A coupe of years ago I led a process mapping exercise for a large organization. This project involved 8 sectors of the National Office and 5 regions across Canada. We were very successful but is was a struggle, and in completing the project we learned some very valuable lessons that I have carried with me (and a great case study for the talks I give on business process modelling).

1 – capture the story – to complete the project we had to work with 25 operations people who knew nothing about process mapping. Our first big challenge was aligning the view of analysts (schema based view) with business operations people (experience based view). To do this we started by taking the schema out of play, and concentrated on capturing the story (what has to be done and who does it).

2 – Business is not always linear – much of the work flowed in a linear fashion that was easy enough to translate into process maps. There comes a point in the administration part of the process where the work becomes ad hoc, event driven and unpredictable. Force-fitting this into a linear mapping can lead to loss of credibility or loss of engagement with the clients. This was where BPMN and its approach to mapping events became a great solution.

3 – Business is not logical – I have recently been on the client side of a process mapping exercise and watched two very experienced analysts drive every business person in the room crazy by telling people that this is how you map things. I almost lost it when they mapped 3 options as decision 1:y-n – decision 2: y-n – decision 3: y-n. Stop it. People do not think that way. Business is not done through a series of logical gates. When mapping decisions, do them the way business works – 1 decision, 3 options (this is another feature of BPMN). When working with business people, think like business people not automated solutions.

Cheers

I totally agree on using diagrams.

My addition/advice would be to start at the end of the process (often the trigger point), your step 3. A workflow will be triggered at some point and has to deliver something. So first find the trigger and if there is no trigger what is the point of the process? Next, who/what is/are the customer(s) of the process result and are the requirements for the end product
Now find out what steps to take from the available information in this process in order to realize the end product. And every step has to add some value to the customer, this way your workflow will stay lean.

Kind regards,
Wouter