Hyperautomation (Automated Decision-Making as Part of RPA)

Abstract

Robotic Process Automation (RPA) has in recent years launched a fundamental new paradigm on how to automate and optimize processes. Practical RPA projects have been a great success but focused on the repetitive tasks always following the same patterns. Hyperautomation extends the scope to include the (algorithm-driven) decision-making in the automated process. The authors explain the ideas behind hyperautomation by discussing a specific example.

1 Introduction

1.1 Initial Situation

Robotic Process Automation (RPA) is part of every digitalization strategy in banks and insurance companies. RPA has in recent years launched a fundamental new paradigm on how to automate and optimize processes.

RPA has been particularly successful in automating processes across systems (avoiding system discontinuities) and processes with clear “clicking” patterns. The automation potential reaches a limit when a manual decision (by a human) is still needed in the process.

In Fig. 1, the difference between classic and modern RPAis shown. Modern RPA widens classic RPA by the aspect of automated decision-making (some sources call this “hyperautomation” see Gartner, Gartner Top 10 Strategic Technology Trends for 2020 (2019) and Gartner, Gartner Top Strategic Technology Trends for 2021 (2020)).

Fig. 1

(© ifb SE)

Modern RPA

The adding of (automated) decision-making is not a one-step process. The recent projects have shown that a step-by-step approach delivers the best results and the highest acceptance. In Sect. 2, the idea of how to address this challenge is illustrated in more detail.

1.2 Structure of the Article

Section 2 introduces the general idea and the step-by-step approach to higher levels of automation. RPA and the software tool UiPath are very briefly introduced in Sect. 3. Section 4 discovers the machine learning aspects needed in the context of this use case. The following Sect. 5 gives insights into a practical application, i.e., how to integrate machine learning (Python-based model) into RPA (UiPath). Section 6 summarizes the key findings.

2 General Idea

In Sect. 1.1, we highlighted that a step-by-step automation of the processes works best. In this section, we will discuss different structures for taking these steps.

In Fig. 2, the five-step decision automation model is shown. The different levels show how to move step by step from manual decisions to autonomous decision-making. The five-step decision automation model is dealt with in detail (Bitcom 2017).

Fig. 2

(© ifb SE)

Five-step decision automation model

The automation of a process beyond classic RPA is challenging and needs to be approached step by step. While Fig. 2 gives a detailed structural view, the main blocks are described in Fig. 3.

Fig. 3

(© ifb SE)

Blocks for a step-by-step implementation

The foundation for any model to work is formed in level A “learning.” The relevant data is collected for a model calibration. The labels are especially hard to find in a structured form. Classic RPA can help with this task because RPA can seamlessly collect and save decisions made by a human in a user-friendly way. In traditional processes, this decision-driving information is—in most cases—lost after the process management has used it to select the further steps.

To ensure the correctness of the proposed decisions and to ensure the person involved has a good understanding of the status of the process automation level, the model proposes a decision in level B “suggestions,” but the human can overrule the model decision. When the model has proposed reasonable decisions for a long time, then the last step (level C) can be entered. The process can run fully automated.

3 RPA and UiPATH

UiPath is one of several tools that can implement RPA procedures. It draws its strength from a graphic user interface that not only lets you string together abstract commands but even simply record mouse clicks that encompass and bring together the control of many different programs by a plethora of third parties. It is therefore easy to create a classic RPA robot that contains, for example, steps going through OfficeSuite products, web browsers, and SAP distributions all at once.

Regarding modern RPA as outlined in Fig. 1, UiPath offers, for example, the integration of external programming languages like Python that can assist the human user in the decision-making process by providing appropriate, custom algorithms. More details are given in the next section.

4 Machine Learning/Data Analysis

4.1 From Data Collection to Full Automation

Figure 3 highlights three steps or phases in the development of a fully automated system. Even in such a system, the data collection process, which is the key part of level A, does not stop. Data collection and usage can therefore themselves be structured into three similar phases. Let us take a use case of, for example, announcements of future invoices arriving at a motor vehicle leasing company. Said announcements present an approximate price corresponding to a specific vehicle and maybe contain additional information like billing addresses, etc., for a purchased vehicle. This is necessary for the leasing company to make provisions to be able to comply with future payments. However, the announced price may be merely a preliminary value and even faulty at times. The receiver of the announcement, henceforth called the user, will have to decide the actual amount of provisions that the company needs to make. This can range from simply approving the announced amount or double checking it against a list price and selecting the correct one, through to remembering and analyzing previous purchases.

