The 5 Metrics You Should be Tracking Before RPA Platform Migration

There are numerous reasons why organizations are unhappy with their current RPA providers and looking to switch automation platforms. High costs, the inability to scale, underwhelming returns, and the technical complexity in delivering automations are the most common, but there are others.

Identifying the reasons to switch is easy enough, but justifying a switch and measuring whether an RPA platform migration has been successful requires a bit more of a quantitative approach.

These are the five metrics you should be tracking prior to a migration that will substantiate a move to another platform and help you objectively prove that your decision was the right one.

1. Design Time

Design time, simply put, is the amount of time it takes to design an automation. It doesn’t include RPA candidate identification or prioritization but instead measures how long it takes to:

• define and optimize a process for automation
• connect that process and process steps to any relevant and critical dependencies like business rules, regulations, applications, and systems
• package that information into something that can be picked up by an RPA developer for development.
  
  The most common way we’ve seen this done is through a PDD (process design document), but it’s common knowledge how time-consuming, outdated, and flawed this approach is.

You want this KPI to go down after making a switch to another RPA provider. However, this metric is more reliant on your internal best practices and processes. Ideally, you have a solution that simplifies, accelerates, and digitizes automation design.

2. Development Time

Development time is arguably the most relevant hygiene metric when migrating from one RPA platform to another. It refers to the amount of time it takes a developer to code the automated process, test, and then deploy it.

Development time is so telling because each RPA vendor specifies automated processes differently, so naturally, it will vary from platform to platform. For example, automation development in some RPA platforms, like Automation Anywhere, resembles a flat coding language. In others, like UiPath, a graphical workflow representation is used.

One main driver of RPA platform migration is reducing the complexity of developing automations—so development time should reflect this.

3. Automation Uptime

Automation uptime is the amount of time your automated processes are available to be executed. This metric indicates the quality and resiliency of your automated processes.

As bots are pulled out of production because they’ve produced errors, are broken, or non-compliant, automation uptime goes down and business value is lost.

When migrating your digital workforce to another provider, reduced complexity, ease of implementation, and better capabilities should lead to higher-quality bots that experience less errors and require reduced maintenance.

4. Total Cost of Ownership

The total cost of ownership (TCO) reflects how much your automation program costs in terms of operational overhead. It’s multi-dimensional, and numerous factors contribute to automation TCO; however, beyond your full-time employees (FTE) that make up your RPA team or Center of Excellence (CoE), licensing fees for your automation platform are right up there.

A reduction in TCO is naturally what you’re looking for when making a switch to another RPA platform. However, you should also consider less break-fix cycles and fewer maintenance issues into this equation to give you a more holistic picture.

Learn More: How Much Does RPA Really Cost?

5. Average Number of Steps per Automated Process

Reducing the complexity of automation development and leveraging better features and capabilities of another RPA platform are prime motivators for RPA platform migration. Logically, those benefits should enable you to automate more complete and complex end-to-end processes that will deliver higher returns.

Tracking the average number of steps per automated process before migration will give you the insight you need to verify if automation complexity, and the promise of higher ROI, has increased post-migration.

Measuring and tracking these metrics is only one part of the equation—they will give you the baseline or benchmark you need to justify the switch you’re making. You’ll also need to monitor the same metrics after migration, in addition to a few others to fully validate the success of your RPA platform migration. We’ll be speaking to those in a future article, so stay tuned.

In the meantime, if you’d like to learn more on the complexities and considerations when migrating between RPA platforms, see the Blueprint RPA Migration Technical Overview.