The real unfiltered truth behind the lack of RPA use cases


My good pal, Steve Rudderham, formerly of Genpact, Capgemini and Accenture fame… and recently anointed the great GBS leader at Kelloggs, posed the irresistible question to me on our Robotic Premier League blog:

Phil, One thing we’ve struggled with is really where the rubber hits the road in terms of credentials. There are a lot of good innovation “stories” around RPA but several of the players on your list have really struggled to articulate savings and examples outside of their own in-house improvements using macros in excel. When do we expect more maturity in this space in terms of client stories that the rest of the industry can get behind? 

Fair enough, Steve, great question… so here’s my answer:

@Steve Rudders –

It’s early in the morning, the filters are off so I’ll just answer your question as bluntly as possible: We live in ignorant times – people are blindly groping for that next vehicle to drive out cost, and RPA currently fits the bill.

I, personally, thought the hype would die down this quarter as companies struggled to figure out what not to automate. Don’t get me wrong, the RPA value proposition is tremendous – taking high throughput, high-intensity processes that require large amounts of unnecessary manual intervention and digitizing them to free up thousands of man/woman hours, is a terrific way to add value to a business.

But RPA is a murky, weird, and very complex, technical world – you need people with good process knowledge (not too hard to find), you need people to help evaluate what to automate in the software that makes business sense (you can’t automate everything or you’ll forever be automating and forever be spending money on automation) and you need technical folks who can help integrate the software behind the Citrix firewall in enterprises, who understand complex APIs and security issues. You also need a skilled change management plan as the “robo” paranoia can make the old offshore paranoia seem like chicken feed. Then you need some serious robo-governance competency… and these people are really hard to find. You can’t train your 28 year old MBAs to be robo-governators – these need to be your battle-weary operations leaders who know how to balance politics, panic, understand enough about tech to be dngerous, and can communicate the bloody stuff to leadership and middle management.

So to conclude, we will need some time before the true excel-proven results really materialize – and many firms will forever struggle to metricize the true ROI of RPA down on paper. It’s a bit like ERP 20 years ago – did anyone ever truly prove the ROI from huge investments in SAP or Oracle? It just became “assumed” that you couldn’t run a business effectively without and ERP system. In a couple more years, we’ll just assume you can’t run a business properly if you haven’t retro-fitted RPA into your down and dirty business processes to make some of them run better.

So most people associated with outsourcing and shared services are now aligning themselves in some way with RPA – the advisors are shaping up to make their clients look like they have a plan, the providers are working hard to make it look like they have RPA firmly embedded in their capabilities, and many savvy buyers are slapping RPA somewhere in their job title / job description.

But the true answer to your question – “when will we see more client stories the industry can get behind”? Simple – when the hype finally fades and those firms that made the smart investments finally put their experiences to print, unafraid to talk about how they improved their business with smart automation software. And this can take years – moving processes into software is a significantly more challenging exercise than moving them to lower cost people half way across the world.

One other issue, Steve, is the paranoia and reluctance of buyers to talk openly about their automation initiatives. Automation is being treated with a much more heightened degree of sensitivity than we ever saw with “outsourcing”.

Having said all of that, I do expect us to see many better communicated RPA cases next year simply because, for the first time, we have software marketing people in our services industry. Experienced software marketeers are simply better at getting their success stories across than services marketeers – because technology is at the core, not people. Enterprises are buying magical products to provide them with magical silver bullets… my concern is we could lose the very essence of operations… that they will always really be about people managing technology… not the other way around,


Posted in : Robotic Process Automation



