Since bursting on the scene, Robotic Process Automation (RPA) tools have developed a well-earned reputation for ease of implementation; they are configured by subject matter experts and don’t require complex programming skills, they reside on local servers and they typically don’t require a great deal of IT support.
As a result, business sponsors — especially those who have imbibed the RPA Kool-Aid — can tend to be a bit sanguine about the potential risks robots represent. And that’s a mistake because, like any operational change initiative, RPA involves a certain level of complexity and, as such, requires the appropriate level of project management discipline, best practices and oversight. Otherwise, the project will likely fail to meet expectations.
One pitfall is to bypass the CIO when implementing RPA tools. While it’s true that robots require minimal IT support and absorb a relatively scant amount of IT resources, CIO involvement is essential to avoid disrupting the existing technical environment. For example, robots need to be considered in overall disaster recovery and change management processes related to system updates.
On the business process side, failing to account for unintended consequences can lead to trouble. Although RPA tends to focus on “simple” processes, any end-to-end process has tentacles that extend deep into the enterprise and, by definition, involves some degree of complexity and risk. Examples of technical risks we’ve encountered include an incomplete, incorrect process definition at the front end of the process, incorrect use of variables and commands, incorrect data ingested into the automation and malfunctions of the automation tool. In terms of project management, lack of appropriately skilled automation specialists and process subject matter experts can compromise a project.
The key to mitigating these risks is to break the RPA project into chunks and milestones. As each phase of the project is completed, the RPA implementer and the business need to come together and agree that respective boxes are checked. Communication and alignment are imperative — for example, the subject matter expert from the business needs to participate in the process definition and design phases, as this exercise produces the detailed process definition at the keystroke level that is required during automation build.
Architecting the robot before building it is also essential. Analogous to architecting a house, the process involves defining the robot’s structure, logic and compute functions as well as support and maintenance functions post-deployment. During the implementation phase, some degree of scope creep is to be expected, as the iterative back-and-forth between the deployment and business teams will likely yield new insights into process and logic details that require adjustments in configuration.
Once the robot is up and running, risk mitigation requirements include ongoing oversight of inputs, outputs and process. In addition to validating the data going into and coming out of the automation process are accurate, you need to ensure that all transactions are properly recorded and accounted for.
If you think of “risk” as any single action, event or infrastructure component that can contribute to the implementation’s failure to meet objectives, it’s easy to understand why attention to detail is imperative. By approaching each automation as a “project” that requires project management discipline, and by acknowledging that any process involves some degree of complexity, business and implementation teams can effectively mitigate RPA risk and achieve the anticipated benefits.
