Ask the people who run a business to describe one of their core processes and you will usually get a clean, confident answer: first this happens, then that, then this, and it is done. Ask to follow a single real piece of work through that same process, step by actual step, and a very different picture appears. There are detours nobody mentioned, steps that exist only in one person's habits, exceptions handled by a quiet workaround, and waits where things sit for days. Every company has two processes: the one it thinks it has, and the one it actually runs. They are rarely the same, and the distance between them is where a surprising amount of cost, delay, and risk quietly lives.
This matters because almost everything a business does to get better, whether improving a process, automating it, buying software to support it, or restructuring around it, is built on a picture of how the work flows. If that picture is the tidy documented version rather than the messy real one, the effort is built on a fiction, and it fails the moment it meets reality. You cannot improve, automate, or fix a process you have never actually seen. You can only improve the story you tell about it, which is not the same thing at all.
The documented process is a story, not a record
Most documented processes were written once, early, to describe how the work was supposed to go. From that moment they begin to drift out of date, because the work keeps changing and the document does not. The flowchart in the shared drive, the steps in the training manual, the diagram in the slide deck: these describe intentions, not current reality. They are a story the organisation tells about itself, usually an outdated and flattering one, in which every case is standard and every step happens as designed. The real process has moved on without telling anyone, and the longer the gap between when the document was written and now, the less it resembles what actually happens today.
Where the real process hides
The real process lives in the places the document leaves out. It lives in the exceptions, the cases that do not fit the standard flow and get handled by someone improvising. It lives in the workarounds, the informal shortcuts people invented because the official way was too slow or did not fit. It lives in the steps that exist only in one experienced person's head, invisible until they are on leave and everything stalls. And it lives in the shadow systems, the spreadsheet on someone's desktop that half the process secretly depends on. None of this is in the flowchart, and all of it is load-bearing. A process map that captures only the clean path is not a simplified version of reality; it is a different process that nobody actually runs.
Why the gap wrecks improvement and automation
The gap is not harmless, because it is exactly what improvement and automation projects trip over. Automate the documented process and you automate the version that ignores every exception and workaround the real work quietly depends on, so the automation works in the demo and fails on the real cases the moment it goes live. Buy software designed around the process you think you have and it will not fit the one you actually run, and people will either reject it or build fresh workarounds on top of it. Restructure a team around an idealised flow and the real handovers it missed will start to break. In every case, the project was designed for a process that does not exist, which is why so many well-funded improvement efforts deliver so little: they optimised the map while the territory carried on as before.
Map what actually happens, not what should
The fix is not cleverer solutions; it is seeing the real process before touching it. That means going and watching the actual work rather than asking how it is meant to go. Follow one real item end to end, from the moment it arrives to the moment it is finished, and record every real step, wait, handover, and decision, not the ones that should be there, the ones that are. Talk to the people who do the work every day, because they are the only ones who know the exceptions and the workarounds, and make it safe for them to tell you how things really happen rather than how the manual says they should. Look hard at where work waits, where it loops back, and where someone fixes something by hand. What you end up with is an honest map of the current reality, exceptions included, and only from there can you sensibly decide what to improve, automate, or remove.
A worked example
A business asked us to automate what they described as a simple, well-understood approval process, and on paper it was: a request comes in, a manager approves it, the work proceeds. When we followed real requests through it, the actual process looked nothing like that. Roughly a third of requests did not fit the standard path and were handled by a senior person using judgement that existed nowhere in writing. Certain types quietly skipped the manager entirely through an informal shortcut everyone had agreed to years ago. And a spreadsheet nobody had mentioned was tracking the cases the official system could not handle. Had we automated the documented process, it would have broken on a third of all requests on day one. Because we mapped the real one first, we could see that the genuine problem was not the approval step at all, but the unmanaged pile of exceptions, and the fix was far simpler and cheaper than the automation they had asked for. Mapping reality did not just enable the project; it changed what the project should be.
See it before you change it
It is tempting to move straight to solutions, because mapping the current reality feels like slow, unglamorous work next to building the improvement. But every solution is only as good as its understanding of the process it is meant to serve, and most understandings are of the documented fiction rather than the running reality. The businesses that actually get better are the ones willing to look honestly at how their work really flows, exceptions and workarounds and all, before they spend a rupee changing it. Before the next improvement, automation, or system, the most valuable question is not how do we make this faster, but do we actually know how it works today, because the process you think you have is almost never the one you run.
Seeing how your work truly flows today, exceptions and workarounds included, so that whatever you improve or automate next is built on reality rather than a tidy fiction, is the heart of our process assessment and mapping work. Book a discovery call and we will help you map the process you actually run.
Frequently asked questions
What is process mapping?
Process mapping is the work of setting down, step by step, how a piece of work actually flows through a business from start to finish: who does what, in what order, what each step waits on, and where things get handed over, hold up, or go wrong. The point is not to produce a neat diagram of how the work is supposed to happen, but an honest picture of how it really happens, including the exceptions, the manual workarounds, and the steps that live only in someone's head. A good process map is the shared, accurate view of reality that lets a business see where the time and the problems actually are, which is why it is the foundation for improving, automating, or systemising almost anything.
Why is the real process different from the documented one?
Because the documented process describes how work was meant to go, and reality keeps diverging from it without anyone updating the document. Over time, edge cases appear and get handled with one-off workarounds, people invent quicker informal routes, steps get added to deal with a problem and never removed, and knowledge about how things really work settles into individuals rather than into any written record. The official process stays frozen as a tidy story while the real one drifts into something messier and more complicated. The result is that the flowchart on file and the work happening on the floor describe two different businesses, and the gap between them is usually far larger than anyone expects until they look.
Why map a process before improving or automating it?
Because if you build an improvement or an automation on the documented process rather than the real one, you build it on a fiction, and it breaks the moment it meets reality. Automating a process you have not truly mapped means automating the version that ignores all the exceptions and workarounds that the real work depends on, so the automation fails on the cases that actually matter. The same is true for new software, restructures, and efficiency drives: they are designed for the process people think they run and then collide with the one they actually run. Mapping the real process first is what stops you from spending heavily to optimise something that does not exist, and it very often reveals that the simplest fix was in the gap all along.
How do you map what actually happens?
You go and watch the real work rather than ask how it is supposed to go. Follow a single real item all the way through, from the moment it enters to the moment it is done, and record every actual step, wait, handover, and decision it passes through. Talk to the people who do the work every day, because they know the exceptions and workarounds that never made it into any document, and make it safe for them to tell you how things really happen rather than how they are meant to. Pay special attention to where work waits, where it goes back a step, and where someone quietly fixes something by hand. The goal is an honest map of the current reality, exceptions included, before anyone starts drawing the improved version.