Robotic process automation, five years on

We built a set of bots for a retail bank's loan operations. They extracted data from documents, ran eligibility checks, verified paperwork and categorised incoming complaints. Loan processing time fell by 60% and operating cost by 40%. Some of those bots are still running. Others were switched off inside two years, and switching them off was the correct outcome rather than a failure.

What survived

The bots that lasted all share a shape. They sit against a system with no programmable interface and no realistic prospect of getting one: a core platform two decades old, a government portal, a vendor product past end of support with an empty roadmap. The process they automate is high volume and stable, and it is written down somewhere because a regulator once asked for it. Document extraction into a system of record is the archetype.

In that position a bot is a cheap adapter over software nobody is allowed to change. It buys time, and buying time is a legitimate thing to spend money on when the replacement programme is three years out.

What was quietly replaced

Whenever a real interface appeared, the bot became the more expensive option within a release or two. A vendor ships an API and a routine that drives twelve screens collapses into a hundred lines of integration code that runs faster and fails in a way a test can catch. We have done that rewrite several times. Nobody mourned the bots.

This is predictable enough to plan for. At the point of building a bot, write down its expected life and what would replace it. A bot with a stated successor is an engineering decision. A bot with no stated successor is a permanent liability that arrived through the back door.

Where the brittleness showed up

The failure everyone expects is a screen change breaking a selector. That does happen, and it is the least troublesome kind, because the bot stops and someone notices within the hour.

The expensive failures were partial. A bot completes seven of nine steps and the session times out. A record is now half updated, an internal ledger and a case management system disagree, and nothing has raised an alarm because from the automation platform's point of view a run simply ended. Weeks later the discrepancy surfaces as a customer complaint, and the reconciliation is manual and slow because nobody kept an audit trail at step level.

Two rules came out of that, and we apply them to every automation estate we take on now. Every run is a transaction with a reconciliation step, and re-running it must be safe. A bot that stops in the middle must generate a louder signal than one that never started.

The credentials problem

Bots log in as somebody. During a pilot that somebody is frequently a real employee whose account was borrowed because provisioning a service account would have taken three weeks. Two years later that employee has moved on, the account has survived every joiner-mover-leaver process because switching it off breaks production, and its permissions have accumulated. An automation estate is an access estate, and it belongs in the same review cycle as human accounts, with named service identities and scoped permissions. This is the finding that comes up most often when we inherit somebody else's bots.

The lesson we did not expect

Most of the value came from the assessment rather than the robots. Identifying automation candidates meant reading each process end to end, in detail, with the people who run it. Roughly half of what we found were steps that existed because of a system that had been decommissioned years earlier, or approvals nobody could name an owner for, or a form transcribed by hand into a second form.

Deleting a step is cheaper than automating it and it never breaks afterwards. We still build RPA, and in the right position it earns its place. We also put a sunset date on every bot at the moment we write it, and we are pleased when the date arrives on schedule.