What is success in RPA and how do customers get there?

Executive Summary

The article puts forward the idea that success in RPA should be considered in terms of what proportion of an organisations work is done by robots, rather than in the more common measures of FTE savings or hours returned to the business. A company with 100 robots returning 1 million hours a year to the business sounds impressive, but it could also be viewed as disappointing in a bank with 30,000 employees.?The article then looks at the 4 different journey profiles of RPA customer licence growth and the pros and cons of each.?It will explain that most RPA customers scale their capability in small incremental steps that take a very long time to get to scale, if they ever manage to scale at all.??

Introduction

Do you know companies that are successful at scaling RPA???If you think the answer is yes then it is worth asking “what proportion of work that was done by people is now done by your robots?”??Have they automated 1% of the work, maybe 2%??Are they doing amazingly well and have automated 5% and have plans to get to 10%???How many years has it taken to get to the % of work automated figure they are currently at???

To quickly understand where an RPA capability is in their journey, I have a cursory calculation I quickly do when I meet with an automation customer for the first time.?The quick calculation roughly estimates the amount of work the robots are doing compared to the size of the company, and I compare that to other companies I know that I think are doing well.

Is this quick calculation overly simplistic? Of course! Given lots more data and time could I do a better evaluation of success? Definitely! Is this quick finger in the air method of appraising how an RPA customer is doing usually correct??Yes, it is!

Here are four real-world examples of companies I know with an RPA capability:

• One of the world's largest conglomerates with over 300,000 staff globally, has under 50 robots. They have been doing RPA for five years.
• A small to mid-sized European bank with about 6000 employees, they have been doing RPA for about 7 years and have about 140 robots in use.
• One of the world's largest banks with about 230,000 employees. They have been doing RPA for 6 years and have about 700 robots in use.
• A small European insurance company with 400 staff, they have 10 robots.?They have been doing RPA for a few years.

How do you think these companies are doing at RPA? Are they successful? I suspect the global bank with 700 robots would certainly be seen by most people as one of the most successful RPA capabilities in the world. However, in terms of % automated the small insurance company with 10 robots is absolutely nailing RPA compared to the bank with 700 robots but it is the bank that would usually be discussed as a success story in RPA circles.?

If we use a very approximate 1 autonomous robot can do the work of 4 full time employees (FTE) calculation the percentage of work being done by robots in each of my example companies is as follows:

Global conglomerate = 0.07%; European bank – 9.3%; Large global bank = 3.5%; Small insurance company = 10%.

Based upon this way of scoring we can see that the European bank and small insurance company are both doing extremely well, probably amazingly compared to most organisations doing RPA.?The global conglomerate is in a failed state with robots doing hardly any of the company’s work and needs a total restart with new leadership, sponsorship, and targets.??The large global bank is probably one of the top companies in the world in terms of number of robots in use but there is obviously a lot more automation for them to do to be amongst the best in terms of percentage automated.

Thinking in this way helps me to have a sensible conversation with RPA customers about where they are today and where they could be.?It helps to reset the ambitions of some customers that think they are doing well to think about how they could do a lot better, it helps to discuss with failing customers where they should be and how we can help them to get there.

So, is 10% the target?

I believe that every organisation should be able to get to at least the 10% of work automated threshold, the failure of almost all RPA customers in getting there is the biggest frustration of the RPA sector, it is what keeps us all awake at night wondering about how we do better.

In my opinion 10% is a great initial target to get sponsorship and investment for, but if you do manage to get there you can expect to go a lot further. My experience is that every company I have met that is at or nearing the 10% mark have told me they have a healthy pipeline for work still left to automate and/or parts of their organisation where they still have not done any automation yet.?In my experience BPM and other core system implementations do not remove the need for using RPA in the slightest, if a CIO says that there is a better strategic alternative to RPA that will remove all manual work then she/he does not know the history of technology in business, there will always be gaps that need to be filled.

What I love most about scoring RPA customers using a % automated as a measure is that it levels the playing field as it lets smaller companies compare themselves with the biggest. I have been at some RPA events with global organisations talking on stage about the enormous FTE or hours returned savings they have had leaving RPA leaders in smaller companies feeling that they are not part of the same conversation.?Comparing by percentage automated might put many smaller companies ahead of many of those larger ones.

What is the timeline for successfully scaling RPA?

The saving grace if you have not yet scaled RPA in an organisation up to and beyond my 10% target is that you are not alone, very few have.?You can also take comfort in the fact that it usually takes years to scale RPA anywhere near 10%.??

