What automating a process actually freezes

Every automation business case you have read was costed in hours. None of them was costed in permanence, and permanence is the half you keep.

If a proposal lands on your desk this quarter and the whole argument is a time saving, there is one question that belongs beside it, and answering it takes about four minutes.

What the sign-off actually changes

At the moment, the process sits in people's hands. Anybody near enough to spot what is wrong with it can fix it that afternoon by telling two colleagues. There is no form to raise and no queue to join.

Afterwards it owns a budget line, a named owner, a dashboard, a runbook for the day it breaks, and a small crowd of downstream things that consume its output and would fall over if its shape changed. The work happening is identical either way. What has moved is the price of changing your mind about it, and that price went from a conversation to a project.

The thing that gets settled while everyone discusses mud

Picture the footpath people have worn into the grass between two office blocks.

That path is doing two jobs and only one of them ever comes up. Everybody talks about the walk itself. Nobody mentions that the route is free to move, which it is, because people simply walk towards whichever door they need. Open a new entrance and within a fortnight the grass has a new line worn into it.

Then the path gets paved.

Paving it is not a mistake. Paved is genuinely better: no mud, no ruined shoes, and lighting becomes possible. What the concrete also does, silently, is declare that the route is finished. After that morning the walk is fixed where it happened to be, and shifting it has become somebody's capital project.

None of that came up in the meeting, because the meeting was about mud.

Automation does the same thing to a process. You are buying the speed, and you are also announcing that this particular version of the process is the one worth setting in concrete. That announcement usually gets made by people looking at a figure for hours saved.

The question, and what each answer tells you

The useful question is not whether the thing can be automated. It nearly always can, and the tooling has made starting cheap enough to do on a whim.

How many times has this process changed in the past year, and who changed it?

You will get one of three replies.

It has not changed. Good, because the process has settled, and the rigidity you are about to buy is the feature rather than the bill.

It changed a few times, and each time somebody near the work just started doing it their way. That is an unfinished argument, and automating it does not end the argument. It freezes whoever happened to be ahead this month, and stakes a migration cost behind them.

Nobody can say. This is the most valuable reply of the three, because it means the process has been running somewhere unobserved, and the first thing automation will do is make it official.

Where the standard advice runs out

You will have seen the line about not automating a bad workflow. It is sound, and I would not argue against it.

Notice what it says the damage is, though: a build you wasted. That is true and it is the cheaper half. A clumsy process performed by hand stays irritating and stays fixable. Automate the same clumsy process and it is irritating, fixable in theory, and every improvement now arrives behind a migration. You can recover a wasted build. The rigidity is what remains.

Rigidity is not the villain here

Plenty of processes ought to be held still, and holding them still is the whole reason to automate them. Nobody wants payroll drifting because a colleague found one step awkward on a Tuesday. A quarterly filing that looks different every quarter is a finding in itself. Where sameness is the actual product, permanence is exactly what you are paying for, and paying for it knowingly is a good decision.

So the failure is never picking permanence. It is picking it by accident, on the evidence of a slide about hours.

And here is what the question cannot do for you: it will not tell you whether to automate. It tells you what you are about to make permanent, which is a smaller claim, and it is the one nobody in that room currently holds.

Before you sign

Write out the last three occasions it changed: who, what and why. If that comes easily, you know precisely what you are setting, and you can set it deliberately. If you cannot manage one, you have turned up something worth more than an automation candidate.

It is three columns and four rows, and the row about what changing it would cost afterwards takes most of the page, which is where the real argument lives. The page itself is here, carrying blanks rather than worked examples, because a number sitting in a template is a number somebody inherits.