Hybridizing humans and robots: An RPA horizon envisaged from the trenches

Contents lists available at ScienceDirect Computers in Industry journal homepage: www.elsevier.com/locate/compind Hybridizing humans and robots: An RPA horizon envisaged from the trenches Rafael Cabello Ruiz a , Andrés Jiménez Ramírez b,1 , María José Escalona Cuaresma b,2 , José González Enríquez b,⁎,3 a Servinform, S.A. Parque Industrial PISA. Calle Manufactura, 5.41927 Mairena del Aljarafe, Seville, Spain b Departamento de Lenguajes y Sistemas Informáticos. Escuela Técnica Superior de Ingeniería Informática, Avenida Reina Mercedes, s/n, 41012, Seville, Spain article info Article history: Received 5 December 2020 Received in revised form 10 December 2021 Accepted 23 January 2022 Available online 11 February 2022 Keywords: Robotic process automation Process mining Computer-human interaction abstract After the initial hype on RPA, companies have more realistic expectations of this technology. Its current mature vision relegates the end-to-end robotic automation to a less suitable place and considers the human-robot collaboration as the most natural way for automating robotic processes in real-world settings. This hybrid RPA implies a vertical segmentation of process activities, i.e., some activities are conducted by humans while robots do others. The literature lacks a general method that considers the technical aspect of the solution, the psychological impact of the automation, and the governance mechanisms that a running hybrid process requires. In this sense, this paper proposes an iterative method dealing with all these aspects and results from a series of industrial experiences. Additionally, the paper deeply discusses the role of process mining in this kind of method and how it can continuously boost its iterations. The initial validation of the method in real-world processes reports substantial benefits in terms of efficiency. © 2022 The Author(s). Published by Elsevier B.V. CC_BY_NC_ND_4.0 1. Introduction Robotic Process Automation (RPA) has received increasing attention in many different sectors in the last few years. It has prominently grown in the enterprise software market (Biscotti, 2018) where RPA has focused mainly on efficiently and automatically solving extensive administrative and back-office processes (Madakam et al., 2019). RPA is seen as another tool in the automation tool-set of an organization that enables mimicking the human actions that are performed on the user interfaces and, therefore, allowing for a higher level of automation. Although the initial hype and the existing predictions of billionaire investments for the following years (Fersht and Snowdon, 2018), nowadays, companies have more realistic expectations of RPA keeping a significant traction (Taulli, 2020a). These expectations go beyond high savings and fast returning of the inversion with fully automated processes (Penttinen et al., 2018). In turn, the mature vision of RPA starts by acknowledging that humans are the keystone in the RPA horizon (Kirchmer and Franz, 2019). 1.1. Problem statement In the early days of RPA, the main focus was on automating the highly repetitive branches of a business process that were executed by the employees (e.g., because the API of the system is not accessible) (Penttinen et al., 2018). Those frequent branches that (1) included a low level of exceptions, (2) involved an enclosed cognitive scope, and (3) were susceptible to human error were suitable candidates to automate with RPA (Fung, 2014). However, this horizontal segmentation of processes ended up having minimal applicability since these ideal branches —which should be fully automated— seldom occur (cf. left side of Fig. 1). On the contrary, a vertical segmentation of activities results to be a more natural approach. Here, part of the activities is identified as convenient to automate while other activities keep being executed by humans (Mendling et al., 2018) (cf. right side of Fig. 1). The automation of these processes implies the collaboration between robots and humans, leading to a hybrid approach which is the one that has been deployed most in recent years. https://doi.org/10.1016/j.compind.2022.103615 0166-3615/© 2022 The Author(s). Published by Elsevier B.V. CC_BY_NC_ND_4.0 ]]]] ]]]]]] ⁎ Corresponding author. E-mail addresses: [email protected] (R. Cabello Ruiz), a[email protected] (A. Jiménez Ramírez), [email protected] (M.J. Escalona Cuaresma), [email protected] (J. González Enríquez). 1 0000–0001-8657–992X 2 0000–0002-6435–1497 3 0000–0002-2631–5890 Computers in Industry 138 (2022) 103615 This collaboration implies incorporating the “human-in-the- loop” instead of end-to-end automation. Regardless it is understood as a human process with robotic activities, or a robotic process with human activities, its challenges can be tackled with different approaches (Jiménez-Ramírez et al., 2020; Axmann and Harmoko, 2020): 1. Asynchronous collaboration. Here, robots and humans keep their task queues which they process independently to each other. In this orientation, human workers may send activities to the robot queue and, hereinafter, continue with the following human task. 2. Synchronous collaboration. Here, the robot’s duties consist of “on-demand” activities that need to be started as soon as they are requested. In this orientation, the human keeps waiting for the robot to complete its task since the robot outcome is needed to complete the human task. The most common orientation is the first one, where the collaboration is done in an unattended way. Scenarios that are faced by this approach include, for example, processes where a robot gathers data from several information systems before a human comes into action. Here, the robot groups and presents the information in a structured way so that the humans may perform their cognitive actions in an agile way. The benefits which can be obtained are beyond the efficiency of humans. On the one hand, the human-robot contact points have complete control of the data, time, and activities needed in the decision-making. That is, the cognitive work of humans can be “McDonaldized”. On the other, this “McDonaldization” would pave the way to make these activities more efficient with Machine Learning approaches or if-then rules. Previous approaches have already identified and addressed the presence of humans within the RPA lifecycle. Some of them (Herm et al., 2020; Jimenez-Ramirez et al., 2019; Sigurðardóttir, 2018) enclose the human activity in the early stages of the identification of activities and processes to robotized, but they miss the later presence of humans during the process execution. In contrast, others (Ravindranath and Bhaskar, 2020; Mohanty and Vyas, 2018) acknowledge the collaboration between robots and humans mainly in data validation activities related to artificial intelligent contexts. All these approaches lack a general method to be applied in an RPA context with robot-human collaboration. 1.2. Contribution The current paper explores the aforementioned challenge of the asynchronous human-robot collaboration and proposes a method derived from industrial experiences in the RPA field. Besides the methodological support for RPA implementation, the method is addressed considering the socio-technical implications and pointing out the critical factors to conduct such implementations successfully, which are key contemporary challenges in the RPA field (Syed et al., 2020). The proposed method starts by structuring the contact points between robots and humans. This activity implies the design of a “landing area” which is the single point where the switching of the responsibility happens, thus avoiding the “cases in limbo”, i.e., where neither humans nor robots have the knowledge that they must treat within an activity. On the one hand, the design of this landing area must guarantee that all the required information is passed from the robot to the human in a structured way, with enough details about the conducted activities so that the human is confident in the robot’s results. On the other hand, humans should be able to pass their results in an agile and structured way so that the robot may continue the execution autonomously. Besides transferring the responsibility between the process actors, these designs should consider (1) the psychological perspective of the humans to prevent a negative feeling or rejection stances of the automation initiative and (2) a data-aware approach that centralizes all the interactions with this transfer point for being able to learn and improve its performance in subsequent versions. In addition, the proposed method leverages the strong benefits that process mining (van der Aalst, 2016) may bring to RPA —as already recognized by Geyer-Klingeberg et al. (2018)— in this specific context of robot-human collaboration. Specifically, process mining deploys the necessary mechanisms to visually and quantitatively analyze the metrics to divide activities between robots and humans potentially. In addition, it supports the continuous monitoring of human activities to make the “landing area” more efficient progressively, i.e., identifying “McDonaldized” activities that can be automated. Besides that, it may identify the friction points existing in the “landing area” due to incomplete transfers of knowledge between robots and humans that may lead to process redesigns. In general, process mining provides a comprehensive and automated Fig. 1. Workload assignment to humans and robots in both horizontal and vertical segmentation approaches. R. Cabello Ruiz, A. Jiménez Ramírez, M.J. Escalona Cuaresma et al. Computers in Industry 138 (2022) 103615 2 analysis of the processes, which typically requires a high effort. Moreover, this analysis typically starts with inaccurate or incorrect information since there is a natural and historical resistance from humans to automation (Pouget, 1913). However, process mining diminishes this threat by obtaining an accurate analysis of the processes that are being continuously monitored. Moreover, the proposed method has been applied in industrial settings in the domain of business process outsourcing (BPO). The results evidence a clear benefit in terms of time savings and, more importantly, in controlling the evolution of automation. Nonetheless, the early results of the method also reveal several limitations and lessons learned that disclose future lines for research. In a previous work (Cabello et al., 2020), an abstract overview of the method was presented. However, this paper significantly extends it by: • Materializing the method to be applicable to real RPA contexts. •Elaborating over a running example to demonstrate the applicability of the method. • Including a comprehensive study of the related works and an extensive discussion of the advantages and limitations of the proposal. The rest of the paper is structured as follows. Section 2 provides an introduction to the human-in-the-loop context within RPA. Section 3 describes a running example for such a context. Section 4 details the proposal. Section 5 reports the experiences in industrial settings conducting the proposed method. Section 6 provides a discussion of the method and its limitations. Section 7 summarizes the main related works within the scope of human-robot collaborations. Section 8 concludes the paper and elaborate on the open research lines. 2. Human-in-the-loop and RPA This section aims to describe the different application areas and scopes of RPA (cf. Section 2.1) and how the industry has pushed to acquire a strong maturity level (cf. Section 2.2), thus envisaging a natural human-robot collaboration (cf. Section 2.3). 2.1. RPA scope. Back and front office Medium and large-sized organizations have been increasingly adopting RPA in the last years for automating. They use the “Robotic FTEs” to set a “Virtual Back-office” which can perform manual activities without a direct human participation and with high efficiency and speed (Willcocks et al., 2017; Fung, 2014; Slaby, 2012). The main application has been done in the so-called “back-office” activities of Administration and Finance business scopes (Ortiz and Costa, 2020; Gotthardt et al., 2020). Activities in this area are, for example, analysis and report of finances, management of sales, payments, receipts, taxes, and accounting in general. All these activities share that they are systematic, have a significant volume of cases, require an enclosed cognitive effort, and are executed on existing information systems through their user interface, thus being good candidates for RPA (Penttinen et al., 2018; Fung, 2014). These early adopters of RPA were motivated by the high expectations on efficiency, cost savings, and capacity for adapting to potential fluctuations of the workload in the short term. Later on, the previous back-office approach was extended to incorporate the “front” activities too. Herein, a human tries to respond quickly to a request, for example, processing phone or online queries and claims in a Customer Service Center where clients might expect an answer at the moment. Front activities tend to be simpler —if compared with the back-office activities—, require an immediate response, and include a relatively wide variety of actions, although they are short in time. Traditionally, macros have been broadly used to automate these kinds of short but repetitive actions in spreadsheets or legacy systems. Moreover, sometimes, macros have been responsible for carrying out highly critical activities. Nonetheless, it implies a significant operational risk since macros are usually developed using “informal programming”, and the code remains on the employee side. Thus, they are associated with governance and maintenance problems. Here, a view of “RPA steroids” is applied to the traditional concept of macros. An “on-demand” approach of RPA has recently been applied to solve these deficiencies by substituting old macros with attended robots (Axmann and Harmoko, 2020). However, the “reaction time” factor is critical to consider RPA applicable in this scenario. For all these reasons, RPA has a strong presence in the back-office scope, which offers a faster return of investment (Geyer-Klingeberg et al., 2018). Nowadays, it is also present at the front-office scope since the separation of both is generally fuzzy or even there is no separation, so trying to separate them artificially would produce inefficient processes. 2.2. Industry stances for RPA maturity The advances of RPA have been mainly led by industry in the last years. The strongest leaders have delivered RPA solutions posing the focus on the back-office activities. Here the solutions of UiPath (2019), Prism (2019) and Automation Anywhere (2019) are highlighted. With the scope of the front-office, other vendors like PegaSystemPEGA (2019) are also highlighted. All of them have contributed to the maturity of RPA through the following actions: •Moving from the script-based robot programming to a comprehensive low-code or no-code robot construction environment. That is, business users are enabled to contribute to the robot constructions where deep technical skills are not required. These frameworks enable a continuously increasing plethora of components designed to address each specific administrative need that the robot should do. •Providing advanced tools for the governance, control, and management of farms of robots. They enable the required business capabilities to administrate the virtual back-office, e.g., controlling in real-time the state of the robots or reporting online performance indicators of the robotic processes. • Creating and maintaining RPA knowledge databases and RPA MOOC 4 environments allows an increasing number of people trained in RPA topics. This enables a new generation of workers qualified in RPA tools to be ready for companies. • Developing and providing advanced RPA components for solving cognitive activities. The use of Machine Learning within RPA has broadened its application to tasks that were not initially considered as candidates for robotic automation. Nonetheless, the current market landscape is divided into two different approaches regarding the inclusion of RPA tools and philosophy within the companies and their processes: 1. The BPM-centric approach: The Business Process Management (BPM) discipline has been helping organizations to control their processes efficiently (Weske, 2007; Dumas et al., 2018). It is about the analysis, design, development, deployment, and operation of the processes and integrating them with the company’s information systems. In this market approach, RPA elements are considered as other information systems to integrate into the 4 MOOC: Massive Open Online Course. R. Cabello Ruiz, A. Jiménez Ramírez, M.J. Escalona Cuaresma et al. Computers in Industry 138 (2022) 103615 3 BPM tool. One of the most prominent industrial examples in this orientation is Appian 5 , a benchmark in the BPM sector. Besides enabling the integration with different external RPA vendors, Appian has recently acquired an RPA company to offer their RPA elements within their own platform. 6 This approach presents several advantages. The BPM paradigm counts with a contrasted maturity in developing process vision, strategy, and objectives. This explains why there are numerous integration elements out-of-the-box in the majority of BPM tools. In addition, this integrated process environment enables putting the focus on the end-user experience. Nonetheless, the BPM- centric approach is mainly applied to heavy and complex processes with a centralized IT infrastructure. Moreover, BPM solutions typically require a business transformation and large economic investments, which might be non-affordable or costeffective if human FTE reduction is the only dimension to consider. 2. The RPA-centric approach: This market approach concerns those standalone RPA solutions which provide robot-human interaction for the specific situation of the designed processes. In contrast to BPM, these solutions mainly focus on organizing finegrain tasks on the robot side. In this orientation, UiPath 7 stands as one of the major leaders. Along with a comprehensive toolbox of robotic components, it allows data entry forms for the inclusion of humans in the robot workflows through its control and governance tool called “Orchestrator”. 8 One of the major advantages of these approaches is the detailed control of the human and robot activities that they provide, which, consequently, it enables precise management of the workload that both robots and humans generate to each other. In turn, the RPA-centric approaches lack a general overview of the company processes and, thus, the required exploitation mechanism to work on general process optimization. Beyond the standard batch-processing behavior of RPA, this approach includes the RDA (Robotic Desktop Automation) vision of the robotization/hybridization, i.e., robots that respond quickly to the humans’ on-demand request, the so-called “attended robots”. This entails a robotic process with fewer steps, which spends less execution time to produce immediate responses. In the case of UiPath, the RDA view is offered by the “Assistant tool” 9 which is an end-user solution to command the robots. RDA offers a simple mechanism to the user for interacting with the robots. However, since these solutions are conceived for an agile interchange of information, it lacks (1) support for complex or sophisticated interactions, and (2) comprehensive feedback from the robot in case of a KO occurs, i.e., the human would hardly know what has happened to the robot if it fails. 2.3. The human-in-the-loop scenario In the early times of RPA, companies tried to robotize 100% of the manual activities within their processes. That is, performing end-to- end automation, including as many complete process branches as possible. After the many cases of failures, mainly because of unrealistic expectations (Hindle et al., 2018), a more mature view of RPA left apart from this monolithic approach. In turn, the current view separates the fractions of the processes that are too complex and would produce the whole automation to be non-profitable. Discovering such non-automatable activities in the early RPA stages has been recognized as a key factor for the success of the RPA development that may, eventually, run stably (Jimenez-Ramirez et al., 2019). In that way, part of the process keeps being executed by humans instead of robots. Even with the incorporation of Machine Learning techniques in RPA, the number of suitable processes for end-to-end automation is fairly lower than the processes where only some parts of it are suitable. Therefore, including both robots and humans in the robotic automation brings more efficiency and effectiveness to RPA. This hybrid scenario, also called “human-in-the-loop”, is a more realistic and common scenario where: • Some of the activities are identified as suitable for execution by RPA due to their high frequency and systematic nature. • The rest are kept to continue being executed by humans due to their low frequency, cognitive nature, or because there is no simple identification of execution criteria. 3. Running example This section describes a motivating scenario and a running example that includes the main drawbacks that are addressed in the current paper. Fig. 2 depicts the process of one of the scenarios proposed for the validation of this study (cf. Section 5) 10 . Some of these process activities are designed to be executed by a human, i.e., “Validate Invoice & Copy to SAP”. This human activity can be seen as a subprocess that is decomposed in the following activities (i.e., the human must perform all these actions): 1. Look for the client’s invoice, which is associated with the running instance given the invoice number. The required invoice might be in different information systems, e.g., external ERPs, CRMs, shared folders, or even, in the email. Therefore, all these systems have to be visited until the invoice is found. 2. Validate the content of the invoice and that it is properly signed. The name, VAT number, and amount must match those recorded in the own SAP system. The invoice layout of each company might be different from other companies, thus, a variety of layouts exist. 3. In case that there is some missing information or errors (e.g., not found, unreadable, not associated with the given client), the client must be contacted to amend the errors. Then, the human activity ends, and the client has to start the overall process again. 4. In case that everything is correct, some invoice data must be inserted into the SAP system to evidence the validation. Then the human activity ends, and the overall process continues. This simple flow of steps is affected by several exceptional situations. Sometimes, the human finds none or more than one invoice within the different information systems. For some others, the client is not found in SAP. 4. A method to hybridize processes This section describes the industrial method that has come up from research experiences in the business environment (cf. Section 4.1Fig. 3 (a)). Furthermore, some key factors are presented to help the teams to measure the success of the application of the method (cf. Section 4.2, Fig. 3 (b)) which can be later enriched from a process mining approach (cf. Section 4.3, Fig. 3 (c)). 5 https://www.appian.com/hyperautomation/ 6 https://www.appian.com/news/news-item/appian-acquires-robotic-process- automation-rpa-company/ 7 https://www.uipath.com 8 https://www.uipath.com/product/orchestrator 9 https://docs.uipath.com/robot/docs/uipath-assistant 10 Due to confidentiality issues, all the activities that do not directly concern the running example are shown blurred. R. Cabello Ruiz, A. Jiménez Ramírez, M.J. Escalona Cuaresma et al. Computers in Industry 138 (2022) 103615 4 4.1. Defining the hybrid process The proposed method aims to help development teams to create a hybrid process and consist of the five key activities which are depicted in Fig. 3. From a technical perspective, the method starts with the segmentation of the process (i.e., identifying which parts of the process should be on the robot or on the human side) and the isolation of each segmented part. Then, an information system needs to be designed for each point where the ownership of the process moves between robot and human. Herein, it is important to highlight that such a design should pay special attention to the psychological perspective: the humans must feel that they are the ones “behind the wheel”. Lastly, the resulting hybrid process requires a supervision system that enables governance and control mechanisms. Additionally, from an analytical perspective, the previous activities tend to be data-intensive and, thus, require a data centralization activity that leverages all the generated data. 4.1.1. Segmentation and isolation of process activities It is essential to identify which parts of the process are the robots’ responsibility and which ones of the humans. Simultaneously, it is crucial to enable the required mechanisms to avoid humans bypassing or disrupting the robot activities. This prevention can be done by designing the execution method to “poka-yoke” task or by restricting the access to concrete systems designed just for the robots. The input of this step is a process design where part of its activities are manual ones executed by humans. This step aims to return (1) the best candidate portion (i.e., activities) that can be delegated to the robots (i.e., segmentation) and (2) the context of the information systems required to conduct such portions (e.g., system credentials or access level to shared folders). Example 1. Regarding the process of Fig. 2, the activity “Look for the invoice” might be identified as a candidate for the robot while the others may remain on the humans’ side. One simple mechanism to avoid that humans performing the robot activity is to grant access to the invoice systems only to the robots. As another industrial revolution, people involved in these processes might negatively perceive the impact of hybridization. Experience shows that, although these isolation mechanisms can be seen as “anti-Luditte” 11 , it is required to maximize the probability of success. Fig. 2. Human-in-the-loop example. Fig. 3. The defined process. 11 The Ludittes were the radical faction in the UK that destroyed textile machinery in the 19th century. R. Cabello Ruiz, A. Jiménez Ramírez, M.J. Escalona Cuaresma et al. Computers in Industry 138 (2022) 103615 5 The segmentation of activities is a relevant topic in RPA (Leno et al., 2020). Although it has not yet been extensively studied, some proposals address this problem by using Machine Learning techniques (Agostinelli et al., 2021; Geyer-Klingeberg et al., 2018), rule mining and discovering data transformation techniques Bosco et al. (2019) or probabilistic methods (Fazzinga et al., 2018), among others. In general, these methods pursue identifying parts of the process with a high volume of cases, prone to human failure, or which require limited cognitive effort (Fung, 2014). 4.1.2. Design of the robot-human transfer points Since the same process may include parts that are to be conducted by robots and parts conducted by humans, it is necessary to identify and design how to transfer the ownership of the process between robot and human and vice-versa, i.e., the checkpoints at the Border Control. Therefore, this step takes as input each isolated portion of the process identified in the previous step. The objective of this step is, for each isolated portion, to design a transfer point (i.e., a graphical information system which serves to the human) which, first, transfers the ownership of the process from the robot to the human and, second, transfers it back to the robot when the human activity is finished. Some important rules should be considered: 1. Its position within the process must be defined unambiguously. 2. Each transfer point has a unique direction for the information flow between the two kinds of workers. 3. The transfer of information of the process must be done completely and in a single step. Following these three rules, it can be ensured that the human has all the necessary information to continue with the process without looking back to what the robot has been doing. More precisely, when a human picks up a task –which was preceded by a robot activity in the process flow– from the queue, four different elements should be presented in the transfer point. First, the concise information needed to conduct their task, i.e., the outcome of the robot task, is necessary as input for this concrete task. Second, a series of potentially empty views related to the performance of the robot when creating such an outcome, i.e., meta-in- formation related to the input: • Confidence view: comprehensive information about how the robot has conducted its task so that the human may check if the main information is reliable. This view aims to generate trust in automation. •Uncertainty view: the degree of uncertainty related to the processing/interpretation steps done by the robot. In contrast to the confidence view, here the aim is to call the attention to the human who must check if the robot has interpreted its task properly. •Missing data view: list of elements that the robot could not retrieve or generate so that the human will have to do it. Similarly to the uncertainty view, human attention is called again but, this time, the human has to do something from the scratch, e.g., due to a robot malfunction. • Raw view: non-processed information that the robot has used to complete its previous task. This view aims to serve as a basis to check or repair those items pointed in the uncertainty and missing views, respectively. Third, in case that after the human task there is a transfer back to the robot (i.e., the next robot’s activity expects an output by the human activity), a custom output view is shown where the human introduces the required information in a structured form. While the human requires extensive information to complete the task appropriately, the output form should be concise and easy to entry. Otherwise, the human may suffer an increase of workload leading to a “clumsy” automation (Parasuraman et al., 2000). Nonetheless, this custom view should be designed to avoid misinterpretations to diminish the transfer errors, i.e., if the human expects a date, this input field should be validated before letting the human finish the task. And lastly, a special output view is presented to enable the human to break the flow in case some errors have been detected either on the input or meta-input information or in the proper human task that prevents passing the ownership to the robot. The tasks that go to this special output branch are tagged as KO (i.e., malfunctioning) and will wait into the queues of the managers or operators to be processed. In several situations, it is the human the one who starts or ends the process flow, i.e., the human activity is the first or the last of a process. In those cases, the design of the transfer point may lack input or output views, respectively. This design of the transfer points has implications in the workflow design of the robot too. Besides its specific functionality, the robot design must guarantee two main things: •When a robot continues after the human task, its input information must be aligned with the output of the transfer point. • When a robot precedes a human task, its output information must be sent together with the four meta information, i.e., confidence, uncertainty, missing, and raw. This step generates trust and robustness in the hybrid process. Without that, the human efficiency —and thus the process efficiency— decreases since it produces the effect of “I have to review the robot task because I do not trust.” Although both humans and robots may perform perfectly individually, experiences in the development of RPA acknowledge that this trust and robustness is necessary to avoid the “cold welding” effect that eventually produces the process to break. Generating the “man-behind-the-wheel” feeling. Reducing the employees’ awareness of the system is identified as one of the primary vulnerabilities in the automation projects (Parasuraman et al., 2000). It has implications on human and system performance and, ultimately, in a low trust in automation (Parasuraman, 1987). Therefore, in addition to the former rules, the design of these transfer points should aim to generate the capacity and the feeling that the human may know and control the global state and evolution of the process during its execution, i.e., avoiding reducing the situation awareness due to the automation. That is of utmost importance since, as indicated by the French Luddite, anarcho-syndicalist, and activist Émile Pouget (1860–1931), “the worker will only respect the machine the day it becomes his friend, reducing his work, and not like today, which is his enemy, takes jobs and kills workers” (Pouget, 1913). Furthermore, this feeling may have effects, first, in the early stages of the adoption of the new —hybrid— way of working and, second, to ensure the efficient execution of the process. Several elements help in acquiring this process knowledge. On the one hand, the robot’s OK/KO resulting state, i.e., if it has completed its activity with success or failure, respectively. The later information is accompanied by the operational details of the collaboration between the robots and the humans, e.g., its trace log. Example 2. Fig. 4 shows an example mock-up of a user interface designed to transfer the ownership to a human when activity “Looking for the invoice” (cf. Fig. 2) is finished. It can be seen how the robot identified by “RR101 (Rick)” transfers the ownership with the relevant data. Before the human task, “Validate Data”, is R. Cabello Ruiz, A. Jiménez Ramírez, M.J. Escalona Cuaresma et al. Computers in Industry 138 (2022) 103615 6 open, the human must see this interface showing the data extracted from the invoice in an editable way, being able to modify it if errors or missing information is found. Moreover, extended meta-information is depicted related to these data, that is: • A confidence view showing (1) the invoice which has been found along with the name of the information system where the robot found the invoice, (2) a screen capture of the invoice file in the mentioned information system, (3) the client and invoice numbers that were used by the robot to look for the invoice, and (4) a direct access to the complete trace of the robot execution. • An uncertainty view that guides the attention to such pieces of information in the invoice where the robot presents low fidelity. • A missing view that clearly point to those parts of the invoice that the robot could not extract. • A raw view showing the invoice in its original format before the extraction was performed. The human has both the option to continue with the associated task or the option to raise an exception if the normal flow of the process can not be followed due to some detected problems. Fig. 4 does not show the output view since the ownership is not transferred back to a robot in the process. On the other hand, the aggregated information related to the volume of work assigned to the robots and the execution state of each assigned case (i.e., pending, running, or completed) are also valuable to acquire this feeling. Although this information may result of interest mainly for managers or supervisors (see, for example, the next activity in the method), it needs to be accessible by the humans who execute the activity. Experiences show us that these workers rarely access this information, just mainly when errors occur. Nonetheless, it is important to create the feeling that this information is available to avoid perceiving that the virtual workmates operate in a black-box manner. 4.1.3. Deployment of governance and control tools This step addresses one of the most critical needs of a process supervisor: the integrated control of the whole process. For this, it takes as input the hybrid process design where transfer points act as glue between humans and robots. This step aims to return a system that follows the philosophy of a Business Activity Monitoring tool for real-time analysis (Kang and Han, 2008) which combines the human and the robot supervision under the same view. There are numerous use cases in the supervisor scope, e.g., balancing the workload, identifying bottlenecks and the occupancy and productivity of the workforce, managing the task queues of the different workers, managing alarms to control the values of specific KPIs like the number of pending cases, etc. In the context of RPA, these use cases are extended with the ones that involve the participation of robots, e.g., balancing work between robots and humans, taking the control of cases for manual execution, scaling, or descaling the digital workforce to fit some existing service level agreements, among others. To help the supervisor in making these decisions, specific KPIs are designed for the RPA context. The following ones are examples of KPIs taken from the industrial practice: • The number of KOs. That is, the robot operations that fail. They can be distinguished into two types: operative KO (i.e., the robot is unable to continue its work, e.g., due to a system malfunctioning) and business KO (i.e., the robot is able to complete its work but it deals with some kind of exception, e.g., the client does not exist in the CRM) that can be considered as a partial OK. The ratio of the number of KOs against the OKs and the number of subsequent KOs in a row are meaningful indicators to detect issues in the processes. •The number of retries. As a common strategy, robots are programmed to go back and retry in case that a step fails. Only when a retries limit is reached, the step is considered as failed (i.e., KO), and human intervention is required. Although this helps reducing the number of KOs, the operation time of the robot soars, thus, this number must be supervised. Fig. 4. Transfer point mock-up for the running example. R. Cabello Ruiz, A. Jiménez Ramírez, M.J. Escalona Cuaresma et al. Computers in Industry 138 (2022) 103615 7 • The occupation time of a robot. That is, the amount of time the robot is working on cases. It is interesting to distinguish between the different processes and subprocesses to identify bottlenecks. The ratio of the occupation time against the total uptime of a robot is relevant as well. To support this challenging scenario, the deployed system must allow the supervisor to control the processes, i.e., to complete the previous use cases, e.g., start/stop the robots, move a task between a robot and human, etc. What is more, these tools may also be designed to guide towards a process of governance that diminishes the human decision-making intervention. This can be achieved by programming rules —deterministic ones or based on Machine Learning— that automate the supervisor’s actions. Example 3. Example 2 describes the flow from the perspective of a human that works within a process instance. In turn, Fig. 5 shows an example mock-up designed for a process supervisor with a general view of the workforce involved in the process similar to Business Activity Monitoring tool. It includes, among other things, (1) a general view of the robots, (2) the queue of tasks that are pending for the robots, and (3) the individual state of each robot. Between other data, the process supervisor can check which robots are executing the activity “Look for Invoice”, the productivity of each of them (i.e., the working time/uptime), and all those robots which are halted due to any circumstance. The same supervisor is enabled with action buttons to govern the process. For instance, tasks in the robot queue (i.e., assigned and pending) can be reassigned to a human, thus automatically granting this human the access level required to perform such a task. Besides that, this governance can be ruled by alerts defined by the supervisor or the organization itself. Therefore, when an alarm is fired, the supervisor is notified and other actions can be triggered automatically. Although the previous step was focused on creating the perception that the human worker knows and controls the process, the current step is oriented to achieve that the cadence of tasks is ruled by the robot actions, which push tasks in the human queues. Experience shows that a faster adoption and greater process efficiency is generated with this kind of model where the human workers keep in charge of a reduced set of manual, relatively long, and cognitive activities which help the robots to accomplish the processes. 4.1.4. Data centralization In the current era, where data is one of the most valuable assets of an organization, it is not surprising that the success of the hybridization of the process depends on both data and its quality. On the one hand, having a centralized repository where the process traces are stored to analyze the process and workforce performance, which enables the aforementioned control and governance mechanisms more accurately, is essential. This repository may keep data related to each of the three previous activities of the method for both robots and humans. First, related to the information systems accessed in the hybrid process, their systems logs must be identified since they yield relevant information for the segmentation activities. As identified in existing literature (Agostinelli et al., 2020; Leno et al., 2020; Jimenez-Ramirez et al., 2019), the UI logs (i.e., logs acquired by monitoring the user interface of the humans while interacting with the information systems) may serve as an additional resource to help in the segmentation along with the systems logs. Second, the transfer points may generate useful traces to understand how humans interact with the new system. In addition, the systems and UI logs that are gathered within the transfer point (i.e., regarding isolate activities) enable performing local analysis, which tends to be more affordable than holistic process analysis. Such a holistic analysis can be done, nonetheless, with the hybrid process logs, which Fig. 5. Process overview mock-up for the running example. R. Cabello Ruiz, A. Jiménez Ramírez, M.J. Escalona Cuaresma et al. Computers in Industry 138 (2022) 103615 8 contain the traces of the hybrid process from a BPM perspective (cf. Fig. 6). Lastly, the calculated KPIs from the previous logs serve as a basis for analyzing the overall behavior of the hybrid process. This repository may keep these data related to both humans and robots in such a way that they are of similar quality, detail level, and structure so that they can be analyzed in an aggregate manner and as a whole. On the other hand, the continuous collection of data in a centralized repository enables the comparison of the real performance regarding the evolution from the manual process to the different versions of the hybrid process deployed over the time. Moreover, detecting hidden inefficiencies, errors, optimizations, or automation opportunities can be systematized based on this data. In that way, the improvements in the hybrid process can be pulled and motivated by the data pieces of evidence found. Example 4. Fig. 6 shows an example of a simplified centralized data store containing some process log events. These events are related to the actions which were performed on an instance of the process of Fig. 2. This log is useful to do a “post-mortem” analysis of the instance since, as can be seen, it showed an unforeseen KO in a robot task. Note that this log keeps low-level information regarding each individual action of the robots and activity-level information that aggregates them. The design of the custom columns for this process includes the state of the task, e.g., OK in case of successful completion, KO-operation in case the worker cannot execute the task, and KO-business in case that some business rule is not fulfilled. In addition, it includes the state of each individual robot’s action along with a description message. As shown in the last action of the robot —RR101 (Rick)—, an unexpected failure occurred when it checked some data of the invoice. It seems that some “o’s” are captured and, although it can be seen that another worker has eventually conducted the task, its screenshots and other related data can be used to improve the “Extract data” action of the robot to avoid similar errors in the future. The knowledge that can be gathered from this centralized data is later used as feedback for the next iteration of the method. For instance, the log related to the activity “Sent to SAP” might point to it as a candidate activity to be performed by the robots instead of the human workers. Experience shows that hybridizing a process is a continuous effort where each cycle of the method aims to (1) shift workload from the human side to the robot side, or (2) adapt the already-automated parts to address new requirements or detected errors. 4.2. Assessing the process improvements The previous steps aim to design a hybrid process that leverages the best of both humans and robots. Applying this process successfully would generate the necessary fluidity and robustness in the overall process, producing quality and performance improvements. These improvements are pursued in each cycle of the method. For evaluating that each cycle improves the previous process version, the development teams require a set of guiding metrics. In addition, these metrics would serve for pointing out what the next versions have to improve. The following ones are considered key metrics in the current proposal: • POK (Percentage of OK collaborations): This metric shows the balance between (1) the cases that have been conducted end to end as designed and (2) the total number of cases. Here, only those cases that involve the collaboration between robots and humans are considered. • PRC (Percentage of Rescued Cases): This metric represents the percentage of cases where a human has to take the manual control of a robot task. It aims to measure the degree of fluidity of the hybrid process. As described in the method, every time that a robot task fails, such a task remains in a dirty state that a human has to finish after seeing what the robot has done, e.g., looking at the trace log. Moreover, sometimes it involves reprocessing the task from the beginning. These manual interventions break the process flow, change the worker queues, and invalidate the process estimations. Therefore, keeping this metric as lower as possible should be a must. Example 5. Fig. 6 shows a rescued case in the task “Looking for the invoice” (cf. Fig. 2) from case “C00340”. As can be seen, it is performed by two workers, first, by the robot “RR1010 (Rick)” and then, after it produces a KO, by “Sussane L.” who rescues the case. • OMT (Operation Medium Time): It measures, on the one hand, the required “pure” time for executing the human tasks and, on the other, the required “around” time for managing them. The latter includes managing work queues, monitoring the process activities, and other non-productive time invested around the tasks themselves. Although OMT of humans always exists, the design of the new process must pursue to reduce the human time required in both effective executions and management. Fig. 6. Log example of a robot and human interaction. R. Cabello Ruiz, A. Jiménez Ramírez, M.J. Escalona Cuaresma et al. Computers in Industry 138 (2022) 103615 9 automation they offer. Both approaches identify the hybrid mode as one of the most important, considering that the robot coexists with the human throughout the execution of a process. Kirchmer and Franz (2019) reinforce the importance of humans within the automation ecosystem. In this sense, the authors argue that RPA projects would not be possible without their enablement and empowerment. The concept of “human-in-the-loop” refers to systems where an operator controls a device with the desired task (Stanciu and Oh, 2003). In the RPA literature, this concept has been coined from different perspectives. Ravindranath and Bhaskar (2020) define it as a method where a human agent manually validates a process activity. Taulli (2020b) has identified some RPA vendors, e.g., UiPath, that introduces the concept of “human-in-the-loop” by providing human interaction at any activity of an unattended robot. From Mohanty and Vyas insights (Mohanty and Vyas, 2018), in processes involving Artificial Intelligence (AI), humans spend much time collecting data. Their “human-in-the-loop” approach promotes leaving these types of activities to robots. In this sense, the authors propose that humans perform activities related to making sense of data and feeding those lessons back to the AI strategy for better performance. The inclusion of humans within the RPA lifecycle has also been considered in the literature. Jimenez-Ramirez et al. (2019); (Jiménez- Ramírez et al., 2020) propose the automation of robot testing, taking as a starting point the monitoring of the human work behavior in an outsourced process. Sigurðardóttir Sigurðardóttir (2018) defines the RPA lifecycle as a set of six main steps, i.e., process breakdown, development robots, process testing, execution, and verification in production and evaluation of benefits. Herm et al. (2020) present a framework for implementing RPA projects. However, in these approaches, the human is considered superficial, e.g., throughout the process analysis phase or process breakdown of the RPA lifecycle or during the automation need identification, not in the complete process. From a different point of view, Siderska (2020) enhances the human figure by delegating the most creative or strategic activities to him, leaving the robots to perform more routine ones. Furthermore, Kopeć et al. (2018) propose a human-centered method to design and maintain robots. Nonetheless, in this method, the human is not involved in the process execution. In summary, the current literature focuses either on including one human activity in an automated process or on just one phase of the RPA lifecycle. Conversely, these perspectives do not fit with the one presented in this paper, where the human factor has a holistic vision of the whole process or lifecycle. In addition, the proposals found rarely present case studies or industrial validations. In this sense, this paper has presented a running example based on industrial experiences in the sector where the approach is validated. 8. Conclusions and future works The movement of RPA has been raising the attention of both research and industry in the past years. Medium and large-sized companies have successfully adopted RPA to increase their competitiveness through this advanced automation solutions. Nonetheless, a broad set of environments were still unsuitable for robotic automation, like the small and medium-sized companies. Therefore, this paper brings a discussion about how different environments can become suitable by considering the human-in-the-loop. In that context, this paper describes a method to develop RPA projects when the collaboration between robots and humans is a must. Its goal is to end up with an efficient, robust, and fluid hybrid processes. For this, five steps are suggested covering from the initial segmentation of activities until the deployed processes’ design of control and governance mechanisms. This is an iterative approach where analyzing the process data is crucial to perform sound steps towards an optimized collaboration. Therefore, process mining plays an important role in the method. The method has been applied in real-life settings to show the applicability of the approach. Results indicate that the method provides substantial benefits in the efficiency, which is greater than 40% in the two conducted evaluations. Nonetheless, the method presents some limitations. First, it provides a set of steps that, although they are concrete, do not provide specific techniques or tools to perform them since they might depend on the company or the process itself. Second, the proposed method starts once the automation decision is already done. Therefore, the analysis of the organization, the selection of RPA tools, and other previous steps remain out of scope. Lastly, in the same way, the method scope ends with the design of the mechanisms to measure and govern the hybrid processes. Nonetheless, the precise rules or actions to conduct to scale or move the workload are not covered in the paper. For future work, we plan to (1) experiment with different metrics and rule patterns for the process governance in such a way that they can be automatically discovered, (2) elaborate more on the psychological and socio-ethical part of the method to disclose the barriers that keep appearing and can generate frictions in the hybrid process, and (3) perform controlled case studies in different size companies and processes to improve the soundness of the initial results. CRediT authorship contribution statement Rafael Cabello Ruiz: Conceptualization, Supervision. Andrés Jiménez Ramírez: Conceptualization, Methodology, Investigation, Writing − original draft, Investigation. María José Escalona Cuaresma: Writing − review & editing, Supervision. José González Enríquez: Conceptualization, Methodology, Investigation, Writing − original draft, Investigation. Declaration of Competing Interest The authors declare that they have no known competing financial interests or personal relationships that could have appeared to influence the work reported in this paper. Acknowledgments Research was partially supported by the NICO project (PID2019- 105455GB-C31) of the Spanish Government’s Ministry of Science, Innovation and Universities, Trop@ project (CEI-12-TIC021) of the Junta de Andalucía and by RAIL project (Platformfor the automatic and intelligence learning of Software Robots). References van der Aalst, W.M.P., 2016. Process Mining: Data Science in Action. Springer, Heidelberg. van der Aalst, W.M.P., LaRosa, M., Santoro, F.M., 2016. Donat forget to improve the process! Bus. Process Manag 58, 1–6. Agostinelli, S., Lupia, M., Marrella, A., Mecella, M., 2020. Automated generation of executable rpa scripts from user interface logs. In: Business Process Management: Blockchain and Robotic Process Automation Forum. Springer International Publishing, pp. 116–131. Agostinelli, S., Marrella, A., Mecella, M., 2019. Research challenges for intelligent robotic process automation. In: International Conference on Business Process Management. Springer, pp. 12–18. Agostinelli, S., Marrella, A., Mecella, M., 2021. 11 automated segmentation of user interface logs. Robot. Process Autom. De. Gruyter Oldenbourg 201–222. Automation Anywhere, 2019, Automation Anywhere: Global RPA Solutions.Available at: www.automationanywhere.com. Last accessed: December 2021. Axmann, B., Harmoko, H., 2020. Robotic process automation: An overview and comparison to other technology in industry 4.0. 2020 10th International Conference on Advanced Computer Information Technologies (ACIT). IEEE, pp. 559–562. R. Cabello Ruiz, A. Jiménez Ramírez, M.J. Escalona Cuaresma et al. Computers in Industry 138 (2022) 103615 16 Biscotti, F., 2018. Gartner market share analysis: robotic process automation. Worldwide. Blue Prism, 2019, Blue Prism, Intelligent RPA Platform.Available at: www.blueprism. com. Last accessed: December 2021. Bosco, A., Augusto, A., Dumas, M., LaRosa, M., Fortino, G., 2019. Discovering automatable routines from user interaction logs. In: International Conference on Business Process Management. Springer, pp. 144–162. Dumas, M., LaRosa, M., Mendling, J., Reijers, H.A., 2018. Fundamentals of Business Process Management. Springer, Berlin and Heidelberg. Fazzinga, B., Flesca, S., Furfaro, F., Masciari, E., Pontieri, L., 2018. Efficiently interpreting traces of low level events in business process logs. Inf. Syst. 73, 1–24. Fersht, P., Snowdon, J., 2018, RPA will reach $2.3bn next year and $ 4.3bn by 2022. as we revise our forecast upwards. Available at: 〈https://www.horsesforsources. com/RPA-forecast-2016–2022_120118〉. Fung, H.P., 2014. Criteria, use cases and effects of information technology process automation (ITPA). Adv. Robot. Autom. 3, 1–10. Geyer-Klingeberg, J., Nakladal, J., Baldauf, F., Veit, F., 2018. Process mining and robotic process automation: A perfect match. BPM (Diss. /Demos/Ind. ) 124–131. Gotthardt, M., KoiVulaakso, D., Paksoy, O., Saramo, C., Martikainen, M., Mlehner, O., 2020. Current state and challenges in the implementation of robotic process automation and artificial intelligence in accounting and auditing. J. Financ. Risk Perspect. 9, 90–102. Herm, L.V., Janiesch, C., Helm, A., Imgrund, F., Fuchs, K., Hofmann, A., Winkelmann, A., 2020. A consolidated framework for implementing robotic process automation projects. In: International Conference on Business Process Management. Springer, pp. 471–488. Hindle, J., Lacity, M., Willcocks, L., Khan, S., 2018. Robotic process automation: Benchmarking the client experience. Knowl. Cap. Partn. Kang, J.G., Han, K.H., 2008. A business activity monitoring system supporting realtime business performance management. 2008 Third Int. Conf. Converg. Hybrid. Inf. Technol. 473–478. Kirchmer, M., Franz, P., 2019. Value-Driven Robotic Process Automation (RPA). In: International Symposium on Business Modeling and Software Design. Springer, pp. 31–46. Kopeć, W., Skibiński, M., Biele, C., Skorupska, K., Tkaczyk, D., Jaskulska, A., Abramczuk, K., Gago, P., Marasek, K., 2018, Hybrid approach to automation, rpa and machine learning: a method for the human-centered design of software robots. arXiv:1811.02213. Leno, V., Polyvyanyy, A., Dumas, M., LaRosa, M., Maggi, F.M., 2020. Robotic process mining: vision and challenges. Bus. Inf. Syst. Eng. 1–14. Madakam, S., Holmukhe, R.M., Jaiswal, D.K., 2019. The future digital work force: robotic process automation (RPA). J. Inf. Syst. Technol. Manag. 16. Mendling, J., Decker, G., Hull, R., Reijers, H.A., Weber, I., 2018, How do machine learning, robotic process automation, and blockchains affect the human factor in business process management? Communications of the Association for Information Systems 43, 297–320. Mohanty, S., Vyas, S., 2018. Reimagining Competitive Advantage in the AI World. Springer, pp. 41–74. Ortiz, F.C.M., Costa, C.J., 2020. Rpa in finance: supporting portfolio management: Applying a software robot in a portfolio optimization problem. 2020 15th Iber. Conf. Inf. Syst. Technol. (CISTI) 1–6. Parasuraman, R., 1987. Human-computer monitoring. Hum. Factors 29, 695–706. Parasuraman, R., Sheridan, T., Wickens, C., 2000. A model for types and levels of human interaction with automation. IEEE Trans. Syst., Man, Cybern. - Part A: Syst. Hum. 30, 286–297. PEGA, 2019, PEGA, Changing the way the world builds software. Available at: www. pega.com. Last accessed: December 2021. Penttinen, E., Kasslin, H., Asatiani, A., 2018. How to choose between robotic process automation and back-end system automation? 26th Eur. Conf. Inf. Syst., ECIS 2018, 1–14. Émile Pouget, 1913, Sabotage. Charles H. Kerr & Company. Ravindranath, I.R., Bhaskar, R., 2020. Review robotic process automation among artificial intelligence. Int. J. Adv. Res. Educ. Technol. (IJARET) 7, 10–14. Jiménez-Ramírez, A., Chacón-Montero, J., Wojdynsky, T., González Enríquez, J., 2020. Automated testing in robotic process automation projects. J. Software: Evolution and Process., e2259. Cabello, R., Escalona, M.J., Enríquez, J.G., 2020. Beyond the hype: RPA horizon for robot-human interaction. Business Process Management: Blockchain and Robotic Process Automation Forum 185–199. Siderska, J., 2020. Robotic process automation-a driver of digital transformation? Eng. Manag. Prod. Serv. 12, 21–31. Sigurðardóttir, G.L., 2018, Robotic process automation: dynamic roadmap for successful implementation. Ph.D. thesis. Reykjavík University. Slaby, J.R., 2012. Robotic automation emerges as a threat to traditiomal low-cost outsourcing. HfS Res. Stanciu, R., Oh, P.Y., 2003. Human-in-the-loop visually servoed tracking. Int. Conf. Comput., Commun. Control Technol. (CCCT) 318–323. Syed, R., Suriadi, S., Adams, M., Bandara, W., Leemans, S.J., Ouyang, C., terHofstede, A.H., van de Weerd, I., Wynn, M.T., Reijers, H.A., 2020. Robotic process automation: Contemporary themes and challenges. Comput. Ind. 115, 103162. Taulli, T., 2020a. Future of rpa. In: The Robotic Process Automation Handbook. Springer, pp. 293–316. Taulli, T., 2020b. Rpa vendor evaluation. In: The Robotic Process Automation Handbook. Springer, pp. 101–114. Jimenez-Ramirez, A., Reijers, H.A., Barba, I., Del Valle, C., 2019. A method to improve the early stages of the robotic process automation lifecycle. In: International Conference on Advanced Information Systems Engineering. 446–461. UiPath, 2019, UiPath Enterprise RPA Platform, where the future of RPA arrives first. Available at: www.uipath.com. Last accessed: December 2021. Viehhauser, J., Doerr, M., 2021. Digging for gold in rpa projects – a quantifiable method to identify and prioritize suitable rpa process candidates. In: La Rosa, M., Sadiq, S., Teniente, E. (Eds.), Advanced Information Systems Engineering, eds., Springer International Publishing, Cham, pp. 313–327. Wanner, J., Fischer, M., Janiesch, C., Hofmann, A., Imgrund, F., Geyer-Klingeberg, J., 2022, Process selection in RPA projects - towards a quantifiable method of decision making, 17. Weske, M., 2007. Business Process Management: Concepts, Languages, Architectures. Springer. Willcocks, L., Lacity, M., Craig, A., 2017. Robotic process automation: strategic transformation lever for global business services? J. Inf. Technol. Teach. Cases 7, 17–28. R. Cabello Ruiz, A. Jiménez Ramírez, M.J. Escalona Cuaresma et al. Computers in Industry 138 (2022) 103615 17