Keywords

1 Introduction

Robotic Process Automation (RPA) is a tool among a diverse set of other tools that enable higher productivity as part of an automation and digitization strategy. It refers to software tools operating on the user interface that try to mimic a real user [1]. RPA is non-invasive to the underlying IT infrastructure, as opposed to traditional BPM solutions [16]. It is used to automate processes that are structured, rule-based, and repetitive [13, 34, 41]. A typical use case is creating invoices. To create an invoice a bot can be tasked to retrieve data from an Excel sheet and enter the invoice data from that sheet into the correct fields of an SAP form. Once all the data is pasted into SAP, the bot creates the invoice by running all the transactions. This example emphasizes a notable strength of RPA, which is to connect different applications without human intervention.

Organizations that aim to establish quick wins to save costs are eager to implement RPA [20]. Bots are relatively quick and easy to build compared to traditional automation solutions. When the application of RPA within an organization starts spreading beyond initial experiences, the issue of governance comes up. Some organizations choose for a decentralized model by letting business units develop bots autonomously, completely bypassing the IT department [39]. In other settings, as for example described in  [30], a centralized unit takes overall responsibility and accountability of RPA within an organization. This could be a newly created Center of Excellence (CoE) or the traditional IT department. Finally, it is possible to mix these approaches into a federated model, where self-sufficient business units take care of RPA implementations but receive support from a CoE. Regardless of the model, however, each organization must face the problem of an increased burden of maintenance; such efforts are often much higher than expected  [27]. Illustrative is the following remark of an RPA project manager, cited in  [34]:

You always underestimate the complexity of things, even if it is simple. There is more need for monitoring and maintenance than we thought one year ago. [....] We just wanted to get started, and our focus was on delivering solutions.

Because widespread organizational RPA use is still in its early stages, there is a gap of knowledge on how to deal with the maintenance challenge, which brings us to the following research question: How can organizations minimize maintenance problems related to RPA implementations?

The contribution of this paper is that it presents a set of 11 guidelines for the creation and sustenance of low-maintenance RPA implementations. The guidelines are considered to be particularly useful in the setting of a federated model for RPA, i.e. when RPA is driven by business units that receive support through a CoE. Organizations that have adopted a centralized model can use these guidelines to investigate or structure a business case to transition to a federated model. Those organizations that are completely new to RPA can use the guidelines to improve or critically review their business case.

To develop the guidelines that are presented in this paper, a mix of methodologies was adopted. A survey of the literature was used to develop an initial list of guidelines. Case studies within four different Dutch organizations were carried out to supplement this list. Finally, a survey-based Delphi method was used to validate the guidelines.

The remainder of the paper is structured as follows. Section 2 elaborates on the related research focusing on RPA governance structures and enabling business units. It is followed by the research methods used to create and validate the guidelines. Sect. 4 presents the guidelines. We conclude the paper in Sect. 5 with a reflection on the implications and limitations of this study.

2 Background

For governing RPA, three distinct organizational models can be identified: the decentralized, federated and centralized organizational model [27]. In a centralized organizational model, a Center of Excellence (CoE) is created containing the entire RPA capability. In practice, as observed by Schmitz, Dietze and Czarnecki [30] this can mean that a centralized team of project leaders are responsible for multiple smaller automation teams. The project leaders have a role in the identification, design and implementation of RPA use cases that contribute to the overall objective of increased process automation. Employees tasked with the processes to be automated are closely involved as they can share their expertise with the people that are tasked to automate a process. Their detailed operational understanding can also help to identify and prioritize ideas for future RPA use cases. A decentralized approach places the RPA capability in different business units without a governing body in place. Osmundsen, Iden and Bygstad [27] identify advantages of a decentralized approach. It creates enthusiasm for digitization due to the deep involvement of local employees within the RPA initiative. Employees realized how they could employ RPA software and make improvements themselves without the help of the IT department. By establishing local ownership, the employees knowing the processes were better involved. A decentralized approach can however have significant downsides [3, 27]. For instance, it lacks control mechanisms to coordinate and prioritize the different RPA initiatives. Another downside is the lack of an end-to-end process view. Process automation is done within departments without a perspective of how processes are part of and affect other parts of the organization.

