In another company, the business operations staff made up all the data required to give the robots an account—like age, gender, and an employee ID. This severely compromises security.
In yet another company, the RPA team came to work one day to discover the robots stopped working in the middle of a job—precisely at midnight. The staff forgot that IT requires that passwords must every six months, so the robots’ accounts were suspended by the access management system.
When business operations took charge of loading software robots on decentralized servers without involving IT, network latency was horrible. At one company, network latency was so bad that the service was slower after automation. At another company, business operations couldn’t coordinate software robots because the hodge-podge infrastructure of servers with different power, memory, and operating systems caused disparate performance. IT finally rescued these companies and built scalable, safe, and robust RPA infrastructures.
CIO.com: What specific steps can CIOs take to support business RPA programs?
Lacity: The very first step CIOs must take is educating the IT folks about RPA. In general, IT professionals are about 18 months behind business operations in understanding what RPA is, how it differs from IT-led service automation tools like software development toolkits (SDKs) and business process management solutions (BPMs), and how RPA can be used for business advantage.
IT professionals need to understand that RPA compliments SDKs and BPMs. RPA is what we call “lightweight IT” because it accesses current systems at the presentation layer; Software robots get a logon ID and a password and are configured to do structured tasks previously done by humans. RPA’s sweet spot is taking over “swivel chair” processes where a human was aggregating data from multiple sources, applying rules, and updating systems of record. IT professionals will still be in charge of “heavyweight” software automation tools like SDKs and BPMs because these require computer programming skills to alter business logic and database layers in the OSI stack.
CIOs will find that if IT manages the RPA software vetting, RPA infrastructure, and access management, business operations can safely take control of service automation. This reduces IT’s workload. IT will not have thousands of requests for minor automation projects and can focus priorities on the “heavyweight” projects.
CIO.com: What about the cases when RPA is being used/implemented by third-party service provider?
Davison:CIO’s should be involved as part of their role of overseeing strategy and governance. More specifically, since the CIO controls IT resources, they need to be involved in managing how those resources will be used to install and support the initiative in terms of infrastructure and applications and change management. The CIO needs to ensure that the changes resulting from the RPA solution are in lockstep with IT. In a BPO solution, the provider may bring their own proprietary RPA tool into the environment to connect to the client’s system or may propose a third party solution. So the CIO needs to understand the technology in order to optimize performance and resource allocation, and effectively support users.
From an organizational politics standpoint, a CIO’s endorsement can facilitate buy-in across different business units, which is essential to ensuring results.
CIO.com: Are there lessons to be applied here from how CIOs have effectively (or ineffectively) handled other forms of shadow IT?
Davison: In many respects, the dynamics at play with shadow RPA are similar to what we’ve seen in the past. Years ago, departments would buy their own PCs that didn’t conform to enterprise standards for capability, performance, documentation, and backup—and consequently you’d see problems downstream. The net results were the sub-optimization of funds spent, poor performance, inability to integrate into the enterprise, and—ultimately—replacement of the systems. The result then as it is now is that if IT isn’t involved, the solution will be sub-optimal. So the lesson for IT is to get involved early and often, and to be perceived as an enabler rather than an obstacle.
Lacity:We are already seeing how a lack of centralized oversight is creating RPA islands in some global firms. In one financial service firms, different business units had negotiated radically different prices with the same RPA provider! If IT or another centralized group had aggregated demand, the company would have gotten a better deal. We also see business units selecting different tools with essentially the same functionality.
Join the CIO New Zealand group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.