Importance of establishing ownership early
One of the key issues in
BPR is not their accuracy but whether those you assigned responsibility to
actually agree to it.
For that reason, do not
go into process design until you have agreement of ownership. This
should be a reasonably formal checkpoint, so seek sign-off of the
The only exception is if
you are absolutely sure that you have an agile business environment
Importance of maintaining interest
Once ownership is
established there is a danger of neglecting to keep senior stakeholders
involved until the project conclusion.
Whilst day-to-day end-user
involvement is essential as part of process design, do not neglect to
include those senior stakeholders who were involved in signoff of
Of course the level of
detail will be different but highlight issues and challenges encountered
at the process design stage. Such a forum can act as a prototype of the
process governance structure required once the project is complete.
Importance of getting right level of modelling
Analysis models should be
structured and complete. However the models you present to users must be
primarily readable. It is better to over simplify than not to gain an
understanding from your audience. Remember what the model is for! If
this means cutting out conditionality or other detail from the activity
model, than so be it.
Importance of not coupling technology too early
Initially the BPR should
be solution neutral to allow it to progress and remain decoupled from
architectural decisions. However considerations of architectural should be
fed back into the process as they are made, so that any blind-alleys
consideration can be discounted
Whilst it is important to
understand the role of technology to support the business proc, BPR is
often done in advance of it so it is important not to couple uncertainties
in the choice of IT early.
Rather, if the choice of
IT is not yet decided, reference rather the features of the solution,
rather than a presumed choice in technology – another way of looking
at this is just to reference the characteristics the eventual solution
would need to have in order for the business process to work. Where the IT
is known, or is stable then it is fine to reference it.
Where presumed features of
IT is described, always have a dependency section to make all this clear
Importance of emphasising collaboration
is important to consider the impact of responsibility at the earliest
This focuses the mind of the participants involved on understanding if the
responsibility is correctly defined: both of the participant who owns the
responsibility and the named collaborating party. This is especially true
if the responsibility is in a contentious area.
For example: If one party
feels that a goal of the BPR is giving up one responsibility to another
party (say on the grounds of process harmonisation/responsibility
consolidation), if they then see that they are still a collaborator on
that responsibility then they could (correctly) argue that they haven’t
given this up fully – and thus challenge the conclusions. This is the sort
of detail and discussion that we want to stimulate.
Note that being a
recipient of a responsibilities output is not the same as being a
collaborator. Take this analogy: if you went into a shop and made a
purchase you would be the recipient of the goods not a collaborator!
© 2002-2007 Codel Services Ltd
This paper has been prepared
by Codel Services Ltd to illustrate how structured business
modelling can help your organisation. Codel Services Ltd is an IT
Consultancy specialising in business modelling. If you would like further
information, please contact us at: Deryck Brailsford, Codel Services Ltd,
Dale Hill Cottage, Kirby-Le-Soken, Essex CO13 0EN,United Kingdom.
Telephone: +44 (0)1255 862354/Mobile: + 44 (0)7710 435227/e-mail: email@example.com