Keywords

1 Introduction

To remain competitive in today´s complex and competitive economic environment, process automation is essential for companies of all sizes [1]. Efforts for digitalization and process automation in production environments have been increased considerably in the last years in the context of Industry 4.0. Several manufacturing processes on the shop floor have supplied a vital base for optimization and digitalization that have enabled companies to efficiently produce complex products at low costs. These efforts have led to an increase in administrative work tasks, which are often repetitive, time-consuming and have not been examined with the same care and accuracy as manufacturing process automation has received [2, 3]. One of the reasons for this discrepancy is that the output of a business process cannot be measured simply on the basis of quality and quantity like a manufacturing process, since the process result is usually more complex in business processes. Science provides general methods to automate business processes to reduce administrative efforts in line with concepts like Lean Administration [4, 5].

Robotic Process Automation (RPA), a comparatively new method, poses the advantage that the responsible employees themselves can quickly and easily automate these administrative processes. However, RPA procedures are intended to automate a process at hand without an in-depth analysis or valuation of the necessity and usefulness of automated process steps [6]. As a consequence, redundancies and dispensable process steps are also transferred into new designed RPA process flows. Incorporating the procedures of RPA into the well-known Business Process Management (BPM) approach appears to be a useful strategy. The as-is process could be standardized and optimized first. Consequently, the RPA procedure would be able to reach its full automation potential on the remaining process steps. As the combination of BPM and RPA has rarely been addressed in scientific literature, this paper intends to propose a methodology and demonstrate the potential of the combined use of BPM and RPA within a case study. Specifically, we intend to answer the following research questions:

  • RQ1: How can BPM and RPA be distinguished?

  • RQ2: Is there synergy potential between BPM and RPA? If so, how could a combination of both methods be achieved?

  • RQ3: What are the benefits and risks of this concept?

The remainder of this paper is organized as follows: In the next section, we provide the background of our study with an overview of the characteristics of BPM and RPA. The literature on both concepts is reviewed. We compare BPM and RPA and demonstrate the synergy potential. In the third section, we present a methodology to combine RPA and BPM in digitalization projects. Afterwards, we show the potential of our proposed methodology in a case study and discuss capabilities, benefits, and risks involved. To conclude, the last section presents limitations, further research opportunities, and an outlook.

2 Comparison of BPM and RPA and Synergy Potential

Different concepts can be utilized for the automation of business processes. This section provides an overview of the specific characteristics of the two concepts of interest for this study: BPM and RPA. First, both are defined and compared. Then, the synergy potential between BPM and RPA is evaluated and indicated.

2.1 Characteristics of BPM and RPA

In order to clearly distinguish between BPM and RPA and to reveal the benefits of a combined application, both methods are defined in this section, including the elaboration of differences and similarities.

BPM.

In scientific literature, BPM is a vague term that lacks a precise definition and delimitation [7]. The European Association of Business Process Management [8] specifies BPM as follows: “Business Process Management (BPM) is a systemic approach geared to capture, design, execute, document, measure, monitor and control automated as well as non-automated processes in order to meet the objectives that are aligned with the business strategy of a company. BPM embraces the conscious, comprehensive and increasingly technology-enabled definition, improvement, innovation and maintenance of end-to-end processes.” By means of BPM, the process is understood as a whole and optimized from an organizational perspective with the help of information technology (IT). The conceptual basis of BPM has been developed in the 1990s: Business Process Reengineering (BPR) led to a radical redesign of business processes as they were increasingly recognized as drivers for efficiency and innovation [7, 13]. Business processes can be divided into sub-processes and mainly consist of administrative activities, which are planned, controlled, and executed in a predefined order to achieve a specific goal. They represent procedures within or across the company that require time, resources, and expenses and are triggered by internal as well as external events [9,10,11]. Through BPM, processes can be aligned with the business strategy, improving the overall performance due to process optimization within single departments, between multiple departments of the company (inter-divisional) or even beyond company borders [8]. Further advantages are reduced costs and increased quality of processes, organizational flexibility and performance as well as customer and employee satisfaction [12].

The automation of the considered business processes can be realized with Business Process Management Systems (BPMS). These IT systems allow for a precise definition of processes by means of one or several process model notations to analyze, model, and simulate them. Additionally, they facilitate the executional support and integration into other systems [11]. The present de-facto standard, Business Process Model and Notation (BPMN), also offers process execution methods [14].

