A framework for implementing robotic process automation projects

Robotic process automation is a disruptive technology to automate already digital yet manual tasks and subprocesses as well as whole business processes rapidly. In contrast to other process automation technologies, robotic process automation is lightweight and only accesses the presentation layer of IT systems to mimic human behavior. Due to the novelty of robotic process automation and the varying approaches when implementing the technology, there are reports that up to 50% of robotic process automation projects fail. To tackle this issue, we use a design science research approach to develop a framework for the implementation of robotic process automation projects. We analyzed 35 reports on real-life projects to derive a preliminary sequential model. Then, we performed multiple expert interviews and workshops to validate and refine our model. The result is a framework with variable stages that offers guidelines with enough flexibility to be applicable in complex and heterogeneous corporate environments as well as for small and medium-sized companies. It is structured by the three phases of initialization, implementation, and scaling. They comprise eleven stages relevant during a project and as a continuous cycle spanning individual projects. Together they structure how to manage knowledge and support processes for the execution of robotic process automation implementation projects.


Introduction
Companies compete in an international market that can be highly volatile (Levitt 1993). Therefore, it is becoming increasingly important for companies to be more efficient and agile to remain competitive (Syed et al. 2020). As many processes are already performed using computers, digitalization offers a variety of potentials for optimization such as analysis and improvement through business processes management (BPM) (Fischer et al. 2020a, b).
However, due to resource constraints BPM projects tend to focus only on a handful of processes at a time (Dumas et al. 2018). Imgrund et al. (2017) and van der Aalst et al. (2018a, b) have pointed out that there are more processes that should be managed actively as their distribution rather follows the long tail principle than the Pareto principle. Further substantiating this issue, Fischer, Imgrund and Janiesch (2020) provide initial evidence that many of these long-tail processes are dysfunctional and, thus, require assistance.
Whereas traditional off-the-shelf software (such as enterprise software) as well as BPM software itself have turned out to be too heavyweight for rapid automation projects robotic process automation (RPA) is a lightweight automation technique (Santos et al. 2019). It enables to automate already digital yet manual tasks or subprocesses within business processes with software robots using the existing user interface (UI) (Lacity et al. 2016c;van der Aalst et al. 2018a, b). It is typically used to automate manual tasks that are performed repetitively on a daily, weekly, or monthly basis associated with high administrative efforts . Consequently, RPA is an economically relevant alternative, since a return on investment can be achieved rapidly due to the lightweight automation approach (van der Aalst et al. 2018a, b).
Despite the interest and growth as well as the associated high expectations, RPA technology faces several challenges. According to Gartner Inc., RPA technology has recently entered the trough of disillusionment of the hype cycle for legal and compliance technologies (van der Meulen 2020). However, associated concepts such as RPA's promise to organizations, hyperautomation, has been declared a "top strategic technology trend" by them (Panetta 2020). In addition, from a research perspective RPA is only vaguely understood and still in the early stage of scientific research. Hence, several areas have not yet been sufficiently investigated and pose challenges (Asatiani and Penttinen 2016;Syed et al. 2020). This indicates a lack of transparency, which results in a mistaken understanding of RPA and its potential as evidenced by its placement in the hype cycle.
Although RPA is generally considered a straightforward to implement technology, expert knowledge is necessary to create reliable and scalable software robots that offer business value. As a result, up to 50% of initial RPA implementations are estimated to fail (Huang and Vasarhelyi 2019). Although academic literature already provides several case studies, most of them refer to specific companies and therefore do not enable a generalization of the findings to support RPA projects. This means that there are no general agreements on the tasks and procedure necessary to conduct RPA projects. We aspire to close this gap by consolidating findings from reported cases to develop a framework for RPA implementation projects and refining it in an expert interview study. To ensure practical relevance, we validate the framework in several workshops by revisiting actual RPA implementations.
In doing so, we provide three contributions: We provide (i) a meta-synthesis of the state-of-the-art of RPA implementation projects as represented in scholarly publications with a particular focus on their procedures. Further, we design and evaluate (ii) a framework to structure the implementation of RPA projects consisting of multiple stages and phases. Lastly, we provide (iii) evidence through real-life cases that our framework is relevant to practice, and we highlight its theoretical and practical implications.
With these contributions, we answer the call for research on RPA by van der Aalst et al. (2018a b) and we address several challenges that Syed et al. (2020) have put forward, namely contributing to better methodological support for the adoption and implementation, socio-technical implementation, and in particular the systematic design, development, and evolution of RPA projects.
We have structured our research as follows: In Sect. 2, we introduce the fundamentals of RPA and its relation to BPM. Section 3 introduces our research methodology, while Sect. 4 comprises the literature analysis and the preliminary phases we identified provide our first contribution. Section 5 summarizes the expert interviews (Sect. 5.1) and workshops on concrete implementation cases (Sect. 5.2). We analyze and discuss the results of the data collection in Sect. 5.3 and introduce the framework as well as its phases and stages in Sect. 6 as the second contribution. In Sect. 7, we provide a discussion of theoretical and practical implications constituting the third contribution before we conclude in Sect. 8.

Business process management and robotic process automation
Business process management (BPM) is the management discipline that enables business processes to be identified, documented, and digitalized in a structured manner (Dumas et al. 2018;Hammer 2015). Traditionally, processes are managed and optimized in mid-size or large cross-organizational projects focusing on high-value processes (Dumas et al. 2018) using customizable enterprise software or more flexible BPM systems. Both, require application programming interfaces (API) and may need custom (micro) services that can be called from a process model (Syed et al. 2020) to integrate with other (legacy) software.
In contrast, RPA is an approach that does not require new APIs or software services to replace current practices, but installs software robots that mimic the behavior of human users and interact with their already existing graphical UIs invoking a sense of anthropomorphism (Czarnecki and Fettke 2021;Lacity et al. 2016c;Penttinen et al. 2018). This approach makes RPA fundamentally different from previous more invasive automation solutions (Penttinen et al. 2018). The advantage of implementing RPA with off-the-shelf low-code platforms is that by using the UI, no in-depth technical (programming) knowledge and no intervention into the architecture of legacy software is required (van der Aalst et al. 2018a, b). Since many human tasks can be implemented through scripting or recording techniques rather than traditional software development, RPA projects typically involve comparatively little cost and are rapid, fostering RPA's image of hyperautomating the corporation (Jiménez-Ramírez 2021). As a result, RPA implementations are often not managed by the IT department, but by the business departments that are directly affected by the process's automation (Hofmann et al. 2020).
In summary, RPA can be defined as technology for the lightweight and rapidly deployable automation of tasks and processes using software robots that operate on the UI layer of preexisting software.
There are many different RPA vendors and not all of them develop stand-alone RPA software. Rather, they have added RPA functionality to their existing products, which often were BPM software (Lacity et al. 2016c;van der Aalst et al. 2018a, b). Although the two software families share the goal of process automation, the way they achieve this differs fundamentally. BPM software aims to coordinate and orchestrate process automation while communicating through programming or APIs accessing the data and business logic layer (Hofmann et al. 2020) constituting heavyweight IT (Bygstad 2017;Penttinen et al. 2018). Heavyweight IT can create IT silo problems in organizations with integration and security requirements so complex that approaching them would exceed the benefits of change (Bygstad 2017). RPA as lightweight IT, which only accesses the presentation layer, bypasses these issues. As a drawback, lightweight IT integration is less robust and may only constitute bridging functionality until a feasible heavyweight IT solution has been found. In addition, one has to be aware of the fact that simply automating a process-lightweight or not-does not necessarily constitute genuine process optimization as the underlying inefficiencies have not been improved. Still, the process can progress in the dimensions of speed, scalability, and reduction of human errors (Janiesch 2020).
To realize automation today, RPA mostly relies on clearly defined tasks consisting of simple if-then-else statements or business rules (Enríquez et al. 2020;Lacity et al. 2016a). In corresponding RPA software, a workflow is configured that consists of several of these tasks. Currently, the extension of this rule-based concept of RPA with methods of artificial intelligence is being explored, so that the next task can be determined automatically from the data (Chakraborti et al. 2020;Schmitz et al. 2019) or cognitive decision-making can replace current rulesets and process models.
This entails that one can distinguish symbolic RPA, which relies on handcrafted process models and rules, and intelligent RPA, which uses AI technology to enable human-like cognitive abilities for selected tasks ).

