A Method to Improve the Early Stages of the Robotic Process Automation Lifecycle

A Method to Improve the Early Stages of the Robotic Process Automation Lifecycle Andres Jimenez-Ramirez1,HajoA.Reijers2, Irene Barba1, and Carmelo Del Valle1 1Departamento de Lenguajes y Sistemas Inform´aticos, University of Seville, Seville, Spain {ajramirez,irenebr,carmelo}@us.es 2Utrecht University, Utrecht, The Netherlands [email protected] Abstract. The robotic automation of processes is of much interest to organizations. A common use case is to automate the repetitive manual tasks (or processes) that are currently done by back-office staff through some information system (IS). The lifecycle of any Robotic Process Automation (RPA) project starts with the analysis of the process to automate. This is a very time-consuming phase, which in practical settings often relies on the study of process documentation. Such documentation is typically incomplete or inaccurate, e.g., some documented cases never occur, occurring cases are not documented, or documented cases differ from reality. To deploy robots in a production environment that are designed on such a shaky basis entails a high risk. This paper describes and evaluates a new proposal for the early stages of an RPA project: the analysis of a process and its subsequent design. The idea is to leverage the knowledge of back-office staff, which starts by monitoring them in a non-invasive manner. This is done through a screen-mouse- key-logger, i.e., a sequence of images, mouse actions, and key actions are stored along with their timestamps. The log which is obtained in this way is transformed into a UI log through image-analysis techniques (e.g., fingerprinting or OCR) and then transformed into a process model by the use of process discovery algorithms. We evaluated this method for two real-life, industrial cases. The evaluation shows clear and substantial benefits in terms of accuracy and speed. This paper presents the method, along with a number of limitations that need to be addressed such that it can be applied in wider contexts. Keywords: Robotic process automation ·Process discovery · Business process outsourcing 1 Introduction The term Robotic Process Automation (RPA) refers to a software paradigm where robots are programs which mimic the behavior of human workers interacting with information systems (ISs) and whose objective is to perform structured and repetitive tasks quickly and profitably [12,22,27]. Significant cost savings, agility, and quality improvement are associated to a successful RPA project [6]. Nonetheless, not all processes are suitable for automation. The following criteria need to be met [12]: the process (1) must be highly frequent, (2) with a low level of exceptions, (3) involving an enclosed cognitive scope, and (4) susceptible to human errors. According to these criteria, the best candidates to be subjected to RPA projects are processes found within the back-offices of a company [13]. In general, an RPA project follows the following lifecycle: 1. An analysis of the context to determine which processes – or parts of them – are candidates to be robotized, considering the criteria mentioned earlier. 2. The design of the selected processes, which involves the specification of the actions, data flow, etc., which must be developed. 3. The development of each designed process. 4. The deployment of the robots in their individual environments (e.g., virtual machines) to perform their jobs. 5. A testing or control phase in which the performance of each robot is analyzed and errors are detected. Noted that within the traditional software development lifecycle testing precedes deployment, RPA is characterized by lacking a testing environment; only the production environment is available. 6. The operation and maintenance of the process, which takes into account each robot’s performance and error cases; the outcomes of this phase enable a new analysis & design cycle to enhance the robots. When considering state-of-the-art RPA technology, specifically solutions like UIPath [25] or WorkFusion [29], it is apparent that these mostly focus on the later stages of the lifecycle, i.e, the actual development and deployment stages. They provide very limited support to detect candidates of tasks or processes to automate. To date, there are also no established methods to carry out these analysis and design phases. As a result, current RPA projects mainly rely on the analysis of documentation, which may be of poor quality and may require substantial effort to understand. Considering that designed robots are typically deployed in production environments, where they interact with operational ISs, there is much risk involved with building on an inaccurate analysis. Interestingly, in companies that have adopted RPA, people and robots typically work side by side within their back-offices. People are in charge of managing the processes that are either not suitable for RPA or which still need to be robotized. To carry out their work, these human employees receive formal training on how to deal with the cases that belong to the process under their control, but also receive training-on-the-job: they experience exceptions, process deviations, and undocumented cases on a daily basis. We will leverage their domain knowledge and analyze their behavior as the main ingredients of a method that improves and speeds up the early stages of the RPA lifecycle. Against this backdrop, we propose in this paper a method that starts by monitoring the computers of the back-office staff in a non-invasive manner by recording the screen, mouse and key events. Next, we apply a set of mechanisms (e.g., image similarity and frequency analysis) to transform this information into a standardized event log [1] including UI information, i.e., the sequence of raw images is converted to a set of shorter sequences of events each one corresponding to a process instance that the back-office staff has performed. The generated log is then used to automatically discover the underlying process. As widely acknowledged [3,13,16], the process mining paradigm [2] provides efficient and suitable analytic techniques to address this step. To evaluate our proposal, it has been applied to two industrial cases. We chose the domain of business process outsourcing (BPO) to select these cases since they provide a particularly challenging setting. When a process is outsourced, various companies are involved in carrying it out and the ISs in this process context may be geographically dispersed. What is more, the use of secured connections (e.g., Citrix) is the standard in outsourced scenarios, which only permits raw images to be gathered from the monitored screen instead of the structure of the information that is being processed. The results of our evaluation show clear benefits in the early phases of RPA projects in the BPO domain by (1) improving accuracy and (2) saving time. In addition, our evaluation shows that the insights generated during the analysis phase are also beneficial during further stages of the RPA lifecycle. The rest of the paper is organized as follows. Section 2motivates the need for leveraging human knowledge to foster better RPA analysis and design in a BPO context. Section 3presents the details of our proposed method. Section 4 reports the results for the cases we used for our evaluation. Section 5presents related work on RPA. Finally, Sect. 6concludes the paper with a summary and description of future work. 2 Context In a BPO scenario (cf. Fig. 1), back-office tasks are carried out both by teams of humans and teams of robots. For both types of teams, documentation of the prescribed process is a crucial ingredient. This documentation covers the various case situations in a mix of formal and informal descriptions, typically containing some sort of ambiguity or uncertainty (e.g., lacking information related to the software ecosystem beyond the ISs which are used). We will take a look at the role that documentation plays in more detail first. As far as the human staff is concerned, documentation is used as the basis for training them. While human performers are expected to be able to deal with a particular process on the basis of this training, they are likely to encounter non-documented scenarios. Humans are expected to make decisions under such circumstances, which they are usually capable of by applying a cognitive effort – probably by applying common sense (i.e., on-the-job training). Typically, such new decision-making behavior is then incorporated into a knowledge database, which is shared across the team. As explained earlier, the deployment of a robot team emerges from following the common RPA lifecycle, i.e., by going through the phases of analysis, design, Prescribed process behavior Back-office training Back-office production Secure . External Information Systems RPA analysis & design RPA development & deployment RPA testing & operation & maintenance Fig. 1. Current situation of the business. development, deployment, testing, operation, and maintenance. In the analysis and design phases, a significant effort is spent on formalizing the process to be carried out in such a way that ambiguity and uncertainty are reduced about the way various cases should be dealt with. Selected parts of the prescribed process are formally documented and delivered to the developers of the robots. These developers produce the robot code, which is then gradually deployed such that the robots can execute the related processes while their behavior is monitored and tested. After a period of time, a full team of robots will be ready to execute the process in question. However, robots tend to be rigid and do not behave well under unexpected circumstances. When an unexpected situation occurs, two things happen: (1) the involved robot gets stuck and a human operator must bring the process to a situation where the robot can go on – typically, the starting point of a new case, and (2) the RPA lifecycle starts again to analyze the newly encountered situations to decide which of these must be included in the design to deploy an updated version of the robot team. From a company’s perspective, each team – human or robotic – has its own benefits and drawbacks, which can be seen in Table 1. While robots can work 24/7 and can be flexibly spawned to deal with heavy workloads, they are expensive to analyze and have a low accuracy when dealing with judgment-based tasks, e.g., deciding what to do based on unstructured data. Therefore, they require the supervision of humans, which are typically engaged with knowledge-intensive tasks and relieved of repetitive, simple tasks [5]. As stated before, analyzing a process that is to be robotized is a timeconsuming task and only a small portion of the process can be robotized initially, i.e., the most structured and repeated parts [3]. During the lifetime of such a process, new scenarios and corrections are detected and included in the robotized set. Eventually, only the most unstable and judgment-based parts of a process remain separated from the cases that can be handled by robots. The human team will stay in charge to deal with these. The sooner this eventual situation is reached, the more profitable the RPA project is. Table 1. Main benefits and drawbacks of human vs robot taskforce which are identified in the considered scenario. Human Robot Benefits Cognitive effort for problem solving Continuous and flexible work capacity Drawbacks Not efficient for repetitive, high volume, simple tasks Expensive to analyze and unreliable for problem solving The context we provided here points at the main challenge that is being addressed in this paper: to reduce the effort to analyze the actual system. As the reader may have noticed, this effort is done twice: (1) when the human team is trained or trained-on-the-job, and (2) when new documentation is received or when errors are detected, which trigger a new analysis of the robots. Although managers of the human teams and managers that are concerned with the development of robots communicate with each other, the flow of knowledge that is available in the human teams to that of the development teams is far from ideal. To mend this, the current paper tries to automate this flow. 3Method In this section, we will describe our proposal to deal with the challenges that exist in an RPA setting. Essentially, this method leverages the knowledge of back-office staff for improving the early stages of the RPA lifecycle. This method starts with behavioral monitoring (cf. Sect. 3.1), after which a set of configuration cycles are conducted over the monitored information (cf. Sect. 3.2). Each cycle produces a process model that is related to such behavior (cf. Sect. 3.3). Figure 2depicts an overview of this proposal. Secure . Mouse&Key Log Screen captures UI Log IS a c. Activity monitoring IS b IS c a. Interaction with external Information Systems b. Opaque communications d. Event and Instance separation Back-office computer Prescribed process e. Process discovery f. Process analysis Discovered process g. Configuration update Config Fig. 2. Overview of the proposal. 3.1 Behavioral Monitoring As can be seen in Fig. 2, in a BPO setting, a back-office employee interacts with different ISs (e.g., proprietary ERP systems cf. Fig. 2a) to perform a number of repetitive, administrative processes. The interaction with these ISs is done through secured connections (e.g., Citrix cf. Fig. 2b), which makes it difficult to perform a transparent analysis of the user interaction by means of tree-like structures (e.g., HTML DOM or Windows UI). Therefore, only raw images on the one hand and mouse and keyboard events on the other can be monitored from someone’s computer during their interactions with an IS. Our method starts by recording these back-office interactions through non-intrusive monitoring software (i.e., it is invisible for the user, cf. Fig. 2c). This software captures a single long trace of events with the information depicted in Table 2.1Such events may be related to several traces (or instances) of the same process. 3.2 Configuration Cycles A specific algorithm is executed to identify events and traces/instances to generate a UI Log (cf. Fig. 2d, Definition 1, Algorithm 1). For this step, a default configuration (i.e., a set of pairs key−value) is used with the information shown in Table 3. Definition 1. An UI Log is a XML file whose grammar is an extension of the standard XES [1]. This extension incorporates the concept standard [1] attributes (i.e., concept:name for traces and events) and the attributes of Table 2. Algorithm 1. From raw log to UILog input :Logl, Config c output:UILoguiL 1uiL ←createBasicLog(l) 2uiL.groupEventsByFingerprint(c.similarity th) 3uiL.deleteEventsByT emplates(c.templates) 4uiL.deleteEvents(c.rm events) 5foreach (source, targets):c.join events)do 6uiL.joinEvents(source, targets) 7if c.st event is not defined then 8c.st event ←uiL.mostReapeatedEvent() 9uiL.divideLogInT racesByStartEvent(c.st event) 1These event attributes are considered necessary for different use cases. However, not all of them are useful for the current paper. Table 2. Event attributes captured from the UI. Name Description Name Description app name Name of the application which is being used. Not useful in secured systems keystrokes Sequence of keystrokes pressed. Only if event type is keystroke focus Indicates if the application has just gained the focus start ts Start timestamp event type {click, keystroke}end ts End timestamp click type {left, right, middle}. Only if event type is click img name Name of the file with the screen capture click coords Coordinates of the click. Only if event type is click img fingerprint Quasi-unique string summarizing the image Table 3. Configuration attributes. Key Description similarity th Threshold to use for grouping images. If it increases, it will be more likely that two images are considered the same event st events Set of event to be considered the alternative starts of the instances rm events Set of events to be removed from the log rm templates Set of images to remove the events which contains any of them join events Set of pairs (source, target) to join the source with the target events sp processes Set of processes to be considered special or exceptional and, thus, to be separated from the final model In a first step (cf. line 1 of Algorithm 1), the UI Log is created using the basic information of the input log i.e., the data of Table 2. Next, the images are used to identify repeated events (i.e., atomic process activities) and divide the long trace into different smaller traces. First of all, repeated events are identified through an image-similarity algorithm which groups similar images (e.g., a log-in window with two different user names will be grouped together). In this step (cf. line 2 of Algorithm 1), the Hamming distance [14] of image fingerprints (e.g., pHash or Image-match [28]) is used to check whether two images correspond to the same activity or event, i.e., if such a distance is below the configured threshold, then both images are grouped together. As a result, each event of the log now contains the event concept :name. As the log may contain noise, some mechanisms are enabled to clean the log from it (cf. lines 3–6 of Algorithm 1): 1. Some events can be deleted if they contain some configured templates (e.g., a social network or email icon, cf. Table 3rm templates). 2. Some detected events can be directly deleted (e.g., the log-in window of an ERP system, cf. Table 3rm events). 3. Some events can be considered to be the same although they look different (cf. Table 3join events). Secondly, to separate the one-trace log into different traces, an event (i.e., the most repeated or a configured set, cf. lines 7–8 of Algorithm 1, Table 3st events) is used to split this long trace into smaller traces, each of which corresponds to a different instance (cf. line 9).2Therefore, in the resulting UI log, traces with different concept :name are created containing their corresponding events. 3.3 Process Discovery The generated UI log is used as input of a process discovery algorithm (cf. Fig. 2e). The purpose of this step is to generate graphical process models that capture the behavior of the back-office employee. It is here that a business analyst becomes involved. First, the processes which meet a configured specification are marked as special (cf. Table 3sp processes). These relate to less relevant processes, which either obscure the main process or convert it into a spaghetti model. What is more, this mechanism can be used to exclude undesired processes, e.g., when the employee deals with multiple procedures on a daily basis. Second, the main process that is cleaned from the special cases is captured too. Although the aforementioned steps (cf. Fig. 2d and e) are automatic, there are some parts where errors may be introduced. For example, the back-office employee may introduce noise in the UI log if she performs personal activities, the image-similarity algorithm may group images together that actually correspond to different events, and a wrong event may be selected to divide the cases. To deal with this, our proposal includes a manual activity by a business analyst to analyze the generated models (cf. Fig. 2f). In this step, the business analyst can perform a deep review of both the special model and the main model. In case she considers this necessary, any process model may be refined by providing a new configuration setting for a next iteration of the process discovery stage (cf. Fig. 2g). The process model that results from a number of iterations exactly captures how the back-office employee applies her know-how. The outcomes of this approach can be used to improve different phases of the RPA lifecycle, as follows: 2Note that considering an event for dividing the traces implies that this selected event may not appear in the middle of a trace. 1. The final process model represents a key element for the analysis and design phases since it includes (1) information about the real process – which may differ from the documented one–, (2) figures on the frequency of the cases – which is relevant to decide which cases should be robotized–, and (3) the human effort that is still required to be allocated to the process – which is necessary to evaluate the potential performance of the RPA deployment. 2. The additional UI log information, which is associated to the activities of the process model, provides strong support for the development phase since it includes the actions that have been done (i.e., keystrokes and clicks) that lead one activity to other for the different instances of each case type. Furthermore, testing the developed robots will become easier since the UI logs can be used to generate test scenarios. In the evaluation that follows, we will focus on our primary objective, the optimization of the analysis and design phases. 4 Evaluation To evaluate our method, we worked together with Servinform S.A.3,whichis active in the BPO domain. To be more precise, we carried out the analysis and design phases for RPA scenarios within two companies. We compared the outcomes with those that resulted from the conventional analysis and design activities of Servinform for the same scenarios. Section 4.1 describes the set-up that underlies our evaluation; Sect. 4.2 provides the data analysis and summarizes the results of the evaluation. 4.1 Set-Up To enable our evaluation, a software infrastructure is developed and deployed (cf. Fig. 3) to support the following use case: 1. A back-office computer is monitored for some time through non-intrusive software written in the AutoIT scripting language [7]. The software sends all events (cf. Table 2) to a central server using JSON messages. 2. A central server, coded using Java and the Spring Cloud framework [23], exposes a REST API for receiving the events of the monitored computer and storing both the images and the UI events into a MySQL database. The fingerprint of the images is calculated by a Python component4. 3. After the observation period, an analyst requests a process model that is based on the monitored events to the central server. For this purpose, a configuration (cf. Table 3) is sent through a custom-made ProM plugin. 3Serviform is a Spanish BPO company with an IT consulting area. 4There are several alternatives for computing a fingerprint of an image, in this paper we based on [28]. 11. Dumais, S., Jeffries, R., Russell, D.M., Tang, D., Teevan, J.: Understanding user behavior through log data and analysis. In: Olson, J.S., Kellogg, W.A. (eds.) Ways of Knowing in HCI, pp. 349–372. Springer, New York (2014). https://doi.org/10. 1007/978-1-4939-0378-8 14 12. Fung, H.P.: Criteria, use cases and effects of information technology process automation (ITPA). Adv. Robot. Autom. 3(3), 1–10 (2014) 13. Geyer-Klingeberg, J., Nakladal, J., Baldauf, F., Veit, F.: Process mining and robotic process automation: a perfect match. In: International Conference on Business Process Management, pp. 1–8 (2018) 14. Gusfield, D.: Algorithms on Strings, Trees, and Sequences: Computer Science and Computational Biology. Cambridge University Press, Cambridge (1999) 15. Le Clair, C.: Digitization Leaders Share Robotic Process Automation Best Practices. Forrester Research Inc., Cambridge (2016) 16. Leno, V., Dumas, M., Maggi, F.M., La Rosa, M.: Multi-perspective process model discovery for robotic process automation. CEUR Work. Proc. 2114, 37–45 (2018) 17. Leopold, H., van der Aa, H., Reijers, H.A.: Identifying candidate tasks for robotic process automation in textual process descriptions. In: Gulden, J., Reinhartz-Berger, I., Schmidt, R., Guerreiro, S., Gu´edria, W., Bera, P. (eds.) BPMDS/EMMSAD -2018. LNBIP, vol. 318, pp. 67–81. Springer, Cham (2018). https://doi.org/10.1007/978-3-319-91704-7 5 18. Linn, C., Zimmermann, P., Werth, D.: Desktop activity mining - a new level of detail in mining business processes. In: Workshops der INFORMATIK 2018 - Architekturen, Prozesse, Sicherheit und Nachhaltigkeit, pp. 245–258 (2018) 19. Marrella, A., Catarci, T.: Measuring the learnability of interactive systems using a petri net based approach. In: Proceedings of the 2018 Designing Interactive Systems Conference, pp. 1309–1319. ACM (2018) 20. M˘aru¸ster, L., Weijters, A.T., Van Der Aalst, W.M., Van Den Bosch, A.: A rulebased approach for process discovery: dealing with noise and imbalance in process logs. Data Min. Knowl. Discov. 13(1), 67–87 (2006) 21. Rosa, M.L., Dumas, M., Uba, R., Dijkman, R.M.: Business process model merging: an approach to business process consolidation. ACM Trans. Softw. Eng. Methodol. (TOSEM) 22, 11 (2012) 22. Slaby, J.R.: Robotic automation emerges as a threat to traditional low-cost outsourcing. Horses for Sources (2018) 23. Spring cloud (2018). https://spring.io/projects/spring-cloud. Accessed 1 Mar 2019 24. Suriadi, S., Andrews, R., ter Hofstede, A.H., Wynn, M.T.: Event log imperfection patterns for process mining: towards a systematic approach to cleaning event logs. Inf. Syst. 64, 132–150 (2017) 25. Uipath (2018). http://www.uipath.com. Accessed 1 Mar 2019 26. Wang, G., Zhang, X., Tang, S., Zheng, H., Zhao, B.Y.: Unsupervised clickstream clustering for user behavior analysis. In: Proceedings of the 2016 CHI Conference on Human Factors in Computing Systems, pp. 225–236. ACM (2016) 27. Willcocks, L., Lacity, M., Craig, A.: Robotic process automation: strategic transformation lever for global business services? J. Inf. Technol. Teach. Cases 7(1), 17–28 (2017) 28. Wong, C., Bern, M.W., Goldberg, D.: An image signature for any kind of image. In: International Conference on Image Processing, pp. 409–412 (2002) 29. Workfusion (2018). http://www.workfusion.com. Accessed 1 Mar 2019