BOT ROI Modelling Failure

Don't you think this is very surprising that even after lots of planning, financial analysis & smart investments, majority of organizations miss to achieve the BOT return on investment (ROI). Is this due to a lack of understanding, a lack of insight or a lack of oversight? Personally, I think these are not the true drivers of failure, rather nearly all these failures generate stem from unreasonable expectations. If you closely watch, you will find that most of the business leaders are looking for different ways & means to leaning out their organization, and when a technology like robotics process automation comes along, promising to provide immediate benefits, for little cost, and little effort, they excitedly want to believe those promises. They buy into often crazily optimistic cost or benefits models, in the hope that those benefits will be realized. But with slight slippage here and there, investments in BOT fail to deliver the expected ROI. 

If you take a deep dive, you will find that missed ROI can be caused by less savings than expected, more cost than expected, or both. All three of these scenarios occur with RPA implementations, and observable in several specific areas of error. The largest offending causes of missed expectations include: 

• How much the BOT was busy or utilized?
• How much spend to buy, build and deploy the BOT?
• How much saving was done by head count reduction or human labor cost is replaced by the BOT?
• How much does it cost to keep the BOT up & running
• Does the BOT do what needs to be done?

Smart utilization of BOT is perhaps the most critical factor in achieving financial returns from RPA.  Unlike the predominantly hourly human workers they replace, BOT's invite costs to organization whether they are working or idle. Normally, it is believed that BOT's are four times as productive as human workers, but this also means that when they are idle, they waste productivity four times faster than humans! Actually the unfortunate reality is that, while most ROI models and business cases assume BOT's are 100% utilized, this is almost never realized in actual practice, at least not until we have enough processes automated to ensure than any down time in one process can be utilized by another.

Acquisition costs frequently cause issues through a combination of hidden costs, incorrect assumptions, and overly optimistic estimates for what it takes to create and deploy BOT's. By far, the greatest source of errors in estimating the cost of deploying BOT’s is the cost of testing and support. It is not uncommon to see ROI models that include NO testing effort, and often only a few weeks of support.  This is largely because of the constant belief that BOT’s are easy to create, easy to deploy, and require little or no support once they are released.  In practice, these beliefs are almost never accurate, and hence scope creep in each of these areas is often the cause of missed ROI.

Almost in all the cases, the cost savings driven by RPA is through reduction in human labor.  This is a firm belief that A task performed by BOT is cheaper, faster, more effective.  The assumption in the ROI calculators is that those people are subsequently let go, or in some way disappear from the cost structure of the organization. But this is far more complicated by the issue of fractional Full-Time-Equivalents (FTEs). Now day's hardly you will find a person or group of people performing one & only one task. This typically means that when a BOT is created to automate a task performed by humans, only part of that person’s work goes away; their other responsibilities and tasks remain for them to perform.  Such automation replaces part of a human worker, but not all. Hence, you have picked up the added costs associated with the BOT, but cannot reduce your human labor costs, because you haven’t automated all of the tasks performed by one or more of your people.  Overall costs go up, not down, and potentially no additional work is done, despite the improvements from automating a particular task.

The next major error in modeling RPA ROI comes in testing.  In most cases, people seem to believe RPA requires little, if any, testing.  This stems from the “it’s so easy” and “just copy what people do” messaging that is so common amongst consultants.  As a rule of thumb, the amount of testing effort for a BOT should be two to four times as great as the effort to create it. This is because for every function point coded into the BOT, define the failure and success scenarios.  Each of these efforts are at least equal to the coding effort, hence up to four times the level of effort.  If you are creating an ROI model, and there is either no testing, or relatively little testing, your model is wrong.  And it’s probably wrong by a factor of two or more. 

Post-deployment support is another area that is dramatically miss measured in most ROI models. There are maybe a few percentage points of bots that are truly “set-it-and-forget-it.”  Very few bots are so simple and participate in such stable environments to allow otherwise.  The remainder often require steady, consistent, and frequent updates and support, and will do so throughout their entire useful life.  As a rule of thumb, if the cost of supporting a BOT is shown to be less than the cost of building it, your model or your assumptions are likely off, and your business case will evaporate once the BOT is deployed.

Finally, many models miss in delivering the benefits that are anticipated due to poor performance by the BOT.  BOT's don’t always complete the tasks they are assigned, and when this happens the BOT generally reports the failure back to humans and then proceeds to work on the next item in its queue.  Most ROI models assume that BOT’s complete their tasks one hundred percent of the time, or nearly so.  Newly deployed BOT’s completing their work without issues as little as twenty percent of the time, until they are tuned to work in actual production.  Such poor accuracy can completely eliminate the business benefit of the bot, and the costs of rework or recovery of the failed transactions can often be more expensive than had they been performed manually in the first place. As a rule of thumb, if your ROI model does not work if the BOT’s yield is below fifty percent, you may not want to build that bot. 

In my estimation, these few examples of poor financial modeling for RPA account for at least half of the “financial failures” experienced by organizations. For BOT’s to make financial sense, they must be modeled correctly. Only then will the business have confidence that this technology does deliver real benefits and is worth the cost of admission.

------------------------------------
---------------------------
----------------