Process mapping: which method for what — and where every diagram stops

A process map is quick to draw and almost as quick to become useless. Not because it is wrong — the boxes are usually right. Because it does not answer the question it was drawn for. You map in order to know where to intervene. What you get is a structure in which every step looks equally important.

So this article stands on two legs. First the craft: which method is worth its effort, which symbols you actually need, how to find the right granularity and in what order to work. Second the limit: the four inputs that appear in no notation, and without which no diagram tells you which step is holding the work up.

What is process mapping?

Process mapping is the graphical representation of a single business process using standard symbols. It answers four questions: What triggers the workflow? Which tasks follow in which order? Where does it branch, and who decides? How does it end?

The terms get used interchangeably, but they mean different things:

The landscape is the city plan, the map is the directions for one street. Force both into one picture and you get a landscape with two hundred boxes that nobody opens after the presentation.

What a map is good for:

• Onboarding: new colleagues see the workflow instead of being told about it
• Audits and certification: ISO 9001 asks for this structure anyway
• System changes: what has to be described before software can support it
• Handovers: the points where a case changes ownership
• Exceptions: the cases everyone handles differently because they are written down nowhere

What it is not good for:

• Prioritisation. Every box is the same size.
• Effort estimation. A step may mean ten minutes or four days.
• Capacity planning. How often the process runs is not in the diagram.

As-is and to-be: draw what is, first

Process mapping distinguishes two model types. The as-is map shows the current state: how the workflow actually runs today, including the detours, the rework and the spreadsheet that officially does not exist. The to-be map shows the target state after the change.

The order is not negotiable: as-is first, then to-be. Start with the target and you are optimising a workflow you do not know.

Between them, though, belongs a third step most guides leave out: measure. A to-be map drawn straight from the as-is is a wish list. It improves the step that was talked about loudest in the workshop — and that is rarely the one holding the work up. The loud step is the unpleasant one; the expensive step is the quiet one where cases sit and wait.

Practical rule: draw a to-be map for exactly one step, the one the measurement names. Everything else stays as it is for now.

Process mapping methods at a glance

Flowchart

The simplest form: start, tasks, diamonds for decisions, end. Everyone reads it without training, and that is precisely its value. Its limit shows as soon as several roles are involved: responsibility survives only as text inside the boxes, and the handovers where the time is actually lost disappear.

Swimlane diagram

The same workflow, but each role gets a lane. The gain is not beauty, it is a hard piece of information: every arrow that leaves a lane is a handover. Handovers are where cases sit, because nobody owns them any more and nobody has started yet. For workflows crossing departments, the swimlane is the right default.

BPMN 2.0

The international standard from the Object Management Group: around 150 symbols, machine-readable. Its strength is precision — a BPMN model can be exported, validated and executed by a process engine. Its weakness is the learning curve; on the business side, few people read it voluntarily.

Choose BPMN when the model will be executed, externally reviewed, or maintained for years. Do not choose it for prestige. A clean swimlane diagram the department actually reviews is worth more than a correct BPMN model nobody opens.

EPC and extended EPC

The event-driven process chain alternates strictly between event ("request has arrived") and function ("record the request"), joined by connectors for AND, OR and XOR. In German-speaking countries it is widespread through ARIS. The extended EPC adds the organisational unit and the information object to each function — who performs the step, and with what.

The forced alternation is both strength and weakness: it makes you spell out triggers, and it roughly doubles the length of the model. Sensible where an EPC estate already exists. For a new map on a blank page there is rarely a reason to pick it.

SIPOC

Five columns: suppliers, inputs, process, outputs, customers. This is not a flow diagram but the scoping exercise before one. Filled in within an hour, it settles the question most mapping efforts founder on: where does the process start, and where does it end? The process column stays deliberately coarse — five to seven blocks.

Value stream mapping

From lean manufacturing. It draws material and information flow and attaches numbers to every step: processing time, waiting time, inventory, defect rate. That makes it the one classic method that is quantitative by design. Its home is the shop floor; in office processes the "inventory" is the queue in someone's inbox, which makes it harder but not impossible.

Value chain and detailed map

Two ends of the same scale. The value chain shows five to nine blocks with no internals — the version for management and outsiders. The detailed map shows every step including subprocesses, exceptions and systems — the version for handover to IT. Both are legitimate. What is useless is both levels of detail in one diagram: three boxes for half of sales, then fourteen for the approval procedure.

Which method to pick? Three questions

1. Are several roles or departments involved? Yes → swimlane. No → flowchart.
2. Will the model be executed, exported or reviewed externally? Yes → BPMN 2.0.
3. Is this about material, inventory or waiting stock? Yes → value stream mapping.

