Why automating a broken process makes it worse

What does automation actually do to a process?

It multiplies. Whatever the process produces, automation produces more of, faster, with less variation. When the process is sound, that is the point. When it is broken, you have scaled the fault.

This is not a new lesson. Michael Hammer's 1990 Harvard Business Review article was titled "Reengineering Work: Don't Automate, Obliterate", and it described companies using technology to speed up work that should not have existed. Thirty-five years later the technology is better and the mistake is the same. The instinct is to point AI at the step where the effort is most visible. The map usually shows the effort is a symptom of something upstream.

How do you know a process is broken?

Some of these will sound familiar. Three or more means fix before you automate.

• Nobody can describe the process end to end. Each person knows their own step.
• Information is re-keyed from one system into another.
• The customer is asked for the same thing twice.
• Exceptions are handled from memory, by the person who has been there longest.
• There is a queue at a handoff, and the queue is treated as normal.
• Quality depends on who is on shift.
• There is a spreadsheet nobody admits to.
• The process owner is a box on a chart, not a person who can change it.

What goes wrong when you automate it anyway?

• Errors scale. A mistake at step three used to be caught by the person at step five who noticed something odd. Automated, step five is a rule, the mistake passes it, and so do the next five hundred.
• Workarounds become requirements. The build team documents what people do now, including the parts that exist only to cope with an upstream failure. You pay to build the problem in.
• Knowledge leaves. The people who knew why a step existed move on. In two years nobody remembers the exception rule was a workaround, and nobody dares remove it.
• Cost moves instead of disappearing. Fewer people keying data, more people fixing what the automation produced, plus a licence fee. The business case assumed the first and not the second.
• Visibility drops. People complain about a broken step. Software does not. A fault that used to generate grumbling in the team generates a quiet error log that nobody reads.
• Governance gets harder. You now have a system making or shaping decisions about people, built around a process nobody mapped. From 10 December 2026 thePrivacy Act's automated decision rules may require you to disclose it, and you will struggle to describe what it does.

What did this look like inside a bank?

In a home loan operation inside a major Australian bank, the obvious target was the checking of documents. That was where the visible effort sat and where the automation vendors were pointing. Mapping the process with the people doing it told a different story. A large share of the team's time went on chasing information that should have been captured when the application came in, re-keying it between systems, and reworking files that bounced back from a later check.

Automating the checking step would have made files bounce faster. So the work started upstream: capture the right information once, remove the double entry, and agree what a complete file is so that the rule is the same whoever is on shift. Only then was automation applied to the steps that remained. Processing ended up around 50% more efficient, and the largest gains came from steps that were deleted, not automated.

What should you do instead?

1. 1Remove the steps, handoffs and rework that should not exist. For every step ask what breaks if you skip it. If the honest answer is nothing, stop doing it. Ask the same of every approval and every copy of the same information.
2. 2Consolidate duplicate tools and double entry. One place for each fact. If a customer’s details live in three systems, decide which one is true and make the others read from it, or retire them.
3. 3Decide who owns the outcome, and where a person must approve. One business owner with the authority to change the process. Named points where a person reviews the work. Agree the number the process must move and record today’s baseline.
4. 4Then automate what is left, and measure it. With fewer steps and clear rules, the build is smaller, the testing is shorter and the result is easier to prove. If the number does not move, you find out early.

Is it ever right to automate first?

Yes, in two cases.

The first is a process that is already stable, owned and measured, where the only thing wrong is that it is slow. There is nothing to fix, so automate it and watch the number.

The second is when a small piece of automation is the way to make the process visible. A simple intake form that logs every request tells you volumes and wait times you could not see before. That is fine as long as it is cheap and reversible. The test is whether you could switch it off tomorrow without harm. If you could, go ahead. If switching it off would break something, you are building on the process, and the process needs to be right first.

Frequently asked questions