RPA.

Robotic Process Automation (RPA) is a general heading for software tools operating on the user interface of IT systems. Thereby, the term “robot” technically describes a single software license [15]. RPA flows imitate human behavior and relieve or replace employees by automating simple, repetitive, and rule-based back office business tasks [16]. Studies suggest that RPA software robots could lead to cost savings ranging between 20% and 50% compared with a full-time employee while performing the same work amount [6, 17]. Further benefits of RPA are good scalability, enhanced process accuracy, and transparency. Software robots work around the clock and can be trained by refining and extending the script [18, 19].

However, BPM and RPA differ in essential criteria. The following comparison (see Table 1 for a comprehensive overview) focuses on the most relevant distinguishing characteristics used in literature: area of application, procedure of automation, method of integration in existing IT systems, required personnel for implementation, estimated implementation effort, scope of the introduction phase, and dissemination in practice and academia.

Table 1. Characteristics of BPM and RPA
Full size table

Area of Application.

BPM is a holistic management concept facilitating the optimal redesign of all kind of processes in an enterprise. Concerning process automation, the primary area of BPMS are rather complex, extensive, and specialized processes with a high proportion of added value and strategic significance across the whole company. Whereas RPA automates simple, already existing repetitive processes with little strategic impact and predominantly local effects on the respective department [6]. The technology is also able to make simple decisions following a precisely defined set of criteria. Typical tasks of RPA flows include searching, analyzing, transforming, and saving data in various software applications [18].

Procedure of Automation.

The sequence of activities in a BPM project can be described in life cycle models, of which various scientifically illustrated versions exist (for an overview of different models, see [9]). We focus on the model of [11], since it advances existing models (see Fig. 1). In the first phase, relevant processes are identified and defined precisely. Then, the current state of each process is documented, also called as-is modeling. The resulting process models reflect and facilitate the understanding of the responsible employees. Stakeholder communication can be improved using the as-is models. Their quality has a significant impact on the successful realization of BPM [20]. The following phase (process analysis) identifies and quantifies issues associated with the as-is models to reveal optimization potential. The processes can then be purposefully redesigned and improved by defining appropriate alternatives, also called to-be modeling. Next, the resulting to-be processes with its necessary changes are put into practice. The realization covers two aspects: organizational change management, which includes modifications concerning the way of working, and process automation which refers to the implementation of suitable IT systems. Once the redesigned business process is running, continuous monitoring and analysis of data concludes the BPM life cycle. This data collection can be performed through process mining that supports a targeted process analysis and monitoring [21].

Fig. 1.
figure 1

BPM life cycle model by [11]

Full size image

RPA does not provide an optimized to-be model. The initial as-is process is rather analyzed regarding its technical realization and less concerning its optimizing potential. It is then mapped in the RPA tool language as a detailed and executable script. There are two ways of creating the source code: screen scraping and hard coding. Using the first method, the RPA software is recording all user entries and transferring them to source code automatically. By means of hard coding, the data is directly embedded into the source code [6, 22]. After a successful testing phase, the RPA flow is implemented in the productive environment performing “if, then, else” sequences. However, a holistic process monitoring and controlling is missing [23, 24].

Method of Integration.

BPMS use various application programming interfaces (API) or web services to access third-party systems and improve them. They generate new models and databases in the data layer. Integration takes place “top-down”, since processes are standardized through implementation. RPA programs are directly based on the graphical user interface (GUI) of existing IT systems. They are integrated into the presentation layer and do not change the deeper system logic. Integration takes place via direct process integration prior to implementation (“bottom-up”) [15,16,17].

Required Personnel for Implementation.

Process modeling in BPM is predominantly performed by business analysts. However, specialized software developers are needed for the implementation in the BPMS. RPA is almost completely independent of IT staff. Programming can be carried out directly in the respective departments after an initial configuration phase [25, 26].

Implementation Effort.

The implementation effort for BPM is significantly higher than for RPA. Full-scale BPM projects have significantly higher costs and payback periods due to the additional technical effort involved [6, 15, 16].

Introduction Phase.

