The rise of RPA over the last three years has seen a flurry of proof of concept projects which have resulted in many organizations dipping their toes into this new technology. The prominence of the term “Digital transformation” has had senior leadership in organizations scrambling to get on the “me too” bandwagon, with RPA having one of the lowest barriers to entry. Many organizations have had pockets of entities carry out their own RPA initiatives, very often oblivious to what is taking place in this space in the rest of the organization. As a result, we now have many organizations who have run multiple RPA initiatives, often with different vendors and technologies, who have plucked the low-lying fruit and suddenly realise that they don’t have a “what’s next” plan.
RPA technology providers often approach the business and operational entities in an organization as they consider them an easier sell. Very often the technology departments in organizations are either rationalizing their technology footprint, or do not see RPA as a solution to their own issues. This focus on the business and the operational entities and the numerous demo’s showing how they can reduce their headcounts or scale at non-linear rates, coupled with the promise of quick turnaround time for RPA projects, has made many heads of these entities eager to try out RPA. Often this is done without or with minimal the consultation of their in-house technology teams. The “IT is slow and costly” paradigm has never been as pronounced as it is now.
RPA initiatives often start in good faith, deliver several of the promised increased in productivity and efficiency, but are then at the mercy of the environments they operate in. The bots that they run, inevitably work in environments that have their own deficiencies in resiliency and risk, with the applications they run on having their own roadmaps in terms of upgrades, patches, change requests and end-of-life issues. Furthermore, any changes needed for these bots, any support for inconsistent behaviour and any errors which need to be fixed, are now at the mercy of less than well thought through continuation plans. It is part and parcel of a technology reaching a mature state that these type of thought processes happen. Although, in RPA’s case, the conversation has been somewhat complicated by the technology’s easy accessibility and its affinity to plug into the business or operational ownership structure of an organization. This trend needs to be contained. Having business ownership of a technology which in turn depends on technology run and maintained by IT teams, without any clear demarcation of roles and responsibilities, will only create further rifts in the business and IT relationship. RPA needs to achieve a balance in governance and deliverability that evade traditional technology projects. The establishment of Agile as the modern go-to development methodology feeds into RPA projects well, with strong collaborations required between business and IT teams to come together to delivery value which the organization needs. The governance that RPA programs need is different from traditional project delivery. RPA demand manifests itself in either micro activity-type requirements or end to end process type requirements. These are heavily dictated by how the business is currently running these tasks or processes as well as how they intend to run them in the future. The governance teams will then need to take this demand and run it through principals that get built into the program over time (Ex: Does the savings from automating this process exceed 4x the build cost + support cost per year”). They then need to check on the resiliency and the risk ratings of the environment that these bots will operate in and make a call on whether this makes sense for the organization. Many organizations have deployed high risk bots dealing with sensitive information, into environments of low resiliency, resulting in negative consequences. Once organization work through and evolve their governance processes, the following thought patterns should emerge:
- A pipeline management process to check demand against supply
- A skill upliftment program to shift some of the subject matter expertise closer to the business and increase the organizations in-house capability
- Thinking around the sustainability of the program and how to make it self-sufficient.
- Thinking around the updating and growing of the governance principals and measurement metrics which cater to the sweet spot of the organizations culture
When you see your organization moving towards having conversations on these aspects, you know you are on the right track. Harness the abilities of the people in your organization who can think critically about these problems and come up with simple and culturally appropriate modes of governance. If you are proceeding along a path of not knowing the impact of the bots you are constantly creating or losing track of what you have deployed, it is time to take a step back and think about the tangent you are on your RPA program. Good faith in large uncontrolled amounts, can lead to just the opposite.