Keywords

1 Introduction

Currently, the concept of Robotic Process Automation (RPA) is an accepted concept that has been maturely deployed in medium-large organizations where it has focused mainly on efficiently and automatically solving large administrative and back-office processes [9]. In this context, there has been a very high initial hype because very high returns were expected in the short term. However, and after a landing phase of unrealistic expectations, the RPA movement has taken significant traction [13]. In recent years, its technology has matured rapidly, while it has become sophisticated in different lines [2]:

  • Incorporate more “low code” approach elements. Thus, construction agility, deployment control, component reuse and “developer independence” (increasingly relevant factor in the software industry) are an improvement.

  • Incorporate machine learning elements that allow the systematic actions to be extended to others where cognitive elements have intervened to date.

  • Facilitate the scalability and governance of numerous robotic processes; the existence of hundreds of robot farms requires control + command elements similar to the SCADA systems of an electrical network.

  • Incorporate “human in the loop”, promoting human-robot collaboration.

This last point is especially relevant since RPA was initially oriented towards monolithic processes, where automation was complete, end-to-end covering the different branches and activities of the process [11]. However, it was found that this approach was excessively unrealistic, since the number of these ideal robotising processes was very low, and even required input data structuring that did not obey the reality of the processes. On the contrary, after the advance of the first years, it was detected that hybrid scenarios of robot-human collaboration were the most natural. In them, a part of activities was identified as convenient for execution by RPA, due to its high frequency and systematic nature [10]. The rest of the activities continue to be carried out with human participation, due to their low frequency, cognitive nature, or where there was no simple identification of performance criteria. This “blended” approach is the one that has had the most deployment in recent years. The challenge involved is tackled with different approaches [1, 6]:

  1. 1.

    Segmentation of robot/human activities of the process, with the structuring of the robot - person contact points in the form of a “landing area” where the activity switch occurs. The key aspects of this “landing area” are the structuring of the data required for that activity switch completely, autonomously for both humans and robots, as well as control of the switch, avoiding the terrifying aspect of “cases in limbo” (cases of the process that neither robot nor human has clear or agile knowledge that they must treat).

  2. 2.

    Encapsulation of relatively short sequences of human activities of a systematic nature, theoretically of full application of RPA, where the immediacy factor of execution on demand is critical for the business, not being possible to “packet” or demand activity for the robot.

The first approach applies, for instance, to cases of information collection by robots from different information systems, so that once the required data set is available, the robot makes them available in a structured way for the human to execute cognitive action required or continue the process. The benefits obtained are multiple, not only the expected efficiency but others of greater significance that were not initially considered in a relevant way. In particular, the complete control of data involved in decision-making “within the process”, as well as complete control of times and activities carried out by people with the data provided by robots. Therefore, an “mc-donalization” of the work of people in “stealth mode” is carried out. And at the same time the ways are laid so that once cognitive actions have been mc-donalized, they can be identified as efficient, either through deterministic rules or through machine learning algorithms. The second approach applies especially in call centres or back-office activities, applying “RPA steroids” to the traditional concept of “macros”. Macros are not a new idea but were limited to mostly simple embedded spreadsheet actions or script execution on legacy systems. However, there were significant governance and maintenance problems, since most of these macros are based on “informal programming” carried out by the employees themselves. Even though activities were carried out in some cases of high critically, there were significant risks of operation (ignorance of the code, lack of maintenance capacity, high dependence on the person who carried it out). The application of RPA to these activities on demand of people allows solving these challenges, by providing a framework of governance and control, integrating interaction capabilities with any information system and execution of actions of any degree of complexity. However, the “reaction time” factor is critical, and that the human cannot remain “waiting” for the completion of the robot’s activity since the efficiency would degrade and/or the process may lengthen its completion time. With this short introduction, we start from the hypothesis that Process Mining can be an extremely useful tool to facilitate this two-way RPA extension in human-robot collaboration [4]:

  • In the case of a single process mining approach, it allows identifying both visually and quantitatively the elements of potential segmentation of robot vs. human activity. And equally important that the identification is the monitoring of the evolution of the process progressively since different segments of the “mc-donalization” are executed by robots instead of people. And equally important is identifying the “friction points” on the switch between robot and person due to incomplete data transfer and process control (what would be called a cold “weld” of the redesigned process).

  • In the case of multiple process mining approach, it is possible to identify the “long tail” of systematic human actions in which attended robots allow the human being to have an “exoskeleton of administrative activity”, along the lines in which mechanical exoskeletons are used on industrial production lines for heavy-duty. The identification of the long tail must allow identifying the aggregate volume as the prioritization of the candidates to robotize and its impact. There is a common benefit, and that is that the evaluation of processes to be robotized has generally required a high effort of analysis, generally starting from incomplete or even incorrect information (let’s not forget that a process is analyzed to partially eliminate the human factor from the process, therefore that resistance to change is relevant). Process Mining contributes efficiency in this process of analysis and reduction of the “time-to-market” of obtaining results while incorporating a framework of continuous systematic evaluation.