Process automation with BPM requires an extensive test phase as well as continuous monitoring of the system. RPA, on the other hand, profits from simple implementation and a short testing phase. The training duration of the software robots certainly increases with faulty programming and insufficient definitions of process sequences [26].

Dissemination.

Due to its importance for both academia and practice, BPM constitutes an established discipline and is considered as the most comprehensive and well-known business process management approach [27]. BPM is used widely in practice and shows an advanced state of knowledge in the scientific literature [26]. The modeling language BPMN has been the subject of many recent research projects. RPA has so far shown a rather low dissemination, although practice is familiar with its potential benefits and is beginning to focus more on this area. However, scientific literature on RPA is limited [17]. Relevant contributions mainly present case studies [28]. The combination of RPA with artificial intelligence to automate creative processes is a field that has recently moved into focus [29]. Intelligent RPA (IRPA) recognizes unstructured data such as e-mails or handwritten recordings using techniques like natural speech analysis. In the event of an unknown situation, the IRPA system acts independently and develops continuously [28]. This enables the software robot to react more flexibly to changing tasks. Although intelligent automation is promising, it is still at an early stage of development and is rarely studied scientifically. Moreover, IRPA requires higher expenses and a longer implementation time than standard RPA [29].

Besides their differences, BPM and RPA show several similarities. Both concepts enable the systematic automation of business processes [6]. They are applied for consistent IT support and therefore use similar components, such as graphical editors for modeling [18]. Common goals are the exploitation of potential, e.g. by reducing process costs and time as well as increasing customer satisfaction and frequency [11, 16]. The organizational change associated with the respective projects has to involve all stakeholders at an early stage [12, 25].

The above comparison contributes to answering the first and part of the second research question. BPM and RPA can be clearly distinguished; they have reciprocal advantages and disadvantages. In practice, they do not substitute each other, but are used simultaneously and context-dependent [6]. We provide indications to utilize the synergy potential in the following, leading to an integration of RPA into a holistic BPM concept.

2.2 Synergy Potential Between BPM and RPA

A combination of both methods provides three major advantages. Firstly, it would benefit RPA as this method is not suitable for extensive processes including multiple process steps in principle. However, RPA could be possibly applied if the process is simplified and optimized in advance through a BPM to-be model. Secondly, the RPA flow would benefit from the holistic BPM monitoring and controlling, which comprises all business processes that are executed in the company, enabling a faster detection of further optimization potential. And thirdly, BPM benefits from a proper combination as RPA enhances the possibilities to automate processes that are economically not feasible regarding a costly BPM project. In consequence, the holistic BPM approach obtains a further automation concept in addition to BPMS to automate more processes as shown in the following.

Figure 2 depicts the positioning of BPM and RPA in terms of feasibility and process characteristics. The x-axis shows the different types of cases (processes). Similar cases that are managed in the same way are assigned to the same case type. The y-axis shows the frequency of case types (number of similar cases) in a given period. The frequency needs to be individually determined for each company. The correlation of both axes is typically described by a Pareto distribution. A lot of case types are quite infrequent; 80% of all cases can be explained by 20% of the case types. Traditional automation through BPMS focuses on the most frequent 20% of case types (dashed line in the left sector). These processes are often highly value-adding with many similar process steps and only a few exceptions, making automation economically feasible. The remaining 20% of cases contain 80% of the case types and are often performed manually by humans (solid line in the middle and dotted line in the right sector). This includes repetitive work and decision making due to exceptions and various process steps. These types of cases are more time-consuming than the frequent ones. For a small proportion of the processes (dotted line), automation is not possible or economically feasible. However, a large proportion (solid line) can be automated with RPA [15]. Such processes are usually of low to medium complexity and can be performed within 5 to 30 min [17]. RPA supports employees by executing tasks that are repetitive but not frequent enough to justify traditional automation through costly BPM projects. Therefore, RPA constitutes a sensible alternative as it is applied using the existing GUIs instead of adjusting to changing APIs. Moreover, it could save time and resources to automate suitable processes with RPA instead of BPM, resulting in shorter amortization cycles and test periods. Together, a combination of BPM and RPA would therefore cover most if not all processes that can be automated to some extent (dashed line and solid line).

Fig. 2.
figure 2

