This article is published in collaboration with our key partner, Basico P/S.
RPA the day after
For some years now, RPA has been the “new hype”, and is in the top 10 of all digitization agendas around the world, but now reality start to emerge. A report released last year concludes that although several companies achieved the desired and expected scalability with RPA, this increase was limited to a leap from 3% to 4% of respondents from 2017 to 2018. Also, several articles deal with “The PoC cemetery”: Countless companies have made a PoC, perhaps also a larger pilot project, but it strands there. There is no-one to drive the project further and what has been acquired is an inspiring, but quite superfluous “machine that goes beep”, that quietly error handles itself out of existence and justification as the world changes around it. And often consultancies buy it at an expensive price.
The fundamental causes can be many, and they are well-described: The processes were too fragmented; IT was not on board and constantly changed preconditions independent of the RPA project; there were not enough resources internally to take over the robot; the robot was not considered part of a major solution strategy and became a “stupid” employee who did not give any value other than the manual.
Long live RPA!
If we are to avoid this deadlock and give RPA the place it deserves, then the concept must be turned upside down. The concept to be proven in a Proof of Concept is not automation. It has gradually been proven and it should be obvious that IT systems can be automated by using IT. Of course you can prove the degree of complexity in the automation, but that is not what is demanded when you want proof of a new product. Imagine buying a car – you want Proof of Concept – a demo. The car dealer puts the car on an auto lift and shows you how fast the wheels can spin. Or he puts you in the backseat and take you for a ride. It is not quite enough, is it? The concept you want proven is not whether the car can drive and the wheels can turn. Instead, you want to test how it fits you and your needs. That means: Do I like how I sit in the car? Is it easy to use? And so on. The important concepts for the car dealer's sales are thus aimed at you, the receiver, and how you feel about the car. That is why car dealers let you drive their demo cars. They do not need to prove that the car can drive, but that their car is the best fit for you.
Similarly, the concept of RPA should not be whether the task can be automated, because it can be. Instead, the concept must be whether you can figure out how to use the tool. Keep in mind that it is all about whether you can use the new tool or not. Do you like how it looks? Is it intuitive? Can you solve the problems that undeniably appear? Can you set it up to take you from A to B? The concept need to be aimed at the recipient and the person using the tool in the end.
The formula for the RPA-concept must thus change to: We do not want to prove automation, but usability. Through courses and workshops usability is proven. Foxtrot RPA is probably the most intuitive and user-friendly RPA-tool in the market. Foxtrot can be used in all departments, at all levels and - most importantly - often without prior IT skills of any kind. It is a quite unique tool and it is in that exact direction RPA must move to get out of its deadlock. Automation must not be an IT project, because there are already thousands of IT projects in a delayed pipeline, and if you are going to put an IT expert to work, why not then just create an API, a new application or an add-on to your ERP? RPA must be a tool that can be used by the individual employee, no matter what he or she works with in their daily work.
Therefore: RPA must prove that it is user-friendly and can be anchored directly with the recipient and the process owner. This is where the real challenge lies. But that is also what already partly forms the base of all the hype: That robots can be everybody's, that technology can be democratized, that it can be yours and mine. So far, however, RPA and most suppliers have focused on the automation part alone. The PoC cemetery is therefore being filled with projects no one can revive.
Basically, the logic should be that if you can teach the current process owner how to automate, then you will get the most optimal automation consultant on that task. This means that many of the challenges mentioned at the top are easier and faster solved. Does it sound sensible? So, let's agree to change the concept of RPA: Everyone can learn to automate. That is the goal we should aim for.
#FoxtrotRPA #ProofofConcept #RoboticsProcessAutomation #Foxtrot #consulting #automation #RPA