Should CIOs be chief robot wranglers
[ Related: How to prepare IT workers for the impact of automation ]
In many cases business leaders are bypassing IT when implementing RPA initiatives, say Mark Davison, a director in the RPA practice of outsourcing and technology consultancy Alsbridge. In some cases, IT is not seen as a critical stakeholder since the service automation efforts tend to focus on process discipline and subject matter expertise, rather than on programming skills. In addition, business decision makers may see IT involvement as a potential roadblock or slowdown to their operational improvement initiatives.
[ Related: IT automation in the wild ]
However, these RPA systems do require a level of IT support and involvement to ensure performance. Lack of CIO involvement in business RPA projects them can lead to the typical risks of any shadow technology project—disconnected technology, performance issues, security lapses, and decreased business value delivery.
CIO.com talked to Davison as well as Dr. Mary Lacity, professor of information systems and the University of Missouri-St. Louis’s College of Business (and co-author of Service Automation: Robots and the Future of Work with Leslie Wilcocks) about the case for increased CIO involvement in RPA initiatives.
CIO.com: How important will RPA initiatives be to companies in the near future Why
Dr. Mary Lacity, University of Missouri-St. Louis: RPA is still in the early adoption phase. Our survey research revealed low RPA adoption levels in 2015, but a quick uptake in 2016. The business value of RPA is so compelling that growth will accelerate.
Our case research on 14 early adopters of RPA revealed that all 14 companies achieved triple wins with RPA—wins for shareholders in the form of positive one year returns on investment, wins for customers with better and faster services, and wins for employees who were freed from dreary, repetitive tasks to focus on tasks that required problem-solving skills, creativity, and social interactions.
Mark Davison, director, Alsbridge: Businesses are recognizing the benefits [of RPA]. The most apparent is cost reduction: a robot that costs $10,000-$15,000 a year to implement and maintain can, in many cases, replace five to 10 humans. But in many cases other benefits are more important. For example, robots produce work that is more dependable, accurate, documentable, and auditable. This helps improve process consistency as well as regulatory compliance, which is critical to highly regulated industries such as banking and pharma. With robots in the environment, transactions also get processed more quickly, which means more efficient payments and logistics. And, robots enhance analytics through their ability to rapidly process and collect huge volumes of data, which is a boon to industries such as healthcare and retail seeking to leverage big data.
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.
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.