The Successful Path to Scaling RPA

Over the past four years, I have met and talked with many organizations about their Robotic Process Automation (RPA) journey. The vast majority are still struggling to cross the chasm between successful pilots—and even multiple deployments—to large scale deployment. Most of the issues hindering scaling RPA are organizational and I have written a white paper that describes the issues and proposes some solutions and a framework to think about them.

Lately, I have observed some patterns among those organizations who have difficulties scaling RPA and also some common best practices among those who succeed.

Most organizations, when starting their RPA journey, are advised to start automating the famous 'low hanging fruit' processes that present a combination of high potential and low complexity. 'High potential' is driven by volume and estimated time reduction, and 'complexity' by characteristics such as the presence of structured data, number of steps, rule-based, etc.

The objective of automating these first 'low hanging fruit' processes is multiple: producing a 'wow' effect, allowing the organization to familiarize itself with the technology, and winning over some stakeholders to be able to continue the RPA journey.

There’s nothing wrong with that. However, based on these first successes, many organizations continue on a path to multiple RPA deployments driven by the same principle of 'high potential' and 'low complexity.' Unfortunately, in doing so, they also create the traps that will impede them from successfully scaling RPA further.

The most common traps preventing RPA scaling

The first trap consists of requiring a quick and high return on investment (ROI) per automated process.

In their eagerness to convince the organization to adopt RPA, the first champions of RPA in an organization (often middle managers) have over-sold the quick and high 'ROI story'—and do so, to be honest, often with support from RPA vendors.

By choosing 'low hanging fruit' processes as the first processes to automate, RPA champions have proven that automation for a few selected processes can produce a quick and respectable ROI. Unknowingly, they have created the expectation that all future automations should have, on a standalone basis, a quick and high ROI. This issue leads them to the second trap.

The second trap consists of 'peppering' automation across the organization. To be able to 'pass' the requirement of a quick and high ROI per process, the RPA leader and RPA team will be searching across the organization for the famous 'low hanging fruit' processes and automating only those processes.

As a consequence of traps one and two, after 12 to 18 months of multiple RPA deployments, many organizations start to run out of processes to automate. In addition, despite having shown decent results per automated process, the CFO and department heads fail to detect the bottom-line effect of automation.

Furthermore, anxiety and some passive aggressive behaviors may have started to creep in among employees. Those behaviors complicate the RPA team’s engagement with process owners and employees.

Finally, the internal RPA skill set might still be limited if the CEO has concentrated their effort on automating low complexity processes. Ironically, the CEO is often being simultaneously pushed to do 'exotic' artificial intelligence (AI) stuff because C-level managers have read about them in the press!

Sounds familiar? There must be a better way!

Scaling RPA more efficiently

The good news is that there is a more efficient way. I have aggregated observations from successful RPA deployments across a variety of organizations to propose a roadmap for a successful 12-month period that can prepare an organization for successfully scaling RPA. However, this roadmap to automation success assumes two things:

• 1. The organization has already had successful deployments of RPA and the technology is well understood.

• 2. The organization’s top management and key stakeholders are aligned on the strategic importance of RPA/automation and there is an identified RPA leader.

Before getting into the details of the plan, I would like to establish some common understanding.

One way of looking at a company’s automation is through the different levels of process automation. 

The three levels of process automation

At the highest level, there are the inter-departmental processes that cut across multiple departments and engage multiple people, such as employee onboarding. These processes are often (though not always) complex, require re-engineering while being automated, and may utilize multiple automation technologies such as intelligent optical character recognition (OCR), AI, or chatbots.

These process automations frequently yield impressive results as the automations not only eliminate any human errors, but also considerably reduce execution time. Execution time is reduced because the automation is treated as a single continuous process and, thus, hand-over time between departments is eliminated.

Further down, there are 'departmental level' processes. These are processes that are contained in a single department (e.g. end of month closing). The processes involve multiple people within the same department and they run the spectrum of relatively simple to relatively complex.

Finally, at the 'bottom' there are task automations. I define a task as a relatively simple process that involves only one person on his or her own workstation.

In the 'not so successful path to scaling' described early, an organization, in essence, concentrates mainly on automating 'low hanging fruit' processes at a departmental level across several departments.

