Keywords

1 Introduction

Digital transformation and external disruptions like the Covid-19 pandemic are increasingly impacting Business Process Management (BPM) [17]. Along this line, conventional Business Process Management Systems (BPMS), which are designed to support the end-to-end process definition, enactment, and automation of business processes [3], have several shortcomings [15]. For example, traditional process automation through deeply ingrained and inflexible business processes can hardly keep up with today’s fast-changing environment [17]. To this end, recent articles indicate the promising integration of BPM, specifically BPMS, with the emerging Robotic Process Automation (RPA) technology [4, 8, 9]. RPA is an umbrella term that merges robotics and business process automation and aims to automate repetitive, standardized, and rule-based tasks based on digital input, such as collecting, preprocessing, and transferring data [5, 21, 22].

A recent debate at the BPM Expert Forum [16] corroborated the practical and scientific relevance of an integrated BPMS-RPA platform and indicated potential benefits, particularly regarding a unified language for process modeling, such as the Business Process Model and Notation (BPMN). Additionally, several articles highlight potential integration synergies like improved process monitoring and error handling [8], process optimization [4], and human-bot collaboration [2]. However, profound academic approaches to examining concrete designs are scarce to date. Therefore, we contribute to the recent practical and scientific discourse by investigating the following research question:

How can BPMS and RPA be holistically integrated based on a consistent notation for process modeling and orchestration?

Grounded in Design Science Research (DSR) [13] and based on empirical data from 20 expert interviews, our contribution is threefold: First, we provide eight requirements for an integrated BPMS-RPA platform, indicating the suitability of BPMN as an underlying notation. Second, we propose an initial conceptual design of such a holistic platform based on a multi-layer process visualization approach and exemplify several components with a publicly available prototype. Finally, we contribute to the scarce literature by providing directions for further research and organizational practice on integrating BPMS and RPA.

This paper is structured as follows: Sect. 2 provides the relevant background while Sect. 3 introduces related work. Our applied research methodology is described in Sect. 4. The requirements and design of the proposed BPMS-RPA platform are presented in Sect. 5, followed by insights into the evaluation process and the prototypical implementation in Sect. 6. We conclude with a discussion in Sect. 7, covering our study’s theoretical and practical implications, limitations, and recommendations for future research.

2 Background

In the following, we detail the basic terms and concepts relevant to this paper, i.e., BPMS, BPMN, and RPA.

2.1 Business Process Management Systems

BPM is considered a holistic concept to control and improve business processes, including identification, discovery, analysis, design, implementation, and monitoring. To this end, BPMS enact various aspects of BPM, such as the modeling, analysis, and execution of business processes [3, 15]. BPMS typically consist of a Process Modeler to define and configure the process models, which are stored in a Process Model Repository and deployed to a Process Engine for coordinated execution [27]. Besides, diverse application programming interfaces (APIs) are provided to integrate external software, e.g., for process analysis and monitoring [3].

BPMS usually build on BPMN, which constitutes the de-facto industry standard for process modeling and orchestration [24, 27]. This standardized and readily understandable graphical notation allows for visualizing and implementing business processes with varying complexity levels. BPMN provides multiple modeling elements to describe the process behavior, interrelations, and involved stakeholders and translates this information into BPMS execution languages [3, 12]. Generally, activities pose core elements of BPMN process diagrams and can be distinguished into tasks and sub-processes. The latter represent compound activities that can be subdivided into finer levels of detail, whereas tasks constitute atomic activities already at the lowest level of process detail [12, 24].

Considering the different needs of process model stakeholders (e.g., managers, process owners, business analysts, or programmers), van Nuffel and de Backer [24] propose a multi-abstraction layered approach with defined relationships to model and structure business processes. Their framework includes five levels with descending degrees of abstraction: process map, process variant, elementary process, activity, and task. While the first two levels are more abstract and of organizational nature, the latter three levels target specific business processes and their parts, for which the authors propose the use of BPMN [24]. The elementary process level shows abstract activities, inputs and outputs, and actor roles of single business processes. The subordinate activity level describes a specific part of the business process without revealing irrelevant aspects to a particular stakeholder. Finally, the elementary task level decomposes each activity into its atomic tasks by providing all available details at the lowest level of granularity [24].

