Changing RPA tools can be a great decision, but it may not be as straightforward. As an automation delivery expert, my most recent experience supporting a client with a major RPA platform conversion gave me a lot to think about. We have recently seen an increased interest in organizations wanting to switch RPA tools, so if your company is exploring this option, I want to share some key insights to keep in mind.

You’ll inevitably face several challenges if you decide to make the switch yourself, and we’ll get into those. But before we do, let’s first look at why organizations choose to make the switch in the first place.

How did we get here? Consider three areas that may have driven you to search for a new automation tool.

“We’re experiencing an excessive amount of production issues.”

If a lot of time and effort is focused on production issues rather than new opportunities, you’re losing money. Especially in the early stages of an RPA journey, it may initially seem problematic with the RPA tool. “It throws too many errors.” “It keeps crashing.” “The output is not correct.” While this is frustrating to deal with, it’s a call to consider the design standards of the program. No matter your tool, you must maintain high-quality design standards and best practices across your program to minimize future production issues.

“We’re not achieving our anticipated ROI as quickly as we expected.” 

Automation programs live (or die) by their ROI. If you’re not realizing the value of automation as planned, I’ll ask you to consider the intention behind your process selection. Automation can only deliver as good of benefits as the processes they automate. Beyond the processes themselves, what kinds of roadblocks delay your deliveries? Application access? Business availability? Incomplete or changing business requirements? Regarding expected ROI, delivery hurdles hindering your estimated delivery time are second to selecting the best automation processes. It’s essential to set realistic expectations early on and structure the development schedule so that the right processes are automated first.

“The tool doesn’t do everything I thought it did.” 

Automation tools are advancing daily, and their capabilities are expanding rapidly, even including complementary technologies as a part of the offering (e.g., Intelligent Document Processing, Natural Language Processing, Machine Learning, and Artificial Intelligence). However, somebody sold you the dream rather than the reality. These tools exist with limitations that need to be understood upfront. It’s best to start with the core functionality of a tool against lower complexity challenges to manage your expectations. As your understanding of what the tool excels at grows, you’ll be more ready to handle complex scenarios.

If those challenges resonate, perhaps it’s worth a pause to address the root issues before proceeding with a major RPA tool change. Otherwise, let’s move on to the challenges of making the switch.

I’m going for it – what challenges should I expect to encounter? Consider five areas that will make this switch harder than you expected.

1. Existing automation documentation is poor or non-existent

Although most automation tools suggest some form of business process and solution design documentation as the first steps of the delivery lifecycle, this step is often neglected or not done thoroughly (it’s way more exciting to jump right into the build!). Further, when processes or applications change, the already completed documentation is often untouched on the shelf.

Untouched documentation can be problematic when you must convert existing automation code to a new tool’s platform. Without sufficient documentation, you have to re-learn the process from the business, and the effort of converting existing code slows down. With poor or non-existent documentation, you might find your timeline and cost of conversion significantly inflated, adding a dependency on business SME availability.

2. Automation conversion tools do not deliver

Some RPA vendors have built conversion tools to make the code switch between RPA tools seamless. While this may seem straightforward on paper, as someone exposed to these tools, I can guarantee it is not. The promise of simple code conversion requiring little manual effort to polish the output is misleading. The conversion tools do some of the upfront work, but a lot of work remains afterward, which becomes apparent when you start testing, and processes are not working as expected. The promise of simple code conversion requiring little manual effort to polish the output must be more accurate.

Conversion tools aren’t able to copy everything over like for like due to the activities being used across all the RPA tools not being the same. Be Conversion tools can only copy some things over, like for like, due to the activities across all the RPA tools not being the same. Be prepared to be promised short timelines that may not be able to be met using these tools.

3. Performance of activities is different

All RPA tools have different strengths and weaknesses, so what may have worked exceptionally well in one tool may not perform to the same standard in another, and vice versa. When converting from one RPA tool to another, be prepared for a decrease in the performance of some of your automations. It’s not all doom and gloom, though, as you could have processes that run better.

4. Lack of continuity in Audit logs between tools

Audit logs from RPA tools are essential for all Intelligent Automation programs for compliance, troubleshooting, security, and performance monitoring. Audit logs and performance data are not stored the same way between each RPA tool, so the data may not be readily available when migrating to a new RPA vendor.

5. Large cost of changing vendor

If you’re changing vendors, you probably know about the basic cost of conversion. Overlapping license costs is the first that comes to mind – you will have one for the current vendor to continue running automations while the conversion takes place and another for the new vendor. The next big one is resourcing – your current resources won’t be able to handle the conversion and maintain existing bots, so hiring additional staff or consultants will be necessary.

The surprise cost comes from the inevitable delays caused by all the challenges outlined in this blog. Delayed timelines will extend your license overlap and additional resource requirements to complete the transition. The delayed timelines will negatively impact business units supporting the transition due to the ongoing time commitment they will need. In the worst case scenario, they may even need to perform the process manually until the automation is live in production.

To proceed with conversion or pursue an alternative

After considering all the points above, you may either proceed with the conversion or pursue an alternative path. Regardless, you can do things at any time (even during a conversion) to help your RPA program run more efficiently. The best place to begin is by looking internally and ensuring that all the components surrounding the RPA tool are operating at peak efficiency, like reviewing design authority and best practices, exploring new automation tracking methods for ROI, providing additional training to staff, or integrating ML or AI tools to supplement the existing RPA tool.

Finally, if you still feel you are not getting the most out of your automation program, seeking assistance from an external organization to perform a health check on your RPA program can provide valuable insights and options for improvement. Whatever you decide, I hope you can start getting the benefits out of your RPA program that you deserve.

If you’re interested in learning more on this topic or would like to set up time, let’s chat.