Each month, through our partnership with Harvard Business Review, we refresh our resource library with five new HBR articles we believe CIOs and IT leaders will value highly.
Robotic Process Automation (RPA): 6 things people get wrong
To avoid trouble with robotic process automation projects, explain these common misconceptions to your team – and to executives supporting your RPA work
You have a variety of factors to consider when identifying opportunities for robotic process automation: If a process is predictable, repetitive, and high-volume, for example, it might be a prime candidate for RPA.
However, due to high expectations – and sometimes misplaced hopes – some people veer off the path to a successful RPA initiative before they really get going. When this happens, it can be the result of a basic misunderstanding about what RPA is or how it works.
[ Making the case for RPA in your organization? Learn how to explain RPA in plain English. ]
By debunking misconceptions up front, you can avoid unnecessary detours. You will want to explain and emphasize these misconceptions with your team – as well as executives up the chain who are evangelizing your RPA project. So let’s consider – and clarify – six things people often get wrong about RPA.
1. “RPA improves business processes.”
RPA automates processes. If those processes need to be improved, though, you have to do that work – RPA won’t do it for you, and automating a flawed process isn’t productive.
“As companies look to digitally transform themselves, they are looking to streamline and modernize processes,” says John Thielens, CTO at Cleo. “While RPA perhaps can be viewed as a form of streamlining, it streamlines processes in place, but by itself does not necessarily improve them.”
Thielens notes that this misunderstanding can occur in organizations that are looking for process improvements as part of a broader digital transformation; they might see RPA as a solution to process woes when it’s better looked at as a tool for achieving new efficiencies and productivity gains with well-established processes.
There’s a related mistake people make with RPA: Automating a process you don’t fully understand. Eggplant COO Antony Edwards recently told us that this is a common pitfall: “Most people don’t have clearly defined processes, so they start automating, and either automate the wrong thing or get lost in trying to reverse-engineer the process.”
2. “RPA notices aberrations.”
One of the key characteristics of good use cases for RPA is highly rules-based and predictable processes. RPA doesn’t do variability well; in particular, RPA is typically not going to raise its eyebrows when something unusual occurs. It’s going to plow forward, at least until the point that its instructions hit a wall, with no questions asked. That kind of alertness for weird stuff can be programmed, but it’s not easy and it’s certainly not automatic.
“When human beings are working in a repeatable process, even unconsciously they apply a level of sanity checking on the work they are doing and can raise alarms and ask questions when something in the process is anomalous,” Thielens says. “This kind of anomaly detection can be modeled into RPA, but takes a deliberate effort to capture.”
Thielens points to a 2008 academic study on spreadsheet errors, conducted by University of Hawaii professor Raymond R. Panko, as an example of how hiccups can lurk in even the most mundane contexts. (One of the study’s bottom lines: Spreadsheet errors are much more common than people probably realize. In fact, it calls them “pandemic.”)
“Many RPA efforts involve working with spreadsheet-powered processes, but spreadsheets themselves are often fraught with errors,” Thielens says. “[The Hawaii] study illustrates this point in astonishing fashion.”
3. “RPA is flexible as our situation changes.”
On the contrary, Thielans notes that RPA can be quite brittle. By this, he means that RPA is not good at change, even small change.
“As dependent systems change, RPA-powered processes may not be able to absorb the small changes that human beings would absorb without noticing,” Thielens explains.
This can run antithetical to many of the tenets of digital transformation and IT modernization in general, not to mention the culture of DevOps: In the simplest terms, they’re all about change, and RPA needs typically needs to be re-tuned to handle even tiny changes. Not taking this into account can set up RPA for problems, because it’s not adaptive.
“Part of the digital transformation and modernization effort should involve updating software governance policies to apply updates and changes more frequently – frameworks like PCI and good security practices mandate it in fact,” Thielens says. “So RPA is not one-and-done and the dependency management can be more costly than expected.”