Research methodology
Our research methodology generally follows the design science approach of Vaishnavi and Kuechler (2015). Our awareness of the problem and initial proposal is based on a qualitative meta-synthesis of RPA projects in research and practice to reconcile findings across studies unearthed with a structured literature review (Sandelowski and Barroso 2006;Webster and Watson 2002). Following Beck et al. (2013), we extend their procedure with theory-building elements from the interpretative research method grounded theory (Strauss and Corbin 1994). Our approach consists of four distinct phases: Awareness, data collection and suggestion, development, and evaluation and conclusion. Thereby, we extend Vaishnavi and Kuechler (2015)'s design cycle with an explicit step of data collection and have merged the last two steps. See Fig. 1 for a summary. All phases are sequential but have been iterated until a consolidated framework emerged. Specifically, we have performed three design iterations of data collection and suggestion, development, and evaluation and conclusion: • Iteration 1: Structured literature review to enhance theoretical sensitivity, metasynthesis, initial framework, • Iteration 2: Expert interview study, data coding, consolidated framework, demonstration, and expert feedback, • Iteration 3: Framework refinement, evaluation workshops, final framework.

Awareness.
In line with the challenges put forward by Syed et al. (2020), the artifact of this research is a framework to facilitate and guide the introduction of RPA in companies to aid the systematic design, development, and evolution of RPA implementations. Thereby, we have identified the problem of missing concrete advice and guidance for RPA projects, which is not the focus of current research that attempts to synthesize issues and challenges: Gotthardt et al. (2019) identify broader challenges, but they are not broken down to a project level. Similarly, literature reviews such as Syed et al. (2020) only highlight overarching challenges. Jimenez-Ramirez et al. (2019) only investigate the phase of discovering process flows resembling rather a procedure model for task mining than complete RPA projects.

Data collection and suggestion.
To examine the current state-of-the-art and provide our first contribution, we conducted a systematic literature review following the recommendations of Webster and Watson (2002). While we were aware of the limited scientific research in this area, we still considered a literature review more promising to structure the domain than reviewing unstructured material from the Internet or forgoing the opportunity for sensitizing altogether. From the analysis of the articles, we designed a first iteration of the framework. In the second iteration, we conducted semi-structured interviews to verify the first iteration of the framework  Fig. 1 Research methodology based on Vaishnavi and Kuechler (2015) and adapt it according to the input we received from the interviewees (Edwards and Holland 2013;Paré 2004). The interviews were recorded, anonymized, and transcribed (Kuckartz 2014). To extract information from the interviews, we coded the transcripts iteratively (using open and axial coding) and analyzed them with the grounded theory approach of Strauss and Corbin (1994). 1 The majority of the data was coded by a single coder. In line with O'Connor and Joffe (2020), intercoder reliability was obtained by coding a sample of the data by an additional person. Code interpretation and analysis was a joint activity of multiple authors. During the workshops, we discussed the rationale of the RPA framework with the participants. Then we explored one representative real-life RPA case with respect to the phases and stage of the framework to judge the framework's suitability to prescribe actions and to identify remaining deficiencies in application. All workshops were recorded.

Development.
Based on the evaluation of the structured literature analysis through the interview study, we combined the identified stages and phases from both analyses. The first version of the framework emerged from the results of the literature analysis, which were adapted and supplemented by the expert interviews. If stages from literature were not considered applicable and not considered relevant in practice by the experts, we removed them. On the other hand, when new stages were identified by the experts, we added them to the framework. After the evaluation workshops, we revisited and slightly adapted the framework to its final form to provide our second contribution.
Evaluation and conclusion. Our evaluation was informed by FEDS Framework (Venable et al. 2016) to "demonstrate the utility, quality, and efficacy" (Hevner et al. 2004, pp. 83) of our design artifact. Due to the nascent nature of our research with the absence of general recommendations for RPA implementation, we decided to implement a two-staged naturalistic, summative evaluation based on a human risk and effectiveness strategy (Venable et al. 2016). First, we presented the framework to the interviewed experts again and collected their feedback. Second, we evaluated the applicability of the revised and refined version of our framework in multiple workshops using real-life cases. We conducted online meetings with multiple companies and applied the framework to their respective situation. We used their input to finalize our framework as outlined above. The learnings from the workshops constitute our third contribution. Please note that for the sake of readability, we have combined the learnings from the interview study and the workshops into a single section, before we present the framework.

