Why operational automation stalls six months after launch

The launch is not the finish

An automation is commissioned against the operation as it stood on the day it was specified. That operation then keeps moving. New suppliers, a new field on the form, a policy that changed in one team and not the other, and none of it arrives as a ticket.

The code is unchanged and still correct against a description of the business that has quietly expired. That is what stalling looks like from the inside: nothing broke, and the output stopped being right.

Rules age faster than code

The parts of a system that go stale first are the ones written as thresholds and mappings — the list of statuses that count as closed, the amount above which a human signs off, the mapping from a supplier name to an account.

Those were decisions, not logic, and they were true for a quarter. Held in the same file as the logic that uses them, they are revisited only when somebody is already deep in the code, which is the least likely moment to question them.

Silence is not success

A process that never raises an exception is not a process that has none. It is one that has stopped noticing them.

Most operational automation is measured by whether it ran. It ran, so the dashboard is green, and the cases it forced into the nearest available category look exactly like the ones it got right.

Watch the inputs, not the model

The earliest signal of drift is in the data arriving, not in the decisions leaving. Before the output goes wrong the input has already changed shape:

• a field that starts arriving empty
• a category that stops appearing
• a volume that doubles on one route
• a free-text box doing a new job

Each is cheap to watch and none of it requires understanding the model. A weekly comparison against the month the system was accepted catches most of what a customer would otherwise find first.

Give exceptions somewhere to go

When an automation cannot decide, the useful behaviour is to say so and hand the case on with the reason attached. Given nowhere to hand it, the system will guess, and a guess recorded as a decision is worse than no automation.

A drift check is two queries

It does not need a platform. A scheduled job that counts what came in and how it was disposed of, held against the accepted baseline, makes drift visible while it is still an edit rather than a project.

rows = fetch(last_7_days)
compare(rows, accepted_baseline)

Who owns it after handover

Automation that nobody owns degrades on a predictable schedule. Ownership here is not a maintenance contract. It is a named person who is told when a threshold is about to be wrong, and who may change it without opening a project.

What ages well

The systems still right after a year are the ones built to be argued with: rules held as data, inputs watched as routine, and an exception path a person actually reads.

None of that is sophisticated. It is the difference between software that was delivered and software that is still in service.