Robotic Process Automation: Lessons from the Pandemic

Reports from research organizations — such as Gartner and Deloitte in 2018 and 2019 — found as few as 4% of organizations were able to achieve operational scale with RPA, typically meaning more than 50 bots in production. Again and again, organizations found that when implemented in an incremental, piece-meal, try-before-you-commit manner, RPA rarely provided the value initially promised. Many organizations clearly saw these tepid adoption approaches as the path to RPA failure, yet they seemed unable to avoid it. By early 2020, those of us in the RPA business began to wonder if the shine was finally off the apple and began looking for other technologies in which to invest.

Then COVID arrived.

At first glance, it may not seem obvious why the pandemic would change organizations’ view of RPA, but my subsequent research on this topic tells a different story. In discussions with dozens of executives around the world, it became clear leaders were adopting a dramatically different perspective regarding automation in light of the lessons they learned during COVID.

I have condensed my findings down to the following five lessons for the effective use of intelligent automation (IA) post-pandemic.

Saving time matters

While many of the bots deployed over the last decade failed to reach their return on investment (ROI) goals, many of them did provide value in a number of other ways. I refer to this as ROx (Return On X), and typically these “soft” benefits of RPA were undervalued in light of the focus on “hard” benefits from measurable cost savings.

Return on Time (ROT) was chief among these ROx’s, and it was typical to see a bot generate 90% or more savings of cycle time in the tasks they performed. I personally deployed bots that reduced process cycle times over 97%.  Regrettably, saving time was often undervalued because organizations tend to follow a certain tempo. Significant changes to that tempo are often viewed as disruptive and counterproductive. But this perspective changed dramatically during the pandemic. Suddenly, a vast array of decisions had to be made, practically overnight, and those decisions had to be implemented over the course of a weekend.

The cause of the disruption was not that organizations had to quickly speed up their tempo — but rather that they did so with little difficulty. The intense belief in the impossibility of doing things faster was proven false. In fact, many organizations felt liberated by the sudden need to make decisions quickly and then follow through without mountains of doubt or dissent. The majority of leaders I interviewed recognized the immense value of the rapid decision making they experienced during COVID, and many are seeking ways to replicate such operational velocity on a continuing basis. RPA fits this bill perfectly, and these companies now properly value ROT as a “hard” savings.

 

Mandate adoption

Pre-COVID, those that succeeded with RPA tended to force adoption within their organizations. Automation was a leadership mandate, and subsequent compliance was measured and rewarded. Conversely, those organizations that followed an “If we build it, they will come” approach rarely saw extensive adoption of RPA. This was the dreaded center of excellence (COE) model widely hailed as a best practice.

Unfortunately, most COEs had funding for themselves, but little funding, support, or influence within the business units they were designed to support. Those units in turn could choose whether they wished to use RPA and to what extent. This forced COEs to act like internal vendors — forced to try to sell their value proposition to the rest of the business before they could generate the positive returns necessary to justify their existence.

In hindsight, the COE model was never going to work. The upfront costs were too high and the organizational barriers to their success too great. Without a leadership mandate for use, RPA became a potential source of savings obliged to prove itself — over and over again — with each business unit leader considering its use. COEs created opportunity pipelines, dozens if not hundreds of internal sales calls, proofs-of-concept for a technology that is not conceptual, and a veritable mountain range of hurdles to adoption.

What did work was leaders telling subordinates they had to use RPA, and they were on a timeline to do so. Several clients I worked with applied a use-it-or-lose-it approach, whereby business units were not allowed to replace attrited employees with new personnel; they had to replace their labor with bots. Further, they had to increase their department’s throughput without expanding headcount. In these instances, RPA flourished, and business leaders scrambled to increase their rate of adoption.

The lesson from the pandemic is clear: People thrive on leadership and direction, and better results derive from decisive leadership. Organizations willing to commit to automation — and expecting themselves to live up to this commitment — are those most likely to succeed.

Breadth not depth

In RPA 1.0, most organizations implemented big-bang proofs-of-concept (POC) projects. These projects were selected because their expected ROI was sufficient to cover all the startup costs associated with POC. This led to a vicious cycle wherein the size and scale of the POC kept increasing to generate enough benefit to overcome the costs in realizing it. What may have started out as a $50,000 pilot quickly became a $500,000 project once all the startup costs were considered, and the need for positive ROI out of the gate came into contention.

Such spiraling of costs and benefits is well understood by people in the space industry where I started my career. Every time I saw a client ask for a $250,000 COE before they even started coding, I knew they were likely doomed. Expecting the first bot activated to cover all the costs associated with its activation is like a taxi driver expecting their first passenger to pay for the total cost of the taxi. It doesn’t make rational sense, but for the last decade, this has been the common approach to RPA adoption.

