What is RPA?

And what isn’t

I wrote an article on RPA more than a year ago, The Deception of RPA, and ever since I’ve been getting deeper and deeper into this area by providing RPA services internally with a new dedicated team. We’ve made a lot of progress, solved many problems, and we are still far from the status that I wanted to be.

Just as I pointed out in my last article, RPA was misunderstood by many people, especially in the boundary of RPA, and almost all the articles you can find online regarding What RPA can do are not helping by exaggerating without saying “everything”.

There should be a broad definition and a strict definition of RPA, but it’s exactly those broad definitions that confuse people and make it sound omnipotent. So I’ll stick with my own strict definition:

1. RPA is a script or tool. Without a script or script-enabled tools, there’s no RPA. And because of its script component, no RPA is bullet-proof like many “zero-error” propaganda said.
2. RPA deals with front-end applications or applications. We use RPA only when we don’t have control over the backend of those applications, if we had, we would rather write a backend automation script that works much faster and better than any RPA solution. This means RPA is a bridge between data and system, between one system and another. It also means we shouldn’t categorize pure data analytics and visualization work as RPA.
3. RPA is a type of control. It controls things that you can’t control by other means, for example, an online form that you can’t populate data from the backend. And it helps you avoid using another type of control: quit the job.
4. RPA is data-driven. It means RPA is either populating data repetitively, or using data as a deciding factor to perform some actions repetitively, or both.
5. RPA is a process. It’s not a single operation, it’s not a full-fledged application either. It can’t replace the applications it interacts with, and as a matter of fact, it can be replaced by them if those applications evolve in the right direction.
6. RPA is automation. With or without robotics and artificial intelligence, RPA is always automation. More often than not, without.
7. RPA works like humans by mimicking human operations. But only because it has to, for example, to avoid being blocked as a crawler. In fact, it can transcend humans whenever it can, for example, by cheating the target application to get around certain limitations.

What RPA isn’t then?

1. It’s not a panacea. It can’t solve every problem, for example, you prepared a spreadsheet with wrong data, and use RPA to fill the data online. It’s only going to fill the wrong data for you.
2. It’s not the best solution. It’s only probably the best available solution, and still, it’s largely dependent on the skills of the people who are developing RPA solutions for you.
3. It’s not that easily available. Unlike proclaimed by many RPA tools, one needs to have a coding mindset in order to learn to use those so-called “no-code” RPA tools. And by “no-coding” it means you can only get so far without coding. We all want to press a button and get things done, but the more a button is capable of, the more unreliable it can get to be.
4. It’s not a crawler. Crawler works for the sole purpose of getting information out of applications, while RPA works majorly for sending information into applications, even though sometimes it crawls data as an input.
5. It’s not illegal. There’s no ill intention in RPA, it doesn’t want to break anything, it only wants to do a better job by providing data in a more effective and efficient way.

That’s all I can think of now, please leave a comment if you agree or disagree, or agree to disagree.

Further readings:

1. The Deception of RPA
2. The Deception of Full Automation