Blog Posts Case Management Process Management Process Modeling

RPA / BPM Implementation Strategy

Blog: Collaborative Planning & Social Business

There is a broad misconception that RPA about “business process” by itself. I have heard people say that they were going to switch from BPM to RPA. That is strange because the capabilities are quite different. It makes sense to use RPA and BPM together, and sometimes you can use one without the other, but only to solve different problems.

Definitions

RPA – Robotic Process Automation – a software system with the ability to access another software system using the user interface with the capability to enter data into that other system, or extract it out.
BPM – Business Process Management – a software system designed to represent the flow of responsibility through an organization and to deal with the complexity of involving humans into a process.

Yes, they both have the word ‘process’ in them, but neither of these should be confused with an “Operating System Process” which also uses the word. Process is a very general term saying that multiple things get done in a particular order, and all three of these accomplish a ‘process’ to some degree. But there are big differences in the types of process that can be implemented.

Similarities

Both allow a kind of automation. Both carry data for a specific instance. Both can send and receive data to other systems. Both offer a graphical representation of the automation.

Diagram Differences

The style and capabilities of the diagram are completely different. Below you see a typical RPA-style diagram.

What you are seeing is boxes that represent things that the RPA tool will do: login to salesforce, search contacts, create CSV file, and notify user. There are branch conditions that allow you to get the RPA tool to do different things in different conditions, and to implement loops and such. It is a programming language for telling the RPA tool what to do.

The RPA diagram represents automation. In such diagrams, the boxes represent operations and there can be branch nodes, etc. It is a style of visual programming, but what is missing is the representation of people and roles. RPA can access existing software systems, and can send or receive data through the web interface that a human normally uses. It does log in as a person, and could log in as many different people, but the diagrams do not represent the “roles” or “skills” that a person would require. While RPA is meant to replace people doing menial key-entry type jobs, the diagrams have no representation for assigning a task to a person to do. RPA does not provide a worklist that people can log into, to claim their workitem, and to tell the RPA system that you as a human are finished working on something. There is no way to represent the flow of responsibility through the people of an organization.

The most telling is the “Notify User” step in the diagram above because you see users are not first class concepts in the diagram. What you can not do is to pick a box in this diagram and designate in any way that “Sally” will be responsible for doing that step, and that “Joe” will do the following step. There simply is no concept in this diagram about assigning work to users because this is not a diagram of work distributed through an organization. This is just a visual programming language for the RPA tool to perform. As a robot.

Compare to a process for a BPM system:

Here you have tasks, but these are designed to be done by people. The task “Reproduce Problem” is a quality assurance task that can not be automated, but instead requires a human to do it. This process is showing the flow of responsibility between three roles within the organization, and each swim lane represents not one person, but a class of people who have particular skills.

Not shown in this diagram is how those people are informed of their tasks, how they search and find a suitable one, how they claim the task. There is no step showing “login” or any other trivial system interaction. What is not shown is the deadline to get the task done, nor the reminder they get if the dead line is passed. Notifying users is an inherent part of the system, and does not need to be explicitly modeled. What is not shown is what happens if a task is reassigned from one person to another when halfway completed. You can’t in this diagram see any logic to cope with daily shifts, human work scheduled, and vacation schedules.

Most important: the RPA diagram shows what the RPA system will be doing, while the BPM diagram shows the flow of responsibility between humans without getting bogged down in the details of how this coordination is accomplished.

Misuse

You can use RPA to implement a business process, but you can also use Java, email, or Excel to implement one as well. You can theoretically use any programmable system to implement this. The question is not whether it is possible, but whether it is the right fit to be easy to implement and easy to maintain in the long run.

RPA might be able to implement a “straight through process” where no humans are involved, but it has no facility to represent a process where people need to participate and make decisions.

One could re-implement the responsibility flow capabilities from scratch in the RPA tool: implement worklists, vacation schedule logic, reassignment logic, notification to people, and reminders to people. The point of course is that these capabilities are built in to a BPM system and you don’t have to reinvent it as explicit logic which is copied from implementation to implementation.

Working Together

What makes a lot more sense is to have a BPM based “work distribution model” which is a representation of the skills and capabilities of the people involved in the business, and distributes work to them. And then, on individual tasks, you can automate SOME of them with RPA where the person was primarily employed to enter or extract data. Some RPA is deployed standalone to completely replace a user, and in other cases it is deployed in “attended” mode where the RPA helps replace some of the routine aspects of the work, but does not entirely replace the humans.

Hopefully this helps clarify the role of both technologies. Clearly the future lies in systems that can handle both aspects: the RPA (replace humans when using a web interface) and the BPM (distribute work to humans) but it is important to understand the differences that exist today in the current implementations of each.