A federated approach combines the decentralized and centralized approach [27, 39]. This organizational model retains the benefits of local ownership and business involvement of the decentralized approach. The disadvantages of the decentralized approach are avoided by retaining a CoE. Adopting a federated organizational model can spread out the maintenance effort more evenly across the organization. By organizing RPA within business units, local employees possessing the knowledge of the processes are more involved. Many organizations have claimed success by organizing RPA within business units [16, 27, 34, 40].

However, also with a federated approach, pitfalls may emerge. First, the IT department has to be part of the RPA initiative as they can ensure that RPA solutions work securely, consistently and are scalable [32]. Furthermore, business people will run into issues that are initially invisible to them, but not to IT, such as capacity planning, fail-over for servers and storage, licensing of virtual machines and network latency [32]. This kind of collaboration between business units and the IT department can lead to ambiguity in terms of ownership and responsibilities. Indeed, establishing RPA development teams consisting mainly of business people without a background in IT can create tensions with the IT department as such a development task is often associated with software development [6, 27, 34]. These stakeholders can have different views on RPA and how to approach it. For example, in one case study the IT department reacted negatively to RPA as they viewed it as a temporary IT solution that was improperly integrated [34]. The IT department was concerned that RPA developers did not apply the methods and best practices that software developers use.

Second, the maintenance of bots can be more burdensome than initially expected [27, 34]. RPA can scale rapidly in a relatively short time and exacerbate problems if insufficient preparation has taken place. It is recommended to continuously monitor bots, and as such RPA software often comes with a performance dashboard [7]. Such a dashboard can show average processing time per case, but also provide more insight into the exceptions. Cooper, Holderness, Sorensen and Wood [7] describe a case in which an organization operates over a thousand bots. This organization has created a manned control room where all bots are monitored 24/7, highlighting the need for continuous monitoring. An increasing need for low maintenance can lead to discussions related to ownership and responsibilities and alternative solutions [27, 34].

To summarize, three governance structures for RPA can be identified, of which the federated model is the most promising. Nevertheless, when adopting a federated model, certain potentially negative consequences must be considered. The aim of this study is to prevent these negative consequences with the help of the identification of guidelines. These guidelines are specifically targeted at organizations that have adopted the federated model and that aim for low maintainability of their RPA solutions.

3 Methods

This section discusses the different research methods used to set up this research and to create and validate the guidelines. First, in Sect. 3.1, we outline the literature review. We then explain our multi-case study in Sect. 3.2. We successively (1) provide a summary of the case organizations and (2) discuss the data collection and analysis approach. We end the section with an explanation of the validation of the guidelines (Sect. 3.3). Figure 1 illustrates the steps we have taken to arrive at the guidelines, using this mix of research methods.

Fig. 1.
figure 1

Overview of the derivation of guidelines

Full size image

3.1 Literature Review

A list of both scientific literature and grey literature was created using a search on Google Scholar and Google. As search terms, we used 26 different combinations of the term “Robotic Process Automation” combined with a term such as “lessons learned”, “core problems”, or “implementation”. Both the results from Google Scholar and Google were analyzed on their contents by scanning through titles, abstracts, and, if necessary, the article contents. We used the following inclusion criteria for evaluating entries:

  • Describes an RPA implementation process

  • Describes lessons learned from an RPA implementation process

  • Mentions strategies to minimize the negative aspects or reinforce positive aspects

