operations-process-mappinglisted

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