As good and informed decisions are based on sufficient amounts of adequate data, the first step is the pure collection of such data.

Phase one will therefore be a period in which relevant data will be collected, manually processed, and evaluated until one achieves a dataset of input values, e.g., announced invoiced amounts, and validated output data. The latter here are the amounts that are validated, approved, and eventually paid. While the collection of the input data can be automated at this point, the generation of the output data is still a fully manual process.

Once the first phase is completed to a satisfactory degree, one can start to incorporate more automation into the process. In step one, not only was the decision-making excluded from automation, the at times cumbersome research of plausible pricing and comparison to empirical values was a manual process as well. The next phase tackles the latter issue.

Phase two uses the data collected in phase one to aid the user in his or her decision-making process by predicting and proposing a monetary amount for provisioning.

This is the point where hyperautomation enters the playing field. Simply collecting data, pushing it through a static process and ultimately pasting it into a sought-after format is the traditional or standard form of automation. In hyperautomation, a combination of different tools comes into play (Maddox 2019). Here, we combine RPA with a machine learning model, which analyzes the previously collected and prepared empirical data. Triggering the use of that model automatically within the traditional RPA framework brings us to a hyperautomated process. The final result of phase two is a semiautomatic procedure, where the user is predominantly just left with the decision-making process itself. That is whether to confirm the amount suggested by the model for the actual provisions, or to choose the amount extracted from the email invoice announcement. Exceptions might be vastly unintuitive values for both the proposed and extracted values. In that case, the user could opt for a third option, which is to do some manual research after all and set the actual amount him or herself. Note that during phase two the data gathering process of phase one continues, albeit in a more automated fashion. The training of the model should then also be updated in regular intervals incorporating the new data.

Phase three aims at further and ideally full automation. The goal is to eradicate a user as an ongoing decision-maker, instead letting the robot work its “magic” to the fullest.

A natural piece of information that is gathered in phase two is how often the user chooses to follow the model prediction and how many times he or she does not. This is a measurement of how well the model works. This, of course, is also influenced by the amount of data the model is based on, which keeps on increasing over the course of time. Assuming there are no fundamental mistakes in the implemented model, we can assume that the rate for choosing the predicted value increases, too. Not only this way, but also through the user’s experience, we gain intuition and measurements regarding the quality of the model. This goes somewhat in the direction of cross-validation, i.e., testing the model on new data. Once it reaches a satisfactory degree, one can switch to always accepting the predicted value as the actual value that is reserved for provisions. At this point, only regular backtesting is required to make sure that the predictions and propositions of the model remain accurate.

4.2 Natural Language Processing for Data Extraction

Natural language processing, or NLP, is a field focused on the interaction between computers and human languages (Wikipedia 2020). A brief introduction to the models can be found in Section 4 in Liermann et al., Deep learning—an introduction (2019). Other applications of NLP can be found in Liermann and Schaudinnus, Real estate risk—appraisal capture (2019) and Schröder and Tieben (2021).

In our particular case, NLP can be a valuable asset—maybe even indispensable in practice. The key area for its application would here be the collection of data extracted from incoming emails that announce upcoming invoices. There are ways to force a certain format of the emails, for example by generating said format after submitting a form on a website, but those ways could be cumbersome, less user-friendly, or even redundant and resulting in more work and time for upkeep. Ideally, the sender sends the email in any way he or she likes, and the receiving computer is able to extract the sought-after information automatically. This is where NLP becomes necessary for automation.

NPL is not only a good idea in the final stages of implementation, nor should it be seen as the cherry on a cake. It could make a tremendous impact on automation at the earliest stage already, i.e., the collection of the initial data.

4.3 Features Engineering and Model Training

The dataset presented in this chapter is mockup data but reflects the structure of the real data. We simulate 13,730 datasets and an overview of the first nine samples is provided in Table 1.

Table 1 Head of the dataset

