Heralded as a “tech light” way to quickly eliminate repetitive work and reduce cost, robotic process automation (RPA) has been gaining wide acceptance and has been deployed by giants like Walmart, AT&T, Walgreens and American Express to automate both front-office and back-office processes.
But RPA is not a cure-all. RPA, aka “bots,” while good at handling highly manual and repetitive rules-based processes, is not the right answer for all activities. A bot is a point solution that can sometimes perpetuate issues of legacy environments and “technical debt” rather than address them. Implementing RPA is not a substitute for core platform modernization — though it often can make the process of bridging legacy systems more efficient prior to a modernization project. Nor is every process or task a good automation candidate, as we’ve pointed out before. Finally, automating a broken process not only will not fix it but will expose companies to the real risk of making bigger mistakes even faster.
There are many ways an RPA implementation can go awry, or simply fall short of expectations. Below are five of the most common RPA implementation risks we regularly encounter, along with suggestions on how to prevent the risks from becoming a reality:
- Picking the wrong processes. Not every process lends itself to automation. The ideal RPA candidate is repetitive, manually-involved (and therefore time-consuming) and rules-based — with high levels of consistency, low exception rates and requiring little or no judgment. Alternatively, it might be a task, such as a control activity, that is currently performed periodically because of resource or time constraints, but which would deliver much more value to the business if performed more frequently or continuously with the help of a bot. Likewise, it could be a control or activity that is currently being performed as a high-level review, versus at the transaction level, for similar reasons of time or resource constraints. Processes that do not meet the above criteria likely will not deliver enough value to be worth the investment, and should be considered low-priority RPA candidates or dismissed from RPA consideration.
- Workforce disruption and/or loss of knowledge capital. RPA pitches based exclusively on promises of headcount reduction rarely deliver – but they can cause significant disruption among workers worried they might be displaced by the bots. Companies with successful RPA programs typically assign workers whose workload is reduced as a result of automation to more challenging and analytic roles, such as exception handling, data analysis and monitoring to ensure that the bots are performing consistently and correctly. It is uncommon for entire roles to be replaced by automation. The much more common scenario is for bots to take over a portion of an employee’s role — which underscores the importance of thoughtful planning related to workload rebalancing. The effort to get more value from workers partially replaced by bots rather than transition them out of the organization ensures that no institutional knowledge is lost when the bots take over. Another way to minimize the loss-of-knowledge risk is to create detailed, desktop procedure-level documentation for each process.
- Masking technical debt. One of the characteristics of RPA bots is that they can be deployed without true integration into the enterprise IT environment. This can be both a blessing and a curse — a blessing in that they are relatively lightweight to deploy and, in fact, can be useful stopgap measures, as mentioned earlier; and a curse in that they may mask legacy system problems and potentially delay efforts to address the true underlying issues. By deploying bots to bridge efficiency or technology gaps, companies run the risk of perpetuating and even growing their technical debt. At the very least, such companies are likely only kicking the can down the road. To avoid this scenario, companies need a clear vision for how and when bots will be deployed and ultimately retired, with their functionality incorporated into newer core technology.
- Not maximizing ROI. In a somewhat similar vein, there is a tendency for RPA deployments to be focused on a specific department’s processes rather than the organization as a whole. In cases where one department, let’s say finance, is more proactive and assumes responsibility for RPA initiatives, there is often the risk of missing opportunities for optimization in other departments, such as HR or customer service. To manage this risk, it is advisable for companies to establish a business performance team or an RPA steering committee tasked with identifying and prioritizing automation candidates and ultimately maximizing the value of RPA across the enterprise.
- Bot overload. Many legacy systems were designed based on assumptions of a certain number of users logging in, and the demand those users were likely to place on the system. Those assumptions become immediately invalid when deploying bots capable of tirelessly processing transactions at high volumes around the clock. Unleashing a large number of bots in the IT environment can result in an unexpected overload, which can crash critical systems, such as a public-facing website. This can be avoided with traditional change management controls, including system performance testing as bots are scaled up through a designated process. Effective configuration and change management can also mitigate the risks stemming from upstream or downstream systems with which bots are required to interact, which can impact the functionality of the bot. Consider, for example, if the data element a bot captures as part of its processing is renamed or reorganized in an upstream system. Without sufficient consideration of this impact on the RPA environment, it is likely the bot in question would no longer function as intended.
The bottom line is that RPA is great as a quick, cost-effective solution to specific contained processes, and organizations should certainly seek out opportunities for automation. Our advice is not to ignore the downside risk in a blind pursuit of innovation.
If your organization is considering an RPA implementation, or you are simply interested in learning more about the subject, you can read our previous blog posts on this topic or visit our website.
