Map what starts the work, who acts, what changes, and how it ends. Include waiting and exceptions, because those often explain why the business needs a new system.
Prepared with AI assistance. These are practical scoping recommendations; examples are illustrative, not client results.
Observe a real case
Ask a team member to walk through recently completed work using the actual tools and records. Note where information is copied, decisions are made, and responsibility changes. Avoid starting with an ideal process diagram that omits the workarounds staff currently rely on.
Mark decision points
At each branch, write the question, available evidence, and person authorized to decide. Distinguish a rule the software can apply from judgment a person needs to exercise. If two employees describe different rules, record the disagreement for the business owner rather than choosing one during implementation.
Show waiting explicitly
Identify what the process waits for and who can move it forward. A task may spend little time being handled but several days awaiting information. That distinction changes the solution: faster data entry will not necessarily resolve a missing handoff or an unclear approval responsibility.
Turn the map into scope
Select a complete segment for the first release and define its incoming and outgoing boundaries. Use normal and unusual examples to validate it with users. The map should support concrete implementation decisions, not become a large diagram that nobody consults when the team needs to settle how the workflow behaves.