How to map a business process
How to map a business process end to end: agree the boundaries, interview the people who run it, map the as-is including exceptions, then validate it. With a live procure-to-pay example.
A worked example, stage by stage
Fix the boundaries
The map starts at "Identify purchase need" and will end at payment. Two events, written down before anything else — because the argument about whether supplier selection belongs in this process is much cheaper to have now.
Find the control gates
Manager approval, budget availability, then a value threshold routing to a finance director. Control gates are the steps a business process map is most often built to expose, and the threshold decision is the one that reveals whether the delegation of authority matches practice.
Show where work leaves the building
Sourcing moves into procurement and then to the supplier's own lane. The delivery step forks into two arms that run independently — goods coming in, invoice coming in — which is a real feature of this process and impossible to see in a linear checklist.
Map the exception, not just the happy path
The three-way match is where invoices go to die. The mismatch branch goes back to procurement, gets corrected, and re-enters the match: an honest map shows the loop, because that loop is where cycle time is actually being spent.
End on the event you promised
"Payment released to supplier" — the end state named in stage one. A map that stops somewhere other than its stated boundary is a map whose scope moved while it was being drawn.
How it works
Write the scope as two events
"Starts when a purchase requisition is raised; ends when the supplier is paid." One sentence, agreed with whoever asked for the map, before any interviews. If people disagree about the boundaries, that disagreement is the first finding and it is cheaper to resolve now than after three drafts.
Identify the lanes and the people in them
List the roles the work passes through, including external parties, and find one person per lane who actually performs the steps rather than one who supervises them. Four or five lanes; if you need eight, the scope is too wide and should be split at a handoff.
Interview for the exceptions, not the routine
Everyone can describe the happy path and it is rarely where the problem is. Ask instead: what do you do when the budget code is missing, when the approver is on leave, when the invoice arrives before the goods? Those answers are the branches, and they are almost never written down anywhere else.
Build the as-is in rows, lanes last
Type the steps into QueryChart as rows, connect them with the Line to column, then assign each row an owner lane and a phase. Getting the sequence right before worrying about layout keeps the discussion on the process; the diagram assembles itself from the rows.
Measure the handoffs
For each crossing between lanes, note how the next lane learns it has work and how long it typically waits. Put it in the step's comment. Cycle time in most business processes is queue time, not work time, and the queues are exactly at these boundaries.
Validate, approve, and keep one version
Walk the finished map with each lane owner and change what they disagree with. Then get it approved in QueryChart so there is one current version with a signature and a date on it, rather than a PDF that starts diverging from reality the day after the workshop.
Frequently asked questions
What is the difference between process mapping and process modelling?
Process mapping produces a picture people use: who does what, in what order, with which decisions and handoffs. Process modelling produces a formal, notation-bound representation — usually BPMN — that a tool can validate or execute, and it carries rules about event types, gateways and message flows. Most organisations need the map. Reach for the model when something downstream is going to consume it, such as a workflow engine or an automation project.
Should I map the current process or the improved one?
The current one, first and always. An as-is map is a factual record you can validate with the people who do the work, which makes it an agreement rather than an opinion. Once it exists, a to-be map is a short, cheap conversation about specific changes. Skipping the as-is means the improvement is being designed against an assumed process, and the assumption is usually the happy path.
How long should mapping a business process take?
For a single operational process with four or five lanes: a couple of hours of interviews, an afternoon to draft, and a validation session. Two to three days of elapsed effort. Anything that takes weeks is usually a scoping problem rather than a complexity problem — the boundaries were not fixed, so the map kept growing sideways into adjacent processes.
Who should own a business process map?
One named person who can change it, normally the owner of the process rather than whoever facilitated the mapping. Lane owners review it; the process owner keeps it. Without a single owner, maps decay in a predictable way: they stay technically available and quietly stop matching reality, which is worse than not having one because people still trust it.