RPA hangover? Here are the top 4 reasons for your RPA solution to go wrong

"Our RPA delivery supplier constantly says that we need to purchase more robots."

"Our RPA recordings fail, and the benefits are reduced by high maintenance."

Do those comments sound familiar?

Already for a while, I have heard these and many other comments and complaints from our customers who have walked their RPA journey. So, for this reason, I decided to compose the set of recommendations on RPA uses cases to help businesses to avoid problems:

• when to use RPA;
• when to use an integration platform;
• when to use both as a hybrid solution.

You can find the use-case list at the end of this article. Before that, let's look at what RPA hangover is and how companies end up suffering from it.

BPA vs RPA approach

Integration-platform-as-a-Service or iPaaS is a tool that can run predefined processes directly on top of systems. iPaaS platforms with business process automation (BPA) capabilities do not emulate users with user-interface but access systems directly via interfaces (APIs, file systems, etc.). The screen-scrape below illustrates how this is done with Frends iPaaS Business Process Model Notation (BPMN2.0) standard notation.

Example of the visual BPMN2.0

Best modern iPaaS platforms also include API hosting and management, scheduling, BPMN capabilities, among many other features. Frends also comes with the ability to run, e.g., UiPath recordings within the orchestrations. Using iPaaS with an RPA tool is called hybrid automation. Pour in some AI-based decision making or AI-based reading, e.g., invoice images, and you've got hyperautomation.

RPA tools, on the other hand, tend to emulate a human using a user interface. When emulating the user interface, they also emulate the underlying operating system. This emulation leads to error-prone automation as the user interface and environment around them tend to change without taking those recordings into account. On the contrary, interfaces and APIs change with much lesser frequency, which are taken into account beforehand. The much bigger problem is scaling. If you have to need to run processes concurrently, you need more and more robots. For example, a single execution unit of Frends that we call "Agent" can run hundreds of processes concurrently. Still, robots - you need an individual robot for every concurrent process you have. What if you need to run 50 concurrent processes? You'll need 50 robots or one single Agent. I've read and watched several "myth buster" articles and videos that say that robots do scale. Technically that's true, but the cost of scaling is unbearable - as will be the cost-of-ownership due to the heavy maintenance recordings need.

Yet, there are many use-case scenarios for both approaches - and for a hybrid approach, iPaaS orchestrates RPA recordings as part of BPA.

Why do companies end up with the RPA hangover?

RPA has been at the top of the hype cycle for a while now. Everyone got one, so there is often a human need to be as advanced as others. The benefits of RPA are there - it saves money, makes processes not relying on humans during, e.g., pandemic, increases happiness as the most mundane routines can be left to robots. All of these benefits have been accessible for decades via BPA with one exception: the citizen automator/integrator approach democratizes the automation of own work - something that has been the privilege of tech-oriented employees. The major thing for overusing RPA is very human: it is easy for non-tech people to understand and grasp the concept that we replace a human with a robot. BPA, on the contrary, requires understanding the abstract non-tangible process and the interfaces it requires. Never underestimate the power of simplicity - even when it does not lead to the best solution for the need.

Symptoms of an RPA hangover and how to avoid them

• One morning, you notice that you have an army of bots with a substantial annual price tag;
• You might notice that the bill from operating these bots is exceeding the profit gained from automation, and that bill is constantly increasing;
• You have to adjust and schedule your process executions based on when your bots have free time;
• People are blaming bots when a critical process halts or fails.

To avoid these kinds of problems, go for pervasive automation. Think iPaaS and RPA as a tool in an automation toolbox:

• When automating anything - remove the first letter from BPA and RPA and consider it as a whole: Process Automation.
• Ensure that a team or a person is responsible for choosing the right tool. Remember, you can always do hybrid, meaning that the development team can embed recordings in orchestrations in iPaaS.
• Ensure that team or person has enough understanding of the capabilities of these tools.
• Go for joint teams - not a separate RPA team and integration team.
• Ensure that your recordings are small and clear pieces - glue them together with iPaaS orchestration as they have much more robust access to APIs and interfaces than, e.g., RPA tools.

When to use iPaaS BPA, RPA or hybrid?

Here are some use-cases that we have come across during our Frends and UiPath hyperautomation deliveries:

1. The system that needs to be accessed does not have interfaces - go for a hybrid. Remember, e.g., legacy system integration via recording can be embedded into an orchestration of the iPaaS as a small independent recording.
2. The system interface cost is unbearable - go for Hybrid and access the greedy system supplier's system with RPA recording. So yes - sometimes the APIs and interface do have a separate price tag on them.
3. The task is something that includes, e.g., several Excels and alike. Go for RPA - these are the citizen automator tasks.
4. The business logic is only accessible via pressing a button on a system - go for a hybrid.
5. Data volumes are high - go for iPaaS.
6. There are lots of concurrent executions of the same process - go for iPaaS.
7. The automated process includes only systems with modern interfaces - go for iPaaS. Note that this is the case very often.
8. The automated process includes a system that is at the end of its life. So go for Hybrid or RPA, depending on the case.
9. There are many if-then-else and other logic in the process - go for iPaaS as RPA tools tend to slow down on these cases.
10. The solution needs complex scheduling or specialized triggering - go for iPaaS with abilities in these, e.g., Frends.

I hope you find these experiences insightful. Don't hesitate to contact us to discuss this topic more in-depth, or if you would like to have a consultation on your RPA journey!