4 reasons for changing RPA to Hyperautomation

"Hey, we need to add one more robot", says the RPA lead. Sounds familiar? The need for process automation is growing constantly as companies seek more resilient processes and cost-efficiency. To put it simply, human work is expensive, error-prone and vulnerable to e.g. sick leaves as pandemia has cruelly proven. In the "RPA only" approach the constantly growing number of automated processes have led to unbearable total cost-of-ownership. This due to the fact that robots - as they simulate humans in repetitive mundane tasks - scale as bad as humans. The human brain can do only one thing at a time. Yes, some of us seem to multitask and do several things at a time, but in the end, brains do have a single conscious thread that is just switching from one task to another. RPA robots by the way cannot do that - they'll do the task at hand from the beginning to end and then start the next one. So, when you need to automate processes that run concurrently, you'll need more and more robots. A quite common pricing mechanism of RPA suppliers is "per robot" and this leads to a nasty surprise - running just 5 concurrent processes at the same moment requires 5 expensive robots. The bad news doesn't end here - recording humans doing tasks with UIs is a highly error-prone approach: each change in UI or environment makes that part of the recording break. Think of it - if you record a browser-based cloud application - every time supplier internally change something, your recording breaks. If you record mouse movements, we'll that is even more vulnerable to resolution, element placing in UI and that kind of changes.

Hyperautomation is an approach to automation where the right tool is chosen for each job. An automation capable iPaaS or iBPMS system orchestrates the processes. The modern iPaas do have the ability to run processes concurrently in a single execution engine like Frends Agent of Dell Boomi's Atom - no nasty scaling surprises there. For example, a single Frends agent can run 200 processes concurrently in a second where a recording based RPA robot can do one in minutes. In the Hyperautomation approach, we use Frends iPaaS for APIs, integrations and process orchestrations, UiPath for recording based automation when needed and pour in some AI using Azure or AWS ML engines or UiPaths built-in OCR capabilities.

In the illustration above is Frends low-code (BPMN2.0) process automation language. Notice, that the process is actually the logic of an API call. In the pink task, we call outside AI engine to make the next decision. In the dark blue tasks, we execute small separate UI recording automation by running UiPath robots. The recoding executions are tiny and reduced to the small as possible. Still, that RPA automation does pose a risk in concurrency, but a now smaller one than compared to a process where everything is executed via robots. In the real case, the API return is always made before any recording is started thus combining APIs and Hyperautomation into a single seamless solution.

I've composed a list of the 4 most common problems and challenges of the RPA approach and how to solve them with Hyperautomation.

Problem 1: RPA robots don't scale.

• Symptom: Constant need for new RPA robots thus increasing costs.
• Symptom: Your RPA processes are "running late" as robots are queueing the work instead of doing it concurrently.
• Solution: Use scalable iPaas Use enterprise integration platform-as-a-service (iPaaS) to orchestrate your processes in a scalable way.

Problem 2: Recording based RPA is an error and change prone

• Symptom: The TCO of RPA grows due to the increasing maintenance costs of constantly breaking RPA automation.
• Symptom: Constant changes and upgrades require constant re-recording thus increasing costs.
• Symptom: Constant uncertainty of what processes are truly successful and what has failed in the RPA solution
• Solution: Use enterprise iPaas to orchestrate your processes on top of interfaces whenever possible. The interfaces and APIs do change but not by surprise unless communication has failed. Enterprise iPaas, like Frends, do have a full visual low-code audit trail from which even business people can see how the process actually was executed and with what data.

Problem 3: RPA robots have limited capabilities for orchestration.

• Symptom: RPA automation gets very slow when they are trying to solve multiple "if-then-else" branches. For example, if you have multiple content-based decisions to make inside the process this usually occurs.
• Symptom: It is hard or impossible to express complex loops and concurrent execution within the RPA process and visualize them in an easy-to-understand way.
• Solution: Use iPaas for orchestrations. Modern integration platforms and iBPMs systems have developed orchestration capabilities for decades. For example, Frends iPaaS uses BPMN2.0 notation which is much more powerful and standardized than e.g. languages found in RPA tools. Most of the iPaaS compile the automation to be executable thus thousands of times faster than recording.

Problem 4: RPA robots are not for large volumes

• Symptom: Your RPA automation execution time is too long due to the mere amount of records of data that are transferred.
• Solution: Use iPaaS with e.g. ETL capabilities to integrate large batches or use APIs in iPaaS to create a scalable event-based architecture. Robots and recordings are not designed to handle large volumes of data in chunks (files) or volumes of messages (e.g. APIs).

To put it short: use a hammer for nails and a screwdriver for screw - put them both in your toolbox. Here is a real-life war story of how RPA can go wrong: Hold my beer - let's do RPA.

If you are interested in the Frends and Hyperautomation, please don't hesitate to contact me or comment.

Read more about Frends enterprise iPaaS and Hyperautomation from here.