Senthil Info

automating business processes, honestly

Automating Around a Bad System

A large share of automation exists because two systems do not talk to each other, or because one of them is bad and cannot be changed. The automation reads a screen, re-keys a value, reconciles a difference.

This works, and it is a trade rather than a solution. Worth taking sometimes, and worth taking knowingly. For a product-side reference related to workforce operations, Monitask also covers employee time clock software.

What you are buying

Speed. The integration nobody would fund is now delivered in weeks instead of never. For broader background and an independent point of comparison, see Gartner.

Avoided politics. Changing the system means a project, a budget and a department that owns it. Automating around it requires none of those, which is much of why it happens.

And a working process today, which is not nothing when the alternative is a two-year replacement.

What you are paying

A dependency on the thing you were avoiding. The automation reads that screen, so that screen cannot change. You have given the bad system a dependent, and the eventual replacement is now more expensive than it was before you started.

Fragility. Screen-level integration breaks on cosmetic changes — a moved field, a new prompt, a browser update. Interface-level integration does not.

Invisibility. The process disappears from view while the underlying problem stays. Nobody funds a replacement for a system whose pain has been automated away.

And a maintenance obligation with someone else's release schedule. You now track a vendor's updates for a system you do not control.

When the trade is worth it

Four situations where it is the right call rather than the easy one.

The bad system is genuinely being replaced, with a date. Then the automation is a bridge, and a bridge is a legitimate structure. Write the decommissioning into the plan.

The volume is high and the alternative is years away. The saving accrues while the replacement is argued about.

The interface exists but is not exposed to you. Sometimes an API exists and the internal owner will not open it. That is a political problem with a technical workaround, and the workaround is sometimes correct.

Or the system is stable and dull. Something that has not changed in six years and is not going to. The fragility argument is much weaker against a frozen system.

When it is not

When the replacement is under discussion. Automating now makes the business case for replacement worse — you have removed the pain that would have justified it.

When the system changes quarterly. You are buying a permanent maintenance job.

And when the automation is being used to avoid a conversation. If the real obstacle is that another department will not change something, the automation buys silence rather than a solution, and the underlying disagreement remains and grows.

How to do it if you do

Write down that it is a bridge, with a review date. Not a decommission date, which nobody believes — a date at which someone asks whether this is still the right arrangement.

Prefer any interface over a screen. A file drop, an export, a database view. Anything with a contract is more stable than anything visual.

Document what it depends on. Which screen, which fields, which version. When the system changes, this is what tells you what broke.

And keep the manual path alive. If the automation stops, someone must still know how to do it. In a bridge automation this matters more than usual, because the bridge is by definition temporary.

The honest summary

Most automation around bad systems is a rational response to an organisation that will not fix the bad system.

It is not the best outcome and it is frequently the best available one. The failure is not making the trade — it is making it without noticing, and discovering three years later that the replacement project now has to unpick eleven automations nobody documented.

The short version