A framework for implementing robotic process automation projects

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

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.⁴ 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.⁵ (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, SYSTHEMIS 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.⁶ (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.

Siemens AG.⁷ (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.

Blanco GmbH and Co KG.⁸ (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.

Weleda AG.⁹ (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.

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.

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 co-workers 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 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.

Center of excellence. Centers of excellence (CoE) should be introduced especially in larger companies (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.

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.

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

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

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

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

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.

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

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

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

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 RPA-specific 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).

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 (Lacity and Willcocks 2017). 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).

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.

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.

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.

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 meta-synthesis 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-effect-free 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 (Herm et al. 2021; van der Aalst et al. 2018a, b). The latter two dimensions constitute future research opportunities.

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.

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.