# Operations Process Mapping

> Maps a real process into a swimlane by role, capturing every handoff, decision, wait, and rework loop, distinguishing the process as performed from the process as designed, and quantifying where time is actually lost. Use when a cross-team process is slow, error-prone, or disputed, or before documenting or automating it; trigger on 'map this process', 'draw the workflow', 'swimlane diagram', 'where does this get stuck', 'nobody agrees who does what here'. Not for writing the step-by-step instructions once the flow is agreed (use operations-sop-authoring), not for system architecture diagrams (use engineering-decision-record), and not for a product feature flow (use product-requirements-doc).

- Skill: `alihusains/operations-process-mapping` (Agent Skill)
- Install (CLI): `npx skillmds@latest add alihusains/operations-process-mapping`
- Raw SKILL.md: https://api.skillmd.com/api/skills/alihusains/operations-process-mapping/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: alihusains (https://skillmd.com/u/alihusains)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/alihusains/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.

| Element | Meaning | Label with |
| --- | --- | --- |
| Lane | One role, team, or system that performs work | The role, not a person's name |
| Step | One action performed within a lane | Verb plus object: "verify identity documents" |
| Decision | A branching point | The question, with every outgoing path labelled |
| Handoff | Work crossing a lane boundary | What is passed and by what mechanism |
| Wait | Elapsed time with nobody working | The queue and its typical duration |
| Rework loop | Work returning to an earlier step | The reason it returns and how often |
| External party | Customer, supplier, or regulator | Their lane, at the edge of the map |
| Start / end | The trigger and each terminal state | Include the unhappy terminal states |

## 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.