You do not need a complicated diagram to understand a workflow. You need a shared view of how one piece of work reaches a useful result. Keep the first map simple enough that the people doing the work can challenge it.
Choose a start and finish
Be specific. 'Sales' is too large. 'A complete enquiry arrives' to 'an approved quote is sent' is workable. Identify the person receiving the final output and what makes that output acceptable. This prevents the map becoming a list of software features.
Follow a recent item
Ask someone to show what actually happened to a recent enquiry, order or document. Use the artefacts involved, with private details handled appropriately. Write one step per box. Use verbs: check details, prepare quote, approve price, send response.
For each step, record its owner, source information and output. Mark changes of owner. Include queues and waiting, not only activity. If two people disagree about a step, record the uncertainty and investigate rather than deciding that the tidier version must be correct.
Add the exceptions
Now follow an item that went wrong or needed unusual handling. What happens when an enquiry is incomplete? When an approver is away? When an order changes after approval? A useful map includes an escape route for those cases.
Separate a rule from a habit. 'We always email Alex' may mean Alex makes a required commercial decision, or it may be how a missing responsibility has been patched. Ask which it is before changing the step.
Add enough measurement to choose a change
For a sample of items, record active work time, elapsed time, rework and the number of incomplete inputs. A hypothetical quote might require 20 minutes of preparation but wait two working days for approval. Faster document generation would tackle only a small part of the elapsed time.
Process-mining software can visualise event data and variations at a larger scale. The Microsoft documentation explains how maps can expose bottlenecks. A manual map remains a useful starting point when you need to establish the boundaries and meaning of the process.
Agree the next version
Review the map with everyone responsible for a handoff. Choose one change, identify its owner and define a measure. Keep the original map so you can explain what changed. Update it after the pilot to reflect reality.
The map is useful when it leads to a decision. Use it to choose whether automation is appropriate, improve a handoff or identify an unnecessary step. It does not have to become a permanent diagramming project.