With this initial context, in this paper, we analyse how the incorporation of human-robots and the users of process mining in RPA context, can offer a high positive impact, not only in large administrative and back-office processes of the medium-large company. They can also offer a suitable solution for SME (Small and Medium Enterprise). With this aim, this paper is structured as follow. In Sect. 2 a background description is presented. Section 3, presents a general view of our approach of human-robot interaction, which is illustrated with a real example in Sect. 4. We finalized the paper with related work (Sect. 5) and with conclusions and future works in Sect. 6.

2 Background

In the last 5 years, there has been a very high increase in the use of RPA (Robotic Process Automation) in medium-large organizations. Robotic Process Automation (RPA) is the automation of a wide set of administrative tasks using “Robotic FTE’s” configured to have a “Virtual Backoffice” that perform manual activities without incorporating direct human participation with high efficiency and high speeds [15]. The application of RPA has been carried out mainly in the so-called “back-office” activities, mainly related to the areas of Administration and Finance, which includes financial analysis, financial reporting and planning, managerial accounting, treasury and cash management, payment and receipt of accounts, risk management and taxes. Another area of application in RPA has been carried out in customer service activities, in queries and claims for the services and/or products provided. These back-office activities are based on carrying out tasks, mainly administrative, systematic, of relevant volume, on already established information systems, where the required cognitive activity is limited [12]. The driver of the utilization of RPA has been fundamentally the generation of efficiency in these processes and cost savings in the main measure, and additionally the availability of flexibility of execution capacity to adapt to changes in the variable and fluctuating workload in the short term. Robotic Process Automation (RPA) is the automation of a wide set of administrative tasks using “Robotic FTE’s” configured to have a “Virtual Backoffice” that perform manual activities without incorporating direct human participation with high efficiency and high speeds [8]. In the initial scope of RPA application back-office processes, it was later extended to activities called “front”, in those where a human responds to a request for resolution of incidents, queries, claims, in usual environments of Customer Service Centers, mainly online both by phone and by other telematic channels. The main difference between “back” activities compared to “front” lies in that while “back” activities are usually complex, with relatively medium-high process time, highly systematized, generally requiring scaling between different levels of internal support, front activities tend to be more atomic, require immediate action (frequently the user or client is in interaction while the process is carried out), their process time is reduced and they involve a very high diversity of activities. It is for all these reasons that the initial application of RPA has been carried out strongly first in the areas of back-office where the return on investment materializes more quickly and then has been extended to the areas of front-office later. This application extension has also been favoured in that the separation between back-office and Frontoffice is often fuzzy and there is generally a union of back/front activities that separating them in a watertight way makes processes inefficient. Over the last few years, powerful manufacturers of RPA solutions have established themselves in the market, with the main UiPath, BluePrism and Automation Anyware, being the natural focus of RPA application the activities of Backoffice [14]. The focus of RPA application in Front activities carried out by the manufacturer PegaSystems is remarkable. These solution manufacturers have provided benefits in the maturation and extension of the application of RPA through:

  • Availability of component framework and robot construction environment with a low-code approach that allows for the agility of construction, reuse of components and “developer independence” (increasingly relevant factor in the software industry) are significant tools for the control of deployment and governance of robot farms of dozens of robots that execute operations in real-time, where the identification of incidents in their execution is a critical factor

  • Disseminate RPA knowledge and application methodologies, so that the generation of RPA-trained personnel has accelerated over time, reducing the barriers to entry of such knowledge through the availability of RPA MOOC environments, generating high liquidity of personnel qualified in RPA tools.

  • Incorporate machine learning elements that allow the systematic actions to be extended to others where cognitive elements have intervened to date. These factors of market needs together with the availability of solutions have allowed the explosion of RPA application. There are numerous experiences with massive deployments of dozens of robots in financial companies and utilities, where the back-office and front-office processes are highly relevant.

