Automation is the wrong starting point

Most efficiency projects begin with the same question: what can we automate? It is a reasonable question to ask eventually, but it is the wrong place to start. Automation applied to a broken process does not fix the process. It runs it faster, and the flaws get harder to see once a system is doing the work.

The point is not new. “The first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will magnify the inefficiency.”¹ That was Bill Gates writing decades before RPA, workflow tools, or AI agents existed. The principle has aged well, even if it gets routinely ignored when the next vendor presentation arrives.

The RPA wave of the late 2010s ran this experiment once already. Ernst & Young put the failure rate for initial RPA projects at 30 to 50%.² PwC found that proofs of concept routinely took four to six months instead of the four to six weeks originally promised.³ The pattern is consistent enough to be diagnostic: companies bolt automation onto processes they have not simplified, and the automation inherits every flaw the process had.

Below are three failure modes we see repeatedly.

1. Automating the workaround

Most processes were not designed. They accumulated. A step was added in 2014 to satisfy an auditor. A second approval was inserted in 2017 after one bad incident. A spreadsheet sits in the middle of the workflow because the ERP could not do what somebody needed in 2019, and the spreadsheet became permanent.

When automation arrives, all of this gets encoded. The software performs the workaround forever, and the workaround is now invisible because no human has to do it anymore. The cost has not disappeared, only moved. HfS Research has found that RPA maintenance consumes 70 to 75% of total budgets over time.⁴

2. Speeding up the wrong thing

A purchase order process takes eleven days. Two of them are the actual processing, nine are waiting time for an approval nobody has questioned in years. Automate the processing end-to-end and the process then takes nine days. The bottleneck was never the processing, and nothing about it has changed.

The question that comes before automating any step is whether it needs to exist at all. The lean tradition has a clear sequence for this: eliminate, simplify, standardize, automate. Each step applies only to what survived the one before it. A 2025 simulation study in Engineering Reports confirmed quantitatively what practitioners have argued for years, showing that applying lean tools before automation produces significantly higher productivity gains than automation alone.⁵

3. Automating variance

Most companies underestimate how much their processes differ between sites, teams, and individuals. The accounts payable team in Düsseldorf does not handle invoices the same way as the team in Stuttgart. Both believe they are following the process, and in a sense both are right, because no single process has actually been agreed.

Automation cannot reconcile this. It picks one version and imposes it on everyone, or it tries to handle every variant at once and becomes unmaintainable within a year. Deloitte’s survey of 479 executives across 35 countries found the three biggest barriers to end-to-end automation to be integrating various solutions (62%), lack of skills and experience (55%), and inability to change business processes or ways of working (52%).⁶ The third number is the telling one, because it identifies behavior change as the bottleneck rather than technology. The software can be installed in weeks. Getting people to work the same way takes considerably longer, and most automation projects never finish that part.

Taiichi Ohno, the architect of the Toyota Production System, made the point seventy years ago: where there is no standard, there can be no kaizen. The same applies to automation.

What the sequence should look like

A serious efficiency project starts with the process, not the tool. Before any software is bought or any process automated, four questions need clear answers.

Which steps in this process exist for a reason that still applies today? Which steps can be eliminated entirely? Of the steps that remain, are they performed the same way by everyone who does them? And only then: which of the simplified, standardized steps are worth automating?

This sequence is the right one, and it is slow. It also produces more durable gains than buying another platform. The companies that get real value out of automation are not the ones that automate the most. They are the ones that did the right upstream work before any of the software arrived.