RPA Adoption: What Works and What Becomes Automated Chaos

A few years ago I sat through a demo from one of the major RPA vendors where a bot filled out a web form, copied a row from a spreadsheet, pasted it into a second system, and clicked submit. It did this perfectly, in about twelve seconds, over and over. The audience applauded. The promise was obvious: anything a human does by clicking, copying, and pasting, a bot can do faster and without making typos. The demo was accurate. The demo was also not reality.

Robotic process automation is genuinely useful for a specific class of work. The classic case is this: you have two legacy systems that cannot talk to each other, integrating them directly would cost more than the integration saves, and someone has to manually copy records from one to the other every day. That task is stable. The fields are the same every time. The sequence is always the same. The volume is high enough that it eats real human time. This is exactly what RPA was built for. The bot handles the mechanical middle part so the person who was doing it can do something else.

The vendors that built this space, UiPath, Blue Prism, Automation Anywhere, are well established and have real enterprise customers. The technology works. The question has never really been whether the bots can execute. It is whether the conditions under which bots succeed are as common as the sales materials suggest.

They are not, in my observation. The brittle bot problem is probably the most underappreciated risk in RPA deployments. A bot built to navigate a particular screen workflow breaks the moment that screen changes. If a vendor updates their web application and moves a button, the bot stops. If a data format changes slightly, the bot stops. If a process step gets added because of a regulatory change, the bot stops. Each of these events requires someone to go find the bot, understand what it was doing, figure out what changed, and rebuild the relevant section. That is maintenance work, and it is ongoing.

The problem I keep running into in the literature and in industry reporting is that RPA implementations rarely account for this honestly in the original business case. The case is built on what the bot saves during steady-state operation. It does not usually account for the engineering time to build the bot, the monitoring infrastructure needed to know when the bot fails silently, the exception handling for records that do not fit the standard format, and the ongoing maintenance as the systems the bot touches keep changing. When organizations automate dozens or hundreds of processes, the aggregate maintenance cost of that estate can be significant, and by most accounts it often surprises organizations that did not plan for it.

There is also a process-quality problem that I think is more serious than the brittleness problem, because at least brittleness is visible. When a bot breaks, someone notices. When an organization automates a bad process, the badness becomes faster, higher-volume, and harder to fix. I wrote about how workarounds reveal system-task misfit, and the same logic applies here. If the manual process being automated has inefficiencies, redundant steps, or embedded workarounds for some other system's limitations, the bot faithfully replicates all of it. You have now automated the inefficiency and made it permanent, because changing an automated process is harder than changing a manual one.

This is where the framing of RPA as a "transformation initiative" causes problems. Transformation implies the process gets better, not just faster. But RPA does not redesign processes. It automates whatever exists. Organizations that approach RPA as a tactical efficiency tool for genuinely stable, well-defined, high-volume tasks tend to get real value. Organizations that approach it as a transformation strategy tend to build themselves a brittle estate of automated bad processes, then wonder why the promised transformation has not arrived.

The governance challenge compounds over time. When a single team deploys a handful of bots for a specific purpose, ownership is clear. The same team built the bots, the same team monitors them, and when something breaks they know exactly what to fix. After three or four years of aggressive deployment across an organization, many companies find themselves with hundreds of bots, and for a significant portion of them, nobody can clearly answer who owns it, what it does, when it was last updated, or what happens if the system it touches gets upgraded next quarter. That is not a bot problem. It is a governance problem dressed in bot clothes.

My read on RPA is that it occupies a specific and legitimate niche, but that niche is smaller than vendors would prefer. The meaningful question before any RPA project is not "can a bot do this?" Almost anything a human does by clicking a screen, a bot can technically replicate. The question is: is this process stable enough that we will not spend more maintaining the bot than we save by running it? Is it well-designed enough that automating it does not just lock in existing inefficiencies? And do we have the monitoring and ownership structure to manage this bot when it breaks at 11pm on a Tuesday?

If those answers are yes, RPA is a reasonable tool. If the process is going to change in the next eighteen months because of a system upgrade, a regulatory shift, or a business model change, the economics look a lot worse. The honest version of an RPA business case includes the maintenance line. Most of them still do not.