Showing posts with label business process mapping. Show all posts
Showing posts with label business process mapping. Show all posts

Wednesday, August 19, 2026

Mapping A Process Nobody Has Written Down

Split panel graphic reading: Everyone describes the process differently What it actually is: Nobody has written it down.

A process nobody has written down is mapped by watching the work, not by asking about it. Descriptions collected in a room produce the process people believe they follow. Observation produces the one that actually runs, and the gap between those two is where most operational problems live.

That gap is not dishonesty. People describe the version they were taught, or the version that works when nothing goes wrong, because the exceptions are handled by habit rather than by rule.

Mapping therefore begins as an act of observation rather than documentation. What gets written down is the output of the exercise, not the exercise itself.

The anti-pattern is the workshop map

A room is booked. Everyone who touches the process attends. A facilitator draws boxes on a wall and the group agrees on the sequence, and the resulting diagram is clean, linear, and wrong.

It is wrong in a specific way. Group mapping captures the happy path, because the happy path is what everyone shares. What it misses is not hiding by intent, it is hiding by omission. Exceptions belong to individuals, and an individual rarely volunteers the workaround they invented, since describing it in front of a manager sounds like confessing to something.

The map that results looks authoritative and omits the rework, the second system somebody keeps in a spreadsheet, and the phone call that unsticks things twice a week. Those omissions are the process. Everything else was already working.

Observe before you diagram

A calmer approach delays the diagram. Before any boxes are drawn, the work is followed through the organization. The period has to be long enough to catch an exception, because exceptions are the reason mapping is being done at all.

Following work rather than interviewing people changes what is visible. Handoffs appear where nobody described one. Queues become obvious, since a piece of work sits somewhere while someone waits for information, and nobody in a workshop describes waiting.

Theory of constraints supplies the reason to care about queues specifically. Work accumulates in front of the limiting step, so the place where things pile up identifies the constraint without anyone having to reason about it. Porter's separation of primary activities from support activities then tells you whether the constraint sits in the value-creating work or in the machinery around it.

The systemic fix is a map of exceptions, not steps

Serious work on business process mapping treats the exception path as the deliverable. The happy path is background against which exceptions become legible.

Start by recording every point where the work stops. Not why it stopped, initially, just where. A list of stopping points is a list of candidate constraints and it takes observation rather than analysis to produce.

For each stopping point, ask what is waiting for what. Information waiting on a person, a person waiting on approval, physical work waiting on materials. Those three classes fail differently and mixing them produces a map nobody can act on.

Then attach ownership. A RACI grid applied to a process map exposes the steps where responsibility is unnamed, and unnamed responsibility is the most common cause of a queue that nobody can explain. Work sits because sitting is not anyone's problem.

Only then draw something. The diagram is a communication artifact for people who did not do the observation, and it is worth very little to the people who did.

Why the undocumented process is a burden on people

An undocumented process is held in individual memory, and that has consequences beyond the operational ones. The person holding it cannot take leave without the work degrading. They cannot be promoted without creating a gap. They are also, quietly, the reason the company has not noticed the process is fragile.

Writing it down protects them. It converts private knowledge into shared knowledge, which sounds like a loss of standing and is usually the opposite. The person who documented the process becomes the person who improved it rather than the person trapped inside it.

Documentation is therefore a form of care before it is an efficiency measure. A company that maps its processes tells its people something specific. Continuity does not depend on any one of them being available, and that message is worth more than the diagram.

What this looks like in practice

Consider a mid-market distribution company where order accuracy had declined and nobody could say why. The workshop map showed a clean five-step flow from order receipt to dispatch, and everyone in the room agreed with it.

Observation over two weeks found something the room had not mentioned. A warehouse supervisor was reconciling a stock discrepancy by phone with the office each morning. The step had been invented years earlier and never described, because it did not feel like part of the process. It felt like tidying up.

That call was the constraint. It ran once a day, it took as long as it took, and every order behind it waited. No diagram contained it, so no improvement had ever touched it.

Organizations that map by observation report the same shape of finding often enough that it should be expected rather than treated as a surprise. Firms that map by workshop tend to confirm what they already believed and improve the steps that were never the problem.

The question the map should answer

A process map earns its cost when it answers a specific question, and the useful question is rarely how the work flows. It is where the work waits, and who owns the waiting.

Jobs to be done offers a discipline worth borrowing here. Asking what a step is hired to accomplish, rather than what it does, exposes steps that have outlived their purpose. They continue because removing them was never anyone's job either. A step with no strategic fit still consumes the same attention as one that carries the work.

Engagements that begin with a stated question finish faster and produce narrower maps. Engagements that begin with mapping as an end in itself produce documents that are accurate, complete, and used by nobody.

What compounds

Each mapped process makes the next one faster, because the conventions are already agreed and the observers know what to look for. The second map takes a fraction of the time of the first. By the fourth, the organization has a shared vocabulary for handoffs and queues that did not exist before.

That vocabulary is the durable asset. Diagrams go stale as the work changes, and they should. A company that has learned to see where work waits will keep seeing it long after any particular map has been superseded.

Every process a company can describe honestly, including its exceptions, is a process someone other than its current holder could run. Every process that exists only in a workshop diagram is still being held in somebody's memory, and the company has simply agreed not to look at that.

Frequently Asked Questions

How do you map a process that has never been documented?
By following the work rather than interviewing the people who perform it. Descriptions collected in a room capture the path that works when nothing goes wrong. Observation over a period long enough to catch exceptions captures the path that actually runs, including the workarounds nobody volunteers.
Why are workshop-produced process maps unreliable?
Because they capture what the group shares, which is the happy path. Exceptions belong to individuals, and describing a personal workaround in front of a manager feels like admitting to something. The omitted material is usually the entire reason the mapping exercise was commissioned.
What should a process map actually show?
Where work stops and who owns the stopping. Sequence is easy to obtain and rarely informative. Queues identify constraints without analysis, because work accumulates in front of the limiting step, and unnamed ownership is the most common reason a queue persists unexplained.
How long should observation take before diagramming?
Long enough to see an exception, which depends on how often the process runs rather than on a fixed period. A process that runs daily may reveal its exceptions within a week. A monthly close may take a full cycle, and mapping it from description will miss what matters.
Does documenting a process reduce the standing of the person who held it?
The opposite, in practice. Undocumented knowledge traps its holder, who cannot take leave or move roles without the work degrading. Documentation converts private knowledge into shared knowledge and repositions that person as the one who improved the process rather than the one confined to it.
When is an outside observer worth the cost?
When everyone capable of doing the observation is inside the work being observed. Familiarity makes exceptions invisible, because a workaround performed for years stops registering as a workaround. An outsider carries no assumption about which steps are supposed to be there.