Key Success Factors When Implementing Robotic Process Automation

Robotic process automation (RPA) and robotic data automation (RDA) can offer state governments significant advantages, chief among them allowing IT personnel and data engineers to avoid spending time on tedious data management activities. A recent StateScoop study found that 41% of states using RPA tools to avoid 5,000 or more hours of routine work per year.

Yet, as is the case with all emerging technology, government agencies may face challenges when implementing RDA or RPA or may find that these approaches may not be suited for every use case. To maximize the success of any RPA or RDA program, we recommend the following:

Consider the consumer.  Automation only goes so far, and at some point, manual human action will continue the process where the automated actions cease, or humans will provide manual input for the automation to continue. It is important to build automations around the human element so that they harmonize with actions humans will take and reduce potential friction.

Don’t sacrifice security.  Certain systems may have security policies in place, such as multifactor authentication or access rules, that can be problematic for RDA/RPA tools to navigate. These policies around security should not be compromised for automation, which may mean modifying or stopping the automation.

Understanding takes precedence.  If the actions to be automated were also part of learning about a particular dataset or system, then the RDA/RPA solution should attempt to derive and communicate findings to humans in addition to completing the task to maintain knowledge of the system.

Proactively communicate results.  As the level of human involvement in the execution of a process decreases, the level of reporting about the actions taken on behalf of humans should increase to provide an auditable record for investigation and validation of the process.

Assess potential risk.  Deterministic processes (i.e., the same input or start condition always results in the same output or end conditions) make good candidates for RPA/RDA because the steps of the automation remain constant and the risk of the automation making an error is low.  Probabilistic processes (i.e., the same input or start condition may result in variable output or end conditions, possibly due to uncontrollable factors) come with a potentially higher risk of the automation achieving an incorrect result.  When there is a risk of the automation not producing a desired result, have a plan in place for how to address issues that may arise.

Quantify time savings.  Automation can bring a high degree of consistency, but the time to implement may not be worth it.  For a given automation, consider both how often the automated task must be performed and how much time will be saved by making the task more efficient through automation.  If the time saved is less than the time to implement, then automation may be inappropriate.  For instance, if a routine task is performed once daily, and the time saved by the automation is five minutes, then the breakeven point (where more time has been spent automating the task than has been saved by the automation across 5 years) is just over 152 total worker hours.  These hours must include all management, design, development, testing, and deployment of the automation solution by all humans involved.

Calculate cost savings.  Also consider the labor rates of those performing the task against the cost of implementing and running the automation (including software licensing, infrastructure, and monitoring).  If the time and materials costs to implement the automation exceeds the time and materials costs of those who would manually perform the task, or the cost of running the automation exceeds the cost for a human to perform the task, then automation may not yet be worth it.  Cost to run an automation is becoming less of an issue all the time with increases in computing power and decreases in cloud computing costs, but there are still instances where automation can prove to be more expensive than manual action.