White Belt · 12 min

Mapping the gaps, not the boxes

After this you can

draw a basic process map and mark where work waits.

Assumes you have done DMAIC: what each phase produces and why the order holds.

A finance team flowcharted their invoice process: five boxes, 46 minutes of work end to end. They opened a project to speed up the matching step, which at eight minutes was the second longest box. Nobody could explain why suppliers were waiting four days to be paid, because the flowchart had no notation for the thing that took four days. It had boxes. The four days were in the gaps between them.

The idea

A process map is a flowchart with the waiting written down.

That one addition is the difference between a mapping exercise that changes something and one that produces a poster. In office and service work the ratio is not close: the work takes minutes and the process takes days, and every one of those days sits in a gap that a box-and-arrow diagram has no way to show.

Two clocks

Working time is how long the activity takes when somebody is doing it. This is what people estimate when you ask "how long does that step take?", and they are usually accurate.

Lead time is elapsed time — the whole clock, from the customer's point of view, including every queue, every overnight, every wait for an approver to come back from leave.

The gap between them is where improvement work lives, and it is invisible from inside any single step. Everyone in the process is busy. Every step is efficient. The process is slow.

What to record for each step

What happens — an action, starting with a verb.
Who does it, because handoffs between people are where queues form.
Working time — how long the activity takes.
Waiting time before it — how long the item sat before this step started. Ask "when the previous step finished, how long until someone picked this up?"

That last question is the one that is never asked, and it is the one that produces the number nobody knew.

Reading the map

Once the times are on one scale, three things become visible that were not:

Where the queues are. Not where the work is. These are almost never the same step, and teams reliably guess the busy step rather than the queued one.

Whether the map matches reality. Add up the lead time and compare it with what customers actually experience. If your map says two days and the customer says a week, you are missing a queue — often a loop where work goes back for rework and nobody counted the second pass.

Where the rework is. A step whose output sometimes goes backwards is not one step; it is a step plus a hidden loop. Mapping the loop is usually the single most valuable thing a mapping session produces.

Mapping the process that actually runs

Map what happens, not what the procedure says. The two differ, and the difference is information rather than a problem: if people work around the standard, the standard does not fit the work. Walk the process, follow one real item, and ask at each step what happens when things go wrong — the exception path usually carries far more of the volume than anybody expects.

Worked example

The invoice process, mapped properly.

Step	Who	Work	Waiting before	Classification
Receive invoice	Accounts inbox	3 min	—	Business-necessary
Match to purchase order	Accounts clerk	8 min	8 h	Value-add
Resolve mismatch	Purchasing	25 min	2 d	Waste — defects
Obtain approval	Budget holder	4 min	1 d	Business-necessary
Release payment	Accounts clerk	6 min	16 h	Value-add

Working time: 46 minutes. Exactly what the flowchart said.

Lead time: 5,806 minutes — 4.0 days.

Waiting: 5,760 minutes, which is 99% of the elapsed time.

Value-add ratio: 0.24%. Fourteen minutes of the four days are work the supplier would pay for.

That number reads like an error the first time anyone sees it. It is not. Ratios between 1% and 10% are ordinary for office processes, and below 1% is unremarkable for anything with several approvals in it. The reason it feels wrong is that everybody inside the process is busy all day, and being busy is not the same as the work moving.

Now compare the two projects.

The flowchart project was going to halve the matching step: eight minutes down to four. Saving: 4 minutes out of 5,806.

The two-day queue in front of Resolve mismatch is the largest single block on the map, and it exists because mismatched invoices go to a different team that batches them. Removing it saves 2,880 minutes — 720 times more than the project that was about to start, and it requires no one to work any faster.

One more thing the map shows. Resolve mismatch is classified as waste, category defects: it is rework, and it only exists because something upstream produced a mismatch. Twenty-five minutes of work and two days of waiting are spent correcting an error made earlier. The real question the map raises is not how to speed up the resolution — it is why the mismatches happen at all.

Dataset: ds-invoice-process-map — the same data loads in the tool below, so you can reproduce every figure here yourself.

Your turn

The map opens with the invoice process, drawn to scale.

Look at the bars before the numbers. The solid blocks are the work; the hatched blocks are the waiting. On this scale the 8-minute matching step is nearly invisible next to the queue in front of it — which is the entire argument of this lesson in one picture.
Halve Match to purchase order from 8 minutes to 4, the project the team was about to run. Watch the value-add ratio and the lead time barely move.
Now set the waiting before Resolve mismatch to 0 — the batching changes to same-day. Lead time drops by two days from a change that asks nobody to work faster.
Notice the tool asking you to categorise Receive invoice: it is business-necessary with no waste category. Categorising is what turns "this is not value-add" into something specific enough to change.
Map a process from your own work. Fill in the waiting column last, and expect the total to surprise you.

Process Map

practice

Record the work and the waiting. A flowchart has no notation for the gaps, which is where nearly all the elapsed time in office work lives.

Receive invoice3 min work · 0 min waiting
Match to purchase order8 min work · 8.0 h waiting
Resolve mismatch25 min work · 2.0 d waiting
Obtain approval4 min work · 1.0 d waiting
Release payment6 min work · 16.0 h waiting

Solid: working. Hatched: waiting. Drawn to one scale — which is the point. Waiting is 99% of the elapsed time.

Process steps with who performs them, working time, waiting time before the step, and classification.
Step	Who	Work (min)	Waiting before (min)	Classification	Waste category

Lead time

4.0 d

Working time

46 min

Waiting

4.0 d

Value-add ratio

0.24%

The largest removable category is waiting at 5760 minutes — 99.2% of total lead time. Removing it would do more than speeding up the value-add work.

Working twice as fast on the value-add steps would save 7 minutes. Removing the largest waste category would save 5760. The waiting is where the time is — it nearly always is, and it is nearly always the part nobody measures.

1 non-value-add step has no waste category. Categorising them is what turns "this is waste" into a specific thing you can change.

How this is calculated

Waiting is treated as a step in its own right, so it lands in the lead time and in the waste totals rather than being a property of a box that the arithmetic never sees. Value-add ratio is value-add time ÷ total elapsed lead time, including every wait — not the time the team was busy. Measuring against working time answers “how busy were we?” and produces a comforting number.

The arithmetic is the same function the Waste Walk uses, so the two tools cannot disagree about a value-add ratio.

Source: Rother, M. & Shook, J. (1999), Learning to See; George, M. et al. (2005), The Lean Six Sigma Pocket Toolbook — process cycle efficiency.

Check yourself

No hints. Wrong answers are explained, not softened.

A process map shows six steps totalling 90 minutes of work and a lead time of 6 days. What should the team work on first?

Your map totals 2 days of lead time. Customers consistently report about a week. What is the most likely explanation?

A team maps the process as documented in the standard operating procedure, then discovers the floor does something different. What should the map show?

Worth remembering

What does a process map add to a flowchart?

The waiting between steps. In office work the activity takes minutes and the process takes days, and every one of those days sits in a gap a flowchart cannot show.

Your map says two days and customers say a week. What are you probably missing?

A rework loop. Work goes back, re-queues, and the second pass was never counted. Map the exception path and measure how much volume takes it.

Should a process map show the documented process or the actual one?

The actual one. Where practice differs from the standard, that gap is information — people work around a standard when it does not fit the work.

Can you do this now?

Rate yourself honestly. We compare your rating with how you actually answered — the gap is more useful than either number alone.

I can draw a basic process map and mark where work waits.

Your rating is recorded alongside your drill results. Neither alone marks the competency as met.

The problem