The highest ranked entries on both Google Scholar and Google yielded several useful results. Further down the search results, fewer and fewer useful articles could be identified. When stopped finding useful entries (based on the inclusion criteria), we stopped our search. This resulted in 14 scientific papers that we found on Google Scholar and 12 items of grey literature found on Google. The list of grey literature consists of website entries and reports from RPA vendors and consultancy firms. The total of 26 papers and documents were summarized and reflected upon by focusing on the lessons learned by the organizations. From this, we derived a set of 29 preliminary guidelines that could potentially help organizations develop low-maintenance RPA solutions.

3.2 Multi-case Study

As we are interested in a contemporary phenomenon in its context, a multi-case study was conducted, which was the next step in our overall approach. The case study methodology is suitable when the phenomenon is difficult to study in isolation [29, 42]. For this study, it was difficult to isolate RPA, since it is part of an organizational process and involves different stakeholders. Furthermore, the case study methodology is suitable for an exploratory research purpose that seeks to find out what is happening and to gain more insight [29].

Another advantage of the case study approach is triangulation, as studying the phenomenon from different angles provides a broader picture and strengthens the evidence [28, 29, 42]. Furthermore, fulfilling multiple case studies increases the generalizability and provides more insight [25].

Case Organizations. Four organizations participated in the case studies. One organization requested to be anonymized and will be referred to as BankX. The other participating organizations are the Rabobank, PostNL, and the municipality of Rotterdam. All four organizations either adopted a federated model or were moving towards a federated model. An overview of the participating organizations can be found in Table 1.

The Rabobank is a large Dutch bank and is among the 30 largest financial institutions in the worldFootnote 1. The Rabobank is an early adopter of RPA, starting with a first prototype, or Proof of Concept (PoC), in the summer of 2016, and moving beyond a PoC in 2017. In terms of RPA adoption and, more specifically, automation of processes, it is ahead of the other case organizations.

BankX is a bank as well, but is significantly smaller and only services institutional customers. BankX started with a PoC in October 2016 and moved beyond their PoC in January 2017.

PostNL is a mail, parcel, and e-commerce corporation.Footnote 2 It has its operations mainly in the Netherlands, but also in Germany, Italy, Belgium, and the United Kingdom. PostNL came into contact with RPA at the end of 2017 and subsequently started their PoC.

The municipality of Rotterdam is the second largest city of the Netherlands with more than 600, 000 inhabitants. The city council of the municipality started exploringy RPA at the end of 2018 and plans to have 4–10 operational bots before the end of 2020.Footnote 3

Table 1. Overview of the organizations participating in the case studies
Full size table

Data Collection and Analysis. An overview of the data collection is shown in Table 2. Semi-structured interviews form the main source of data collected from the case studies. The interviews were held with different participants from the selected organizations. The questions that were asked related to the arrangement of RPA within the organization and the choices that were made, such as: “To what extent has RPA been scaled up and are there specific factors that could hinder this? Have certain choices been made to facilitate upscaling?” And: “To what extent and how are employees being involved in the development of bots?”

The collected data were coded in NVivo, based on the guidelines as derived from literature in the previous step. As a result, 16 of the guidelines from literature were confirmed in the case studies. 10 guidelines that were not found in the literature, but did emerge in the case studies, were added to the provisional list of guidelines. 13 guidelines that had been found in literature, were not found during the case studies. We transferred the full set of 39 guidelines to the next step, the validation.

Table 2. Overview of data collection
Full size table

3.3 Validation

To validate the created guidelines the Delphi method was used. The Delphi method is defined as “a method for structuring a group communication process so that the process is effective in allowing a group of individuals, as a whole, to deal with a complex problem” [21]. The method is based on the premise of collective intelligence that enhances individual judgment by capturing the collective opinions of experts. In this study, we used two rounds of surveys to collect the expert opinions, allowing for participants that are both geographically close and far away to contribute anonymously [36]. This allowed for higher expert selection criteria that have academic publications related to RPA.