Leave a Reply

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

  1. Adopting the BPMN 2.0 standards for layered approach to process mapping, once maps have been created at a task or key stroke levels, Opportunities for RPA can be systematically identified. To ensure that this method of identifying RPA opportunities get institutionalized it is important to create the right organisation structure to support identification and implementation of the opportunities. However the pace of progress becomes slower when you have different stakeholders managing different aspects of RPA and they don’t compliment each other or are unaware of how they both can work together as a team for a larger benefit

  2. “…battle-weary operations leaders who know how to balance politics, panic, understand enough about tech to be dangerous, and can communicate the bloody stuff to leadership and middle management.” Perfect.

  3. Great article. Sometimes it also seems that an RPA project is a sticking plaster for software that is struggling to cope in the age of digital process integration, and that we are cutting corners by trying to use RPA to fix processes which are no longer fit for purpose. I think that the best use cases that we are going to see are not so much the sticking plasters, but rather the adoption of great software where process automation and machine learning are core features within an end-to-end integrated solution. That way, we will see processes being automated by design, rather than trying to use the RPA sticking plaster to fix the wrong thing. But the question is, does “RPA built-in by design” fit within the current terminology of what people consider to be an RPA project?

  4. @Tony – I think those poor providers you’ve beaten up over the years would gladly trade you in for a robotic version…


  5. @Chris – “RPA” should simply be native to an application, development environment of business process. We shouldn’t even think about the term – it is just there. You are right that the current use of RPA is a “retro-fit” exercise to make legacy apps and processes function better – as an interim fix, never the end game. However, some legacy works well and doesn’t all need to be written off tomorrow… much of it can last for decades fulfilling a task, or set of tasks effectively. RPA patching can have years of impact to old processes to get them as good as they need to be to get something done!


  6. Great discussion. The hype is mostly based around real stories of success. I think the case studies prove success at large scale, taking a large proportion of back office work. The reality often missed in those case studies is that it usually takes many years to get to that point.

    There are also some sectors where RPA is harder to do than others (HR and F&A spring to mind), where only now are some of high hanging fruit being picked off (thanks to adding cognitive and ICR tools to the mix.
    No one says it is supposed to be easy, and it is often a rush to succeed that causes failures.

  7. Good article Phil. “robo paranoia can make the old offshore paranoia seem like chicken feed” – a humorous take on something which can become a serious concern for RPA success in any automation project.

  8. Phil,

    I have gotten back this past week after graduate studies came to an end, to reading HfS materials and attending seminars. Must say your unique blend of realism and humor is quite refreshing! You hit this our of the PARK on so many levels and so many ways, I could write an article about it. I am still recovering from my last one I posted this morning and I would cited this as central in that article! All the C-Suite leaders need to hear what you wrote loud and clear, “My concern is we could lose the very essence of operations…that they will always really be about people managing technology and not the other way around”. Take that to the Bank or miss out on one heck of a lot of ROI with RPA and way more with Cognitive RPA.


  9. It’s true that like all technology and process innovation RPA also needs the infrastructure to manage and govern the change / impact it creates. Also true that very quickly like ERP , RPA will move from competitive advantage to being a given. Question is – will we lose out on realising its true potential in this rush?

    Ritika Dhar

  10. Nailed it Phil. This is so true on multiple levels. Particularly the risk controls and governance pieces. This needs to be clearly articulated. Good read.

  11. Ultimately, the RPA Evangelicals will have to go beyond the current state of basically being “work arounds” for existing and out-dated processes and demonstrate that they can create serious customer and therefore, business value. Just like for example many of us demonstrated with Advanced-analytics COEs over the last 5 plus years. Otherwise, they risk being dismissed as a “back office ops thingie” or a “hype” or both.

  12. At Virtual Operations, we particularly liked the honesty about the Murky world of RPA. It IS murky and, for many on the band-wagon this is both deliberate and a good thing as they can shine the mirrors and thicken the smoke and claim their place in a market where they don’t yet know what they don’t know

    We started this business long before it became over hyped and we have learned much since. Others will have to go through the same learning curve but they will struggle to do so without the “battle weary operations leaders, the change management experts, the highly skilled RPA engineers and the Robo-governance competence” Phil described. 10 rebadged RPA resources with 6 months experience is not the same as 1 person with 5 man year’s experience it’s more like staffing a large hospital with Junior Doctors

    This is why we believe the “pure-play” RPA specialists will thrive as many of the bigger players continue to work things out.

    Hat’s off to HfS for continuing to lead the market in the right direction


  13. Good question, great article.
    At the Digital Workforce website, we have several videos of different use cases we have automated for our customers, with more coming soon.
    For anyone interested in how our customers have experienced their (very often first) robotic process automations, the videos can be found here:

    To help organisations establish self -sufficient RPA capability, we train their employees to understand both the management and development sides of things and, most importantly, how those two are connected. This has been found crucial, as so many organisations are looking to get into RPA, but are not certain where to start and what to do after the first PoCs have been created.


  14. This article hits the nail on the head!… I sometimes wonder if organisations are not sharing because deployment has proven more difficult than expected! as stated you need a team of people with very specific skillets, and lots of multifaceted experiences!

  15. Very interesting read ! Especially like we can’t think business without ERP, soon will come a time when RPA will be ubiquitous !


  16. Very good question from Steve. Clients in Steve’s similar position also ask us similar irresistible type questions around what is the right RPA governance model and what is the right RPA tool for which process since all software players claim maturity in every process…

  17. Phil – This is a fantastic assessment of another process technology that has been marketed as lightning in a bottle. Just like BPMS, finding the right case is critical to meeting the expectations that are sold to our Executives.

    Yes, the robot can be configured to press buttons in five minutes. However, we’ve now layered in not only understanding the business process, but every screen and data field touched by the original performer. In some legacy systems, that is a lot to account for in those few minutes.


  18. Quote: “Then you need some serious robo-governance competency… and these people are really hard to find.”

    Why are these people with robo-governance competency hard to find? With so many pure play consultancies around and many other prominent service providers around, and many of them in RPA business from at least last couple of years, shouldn’t we have good robo-governance competency by now?

  19. @Kapil – being able to govern an environment where there is process transformation, significant change management and understanding the potential and limitations of the various RPA applications… dealing with both IT and business operations people, as well as software vendors, consultants, service providers, internal stakeholders and perception politics. This is is a journey into the unknown for everyone in the RPA business right now… you can’t train your 27 year old MBA graduate to do this stuff overnight, or your experienced P2P process owner… this requires an evolution in learning the murky world of RPA, which is challenging both from a technology and a process perspective, not to mention the ability to deal with sensitive issues and company politics. Talk to any of the consulting leaders in the space right now and they will all tell you the same thing – they are desperate for new talent to make this work effectively for clients,


  20. Witty 🙂 Nice post Phil, although we have RPA use cases, in this new robo-paranoia world 🙂 I fully agree that RPA is not just about technology but processes re-engineering and profound process knowledge. My best,


  21. Good Post and a good discussion! I may add a few comments:

    1. I don’t like the Term RPA as the real game changer. If this terms is meant to describe a program which automatically executes a (business) process or parts of it in high volumes and at any time, we have done that for many years already. I prefer the term "Cognitive Technology" to describe the capability to adapt the execution of process steps to changes in the environment the process is operating in.

    2. The difference is, that a robot automating a process will always follow a defined pattern. Cognitive Technology will change the pattern on it’s own. This has a tremendous impact on governance of such implementations. In pure automation you can trust that the steps are always executed in the same way and quality (24 x 7) – ideally the robot will notify it’s operator if an exception occurs, which doesn’t fit into the pattern. In Cognitive Technology you have to trust that exception handling leads to the right adaption or extension of the pattern. This implies that you need "some serious robo-governance competency".

    3. The slow implementation of such technology can be attributed to the denial of deficiencies in the organisation and process landscape across all levels of the organisation – not just the executives. Allowing Cognitive Technology to take over parts of day-to-day business is more than an improvement project as part of the digitization program many companies have kicked-off. Just the discussion to what extend the organisation would allow Cognitive Technology to change operational patterns on its own, will require commitment of a much larger stakeholder group.

    There is surely much more to discuss, but it is good that an open and candid discussion takes place – thanks Phil for starting this…

Continue Reading