One hour of process mapping before I start building has prevented at least three projects that would have taken six months and delivered nothing useful. The clients who skip it give me a problem statement that sounds specific ("automate our invoice approval process") but turns out, on inspection, to describe five separate processes, two of which should not exist, and one of which cannot be automated because it depends on a judgment call that only one person in the company can make.
Here is the exact method I run in that first hour and what it produces.
Why Process Mapping Before Automation
Automation codifies behavior. If you automate a broken process, you produce a reliable broken process. If you automate the wrong process (the symptom rather than the cause), you spend three months on infrastructure that does not move the business metric that matters.
The process map forces three things the project brief cannot surface:
- Visibility into the actual steps, not the steps people think happen
- Identification of who does what and where handoffs create delays
- The question: "Should this step exist at all?"
The third question is the one that kills the most automation projects before they start, in the best possible way. I have done discovery sessions where the right answer was "you do not need to automate this step; you need to eliminate it."
The One-Hour Method
Minutes 0 to 15: The as-is walkthrough
I ask one question: "Walk me through exactly what happens when [triggering event] occurs, step by step, until [desired outcome] is achieved."
I do not interrupt except to ask "what happens next?" I write every step in a numbered list. I do not filter, edit, or question anything during this phase. I also note who does each step (role, not name), what tool they use, and roughly how long it takes.
Minutes 15 to 30: The swim lane diagram
I convert the numbered list into a simple swim lane diagram. Each row is a role (Accounts Payable, Operations Manager, Vendor). Each box is a step. Arrows show handoffs. This takes fifteen minutes and immediately makes visible three things that the numbered list hides: parallel steps that are currently sequential, handoffs that cross role boundaries (each is a potential delay), and steps where the same information is re-entered by a different person (a reliable indicator of a broken process).
Vendor [Submit invoice] ---------> [Send reminder if no reply in 7 days]
|
Accts Pay [Receive invoice] -> [Enter in ERP] -> [Route for approval]
|
v
Ops Mgr [Receive request] -> [Review] -> [Approve or Reject]
|
v
Accts Pay [Receive decision] -> [Process payment] -> [Notify vendor]
Minutes 30 to 45: The bottleneck interview
I ask the person in the room: "Where does this process usually slow down or break?" I have never had a client who did not immediately know the answer. Then I ask: "How often does that happen and what does it cost when it does?"
These two questions surface the real problem. Often it is not the step that takes the most time; it is the step that blocks everything downstream when it fails. In the invoice example above, the bottleneck is almost never data entry. It is the approval step: the operations manager is hard to reach, approval sits in their inbox for three days, and AP cannot process payments until it clears.
Minutes 45 to 60: The three questions
For each step, I ask three questions:
- Does this step need to exist? Can we redesign the process to eliminate it entirely?
- Is this step a good automation candidate? (Apply the frequency-error-cost filter from my audit article.)
- What would break if we automated this step without changing anything else?
The third question is the most revealing. Automating the invoice data entry step without fixing the approval bottleneck produces a system that captures invoices instantly and then queues them for three days. The automation creates an illusion of efficiency while the real problem remains untouched.
What the Map Produces
By the end of the hour, I have:
process_map_output:
process_name: invoice_approval
trigger: vendor_submits_invoice
outcome: payment_processed
steps:
- id: 1
name: invoice_receipt
actor: accounts_payable
tool: email
avg_duration: 5min
failure_mode: missed_in_inbox
automation_candidate: true
- id: 2
name: system_data_entry
actor: accounts_payable
tool: erp_system
avg_duration: 15min
failure_mode: duplicate_entry_errors
automation_candidate: true
- id: 3
name: approval_routing
actor: accounts_payable
tool: email
avg_duration: 2min
failure_mode: sent_to_wrong_approver
automation_candidate: true
- id: 4
name: approval_decision
actor: operations_manager
tool: email
avg_duration: "10min to 3 days"
failure_mode: no_response_no_escalation
automation_candidate: partial_sla_enforcement_only
- id: 5
name: payment_processing
actor: accounts_payable
tool: banking_portal
avg_duration: 10min
failure_mode: manual_error
automation_candidate: true
bottleneck: step_4_approval_decision
recommendation: add_sla_enforcement_and_escalation_before_automating_other_steps
The Step Elimination Conversation
At least once in every ten process maps, a step falls away entirely under scrutiny. This is the conversation: "Why does this step exist?"
A Singapore accounting firm had a step where a junior accountant printed every client invoice, signed it, and filed it in a physical folder before the digital approval workflow ran. When I asked why, the answer was: "We have always done it that way." The step had been carried forward from a paper-based process that predated the digital system by eight years. It cost roughly three hours per week and contributed zero value.
Eliminating that step before any automation discussion saved the client three hours per week immediately, at zero cost. The automation we did build (digital approval routing) ran on a cleaner process with one fewer unnecessary dependency and produced fewer exceptions.
Finding the Bottleneck vs. Finding the Loudest Complaint
The bottleneck and the loudest complaint are almost never the same step. The data entry step in an invoice process generates complaints because everyone sees it and it is tedious. The approval step causes the actual business damage because delayed payments strain vendor relationships and sometimes incur late fees.
I map both. The complaints point to quick wins that build stakeholder trust. The bottleneck points to the real automation priority. Address both, in order: quick win first (builds belief), bottleneck second (produces the business outcome the project was funded for).
When NOT to Map and Build Directly
Some processes do not need a full map. If the task is entirely self-contained (no handoffs, no approvals, single actor, single tool), a thirty-second description is enough. Automating a scheduled report that one person runs manually every Monday does not require a swim lane diagram.
The map is for processes with multiple actors, multiple steps, or a history of failure and rework. Apply judgment.
What I Got Wrong
I once ran this exercise with five people in the room who all described the process differently. I assumed the most senior person's version was correct and built from it. Three months in, I discovered the process the senior person described was the official process: the one in the documentation. The actual process the team ran was a workaround that had evolved over two years because the official process was too slow.
Now I always end the mapping session with: "Is this how the process actually runs day-to-day, or how it is supposed to run?" They are different more often than you would expect.
The Output: A Process Contract
The deliverable is a one-page document: the swim lane diagram, the bottleneck identification, the automation candidates ranked by priority, and the steps that should be eliminated or redesigned before any automation is built.
This document becomes the contract for the project. Every subsequent decision traces back to it: which tool to use, which step to automate first, what the success metric is, and what success looks like in month six.
The one hour is not overhead. It is the project's foundation, and it costs less than a morning stand-up.