Senthil Info

automating business processes, honestly

Fix It Before You Automate It

An automation is a decision to keep a process. It fixes the current design in code, builds dependencies on it, and makes changing it a project rather than a conversation.

That is fine when the process is good. When it is not, automation makes a bad process permanent, faster and harder to change — three effects in the wrong direction, bought at full price. For a product-side reference related to workforce operations, Monitask also covers workforce analytics software.

What automation does to a bad process

It removes the pressure to fix it. The pain of a clumsy process is what eventually gets it redesigned. Automate it and the pain disappears from view while the design stays. For broader background and an independent point of comparison, see NIST AI.

It adds dependencies. Once an automation reads from a screen, that screen cannot change. The workaround has acquired a dependent, and the eventual system replacement is now more expensive than it was before.

It preserves the exceptions. Every awkward case in the current design is now a rule in the automation, documented and maintained indefinitely.

And it makes the process invisible. Nobody watches a working automation. Three years on, nobody remembers why it does what it does, and the person who knew has left.

Four fixes that come first

Cheaper than automation, faster to deliver, and they improve the manual process immediately rather than in nine months.

Standardise the input. A required format, a template, a portal, a mandatory field. High input variance is what makes classification expensive, and removing it upstream is usually cheaper than building a classifier downstream.

Eliminate steps. The check nobody can explain, the approval that has never been refused, the reconciliation that exists because a sync failed once in 2019. Removing a step beats automating it and costs nothing.

Fix the upstream system. Expensive, and it removes the process rather than preserving it. Worth pricing honestly against the automation plus its maintenance rather than dismissing.

Assign an owner. Free. A process with an owner gets improved continuously; one without gets automated and forgotten.

The test

If we could not automate this at all, what would we do?

The answers are informative. Simplify the form. Stop doing the check. Get the supplier to send it properly. Frequently one of those is cheaper than the automation, deliverable in weeks, and improves things for the people doing the work today.

Then ask: after doing that, is automation still worth it? Sometimes yes and the project is now smaller and better scoped. Sometimes no, and you have saved the whole cost.

Why this argument loses

Not because it is wrong.

Process improvement has no vendor. Nobody arrives with a deck about eliminating a step. Automation has a market and a sales motion; simplification does not.

It implicates people. "This step is unnecessary" means somebody added it, and somebody has been doing it. Automation avoids that conversation entirely, which is part of its appeal.

And it is not a project. Simplification is a series of small changes with no launch, no milestone and no photograph. Automation produces an artefact — which is exactly why the effort goes there.

The order that works

Map it. A week, no budget.

Simplify what can be simplified, and measure the process again afterwards. The exception rate often drops materially, which changes the automation case.

Then automate what remains, if the case still holds against the simplified baseline rather than against the original mess.

That sequence produces smaller automations on cleaner processes, which is the profile that succeeds. It also occasionally ends with no automation at all and a better operation, which is a good outcome that nobody counts as a project success.

The short version