API-Led Robotic Process Automation. Reality or fiction?

A brief RPA review

If you have been reading my latest posts, I have been writing a lot about Robotic Process Automation (RPA) in the context of Process Automation and Integration and how the two can be combined together to bring augmented value. At a high level, RPA has two types of robots: attended and unattended. Based on analysts' research, attended robots account for about 60% while unattended for the remainder. As a quick review, here is a debrief on these two:

• Attended robots are the ones that are triggered by a person when they need them. The most common example is a Customer Service Representative (CSR) in a Call Center that upon a particular request, he/she needs to interact with different systems to complete the transaction. In this context, the CSR can simply launch the appropriate robot transaction in his/her windows workstation and the robot will do all the points and clicks and interact with the CSR to collect necessary pieces of information. There are clear benefits for this type of robot in industries with lots of manual labor. 
• Unattended robots are on the other hand will not run on a person’s workstation, but they will run on a Windows server without any human triggering or supervising it. These robots are triggered via API calls or based on some kind of schedule. When invoked via API calls, they can easily be combined with any sort of orchestration layer (regardless of a human or service orchestration) to coordinate API calls that can trigger a robot to do something as well as trigger APIs that go straight into an application.

What does business need to help digital transformation initiatives?

Digital Transformation is top of mind in any business agenda. Digital transformation conversations usually revolve about improving business processes and experiences, and this translates into accessing data and transacting electronically against a business’ systems of information. Newer and more modern systems have been created with the notion of an API in place which greatly simplifies how consumer applications (business processes and new experiences) can take advantage of this data access in the context of new experiences. But what happens when these backend systems of information data cannot be accessed via an API?

RPA to the rescue?

RPA at its core is primarily a technology that allows transacting with an application via its UI. Whether the target application can be accessed via a browser or an app on a desktop, RPA can create a script that can be run each time with different data to transact against the system it was created for. This RPA script (aka, RPA process) can be run in an attended or unattended manner. Imagine for a second, that a proper API abstraction is created connecting to an RPA process. This API can be called by a consuming application to transact against a target app that does not offer an API. All of a sudden, API + RPA combined, allow creating new experiences with applications that were not accessible in the past. 

Examples of this include creating simple self-service transactions against a legacy app. Imagine for a second that a new experience like a chatbot asks an employee for his/her new home address, and when all this information is collected, the proper RPA process is launched connecting to a legacy HCM application and updates all data.

Some caveats with this pattern.

RPA processes take a significantly higher amount of time to perform granular simple transactions when compared to pure APIs. RPA processes usually have to log into the application, navigate the application UI and then perform some kind of action before logging out. Needless to say that having this RPA process is still WAY better than having a person manually do it or not doing it at all. With this caveat in mind, we really have to think about using this API + RPA pattern in asynchronous scenarios. This implies triggering the execution of the RPA process without holding the end user waiting for the RPA process to complete and creating an appropriate experience to deal with this (for example, the end-user may be notified via email when the transaction has been effectively completed).

So, it is possible to combine API-led initiatives implemented with RPA?

As we have seen in this writing, YES. As long as you account for the described caveats, you can digitize access to systems of information that do not have APIs and help organizations boost their digital transformation initiatives!