In 30 seconds
Start with one real case. Draw what triggered the work, each meaningful step, every decision, the people and systems involved, and what happens when the normal route fails.
The map is useful when the people doing the work recognize it and the next design decision becomes easier.
What you are trying to produce
Use a small set of shapes or labels:
[TRIGGER] → [STEP] → <DECISION?>
├─ Yes → [STEP]
└─ No → [EXCEPTION / OWNER]Mark people, systems and knowledge sources next to the step where they matter. You do not need specialist diagramming software or a formal notation to begin.
Step 1: Set the boundaries
Write one sentence for the beginning and one for the end.
For example:
- Begins when a supplier invoice arrives.
- Ends when the invoice is approved for payment or sent back for clarification.
Without boundaries, the map will keep expanding into adjacent processes.
Step 2: Follow one recent example
Write the actions in the order they happened. Use specific verbs:
- Open the invoice.
- Find the purchase order.
- Compare supplier, amount and line items.
- Ask the buyer about a mismatch.
- Record approval in the finance system.
Avoid broad boxes such as “process invoice.” They hide the work you need to understand.
Step 3: Add decisions
A decision changes what happens next. Write it as a question with observable answers.
Instead of “validate invoice,” ask:
Then draw the path for yes, no and unknown if those lead to different actions.
Step 4: Mark handoffs and systems
For every step, note who performs it and where the information lives. Pay attention when work crosses a boundary:
- one person to another
- email to spreadsheet
- spreadsheet to ERP
- one department to another
- automated step to human review
Handoffs are common sources of delay, lost context and duplicate work.
Step 5: Add exceptions
Ask what happens when information is missing, records disagree, a person is absent or a system is unavailable.
Do not force exceptions back into the happy path. Give them a visible queue, owner or resolution step.
Step 6: Check the map with the people doing the work
Walk through the same real case using only the map. Then try a difficult case.
Ask:
- Where does the map become inaccurate?
- Which step contains more judgment than it appears?
- What information is missing?
- Who else would describe this differently?
Update the map in the conversation. The map is a shared thinking tool, not a final report.
Before and after
| Before mapping | After mapping |
|---|---|
| “Finance checks the invoice.” | The three checks and their sources are visible. |
| “Problems go back to purchasing.” | The mismatch types, owner and return path are explicit. |
| “The ERP has the status.” | The actual status names and who changes them are known. |
Common mistakes
- Mapping the policy instead of a real case.
- Using broad activity names that hide decisions.
- Leaving people and ownership out of the diagram.
- Drawing only the normal path.
- Adding technical detail before the workflow is agreed.
- Making the map so polished that people hesitate to correct it.
What this does not solve
A map shows how work moves. It does not prove that the underlying rules are correct, the data is reliable or AI is appropriate. Those questions belong to later stages.
Good enough to move on when
- The start and end are explicit.
- Steps use concrete actions.
- Decisions show more than one path.
- People, systems and important sources are named.
- Common exceptions have an owner and outcome.
- A domain expert can use the map to explain a real case.