Positioning of BPM and RPA (based on [15])

Full size image

Furthermore, by means of a combined BPM-RPA methodology, the BPM system can trigger an RPA activity to interact with other IT systems and use the returned results in the subsequent steps of the BPM process flow. Other promising process types are those that require human approval after the transfer of the result or due to necessary exception handling. BPM can initiate these processes based on the results of an RPA flow. This minimizes potential human error while allowing human control over the outcome. The results of the approval process could be logged for compliance requirements [30]. Our proposed approach is presented in the following.

3 Methodology to Combine BPM and RPA

We developed a methodology to combine BPM and RPA. Figure 3 demonstrates our proposed life cycle model. The first four phases are inspired by the existing BPM life cycle of [11] (see Fig. 1). The as-is model is established, analyzed, and optimized to create a to-be process model. After the redesign and optimization, a case distinction is necessary. Based on Sect. 2.2 and Fig. 2, the users need to decide whether the process under consideration is suitable for RPA or not. This decision can be supported by several questions: Is the process repetitive and standardized (rule-based)? Is the error potential high? Is permanent processing necessary? Is the process relevant for compliance? Does the process occur rather frequently and at least partially contribute to value creation? Are resources such as budget or IT staff currently scarce? If all or most of these questions are answered affirmatively, the process appears suitable for an automation with RPA. Furthermore, the process should require neither subjective judgement nor creativity but should be clearly defined and highly standardized.

Fig. 3.
figure 3

Proposed BPM-RPA life cycle model

Full size image

Processes that are suitable for RPA then deviate in the life cycle model and pass through the development, testing, release, and run phases [23]. In the development phase, a technical design and an implementation plan are created. The automation procedure follows the standardized to-be process model. Testing ensures the usability of the RPA flow, especially the consideration of all specifications and a proper robot functionality. Testing should be carried out in a non-productive environment with real, historical data. The release phase represents the transition from the test to the productive environment, which is planned and then executed. After the release, the process is performed for several iterations while being constantly monitored by a human employee to ensure stable performance in live operations and the achievement of expected benefits. As soon as the correct sequence has been guaranteed, the BPM flow is reactivated and takes over monitoring and control accordingly. The processes that are not suitable for RPA follow the known path with process implementation as the next step and meet again with the RPA flow in the step monitoring and control.

Our life cycle model provides the following benefits: The BPM process is not profoundly changed, but the RPA flow is added at a critical point. The decision for RPA process suitability is determined after the target process modeling has been completed. This guarantees full exploitation of the optimization potential of the BPM procedures. Although the effort involved will be greater if an upstream optimization is performed, we avoid a premature execution of the RPA sequence based on the as-is process. After the successful implementation of an RPA flow, this sequence is also subject to monitoring and control, enabling the same control level as for the remainder of the BPM process. Iteratively, the process is checked and optimized again. RPA can thus be replaced by a full automation of the affected IT systems at a later point in time, when missing resources such as budget or IT staff become available. Anyway, if a (costly) BPM project starts, RPA suitability should be checked to prevent unnecessary costs and efforts. With our combined life cycle model, more processes can be covered (see dashed line and solid line in Fig. 2) and the methods benefit from the advantages of each other. To demonstrate the potential of our proposed methodology, we present a case study hereafter.

4 Case Study

The case study is inspired by a typical process of our case company and can be attributed to production planning and control. The case company operates in the semiconductor industry, with a high level of automation in the manufacturing process. However, many repetitive planning processes are still performed manually at high costs.

Production planners solve scheduling tasks daily that are handled differently, depending on the assigned process flow of each order. Our case company deals with a large product mix and many manufacturing steps. Thus, it uses a wide variety of IT systems and databases to manage and change process data. Particularly in industries such as microelectronics, product life cycles have become very short and new products are enhanced in productive operations as development batches. Often the process flows are modified iteratively and are not immediately available in the operations department, but have to be collected from various databases. Due to its generality, our case study can also be adopted for companies operating in other industry sectors, showing comparable results.

