Posted: 22 May 2019 15 min. read

How to develop an RPA program that actually works

“RPA will revolutionise our operations, saving at least 60% of our annual costs, in the first year itself” or “RPA is the epitome of an unfulfilled promise – at least 50% of our RPA projects have updated their cost benefit profile within 4 weeks, typically increasing cost estimates and reducing benefits”

In the past 18 months, most companies implementing RPA have had a bipolar experience – some swear by it where as 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. 80% of the work is deemed suitable for automation just because it is rules-based. There is little comparison of what constitutes rules based decision-ing 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% 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 desktop recorder like functionality used in most demonstrations and Proofs of Concept. The roles in the RPA program are mainly business focussed – 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 that we thought”

Missed roles in the operating model: As the first few project are nearing go-live, multiple roles emerge with team members asking the question “who’s responsible for that”? Typical examples are – who would oversee 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”, IT applications have an unplanned change e.g. batch jobs are cancelled for a week requiring 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 require 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, low levels of documentation rather than challenges around scale, operational risk, seasonality, speed for mature, 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 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 virtualisation platforms, 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 refer more business transactions to human workers which in turns reduces benefits from Automation.

Cultural change readiness: Implementing RPA at scale requires a change in the organisational 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 standardisation 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, organisations need to realise that their human workforce is a lot more adaptable and forgiving than their robotic counterparts. Building out a Robotic work force requires a lot more operational discipline, a technology platform to match, and much greater collaboration between the operations and technology teams.

In the next post, we will share our battle-tested tactics to advance quickly and with less pain to Phase 3.

More about the author

Ajay Yadav

Ajay Yadav

Partner, Consulting

Ajay Yadav is an experienced Service Transformation professional who has advised Financial Institutions, Government and Telecommunications clients in multiple geographies (Australia, UK, US, South Africa and Europe). He is a core member of the Service Transformation practice, focusing on Process Automation using Robotics and Cognitive Automation, Agile transformation, Operating model design and Service Design.