With 44% dissatisfaction, it’s time to get real about the struggles of RPA 1.0


Who remembers this classic “statistic” from a couple of years’ ago, where we caught some friends declaring RPA fantasies that are simply miles from reality:

We’ve been keen to share with the world that RPA satisfaction has been in positive territory for more than half of the adopting enterprises, which is OK for a relatively complex new type of solution that takes a while to get right, and we revealed a 58% a satisfaction rating a few weeks later.

Sadly, two years on, satisfaction ratings have not improved

Our brand new study of 355 operations leaders, conducted with the support of KPMG, has revealed that only 56% of the Global 2000 express a positive experience from process automation and robotics:

Click to Enlarge

What’s alarming about this is we asked operation leaders to assess the satisfaction levels of all key C-Suite directives, such as the adoption of AI/ML, enabling hyper-personalization, ever the old faithful of “driving down operating costs” …and process automation finishes dead last.  I would argue this isn’t because process automation and robotics initiatives have been a disaster, but more likely, expectations from the sell-side have been vastly over-inflated.  While this may sell more licenses and consulting days in the short-term, it will stunt longer-term growth for the industry.  Let’s delve deeper here…

Why are process automation and robotics lagging in terms of satisfaction?

The over-hyping of how “easy” this is. The problem we have in this industry right now is an obsession with glittering outcomes and not enough real-world guidance on how to achieve them. The majority of robotic adopters have never ventured into double-figures of bots deployed, and many simply have little idea how to progress their adoption beyond a handful of pilot projects. The focus of the narrative needs to be directed to helping clients develop broader robotics strategies across organizational areas. We’re also hearing about some enterprises aborting some major RPA projects because they just didn’t expect the cost and scale of the effort to be so large. So we need to be realistic and balance the great benefits of robotic software with the challenges of training people on it, scaling the technology and gaining buy-in across business units.

Lack of real experiences being shared publicly.  Enterprises RPA adopters are fed up with the constant deluge of “motherhood and apple pie” being served up by the industry when they know full well these deployments are among the biggest challenges their customers have ever faced.  The RPA vendors – and several of the leading services firms – will be far more appreciated if they started sharing the real customer experiences with the world. For enterprise operations and IT executives, being successful at automation and AI is career critical – they want to learn how to be effective and how to invest their time wisely.  If this stuff was easy, they’d be out of a job pretty quickly, but fortunately for them, it is not, and they can embrace these experiences to increase their value to their firms and their careers.

Huge translation issues between business and IT.  Simply put, most IT folks have little understanding of RPA and think all their world problems can be solved with an API.  RPA – for most operations executives – is the first time they have had to work with actual software development and get involved in some low-code activities.  And they approach it with a “process first” context – how can I use these tool to integrate these apps / screen views / objects / documents etc?  I can honestly say I have been to two major software developer conferences where RPA is on display and the developers are simply clueless with regards to how RPA fits into their world of platform modules and APIs. If we can’t bridge this divide, we run the risk of RPA being relegated to the scrap heap of failed technologies.

Obsession with “numbers of bots deployed” versus quality of outcomes.  If I hear another executive claim he/she has deployed over 100 bots, and that is their prime measurement of success, I will start naming and shaming =)  In all seriousness, there is no race the finish-line with this, and can see many enterprises still grappling with automation projects for many years to come.  The ones whom I have met who have expressed the most dissatisfaction are those who have bought far more licenses than they know what do to with, and have real issues trying to explain this their over-investment to their bosses. I’ve even seen some fired because of it.