2.2 Robotic Process Automation

RPA employs so-called bots that represent single software licenses and operate on the user interfaces of existing applications and IT systems, mimicking human behavior [21, 26]. Unlike BPMS, RPA does not require extensive programming, as RPA bots are developed using low-code or no-code approaches and are configured via graphical user interfaces [11, 25]. Therefore, RPA is also referred to as “lightweight IT”, focusing on agility and speed, whereas the more complex BPMS are considered “heavyweight IT”, emphasizing security and reliability issues [14]. RPA is perceived to be cheaper, easier, and faster to introduce, configure, and maintain than BPMS initiatives since RPA does not (profoundly) change the IT architecture and thus entails only a fraction of the implementation costs and efforts [4, 21, 26]. Although RPA systems are less sophisticated and extensive than BPMS, they consist of similar components, like a Process Modeler, Model Repository, and Orchestrator [8]. Furthermore, RPA distinguishes between attended and unattended bots. Unattended bots are executed autonomously, e.g., on virtual machines, and are suitable for end-to-end automation of standardized and straightforward tasks with a limited scope. Attended bots, in turn, usually run on local desktops and require human input and interaction since they are triggered by business users to perform specific tasks of a process [5, 21]. During operation, both bot types follow specified procedures consisting of detailed work instructions, which we refer to as RPA flows or RPA sequences further on.

3 Related Work

Despite increasing research and practical dissemination, neither RPA nor BPM(S) have exploited their full potential yet [5, 15, 18]. Whereas BPM(S) rather focuses on the more complex and abstract process level, RPA tackles the atomic task level of a business process [11] and is thus regarded a complement for BPM(S), indicating the beneficial integration [4, 8, 16].

Therefore, Flechsig et al. [4] propose a high-level framework that combines the BPM and RPA life cycles to realize synergy effects, e.g., the prior optimization of the as-is process model to improve the RPA sequence, which is then subject to the BPMS monitoring and control. Similarly, König et al. [8] introduce an RPA-aware BPM life cycle to link both approaches and present a prototype that provides an API between BPMS and RPA systems for tandem use. The authors conclude that the BPMS can facilitate the upscaling of RPA and its capabilities for exception handling and managing automation on the process level [8], particularly if RPA is intended as a long-term solution [7]. More practically oriented, Romao et al. [18] present preliminary results of a BPMS-RPA integration project in the banking industry. However, the concrete platform design and the task orchestration between BPMS, RPA, and human operators remain an open issue [2, 18]. Along this line, Ludacka et al. [9] outline a related initiative at Deutsche Bahn Group and illustrate the interplay between the BPMS and RPA bots but do not elaborate on how to accomplish the conceptual and technical integration. Besides, the presented approaches neglect the impact of BPMN for standardized process modeling and orchestration within integrated systems, as emphasized by academia and industry [15, 16].

Although BPMN is widely used in BPMS [3], the notation itself is rarely applied to model bots since most RPA providers maintain individual languages [25]. Consequently, BPMN has not yet been studied regarding its inclusion in an integrated BPMS-RPA platform. However, recent articles [6, 8, 18] indicate the technological feasibility and beneficiary of such an approach, which would address several RPA issues (e.g., upscaling, monitoring) and facilitate comprehensive and consistent process modeling and orchestration familiar to business users [6, 16].

To tackle these open issues and supplement the existing methodological work with requirements and a technical concept of an integrated BPMS-RPA platform, we conducted an empirical study that is described in the following.

4 Research Methodology

We employed DSR as our methodological foundation to iteratively develop an artifact that addresses the presented research problem. The applied procedure followed the widely accepted activities proposed by Peffers et al. [13], i.e., problem identification, definition of objectives, design and development, demonstration, evaluation, and communication. We aim to develop a concept for an integrated BPMS-RPA platform based on a standardized and comprehensive notation that allows for unified process modeling and orchestration. In this vein, the exploratory nature of our study reflects our research question as we seek new insights and intend to provide implications for further research and organizational practice. The design process comprised three iterations, each resulting in several adjustments: (1) building the conceptual design based on the requirements derived from the interview study and related literature; (2) discussion and evaluation with six experts from the first iteration; (3) revision of the concept and prototypical exemplification of several components to demonstrate the practicability.

