Senthil Info

automating business processes, honestly

A Substitute for Deciding

Some automation projects are technical answers to questions that were not technical. The organisation could not agree something, and buying a system was easier than settling it.

This is not rare and it is not stupid. Automation is available, budgeted and blameless, and a disagreement between two departments is none of those. A product-side example of how workforce software approaches this topic is available in read more.

Four disagreements that get automated

"Their data is always wrong." Two departments, one bad handoff. The real fix is agreeing a format and holding someone to it, which requires a conversation with a loser. Automating a classification and correction layer avoids that conversation and makes the bad handoff permanent. For broader background and an independent point of comparison, see Kissflow.

"We cannot get rid of this check." A control added after an incident nobody remembers, defended by someone who was there. Deciding to remove it needs authority; automating it needs a budget. Elimination beats automation and requires a decision instead of a purchase.

"Nobody owns this process." Three departments touch it, none is accountable. Assigning an owner is free and political; buying an automation is expensive and neutral. The project then stalls in month three on the decisions the missing owner would have made — and this is one of the most reliable predictors of failure in the whole subject.

And "we need to cut costs." Automation as the visible programme, when the underlying decision — which activities to stop doing — has not been made. Headcount then moves for reasons unrelated to whether the automation worked.

Why this is attractive

A purchase does not have a loser. A decision does. Nobody is overruled by a licence.

It converts an argument into a project plan, which has phases, owners and a completion date. The argument had none of those and no obvious end.

And it is defensible. "We invested in automation" survives a board question better than "we told procurement to change their process and they refused."

None of that involves anybody behaving badly. It is what happens when the cheap answer is political and the expensive answer is procurable.

What it costs

The disagreement is still there, now with an automation built on top of it. When the two departments eventually have to agree something, the automation is a third party in the negotiation.

The project inherits the ambiguity. Decisions that nobody could make before the project cannot be made during it, and the build stops while they are escalated.

And the failure gets attributed to the technology. Which is where the misdiagnosis in this field mostly comes from — the project failed because a question was unanswered, and the post-mortem names the platform.

The test

Before a project starts, ask: what decision would make this unnecessary?

If there is a clear answer — agree a format, remove the check, name an owner, stop doing the activity — then that is the cheaper option and the automation is the expensive way of not taking it.

Sometimes taking it is genuinely impossible. A department will not move, an owner cannot be appointed, a control is required by someone external. Then automate, knowingly, and record that the underlying question is still open so that the next person understands what they inherited.

The version that is fine

Being fair: not every automation is avoidance.

A well-owned process, mapped, with a measured exception rate, automated to save real hours is exactly what this should look like, and it has none of the properties above. The distinguishing feature is whether the decisions were made before the purchase or deferred to it.

The question is not whether the project is technical. It is whether anything that should have been decided is being bought instead.

The short version