Get readyfor robots
Why planning makes thedifference between successand disappointment

Contents
246

Delivering Robotic Process
Automation

Top 10 common issues
in failed RPA projects Business issues

Top 10 common issues
in failed RPA projects Project challenges

89

The multiplier effect

One further thought

Delivering
Robotic Process
Automation

2

S oftware R obotics, or R obotic
P rocess A utomation ( R P A )promises to transform the cost,
efficiency and quality of executing
many of the back office andcustomer- facing processes thatbusinesses rely on people toperform.

T hat’ s the good news. B ut R P A is not without its
challenges. We hav e deliv ered R P A proj ects across
2 0 countries and are often called upon to help
companies when their first attempt failed. While
R P A can transform the economics and serv ice
lev el of current manual operations, we hav e seen
as many as 30 to 50% of initial RPA projects fail.
This isn’t a reflection of the technology; there
are many successful deployments. But there aresome common mistakes that will often prevent anorganiz ation from deliv ering on the promise of R P A .
A s one of the largest R P A consultanciesdelivering programs globally to financial services
organisations, E Y is often called in to get R P A
programs back on track. This is the first in a seriesof papers based on our practical experience andthe lessons we hav e learned. I n this paper, we
examine the common issues that we see clientsfacing as they move forward with robotics projects.
Subsequent papers will define robotics and explore
its potential, how best to structure R P A programsand adv anced robotics.

Given the promiseof RPA, where docompanies go wrong?
Any technology that can reduce thecosts of existing manual operations
by 25% to 40% or more withoutchanging existing systems, yet
improv e serv ice and generate
return on inv estment ( R O I ) in lessthan a year, can truly be described
as transformational and disruptiv e.

Getting RPA projects right is difficult. So what are
the top 10 issues that companies always need toaddress to deliv er on the promise of R P A ?
At EY, we break these down into two components:•T he common issues across failed R P A proj ects•

T he multiplier effect from multiple issues

Get ready for robots | Why planning makes the difference between success and disappointment

3Top 10 common issues
in failed RPA projects
B usiness issues

4

1.

2.

3.

Issue

N ot considering R P A as
business led, as opposed toI T led.

N ot hav ing an R P A businesscase and postponing planning
until after proof- of- concepts( P O C s) or pilots.

U nderestimating what happens
after processes hav e beenautomated.

Description

A successful R P A is a businessled initiativ e or program withstrong partnership from I T ,Cyber, Security, Risk, HR andother enterprise functions.

A common route for mostorganiz ations is to perform an
initial P oC or pilot to see thatR P A deliv ers on its promise.
B ut often this creates anembarrassing gap between a
successful P oC and large- scale
production automation, as R P A
programs cannot answer simple
questions from the Board about“ where are we going to target
R P A , how much will it cost andwhat is the return? ”

T here are a number of issues
with j ust getting an R P A
program mobiliz ed, targeted
and deliv ered at pace. B ut
another common mistake isneglecting to consider how
to get processes liv e and whoruns the robot workforce – bothissues that will delay “goinglive” and timely delivery ofbenefits.

Mitigation

Often companies think about
the initial automation proj ect,
but forget that ultimately RPA
will deliver a virtual workforce
that allows the business totask robots across the entire
organiz ation. I T would not bein charge of managing thecurrent agent workforce, norshould it manage a v irtual one.
And, as back-office agents canbe trained to teach robots,
hav ing a business- owned R P A
center-of-excellence (CoE),
liberates a constantly stretched
I T department to focus on morevaluable activity. So businessled C oE s allow the business toprioritiz e which processes toautomate and what the v irtual
workforce does. However,I T still has a crucial role indeliv ering infrastructure andsoftware support, but also jointly
gov erning and managing change
in automated processes.

There is significant body of
ev idence to show that R P A candeliver tangible business benefits
across all types of companies,
ev en those with the mostarchaic IT systems. We typicallyadvise companies to carry out
a rapid company-wide or unitwide opportunity assessment
alongside a PoC. Typically, PoCs
can automate sophisticatedprocesses in weeks, which is
all it takes to perform a solid
opportunity assessment andcreate a detailed business case.
This means quick stakeholder
sign- off, and enhances themomentum of the R P A program.

We believ e a business- ledRPA CoE is the best way tomanage and enhance a v irtual
workforce – but it does not
simply spring into existence.
S o the C oE processes need
to be in place, I T gov ernanceagreed, and staff trained tooperate robots and continue
to enhance processes. While
this seems daunting, a wellexecuted skills building
program can see a fully
self-sufficient CoE establishedwithin six to nine months – andis usually quicker and lessrestrictiv e than negotiating anoutsourced C oE arrangement.

4.
T reating R obotics as a series ofautomations v s. an end to end
change program.
U nless a structured reorganiz ationand full-time-equivalent (FTE)- release happens as part of an R P A
project, agents quickly “drift off”
to perform other work. Typicallythis inv olv es focusing on prov iding
a better service, or working on
more interesting tasks instead ofthe manual work the RPA is now
doing. While understandable, itmeans that the benefits are notfully realized and subsequent
phases are not approv ed.