The 39 guidelines derived from literature and the case studies were separated into 52 statements, which allowed for a more detailed analysis. Each statement was presented in a survey to the participants, in most cases followed by a 9-point Likert scale to determine the corresponding agreement (ranging from 1 point for complete disagreement to 9 points for complete agreement). With Delphi research, there are no set criteria available to determine at which percentage consensus has been reached [38]. McKenna [24] and Loughlin and Moore [22] suggest consensus is reached if there is 51% agreement amongst respondents. In other research, percentages of 70% or 80% have been recommended. Two studies with a similar Delphi setup using a 9-point Likert scale adopted a consensus of 70% and 75% respectively [2, 36]. Based on consensus percentages used in other studies, we determined the level of consensus by establishing for each statement whether a range of three consecutive points on the scale was selected by over 70% of the experts.

The Delphi study required two rounds of surveys sent to selected experts after which sufficient consensus was reached. These experts were selected based on publications related to RPA. They were working mostly in academia, but also in industry. In the first round we received 16 responses, while we received 9 responses in the second round. In both rounds we used statements to determine consensus, in this way testing support for the guidelines. As mentioned, the first survey round consisted of 52 statements, excluding demographic questions. For each statement there was an opportunity for the experts to leave a comment. The collected comments were used to refine a number of statements that did not lead to sufficient consensus. After the first round, two guidelines were eliminated because consensus was not achieved. This meant that the second round the survey covered statements related to 37 guidelines only. After this second round, 4 guidelines were rejected; 3 guidelines were merged into other guidelines, since they were determined to be similar.

After the validation, 30 guidelines derived from literature and/or the case studies were validated successfully by the experts. We then brought further focus by including only those guidelines that are relevant to organizations that have adopted a federated model and contribute towards achieving maintainability in terms of their RPA solutions. For example, the guideline choose the organizational model with the best organizational fit is crucial for all organizations, but as we focus on organizations that have already adopted the federated model, this is out of scope for our study.

Based on the criteria of relevancy to organizations adopting a federated model and focusing on maintainable RPA, we excluded a further 19 guidelines; 11 guidelines remained.

4 Guidelines

This section presents the 11 guidelines that went through the entire research process, such as described in the previous section. Figure 2 presents an overview of the guidelines, in relation to the different phases of RPA adoption, which we will further explain below.

Fig. 2.
figure 2

Overview of the presented guidelines

Full size image

4.1 Phases of RPA Adoption

In order to bring structure to the guidelines, we grouped them into three phases: Establish Capability, Develop Capability, and Mature Capability. The phase Develop Capability is subdivided into the phases assess, configure, and test. The phases are not intended as a proposed approach for integrating RPA in an organization, but purely function as clarification of the distinctive character of the guidelines.

The first phase, Establish Capability, generally consists of vendor selection, creating a business case, and developing a Proof of Concept. In this phase, organizations build the foundation of their RPA capability. The Develop Capability phase concerns the development phase in which the initial RPA capability is built. Bot development is divided into three parts, namely: assess, configure, and test. The Mature Capability phase marks the middle and ending point of scaling up the number of bots. It is also a phase that is characterized by continuous improvement and maintenance.

4.2 Guidelines to Maintainable RPA Using a Federated Model

In what comes next, we will explain the guidelines one by one. A number of guidelines are accompanied by literature references that are part of the basis of those respective guidelines. The guidelines without a reference originate exclusively from the case studies. Furthermore, each guideline is followed by one or more statements as used in the Delphi survey. The statements are accompanied by a percentage conveying the level of agreement. In addition to this percentage, a range is displayed, which denotes the degree of acceptance between that specific interval on a 9-point Likert scale. For example, for Guideline 2, 89% of the experts scored the statement with a 7, 8, or 9 on the 9-point Likert scale. Guideline 10 is the exception, which will be in the respective section.

