map-a-business-process

# map-a-business-process Observe actual cases before drawing the diagram. Preserve variants and failure paths that determine real performance. ## Procedure 1. Define process start, end, customer, owner, purpose, volume, and the decision the map must support. 2. Select representative normal, delayed, rejected, corrected, urgent, and exception cases. 3. Interview and observe operators across roles; inspect timestamps, records, systems, queues, and handoffs. 4. Record each step with actor, input, action, system, decision, evidence, wait, output, and downstream recipient. 5. Separate value-creating work, controls, rework, batching, delay, duplicate entry, and unofficial workaround. 6. Map variants by trigger or policy instead of forcing one false happy path. 7. Validate the map in a walkthrough where operators trace real cases. 8. Quantify volume, cycle time, error, backlog, and capacity only where evidence supports it. 9. Identify problems and improvement hypotheses without editing the current-state map to resemble the desired future. ## Failure plan - Do not use policy documents as proof of actual practice. - Never publish credentials, customer data, personnel detail, or sensitive control weaknesses broadly. - If observation conflicts with policy or compliance controls, record and escalate the gap. - Avoid automating a workaround before confirming the authoritative process. ## Done - Trigger, finish, roles, steps, decisions, systems, evidence, waits, and exceptions are mapped - Operators validate representative cases against the current-state map - Metrics, gaps, and improvement hypotheses are traceable to evidence