The reason it is slow is because change in most organisations is hard and there is no quick fix for getting security sign off, for getting IT on board, for getting the workforce on board,?for engaging lots of different department leaders, for getting an operating model in place that works, for engaging every system owner, for coping with business changes and system changes,?for having the MI you need…. and the 100 other things that need doing to do this well. Every RPA leader that has managed to scale an RPA capability is full of war stories about the troubles they hit along the way.

There are four main profiles which show the different paths RPA customers take to try and get to scale. These are: the moon-shot; the very, very long pilot; the gradual staircase; and the small and stalled.??I will dive into each of these below:

1.???The moon-shot

This profile represents an ambition for scaling RPA enormously right from the start with extremely strong sponsorship, large automation and ROI targets, and a very large number of robots licences purchased at the very start of the RPA journey. The licenses in such a deal are usually incrementally staggered in 6 monthly or 1 yearly release increments because no one can use 1000 licences on day 1, and the large up-front number of licenses commitment means the customer gets a healthy discount per robot.

The moon-shot is the rarest type of RPA deal, I have known only a few of them in my 17-year career.?An RPA sale of this type represents an enormous success by the sales team for both getting access to board level executive sponsorship and selling a transformational vision to the customer.?It is extremely rare for salespeople in RPA to be able to do this and it is usually career defining for anyone who manages it, for the biggest of these deals it also always requires one of the large multinational IT consultancy firms to be part of the deal and get access to the c-suite.

With big up-front licence deals like this the post deal focus for the software vendor must be on licence consumption rather than licence upsells which should be Customer Success bread and butter work, unfortunately some vendors can disappear due to the lack of upsell opportunity for the duration of the multi-year deal.

Pros:

The big benefit of this type of deal is that the sponsorship is already there, for most other customers a common problem is lack of c-suite sponsorship and we are usually struggling to get it for years after the initial deal.

Even though these moon-shot RPA deals never manage to quite land on the moon and deliver everything that was planned in the expected time, all the customers that take on such a project get further than all other companies and end up being amongst the largest RPA implementations on the planet. In the words of Norman Vincent Peale, “Shoot for the moon.?Even if you miss, you’ll land among the stars”.???There is nothing like a difficult target and strong sponsorship to concentrate minds, remove blockers, and solve difficult problems.??The licence discounts in such large deals often leave the customer with some leeway on licence consumption, if they do not use all the licences as quickly as hoped they might still be saving on robot costs compared to if they had paid more in smaller incremental deals.

“Shoot for the moon. Even if you miss, you’ll land among the stars”

Cons:

For the biggest moon-shot customers, the planned speed of scaling RPA for this kind of deal are usually over-ambitious from a standing start, and the project does not include enough experience or resources to deliver anywhere near what is needed at the rate required.?

Let’s be honest, there are not many people with experience of truly scaling RPA and there is an ongoing shortage of RPA developers in the market.?Moon-shot projects can be plagued with poor quality RPA leadership, and mostly poor quality off-the bench developers that are straight off the training courses.??I know of three moon-shot projects sold by one of the world’s biggest consultancy firms where this was their resource profile and they were thrown out of all three projects within 18 months and the customers were left with transformational projects that needed a total reboot.??

For me the most frustrating thing about these large transformational projects has been the sometimes insulated and non-collaborative nature of the consultancy firm involved.??On the one hand they are the best organisations at selling transformation, on the other hand they can be greedy in keeping every penny possible of the service revenue irrelevant of their ability to deliver on their own.?In one recent example a well-known firm sold several million euros of services to a European government organisation and refused to embed just 50 days of expert consultancy from the software vendor’s team into the deal even though they admitted they had zero in-country experience themselves to deliver the enormous project successfully.?They wanted to take every penny of the service money at an enormous risk to the project, to the customer, and to their own reputation.??

So, buyer beware, it is never the RPA platform that cause these large projects to fail, it is instead not including the leadership and experience needed to deliver it.?My advice is to make sure the software vendor has a direct commitment to be a part of making your transformational project successful and look for evidence of experience from your consultancy firm of choice.?One infamous 1400 robot license project had less than 200 hundred robots in production after 18 months.?The answer for the customer was to throw out the consultancy firm that was failing so badly and bring in some people that had successfully scaled RPA before at another company and turn the project around (which they did).?The customer had also been considering dropping RPA altogether.

The biggest risk with the moon-shot for the RPA vendors is the downsell (or worse churn) of the customer when the project inevitably fails to hit its targets, luckily, the customer usually get enough robots into production to make migration to a different platform difficult.??

2.???The very, very long pilot

