To map a business process, name its start and end, interview the people who do the work, list every step in order with who does it and which system is used, mark decisions, delays and exceptions, time each step, and then check the map by walking it with the team. A good map reveals waste to remove before you automate anything.
- Map the process as it actually runs, not as the manual says it should.
- Capture owners, systems, decisions, delays and exceptions for each step.
- Time the steps so you know where hours and waiting really go.
- Validate the map with the people doing the work before using it.
Why map a process before automating it?
Automation copies a process faithfully, including its flaws. If a task has needless approvals, repeated checks or workarounds, a bot will perform all of them quickly. A map makes those visible so you can remove them first, which usually improves the result more than the automation does.
Mapping also exposes hidden knowledge. Experienced staff handle exceptions from memory, and none of it is written down. If that knowledge never reaches the automation, the first unusual case will break it, and the team will lose confidence in the whole effort.
What should a process map contain?
At minimum, each step needs an action, a person or role, the system or document used, the time it takes and what happens next. Decision points, such as approve or reject, and the paths they lead to, belong on the map as well, along with wait times between steps, which are often longer than the work itself.
Keep the format simple. A table, a whiteboard sketch or a basic flowchart is enough; the clarity of the content matters more than the tool. Anyone unfamiliar with the process should be able to follow it without explanation.
- Trigger: what starts the process
- Steps in order, with the owner of each
- Systems, files and documents used at each step
- Decisions and the paths that follow them
- Time spent working and time spent waiting
- Exceptions and how they are handled today
How do you gather the facts accurately?
Talk to the people who do the work, not only their managers, and ask them to walk through a recent real case rather than describe the ideal. Sit beside them if possible and watch. Questions such as what do you do when the invoice has no PO number tend to uncover the real rules.
Collect a few real examples, including awkward ones. Compare how different people handle the same situation; differences show where the process is unclear and where standardising would help. Note volumes over a typical month so that automation effort can be weighed against benefit.
How do you find waste and bottlenecks?
Review the map step by step with three questions: is this step necessary, could it be combined with another, and could it be done by someone or something else? Look for rework loops, repeated data entry, approvals that never get rejected and long waits for a single person.
For example, if an order spends ten minutes being keyed and two days waiting for a manager's signature, automating the keying barely changes the outcome. Waiting time, not working time, is often the real problem. This is a made-up illustration of the principle.
How do you validate and use the map?
Walk the finished map with the people who do the work and with the process owner. Ask them to correct anything that looks wrong or missing. A map that the team recognises as true is ready; one they dispute needs another round.
Then decide what to change. Remove unnecessary steps, clarify rules, and mark the steps that suit automation: repetitive, rule-based and digital. This annotated map becomes the specification for your automation project and the baseline for measuring improvement afterwards.
- Walk the map with the team and correct it
- Remove steps that exist only through habit
- Mark steps that are repetitive, rule-based and digital
- Keep the final map as the baseline for measuring results
When should you get outside help?
Mapping a single small process is easy to do yourself. When many teams are involved, or politics make honest answers difficult, an outside facilitator can speed things up and keep the discussion neutral.
A Plus Solution includes structured process mapping in its automation audit, producing documented maps and a ranked list of what to automate.
Step by step
- Define the boundaries. Name what starts the process, what ends it and what is out of scope.
- Interview and observe. Ask the people doing the work to walk through recent real cases.
- Record each step. Note the action, owner, system, time taken and next step.
- Add decisions and exceptions. Mark where paths split and how unusual cases are handled.
- Validate with the team. Review the map together and correct anything missing or wrong.
Frequently asked questions
Which tool should I use to draw a process map?
Any simple tool works: a spreadsheet, a whiteboard or a flowchart app. Clarity matters more than the software.
How detailed should the map be?
Detailed enough that a newcomer could follow it, and no more. Avoid mapping every click unless you are building a bot for that task.
How long does mapping take?
A single process can be mapped in a few hours to a few days, depending on its complexity and how many people are involved.
What if people handle the same task differently?
Record the variations, discuss why they exist and agree on a standard before automating.
Do I need to map every process?
No. Map the candidates you are seriously considering for automation.
Need help with this? See our Automation & AI Audit service or talk to Yash Parikh.