Process Map

A process map is a diagram of the steps, decisions, handoffs and systems in a process, drawn in the order they happen. ASQ describes the flowchart as a common type of process map and lists it among the seven basic quality tools.

In a root cause analysis, a process map helps answer a narrower question than “why did this fail?”: where in the flow does it fail? Knowing the step, the decision or the handoff where things go wrong focuses the search for causes.

How a process map helps root cause analysis

A process map makes the flow visible enough to compare it with what happened:

• Locate the break. Mark the step where a symptom appears, such as an error, a drop-off or a delay, and the steps just before it.
• See handoffs and decisions. Problems often appear where work passes between people, teams or systems, or where the flow branches.
• Compare intended and actual. A map of the process as designed, overlaid with observed paths, shows where practice differs from the plan.
• Constrain hypotheses. A possible cause that sits in a part of the flow the failing cases never reach is unlikely to explain them.

A map shows where to look. It does not explain why the problem occurs, and a map of the intended process can hide the workarounds and exceptions where many failures start.

Which mapping exercise should you use?

Different maps answer different questions. Choose the one that fits what you need to see:

You want to map	Use	What it shows
The front and backstage of a service	Service Blueprint	The customer’s steps alongside the people, processes and systems that support each one
How users move through a product to complete a task	Flow Analysis	Task and user flows, and where actual paths diverge from the intended ones
Where customers drop out of a sequence of stages	Funnel Mapping	Conversion between stages, and the bottlenecks between them
A typical customer’s experience over time	Journey Mapping	Actions, thoughts and feelings across the journey; see also customer journey map
One specific failure, as it actually happened	Incident Timeline	The sequence of events before, during and after the failure, with evidence and gaps marked

The first four describe a typical or intended flow. The incident timeline reconstructs one occasion. In an investigation they often work together: a blueprint or flow map locates the step and the systems involved, and a timeline establishes what changed there and when.

A worked example

The following flow and observations are illustrative. They are not results from an actual customer study or incident.

The subscription service from the root cause analysis guide maps its setup flow as designed: sign up, enter company details (typed or autofilled), press Continue, validate, save, create a first invoice. On this map, both entry paths reach Save.

The team then overlays what it observed in support tickets and usability sessions. The reports cluster in one place: customers press Continue on company details and get a generic error, and the complaints mention autofill. To see that step properly, the team splits the “enter company details” box into what happens on screen and what is submitted. The map now shows a gap the intended version hid: between “the field shows a value” and “the value is submitted”.

The map tells the team where to investigate, not what is wrong there. The root cause analysis guide shows how it then reproduces the failure and establishes the mechanism.

Limitations

A map of the designed process is not evidence about the actual one. Check it against observations, logs or the people who do the work, and label which version you drew.

Locating a step is not explaining it. The step where a symptom appears may not be where the cause is. A problem earlier in the flow, or outside it, can surface later.

Detail is a trade-off. Too little detail can hide the step that matters, as in the example. Too much makes the map hard to read and maintain. Add detail around the problem area rather than everywhere.

A typical flow does not show one incident. For what happened during a specific failure, reconstruct it with an incident timeline instead.