Process mapping sounds straightforward until you try to do it accurately. Most organisations have process maps. Most of those maps describe the intended process, not the actual one. The difference between those two things is usually measured in hours of lost time per week, and it is almost always where the improvement opportunity is hiding.
Start with observation, not interviews ¶
The instinct is to gather the team in a room and ask them to describe the process. This produces a map of how people think the process runs, filtered through how they think it is supposed to run. It is useful background, but it is not a reliable map. Start instead by watching the process run in real time. Sit with the people doing the work. Note every step, every decision point, every time something is handed to another person or system. Do this for at least two full cycles before drawing anything.
Time every step, not just the total ¶
Total cycle time tells you how long the process takes from start to finish. Step-level timing tells you where the time goes. These are different and the second is far more useful. A process with a three-day cycle time might have four hours of actual work in it and sixty-eight hours of waiting. The waiting is not evenly distributed. One approval gate might account for forty of those sixty-eight hours. You cannot find that from a total cycle time figure.
Document the exceptions, not just the standard path ¶
Every process has a standard path and a set of exceptions. The standard path is usually well-documented. The exceptions are usually handled informally, by specific people, using methods that exist nowhere in writing. In our experience, exceptions account for between 15 and 40 percent of transaction volume in most workflows. Mapping only the standard path means your future-state design will encounter the exceptions as surprises. Map them now, deliberately.
Validate the map with the people who run the process ¶
Once you have a draft map based on observation and timing, walk through it with the process operators, not the process owners. Operators know the workarounds, the informal steps, and the edge cases that do not appear in any documentation. They will correct your map in ways that matter. A validated current-state map is the only reliable foundation for a future-state design.
Resist the urge to redesign while you are still mapping ¶
Current-state mapping and future-state design are two separate activities. Running them simultaneously is one of the most common mistakes in process improvement projects. When you spot an obvious fix during mapping, note it and move on. Do not stop to redesign. The obvious fix often looks less obvious once you have the full picture, and changes made before the map is complete tend to create problems downstream that were not visible at the time.
A good current-state map takes longer to produce than most organisations expect. It is also the single most valuable document in any process improvement project. Everything that follows depends on it being accurate.