3
A framework for implementing robotic process automation… 4 Literature review For our systematic literature review, we searched in the databases AIS Electronic Library (AISel), ACM Digital Library, Business Source Complete, EconBiz, Emerald Insight, ESCBOhost, IEEE Xplore Digital Library, Research Papers in Economics (RePEc), and ScienceDirect for the search term "('robotic process automation' | RPA)" in title, abstract, and keywords where available. 2 We screened and then analyzed the full text of the resulting 541 hits for articles that contain stages of RPA projects and conducted a forward/ backward search to identify case studies that were not listed in the databases. This was important as due to the novelty of the technology several well-cited publications have not been published in peer-reviewed journals or conferences but as working papers. We examined these non-peer reviewed contributions critically for their relevance and rigor. The final set of articles comprises 35 examples of RPA implementation projects. See Fig. 2 for a quantitative overview of the literature review process.
Most of the articles are case study reports and their analyses. Other articles focus on RPA software, RPA and artificial intelligence, methodological support for RPA, and RPA and society. During the literature review, we have analyzed the 35 contributions in terms of their content for stages or phases within RPA projects. Across cases, we identified similar patterns, documented and grouped them together into stages. Subsequently, we checked all contributions again for the occurrence of these patterns. Table 1 illustrates the distribution as well as the number of occurrences of the phases or stages that we found across the different case studies. In addition, we segmented the contributions by the count of stages they used.
It is apparent that most contributions only consider between three and five stages for RPA implementation projects, while only six contributions consider eight stages for RPA implementation projects. While this may be due to the limited space and specific focus on selective research questions in scholarly publications, not all case studies had page limits but were project reports. Hence, we assume that this lack of comprehensiveness can also be attributed due to the aforementioned lack of methodological guidance on the systematic design, development, and evolution of RPA projects.
· · · · · · · 7 1 3 A framework for implementing robotic process automation…  Furthermore, while some stages such as proof of concept (PoC) are ubiquitous (n = 30), and most cases use some sort of process selection (n = 22), business case creation (n = 20) or RPA demand (n = 20). Few cases approach RPA projects in a structured fashion early on or consider the long-term benefits and challenges: that is, not many cases report on a structured screening of technologies (n = 9) let alone provide thoughts on long-term service (n = 5) or the transfer (n = 3) of results in future RPA projects.
In summary, our literature review summarizes the current state of academic literature on the different phases and stages within RPA implementation projects and, thus, serves as our first key contribution. Table 2 provides a short description for each stage.

Overview of interviews
Using RPA software ourselves, we identified and contacted practitioners from the discussion group Robotic Process Automation (RPA)-Practitioner Network at the social media platform XING. Overall, eight experts with different backgrounds in terms of roles, industries, and company sizes agreed to share their experiences in an interview. We understand the term expert as someone who possesses special knowledge that can only be attained under special circumstances, that is in our case someone who has participated in at least one real-life RPA project. We summarize the interviewees and their backgrounds anonymously in Table 3. Since these experts were from German-speaking countries, the interview study was conducted in German and the concepts were later translated into English language.
We opted for telephone interviews to enable synchronous communication and enable inquiries across a distance. We followed a semi-structured interview guideline with three parts: (A) background information and skills, (B) alignment between theory and practice as well as (C) discussion of the identified preliminary stages. To align theory and practice, we asked general questions in (B) about the how and why of their RPA project. As an example, this allowed us to distinguish theoretical and practical aspects when developing a PoC. Following that, in (C), we demonstrated the preliminary framework derived from literature. Here, the experts critically discussed the usefulness, sequence, and completeness of stages and framework as well as provide recommendation for changes. The questions could be answered openly to include emerging ideas. The interviews have been recorded, transcribed, and the data has been coded and analyzed based on the grounded theory approach by Strauss and Corbin (1994). While (A) and (B) were conducted without any preconceived ideas, (C) was based on a review of the substantive literature to enhance theoretical sensitivity (Thistoll et al. 2016). In total, our audio recordings for the interviews have a length of 583 min. This is equivalent to 150 pages of transcriptions. 3

Overview of workshops
In a bid to apply and learn, we used our consolidated framework in workshops with small, medium, and large enterprises that recently dealt with RPA. With each workshop, we focused on a different industry to evaluate our framework broadly. Each workshop covered one real-life project and was conducted with one or multiple employees from the different companies and lasted approximately two hours. Generally, the employees we talked to were functionally responsible for the automated task or technically responsible for the development and operation of the software robot. Table 4 provides an overview of the cases. The workshops were conducted in German. 4 In each workshop, we asked the participants to explain the frame within which the RPA project was conducted and to detail the process's context as well as its activities and associated applications. Then, we detailed each stage of our framework and discussed how the respective projects followed similar stages or may have been informed by the framework if it had been available as a prescription at the outset. In particular, we discussed how helpful stages, which the respective projects omitted or conducted in another order, might have been in the short-and long-term. At times, the participants took notes to revisit their stages inspired by our discussions in particular in terms of rollout as well as adoption and scaling. After each workshop, we revisited the consolidated framework and annotated the workshop results. Finally, we evaluated all annotations to revise the framework based on the summative feedback of the workshops. In the following, we briefly introduce the workshop companies and the concrete processes that were implemented in the respective RPA projects. SYSTHEMIS AG. 5 (SYSTHEMIS) is a German software development and consulting company. It was founded in 2009 as part of the Prof. Thome AG group. Most of SYSTHEMIS day-to-day business is focused on consulting work. Thus, SYS-THEMIS has to create multiple reports such as a proof of performance report on a regular basis. Since, those reports are repetitive and time-consuming processes, SYSTHEMIS integrated RPA into their company through an internal initiative. In doing so, SYSTHEMIS aims to enable employees to focus on more critical tasks as well as reduce reporting mistakes due to human mistakes. They identified the process proof of performance as a suitable RPA pilot. In the process, an employee has to import and export data from multiple systems into a calculation software to generate a report, before sending a report as well as an invoice to the client.
Sparda-Bank Hessen eG. 6 (SBH) is a German cooperative bank located in the federal state of Hesse and connected to the Sparda-Bank association, with more than 355,000 clients and 36 subsidiaries. In course of ongoing digitalization efforts, SBH tried to overcome inherited burdens within their heavyweight IT and to determine potentials for process automation. On the one hand, SBH aims to automate repetitive tasks through RPA to free up human resources for more complex tasks. On the other hand, they aim to offer new services for their clients due to improved speed and frequency of software robots as well as due to improved data quality. Thereby, SBH is using a top-down approach driven by middle management to integrate RPA into the process landscape involving external consultants and engineers of Roboyo GmbH.
In our workshop, we discussed the process compensation for early termination. RPA enables SBH to provide each client at any time with a comprehensive calculation about additional fees for unpaid interests, if they plan to cancel existing contracts before the end of term. Before automation, this process was manual and only executed at the clients' request due to the tedious manual tasks involved, limited human resources, and legal requirements. The process comprises opening custom software as well as an e-mail client, checking for new requests, and extracting necessary client data for transfer into a calculation software, before forwarding the generated report to the requesting client.
Siemens AG. 7 (Siemens) is a German multinational conglomerate company active in the areas infrastructure and cities. With over 290,000 employees and a revenue of over 58b Euro, it is one of the largest corporations in Germany. Due to its size, the RPA initiatives in the company happen decentralized in the different areas of the company. The process we discussed in the workshop was modeled and automated by the RPA consulting firm ProBotic GmbH.
In the workshop, we discussed a data aggregation process that imports data from multiple sources into a management dashboard. The process involves the extraction, preparation, and integration of data into a new system. The original process was time-consuming and only performed on a weekly basis. After the introduction of RPA, the task was run daily, so that more timely data could be included into the dashboard.
Blanco GmbH and Co KG. 8 (Blanco) is a German manufacturer for kitchen sinks, founded in 1925 with approximately 1500 employees generating a turnover of about 395 m Euro. Blanco used a bottom-up strategy, whereby different divisions focus the automation of their respective processes. In our case, the finance department identified eight potential processes for automation to address three key issues within their processes. First, they wanted to increase the quality through standardized process execution and the reduction of human errors. Second, Blanco wanted to free employees from repetitive tasks. Third, as a long-term result they want to compensate for employees leaving the company due to retirement. In our workshop, we discussed the process forecast of liquidity, in which three specially trained employees extract data from different applications and transfer it into report generation software. Due to strict time constraints, the process must be completed within three days at the end of every month. As a result, currently the absence of employees can hardly be compensated. Applying RPA in this process enabled Blanco to be more robust towards circumstances such as sickness or employee turnover. Blanco also enlisted the support of consultants from Roboyo GmbH. Weleda AG. 9 (Weleda) is a natural cosmetics company based in Switzerland with over 2500 employees and a turnover of 429 m Euro. Besides natural cosmetics, the company produces pharmaceuticals. Therefore, the introduction of software is highly regulated and provides additional challenges for RPA. However, as automation of processes can reduce human error sources and therefore help to comply better with regulatory requirements, Weleda is currently looking into automating several tasks in the company.
During the workshop, we focused on the customer relations process participant management. Here, customers can register for events via an e-mail form. Their information needs to be extracted from the e-mail and the customer must be registered for the event in the CRM system. This task may fail and the exception needs to be handled. It was not possible to automate the process fully with RPA. Today, an employee is provided with additional information and hints to shorten compensation in comparison to the formerly unsupported handling of registration errors.

