Confused About RPA and BPM? You’re Not Alone

Confused About RPA and BPM? You’re Not Alone

Confused About RPA and BPM? You’re Not Alone

Automation has a lot of benefits for organizations that want to get more from their technology and their employees. By automating repetitive tasks, you can get faster results and give your employees more time for work that adds more value to the business.

Of course, there are multiple technologies available to meet your automation needs. Some are better than others, depending on what you want to accomplish. Recently, a debate has emerged pitting robotic process automation (RPA) against business process management (BPM).

The question often asked is: What’s better?

Robotic process automation (RPA) is a software solution where a script, or bot, mimics human actions when interacting with software. The bot does the work so the human can do other things. RPA is designed to execute tasks that require handling large quantities of structured data and interacting with a number of different IT systems— tasks that have traditionally been done manually. Many businesses have experimented with RPA and have found the results extremely beneficial.

Business process management (BPM) is designed to model and orchestrate complex workflows such as multistep processes with dependencies, parallel tasks, and other workflow dynamics.

The question should be: What’s better for my Use Case?

If All You Have is a Hammer, Every Problem Looks Like a Nail

RPA and BPM can both deliver outstanding benefits to companies ready for an automation solution, but they handle automation in different ways depending on what you want to automate and the type of job functions that are being automated.

The key is to apply RPA or BPM according to the needs of the job. Psychology professor Abraham Maslow is famously quoted as saying, “I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.” If RPA is the hammer, it may appear to some that every automation opportunity is a nail.

This enthusiasm for RPA has resulted in over-application: Stringing a series of bots together to create an end-to-end automated workflow. This has been motivated, at least in part, by RPA vendors that are promoting their solutions as enterprise-grade business process automation. It’s not.

The problem with this approach is that RPA wasn’t designed for end-to-end enterprise-grade automation of complex workflows. Its core intent is to execute a task. While you can certainly string together RPA bots to handle a series of tasks for more efficiency, eventually companies hit a point of diminishing returns where RPA fails to deliver, especially when they roll it out across the whole organization, as described in this white paper by Deloitte.

RPA’s Frankenbot Syndrome

While there’s nothing inherently wrong with stringing together RPA bots, the moment you put it out as an end-to-end enterprise workflow solution, you might end up with a Frankenbot, where many tasks and groups of tasks are coupled together with linkages, resulting in a lot of possible breakage points and a lot of management and maintenance. And when the Frankenbot breaks, there’s little, if any, visibility into the process for troubleshooting.

The result is that many business and IT leaders have soured on RPA. Others are confused about which is better, RPA or BPM. The fact is they’re both excellent automation solutions as long as each is applied to the work it does best: RPA to execute specific tasks and BPM for orchestrating complex enterprise-wide workflows, which draws on RPA processes to create an end-to-end workflow solution.

The debate about RPA vs. BPM boils down to the nature of the tasks to be performed and the nature of the worker whose task is being automated. RPA works well for simple workflows that ideally don’t require heavy lifting. BPM orchestrates complex workflows that split, have dependencies, have wait states, or have a number of other workflow dynamics. Oftentimes, at scale, you’ll have a blend of simple and complex workflows.

So, the conversation shouldn’t be about using one or another exclusively. It should be about which tool is best for each situation. For example, you could start with automating productivity activities with RPA and then grow and automate the entire end-to-end workflow with BPM.

Solutions like the IBM Cloud Pak for Business Automation recognizes this challenge by including BOTH BPM and RPA tools within the platform. These can be designed and invoked as needed and this approach solves the Maslow’s hammer issue.

What RPA Does Best?

An example of a workflow ripe for an RPA solution is medical underwriting, where a customer starts the underwriting process by filling out an online form to request a new benefit. This request goes to an underwriting professional, who may need more information than what’s provided in the form. The worker goes to the Medical Information Bureau (MIB) website to capture information about the applicant. This is a manual task done outside of the workflow but is a required part of the application process. Rather than doing it manually, an RPA bot can be used to capture that information from the MIB website. While an Application Programming Interface (API) can do the same thing, MIB may not have an API for this. If medical tests are required to finish underwriting, the underwriter goes through a similar process with another website to order the tests.

So, RPA is a good solution to automate high-volume transactional tasks. For an employee handling transactional tasks on a daily basis, you may be able to automate a high percentage of that employee’s work with RPA.

However, for knowledge workers, RPA typically struggles because of the complexity of the tasks. For example, a professional’s medical opinions couldn’t be automated. RPA is task specific, whereas BPM can handle workflow dynamics such as split tasks, where the workflow branches out to two or more operations running at the same time before coming back to the next step in the workflow.

How RPA And BPM Can Work Together and Scale Together?

BPM orchestration allows you to create a model of these splits, dependencies, and other dynamics, whereas sequential RPA isn’t designed to orchestrate complex workflows like this, although RPA can certainly be a part of the workflow to automate specific tasks along the way.

In addition, BPM solutions like IBM Cloud Pak for Business Automation build on this orchestration capability to give you tools to monitor the activity, get alerts or otherwise prompt human action along the workflow such as viewing or annotating the content and iterating the process if more information is needed. What happens if you do that with RPA? You get a Frankenbot—a potential nightmare that may pass your proof of concept but fail in production when it attempts to scale out.

So, to answer the original question about what’s better, RPA or BPM, the answer is neither is better than the other. They can work together to create scalable end-to-end automation solutions that help you get more from your technology and your people. But for automating specific high-volume transactional tasks that don’t need enterprise-level scale, RPA still works great.

Still not sure what technology to use for your specific business need? VersaFile has established a Centre of Excellence and built a evaluative framework; The Intelligent Automation First Method (iAFM) to assist clients map the correct technology to the correct use case. Get in touch!

Share on facebook
Share on twitter
Share on linkedin
Share on reddit
Share on tumblr
RPA vs BPM

Sign up for future blogs and let us know which Intelligent Automation topics are of most interest to you.

Leave a Reply

Leave a Reply