Managing Robotic Process Automation
MANAGING ROBOTIC PROCESS AUTOMATION: OPPORTUNITIES AND CHALLENGES ASSOCIATED
WITH A FEDERATED GOVERNANCE MODEL
Abstract
In this thesis, I explore Robotic Process Automation governance through a qualitative case study. The chosen research method provides an extensive overview of opportunities and challenges in a federated governance model for RPA. In addition, several practices to mitigate noticed challenges in the chosen governance approach are provided. Hence, this study provides novel insights into RPA governance.
In this study, case company's federated governance model for RPA is described based on material available on the intranet and information gathered through expert interviews. This study evaluates implications of the selected federated governance model on software robots' deployment and maintenance based on the held eight expert interviews. As a result, the study provides managerial implications of RPA governance for the case company that can be utilized in the development of RPA governance and other technology approaches that include similar characteristics.
Keywords: Robotic Process Automation, IT Governance, Business Process Automation
Table of Contents
1 Introduction
We are living in the era of change in traditional processes, while companies are constantly seeking new ways of doing business more efficient. At the moment, a miscellaneous group of business forums offers terms like lean, outsourcing and automation for cost-efficiency. Robotic Process Automation (RPA) is currently a highly debated automation tool for automating manual routine service tasks. McCarthy and Anagnostou (2004) wrote that outsourcing developed as a popular strategic management initiative in the early 90's, but the world changes continuously. Nowadays, RPA can be considered as a competitor for outsourcing and thus Slaby (2012) also argued: "robotic process automation emerges as a threat to traditional low-cost outsourcing". Companies have succeeded to launch many robots already, and researchers have highlighted that considerable operative cost savings can be achieved by RPA (Slaby, 2012; Lacity, Willcocks & Craig, 2015). However, companies are still learning to manage RPA among other automation tools.
In this thesis, I consider RPA functionalities when a corporate level Center of Excellence (CoE) has centralized to another country. I will evaluate case company's RPA functionalities based on a qualitative research. The ultimate goal of this thesis is to contribute the current research of RPA and offer an outlook about governing RPA to the case company.
The first part of my thesis begins with background and motivation for the study. In this part, I will introduce the rise of RPA and sources of my motivation. The last parts describe the basic elements of the thesis from research objectives to its structure.
1.1 Background and Motivation
Companies have striven focus on core value-adding functions instead of non-value-adding functions for a long time. Outsourcing has been a common solution for companies to focus on core business (McCarthy and Anagnostou, 2004). However, outsourcing includes scientifically proven risks and one of the noticed cons in outsourcing is wage rate fluctuations (Slaby, 2012). An example of that appears in Lacity, Willcocks & Craig (2015) research, where case company's annual savings achieved by outsourcing decreased continuously due to wage rate fluctuations in India. That was an incentive to reevaluate the case company's processes and a need for automation was born.
The trends of offshore outsourcing, outsourcing and RPA figured constantly in companies' strategies. The management of companies has enormous motivation for finishing projects concerning the above trends. In retrospect, passing the buck of routine tasks to an external organization or another country is not a long-term solution. Thus, the automation of routine tasks sounds more sensible in long-term than running after lower wage rates.
Software robotics stimulating discussion largely in business, especially in companies that have several legacy IT systems and necessary routine tasks to do in these systems by a human being. Many consulting companies offer their expertise for automation with different RPA software like Blue Prism and UiPath. Some companies have decided to do software robotics in-house, as a result of modest development skills required with RPA tools (Slaby, 2012). Despite how an RPA robot has been implemented, software robots are able to do human being's routine tasks. But the development of the concept has raised a question on my mind, how to govern RPA.
Currently, there does not exist enough literature about RPA governance. The existing literature focuses more on the early stages of RPA journey and presenting successful cases of RPA implementations (Lacity, Willcocks & Craig, 2015). This study aims to explore, how a multinational ICT company (see Appendix A) should govern software robotics. In RPA governance, companies have to pay attention for example, how changes in legacy IT systems influence on robots' performance. Moreover, how companies control software robots efficiently and simultaneously maintain one of its greatest strengths, agility.
The case company has decided to govern RPA with a federated structure. In practice, the company has erected a centralized RPA Center of Excellence (CoE) which is responsible for corporate-wide RPA development. However, all business domains have own local RPA CoE which is responsible for RPA value creation in their processes. In addition, the structure has an effect on RPA functionalities. For example, the business domains are responsible for the development of their own software robots, but when the software robot is developed ready for the implementation and maintenance phases, only the centralized RPA CoE can implement and control it. Regarding the software robots' development, the above-mentioned decision may cause challenges or even problems to the company that needs to be mitigated.
Currently, there is not enough research with respect to the field of RPA. In addition, there is not enough research about the governance of software robotics. Hence, the demand for my study exists. This study aims to contribute the current RPA research and gives insights into successful RPA governance.
1.2 Research Objectives
In this thesis, research objectives are placed in the research field of IT, more accurately in the field of RPA governance. Management of Information Systems has been a research topic for a long time and for example, Edwards (1984) offered an integrated perspective for information systems maintenance. RPA is currently one of the top topics in business and companies have already some RPA-solutions in-use, but there does not exist enough research how the concept of RPA should be governed. Also, Bygstad (2016, p.12) suggest an avenue of future research regarding software robotics which has described as a "lightweight IT": "for the IT departments around the world, the governance of lightweight IT is basically unsolved, and we need to develop new, practical models that combine the generative potential of heavyweight and lightweight IT".
An extreme option for RPA governance could be a fully decentralized governance where local business units are entirely responsible for their own robots, in other words, every business domain's RPA activities are based on their own RPA CoE. A radical alternative to the aforementioned is a centralized RPA governance where the head of RPA is centralized, and business domains lose their autonomy. Naturally, both possibilities include advantages and disadvantages and my thesis is going to explore the chosen governance structure for RPA in the case company.
In consequence of noticed research gap, research questions were defined:
• How does the federated governance model affect the implementation and maintenance of software robots?
• What kind of practices does the case company build for tackling potential challenges in consequence of the federated governance model?
1.3 Research Methods
At the moment, RPA research can be stated as a young research field. There is a lack of research regarding the governance of RPA. My study aims to broaden the current research in the field of RPA governance. I chose a qualitative case study as a research method to achieve a high-quality study. The qualitative case study was executed by eight semistructured expert interviews.
The research method was a natural choice for the study because there is not enough existing literature available for answering the research objectives. In addition, the facilitation of understanding of the complex research field and finding casual connections requires a concrete example. Based on the arguments above it can be stated that the thesis is a strong empirical study.
1.4 Research Scope
The concept of RPA includes a lot to explore in different aspects and for ensuring a highquality master's thesis it is important to define enough narrow scope. While approaching the field of RPA, I define my research scope to one case company.
In the theoretical background, I will introduce the work system theory. In addition, the governance tendencies of centralization, decentralization, and hybrid will be handled in the next section, because the thesis explores effects of the chosen governance structure on the company's RPA functionalities. Finally, I consider the term of RPA that the concept can be explored comprehensively.
In this study, RPA research field is observed from the aspect of governing software robotics. My main interest is to explore what kind of opportunities and challenges the federated RPA governance, and the centralization of corporate-wide RPA CoE to another country induce. Does the centralized group level RPA CoE induce challenges for the organization and how the case company tries to take a full advantage of the chosen governance approach?
As a result of limitations in the current research and the size of master's thesis, I have only chosen one research method for the thesis. However, the chosen method is believed to give the most valuable information and ensures that I can get enough depth on the chosen research topic.
1.5 Structure of the Thesis
This study includes six sections. The second section considers the theoretical background of this research. First, I present the work system theory in order to build an understanding of work systems and development of them. In addition, I discuss IT governance and its influences from aspects of centralized, decentralized, and hybrid model. Lastly, I describe the term of Robotic Process Automation and a typical journey of software robot from the beginning of the RPA project to the maintenance phase.
The third section, research methodology, introduces the method used in data collection and analysis for the empirical study. The fourth section presents the research findings from the analysis of the expert interviews. This research fifth section discusses the research findings and the current research outlook. In the last section, conclusions, I summarize the research results and give suggestions for the future research.
2 Theoretical Background
This section enables a scientific approach to the empirical case study. At first, I introduce the work system theory. The theory describes how companies realize systematically information related work. Then, I move to consider a structure of IT governance. I approach IT governance in terms of centralization, decentralization, and hybrid model of them that the case company's approach can be explored. In the last part of this section, I introduce the concept of RPA and its short history. I describe what RPA is, the different stages of RPA robot's lifecycle from the beginning of an RPA project to the maintenance phase, and the term of RPA CoE. In the description of RPA journey, I assume that a company has already RPA experience and facilities. Lastly, I go through successes and challenges in the RPA field.
2.1 Work System Theory
Companies usually possess several work systems simultaneously. While approaching a work system from a static view, it describes how a work is done through a determined system. The outputs of a work system are services and products for its internal and external customers. (Alter, 2002, p.6) Alter (2002, p.5) introduced the Work System Framework which describes the functionality of a work system with nine elements. The framework includes four internal elements: business process, participants, information, and technology; that perform the system's work. In addition, the framework includes five other elements: products & services, customers, environment, infrastructure, and strategies; that should be taken into account for a deeper understanding of a work system.
A few work systems remain unchanged and keep their static state for a long period. Hence, the work system theory combines a static view and a dynamic view. The dynamic view illustrates, how a work system changes through planned changes and unplanned adaptions (Alter, 2001). For the dynamic view, Alter (2001, p.17) introduced the work system life cycle (WSLC) model which aimed to solve the communication gap between business and IT regarding the understanding of work systems and development of them. The above-mentioned author has updated the WSLC model multiple times and the following figure (see Figure 1) has adapted from these presentations.
The WSLC model includes four phases: initiation, development, implementation and operation & maintenance. The static view of a work system can be positioned to the last phase, operation & maintenance. A decision between operation & maintenance and initiation phase includes the most alternatives. The decision might be to continue a current work system with incremental improvements, then an action is called as a continuous change. The second alternative is to initiate a major revision of the current work system and move to the initiation phase. The issue at stake is a discontinuous episodic change (Lyytinen & Newman, 2008, p.5). The last alternative is to terminate the current work system (Alter, 2001, p.17).
Lyytinen & Newman (2008, p.4) described work systems with characteristics of inflexible, habitualization, and high complexity. To overcome these weaknesses of work systems and enabling successful change for them, the authors wrote that there exists a need for a separated system called as the building system. This system's functionality has described in the following way, "commands a set of resources and enacts routines to carry out the change and address the issues of uncertainty, ambiguity, and complexity" (Lyytinen & Newman, 2008, p.4). In most cases, the building system is isolated in space and time from the work system. However, these systems cannot be separated entirely because they are constantly interacting among themselves and inducing changes across both systems.
Both systems, work and building, include same components that interacting among themselves. Lyytinen & Newman (2008, p.6) described these systems as a social-technical model which includes four socially constructed components of technology, structure, actors, and tasks. Bloomfield & Vurdubakis (1994) research emerged, that boundaries between these systems are drawn through negotiations which define the rights, responsibilities, and roles of each component. Hence, it can be argued that the borders of systems variate significantly between companies.
In table 1, I present the main content, the main properties, and gaps of the all four components in the aspect of work and building systems. Work system's tasks describe the way of work getting done in the organization. Its actors consist of individuals who execute or influence the work. Work system's structure covers for example communication systems. Technology defines what tools a work system utilizes during the work. Project deliverables and aspired process features define the tasks of a building system. Its actors are individuals who can develop the system and benefit from it. The structure of it covers formal project organization and decision-making structure. A technology component defines which tools it utilizes in the developing of the information system.
The components include several main properties, for example, task uncertainty, actors' commitment and skill, actors' cultural and historical differences, the structure's level of centralization, the structure's level of span and control, and the technology's level of specialization. In addition, table 1 presents possible gaps between the components from different angles. The actor and the task components may include a gap between actors' capability and willingness to execute the task. The structure may hinder the execution of tasks which generates a gap. A gap between the task and the technology components may exist when the technology is unsuitable for the given task.
Furthermore, a gap between the components of actor and structure may exist in a situation where an actor is not familiar with the structure's procedures or does not accept the structure. Sometimes, actors are incapable to utilize the technology or are not willing to use it. Lastly, the gap between the structure and the technology components arise when the technology does not fit in the structure or the structure is unsuitable for taking a full advantage of the technology's capabilities.
Table 1: The characteristics of socio-technical systems, condensed after Lyytinen & Newman (2008)
Component | Main content | Main properties | Gaps |
Tasks | Work system: Tasks describe the way of work getting done and the goals of the work systems. Building system: Project deliverables and aspired process features defines tasks. | Task size and complexity, task uncertainty, task stability
| Task-actor: Actors incapability or unwillingness to execute the task. Task-structure: The structure does not support the execution of the task Task-technology: The feature of technology does not support the task |
Actors | Work system: Organization's members and main stakeholders who execute or influence the work. Building system: Customers, managers, maintainers, developers, and users who can develop the system and benefit from it. | Commitment and skill, wrong expectations, opportunism and personal agendas, cultural differences, historical differences | Actor-task: Actors are not suitable for the task Actor-structure: Actors do not know the operating procedures or do not accept the structure. Actor-technology: Actors incapability or unwillingness to use the technology |
Structure | Work system: The structure covers workflow, authority, and communication systems Building system: The structure covers formal project organization and decision-making structure with its workflow and communication tools. | Level of centralization, level and span of control, allocation of rights and duties, geographical dispersion, functional differentiation and specialization | Structure-task: Structure is unsuitable for the task Structure-actor: Structures do not support actors' tasks Structure-technology: Structure is unsuitable for taking advantage of the technology's capabilities. |
Technology | Work system: Technology tools that are used during work, e.g. computers, platform. Building system: Technology tools used to develop and implement the information system, e.g. design tools, hardware technology. | Functional dimension, level of specialization, systemic properties | Technology-task: Unsuitable technology for a given task Technology-actor: Actors incapability to utilize the technology. Technology-structure: Unsuitable technology for a given structure. |
Based on the nature of both systems, it can be stated that the building system impacts enormously on work systems and life cycles of them. This system defines frames for continuous change and especially for a discontinuous change of work systems. Both systems are continuously interacting among themselves and inducing changes across both systems, but enormous gaps inside the system or between systems may exist.
In the next section, I will handle IT governance and its tendencies of centralization, decentralization, and hybrid, which is the intermediate form. IT governance is strongly related to work and building systems. The decision regarding IT governance can determine the temporal and locational distance between work and building systems. Hence, administrative decisions in connection with building and work systems organizing require deeper examination.
2.2 IT Governance
Governance is the manner, how an entity governing all the processes undertaken by itself (Bevir, 2012). Hence, it can be said that it inhibits confusion inside an entity by defining for example responsibilities. In this thesis, my attention is focused on IT governance due to the nature of RPA. Because of this, the earlier term definition of governance requires elaboration. Weill (2004) defined the IT governance in the following way:
"IT governance is not about what specific decisions are made. This is management. Rather, governance is about systematically determining who makes each type of decision (a decision right), who has input to a decision (an input right) and how these people (or groups) are held accountable for their role. Good IT governance draws on corporate governance principles to manage and use IT to achieve corporate performance goals."
Weill (2004, p.2-3)
The previous determination is enough extensive for this thesis and in the next chapter, I handle forms of IT governance.
2.2.1 Centralization, Decentralization, and Hybrid
Centralization refers to the impression of the authority to make an important decision in the head of an organization, while respectively decentralization reflects more autonomy to make decisions locally (Cummings, 1995, p.103). A concrete and universal example describes a difference between these terms when comparing organization's centralized and decentralized IT governance. In the centralized IT governance, the biggest authority to make a decision related to IT is centralized to the determined center of IT and business units are unable to manage IT changes by themselves. In the opposite, all business units are responsible for their own IT and there are no limitations to make changes by the business units.
However, the above-mentioned unrealistic bi-polar and rigid classification of governance structures between centralization and decentralization has been challenged in the current literature by allowing multiple degrees of these governance structures. One of the methods to define the degree of governance named as a continuous classification which allowed, for example, the determination of soft midrange points between these extreme governance structures (Brown et al., 2005). There exist many other methods to define organization's governance structure, but the most explicit way to define it is sharing governance structure into three categories: centralized, decentralized, and hybrid.
Lewis (2004) wrote about companies' hesitation with IT governance models. He weighed the pros and cons of centralized, decentralized and hybrid IT governance structures. Centralization includes the advantages of cost-efficient, highly efficient at corporate-wide initiatives and running stable, repetitive global operations, and controllability. A lack of ability to react agilely to changes in the local environment and the understanding of local needs are seen as the biggest challenges of centralization.
The decentralized governance structure's pros regard mainly to the ability of act locally. Business units can implement local strategies efficiently, response to local requirements, and ensure service's high-quality. On the other hand, decentralization causes lower cost-efficiency when costs disappear into business units' budgets, autonomous complicates corporate-wide initiatives, and general corporate-wide controllability decreases significantly. (Lewis, 2004)
The hybrid governance structure includes also pros and cons. At its best, it can take the advance of both extreme governance structures by centralizing commonly used functions like ERP or e-mail and decentralizing functions that are not shared across business domains. As a result of successful hybrid governance, the structure can be cost-efficient but simultaneously maintaining the ability of act agilely and responsively to local needs. A messy share of responsibilities between business units, and a requirement for talented matrix management and shared services management are the cons of the hybrid structure. (Lewis, 2004)
Table 2: Centralized, decentralized, and hybrid IT Governance, adapted after Lewis (2004) and Weill & Ross
(2005)
Characteristic | Centralized | Hybrid | Decentralized |
Strategic driver | Profitability & costeffectiveness | Profitability and retention of innovativeness | Fast growth and innovativeness |
Key IT governance mechanism | Enterprise-wide management mechanism | IT leadership team | Local accountability |
IT infrastructure | Not locally customizable shared services | Shared services centrally coordinated | Local customized capability with few required shared services |
Key IT principles | Low business costs | Low IT unit costs | Local innovation with communities of practice |
Pros | Cost-efficient, controllability, corporate-wide spreadability | Cost-efficient, reacting to local needs, benefits from shared services | Agile response to local requirements, innovativeness, service quality |
Cons | Incapable of reacting to local requirements, loss of innovativeness | Confusing structure of responsibilities, need for talented matrix management | Not cost-efficient, lack of corporate-wide controllability |
Although Lewis (2004) has a clear opinion which IT governance structure fits the best into companies, it can be argued that researchers are mainly unanimous about the absence of the "golden" IT governance structure (Brown & Grant, 2005). Several different factors influence on company's IT governance's formation and those factors have been studied a lot in the existing literature. In Table 2, I summarize all the key characteristics of the abovementioned three governance orientations, and advantages and disadvantages of them. The most influential factor in an IT governance choice between centralized, hybrid, and decentralized is a strategical orientation. Organizations that focus on profitability and costeffectiveness in core competencies usually end up with more centralized IT governance. Organizations with a fast-growing strategy and insist on locally accountability typically end up with more decentralized IT governance. The hybrid choice balances between these two strategies and aims to enough strict governance structure for profitability, controllability, and innovativeness. (Weill & Ross, 2005)
The key IT governance mechanism differs in these three governance forms. In the centralized option, business units' IT is managed by the corporate-wide management and they follow corporate-wide decisions without any autonomy. Local accountability is the key mechanism in the opposite extreme structure without corporate-wide decision functions. In the hybrid governance structure, IT decisions is made by the IT leadership team which consist of local units' IT representatives. (Weill & Ross, 2005)
The shape of IT infrastructure is the third characteristic of the table. A centralized IT infrastructure is based on shared services that are not modifiable in business units. A hybrid IT infrastructure utilizes shared services also, but typically business units have the freedom to develop IT solutions for their needs. However, these local IT solutions are coordinated corporate-wide in order to launch a standardized shared service instead of an isolated local solution. A decentralized IT infrastructure is entirely capable of local customization with few required shared services. (Weill & Ross, 2005)
The last unaddressed characteristic of Table 2 is the key IT principles. In the first IT governance orientation, centralization, it is low business costs. Companies seek low business costs with a high degree of standardization in IT services. The standardized services are offered to all business units as a shared-service. In the decentralized orientation, local innovation is the key IT principle. Organizations aim to maximize growth by innovativeness in local communities of practice. In the last IT governance orientation, the key IT principle is low IT unit cost. Corporates strive to decrease the IT unit costs by avoiding development of duplicate IT services and encouraging to reuse of process models and services that are useful corporate-wide. (Weill & Ross, 2005)
In the last section of the theoretical background, I will introduce Robotic Process Automation. I will describe what RPA is and how a software robot is developed. In addition, I will present RPA CoE, which is the heart of RPA function. Finally, I will discuss the challenges and successes in the RPA field.
2.3 Robotic Process Automation
RPA is a subfield of Business Process Automation (BPA). Mohapatra (2013, p.214) wrote about the history of BPA which originates mid-90's when Business Process Re-engineering (BPR) did not thrive consistently across diverse industries. The next wave in process management was Business Process Management (BPM), which aimed to make business processes more efficient with the proper use of IT instead of eliminating them which was the main goal of BPR. After these process management trends, BPA emerged which main goal was to make processes more efficient while maintaining the importance of employees.
Nowadays, RPA has emerged as a highly debated solution for automating business processes. This thesis focuses on exploring this BPA sub-field. Next, I will introduce a definition of Robotic Process Automation.
2.3.1 Definition of Robotic Process Automation
Although RPA can be stated as a young research field, the concept has already different definitions. Lacity, Willcocks & Craig (2015, p.4) described the concept in the following manner, the main idea is to configure a software robot to do the work previously done by a human being. Researchers highlighted in their definition that a software robot is not a desktop script that assists human agents, but it replaces even entire tasks previously performed by a human being. Authors wrote also about RPA's high interoperability and argued that a software robot needs only an access to the same presentation layer than an employee normally uses. RPA does not need changes into legacy IT systems but teaching an RPA robot to do tasks is enough. (Lacity, Willcocks & Craig 2015, p.10)
Another definition describes software robotics as a technology which enables process automation quickly and cheaply by software robots that handle routine tasks previously done by an employee. Created components of software robots can be reused to develop new robots. (Slaby, 2012, p.5) Moreover, RPA has defined as a lightweight IT which is driven by competent users' need for solutions and the solution is typically realized through innovation processes. The opposite is heavyweight IT, "the more traditional IT", which is driven by IT professionals through software engineering. (Bygstad, 2016, p.3)
Bygstad (2016, p.3) summarizes and separates comprehensively the attributes of heavyweight and lightweight IT. In his definitions, the owners of lightweight IT are users and vendors, and the IT architecture of lightweight IT has defined as non-invasive solutions. Because lightweight IT's characteristics differ significantly from heavyweight IT's and it is a new form of IT compared to the more traditional, the governance of lightweight IT is basically unsolved. Also, Bygstad (2016) wrote about that lack in the current research and highlighted the need for developing new, practical models that maximize the generative potential of both IT forms.
Based on the current research about RPA I describe it as an automation tool which enables agile business process automation for non-engineers with a low financial and timeconsuming investment by configuring rules for a software robot in order to do manual tasks of employees. The software robot is not just a desktop script which assists an employee to do tasks, but it can complete even entire complex tasks. An RPA tool is based on programming languages and a user does not need programming experience for the use of RPA tool. However, the logic of RPA tool must be understood in-depth. RPA utilizes other information systems by user-interface. In other words, a software robot operates across IT legacies via front-end, while a traditional IT automation has built to operate via back-end. (Asatiani & Penttinen, 2016, p.2) As a result of this characteristic, RPA is highly dependent on the functionality of IT systems where software robots operate.
A software robot can for example: manage data between prescribed systems, make calculations for analytics, monitor and control many systems simultaneously, even trigger downstream activities of a system (Tornbohm, 2016). In contrast to the more traditional IT, the nature of RPA is more business orientated. Thus, the concept can be defined as an automation tool which aims to create a controlled discontinuous change of work systems by embedding new information technology components and changing the processes of the current work system. Next, I will move to consider the heart of RPA, RPA CoE, which acts as a core of company's RPA actions.
2.3.2 RPA Center of Excellence
CoE has been defined in many ways depending on the context where it occurs. A comprehensive term definition does not exist in the context of RPA, but in the context of BPM, the term has been described. The CoE is the key component of the successful management of business processes. The BPM CoE is the point of accountability of company's processes and tasked with, for example, ensuring sustainability, alignment, governance, measurements that make BPM successful. (von Rosing, von Scheel & Scheer, 2014)
The concept of RPA CoE has commonly used in business and its purpose can be described in the same way as in the definition of BPM CoE. The core of RPA CoE is a Robotic Operating Team (ROT) which consists of several and clearly defined roles and responsibilities. Because the field develops quickly, new roles and responsibilities emerging continuously in the ROT, there is not a completely consistent way to build the RPA CoE. According to some definitions, roles of a sponsor, champion, change manager, business analyst, solution architect, developer, infrastructure engineer, supervisor, service support are
possible roles in the ROT. (Uipath, 2018) Although every role includes work and responsibility, a single person can be responsible for several roles at the same time.
These roles of the ROT can be categorized into three groups based on the nature of the role. The first group, the RPA enabler, consists of roles of sponsor, champion and change manager. It enables the concept of RPA and it is responsible for successful adoption across the organization. The second group, the RPA creator, consists roles of business analyst, solution architect, developer, infrastructure engineer. This group's responsibility is to realize software robots. The RPA controller is the third group which consists roles of supervisor and service support. The last group is responsible for managing, controlling of implemented robots and simultaneously improves, ensures robotic operational performance by analytics and service support.
Figure 2. RPA Center of Excellence
Granted a significant role of the CoE in RPA, the concept needs input from other stakeholders in a successful adaptation. In Figure 2, I describe all the most important stakeholders of successful RPA management. IT department is a vital stakeholder in RPA. Lacity, Willcocks & Craig (2015, p.7) wrote about an assertion of software robotics to IT department. After the IT department became convinced about RPA, software robotics became a part of case company's technology offerings. Also, Slaby (2012, p.13) argued that cooperation with the IT department is essential for the success of RPA. Cooperation with the IT department further the solving of technical challenges and enabling traditional infrastructure planning, support, and security. In addition to the previous points of cooperation, the involvement of IT department in the maintenance of software robots is essential. The information about planned IT changes and their effects on software robots' functionality due to RPA scripts' up-to-dateness impacts on the overall performance of RPA (Tornbohm, 2016). Because the essential involvement of IT and the nature of RPA, a suitable governance structure is alleged to lie between business and IT (UiPath, 2018).
The second vital stakeholder is employees and their managers. RPA's impact on employees has explored as a downside of the concept. RPA has been found to have even a destructive effect on employee morale because they have seen software robots as a direct competitor of their jobs. (Asatiani & Penttinen, 2016, p.2) An involvement of this stakeholder is important because their role, for example as process experts, is considerable in the development of software robots. In addition, RPA itself could even create new jobs eventually for example, in robot management (Asatiani & Penttinen, 2016, p.2). To fill these places, it would be sensible to offer RPA education to employees and move them from routine tasks to more productive. In addition to employees, managers of these process experts are necessary to involve in RPA. Usually, managers decide where employees spend their time. If they decide to keep their employees doing routine tasks instead of letting them develop processes and software robots, the full potential of RPA will not be achieved.
Next, I will describe RPA robot's journey from the beginning of a project to the maintenance phase. In the journey description, I will handle the RPA robot's journey from a perspective of in-house RPA development.
2.3.3 RPA Robot's Journey
A software robot can be developed as an in-house project or alternatively supported by an external operator. Asatiani & Penttinen (2016, p.4) described the main phases of RPA introduction to client organization from the perspective of RPA provider. In this description, the stages are RPA potential analysis workshop, process assessment, business case proposal, and RPA implementation. I approach a journey of a software robot from the perspective of in-house RPA project by the case company and Figure 3 summarizes the main phases.
Figure 3. RPA Robot's Journey
The company starts an RPA project with a pre-study and building a business case. In this phase, the main objective is to understand the environment and processes for further evaluation and estimate RPA potential in the current processes by a business case. The understanding of the environment and its processes can be achieved in several methods for example, from idea channel or RPA potential workshops.
A need for RPA investments will be evaluated in the business case by looking at the total costs of RPA solution against the outcomes of delivering a process by RPA. The total costs of the RPA solution include, for example, the personnel costs of developing software robots to do tasks and the total cost of ownership (TCO) of the robot. The TCO differs depending on the pricing model of a provider, but basically the term related to license payments and robot's maintenance. (Tornbohm, 2016) The potential outcomes of RPA solutions include, for example, the higher quality of processes and increased customer satisfaction, the improved turnaround times of processes, cost-efficiency, and employees have more time for cognitive tasks (Slaby, 2012). In addition, RPA projects lead usually to other process development due to accurate process description during process analyzing (Tornbohm, 2016).
The next phase of the company's RPA journey is process & RPA analysis and pilot. In this phase, an RPA business analyst analyzes the automatable process in close cooperation with process specialists, typically people who have a deep experience in doing these presently automatable tasks, and simultaneously creates process maps of the current process. Based on the created process maps an RPA developer designs and develops the software robot, tests the automation workflows, and acts as a support for the pilot's implementation. Next, an engagement team implements and tests created RPA solution, and the solution's all actions will be monitored and evaluated. Before the next phase of the software robot's journey, the solution will be revised based on the pilot's monitored results and feedback from the engagement team. (UiPath, 2018)
The last phase of the journey is the implementation and maintenance of the developed software robot. The software robot will usually be implemented into a process by ROT. The maintenance of a robot starts immediately after an implementation and the maintenance of software robots means auditing and monitoring of their activities, reacting to failures, and keeping RPA scripts up-to-date (Tornbohm, 2016). The maintenance of robots needs special attention if they are planned or programmed to run 24/7 and the organization faces changes in legacy IT systems where the software robots operate. When the organization modifies IT system, where the robot operates but the robot's script is not up-to-date, it will do failure instantly.
The journey of a software robot seems straightforward and simple. However, the development of software robot includes challenges and typical stumbling blocks. One of these typical obstacles lies in the building a business case. Focusing too much on potential cost reductions instead of revenue-generating outcomes can be seen as a challenge for companies. Cost reduction by saved Full-Time Equivalent (FTE) is mentioned as a benefit, but this area of cost reduction is not usually achieved as planned because the saved FTEs redeployed to other tasks. Some estimations argued that ignoring focus on RPA's capability to improve business outcomes limits potential achievements of RPA from 50% of organizations by 2019 (Tornbohm, 2016). Hindle et al. (2018, p.6) expressed an emerging risk in RPA projects when created business cases aimed at immediate FTE savings too aggressively. In the next section, I will discuss the successes and challenges in Robotic Process Automation.
2.3.4 Successes and Challenges in RPA
As it has been mentioned earlier in this thesis an enormous business value can be achieved by RPA. Lacity, Willcocks & Craig (2015, p.4) reported the return on investments (ROI) in the automation of 15 core processes with over 160 robots in a case company. A three-year ROI rate was between 650 and 800% and a payback period was approximately 12 months. Another success can be achieved when comparing offshore outsourcing and RPA (Asatiani & Penttinen, 2016, p.2). Also, Slaby (2012, p.10) proved this potential with RPA in a case study, where 45 offshore FTEs replaced with 10 robotic FTEs. The annual cost savings of that replacement was $1,25M. However, these two success stories are evidence of wellmanaged RPA projects. A later quantitative research about the usage of Blue Prism RPA tool in different organizations indicates much lover ROI rates. In this quantitative research, 28% of the respondents informed that a one-year ROI was between 1 and 25%. Over 10% of the responders argued that the one-year ROI was negative or zero. However, approximately 20% of the respondents expressed that the one-year ROI was 76-100% or over 100%. (Hindle et al., 2018, p.21)
Robotic Process Automation contains functional challenges related to the technology and more strategical challenges for example, in RPA adaptation and understanding the overview of its potential. One of the functional challenges lies in software robot's configuring. A software robot needs completely explicit configured rules and these rules must be up-to-date. This challenge has been found when robots have made a failure, for example, sending multiple phones to a customer instead of a phone. Another noticed functional challenge related to an internal IT infrastructure where the RPA technology operates. The IT infrastructure needs to be enough capable of running RPA technology when maximizing the potential of the concept. (Lacity, Willcocks & Craig, 2015, p.13)
There exist several more strategical challenges related to software robotics. First, organizations that considering RPA as a tactical tool to decrease FTE's from some processes in certain departments and misunderstanding all the potential outcomes, for example, increased customer satisfaction and increased quality due of disappeared human errors inhibits RPA's potential (Tornbohm, 2016; Hindle et al., 2018)
Second, some organizations are not able to buy-in all the important stakeholders or even the most critical. Hindle et al. (2018, p.7) argued organizations fail especially in the following two areas: not considering the broad range of stakeholders, and poor communication through the organization.
Third, companies are stumbling in the selection of suitable RPA sourcing method and platform. Some companies try to execute RPA in-house but notice a lack of RPA capabilities. On the other hand, some outsource the capability and disappoint in achieved value. The number of available RPA platforms is confusing companies at the moment and it can be challenging to find the most suitable tool to match needs. (Lacity, Willcocks & Craig, 2015, p.14; Hindle et al., 2018, p.6)
Lastly, change management causes challenges for companies. Companies must ensure workable change management which requires good communication that all business units affected by a change know about it, and organization can act efficiently and agilely in RPA changes with well-defined responsibilities. (Hindle et al., 2018, p.6-7).
Research Methodology
3 Research Methodology
This section presents the utilized research method. In this section, the chosen research method is justified, and the elements of the study process are described.
In the next chapter, I discuss the chosen approach of this study. I provide arguments for the chosen research method based on the current literature and the aims of the study. The data selection is the second part of this section. In this part, I introduce, how the data was selected for the study. The last part is data collection and analysis. This part describes the study process of the qualitative research method.
3.1 Chosen Approach
This research aims to broaden the current research of RPA and simultaneously gives managerial insights of RPA governance to the case company. The existing research has highlighted the agility and effectiveness of process automation by software robotics. However, the current research has not provided enough insights into RPA governance as an enterprise-level practical element of a multinational company.
I approached the research gap by a qualitative study. The most important reason for the chosen method was a lack of research relating to RPA governance in the existing literature. Taylor, Bogdan, & DeVault (2015, p.164) introduced their notion of qualitative research and a key characteristic of qualitative research was its inductiveness. The authors highlighted that qualitative researchers develop novel insights and understanding instead of re-evaluating existing theories. This definition has also been described by a grounded theory where the goal of qualitative research is to build theory (Glaser & Strauss, 1967). This study aims to broaden the current understanding of RPA and give insights into an unsolved governance structure for RPA.
To reach the objectives of this study, I decided to utilize expert interviews as the data gathering method. The purpose of the expert interviews was to gather data about the implications of the selected federated governance model on software robots' deployment and maintenance. In addition, I wanted to research, what kind of practices does the company build for avoiding potential challenges related to the federated governance model. With the chosen research strategy, I gained valuable information for achieving the research objectives.
Research Methodology
3.1.1 Expert Interviews
As a result of study objectives, a semi-structured interviewing technique was utilized for data collection. Semi-structured interviews are conversations where an interviewer is conscious of topics that should be covered, and a set of questions is prepared before the interviews. However, it is typical for the semi-structured interviews that the conversation is free to vary and the level of variation changes between interviews. (Miles & Gilbert, 2005, p.65-67) Usually, this interview technique is structured into segments and an interview starts typically with entirely open-ended questions towards more theoretically driven questions as the interview progresses (Galletta, 2013, p.45-60). The interview template, (see Appendix C) which has been utilized in this thesis, follows the above-mentioned interview structure but includes enough structure that a coding frame can be utilized in the analysis phase.
The semi-structured interviewing technique includes benefits that contribute this study's value. The first important benefit of the interview method is its versatility. The interviewer can react to participant's responses and explore possible contradictions within participant's responses by more elaborate questions (Miles & Gilbert, 2005, p.65-67). A great potential to attend to the complexity of chosen research topic is the second key benefit of the chosen interview technique. The interviewing technique provides the possibility to focus on the lived experience of research topic while also addressing theoretically driven variables of interest (Galletta, 2013, p.45-50). These characteristics of the semi-structured interview enable the development of a much deeper understanding of the research question in a complex research topic compared to a fully-structured interview technique.
3.2 Data Selection
I decided to gather the research data through expert interviews inside the case company. This decision is based on several factors that eliminated other alternatives. Firstly, the research topic is comparatively young, and the concept of RPA is still searching for a place inside companies. Hindle et al. (2018, p.29) wrote about four phases of RPA market: hype and fear, focus on ROI, triple win, institutionalizing. This study aims to explore administrative aspects of RPA when the company has reached the institutionalizing phase. Therefore, I should have been found another company which has also expanded RPA practices into several countries and has reached the institutionalizing phase.
The second reason which led me to focus on one case company was master's thesis size limitations. The master's thesis should not swell too broad. For ensuring that I can get
Research Methodology
enough depth on the chosen topic, and generate valuable information for the study, it was justified to focus on one case company. Also, Punch (1998, p.119-121) argued that building an in-depth understanding of the case is valuable for research. For this research, it is significant to ensure a high value of findings from the expert interviews that help to build a novel understanding of the chosen topic.
Employees for the interviews were selected in a cooperation with one of the company's RPA group managers. The selected interviewees were chosen in order to get versatile views all around the company's RPA functionalities. Among the interviewees were employees from different RPA roles that have been involved in the corporate-wide RPA development (See Table 3). Hence, group and country level views will be taken into account by the collected data.
3.3 Data Collection and Analysis
The data collection began on December 2017 and it continued till May 2018. At first, unofficial meetings were held with the case company where we explored the most potential interviewees for the expert interviews. Findings were recorded in notes for deeper reflection. After the reflection, the list of interviewees was confirmed, and the structure of interviewee template was formed.
In the next phase of the data collection, the expert interviews were held. Eight RPA expert interviews were held for gathering the data. All expert interviews were recorded in audio format for transcription. In table 3, I present interview profiles and information about the length of each interview.
After the data collection, I moved to the analysis phase. First, I imported the transcribed data to a qualitative data analyzing software called Atlas.ti. All expert interviews were scanned through in order to found repeating themes of answers. Based on this phase the first coding scheme was defined. The first coding scheme was not the final version, but the final coding scheme of this study formed during several cycles of the analyzing phase. The final coding scheme of the expert interviews is presented in Appendix B. In the next section, I will introduce the findings from the analyzed data.
Research Methodology
Table 3: The details of the interviews
Length (min)
Interviewee Title Responsibilities
56 | A | Lead of Spoke RPA CoE | Leading business domain's RPA CoE |
91 | B | Business Development Manager of RPA | An RPA developer, An RPA solution architect, A member of Spoke CoE |
68 | C | Head of Robotic Services | The owner of the RPA development & maintenance phase, A member of Spoke CoE |
97 | D | Group Manager of RPA Analyst Team | The owner of the RPA analyzing phase, A member of Spoke CoE |
32 | E | Senior Business Manager of RPA | Spreading RPA to external customers |
44 | F | Business Development Manager of RPA | An RPA analyst, A member of Spoke CoE |
56 | G | Program Manager of RPA | Leading RPA program at the group level |
54 | H | Head of Customer and Order Management in IT | IT functions in RPA, A member of Spoke CoE |
4 Findings
This section introduces findings from the data analysis phase. The first part of the section describes the journey of RPA in the case company from the beginning to the present state. In the second part, I go deeply through the findings from the expert interviews. The entirety of the findings section aims to give information for answering the following research questions:
• How does the federated governance model affect the implementation and maintenance of software robots?
• What kind of practices does the case company build for tackling potential challenges in consequence of the federated governance model?
The description of RPA in the company is based on the expert interviews and data available on the company's intranet. The first part is necessary because this thesis explores the implications of the federated governance structure on RPA functionalities and tries to give insight into optimal RPA governance. In addition, the description helps the reader to perceive the formation of RPA in the company that the second part of findings is more easily interpretable.
After the first part, I present the findings from the expert interviews. This part: deepens the perception of RPA as a technology, highlight advantages and challenges of the chosen RPA governance and practices to overcome challenges, and introduces experts' understanding of the existence of work and building systems.
4.1 Description of RPA in a Case Company
The company has utilized RPA for several years. The first pioneers brought software robotics into their own processes to facilitate their daily work. The concept started to expand at country level after justified positive impacts on process development. Next, the business domain of Finland reported significant qualitative increases in processes and great cost savings due to RPA activities. In 2017, the business domain had a financial goal of creating millions of cost savings by RPA and it succeeded to achieve it and even exceeded the goal.
In consequence of country-level successes, the concept began to extend at the group level. The company began to search a suitable RPA partner and planned a shared RPA tool at the group level. One of the business domains had already started their RPA activities with Blue Prism RPA tool and the group had used the same tool in a proof of concept for group's financial services. Thus, it was an easy decision for a shared RPA tool. Then, the group searched the best RPA partner for utilizing Blue Prism tool in the company. Currently, the company considers the most generative method to lead RPA in all business domains.
4.1.1 Federated RPA Governance
At the current institutionalizing phase of RPA, the company has decided to operate with the federated governance model. The model lies between extreme governance alternatives of centralized and decentralized and can be considered as a hybrid model. In the federated RPA governance model, a part of functions is executed centralized, but it sustains a strong local capability.
In the federated governance model for RPA, the company centralized Blue Prism platform because it assumes to achieve synergies by a shared platform. The potential synergies can be categorized into two groups, managerial and size synergies. The first managerial synergy regards platform operations and maintenance. The group believes that it can maintain the platform more efficient and with higher quality. The second potential managerial synergy is a result of a common RPA library. All the business domains can reuse created RPA components and elements from the library when the platform is shared. The third potential managerial synergy would be achieved through centralized technology training when the group can offer high-quality training for all the business domains. The last potential managerial synergy is RPA tool license optimization. The group supposes that it can optimize the use of licenses when it controls all the software robot licenses.
Potential size synergies relate to license and supplier management. The group assumes to achieve cost benefit with licenses when it negotiates as a group with the RPA tool provider. Another potential size synergy is connected with the supplier management. The group believes to get more power into negotiations with all suppliers and get better contracts.
While thinking the federated IT governance model for the concept of RPA more theoretically, the company has erected an analytically separated building system for enabling the concept, guiding business domains towards the common way of managing software robotics, and controlling and developing the RPA platform at the group level. In figure 4, the erected Hub-Spoke structure is presented. The building system is called as the hub of RPA CoE and it has positioned on the group level IT department farther the business domains' activities. Although the hub has a significant role in RPA activities, for example by allocating the RPA budget for software robot licenses and the platform to business domains, and offering the best-practice of RPA, every country has their own spoke of RPA CoE. The spoke is responsible for generating value by the technology and developing software robots in cooperation with business segments. However, the building system restricts all the business domains' RPA practices by keeping the right to implement a software robot into the production environment and it can only monitor the technical performance of digital workforce.
The WSLC model helps to figure out the situation (see figure 1.). An orderer of an RPA robot, typically a business segment, is responsible for the initiation phase of work system's change. The second phase, development, is realized by spoke CoE in close cooperation with the business segment. The hub is strongly involved in the last two phases, implementation and operation & maintenance. The hub implements digital workforce into the production environment, and maintenances and monitors the RPA platform where software robots lie. However, the business segment is the owner of the completed RPA robot and processes where the robot operates. Hence, the responsibility of the last phase is shared between the hub and the business segment.
|
| |||||||
Figure 4. Hub-Spoke Structure
4.2 Findings from the Expert Interviews
The second part of this section presents the key findings from the held eight expert interviews. All the interviews followed the same structure of question themes. Every interview began with a short background question set about interviewee's current position and connection with RPA. The first software robotics topic was RPA as a technology, its strengths and weaknesses, and practices to boost its success. After a more general discussion about RPA, the interview went ahead to the IT governance structure for RPA in the company. In this topic, the interviewees presented their insights on advantages and challenges in the current IT governance structure and practices to overcome these challenges. In the last topic, the interviews aimed to consider the IT governance from the more theoretical aspect in terms of building and work systems. The interviewees introduced their view of an analytically separated development system from a work system and its effect on the work system's development and functionalities.
All the topics covered in the interviews aimed to develop the understanding of RPA governance that utilizes the generative potential of it. The first RPA topic deepens the knowledge of RPA as a technology that should be taken into consideration in governance planning. The second RPA topic broadens the perception of RPA governance by considering the case company's approach. In the last topic, the empirical research strives for advancing the theoretical understanding of RPA governance with the theory of building and work systems.
4.2.1 RPA as a Technology
The first part of the interviews dealt with RPA characteristics generally and compared with more "traditional" IT. RPA was witnessed as a process development driven by business. The traditional IT is more technology-oriented and new IT components are realized through software engineering and do not need as close cooperation between IT and business than RPA development needs. Only a small share of RPA is about technology and it is not system development-oriented. However, the findings pointed out that similarities between both technology forms exist. In addition, software robotics was described as a change programme that requires the whole personnel involvement for success and the programme must begin before RPA implementation into a company.
Furthermore, the interviewees highlighted that RPA is a new automation element in the toolbox which utilizes other information systems via front-end. It should be used when other practices cannot develop processes, for example, IT-integration and business process re-engineering. The interviews raised also that RPA is the last option for process development.
Lastly, the interviews brought out other basic characteristics of RPA in the current maturity level. Companies do not have the first-mover advantage anymore and the concept has changed almost a business as usual. RPA contains more tactical investments than other automation tools and it is easier to execute than the more traditional IT. RPA is one way towards digitalization for companies.
The most emerged strengths were in line with previous research and material by consulting companies. RPA is agile and fast automation tool for process automation. In addition, the concept is cost-efficient. Companies can build automation solutions with small investments and the utility potential is bigger than with the more traditional automation tools.
When comparing to a human being, the software robot can operate 24/7 without coffee breaks at a high-quality level. The software robot's high-quality work has an effect on internal and external customers' satisfaction. The digital workforce makes fewer mistakes than human beings and the external customers get better service. Employees can focus on cognitive tasks instead of manual routine tasks. An ability to replace manual tasks and its influences on employees' well-being is a clear strength of RPA. As a result of easy understandable of RPA to all participants and its trendiness, the concept induces an in-depth study of processes all around the company.
The interviews raised also many weaknesses of RPA. The most emerged weakness of RPA was uncertainty about it. The uncertainty can be divided into two groups: how to use it and what is it. People do not know and understand, what kind of processes software robotics is suitable and optimal. At the process level, employees try to use the concept in all kind of processes without considering the current state of the process and what is the best solution for the process development. At the managerial level, managers budgeting unrealistic cost savings by RPA without considering realities and opportunities. In the second group, the weakness is uncertainty about the digital workforce. Because employees do not know what the software robot is and what the purpose of the concept is, it causes negative prejudice and the fear of losing a job.
Another weakness of RPA is attitudes towards it. As it has also mentioned in the existing literature (Lacity, Willcocks & Craig, 2015), the case company has noticed that IT departments' reactions against RPA have turned out challenging. IT departments do not see RPA as an automation tool among others and it is not experienced as a real IT. RPA considered being a plaster stacked on processes that have not been automated by the more traditional IT automation tools due to financial and temporal limitations. In consequence of strong resistance and low prioritization by IT departments, the speed of RPA deployment and the maturity level of the concept have suffered.
The third weakness of RPA regarding the concept management is business's involvement. A business segment is an ordered of a software robot and owns the software robot in the company after the development phase. The ownership and business unit's involvement sufficiently in the development of RPA is perceived as an important factor for success. Simultaneously, an understanding of the importance of business involvement in RPA development and in the digital workforce operation and maintenance phase is experienced a major threat.
The rest of weaknesses regarding more on RPA as a technology. The software robots need a constant monitoring and maintenance. The completed robots are vulnerable to failures due to changes in IT systems where they operate. Furthermore, RPA tools security features, ability to operate with high volume processes, and usability in complex processes were highlighted during interviews. The RPA tools do not currently include satisfactory information storing features of robots' activities. Hence, other tools must be utilized to fill that gap in order to meet European general data protection regulation (GDPR) -requirements.
The company has also had major challenges with RPA platform and IT infrastructure.
4.2.2 Advantages of the Federated Governance
After a more general discussion about RPA, the interviews moved on the theme of the current RPA governance in the company. The first part of the theme was advantages and challenges of the federated governance structure. All the respondents highlighted the advantage of knowledge sharing in the current governance structure. The hub of RPA CoE offers the best-practice of RPA for every business domain's RPA CoE. All the business domains can benchmark the offered best-practice against its own practices and develop its RPA function. In addition to benchmark side, the RPA function is easier to start in a new place when the hub offers a proof of value assessment to the new player. Hence, the offered proof encourages the extension of software robotics across the organization by supporting the implementation of the first RPA robot.
"The best-practice which the hub offers includes the best-practices for several functions of RPA for example, incident management, change management, problem management, configuration management, event management, request fulfillment, common platform templates, robotics playbook, development guidelines." (Interviewee G)
"The hub offers a proof of value assessment. We have packaged a fast start for RPA function, where will be implemented a unit-specific process scanning and the first RPA robot to the pre-production live proving environment as well as can start building the new spoke organization." (Interviewee G)
Another side of knowledge sharing is communication between the business domains' RPA CoE's where the hub acts as a facilitator. The federated governance structure has enabled the creation of RPA communities among the business domains. The RPA communities like development and process analyst communities encourage to learn from each other and solve common problems together. As a result of knowledge sharing by the created communities, every spoke CoE can benchmark its software robotics activities against other countries best-practices and find a better way to do for example RPA analyzing. The communities enhance also problem management when a communication channel includes all the key stakeholders from every country, the hub, and a couple of employees from the platform provider.
"The hub brings the best-practices that we can benchmark here in the spoke. Also, this structure enables common events for the exchange of views and the best-practices. I see that exchange of experiences is a clear benefit in this structure when we get a community that has same objectives and problems. (Interviewee E)
"The current governance structure offers a community where we have all RPA developers from each spoke, the hub representatives, and the platform provider representatives. This encourages knowledge sharing and problem-solving." (Interviewee A)
The second emerged advantage was economies of scale. The concern believes to get more power to negotiations with vendors by negotiating as a group, for example, lower RPA license prices and infrastructure costs, and better service level. The economies of scale stretch also to RPA platform operations and enable transparency between business domains' activities. The interviewees underlined that this structure emphasizes cost-efficiency by developing and maintaining the platform centralized, and optimizing RPA license usage centralized.
"The governance structure enables economies of scale on platform side: operations, license management, cost level, and gives a visibility to other countries' actions." (Interviewee C)
In addition, the current structure directs and supports the common way of the act at the group level and all kind of RPA considerations will be taken into account with a broader view. In other words, the governance structure supports the creation of the group level strategy. Furthermore, when all business domains use the same RPA tool, components and elements of the RPA robots from the common library can be reused between business domains. This would not be possible if all countries used different RPA tools. However, the reusability of software robots' components and elements has not produced the desired benefits, because every business domain's IT landscape differs radically.
"It is good that we can create a common strategy for RPA at the group level. We can utilize experiences of other countries when we have standardized approaches."
(Interviewee A)
"The common RPA usage enables, that we can reuse components across business domains. However, we have found only one component which has been used in another country." (Interviewee C)
"We have the common RPA library that every country can reuse components and elements, but every country has own IT legacies. No one cannot reuse components and elements made by another country." (Interviewee D)
Also, a decrease of responsibilities from the business domains turned out to an advantage of the current governance structure. The spokes did not have to build know-how of platform maintenance and the hub is responsible for discussions with platform and infrastructure vendors. The hub allocates also the budget for platform and licenses to the spokes, which raised as a supportive factor. The decrease of responsibilities releases more time to value creative actions by the business domains which accelerates the deployment of software robots.
Furthermore, the maintenance of software robots and platform, and the control of defined quality level in the RPA platform were seen as beneficial. Some of the respondents argued that the level of quality will be higher when the hub controls inputs into RPA platform. In addition to above mentioned, a part of respondents highlighted that the change management of IT is at best level when it is well controlled and structured. Hence, it is justified that the hub controls the maintenance of software robots and RPA platform, and owns the right to implement software robots into the production environment.
"Change Management is at best when it is well controlled, and we make a clear process for it." (Interviewee G)
The last advantages that emerged during interviews were enough level of autonomy, a platform development, and the building of IT infrastructure for RPA. The federated governance model enables the value creation of RPA for business domains. The spokes can autonomously choice the processes where they utilize software robotics. The group has not the required local knowledge of processes and IT legacies in the business domains to determine the best processes for automation. Hence, it is important that the business-case is at country level instead of group level because the spokes have the capability to find the best processes for software robots.
"Our business domains are significantly different. When we look at a single process, the execution of it variates a lot because every business domain has own IT landscape. Because we have the federated governance model for RPA, the value creation prioritization happens in a correct place, in the country in other words. The business-case lies in the country and it is a clear benefit in this governance model." (Interviewee G)
The structure has also supported the platform development when the hub has put a pressure on the vendor and some of the useful features have appeared as a result. Lastly, the hub has succeeded to build the separated IT infrastructure for RPA that accelerates firewall openings.
"The hub has developed the platform and succeed to add some useful features for the software robot development. In addition, it has also managed the communication with the platform provider and other vendors. The spokes do not need to manage the IT side of RPA, platform development and maintenance." (Interviewee B)
4.2.3 Challenges of the Federated Governance
The interviews emerged many advantages in the current governance structure, but a lot of challenges came out also. All the respondents told that the hub has had technical challenges with the platform and it has not been able to solve problems with enough speed. These technical challenges have related to the building of the common RPA production environment and it can be stated an existence of major infrastructure challenges. Moreover, the hub's capability to respond enough quickly to the spokes' requests has been a challenge at the operative level. The spoke of Finland is worried about its capabilities to respond business segments' service requests for developing RPA robots if the hub's activities are too slow. Another fear regards to the maintenance phase if some component of RPA robot needs to be modified in a cooperation of the hub and the spoke. Due to slowness by the hub, the spoke of Finland is uncertain how to respond to service level agreements between it and a business segment.
"The hub's response time has been a problem regarding the robots' production environment. The spoke has responded to the hub's request in few hours, but the hub has responded in a couple of days." (Interviewee A)
In addition, the current governance structure proved to be inflexible and complex for the development of software robots. The first phases of RPA robot's development are currently working well on the development servers, but a movement from the development phase to the implementation phase has experienced inflexible and complex. The rights of spoke's RPA developer have restricted in testing servers and they cannot test the robot's functionalities. As a result of restrictions, the RPA robot has to be moved between the spoke and the hub several times before the implementation to the production environment. This restriction currently damages the agility and speed of RPA because the development and implementation of software robot take much longer. Furthermore, the right restrictions cause additional planning for the spoke's developers because they do not see what software robots and server the hub schedules.
"The spoke's RPA developers cannot test RPA robots in the preproduction environment. We always need to ask the hub to test our RPA robot. Then the hub informs that something needs to be modified in the RPA robot and we can fix it in a couple of hours. After that, we wait days that we can test it again. We have definitely challenges in the software robot's development process." (Interviewee C)
"At the moment, we do not see which server the hub takes and which robot it schedules. We have had to design our processes that it works with every robot and server. We need to request all the user ID's for every robot because we do not know what robot the hub schedules. We need to plan a lot of extra" (Interviewee B)
Other commonly raised challenges related to a lack of cooperation between key stakeholders, and unclear responsibilities and roles. Communication and collaboration between the hub and the spokes have not been sufficient and it has weakened the RPA robots' development and solving technical problems. In some cases, the hub and the spoke do duplicate work in the robots' development due to lack of communication and collaboration. Another side is that the hub and the spoke have not enough time to solve technical problems together which slows down the development of the concept.
"The lack of communication is a big challenge. In some cases, the hub has tested the same robot for five weeks after us, but we have already made the same tests."
(Interviewee F)
"At the moment the hub can serve poorly local technical needs. We tried to tackle this with a technical meeting, but we have succeeded to organize two meetings of 20 attempts. (Interviewee H)
The development of the whole concept has suffered from unclear responsibilities and roles. Participants do not know clearly what their roles and responsibilities are, and that causes confusion which leads to no-one takes the responsibility. In addition, the findings raised a problem regarding local IT involvement. Currently, the local IT does not involve sufficiently in RPA functionalities and RPA developers have to focus on traditional IT infrastructure planning, support, and security issues that could be executed more efficiently in the local IT.
"Nowadays roles and responsibilities are at better level. Previously, there were not clear responsibilities and roles between local IT and the hub which lead to the omission of tasks." (Interviewee A)
Moreover, the standardized RPA platform induces slowness in the development of software robotics. When the hub plans to change and bring some new elements to the golden image, the centralized virtual desktop infrastructure for the RPA robot development, for matching spokes' needs, all the RPA environments have to be tested in addition to tests against completed RPA robots. The standardized RPA platform complicates the company's ability to respond to local requirements. In addition, the standardized platform complicates the work of RPA developer as a result of a messy environment. The developers do not see the advantage of seeing all the components and elements across the business domains because the IT landscape differs significantly among countries.
"A concrete example about the standardized and common platform comes from a Golden Image change. When it is planned, it causes a big test episode in the development, the preproduction, and the product environment, and tests of completed robots. It takes a lot of time." (Interviewee C)
"I do not see a benefit that the development environment includes all the RPA components and elements of every business domain. It is very chaotic. In addition, this has caused unexpected challenges when local IT change has impacted on other country's RPA robot's functionality and it has stopped its tasks." (Interviewee B)
The last highlighted disadvantage of the governance model concerning centralized RPA training. The hub enables common RPA training to all the business domains. In this solution, the group has outsourced the RPA training to third-party, which provides noncustomer specified RPA training. Thus, the outsourced training fails to fit the company's context and does not provide enough extensive and detailed RPA training.
4.2.4 Practices to Mitigate Challenges in the Federated Governance
The last part of the governance theme was practices to mitigate the challenges of the federated governance model. Most of the practices are already in use, but the usage level of some must be sharpened. The most highlighted practice was increasing cooperation among the key stakeholders. The company has already launched temporary daily calls where the hub and the spokes discuss the daily situation of software robots' implementations, schedules, and queuing times. The temporary arrangement aims to tackle the problem of the hub's slow reaction on service requests. In the development of software robots, the importance of different communication and problem ticketing tools must be emphasized that the development process will be more transparent for all participants. This practice has already started, but the usage level of the common communication and ticketing tools is not at relevant level.
"At the moment, we have a temporary daily call solution because the hub has not succeeded to respond to service level agreements. This is a call where we handle the current situation, schedule, and queuing times. This is not a permanent practice. We have several communication and ticketing tools that should be used for communication and problem management." (Interviewee B)
"We have planned the usage of common problem ticketing system as a communication system also. We store all the relevant information there that everyone sees what has been agreed. It is one of the practices that we should use actively." (Interviewee A)
"We use the common problem ticketing system already. But we have not understood, how broadly we should use it." (Interviewee H)
In addition to the above-mentioned practices to accelerate collaboration, the spoke of Finland has tried to involve the local IT department more in the RPA development by engaging information system manager (ISM) into all starting meetings of RPA robots' development projects. However, a worry about business involvement sufficiently in the RPA concept development highlighted during interviews. It is important that the business determines the direction of development in order to avoid that RPA becomes a technology exercise. The case company should find tools for ensuring sufficient participation of business and local IT in the RPA development and daily operations that software robotics would remain business-driven, and the maintenance of software robots would be efficient.
"We have to keep RPA business-driven. How we involve the representatives of business in the RPA development all the time, that it will not become a technology practice?
Technology gets continuously too much importance in RPA in my opinion." (Interviewee C)
Furthermore, the hub's role, responsibilities, and collaboration with the spokes was one of the big topics during interviews. The hub already acts as a facilitator for collaboration of the spokes and it should continue that facilitative act in order to deepen the collaboration between the spokes which lead to knowledge sharing. The hub takes a responsibility for offering the best-practices at the moment and it should implement the very best-practices into the spokes. The fluency of collaboration between the hub and the spokes should be sharpened that overlapping work will be scaled down and the software robot's development process will be less heavy.
"The importance of communication will be emphasized. The responsibility for scheduling and other elements of software robots remains the spoke's developers. Their tasks should be in good control and they should be informed of important things because the spoke's developers instruct the hub's employees to do tasks." (Interviewee F)
In addition, the clear structure of responsibilities and roles in RPA was also one of the practices that the company has already used, but it should not stop at this moment. At the beginning of the federated governance structure for RPA, roles and responsibilities were cryptic for every stakeholder and no one did not take responsibility for tasks. Hence, the organization sharpened the roles and responsibilities, and the division is currently clear. However, the interviewees highlighted that the current number of roles and people behind them is not enough in the near future. For example, the company does not have enough people for the controlling roles of RPA when the number of robots will increase in the production environment.
"At the moment, we have a sufficient number of people and roles. But we have to rethink what roles we need more when the maturity level of RPA advance. We cannot stop here. This is the optimum now, but not in the future." (Interviewee H)
As previously written, the participants of Finland's RPA spoke witnesses the current RPA robot's development inflexible and complex in addition to difficulties in the standardized platform development. Reducing the level of centralized control on the RPA platform turned out as a practice to mitigate this challenge. Some of the interviewees viewed that every spoke should have a right to test software robots in the test environment at least. Some viewed that the rights of spoke should extend to the production environment. Another aspect related to RPA platform infrastructure. The development of RPA tool in order to match local requirements would be easier if every country had own RPA Golden Image. When there existed a local need for change in the Golden Image, it would not need to be accepted in all countries.
"In the next step, I wish that every business domain will have own Golden Image. The spoke would request features to its own Golden Image and it would not be installed to everyone." (Interviewee B)
The last practices related to the hub's resources and pressure on it, and a creation of a clear problem management process at the group level. The spoke of Finland has experienced that the hub does not have enough resources for the maintenance of software robots and the platform development. A part of interviewees highlighted that the hub must increase their resources or prioritize resources time more on RPA. Putting more pressure on the hub expressed as a practice to mitigate the spoke's challenges. The spoke needs to require better service level from the hub, that they can meet requirements of local needs. In addition, the building of the clear problem management process of RPA robots at group level experienced as a tool for developing the current situation. The problem management process needs clarifications to problem ticketing systems, and the relation map of RPA robots and IT systems where they operate. If the company succeeded to organize clear problem management process at the group level, it would make the problem management process agiler.
"At the moment, we do not have in-depth problem management process for RPA. It would be important that we get a common view of robot's lifecycle from a problem ticket. We have had plans for the problem management at the group level, but there are still open points." (Interviewee B)
"The spoke should make more structured requirements to the hub and ensure that those are understood correctly, and constantly build cooperation aggressively.
(Interviewee F)
4.2.5 Findings of Work and Building System.
Lastly, the interviews moved on the more theoretic theme of work and building systems. The theme emerged the most challenging to understand and give answers, and conceptions of the theory variated greatly. All the interviewees that responded questions regarding this theme stated that these systems can be analytically separated, and so the company has already done during its history. It has even separated these systems on a large scale by locating the building system concretely far away from the work system. The biggest share of respondents that comprehended the building system as a system which contains components such actors, structure, technology and tasks, and which is responsible for actual development work and plans, should lie close of a work system. The claim was justified based on the interviewee's personal experience during their working career in the company. When the company has tried to locate the building system into another country which takes full responsibility for the whole work system's development, results have been poor.
"We have tried to locate a building system in another country. It did not go well. They did not understand local requirements and did not react on critical issues, because those were not critical from their point of view. I guess that it was also a result of low prioritizing because the work system was so far away. It can be a mental issue or lack of local knowledge, for example, incapable to understand a deeper local infrastructure." (Interviewee B)
However, some of the respondents experienced the separation of the building and work system worthwhile when a small share of the work system's development is separated into the building system. When finding appropriate parts of the work system's development for the building system's responsibility, it can bring speed and clarity to address the issues of uncertainty and complexity. In addition, the building system is seen as a temporary system, where a core is permanent. The building system is erected when the work system needs a revolutionary development step. Nevertheless, the work system should be strongly involved in the development.
"A building system can bring speed and clarity to issues, and everything is not connected among themselves. It is possible to clarify and share responsibilities much smarter. Otherwise, work systems are too complex to understand. The separated building system is enabling the understanding of a whole complex of issues." (Interviewee C)
One view of the theory differed considerably from others. In this view, the work and building systems are different versions of the same system. The work system is separated organism which can promote its current state. If it wanted that development goes on the side of the work system's daily activities, the separated building system can be used for it.
"I think that a building system is a different version of a work system. But before the building system succeeds in defining the needs of the work system there might exist a gap between these systems." (Interviewee F)
Furthermore, this theme raised challenges and advantages due to the separation of these systems. The first challenge is the building system's capability to meet the work system's requirements and needs. Interviewees were skeptical that the building system has enough knowledge about the work system's components like IT and processes. Because of that deficiency, the development may head in the wrong direction and the company would lose a local view. Motivation challenges were the second downside. This downside includes motivation challenges in both systems. As mentioned earlier, the building system may have motivation and prioritization challenges because its actors are not necessarily participants in the work system. At the same time, the participants of the work system may be unmotivated to bring out their expertise regarding the work system's development if they are not fully responsible for it.
"Could a building system develop a work system towards right direction without a strong local knowledge? In my opinion, the analytically separated building system removes the local knowledge." (Interviewee A)
"Because of the existence of a building system, work system's experts do not express their expertise. They only bring out the work system's problem, but do not tell a solution even though they already know it." (Interviewee H)
The rest challenges of the separated building system were stiffness and communication challenges. The systems' separation highlighted to increase stiffness and slowness in the work system's development. In addition, interviewees argued that sufficient communication between the systems would be challenging and cause a gap in the definition of needs.
"This kind of system separation usually creates inflexibility and slowness." (Interviewee C)
"First, can we define the needs of a work system from a building system? Alternatively, communication and information from the work system to the building system would be challenging" (Interviewee F)
In addition to the challenges, the interviews emerged three advantages of the systems' separation. At first, the ability to lead on a big scale experienced beneficial. The building system can think outside the box easier and it may develop the work system towards better form in long term. It would be able to consider better the development of the whole market, thus notice that the work system will not fall behind the general development. Secondly, the building system's ability to address the issues of complexity, and uncertainty due to its nature of unbundled entity raised as an advantage. The third advantage was a decrease of risk and responsibilities from the work system. The interviewees highlighted that when the building system takes the responsibility of work system's development, the work system can better focus on its daily work and wait for the results from the building system.
"When we erect a separated building system which has a better market knowledge about RPA, it can develop a work system towards market's best-practice. It would be a significant pro." (Interviewee A)
5 Discussion
In this section, I strive to discuss the research findings and associate those with the existing research. Hence, all the possible inconsistencies between the findings and the current research, and novel findings that have not expressed in the existing research will be presented. This section aims to deepen the understanding of the findings section and simultaneously advance the current research.
The research gap in the current research field of RPA governance was discovered at the beginning of the thesis. As I earlier have mentioned, the case company currently searching the golden mean for RPA governance which empowers all the strengths of software robotics but simultaneously ensures controllability at the group level. In this study, I explore the chosen RPA governance of the case company and aim to gain insights on successful RPA governance in the company.
The findings from the expert interviews began with debating on RPA as a technology. The most emerged findings are aligned with the existing literature. Strengths like agile and fast, cost-efficient, ability to replace manual routine tasks, and qualitative influences raised during the interviews. Also, the most highlighted weaknesses such uncertainty about RPA, and attitudes towards digital workforce, did not cause inconsistency between the findings and the existing research. In addition, opinions about empowering practices did not bring any great revolutionary. However, some of the novel insights of RPA emerged during the interviews. For example, the RPA tools available on the market do not meet security requirements of the European general data protection regulation (GDPR). Moreover, the proper use of RPA and designing the use of it on a bigger scale emerged significant important practices to boost RPA.
The second theme of the findings, RPA governance, showed up novel insight into the existing research. This empirical research raised several advantages and challenges in the federated RPA governance structure that has not been studied in-depth in the current research. Furthermore, the empirical study presents many practices to mitigate challenges connected with the federated governance of the multinational company.
Lastly, the theoretical part of the findings advances the theory of work and building systems. This theory was chosen to describe the case company's federated governance structure for RPA. It was interesting to find out, how RPA experts experience this theory and how it differs from the current research. The findings were interesting and are not completely aligned with the current research. In the following chapters, I will discuss the findings more and its relation to the existing research.
5.1 RPA Governance
Willcoks, Lacity & Craig (2015/05, p.30-31) reported that RPA has successfully deployed in decentralized, federated, and centralized governance structures. Pros and cons of each approach were aligned with other existing literature (Lewis, 2004; Weill & Ross 2005). The decentralized governance for RPA has brought quick wins, but scalability across the enterprise is not possible, the imposition of corporate level standards is difficult, and the duplication of hardware infrastructure may result. The federated and decentralized structures included very similar advantages among themselves. The central and standard platform enables low cost, scalable automation solutions across the group, but the change and RPA delivery management disciplines can be problematic at the group level and resource bottlenecks may exist (Willcoks, Lacity & Craig, 2015/05, p.30-31).
Table 4: The federated governance structure: main advantages, challenges, and practices to mitigate challenges
The Federated Governance | ||
Main advantages | Main challenges | Main practices to mitigate challenges |
Knowledge sharing | Resource bottlenecks | Intensifying cooperation among the key stakeholders |
Economies of scale | Inflexible and complex RPA delivery and change management disciplines | Reducing the level of centralized control |
Strategical benefits | Challenges with the standardized shared platform | Creating clear responsibilities and roles |
The decrease of responsibility from business units | Lack of cooperation among stakeholders | Increasing resources at the corporate level CoE |
Enables scalable automation solutions across the group | Differences in IT landscape | The building of a clear problem management process at the group level |
Controllability | Unclear responsibilities and roles | Putting more pressure on the hub |
The research findings are mainly aligned with the above-mentioned findings from the existing literature. However, the study revealed novel advantages and disadvantages of the federated RPA governance. All the main advantages, challenges, and practices to mitigate challenges are presented in table 4. The biggest experienced novel advantage of the federated governance structure was knowledge sharing. The structure encourages knowledge sharing by creating RPA communities across business domains. The business domains can learn straight from each other and solve common problems together. Weill & Ross (2005 p.6) wrote about hybrid approach's characteristics in the following way: "Their IT principles emphasize sharing and reuse of processes, systems, technologies and data." Hence, the existing literature about governance models generally supports the finding of knowledge sharing but its significance as an advantage in RPA governance emphasized.
Economies of scale emerged as an advantage in the study as well in the current research (Lewis, 2004; Weill & Ross 2005). Weill & Ross (2005, p.8) research argued that the hybrid approach strives to use standardized shared services in situations where they can provide economies of scale. In the interviews, RPA experts viewed that the federated governance increases cost-efficiency and negotiation power by the centralized vendor and license management of the standardized platform that can be noticed for example, as a platform development and lower RPA license prices. However, the economies of scale in the centralized vendor and license management has not been justified yet, because the maturity level of RPA is still low. This advantage of the federated governance has been one of the top expected advantage of the group level management, but surprisingly it has not been realized on a large scale yet.
The common RPA tool between countries enables strategic unification and governing at the group level. In the decentralized approach, this may be difficult as Willcocks et al. (2015/05, p.30) argued: "standards can become fragmented and difficult to impose". When the platform is standardized, it will be aligned with the group's strategy and software robots' parts can be reused across countries as Willcoks, et al. (2015/05) mentioned:
"In a federated structure low cost, scalable automations across multiple operations functions can be achieved using a central and standard platform." Willcoks, Lacity & Craig (2015/05, p.30)
The above-mentioned advantage of scalable automations across business domains was also an expected advantage of the federated governance in the case company. Nevertheless, the expected advantage has not been realized at the level than the group has estimated. The spokes have noticed that there does not exist a synergy of reusing RPA robots' components across business domains because IT legacies differ radically among themselves. In addition, the shared-platform creates a chaos of useless components and elements in the development environment for RPA developers. In other words, the common RPA library is not useful across the business domains, but that is one of the main advantages of software robotics in the current research, for example, Everest Group (2018) wrote: "This scalability could come in the form of a centralized application server that can be duplicated for scaling up as well as features such as re-usability of robot parts, autonomous execution, and process orchestration to join parts of complex processes." However, some of the RPA platform's features have been succeeded to scale group-wide in the case company. So, the sharedplatform has created an advantage of scalable platform's features due to the centralized platform development instead of scalable RPA robots' components and elements across the business domains.
The clear advantage of the federated governance compared to the centralized option is its better capability to react to local needs (Lewis, 2004; Weill & Ross 2005). Also, this advantage raised during interviews while business domains are responsible for the value creation of RPA by creating business-cases. The group does not feel sensible to define business-cases because it does not have enough local knowledge about processes. Furthermore, the interviewees pointed out that the centralized platform enhances the quality of its contents and maintenance of it. However, the chosen governance model and the sharedplatform have induced challenges and those are mainly aligned with the existing research.
As it has discovered in the existing research (Willcoks, Lacity & Craig, 2015/05, p.3031), this study's findings emphasize same challenges of the federated RPA governance related to change and RPA delivery management disciplines and formed bottlenecks can be noticed in the group level CoE. The federated model has not operated with enough speed to match local requirements, and the software robots' change and delivery management has been inflexible and complex. The findings raised reasons for the slowness of the group CoE that were significant technical challenges with the common RPA production environment, and lack of resources and prioritization in the group CoE. The software robots' change and delivery management is currently complex, and participants do duplicate work and do not know their responsibilities that slows down the process. One noticed challenge which partly explains this is a lack of cooperation among stakeholders.
Moreover, the centralized RPA maintenance cannot take the responsibility for robots' component and element changes, because its participants do not know enough about local systems and processes where the robots operate. A tentative plan was to handle the RPA maintenance and the infrastructure building from the hub CoE but an involvement of the spokes has been essential and it has impacted negatively on the spokes' RPA developers' daily input into the software robots' development. When comparing the case company's way to organize the software robots' delivery and change management with Lewis's (2005) perception of hybrid approach, an inconsistency can be found regarding centralized and decentralized functions.
"It uses a shared-services group to centralize functions that benefit from economies of scale and don't have to be highly agile. And it decentralizes functions that are close to the customer and have to be responsive to fast-changing market conditions and business-unit strategies." Lewis (2005, p.2)
Because the software robots' delivery and change management have caused challenges, it is not surprising that intensification cooperation among key stakeholders, reducing the level of centralized control, increasing resources in the bottlenecks, and building of a clear problem management process at group level seemed main practices to mitigate challenges. The findings highlight that all the practices above advance the agility of RPA activities that should be agile in order to fit into business domain's strategy.
Also, Forrester Consulting (2017) reported the difficulties in controlling and operating software robots when the split of control between IT and the business is unclear and delivering RPA robots causes challenges. The findings pointed out that the view of controlling and operating software robots includes inconsistency between current RPA marketing and experienced IT-managers:
"When discussing with experienced IT-managers about controlling and operating software robots, no one else should not have access to the production environment than administrators. Sooner or later someone makes a big mistake, and massive costs result. We have thought that the production environment is under centralized control, and our best experts administrate it. This is highly inconsistent with RPA marketing which argues that business segments can do whatever they want, but software robotics should be an enterprise level solution simultaneously. Enterprise level IT-managers are very skeptical about giving extensive rights to people that are not IT experts." (Interviewee G)
As it has already emerged from the study, the cooperation between the key stakeholders has experienced significant challenging for the governance structure. The current research has highlighted the importance of IT department involvement in the RPA development (Lacity, Willcocks & Craig, 2015), but the case company has not succeeded in the buy-in of local IT departments at the desired level. As a result, local IT does not take enough role of the traditional IT tasks and it hinders the development of RPA. This challenge was not expected at this level in the case company and the finding underlines the existence of the stakeholder buy-in risk for the current research, which was also pointed out in Hindle et al. (2018) research.
In addition, the informants underlined a challenge with the centralized RPA platform that the existing literature and consulting reports have not emphasized. The group's standardized platform has hindered the development of business domain's RPA results when desired changes to platform features have not implemented by the group. Moreover, some unexpected implications on RPA functionalities due to the shared platform have emerged. For example, a change on local IT legacy has impacted on other country's RPA robot's activities and has stopped the robot's operation. Both of these implications are totally novel for the current research of software robotics and unexpected for the case company also.
Weill & Ross (2005, p.6) argued that hybrid approaches introduce new governance mechanisms that balance between corporate-wide and local control. A couple of novel approaches to mitigate challenges with a shared platform emerged in the study that is aligned with the above citation. The findings raised that multitenancy could be a lighter solution to decrease challenges with the standardized platform. In this solution, a company and platform provider erect multiple independent instances in a shared platform that are logically isolated but physically integrated. The logic isolation will be by business domain in this situation. A heavier practice to mitigate challenges with the centralized platform could be erecting multiple Golden Images by business domain. Every business domain would have own virtual machine for RPA development which includes only the country-specific IT legacies. As a result, configuration changes to match local needs could be done without comparison across all the business domains.
"If we got own Golden Image into the spoke, it would help us. We can build countryspecific virtual servers. Our Golden Image would include our IT legacies and other Golden Images other countries'. We could make configuration changes much faster and simpler when there is no need to observe systems in other countries." (Interviewee B)
Lastly, the interviews raised that the centralized RPA training offered by the hub has not brought an expected advantage. The hub has outsourced the RPA training to third-party, which provides a more generally RPA training regarding, for example, developing, and analyzing. The centralized training is not customer specified, thus it cannot familiarize participants with the chosen training field at the required level. In addition, the centralized training has experienced expensive and the tempo of the training is too fast. Hence, the business domains have provided own RPA training that fit better into the company's context, is less expensive, and the quality of the training is better.
Regardless of several challenges in the federated RPA governance, the interviews highlighted that the federated RPA governance could be a successful structure with several development activities, even though it cannot probably get synergies from reusing of software robot's components and elements across countries. Currently, the federated governance structure partially fails in reacting to local needs, which is listed as an advantage of the hybrid approach in the existing literature (Lewis, 2004; Weill & Ross 2005). All the informants perceived that a fully centralized governance is not an option. Based on the findings this is strongly justified and also, Pegasystems (2018) recommend a federated option instead of centralized when there exist distinct objectives by country.
"When there are very distinct objectives by line of business or by geography, we often find that what works well is a central, corporate level COE that supports several individual
COEs." (Pegasystems, 2018)
5.2 Work System and Building System
In the existing research, work systems are described with properties of high complexity and low malleability that evolve continuously by incremental or episodic changes (Alter, 2001, p.17). Lyytinen & Newman (2008, p.4) argued that an analytically separated building system needs to be erected in order to take the responsibility for executing the change of the high complexity and low malleability work systems and addressing the issues of uncertainty. The study emerged that the building system can be analytically separated in space and time, but enormous gaps between systems are probable. In addition, the findings pointed out that the forming of these systems functionality has happened though political struggle during the company's history. Hence, the finding is completely aligned with Bloomfield & Vurdubakis (1994) claim that boundaries between these systems are drawn through a political struggle which defines the rights, responsibilities, and roles of each component.
The interviewees cannot recommend the analytically separated building system which takes the full responsibility of change in the work system based on their own experience. However, the findings pointed out that small shares of the responsibility for the work system's change can be sensible to locate in the building system. In addition, the study highlighted that this model utilization on a bigger scale can be suitable for different kind of companies and industries where the local knowledge is not crucial for the development. Hence, the findings are inconsistent with Lyytinen & Newman (2008) in the case company, but it would efficient in another environment.
"Therefore, an analytically separate system called the building system needs to be erected. This building system commands a set of resources and enacts routines to carry out the change and address the issues of uncertainty, ambiguity, and complexity. To do so it needs wield power to overcome resistance, to obtain resources, and to legitimize the change." Lyytinen & Newman (2008, p.4)
The most emerged challenge in the separation of these systems was incapability to meet local requirements. Arguments for this claim based on the evolved gaps if these systems are separated. In the company, a geographical dispersion is not significant, but a functional differentiation and specialization variate substantially. All the countries have their own IT landscape and processes; hence the building system cannot meet local requirements if it separated in time and place. Furthermore, the findings raised that the building system's actors are not suitable for the tasks if they do not have enough local knowledge. The findings were aligned with Lyytinen & Newman (2008, p.8) who listed functional differentiation and specialization as a property of structure component that could create a gap between structure and task. Also, the task-actors gap due to the incompetence of actors was aligned with the current research.
Second, the motivation gap between the systems raised from the findings. The work system's participants may be unmotivated to cooperate with the building system as a result of a complete transfer of responsibility to the building system's actors or unwillingness to accept the structure. Lyytinen & Newman (2008, p.8) presented this potential actor-structure gap in the following way: "Actors do not know the operating procedures, do not accept the structure, or are not aligned adequately with the structure."
Third, the interviews underlined that the separated building system brings stiffness and slowness to the development of the work systems and it can be even a useless intermediary. The description of useless intermediary was novel for the building system when comparing the finding with the existing research. Lyytinen & Newman (2008, p.4) wrote that the building and work systems are constantly interacting. However, the findings pointed out that a communication gap between systems' actors seemed as a great challenge in this kind of structure.
The last gap mentioned during the interviews related to building and work system from the aspect of RPA. At the moment, the current structure experienced to be unsuitable for taking advantage of the technology capabilities. The level of centralization, level and span of control, and allocation of rights and duties restrict the development of maturity level.
Thus, this finding is supported by the prior research and the finding is an example of a potential structure-technology gap.
"Structure-technology: The structure is not aligned with the technology and does not support technology operations and use. Structure does not take advantage of the capabilities of the technology." Lyytinen & Newman (2008, p.9)
The findings confirm the existence of the analytically separated building system in time and place. However, the findings are not aligned with Lyytinen & Newman (2008, p.4.) claim that it should be erected. Lyytinen & Newman (2008, p.4) described that the building system is responsible for the implementation of episodic changes in a work system when the gap exists in the work system. They stated a gap in the following way:
A gap is any contingency in the system which, if left unattended, will reduce the system's performance and threaten its viability. Lyytinen & Newman (2008, p.7)
This study provides novel insights on the understanding of the building and work systems coexistence and the gap description. The findings underline that the development of work systems should be located as close as possible and preferably in the system itself. The building system constantly fails to fix unworkable components that cause a gap in the work system and between the systems when there exists the analytically separated building system which is significantly separated in space and time in an organization. Lyytinen & Newman (2008) handle the gap mainly from the aspect of a gap in the system, but this study underlines that the gap is more likely to emerge between the systems. Hence the prior gap description can be modified in the following way: "A gap is any contingency between the systems or inside it which, if left unattended, will reduce the system's performance and threaten its viability."
6 Conclusions
This study aimed to answer the following research questions:
• How does the federated governance model affect the implementation and maintenance of software robots?
• What kind of practices does the case company build for tackling potential challenges in consequence of the federated governance model?
Theoretical background of this study was formed with three main elements, the work system theory, IT governance, and RPA. The work system theory described how companies realize systematically information related work. The governance approaches of centralization, decentralization, and hybrid described IT governance alternatives that the chosen governance approach of the case company can be explored. In RPA description, I introduced the characteristics of the automation tool and its short history that the concept can be studied.
I executed the qualitative case study by the eight expert interviews in the multinational ICT company which utilizes RPA in internal processes and acts also as an RPA provider. In these interviews, I explored the company's way to govern software robotics and the chosen governance model's opportunities and challenges. In addition, I searched how the company is going to tackle potential challenges of the federated governance structure. As a result, I found several advantages and disadvantages of the chosen governance structure and practices to mitigate potential challenges of it. Hence, I was able to answer the research questions.
From a managerial perspective, this study provides insights into managing RPA as a business-driven automation tool by the federated governance model. Theoretical implications include novel insights into the prior research of RPA governance and the work system theory.
6.1 Managerial Implications
The study provided an overview of RPA in the multinational ICT company and insights into governing software robotics by the federated governance model. Hence, it produced plenty of information about the federated governance for RPA in the case company.
This study highlighted several advantages and challenges of the federated governance model, and practices to mitigate these challenges. Thus, the study provides important information about the current situation and suggestions for managing software robotics. For the management of the company, the study provided insights, how to govern software robots' delivery and change management, and preserving its strengths as a technology and maximize the generative potential of the technology.
RPA brings considerable similar possibilities and threats as a technology regardless of company's size or industry (Hindle, et al., 2018). Hence, the research results can be utilized in other companies and industries too, although the study was realized by a qualitative case study in a multinational ICT company. The results are the most beneficial in organizations that are planning to govern RPA by the federated governance. Companies can learn about the potential challenges and possibilities of the federated governance and RPA as a technology from the study.
6.2 Theoretical Implications
The study aimed to provide insights into a research gap in the research field of RPA governance. As Bygstad (2016) stated, the prior research does not provide a generalizable approach to govern software robotics and suggested an avenue of future research in the field of RPA governance. The theories of work system and IT governance in the context of software robotics has been utilized in this study. The ultimate goal was to give novel insights into RPA governance by utilizing these theories.
This study provided novel insights into the research gap in the research field of RPA governance. Research findings amplified the prior findings of the federated governance and produced novel insights into characteristics of the governance approach. In addition, the study provided novel insights into the work system theory, especially into the management of episodic changes of work systems. This research takes a stand, how a change of work system should be governed and what is a role of a building system in a change. Furthermore, novel insights into the prior research of systems' gap (Lyytinen & Newman, 2008) emerged from the research findings. The results underlined that the gap is more likely to arise between the systems instead of inside the system. Hence, the study provided the modified definition for the systems' gap: "A gap is any contingency between the systems or inside it which, if left unattended, will reduce the system's performance and threaten its viability."
6.3 Limitations and Avenues for Further Research
This study has some limitations that should be taken into account. The chosen research method explores the implications of the selected federated governance model on the software robots' deployment and maintenance, and practices that the case company currently utilizes and should utilize in order to mitigate challenges of the chosen governance structure. However, the study does not take a stand on the other governance models' suitability for RPA governance, for example, the extreme governance approaches of centralized and decentralized. Furthermore, the study explores only one case company that has specialized in ICT industry and its IT landscape differs significantly across business domains. Hence, the research findings are not completely generalizable to concern other companies, industries. Furthermore, this study does not take a stand which governance model suits the best for the needs of software robotics.
Lastly, I suggest some avenues of future research. Because this study limited to one case company only that has chosen the federated governance approach for RPA governance, it could be beneficial to explore the decentralized and centralized approaches suitability for RPA in the future research. The examination of both extreme approaches could develop the knowledge of suitable governance for RPA among different kind of companies and industries. In addition, it emerged that there exists an inconsistency between experienced enterprise level IT-managers and current RPA marketing about the level of control in the RPA robots' deployment and change management. The future research would explore different control levels that the inconsistency could be solved.
References
Asatiani, A., & Penttinen, E. (2016). Turning robotic process automation into commercial success - Case OpusCapita. Journal of Information Technology Teaching Cases, 6(2), 67–74.
Accenture. (2018). Robotic Process Automation: The future of technology in financial services. Online. Available at: https://www.accenture.com/no-en/insight-financialservices-robotic-process-automation [29.1.2018]
Alter, S. (2001). Which Life Cycle--Work System, Information System, or Software? Communications of the Association for Information Systems, 7(1), 17.
Alter, S. (2002). The Work System Method for Understanding Information Systems and Information Systems Research. Communications of the Association for Information Systems, 9(September), 90–104.
Alter, S. (2008). Service system fundamentals: Work system, value chain, and life cycle. IBM Systems Journal, 47(1), 71–85.
Alter, S. (2013). Work System Theory: Overview of Core Concepts, Extensions, and Challenges for the Future Work System Theory: Overview of Core Concepts, Extensions, and Challenges for the Future. Journal of the Association for Information Systems, 14(February), 72.
Bevir, M. (2012). Governance: A very short introduction. Oxford. Oxford. 131 p.
Bloomfield, B., Vurdubakis, T. (1994) Boundary Disputes: Negotiating the Boundary between the Technical and the Social in the Development of IT Systems, Information Technology & People, 7(1), 9–24.
Brown, A. E., & Grant, G. G. (2005). Framing the Frameworks: a Review of It Governance Research. Communications of the Association for Information Systems, 15(May), 696– 712.
Bygstad, B. (2016). Generative innovation: A comparison of lightweight and heavyweight IT. Journal of Information Technology, 32(2), 180–193.
Cummings, S. (1995). Centralization and decentralization: The neverending story of separation and betrayal. Scandinavian Journal of Management, 11(2), 103–117.
Edwards, C. (1984). Information Systems Maintenance: An Integrated Perspective. MIS Quarterly, 8(4), 237.
Everest Group. (2018). Defining Enterprise RPA. Everest Group Research.
Forrester Consulting. (2017). The New Frontier Of Automation : Enterprise RPA. Forrester Consulting Thought Leadership Paper Commissioned by UiPath.
Galletta A. (2013). Mastering the Semi-Structured Interview and Beyond: From Research Design to Analysis and Publication. NYU Press. New York. 258 p.
Glaser, B. G., & Strauss, A. (1967). The discovery of grounded theory: Strategies for qualitative research. Aldine. Chicago. 271 p.
Hindle, J., Lacity, M., Willcocks, L., Khan, S. (2018). Robotic Process Automation: Benchmarking the Client Experience. Knowledge Capital Partners.
Lacity, M. and Willcocks, L. (2015). What Knowledge Workers Stand to Gain from Automation, Harvard Business Review.
Lacity, M., Willcocks, L., & Craig, A. (2015). Robotic process automation at telefónica O2. MIS Quarterly Executive, 15(1), 21–35.
Lyytinen, K., & Newman, M. (2008). Explaining information systems change: A punctuated socio-technical change model. European Journal of Information Systems, 17(6), 589– 613.
Lewis, D. (2004). Stop THE PENDULUM! Computerworld, 38(2), 37–38.
McCarthy, I., & Anagnostou, A. (2004). The impact of outsourcing on the transaction costs and boundaries of manufacturing. International Journal of Production Economics, 88(1), 61–71.
McNaughton, B., Ray, P., & Lewis, L. (2010). Designing an evaluation framework for IT service management. Information and Management, 47(4), 219–225.
Miles, J., Gilbert, P. (2005). A Handbook of Research Methods for Clinical and Health Psychology. Oxford University. Oxford. 328 p.
Mohapatra, S. (2013). Business Process Reengineering. Springer. New York. 254 p.
Orlikowski, W. J. (1992). The Duality of Technology: Rethinking the Concept of Technology in Organizations. Organization Science, 3(3), 398–427.
Pegasystems. (2018). Coe Structure, Roles, & Responsibilities. Online. Available at:
https://www.pega.com/insights/centers-of-excellence/structure-roles-responsibilities
(2.5.2018)
Punch, K. F. (1998). Introduction to Social Research: Quantitative and Qualitative Approaches. Thousand Oaks, CA: Sage Publications. London. 320 p.
Slaby, J. R., & Fersht, P. (2012). Robotic automation emerges as a threat to traditional lowcost outsourcing. HfS Research, 1–19.
Taylor, S. J., Bogdan, R., & DeVault, M. (2015). Introduction to qualitative research methods: a guidebook and resource. Wiley. New Jersey. 416 p.
Tornbohm C. (2016). Robotic Process Automation: Eight Guidelines for Effective Results.
Online. Available at: https://www.gartner.com/doc/reprints?id=1-
3U26FK2&ct=170222&st=sb [26.1.2018]
UiPath. (2018). RPA is a journey not just a project. Online. Available at: https://www.uipath.com/rpa-journey [29.1.2018]
Von Rosing, M., Von Scheel, H., Scheer, A. W. (2014) The Complete Business Process
Handbook. Body of Knowledge from Process Modeling to BPM. Elsevier. Massachusetts. 776 p.
Weill, P. (2004). Don't just lead, govern: How top-performing firms govern IT. MIS Quarterly Executive, 8(1), 1–21.
Weill, P., & Ross, J. (2005). A Matrixed Approach to Designing IT Governance. MIT Sloan Management Review, 46(2), 26–34.
Willcocks, L., Lacity, M., & Craig, A. (2015). Paper 15/03 Robotic Process Automation at Xchanging. The Outsourcing Unit Working Research Paper Series, 1–26.
Willcocks, L., Lacity, M., & Craig, A. (2015). Paper 15/05 The IT Function and Robotic Process Automation. The Outsourcing Unit Working Research Paper Series, 1–38.
Appendix A: Information about the Case Company
Appendix A: Information about the Case Company
Table A1: Information about the case company
Description | A multinational ICT company |
Personnel | Over 20 000 employees |
Industry | ICT and digital services |
Role of RPA | Uses in internal processes, Offers RPA consulting and sells RPA solutions |
Appendix B: Coding Scheme of the Expert Interviews
Appendix B: Coding Scheme of the Expert Interviews
Appendix B: Coding Scheme of the Expert Interviews
Current RPA governance structure's advantages | Knowledge sharing | 16 |
Economies of scale | 11 | |
Becoming more uniform at the group level | 10 | |
The decrease of responsibilities from business domains | 7 | |
Maintenance of RPA robots | 6 | |
Control of defined quality level | 5 | |
Reusability of components and elements of RPA robots at the group level | 3 | |
Enough level of autonomy | 2 | |
Platform development | 2 | |
The building of IT infrastructure for RPA | 1 | |
Current RPA governance structure's challenges | Slowness by the hub | 16 |
Inflexible and complex | 12 | |
Standardized RPA platform (restrictions and messy) | 8 | |
Lack of cooperation among stakeholders | 8 | |
Differences in IT landscape | 6 | |
Management of completed software robots | 6 | |
Unclear responsibilities and roles | 5 | |
Infrastructure challenges | 3 | |
| Training | 1 |
Practices to mitigate challenges in the current RPA governance | Increasing cooperation between key stakeholders | 15 |
Reducing the level of centralized control | 12 | |
Creating clear responsibilities and roles | 8 | |
Increasing resources in the hub | 7 | |
Developing a clear problem management process at the group level | 5 | |
Putting more pressure on the hub | 2 | |
Advantages of the separated building system | The ability to lead in the right direction on a big scale | 8 |
The decrease in responsibilities and risks | 4 | |
Address the issues of complexity and uncertainty | 3 | |
Challenges in the separated building system | Incapability to meet local requirements | 9 |
Motivation challenges | 3 | |
Communication | 2 | |
Inflexible | 2 |
Appendix C: Interview Template, Expert Interviews
Appendix C: Interview Template, Expert Interviews
Background questions about interviewee in the case company:
Could you tell briefly about your position and responsibilities?
Could you tell more about RPA:
How long have you been involved in RPA activities?
What kind of RPA projects/implementations have you done?
Questions about RPA:
Based on your experience, what kind of strengths and weaknesses does RPA have? How can the case company empower strengths and overcome weaknesses?
Does RPA differ from other IT technologies? How?
Questions about Hub-Spoke structure:
Could you describe your understanding of the Hub-Spoke structure of RPA?
How does the structure affect RPA activities of the business domain of Finland?
When general RPA development is done in the hub and spokes must follow this development, what are:
Pros?
Cons?
What are your thoughts about stricter IT governance related to RPA, for example when the hub can only implement robots into the production environment?
Challenges?
Advantages?
How can the company tackle these challenges and benefit from the Hub-Spoke structure?
What practices/tools does the company use at the moment?
What practices/tools should the company use in the near future?
Could you give an example where the Hub-Spoke structure turned out as a supportive structure for RPA activities of Finland business domain?
What kind of process/situation was in question?
What were the factors that made it successful?
Could you give an example where the Hub-Spoke structure turned out a structure that hindering RPA activities of Finland business domain?
What kind of process/situation was in question?
What were the factors that hindered RPA activities?
What should have been done differently?
Appendix C: Interview Template, Expert Interviews
Questions about work system and building system:
How do you understand terms of work and building system? What are the differences between these systems?
Does it possible to analytically separate these two systems? Do you feel that there exists a gap then?
What do you think, if the building system is responsible for the development of work systems and the building system is isolated in space and time from the work system?
• Challenges?
• Advantages?
If we imagine that building system is responsible for RPA development and work systems have to follow the development:
• Do you feel that there exists a gap between these systems?
• Challenges?
• Advantages?
Questions about RPA governance:
How should the case company organize RPA governance in your opinion?
• Advantages
• Challenges
Do you have any other comments and opinions that you want to highlight?
Appendix D: Quotations from the Expert Interviews
RPA as a technology | |
Characteristics | "People talk RPA as a technology, but it is not only a technology. The technology part is the platform and technical execution. RPA is a change programme which must begin before the implementation of RPA in a company. The whole organization needs to be involved in the programme and fears regarding the programme needs to be erased that the programme will be successful. If RPA will be implemented without the involvement of the whole organization, it will cause fear and opposition, and that cause problems and failure." (Interviewee E) |
"If we think the whole process development, we always begin by thinking can we lean the process. Second, we evaluate the possibility to build a full IT-integration, if the volume is enough large. The third option is RPA. Should we robotize the process and make the process development more agile and faster, instead of IT-integration?" (Interviewee C) | |
Advantages | "Companies use three times more time and money at least for creating traditional IT-automations compared to RPA solutions. The RPA project could be implemented in the production environment in a month after the analysis phase. Traditional IT-automations cannot get even close to that speed, a quarter is a very short time. When talking about money, the variance between traditional IT development and RPA is very big, there exists a large fundamental difference." (Interviewee C) |
"A strength of RPA is its trendiness which induces an in-depth study of processes while planning RPA implementation. As a result of that, we may notice better tools for process development, for example, process leaning, and API (Application Programming Interface) development or some other automation tool." (Interviewee A) | |
Disadvantages | "People think that RPA fixes everything, the software robot does anything. People understand RPA wrongly. When people think RPA at a general level, we face continuously questions, can the software robot do this task without considering the form of data, variation or does it even possible to automate with software robots. At the managerial level, there would exist decisions about cost savings by RPA without thinking the realities of RPA. We do a lot of positive things with RPA, but we also use it as an excuse for many things."(Interviewee B) |
"When talking with IT personnel about RPA, their reactions are usually that this is not a real IT. This is a plaster. They say that these processes should be automated with traditional IT automation tools if I have time, resources, and money. IT department's reaction is pretty negative." (Interviewee E) | |
"RPA's bad side is that it needs a constant monitoring, maintenance and fixing." (Interviewee A) | |
"How we handle the maintenance of hundreds of software robots? We have a huge transformation at the moment while organizations change, practices change and IT legacies change. How the software robot keeps up?" (Interviewee D) | |
"RPA tools are not so mature as they are marketed. There exists a huge lack of features. Especially when we think GDPR-requirements, it is not enough thought the storing of information about robot's activities. It has not built in the RPA tool and we have to buy another tool for handling this part." (Interviewee H) | |
"We have succeeded to automate many routine tasks by RPA, but in some cases, the complexity and security issues of processes have made it senseless. In some cases, these issues caused insuperable infrastructure barrier and RPA turned out an unfeasible option for automation. For example, when the complex infrastructure loses the visibility of software for RPA robot." (Interviewee F) |
Practices to empower RPA | "We usually forget, how to involve people in the software robotics and understand what it is. Basically, a software robot is a new colleague. If we involve change management in RPA journey, then we hold the keys to success." (Interviewee D) |
"We should recognize all the activities under the same roof, then we point out what we will automatize next. After that, we will get a common view, what we have automatized and what we will automatize next. At the moment, we can only see a small share of the processes that are automatable by RPA and we will probably understand in the near future that the same robot could have done much more instead of a small share." (Interviewee D) | |
"It is important that we find the golden mean where we are transparent, but we can maintain the agility and speed of RPA activities. That is the biggest practice what the company can do for RPA." (Interviewee F) | |
"We should utilize the reporting and monitoring of digital workforce for the supervisor of the digital worker. We should find a way, how reporting goes automatically to the supervisor that tasks made by the digital worker are easily visible." (Interviewee C) | |
The federated RPA governance | |
Advantages | "The best-practice which the hub offers includes the best-practices for several functions of RPA for example, incident management, change management, problem management, configuration management, event management, request fulfillment, common platform templates, robotics playbook, development guidelines." (Interviewee G) |
"The hub offers a proof of value assessment. We have packaged a fast start for RPA function, where will be implemented a unit-specific process scanning and the first RPA robot to the pre-production live proving environment as well as can start building the new spoke organization." (Interviewee G) | |
"The Hub brings the best-practices that we can benchmark here in the spoke. Also, this structure enables common events for the exchange of views and the best-practices. I see that exchange of experiences is a clear benefit in this structure when we get a community that has same objectives and problems. (Interviewee E) | |
| "The current governance structure offers a community where we have all RPA developers from each spoke, the Hub representatives, and the platform provider representatives. This encourages knowledge sharing and problem-solving." (Interviewee A) |
| "The governance structure enables economies of scale on platform side: operations, license management, cost level, and gives a visibility to other countries' actions." (Interviewee C) |
| "It is good that we can create a common strategy for RPA at the group level. We can utilize experiences of other countries when we have standardized approaches." (Interviewee A) |
| "The common RPA usage enables, that we can reuse components across business domains. However, we have found only one component which has been used in another country." (Interviewee C) |
| "We have the common RPA library that every country can reuse components and elements. Every country has own IT legacies. No one cannot reuse components and elements made by another country." (Interviewee D) |
| "Change Management is at best when it is well controlled, and we make a clear process for it." (Interviewee G) |
| "Our business domains are significantly different. When we look at a single process, the execution of it variates a lot because every business domain has own IT landscape. Because we have this federated governance model for RPA, the value creation prioritization happens in a correct place, in the country in other words. The business-case lies in the country and it is a clear benefit in this governance model." (Interviewee G) |
| "The Hub has developed the platform and succeed to add some useful features for software robot development. In addition, it has also managed the communication with the platform provider and other vendors. The spokes do not need to manage the IT side of RPA, platform development and maintenance." (Interviewee B) |
Challenges | "The hub's response time has been a problem regarding the robots' production environment. The spoke has responded to the hub's request in few hours, but the hub has responded in a couple of days." (Interviewee A) |
Appendix D: Quotations from the Expert Interviews
| "The spoke's RPA developers cannot test RPA robots in the preproduction environment. We always need to ask the Hub to test our RPA robot. Then the Hub informs that something needs to be modified in the RPA robot and we can fix it in a couple of hours. After that, we wait days that we can test it again. We have definitely challenges in the software development process." (Interviewee C) |
| "At the moment, we do not see which server the Hub takes and which robot it schedules. We have had to design our processes that it works with every robots and server. We need to request all the user ID's for every robot because we do not know what robot the Hub schedules. We need to plan a lot of extra" (Interviewee B) |
| "The lack of communication is a big challenge. In some cases, the Hub has tested the same robot for five weeks after us, but we have already made the same tests." (Interviewee F) |
| "At the moment the Hub can serve poorly local technical needs. We tried to tackle this with a technical meeting, but we have succeeded to organize two meetings of 20 attempts. (Interviewee H) |
| "Nowadays roles and responsibilities are at better level. Previously, there were not clear responsibilities and roles between local IT and the Hub which lead to the omission of tasks." (Interviewee A) |
| "A concrete example about standardized and common platform comes from a Golden Image change. When it is planned, it causes a big test episode in development, preproduction and product environment, and tests of completed robots. It takes a lot of time." (Interviewee C) |
"I do not see a benefit that the development environment includes all the RPA components and elements of every business domain. It is very chaotic. In addition, this has caused unexpected challenges when local IT change has impacted on other country's RPA robot's functionality and it has stopped its tasks." (Interviewee B) |
Appendix D: Quotations from the Expert Interviews
Practices to mitigate challenges in the federated governance model | "At the moment, we have a temporary daily call solution because the Hub has not succeeded to respond to service level agreements. This is a call where we handle current situation, schedule, and waiting schedule. This is not a permanent practice. We have several communication and ticketing tools that should be used for communication and problem management." (Interviewee B) |
"We have planned the usage of common problem ticketing system as a communication system also. We store all the relevant information there that everyone sees what has been agreed. It is one of the practices that we should use actively." (Interviewee A) | |
"We use the common problem ticketing system already. But we have not understood, how broadly we should use it." (Interviewee H) | |
"We have to keep RPA business-driven. How we involve the representatives of business in RPA development all the time, that it will not become a technology practice? Technology gets continuously too much importance in RPA in my opinion." (Interviewee C) | |
"The importance of communication will be emphasized. The responsibility for scheduling and other elements of software robots remains the Spoke's developers. Their tasks should be in good control and they should be informed of important things because the Spoke's developers instruct the Hub's employees to do tasks." (Interviewee F) | |
"At the moment, we have a sufficient number of people and role. But we have to rethink what roles we need more when the maturity level of RPA advance. We cannot stop here. This is the optimum now, but not in the future." (Interviewee H) | |
"In the next step, I wish that every business domain will have own Golden Image. The spoke would request features to its own Golden Image and it would not be installed to everyone." (Interviewee B) | |
"At the moment, we do not have in-depth problem management process for RPA. It would be important that we get a common view of robot's lifecycle from a problem ticket. We have had plans for the problem management at the group level, but there are still open points." (Interviewee B) "The spoke should make more structured requirements to the Hub and ensure that those are understood correctly, and constantly build cooperation aggressively. (Interviewee F) |
Appendix D: Quotations from the Expert Interviews
Building and work systems | |
Characteristics | "The building system can bring speed and clarity to issues, and everything is not connected among themselves. It is possible to clarify and share responsibilities much smarter. Otherwise, work systems are too complex to understand. The separated building system is enabling the understanding of a whole complex of issues." (Interviewee C) |
"I think that building system is a different version of work system. But before the building system succeeds in defining the needs of work system there might exist a gap between these systems." (Interviewee F) | |
Advantages | "When we erect a separated building system which has a better market knowledge about RPA, it can develop a work system towards market's bestpractice. It would be a significant pro." (Interviewee A) |
Challenges | "We have tried to locate a building system in another country. It did not go well. They did not understand local requirements and did not react on critical issues, because those were not critical from their point of view. I guess that it was also a result of low prioritizing because the work system was so far away. It can be a mental issue or lack of local knowledge, for example, incapable to understand a deeper local infrastructure." (Interviewee B) |
"Could the building system develop a work system towards right direction without a strong local knowledge? In my opinion, an analytically separated building system removes the local knowledge." (Interviewee A) | |
"Because of the existence of the building system, work system's experts do not express their expertise. They only bring out the work system's problem, but do not tell a solution even though they already know it." (Interviewee H) | |
"This kind of system separation usually creates inflexibility and slowness." (Interviewee C) | |
| "First, can we define the needs of work system from the building system? Alternatively, communication and information from the work system to the building system would be challenging" (Interviewee F) |
| "When we erect a separated building system which has a better market knowledge about RPA, it can develop a work system towards market's bestpractice. It would be a significant pro." (Interviewee A) |
Credit: T. Kämäräinen (2018)
.webp)
No comments: