The short version
Key takeaways
- Map one outcome from a clear trigger to completion, including waits, decisions, exceptions, and rework.
- Observe the work with the people doing it; written policy rarely captures the full current state.
- Redesign around fewer handoffs, explicit ownership, visible controls, and a measurable pilot.
Scope one process and one customer of the outcome
Choose a process with a visible problem: slow quoting, missed lead follow-up, invoice exceptions, onboarding delays, duplicate data entry, or unclear project approval. Define the trigger, final outcome, internal or external customer, normal volume, and boundary. Avoid trying to map an entire company at once.
Write the current performance question: "Why do complete supplier requests wait four days before approval?" is more useful than "improve procurement." Capture baseline elapsed time, hands-on time, backlog, error or rework rate, and exception volume where the data is available.
Observe the current state without blame
Interview the people who perform and receive the work. Follow several real cases, including an exception. Collect the forms, messages, systems, decisions, approvals, and evidence used. Ask what starts the step, what information is required, how completion is known, and what happens when information is missing.
Map what actually occurs, not what a policy says should occur. Differences reveal training gaps, obsolete instructions, or workarounds that keep the process functioning. Link any approved procedure to a maintainable SOP rather than turning the map into a wall of instructions.
Draw steps, decisions, waits, handoffs, and evidence
Use swimlanes for roles or systems and a small symbol set for start/end, action, decision, wait, and record. Number the steps. Mark elapsed time and hands-on time separately. Show every transfer of ownership and every place data is retyped.
| Map element | Question | Common signal |
|---|---|---|
| Wait | What must happen before work continues? | Queue, batching, unavailable approver |
| Decision | What rule or evidence determines the path? | Inconsistent judgment |
| Handoff | Who knows they own the next step? | Lost email or duplicate follow-up |
| Rework | Why does completed work return? | Missing input or unclear quality check |
Redesign the constraint before adding software
Look for unnecessary approvals, batching, duplicate entry, unclear decision rules, overloaded roles, missing information, and exception paths that rejoin poorly. Simplify, move quality checks earlier, collect required information once, and make ownership visible. Preserve controls that manage real risk.
Only then use the automation prioritization matrix to decide whether technology improves the redesigned process. If the workflow needs coordination across milestones and dependencies, evaluate a project management system against the mapped needs.
Pilot the future state and maintain it
Choose a narrow team, location, or transaction type. Train participants on the new path, the reason for the change, and the exception route. Compare elapsed time, hands-on time, backlog, rework, errors, customer outcome, and staff feedback with the baseline. Watch for work that moved outside the map.
Assign a process owner and review date. Update connected forms, training, system rules, and SOPs together. Retire obsolete instructions. The final map is not a poster; it is a shared model for operating, measuring, and improving the workflow.
Common questions
Frequently asked questions
How detailed should a process map be?
Detailed enough to expose ownership, decisions, waits, handoffs, systems, evidence, and meaningful exceptions, but not so detailed that the operating question disappears.
Should the ideal process be mapped first?
Usually map the current state first. Otherwise the redesign may ignore constraints, workarounds, and exceptions that determine what will actually work.