In this 2nd profile I am discussing a low number of robot licences that have been purchased just as an entry point for the customer to understand how to do RPA in their organisation, the salesperson should not see this as a closed deal even if licences have been paid for.?By “very, very long” I mean usually over a year.??This is not a 1-month POC or Pilot using free robot licences, this is taking a long time to prove the technology works and grow sponsorship by showcasing it.

This is a more common growth profile for large companies than the moon-shot, but still rare.?One of Blue Prism’s largest US banking customers spent 18 months in this pilot phase with hardly any robots in use before making a massive licence purchase and really going for scale.

Sometimes this pilot phase can go on for years, maybe following a very gradual staircase profile (see below), and the organisation might not think of themselves in a pilot but they have so few robots as a percentage of their workforce that they effectively still are.

Pros:

If the very long pilot does ever turn into a transformational deal that looks more like a moon-shot it has a far greater chance of success because time has already been taken during the pilot to plan for scaling, to remove many of the common automation blockers, and to gain a wider spread of c-suite sponsorship.?

A customer who has been trialling RPA for a while using their own resources is far more likely to have an equal relationship and better governance over consultancy firms if they decide they need to use them for resource augmentation.?A true partnership with these organisations makes for a far better relationship and has a good chance of succeeding.?In my experience all the best examples of consultancy firms succeeding with customers at RPA is where there is an open spirit of collaboration based upon equality of experience and knowledge.

Cons:

There is a risk the internal sponsorship and investment sought by the long pilot phase never materialises leading to the customer to either fail as an RPA customer or instead stay in the far slower to scale staircase profiles instead.???Often it is one fantastic use case or an “RPA saved the day” project that gets RPA properly showcased and sponsored leading to the shift into a hyperautomation moon-shot style profile.?This means the RPA vendors should not see a customer that matches this profile as a normal customer, but instead still as a prospect who just happens to have purchased some licenses.?

It is vital the vendor makes sure the pilot phase is successful, which requires their best and most experienced RPA people to be engaged with the customer.?I have heard of some horror stories where off the bench untrained people are left to engage with an important prospect in this pilot profile, you may as well drive the prospect straight to the offices of your competitors.?

3.???The gradual staircase

This staircase style chart is the customer growth profile we see most often in all software licence sales, including RPA.?The customer purchases additional licenses as and when they need them as they gradually increase their use of the product over time.?

Robot licenses bought in lots of smaller incremental deals are more expensive to the customer than single large multi-year commitments where discounts can be negotiated.??The reason they exist is because the customer does not have the c-suite sponsorship and investment to plan for a transformational delivery of automation up front, instead they can only purchase licences one business case at a time.

For customers who scale quickly in this staircase profile, with the larger additional robot licence purchases closer together, this graph can represent a very high-quality RPA leader who, with limited sponsorship and scope, has managed to push through real change through automation.?This often will lead to good sponsorship eventually and better larger licence deals at renewal.

?Unfortunately for most customers the steps in this profile are small and far apart, the license increments represent piecemeal growth of the use of RPA, with many projects being difficult and protracted.

Pros:

Don’t knock it, for many customers this slowly, slowly approach is the only way to scale RPA and with a good headwind might just get to scale eventually.?The staircase can represent a gradual gaining in credibility and recognition in an organisation until RPA becomes a central part of operations.?Most of the customers I know that are doing RPA well have grown following this staircase profile, unfortunately for the RPA vendors it has taken them several years to get to get anywhere near my 10% automated target.

A customer that successfully scales this way can represent both a success story (eventually) and a lot of frustration for RPA old timers such as me.?I do not want it to take several years for a company to scale RPA, I want rapid growth, I want RPA to be done like an offshoring project where the work is lifted and dropped onto the robots at speed using scalable and repeatable transformation methodologies.?

Cons:

The big risk with a staircase is that the customer takes so long to scale RPA that any excitement and sponsorship of RPA is lost as the executives and business move onto look at the “next bright shiny toy”.??Once RPA is seen as a limited success BAU toolset getting the kind of sponsorship needed for more rapid investment sponsored growth can become even more difficult.?Also, the more time it takes to get to scale the more chance of being derailed by unexpected events or changes.??I know one large UK insurer where what little sponsorship there was for RPA was lost during these small increments, and the new CIO stopped the use of RPA altogether (he was stuck in an IT purist anti-RPA mindset, of course the customer went back to RPA again after he left a few years later).

