Hi,

I have worked with a number of customers and partners in Japan who consider introducing BPM and RPA for automation, and through its interaction I had a chance to sort out my thoughts around BPM vs RPA discussion. One of my customer’s questions was, "Some of the functionalities are shared between Pega Platform and Pega Robotics. For example, both software can send a notification e-mail. Which technology should we choose over the other, and why?". Another partner has built everything (logics and workflows) in Robotics and Pega Platform is only used to call the robots. I believe that these questions or wrong implementation design come from the lack of clear distinction of BPM and RPA concepts. It’s important to understand their individual capabilities and limitations. In this post, I will try to explain their true essence, underlining what makes them different and what may turn them into ideal partners.

• What are the differences between BPM and RPA

While both BPM and RPA help you implement organization-wide digital transformation seamlessly, they are distinct in their ways. BPM is a holistic approach and an end-to-end solution for streamlining and reengineering underlying business process to improve enterprise efficiency and productivity (process-focused). BPM platforms are deeply transformative, and therefore requires an eye for the big picture and high-effort, offering a long-term returns.

On the other hand, RPA is a software-driven approach, designed to complete monotonous, routine, and time-consuming tasks in order to save time so that employees can focus on more important and complex tasks (task-focused). RPA empowers non-technical users to create "bot" to mimic human activities such as logging into IT systems and copying and pasting data across systems. RPA tools can be quickly and easily integrated to work with existing application (short-term returns), without requiring an overhaul of organization’s IT system or corporate culture.

• Case studies

Here let me talk about one of my customers who introduced BPM system built on PRPC v6 back in 2013. However, the hype for RPA has grown massively around 2016, and the simple-to-use tools have pushed this company in trying to solve everything with RPA. They replaced their entire business process with UiPath and WinActor across organization. A few years later, they ended up with producing many “stray robots” (that’s what Japanese customers call unstable and hard-to-maintain robots) and it had led to many failed projects. According to Ernst & Young, as many as 30-50 percent of Robotics projects fail globally. The reason for this is that many organisations misuse the RPA solutions that they have purchased, often due to the vendors adding more features and functions that take robotics away from its original key benefit. Fortunately, this customer came back to Pega again for help (right choice!) and we had assisted them to rebuild their business process with Pega Platform v7 and Robotics in 2018. This approach went well this time and improved efficiency and their overall return on investment (ROI) from their spend.

• How should we use BPM and RPA

A common misconception is that both BPM and RPA automate business process in a similar manner and which solution to use does not really matter - this is not correct. Most of RPA software has a canvas in IDE where you can draw a workflow just like BPM platform, hence they look alike and may confuse you, but RPA’s focus is to deal with smaller, repetitive tasks completed that just comprise a part of a business process. It is more of a surface-level fix and it doesn’t aim at optimizing processes while BPM is used to automate complete end-to-end process in a broader perspective. RPA can be part of a BPM approach, but it can’t replace BPM.

There are best practice guidelines which need to be considered when deciding where to put the effort, BPM or RPA. An end-to-end process is never either RPA or BPM. It is important to remember that BPM and RPA are meant to be complementary, rather than competitive technologies. While both solutions have their respective merits, they work best and provide the most benefits when used together. So, if you are really looking at end-to-end automation, then you will always be using a mix of both, but you should always start with BPM. The important phrase here is "end-to-end automation". If you are only looking to automate simple tasks on the desktop, like a cut and paste from one system to another, then deploying an RPA only solution might be a valid solution. However, these use cases should be few and far between if we are looking at the complete end to end journey because they rarely add enough business value to justify the investment and TCO.

• RPA usage should be limited to simple integration tasks

I have observed multiple system integrators in Japan misused RPA and it had led to a complex IT architecture as business rules and process flows had been embedded into robots rather than being externalized for the whole business architecture to use. This is not a correct approach. Business rules and processes should go into the BPM platform and the Robot can simply do the integration task. As I stated earlier, a robot should replace time-consuming tedious tasks that are carried out by a human, and these tend to be taking data from one system and adding it to another, traversing multiple systems to collate information. Although there are other valid fringe use-cases, Robotics should primarily be used to replace this "integration" tasks. One of the major challenges with BPM is accessing existing systems. Unfortunately, many organizations still use legacy systems or mainframe that do not have APIs, or even if they do, these APIs don’t provide all the necessary data for a particular process or use case. As a result, enterprises are left with the costly and sometimes high-risk choice of developing new APIs or replacing the applications themselves. It is difficult for BPM to handle such situation, but RPA can let developers easily automate data entry / retrieval so enterprises can side-step a missing API and deliver value faster.

• Don’t start with RPA

Just because RPA can doesn’t mean that you should. This is often the case when manipulating files, reading from Excel or listening to inboxes via Outlook. RPA has the tools to build automations to handle these scenarios, however, these are better implemented using BPM. The reason for this is that a platform like Pega has more advanced features to handle these interactions with better error handling, auditing and exception management than a Robotics solution. As I stated earlier, RPA should be seen as a "short-term" solution, like Band-Aid. By integrating into legacy systems, enterprises are implicitly adding to the cost of supporting these old applications and building in a dependency on these systems into your future application eco-system, when really most businesses want to look to replace legacy applications. Another suggestion is to avoid Excel from being part of the process. Most organisations today handle critical elements of their business processes in Excel. In many ways Excel is a victim of its success, however if you are looking for robust enterprise strength automations Excel should form no part of it. If you have a process where you are looking to incorporate Excel, then stop. Whatever Excel is handling should be transferred into the BPM solution.

This post outlines best practice, not a strict set of rules. Like all things it needs to be used in context and with an awareness of other business and technical considerations. For example, some companies in the early stages of digital transformation may choose to begin with targeted RPA tools to address their biggest bottlenecks, and then work toward a more complete BPM integration in the future. That is a valid approach. As their BPM platform expands and its strategy matures, we believe that organizations will realize the highest ROI and drive end to end automation with the lowest TCO by creating simple, integration-based Robotic Automations and leaving the BPM platform to handle the UI, Rules, Process Management, Data Management and API driven integration.

* I've also posted more concrete documentation regarding how to integrate with two popular RPA software in Japan. Please see https://collaborate.pega.com/discussion/how-connect-uipath-orchestrator for UiPath Orchestrator, and https://collaborate.pega.com/discussion/how-connect-windirector for WinDirector.

Hope this helps.

Thanks,