Process mapping for quality management describes how work moves from a defined start to an intended result. A useful map shows relevant activities, decisions, handovers and exceptions. Its purpose is to support understanding and action, not to create a polished picture that differs from actual practice.
The process management guide explains the governance around mapping. This article focuses on conducting the mapping exercise and validating its output, rather than restating the broader process-approach principle.
Define the mapping question and boundary
Identify why the map is needed. The objective might be understanding repeated handover delays, preparing a controlled change or explaining a complex decision route. The question determines the useful level of detail.
State the triggering event and ending condition. For a customer-change process, the start might be receipt of a proposed change and the end an authorised updated instruction acknowledged by affected operations.
Clarify what remains outside the exercise. A narrow map can be useful, but its limitations should be visible so users do not mistake it for the entire delivery system.
Bring together people who know the work
Include those performing activities and receiving outputs. A manager may know the intended arrangement while users can explain practical exceptions and workarounds. Both views are useful evidence for the exercise.
Follow a real case and compare it with another where variation matters. Ask where information was entered, decisions were made and work waited or returned. Do not rely solely on memory of the procedure.
Resolve disagreement by examining cases and relevant requirements. The most senior person’s account is not automatically the most accurate description of what happened.
Capture the current state honestly
Record the sequence before replacing it with a desired future process. Identify steps, decisions, loops, waiting and transfers of responsibility. A workaround may reveal an outdated instruction, an improvement opportunity or a control failure that needs evaluation.
| Mapping item | Question to ask |
|---|---|
| Activity | What actually happens to the case? |
| Decision | Which criteria determine the next route? |
| Handover | What must the receiving person obtain? |
| Loop | Why does work return or repeat? |
| Waiting | What condition or authority is missing? |
| Evidence | What shows the activity or result occurred? |
These are original prompts, not a mandatory ISO map specification.
Choose the notation for the decision
A high-level view can establish boundaries and relationships. A flowchart can show sequence and branching. A swimlane-style view can make responsibilities and handovers visible. Use notation that intended users can understand.
A SIPOC view can help agree suppliers, inputs, process, outputs and customers before detailed mapping. It does not replace a step-level analysis where decisions and loops matter.
Avoid including so much detail that the main relationship disappears. Use linked levels where necessary, with clear boundaries and consistent references between them.
Validate the map against actual work
Walk through an ordinary case and a relevant exception with the people involved. Check whether decisions have criteria, branches reach meaningful outcomes and responsibilities are clear at handovers.
Compare the map with controlled instructions and system behaviour. A difference should prompt evaluation, not automatic replacement of one with the other. Determine which arrangement is authorised and whether applicable requirements are met.
If a case cannot be followed using the map, identify whether the problem is missing detail, an inappropriate boundary or genuine process variation. Revise through suitable review.
Identify improvement without confusing states
Mark concerns or opportunities separately from the current route. Repeated data entry, unclear acceptance, uncontrolled shortcuts and waiting can guide further enquiry. A map makes issues visible but does not prove their cause or priority by itself.
Use evidence to assess frequency and consequence. A rarely used branch can still be critical; a visually complicated sequence may be justified by an important control.
When designing a future state, evaluate effects on connected work, resources, competence and requirements. Removing a step solely because it looks inefficient can remove information or authority needed later.
Control and use the resulting information
Identify the owner, status and intended use of the map. If it directs work, apply suitable review, approval and change controls. If it records an analysis only, make that purpose clear so it is not mistaken for an authorised instruction.
Retain necessary context about the cases and evidence used. A future reviewer should understand what the map represented and when.
Flowchart examples show how branches and exception routes can be represented. The useful outcome of mapping is a shared, evidence-based understanding that supports controlled decisions, with the current arrangement and proposed changes clearly distinguished.
For a cross-functional map, agree whether each lane represents a role, function or external party. Mixing those meanings without explanation can make responsibility appear clearer than it is. Test a handover by asking both sides what is transferred and who decides whether the receiving activity can proceed.
Preserve relevant assumptions from the workshop. A map based only on one product family or a normal daytime route should not later be presented as a validated description of every case without further evaluation of the differences.