Operations Process Mapping

Process Mapping into Swimlanes

Purpose

Arguments about a broken process are usually arguments between people holding different mental maps of it, none of which match what happens. A swimlane map forces every step to belong to a role, makes handoffs visible, and separates processing time from waiting time — which is where nearly all elapsed time in a cross-team process goes. The output is the evidence base for fixing or documenting the process.

Prerequisites

• Inputs: the process boundaries — the trigger that starts it and the end state that finishes it — and the roles involved.
• Access: at least one person per role who performs the work, not only their managers; and, where available, timestamps from the systems the process passes through.
• Required: agreement on whether you are mapping the current state or a proposed future state. Mixing them in one map is the most common way a mapping exercise produces a diagram everyone disputes.

If you cannot speak to the people who perform each lane, map only what you can observe and mark the rest as unverified. Do not fill unknown lanes with a plausible flow; an invented lane is defended as fact once it is drawn.

Data classification

Internal. Maps may reveal control points and approval thresholds — where they do, classify Confidential. Do not include personal data, customer identifiers, or credentials in step labels or example artefacts; refer to record types generically. Where a step handles regulated data, annotate the step with the data type rather than reproducing any of it.

Notation

Keep it minimal and consistent. A map that needs a legend of twenty symbols does not get read.

Procedure

1. Fix the boundaries and the unit of work. State the trigger, the end state(s), and what one instance of the process is — one request, one order, one case. Maps drawn without a defined unit mix volumes and become uncomparable.
2. List the roles and give each a lane. Include systems that act autonomously, and include external parties. Anyone who touches the work gets a lane, even if they only approve.
3. Walk one real instance end to end with the people who perform it. Follow an actual case, not a described one. Record what happened, in order, with who did it. This is the as-is map.
4. Add the handoffs explicitly. For each lane crossing, capture what is passed, by what mechanism, whether the receiver is notified, and what happens if it is never picked up. Handoffs with no notification and no timeout are where work disappears.
5. Add waits and their durations. Separate processing time from elapsed time per step. Where system timestamps exist, use them; where not, ask for typical and worst-case durations and label them as estimates. The ratio of total elapsed time to total processing time is usually the finding that changes minds.
6. Add decisions with every branch labelled, including the branches that lead to rejection, escalation, or exit. Unlabelled branches are how the map ends up showing only the happy path.
7. Add rework loops with their frequency. Ask each role what proportion of work comes back to them and why. Rework is systematically under-reported because it feels like normal work; ask about the reason, not the rate, first.
8. Mark the difference between as-performed and as-designed. Where people deviate from the official procedure, capture the deviation and the reason. Deviations are usually rational responses to a process that does not fit — they are findings, not misconduct, and treating them as misconduct ends the interviews.
9. Validate the map with each lane's performers, separately. Circulating the map to managers only produces agreement with the designed process rather than the real one. Correct and re-validate.
10. Annotate the findings on the map: the longest waits, the handoffs with no ownership, the decision points with no defined rule, the rework sources, the steps duplicated across lanes, and any control point that exists in only one person's head. Quantify each where you can, and mark unquantified findings as such rather than asserting scale.
11. Decide what happens next. Documentation of the agreed flow goes to operations-sop-authoring. Automation or system change goes through it-change-management. Supplier substitution goes to operations-vendor-evaluation. Do not draw a future-state map until the as-is map has been validated at step 9.
12. Version and date the map, name its owner, and state the next review. A map dated to a period before a system or team change is history, and should be labelled as such.

Failure modes

• Mapping the designed process. Interviewing only managers or reading only the existing SOP reproduces the document, not reality, and finds nothing.
• Person names in lanes. The map becomes obsolete with the next personnel change and reads as an assessment of individuals.
• Happy path only. Exception paths carry a disproportionate share of cost and are where the process actually fails.
• Waits omitted. A map of processing steps shows a process that appears to take two hours and in fact takes nine days.
• As-is and to-be conflated. Nobody can tell which parts are proposals, so the map cannot be validated.
• Detail beyond the decision it supports. Mapping keystrokes when the question is about handoffs wastes weeks and produces an unreadable diagram.

Boundaries

• Writing executable step-by-step instructions once the flow is agreed — use operations-sop-authoring.
• Technical system or integration design — use engineering-decision-record.
• A user-facing product flow being designed rather than an internal process — use product-requirements-doc.
• Implementing a system or tooling change identified by the map — use it-change-management.

Hand-offs

• Receives from: engineering-incident-postmortem (a failure whose cause is process rather than technical), operations-sop-authoring (an SOP that cannot be written because the flow is disputed).
• Routes to: operations-sop-authoring for documentation of the agreed flow, operations-vendor-evaluation where a step should be outsourced or a tool procured, and it-change-management for system changes.