Automating a broken process just makes it fail faster

Automation does not improve a process. It amplifies it.

Point it at a step that works and you get more of what works. Point it at a step that leaks, and the leak arrives faster, more consistently, and with the authority of a system behind it. The mistakes are the same mistakes. They just scale.

This is the least fashionable thing to say about operational technology and the most reliably true. It is also, in my experience, the reason so many automation programmes are described afterwards as both successful and disappointing.

The mistaken diagnosis

When a firm decides its operations are slow, the instinct is to treat speed as the problem and automation as the answer. The invoice takes eleven days to go out, so automate the invoice. Timesheets arrive late, so automate the reminder.

That reading confuses throughput with design. The invoice does not take eleven days because a human is slow at pressing buttons. It takes eleven days because the billing rules were never agreed, so somebody has to establish what is billable before anything can be generated.

Automate that and you have not removed the eleven days. You have removed the two minutes of button-pressing and kept the ten and a half days of reconstruction, and now the reconstruction happens under time pressure because the system is waiting.

The scale of the underlying drag is not small. Forrester Consulting, in a 2022 study commissioned by Airtable, found respondents “spend 30% of their week (2.4 hours daily) trying to find the right data and information to do their jobs“. That time is not a speed problem. It is a structure problem wearing a speed problem’s clothes.

Design the process, then automate it

The sequence that works is unglamorous and it is four steps.

Standardise. One way to scope, one way to approve, one way to capture time, one way to bill. Not because variety is sinful, but because you cannot automate a step that is performed five different ways by five different teams — you can only automate one of the five and leave the others stranded.

Structure. Decide what the shared data model is from prospect to payment, and which record is authoritative for each fact. Automation moves data between steps; if the steps disagree about what a project is, the automation will faithfully move the disagreement.

Consolidate. Fewer places where the same fact is stored. Every duplicate is a future reconciliation, and reconciliation is the work automation is usually bought to remove.

Clarify. Named owners, explicit rules, and a definition of done for each gate. Ambiguity that a person quietly resolves becomes an exception queue the moment a system has to resolve it.

Only then does automation earn its keep, because at that point what is being amplified is a process somebody designed on purpose. Where these gates sit in practice is set out on our delivery and time capture page.

The same argument applied to implementation

There is a second version of this failure, and it happens during the rollout rather than after it.

Most implementations go wrong in one of two directions. Either the business is bent to fit the tool, and people quietly stop using it for the parts of the job that matter. Or the tool is bent to fit the business with heavy custom code, and the firm acquires a maintenance liability it will carry for a decade.

Both are versions of refusing to decide what is genuinely distinctive about how the firm works. Standardise what is not special. Protect what is.

The evidence on the second path is worth knowing. A 2021 study in Applied Sciences surveying 244 SaaS professionals found that configuration and composition approaches have positive impacts on SaaS quality, while the impacts of the other customisation approaches are negative. That is a perception survey rather than a cost model, so treat it as directional — but the direction is consistent with what implementation teams see: configuration preserves the upgrade path, code consumes it.

The base rate is sobering too. McKinsey’s 2018 global survey reported that only 16 percent of respondents say their organizations’ digital transformations have successfully improved performance and also equipped them to sustain changes in the long term. It is an eight-year-old figure and should be read as one, but nothing since has suggested the number is comfortable.

What the mess actually costs

The cost of automating a bad process is not only wasted licence spend. It is that the bad process becomes harder to see and harder to change, because it is now encoded.

A manual workaround is visible. Somebody performs it, complains about it, and can describe it. The same workaround, automated, disappears into a rule nobody has read since the implementation, and the firm loses the ability to notice that it is wrong.

Data quality compounds the same way. Gartner, in 2021, put the figure at an average of USD 12.9 million a year lost to poor data quality across organisations — a mid-market services firm is nowhere near that scale, but the mechanism is identical and the proportion is not obviously kinder.

This is the discipline I came from. Before software, my work was value-stream mapping and process redesign — lean six sigma, applied to firms that had already bought the tools and still could not get the invoice out. The tooling was rarely the constraint.

Where this argument breaks

Redesigning before automating is the slower path, and slower is not always right.

If a firm is bleeding cash on one specific, well-understood step — a manual export that takes a day a week and is otherwise correct — automating the imperfect version now and fixing the design later is a defensible commercial call. The principle is a default, not a law, and treating it as a law is how process people become the reason nothing ships.

Configuration-first has a limit too. At some point, refusing to customise means refusing to support the thing the firm actually wins work on. A platform that cannot be extended to hold your one genuinely distinctive commercial model is not disciplined, it is inflexible, and the honest answer is to build that piece properly and give it an owner and a lifecycle plan.

Amplify what works

The test before automating any step is a single question: if this ran ten times faster and ten times more consistently, would that be better or merely louder.

Where the answer is louder, the work is upstream — in the rules, the records and the gates — and the automation should wait. Our quickstart page sets out the sequence we use to establish that spine before anything is switched on.