Our empirical inquiry followed the principles of case study research proposed by Runeson et al. [19], who consider expert interviews as essential data sources for software engineering, particularly when applying DSR. We selected the participating organizations based on theoretical sampling and paid attention that they differ in their scope (i.e., providing BPMS and/or RPA platforms and services) and size (i.e., revenues) to increase external validity. We ensured construct validity by conducting 20 semi-structured interviews with 15 experts of various functions and hierarchical roles (see Table 1). The average duration was 51 min, with one or two informants participating per interview. The organizations’ names and revenues are anonymized for confidentiality reasons [19].

Table 1. Overview of the participating organizations and informants
Full size table

The applied interview guideline included open-ended questions related to five parts: (1) information on the experts’ background, understanding of BPMS and RPA, and related experience; (2) feasibility of using a standardized notation for process modeling and orchestration for BPMS and RPA; (3) discussion of suitable integration approaches; (4) implications and application areas of an integrated BPMS-RPA platform; (5) challenges to be addressed by further research. The procedures for data gathering and analysis were performed collectively by three authors to reduce bias and increase validity and reliability, including rich supplementary data for triangulation, e.g., websites, white papers, internal presentations, and software demonstrators [19]. The interviews were transcribed and coded with the software MAXQDA 2022 following the guidelines for systematic qualitative content analysis [10]. We ensured internal validity by applying a hybrid inductive-deductive approach, i.e., we generalized emerging patterns through a combined within-case and cross-case analysis and assigned the coding elements to main categories deduced from related literature and sub-categories developed inductively [10, 19]. The results of our study are presented next.

5 Towards an Integrated BPMS-RPA Platform

During the interviews, we recognized that many organizations employ separate BPMS and RPA systems, even though they acknowledged that the growing number of operational RPA bots necessitates sophisticated and standardized orchestration to align the execution of business processes and RPA flows. However, adjusting and connecting both systems requires considerable effort since there is not yet a common standard interface. That recurrent problem corroborates the need for a novel approach that enables consistent process modeling and orchestration while treating RPA bots as “first-class citizens”, i.e., deeply embedded into processes. In this section, we derive the requirements and propose an initial conceptual design for such an integrated BPMS-RPA platform.

5.1 Requirements Engineering

The synthesized findings from the interview study and related literature yielded eight requirements of an integrated BPMS-RPA platform: four referring to organizational aspects (O1–O4) and four addressing technical issues (T1–T4). The requirements are described in the following and substantiated with representative quotes from the interviews [10] in a supplementary documentation.Footnote 1

O1 BPM Maturity. Integrating BPMS and RPA systems requires a certain degree of BPM maturity, i.e., organizational maturity and respective process capabilities. In this vein, maturity relates to the extent and interplay of process modeling, process deployment, process optimization, process management, organizational culture, and organizational structure to enhance business process performance. In contrast, capabilities refer to the competencies necessary to achieve the intended process results [23]. Various experts [Org. C, G, H, I] indicated the poor BPM maturity of many organizations and corroborated related work [20] by emphasizing the importance of a well-prepared IT architecture and process landscape, know-how building, and strategic implementation for an integrated BPMS-RPA platform.

O2 Mindset. The participants also reported that the lacking understanding of integrated process automation impedes the deployment of respective initiatives [Org. B, C, H, I]. While many organizations have been triggered by the automation hype around RPA and focus on bot development, they tend to neglect the more expensive yet essential BPMS projects. Although the functionalities of both technologies are increasingly converging [7], it was emphasized that organizations should not follow the RPA-centric approach [2] by considering RPA as a replacement for BPMS but rather a beneficial complement [Org. A, C, G, H]. Along this line, introducing an integrated platform requires top-level management support to release necessary budgets and promote change management that facilitates user acceptance, familiarity with new procedures, knowledge sharing, and collaboration between the IT and business departments [7, 9].