If the scope itself is still unclear, SIPOC goes first. The rest is taste — and taste is a poor guide for notations, because the map will be read by people who do not share it.

Process mapping symbols

The common symbols come from the flowchart tradition and are the same in every tool:

• Oval (terminator): start and end of the process
• Rectangle: a task or activity
• Diamond: a decision, with labelled exits
• Arrow: the direction of flow
• Rectangle with double side lines: a subprocess mapped elsewhere
• Parallelogram: data as input or output
• Rectangle with a wavy bottom edge: a document
• D-shape: a delay, meaning idle time
• Rectangle with a slanted top: manual input — in practice the most reliable marker of a media break

In BPMN the five that matter are: start event (thin circle), task (rounded rectangle), exclusive gateway (diamond with an X), sequence flow (solid arrow), end event (thick circle). That set covers most workflows.

Two rules matter more than any symbol list. Every diamond has labelled exits — "yes"/"no" or the condition. And every path ends. A branch that runs into nothing is a cosmetic flaw in the diagram and, in reality, the case that never gets closed.

Mapping a process: six steps

Step 1: Set the boundaries

Two sentences, written down, before anything is drawn: what starts the process (the trigger) and when it is finished (the result). Without them the map grows while you work on it — every conversation adds something at the front and at the back. This is the most common reason a two-day mapping exercise takes three weeks.

Step 2: Collect the steps — from the people who run them

Not from the managers. They know the official procedure, and the gap between that and reality is exactly what you are looking for. Five questions that reliably surface what no work instruction contains:

• What triggers this case for you, and how do you notice?
• What do you need before you can start, and where does it come from?
• What do you wait for most often?
• What do you do when something is missing or the system will not cooperate?
• What do you do differently from the written procedure — and why?

Step 3: Fix the granularity

The rule that settles the level of detail: a step is a piece of work one role completes in one system in one sitting. When the role changes, the system changes, or the work is interrupted, a new step begins.

Applied to a normal business process this yields eight to fifteen steps. If you end up with fifty, you are mapping keystrokes. If you end up with four, you are mapping departments.

Step 4: Draw

Pick the method from the three questions above, then do a first pass without exceptions: the normal case, left to right. Branches come afterwards — and not all of them. A process typically consists of just under a third exceptions; map the two or three most frequent ones. The rest goes beside the diagram as text.

Step 5: Have it reviewed

The finished diagram goes back to the same people from step 2 with a single question: "Where is this wrong?" Not "Does this look right?" — everyone answers yes to that. In practice the group corrects two to four points, and at least one of them is not a detail.

Step 6: Attach the numbers

The step missing from most guides, and the one without which the map stays decorative. Four figures per step, estimated if need be:

• Duration as a range: optimistic, typical, pessimistic — not an average
• Waiting time before it: how long the case sits before anyone starts
• Frequency: how often the step runs per month, and the share of exceptions
• Role and system, plus: media break, yes or no

Why the range instead of the average: plugging averages into a process chain is systematically too optimistic as soon as the workflow contains gates, loops or shared caseworkers. The arithmetic is in Your spreadsheet does the math right and is still wrong.

Example: a quotation process, mapped

The map below comes from our sample analysis AN-2026-01. It is constructed, not measured at a client — the structure is modelled on typical mid-sized workflows, the numbers come from a simulation over 500 runs. For the point being made here that is enough: the gap between picture and measurement is a property of the method, not a trade secret.

As a swimlane, six steps, four roles:

                 ┌────────────┐                              ┌──────────────┐
Inside sales  ●──│ 01 Record  │                              │ 05 Write     │──▶ ● 
                 │  request   │                              │   quotation  │
                 └─────┬──────┘                              └──────▲───────┘
                       │                                            │
                 ┌─────▼──────┐                                     │
Engineering      │ 02 Technic-│                                     │
                 │ al review  │                                     │
                 └─────┬──────┘                                     │
                       │                                            │
                 ┌─────▼──────┐   ┌───────────┐    no      ┌────────┴────┐
Costing          │ 03 Costing │──▶│ 04 Appro- │───────────▶│ Query back  │
                 │            │   │   ved?    │            │ (exception) │
                 └────────────┘   └─────┬─────┘            └─────────────┘
                                        │ yes
                                        ▼
Sales                             06 Send & follow up ──▶ ●

The diagram is correct. It answers who does what in which order, and it shows three media breaks (email, spreadsheet, word processor). What it does not answer: which of these six steps is holding the work up?

On paper all six look the same. Computed, they do not:

One role sits above 100 percent — more work arrives than it can clear, and a queue grows in front of its step. The map shows that role as one lane out of four, on equal footing with sales management at 41 percent.

