Last week, Robotic Process Automation (RPA) was presented as transformational technology because it opens up workflows beneath ERP scale to automation benefits. But what about Business Process Management (BPM)? This post compares the two technologies and looks at which should wear the return-on-investment (ROI) crown.
Widespread adoption of BPM technology began almost ten years ago, combining business rules and data into workflow automation across roles and systems, and delivering functionality for process modeling, complex rule generation and pre-built integration tools. As it was ten years ago, at the heart of BPM systems are engines for business rules and processes. These engines orchestrate and monitor the automation flow across business processes and associated interactions. Capabilities have grown to include sophisticated analytics, in which business rules are used to evaluate streams of multiple events to determine if any patterns or relationships exist between events and, if so, what options for optimization exist as well.
Distinguishing Between RPA and BPM
There are two primary points of distinction between robotic software and BPM.
Business Logic vs. Presentation Layer Integration: BPM functionality is based upon business logic integration. For the purpose of this discussion, the scope of business logic is:
Data – rules for values or attributes must be entered and stored, along any role-based stipulations.
More Complex Data – rules for values or attributes that must be created by rules or formulas.
Processes – coded instructions that run without human intervention and do not involve complex flow control (think month-end batch runs).
More Complex Processes – coded instructions that run without human intervention and involve extensive flow control statements for dependencies, what-if’s, queuing, etc.
This integration is very tight, with process integration going directly from application events in one process directly – without human intervention – to sequential events in another application. The integration also touches various databases in the course of executing automation processes – something that requires high security compliance.
Robotic software, in contrast, is only capable of loose integration – primarily on the presentation level. This reliance on presentation layer integration is why the technology is often described as mimicking human behavior. It can literally map the step-by-step actions of a user as data is extracted and either placed into another application process or into a series of calculations.
This loose integration also means that RPA process automation does not touch database schemas. While UiPath process automation products can integrate on much more than just the presentation layer, data extraction or insertion is done on the presentation level – meaning that automation can be implemented without encroaching on any IT security policies or processes.
Complexity: the BPM rules engine and process engine is able to accommodate both highly complex business rules and logic, as well as business environments in which frequently changes are the responsibility of business analysts. An example would be health insurance claims processing. Adjudication rules generally change significantly, with different regulations or products for each new open enrollment period, and experienced claims processing specialists are required to model and finalize such changes.
RPA, on the other hand, is most effective automating highly repetitive, rule-based workflow. While the technology can handle business processes with complex flow control requirements as well as sequential and event-triggered workflows, it does handle constant rule changes efficiently. What is does well is quickly mimic user steps, and then almost instantly scale up to dozens or hundreds of automaton instances.
The ROI Advantage
For the purposes of determining which technology has the potential to deliver the biggest ROI, the decisive factors are data; complexity and scale.
Data: while BPM data integration is relatively straightforward on a conceptual level, it is often an extremely difficult, time-co
nsuming and risky proposition on the project level. The reason is that most large organizations have several data silos and no reliable book of record by which to cleanse and rationalize them. For example, most large insurance companies have an extensive history of mergers and acquisitions – each of which brought in new databases, few of which have been integrated. In order to implement BPM, a data ETL project must be executed first.
Robotic automation, because it does not touch data schemas, neither adds to nor detracts from any existing data quality issues. It simply uses current outputs in the same way that business users are already doing.
Complexity: while BPM systems have the capability to handle complex business rules and logic, the users with the greatest business knowledge typically can’t implement them without extensive system training, a distracting activity that will pull their valuable skills away from existing responsibilities.
The UiPath product, on the other hand, employs a highly intuitive product that leverages features such as drag & drop, macro recorders and out-of-the-box automation wizards to achieve productive results in one or two days.
Scale: a BPM system requires a large scale automation footprint to justify the costs, risks and related projects (e.g. data cleansing) of its implementation. While those footprints exist, they tend to pale beside the cumulative number of smaller, less complicated and more repetitive business processes that fit robotic process automation.
Because of these advantages in data, complexity, and scale, robotic process automation has the greatest potential for achieving a high ROI. Fortunately, the two technologies are mutually exclusive, so there is distinct possibility larger companies will find themselves deploying both.