Why You Need IT On Board for Your RPA Initiative: Part One

Professor Mary Lacity Makes the Case for Increased CIO Involvement in automation projects

The benefits of Robotic Process Automation (RPA) in the enterprise have become almost too enticing to ignore: positive ROI, improved and accelerated delivery of services and the liberation of knowledge workers from mundane, monotonous work that is better suited for machines.

By design, RPA is meant to be configured and leveraged by subject matter experts, explains Mary Lacity, Curators’ Distinguished Professor of information systems at the University of Missouri – St. Louis’s College of Business (also co-author of Service Automation: Robots and the Future of Work with Professor Leslie Willcocks). She says this creates the misconception that RPA is an operations project – not IT. This misconception, along with a host of others, prevents organizations from fully involving IT in an RPA initiative and ultimately stands in the way of its success.

In a conversation with Stephanie Overby of CIO (found in full in the article, “Should CIOs be chief robot wranglers?”), Lacity cites findings from her year’s worth of research on 14 early RPA adopters to explain why service automation projects so often bypass the CIO. She warns of the risks and potentially detrimental effects bypassing IT can have on realizing the true benefits of this cutting-edge technology, and the steps CIOs should take to support RPA programs. Overby and Lacity’s full conversation is excerpted below:

CIO: How important will RPA initiatives be to companies in the near future? Why?

Professor 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.

CIO: 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.

CIO: What operational and business risks result when IT is not involved?

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 change 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: 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 complements 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: Are there lessons to be applied here from how CIOs have effectively (or ineffectively) handled other forms of shadow IT?

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.