My conversion from RPA skeptic to RPA advocate and why governance is so important

What I used to think about RPA

Seeing the world from the perspective of a developer, I echoed a common chorus that criticizes RPA along two main points:

• RPA is inherently limited in what it can do. Many automation use cases cannot be realised using RPA, and many that are realised using RPA could be realised better (i.e. of higher quality / more robustly / more efficiently) using different technologies. A common example is integration of different software tools using screen capture with an RPA tool vs. integration via APIs. Maybe an HR professional has a job post that they want to publish on several job platforms. Typically, this is a copy-paste job. Using an RPA tool, they might automate it using screen capture – i.e. recording their screen while doing the copy-pasting and then having “the bot” repeat the process for them. While it might make the HR professional faster in their work, it is a highly error prone way to automate this – e.g. when one job platform moves a button slightly, the RPA bot might not find it again. It is also not secure, since the RPA bot might store the login credentials to the job platforms in plain text – or rather, the HR professional is likely to provide the bot with their login credentials in the simplest possible way, which is probably in plain text. It is also not performant, and definitely not elegant. Using APIs to automate this would be more robust, more secure, auditable and performant.
• Giving “every person a bot” leads to a proliferation of automated processes that is incredibly hard to manage. Allowing “anyone” to automate leads to poor implementation of automated processes which are not properly managed and monitored. This creates high risk to an organisation, which quickly becomes reliant on such automations which can (and do) fail at any moment.

Both these points are true. But this doesn’t mean that RPA is a fundamentally bad idea, which is the conclusion that many skeptics draw – as did I. Just Google “why rpa is bad” to get an idea how common this stance is.

This conclusion is often accompanied by a generalised disdain of technical people towards non-technical people who “dare” to attempt to solve their own problems. This cannot end well, seems to be the general understanding

But this is an embarrassingly arrogant position that limits one’s own perspective to consider only arguments that are in line with one’s preconceived position. To be able to make good decisions, it is invaluable to take a step back and open one’s perspective. Anything that is as successful as RPA clearly provides real value, otherwise it would not be adopted so widely.

Seeing that my thinking of RPA as an inherently limited technology was in such stark conflict with the wide adoption of RPA and its many fans, I realised that the problem was not RPA, but my thinking.

The error in my thinking

The error in my thinking: looking at RPA from my perspective, I tried to find fault with it, and I did. What I didn’t consider was: what is the alternative?

I thought it was clear: the sensible alternative to RPA is to use “proper”, code-based automation tools that allow to automate pretty much anything.

Using such code-based tools required technical experts, which are deemed inherently better suited to automate processes in a way that will be of high quality, well managed and monitored.

This is assumed because it is the IT department’s job to do just that, to automate in a way that is sustainable, and they usually have both processes and tools in place to ensure that an automated process is managed and monitored properly.

But does this make sense in every case

No it does not.

The problem with proper automation

There are two major drawbacks of this approach of giving IT a monopoly on automation:

• High risk of failure: the interface between business and IT is a legendarily fraught one. Communication of requirements from business to IT is notoriously difficult. This is where many, many projects fail, and even those that succeed very often result in an automated process that doesn’t do what business needs, or does so only partially or poorly.
• It is expensive: having IT automate a process means involving at least two departments, many people, and a lot of effort going into communication. On top, making sure that an automated process follows best practices, is managed and monitored well, comes at a cost: it will not be implemented in the simplest possible way, but in a “good” way. This has obvious value, but it also costs money.

The result is clear: this only makes sense for processes which are business critical and deliver a high ROI. For the most valuable processes in an organization, it is sensible to involve IT in their automation, management and maintenance and to use tools that allow both to automate the process following the highest technical standards and exactly as is required – thus choosing a tool with the required flexibility. The cost associated with this is paid for through the reduction of risk that comes with proper implementation.

But the truth is that the majority of automation use cases in an organisation are not valuable enough to warrant this effort. They will never be automated if it means involving the IT department. It’s just not worth it.


