Ask a company how a customer order gets fulfilled, and you will get an answer. It will be clear, it will be sequential, and someone may have a diagram. That answer describes a process. It is rarely the one the company is running.
This is not a criticism, and it is not a documentation problem to be fixed with better documentation. It is the single most useful diagnostic available to anyone trying to improve how a business works — provided you go looking for the difference rather than trying to eliminate it.
Descriptions produce the official version
The first mistake is method. If you ask people to describe the process, they will describe the process as it is supposed to be, and they will do this sincerely. Memory reconstructs from the general case. Nobody includes the message they send every Tuesday to chase a thing that never arrives on its own, because that message does not feel like part of the process. It feels like an annoyance.
It is part of the process. It is the most informative part.
So do not ask people to describe it. Follow the work. Take one real order, one real invoice, one real onboarding, and trace what happens to it, step by step, talking to each person as it reaches them, about the specific thing in front of them right now. The questions that produce findings are small and concrete: what did you just do with this? What do you do when it arrives wrong? What did you have to check first?
You will get a different process than the one on the diagram. That is the point of doing it.
Every workaround is a solved problem
When you find a step that is not documented — the second spreadsheet, the manual re-check, the message on Tuesday — the instinct is to see waste. Someone is doing something unnecessary. Cut it.
That instinct is usually wrong, and acting on it is how process improvement projects make things worse.
Every one of those steps exists because a person hit a problem and solved it. The re-check exists because the data was wrong once and it was expensive. The second spreadsheet exists because the system will not show two things side by side. The Tuesday message exists because the upstream team has no way of knowing you are waiting.
Remove the workaround without solving the problem underneath and you have not removed anything. You have moved the cost somewhere less visible, usually onto a different person, who will invent a new workaround within a month. Now the problem is the same and you cannot see it.
So the question at every undocumented step is not why are they doing this. It is what would have to be true for this to be unnecessary.
Sometimes the answer is a system change. Sometimes it is a permission. Sometimes it is one conversation between two teams who each assumed the other owned a step. Occasionally the honest answer is that the workaround is the cheapest available fix and should be documented and kept, which is a perfectly good outcome — a known workaround is a different animal from an invisible one.
What the gap tells you
Once you have both versions side by side, the difference sorts into a small number of patterns, and each points somewhere specific.
Steps that exist only to move data between two systems mean a person is acting as an integration. That is the clearest automation candidate you will find, and usually the cheapest.
Steps where someone checks work that was already done mean trust has broken somewhere upstream. Automating the check makes the check faster; fixing the upstream quality makes it unnecessary.
Steps nobody can explain — where the answer is “we have always done it that way” and no one will defend it — can generally go. That is the whole test. If you announce you are removing it and nobody objects, it was not load-bearing.
Steps where two teams each believe the other owns it are where work silently falls through. These are rarely visible in any documentation, because both teams documented it as the other team’s responsibility.
Then give it an owner
The last part is the one most often skipped, and it is the reason so many process improvements do not survive.
A redesigned process with no named owner reverts. Not because anyone opposes it, but because the moment reality diverges from the new process — and it will, within weeks — somebody has to decide what happens. With no owner, the answer is whatever is locally convenient, and each of those small local decisions is the first step of a new undocumented process.
One name per process. Not a committee, not a department. The person who decides what happens when the process meets a case it does not cover.
Do that, and the map you drew stays true for longer than a quarter. Skip it, and you will run this exercise again next year and find a fresh set of Tuesday messages.