The as-is process of the case study contains the following process steps: The order list is received in the operations department as an MS Excel worksheet. It consists of six columns: a serial number (ID), information about the product ordered and its demand, as well as its production steps with related characteristics (see Table 2). The order list contains 300 different products, the product mix consists of 15 product classes with 20 variants. Order quantities range from single orders up to 200 units per order. In our case study, we consider a production scenario with three production steps (X, Y, Z) in different sections (A, B, and C). Each production step can be performed in six different modes. For every production step, the research and development (R&D) department maintains a respective database in which the process characteristic for the product is updated first. Some of the products show missing information regarding one or several production step(s). We created three cases to investigate the impact of the quantity of missing information on the process execution (both manual and RPA). In case 1 we assume that 5% of the products (n = 15) are affected by missing information. The total amount of lacking data fields is 21. In case 2, 10% of the products (n = 30) show missing information, comprising 42 lacking data cells. This is the standard case, based on expert feedback from the case company. Furthermore, we created case 3 with 20% of affected products (60) and 84 data fields missing. The order list is initially and manually checked by the operations employee for completeness with regard to the production steps. If an entry is missing, the planner checks the information in the respective database that is maintained for the production step. The planner copies/notes the required product type, opens the database, searches for the entry of the product type and for the missing information. If the information is accessible in the database, the employee copies the data and pastes it into the order list. If the information is missing, the planner sends an e-mail to the responsible colleague in the R&D department to ask for feedback on the specific production step. The affected order is restrained as long as the process flow is not clarified. Once all orders have been checked, the planner releases the orders that have not been restrained.

Table 2. Order list (excerpt)
Full size table

The previously described as-is process was analyzed. Several issues were identified and the process was redesigned. Figure 4 shows an excerpt from the optimized manual to-be process model where the three databases were merged into one master database to reduce individual search efforts as well as the complexity of the IT infrastructure. Moreover, it is methodically easy to implement for the IT department. As an additional step, the planner now saves the queried information in the operation department’s own database to prevent redundant searches in upcoming weeks. Thus, stored data is automatically used to generate and complete future order lists. The to-be process model was subsequently reviewed in order to make a decision on the potential suitability for RPA. The process flow is repetitive, moderately complex, and fairly value adding. It seems reasonable to use an RPA flow for these process steps.

Fig. 4.
figure 4

Manual to-be process model (excerpt)

Full size image

The to-be process flow following our methodology with a combined use of BPM and RPA is described in the following. After determining its suitability for RPA, we transformed the manual to-be process model (Fig. 4) into a technical RPA-design. This implementation plan must be encompassing and rule-based, defining responsibilities and containing all process steps and a detailed exception handling. Due to its complexity and space limitations, the RPA process model is not included as a figure in this paper. However, we would like to focus on two points in particular: the retrieval of information and the handling of exceptions. The RPA flow automatically searches the master database for missing information detected in the order list. The data is pasted into the order list and saved in the same way as in the manual to-be model (Fig. 4). If information is missing in the retrieval database, the RPA flow automatically prepares a list for the operation employee with the respective products and the missing information. A handover notice is created to return control to the human employee. The employee can then easily request feedback from responsible colleagues in the R&D department. If no information is received after a certain period of time (e.g. 30 min), the order is restrained. Any received information is pasted into the order list and the operations departments database accordingly. This procedure ensures the correct handling of each order and enables more orders to be produced in the next period. As the RPA flow is much faster than manual processing, more time can be spent on processing the special cases and the employee can systematically consult with colleagues.

In order to evaluate the practical benefits of our proposed concept, we compare the different workflows and respective cases regarding the time required to process the order list. The workflows are the manual as-is model, the manual to-be model, the RPA as-is model and the RPA to-be model. In the as-is models, an MS Excel order list and three separate MS Excel databases were used, which were combined into one MS Excel master database for the to-be models (MS Office 2016, Windows 10, CPU i5-6500). Both RPA flows were designed and implemented using UiPath Studio v2019.1.0 [31] on the same workstation. The to-be process starts with opening the order list and checking for completeness. The master database is then opened (manual to-be process) or the RPA flow is initiated by starting the RPA software and the flow execution. The resulting completed order list is finally revised. Figures 5 and 6 show the different runs for the single workflows and cases. The data were obtained over several runs (n = 6) in the case company by observing the corresponding employees (case 2) and by experiments (case 1 and 3).

Fig. 5.
figure 5

Comparison as-is, to-be process model

