A process map for automation must show what actually triggers work, who decides, where information comes from, what waits, how exceptions return and what proves completion. A neat happy-path diagram is not enough.
Observe real cases before designing the future state. The purpose is to remove unnecessary work, expose policy decisions and create testable automation boundaries.
Frame one process instance
Name the customer or beneficiary, start event, end outcome, included variants and owner. Set a boundary narrow enough to observe end to end. “Procurement” is too broad; “approve and issue a standard purchase order” can be mapped.
Record volume, peak, value, risk and the current outcome measure. This gives the automation decision a baseline.
Follow real work
Sample ordinary, urgent, rejected and reworked cases. Ask participants to show inputs, systems, messages and evidence. Capture what happens, not what the procedure says should happen.
Note shadow spreadsheets, personal reminders, copied data and informal approvals. These often carry essential state that the official system does not expose.
Use six map elements
| Element | Question |
|---|---|
| Event | What creates or changes the case? |
| Activity | What work transforms information or state? |
| Decision | Who applies which rule using what evidence? |
| Wait | What dependency or clock prevents progress? |
| Exception | How does the case deviate, recover or stop? |
| Evidence | What record proves outcome and control? |
Separate policy from workaround
Ask why every approval, copy and reconciliation exists. Mark whether it satisfies policy, mitigates a system limitation, compensates for poor data or has no current owner. Preserve the control outcome while challenging the implementation.
Do not automate duplicate entry merely because it is familiar. Fix system authority or integration where proportionate.
Measure time by state
Record touch time, wait time and rework separately. Automation often reduces a small handling step while the case still waits days for a decision. Identify queue age and the condition that releases it.
Segment by variant. A small number of exceptions may consume most effort and determine whether straight-through automation is realistic.
Define data and system authority
For each input and output, name the source, identifier, quality rule, update right and consumer. Trace the case across systems and note where status is inferred rather than recorded.
Automation must detect duplicate and replayed events. Define what happens when an interface succeeds partly or returns conflicting data.
Design the future state in layers
- Remove activity that has no useful outcome or control.
- Simplify rules and variants where owners agree.
- Clarify responsibility and authoritative data.
- Use native system capability or supported interface.
- Automate stable routing, calculation and evidence.
- Keep judgement and unusual exceptions with people.
This order prevents technology from preserving avoidable complexity.
Create acceptance scenarios
Turn the map into a normal case, boundary case, rejection, cancellation, duplicate and system-failure scenario. State starting data, expected state, evidence and responsible role.
These scenarios should drive demonstrations, build tests and operational rehearsal. A flowchart without executable examples remains open to interpretation.
Add an evidence layer to the map
For every control or state change, show the record that proves it: approved decision, validated input, timestamp, system response or reconciliation. Mark evidence that currently lives only in email or personal knowledge. This layer distinguishes a process that merely moves from one that can be operated and audited.
Keep evidence proportionate. Recording every click adds noise; retain what explains authority, outcome and recovery.
Run a challenge workshop
Give participants a specific case and ask them to challenge the map: missing information, absent owner, policy conflict, unavailable system, repeated event and customer cancellation. Update the flow only when the group agrees the state and responsibility.
A challenge workshop is more productive than asking whether a polished diagram “looks right.” It turns tacit exceptions into design decisions.
Version the process and decisions
Record map version, owner, assumptions and approval date. Link later automation changes to the affected process rule and test. When policy or systems change, review the relevant branch rather than redrawing from memory.
Retain the earlier version for rollback and explanation. Operational teams need to know which process is currently authoritative.
Set the automation boundary
Choose which component owns process state and how humans see and change it. Define timeouts, retries, escalation, manual intervention and recovery. Keep a case identifier across the chain.
When one automation calls another, make input, output and failure explicit. Do not let several scripts silently share ownership.
Validate with participants
Walk the future map with people who perform, approve, support and receive the process. Ask them to challenge the difficult case and identify new work created elsewhere.
Approve the map, decisions, measures and exceptions before detailed automation. Update it after the pilot so the operating documentation reflects reality rather than the original workshop.
Give the final map an accountable owner and next review trigger. A process changed by regulation, organisational structure, volume or system replacement should not continue executing an outdated design simply because its automation still runs.