These massive deployments initially tried to address a one hundred per cent RPA approach to processes, trying to incorporate all possible activities to be carried out in the process in robot execution, with very high expectations for savings and return on investment. However, as the deployment of RPA in these organizations has matured, it has been confirmed that this approach has been excessively optimistic, since it has the weakness of implying a monolithic application approach, trying to incorporate the end-to-end process into RPA. covering the different branches and activities of the process. In many, there are fractions of the process whose casuistry or complexity do not make the incorporation of RPA profitable to address them. In turn, the discovery effort of all the activities to be carried out in the processes has been identified as a relevant factor both in the investment required for the deployment of RPA and in the time involved from the identification of opportunity to the availability of RPA. running stably. That is why the RPA approach is considered a much more efficient and effective approach considering from the beginning the collaboration of robots and people in an integrated way in the process, which has been called “human in the loop”. Therefore, hybrid scenarios for robot-human collaboration were established in the natural ones, where:

  • A part of activities were identified as suitable for execution by RPA, due to their high frequency and systematic nature

  • The rest of the activities were kept to be executed by the robots, due to their low frequency, cognitive nature, or where there was no simple identification of execution criteria.

3 Robot-Human Interaction and Process Mining

In this section, we are going to present a proposal that we have drawn mainly from research experience in the business environment and that is validated in Sect. 4 with a real example. This proposal starts with the hybridization scenario discussed in the previous section.

3.1 Applying Our Approach

Our approach is thinking about a very concrete set of stakeholders. It is oriented to help the development team who wants to create an RPA hybrid solution enriched with process mining. In this sense, the first part of our approach presents a set of steps that should be executed and consider the definition of the RPA hybrid solution. The factors identified to perform a successful hybridization are presented in Fig. 1 as a process composed of five steps that should be executed to rightly defined the hybrid process.

Fig. 1.
figure 1

