How to develop an RPA program that actually works

March 23, 2018

A blog post by Ajay Yadav, director, Consulting, Deloitte Australia.

In the past 18 months, most companies implementing RPA have had a bipolar experience—some swear by it whereas others swear at it. So what’s really going on here? At Deloitte, we have been implementing RPA at clients in multiple industries for some time now and believe that the truth is a bit more nuanced. This is the first of a series of posts describing various phases of maturity of an RPA program and battle-tested tactics to get to the higher maturity phases as fast as possible.

Given the low maturity of implementing RPA, most companies require multiple attempts before they are able to make steady progress in their RPA programs. We find RPA programs go through three phases in their journey.

Phase 1: Sky's the limit—"RPA: The silver bullet we've been waiting for"

Massive scope: During this phase, there is a lot of excitement about the world of possibilities with RPA. Processes are selected based on how easy is it for humans to execute the process. Eighty percent of the work is deemed suitable for automation just because it is rules-based. There is little comparison of what constitutes rules-based decisioning for humans versus RPA (e.g. Jon versus Jonathan may be ok for humans to action but typically not ok for robots).

Huge savings: Industry “benchmarks” are used to estimate the size of the prize, with anecdotal evidence from single data points and article headlines used to justify the initial cost-benefit estimates. Savings of 50–60 percent and program return on investment in the first 6 months are not unusual.

Easy to implement: There is a strong belief that RPA programs are really easy to implement. This is partly driven by advances in user interfaces on the RPA tools and a desktop recorder like functionality used in most demonstrations and proofs of concept. The roles in the RPA program are mainly business focused—typically business analysts, with some doubling up as RPA configurators/RPA developers and project/program manager(s).

Phase 2: Fall and learn—“RPA is more complex and expensive than we thought”

Missed roles in the operating model: As the first few projects are nearing go-live, multiple roles emerge with team members asking the question “who’s responsible for that?” Typical examples are, who would oversee the actual running of these robots updating schedules and resource allocation based on changes in demand? Who would tweak/fix/modify them when business processes change “slightly,” information technology (IT) applications have an unplanned change e.g. batch jobs are canceled for a week requiring a different interpretation of the data presented on the user interface?

Underestimating IT environment complexity: Using the assumption that robots are simply rules-based humans, initial RPA projects typically overlook the complexity and idiosyncrasies of interacting with various target applications. Some of IT application requires only one log on and log off during the day, others are the opposite. Some are built for browsers that the RPA tool doesn’t support natively, leading to longer build times and requiring a more robust design. Finally, there are implications on upstream and downstream systems that underpin the target applications which need to be considered in the automation build.

Using RPA to cover for process gaps: RPA is sometimes incorrectly used to address operations pain points related to broken processes e.g. lack of standard operating procedures, and low levels of documentation rather than challenges around scale, operational risk, seasonality, speed for mature, and well-documented processes. This leads to longer design times, “discovery” of new business scenarios during testing/pilot, reduction in scope of what can be automated using RPA, and rework of automation build—leaving the stakeholders frustrated, increased costs, and lower benefits.

Phase 3: Eyes wide open—“RPA requires structured, cross-functional effort with a specific focus on foundations”

Industrialised RPA framework: Development of a robotics operating model (ROM) is critical to scale process automations. The ROM needs to clearly define new roles, accountabilities, and controls, specific to development and use of RPA. The RPA build requires a new robotics delivery lifecycle and a new robotics support lifecycle. Both of these are similar in some aspects but quite different in others from the typical software delivery and support lifecycles.

Robust robotics platform: The RPA platform is only as strong as the underpinning platforms it relies upon. These include, but are not limited to, the virtualization platforms, and the networks and hardware infrastructure that host the virtual desktops that the robots use to interact with the target applications. Any gaps here will result in slow robots resulting in missed OLAs/SLAs, typically mitigated by increasing resource requirements or adding more bots but this results in higher run costs. An inadequate platform also causes robots to refer more business transactions to human workers which in turn reduces benefits from automation.

Cultural change readiness: Implementing RPA at scale requires a change in the organizational culture at many levels. First and foremost, the business needs to prepare for the workforce implications both in terms of roles that are no longer needed as well as the new ones that are going to be needed. Secondly, RPA needs to be seen as a lever in operations excellence, which means fundamentals such as waste elimination, process standardization, and simplification cannot be ignored. Finally, for RPA to scale, it may be business led but it also needs to be technology (IT) driven—after all automations are a hybrid of process and technology.

RPA programs can be a huge success and scaled RPA capability is not a pipe dream. However, organizations need to realize that their human workforce is a lot more adaptable and forgiving than their robotic counterparts. Building out a robotic workforce requires a lot more operational discipline, a technology platform to match, and much greater collaboration between the operations and technology teams.