Lately I have been delving into the different business models for Robotic Process Automation, or as it’s called in short: RPA. How are these RPA business models implemented, how are suitable processes identified and how are the services charged? Most important, why do RPA projects fail most of the time, although they initially seemed to be with high potential. In this blog I will elaborate on which processes are suited for current state RPA and explain how I think they should be implemented. In closing I will dive into the remuneration of the RPA provider.
To be or not to be
First, what is robotic process Automation exactly?
“A technology designed for the fully automated processing of rules-based business processes by software robots. With Robotic Process Automation, you can overcome all obstacles that inhibit efficient operations – and without making any fundamental changes to your IT infrastructure at that.”
I found this relevant definition at the website of Another Monday. And there are off course a lot of other definitions and background to be found at Wikipedia. But note that not all processes are suitable for RPA. One can identify business specific processes or vertical processes that can be made suitable by taking among other aspects the following into account:
- Do the eligible processes require a lot of manual “clicks”?
- Are the processes done with a sizable volume?
- Is the process perceived as time consuming or as administrative hassle by your customers?
Key motivation: improving customer satisfaction
Recently I attended a lecture of Casper van der Veen, head of strategy of Aegon. A passionate speaker who was explaining a group of students how Aegon automated their process related to life insurances through RPA. What I liked a lot about his talk, is that he didn’t approach this as a pure cost play, but as a way to improve customer satisfaction by enhancing throughput times. A viewpoint I earlier subscribed to in an previous article about RPA. Imagine reducing throughput times, lowering cost, enhancing client engagement whilst not having to go into the depth of your legacy systems…
Picking the right technology provider
Wanting to establish all that develops the need to select some kind of technology. The list of potential technology providers is not extremely long. RPA is still an emerging market; technology providers are just slowly picking up. What I find interesting in the RPA technology is the way it is deployed. Is it purely a software tool or can you drive value added services from your provider, like identifying bottlenecks in the execution of processes? In that sense, I firmly believe that automation companies that both understand the process and have proprietary technology are getting ahead of the pack. It takes time to understand how people currently work the process. In relation to that it is vital to understand that not all people are executing the process as desired or defined. Therefore learning might be a bit difficult. When not taking the differences in process operation in consideration, it leads to one of the key arguments that implementations fail.
The implementation of RPA is not a procurement kind of process; you are not just buying a software tool. RPA requires very clearly defined business requirements and very clear rules of engagement. The tools are not very comparable to each other. Therefore it is vital to do a more extensive deep dive into the benefits than you would when acquiring a normal software tool. For me one of the most important aspects is the implementation track record for success. In other words, the way the vendor desires to enter into risk-reward based outcome instead of unit price or even worse a license fee. Other very important elements are flexibility and business knowledge in relation to the processes that need to be automated.
This brings me to why so many RPA projects still fail. In my experience, so many projects are undertaken by a Center of Excellence (CoE), where people are running internal RPA projects. This doesn’t work. A clear example we have seen the last few years in the area of data science. A lot of companies have tried to apply data science on their own, but are now moving away to standardised services and building blocks. My advice: don’t do it on your own. The second most important reason of RPA failure has to do with the fact that most RPA vendors are currently selling a software tool instead of business results. Therefore once they have sold their license, their customer engagement stops.
RPA can drive significant benefits for your business. However, finding the right partner is not easy. Look into your company DNA and find a fit on that level. Look for joint entrepreneurship that has the potential to grow into a long term commitment. And yes, it also means hiring a consultant in order to help you find the right partner and processes.
The Benefits of Analyzing Your Client Base
10 Reasons to Preserve a Legacy
This Is What Makes Your Strategy Useless
The ABC’s of Power Spending
The Simple Little Model That Will Supercharge Your Leadership
The Important Question For Your Clients Contemplating Retirement
What’s Happened to the Art of Note Taking?
4 Habits For Responding To People That Piss Us Off
The Bad News About Record-Low Unemployment
11 Most Interesting Things About Facebook’s Libra Cryptocurrency
Research10 hours ago
The Bad News About Record-Low Unemployment
Development10 hours ago
Why Advisors Should Use Multiple Marketing Channels
Equities11 hours ago
Small Caps May Lead A Market Rally
Insights1 day ago
Facebook Libra: Weighing The Pros And Cons
Research1 day ago
Trump’s Trade War Is Paralyzing Business
Development1 day ago
7 Things Many Advisors Don’t Do and Fail as a Result
Global3 days ago
Should You Follow This Billionaire Investor Towards Gold?
Digital Strategy3 days ago
What Does the Fourth Industrial Revolution Mean for Healthcare?