“We would like to automate this process.” It is one of the most common sentences in our first conversations — and one of the riskiest. Because the most honest answer is usually: “First it has to actually be a process.” What everyday speech calls a process is often a collection of individual routines that different people perform in different ways — some consciously, some by habit, some from necessity.
The difference that changes everything
Standardisation is the prerequisite for automation. A task that is done today by four people in four different ways cannot be automated — it has to first be brought into an agreed form. That is not bureaucracy, but clarity. Once it is clear how a task should look, an AI can stick to it. If it is not, the AI will pick one of the four variants — probably not the best one.
Standardisation is also not the opposite of flexibility. On the contrary: it makes flexibility affordable. In a standardised process, an exception can be treated as an exception — it stands out because it deviates from the pattern. In an unstandardised process, every case is an exception, and no one can see any more what is actually unusual.
How much standardisation is really needed
There is a widespread fear that standardisation leads to bureaucracy — to rules that nobody understands any more. That fear is legitimate, but it mistakes means for ends. A good standard describes the essentials of a process:
- Who triggers it?
- What inputs are expected?
- Which steps are taken in which order?
- Which decisions are possible?
- What outcome is acceptable?
Nothing more. Anything beyond that — internal sequence of processing, tools, individual notes — stays with the person doing the work. Standardisation sets the guardrails, not the steps.
Where standardisation fails
Standardisation fails where it is pursued as an end in itself — when the standard is the goal and not the better process. Three typical traps:
- Standardisation without rationale. When staff do not understand why a rule applies, they do not follow it. The standard exists on paper, not in practice.
- Standardisation from above. When standards are designed by people who have never performed the process themselves, the most important edge cases are usually missing. The standard is clean but unusable.
- Standardisation without care. When a standard is never reviewed after introduction, it ages. Within months, practice drifts away and nobody corrects either side — neither the standard nor the practice.
The pragmatic path
In our practice, a way of working that develops standardisation and automation together — not sequentially — has proven itself:
- As-is observation. How is the process actually done today — not according to the handbook, but in practice? Three to five observation sessions with the people doing it.
- To-be definition. What form should the process take? What stays, what goes, what is added? The process owners make this decision, not external consultants.
- AI-ready cut. At which point in the to-be process can AI sensibly contribute? Pre-classification, pre-filling, summarisation — the interface is chosen deliberately.
- Pilot operation. Four to eight weeks of live operation with human-in-the-loop. Measure what works and what does not.
- Adjust. Standard refined, AI refined — both are allowed to change.
- Rollout. Only once the pilot runs stably.
This way avoids the two most common mistakes: automating a bad process — and crushing a good process under excessive standardisation.
What becomes measurable in the end
Standardised and AI-supported processes have a side effect that is often underestimated: they make the company measurable. When a process is clearly defined and AI takes over parts of it, throughput times, error rates and effort per case can be reliably captured. That is the prerequisite for any serious management — and it emerges almost as a by-product if both sides are done properly.
Standard and automation are not bureaucratic duty. They are the foundation that lets a company become better over time, instead of merely larger.