Is your RPA ROI getting eroded?

Many moons ago, I had written about calculating ROI for RPA and then how to ensure the ROI. Much has progressed since. Larger acceptance to the idea of automation, higher sophistication, embedded intelligence, better integration etc. have happened. Though most organizations have a sense of whether they will reach ROI or not (at the planning stage), automation (whether RPA or otherwise) have yet to effectively reach a scale where they cause a significant impact on business. Let’s delve a little deeper.

Unless all strategically pre-planned, most organizations start with automation point solutions. Later, most businesses end up with more than one automation platform. In most cases, naturally so, because it is near impossible for a single platform to meet all automation needs across all types of business processes in an enterprise. These myriad business processes, often not integrated themselves, cause the need for platforms that include RPA, cognitive (or other AI) tools, communication bots and orchestration tools at the least. These could be off the shelf commercial software, larger process orchestration or automation software, no/low code automations or even custom developed ones using open source. The automation silos remain.

RPA tools have been well received, at least in labour expensive markets. When businesses start their automation journey, they usually focus on evaluating products or configuration to ensure that the bots run successfully, thus driving ROI. In reality, and this comes usually from experience, the burden of driving ROI rests more on reliability, support and maintenance of bots. If bots keel over, they fail to provide increased quality, reduced risk, time savings, shifted labour costs or reduced operating costs.

Let us look at some of these situations when automation causes a drain, and use available industry data to illustrate.

• Automation fails to execute as expected some 7% (ish) in production environments and requires support and human intervention on a daily basis.
• Often, these failures can be attributed to extraneous reasons. Some 85% of these failures can be attributed to IT infrastructure components that are outside of Automation’s control. We don’t usually hear the Automation code breaking, but changes in infrastructure often lead to a failure.
• The remediation process is most often executed by human effort, because not too many tools exist which can traverse through architecture to figure what caused an Automation to fail and what change in infrastructure might be responsible. Industry says one FTE is required, to support, every 10-15 Automations. The entire remediation process consumes some 16-22 hours per bot per month.
• AOCs (automation version of NOCs) help schedule automations, report failure but fail to identify the cause of failure or assist in remediation. Now consider the added complexity created by the existence of multiple such AOCs to support the multiple platforms. Or the absence of even those AOCs in case of multiple platform less automations, or custom developed ones.

On the flip side, when the bots work well, they would shave away some 30-70% cost, and certainly enhance employee morale. The latter is difficult to measure for its impact; also that these are one time savings, or cost avoidance anyway. This implies that there are no year on year gains being recorded unless one keeps expanding the playing field of automation, or does accounting wizardry.

In conclusion, I would say that there are two large blocks to tackle. The maintenance of automation needs some serious thought and industry. And how does one create an Automation implementation which keeps giving, while considering the ‘unaccountables’.

Meanwhile, should you be interested in knowing how to calculate your Bot maintenance, do write in to us. We, at 3nayan, can help.