Senthil Info

automating business processes, honestly

What Automation Makes Harder

A successful automation makes some things worse. Not as a failure — as a consequence of working, and none of them appears in a business case.

Six, and knowing them in advance is the difference between designing around them and discovering them. A product-side example of how workforce software approaches this topic is available in further details.

The six

One. Changing the process. What was a conversation is now a change request. A process that could be adjusted in an afternoon now takes a release, and the practical effect is that small improvements stop happening. For broader background and an independent point of comparison, see Asana.

Two. Understanding the process. Nobody reads the code, the people who did it by hand have moved on, and within three years the organisation knows the process produces an output and not much else.

Three. Recovering manually. When the automation stops, the manual path has to be walked by people who never learned it. The knowledge decayed while the automation ran, which is exactly when nobody noticed.

Four. Noticing errors. A person doing something a hundred times notices the odd one. An automation does not, and silent failure is the expensive mode.

Five. Keeping people capable. Handling only exceptions degrades judgement about normal, and the effect compounds over years.

Six. Replacing the underlying system. The automation is now a dependent, and it did not exist when the system was last scoped for replacement.

Why none of them appears in a case

They are second-order and delayed. All six arrive after the project closes and are attributed to something else — a difficult year, a staffing problem, an unrelated system project.

And nobody's job includes predicting them. The vendor is delivering, the sponsor is approving, and the person who will experience them is not consulted.

Designing around them

Each has a cheap countermeasure, applied during the project rather than after.

Change friction: a change procedure that does not require a purchase order. If a rule change is a form and two days, small improvements continue.

Understanding: the prose description, kept current.

Manual recovery: document the manual path and run it once a year. An hour, and it is the difference between an outage and a crisis.

Error detection: output validation and reconciliation, designed in, not added after the first incident.

Capability: rotate people through both automated and exception work.

And replacement: register the dependency where whoever scopes the system replacement will find it.

The honest accounting

These are costs, they are real, and they do not usually outweigh the benefit. A good automation on a well-chosen process is worth having despite all six.

The argument is not against automating. It is that a business case listing only benefits is incomplete, and the six above are what makes year two feel worse than year one even when the automation is working exactly as designed.

Naming them in the case costs nothing and makes the case more credible, because a reviewer who has lived through one of these recognises that the author has too.

The one that is not a cost

Worth ending on.

Automation makes the process consistent, and consistency is the benefit least often claimed and most often real. Same result on a Friday afternoon as on a Monday morning, from a new starter as from a veteran, in a busy month as in a quiet one.

That is worth something on its own, and it is frequently the reason to keep an automation whose hours no longer justify it.

The short version