Considerations for RPA Cost Benefit Analysis

Often times there's doubt over the cost of technology and its benefit to the business.

Consider the price of a mail server, firewalls, and other investments needed to keep email working properly within a company. It might seem absurd to spend tens of thousands of dollars on mail every single year when it's all added up. However, when comparing email to running a mail room, the cost becomes very reasonable very fast. This example may seem obvious, but it's exactly the type of issue that comes up within management on the topic of technology expenditure.

RPA is often seen as a ‘low-cost’ solution to deliver IT solutions for the business, but costs will inevitably stack as time goes on. As costs increase into the hundreds of thousands of dollars, it's important to track the benefits and always be able to justify automation. In early stage programs, benefit analysis will be the determining factor as to whether they scale beyond a proof of concept or get shut down.

Monitoring costs and benefits throughout the lifecycle of automation

As you read this article, make note of how you can document expected benefits before implementation of automation and how you can modify those expectations as new information emerges. For example, the first automation opportunity may seem to save $50,000 a year after factoring in all costs. After a proof of concept gets delivered, the scope is lowered of what is feasible for automation and savings then only account for $25,000 in total. Finally, after the automation's implementation, benefit monitoring indicates that only $18,000 in savings were realized due to unexpected maintenance requirements. This information will be valuable in making cost analysis as effective as possible, and it'll provide a baseline to assess how well investments hit their predicted targets as time goes on (and new incidents or upgrades emerge which further erode value).

Documenting tangible benefits

Tangible benefits (such as time saved per year and service-level agreement improvements) are a priority in analysis models — as are other metrics that easily convert to a dollar basis. A company considering tangible benefits might ask themselves 'how much do we value reducing turnaround times for customer requests?' If there’s a known penalty, such as having to pay a refund to the customer (or losing renewals) then we're able to quantify the savings of a better SLA.

Collecting expected benefits as early as possible when identifying automation opportunities is critical. Simply going off business user estimates of how long a task takes isn't enough to satisfy documentation requirements. This information should come from a business user, a subject matter expert, and/or management. Discrepancies should be carefully analyzed. One other way to gather this information is through a time-in motion study completed by an impartial and skillful analyst.

The reason relying solely on numbers provided by employees is avoided is because they can change dramatically depending on who you talk to. That's not to say that employees will outright give the wrong information to downgrade how long a process takes (for fear of losing their job to automation) - but rather, it's more a matter of them not having the full picture.

Consider that after a front-line worker completes a certain task, they don’t have visibility into how long it takes to complete quality assurance on their own work. The front-line worker also doesn't have visibility into how long it takes to complete a follow-up process that another department will undertake with the output of their efforts.

If a process is being evaluated as an automation opportunity, it’s important to assess it fairly by understanding exactly how much time and resources are required per transaction. The downstream impact of potential automation on quality insurance, related processes, and systems must be considered.

An objective and comprehensive cost analysis may take time and effort, but it is a cost of doing business in automation and shouldn't be an afterthought. Such an analysis is the lifeblood of justifying the operation of an automation program as well as its expansion. After all, you'd rather find out early on that a process isn't worth automating rather than a few weeks into its implementation and go-live.

Intangible benefits must also be factored

If customer satisfaction is suffering due to poor quality or slow turn-around times, what opportunities does automating a process represent? Would cutting 10% of negative reviews left every year improve reputation enough to justify the cost of implementing automation?

These types of questions have different answers across companies and industries (according to their go-to-market strategy and objectives). The nature of intangible benefits is that they're hard, if not impossible, to directly correlate to revenue or profit. As a result, the amount of processes that are prioritized for automation due mostly to their intangible benefits are likely going to be far and few in-between.

Focus on tangible savings and supplement with intangible benefits

A company that's a heavyweight in automation is in a better position to spend money on something that might look like a loss maker to beat the competition or derive other benefits. For a company that’s in the early stages of automation, taking on this kind of unknown risk isn't worth it, especially as the company is coming to terms with the total cost of operating and scaling their program.

Implementation costs

For implementation, it’s critical to determine how much it'll cost to develop bots in a given time frame. For example, if the first year of bot development will be undertaken by consultants — how much will that cost and what will the expenditure be to bring in internal developers towards the end of the year to take on development responsibilities?

Another important question to consider is at what point does the cost of the first RPA initiative (which is testing the waters within a business) move on from an implementation cost to an operational cost? Once your organization has their answer, it's important to stick to the guidepost and not move it for the interest of 'extending the viability study.'

Something else that must be considered is the cost of labor for the business’s investment into RPA. Subject matter experts, management, business analysts, and ancillary departments will be engaged throughout automation qualification and implementation.

Hours of resources add up quickly and it may not be possible to get an accurate number down for resources, but it's important to have a rough understanding of departmental costs. For example:

1. Costs of HR (upskilling in RPA, hiring, etc)
2. Costs of InfoSec (access, new workflows for tracking automation compliance)
3. Costs of specific departments engaged in automation

Keeping track of time (even in increments of 4 hours, for example) is also a great way to gain insights from RPA implementations. Trying to look back on a year of implementations to determine ‘how much did it require in terms of labor’ is a really difficult endeavor that relies on memory and inaccurate estimations.

It’s better to capture cost-benefit data up front and to optimize implementation efforts in two to four week sprints than it is to look back and see that the program didn't operate as well as it could have.

Re-evaluate consistently and question how the value could be improved. If something isn't panning out as intended, don't be fearful of pivoting or reducing spend as needed.

Infrastructure costs

Track everything that goes into infrastructure including RPA bot licenses, orchestration licenses, servers, supporting software (such as VPN software, antivirus, and so forth).

None of this is free and the more information that's gathered, even at a high-level perspective of ‘it costs about $1,000 to provision one machine with the necessary software and another $5,000 pear year for a bot license in 2022’ is a lot better than the perspective that it’s ‘free’ or ‘inexpensive.’

Establish a time frame to assess these costs and make sure that they are kept up to date. As time goes on costs will increase and it's beneficial to analyze performance and predict how changing variables will continue to impact your business.

Operational costs

How much does it cost to operate your RPA program? Whether this is a consulting cost, or an internal cost, what is the total investment required to support automation?

If you have a governance group that provides oversight to an Automation Center of Excellence, how much is that additional overhead incurring? If it’s necessary to bring on a change manager, an Agile trainer, or another resource, what is that cost and how are those costs allocated to individual automated processes (or to the entire program)?

Other questions include:

1. What does the operational cost look like on an expanded time frame two or three years down the road?
2. Is it sustainable to operate automation via third parties or is it better to bring it in house?

During implementation, it’s tempting to just 'onboard' additional bots and worry about the rest later. However, as an RPA program picks up steam, it’s necessary to consider the usage of bot servers:

1. Are the bots really running 24 hours a day? Or are they running closer to 10 hours a day? If so, the cost of their underlying infrastructure needs to be updated.
2. If a bot license is used 10% of the time, is there a way to get other processes added to that same server to reduce the cost of running a single process on it?

There’s a variety of metrics to track, forecast, and manage when running an RPA program. This article could only cover so much, but we hope it got you thinking about what would go into an automation cost-benefit analysis.

If you’d like to read more on the topic, you'd likely find value in ‘Understanding RPA ROI’ by the Institute for Robotic Process Automation & Artificial Intelligence.

Footnote:

The term 'Robotic Process Automation' is used due to its popularity in the industry. Process automation is a clearer term that'll ideally replace 'RPA.'