You may like to try this simple experiment for yourself, choosing any processes you like. (We do this in training sessions as well, and it’s always interesting to see how long it takes a group to settle on a process..well, you’d need to know processes and what they’re called to start with)
- Ask yourself who the customer of that process is
- Try to find out what the ‘official’ objective of the process is, e.g. what people think what is being accomplished through the process and why it exists
Chances are that you will already see a disconnect at this point.
Next comes the devious bit:
- Sketch out a rough draft of the process from the customers perspective. This will usually include most if not all touch points he has with the company. Write down the customer expectations with regard to quality and perceived or expected value for each touch point.
- Try to identify what parts of the [internal] process specifically address the customers expectations.
Besides the fun of it all, this simple approach may also help you identify which aspects of your processes are dependent on certain customer expectation (this could be the one area in which the dreaded word “agility” might actually make sense).
Of course, in many cases this experiment will already come to a sudden stop at stage 2: Never mind the process objective when we don’t even know what the process is. This may go some way to explain, why even constant reengineering of processes seldom leads to real improvements. Saving yourself the time of thinking about the basics during projects can come with a much larger bill later on.
