Key principles

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 ownership documentation

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 ownership periodically.

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

It is important to consider the impact of responsibility at the earliest practical stage. 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!

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: info@codel-services.com