Do you think RPA (Robotic Process Automation) is the path to pervasive automation? Are you suffering from the Total-Cost-Ownership of RPA getting too high? You may be using a hammer when a screwdriver is needed.
The process automation scene evolves fast. In this article, Antti Toivanen, our Integration fellow, describes the two major approaches to automation and how to get the best of both worlds.
What is process-oriented automation?
Process-oriented automation or Business Process Automation (BPA) automates what the abstract process should do. It does not simulate what humans would do, but it executes the actual predefined business process or its technical parts. For example, the simplified Order-to-Cash (OTC) can go like this:
- Receive Customer Order
- Validate Order with rule-engine
- Upsert Customer order to CRM (Upsert = insert if new or update existing)
- Credit Check via API
- Order Entry to Line-of-Business (Lob) System via API
- Order fulfillment (wait for LoB)
- Trigger the Order shipment process via API and send the transport order to the logistics partner via API.
- The purchasing party received the ordered articles and confirmed them via API. Update order status in LoB and initiate invoicing process.
- Wait for the "Order Invoiced" status
- Payment Received - update Lob and end.
This kind of process automation can be done with BPA capable iPaaS (Integration Platform as a Service), like Frends enterprise iPaaS that I used to draw the diagrams for this article. Note that in the Frends BPMN2.0, a diagram is also an executable code. Each Order -instance can be visually monitored with all the data that went through - or caused an exception. With an iPaaS, the process may be triggered directly from a website or by the purchasing party's ERP (or integration platform) via API exposed by the iPaaS. The iPaaS or automation platform executes the process using interfaces of the line-of-business system and external interfaces, for example, checking the credit.
Pros
- Robust as interfaces don't change by surprise
- Transparent as modern low-code iPaaS like Frends shows the process execution visually so that business people understand and can interpret without technicians' help.
- Fast execution
- Modern iPaaS scales quickly for thousands of concurrent processes.
Cons
- Process and the systems must be known beforehand.
- Not all systems have interfaces, or the business logic is not available via interfaces.
Tip
BPA capable iPaaS platforms are often capable of also executing process-agnostic automation as part of their orchestration.
Process-Agnostic automation aka. RPA
Process-agnostic means that we do not have to understand the actual underlying process; we simulate the humans that perform it on top-of user interfaces of these line-of-business systems. Let's take Microsoft PowerAutomate, for example.
- Read the Order that came in from order systems UI.
- Validate the Order by checking that the order system does not have an error flag on it.
- Open the CRM and check if the customer exists. If it does, update the new order information; if it doesn't, insert a new customer.
- Login in and check the credit system via UI.
- If the previous step was ok, log in to the Line-of-Business system and insert Order.
- The process goes this way to the end using UIs. You get the point already.
This kind of process is agnostic - meaning that we do not have to be even aware of the business process but simulate what employees already do to execute it.
Pros
- No need to understand how the process runs on top of Line-of-Business systems. No need to get the API information from all the related system suppliers.
- Can access systems without interfaces or APIs.
- Can perform automation within system UI where are no business APIs available.
Cons
- Faster than humans, still enormously slow compared to BPA as UI and underlying OS must be simulated.
- Error-prone to UI changes.
Recorder-based or orchestrated RPA?
In my samples, we orchestrate both of the automation, whether agnostic or process-oriented. Orchestrating in process-agnostic automation means that we do not use the screen recording where the RPA tool tracks mouse movements and clicks on the screen. Instead, we orchestrate the employee's steps via the RPA tool. The RPA tool finds the right field or button by its technical name that is not visible to the user. The recorder method is the easiest but even more error-prone than orchestration-based RPA. The edit field or button on the screen may change position. UI might get an update — there are tens of more pitfalls that fail your process.
Cost of agnostic and process-oriented automation
The IT department often implements or manages process-oriented automation, and the business unit adopts RPA-approach. Using recorder-based automation, a person can automate a process in hours if they are an expert on that process. Sounds superbly agile? The problem is that if someone, like IT, is to upkeep these, the RPA specialists need the documented process of what to automate, consider exception handling, and all the requirements for process-oriented automation with any iPaaS. When we look at the work estimations of enterprise-level RPA or BPA, the development cost in days is pretty much the same. Some processes are a little faster to implement with iPaaS if all systems included have modern interfaces. Some processes are faster to implement with the RPA tool if business logic is available via UI.
At the early stage of RPA-based process agnostic automation, 1 FTE is generally required to upkeep 5-10 processes (source). The same number for process-oriented automation is 1 FTE for 60-120 automation based on the number our iPaaS 24/7 SLA team handles. The maintenance people are equally professional; this huge difference results from the technical approach. The agnostic approach has more error-prone parts when simulating the human using UI on top of a virtual machine. The TCO of the process agnostic approach is high by design. The following chart illustrates this TCO when the amount of automation grows.
Why then is process agnostic RPA so popular? There are several reasons for that:
- Automation development can start without understanding the process - just simulate a human.
- RPA can automate processes even when there are no interfaces.
- RPA excels when automating user-like processes that line-of-business systems don't have interfaces or API to access.
Hyperautomation
Consider Hyperautomation as an approach to "automate everything". This holistic approach sometimes uses AI to:
- Make decisions within the orchestration to direct the process steps differently.
- Decide what value is the correct parameter for a step.
- Read images and documents into a digital format to be processed by the automation.
The automation level can be much higher by using AI as a part of the process that can make the decisions that humans formerly did. Both processes agnostic and process-oriented automation can utilize AI.
How to get the best of both worlds?
A good approach is establishing a single team, and empowering them with both process-oriented and agnostic tools, and pouring in some AI to automate the last mile where human decisions were formerly needed. Due to the robustness, I would choose the iPaaS to be the central orchestration platform as iPaaS can publish processes as API functions. Then, of course, some processes will be simply simulations of users and can be done entirely with tools like Microsoft PowerAutomate. The important thing is that a single team considers automation as a whole and then chooses the best tool for it.
The fundamental learning is that do not separate these two approaches for the same goal: automation. Got interested? Don't hesitate to contact us.
