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.
Mapping a business process means agreeing where it starts and stops, finding out what actually happens between those points, and recording it as a diagram the people who do the work will confirm.
The short version
- State the scope as two events (a trigger and an end state), not as a subject area.
- Interview the people who do the work, and ask specifically about the exceptions.
- Map the as-is first. A to-be map drawn before anyone agrees on today is a proposal.
- Include external parties in their own lane: waiting on a supplier is part of your cycle time.
- Validate by walking the map with each lane owner, then keep one approved version.
What goes wrong before you draw anything
Process mapping goes wrong before anyone draws anything. It goes wrong when the scope is stated as a noun ("map purchasing") instead of as two events, so every interview surfaces a different process and the map grows until it describes the company. Fix the boundaries first: this process starts when a requisition is raised and ends when the supplier is paid. Everything outside those two events is somebody else's map.
The second failure is sourcing. A map drawn from the written policy documents what should happen; a map drawn from the system documents what the system permits. Neither is the process. You get the process from the people who run it, and specifically from asking what they do when the normal route does not work: the workaround is not noise, it is the process, and it is usually where the risk sits.
The example below is a procure-to-pay flow across five lanes, including the supplier. Step through it and watch what a complete map contains beyond the happy path: the gates that stop money being committed, the point where the work leaves the building, and the exception queue that forms when the purchase order, the goods receipt and the invoice disagree.
A business process mapped end to end
Procure-to-pay across five lanes, built up in five stages: boundaries first, then the controls, then the exceptions.
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.
Mistakes to avoid
Scope stated as a subject
"Map procurement" has no boundaries, so every interview adds a step at either end. Two events, written down, agreed. Everything else is negotiable; this is not.
Mapping from the policy document
The policy is what someone intended. The map is meant to record what happens. Where the two differ, that gap is the most useful output of the whole exercise, so do not resolve it silently by drawing the policy.
Leaving external parties out
If the process waits on a supplier or a customer, they belong in a lane. Otherwise the map implies the delay is internal and improvement effort goes to the wrong place.
One map, forever
Processes change. A map with no owner and no review date is a snapshot of a company that no longer exists. Give it an owner, a review cadence, and version control, so the current version is identifiable.
Map your own business process
Start from the procure-to-pay example, or open a blank chart and type your steps into the rows.
Related guides
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.
