We need to add one more robot, can we?
Usually this is what happens: at some point you would need to add more robots into your process automation. But, are there any alternatives? Maybe no more robots should be added?
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 it. 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 an 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.
What is Hyperautomation?
Hyperautomation is an approach to automatation in which the right tool is chosen for each job. The modern iPaaS does have the ability to run processes concurrently in a single execution engine (like Frends Agent or Dell Boomi's Atom - no 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 Machine Learning engines or UiPaths built-in OCR (Optical character recognition) 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 as 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.
Four most common problems in the RPA approach
Problem 1: RPA robots don't scale.
Symptom 1: Constant need for new RPA robots thus increasing costs.
Symptom 2: Your RPA processes are "running late" as robots are queueing the work instead of doing it concurrently.
Solution: Use scalable 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 1: The TCO of RPA grows due to the increasing maintenance costs of constantly breaking RPA automation.
Symptom 2: Constant changes and upgrades require constant re-recording thus increasing costs.
Symptom 3: Constant uncertainty of what processes are truly successful and what has failed in the RPA solution
Solution: Use an 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 1: 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 2: 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 solutions compile the automation to be executable thus thousands of times faster than recording.
Problem 4: RPA robots are not for large volumes.
Symptom 1: 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).
Read more about Frends enterprise iPaaS and Hyperautomation from here.
If you are interested in the Frends and Hyperautomation solution, don't hesitate to contact us