Automating a bad process only makes it faster
- 1Automation freezes workarounds and exceptions into code, and makes the process more expensive to correct later.
- 2In a typical worked example, simplifying upstream removes more effort than automating data entry alone.
- 3Four questions qualify a process before any tool is chosen: customer, value, exceptions, owner.
- 4A stable, high-volume process with clear rules and reliable data can be automated without delay.
Speed amplifies defects
In a company of 50 to 500 people, the scenario is familiar. A process wastes time: order handling, supplier invoices, service requests. A vendor presents a tool, a software robot, a workflow engine or, more recently, an AI agent. The budget is found and the project starts. Six months later the process runs faster, yet the delays, disputes and re-keying have not gone away. They have simply become more numerous and harder to locate.
Our view is straightforward: automation is a multiplier. It multiplies whatever exists, including unnecessary steps, redundant controls and rules nobody can justify any more. Before asking which tool to choose, ask what you are about to multiply.
What automation freezes in place
Workarounds become rules
In a manual process, people compensate. An assistant knows to call a certain customer before approving an order; an accountant knows that a given supplier always sends invoices without a purchase order number. None of this is written down. When the process is automated, either these adjustments are forgotten and the process fails, or they are coded as they are, and a local workaround becomes a permanent system rule.
The error moves, it does not disappear
If 20% of files arrive incomplete, automating data entry does not fix the problem. It moves it into an exception queue, handled by the same people as before, with less context. The gain reported on the standard case hides a growing cost on the atypical one.
The process becomes harder to change
A manual process can be corrected in a single conversation. An automated one requires a change request, testing, sometimes an external provider. The earlier an imperfect process is automated, the more expensive its future improvement becomes. This lock-in effect is almost never captured in project budgets.
A worked example
Consider an illustrative case, with explicit assumptions rather than measurements. A mid-sized company processes 600 supplier invoices per month. Average handling time is 12 minutes per invoice: 4 minutes of data entry and 8 minutes of searching for information, internal chasing and successive approvals. That amounts to 120 hours per month. About one invoice in four is blocked for lack of a purchase order number or an identified approver, and four approval levels apply regardless of amount.
First scenario: automate data entry with document capture. At best, the 4 minutes of entry disappear, or 40 hours per month. The remaining 80 hours of chasing and approvals are untouched. The quarter of blocked invoices is still blocked, but they now pile up faster.
Second scenario: before any tool, require a purchase order number at the time of purchase, cut approvals from four levels to two, or even one below a set amount with automatic matching to the order. If the 8 minutes fall to 3, the saving is 5 minutes per invoice, or 50 hours per month, with no software at all. Automated capture then runs on a clean flow, and the total approaches 15 to 20 hours of real work, the rest being exception-based control.
Exact figures will differ from one company to another. The order of magnitude is robust, though: lost time usually sits in waiting and coordination rather than in the task itself. We explore this in our analysis of support functions and where the lost hours hide. For the implementation once the flow is clean, our use case on automating invoice processing describes the approach.
Four questions before choosing the tool
We put these to the team that owns the process before any technology discussion.
Who is the customer and what do they expect? A process with no clear recipient accumulates steps nobody challenges. If you do not know who benefits from each deliverable, you do not know what can be removed.
Which steps create value? Separate what transforms the file, what checks it and what makes it wait. In most administrative processes, waiting dominates by a wide margin.
Where do exceptions come from? A high exception rate nearly always has an upstream cause: a poorly designed form, incomplete reference data, an ambiguous commercial rule. Fixing the cause costs less than automating the handling.
Who owns the process end to end? Many processes cross three departments, none of which answers for the final result. Without an owner, automation optimizes one segment and degrades the rest.
When to automate without waiting
Our position is not hostile to automation. A stable, high-volume process with written rules and reliable data is a good candidate right away. Optimizing field technician routes is one example: the problem is well posed, mathematically defined, and the gain comes directly from the calculation. Even there, the quality of addresses, intervention durations and declared skills determines the outcome. A powerful algorithm fed approximate data produces schedules that are precise and wrong.
The same applies to AI agents. They are attractive because they absorb exceptions that classic automation rejects. But an agent handling cases for which nobody has defined the right outcome merely generalizes uncertainty. We discussed the promises and first realities in our article on AI agents in operations.
One last point, often overlooked: automating also means making repeated decisions with data, sometimes personal data. The Swiss revised FADP, in force since 1 September 2023, and the EU AI Act, in force since 1 August 2024 with phased application, both require organizations to know what a system does and why. A poorly understood process is hard to document. This falls under our Data, AI & compliance expertise, and it is better addressed at design stage than at the end of a project.
What we recommend to leaders
First, impose a sequence: understand, simplify, stabilize, then automate. It looks slower, but it avoids the cost of reworking a tool built on an unstable process. One to three weeks of serious analysis is often enough to decide.
Second, measure before and after with simple indicators: end-to-end lead time, the share of files handled without intervention, and time spent on exceptions. Data entry time alone is misleading.
Third, name a process owner with the authority to remove steps. Without one, the tool will be the only lever available, and it will be used even when it is the wrong one.
Fourth, reserve AI for places where it brings something simplification cannot, such as reading unstructured documents or forecasting. Elsewhere, common sense and organization do better and cost less. Our approach to operations and processes follows this logic: strategy, then deployment, then steering results, with technology in a supporting role.
If you are unsure about an automation project under way or planned, a few days of outside perspective are often enough to separate what should be simplified from what should be equipped. Our diagnostic is designed for exactly that.
A personalised first reading in three minutes.