The process you are automating may not deserve to survive

Automation is usually framed as an efficiency exercise: here is a process people perform manually, here is the same process performed by software, here is the time saved. The framing is accurate and incomplete, because it treats the process itself as given.

Many processes in a large organisation are not designs. They are accumulations — a control added after an incident in 2014, an approval introduced because one manager wanted visibility, a reconciliation step that exists because two systems disagreed and nobody fixed the underlying cause. Automating that is not efficiency. It is preservation.

Why automation makes things permanent

A manual process is continuously questioned, because someone performs it and finds it tedious. That irritation is a useful signal, and it is the mechanism by which bad processes eventually get killed.

Automate it and the signal disappears. The process now runs invisibly, costs nothing per execution, and has an implementation someone was paid to build. Nobody proposes removing it, because nobody experiences it. Ten years later it is still running, and the incident it was designed to prevent has been impossible since the system it referred to was decommissioned.

Questions to ask before automating

• Why does this step exist? If nobody can answer, that is the finding, and it is worth more than the automation.
• What would happen if we simply stopped? Frequently the honest answer is nothing, and it is cheaper to test that than to build.
• Is this step compensating for a defect elsewhere? Reconciliation, re-entry and verification steps usually indicate a problem upstream that automation will now make permanent.
• Who benefits from this control, and are they still here? Processes often outlive the concern that created them.
• Would we design this today, knowing what we now know? A process that would not survive a blank-page review does not become better by running faster.

The stronger version of the exercise

The most valuable automation projects tend to begin as elimination projects. Map the process honestly, including the parts people are slightly embarrassed by. Remove what has no defensible purpose. Fix the upstream causes of the compensating steps. Then automate what remains, which is usually a fraction of what you started with and considerably simpler to build.

This is harder to sell, because removing a step produces no artefact and no demonstration. It is also where most of the value is. Automating a bad process yields a fast bad process, delivered with confidence, and roughly a decade before anyone is willing to look at it again.