The defined process

  • Step 1.- Identification of the activities carried out by both robots and people. It is necessary to clearly and exclusively segment the activities carried out by each one, but at the same time, it is necessary to include in this identification of activities the design of mechanisms that prevent the human from bypassing the robot. This can be done either by designing execution methods for “poka-yoke” tasks or by preventing the human from accessing certain information or system required for the execution of the tasks that must be performed on the robot. Although this process design orientation may not seem necessary, the experience in the deployment of RPA indicates that to maximize the probability of success, it is necessary to include these elements that some might consider “anti-ludicrous” mechanisms, since on numerous occasions the people involved in the human-robot hybrid process they visualize the impact on jobs that the incorporation of RPA implies for them

  • Step 2.- Identification and design of how the transfer of information is carried out between robot-human and/or vice versa. Although the clear and exclusive identification of human and robot activities has been carried out, there are always points where to achieve the overall flow of the process, it is necessary to transfer the “ownership” and execution of the process from one to another. They are the checkpoints of the Border Control. Their characteristics are that they must be clearly and unambiguously defined where they are, with a unique sense of the human/robot or robot/human information flow, and the transfer information must be complete and transferred in one go. These conditions are important to ensure that the human being can continue with the process without reprocessing or reworking what the robot has already done, which would cause a loss of efficiency in the process. At the same time that it would generate distrust in the human being of what has been done performed the robot, producing the effect “I review what the robot has done because I do not trust.” That is why in these checkpoints it is critical to provide the human-robot with all the information required for the continuity of the process, and if for any reason it has not been possible to complete or generate any information, it must be identified and the process marked as “KO”, i.e. failed, To avoid confusion. In the process, these Checkpoint points must, therefore, guarantee the robustness of the hybrid process, experience shows that if it does not have that robustness, although the activities performed by robots and humans are perfect, there is a “cold welding” effect that produces the process is split.

  • Step 3.- Generation of capacity and feeling that the human who executes the human part of the process knows the global evolution of the process in real-time. This factor is critical both for the efficient execution of the process and to ensure effective change management in the adoption of the new way of working. The ultimate goal of achieving the feeling that the human is “man-behind-the-wheel”, or as the French Luddite anarcho-syndicalist activist Émile Pouget (1860–1931) indicated, “The worker will only respect the machine the day it is become your friend, reducing your work, and not like today, who is your enemy, takes jobs and kills workers”. The elements that are part of this knowledge of the situation of the process can be synthesized in:

    • Indicators of the number of cases of the process in execution in its different states (pending to be treated by robot and human, in the process by each and completed)

    • State OK/KO, i.e. passed or failed, of each of these cases completed

    • States of operation of each of the robots that collaborate with humans and details of the activity carried out.

    It is critical to generate the feeling that this information is there for the human when s/he needs it, in an agile way, although most of the time s/he does not need it. Experience shows us that most of the time the humans who execute the process do not need this information, only when there are incidents in the execution of the process is access to this information necessary, avoiding the perception of unknown operation black box.

  • Step 4.- Deployment of tools for control and governance of the whole process. The integrated control of the process must be carried out in such a way that the process supervisor has the information in real-time of how the process is executed as a whole, in both the human and robot parts, allowing to balance workload between humans and robots, managing respective work queues, identify the degree of saturation of human and robot capacity, the status of OK and process KOs globally, and even, if necessary in exceptional circumstances, take cases in process or pending execution for manual execution. These elements of the process are part of the elements of command and control of the integrated process, but as important as they are they make a design of the government of the process itself that guides its automatic execution and with the least human decision-making intervention. Although as indicated in the previous point that the human who executes the manual or cognitive part of the process must have the perception that he knows and controls the process, the design of the process must be oriented so that the cadence of activities of the process itself is marked by the robot’s actions, aiming for robots to generate human work queues. This automatic process pulse dialling will generate greater process efficiency while reducing process adoption times by forcing faster and more focused adoption.

  • Step 5.- Centralization of human process data - robot. Having a centralized repository of executed cases, their trace of execution, human actors and robots that have participated throughout its execution is essential to allow the aforementioned elements of process control and governance and online visibility of the process situation. But even more, it is the essential tool to evaluate the real performance of a new process executed in a hybrid way, its evolution over time and the detection of possible hidden inefficiencies. In addition, it becomes the “post-mortem” identification tool for actions performed by humans and robots in the face of unforeseen KOs or performance values out of range.

3.2 Measuring the Process

The design of the hybrid human-robot process it is not a simple problem and it requires the development team to work a guide for a set of measures that guarantee that the development is being successfully applied. It requires takes into account the above steps and implements them effectively will generate the fluidity and robustness necessary in the new process. However, it is critical to define a set of key indicators that help the team to value the success of the new process that is established. In our approach, the next ones are considered:

  • The captured data allow knowing the complete cycle of activity of robots and humans, having enough fine grain of associated information for the discovery of causes involved in the KOs of the process? Percentage of process OK considered as cases that are executed end to end in human-robot collaboration as designed.

  • Percentage of cases that have remained at some point in the process without being automatically transferred between humans and robots, and have had to be manually rescued to be manually inserted back into the process or reprocessed in the process.

  • OMT (Operation Medium Time) of human activities concerning the forecast before design. In this aspect, it is necessary to identify the “pure” time for the execution of human tasks, and also, but separately, the time “around” the execution of tasks, related to the management of work queues, monitoring of ongoing activities, time non-productive around the task.

  • Time of execution of tasks by humans that should be performed by robots, due to their unavailability, required operation windows exceeded, the operation performed OK only partially by robots. This indicator shows the degree of underperformance of the process, and the expectation of its improvement.