The example data shown in Table 1 will be generated by an RPA tool (UiPath in our case). The RPA extracts the relevant data from incoming emails. The data collection process is covered for the user by the automated process. The extraction can be implemented rule-based (see Sect. 4.1) or can use more “error”-tolerant tools like NLP (see Sect. 4.2).

The column “Value” contains the value of invoice announcements. We aim to predict this column (label) based on the other columns (features). In this section, we are going to analyze the label and features and develop a machine learning method at the end. The following analysis is implemented by using R with ggplot2¹ and h2o library (H2O.ai 2019).

4.3.1 Label

The following analysis shows that the column “Value” contains only 12 categories among 13,730 data samples, see Fig. 4. It suggests that we consider it to be categorical (discrete) instead of numerical (continuous), which implies that we need to discover a classification model instead of regression. In the general case, we should extend a label to be continuous.

Fig. 4

(© ifb SE)

Overview of label “Value”

4.3.2 Features—Correlation

Feature selection is the process of reducing the number of input variables when developing a predictive model, to reduce the computational cost and improve the model performance. Although we do not have many features and samples, we still proceed with the feature selection to introduce a statistical-based approach by using a correlation matrix. Figure 5 illustrates the correlation matrix between all columns given in the dataset, where the correlation values are displayed by using different colors. Correlation-matrix-based feature selection is widely used to develop machine learning models, especially in case of Big Data. Clustering can be performed based on a correlation matrix, where similar variables can be grouped into the same cluster. In other words, the strongly correlated variables will be selected. In our example, we can directly read that the columns “Company,” “Address,” “Post code,” “City,” “Country” and “DUNSNr” are strongly correlated, since they are all geographic based. On the other hand, columns “Value,” “Object” and “Object.Type” should be grouped together. This indicates that we should select “Object” and “Object.Type” for building the machine learning model.

Fig. 5

(© ifb SE)

Correlation matrix

4.3.3 Features—Object and Object.Type

In the following, we provide some further statistical analysis for the columns “Object” and “Object.Type.” As we already mentioned in other articles (Liermann and Li, Methods of Machine Learning 2021), these classic statistical intuitions should not be ignored. They will provide a deeper look at the dataset and are able to improve the training efficiency during the development of machine learning models.

Figure 6 plots column “Object.Type” against “Value.” We are not able to separate the values of the column “Value” finely according to column “Object.Type,” since the invoice announcements of category “Airplane” take values across 1.5e+08 to 6.5e+8 and the category “Tractor” covers values between 4e+5 and 6e+5. After considering the column “Object,” the separation becomes sharper. As illustrated in Fig. 7, we are nearly able to identify the value of “Value” based on “Object.Type” and “Object.” The result of the analysis is not surprising, since we used deterministic conditions to generate datasets, as introduced in Sect. 4.3.

Fig. 6

(© ifb SE)

Object.Type vs. Value

Fig. 7

(© ifb SE)

(Object.Type, Object) vs. Value

4.3.4 Model Training—Random Forests

One of the traditional classification models—random forest—is chosen. Recalling the statistical analysis provided in the last section, it is unsurprising to see that a small forest with five trees is already able to achieve an excellent accuracy beyond 99.9%. Cross-validation results are shown in Fig. 8. In practice, we might face more complicated data structures and need to use more advanced models.

Fig. 8

(© ifb SE)

Random forest: cross-validation result

5 Practical Application: Machine Learning UiPATH

In this section, we present an example technical implementation of the previously circumscribed use case. As the RPA tool we use UiPath Studio Pro 2020.6.0-beta.93 Community License from the company UiPath. This offers the integration of the Python programming language as an external tool.

5.1 Python Integration in UiPath

For the technical integration of the externally installed Python programming language, UiPath provides an adapter package module called UiPath.Python.Activities, which is found in its Packages manager,² see Fig. 9.

Fig. 9

(© ifb SE)

UiPath.Python.Activities module in the UiPath Packages manager

Once installed, UiPath provides a so-called App Invoker for Python in its listed activities that include objects like Invoke Python Method, Load PythonScript or Python Scope. Python is connected to UiPath via the Python Scope environment, see Fig. 10.

Fig. 10

(© ifb SE)

Python scope and properties in UiPath