Another risk is that the RPA vendor might segment this type of customer as successfully growing and therefore not give them the intention and investment the customer needs, even if the customer is growing at a far slower rate than they should be.?This can leave a customer with the potential for enormous RPA scale left on their own and hardly scaling at all.?I have seen celebratory emails in a sales organisation celebrating tiny upsells in customers where the truth is the upsell should have been seen as a disappointing undersell given the potential.?Segmentation models at RPA vendors need to be nuanced enough to include rate of licence growth plotted against expectation for the customer.

This profile can sometimes represent either a ‘departmental sale’, as described as a key RPA risk in the Lacity & Willcocks RPA risk mitigation book, or it can represent a shared service organisation, such as IT, having an RPA capability which is sitting back and waiting for use cases rather than proactively looking to transform the company.?Either way, c-suite sponsorship for rapid cross company transformation through automation is lacking.

4.???Small and stalled (and needing to start again)

This profile represents stalled RPA customers that have lost momentum.?These customers may have previously been in the staircase or long pilot profiles.

This chart looks like the long POC chart but the plateau of not scaling is a lot longer to the point all the initial excitement and promise of doing RPA has now been lost and the organisation needs to be resold the potential of RPA again as though they are a new customer.

Examples of this are a large utility company that for many years only had 11 robots. There was zero real sponsorship and no real ownership or leadership to spread RPA outside of the one department where RPA was being used.?

What these companies need is a relaunch of their RPA capability, almost starting again from scratch and a proactive sales push treating the customer like a prospect logo.?To prevent making the same mistakes again that relaunch needs strong sponsorship, which may be difficult to find if they have failed previously at scaling RPA, and an injection of expert services to help to remove existing blockers that prevented success the first time.

Pros:

The good thing about a stalled customer is that it is obvious to everyone that there is a problem, unlike the staircase profile where small incremental purchases can cover a multitude of sins.

A customer knowing they have problems might be more willing to accept help and advice and the RPA vendor may be more willing to invest in providing help if the size of the company has potential for far more licences. The stalled customer is therefore an opportunity for a turnaround and future success.?

Cons:

The main risk is that the customer blames the RPA vendor rather than themselves or their service partner and changes the RPA platform expecting some kind of miraculous solution to their problems rather than solving what they have been doing wrong. ??I have seen several companies change the RPA platform and be left with the same organisational and leadership problems that stop them from scaling.

Some of the customers in the staircase profile and very long pilot profile should also be classified as stalled because their rate of license growth is so slow it may as well be classed as static or the pilot phase has taken too long.

Sometimes customers get themselves out of a stalled state with a change in leadership, or a business-critical problem or major transformational program that RPA ended up saving the day with thereby getting the technology spotted by executives as something that should be used more.??More often however the only way to get out of the stalled state is a two-pronged strategy of sales somehow engaging with sponsors high up enough to shake things up and an injection of experienced services to help the customer to remove all their blockers and do RPA the right way.

Conclusion:?What do these four profiles tell us about scaling RPA?

Look again at the licence profiles in the charts above.?These trends are not unique to RPA, you will see the same across the wider software industry and in other sectors such as the BPO space.?We are not unique and the answers to our problems are not new.

• The first key fact to recognise is that most RPA customers that successfully scale manage it via a gradual staircase profile.?This is the slow route that usually takes many years, not quick enough as is needed to counter the annual losses and quarterly revenue targets of the big RPA venders.
• The second main lesson is that the first RPA project delivered by an organisation is usually the most important one.?It is either the pilot phase before scaling fast or it sets the trend for how fast the customer will scale in a staircase profile.??RPA venders need to invest in ensuring the success of their customers first project, I would recommend a ‘Customer Onboarding’ team as part of Customer Success and working with the training teams that focuses fully on first customer projects. ?Get it right first time and everything after becomes quicker ‘painting by numbers’ projects.?
• The third lesson is that RPA venders are almost always failing at selling automation into the c-suite.??Moon-shots hardly ever happen and initial smaller sales are rarely being followed up with big deals once the technology has been proven and a showcase is in place.??Considering the very high proportion of investment RPA vendors have ploughed into sales organisations over the last 5 years and the investment in partnerships with the big consultancy firms, this can be seen as a major failure they still need to solve.

There are examples of companies that have got to the 10% of all work done by robots target so we know that RPA is difficult to scale but is very much possible, if an organisation has failed to scale RPA so far it does not mean it cannot be done, they just need more help to get there.?If most RPA customers were able to get to the 10% rather than very few the RPA industry would live up to the early hype it had a few years ago.

Notes:

Any opinions I give in this article are my own and not based upon any single RPA company.?Any data or graphs I provide are based upon published public records.