The implementation of a continuous improvement cycle based on these indicators allows us to iterative go through the 5 identified phases (see Fig. 1), helping us to solve the following questions:

  • What new activities can be done by robots instead of humans? Are there systematic failures in tasks performed by robots that impact humans? How can they be avoided and make the process more robust?

  • A higher than expected human BMT may hide friction in the transfer of information. Is there partial information on robots made available to humans? Are there new manual human activities not initially contemplated?

  • What information is mainly used by humans for the execution of their tasks? Is there other information required and not covered?

  • Are the process queues generated by the robots sufficiently optimized or are there capacity bottlenecks? Is the information required at the time it is needed?

  • Are the data collected from robots and humans sufficient for the complete and effective measurement of the efficiency generated? The captured data allow knowing the complete cycle of activity of robots and humans, having enough fine grain of associated information for the discovery of causes involved in the KOs of the process?

3.3 Enriching with Process Mining

How to market technology solutions have addressed this challenge today comes from two different poles: \(\bullet \) Centric BPM: BPM (Business Process Management) solutions that have allowed the design, construction, deployment and operation of processes through workflows and their integration with information systems, to which RPA elements have been incorporated as yet another system to integrate. The most significant example of this orientation is Appian, a benchmark in the BPM sector, which has facilitated integration with market RPA tools, and even by acquiring the RPA company. The advantages of this approach are its maturity in the process vision, the availability of out-of-the-box integration elements and the focus on the end-user experience that an integrated process working environment has. The disadvantage is that its application focus is mainly heavy processes, extensive in human activities, of high complexity, as well as the cost of the technology involved, which sometimes prevents a return on investment based on the efficiency generated (cost of human FTE removed). \(\bullet \) RPA centric: RPA solutions that integrate elements of robot-human interaction in the event of or in certain situations of the designed process. As the most significant example of this orientation is UiPath, which has incorporated the generation and management of data entry forms and/or validation of information by humans, as an extension of its robot control and governance tool (component called “orchestrator”). The advantages of this approach are that it allows complete control of human activities within the process of interaction with the robot, as well as guiding the cadence of the process of the robot towards the human. However, the main disadvantages of this approach are the limited benefits in sophisticated interaction of the human with the robot (complex data involved, integrated validations and logic, global process vision), as well as lack of exploitation, monitoring and process control benefits. integrated both humans and robots. Additionally, the centric RPA approach also incorporates the RDA vision of robotising (RDA: Robotic Desktop Automation), focused on under-command activities (“unattended robots”) where a human on-demand makes specific requests to execute automatism. This automatism generally implies a reduced number of activities by the robots, reduced execution time of the robots, and the need for immediate feedback to the user who requested the OK/KO completion. In the case of UiPath, this approach to RDA is made using its UiPath Assistant tool, which is its end-user manager for the available unattended robots. Although its operation is simple for the user, it has very limited deficiencies regarding feedback and sophisticated interaction with the user, and in the case of KO of the robot, the user has reduced information and is not quick to know what has happened in the process.

