This blog post is based on research presented in the RPA forum at the Business Process Management Conference 2022 in Münster (BPM 22).
With this summary, we aim to show you all the key highlights of the research.
What is the study about?
A few decades ago, it was said, “RPA will transform how we work in the future.” Today, we are living in that future. RPA is a critical component for businesses and companies. It came with its own set of issues. The more RPA automation a company has, the harder it is to manage the automation of the new processes.
Hence, in this research, we analyzed the problem of maintaining the RPA bots. Recently, we noticed an uptick in the number of companies stuck in the maintenance trap.
What is a maintenance trap? It is a common issue where companies end up spending all their resources on maintaining the current automation setup and, therefore, aren’t focused on building new ones.
With Pointee, we want to help companies escape the maintenance trap and improve their automation. Based on our previous research (link), we concluded that good architecture of the RPA process could improve RPA automation as a whole. We checked out some interesting design patterns of RPA and spotted the use of API.
For years, RPA was mainly used as a tool for automating legacy systems, and not many organizations were interested in investing their money in it. However, since it was easy to deploy and the automation generated value sooner, RPA gained momentum.
The situation is vastly different now. Many companies automate most of their processes as it is pretty straightforward. So, where does the issue arise? It is usually when the front end is changed, or businesses request changes in the process or legislation and other issues. It becomes challenging for companies to maintain.
Companies use RPA to automate various processes, but it mostly has to do with Excel. It isn’t limited to only old applications in FORTRAN and COBOL. Many companies also use modern applications like CRM, ERP, or database applications with API.
How did we conduct the research?
We assumed it is possible to use the API call in your RPA automation. We designed an experiment with this assumption in our minds. We chose three processes that were possible to automate by RPA via front-end and also perform the task via API call.
As you can see in the picture below, our first process was to make a post on a Facebook page. The RPA robot starts by opening the browser with the URL, makes the post, and the process ends when it logs out of Facebook.
In the second process, the RPA robot has to log in to get data from the database and finish it by sending the data in an email to the manager. Whereas the third process is a simulation for maintaining GDPR rules. So the robot logs into your CRM system, finds and selects the record that needs to be taken out, deletes it, and sends out a notification email saying that the action has been completed.
All three processes are run on the front end and via API on the crucial platforms for RPA - Automation Anywhere, Blue Prism, and UiPath. We ran each process ten times, making it 180 runs in total.
After using the Pointee deep analysis tool, we got the results which you can see in the table below. You can see the aggregated results from each platform. At first glance, it is pretty evident that using API in RPA automation works in your favour, as the difference in runtime is more than 90% for the two processes.
|
Process |
AVG GUI duration (s) |
AVG API duration (s) |
AVG difference (s) |
AVG percentage change (%) |
|
P1 |
26.9 |
2.6 |
-24.3 |
-90.3 |
|
P2 |
21.5 |
3.4 |
-17.8 |
-84 |
|
P3 |
25.5 |
2.1 |
-23.4 |
-91.9 |
Source: Průcha & Skrbek, 2022 (Original Research)
But that is not the only indicator for us to make our conclusions. We noticed that API and the front end behaved differently during the development phase. After the API process was set up, everything went smoothly. However, the front-end automation often ran into trouble, especially with changes on the front end or with pop-up windows. Any change in the front-end automation made it challenging to operate without glitches.
Other key findings:
- API is probably more complicated for citizen developers to use.
- The build time of API or FE automation on our simulated process was almost the same.
- Enabling the API in the administration of APPs was complicated, and the initial cost was high. Over the period of time and usage, the cost decreases because the infrastructure is set up for using the API calls as well, not just in RPA automation.
So, in our conclusion, we can say that API and RPA can be terrific friends. A dynamic duo - might we say!
Subscribe to our newsletter and stay updated with the latest topics and industry trends in intelligent automation.
Sources:
https://link.springer.com/chapter/10.1007/978-3-031-16168-1_17