Discussion of findings
When analyzing the stages from the case studies in the interviews and workshops, the experts generally confirmed, compressed, but also expanded the findings derived from the literature review. Following the recommendations of the experts, we have also adjusted the naming of the stages.
Identification of RPA demand. The experts gave various arguments for this stage. I1 considers the potential to automate manual tasks to be particularly important. I7 identifies the potential especially for frequently repeating and more formalized processes. Further I7 and W2 added that many employees are already aware of improvement potential for certain processes. Nevertheless, this identification has to be precise and is time consuming and resource intensive (W1). I5 sees potential for increasing the size of the company while keeping the number of employees constant. W4 also considers the development of new services for the customer because of to the advantages of RPA. In W3 and W5, the awareness about RPA technology was triggered by external consultants. The identification of the demand was guided by consultants as well.
Alignment with business strategy. While not present in literature, the interviewees and workshops stressed that any company should address questions regarding the usefulness and benefit of introducing RPA at an early stage. Therefore, an alignment with business strategy must be performed at an early stage to determine whether and how RPA can positively influence corporate targets. The need to acquire adequate project support from management justifies an additional stage to reflect this (I5, I7). I5 describes this as follows: "I actually have to integrate the corporate strategy into this. That is quite decisive. Because there has to be a corporate goal. It is not a departmental goal or anything else". Likewise, in W2 the use of RPA within the company was a decision made by management to improve process handling across the process landscape and further reevaluate existing processes to purify the landscape in the course of this. In contrast, W4 mentioned the integration of RPA on a business division level but with the involvement of management at the beginning. On the one hand, this ensures long-term management support by providing incentives. On the other hand, it reduces concerns from work council. W3 mentioned, that external consultants should be included already in this stage, since they can accurately inform management and work council about the capabilities and risks of RPA.
Screening of different (RPA) technologies. I1 and I5 point out that this stage is often skipped resulting in the decision to use RPA due to its perceived benefits. On the other hand, I8 remarks that technology selection decisions are made individually for each case, knowing that other automation technologies may be more suitable. I3 also explains that other simpler technologies are often sufficient: "We often find that this can be done with a simple Excel macro, so we can quickly add an interface with batch files or other things". Therefore, this stage may have to be adapted individually for each company. Since RPA mostly addresses process automations across different software without API, W2 and W4 consider RPA to be a bridging technology without a defined expiry date.
Process selection. Almost all experts (except I7) named execution frequency as a key indicator for process selection. Standardized processes are also particularly relevant (I1-2, I5-8, W1-2). Many experts (I1-2, I5-6, I8) considered further technologies such as process mining to be particularly relevant to shorten and improve the selection process. In addition, processes with low complexity as well as few exceptions (I3, I5, I8, W2, W4), which are financially lucrative to automate (I5), should be used for initial RPA projects. I3 notes though that simple processes may only be appropriate candidates "if you want quick wins and collect low-hanging fruits". Nonetheless more complex processes can also be selected, but in this case more time has to be spent in the RPA pilot stage (I3). W4 consider the future retirement of employees as an additional factor for process selection. W5 stated, that they prepared a questionnaire for the departments to help them identify processes that are suitable for RPA. They also differentiated between different automation techniques. Similarly, a determination of the process selection can be done with a balanced score card (W4). Lastly, many experts recommend beginning with back-office processes in departments such as accounting and finance (I1, I3, I5, I8, W1-3).
RPA software selection. When selecting RPA software, the most important point is cost (I1-3, I6, I8, W1-4). Further, W2-4 consider the ability to use a fee trial version as important to evaluate an RPA pilot. In addition, factors such as reputation (I5, I8), support and software training by consultants (I4, I8, W2, W4), support by the RPA vendor if no external consultants are involved (I6), community support (W1-4), transparency in the creation of robots (I3, I7, W2), stability (I2), manageability (W1), IT security (W4), or certification and compliance (W5) should be considered. Further, all workshop participants prefer to use a low-code platform as well as a more modular programming structure, which enables them to automate less complex robots on their own (W1-5). Despite the availability of some objective criteria, I6 illustrates that some selection RPA software processes rather proceed like "someone in the company […] is convinced by a tool and that's it" or that "RPA is so new for many that they cannot objectify the decision as there are so many factors involved that they do not know about", resulting in a non-standardized selection process (I8). Nonetheless, W2 sees the companies' IT support in the position to propose and support different RPA vendors. Also, W4 as well as I5 and I6 mentioned the integration of IT support at this stage as important to overcome technology and permission barriers for the subsequent development and integration of software robots into the IT landscape. Hereby, expert knowledge from RPA consultants can be helpful to allow for more rapid and less stressful development of the software robots (W4).
Proof of concept and RPA pilot. While in literature the term PoC is frequently used, we noticed that due to the lightweight development of RPA, the implemented robots are rather used as pilots than as prototypes. Therefore, instead of focusing on the feasibility of an RPA implementation, practitioners directly develop robots for use. According to the experts, an RPA pilot should focus on simple but relevant processes (I3, I6-7, W1-4). It is important "so that everybody sees-aha-how does it work, what is it about?" (I6). Important tasks are the evaluation of the technical and financial feasibility (I1, I5, I6) and the comparison with the previous process flow (I7). A fast and less expensive RPA pilot will demonstrate the potentials of RPA and thus increases the long-term acceptance of RPA within the company better (I3). Nonetheless, W3 stated, that it is more important to show "the magic" of what the technology can do, since "employees have no understanding of it, they want to see it" (I6). A pilot is also used for test alignment with corporate governance (I3, I6). While I6 states that "technical feasibility is more or less irrelevant" in an RPA pilot, W5 emphasized that the selected process should represent the technological landscape to already prove technical feasibility for similar processes. In contrast to W4, W2 recommend involving the work council at this stage at the latest.
Evaluation of business case. The experts agreed on the creation of a business case as an important stage. On the one hand, the business case is supposed to compare the automated processing times to manual processing times. On the other hand, the aim of the business case is a proof that the change will reduce cost (I1, I4-8), is more efficient (I7), or leads to a decrease in processes execution errors (I1). Economic efficiency depends on the number of processes, which can be automated, as a high number of processes can result in a faster return on investment (I4-5, I7, W1). To reach this goal early as possible, W2 uses annual RPA software licenses to be more flexible with respect to the number of their robots. I4 and I7 recommend using consulting services to benefit from their know-how from prior projects due to the novelty of the technology. Further, W4 use a continuous evaluation of the business case to ensure the management support by presenting the state of development on a regular basis, for example by providing efficiency reports (I5). In contrast, if the company's management is already convinced of the application of RPA (I8, W2), companies can focus less on a detailed monetary evaluation, which is sometimes hard to put into effect (W2).
RPA rollout. The stage of RPA rollout identified in literature was not considered explicitly as an individual stage in the interviews, but as a necessary procedure within any implementation (I1, I6). However, the workshop participants highlighted several specificities of RPA rollout. W3 emphasized, that from a consultancy's perspective the hand-off of the software robot to the customer along with an extended support period and appropriate documentation is extremely important. It cannot be left out. W1-5 pointed out that the synthetic yet anthropomorphic nature of robot coworkers requires extra care when "hiring" them. W2 went as far as giving the first robot the name "Robert Bot" and presenting "him" in the employee magazine. In addition, they provided trainings for employees on the topic of RPA to raise awareness. W3 expects employees to take initiative and suggest further potential processes for automation if properly involved. Further, W2 pointed out that the robot needs to be treated like an employee in terms of access rights and single sign-on. While W4 copied and transferred the permission rights of the process owner, W2 plan to define a new permission matrix for software robots. In addition, W2 had to split up process execution into multiple robots due to legal regulations, as one employee (or robot) is not allowed to execute a process in its entirety.
Long-term service of RPA and transfer. While long-term service is about the ensuring the operation existing software robots, transfer implies the handover of knowledge from previous RPA projects to new projects. In literature, these aspects are often addressed separately. In contrast, the analysis of the interviews suggests that the experts consider these aspects to be part of the CoE, RPA support processes as well as the scaling of RPA services stage (I1-2, I6-7).
Adoption and scaling. Within this stage, the experts emphasize the need to set up a competence center (I1, I3-4, I7). After all, "there is, of course, no point in always sourcing this from an external consultancy. One must also build up one's own competencies" (I4). Thus, we noticed within the workshop and expert interviews that external consultants support companies until these companies can perform independently (I6, W2-4). The competence center can also create templates and training for software robots (I1-2) and increase the complexity of the processes being implemented (I2, I8, W1). I5 aims to integrate artificial intelligence into software robots to archive more flexibility for process execution. Further, W4 describes the development of modular subprocesses, which can be reused in future RPA projects, whereby a robot initiates different already existing sub-automations. I3 and I5 highlight that there is practically no end in automating processes with RPA since you always discover new processes while automating. Nevertheless, I6 recommends automating only one additional process per month initially, while subsequently the number of 1 3 parallel RPA developments can be successively increased (I8). After the successful implementation of the first software robot, W2 expects a deluge of requests for robots, which need to be prioritized with new governance mechanisms. (I3-4, W1-5). This is a direct result from hiring RPA experts. I6 points out that "In Germany, you currently have to look for experts for RPA like a needle in a haystack". If introduced, CoE should be positioned on the business side (I3, I5, I8, W2, W4) and represent a central department (I2-5, I8), whereby in smaller enterprises the CoE can also be placed within the IT department (W1, W5) or as a hybrid department (I2). An executive department as an organizational form would also be feasible (I1, I5, W4). The goal of a CoE is to handle the operational and strategic day-to-day activities of RPA initiatives (I5, I7). When looking into a potential CoE, at least RPA developers and business analysts should be involved (I3). According to W4, employees from the IT department should also be included in the CoE to ensure IT infrastructure support. Also, W4 stated, that is important to define specific responsibilities within the CoE. Further this enables a fast and a clear communication of responsibilities to new or external employees. At the same time the CoE can be used to take over BPM functions (I5) as well as orchestrate existing RPA licenses and resources efficiently as possible (W2). In addition, the CoE should support different departments in process prioritization (W2). In contrast to literature, W4 state that while the development of a CoE from the beginning is advisable, it is ambitious and in practice almost impossible.

