The steady evolution of RPA to intelligent automation

With the amount of excitement robotic process automation generates, it's almost as if it's a completely new and emerging field. Of course, it isn't; the slow and steady evolution of RPA tools can be traced back decades, even as they are just now getting swept into the whirlwind of AI publicity.

It's been more than 20 years since a variant of RPA was first introduced. Vishal Awasthi, senior vice president of technology and products at Serrala, a financial services automation and data management software vendor, explained in this Q&A how the technology has changed and improved but how its core function of providing basic automation has remained the same.

Simply, RPA is the use of software or bots to automate repetitive, high-volume tasks that would have otherwise been carried out by human workers. RPA might, for example, be used in disaster recovery infrastructure testing, a typically time-consuming task for IT administrators doing it manually. By using RPA, IT employees are freed up to pursue less mundane tasks.

Vishal Awasthi

The potential time and money savings are part of the reason why RPA is such a hot term. Ease of use -- if RPA bots, made to simulate a human worker, can run on top of systems rather than be integrated into them -- relatively low startup costs and numerous vendors to choose from have also helped.

In this Q&A, Awasthi, who was CTO at Dolphin before its incorporation into Serrala, went over the evolution of RPA. With two decades of experience in the sector, Awasthi spoke with firsthand knowledge.

Editor's note: This interview has been edited for brevity and clarity.

What did the start of the evolution of RPA look like? It has been around for quite a while.

Vishal Awasthi: Even in the late '90s, a previous variant of the RPA started out, with things like desktop macros and screen scraping.

Even in the late '90s, a previous variant of the RPA started out, with things like desktop macros and screen scraping.

We weren't really in the business at that time, but we saw there was a gap there -- that a lot of big companies that invested in ERP systems were still doing a lot of manual copying and pasting across applications. There was this kind of grassroots-type effort from the business side to try to automate those steps; they didn't wait to optimize underlying business applications to essentially eliminate those tasks for them.

To me, that was the genesis of the RPA that we see now. I think the intent there was to try to remove repetitive steps off of desktop tools that essentially use these older screen-scraping, macro technology to essentially automate what the user is typically doing on the desktop using the mouse, the keyboard, and to create a script and distribute it across the user base.

The evolution of RPA took that to the next step by bringing it to an enterprise-wide framework.

We like to classify robotics and software generally under three broad classes -- so, robotics class 1, 2 and 3. This basic structure on the enterprise is a typical form of robotics class 1. It's the lowest form of RPA, and it's essentially more like a stopgap measure, because the underlying applications really didn't improve and the underlying business processes really didn't improve.

What did class 2 bring to the development of RPA?

Awasthi: From there, we questioned why users are still doing so much manual, repetitive work, and so this is where class 2 RPA comes in. It still follows the principles of class 1 RPA, but not just to mimic the user's actions in the desktop, but really trying to improve these fundamental, back-office applications that tend to be very much architected in a monolithic way. So, they're very hard to change and maintain.

We wanted to know if there is a way to optimize these applications themselves, either through extensions or add-ons or even cloud-based applications that could extend the functionality of these applications and try to automate some of those tasks in the background, with the intent that, as opposed to using the class 1 RPA on the desktop, you could not even send stuff to the user and give the flexibility to the company to make it work with existing back-office applications.

For example, in accounts payable, when the supply is sending invoices to large organizations, it's a very manual and paper-intensive process to take it from the supplier and then all the way to the different approvals, matching the purchase order. It sounds simple, but sometimes, in a large company, more money is spent doing these invoices than money being sent.

But class 2 basically still deploys the classic software technique for the automation, like the workflow and tracking -- these technologies have been there for a while, and they will automate things, but they are doing it under structured rules. So, someone needs to sit and basically write rules, which still requires a lot of manual effort.

So, moving on to the still-evolving class 3 in the evolution of RPA?

Awasthi: In class 3, we try to use some of the modern cognitive functions in the software that are based on AI tools, things that use machine learning and natural language processing, and start to automate things that we don't have structured rules for. The system is able to learn from history and patterns and create rules by itself, for itself.