O3 Economic Efficiency. Profitability is essential for integrated platforms since the acquisition, deployment, operation, and maintenance require high efforts, particularly for small and medium-sized enterprises, which may not necessarily need a comprehensive (BPM) system for business process execution. Besides, multiple RPA bots must be employed to justify their incorporation since a limited number can also be managed manually and more cost-effectively [Org. A, G, H]. The more bots and tools involved, the higher the costs for licensing, operation, and orchestration. Therefore, an integrated platform must show a reasonable return on investment [16] and a favorable cost-benefit ratio [Org. A, D, E].

O4 Integrated Organizational Structure. The interviewees also reported on different departments being responsible for BPMS and RPA initiatives. However, an integrated platform requires integrated organizational structures, i.e., “bringing the two worlds together and overcoming the silo thinking” [Org. D]. Therefore, a consolidated “Center of Excellence” (CoE) centralizes the necessary competencies, responsibilities, technical capabilities, and human resources for operation and control [Org. A, C, D, E]. The CoE should also reflect the organizational and IT strategy and implement appropriate governance structures [5].

T1 BPMS Fundament. When scaling up RPA initiatives, many organizations recognize the need for a central BPMS platform to automate, control, and monitor processes holistically, i.e., “end-to-end” [Org. D, E, I]. BPMS usually include sophisticated procedures for process documentation, analysis, and orchestration and provide interfaces to integrate external applications (e.g., process mining tools), facilitating the further adoption of RPA [Org. A, C, G]. In that sense, BPMS could identify suitable routines for RPA, standardize process modeling and task orchestration, launch and monitor RPA bots to detect bottlenecks and exceptions, and drive comprehensive process optimization [1, 4, 6, 8, 9]. The BPMS fundament with a complementary RPA integration constitutes the most frequently mentioned requirement and reflects the BPM-centric approach [2].

T2 Concerted Task Orchestration. While RPA systems lack large-scale process orchestration, focusing on the management and alignment of bots and tasks [8], current BPMS are often restricted regarding their functionalities for human-bot collaboration [18, 20]. Therefore, academics and practitioners emphasize the need for seamless coordination and collaboration between the BPMS, RPA bots, and human operators. To this end, an integrated platform should be based on transparent interfaces, profound decision logic, and predefined rules for requests [Org. A, B, G, I], providing functionalities for synchronous and asynchronous human-bot collaboration [2].

T3 Consistent Process Modeling. The need for uniform and comprehensive process documentation was consistently mentioned in the interviews and related work [4, 6, 8, 18]. In this vein, multiple experts recommended using the standardized BPMN 2.0 notation as it is already applied for process modeling and execution by most BPMS [Org. C, D, E, G]. Besides, many RPA design languages are inspired or rest upon BPMN elements [Org. I, K]. Therefore, an integrated BPMS-RPA platform based on the BPMN 2.0 notation would facilitate consistent and comprehensive process documentation and automation. The holistic approach could enable the standardized design of BPMS and RPA workflows, automatically generate related flowcharts [1], and foster the upscaling of RPA bots and their integration into the BPMS [Org. D, H, I].

T4 Limited Complexity. Several articles [6, 18] and interview participants stressed the necessity of limited complexity regarding technical implementation (i.e., preferably low-code or no-code programming) and process model representation. Adequate process visualization can be facilitated through a layered approach, enabling all stakeholders to illustrate the process model and relevant activities in the required level of detail [24]. However, some interviewees highlighted potential difficulties when linking the rather technical RPA bot configuration with the graphical BPMN 2.0 notation due to the different contexts and objectives, resulting in too complex and hardly readable process models. In this context, the experts reported on necessary BPMN extensions to adequately depict human-bot collaboration, complex decision-making, data extraction from user interfaces, and the use of artificial intelligence. Besides, status-affected objects, loop constructs, and function calls must be embedded [Org. A, C, H, I, K].

Emphasizing the high efforts for integrating the different BPMS and RPA technologies, several experts recommended the development of an entirely new platform resting upon a holistic and consistent approach for process modeling, orchestration, and automation [Org. B, C, K]. As indicated by expert E1, such an environment would allow specifying both BPMS routines and RPA bots based on a consistent notation: “You need a uniform BPMS and RPA system. As long as you partner with an external RPA provider, it’s difficult to implement an integrated platform, as the different RPA tools have their own notation.”