Center of excellence. Centers of excellence (CoE) should be introduced especially in larger companies
RPA support processes. Long-term service of RPA and transfer were not considered as stages of their own by the interviewees, but these stages can be integrated into other stages detailed above or consolidated into a stage of RPA support processes. In this respect, W2-4 see the necessity to communicate the application state of RPA projects with the management to ensure a long-term management support. In addition to maintaining the access right assigned during rollout, W5 has strictly defined guidelines and restrictions for which employee can interact with which robot. Likewise, W4 also points out the urgency to involve IT support, as they struggled with the seamless development of software robots due to technical barriers across the IT landscape. This becomes even more evident, when the IT support is a central department within the company. Lastly all workshop participants agreed on the necessity to develop governance guidelines (W1-5). Since, a software robot is mostly executing existing processes, W4 suggested reusing existing governance guidelines.
Ordering of stages. In summary, the experts agreed to the stages we proposed. Some argued about their ordering. In the end, most experts agreed that the stages are never purely sequential but overlap. Table 5 provides an overview of their suggestions, which informed the ordering of stages in our framework. We confirmed this ordering in the workshops.
Nevertheless, our evaluation revealed that the final framework should have a high degree of flexibility, as there is no generally valid procedure-especially with regard to the concrete sequence of the individual stages-as it always depends on company-specific circumstances. Nevertheless, it is possible to make some explicit specifications, since certain stages are necessary for the execution of the subsequent stages and therefore cannot be moved around arbitrarily.

Framework for implementing RPA projects
In the following, we present our framework for implementing RPA projects first compiled in Sect. 4, consolidated and validated in Sect. 5.3. See Fig. 3 for an overview and the temporal relation of the phases and stages. With the presentation of our framework, we provide our second contribution.
The framework is divided into three phases for implementing RPA projects: initialization, implementation, and scaling. Some of its stages are performed once per project, while others are performed continuously. These continuous stages represent project-external influences that support concrete RPA implementation: in particular, this is the establishment and enhancement of a CoE. As the framework has been developed through 35 literature use cases as well as eight expert interviews and five workshops with different companies, it represents a comprehensive and actionable prescription to support the systematic design, development, and evolution of RPA projects in practice. Further, it is flexible and can be adapted to the different locales within distinct companies and industries. It allows for the integration of external consultants for more comprehensive RPA implementations as well as assistance in developing a CoE for knowledge transfer and continuous improvement.

