Why RPA turns out to be a Real Pain in the A***, sometimes

June 21, 2017 / By Krishnan Rangi

The buzz word seems to be RPA. Everyone wants to jump on to the band-wagon imagining RPA is a panacea for all their problems.

There are hordes of RPA software vendors and solution providers pushing their products and services, amidst the din created by analyst groups, that it is very natural for a CFO to be swayed into deciding in favor of one or the other RPA solution.

What follows is a much bigger problem [you have not solved your original problem and you don’t know how much your investment into the RPA solution will yield results].

In my mind, automation has different flavors ranging from simple scripting/building of utilities to use of Off-the-shelf RPA products like Blue Prism, Automation Anywhere, UiPath etc. No one solution can address all the problems optimally. More often than not, it is a combination of these automation solutions that works best for enterprises seeking to Optimize their business and not just looking for cost transformation.

Consider the following ITSM use case of Troubleshooting of an incident where a switch is down



For a process to be suitable for RPA, it should contain a series of consistent steps, must be rule-based and should look for standard inputs to arrive at a desired outcome.

Many steps like device reach-ability from server, device login possibility, checking for redundancy, checking for interface errors, checking for onsite power/LED status etc. are seemingly RPA-able as they are the routine steps involved in all switch-down related incidents. However, from an automation perspective, if we assume these steps require creation and maintenance of a bot, the cost will far outweigh the benefit that may be derived by re-engineering the process and getting the same done by one or two resources from a low-cost location

Such diagnostics steps can be drastically reduced by a simple script/utility that can be invoked when needed.

Likewise, Automation of sub-processes for guided resolution can be achieved by uplifting the inherent feature of the ticketing system. In our experience, we have seen that some organizations have not leveraged certain basic features, leave alone advanced features, of their existing applications.

This will leave a bunch of processes like checking for planned activities, checking in CMDB for inventory information etc. that merit BOT creation as there are lot of systemic rules involved that has to be checked in a logical sequence. This is worthy of BOT creation as these are not only related to switch-down incidents but also related to majority of incident types. Hence there is a scaled volume that justifies the readiness for RPA for such processes.

Therefore, it will be wise to begin the transformation project with the first step of evaluating all the processes (along with the sub-processes) for the optimal automation solution. If there are non-standard processes, a separate exercise has to be completed for Process standardization.

Once the first step is over, candidates for automation have to be grouped by the preferred solution and a cost-benefit analysis undertaken to arrive at the RoI and then move to the implementation stage.

Happy to hear your views...