How to Read a Process Map You Did Not Draw

Somebody hands you a process map. A consultant drew it during an engagement that finished two years ago, or the last operations manager built it in Visio, or a tool generated it from your ticketing system last Tuesday. Either way you are looking at a diagram of how work supposedly moves through a business, and you have to decide how much of it to believe.

The instinct is to read it like a route map: find the start, follow the arrows, arrive at the end. That gives you the happy path and almost nothing else. The happy path is the least useful thing on a process map, because it is the part everybody already agrees on. What you are actually looking for is the places where the map and the business have quietly come apart.

Six passes, in this order.

Check that the start is the real start

Most maps begin where the person drawing it started paying attention, which is usually a system event: a ticket raised, an order created, a form submitted. The real beginning is often a customer emailing an engineer directly, or a salesperson promising something in a meeting that nobody writes down for two days.

Test it by asking whoever does the second step where the work actually reaches them. If the answer names a channel that is not on the map, the map is missing its front door, and every duration on it is being measured from the wrong moment.

Count the handovers, not the boxes

Thirty boxes inside one team is usually fine. Nine boxes across five teams usually is not. Work does not rot while somebody is doing it. It rots while it sits between two people who each think the other has it.

Mark every point where the map changes owner, team or system. That count predicts how long the process really takes far better than the number of steps does, and it tells you where to look first when somebody says the process is slow.

Look for a branch with no rule

Every branch is a decision, and every decision should carry the rule that settles it. A diamond labelled "approved?" with no criteria beside it is not a process step. It is a judgement, which means it runs at the speed of whoever holds it and produces a different answer depending on who that is.

These are the cheapest things on the map to fix and the most reliably undocumented. Write the rule down and half of them stop being decisions at all.

Ask who owns each box, and accept only names

"Operations" is not an owner. "Sales" is not an owner. A box owned by a department is a box that belongs to nobody on the day it breaks.

Go through the map and put a person's name against every step. Anywhere you cannot, you have found either a gap in the map or a gap in the organisation, and it is worth knowing which. This pass takes ten minutes and it is the one most likely to start an argument, which is rather the point.

Find the steps that exist because of one person

Every real process contains a few steps that make no sense on their own. A spreadsheet somebody updates at four on a Friday. A second copy of a record, kept by hand, in a different system. A check that repeats a check two boxes earlier.

On a map these look like waste. They are usually compensation: somebody does not trust something upstream and has built their own insurance against it. Before you remove anything that looks pointless, find out what it is insuring against. The step is the symptom. The cause is further back.

Walk one real item across it

Pick a single thing that went through the process last week. One ticket, one order, one new client. Follow it across the map, step by step, and mark every disagreement.

Where the item did something the map does not show, the map is wrong. Where the map shows a step the item skipped, either the step is optional, in which case the map should say so, or it is being skipped quietly, in which case somebody should know. One item is enough to find most of it, and a map that survives one real item is usually good for the rest.

What a map is for

A process map is not documentation. Documentation describes. A map is supposed to let you act. After these six passes you should be able to answer three questions without opening anything else: where does work wait longest and between whom, which steps produce nothing that anyone downstream uses, and if one person left tomorrow which boxes stop.

If the map cannot answer those, it is a picture rather than a tool. The fix is not another workshop. It is handover counts, owner names, and one real item walked end to end.

One argument against all of this. A map you inherited and keep current beats a better one you draw and then abandon, and most redraws are abandoned. If what is in front of you is roughly right, correcting it is nearly always cheaper than starting again. The six passes are how you find the part that is wrong. They are not a reason to throw the map away.

If you would rather draw your own than inherit somebody else's, abi. Clone builds a process map from a short intake instead of a workshop. It is free, it runs in the browser, and you can try it without an account.