Initialization, implementation, and scaling
Each RPA project runs through three project phases. In the initialization phase, identification, alignment, and technology screening are completed and the implementation phase stages of process selection, RPA software selection, RPA pilot, and the evaluation of business case start. All of the latter may involve external consultants (if the project is not run by an external consultancy in its entirety). The implementation phase completes all of these stages and ends with the RPA rollout. The scaling phase only starts after the RPA project has been completed and focuses on the adoption and scaling of results for further RPA implementations. All stages are complemented by a continuous cycle of RPA support processes and through a CoE. It became evident that the initialization phase differs, when only few RPA implementation projects have been completed in contrast to abundant experience with RPA implementation projects. As a result, companies well into their RPA journey tend to apply the initialization phase as a continuous cycle as well (W2, W4).

Identification of RPA demand
The first stage focuses on the identification of process automation needs and opportunities. Evaluating and determining current processes in enterprises for automation can be realized amongst other techniques with workshops, surveys, reviews as well as document analysis (Asatiani and Penttinen 2016). Additionally, the need of automation for processes can be verified in normal conversations within departments (Lacity et al. 2016b), (W1-2). Depending on the level of digitalization, enterprises can discover whether manually executed processes should be automated using existing IT (Schmitz et al. 2019), (I5, I7) and process and task mining (Geyer-Klingeberg et al. 2018;Leno et al. 2020). This also enables companies to consider the need for digitalization and the further maintenance of their processes within their IT landscape (W2).

Alignment with business strategy
Companies need to consider importance, usefulness, and added value of introducing RPA early on (I3). That is, they need to identify RPA success factors for their organization (I7). Hence, early alignment with business strategy is important to understand where RPA can positively influence strategic goals (I5, I7, W2). Otherwise, the application of RPA should not be considered further than a pilot to gather interest. In addition, organizational issues should be addressed already at the start of a project, for example questions of principle about involved roles and functions need to be asked and answered (I3, W4).

Screening of different (RPA) technologies
The screening stage helps to determine whether an organization can apply RPA usefully and which kind of technology is most suitable to solve the problem. This may entail that RPA turns out not to be the first candidate for automation. The implementation of the methods for screening potential depends on the situation and can be executed proactive or exploratory (Hallikainen et al. 2018), (I1-4). Rapid process reengineering, aspects of machine learning, custom-tool remediation, and traditional BPM systems can be alternate options to automate processes and need to be considered besides RPA (DeBrusk 2017). While RPA is often only considered as a bridging technology (W2-4), it can be a mid-term solution if the establishment and integration of APIs is considered to be infeasible at the moment (W1).

Processes selection
After verifying RPA as a practicable and efficient technological solution to an enterprise problem, this stage focuses on the prioritization and selection of process candidates for automation. Process selection requires information from end users and  stakeholders to make better decisions (I4-5). Moreover, taking into account the processes of the involved departments can significantly improve business understanding (Schmitz et al. 2019). Many experts recommend starting with back-office process in departments such as accounting and finance (I1, I3, I5, I8, W1-3). Most of the case studies predominantly consider processes with a low complexity for initial implementation and testing (Fersht and Slaby 2012;Hallikainen et al. 2018;Lacity et al. 2016b;Schmitz et al. 2019), (I8) as stakeholders often only become aware of the inherent challenges by dealing directly with the issue at hand (Hallikainen et al. 2018), (I7). Therefore, sometimes they adjust and improve the process execution flow before automating it (Dias et al. 2019;Šimek and Šperka 2019). In addition, the degree of standardization and the process stability should be considered for the selection because those processes are typically better understood and documented (Lacity et al. 2016b), (I1-2, I5-7). Further, processes prone to human errors (I6, W2), ensuring a company's flexibility due to retirements of employees (W4) as well as providing new services to customers (W2) can be considered as indicators. Generally, the execution frequency and volume of processes indicate high automation potential and promise an increase in efficiency (Hallikainen et al. 2018;Schmitz et al. 2019), (I1-8). Wanner et al. (2019) have proposed a candidate for a quantifiable method of process selection for RPA projects. Their approach also entails that the relevant processes are already digitized and therefore have a digital inputs and outputs, which is mandatory for RPA. Non-digitized processes must be digitized first.

RPA software selection
This stage focuses on the selection of suitable RPA software for automation. Among other things, the cost of the software (I1-3, I6, I8, W1-4), skill requirements as well prior (successful) implementations represent important factors in the decision-making (I1) although the market seems to mature quickly (I2) resulting in rather organizational than technical factors to consider for software selection. Further criteria include skills availability (with external consultants), community support, vendor support, vendor reputation, ability to develop software robots with low-code programming, software maturity, manageability, security and data protection of RPA cloud solutions as well as free tiers and license flexibility (I1-4, I6-8, W1-5).

RPA pilot
While many use the term PoC for initial or early RPA implementations, we refer to software robots prior to rollout as pilots. While their implementation is done to conduct a first feasibility assessment, the robot's lightweight nature entails that the code is often suitable for production and the implementation can be used long-term (W2-4). Thus, a pilot serves as verification of the functionality as well as the technical and financial feasibility of RPA technology for the given case (Lacity et al. 2016a;Lamberton et al. 2016), (I1, I5-6) to demonstrate RPA to stakeholders (W3) and later be transferred to production. Verification factors may include process quality or return on investment calculations (Lacity et al. 2016a), (I1, I5, I7). For these analyses, it is recommended that a pilot should be executed for several months to provide a detailed data-driven analysis (Lacity et al. 2016c).

Evaluation of business case
The business case is essential to bridge the gap between the RPA pilot and the subsequent adoption and scaling of RPA services within the company (Lamberton et al. 2016). Defining a business case is also highly recommended to ensure long-term management support (Willcocks et al. 2015b), (W4). In order to gather such support, typical indicators such as processing times, (human) error rates, infrastructure, and IT cost should be considered (Fersht and Slaby 2012), (I1, I4-8, W2, W4). A technology-based support in process discovery can be pursued through process and task mining (Geyer-Klingeberg et al. 2018;Leno et al. 2020;van der Aalst et al. 2018a, b), (I4).

RPA rollout
The RPA rollout comprises all activities concerned with making available and activating the implemented software robot(s) in the enterprise's daily operations. While some RPA rollout strategies may not be RPA-specific but apply for many software projects, RPA rollout is a necessary and unique stage (I1, I6) and should be subject to further research including socio-technical aspects of human and machine cooperation (Syed et al. 2020). Apart from common tasks of any software rollout, this stage includes the onboarding of the software robot in terms of rights management and acceptance by its co-workers. Rollout can be accompanied by RPAspecific trainings, company-internal newsletters as well as general sensitizing to increase acceptance among employees, resulting in employee proactivity to uncover further potential for automation (W2).

