Rising Use of RPA in Government Agencies: Pros, Cons and Risks

In the world of government operations, technology has become a linchpin. The reliance on digital systems is so profound that a cyber attack can paralyze an entire local government, forcing it to shut down its digital systems. This highlights the critical importance of making judicious technology choices for government agencies. One such choice gaining traction in the public sector is Robotic Process Automation (RPA). However, it’s essential to consider the long-term implications and costs of such decisions, akin to understanding the concept of debt.

Imagine your car breaks down unexpectedly, and you use a credit card with a high-interest rate to pay for repairs. If you can pay off the balance quickly, the long-term cost is low. But if you were planning to buy a new car, you’d likely opt for a loan with better terms and a lower long-term cost. This analogy applies to technology choices as well, especially when considering RPA.

RPA encompasses software tools or utilities that replace repetitive, labor-intensive tasks with automated processes. It’s becoming an increasingly attractive option for government agencies grappling with legacy technology systems, intricate workflows, and backlogs in approving service applications. These agencies are akin to the unfortunate driver whose car breaks down – faced with an unexpected crisis and limited time, the choices may seem scarce. RPA tools might seem like the perfect solution to immediate problems, but like a high-interest credit card, they come with long-term costs.

One of the main challenges with RPA is that automations built on a specific platform may not be transferable to other platforms. This can lead to agencies becoming tightly tethered to a specific vendor. Given that the RPA industry is still evolving and prone to rapid changes in pricing, vendor consolidation, and feature support, vendor neutrality becomes crucial when evaluating technology options.

This scenario mirrors the one agencies encounter when assessing different cloud service providers. The multitude of choices can be overwhelming, and agencies need to consider how closely a solution would bind them to a specific provider. Can they transition away from the platform in the future? These are the types of questions that need addressing before investing in a particular technology platform or tool.

However, RPA tools alone cannot significantly enhance the user experience of government services. They don’t enable an agency to re-engineer a flawed process or improve an end-user’s experience – they merely attempt to make an existing broken process faster. While this is important, it doesn’t allow agencies to achieve other objectives like adopting plain language or enhancing accessibility.

Attempting to automate a step in a long, complex process involving multiple stakeholders and legacy systems can lead to unforeseen issues. For instance, when I worked for the city of Philadelphia, one of our technology focus areas was property information. An employee developed an automation that allowed property data from one agency to be shared with other agencies via an API. While this reduced time and effort required to access property information, it led to increased traffic on the agency website being accessed, causing instability and service interruptions.

This phenomenon, known as “moving the bottleneck,” is a common pitfall with RPA. By focusing automation on a small part of a larger process, RPA tools can create unintended consequences downstream in the process. Unless all steps in that process can handle increased throughput, a new bottleneck will develop. Instead of eliminating a bottleneck, RPA may just shift it further along in the process.

In conclusion, while RPA has its benefits, it’s important for government agencies to consider the long-term costs and risks associated with this technology. It’s crucial not just from an electronics or computers perspective but also from a broader operational standpoint. Understanding coding or programming languages is not enough; understanding how these technologies fit into the larger organizational framework is equally important.