For the most part Ernst & Young is very enthusiastic about robotic process automation (RPA), according to a report about the technology in which E&Y wrote: “It promises to transform the cost, efficiency and quality of executing many of the back office and customer-facing processes that businesses rely on people to perform.”
However, in that same report E&Y also made clear that the implementation of what for all appearances is a simple application — many are low or no-code — can be fraught with issues for some companies.
Ernst & Young has delivered RPA projects across 20 countries and is often called upon to help companies when their first attempt failed, E&Y wrote, noting that it has seen as many as 30-50 percent of initial RPA projects fail. There is some good news though, the failures aren’t a reflection of the technology, E&Y said. The bad news, one might conclude then, is that it is the company’s methodologies and misunderstandings about the technology that is at fault. For once, it is the humans that have failed instead of a glitchy, overly technical, overly-priced app.
Automating What, Where and How
Establishing some rigor around the decision about what to automate is one example of how humans fail with RPA. “Because it is relatively easy for a non-technical person to build a simple automation procedure, they just do it on a very ad-hoc basis,” said Jakob Freund, CEO of Camunda. “This works fine if it’s just one person or a few people. But the more people involved, the more this system spreads, and it leads to a shadow IT ecosystem that can cause severe damage to the business when it breaks down.”
Such a breakdown is almost bound to happen sooner or later, Freund continued, since the automated procedures are brittle — for example, they can break when the underlying UI changes — and often there are no automated regression tests in place, “one of the very basic best practices when building reliable software systems.”
Indeed there is a disconnect that many companies will not acknowledge, which is that RPA automates a clearly defined process — but most companies don’t have clearly defined processes, according to Antony Edwards, COO of Eggplant. “So they start automating, and either automate the wrong thing or get lost in trying to reverse engineer the process.”
Here is a typical scenario, Edwards offered. A company tries to implement RPA for, say, invoice approval. As the project gets underway the project manager realizes there are actually about 30 different approval processes in the company, perhaps because of acquisitions or perhaps because a certain SVP doesn’t like the established process. Or perhaps the processes are clear cut and the team gets excited, implements scripts, then something changes and the team realizes that maintaining scripts is much less fun. That is another common reason for failure, Edwards said, companies don’t realize it’s an ongoing investment of time and resources, not a one-off project.
Another variation on that theme: some companies automate several flows of a process, but don’t document some lower frequency flows, which results in process exceptions they weren’t prepared for, said Pankaj Chowdhry, CEO of FortressIQ. “Humans are incredibly flexible, and can oftentimes adapt in a process, without really even thinking about it. If these adaptations aren’t accurately documented, the automation is ultimately unsuccessful, and the business case isn’t met,” he said.
Related Article: OpenText Digital Asset Management for SAP Solutions
IT Legacy Debt
Another problem, Freund said, is that many companies have built tremendous technical debt by operating their business on legacy IT that has been developed years or even decades ago. “Applying RPA gives some executives the illusion they would actually be undergoing a 'digital transformation,' which would allow them to defend their market shares against new digital native challengers such as fintech startups or big techs.” Unfortunately for them, RPA cannot compensate for an outdated IT infrastructure, Freund said.
In some situations, he added, RPA can actually delay the necessary modernization by taking away the pain that is often needed to trigger more fundamental improvements and to justify more substantial investments towards the C-suite or external shareholders.