To make the connection work, three input attributes are key, namely Path, Target, and Version. The Path argument points to the folder containing the externally installed Python interpreter, not the interpreter itself. This can be the globally installed version or a virtual python environment created by virtualenv or the like. The tag Version corresponds to the Python version. As you can see in Fig. 10, several versions are supported. We used the latest supported one, version 3.6, as older versions tend to lose support by developers. Python 2.7 has even reached its end-of-life status (Python Software Foundation, Sunsetting Python 2, 2020). Last but not least, the Target differentiates between the 32bit and 64bit versions of Python. A Windows executable for Python 3.6.8 is available at (Python Software Foundation, Download 2020).³

After the Python scope is set up, an externally programmed Python script can be used via the Load Python Script module. This simply specifies the path to the script. Within this script, one defines functions or methods that can then be invoked and used via the Invoke Python Method module. Here you can forward parameters from UiPath to be used as input for the Python function. The return values of the function can then be read out by UiPath and processed further. In the scope of this use case, we created machine learning models beforehand, see Sect. 4.3. These models are invoked by the Python script. For a visualization of the interplay of the different components, see Fig. 11.

Fig. 11

(© ifb SE)

Architecture of the integration of Python into UiPath

5.2 Example in UiPath

As a proof of concept and a technical example, we now sketch the implementation of phase two implemented in UiPath.

At this point, we assume that initial data has been recorded according to phase one. In our example case, it was generated as described in Sect. 4.3. The first step of phase two and ultimately a preparatory step is the model training, which was also covered in Sect. 4.3. The onset is that the user receives an email in MS Outlook like the one shown in Fig. 12.

Fig. 12

(© ifb SE)

Email regarding an invoice announcement

The UiPath procedure starts by checking whether there are unread emails in the inbox regarding a certain topic, here “Invoice announcement.” Upon finding one, its content gets read, processed and the relevant details assigned to UiPath variables. Most important for us are the variables “Value,” stating the amount of the invoice, “Object type” and the “Object.” At the end of the entire process, UiPath checks for the next unread email until none are left, see Fig. 13.

Fig. 13

(© ifb SE)

Coarsest grained flow graph of the automation procedure in UiPath

The detailed automation steps of the data processing are grouped in the “check mail message” box of Fig. 13. There, the logical steps begin by filling in the necessary UiPath variables, in our case the ones mentioned in the previous paragraph. Secondly, a function from a Python script gets invoked with the UiPath variables for the “Object Type” and “Object” as input for the function. The Python function refers to a previously calculated and provided ML model which yields a predicted value for the invoice that is returned by the Python script to UiPath. The user then gets prompted with two values: the originally announced invoice value from the email and the predicted value from the ML model. Since it is only semiautomatic in phase two, i.e., level B from Fig. 3, the user still needs to decide which one to choose or where he or she would like to use a third, new value as provisions.

6 Summary

The chapter shows a practical example of an important pattern in automating processes. The challenge is to have a step-by-step approach to achieve the benefits of true automation (modern RPA using automated decision-making). Full automation including automated decision-making cannot be implemented as a big bang, in one-step or one project task. The important aspect is to gain and integrate the knowledge of the manual process and its decision-making.

The three-step meta process (see Fig. 3) is mirrored in Bitcom’s popular “five-step decision automation model” (see Fig. 2). Label generation can be a tricky task, especially if there is no electronic data history regarding the label. Supervised learning—by definition—only works with labels. The use of RPA capabilities to collect these important information labels is the crucial point in the approach. Only with an approach that collects the label data “en passant” (without any entries to an additional tool) and stores it electronically without slowing down the manual human process will it be accepted by the original process owner.

The potential of the approach is huge. The automation initiatives do not have to stop when more intelligence is required than simple rule-based approaches can easily cover. Defining a rule requires context knowledge and the definition of the rule is still manual and static (no learning without a human interaction), while machine-learning-based pattern recognition can define the rule autonomously and can adapt and learn from new situations. The only, but important, requirement is that the labels are available. Thus, RPA can automate simple, recurring, and stable tasks. In addition, RPA can collect the labels in the existing process and discover the decision-making patterns (using machine learning). Therefore, the way for a full automation is paved.

RPA is well established in most banks and insurance companies. Now is the right time to start collecting the labels (using RPA) so the cost-saving potential can be tapped just in time.