Failure of the “Big iron” ERP vendors and the digital juggernauts to embrace RPA.  Let’s be honest, with the exception of SAP’s small acquisition of Contextor, which didn’t even warrant a mention at the recent Sapphire event, the IT bellwethers haven’t fallen in love with RPA.  It’s just not sexy and scaleable enough for their suites, and if you read some of the guff on social media from IT “thought leaders”, they have no bloody clue what RPA really is – and does. IT people just struggle with a technology that starts with a business process headache – they prefer to work with code-intensive products that can be shoe-horned into businesses, which they can make really complicated to install and manage.  Only Pega, from the world of large enterprise software, has made greater efforts to embrace process automation with its 2016 acquisition of OpenSpan, and I was quite impressed with the prominence it gave digital process automation at the recent PegaWorld event, but, even at Pega, it’s clearly a challenge to communicate the true benefits of RPA to the Pega traditionalists, whose entire world revolves around its shiny CRM orchestration platform.  While we can point to all the lovely partner announcements we hear from the big three RPAs about their Google, Microsoft, Oracle, Workday, IBM etc partnerships, the truth of the matter is excitement and investment levels from the IT glitterati have been nothing close to what we were hoping/expecting just a couple of years ago.

Bottom-line: Over-setting expectations is putting the automation industry at risk of failure, not setting it up for the success it should be

The lesson here is that the sell-side is pushing too hard to sell too much too quickly and is setting up too many clients for disappointment.  We just need to set expectations better and get the balance right…. Rome wasn’t built in a day.  We need to hear the RPA big daddies talking about how enterprises are grappling with real issues of internal change management, training and education.  We need to hear our IT leaders finally reach their “aha!” moment when they finally understand how robotic software is pulling in their frustrated business operations leaders into their world of embracing technology to help achieve real business outcomes.  Because one adage has rang true for 30 years now – design your processes the way your business needs them to achieve the business outcomes you crave… then invest in the right technology to make this happen.  RPA has the potential to be the first true catalyst to make this a reality, and we mustn’t waste this opportunity.  Let’s create an industry that can flourish for the next 30 years, not one that we’ll break in the next couple with our greed to get rich and close that next contract…

Posted in : Robotic Process Automation, robotic-transformation-software



Leave a Reply