While prov iding better serv ice
is laudable, ultimately an
R P A program must deliv er its
planned benefits in order tocontinue to rollout. Focusing on
measuring and realizing benefits
is therefore key. By performing
an opportunity assessment, weusually recommend a portfolio of
sav ings, serv ice improv ement andtransformation processes – each ofwhich needs to be measured andbenefits delivered so ongoing
inv estment continues.

Get ready for robots | Why planning makes the difference between success and disappointment

5

P roj ect challenges

5.

7.

Issue

T argeting R P A at the wrong
processes.

Applying traditional deliverymethodologies

A utomating too much of aprocess or not optimiz ing
for R P A .

Description

Targeting RPA at a highly
complex process is a common
mistake. This results insignificant automation costs,
when that effort could hav ebeen better spent automating
multiple other processes. O ftenthese are tackled only because
they are very painful for agents,
but may not offer huge savings.

Quite often companies try
to apply an over-engineered
software delivery method
to R P A , with no- v alue
documentation and gates,
leading to extended delivery
times – often months whereweeks should be the norm.

O ften we see that companies
try to totally eliminate human
input in a process, which ends
up in a significant automation
effort, additional cost andlittle additional benefit. But weequally often see no effort tochange existing processes toallow RPA to work across asmuch of a process as possible,and hence reduced sav ings.

Mitigation

Perform a proper opportunity
assessment to find the optimum
portfolio of processes. L ow or
medium complexity processes
or sub- processes are the best
initial target for R P A , with aminimum of 0.5 FTE savings,
but preferably more. Ultimately,
we are looking for the processes
with the best return, andsimplest delivery.

While I T gov ernance is essential,
most software delivery methods
are over-engineered for RPA –especially as RPA rarely changes
existing systems, and processes
are documented in the tool.
Companies should look tochallenge and simplify existing
methods and use an agile
delivery approach to deliver atpace. I n fact, a few leading R P A
C oE s, with the right methods,
hav e deliv ered new processesinto production every two tofour weeks.

The best way to view RPA
initially is as the ultimate“helper,” carrying out the basic
work in a process and enablinghumans to do more. A utomating
70% of a process that is thelowest- v alue, and leav ing thehigh-value 30% to humans is agood initial target. It’s always
possible to back and optimize
the process later. A nd while
fully “learning” every process
may take too long, look to see
if simple changes mean that a
robot can do more of a process.

Companies should only tackle
complex or critical processes
once they are RPA-mature,and then look to automate
the highest v alue or easiest
parts first and increase thepercentage of automation
ov er time.

66.

8.

9.

10.

Forgetting about IT
infrastructure.

A ssuming R P A is all that’ sneeded to achiev e a great R O I .

Assuming skills needed to createa P oC are good enough for
production automations.

Most RPA tools work best on a
virtualized desktop environment,with appropriate scaling anda business continuity setup.
It can be so quick to deliver RPA
processes (typically weeks notmonths) that I T has not had
the time to create a production
infrastructure and, hence,
get on the critical path todelivering benefit.

While current R P A tools canautomate large parts of aprocess, they often cannot doit all – frequently because theprocess starts with a call or on
paper, or requires a numberof customer interactions.
Hence companies often end up
automating many sub-processes,
but miss the opportunities toaugment R P A with digital orO C R and automate the wholeprocess.

O ne of the common traps of
RPA is that with just a day or
two of training, most business
users can automate simple
processes. But the skills needed
to create scalable, resilient
RPA processes are significantly
greater. S o often P oC s hav elengthy testing and re-workcycles to go live, if not totally
re- creating.

C ompanies can learn from E Yor RPA vendors about exactly
what I T infrastructure will berequired. This means knowing
your company’s lead times
and ensuring an appropriate“tactical / physical PC-basedinfrastructure” plan is in place,if a production env ironment isnot feasible quickly. Similarly IT
security engagement must startearly so as to not impact go-live.

T he cost arbitrage of R P A
is significant – in European
countries, a robot can be 10%
to 20% of the cost of an agent.
B ut more often than not, a robot
only works on sub-processes andhence leav es a lot of the processthat a robot cannot handle,
and therefore limits sav ings
achievable. But, for example, if
we extend RPA into digital selfservice we see that benefits canbe up to two to three times thatof R P A alone. E Y has inv ested
heavily in getting digital towork well with robotics throughspecial “ robot- aware” digital
tools, and the result is deliv ering
nearly 100% straight-throughprocessing, and significant ROI.

Companies should work on thebasis of needing at least two
weeks of classroom training,then two- to three months ofhands-on project delivery withsuperv ision and coaching,
before an analyst can deliverproduction-quality automations
well. I t’ s essential not to beeconomical on teams’ trainingor skills transfer and support.

Get ready for robots | Why planning makes the difference between success and disappointment

78

The multiplier effectM ore than one of the issues
outlined abov e is often present
or linked, creating a significant
multiplier effect. A s our “ top 1 0issues” list shows, it takes sufficient
forethought or outside help tomitigate these issues.

