Expert Insights

When a company first embarks on their Robotic Process Automation (RPA) journey, 99% of the time Joe from Finance, Sarah from Process Optimization, or Tom from IT is assigned to investigate RPA. They probably raised their hand at the monthly meeting, and just like every good suggestion, the person that makes it gets to do it. Problem is, they have never been formally trained on RPA, and more importantly, they still have their full-time job to perform. Furthermore, to show significant success, they would need to relieve some of their daily functions to others, and then as part of their new role, go to other parts of the business and try to convince them to give up some of their daily routines to a robot – a daunting task. This can make for a scary situation because that person is now between a rock and a hard place. Where are they left if this is not something that is picked up by the business? This person was responsible for certain roles, has now given up that role to others to implement RPA, and in doing so put their previous job in jeopardy – e.g. what role would they go back to. Lastly, while Joe, Sarah, or Tom each have a component of a successful implementation, the reality is RPA implementations require all three of these divisions reporting to one person that owns automation for the whole business.

Let’s start with Joe from Finance. Finance holds two very important aspects of a successful RPA implementation. First and foremost is that it is ripe with back office repeatable tasks. Usually a business could start in any variety of areas here and get a good return of man hours back to the business. The second is exactly that, finance will hold the ear of the CFO, and if they can show real returns to the business, the executive team will buy into the deployment and help press on other divisions to each spend more time on which processes would be effective use cases. The challenge with finance though, is they struggle with having documented work flows and ensuring each process is optimal. At the end of the day, bad process in, bad process out, will still hold true for any solution. Enter Sarah.

Most Enterprises will have some sort of process optimization team or six sigma title and spend most of their time with different divisions, helping to streamline and document each process (a VERY important and often under discussed portion of RPA implementations). Without Joe from Finance though, most divisions will continue performing in the same manner they know and trust, giving Sarah very little to go on. Usually the most essential functions within the business are “too busy” to stop, and Sarah will be left with the non-important tasks. When really looking at process identification for a successful RPA implementation, you really need to avoid areas of your business that are, in a saying “an inch deep and a mile wide”. These can be cavernous holes for RPA, consuming a lot of time internally, and also from a very expensive consulting company that is happy to spin your wheels. You will find that 4-6 months down the line, not only have you spun your wheels, your colleagues’ wheels and your boss’s wheels, you will have done so only to be delivering just a handful of processes to the business. From here, the executive team will evaluate how many man-hours were returned to the business and usually determine it is not in their best interest to continue investing in robotics. The last challenge that Sarah will have is that after you have identified the right process, you need to implement it and ensure that you are not setting up some sort of shadow IT. Enter Tom.

RPA is often sold with the idea of the “citizen developer”. While just like anything in life, if you put your mind to it you can achieve, but the reality of it is RPA still requires some sort programming understanding and ultimately people who weren’t a developer to begin with, just won’t be that interested in becoming a developer now. Tom on the other hand works for IT, he most likely has a computer science background and usually they have dealt with enough situations that they understand the basics of how code works and know how the current processes are being delivered from a technical perspective. He will help ensure that IT has setup the right environment and will be able to identify if another area of business starts trying to do their own thing. (We frequently see different areas of a business trying to establish different programs or even multi-platform environments, because a tool doesn’t specifically do the one thing they want it to do). This will also ensure that proper security is being established and not opening a business up to risks. Lastly, because RPA bots, are setup very similar to the way a human is, it is always a funny day, when HR tells you that Bot-Tom (pun intended) has not passed the new employee training and needs to complete it. Having IT oversee the governance around all these areas will help a business avoid major technical pitfalls in every aspect of their business.

Even if, as a business, you have each of these three people working on an RPA implementation, without a head of RPA they will start working in separate areas of the business and ultimately not have an aligned business vision. A Head of RPA will ensure that IT is properly governing your RPA implementation, while also ensuring that the business side is driving it forward. This role will also be dedicated to making sure that RPA is successful and won’t be concerned that his or her job may not be there at the end, because they will be sure it won’t be there if they don’t make RPA an established enterprise solution for the business. For those going down this path, you can find a lot of white papers here around setting up a Center of Excellence, embarking on your digital transformation and understanding the basics of RPA.