More than 10,000 ways to process an order.
A process-mining engagement revealed how much work the documented process had left out.
On one process-mining project, I saw more than 10,000 variations in how orders were processed. The documented process did not describe that reality.
The number matters because it shows how far the official process was from the real one. An order can appear to follow a familiar sequence while the people handling it know there are exceptions, repeat steps and different routes to completion. A process diagram can look entirely reasonable and still be a poor description of the work.
My concern is what happens when that diagram becomes the basis for a system decision.
Who knows which part?
The person with budget authority may understand the objective without knowing the process in enough detail to specify it. The person entering orders may understand the exceptions at entry but never see what happens after a handoff. Someone downstream may know why work comes back.
Ask any one of them to describe the whole process and you may get a confident but incomplete answer. Nobody has to be careless for this to happen. The organization may have all the knowledge it needs without ever bringing it together.
Sometimes people who know the work explain the mismatch, but speed, cost, or an existing licence wins anyway. That is a different problem. Inviting them to another workshop will not help unless their answers can change the decision.
A variation needs an explanation.
More than 10,000 variations does not mean more than 10,000 mistakes. A variation may reflect a legitimate requirement, an unnecessary habit, or a workaround for something the formal process cannot handle.
Those possibilities need different decisions. Eliminating every exception risks removing work the business depends on. Reproducing every exception in a new system risks paying to preserve complexity nobody still needs.
Understand the difference before the new system makes the choice expensive to reverse.
In How Big Things Get Done (2023), Bent Flyvbjerg and Dan Gardner argue for doing the difficult thinking during planning rather than rushing into delivery. I apply that principle here: understand the work before deciding how to replace it.
Follow real orders, including the awkward ones.
Start with a recently completed order. Bring together the people who handled it and reconstruct what actually happened. Compare their account with the documented route and the available records.
Then look at orders that were delayed, returned, or handled differently. One smooth example cannot tell you how much variation exists. For each difference, ask why it happened and what would break if that route disappeared.
The map is an input, not the answer.
A process map is useful when people can challenge it. It becomes a liability when approval makes it immune to correction. Keep the people closest to the work involved while the requirements are being tested, not only when the training starts.
The problem may show up in the technology. But the cause may be an unclear goal or a culture that ignores the people closest to the work. The number alone cannot tell you where the problem sits.
Before changing the system, find the work the map left out.