Full size image
Fig. 6.
figure 6

Comparison of RPA as-is and RPA to-be model in the three cases

Full size image

As a result of the optimization (manual to-be model compared with the manual as-is model), the mean time decreased by 9.54% in case 1, 13.93% in case 2 and 13.51% in case 3. Figure 6 shows the runtimes of the RPA flow for the three cases and the as-is and to-be models. The mean time decreased by 3.49% in case 1 if the RPA flow is executed based on the to-be model rather than the as-is model. For case 2 and case 3 the results are a decrease of 3.68% and 3.11%, respectively. Overall the runtime of case 1 was improved by 70.53%, case 2 by 79.53% and case 3 by 86.06%. Considering the amount of missing information (cases), the RPA process is insensitive in terms of total runtime. From case 1 to case 2 (twice as many cases), the runtime increases by less than one second, from case 2 to case 3 by less than two seconds.

These results underline the simple but effective optimization from the as-is to the to-be process model and the high performance of an RPA flow. Due to the short processing times of an RPA application and the comparatively simple and generic case process, the differences between the as-is RPA flow and the optimized to-be RPA flow are rather small. However, the advantage of an RPA execution based on the to-be model instead of the as-is process was shown. The use of the RPA flow also contributes to error prevention. As the automation using UiPath is based on ready-to-use modules in the software and is relatively self-explanatory, a duration of about three working days for an employee from the specialist department or about two hours of programming effort for a skilled coder can be estimated. Due to the savings in working time in the specialist department, the amortization period is thus around two months if the same wage level is assumed. To summarize the benefits, the new to-be RPA flow of our combined approach enables a cost-saving, fast, and error-avoiding process flow.

At a later point in time, our case process could be streamlined even more through a master database that is maintained by the R&D department exclusively. The order list would then only include the demand and the corresponding order quantities for each product. When scheduling, the order list is completed by automatically fetching process information from the R&D database. Thus, the RPA flow could be replaced by a full-scale BPM project that continuously checks the consistency and completeness of the R&D database and inserts the information in the order list.

5 Conclusion

In this paper, we presented a methodology for combining BPM and RPA. After a literature-based comparison to define both concepts and identify distinguishing characteristics, we showed synergy potential of a combination, such as error handling through BPM and the release of RPA results in the BPM process. The optimization of the as-is process model in the proposed methodology supports the realization of the full potential of RPA and avoids a premature execution of the RPA sequence. After its successful implementation, this sequence is also subject to the holistic BPM monitoring and control. Thus, the RPA flow can be replaced by full-scale automation later. Our combined approach encompasses more processes than the concepts can individually. Thus, BPM is enabled to automate further activities. The potential of our methodology was shown in the presented case study.

In addition to the mentioned benefits, our study is subjected to some limitations. The proposed approach is a theoretical concept which has not yet been validated in practice. It is based on the BPM life cycle of [11], which in our opinion is the most relevant and significant BPM model among the investigated literature. Other concepts might be more fitting in certain cases. We have automated the given workflow with the software tool UiPath [31]. There are various ways that may lead to slightly different results. Automation through BPMS could result in a faster process, but implementation would be more complex and expensive. A practical implementation considering a real use case could validate the benefits of our approach and show possibilities of useful integration. As RPA promises a significant improvement and can be performed quickly following a clear set of rules in our concept, it could lead to blind faith in this technology. RPA requires clearly defined and appropriate processes to function properly. The relatively simple implementation of RPA could encourage companies to automate unnecessary and inappropriate workflows. Thus, it could hinder critical scrutinizing and further development of significant business processes.

To conclude, BPM and RPA can be clearly distinguished. Both concepts have reciprocal advantages and disadvantages. In practice, they do not substitute each other, but are used simultaneously and context-dependent. Companies should therefore consider integrating RPA in their holistic BPM concept. Since RPA lacks scientific literature, there is a lot of potential for further research. IRPA seems worth investigating, as it could potentially replace traditional BPMS in the future. However, a human optimization from the as-is to the to-be process model remains necessary. Artificial intelligence is not yet capable of taking this important step on its own. Our methodology could also profit from broader empirical validation in a productive environment, considering more comprehensive processes and an enhanced set of criteria for the RPA usage, which we will aim for in future research.