Don't automate what you haven't understood

Most automation projects begin with a decision to automate and work backwards to a justification. The sequence sounds harmless and it produces a specific, recognisable failure: a system that faithfully reproduces a process nobody examined, including the parts that should not have existed.

The reproduction problem

Manual processes accumulate steps. A check gets added after something went wrong in 2019. An approval exists because a person who left in 2021 wanted visibility. A field is filled in because a report that no longer runs once needed it.

None of this is documented as history, so when the process is automated it is automated as found. The result is faster, which is presented as success, and it is faster at doing things that had stopped being necessary years ago.

The cheapest improvement available in most operational processes is not automation. It is deletion. That option is only visible if somebody examines the process before building anything.

Six questions before any build

What is actually happening? Not what the process document says — what the two people who do it every day actually do, including the workarounds.

How often does it happen? A weekly irritation and a two-hundred-times-a-day bottleneck need entirely different responses, and people reliably misremember which one they have.

What does it cost at that frequency? Time multiplied by frequency multiplied by the cost of the person doing it, plus the cost of the errors it produces. If this cannot be estimated even approximately, there is no business case yet.

Why is it happening? Which control or system is missing? A manual reconciliation usually exists because two systems disagree, and automating the reconciliation preserves the disagreement forever.

Can it be fixed without building anything? A configuration change, a different report, a rule at data entry, or removing a step. This question is skipped most often and has a yes most often.

Should it be automated, or should it stay with a person? Some work is repetitive and mechanical. Some looks repetitive and is actually judgement wearing a uniform.

The uncomfortable consequence

Asking these questions properly means sometimes concluding there is no project. A vendor whose revenue depends on building has a structural incentive not to reach that conclusion, which is worth keeping in mind when evaluating anyone's proposal, including ours.

The honest version of this is to charge for the discovery separately, so the answer “do not build this” is not a decision to forgo revenue. That is the only arrangement in which the advice can be trusted, and it is why we treat the assessment as a deliverable in its own right rather than as unpaid pre-sales work.

What this looks like in practice

A week spent sitting with the people who do the work, counting what actually happens, and writing down what it costs. Then a decision, made against a number rather than an impression.

It is slower to start and considerably faster to finish, because the thing that gets built is the thing that was needed.