Lead time behaves accordingly. It is not a number but a range:

Between the typical case and the one you could commit to lies a factor of two. None of that is visible in the diagram — and it would not be visible in any diagram, whatever the notation. The full sample analysis with before and after is at The quotation process that stalls in engineering.

The four inputs that appear in no notation

There is a sober reason why no map shows the bottleneck: notations describe structure, not load. Computing the workflow needs four quantities that neither BPMN nor EPC nor a swimlane provides:

1. Arrival rate — how often the process is triggered, and how unevenly. Forty cases a week is not the same as forty of which thirty arrive on Monday.
2. Spread of durations — not "two hours" but "one to four hours, usually two". Without spread there are no queues, and the arithmetic comes out too optimistic.
3. Capacity — how many people can actually take the step, and for what share of their working time. One lane in a diagram may be one person or eight.
4. Calendar — working hours, holidays, approvals that only happen on Tuesdays. A workflow that takes three hours of work still takes a day across a night.

The best time to collect these four is while mapping, in step 6 above. They are the transition from drawing to computing — and the point at which it is decided whether the map turns into an intervention or into wall art.

Common mistakes

1. Too fine. Two hundred boxes for one process. Fix: the rule from step 3 — one role, one system, one sitting.

2. Drawing the target, not the current state. The tell is that no rework appears in the map. Real workflows always have some.

3. Talking only to managers. Reliably produces the official procedure. The gap to the actual one is the whole return on the exercise.

4. Choosing the notation for prestige. BPMN because it looks professional, and then nobody reviews it — and a map nobody has reviewed is an assertion.

5. Ignoring exceptions. The normal case is drawn, thirty percent of cases run differently. Two or three exceptions belong in the picture, the rest beside it in text.

6. No numbers. The map is finished and "what do we do first?" remains a matter of opinion.

7. No owner, no trigger to update. A map with no named owner and no fixed update trigger — system change, reorganisation, annual review — is wrong within twelve months, and nobody notices.

What to map with

For the first pass: paper, whiteboard, sticky notes. Notes can be moved; a neatly typeset diagram invites nobody to contradict it. For the fair copy the usual diagramming tools are enough — for a single process the tool is the smallest of your questions. Where maps are maintained for years or executed by an engine, BPM suites with a repository, versioning and approval come into play; that is a procurement decision with its own overhead and rarely pays below a two-digit number of maintained processes.

When you type in the meeting instead of drawing

One special case is worth naming, because it covers the most common reason mapping stalls: nobody drags boxes in a workshop. Draw along and you fall behind; take notes and you transcribe them afterwards — or you don't. Our desktop application FlowVisual has a capture line for this: one line per step, Enter for the next, and the chain wires itself.

Request arrives
Price the quote @sales 20-40min
Approval @boss 5min ?above 10k
Rework @sales !missing details

Four markers, and that is the whole grammar: @ the role, a range the duration, ? the condition, ! the pain point. All of it optional — a bare line is a valid line, and what nobody said stays open instead of landing in the model as an invented zero. If you would rather not start from nothing, open one of the six templates (quotation, invoice approval, complaint, onboarding, service desk, order handling) or have existing work instructions read in; every step proposed that way carries a verbatim quote and the file it came from, and is accepted one at a time.

The point is not the drawing but what becomes possible afterwards: because role, duration and frequency are already in the line, the finished picture arrives with the four inputs from the next section attached — and can be computed rather than merely looked at. What that looks like in one pass is in the guide, section "When there is no process yet".

More important than the choice: the map has to live where people already work. A diagram in a tool the department has no licence for will not be maintained — it gets printed and grows stale on a wall.

In closing

Process mapping is a craft with clear rules: boundaries first, talk to the people doing the work, a notation matched to the purpose, one step per role and system, exceptions in moderation, and a review round. Follow those and you have a map that holds up within a day or two.

What the map will not give you, it will not give you with a better notation either: the order in which to intervene. That takes numbers on the boxes and arithmetic over them — arrival rate, spread, capacity, calendar. The diagram is the precondition for that. It is not the answer.

Next steps:

1. Write down the trigger and the result in two sentences
2. Hold two or three conversations with the people doing the work, using the five questions above
3. Draw it as a swimlane, eight to fifteen steps
4. Have it reviewed with the question "Where is this wrong?"
5. Add duration as a range, waiting time, frequency and media breaks per step
6. Only then decide where to intervene

Further reading:

• Lay bare: putting a number on the current state — step two of the FLOWREFY method, which is exactly those numbers on the boxes
• Process analysis — how a map turns into a defensible statement

To carry on calculating: our free process cost calculator puts a monthly figure on the workflow you just mapped, including savings potential and a step-by-step breakdown.