Defining Success

CoE Lead Journey

Learning Experiences

Defining Success

Objective: If we fail to plan, then we should plan to fail. Clearly defining objectives and performance indicators sets your CoE up for success.

As a Center of Excellence, it’s your responsibility to define what RPA metrics are being captured, plan how and where they can be recorded, and make sure that reporting of savings is done the same way across business units. Defining standards for key performance indicators early in your RPA practice will set the organization up for accurate, trusted metrics later on.

Consistency is Key

If you expect to have 3-4 different business groups building bots on the Automation 360 platform in the first year, expect to have about 12 different methods of reporting savings. Why? Because without guidance from the CoE on capturing, storing, and reporting savings, everyone will come up with their own methods. As early as possible, work with representatives from the federated teams (or within your team) to identify a standard way that RPA savings can be captured and reported.

Seek to answer questions like:

  • How are we calculating what a bot run is vs a task?
  • How do we track how much money a bot saves?
  • What’s the best way to track these values across multiple bots?

See the Future

Whether you’re just starting out with RPA, or your organization has been building bots for a while, one thing is certain: Within six months, an executive will come to you and ask “So how are we doing? How much money have we saved?”. Prepare to have an accurate, data-driven answer when the time comes. Ask yourself:

What data am I going to wish I had 6 months from now to demonstrate RPA performance to our leadership team?

While the answer to that question will vary by company and business unit, the basics are the same for most teams. Let’s use the example of an automation process that starts with an Excel spreadsheet on a shared drive that needs its data validated and transposed to a web application for customer transactions.

During the requirements definition process for each RPA opportunity, define:

  • What’s the human time that it takes for the task that is being automated to be completed?
    • For our example, let’s say that it takes a human 15 minutes to fully process each row of our sample scenario’s spreadsheet
  • What’s the average hourly rate of the workers currently doing those tasks?
    • For our example, let’s say that the average hourly rate is $45/hour
    • Depending on how specific you want to get, beyond just what the individual is paid, consider the cost of benefits, insurance, etc.

With those values defined for each opportunity, reporting per bot (as well as for the entire CoE) should be based on the following:

  • Number of tasks completed
    • Example: If on Monday the spreadsheet for processing had 100 rows, and Tuesday it only had 10, we’d need to be able to report those differences as the savings from each of the two bot runs would not be equal.
    • Note: This number could be 1, and that’s ok. Not every automation opportunity lends itself to a variable number of tasks completed. Just make sure you’re recording a non-zero number for each bot run for the later calculations to work.

Based on that data, calculate and report on:

  • Time saved
    • Human equivalent time per task multiplied by the total number of tasks completed.
    • Example: 15 minutes per task x 100 tasks completed = 1,500 minutes (or 25 hours) saved on Monday
  • Money saved
    • Human hourly rate multiplied by the time to complete a task gives the cost per task
    • Cost per task multiplied by the number of tasks completed gives total money saved
    • Example:
      • $45/hour x 15 minutes = a cost per task of $11.25
      • $11.25 x 100 tasks = $1,125 in total money saved on Monday

Storing and Reporting

In our next learning experience, we’ll talk about making sure that each bot is capturing this data. For now though, we have to ask ourselves the question:

How can I store and report on this data in a meaningful way?

The answer depends on:

  • What infrastructure, databases, and systems you have access to
  • What else you want to capture for each bot run. For example:
    • Did the bot run successfully?
    • What transactional data could be saved for auditing?
    • What data could help you make better business decisions in the future?

We recommend using one or more of these methods:

Bot Insight

Bot Insight is an embedded RPA analytics platform that delivers actionable business intelligence, on both what and how the bots are doing. These insights help to report on ROI as well as other bot-specific values. Dashboards are built right into the Automation Anywhere Control Room, and access can be granted to leaders outside of the bot builders and CoE team to analyze and glean valuable insights. One of the biggest benefits of Bot Insight is that a package is already built into Automation 360 that makes capturing metrics easy.


A do-it-yourself approach is to store the savings data and any other bot metrics in a database. The downside is that you’d need to set up a flexible database structure yourself and develop a way to report on the data. On the plus side, you can store whatever data you want with no limitations. If you’re going to go this route, my personal advice would be to consider a No SQL database (like MongoDB or DynamoDB). These database structures let you store any number of custom values for a bot run, which could be completely specific to the opportunity itself. This data might be details related to the transaction, data for future business insights, or audit information for the bot. The format for committing and reading data is typically JSON, so you have maximum flexibility.

Centrally Stored CSVs

While not the most glamorous of solutions, the same objective could be achieved by storing a CSV for each bot run in a centrally located directory, then having another bot compile the results into a larger CSV report for the day, week, or month. While this solution gets the job done, be careful about how these files are named and merged. Additionally, be sure that the bot has a backup in case it’s having trouble writing to the shared directory, for example by storing a local copy of the metrics as well.


6 months from now when an executive at the company comes to you directly to understand how the organization, as a whole, is doing with its robotic process automation initiatives – imagine how thrilled he/she will be when you’re able to report on the savings from a time saved, tasks completed, time saved, and dollars saved. She’ll especially be blown away when the reporting can be broken down by business unit and even specific bot.

Defining success for an RPA program isn’t terribly hard, but it requires upfront planning to ensure that the numbers reported are accurate and consistent. Set these standards early on, and you won’t be scrambling later to retroactively add code to each bot to start reporting savings in the same way.

Bonus: Additional RPA Cost Savings

The benefit of automating tasks is typically quantified by the methods discussed above: The number of tasks automated, the equivalent hourly rate, and the equivalent time to perform the work manually. However, one big benefit of bots is that the tasks that they perform can be fully auditable and run at any time of day, even checking the work performed by other bots (or humans). Consider how you might quantify benefits provided by automations in the way of regulatory fee avoidance, the cost of inaccurate data being propagated to downstream applications due to human keystroke errors, or other industry-specific fees which may be imposed if transactions are not handled within a certain time frame.