Although we noticed that some organizations are pioneering holistic approaches, no respective concept yet exists in the academic literature. Therefore, we tackle this research gap by proposing an initial conceptual design of an integrated BPMS-RPA platform based on BPMN in the following.

5.2 Conceptual Design

This section presents the final version of our artifact and explains how it addresses the revealed (technical) requirements. The changes made during the evaluation process are detailed in Sect. 6.1. We propose a holistic platform for modeling, orchestrating, and executing business processes and RPA flows while capturing and considering their interplay and relation. Corresponding to the requirement T1, the platform’s architecture (Fig. 1) mainly builds on the components of a traditional BPMS (cf. [27]), in particular on the Process Modeler and Process Engine. However, the components are functionally extended and supplemented with additional RPA-related elements. For example, we introduce an additional RPA Flow Repository, responsible for storing the definitions of end-to-end automated RPA workflows. Besides, the Process Engine is supported by an RPA Orchestrator and a Parser for RPA flows similar to those of stand-alone RPA tools. The various components are described below.

Fig. 1.
figure 1

High-level architecture of the integrated BPMS-RPA platform as FMC-Diagram

Full size image

Process Modeler. Contributing to T3, the Process Modeler builds on BPMN to enable the seamless creation and visualization of business processes and RPA flows, which are stored in the respective repositories. The Business Process Model Repository is adapted from traditional BPMS and contains business process definitions that can be enriched with RPA functionality. Sequences in the RPA Flow Repository are end-to-end automated reoccurring activities applicable to various business processes of an organization, e.g., logging in to specific software or retrieving certain information. As shown in Fig. 2, these rather generic workflows are solely composed of BPMN tasks representing atomic RPA operations that need to be performed and are substantiated by an underlying technical RPA configuration. Therefore, the RPA Flow Repository employs flowcharts of automated sequences specified through the process or task variables rather than a “farm” of predefined bots tailored to concrete tasks [2]. These variables allow for flexible configuration of the automated activities and their reuse for different contexts and users, e.g., by dynamically requesting login data from a central credential store. Furthermore, it can be defined whether and how the RPA flow should be executed in an attended or unattended manner.

Although flows of the RPA repository usually pose stand-alone sequences, their integration into the superordinate business processes orchestrated by the BPMS is challenging due to the different scope and level of abstraction. While BPMS mainly include relatively high-level workflows that take additional knowledge on how they are performed, RPA is used to automate individual tasks within a business process and requires detailed technical instructions. To avoid extensive process models and reduce complexity (cf. T4), we adapt the layered approach of van Nuffel and de Backer [24] (cf. Sect. 2.1), which is technically implemented in the Process Modeler using the sub-process elements defined in BPMN 2.0. Therefore, our concept decomposes business processes into three layers with descending levels of abstraction. The first layer represents the process level and includes the main activities and interactions. The second layer poses the activity level and details the main activities. In accordance with van Nuffel and de Backer [24], this layer can be defined recursively for highly complex processes, i.e., the activities can be defined in more detail while remaining on a relatively abstract level. Finally, the third layer describes the task level and comprises atomic instructions on how to perform a particular activity.

Fig. 2.
figure 2

Sample sequence of the RPA flow repository

Full size image
Fig. 3.
figure 3

Applied layered approach, exemplified through a sample business process

Full size image

The process modeler offers two approaches for integrating RPA functionality into business processes. On the one hand, RPA workflows specific to a particular business process can be directly defined in the third layer, as its atomic task level matches the granularity of RPA with its atomic work instructions. On the other hand, generic RPA sequences defined in the RPA Flow Repository can be referenced in the second layer using BPMN call activities. Since they are defined in a central instance, they can be reused quickly and need to be adjusted for updates only once. In contrast, specifying RPA operations directly in the process is helpful for tailored automation and allows for synchronous human-bot collaboration (cf. T2), i.e., RPA tasks and human tasks can be defined alternately. The two approaches are illustrated in Fig. 3. In the given example, the call activity “CRM-Web login” in the second layer references the respective end-to-end sequence from the RPA Flow Repository (cf. Fig. 2). The activity “Send rejection” is detailed in the third layer and involves human-bot collaboration. RPA is used to start the outlook application and prepare the email with predefined input before handing it to a human operator for reviewing. Once the employee has finished the check, the RPA bot is triggered again to send the email.