This was the depth approach to RPA. Find a big, compelling, self-funding use case and hope for the best. If it succeeded, you’d go find another, and so on. This approach rarely worked despite being considered a best practice.

Conversely, those who followed the breadth model fared better. Rather than deploying one big bot, some organizations implemented a dozen or more smaller bots simultaneously and allowed them to share the load of startup costs. Breadth allowed more users to realize the benefits of the technology while also reducing the risks associated with any one of them missing the mark. Spreading costs across multiple bots vastly improved bot utilization and startup infrastructure development.

When combined with a management mandate, the breadth approach has proven to provide a far higher probability of success with RPA.

Encourage fast failure

The depth over breadth approach of early RPA adoption was also notable for its low tolerance for failure. Placing all your ROI eggs in one basket made project failure a matter of survival. Fear of failure tends to attract additional oversight and risk mitigation — aka cost. I saw this all the time in the spacecraft business where a familiar lament was, “Spacecraft are expensive because spacecraft are expensive.” Basing RPA success or failure on a single, large, must-win POC dissuades the experimentation and risk taking implied by the concept of POC. Organizations expecting their POCs to be perfect and profitable from the start set themselves up for disappointment.

The alternative is to try multiple, small, fast automations across a wide range of processes to gain experience with the technology’s strengths and weaknesses and how it might harmonize within your organization. This is much like the contrast between NASA’s approach to going to Mars and that of entrepreneur Elon Musk. Musk’s approach to rapid prototyping and frequent fast failure certainly leads to a significant number of “unplanned, rapid dis-assemblies” of not so perfect rockets, but it has also brought his company breakthrough results in a relatively short time—and at a fraction of the costs of NASA’s more conservative, risk-averse approach.

This holds true for RPA as well. Organizations who succeed with RPA allow themselves room to fail, learn, and improve. They didn’t expect perfection and profit from the beginning, so they were less inclined to abandon their efforts at the first sign of unexpected issues. Ironically, the path of frequent, fast failure generally proves less expensive, less risky, and more successful in the end — despite the potential perception of greater risk of loss.

Chase recursive benefit

In software development, programmers often rely on the concept of recursion to simplify complex problems. Recursion is solving a big problem by breaking it down into several smaller, similar problems, solving those, and combining the results. It’s the notion of climbing a staircase one step at a time — rather than trying to leap to the second floor in one step. Ten or eleven smaller steps are far more likely to get you to the top in one piece!

In chasing the big-bang, immediate ROI of RPA POCs (alphabet soup!), many organizations attempted to automate entire processes  in one shot. If any single point in the automation failed, the entire bot was a failure. This was a recipe for failure and disappointment, and I personally witnessed dozens of instances where such “big bang” bots could never complete a transaction from start to finish.

A far more effective approach is to deconstruct your processes into a collection of individual tasks.  Automate the tasks first, and as you succeed, you can address the next tasks up and down the process chain. Eventually, you may automate the process in its entirety, but even if you don’t, you will make significant gains through task automation along the way. This is chasing recursive benefits — where succeeding with one step helps you succeed in the next and so on until you’re done.

Chasing recursive benefits is one of the technical best practices I applied to fixing “failed” bots, and it worked nearly every time. A bot created to be far too complex, and to complete a process from end to end, was replaced with a series of recursive bots that attacked the process one task at a time. Over time, you still achieve end to end automation, but you do so with far less risk, cost, time loss, and frustration.

 

Get busy bottin’

In reviewing their experience of implementing automation post-pandemic, one of the strongest messages my research subjects shared was the need to get moving. COVID forced many organizations to make overnight decisions they previously agonized over for months or years. Several executives I spoke with recounted how, “projects we thought would take several years and several millions of dollars were completed over a weekend for $50,000.”

Deploying Zoom was one of their favorite examples. While they spent years agonizing over whether to allow work from home, once a black swan event decided this for them, they managed it easily, and business did not come to a screeching halt. Indeed, many found their operations and productivity improved once the decision was made.

Many of them discovered the cost of agonizing over potential costs was greater than actual costs and took no account of the opportunity costs of their hyper-focus on cost — which is costly. Their common lesson learned was this: Decide and get going.

Whether it’s deploying work from home, un-leaning your supply chain to gain resilience, or implementing RPA as a prerequisite for returning to the workplace, the majority of executives I surveyed agreed. The pandemic showed them the need to apply these five principles to their adoption of automation and other transformational technologies. As the research conclusively showed, disruptive technologies are only disruptive if used disruptively. Embrace this approach, and you too might join the small but growing percentage of organizations harvesting a permanent structural operating advantage through the effective use of intelligent automation.