Top 7 IT Concerns about RPA

Robotic Process Automation (RPA) has become very popular.  The predictions for spending on RPA varies but according to Statista RPA is growing at a CAGR of 27.7% and expected to reach over 23 Billion USD by 2030. 🤯 Another study and forecast has the value at 50.5 billion USD by 2030 for worldwide.  

Based on these numbers, it's safe to say that it is growing and wow, is it ever growing quickly. After we've seen the accelerated pace of technology the last couple years, it's not surprising we're seeing it continue. What this digital transformation provides is a competitive advantage to organizations that strategically begin their journey now, otherwise they'll be forced into it just to stay relevant and in business. This now becomes the decision of, do you want to be proactive or reactive?

With all digital transformation, we recognize that IT professionals will have concerns about this relatively new technology of RPA with no-code/low-code development. After all, IT professionals are the ones who keep us out of trouble when it comes to technology. 🙏 The good news is that these concerns do have answers and solutions. 

So get a new coffee brewed and let's dive into the  top seven concerns. 

➡️ 1. Data security is a huge concern with every company. Data breaches and ransomware are in the news it seems like every day and many feel that RPA increases this risk to organizations. In most cyber instances, the root is often traced back to a user initiating it inadvertently. Things like clicking on an email link - whoops! Not following best practices and taking shortcuts in the process, etc.  So the risk isn’t heightened but it may be different in how we approach it and manage it.  

When it comes to our human workforce, we implement processes and educate, educate a little more and re-educate. It takes a while for a new process to stick. With our digital workforce (RPA) other things are put in place to mitigate this risk.  These include ensuring proper development practices and standards, encryption of the bot and the data in transit, audit and review of the bot activity, separation of duties (just like when a human would be doing it), monitor and address vulnerabilities and leverage change management to control changes to the bot.   

Ensuring strong governance is important with humans performing a task and are no less important with bots performing the same task.  When a bot is created, it needs to match or exceed the security needs of the process that is being replaced.  If the current process requires Two-factor Authentication (2FA) or Multi-factor Authentication (MFA), then the bot needs to respect this requirement and provide a way to do this at the same security level. Maintaining the authentication security level can be accomplished in several ways.

One way to work within these 2FA/MFA requirements is to develop the bot as an “attended” bot that requires human interaction at key points but then carries on doing the repetitive task and still frees up time and saves money. 

➡️ 2. IT departments are going to be concerned with the RPA bots and their integration with existing infrastructure. This is a pretty normal concern and happens with every new application or solution added to a network. It is something that needs to be thought of and planned to ensure smooth integrations.  But the value still outweighs the concern.   

In fact, there is an opportunity for RPA to come to the rescue of the legacy systems that exist and extend their useful life.  Often, these system reach a point where they must be replaced regardless of cost so the organizations can continue to function and be competitive.  With RPA, gaps in functionality can be addressed in other ways, extending the life of the systems and saving the effort and cost of replacing them. 

➡️ 3. Knowing that RPA is still relatively new, IT is concerned that the best practices and standards for development of the bots are not followed.  This is a valid concern and needs to be part of the due diligence when working with internal development teams or when selecting a partner to do the development. 

When developing bots, the Software Development Life Cycle (SDLC) must be followed just like any other development project. The bot source code should also be versioned and controlled the same as other software development. Each bot should be uniquely identified, and its activities logged (through audit logs) so they can be reviewed. We know that nothing stays static so it is pretty reasonable to expect that changes will be necessary to the bot as business and environment needs evolve. As changes are necessary, they should follow proper change management and SDLC. 

➡️ 4. If you build it, it must be supported and maintained. Often, the maintenance and support fall back to IT.  With IT already stretched thin, this is just one more thing to look after and often becomes a distraction.  The nice thing with RPA managed services is that this support can be offloaded to firms that specialize in it. If the organization chooses to build and maintain their own bots, IT resources can be freed up by focusing on applying RPA to IT repetitive tasks first, providing the capacity to deal with the maintenance and/or support that will result. Lots of possibilities for RPA to work with your team, not against it.

➡️ 5. No one is looking to manage anything more - plates are already full. Its no wonder that this is a concern of IT.  IT typically is stretched as it is and there is often a strong resistance to anything that may add additional work or responsibilities (and we don't blame them). Depending on how RPA is implemented, there may be additional IT work or they may not (RPA Managed Services) so there are options if that's a challenge within your organization. If there is additional work, what should be addressed first is RPA in the IT area to reduce the repetitive tasks, freeing up this team to do the higher value work and take on this management without increasing the number of hours worked. We don't want to cause burn out or stress, so RPA can help redirect efforts and focus.

➡️ 6. If IT is going to be responsible for a new technology, then they should be included in the conversation. They have valuable perspective to add to the discussion. IT teams are not always being consulted early in the RPA journey.  When this approach is taken, IT is left to plug holes and catch up with the organization. Here's the challenge - IT can be seen of as thought blockers, wanting to take control, playing the devil's advocate that ends up slowing down the process. They have good intentions, but they are trying to understand the full picture so it sometimes puts some bumps in the road. If you want to get IT on your side, they have to be included. Sometimes a great negotiating tactic is beneficial - allowing IT to work with RPA bots first to free up resources for them, rather than just adding to their workload and causing frustration. It's a real value if organizations can turn the perceived risk into an opportunity.

➡️ 7. Job losses is a traditional fear of process improvement and process automation. Changing the perspective - it's not here to do that. Check out this article. Most companies can’t find sufficient staffing to achieve the work they do have. And if you're following news, this isn't going to get easier. And when we look at IT departments, it's normal for there to be more work than there are resources to accomplish it. RPA is going to take on those repetitive mundane tasks and provide time for more value-added work and make sure that your team isn't walking out the door posing an even greater threat to your organization.

If you're interested in learning more about RPA and know the common IT concerns within your organization, schedule a virtual coffee with our team to talk through a strategy to present this technology to your IT department. You can even pass along this 101 RPA bots eBook for them to read.