Adoption and scaling
After a successful RPA pilot and a well-defined business case have resulted in a successful RPA rollout, an extension of the RPA portfolio can take place, facilitating the creation of RPA libraries and related templates (Schmitz et al. 2019), (I1-2, W4). The complexity of the future processes should increase continuously so that the RPA team can understand RPA and the automation feasibility of the corporate processes gradually (I2, I8). The integration of external service providers can provide support for more complex processes as well (I1, I4, I7). The automation of further processes also requires a step-wise increase in software licenses (Lacity et al. 2016a;Willcocks et al. 2015b), (I7, W2). At the same time, the employees affected by the introduction of software robots must be involved at an early stage to ensure a continuing positive working attitude . With an increasing number of RPA implementation projects, the stage of adoption and scaling is gradually transferring into a continuous cycle of RPA support processes. It is also recommended to automate not more than one process per month in the beginning (I6).

RPA support processes
The literature, the expert interviews as well as the workshops revealed that continuous support from management is necessary (Willcocks et al. 2015a) as with any project to enable a consistent financial support (I1,4) as well as a strategic orientation and awareness about the capabilities and limitations of software robots (I1-3) even though software robots can be established and budgeted at the department level. Further, the adaptation of governance guidelines is a practical requirement (W2-4) as is ensuring IT support at the beginning of an RPA project to deal with less obstacles when scaling (W4). Likewise, the integration of change management including robot retirement and IT integration is essential to support continuous changes within the processes towards adjustments in the RPA implementations. They ensure the integration of RPA maintenance and operations in production and cooperation between humans and machines.

Center of excellence
The implementation of software robots using RPA within the company should be accompanied by setting up a CoE to support the definition of necessary roles, skills, key performance indicators, etc. (Lacity et al. 2016a). The tasks of the CoE vary from the monitoring and maintenance of the software robots to the identification of appropriate further processes for automation (Anagnoste 2018), (I1, I3, I5, I7, W2, W4). The CoE is also responsible for process innovation, the development of new services, and efficiency improvements (Aguirre and Rodriguez 2017), (I6, W2). Organizationally, the CoE is typically not anchored in the IT department, but on the business side (Lacity et al. 2016c), (I3, W2-4). Furthermore, it is important to note that implementing a CoE requires resources, so this stage is usually only feasible for large companies (Anagnoste 2018;Willcocks et al. 2015b), (I3-4, W1). Small and medium-sized enterprises should consider making available at least one full-time equivalent to manage RPA knowledge and chaperon projects (W1). Establishing a CoE at the beginning of a project (I6) is ambitious and may not always be feasible. At the latest, it should commence with the stage of RPA software selection (W4). Considering a CoE only when attempting to scale will lead to inefficiencies.

Discussion
While all experts and workshop participants considered the framework as meaningful, relevant and instantiable, we noticed minor differences between literature and practice, which mostly result from company-specific requirements leading to different decision behaviors and criteria. The experts and workshop participants confirmed that the framework is sufficiently flexible as well as complete. In addition, the workshop participants signaled to inform their procedures with insights from our framework for their future RPA projects. Companies that already used a structured approach were pleased to see that their approach often was consistent with our framework. While eight interviewees and five workshops only suggest limited authority and external validity in quantitative research, our study was largely qualitative and throughout the interviews and workshops, we noticed a state of theoretical saturation, where the marginal return of additional data became neglectable (Strauss and Corbin 1994). We observed this saturation in all relevant dimensions.
From the process of specifying our framework and the framework itself stem several theoretical and practical implications that we discuss in the following. Syed et al. (2020) and Gotthardt et al. (2019) propose several challenges revealing a lack of methodological guidelines for adoption, systematic design, development, and evaluation for RPA projects also considering socio-technical aspects. Our goal was to address this gap.

Theoretical implications
In response, our framework provides procedural guidance for RPA implementation projects. We primarily focus on RPA projects at the beginning of a company's RPA journey. Thus, we presented the adoption and scaling of RPA services stage in a compact manner. The maintenance and enhancement of software robots provides manifold challenges and opportunities which may justify a framework of its own. Also, during the workshops we noticed that companies tend to be more flexible with this stage as it mainly depends on company-specific circumstances and requirements and is not yet of immediate practical concern. Thereby, companies parallelize existing knowledge or reuse it to shorten the execution time of the different stages. Looking at the scholarly literature, we noticed the absence of flexibility and parallelization between the stages of RPA projects. As our framework is based on literature and practical experience, it is not exploring the unknown of long-term RPA use and, thus, lack full coverage of RPA evolution aspects. That is for example, we did not discuss a stage of transitioning, where the bridging technology RPA is replaced by heavyweight IT as it was not present in literature and it was only brought up as a side-topic in one workshop. We consider it a special case of retirement, where the software robot is shut down and replaced by a human again or by new software. The absence of these discussions in theory and practice point to the necessity for research to shift focus from the initial phases of RPA engagement to the looming challenges of RPA operations, transitioning, and retirement not present in the metasynthesis of Syed et al. (2020).
Further, the presentation of the framework as well as the evaluation through the workshops has revealed that an own framework for RPA is warranted as RPA differs from traditional IT automation not only in the technical dimension but also in an organizational and social dimension. While the technical difference of side-effectfree lightweight UI layer access as opposed to heavyweight IT (Penttinen et al. 2018) should be immediately evident, we are only beginning to understand RPA's potential for rapidly automating the long tail of processes (Imgrund et al. 2017) lately termed hyperautomation or citizen automation. Novel organizational structures and procedures are necessary to enable but also to regulate emerging decentral initiates using low-code environments. Similarly, research and practice has not yet fully embraced RPA rollout and operation as a socio-technical problem: software robots exhibit anthropomorphic traits such as their need for human-like access rights, the legal necessity for separation of concerns in process execution, as well as, generally, their human-like demeanor. That is, the anthropomorphic consideration of software robots as full-time equivalents is an important aspect of RPA adoption and represents a key aspect in its socio-technical implementation van der Aalst et al. 2018a, b). The latter two dimensions constitute future research opportunities.

