Part IV: Who should be involved in the RPA Implementation?

Many studies have been done on why IT Projects fail and there are various reasons including Technology solutions that are not the right fit for the organization; Not selecting the right vendor, Poor Data Readiness, Lack of leadership, Lack of adequate Training and many others.

However, one of the reasons I feel many organizations overlook is Stakeholder Management. It doesn’t matter how fantastic the solution implemented is if the targeted end users and other stakeholders cannot see value in it, not because it doesn’t meet their need but because they were not involved in the process. In the end, the overall objective is not met. Poor stakeholder management also leads to lack of ownership once the project comes to a close.

For an RPA implementation to succeed, stakeholder management is even more important especially because it’s an emerging technology and many are yet to fully understand it. So, who are these stakeholders that we need to involve?

1.      Senior Leadership. This could be the CEO, CIO, COO depending on the organizational structure. The message here is that senior management must be onboard because they determine whether RPA will be adopted across the enterprise. The Senior Leaders need to understand why the organization should adopt RPA and what they intend to achieve from it. It is only by so doing that they will be able to ensure that adequate funding is made available to make this a reality and also lead from the front and drive the desired changes in the organizations. Without executive sponsorship it becomes extremely difficult to drive adoption across the business.

2.      Process Owners. It is only the shoe wearer who knows where it pinches. As much as RPA is perceived to be about technology, nothing could be further from the truth. RPA is about business processes and how they can be improved so process owners must be involved because they understand the process best, the challenges they face and more importantly they will be the end users of the solution and will be able to truly appreciate the benefits that RPA comes with. Beyond that, they also need to understand how their roles will change going forward, what they will and will not be able to do, what will be handed over to bot. This needs to be managed very well so that the key process owners do not feel like they are losing control but are part of the solution.

3.      Human Resource Leaders. A bot is a virtual workforce that is expected to work with the humans in the enterprise by taking away repetitive tasks that the human would otherwise do. As mentioned earlier, for bots to work we have to tell them what to do, sort of giving them a job description through the instructions/ business logic we give to the bot. As we do this, we will be taking away some of the roles that the human used to perform including come traditional Key Performance Indicators linked to their traditional Job descriptions. The Human resource personnel are key because we need to find new ways of measuring success and performance with the introduction of bots. If for example, a customer service representative’s KPI was the number of calls/requests they were able to process in a day, with the introduction of a bot that takes away some of the tasks, a new KPI needs to be instituted. The Job descriptions will need to be revised as well and the benefits and rewards linked to KPI’s. This is very important as the staff will still feel that their contribution is still recognized in the organization

4.      Technology teams. RPA is business driven and technology enabled. After all is said and done, the bot will need to be deployed in a technology environment, it will still need access to the systems and the requisite infrastructure to be able to run. I have seen cases where the business is so driven by the changes they want to make and fail to involve the IT teams only to realize in the end that perhaps the solution designed does not fit in the existing technology landscape. Therefore, as much as the business will drive this initiative, the technology teams are a key pillar to ensure that the bot’s operating environment is adequately prepared and aligned to the solution designed.

5.      Risk Assurance Professionals. This could be internal audit or quality assurance teams that will help the project team in ensuring that adequate controls have been put in place for the anticipated risks. The days of waiting for solutions to be built and deployed only to realize in the end (mostly through audits) that there are some glaring risks that were not considered are long gone. It is extremely important to ensure that risk management is part of the process. Risk assurance needs to be part of the process so that the right controls are built into the process design.

6.      Information Security Teams. As devices continue to be interconnected the more we are exposed to cybersecurity threats which have far reaching implications should these threats be exploited. The risks we are looking at range from reputational risk to data loss, sabotage, denial of service etc. It is necessary to ensure that whatever solution we deploy at the end of the day can be trusted and this is the role Information security professionals will bring to the table ensuring security of the solutions and not wait for an incident to occur. Trust by design is key.

7.      RPA deployment teams. All the afore mentioned stakeholders are important, however, without the RPA deployment teams we won’t have any bots. The teams would generally consist of business analysts looking at the business process, RPA architects who design the solution and the developers who will eventually build the bots. Deployment teams can either be outsourced or internal within the organization.

8.      RPA Operators. Bots can either be attended meaning someone has to operate them, initiate them to run or unattended meaning, they are designed / scheduled to run by themselves at a certain point in time. Depending on the option picked, it is important to ensure that team that will eventually look after the bots know what they need to do, in most cases the bots operators are key process owners trained on how to manage the bots and escalate as appropriate.

Bringing all these stakeholders together can be a challenge without a structure. This is especially so in large enterprises. If this is the situation in your organization, you can consider having a fully-fledged change management team which would run parallel to the RPA project team. The change management team would ensure that all the stakeholders have been identified, properly mapped, a change management structure instituted with change champions and change agents, proper communication and engagement is achieved at the relevant stages of the project etc. This is truly beneficial as there is someone ensuring that all the moving parts of the RPA implementation process, are given the attention deserved to achieve the outcome that we need.

As much as having all the afore mentioned roles present while deploying RPA is important, remember this has to be put into context and the representation will depend on the specific organization size and structure. These roles may mean different things to an SME as they would for a fortune 500 company. No matter the size of the organization, it is important to ensure that there is some representation present, in some cases you may even have an office/ person play more than one role and that is okay as long as the principles of segregation of duties are adequately considered.

It may be impossible to have all these roles present internally within the organization and sometimes may be not. In this situation, enterprises can consider outsourcing some of these roles that are important but not resident within the organization. What matters is to ensure that proper stakeholder management is done to ensure the success of the RPA deployment.  

So now that you have decided to implement RPA, are you involving the right stakeholders in the process to ensure you succeed?