Follow a real item through the process
Pick a completed request, order, or case and trace it from arrival to completion. Record who touched it, which system held the information, and what allowed it to move forward. Include time spent waiting for a person or a missing field.
Ask the people doing the work to show their actual tools. An unofficial spreadsheet or a message thread may carry an important decision that the formal process omits. Treat those workarounds as evidence about requirements, rather than immediately dismissing them as bad practice.
Mark decisions and exceptions separately
A transfer between systems is different from a judgment call. Copying a reference number may be mechanical; deciding whether a request is complete may depend on context. Show both on the map, and identify who is accountable for the decision.
Then examine an item that did not follow the normal route. What happens when information arrives late, an approval is reversed, or a customer changes their mind? An automation designed only around the easiest case can push the difficult work into a less visible queue.
Choose a small boundary
Look for a section with clear inputs, a meaningful output, and an owner who can judge whether it works. Automating one transfer with good error reporting may be more useful than connecting every step at once.
Before implementation, agree how someone can pause the automation, correct a mistake, and discover what it changed. Walk through the proposed process with the people who will operate it. If they cannot explain where a failed item goes, the workflow still needs design work.
Keep the map after launch. It becomes a useful reference when a new requirement changes assumptions that were previously obvious.
A practical example.
Consider a supplier invoice that arrives by email, gets copied into a spreadsheet, and then waits for approval. Drawing only those three steps misses the useful questions: who recognizes a duplicate, where the supplier reference is checked, and what happens when the approver is away?
A workable map follows both a clean invoice and an invoice disputed by the receiving team. Mark where the authoritative record lives at each step and distinguish processing time from waiting time. The first automation might simply register incoming invoices and flag missing references. Approval can stay with a person until the exception rules are understood. The map should show that deliberate boundary clearly.
Put it into practice.
- Trace an actual completed item before describing the ideal process.
- Mark every handoff, decision owner, and place where work can wait indefinitely.
- Give failed or disputed items a visible destination and a way back into the process.