Automating a broken process just makes it fail faster

There is a particular kind of disappointment that follows an automation project. The tool works exactly as specified. The team was trained. And six months later the operation feels no easier to run. Usually the reason is straightforward: the process that was automated should not have existed in that shape to begin with.

Operational processes accumulate. A step gets added because of one bad experience with one customer in 2019. A second approval appears because someone left the business and nobody trusted the replacement yet. A spreadsheet gets introduced as a temporary measure and becomes permanent. None of these decisions were wrong at the time. Together they produce a workflow that no one would design deliberately.

Four questions worth asking first

Before automating any process, it is worth spending an hour on the following. The answers tend to be more useful than the automation itself.

1. Why does this step exist? If the answer is that it has always been done this way, or that it was added after a specific incident, ask whether the underlying risk still exists.
2. What happens if it is skipped? Some steps have real consequences. Others have been protected by habit long after the consequence disappeared.
3. Who is waiting during this step? A step that takes two minutes of work but sits in a queue for two days is a queueing problem, not a speed problem. Automating the two minutes will not help.
4. What information is being re-entered? Every point where a person copies data between systems is both a delay and a source of error. These are usually the highest-value targets.

Sequence matters more than tooling

The order we work in is deliberate: understand how the process runs today, map it honestly, decide what should change, design the target state, and only then choose the implementation. Choosing the tool first inverts that sequence, and the tool ends up defining the process by default.

The question is not which automation you want. It is how the process works today, where it breaks down, and what a better version would look like.

The evidence is not encouraging

You may have seen the claim that 70% of digital transformations fail. It is worth knowing that the figure is routinely misattributed. McKinsey’s own 2018 survey of 1,793 participants did not measure it that way. What it did find is that fewer than 30% of transformation efforts succeed, and that only 16% of respondents said their digital transformation both improved performance and equipped the organisation to sustain that improvement. Even in high tech, media and telecom, success rates did not exceed 26%.

The gap between "improved performance" and "sustained the improvement" is the interesting part. Plenty of projects produce a short-term gain and then decay, because the underlying process was never redesigned, only automated.

The uncomfortable finding

Sometimes the honest recommendation is that no software is required. A process can be redesigned, a decision right can be delegated, a step can be removed, and the problem disappears without anyone buying anything. Those recommendations are less exciting than a build project. They are also frequently the highest-return change available.

This is why the diagnosis has to come before the proposal. If the assessment can only conclude that you need what the firm happens to sell, it was not really an assessment.