Automate without automating chaos: a five-step method

A muddled process does not become clear once it is automated: it becomes muddled faster, and harder to fix. The idea is not new, but AI tools, which promise to automate tasks once reserved for people, have made it topical again. Here is a simple method for avoiding the trap, illustrated with a generic example.

A lesson more than thirty years old

In the July-August 1990 issue of Harvard Business Review, Michael Hammer published an article with a deliberately provocative title: “Reengineering Work: Don’t Automate, Obliterate”. His argument was that companies spend fortunes on information technology to speed up processes designed before computers existed, instead of asking whether those steps still serve any purpose. He captured the mistake in a memorable image: paving the cow paths.

His best-known example concerned Ford’s accounts payable department in North America, which employed more than 500 people. Ford initially aimed to cut headcount by about 20% through new systems, until it noticed that Mazda ran the same function with five people. Rather than automate the matching of purchase order, receiving document and invoice, Ford redesigned the process: goods received were checked directly against the order held in a database, and payment followed without waiting for an invoice. Where the new process was introduced, headcount fell by 75%.

Reengineering later had its excesses. It was often used as cover for mass redundancies, and Hammer himself admitted he had underestimated the human dimension. But the central principle still holds: rethink before you automate.

Step 1: map the real process

Before choosing any tool, describe the process as it actually runs, not as the manual says it should. Who does what, in what order, with what information, and where are the queues, the re-keying and the exceptions? An honest map often reveals steps that exist only to make up for a flaw further upstream. Those are the steps to remove, not to automate.

Step 2: choose the right first use cases

Not every process lends itself equally to automation. Three criteria help with a first cut:

• frequency: a task repeated hundreds of times a month repays the effort, an annual one rarely does;
• stable rules: if decisions follow clear rules that seldom change, automation is robust; if every case is an exception, it will be fragile;
• available data: a tool can only handle what exists in a usable and reliable form.

It is wise to start with a modest, visible case that meets all three tests, rather than with the most painful but most complex process.

Step 3: measure before and after

Without a baseline, there is no way of knowing whether automation has delivered anything. A handful of indicators is enough: processing time, cost per item, error rate, and the share of cases handled with no manual intervention. A temporary dip should also be expected. The economists Brynjolfsson, Rock and Syverson have described a productivity “J-curve”: general-purpose technologies first require intangible investment (reorganisation, training, data) that weighs on results before the benefits appear.

Example: processing supplier invoices

Take, purely as an illustration, a small business receiving 400 supplier invoices a month by post and email. Each invoice is keyed in by hand, emailed to a manager for approval, then paid.

The process map shows that delays do not come from data entry but from approvals: invoices sit in inboxes, and a third of them match no recorded purchase order. Automating data entry, for instance with an AI extraction tool, would save the accounts team time, but the invoices would still be waiting.

The logical sequence would rather be: make purchase orders mandatory above a set amount, define clear approval thresholds, and only then automate reading and matching. In Switzerland, the QR-bill, introduced on 30 June 2020 and the only format in use since the old payment slips were withdrawn on 30 September 2022, makes extracting structured data considerably easier. Invoices that fit no rule are still handled by a person.

Step 4: govern and maintain

Automation is not a project that ends; it is a system that needs looking after. It requires a named owner, documented rules, error monitoring and a procedure for cases the tool cannot handle. Suppliers change formats, tax rules evolve, AI models are updated: without maintenance, reliability erodes quietly.

Step 5: train the people involved

Finally, automation changes the work of those who used to run the process. They are often best placed to spot exceptions and drift. Training them to understand the tool, check its output and report its errors is not an extra but a condition of success. The excesses of 1990s reengineering are a reminder of the cost of treating people as an adjustment variable.

Our view: in many AI projects, the value comes less from the tool itself than from the clarification work it forces an organisation to do.

Key takeaways

Automating a poorly designed process simply speeds up its flaws, as Michael Hammer was already pointing out in 1990. A sound approach starts with an honest process map, then targets frequent cases with stable rules and available data. Measuring before and after, while accepting an initial dip, allows a judgement based on evidence. Governance and staff training make the difference between lasting automation and a system that quietly degrades.