Process Engine. The proposed Process Engine orchestrates and executes the defined processes and tasks similar to a traditional BPMS process engine. Since the layers are modeled using sub-process elements of BPMN, it does not require any modification in this regard. However, its functionality is extended for RPA integration to handle references to the RPA Flow Repository on the second layer and specific RPA tasks on the third layer. In either case, the (part of the) BPMN model containing RPA tasks is processed by the RPA Parser, which transforms the BPMN diagram into an internal, RPA-specific format. That format is subsequently handed to the RPA Orchestrator for executing the RPA tasks within the appropriate environment as specified by the respective process variables. When a process on the third layer also includes non-RPA tasks, the RPA Orchestrator pauses the bot execution until the intervening non-RPA tasks have been completed and the Process Engine signals to proceed. In both cases, the RPA Orchestrator distributes pending RPA tasks to appropriate RPA bots considering the individual capabilities and task variables, e.g., to account for the configured mode (i.e., attended or unattended) and required software installations.

6 Evaluation and Demonstration

Following the DSR methodology, our concept was evaluated through further expert interviews and partially implemented in a prototypical demonstrator.

6.1 Follow-up Interviews

The evaluation rests upon five follow-up interviews with experts from Org. A, B, C, I, and K (cf. Table 1). We had lively yet constructive discussions and received positive feedback on our concept, entailing valuable proposals for modification. For example, we initially intended to generate RPA scripts from the RPA workflows and third-layer tasks directly after the modeling. Due to the experts’ feedback, we changed this behavior to a more dynamic approach, i.e., the process models containing RPA definitions are both parsed and interpreted during the execution. That allows for short-term modifications and facilitates the detailed monitoring of the RPA execution. Consequently, the former RPA Script Generator component was replaced by an RPA Parser (cf. Fig. 1). Furthermore, we refrained from advocating bots configured for specific RPA workflows. Instead, we propose a “pool” of RPA sequences with predefined yet adjustable process or task variables due to its practicability and increasing relevance.

Generally, the study participants attested to the applicability of BPMN as the underlying notation to visualize business processes and their interrelated activities and tasks regarding the proposed layers. However, during the evaluation, several experts emphasized that the current BPMN 2.0 standard needs to be enhanced to adequately depict RPA sequences as intended with our concept. To this end, we discussed introducing a fourth layer that translates RPA tasks into code and represents technical aspects, while the superordinate layers show the business logic. However, this would increase the complexity of the process model and proposed platform, contrary to our objectives and derived requirements (cf. T4). Besides, it would involve profound (technical) amendments to BPMN 2.0, which does not fit the notation’s original purpose [12]. Therefore, we opt for three layers and propose to configure the chosen RPA functionality using task attributes. For visual guidance, we now indicate the automated application in the process model by a respective icon in the task. Finally, the experts emphasized that activities require precise and descriptive labels due to the nested layers.

6.2 Prototypical Implementation

We prototypically implemented the extended Process Modeler, Business Process Model Repository, and RPA Flow Repository to provide an initial demonstration of our concept.Footnote 2 Based on our explanations in Sect. 5.2, the Process Modeler enables users to model RPA flows and layered business processes using BPMN. RPA tasks on the third layer or in the RPA Flow Repository can directly be configured through task variables in the user interface by choosing the appropriate RPA operation for execution. This configuration via the Process Modeler is based on the open-source Robot FrameworkFootnote 3, which could be integrated by an extended Process Engine and RPA Orchestrator to perform the RPA tasks. It is important to note that the amount and complexity of the automated workflows in both repositories will likely increase over time. Therefore, the Process Modeler enables direct navigation between the different layers and RPA flows via sub-process activities (referencing subordinate layers) and call activities (referencing sequences of the RPA Flow Repository) to handle the increasing complexity. Consequently, processes and their subordinate activities and tasks on the different layers can be navigated and explored intuitively.

7 Discussion and Conclusion

