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:
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.
Related: Grow Up! Start to Use Advanced Business Intelligence
Partner up
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.