Tuesday, March 18, 2008

Process Levels - Ask the basic questions

I was in a training class again last week. The quintessential question came up as to how many levels of processes should be there. Should we have one process that covers all levels of details? That would be akin to mapping your IT process using BPMN. How does it reflect the simplicity of the business users?

Answers ranged from 0, zero to 4 to 7.

This reminded me of an earlier discussion with Dr Naci Akkok - credit is due here.
He said think about what question is the model answering. Is it answering the "what" question or the "how" question. Users will need at least these two levels - one that answers what happens in my organization; the other level or levels that answers the how question.

Now its important to realize that its better to draw boundaries of how many levels of what questions and how many of how questions would we want to address. This will prevent proliferation of levels and will also mandate and facilitate common understanding. I would love to put a number out here as a recommendation but it would vary with the organization and the complexity of processes therein. I would recommend a number between 2 and 4 should be good enough to capture the details of business processes in your organization.
Oracle BPA Suite provides for multiple levels of processes. BPMN process levels can be further detailed.

Reminder - Disclaimer: The views expressed are entirely my own and do not reflect those of Oracle or a methodology of using Oracle BPA Suite.

7 comments:

Jim Lange said...

I agree that this is an area that people get hung up on all the time. I think that there are fundamentally two questions:

1) How many levels?
2) What should be the lowest level?

I think the second question is often the hardest since it is possible to decompose a process to the point where it is almost ridiculous. However, if you get the bottom level correct, the number of levels above it are a byproduct of the total scope you are modeling (the breadth) and choosing a "reasonable" diagram size and complexity for the intermediate levels from top to bottom (which determines depth).

A couple of guidelines that I recommend to help determine when to stop decomposing are:

* Does the task represent a complete action on a business object? For example, the result of "Enter Order" is that an order exists when it did not exist previously. If you decompose this into "Enter Customer Info", "Select Products", "Choose Shipping Method", and "Submit Order"; the order does not actually exist until the last step since you can stop at any time before you reach the end and nothing is created (this is true for both an automated or paper-based system). In this example, I believe that decomposing below "Enter Order" is not useful for the business model, though it could be useful as part of a design document for a software UI. A complete action could also represent a change of state of a business object such as "Approve Requisition".

* Are the boundaries of the task natural points for tracking progress or for notifications? In other words, would it makes sense to be notified that you need to start the task and to notify someone else when you are done? If notification is not appropriate, is the completion of the work a useful milestone for capturing statistics that could be used by a BAM system? Using the prior example, it probably isn't very interesting to capture the time between choosing a shipping method and submitting an order, but capturing the time to enter the order from start to finish is very interesting.

I have found that when working with customers that once people embrace process modeling, there is a tendency to continue decomposing past the level where it is helpful for the reasons we model: Visually identifying bottlenecks and inefficiencies, simulation, monitoring and improving via BAM, automating via workflow, and last, but not least, helping people understand the process.

Anonymous said...

Great article. I agree that there should be a minimum of two levels. I do a lot of ITIL process design and a minimum of two levels are essential in order to differentiate between a process and a procedure. In general for ITIL four levels are used.

Anonymous said...

Absolutely with you it agree. Idea good, I support.

Anonymous said...

You are not right. I am assured. Let's discuss. Write to me in PM, we will communicate.

combattery84 said...

Dell Latitude D610 Battery
Dell Latitude D620 battery
Dell Latitude D630 battery
Dell xps m1210 battery
Dell e1705 battery
Dell d830 battery
Dell inspiron 2200 battery
Dell inspiron 640m battery
Dell inspiron b120 battery
Dell xps m1210 battery
Dell inspiron xps m1710 battery
Dell inspiron 1100 battery
Dell 310-6321 battery
Dell 1691p battery
Dell Inspiron 500m battery
Dell 6Y270 battery
Dell inspiron 8600 battery
Latitude x300 series battery
Dell latitude cpi battery
Dell 1x793 battery
dell Inspiron 1501 battery
Dell 75UYF Battery
Dell Inspiron 1720 battery
dell Latitude C640 battery
Dell XPS M140 battery
Dell Inspiron E1405 battery
dell 700m battery
dell C1295 battery
Dell U4873 Battery
Dell Latitude C600 battery
Armada E700 Series battery

Nikola said...

Only 17 existing paintings are attributed to famed artist Leonardo da Vinci.
online car insurance

Nikola said...

1 out of 350,000 Americans get electrocuted in their life.laptop review