Business Process Mapping Before You Automate Anything
Key takeaway
Map the process as it's actually performed, not as the procedure document describes it, then eliminate and simplify before automating. Automating an unexamined process locks in every workaround and approval that accumulated over a decade, and makes them harder to remove.
Every automation project begins with a description of the process. That description is almost always wrong in interesting ways — which is why the first step is watching the work rather than reading about it.
Walk the process with the people doing it
- Follow a real case end to end, sitting with each person who touches it.
- Record the actual steps, including the spreadsheet, the email folder, and the sticky note on the monitor.
- Note every handoff and every wait. Delay between steps is usually a larger share of elapsed time than the work itself.
- Ask what goes wrong and how often. Exceptions are where the cost and the complexity live, and they never appear in the written procedure.
- Capture volumes: cases per week, time per step, error rate. Without numbers you cannot prioritise or prove improvement.
Question before automating
- Eliminate — does this step serve any current purpose, or is it a control for a risk that no longer exists?
- Simplify — can approval thresholds be raised, or an approval removed where it's never refused?
- Combine — are two people touching the same case because of an old organisational boundary?
- Reorder — can checks happen earlier, so failures are caught before effort is spent?
- Only then automate what remains. Automation applied to a process nobody questioned makes bad decisions faster and cements them.
Map exceptions explicitly
The main path is usually simple and usually accounts for well under all the cases. It's the exceptions — the incomplete application, the customer who paid twice, the item that arrived damaged — that determine whether automation delivers. Document each one with its frequency and decide deliberately: automate it, route it to a human queue, or make it impossible upstream.
Set the baseline before you change anything
- Measure elapsed time from start to finish, touch time, error and rework rate, and cost per case.
- Agree what success looks like numerically, and who owns the measurement.
- Re-measure after the change using the same definitions — improvement claimed against a redefined metric convinces nobody.
- Keep the map current. A process map that ages becomes another document contradicting reality.