Mapping a business process is not complicated, but it is easy to do in a way that produces a diagram nobody trusts. The failure is almost always the same: the map records what someone believes happens rather than what happens. Here is the sequence we use, and the specific places it tends to go wrong.
Decide what one process is
Start by drawing the boundaries, because most arguments about a process map are really arguments about scope. A process has a trigger and an end state. “Onboarding a new client” starts when the contract is signed and ends when the client is live and being invoiced. If you cannot say what starts it and what finishes it, you have a function rather than a process, and you should break it into smaller pieces before you map anything.
Resist the urge to map everything at once. Pick the process that is currently costing you something you can name.
Interview the people who do the work, individually
This is the whole method, and everything else is bookkeeping. Sit with the person who performs each part and have them walk you through it as they actually do it. Ninety minutes is usually enough per person.
Three things matter here. Interview individually rather than in a group, because in a group the most senior person’s version becomes the official one. Have the supervisor present but listening, not answering. And ask about the last time they did the task, not how the task is done in general - the general answer is the policy, the specific answer is the practice.
The question that earns its keep is: what do you do when that does not work? The exception path is where the workarounds live, and the workarounds are the process.
Capture six things at every step
The action
Stated as a verb and an object. “Check the credit limit”, not “credit”.
Who performs it
A role, not a person’s name. Names change and they make the map awkward to share.
The system it happens in
Including the spreadsheet on somebody’s desktop, which is usually the one that matters most.
The document produced or consumed
Forms, approvals, emails that function as approvals.
The decision, if there is one
With the actual criteria. If the criterion is “whatever Sandra thinks”, write that down - you have just found an undocumented rule and a key-person risk in the same step.
Where it goes next
And crucially, whether the next person is waiting for it or has to go looking.
Draw it in swimlanes
A swimlane diagram divides the page into horizontal lanes, one per role, team or system, and places each step in the lane of whoever performs it. Every time the flow crosses a lane boundary, that is a handoff.
This is worth the effort for one reason: handoffs are where delay and error concentrate, and a swimlane map makes them impossible to miss. A process that looks reasonable as a numbered list often turns out to cross between four teams eleven times, and the picture makes that argument for you in a way a list never will.
Keep it to one page per process. A map that needs scrolling is a map nobody will stand in front of.
Take it back to the people who described it
An unvalidated map is a set of assumptions drawn neatly. Put it in front of the same people and let them correct it. They will, and the corrections are frequently more valuable than the original account, because seeing the whole thing laid out prompts the “oh, and sometimes we also…” that never surfaces in the first interview.
Then put it in front of the whole group at once. Disagreement in that room is the point rather than a problem: every disagreement marks a place where the process is genuinely ambiguous, and ambiguity is what you are looking for.
Where it usually goes wrong
Mapping the target state first. If you design the improved process before documenting the current one, you will design around problems you do not know about. Current state first, always.
Only talking to managers. The most common and most expensive mistake. It produces a map of the intended process, which is the version most likely to have drifted.
Too much detail. Mapping down to individual keystrokes produces something unreadable that goes stale in a month. Map to the level at which a step could be delegated to someone competent.
Stopping at the map. The map is a diagnostic instrument, not a deliverable. Its value is the gaps it exposes and what you do about them.
What you should have at the end
A one-page swimlane map per process, validated by the people who perform the work. A written list of the gaps, ranked by what they cost rather than by who raised them. And a short account of which steps have no clear owner, which is usually the most immediately actionable thing on the list.
From there, the sequence runs: establish what each role needs to be able to do, write the procedures against that, then build the training from the procedures. Not the other way around.
Which process would you map first?
If you would rather not run this yourself, it is most of what we do.