Your email address will not be published. Required fields are marked *

  1. hi,

    Very interesting article – however i have to add few more comments.

    How are RPA vendors measuring their performance – is by the number of BOTs sold or customer satisfaction of each of the BOT which are in operations.

    I havent seen/heard about a single client so far who has involved with BOTS COE in last 2 years – sharing the experience of managing and scaling the BOT performance

    Poor quality of resources who arent even aware about the latest version of the RPA platform and feature, who is focusing on retraining and educating them on new features which will help them in their development.

    Why cant RPA scale up and what issues we should be looking at in future ?

    As a COMMON man – why should i invest in RPA and where would i see my organisation with BOTS in next 2 -5 years.

    Looking forward to hear on my comments

  2. Very well explained. Also, I believe that the leaders like UIPath, etc. have been funded so much already that other platforms that have better and more realistic automation capabilities are not getting a piece of the cake. Before selecting an RPA tool companies should also look at small vendors which may be very good at solving their problem.

  3. I wholeheartedly agree. It’ no surprise that the initial wave of RPA “science projects” has a lot of room for improvement.

    It’s very clear that tactical, task-oriented automations will not unlock real business value.

    There’s a parallel to be made between where RPA is now and the scaling up of ERP, BPO, or cloud. As with those, the real objective is to re-think and optimize processes in light of Intelligent Automation’s powerful new capabilities. Once these are effectively designed and implemented, it is equally important to have a robust feedback loop to keep these new processes organically efficient.

  4. I couldn’t agree more Jayant. Enterprise customers and users of RPA products have woken up to the fact that there are much better tools on the market right now that actually meet their needs and goals vs continuing to use outdated behemoths that poorly integrate their applications and include many unused or redundant features. I know of one such modern and innovative enterprise platform….edgeRPA….that integrates directly at the data and web layers for any application plus VDIs like Citrix via its ICA protocol; all from a single UI. Why would any large Enterprise continue using costly tools that persist with methods developed in the 1920s when there are much better alternatives to consider focused on intelligent ‘workflow’ automation such as Edge.

  5. What a great article. Forget the “easy-to-implement hype”, implementing RPA for enterprise value is as hard as any IT-enabled business transformation programme. That is not to say that the potential for the multi-purpose, multi-skilled digital workforce isn’t huge, it really is, but you don’t get there just by having operations people implement software (and skilled configuration and effective reuse of objects is more nuanced than even certified developers might attest)

  6. Thanks Phil Fersht for the great insight!
    First, real expertise, acumen and awareness shall be eventually injected inside Buyers governance and decision makers. Second, huge benefits can only be granted by using reliable sources at the right price, not necessarily at the best price. Third, as also mentioned by Rob King, vendors should be kept granted, being challenged to propose the best service at every level of every organization. Well done RPA will never delude the expectations. Luca

  7. While there are case studies of automation in the industry with variety of outcomes, such articles call out the hype, highlight challenges as well as opportunities, and push the leaders to think differently. In the era of paid content marketing by some analysts and advisors that are supported by heavy marketing investments by vendors, presenting different perspectives through statistics and research like this is noticeable. This is critical to ensuring a balanced view and grounded approach to evolving #automation as a tool. Thanks to Phil Fersht and team.

  8. Love the fourth point on “Obsession with numbers of bots deployed versus quality of outcomes”. We had a client the other day who wanted to deploy a dedicate bot to automate a month end process that currently only takes 12 man day effort per year for a resource in low cost location. Clients are still swayed by the novelty factor of RPA that results in long term dissatisfaction. We actually need to execute RPA as any other transformation project and ask the tough basic questions upfront- “How will adopting RPA benefit my business ?, “How should I re-design my process in the most efficient manner to work with RPA” , “Whats my Plan to get there”, “Have I factored in all costs ( services, support ) and not just licence fee”, “What are the (realistic) KPIs on projected ROI, process improvement” – Only when the above questions have been assessed should businesses embark on RPA adoption and then I would expect the satisfaction index to go up!

  9. It’s true that “Over-setting expectations is putting the automation industry at risk of failure”.
    As a devoper I can say We can’t automate every process. So it’s important to set expectation of which process will automate and which not.

  10. Take your pick:

    Poor build quality – no Re-use
    Poor sponsorship and change management
    Poor process automation assessment
    Poor infrastructure
    Poor governance : Business led IT avoided
    Poor operational platform: no command centre
    Poor automation talent development

    Deployed properly the pure RPA products tend to work.

    Dissatisfaction with RPA or with the Automation Programme?

  11. I agree with the reason that the disappointment is due to the over-selling and largely contributed to the likes of the major management consultancies. There are several cases of MCs committing to massive efficiencies to Financial Services clients to make the deal look lucrative and failing to deliver on those promises.

    The over-hyping of how “easy” this is. – Dont think so. The technology is still easy to create and deploy. RPA Porjects fail due to over -ambitious process selections and lack of governance!

  12. Hi,

    Great insights with deep research on RPA. I request for your help to get understanding on the BOT performance measures. 1st measure is investment vs ROI. Which is easier to find out. But it wont be justified to measure only monetary benefits. But we also need to see the qualitative benefits. So, can you please help on measuring the ROI interms of qualitative benefits and others of you can suggest.

    Amarendra Tiwari

  13. Mixed feeling on this. The final conclusion is correct i.e. overhyping is coming home to roost.
    However, having had a LOT of success in Automation (note I don’t say RPA) at large scale, here’s a couple of things to think about
    – The goal needs to be Automation, not RPA. RPA is a tool, and sometimes not the best one to use to Automate.
    – Too much emphasis on ‘magic’ happening using RPA has occurred due to over-marketing from the tool vendors (no surprise)
    – Do not look to the SAPs of the world to adopt RPA. Their focus is on more SAP, not integrating/ automation diverse systems
    – Automation is a technology project. Bring discipline, good process, analysis, design, control and all the good things all you professionals know about! (And yes, you can STILL be agile and fast).
    – Yep, RPA itself is moving through the hype curve. No surprise
    – Yep, ML/ AI is higher rated because it’s at the FRONT END of the hype curve (give it time!)

    ‘Nuff said

  14. RPA is always driven by people who don’t have any idea about how the day to day business functions
    We need a proper share of functionals/architects from an ERP background to have the skills and understanding of RPA, and not just the resources emanating from programming background. I don’t understand why no one thinks of making automation holistical approach leveraging what we have from both sides. If RPA has to succeed in SAP oriented side , it should smoothly and quickly be able to call the functions, proxies and APIs of SAP. There should be clear approach be defined for synchronous and asynchronous cases of data among system and then fine tune the approach.

  15. Spot on Phil. “Over” is the watch word regarding an increasing number of RPA customer experiences. None of which has to do with the tech itself. When RPA fails, it’s because zealous sales efforts oversell, over-hype, over-simplified, etc. Pure RPA, tooling and methodologies to remote control software for the purposes of system’s integration, can deliver significant value. But as an industry, we do ourselves no good by extending the domain to be things it’s not, and make promises it can’t deliver. The biggest reason for failure we see has to do with another “over”, namely overwhelmed. Most RPA projects are deemed a success day one because they seemingly do what they are supposed to do. High-five everybody – launch party. The reason why they are not deemed a success six months later is because the end-user organization that inherits the production management role is overwhelmed by the support effort.

    Things change, things break, and if the production management group is under-prepared to evolve the automations to accommodate change, those automations will break and projects will ultimately fail. Vendors are all too quick to sell, implement and run. I’ve always believed RPA as a managed service is a giant opportunity because successful RPA doesn’t just happen. It requires, a plan, solid tooling, proper testing, and a whole lot love in production.

    Joe Labbe

  16. A to the point article as always Phil. This means that 56% are satisfied and if so have they set realistic expectations and to quote from the article “Because one adage has rang true for 30 years now – design your processes the way your business needs them to achieve the business outcomes you crave… then invest in the right technology to make this happen” i.e. put the cart before the horse .

  17. @Mike Hobday – am with you on that… especially on poor governance and talent development. I also blame poor consultants and neolithic marketing… PF

  18. Phil – the RPA vendors dash for growth saw product marketing and sales teams growth way ahead of vendor capability and market skills. Either business leaders will keep faith and invest to get it right or RPA will become just another contribution to technology debt.

  19. I too have mixed feelings about this notwithstanding the fact that I totally agree with Phil’s views.

    I would like to add a few perspectives:

    1. Attended vs. unattended:
    If you scrape a bit below the surface, you realize that over 90% of the RPA licenses sold are of the “attended” variant. This lends itself towards task automation rather than process automation oriented “unattended” variant. Good luck trying to get any “ROI” with task-level automation.

    2. SI partners:
    Many of the so-called automation experts provided by the SI partners are inexperienced and clueless. They treat RPA and Automation as synonymous – clearly a fallacy. Plus, they tend to approach it like they used to deal with newer programming languages in their heydays. Third, abysmal levels of domain knowledge spells doom for automation engagements as the “experts” do not analyse any of the upstream or downstream processes and focus their attention only at the task or process-step level of automation. Fourth, service providers should focus on adoption of RPA within the wider automation umbrella – instead, some of them focus their energies on creating proprietary RPA platforms or components such as the orchestrator/controller.

  20. Well presented article Phil. The flux in the market dynamics – technology trends, over hyped capabilities, over simplified execution, opportunity grabbing by ORMs and SI partners, confused customers who don’t want to miss the bus……
    While customers are getting into RPA bandwagon, they can use this opportunity to simplify their processes (in case they are legacy) to make it relevant and appropriate for today’s end user needs and then embark on RPA journey with a defined objective. Maybe this will help them take conscious decisions and not get frustrated after few months.

  21. True.
    I believe Sap combination of Process Mining / IBO software plus iRPA which is deep learning based shows great context sensitivity and thus genuinely capable of providing process automation.

  22. I believe that part of the problem is the lack of planning and metrics used to measure the effectiveness of RPA by the customer. “Low hanging fruit” should be the first place to look and an ROI can be easily measured by the number of FTE’s that are no longer required to provide the manual labor for repetitive data related tasks. If you plan to “shoot for the sky” and roll out a large project, then you should expect limited success.

  23. Isn’t 28% and 28% = 56%? Let’s not give more credit than is due. As a “digital transformation” solution architect who has executed several projects that involved RPA I can attest to these findings. And yes, the simple metric of “number of bots deployed” may be a convenient way to quantify success but in reality is quite meaningless.

  24. RPA failures and this dissatisfaction is a good thing. There will be learnings which should benefit the ecosystem eventually. A reduntant process automated is just an automated reduntant process which also did not automate well, so double pain. We need more statistics, more fine grained to determine the common issues. Agreeing that expectation mismatch is a big contributor to this dissatisfaction.

  25. Oh well. It took a several years and some millions but here we are. The hype curve will hunt you down !!!

  26. Very good reasons why satisfaction is not higher and I agree with them all and will add some details below. I would also like to add another reason which you touched in your article…the cost of those first years of getting things started and using an external partner to help can be much higher than advertised or assumed.

    The over-hyping of how “easy” this is…I don’t believe in the anyone anywhere can automate. You need some technical background/understanding because just like Excel macros, you can’t just record and play and expect it to work.

    Lack of real experiences being shared publicly…Not everyone wants to share their ingredients to their secret sauce of automation success 😉

    Huge translation issues between business and IT…I think the business needs to optimize their processes first then hand off their streamlined process for automation. When this doesn’t occur, often times rpa projects are seen as failures due to unforeseen flows that cause bot failures. RPA + API’s should work hand in hand to “…to integrate these apps / screen views / objects / documents etc…” only after the process itself has been optimized and shared globally for all to follow.

  27. We see this in many areas mainly inside IT, but also with other software tools used by the business (Excel is still the most popular tool for building models). You can’t focus on a tools-first approach to anything. Having designed solutions that include RPA as a component, I concur on your assertion that this is being oversold. It’s part of an end-to-end automation and process solution. It may require integration with external apps and data sources, operating system platforms and existing legacy processes. This cannot be approached successfully unless the totality of the business outcome is properly conceived.

  28. Hi Phil

    You have touched the right chord by writing on this topic. There is no doubt that RPA has been sold like any other service and for this the onus is on both sides to align themselves on expectations, investments, results, support from business. Clear ownership and defind timelines for results at every stage of implementation. Ultimately digital transformation is all about delivering value to business and if the results are not delivered and measured then it does not add up to the business strategy, vision and objectives which an enterprise is aiming for. What remains is all that is glittery and golden with no real value and future use.

  29. Some of the challenges facing RPA are the same ones we’ve seen with countless previous tools, especially the seductive lure of the “tools-first” approach mentioned by @jpmorgenthal. But there are some specific challenges as well. Adding a single robotic patch to an existing process may deliver short-term benefits, but how are users supposed to combine hundreds of bots in a coherent and lasting manner?


  30. Believe it or not, ITIL V4, of all the places, says that we should first look at optimising the process while attempting automation. Truism much?

    Number of bots deployed is just output metric. Impacting bottom lines, MTTR, context switching costs for the shared services personnel, etc. could hint at outcomes. If process is optimised as a result of embarking upon RPA deployment, that’s definitely getting into real value territory.

    BTW, very unfortunate to hear about the shelfware even of BOTs.

    Not integrating RPA with the APIs and connectors of ERP, CRM, HCM, etc. is definitely a tragic misadventure.

    Thank you for this post Phil! A much needed kick in the right anatomy of vendors and practitioners. Hopefully for consultants too.

  31. RPA is no magic bullet to improve efficiency. There are other ways to do that like process optimization. Plus, the measure of outcome is also doubtful. This is an important article.

  32. The success abour RPA program depends on major percentaje from candidate process and governance.

    Interesting posts.
    Thanks everyone about your comments.

Continue Reading