5 reasons RPA deployments fail

Robotic process automation (RPA) promises to deliver business benefits such as decreased costs, reduced errors, greater efficiencies, and the ability to free up workers from mundane and repetitive tasks such as data entry so they can focus on more challenging, strategic initiatives.

Enterprises are increasingly embracing RPA in pursuit of these benefits, and industry research predicts an ongoing rise in demand for the technology. A 2018 report by research and consulting firm Grand View Research says the global RPA market is expected to see at a compound annual growth rate of 61 percent between 2018 and 2024.

Increasing demand for business process automation through the use of artificial intelligence (AI) and software robots is anticipated to be a key trend for market growth over the forecast period, the firm says.

RPA enables organizations to automate virtually any business process, and its ability to learn skills while consistently carrying out functions is expected to drive market growth, the report says.

Companies in a variety of industries are indeed seeing positive results from their RPA deployments. A 2017 survey of more than 400 organizations worldwide by consulting firm Deloitte showed that for companies that have deployed RPA, payback was reported at less than 12 months. RPA was meeting or exceeding expectations across multiple dimensions, the report said, including improved compliance (92%), improved quality/accuracy (90%), improved productivity (86%), and cost reduction (59%).

There are no guarantees of success, however. RPA implementations, like other technology initiatives, can fail for a variety of reasons. This relatively new technology has the potential to create upheaval in work processes and company culture. Here are some of the ways RPA can fail, and how organizations can address these potential pitfalls.

Management hesitation

It makes sense that any technology with the potential to replace human workers will introduce both controversy and questions as to how the technology will work and interact with staff.

“One of the most common reasons [why RPA fails] is less about technology and more about people,” says Frank Casale, founder of the Institute for Robotic Process Automation & Artificial Intelligence (IRPA AI), an independent professional association and knowledge forum for the buyers, sellers, influencers, and analysts of RPA.

Half of the proofs of concept that are conducted for RPA go nowhere, Casale says, because management is not ready for change. “This is indeed disruptive technology, and most do not want their business

disrupted,” he says.

So while the technology might prove itself out during an evaluation stage, the decision makers decide to pass on RPA tools for the simple reason that they are not yet ready to adopt them.

Why the hesitation? That depends on the organization. It might be because of the human resources implications, uncertainty about putting processes into the hands of software instead of people, or some other reason.

Lack of training

If organizations don’t spend enough time getting staff trained or educated about RPA tools, and rely on too few resources to get everything accomplished, RPA projects are more likely to fail.

“It’s critical the organization develop a broad base of individuals with sufficient knowledge of RPA, such that they can be effective in identifying and evaluating automation opportunities,” says Angelo Poulikakos, a director with consulting firm Protiviti who specializes in technology risk, RPA, and IT audit and compliance.

All of the major RPA providers are creating their own “universities” or “academies” with high-quality training on both the technical and non-technical side, Poulikakos says. But companies to a large degree are not leveraging these resources.

“Oftentimes, there’s an over-reliance on a handful of people within the organization, and those individuals are likely the same ones that invested the time to get smart,” Poulikakos says. “As part of the RPA journey, organizations need to make sure RPA training becomes a priority for anyone who wants to be involved.”

Part of the education process is making sure business sponsors and support teams are truly aware of what RPA can do and what typically makes a good candidate for automation, Poulikakos says. This means spending time with them up front to give them a brief RPA awareness training session before diving into a specific project.

“Once you give your business sponsors a better appreciation of what the technology can and cannot do, then it’s easier to establish common expectations and work together to identify suitable candidates for automation,” Poulikakos says.

Building up in-house RPA expertise and having close cooperation between technology and business managers in RPA projects can lead to fast results and an immediate business impact, adds Andrea Martschink, head of robotics strategy, business development and projects at the IT enterprise content management department of conglomerate Siemens AG.

Wrong use cases

If the use case selected for the initial RPA proof of concept or pilot is too complex, that leads to slowdowns in the project, Poulikakos says.

Or if the use case doesn’t create enough of a “wow” factor, it will not fuel the buy-in needed from executives to ramp up production efforts, he says.

“There has to be a balance between starting small but also starting smart,” Poulikakos says. He’s seen situations where a company selected a use case in accounts payable (AP) that offered a significant return on investment (ROI), but it involved a fair degree of unstructured data and required optical character recognition.

“The company spent a lot of time trying to find an RPA partner to get this process off the ground, and ultimately determined they were better off going with a dedicated AP automation solution, not RPA,” Poulikakos says. “At the same time, I’ve seen companies successfully automate relatively simple processes in a short timeframe, but unfortunately not produce a favorable ROI or other compelling benefits.”

It’s important to strike a balance between the potential complexity of the automation and the benefits — whether that be financial ROI, increased efficiency and effectiveness, or improved customer or employee satisfaction, Poulikakos says.

Sometimes organizations are in a rush to automate processes without sufficient evaluation of automation candidates, Poulikakos says. “Avoid the urge to automate everything,” he says. “RPA will not fix broken processes; it’s quite the contrary actually.”

Often the pursuit of automation uncovers significant opportunities to implement process improvements that can not only result in increased automation potential, but also result in increased effectiveness, Poulikakos says. “The first handful of use cases are the most critical ones, because they will often make or break the momentum associated with the technology,” he says.

Excluding IT and security input

Even though RPA directly impacts IT-related processes, some organizations might not think to involve IT or information security managers in the deployment of these tools.

But ideally IT and security should be involved early in the process, Poulikakos says. “I personally haven’t encountered an IT group that wasn’t supportive of the technology, but I have definitely observed tension when the IT department or CISO realize that such-and-such department was building bots without any of their involvement,” he says.

IT is a critical component to building a sustainable and secure model that isn’t entirely dependent on third parties, “especially when you consider the longer-term maintenance of the RPA infrastructure as well as the individual bots that get developed,” Poulikakos says. “IT and security will be much more cooperative when they have a seat at the table at the front-end.”

If IT does not have a clear picture of the business requirements and IT experts lack the specific RPA know-how, “frustration is very likely to happen on both sides,” Martschink says.

Siemens launched an RPA service in October 2017 that is now available worldwide within the company. The platform enables structured and unstructured information such as text, speech, files and email to trigger an RPA bot. The bot is used to automate a variety of tasks.

IT and security staff need to be involved in RPA initiatives not only during the set up phase, but also for ongoing support, Martschink says. “Security is very important. It must be ensured that processes cannot be manipulated,” she says.

Excluding the app developers

When developing an automation capability, it’s vital to engage with the application development team that owns the application, says Rex Price, technology capability manager of shared services at

insurance company Unum Group.

The firm has been using RPA since 2016, when it deployed Pega Robotic Desktop Automation (RDA) from Pegasystems to help its contact center automate administrative tasks.

“It’s important to understand the parameters of when the automations can be run in different environments, and if there are any memory leaks or issues with a legacy system where you’re placing the automation,” Price says. “For instance, putting a desktop automation on a legacy system with known issues can fail because the automation will use more memory, which can create desktop timeout issues.”

It’s also a good practice to have a well-defined change control process in place for how changes to systems will be managed and how automations using those systems will be notified of changes, Price says.

“If there’s not a good change control process in place and application changes are made [that] result in automations breaking, it will leave your customers with doubts about the automations,” Price says. “The failure could be because of the source application, but the automation will get blamed for not working.”