RPA Bot Clean-Up: When Automation Itself Becomes Legacy

You clean up RPA bots in four steps: take inventory, assess, decide and assign an owner. A bot becomes legacy when the system it clicks through changes, or the process it mirrors, and nobody is responsible for its upkeep. Assessing bots by benefit and maintenance effort separates the automations that pay for themselves from those that cost more time than they save.

In recent years Robotic Process Automation has taken over tasks that employees previously did by hand in user interfaces: transferring data from one system to another, entering invoices, reconciling master data. This article describes why such bots age, how a company records and assesses its estate, and which four decisions are possible for each bot. It is written for heads of department and managing directors who steer the operation of their automation and want to know whether it still pays off.

Why do RPA bots become legacy?

RPA bots become legacy because they work on the surface of applications, and any change to that surface or to the process damages them. A bot reads fields at screen positions, clicks buttons and copies values. If the vendor updates the application, a department renames a field or a screen layout changes, the sequence breaks or returns wrong results.

The pattern is familiar from software engineering. In 1992 Ward Cunningham described the image of technical debt: those who build quickly without regard for maintainability take out a loan whose interest falls due as extra effort at every later change. A bot built in a week that has neither documentation nor error handling nor an owner is exactly such a loan. The interest is paid by whoever has to repair it months later and does not know which process stands behind it.

Four causes recur. First, the target systems change: updates and migrations shift fields and flows. Second, the process itself changes without the bot being adapted, so that it automates a sequence that no longer exists. Third, developers and business users leave the company, and with them the knowledge of what the bot does and why. Fourth, credentials and service accounts expire or are blocked, and the bot fails silently. The article on waiting times in processes describes how such failures leave work sitting without anyone noticing.

How do you know the bot estate needs clearing up?

The bot estate needs attention as soon as several of the following signals occur together. The team running the bots spends more time on repairs than on new automations, and business units learn of failures only when a customer asks. Nobody can say how many bots are running and who is responsible for them. A bot has run for years although the underlying process has been changed, or employees routinely check its results by hand because they no longer trust it. In that case the automation has already lost its benefit and still costs money to run.

How do you take inventory of RPA bots?

The inventory records each bot with ten pieces of information and ends with a complete list that an owner in the business unit confirms. Sources are the vendor's orchestration platform, the servers' schedulers and interviews with business units, since some bots run on desktop machines that appear on no list.

The inventory first delivers a sobering result that is useful for what follows: for many bots part of the information is missing. Where the owner is missing, the bot has no future until someone takes responsibility. Where the time saved is missing, the benefit is unproven.

How do you assess whether a bot is still worth it?

A bot is worth keeping as long as the working time it saves exceeds the cost of running and maintaining it. The calculation compares both sides over one year. On the benefit side stands the working time actually saved multiplied by the department's hourly rate. On the cost side stand the licence or a share of the platform cost, the maintenance hours for adjustments and fault repair, and the effort of the business units that spot-check results.

A worked example with assumed values shows the logic. A bot saves 60 hours a month in the business unit; at an hourly rate of 50 euros that is 3,000 euros a month or 36,000 euros a year. It causes a licence share of 6,000 euros a year, 80 hours of maintenance a year at 90 euros, which is 7,200 euros, and 30 hours of checking in the business unit at 50 euros, which is 1,500 euros. The cost comes to 14,700 euros and the net benefit to 21,300 euros. If maintenance rises to 300 hours because of a new release of the target system, the cost climbs to 34,500 euros and the bot barely pays for itself. The example is illustrative; your own estate supplies the real values.

What are the four decisions for each bot?

Four decisions are possible for each bot: keep, rework, replace or switch off. Keeping applies to bots with a clear benefit and low maintenance effort, which receive an owner and documentation. Reworking applies to bots with a clear benefit and high effort, where error handling, logging and monitoring can be improved so that faults are reported at once.

Replacing comes into question when the target system offers an interface. A connection through an application programming interface is insensitive to layout changes because it uses no screen positions. For documents, text recognition with AI support that classifies invoices or e-mails and reads out fields can replace parts of a bot, provided the quality of recognition has been tested in the real process with real data. This option requires a testing task of its own.

Switching off applies to bots whose process has lapsed, whose benefit is unproven or whose upkeep costs more than the manual work. Switching off easily slips out of view during a clean-up. A bot that is retired saves licence, maintenance and checking effort, and after one month the business unit sees whether the manual work actually arises. How the whole stock of initiatives can be reduced is described in the article on clearing out the project portfolio.

How do you keep the estate clean in the long run?

The estate stays clean when every bot has an owner in the business unit, every change to the process includes the bot, and operations report faults actively. Four rules suffice to begin with.

1. Every new bot goes live only when owner, documentation and error handling are in place. The bot's Definition of Done contains these points, in the manner described in the article on the Definition of Done.
2. Every change to a target system or process triggers a check of the bots concerned. For that, operations need a list showing which bots work in which system.
3. Every bot has monitoring that reports failures and unusual results, and a metric for the time saved that the business unit confirms.
4. Once a quarter the owner of bot operations reviews the list with the business units and decides whether to keep, rework, replace or switch off.

Clearing up with Niehues Consulting

Niehues Consulting is a consultancy for AI management and organisational design from the delivery perspective, based in Düsseldorf. Founder Marin Niehues brings AI into operations, in projects from VC-funded scale-ups to DAX 40 corporations and in more than 20 countries on six continents. In the AI management service the work extends from business analysis and requirements through the business case to the selection and sequencing of applications and portfolio steering.

The approach follows the Niehues Delivery Model. Three of its test questions count for clearing up a bot estate: what is the baseline, and how do we measure success? Is the business case confirmed with real values? Who is responsible for operations from day one? The result is a decision per bot with an owner and a metric, and for the estate as a whole a sequence that weighs benefit and risk. The scope and terms of an engagement are discussed in the free initial consultation, which you can arrange via contact.