A process map is worth drawing only if it records what happens rather than what the procedure says. Interviews produce the version everybody agrees on; watching produces the version that runs.
This guide covers how to walk a case rather than describe it, why mapping the one that went wrong matters more, and what separating work from waiting usually reveals. A map that nobody acts on is an expensive drawing, so the exercise is built around producing one change rather than a complete picture.
Key takeaways
- Watch, do not interview: Interviews produce the procedure; watching produces the process, and the difference is the point of the exercise.
- Map the case that went wrong: The extra boxes in that map are where the cost sits, usually handled by somebody's private spreadsheet.
- Label work and wait: Working time is routinely under a fifth of elapsed time, which redirects the improvement conversation.
- Agreement before automation: Where two people decide the same case differently, automating encodes one view and needs a release to change.
Look for the business signal behind the technology
The signal that a process needs mapping is that nobody can describe it the same way twice. Two people give different accounts of the same work, the written procedure does not match what happens, and new staff learn it by sitting next to somebody.
Mapping can also be a way of avoiding a decision. A process map that becomes a project in its own right, with workshops and a notation standard, has stopped being evidence and become an activity. Map the case, not the organisation.
Walk one case through from the trigger to the outcome, watching rather than interviewing. Interviews produce the procedure; watching produces the process, and the difference between them is the entire reason for doing this.
Use four lenses to understand the opportunity
Trigger
Record what starts the work, how it arrives, and how often it arrives in a form nobody expected. Unexpected triggers are where the undocumented process begins, and they are invisible in any map drawn from the written procedure.
Handoff
Mark every point where the work changes hands, how it is passed, and how long it waits there. Handoffs are where the elapsed time accumulates, and an email handoff with no queue is the most common place for a case to sit unnoticed.
Decision
Write down the judgements a person makes, what they base them on, and how often two people would decide differently. Variation between people is the finding that determines whether the step can be automated or only supported.
Outcome
Define what finishing means, who confirms it, and how the customer finds out. Processes frequently have no agreed completion point, which is why the same case appears as open in one system and closed in another.
Assess the current state without buying software first
Map two cases: one that went normally and one that took three times as long. The extra boxes in the second map are where the cost sits, and they are usually handled by somebody's private spreadsheet rather than by any system.
Decide what useful measurement looks like
Label every step as work or as wait and total each column. Teams routinely find that working time is under a fifth of elapsed time, which moves the improvement conversation away from making people faster and towards removing the queues.
Count how often a case returns to an earlier step. Rework is invisible on a map drawn as a straight line, and it is usually the single largest opportunity the exercise will find.
When software is likely to help
Automation is worth considering once the map shows a repeated path, a stable rule and a measurable wait. Those three together mean the computer can do something a person is currently doing without judgement.
Where the map shows that two people decide the same case differently, the first fix is agreement rather than software. Automating a contested rule encodes one department's view and produces an argument that now requires a release to settle.
For how mapped processes turn into roles, systems and decisions, see How to Build a Digital Operating Model for Your Business.
Start with a bounded improvement
Remove the longest wait on the map, by delegating, by changing the order or by deleting a step, and re-time the same case type a month later. One measured change beats a redesign nobody can attribute.
Separate a structural constraint from a temporary problem
Before the map becomes a roadmap item, check that the pattern survives different conditions. Does the handoff still stall when the team is fully staffed, in a quiet week, with the experienced person present? A delay that disappears is a resourcing question.
Put the cases in a grid: routine and exceptional on one axis, busy and quiet on the other. Look at how the trigger, the handoff, the decision and the outcome behave in each square. Usually one boundary fails rather than the whole process.
Where the constraint is structural, state the improvement so it could be proved wrong: this handoff will complete within a day for this case type by the end of the quarter. A mapping exercise with no such claim ends as a diagram on a wall.
Risks to make visible
| Lens | Common risk | Early response |
|---|---|---|
| Trigger | Work arrives in a form the map omits | Record how often the trigger turns up in a way nobody expected. |
| Handoff | Waiting between teams goes unrecorded | Label every step as work or wait and total the two columns. |
| Decision | Two people decide the same case differently | Ask both and record how far apart the answers are. |
| Outcome | Nobody agrees when the case is finished | Define completion, name who confirms it, and say how the customer finds out. |
A 30-day validation plan: Business process mapping
Days 1 to 5: walk one case, do not interview anyone. Follow a single case physically or on screen from the trigger to the outcome, writing down what actually happens. Interviews produce the procedure, and the procedure is the version everyone agrees on rather than the version that runs. The difference between the two is the point of the exercise. Do it at the desk rather than in a meeting room, because the detail you are after is in the second screen somebody opens without thinking.
Days 6 to 15: map the case that went wrong. Take a recent case that failed or took three times as long and map that one too. Put the two maps side by side. The extra boxes in the second map are where the cost sits, and they are usually handled by someone's private spreadsheet rather than by the system. Ask what made it recoverable, since the person who rescued it is holding knowledge that exists nowhere in the documented process.
Days 16 to 30: mark waiting against working. Go through both maps and label every step as work or as wait. Total each column. Teams routinely find that the working time is under a fifth of the elapsed time, which redirects the whole improvement conversation away from making people faster. Show both totals to the people who work the process, as they generally recognise the result immediately and management generally does not believe it.
A practical worksheet: Business process mapping
A process map is only worth drawing if it records what happens rather than what the procedure says. Walk one case through from start to finish and complete a row at each point below.
| Decision area | What to record |
|---|---|
| Trigger | What starts the work, how it arrives, and how often it arrives in a form nobody expected |
| Handoff | Every point where the work changes hands, how it is passed, and how long it waits there |
| Decision | The judgements a person makes, what they base them on, and how often two people would decide differently |
| Outcome | What finishing means, who confirms it, and how the customer finds out |
| Measurement | Waiting time against working time for the same case, which is usually the most surprising number on the sheet |
Map the case that went wrong as well as the standard one. The standard path is generally already understood, and the difference between the two maps is where the cost sits and where the automation argument is either won or lost.
Related guides
- Much of this depends on what is in Digital Transformation Roadmap: A 7-Step Business Guide.
- If the constraint turns out to be elsewhere, read Paperless Workflow: How to Digitize Paper-Based Processes.
When the priorities in Business Process Mapping: Steps, Symbols, and Examples need sequencing against a real budget, Discuss Your Digital Roadmap.
Ali Boran Gazel