Why process maps go out of date, and what to do about it

Everyone has been through this. A team spends months mapping a process. The diagram is beautiful. It goes on the wall, or into a folder, and for about a quarter it is genuinely useful.

Then a system changes. Then a policy changes. Then the team reorganises. Eighteen months later someone opens the file and the first thing they say is: is any of this still true?

Nobody can answer. So they book a room, and do it all again.

This is so common that people treat it as a law of nature. It is not. It is a consequence of one specific decision that almost everyone makes without noticing.

The decision: the diagram became the record

When you draw a process map, the diagram is the thing you made. It is the deliverable. It is what you store, what you share, what you update.

Then everything else gets attached to it. Who owns this step? Add a note to the box. What policy applies? Another note. What system does this run on? Put it in the box label. What is the target time? A little table beside the diagram.

That seems reasonable. But it means every piece of knowledge you have about the process is now hanging off a picture.

And when the picture goes stale, everything hanging off it goes stale at the same moment. Not gradually. All at once, and invisibly, because nothing in the file tells you which parts changed.

The inversion

There is a different way round, and it sounds like a technicality until you see what it does.

The real record of a process is not the picture. It is the things that move through the process, and the events that change them.

A purchase order is raised. Approved. Amended. Matched to a receipt. Paid. That sequence, the thing and what happened to it, is what actually happened. It is true whether or not anyone ever drew it.

Store that as the record, and the diagram becomes a view of it. One way of looking, drawn on demand. Change the record and every view updates, because none of them is the master copy.

The people, the policies, the targets, the systems, the screenshots attach to the record too, to the specific step or the specific thing they concern, not to a box on a canvas.

What this actually changes

One update, not many. Change the approval threshold and it changes in one place. Every view that shows it is already correct.

Questions you did not plan for. A diagram answers exactly one question: the one it was drawn to answer. Ask a different one and you commission another diagram. A record answers the next question too: follow one case through, or show one role's work, or list every step constrained by a policy.

You can tell what is stale. If every item records where it came from and when it was confirmed, staleness is visible. You can look at a record and see which parts are solid, which are drafts nobody has checked, and which came from a document that has since been superseded.

That last one is the difference between a document people trust and a document people quietly stop opening.

How to stop the rot

If you are starting a process mapping effort, three things are worth deciding up front.

1. Decide what your record is. If the answer is "the diagram", you have already chosen the rot. Make the steps and the things that move the record, and treat every diagram as a view of it.
2. Attach detail to steps, not to pictures. The owner belongs to the step. The policy belongs to the step. Not to a text box positioned near it.
3. Make every item cite its source. Where did this come from, which document, which page, and has a person confirmed it? Without that, nobody can ever tell which half of the map to trust, and so they trust none of it.

None of this makes a process stop changing. Things change; that is what businesses do. What it changes is the cost of keeping up, from "book the room again" to "update the thing that changed".

The three ways people do this today →

• How to document a business process (without a six-month workshop)

  The usual way puts forty people in a room and asks them to remember. There is a way that starts from what they already wrote down.

• Process context vs. data context

  Both are real, both are needed, and they answer different questions. Where the boundary falls, and what happens to the questions that land on the wrong side of it.