The RPA Gold Rush — Automating the Process You Should Have Killed

Commentary·Giovanni Leonardi·June 2018·4 min read

Automating it preserves the compromise in code.

The Bots Are Multiplying

The slide has become ubiquitous. A hockey-stick graph of bots deployed, a projected headcount for the “digital workforce,” a savings number extrapolated from the first handful of pilots. It appears in board presentations, in vendor showcases, in the business cases that arrive on the CIO’s desk with increasing frequency and urgency. The story it tells is compelling: robotic process automation can take the processes you already have, exactly as they are, and run them faster, cheaper, and without complaint. No integration. No redesign. No architecture. Just record what the person does and replay it.

This promise has made RPA the fastest-growing category in enterprise software. It has also set in motion something that will take years to fully appreciate: the quiet construction of the next generation of legacy.

The Arithmetic

The uncomfortable arithmetic runs like this. A process that consumes enough human time to justify an RPA licence, a build, and ongoing maintenance is, almost by definition, a process worth redesigning. It exists in its current form because of accumulated workarounds — system gaps bridged by people, decisions made years ago under constraints that no longer apply, integrations that were never built because a clerk with a spreadsheet was cheaper than a project. The process is not a neutral thing waiting to be accelerated. It is an artefact of organisational compromise.

Automating it preserves the compromise in code.

And the code is brittle in ways that are difficult to see from the boardroom. An RPA bot that navigates a user interface is coupled to every field label, every screen transition, every pixel of the application it operates. A routine system upgrade — a patch, a UI refresh, a vendor’s minor release — can break dozens of bots in a single afternoon. The organisations now racing to deploy hundreds of bots are building estates that require constant, specialised maintenance, that fail in ways invisible until something upstream changes, and that encode process logic in scripts rather than in systems where it can be governed, versioned, and understood.

The Centre of Excellence model that most large organisations are adopting to manage their bot estates is itself a telling indicator. We do not build Centres of Excellence around things that are simple to maintain. We build them when something demands ongoing, specialised attention merely to keep running — which is another way of acknowledging that the operational cost has not been eliminated but relocated. The headcount saved on the process reappears, in part, as the headcount required to keep the bots alive.

The Question That Should Come First

None of this means RPA is without value. There are processes that genuinely cannot be redesigned in the near term: regulatory constraints that mandate a specific sequence, vendor lock-in that forecloses integration, systems so close to decommission that investment in them cannot be justified. For these, a bot that bridges the gap is pragmatic and defensible. It is a holding action — an honest acknowledgement that the right solution is not yet available, and that something must fill the interval.

But a holding action is not a transformation strategy, and the distance between these two uses is where the current gold rush loses its footing. When the metric is bots deployed, the incentive is to automate everything that can be automated, not everything that should be. The faster the bot count climbs, the less likely anyone is to ask whether the process beneath it deserved to survive at all.

The organisations that will look back on this period with the least regret are the ones inserting a single question before every bot build: is this process worth preserving? If the answer is no — and it is surprising how often the answer is no, once someone actually examines the steps — then the bot is not the solution. It is the mechanism by which a broken process becomes permanent, defended by the sunk cost of the automation itself and by the dashboard that counts it as a success.

The RPA market is moving too fast and paying too well for this question to gain much traction. But the bots being deployed this quarter will still be running years from now, and the processes they encode will still be unexamined. We are not automating our way out of complexity. We are scripting it into place.


More from Transformation