If you've spent any amount of time and effort looking at your processes you will no doubt like to think that they are now well designed and running at optimum efficiency (Or at least running better than they were prior to you starting to review them). After all if you've gone to the effort of looking at them, documenting them and modifying them - even if it was through the implementation of an EA or BPM tool - then you have to hope that they are in a better state than they were before. However data shows that this may not result in a working process.Teraneon Consulting Group in Germany - which is run by fellow BPM Nexus committee member Thomas Olbrich and his business partner Dr. Norbert Kaiser have just released information relating to their Process Testlab.
The Process Testlab is an environment created to fully test a process prior to it going live. The test lab consists of four major steps:
Test 1: Validation – CompletenessThis is where we check if the process description is in itself complete (are all necessary steps/tasks included in the process design, likewise roles, IT-systems etc.)
What we actually do in this step is to implement the process on our test systems and see where they come up with warnings.Test 2: Validation – Content and ObjectivesOnce the client has updated his process to get rid of the warnings from Test 1, we let various teams from the client experience the process by running it on our systems with distributed roles. The fun part of this is that this is done on the basis of workflow and BPM technology, so the routing of the process across distributed roles and systems is comparable to the final process solution the clients would like to implement…but as this is done ‘only’ on our system system, the client doesn’t need to risk implementing the process before checking if it truly does what it should.Test 3: SimulationAll process designs are based on assumptions. Assumptions about workload, about ressource availability, system response times, influences of other processes and not forgetting customer behaviour (for those who regard this as an essential design input). What the Process TestLab does is to take these different classes of assumptions and build scenarios around them by varying the assumptions. Then we subject the process to these scenarios to determine how the process will behave and perform.Test 4: StresstestThis comes in two parts. The first stresstest is rather like an extreme simulation to determine the limits or breaking points of a process. Sounds like a lot of theory until you think back to the latest case of birdflue, volcanic eruption etc. It’s all about the question of how much stress your process and its resources can take before they seize to be functional any longer. The second stresstest has turned out to be a real eye-opener for some clients: While during the validation test we looked only at single processes instances to determine the quality of the process, this stresstest puts the clients team under stress by producing increasing workloads. Not only does this tell where the cut-off point lies, the point at which the process and the organisational structure cannot provide the required support but it also offers a preview of the conditions employees would face after implementation.
Data from the first few months of running the test lab has indicated that no single process checked in the Process Testlab was complete and could have been implemented and 80% of all processes that reached Test 2 contained logical errors, errors of routing and other types which would have led to unwanted and even wrong IT implementations.
As Thomas says in his blog entry: "Faulty process design will inevitably lead to faulty processes. And it’s no secret that repair work on processes and process systems is always more expensive after the fact than the avoidance effort one might have invested before implementation"
How well designed are your processes? I've talked about this before when I talked about 'Exceptions and Problems - The Non-Standard Process' and 'White Space - The Invisible Problem', but basically there is a tendency to design processes around an ideal state and not worry about what happens in real life. Furthermore there is a tendency to ignore the fact that processes need to talk to one another and hence either forget to make the link or - more likely - to create a simplistic link between two processes that has little relationship to what happens in real life. In either case you will fall into the trap Thomas has mentioned here.
The statistics shared by Thomas are quite scary. What's scarier though is that I think they may be painting a brighter picture than the reality.
Things might actually be worse.
Reminder: 'The Perfect Process Project Second Edition' is now available. Don't miss the chance to get this valuable insight into how to make business processes work for you. Click this link and follow the instructions to get this book.
All information is Copyright (C) G Comerford