As previously indicated, the deployment of RPA systems that allow human-robot collaboration is not a big bang process, on the contrary, its success is associated with a process of continuous improvement. Process Mining allows a successful initial design of collaboration and continuous monitoring of the process to progressively increase the results, based on new activities identified to be carried out by robots and a progressive decrease in KOs. In this robot-human hybridization scenario, the Process Mining of the process constitutes a facilitating tool for said hybridization. Thus, Process Mining allows activities to be carried out as they are currently carried out before the design of the new hybrid process. This survey of the process should aspire not only to the identification of the activities involved carried out by humans in the process but also and most importantly, the effort involved in each activity to evaluate the business case of the hybridized process and its return on investment against the applied change. The great challenge of applying Process Mining to this type of process of the potential application of human-robot hybridization is the difficulty of having traces of human activity of each one of the activities carried out by humans, with which we have a relatively The grossness of human activities, which implies a significant degree of uncertainty and/or inaccuracy of the AS-IS situation, can invalidate the starting premises in the business case to be carried out. Once the robot-human hybridization process has been designed, this design should allow traces and activity records of the robots and humans to be available, which in turn allows Process Mining to be continuously incorporated into this evaluation, as information is now available “finer grain” in the process. The segmentation itself, a structure that requires hybridization, forces the generation of this process execution data that was not previously available. That is why the application of Process Mining in an RPA-human hybridization scenario should not be considered with an application focus of eighty percent of the effort in the design of the AS-IS and TO-BE process and twenty percent in monitoring. But on the contrary, thirty percent of the effort in design and evaluation of hybrid-robot MVP (minimum viable product) focusing on the elements of the greatest contribution of the robot and identification of critical aspects of the initial deployment, and seventy percent of the effort in continuous improvement of the process and efficient process monitoring.

4 A Real Project. Learning from the Trenches

The proposal presented in this work has already been applied in a real project entitled RAIL. This project was developed in collaboration between Servinform Inc. and the University of Seville. The objective of RAIL is to propose an innovative solution and supported by computer tools to identify the business activities to be robotized without any intrusion or requirement with the existing information systems, capturing the data of execution of the tasks at the same time that they are carried out by back-office people and automatically identifying the robotization elements of processes to be implemented, including cognitive elements. Rail is made up of a series of modules that allow its correct definition:

  • Non-intrusive monitoring. Software component that can be installed in the workplace that intelligently captures and completes the interaction data with transactional systems, in real-time and generates a structured dataset for the analysis of the process, without causing any type of degradation in the person’s activity backoffice nor jeopardizes the security and confidentiality of process data.

  • Automatic process survey module. The component allows automatic generation of the work process with all workflow variants from the logs and images resulting from the non-intrusive monitoring module. This automatic process generation is based on the application of image-hash, image-match and OCR algorithms on said dataset.

  • Qualitative evaluation module. On the automatic survey of the process resulting from the previous module, iterative analysis and refinement of the resulting process are applied by modifying the configurations of the different algorithms to generate new refinement of the analysis and comparatively evaluate the results obtained. The integration of ProM makes it easier for the user to refine the processes resulting from the analysis, facilitating the use of process generation algorithms and identification of evaluation metrics. As a result, the representation of the faithful image of the executed process is obtained, and in particular of the branches of the process that constitute exceptions and/or infrequent activities. These activities constitute the elements of the process that are most difficult to identify and which in turn generate the critical points of robotization since their non-identification generates untreated exceptions to the process that cause the robot to stop or incorrect actions (Fig. 2).

  • Module for the identification and deployment of predictive algorithms. It includes the learning components of the expert system (a neural network that will allow any type of action or actions as input, be it mouse clicks, keystrokes or any type of text and will transform all this type of input into a corpus) and the prediction component (Once the neural network has been trained, we are using the learning product to predict the behavior of the robot, so that it asks the RAIL system “what should it do” to continue with its functional process).

Fig. 2.
figure 2

A global view of RAIL project

The Module 1 component aims to capture images and mouse and keyboard presses, to extract all the possible information from the process with which a person works on information systems, generating capture records that must allow the description of your full activity. Modules 2–3 are made up of three stages (Execute, Analyze and Configure) that can be cyclically executed as many times as desired. The component allows integration through the ProM framework, which allows the execution of an extensible set of algorithms for log management, process discovery and analysis. The Execute stage applies image analysis techniques using algorithms including image fingerprint, template matching and OCR. The Analyze stage includes various Group and Process refinement algorithms, to allow the discovery of groups of similar processes as well as exceptions to general threads. The Configuration stage allows modifying the configurations of the different algorithms to generate new refinement of the analysis and comparatively evaluate the results obtained. Module 4 includes the learning components of the expert system and the prediction component that allows integrating prediction algorithms in the identified processes. Additionally, Servinform has carried out the implementation for robot-human collaboration in the practical case of managing consumer claims for a Spanish national electricity company. The solution scheme deployed has been:

Farm of RPA robots made in UiPath that extract information from commercial information systems and CRM. They perform data extraction in the time window from 00:00 to 12:00. These robots extract the information, approximately 100 variables of various kinds, both text and numeric, which are all the data that may be required for a person to decide the resolution to apply to the claim.

  • Solution prediction algorithms. Based on the dataset carried out during 6 months, 45 possible solutions to apply to a claim were identified, based on combinations of output variables from the cognitive resolution process. A model deployed in AWS Sagemaker was trained to predict these three priority solutions.

  • Robot Control System, AWS prediction system and Human-Robot processes, which manages the queues of robot processes, the data collected by the robots, stores them in a database and generates queues of cases to be treated by humans. along with the predictions that have not exceeded the confidence threshold for human review, as well as the result of the resolution to the human claim.

  • Human-Robot interface called “Dispenser”, web front that makes available to the back-office team the data collected by the robots, the proposed solution, and allows the registration of the solution established by the human (which allows the refinement of algorithms)

The results obtained from the projected increase the efficiency of the process from ten percent of the start with the deployment of a collection robot farm until 10 months later, an efficiency of over sixty percent after including both optimization of the collection process, implementation of the three predictive solutions after ten iterations in predictive models and the implementation of deterministic solution rules identified with the dataset generated over time. The main conclusions of the project include:

  • Criticality in maximizing the usability of the human-robot interface. Due to the high number of data to be displayed, the agility to display the data, ease of identification of the information provided and the management of the queue of cases to be treated are highly relevant due to their impact on efficiency.

  • Easy and clear identification of incomplete information collected by robots. In the event of an incidence in the systems on which the collecting robots operate, it becomes very important so as not to degrade the efficiency generated, the immediate availability and at the human disposal of the trace of the actions of the robots on the systems on which they have worked, to unequivocally identify the existing and NOT existing information in the collection.

  • Adaptation of the extraction rate by robots to ensure that humans always have a work queue available at the beginning of their time window. This caused an increase in the number of robots to ensure the absence of bottlenecks.

  • Results monitoring environment using KPIs that identify over time the evolution of the number of cases treated integrally by the human-robot collaboration system, cases treated from outside, the average BMT in each time window (time dedicated by humans in the collaboration process), the percentage of OK and collection KO, the percentage of prediction that exceed the thresholds established for each one and the segmentation of the efficiency provided.

5 Related Works

Definition of RPA is not new. As it was introduced in this paper, there is quite a literature in this environment. Some surveys or reviewers of the current situation of RPA have been found [3, 5]. However, in this paper, we are trying to focus on a real view of the RPA technology. In this sense, our starting point is the recent paper [2]. In this paper, authors review 54 primary studies under the SMS (systematic mapping study) Kitchenham mechanism [7]. As the author introduced and demonstrate, the real application of the RPA that was published is still reduced. This could be motivated by industrial protection or patents on these functionalities or platforms. Nonetheless, it is not possible to confirm since no information has been found on related patents in the field of RPA. Authors add to the paper an industrial review in RPA where they identified some solutions and analyses different commercial tools.

6 Conclusions and Future Works

RPA has being a movement that is being applied in research and industry with successful results. However, after the first era of RPA, it is necessary to reconsider the situation to try to carry out its advantages to other environments, like SME. In this paper, we present a global discussion about how RPA can offer a suitable solution if we consider the human in the loop. Thus, the paper presents an approach to include the human effectively into hybrid RPA. This approach is enriched with a set of key indicators and with Process Mining principles. To illustrate our approach, we present experience from the trenches, RAIL Project. As future work, we want to continue working in our approach, both in the research and in the enterprise side. Our idea is to try to define a detailed process, based on the one presented in Fig. 1, with real mechanisms to measure its development in a very effective way. It is also very important to guarantee that the process mining principles are included in the right way, guarantee that the all approach can offer good results even for small and medium companies.