RPA: where process automation works and where it does not
A clear-eyed look at RPA - which tasks are genuinely suited to robotic automation, and where expectations diverge from reality.
Robotic Process Automation, or RPA, is one of those technologies that has accumulated a lot of expectations. The promise is simple: a software robot does what a person used to do at a computer - logs into systems, copies data, fills in forms, sends files. No API integration, no changes to the underlying systems.
That sounds appealing to companies with a large volume of manual operations. But I have seen enough RPA projects to say: expectations and reality diverge noticeably. And they diverge not because the technology is bad - but because it is applied in the wrong places.
Where RPA works well
RPA is designed for a very specific class of tasks. Tasks that have a few mandatory characteristics:
- the process is stable and well documented. If it is performed slightly differently each time, the robot will keep breaking.
- Interfaces are stable. If systems are updated frequently and the UI changes, robots need to be constantly reprogrammed.
- Volume is sufficient. If the process takes two hours a week, automation will not pay off.
- Data is structured. If the input consists of unstructured documents or free text, RPA needs to be combined with other tools.
Classic examples where this works: daily export of data from several systems into one spreadsheet, entering data from forms into a corporate system, generating standard reports at a set time.
Where expectations do not match reality
The first problem is fragility. Robots operate on the interface, not on the logic. A button changes colour, a field shifts in a form, a browser version updates - and the robot stops working. This creates constant maintenance load.
The second problem is that processes turn out to be less standardised than they appeared. In practice every employee performs the same task slightly differently. Automating such a process is harder than describing it in a specification.
The third problem is that RPA automates a symptom, not a cause. If data needs to be moved manually from one system to another, that is a symptom of missing integration. RPA automates the transfer but does not remove the architectural gap. A year later the number of robots has grown, and the architectural problem is still there.
How to make the decision
Before launching an RPA project, it is worth answering several questions:
- How stable is this process? When did it last change substantially?
- Is it possible to solve this through an API or direct integration? If so, why are we choosing RPA instead?
- Who will maintain the robots after deployment? Is this an internal capability or a vendor dependency?
- How will we know when a robot breaks or starts doing something incorrectly?
- What percentage of cases will require exceptions and manual intervention?
If API integration is possible, I will almost always prefer it over RPA. It is more reliable, cheaper to maintain, and does not break when interfaces update. RPA is justified where there is no API, integration cannot be built in a reasonable timeframe, and the manual process is large enough and stable enough.
The bottom line
RPA is a useful tool for a narrow class of tasks. The problem is not the tool - it is that RPA is often treated as a universal automation solution rather than a specialised instrument with specific conditions of use.
A good question before any RPA project: if we were solving this problem from scratch today, would we choose RPA again - or would we try something else?