Forbes.com has an article that is garnering some attention around the web. it's called "Stalking and Capturing a Business process" and it is concerned with how we design a business process. As the article says:
It goes on to mention several methods of doing this. These include Wiki-Based process discovery, Task-based process discovery and Mash-up-based process discovery.
The problem I have with all these approaches is that they are fundamentally flawed in their underlying principal. The article is predicated around the fact that new business processes come down 'from on high' with minimal, if any interference from the users. This is flawed for two reasons
1) Processes do not come down 'from on-high'. Good process design is a combination of interview, facilitation and process discovery
2) Asking the users to design the process using wikis, mash-up's and task-based discovery is tantamount to asking the fox to design the chicken-coop. Users do not know the best process to do their work. They know the current process, they may even know some flaws in the current process, but they don't have an overall view of the end-to-end process and they certainly don't know how to design the process to work correctly with, for example, a new system that may impose restrictions on how their workflow operates. Many users, in fact, do not even understand the difference between a business process and a procedure (but then again not many process analysts and industry experts do either). Getting them to define and document their own processes is not a viable proposition.
The key issues is that users are users and process analysts are process analysts. It is the role of the process analyst to determine what happens at the moment (using facilitated sessions, questionnaires and observation) and it is the role of the user to validate and confirm that. Of course the analysts should work in tandem with the user and of course the process must be defined whilst understanding the users needs and requirements, but the skill of the process analyst (The good one anyway) is in putting together a process which meets those requirements as well as giving them something they don't already have: simplicity and easy of use.
Stalking and capturing your process will result in a caged wild animal. You don't want one of those running your business, do you?
I do agree with the following point made in the article:
I am also aware enough to understand that in big business process improvement projects working in this iterative or waterfall method might not be allowed.
We can always hope, though.
Why are business processes seen as being handed down from on high? This week, the JargonSpy argues that business processes are like wild animals. They should be stalked, crept up on and then captured.
It goes on to mention several methods of doing this. These include Wiki-Based process discovery, Task-based process discovery and Mash-up-based process discovery.
The problem I have with all these approaches is that they are fundamentally flawed in their underlying principal. The article is predicated around the fact that new business processes come down 'from on high' with minimal, if any interference from the users. This is flawed for two reasons
1) Processes do not come down 'from on-high'. Good process design is a combination of interview, facilitation and process discovery
2) Asking the users to design the process using wikis, mash-up's and task-based discovery is tantamount to asking the fox to design the chicken-coop. Users do not know the best process to do their work. They know the current process, they may even know some flaws in the current process, but they don't have an overall view of the end-to-end process and they certainly don't know how to design the process to work correctly with, for example, a new system that may impose restrictions on how their workflow operates. Many users, in fact, do not even understand the difference between a business process and a procedure (but then again not many process analysts and industry experts do either). Getting them to define and document their own processes is not a viable proposition.
The key issues is that users are users and process analysts are process analysts. It is the role of the process analyst to determine what happens at the moment (using facilitated sessions, questionnaires and observation) and it is the role of the user to validate and confirm that. Of course the analysts should work in tandem with the user and of course the process must be defined whilst understanding the users needs and requirements, but the skill of the process analyst (The good one anyway) is in putting together a process which meets those requirements as well as giving them something they don't already have: simplicity and easy of use.
Stalking and capturing your process will result in a caged wild animal. You don't want one of those running your business, do you?
I do agree with the following point made in the article:
Fred Brooks, author of The Mythical Man Month, teaches us to plan to learn from the process of building the first version of asystem, and then throw it away and build a second one that has a better chance of working. Advocates of agile and extreme programming tell us to build the smallest possible system and put it in the hands of users to get evidence of what really is needed. Then keep this loop going and
improve the system rapidly. Googlehas led the way in launching large-scale products advertised as beta versions, a moniker that sets the expectation that continual evolution will take place. This is the triumph of incrementalism.
I am also aware enough to understand that in big business process improvement projects working in this iterative or waterfall method might not be allowed.
We can always hope, though.
