CIO.com: Why do RPA initiatives often bypass the CIO?
Lacity:RPA’s magic is that the tools are designed to be used by subject matter experts (SMEs) rather than by IT programmers. In fact, it is more accurate to say that RPA users configure the software robots rather than program the robots. RPA recognizes that it is cheaper, better, and faster to train SMEs do their own automations rather than have SMEs explain their deep domain understanding to an IT software developer who then explains it to a team of IT coders. Because RPA tools are designed for SMEs, RPA adoptions are primarily initiated and led by business operations.
RPA champions in our study said they excluded IT at the onset for two reasons: (1) service automation was seen as a business operations program since it required process and subject matter expertise, not IT programming skills, and (2) fears that IT would beleaguer the adoption with bureaucracy. In most such instances, hindsight indicated that this was a poor approach; clients learned the importance of involving the IT department from the beginning so IT can help validate the RPA software as enterprise-worthy, manage how software robots access existing systems, and manage the infrastructure so it is available, secure and scalable.
Davison:IT is often focused on other issues such as managing infrastructure or applications, or on strategic business issues or major systems implementations. As a result, RPA projects tend to fly under the radar, and are sometimes perceived by IT as being a relatively low priority.
CIO.com: What operational and business risks result when IT is not involved?
Davison: One risk is that the business benefits of the RPA deployment will be delayed. If IT is brought in as an afterthought, technical issues that the business didn’t anticipate can arise and the project can be delayed. And that delay can be a significant issue for the business sponsors of the initiative, who likely built a business case that promised to deliver RPA benefits by a specific date.
On the operational side, if the CIO isn’t involved in vetting the RPA vendor and solution, there’s a risk that the solution won’t conform to performance standards or technical environment and configuration requirements. There are also potential issues around whether to include an RPA implementation and robots in disaster recovery and change management processes. Once deployed, robots can run around the clock, and if IT is out of the loop, application or infrastructure updates could compromise the robots’ performance and results.
Lacity:Business operations can inadvertently configure bad software robots that compromise data and system security.
In one client organization, the RPA champion gave all the robots his own ID and password, which triggered alerts in the IT security and fraud detection system. The security team quickly detained the RPA champion and he was nearly fired for violating security rules.
Sign up for CIO Asia eNewsletters.