The arithmetic of automation: a cost model for energy metering

The question is never whether something is worth doing in the abstract. It's whether it's worth doing at your volume, with your failure rate, valuing your team's time properly. So let's do the sum.

Whether something's worth automating is a sum, and the sum is usually not close once you do it honestly. The mistake is doing it on the happy path and ignoring the ongoing cost of the exceptions.

THE TERMS PEOPLE LEAVE OUT

The build cost gets estimated. What gets missed is the exception handling, which is most of the code, and the ongoing maintenance as the surrounding systems change underneath you. An integration is not a one-off cost, it's a subscription.

The other omission is the cost of automation being wrong at volume. A person processing a hundred items makes a handful of individual errors. A rule processing a hundred thousand makes the same error a hundred thousand times, and the cleanup is a project.

PARTIAL AUTOMATION IS USUALLY THE ANSWER

Handling the eighty percent that's unambiguous and routing the rest to a person is often several times better value than chasing full coverage. The last twenty percent contains all the ambiguity, so it's most of the work and most of the risk.

It's a harder thing to sell, because "we automated eighty percent" sounds like a partial success. It's usually the whole win, and the remaining twenty percent is where people should be spending their attention anyway.

At several million reads a day with a two percent exception rate, settlement analysts were absorbing about nine hours of manual reconciliation a week. That's the number the build had to beat, and it's a lower bar than anyone in the room expected.

THE NUMBER THAT ACTUALLY MATTERS

Hours saved is the metric everyone reaches for and it's rarely the one that justifies the work. More often it's a reduction in variance: fewer things going wrong, fewer statutory deadlines missed, fewer disputes. That's the number to put in the business case.

Ask what happens today when it goes wrong, and how often. Frequency times consequence is usually a bigger number than the labour saving, and unlike the labour saving it's a number the client already believes.

The interesting term wasn't engineering time. It was the cost of a timezone change silently duplicated an hour of consumption landing once in the wrong quarter, which the client could size to the pound and we couldn't size at all.

WHERE IT GOES WRONG

• Treating an integration as a one-off build rather than an ongoing subscription.
• Chasing the last twenty percent, which holds all the ambiguity and most of the risk.
• Justifying the work on hours saved, when the real return is fewer things going wrong.
• Costing the happy path, when exception handling is most of the code.

Do the sum with exceptions included. Then automate the eighty percent and route the rest.

WHERE THE MODEL BREAKS

Do the numbers before the meeting, not during it. A decision that survives arithmetic tends to survive the next reorg too, because the reasoning outlives the people who made it.