Guideline 1: Consider Enabling Business Units to Develop and Maintain Bots. [16, 27, 34, 40]

  • Temporarily extending a business unit that is lacking the expertise to successfully develop bots with an expert from the CoE enables that business unit to successfully develop bots - 100%, 6–8

  • Training and mentoring-on-the-job facilitated by the CoE should be sufficient for business units with a moderate amount of IT affinity that want to start building bots - 88%, 6–8

One of the key characteristics of RPA as opposed to traditional BPM solutions is that it is relatively easy to configure, meaning users without a specific technical background are able to develop bots [14]. This allows organizations to use RPA in order to adopt a bottom-up approach, contrasted to a top-down standardising approach [37]. In line with this, the results from the case studies show that organizations can enable their business units to develop and maintain bots if they are deemed sufficiently capable. The statement of temporarily extending a business unit that is lacking the expertise to successfully develop bots was accepted (100%, 6–8). A transition can be facilitated by the CoE, which can help set up a robotics team within a business unit. This includes recruiting qualified people from within the business unit who are able to work with the tools provided.

Guideline 2: When Selecting RPA Vendors, Take the Context and Characteristics of the Organization into Account as Much as the Financial Aspects [8, 15, 20].

  • Organizations aiming for medium to long-term RPA implementations should take the context and characteristics of the organization into account as much as the financial aspects when selecting RPA vendors - 89%, 7–9

Vendors can compete with each other on various aspects such as the total cost of ownership, ease of use, control, analytics and vendor support. Choosing the right vendor depends on variables such as the scope and size of the to be realized RPA capability, expertise within the organization and financial resources. For example, ease of automation can be a more important aspect for an organization lacking IT affinity and know-how among its business units. Easier to use solutions require less training and accelerate the development of bots. Vendors can differentiate the amount of support offered. In conclusion, organizations should be aware of their needs and aspirations. Choosing the right vendor can save costs and reduce the chance of failure.

Guideline 3: Demonstrate and Structure Communication to the IT Department Regarding RPA [9, 26].

  • Organizations should have an internal communication plan when introducing RPA to the IT department that describes the capabilities of RPA, its benefits and limitations, the role of IT and the envisioned roadmap - 87%, 7–9

  • Transparent communication to the IT department about the capabilities of RPA, its benefits and limitations, the role of IT and the envisioned roadmap is effective for minimizing the resistance to RPA - 80%, 7–9

As mentioned earlier, there are specific advantages of adopting a federated model as opposed to a centralized or decentralized model. On the one hand it exploits the benefits of local ownership and on the other hand there are the benefits of a central governance body and knowledgebase of a CoE. In order to achieve these benefits, however, good communication between the parties involved is vital, not only between the CoE and the business. What became clear in the case studies is that organizations should also communicate the capabilities, benefits, limitations, role of IT and the envisioned roadmap to the IT department. Preconceived opinions regarding RPA that can reside within the IT department should be addressed and discussed among IT personnel. Discussing the envisioned roadmap should inform IT personnel about what RPA means for their own internal roadmap. Additionally, the role of IT should be discussed as they are in a supporting role. Friction between the business and IT side can develop if the roles and responsibilities are unknown.

Guideline 4: Consult Software Architects During a Process Assessment.

  • Software architects should be consulted when assessing a process - 71%, 7–9

In line with the previous guideline, the importance of communication with software architects is especially evident during process assessment. Although RPA is characterized by the fact that its development can be led by business units, this does not mean that there is no knowledge to be gained from specialists. On the contrary, our results show that business units wanting to automate a process should consult software architects. Software architects can also be part of the CoE. A board of architects can determine how the process should be automated. In some instances, a permanent solution using traditional automation is more appropriate than using RPA. Alternatively, RPA can be used as a temporary solution until a permanent solution becomes available.

Guideline 5: Create RPA Development Standards to Create Uniformity Across the Organization [12, 16, 18, 23, 26, 31, 39].

  • Organizations should create RPA development standards to create uniformity across the organization - 89%, 7–9

  • A CoE should recommend development standards to create uniformity across the organization - 78%, 7–9

