|The traditional way to identify process improvement is to map the “as-is” state. Then you invite the users to point out on the map the problem areas. These then become the targets for improvement projects. Now, while this approach does certainly yield efficiencies, it doesn’t always capture all the potential opportunities.
A process map does not tell the whole story of what’s going on in a process. It’s designed to show people how the process is supposed to work. But it does a pretty poor job of showing you where the process goes wrong. So here are seven areas to consider that should help you see past the process diagram and identify more opportunities for improvement.
A handoff occurs when responsibility for the process passes from one person to another. The swim lanes on a process map tell us where that happens. That does not tell us much. In fact, this is where things go wrong in a process. At this point, not only are we passing on the responsibility for the process. We are also transferring information about the transaction in the process. It’s a crucial point of communication. If it goes wrong, the person who is responsible for the next part of the process doesn’t have enough information to complete the process successfully.
Look at a process diagram and show me where it says: “Bottleneck here!” You can’t because they don’t. Yet bottlenecks are by definition, where the constraints are in a process. You can improve any other part of the process, but nothing will move faster than the slowest part of the process.
We don’t work on assembly lines, dedicated to a single process. In offices we work on lots of different processes concurrently. And that means we have giant queues where we park work we can’t get to yet while we work on one thing at a time. How we prioritize the tasks in those queues has a tremendous impact on output. But you’d never know from the process diagram.
When you can’t follow the process, it’s called an exception. At that point the process diagram is pretty academic. That’s the polite way of saying “useless.” On average, process exceptions are about the third biggest cause of problems in processes. Most organizations handle exceptions in email. But now we’re off the rails. We have no guidelines and we have buried our problem in a blizzard of email.
IT provides the mathematical model of what is going on in the real world process. It should be an exact and faithful record of the state of affairs at a given moment. Sometimes, however, there can be a mismatch between what the data can show and what the process is actually going on in the process. That mismatch might be because there is more than one system and they don’t talk to one another. Or the system is not updating fast enough to be an accurate record.
So the process diagram shows the sequence of activities. But sometimes it is more instructive to see the information flows that the process triggers. And it is not the same. If you plot a “spaghetti” diagram showing the path of the information you will see all this frantic to-ing and fro-ing as the process flows. It’s the classic case of the stately swan on the surface paddling like mad underneath.
Sometimes in a process somebody has to go look things up, or check on something. If the data is difficult to find you have introduced extra work and friction on the individual who is responsible for this particular activity. The IT system is not doing its job of providing timely information at the fingertips of people who need it, making it easily findable and searchable.
In summary, don’t get me wrong; I am not dismissing process maps. In fact, I have written a video tutorial series on using the free online tool, yEd for process mapping . Process maps are an essential part of every process consultant’s toolbox. However, they are not enough on their own to give you a way to expose every opportunity for making process improvements. Over time, I have found plenty more to go at when I have managed to look beyond the process map and into the areas above. I hope this can help you too.