Robotic Process Automation: What Could Go Wrong?

By admin, 9 January 2018

Robotic Process Automation (RPA) has stormed to the forefront of enterprise technical roadmaps in a remarkably short time. Every company seems to have a dedicated team looking for routine human processes, like copying and pasting data from spreadsheets, that can be done more accurately and less expensively by software robots. The idea has been around for years, embodied in products like web crawlers and automated quality test systems, but it has recently gone mainstream, with dozens of products and hundreds of vendors.

To understand the appeal of RPA, let’s compare it to its less popular cousin, Business Process Management (BPM). A typical BPM project seeks to standardize the workflow of a business process, such as handling a customer complaint, from start to finish. Some of the stages may be handled by software, while others may require human intervention, e.g., getting approval from a manager. At every stage, the BPM process decides what should be the next step based on the result of the previous step. As you can imagine, such a process can take a long time to analyze and define within a given BPM tool, and even more time to debug all the possible states and paths along the way. By contrast, an RPA project has a far more modest goal: to automate one single step in a process, so that a software robot can replace the human being who currently performs that step manually. In some cases, this may require some Artificial Intelligence (AI), to simulate the decisions a human would make in performing that step. But, RPA projects are far shorter than BPM projects and provide a much quicker return on investment.

Now that RPA has gone mainstream and has had (many) successes and (a few) failures, it’s time to step back and try to understand what can go wrong in an RPA project. Here are some anti-patterns and danger signs:

Poor understanding of the business process being automated: If you don’t fully understand the current process, you cannot automate it, so don’t cut corners on the Business Analysis (BA) phase.
Changing the business process as you are automating it: The temptation is huge to make a few improvements to the process as you are automating it, but the result is a moving target that may never converge into a working robot. And, how can you be sure your untested improvement is actually a better process?
Lack of cooperation from humans whose jobs may be automated and made redundant by RPA: It’s hard to automate a process if your only sources of information about the process have decided you are the enemy.
Creating a fully-automated process with no kill switch: A software robot must be smart enough to know when it has to give control back to human beings. Take the example of automated stock trading – on more than one occasion, software robots have all arrived at the same conclusion that it is time to sell and caused the stock market to melt down. Or, consider SkyNet from the “Terminator” movies.
Trying to implement Artificial Intelligence from the start, before you fully understand all the possible states and error conditions: You are better off automating a subset of the process that does not require AI, then expanding the automation to include successively smarter AI, as you learn more about the robot’s real-world behavior.
Eliminating all human understanding of the automated process once the automation is complete: Processes change over time. When you need to modify the automated process in six months, you will need organizational knowledge of the process and how to change it. Otherwise, the change will require an archaeologist rather than an architect.
Neglecting to make the robot enterprise grade: Just because the robot runs doesn’t mean you are done. How will you ensure the reliability and scalability of the robot? How will you deploy new versions? How will you track whether the robot completed successfully or which version was invoked? How will you orchestrate the execution of a team of robots that need to run together to accomplish a business task? You’ll need answers for all these questions in order to deploy an enterprise-grade robot.