st 
[vc_row][vc_column][vc_column_text]Prof. Willcocks, you have recently published a paper that takes an analysis of the effects and involvement of IT departments in robotic process automation implementations in organizations.
Could you please give us a short introduction and why you were looking specifically on the IT-function?
We researched 13 detailed case studies of robotic process automation adoption throughout 2015/16, and also carried out several surveys. While we found considerable business benefits, there also seemed to be surprisingly slow take-up of robotic process automation though it is accelerating dramatically, admittedly from a low base, throughout 2016. Our in-depth case work and interviews show much misunderstanding about RPA’s attributes, and how RPA fits with corporate IT architectures, infrastructures, skills sets, governance and security procedures. In particular IT functions seemed to react by either thinking they did what RPA already, through their IT tools and BPMS, or they saw RPA as a threat to security, governance, infrastructure integrity, and a form of unwelcome ‘shadow’ IT. In our view this has created unnecessary barriers to adopting RPA, and delays to gaining the large process and business benefits manifestly available.
Some CIO’s say that automation is nothing new and actually applied for many years with BPM. What are the differences and where do you see the IT-department’s role exactly?
RPA is not that new. The earliest adoption in our research was 2008 at a major utility. But it is different from BPM systems. There are two things that distinguish RPA from other BPM tools:
1. RPA is easy to configure; developers do not need programming skills. The RPA interfaces work a lot like Visio, by dragging, dropping and linking icons that represent steps in a process. As users drag and drop icons to automate a process, code is generated automatically. Business operations people, with process and subject matter expertise but with no programming experience, can be trained to independently automate processes within a few weeks. In contrast to RPA software, BPM solutions require coding expertise.
2. RPA is “lightweight” IT in that it does not disturb underlying computer systems. RPA software is an example of “lightweight” IT, a term used to describe front-end, commercially available software that supports processes and is typically adopted outside the control of the IT department. RPA technology sits on top of existing systems–without the need to create, replace or further develop expensive platforms. RPA software accesses other computer systems the way a human does—through the user interface with a logon ID and password. RPA software accesses other systems through the presentation layer—so no underlying systems programming logic is touched. RPA products do not store any data. In contrast to RPA software, BPM solutions interact with business logic and data access layers.
What are after your findings the most common misunderstandings of RPA and how can IT contribute in the decision making process when organizations evaluate the opportunities and conditions in implementing/extending RPA?
There are five common misunderstandings. The first arises from misleading vocabulary. Robotic Process Automation has become a label covering many different product and service offerings. Service providers have confused the market and ironically slowed sales, as a result. From our viewpoint, the market conflates three types of products, and call all three RPA:
1. Macros, scripting and screen-scraping (record and replay).
2. RPA (Robotic Process Automation). These products, which we consider true RPA, involve configuring a software robot to do the work previously done by people. The “robot” interacts with a computer-centric process through the user interface of the software supporting that process. RPA processes structured data.
3. SDKs (software development kits). These are different again in offering IT development teams the ability to build a robot according to their own design.
In practice, RPA really does need to be explained better to potential clients.
The second misunderstanding is to perceive RPA as an IT tool rather than a business tool to solve business problems in the face of infinite demand on finite IT resources. In practice, RPA eases IT workloads and delivers high-quality results quickly and inexpensively, solving the faster, cheaper for less conundrum facing many business operations and IT functions.
The third misunderstanding is to perceive RPA as shadow IT. All experienced users we interviewed agreed that, if badly implemented as a very basic tool outside IT sanction, RPA has limited business use. As ‘grey’, ‘stealth; ‘shadow’, or even ‘user-led’ IT, RPA can introduce operational risk, IT insecurities, create fault lines in applications. Further it loses the advantage gained from properly developed and implemented RPA in being un-scalable. In practice, RPA is ‘lightweight’ IT that benefits from business-IT cooperation. It can still operate largely outside ‘heavyweight’ IT resources. Moreover, it can be implemented quickly, as a business project, using a different approach from that used for heavyweight IT projects. In the case of RPA, its non-invasiveness depends on how it has been designed, while in our cases at least, all clients wanted to build RPA into an enterprise capability. Implemented within this definition, RPA becomes lightweight IT, and avoids the perils IT executives rightly associate with ‘stealth’ ‘shadow’, ‘grey’ and ‘end-user’ IT. For example, in the case of Xchanging, a service provider with a mature reengineering and IT capability, RPA was initiated by senior executives in its insurance business, but IT was quickly involved, and though some IT people were, at first, skeptical, the business and IT cases for RPA proved convincing.
The fourth misunderstanding is seeing RPA as an IT project. For the last 15 years business executives, and many CIOs, have recited the mantra that ‘there are no IT projects anymore, only business projects that are IT-enabled.’ Our own research suggests that more precisely they mean that most projects with a business imperative – and all IT-enabled business process innovation – need to be business/user led rather than IT led. RPA can be characterised as an IT-enabled business process innovation. How should RPA be managed? In practice, business operations should lead RPA. In every one of our cases, RPA was manifestly both a response to a business problem, and to the IT function being under terrific pressure to deliver on multiple business priorities while looking after the IT plumbing. In the cases we have investigated, RPA was accepted as an Operations programme, with IT collaboration and scrutiny.
The final misunderstanding is underestimating the full implications of RPA for IT governance, skills sets and organization. IT governance can be defined as: specifying the decision rights and accountability framework to encourage desirable behaviour in using IT. For most organizations, IT principles, IT architecture and IT infrastructure strategies should be primarily the domain of the IT function. RPA initiatives walk straight into many dilemmas here, especially in contexts where IT executives are nervous on having few decision rights in areas for which they feel responsible and exposed. But the actual clear answer emerging from the cases we have studied is that, to be organizationally effective, RPA needs to enter the existing IT governance processes as soon as possible.
In practice, RPA governance must fit within existing IT governance or may even evolve to a Center of Excellence. On skills sets, RPA needs distinctive operator roles. A Process Analyst leads Opportunity Assessments, and creates process definitions. A Process Developer will design, develop, test and support RPA solutions. A Test Analyst is needed to provide business process focused testing and auditing of the automated solution. A Process Controller administers, co-ordinates and controls the automated processes in the operational environment. A Service Analyst provides first line support for RPA production processes. Meanwhile at more senior levels we have found senior process controllers with expertise in all phases of the RPA development process and associated methodology plus hands ability in design, develop, test and support of the solutions. A Programme Manager is required to oversee the creation and ramp-up of RPA capability, while an Automation Manager manage RPA Capability to deliver new and support existing processes. On organization, we found a variety of practices. For example, The University Hospitals Birmingham NHS Foundation Trust started from within IT function and kept it there for over eight years. Xchanging started in Operations but with a strong relationship with their IT department. Bringing skills sets and organization together, one interesting development we encountered was a global financial services organization that formed an RPA Center of Excellence (CofE) from the start.
Do you believe that RPA will have a transformational effect on the way IT-departments work and are structured today? And if yes in which areas these effects will be most critical?
Our research does not lead to this conclusion. RPA is one tool in a large IT toolbox which will increasingly be added to as cognitive automation software develops commercial resilience. We found RPA to be a complement to IT functions, not a replacement.
RPA and classical IT / business process outsourcing – what are the implications for service providers and clients?
There are some big implications arising from large-scale RPA adoption, as seems likely over the next three years. In our research, we saw no job losses amongst client-run processes, but frequent job losses amongst offshore service provider staff . At the same time service providers were becoming eager to adopt RPA themselves, in order to compete in the changing marketplace. In our sample, these service providers were also being given more work to do, so the equation was becoming less people-centric: do more work for the same or less cost, through automation.
More widely, there are pricing model effects. We are seeing moves from FTE pricing to transaction and outcome-based pricing in outsourcing contracts. We have seen the development of separate human and robotic rate cards in the same outsourcing relationship. Service providers are having to rethink drastically the balance between labour and automation in the services they offer. They also have to make strategic decisions about whether to have proprietary RPA and more advanced cognitive automation tools, or be a value-reseller of another provider’s products, or whether to move higher in the chain and become an integrator of services. RPA also favours nearshoring and reshoring rather than offshoring, but we did not see that much change in location decisions in the 2015/early 2016 period. Early days?
And finally what would you suggest to our readers – experienced in RPA or not – when assessing RPA for their organization?
See it as a strategic asset from the start, the aim being to develop a mature capability available to all business process owners in the organization. In our book Service Automation, Robots and The Future of Work, we detail 25 recommended practices emerging from research into successful adopters. These cover Strategy, Launch, Change Management and Building Enterprise Capability. But you have to have the Strategy ones in place first. Strategic service automation requires cultural adoption by the C-suite. It requires strategic alignment with the business transformation objectives. RPA adds a sixth lever to the more traditional ones of centralization, standardization, IT enablement, optimization, and offshoring. Look for multiple business benefits in the business case, not just cost and headcount savings. Beware of hype. RPA is just one in a continuum of many tools and platforms suited to different types of services. It is a complement to enterprise systems and other automation tools. . Finally consider carefully the sourcing options. You can do RPA internally, outsourcing it, get your service provider to adopt RPA for you. Each approach has its own advantages and challenges.
[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column width=”2/3″][vc_column_text]Authors of the paper: Professor Mary Lacity, Curators’ Professor, University of Missouri-St. Louis and Visiting Professor, The London School of Economics and Political Science and Andrew Craig, The Outsourcing Unit, Senior Visiting Research Fellow, The London School of Economics and Political Science
Interviewer: Stephan Fricke, CEO and Head of the Advisory Board, Deutscher Outsourcing Verband e.V. (German Outsourcing Association)
About The LSE Outsourcing Unit: The Outsourcing Unit is part of the LSE, acknowledged as the world’s premier social science university, and in business and management studies ranked first above Cambridge and Oxford Universities in a 2014 Research Assessment Exercise. The OU draws upon a 2,400 plus case study database covering all major economic sectors and countries, and provides independent, objective and rigorous, timely research, report and advisory services to business, government and third sector organizations. Previous research and published work can be reviewed on: www.lse.ac.uk/management/research/outsourcingunit[/vc_column_text][/vc_column][vc_column width=”1/3″][vc_single_image image=”3363″ img_size=”full”][/vc_column][/vc_row][vc_row][vc_column][vc_column_text]This interview was published first in the Outsourcing Journal Special Edition “The ITO Edition”, which can be downloaded via the website of the German Outsourcing Association (free membership required): https://www.outsourcing-verband.org/en/outsourcing-journal-special-editions/[/vc_column_text][vc_empty_space height=”64px”][/vc_column][/vc_row]