Where RPA breaks: the process complexity ceiling

Robotic process automation had a strong run in the late 2010s. The promise was concrete: automate the repetitive clicks and copy-paste work that your staff does daily, without rewriting the underlying systems. No API integration required, no change to the source application. A bot records the actions and replays them.

For a specific slice of work, this actually delivers. The problem is that slice is narrower than most buyers realise.

What RPA is genuinely good at

RPA works well when a process has all three of the following:

• High volume of repetitive steps that follow a fixed sequence.
• Stable underlying applications that do not change their UI frequently.
• Low exception rate - the vast majority of cases follow the standard path.

Extracting invoice data from a fixed PDF template and entering it into an ERP field is a good candidate. Validating that an order record exists in two systems before releasing a shipment is another. Generating a monthly report from a fixed SQL query and emailing it as a PDF is a reasonable use case.

Where it starts to fail

The first failure mode is exceptions. Most real business processes have them. A customer is new and not yet in the system. A field contains unexpected characters. The screen layout changed after a software update. The bot does not handle these gracefully - it stops, or worse, it continues and produces wrong output silently.

Every exception becomes a manual intervention. The team that was supposed to be freed up by the bot now spends time reviewing the bot's queue of failures. If the exception rate is five percent, and the process runs a thousand times a month, that is fifty manual interventions. The efficiency gain is real but smaller than projected.

The second failure mode is UI instability. Bots that interact with desktop applications or web interfaces break when the vendor updates the interface. A button moves, a field is renamed, a new step is added to a workflow. The bot requires maintenance to keep pace. In environments where underlying systems are updated frequently, this cost can be significant.

The organisational trap

I have seen companies automate a process without fixing it first. The process had six exception types because it had never been properly designed. The RPA project turned into an exception-handling framework, which is a brittle and expensive thing to maintain.

The better sequence is to streamline the process before automating it. Remove unnecessary steps, reduce exception paths, standardise the inputs. If you cannot do that, the automation will inherit the complexity of the process and amplify it.

How to evaluate an RPA candidate honestly

Before committing to an RPA project I ask:

• What is the current exception rate? What happens when an exception occurs?
• How often do the underlying applications change? Who maintains the bot when they do?
• What is the cost of a bot failure that is not caught immediately?
• Is the process stable enough to automate, or does it need redesign first?
• What does full-cost ROI look like including bot maintenance over two years?

The right place for RPA in 2021

RPA is not dead and not oversold for everything. It is a good fit for a specific problem: stable, high-volume, low-exception workflows where an API integration is not available and building one is not worth the cost. Outside that zone, the maintenance overhead and fragility tend to outweigh the labour savings within eighteen months.