Unfortunately, if more than one of these issues
occurs – which is common – there’s a significant
multiplier effect that can lead to loss of belief in
R P A or cause the proj ect to stop.

1.

3.

Let’s look at an example, where three of the simpler
issues are encountered in a R P A program.
In the scenario below we are looking to deliver a
simple data cleanse PoC, and then quickly take this
into production to deliver tactical benefits:

2.

Issue

Using the wrong delivery
methodology.

Assuming skills needed
to create a P oC are goodenough for production
automations.

A utomating too much of aprocess or not optimiz ing
for R P A .

Total

Typicaltime todeliver
if issue
avoidedWith skilled resources
and an agile, R P A - centric
method employed,simple sub- processes are
typically automated andready to go live in two tofour weeks.

K nowing a P oC is due to go
liv e means the right designand dev elopment rigor isused and unit tested. Hencethe delivery part of a PoC
may go from one to twoweeks to two to three weeks
to confirm it’s fully scalable,resilient and audited.

A ssuming the focus ison the optimum 70% ofa process, it should bepossible to automate in
two to four weeks.

2-4 weeks

Typicaltime todeliver
if issue
impactsIf a software delivery
method is used, thenexcess documentation andgovernance gateways canquickly mean a process
can take six to eight weeks
to be ready to go live.

If a PoC is delivered bypoorly skilled staff, thenteaching a robot a process
could miss important issues
on scaling, error handling,concurrency or scheduling.
Hence, there can then benumerous cycles of testing
and re-work before it is fit
to go live – adding two to
three weeks.

C ontinuing to automate
the remaining 30% often
inv olv es conv oluted
exception handling or
multiple div ersions fromthe “happy-path”, so candouble the time to deliv er– adding two to fourweeks.

10-15 weeks

One further thought
What should have taken two to four weeks to deliver
under a high quality approach can rapidly increase induration - and hence increase cost – four-or five-fold.
Often these simple errors and delays give senior
stakeholders a reason to withdraw support fromthe proj ect. I t’ s therefore important to recogniz e
and mitigate these ( and other) common issues inorder to facilitate the success of the organiz ation’ s
R P A program.

In order to best gain buy-in to RPA by senior
stakeholders, we recommend that an RPA portfolio
balances cost reduction with other v alue driv ers
such as serv ice improv ement, transformativ eservices, improved regulatory response and growth.
While deliv ering cost- sav ings is great, “ headlinegrabbing” service improvements or showing entirely
new and innov ativ e digital serv ices or products
makes the senior stakeholders even more interested
in making RPA happen.
We hope this paper has helped you with the mainareas to consider when you are starting a project.
Our next few papers will focus on how to organize
and restructure for success.

Get ready for robots | Why planning makes the difference between success and disappointment

9

EY | Assurance | Tax | Transactions | Advisory

Contacts

About EY

United Kingdom
Debraj Dutta+44 20 7951 0607
Debraj.Dutta@uk.ey.com

EY is a global leader in assurance, tax, transaction and advisory
services. The insights and quality services we deliver help build trustand confidence in the capital markets and in economies the world
ov er. We dev elop outstanding leaders who team to deliv er on ourpromises to all of our stakeholders. In so doing, we play a critical rolein building a better working world for our people, for our clients andfor our communities.
EY refers to the global organization, and may refer to one or more, ofthe member firms of Ernst & Young Global Limited, each of which isa separate legal entity. Ernst & Young Global Limited, a UK company
limited by guarantee, does not provide services to clients. For more
information about our organization, please visit ey.com.

Asia PacificAndy Gillard+ 6 1 (2 ) 9 2 4 8 4 0 9 6
andy.gillard@au.ey.com
United StatesGeorge Kaczmarskyj+1 703 747 1887
george.kaczmarskyj@ey.com

EY is a leader in serving the financial services industry
We understand the importance of asking great questions. It’s how
you innovate, transform and achieve a better working world. One
that benefits our clients, our people and our communities. Financefuels our lives. No other sector can touch so many people or shapeso many futures. That’s why globally we employ 26,000 people
who focus on financial services and nothing else. Our connectedfinancial services teams are dedicated to providing assurance, tax,transaction and advisory services to the banking and capital markets,
insurance, and wealth and asset management sectors. I t’ s our global
connectivity and local knowledge that ensures we deliver the insights
and quality services to help build trust and confidence in the capital
markets and in economies the world over. By connecting people
with the right mix of knowledge and insight, we are able to ask greatquestions. The better the question. The better the answer. The betterthe world works.
©

2 0 1 6 E Y GM L imited.
A ll R ights R eserv ed.
EYG no. 03746-164Gbl
E D noneI n line with E Y ’ s commitment to minimiz e its impact on theenv ironment, this document has been printed on paper with a highrecycled content.
This material has been prepared for general informational purposes only and is
not intended to be relied upon as accounting, tax, or other professional advice.
Please refer to your advisors for specific advice.
ey.com/UK