Practical contributions
With regard to methodological guidelines for project design and development, traditional software development procedures especially in the context of BPM are well investigated and formalized (Dumas et al. 2018). These projects (e.g. also for enterprise systems) follow a structured sequential lifecycle or procedure model for implementations to account for the heavyweight nature of software integration (Penttinen et al. 2018;Willcocks et al. 2015a). For example, while traditional software development requires a pre-implementation phase with a specific cost-benefit and requirements analysis (Jagoda and Samaranayake 2017), we mostly observed an experimental RPA implementation with a continuous assessment in our workshops. Compared to traditional software development, this also results from the relatively low costs associated with an initial RPA implementation (Axmann et al. 2021). As explored above, RPA primarily targets high-volume and low-variant processes that already exist or are easily conceivable due to their nature. That is, RPA can only replace what a human worker could have done by him-or herself already. This typically does not require the need of extensive process analysis or process redesign stages as reflected by our framework. The workshops confirmed that companies rather automate existing tasks as-is rather than optimizing them for software robots first. While this has drawbacks, rapid deployment would not be possible otherwise.
Consequently adjusting the process itself and the related software is typically not necessary in an RPA implementation project (van der Aalst et al. 2018a, b). Likewise, many project stages are handled simultaneously (Dias et al. 2019;Plattfaut 2019). In consequence, the implementation of RPA differs due its rapid and lightweight development not requiring APIs (Hofmann et al. 2020;van der Aalst et al. 2018a, b). Our framework reflects this through explicit stages that allow for concurrency. Further, the lightweight nature sometimes leads people to lose sight of diligence, for example regarding a business case or software selection. Moreover, RPA non-technical staff inexperienced with IT project management can now create software robots due to the availability of low-code environments. In response, our framework prescribes necessary activities for any project to avoid (unintentional) negligence.
Further, we noticed that interviewees from large enterprises tended to agree more than interviewees from small and mid-sized enterprises, which was to be expected due to their narrower scope of work. Due to the diversity of interviewees in terms of their roles, industries, and BPM knowledge, we do not expect the framework to have any significant biases. Our proposed framework guides practitioners to implement RPA projects within their companies. Due to the holistic and flexible nature of the framework, practitioners are able to orient themselves on which stages they may or may not need to apply for their RPA implementation projects. That is, smaller companies may need to trim the framework to their needs more comprehensively than larger companies. As an example, we noticed that within larger companies that, in particular when having a centralized IT support department, an early involvement of a CoE and further RPA support processes is mandatory (W2-4). Thus, not all stages need to be considered as necessary. By not only proposing different stages, but also revealing findings regarding these stages from exemplary interviews and workshops, practitioners may raise awareness of aspects that also need to be taken into account.
Regarding the social dimension of RPA, several workshop participants have begun to consider software robots as (virtual) employees rather than outright software systems. That is, their rights management in terms of software access and licenses resembles those of a human worker, they require a (virtual) desktop to work on, and-at least-the early implementations may even be presented in the employee magazines as new co-workers with given names. That is, their "onboarding" with regards to their co-workers can differ significantly from the presentation of a new software system.
Lastly, throughout the interviews and workshops we noted several reoccurring topics, which should be taken into consideration when embarking on RPA projects. First, the understanding of "what RPA does" and "what RPA does not" varies widely. This lack of understanding lead to Gartner's movement of RPA from the peak of the hype cycle of exaggerated expectations (Brant and Sicular 2018) to the trough of disillusionment (van der Meulen 2020). Second, while in one workshop RPA is used for the compensation of retirees, none of the case studies, interviews, or workshops associated RPA with the terminations of existing work contracts. Instead, we noticed that RPA is rather used for freeing up capacity or enabling new activities and thus enabling human workers to concentrate on value-adding tasks. In contrast, in the long term using (software) robots seems to be beneficial for the competitiveness of the company and thus for job security (Wanner et al. 2019). Third, although the interaction of business and IT in RPA projects was clarified by the experts, the understanding of RPA in practice can be increased by a detailed investigation of the interaction of these two areas. In the end, IT departments often only provide the RPA platform, while the functional business areas define the business logic of the software robots. This results in new challenges in an organizational dimension.

Integration with the BPM lifecycle
Finally, our research showed that a detailed analysis of the interdependencies between RPA and traditional BPM are necessary. The two approaches have many similarities and points of contact. Typically, RPA momentum originates from a BPM-friendly department or a BPM CoE.
As explained above, procedures to conduct BPM projects are readily available for use, most prominently structured in the form of the BPM lifecycle (Dumas et al. 2018). While RPA projects can be initiated and completed independent of any structured BPM activities, it makes sense to align larger RPA activities with ongoing BPM efforts. While this was not the focus of our research, we can deduce the RPA phase of initialization can take place before, during, or after the BPM phases of process identification through process redesign depending on the urgency of automation as a temporary bridge or the informed decision to automate using a software robot rather than BPM software. Conceptually, the RPA implementation phase takes place in parallel to the BPM process implementation phase, while timewise this may vary widely due to the shorter implementation times of software robots. The BPM process monitoring and controlling phase is interdependent with what we describe as the continuous cycle of RPA support processes. The RPA phase of adoption and scaling is a technology and knowledge infrastructure stage that needs to be approached once RPA is establishing itself in an organization as well-founded alternative to traditional process automation using BPM. That is, it extends the lifecycle with additional activities as well as it adds a further layer of sophistication to implementing RPA projects at a larger scale.
These considerations are based on the schematic lifecycle of traditional BPM present in many organizations. Novel, participative approaches such as hybrid BPM (Imgrund et al. 2018) will integrate BPM and RPA naturally as two means of automation in distinct central and decentral initiatives to be able address the processes in both, the short head and the long tail of an organization. This, too, constitutes new research opportunities.

Conclusion and outlook
In this paper, we investigated the status quo of RPA research focusing on the challenge of the systematic design, development, and evolution of RPA projects while considering aspects of socio-technical design and adoption (Syed et al. 2020). Following a structured literature review, an interview study as well multiple workshops to uncover differences and similarities between practice and scholarly literature, we developed a framework of three phases, nine project-based stages, and two continuous stages of project support. Our discrepancy analysis showed that there is a substantial overlap between theory and practice. Nevertheless, while promising concepts have already been developed in theory, companies have generally not yet addressed these issues in practice, especially if they represent long-term benefits such as establishing a CoE. In response, our framework can be considered as a prescription that can narrow the gap between theory and practice as all experts saw value in the framework. It provides clear methodological guidance on how to approach RPA implementation projects comprehensively and it is of practical value for companies as confirmed by the interviews and workshops. While it does not guarantee RPA project success, it provides a means to track progress and conduct RPA project in a structured manner.
Since RPA research is still in an early phase, there are many other issues that need to be addressed (Syed et al. 2020). Apart from the needs to consider further organizational and social dimensions beyond technical innovations, we observed the need for an in-depth analysis of the long-term economic viability and transitioning of RPA systems. This also includes the determination of the technological debt introduced by RPA, among other things, caused by superficial implementation and the resulting low level of application integration. Ultimately, we can conclude that RPA has already established itself in practice and contributes to achieving individual corporate goals. However, the technology is still in its infancy so that further innovations and improvements must follow to make hyperautomation a reality (Jiménez-Ramírez 2021).
Funding Open Access funding enabled and organized by Projekt DEAL.
Open Access This article is licensed under a Creative Commons Attribution 4.0 International License, which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons licence, and indicate if changes were made. The images or other third party material in this article are included in the article's Creative Commons licence, unless indicated otherwise in a credit line to the material. If material is not included in the article's Creative Commons licence and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder. To view a copy of this licence, visit http:// creat iveco mmons. org/ licen ses/ by/4. 0/.