This empirical article rests upon the DSR methodology and examines how BPMS and RPA can be holistically integrated based on a consistent notation for process modeling and orchestration. To this end, the conducted interview study and related literature yielded four organizational and four technical requirements. We also developed an initial conceptual design of an integrated BPMS-RPA platform, reflecting the technical requirements. The proposed concept was evaluated by multiple experts and partially implemented through a publicly available prototype, indicating its feasibility and practicability. In the following, we discuss the implications of our study and provide recommendations for further research.

7.1 Theoretical and Practical Implications

Our concept amalgamates the functionalities of BPMS and RPA systems in a uniform platform that rests upon comprehensive and consistent process modeling, orchestration, and automation with BPMN, contributing to the recent practical and scientific discourse [4, 6, 16, 18]. As highly recommended by the interviewed experts, the BPMS constitutes the central instance for process enactment and is complemented by RPA (cf. T1), thus enabling single-source and end-to-end process automation and preparing the ground for holistic process monitoring and exception handling. The consistent use of BPMN throughout the platform in line with the three abstraction layers allows for the integrated visualization of both the abstract business logic and specific atomic RPA tasks (cf. T3, T4). It also simplifies task orchestration between the BPMS, RPA bots, and human operators (cf. T2). Besides, the varying informative value and complexity at the different layers contribute to the various purposes of each process stakeholder and could foster coordination and understanding. Additionally, the concept enables a direct collaboration of RPA bots and humans on the task level, coordinated by the BPMS. As a result, the Process Engine can provide detailed execution information, while error handling could be facilitated, and the subsequent process analyses become more comprehensive. Hence, the need to evaluate which business logic has to be implemented in the BPMS and which in the RPA system, as is often the case with current solutions, is eliminated with our approach.

In contrast to related work considering separated BPMS and RPA systems [8], we opt for in-depth integration of RPA into BPMS to increase process transparency and model consistency while preventing RPA “black boxes” and data silos that usually result from separated solutions. Consequently, our study corroborates the harmonization of the BPM and RPA life cycles [4, 8] with a profound concept on how to realize that integration technically. In this vein, a bridging approach [8] is suitable for organizations that maintain deeply ingrained legacy BPMS and/or RPA systems for which immediate integration would cause excessive efforts. These organizations should prioritize increasing their BPM maturity (cf. O1) and fostering a mindset for holistic process automation (cf. O2) to enable the step-by-step migration towards an integrated BPMS-RPA platform. Depending on the needs and economic efficiency (cf. O3), individual RPA sequences can be gradually incorporated into the BPMS. However, an integrated BPMS-RPA platform also entails integrated organizational structures, i.e., a consolidated Center of Excellence pooling all necessary resources and capabilities (cf. O4).

7.2 Limitations and Recommendations for Further Research

This research is not without limitations. Even though our empirical inquiry rigorously followed DSR and case study principles to provide meaningful insights based on a representative sample, it is restricted regarding the number of examined organizations. Despite the interviewed experts attesting to our concept’s practicability, it still lacks a real-world implementation and validation beyond the prototype. Besides, the presented requirements mainly rest upon the interview study due to the scarce scientific literature. Therefore, future research can conduct more comprehensive studies to confirm, complement, or disprove our findings.

As this work is intended to provide initial insights and starting points for an integrated BPMS-RPA platform, several aspects require further elaboration and should be addressed by future research. For example, concrete and holistic orchestration and governance mechanisms should be established to manage the two repositories [2, 18], specify the configuration and upscaling of automated workflows [1, 11], and control the input-output transfer across the layers and between the BPMS, RPA bots, and human operators. Besides, appropriate regulations for system security and self-government should be examined.

Although we did not explicitly discuss a rework of BPMN, a purposeful extension of the standard could be beneficial, particularly concerning the visualization of RPA-specific information. A process recorder could automatically generate BPMN models, which are then subject to verification, harmonization, and configuration before shifting them to the repository, e.g., to be executed by RPA bots. Targeted task mining approaches can also be incorporated. Finally, we examined non-intelligent BPMS and RPA systems. Therefore, future research needs to investigate their increasing integration with artificial intelligence and other automation technologies towards “hyperautomation” [7], as various functionalities converge, like process modeling, orchestration, or monitoring.