Robotic Process Automation – Why you should think twice before counting your bots

By Christophe Bollard and Mikkel Kristiansen

If you have been working with Robotics for a little while, chances are that you have been to conferences and read countless articles where vendors or companies proudly communicate on the number of bots they have deployed over a period of time. And the bigger, the better obviously. Or is it?

Back in 2017, HfS view on counting bot was simply summarised as follows: Obsession with “numbers of bots deployed” versus quality of outcomes.

Fast forward in late 2019, counting bots is still a rather popular KPI. So, what does counting bots really tell you about how successful your strategy is?

First, the fact that efficiency and cost are the primary drivers for early stage RPA, leads to a logical reasoning that counting the robots is the ultimate way to measure progress and success. This means that most newly appointed Robotics Leads are often challenged with producing a credible answer to this question and to embed this metric in future management reporting. Accepting this (#of bots) as the key metric is problematic in at least a few ways.

Let us explain:

1 – Robots are hard to count

It is essentially a matter of definition. What is “a robot”? Is it a piece of code, a project, a program, a technology? Hard to tell, right? So let’s look at it from a practical angle:

1. 1 automation which connects 2 sub-processes made out of 1 bot each. 1 or 2 bots?
2. 1 bot that runs twice a day. Is it 1, or 2?
3. 1 license used for 2 bots. 1 bot, or 2?
4. 1 bot re-used across multiple projects? 1 or… many?
5. 1 single bot identically replicated across 100 workstations. 1… or 100?

You got it. What we have here is set of options to manipulate the number of bots, at will.

2 – The number of bots is only loosely connected to the value creation

Ok, so they are hard to count but what if it still makes sense?

From a cost perspective you need to monitor the number of licenses in use and the utilisation rate of each license. You also need to look out for server, infrastructure and maintenance costs of deployed robots and compare to the value creation performed by the robots. And here it becomes interesting for at least three main reasons:

1. The ‘shape’ or profile of the specific automation project varies considerably, in fact so much that it is misleading to articulate anything generic about ‘how much value an average robot generates’. Average Lead time, complexity and cost are equally misleading.
2. The “value creation” has different shapes and flavours. While “FTE saving” is measurable, compliance, security, quality, freeing up capacity to absorb larger volumes and focus on value-added tasks, building competitive advantages, attractiveness as an employer, employee satisfaction, increasing R&D speed or time-to-market are far more complex to value. And yet those are fundamental benefits of Automation.
3. Your ability to deploy robots at a faster pace is directly connected to the selection of processes AND to the maturity of your program. For the first 12-18 months, expect project to take 2 to 3 times longer than planned. So the number of bots deployed at the early stages of your journey does NOT prefigure the pace and volumes you will deploy later.

3 – Metrics drives behaviour

Some of the thinking above leads to the last consideration and why it makes sense to think twice before settling on a – perhaps oversimplified – metric such as # of robots: the metrics you chose drives behaviour.

If you operate solely with quantity-type/cost-oriented KPI’s there are multiple ways to achieve high number of bots in a short period of time without twisting the calculation itself. From limiting the scope of processes automated to avoiding adding complex technology such as OCR, NLP/G, ML, connecting RPA to as few other systems as possible, avoiding processes with compliance risk (SOX, GxP to name a few).

You’ll boost the number. You’ll also limit the learning, minimise the strategic impact and miss out on a lot of potential very attractive business cases (see point 2.2 above).

If the number of bots is not the right KPI, then what?

KPI must serve your strategy. So, the “right” KPI is a matter of context and goals. Amongst other ideas:

• The number of processes automated
• % of automated processes within a domain
• The number of manual steps automated, or the number of transactions performed
• The hours “given back to the business”
• The positive impact on risk and compliance

You are after cost and ROI, no problem at all:

• Cost per transaction (not cost per bot!)
• FTE saved
• Cost avoidance due to increased capacity and ability to absorb more work
• Reduction of effort and cost from 3rd party

As any KPI, it matters if connected to the right purpose, context and strategy. If refined, it can be a critical information when it comes to overall capability (business analyst, SME, developers, infrastructure). Logically as the number of bots grows, so will the need for change requests and overall maintenance for example.

Our conclusion

A bot is a tool, a mean to an end. Counting bots turns the situation upside down and makes the number of tools the primary goal. The question is: would you rather focus on how many tools you have in your toolbox or how much you manage to fix and create with them?

You are welcome to reach out, if you have any questions, comments, input or feedback.