<img src="https://secure.leadforensics.com/85060.png" style="display:none;">

RPA versus artificial intelligence and machine learning: not as flashy, but a strong value proposition nonetheless

When I discuss robotic process automation (RPA) with Ventiv’s clients and prospective clients, I’m often asked how RPA differs from machine learning (ML) and artificial intelligence (AI). A November 2017 article from CIO.com offers a good starting point: “RPA can include ML or AI, but it is governed by set business logic and structured inputs, and its rules don't deviate, whereas ML and AI technologies can be trained to make judgments about unstructured inputs.” 

This blog post in 30 seconds:

  • Conventional wisdom holds that for most organizations, robotic process automation (RPA) has value but is only a stopgap on the march toward artificial intelligence (AI) and machine learning (ML).

  • Conventional wisdom overlooks the great expense and upheaval usually associated with deploying AI and ML. RPA is cost-effective and deploys easily.

  • In terms of business need, RPA integrates legacy systems. These systems serve important purposes but often can’t be linked to other, newer systems by modern means of transferring information (like API and web services).

All things being equal, why wouldn’t everyone choose artificial intelligence and machine learning and their ability to learn and make judgments? In reality, all things are rarely equal, and deploying AI and ML is usually a very disruptive, costly process. Moreover, you have to ask what you’re trying to achieve; RPA, I’d argue, strives for more modest, yet imminently more attainable, goals. 

Unifying versus disrupting technologies

RPA, in contrast to AI and ML, is a cost-effective technology that I characterize as a unifying technology: it integrates disparate, often legacy applications and systems and, in the process, automates manual, repetitive processes (the “set business logic and structured inputs…[whose] rules don’t deviate,” as noted in the quote above). For most claim organizations and risk and insurance teams, that’s a good goal for the present.

The significance of RPA is that it’s one of the first technologies that can interact quickly and easily—relative to more complex technologies like AI and ML—with applications and systems already in place (including web browsers, email and Windows applications). AI and ML are exciting, but they are disruptive technologies because they require organizations to make substantial changes to their existing applications and systems (or wait for newer versions to come along before they can take advantage of those new capabilities).

With RPA, organizations don’t have to change processes or the systems and applications they already use.

RPA shines with legacy applications

Cogwheel Gear Mechanism Icon on Blue Arrow on a Grey Background.One important area where RPA shines is with legacy applications, or what are sometimes called closed applications. Oftentimes, an organization will use older applications that don’t support web APIs (application programming interface) or even web services (which is another means of facilitating the transfer of information).

These are “two-tier” applications, which means there’s the application with which the user interacts, and then there’s the database that stores the data. Unlike more-current applications, there’s nothing between these two tiers; there are no other “hooks” into the system.

With RPA, the user interface is, for all intents and purposes, the hook—it becomes the functional equivalent of an API. RPA might not sound as exciting as AI and ML and their ability to “make judgments about unstructured inputs”; however, the way I see it, it’s pretty impressive that RPA can open up systems that were once, seemingly, forever closed.

As for the business need, it’s quite common for organizations to want to integrate legacy systems with each other or with newer applications. Especially in claims administration, but also in risk and insurance management, organizations often use legacy systems that are no longer supported by the vendor; yet, the system still does what it needs to do, and therefore it’s hard to justify the cost and potential upheaval in replacing it.

Pre-RPA: What did it take to integrate legacy systems?

So, before RPA, what would you have to do to integrate a legacy system, or systems, with other applications? Speaking from the technology vendor perspective, we usually had to send one of our own seasoned database experts to sit with one of the client’s database experts; their expert guided us as we interacted directly with the database. And that was often very time-consuming, because how you see data presented in user interfaces rarely corresponds one-to-one with the database table. We’d have to figure out which data tables fed which views, and that could be a costly, time-consuming endeavor. We could do it, but clients often had trouble justifying the cost. So, they just kept doing things the way they always did.

RPA eliminates the need for that kind of intensive database work. RPA works with an application in the exact same way the user does. We study the interaction that the user has with the application, record it, and then train bots to mimic those actions. That’s it! Turn the bots loose and you’ve automated repetitive manual processes and integrated once disparate systems.

The CIO.com article I quoted above cites Gartner research about spending on RPA, which is estimated to reach $1 billion by 2020, growing at a compound annual growth rate of 41 percent from 2015 through 2020. It’s expected that 40 percent of large enterprises will have adopted an RPA software tool by 2020. Most analysts see RPA as a stopgap on the way to broader AI and ML spending, but for what you get for the investment, I think RPA is a strong offering in its own right.

Jarrod Albert, Ventiv TechnologyJarrod Albert is Senior Manager, Automation & Integration, with Ventiv Technology. Contact Jarrod at jarrod.albert@ventivtech.com.   

Learn more >

Topics: Automation 2018.10 redesign