The auditor leafs through the quality manual and reads out the approval process for customer orders: receipt, check by order processing, technical approval, commercial approval, scheduling. Then she asks the clerk how this morning's order went. The clerk explains: the customer called, she emailed the order straight to the production planner because it was urgent, the approvals will be entered afterwards once sales is out of its meeting. The two look at each other. The auditor writes.
I have been experiencing variations of this scene for many years, on the shop floor as in the office. The manual describes one process. The plant lives another. And the first reaction is almost always the same: record the deviation, admonish the employees, enforce the manual. Sometimes that is right. Often it is the most expensive mistake you can make at this point.
Because the question "Who is right?" is the wrong question. The right question is: why are the two processes different, and which of the two is the better one? The answer regularly surprises managers. And it decides whether your next digitalisation maps the right process or the one that exists only on paper.
How the gap arises
Nobody deliberately writes a manual that does not fit everyday life. The gap creeps in, from three directions.
The first: the process was designed at the desk. Someone from quality management or organisation wrote it down, clean and logical, with an eye on the standard and the certification. The people who carry it out every day were not involved or nodded it through once. The process was a wish from the start, not a reflection of reality.
The second: the process was once correct and the world has moved on. New customers, new products, a new ERP system, a reorganisation. Everyday work has adapted, the manual has not. The process description is a photograph from several years ago.
The third, and the most interesting: everyday work has found a better way. The clerk who sends the urgent order straight to the planner is not bypassing the rule out of convenience. She is bypassing it because the commercial approval would have taken three hours that day and the customer needed the date. She recognised a bottleneck in the process and built a solution. The manual never saw the bottleneck.
What the gap really costs
You know the obvious costs: audit findings, rework in the documentation, discussions. The real costs lie deeper.
First: nobody knows how the process really runs. If the manual is wrong and the lived process exists only in people's heads, order processing depends on individuals. If the clerk who knows when which approval may be skipped is absent, the process stalls or runs into a void.
Second: improvement becomes impossible. You can only improve what you can see. Whoever optimises the manual optimises a fiction. Whoever does not know everyday work cannot say where the waste sits.
Third, and this is the most expensive point: digitalisation maps the wrong thing. If a company introduces a new system and derives the requirements from the manual, it builds software for a process nobody lives. People then build the same detours around the software that they previously built around the manual, only now with Excel lists and emails alongside the system. I have seen plants where an elaborately introduced workflow system served only for documentation after a short time, while the real work ran alongside it.
Who is right? Three possible answers
When I stand in front of such a gap with a team, we examine three possibilities, without prejudging.
- The manual is right. Everyday work has built a shortcut that violates a purpose of the process: a check that prevents errors reaching the customer, an approval that controls costs, a safety level. Then everyday work has to return to the standard, but with the question of why the shortcut was attractive. Usually the answer is: the standard is too slow. Then that needs solving, not just admonishing.
- Everyday work is right. The shortcut fulfils all purposes of the process, only faster and with less effort. Then the manual is adapted, and the clerk has made an improvement suggestion without anyone calling it that.
- Neither of them. The manual is too cumbersome, everyday work depends too much on individuals. Both are symptoms of a process that needs to be rethought. That is the most common case.
In the order processing of a supplier with several customer groups there was an approval process that the manual described in five stages and that everyday work lived in two variants: one for regular customers, one for everything else. Neither variant was documented. In the end there was a new process with a switch at the start that mapped both cleanly. The clerks had in effect already invented it. All that was missing was someone who looked.
Making the lived process visible
The precondition for any answer is that you know the lived process. That sounds obvious and it is not. Most managers know the manual and have an assumption about everyday work.
The most reliable way is to follow a real transaction from start to finish. Not the description of the transaction, the transaction itself. You take an order that came in yesterday and trace it: who received it when, what they did with it, where it went next, where it sat, where it was queried. At its core that is value stream mapping in the office, and in a few hours it delivers more truth than any process documentation.
Almost always the same pattern shows: the transaction sits far longer than it is worked on. It is handled several times. It leaves the system and comes back by email or word of mouth. And at one or two points there is a person who knows how to get it done anyway. These people are your most valuable pointer to where the process breaks.
What matters here is the attitude. Whoever sets up this recording as a control gets a demonstration of the manual process. Whoever sets it up as curiosity gets the real one.
Bringing both sides together
In the end it is not about forcing everyday work into the manual or adapting the manual to everyday work. It is about having a process that is both: the best known way, and the way people actually take.
That only succeeds if the people who carry out the process also describe it. Not quality management alone, not the department head alone. The team, facilitated, with yesterday's transaction on the wall. What emerges is shorter than the old manual, because it contains only the steps that are really needed, and it is lived, because it comes from everyday work.
And it needs a mechanism that keeps the gap small in future. The simplest: whoever builds a shortcut says so. Not as a confession, but as a suggestion. That requires leadership that treats a shortcut as information and not as a violation. As soon as people experience that their shortcut becomes the new standard when it is better, they stop hiding it. From then on the manual becomes what it should be: a reflection of the best known way, maintained by those who take it.
Before the next software: process first
If you are planning a digitalisation, a new ERP module, a ticket system, an approval workflow, then the gap between manual and everyday work is the first thing you should close. Not the last.
The sequence that has proved itself: first record the lived process. Then decide together with the team how the process should run in future, and live it for a while without new software. Only once it is stable is it transferred into the system. Whoever reverses the sequence and designs the process in the software gets expensive change requests and a system around which the old detours carry on.
The manual and the plant will never be fully congruent. But the gap can be small, visible and productive. Then the question "Who is right?" is no longer a question of conflict, but the question with which your process gets a little better every month.
In short
- The gap between manual and everyday work arises at the desk, through time, or because everyday work has found a better way.
- The most expensive consequence: digitalisation maps a process nobody lives. The detours then carry on alongside the system.
- Examine without prejudging: the manual is right, everyday work is right, or neither. The third case is the most common.
- Follow a real transaction from yesterday. That shows more in hours than any process documentation.
- Whoever builds a shortcut says so. Leadership treats it as information, not as a violation.
Frequently asked questions
Frequently asked questions
Do I not have to stop deviations from the documented process immediately for audit reasons?
Deviations that violate a purpose of the process, such as checks or approvals with safety relevance, yes. All others are first of all information. The standard requires that your documented process matches the lived one, not that the documented one stays unchanged. Adapting a manual because the team has found a better way is in the spirit of every management system. What you should have demonstrated in the audit is the real process, not a show.
How do I find out where in the office the gap is biggest?
Ask your people where they most often have to check back, where they keep their own lists alongside the system and which transactions they prefer to handle themselves because otherwise it does not work. At these points everyday work deviates from the manual. Then take one of these transactions and follow it from start to finish. You do not need more analysis than that to get started.
Who should write the new process description?
The people who carry out the process, together, with someone who facilitates and provides structure. Quality management brings in the requirements of the standard, the department head the goals, but the result has to be in the language and at the level of detail of those who do the work. A description the team has written itself is lived and maintained. One from the office gets filed.