The main goal of implementing RPA solutions is to achieve improved operational efficiency, for example by reducing transaction processing cost [15, 18]. As operations often transcend business units, RPA development needs to be streamlined both between business units and within them in order to achieve and maintain operational efficiency. Organizations should therefore create development standards to ensure uniformity across the organization. The case organizations that have implemented a federated model have their CoE provide development guidelines and standards to ensure a certain quality standard throughout the organization. These standards can be related to for instance coding conventions, documentation and testing. Implementing such development standards should lead to improved bots. The role of the CoE should be to recommend standards and moderately enforce these standards.

Guideline 6: Create an Automation Library for Reusing Modules [5, 16,17,18, 33].

  • Organizations should create an automation library for reusing modules - 73%, 7–9

As automation is not seldomly completely new to organizations implementing RPA, the mantra is often to ‘think big, but start small’ [10]. One way to do so is starting with smaller simpler bots and reusing parts to build more complex ones. Accordingly, our results show that re-usability and modularity principles should be applied to bot development. Reusable components can be created for steps such as logging into SAP systems. Another benefit of modularity is its support for granular development and testing. Aside from increasing development efficiency, reusable components can bolster maintenance procedures. Updates to reused components can be applied to multiple processes across the organization.

Guideline 7: Implement Quality Checkpoints During Bot Development to Audit the Usage of RPA Development Standards.

  • Organizations should implement quality checkpoints during bot development to audit the usage of RPA development standards - 78%, 7–9

During development, organizations should implement quality checkpoints to audit the usage of RPA development standards. This is done to prevent an accumulation of issues that is discovered during a technical review by the CoE at what is supposed to be the final phase in development. At the Rabobank, a coordinator from the CoE is assigned to a business unit to observe the development process. This coordinator can examine the progress made and provide guidance.

Guideline 8: Have the Center of Excellence Perform a Technical Review of a Bot that a Business Unit Considers Finished.

  • It is good practice to have the CoE perform a technical review of a bot that a business unit considers finished to determine if that bot is ready for a live environment - 78%, 7–9

The technical review done by the CoE takes place once a bot is considered finished by a business unit. This is done to ensure that a bot is up to a certain standard defined by the CoE and is ready for a live environment. The municipality plans to impose quality checkpoints during development and during the final sprint. The goal of the quality checkpoints is to ensure that development guidelines are utilized to prevent the need for rework in the future. More specifically, the bots are reviewed in terms of re-usability of components, robustness, testability and resilience to future changes to reduce the risk of vendor lock-in.

Guideline 9: Create arrangements with software vendors delivering software used by RPA.

  • Organizations should create arrangements with software vendors, who deliver software that is used by RPA - 75%, 7–9

Organizations cannot control the updating schedule of external sources that are accessed by their bots. They should try to obtain information regarding the updating schedule and change-logs to anticipate to updates in advance. This reduces the chance of sudden exceptions created by changes within applications. Agreements with software vendors should be made, if possible, to be prepared for future changes. BankX has made arrangements with software suppliers to be informed two months in advance on any changes made in the software. However, it was not always possible to make such arrangements, which was often the case with external websites.

Guideline 10: Promote RPA and share RPA-related knowledge with suppliers or customers.

  • An organization should promote RPA and share RPA related knowledge with their suppliers or customers, when an organization is halfway at scaling up and can be considered experienced in RPA - 57%

  • ... when an organization has finished scaling up and can be considered an expert in RPA - 29%

This guideline does not include a range, as the participants were asked to choose whether an organization should promote RPA/share related knowledge (a) halfway the scaling up, (b) after the scaling up, or (c) never.

