This article by Andy Walter, Former Global IT & Shared Services VP, Procter and Gamble, was originally published on CIO.com
Robotic Process Automation (RPA) is undeniably red-hot these days. Enterprises are adopting RPA at staggering rates to increase operational efficiency—but when I discuss RPA with fellow CIOs or Global Shared Services Leaders, the most common topic of discussion is the serious issue with scaling RPA in the enterprise.
Forrester is reporting that 86% of organizations adopting RPA are experienced increased efficiency, 67% gained deeper insights into customers, and 57% improved customer service. At the same time, recent surveys by Deloitte and EY found that approximately half of RPA projects fail, and most of those that “succeed” do not deliver the expected ROI.
What’s behind this disconnect? And how do you ensure that your organization joins the ranks of the RPA success stories, not the RPA disappointments?
Breaking Bots Lead to the RPA Death Spiral
“Breaking bots” has fast emerged as the #1 enemy to RPA success. With easy access to UI-based automation, line of business (LOB) owners create RPA bots to automate processes without having to ask for (and wait for) IT/development assistance. After a little trial and error, they can get basic automation up and running. But, sooner or later, something changes. Interfaces are optimized. Data formats evolve. Or maybe connected/dependent systems are upgraded. Regardless of the cause, the outcome is the same: broken bots. Each time a bot breaks, the LOB requires technical assistance to diagnose and fix the cause…until the next time something breaks. Shared services organizations who are not working closely with IT are often hit the hardest!
This is what’s become known as the RPA Death Spiral. To avoid this death spiral, RPA bots must be resilient to change and bot maintenance must be simple and straightforward…which eliminates the popular script-based approaches. Otherwise, RPA is simply short-lived automation that creates technical debt—leaving the organization at risk since automation fails to execute the required tasks.
RPA: Not Robotic. Not Process. “Just” Automation
From what I’ve seen, it’s all too common for organizations to enter into RPA initiatives with unrealistic expectations. Many organizations are enticed by vendor-induced visions of sophisticated “robots” taking over previously-human-led processes—faster, better, and cheaper. However, no actual robots are involved—and RPA’s strength is about automating short repetitive tasks versus long-running end-to-end processes.
As Gartner recently noted: “[Bots are] easy to build; however, they are not equivalent to humans, who can interpret and adapt as needed. Customers should not confuse in their minds the cost of an employee and the cost of a set of integration scripts.”
From a technical perspective, RPA is not all that different than other forms of enterprise automation (such as test automation) that have been around for decades. Under the hood, RPA solutions are based on the same core automation approaches that are extremely well-vetted across the test automation market. Not surprisingly, the script-based approaches that have yielded poor results in the test automation world continue to fall short in the RPA sphere—and the resilient model-based approaches that enable high levels of enterprise test automation continue to rise to the top for RPA.
“For Every Employee, a Bot” … Maybe Not
Some vendors are promoting a futuristic vision where every employee has his or her own bot. Who wouldn’t want an easy button at every employee’s fingertips, taking care of the work they dread and freeing them up for high-value tasks? However, empowering every employee to work smarter will turn from fantasy to nightmare if you don’t make extreme reuse and easy updating a top priority.
Consider this: there’s probably a huge overlap in the core tasks that various departments and divisions would like to automate. Also, the associated systems and processes are probably being continuously updated and optimized. With most RPA implementations, an update to a core interface used in 1001 slightly different ways would require an update of 1001 different bots. That’s just not sustainable. It’s another case of breaking bots propelling you into an RPA death spiral.
What’s really needed to avoid this trap is extreme reuse: the ability to update a core automation “building block” once, and have that change automatically propagated across all the relevant bots. It needs to be as simple as updating a password for a single sign-on versus updating it each and every application you access day in and day out.
While RPA might be a new trend on a meteoric rise, the underlying foundation of enterprise automation is not revolutionary. Ultimately, success with RPA will boil down to aligning your strategy with RPA’s real potential and ensuring that your technology is architected to avoid the pitfalls that have been undermining enterprise automation initiatives for decades. Old problems don’t have to be new again with RPA. Technologies like model-based automation can accelerate your initiative while significantly mitigating the risk of project failure.