By doing so, the organization misses the 'portfolio effect' of automation per department, does not create enough RPA skills, and ignores the element of change management.

So, what should an organization do instead?

The roadmap for successfully scaling RPA organization-wide

The organization needs to simultaneously fully automate one or two departments, tackle several inter-departmental processes, and train hundreds of RPA developers and analysts.

Fully automating departments

Fully automating one or two departments is counterintuitive and goes against current mainstream thinking but it is absolutely necessary to experience the full power of automation. If the organization only automates the 'low hanging fruit' processes, the maximum time reduction expected in a single department would be around 7% to 15% which will not trigger a change in the way work is organized and, consequently, have no impact on the bottom line.

The reason for the phenomena is rather simple to understand:

With the exception of highly specialized departments such as call centers, in most departments the majority of employees are involved in multiple processes during a day, week, or month. So, let’s assume that Suzy in the human resources (HR) department is involved in ten processes and that only two of the processes on which she works have been automated because those processes met the threshold of time saved (which was set at time savings of more than 50%). So, by automating the first process, 70% of the time Suzy spent on that process was saved and by automating the second process, 50% of the time spent by Suzy on that process was saved. However, processes one and two represented respectively 10% and 15% of Suzy’s workload. So, in essence, only 14.5% of Suzy’s time was saved.

By this approach, we may have hundreds of Suzys for which we have saved, in most cases, between 0% and 18% of their time. On the other hand, if we had automated almost all the processes and tasks that Suzy was involved in—down to the tasks with only a 10% time reduction—we would be reducing 20% to 30% of people’s total time in a department. Those time reductions are significant enough to reorganize work and have an impact on the bottom-line.

This approach of 'total automation' proves to the entire organization and, more importantly, to the CFO and department heads that automation is a real tool for increased productivity. However, total automation cannot be achieved if the organization continues with a per-process business case approach. Automation success requires a per-department business case approach and longer ROI timelines. Hence, a shift in mindset and approach is required.

Tackling inter-departmental processes

Tackling several inter-departmental processes is also necessary to show the power of automation because the most single gains are made there. Often, inter-departmental processes are complex processes requiring process redesign, inter-departmental collaboration, and the use of multiple technologies in order to achieve automation success.

Consequently, these are good projects to justify the creation of a common RPA center of excellence (CoE) and development of more specialized skill sets. Successfully automating inter-departmental processes also provides high visibility to the RPA organization and encourages (or forces) the inter-departmental collaboration necessary for company-wide digital transformation.

Training RPA developers and analysts on a larger scale

Training hundreds of RPA developers and analysts relatively early in the RPA journey serves multiple purposes. RPA and automation often, like any new technology, create anxiety among employees, particularly if the new technologies are not well understood. One of the most efficient ways to assuage these fears is to launch an internal program to allow hundreds of employees to be trained as RPA developers and analysts.

RPA is a low/no code technology that presents relatively low barriers to entry and vendors like UiPath offer extensive free online RPA training and certifications. Organizations should take advantage of these opportunities to sponsor an internal training program whereby hundreds of employees, on a voluntary basis, can train themselves on RPA. By doing so, organizations will signal their commitment to re-skill their employees, create a group of enthusiastic ambassadors of the technology, and create a talent pool that will become handy as each department scales.

Indeed, by year two, 'total automation' will no longer be driven solely by the CoE resources but rather by a combination of CoE talent and trained employees embedded in each department. The embedded, RPA-trained employees will act as citizen developers, hence, bringing down the cost of RPA development and deployment.

After a successful 12 months, an organization that has followed this path will have:

• A strong central RPA CoE with adequate skills

• One or two enthusiastic department leaders that have seen RPA considerably improve the productivity of their teams (encouraging others to follow suit)

• Learned how to approach 'total automation'

• Automated several departmental processes with high results and visibility

• Created a pool of RPA talent embedded in business units and departments that will play a key role in the subsequent year of RPA deployment

In other words, the organization will be poised for real RPA scale-up.

To find out more, watch our on-demand webinar "Drive Business Impact at Scale with a Robot for Every Person"