Therefore, the alternative to using RPA is not to use code-based tools. The alternative to RPA is to automate less. And that is a bad alternative.

What I think now

There is immense potential for productivity gains through automation which will never be realised if automation always means involving IT, with all the overhead this involves.

It is in this long tail of small use cases where RPA becomes really valuable. It allows business users and subject matter experts to automate where they see a need or an opportunity.

It removes the immense obstacle of communication between technical and non-technical people by letting the non-technical people solve their own problems. And it is cheap, so a lot more processes clear the hurdle of an ROI analysis because with cheap technology, you get more R(eturn) for less I(nvestment).

What changed to make me realise this

I had this moment of clarity after interviewing an automation expert who was going on and on about governance. Sure, governance is important, but let’s be honest, it’s not a topic that gets many people excited. I was surprised that he chose to talk so much about it.

After concluding our talk, I decided to do a bit of research into the governance features of some of the RPA solutions he had mentioned. I found that they consist mostly of long lists of rules and how they could be enforced.

It felt to me like those governance features were self-defeating: why buy a tool that is marketed as easy to use and accessible to everyone, if you then choose to add so many limitations to it that it becomes unwieldy and difficult to use?

And then the penny dropped: Because proper governance makes it possible to allow everyone to automate.

What is good governance

Good governance makes it possible to manage the risk that comes from many subject matter experts who are not technical experts automating on their own. The key is in the word “good”.

Good governance can’t ever be a blanket approach but has to be something that is carefully tailored to balance governance effort versus the risk that has to be managed.

Good governance frameworks for automation allow us to do just this: to first categorise a process in its importance to the business, and then to define which rules a process automation has to follow depending on how critical it is.

How good governance democratises automation

This means that this long list of rules is applied not at all or only partially on many automated processes. Rules are applied only where it makes sense.

If a process is not very important, quick-and-dirty automation is okay. If it breaks, not a lot happens. By still allowing it to be quickly and cheaply automated, even small productivity gains can be realised – as long as the automation saves more time than it took to create.

Good governance allows the implementation of automation with intermediate impact with intermediate effort. And it allows to highlight those processes that warrant investment in their automation because they are high risk, but high reward.

So the question is not: is RPA valuable, but how to make RPA valuable. This requires to shift focus away from the tool towards governance.

It is still absolutely true that having many automated processes means that there is a high risk that some of them will fail. But: having many automated processes is a great thing! All it means is that care has to be taken to govern them sensibly so that the risk from many non-experts automating a lot of processes can be managed.

So is RPA now the solution to everything?

Clearly, it isn’t. Which technology to choose still depends entirely on the situation at hand. For any business-critical process, it is still absolutely necessary to use tools that allow a higher standard of quality and that have more capabilities, such as e.g. handling larger amounts of data, and to let experts automate them.

But to capture the immense value in the long tail of small to medium processes that have automation potential, RPA is a highly valuable tool.

As long as it is paired with good governance.

And the choice is not one of either using RPA or using code-based automation tools, but to use the right tool for the right purpose.

A note on over-use

Any tool that is successful will inevitably be used in many cases where it should not be used. We all know this to be true of Excel, which is used as a controlling tool, database, accounting tool and many other uses to which it is not suited.

The same is true for RPA. Once an organisation successfully uses RPA, it will inevitably be used to automate processes which should definitely not be automated with an RPA tool. It will be used nevertheless because people already know how to use it, there is a lack of awareness of other solutions, and doing things differently seems even more scary than automating a process with a tool you know, even if it is painful to do so.

Paradoxically, through over-use, the success of RPA contributes to its bad reputation.

This is also the job of good governance, and might be the hardest job it has to do: to make sure that those processes that are really critical, or which have technical requirements for which RPA is simply not suitable, are not automated using RPA. Because the risk of doing so might be higher than the cost savings of automating it.