The rationale behind the guideline is that a bot may rely on external information sent by a customer or supplier. Such information needs to be highly standardized and uniform in all cases. Automatically generating documents such as Excel sheets using RPA can ensure that every sent Excel sheet adheres to a certain set of standards, barring failures. As a result, promoting and sharing knowledge related to RPA could have a positive effect on RPA adoption at customers or suppliers. This can contribute to further standardization requiring less maintenance and leading to fewer exceptions. 57% of the experts agreed organizations should start promoting and sharing knowledge when it is halfway at scaling up and can be considered experienced in RPA. 29% of the experts agreed that organizations should undertake this once it has finished scaling up and can be considered an expert in RPA. BankX stated that it was investigating whether processes at customers could be automated using RPA, to further automate and standardize the entire chain of linked processes.

Guideline 11: Create or Adapt a Personal Development Plan Based on an Impact Assessment [4].

  • Organizations should create or adapt a personal development plan based on the impact assessment - 80%, 7–9

One last but major theme that is often associated with RPA is fear: either with bots in general or with potential job loss as a result of automation [35]. Attention to the human aspects RPA implementation should therefore not be evaded. Communication to involved employees is key. It is advised to create or adapt an existing personal development plan for employees affected within a business unit by RPA. Studies done within an organization on the overall impact of RPA on employees performing work to be automated can be used to further structure a personal development plan. RPA can have effects on employees ranging from changes to job contents to transferring to different business units or being involved in the development of RPA. A personal plan is the process of establishing the aims and objectives in the short, medium and long term in one’s career. It addresses the current situation and identifies the needs for skills, knowledge or competences to achieve the desired objectives. Subsequently, it addresses the appropriate development activities to meet the needed expertise. The personal development plan can then be used to obtain an overview of desired future plans [4]. This information can be valuable for matching employees with new opportunities that may or may not arise from RPA. Additionally, it can be used to match employees with different business units if necessary.

5 Discussion and Conclusion

Organizations were eager to adopt RPA in the last five years, but they must look into stemming the maintenance burden if they do not want to succumb under this enthusiasm. How they will be able to deal with this depends among others on the type of governance structure they choose. One of the most important choices they need to make is which one of three organizational models they adopt: decentralized, centralized, or federated [16, 17, 19, 27, 39]. Implementing the federated model provides advantages over the other models, but does not guarantee success.

This study speaks specifically to organizations that adopt a federated model, which assumes a high autonomy of business units and a CoE on RPA for centralized support. Based on a literature study and four case studies, 11 guidelines were formulated that attempt to mitigate the potential burden of maintenance and mismanagement of the technology. Specifically, they relate to the observed burden of maintenance cf. [27, 34], the mismanagement of the technology cf. [11], and the ambiguity of the roles and responsibilities. All guidelines were validated using a Delphi methodology.

The practical implications of this work are as follows. Organizations planning to adopt RPA are encouraged to consider to review their plans and account for the issues described. For instance, they may want to investigate the capabilities of their business units and the organizational model that fits them best. For many organizations, it may be attractive to balance a relatively high autonomy of decentralized units to develop their own bots with a CoE to provide guidance and support to such units. Organizations that have progressed beyond the choice for such a model and have already engaged with RPA may currently be struggling with maintenance issues. For those organizations, the list of guidelines we provided are particularly useful. We believe that business professionals that carry out, oversee, or advise RPA projects will find it beneficial to review our recommendations, for example on engaging software architects in their endeavors or on investing in the development of standards for documentation and testing. In fact, we would be pleased if our guidelines themselves will become parts of the standards that circulate within organizations applying RPA. While the guidelines themselves may not be so surprising for people who are familiar with software development, they are aimed at business professionals with no or limited experience in this area.

A limitation of this research concerns the surveys used during the Delphi study. The survey had to be brief and concise to reduce the drop-out rate. Due to this limitation, the survey contents were less elaborate than we aspired for. Another threat concerns the selection of experts used for the Delphi study. The experts were selected based on RPA-related publications, resulting in a minority of participants that work in the industry. The threat herein is a possible discrepancy between theory and practice and certainly shapes venues for follow-up work and further validation.