One of the common questions we face at Jidoka during the initial “evangelization” of our customers is to explain the differences between business process automation projects, known by their acronym BPA (Business Process Automation), and automation with RPA (Robotic Process Automation) approach.
For us, there are clearly two important differences:
- In the automation of BPA processes, the objective in terms of scope is to define a new map of processes in the organization, including their re-engineering, technically analyzing the impact of information systems, especially in the area of integration at different levels such as BPM (Business Process Management) or SOA (Service Oriented Architecture). Even from this process reengineering, it is possible to identify the need to develop or acquire new applications or add functionality to existing systems (evolutionary developments).
- In RPA automation the objective is not to change existing processes or systems, or introduce new systems, but to use applications that already exist following the business processes already implemented in the organization. In other words, the systems will be used by software robots instead of the people who would use them regularly. Naturally, when a software robot is introduced into a business process, its operation may change, but these are usually minor changes. What generally does not change are the information systems.
- BPA projects, and more especially process reengineering, are extensive projects requiring months to only obtain a new map of processes and then years for the construction or adaptation of information systems. These projects have a very low ROI. It takes years to recover the initial investment, and that’s if it even provides significant return. There are certain projects that clients have carried out and after years investing a lot of time and money, have not achieved the desired results, ending in disappointment between the client and the supplier.
- The RPA approach takes only a matter of weeks to identify processes to automate, weeks to build, and weeks to deploy. Even though we have a wide catalogue of processes, using an iterative approach, in weeks the customer can have the first operational robot and recover the investment in a few months, with a very high ROI.
Two approaches to achieve the same objective with different strategies and impacts.
At a very strategic level we could think that both approaches have the same objective, the optimization of a company’s business processes, but with implementation strategies and impact on very different systems:
- The BPM (Business Process Management) or SOA (Service Oriented Architecture) approach requires a detailed study of a company’s processes and systems and then a process to create a set of customized solutions transforming the company’s management and providing a solid business infrastructure. Any change or update of the process requires developments and integrations, often made to measure.
- For its part, the RPA approach focuses on well-defined processes that have already been optimized by humans. Working at the user interface level, using existing applications, does not require costly integrations at the level of APIs or databases, so its implementation, in addition to fast, is flexible to changes and updates.
We can say that a BPM solution looks for a new way to carry out processes by modifying or adding information systems, while an RPA solution maintains processes and applications, adding speed and reliability.
Process workflow is a key element in every automation project
Both approaches, BPM and RPA, do share a vital piece in the analysis and construction of the software, the concept of workflow (you can consult here the definition of Workflow according to the WfMC – Workflow Management Coalition) with the following differences: in BPM the workflow is more focused on communication between systems and applications while in RPA the workflow represents the sequence of tasks performed by the human. To supervise the activity of the robot you can use the Jidoka console allowing you to graphically visualize the workflow and the precise task that the robot is carrying out at each moment.
Likewise, the robot programmer also uses the Jidoka console to design the workflow, where each action has a corresponding code sequence that the robot must execute.
Finally, both approaches are not at odds but instead complement each other. Jidoka is a solution that integrates with “screens” but also with client systems via BPM/SOA, using our SDK, as long as there is an API for communication between the robot and the system. Otherwise, the “integration” would be done by imitating the actions of a person, again, by means of a Jidoka robot. At the same time, an RPA project can open the doors to the acquisition of new solutions (such as a CRM/ERP), the need to integrate systems in the BPM/SOA field or even highlight the need for other innovative approaches such as CEP (Complex Event Processing).