A lean approach to robotic process automation in banking

Abstract

Automation is a concept that has been previously introduced in organizations as a means to improve their processes. However, Robotic Process Automation (RPA) is an emerging method to automate processes with software, which the industry calls robots. These robots perform repetitive and low-complexity tasks previously performed by humans in front of a computer which as is known is the most commonly used feature in a company nowadays. Using the Design Science Research methodology to build up this article, it is argued that RPA is being used idly compared to its full potential which would entail using process improvement techniques before applying the automation itself. Thus, this article proposes a new approach to RPA through the use of Lean techniques. This article assesses two market leaders in RPA. It suggests a framework of activities for organizations that are investing in RPA and that want to take advantage of the capabilities currently offered by this technology. The majority of the demonstration proposal was carried out in a Portuguese private bank in three processes. Depending on the different cases, it had an overall positive evaluation in the field or simulations. Comparing RPA and Lean RPA projects in the number of resources (time, FTE) needed to carry out business processes, the latter approach presented values that were significantly lower and, consequently, satisfactory.

1. Introduction

A fourth wave of technological advancement is being witnessed - a new industrial digital technology known as Industry 4.0. It is defined as a network approach that complements Computer Integrated Manufacturing (CIM) through Information and Communication Technologies (ICT) [1] supported by the integration of automation technologies such as cyber-physical systems (CPS), collaborative robots, cloud computing and big data sets, with the production environment via the Internet of Things (IoT) [2].

Many technologies are already positively impacting productivity and employment in large enterprises [3] – particularly robotization, which is growing by about 50% per year [4] – and Industry 4.0 is considered to be a competitive strategy for organizations in the future [5].

Within this context, low-skilled jobs or occupations are predestined to end. Researchers believe that computerization will be responsible for most manual and finger dexterity tasks in the coming years as robot development costs fall and technological capabilities grow and spread [6,7].

That is the path undertaken by this research. There is an incessant need to do more with fewer resources in the enterprise world. This objective creates a high demand for continuous improvement in organizations' business processes, using rationalization and the optimization of resources [8]. Accordingly, this is the starting point for Robotic Process Automation (RPA). Automation will be employed by using scientific and technological principles to replace business-related tasks, previously performed by humans. The term process will be used to define a collection of tasks taken in a specific arrangement to achieve a determined output.

Nowadays, RPA is being used as an (almost) instantaneous automation tool because it delivers quick results and does not involve changing the existing underlying computer systems inside organizations [[9], [10], [11], [12]]. RPA developers do not usually care about optimization [13] since RPA projects are sold as long as they mimics the work that human workers have successfully done. However, what if RPA technology was more present inside an organization's processes?

To summarise what has been stated, the main problem found is that RPA is being taken as a quick fix. There needs to be a more detailed process analysis that doesn't underestimate its value to organizations when combined with a process improvement approach such as lean.

All of this leads to the research questions raised in this article. They are: (i) how RPA can take advantage of a continuous process improvement approach; and (ii) its impact.

The structure of this article is as follows. It starts with a brief Introduction (section 1), giving context to the research problem. It advances to the theoretical background of our framework for RPA and Lean (section 2). In section 3 the research methodology is described. Section 4 details the Research Proposal and the Objectives, and its application is described in section 5 (Demonstration). It follows with an Evaluation of the results (section 6) and concludes in section 7.

2. Theoretical background

This chapter presents a theoretical background on the topics related to this research.

2.1. Robotic process automation

This section provides a context for robotic process automation and the adoption of this technology.

RPA is an emerging form of process automation where one or more software robots perform the same procedure as a human would [14]. The robotic part in the term only emphasizes the idea of a machine doing utilities instead of a human worker, as it is not an actual physical robot. Robot is the concept used in the RPA industry and will be used throughout this paper to define a software robot.

Using robots in work reduces the risk of cross-organizational errors, presents a more integrated process control, provides an accurate playback of the defined path, establishes a reliable performance of repetitive tasks [15], and offers higher availability since robots can work 24 h a day, seven days a week. Currently, the tool offers enhanced digitization, but is unable to perform cognitive decision management solutions.

2.1.1. RPA – life cycle

The current and most widely used RPA development model is expressed in Fig. 1 and was obtained from Anagnoste [16] and Blue Prism's Guide [17]. The maintenance phase is not represented.

Fig. 1.

The most widely used RPA development model (adapted from Ref. [16]).

First, there is a gathering of the processes suitable for automation, and then it proceeds with choosing one. A specific RPA report from EY [18] enhances three critical characteristics of a strong RPA candidate: The actions must be consistent, and the process should be template driven and rules-based. A technical report from Symphony Ventures [19] states an additional characteristic: it must be raw-based, i.e. it does not require a human judgement element. A more specific and formal method is presented and discussed in Costa et al. (2023) [8].

After analyzing the suitable processes, the project proceeds with choosing one to automate – usually the one with higher benefits if automated using RPA. If those benefits surpass the investment cost, and the impact is positive (not just on the organization itself, but also on the employees and clients), it progresses to Process Reengineering.

Next, the goal of Process Reengineering is also to provide a high-level analysis of the process solution, the automation efficiency and the estimation of effort [17].

Following the project's approval by the process stakeholders, comes a detailed study, where the RPA developer gets into detail with the chosen process. After having functional documentation and the project plan has been defined, it is time to build the robot and test it.

There is no average time for an RPA project since it depends on the selected processes and their business complexity.

2.1.2. RPA tools available in the market

For the past years, Forrester Research [20] and Gartner [21] have been researching RPA tools in the market and publicly communicating the results.

According to Forrester Research's RPA Report from 2023 [20], the market leaders are UiPath, Pegasystems, Blue Prism and Automation Anywhere. However, 14 tools are analyzed in the report, and the global market presents a more significant number. Moreover, from Gartner Magic Quadrant for RPA [21], the market leaders are UiPath, Automation Anywhere, Blue Prism, Microsoft and NICE. Three tools are simultaneously present as leaders in both reports: UiPath, Automation Anywhere, Blue Prism.

• •UiPath - The market leader, UiPath, is the fastest-growing RPA vendor. It possesses constant updates, a free-trial period and a community edition that is always free. O'Donnel et al. consider that one of the reasons for that fact is that UiPath, as a vendor, does not do direct implementations. Instead, its success is based on appealing to integration partners and experienced end-users. It is also written that UiPath has 15 partners with natural language processing (NLP), intelligent optical character reader (IOCR), machine learning (ML), and chatbots directly integrated with Orchestrator, the central control point, which has allowed it to become a differentiator from other vendors.
• •Automation Anywhere (AA) – from the reports, it is possible to state that AA is also a market share leader and has been since the RPA concept began. Its primary processes targets are shared services like quote-to-cash, human resources administration, procure-to-pay, among others. Primarily, 80% of AA's capabilities are to automate back-office processes, but there is also the possibility to automate front-office tasks (20%). It is often selected for overall ease, duration and cost of deployment, and it has one of the largest trained partner ecosystems and a vast internal support staff.
• •Blue Prism (BP) - Regarding the second market leader BP, it is mentioned that it was the first vendor to see RPA as a tool detached from BPM. It invented the concept of the Virtual Workforce to define robots. The business grew from 124 to 448 customers in 2017, and its revenue exceeded USD$70 million. The 2017 report [13] stated that analytics should be present to maintain its innovation track record for RPA, and it has partnered with Google's Machine Learning Workflow to bridge that gap. Additionally, it is said to be very strict on certifications and what the tool should and should not do. O'Donnel et al. consider BP the safest bet for firms in financial services and audits due to its security and encryption.

2.2. Lean

The origins of Lean come from Japanese manufacturers in the 1950s and currently consists of a collection of management strategies that aim to boost the flow of operations that, in the eyes of customers, increase the value of the product and reduce waste in the manufacturing process [22]. The Lean concept is translated into the following principles: the identification of the value, the elimination of the identified waste activities, the generation of flow, pulling work instead of pushing it, and continuous improvement in the organization while reaching a cost-value equilibrium [23]. According to Stadnicka & Antonelli [24], using lean tools to improve human-robot-collaboration (HRC) and lean principles for HRC implementation is suitable.

In order to further proceed with this article, it is necessary to define the use of certain concepts. Value is something the customer is willing to pay for. Flow is a concept that describes how work progresses in the system [23]. On the other hand, waste should be considered as anything that does not add value and can be found in any activity of the flow.

2.2.1. Wastes

The main idea of Lean is to eliminate all kinds of waste [27]. Lean tools are known for actively trying to reduce the following eight wastes [25,26]: Transporting, Excess Motion, Waiting, Overproduction, Unnecessary Inventory, Over Processing and Defects and Skills. The mentioned wastes should be taken into consideration at the moment of identifying each activity of a process flow.

2.2.2. Kaizen

Kaizen is a Japanese word that translates to continuous improvement. Kaizen consists of small steps for each improvement, whilst the traditional manner mainly improves substantially, causing high costs and affecting most people in the organization. Regarding potential and benefits, kaizen invokes workers to participate in the upgrade from the beginning, unlike traditional improvement, where the idea of change stays with the organization's top management until it goes live [26,28].

2.2.3. SMART goals

The application of lean tools to a system must have a reason and there are goals that must support that reason. The term SMART Goals has been on trend for a long time, and literature is abundant about its definition and usage.

Conzemius et al. [29] define SMART goals to be Specific, Measurable, Attainable, Relevant and Time-specific. Specificity provides concrete and tangible evidence of improvement, meaning that one determined team should be able to focus efforts on a particular issue with clarity. The measurability of a goal is relevant, so one should be able to track progress and/or understand clearly whether a particular goal was achieved. Attainability is correlated with the gap between what is desired to close and how much work (focus, energy, time and resources) should be put into it while staying realistic regarding the possessed abilities. Relevance provides importance to the goal per se and aligns with other existing goals. Additionally, every goal needs a target date (time-specific) so that one can focus on a deadline and there is an objective to work towards.

2.2.4. Value Stream Management

Well-known tools such as Value Stream Mapping support Lean management for operationalizing its goals [30]. Value Stream is a process for planning and linking lean initiatives through data capture and analysis and consists of a guideline that a company must follow to achieve lean processes. Tapping et al. (2002) [31] assert that the guideline is suitable for office processes – that is, processes that do not produce a physical product but instead provide value to the final customer through a value stream composed of work units [32].

2.3. Discussion

In this section, the typical RPA project lifecycle has been described according to professionals. It becomes clear that the RPA lifecycle needs to include a process improvement approach before implementation, while Value Stream Management steps also miss possibilities for robotic and non-cognitive automation. Also, the importance of describing suitable processes for automation has been mentioned and thoroughly discussed in Refs. [8,33]. These characteristics are fundamental for the possible standardization of processes and insights into what RPA can do, presented by analyzing current RPA vendors and their functionalities.

The significant contribution is the insight into the most widely used and better-known tools for Lean principles. Although some research already combines Lean with RPA [34,35], it has always been done in vertical areas of activity, particular areas, or processes.

Analyzing both RPA capabilities and Lean principles, Table 1 was designed to map the eight wastes of Lean for some situations that can be avoided by applying RPA. The examples refer to work produced mostly on computers (e.g. systems and platforms).

Table 1.

Eight Wastes of Lean associated with situations RPA can avoid.

Lean Waste	Examples RPA ameliorates
Transporting	Data flowing between different departments/systems needs to be more consistent.
Excess Motion	Moving exceedingly to process data between systems/platforms.
Waiting	Stopping workflow waiting for an answer from another department, to be able to finish one determined process.
Overproduction	Workers performing activities that aren't necessary at the moment.
Unnecessary Inventory	Keeping unused documents in the system.
Over Processing	Workers repeating activities, due to previously done errors, or lack of quality in the processing (e.g. missing details); Duplicate work, due to re-entering the same data in the system.
Defects	Processes with similar workflows producing somehow different outcomes.
Skills	Mechanical and rule-based tasks, with zero cognitive actions; Under-utilization of provided tools and systems.

3. Research methodology

Design Science Research (DSR) is one of the two paradigms that characterize research in Information Systems. It is the research methodology that is used throughout this study [36]. DSRM aims to solve identified organizational problems by designing and evaluating IT artefacts. It consists of six activities, as seen in Fig. 2.

Fig. 2.

Detailed DSR for this study. Adapted from [37].

As a result, a six-step procedure is followed for conducting the DSR.

• 1)Problem Identification and Motivation: In this first step there is the identification and specification of the research problem by providing an explanation that justifies the existence of such a problem; in this research, we want to explain how RPA can take advantage of a continuous process improvement approach, and what its impact is;
• 2)Definition of Objectives for a Solution: In the second step, the goals for the research are set. They are inferred from the problem definition, together with the knowledge of what is possible and feasible; in this research, we want to understand how much more effective and efficient Lean RPA is when compared to a standard RPA project;
• 3)Design & Development: In the third step, a proposal is developed consisting of an artefact which includes a research contribution in its design; in this research, we will tend to make a proposal consisting of a model with three phases: RPA tool assessment; Lean RPA framework; Collection of RPA/Lean RPA results;
• 4)Demonstration: In the fourth step, we consider the time needed demonstrate how the proposed artefact from the previous step can be used to solve one or more cases; in this research, an assessment of the tools will be conducted, followed by using the framework in real cases and, finally, gathering results;
• 5)Evaluation: In this step, we obverse and measure/there is an observation and measurement the artefact's effectiveness, supporting a solution for the research problem; in this research, we will evaluate the results by comparing processes without automation with processes executed by RPA and with Lean RPA;
• 6)Communication: In this final step there is an exposition of the problem, the proposed, evaluated and validated artefact and the contribution of the research for the field through scientific publication.

Throughout the rest of this article, the application of each of those steps is explained in detail.

4. Proposal

In this section, the proposal objectives and the proposal description are defined. Following the methodology representation in Fig. 2, it corresponds to Steps 2 and 3.

4.1. Proposal objectives

This section is connected to the “Definition of the Objectives for a Solution” activity of the Design Science Research methodology.

The primary objective this study aims to achieve is to understand how much more effective and efficient Lean RPA1 is. It is necessary to explain the differences compared to a standard RPA project.

To better understand those differences, the following sub-objectives must be achieved.

• 1.RPA Tools Assessment: In order to proceed to the next sub-objectives, it's necessary to choose one tool to work with. The two possible tools chosen are two of the current market leaders, due to their availability to the research team – Blue Prism and UiPath;
• 2.Framework for Lean RPA: This study argues that analyzing and changing processes should be considered before developing any RPA project. This being said, a framework that joins both lean and RPA lifecycles must be created;
• 3.Collection of RPA/Lean RPA Results: Gather results from the application of both RPA and Lean RPA, either in simulation or real-field, to compare both approaches in terms of processing time.

Accomplishing these three sub-objectives will provide enough results to answer the primary objective.1

4.2. Description

The proposed model is represented in Fig. 3. This model helps visualize how the solution unrolls by following the three previously mentioned sub-objectives.

Fig. 3.

Proposal model.

The trigger “Desire to Change” is represented to enhance a beginning. It exhibits the sense of change and innovation necessary for process improvement projects. If this trigger is addressed, the following information is meaningful since it is based on continuous improvement.

4.2.1. RPA Tools Assessment

The criteria for assessment were based on the criteria that Le Clair et al. (2018) [13] proposed, but also on ISO/IEC 25010 characteristics [38] that were mapped to RPA.

• •Functional Suitability: Functional Appropriateness, Third-party Integrations;
• •Functional Efficiency: Time Behaviour, Error proofing Mechanisms;
• •Usability: Previously required programming skills, Overall Usability, and available Training courses;
• •Reliability: Robustness;
• •Security: Robots' deployment (Scheduling) and Logs quality;
• •Maintainability:Re-usability of modules;
• •Portability: Performance of the program on different information systems (IS) and performance of robots.

4.2.2. Lean RPA framework – improvement cycle

The Improvement Cycle is shown in Fig. 4. Each of the four steps has a set of activities below that must be completed before moving on to the next step.

Fig. 4.

Lean RPA framework – improvement cycle.

These activities should be done in the order they are presented.

4.2.2.1. Process Selection

The first step has activities firmly centered on lean principles whilst the decision point starts taking RPA into account.

Lean suggests defining a Value Stream (VS) as the initial point for change. Next, processes belonging to the VS should be sorted and embraced for further mapping.

When mapping processes, it is fundamental to be simple yet detailed. Everyone involved in the process should be able to understand and identify waste tasks with at least one of the eight wastes of Lean.

If the chosen process requires mainly cognitive actions, even after identifying the waste to be removed, then it is not suited for RPA, and the first step should be repeated. Otherwise, it is viable to continue to step 2.

4.2.2.2. process study

This step starts with the RPA Analysis activity. It is necessary to assert what RPA can or cannot do in the process based on its current functionalities. Once that is finished, it is time to define the kaizen plans. Kaizen is the correct choice since it incrementally changes the process to consolidate with the RPA solution.

The next activity is mapping the future state. Mapping the future state will help develop the robot, implement changes to the process flow and allows the new process to be documented. Furthermore, after having some documented processes improved by the improvement cycle, finding similarities between processes and standardizing them might become effortless.

Actions that should be redirected to the robot must be stated in the low-level map.

Before implementation, it's also indispensable to define SMART goals for the project. By defining the goals, one could understand whether it was successful. The goals should also be documented to be revisited later in step 4.

4.2.2.3. RPA project development

This is the step where process flow changes should occur, and the robot should be developed. This step is on constant repetition, so the process does not stop working – another reason to implement the kaizen plans.

After some iterations of the improvement cycle, the developers might notice similarities between processes/sub-processes. If that is the case, this situation requires an analysis to see if the methodology used can become a standard for the organization.

While implementing the robot, standard operation procedures (SOPs) and Simulations should be used to observe and test the development. These activities avoid advancing to step 4 with errors and performance issues.

4.2.2.4. Maintenance & Review

After the RPA project development, it is necessary to review the goals. For this, one should compare the obtained results with the goals that were defined in step 2. If the project achieves those goals, the project goes live, and maintenance activity to that project shall be supported from now on. If the project does not comply with the goals from step 2, it is necessary to go back to step 2 and check what went wrong.

Finally, the cycle ought to continue since lean proclaims continuous improvements.

4.2.3. Collection of RPA/lean RPA results

Once the improvement cycle has had enough processes, the results for each selected process should be gathered through simulation (for RPA approach) and real-field logs (for Lean RPA approach).

5. Demonstration

This section connects to the “Demonstration” activity of the DSR, depicted as step 4 in Fig. 2. For this purpose, we took the opportunity to carry out the demonstration in the context of a Portuguese private bank.

5.1. RPA assessment results

The methodology used to gather information about the selected RPA tools is based on the analysis of the characteristics presented in technical reports by the vendors, the Forrester Wave reports [13,20], the Gartner reports [21], participation in official online learning courses, communication with other professional RPA developers, and experience developing robots for professional and recreational purposes.

The results are stated below, and Table 2 briefly summarises what has been assessed and the prices for each tool per year. It assesses UiPath without Orchestrator (no scheduling and additional costs) and without the additional cost of acquiring the development environment (which can be more than USD$3 k).

Table 2.

Analysis summary of the two assessed tools.

Parameters	Blue Prism	UiPath
Functional Suitability	+	++
3rd Party Integration	+	+
Time Behaviour	+	+
Error-Proofing Mech.	+	+
Programming Skills*	–	+
Overall Usability	+	+
Training Courses	+	++
Robustness	++	–
Scheduling	++	+
Logs Quality	++	+
Re-usability	++	+
Performance on Df. IS	+	+
Price per robot (*)	USD$18 k	USD$6 k

(*) – estimated prices.

Table 2 shows that it is safe to assert that UiPath is adequate for entry-level. It is cheaper and possesses an active online community and free training. However, as BP is more robust, it is adequate for processes dealing with audits, fraud situations, etc. It takes longer for a beginner to learn due to its complexity. Today, its price is triple that of UiPath's price, but that can be reasoned with the Scheduling feature, which allows robots to work 24/7 for processes that require it.

5.2. Lean RPA framework – improvement cycle

In our study RPA was already being used to tackle back-office tasks. The demonstration for this sub-objective was performed inside a private Portuguese bank. The information gathering for the following subsections was done using indirect and direct observation, reading documented processes, and questioning employees about their routines at work.

In this demonstration, processes will be modelled using BPMN due to its convenience in understandability and simulations.

5.2.1. Process #1

Step 1 - Process Selection.

Choose Value Stream: Firstly, assessing the bank's banking services' value was necessary. For every bank service, it is necessary to open an account. The ABC team is responsible and seems an excellent place to start. The ABC team deals with new accounts and any alterations to accounts that may occur. The bank has one clear objective: reduce as many FTEs from the ABC team as possible.

Choose Process: Some chores were stated as obnoxious, and no one ever wanted to do them. The most cited process was the DMIF Forms2 Fulfilment. This process consists of receiving the notification that some customer has updated his/her DMIF form and proceeding to update every form in every account manually after the customer is inserted.

Map Current State & Identify Waste: The process is mapped in Fig. 5. The activity in purple is the identified waste. Searching for new DMIF alterations can be considered over-production since sometimes there are no alterations for that day, and time was wasted on that activity.2

Fig. 5.

Original DMIF Forms Fulfilment process.

Nonetheless, the whole process is mechanical and requires zero cognitive actions. This is directly mapped to the eighth waste of lean skill.

Once settled, the project advanced to step 2 of the process study.

Step 2 - Process Study.

RPA Analysis & Define Kaizen Plans: Searching for new DMIF alterations is something RPA can easily do. However, the robot could not screen-scrape new answers from the form. This was not a satisfactory solution since it could not mitigate any waste. Knowing RPA's current capabilities and limitations, the IT department was contacted to know if there was a database with the answers. It was affirmative but it would take some time to give access to the robot.

The process could continue working whilst being changed. Thus, the defined plan was to start with the previously described implementation. This way, workers would save time searching because the robot would email the information if there were any alterations. The rest of the project could continue whenever IT gave access to the database.

Map Future State & Detailed Study of the Process: The future state is mapped in Fig. 6.

Fig. 6.

Finished DMIF Forms Fulfilment process, with Lean RPA.

The “Search for new DMIF alterations” activity is still considered waste because there might be no new alterations since the last check. However, it is now attributed to the robot, which takes seconds. Also, if there are new DMIF alterations, it instantly proceeds to verify it.

Defined SMART Goals: The robot must be able to perform one instance of the process - from the search to one DMIF alteration - in less than 5 min. It is also intended that the DMIF updates are performed in every customer's account, within 24 h of the original alteration, by the customer. Additionally, after the final project goes live, the ABC team can no longer interact with the regular flux of the process.

Once settled, the project advanced to the implementation of step 3.

Step 3 - RPA Project Development.

Implement Kaizen Plans & Develop Robot, Create SOP and Simulation & Observe Performance: First, the ABC team started getting emails from the robot about any DMIF alterations. With those emails, ABC used the information to update the DMIF.

The rest of the project was developed within one week as soon as the IT department gave access to the database.

Step 4 - Maintenance & Review.

Review Goals: The first and last goals were met, as detailed in the following subsection. The second goal was met by merely running the robot every 24 h. Thus, there was no need to regress to step 2.

Go Live & Maintenance: The process went live. This generates valuable logs for further maintenance (and provides results for evaluation).

The first process using the cycle was then seen as completed, and more process queues were set for RPA.

5.2.2. Process #2

Step 1 - Process Selection.

Choose Value Stream & Choose Process & Map Current State: The DMIF Forms Fulfilment process reminded the ABC team of another unfailingly search they need to make every day.

The bank possesses three types of passwords for accounts. When a customer requests a lost password or wants to change one, a request is generated on the bank's intranet. The ABC team is then responsible for searching and returning new requests to the customer.

Identify Waste: The identified waste in the process was skill waste since searching for password requests is direct and mechanical.

This process requires cognitive actions to attribute passwords; however, searching for password requests is direct and rules-based. Therefore, this sub-process progresses to step 2.

Step 2 - Process Study.

RPA Analysis & Define Kaizen Plans: Since the robot could search effectively for the DMIF Forms Alterations in the last process, this subprocess has the same procedure but for another type of request.

Map Future State & Detailed Study of the Process: Sending Passwords will begin flowing with the robot. The robot emails ABC with the requests from the past 24 h, and the team continues the original flow accordingly.

Defined SMART Goals: This sub-process should take 1 min at most. Additionally, every request should be completed within 24 h (on weekdays).

Step 3 - RPA Development Project.

Implement Kaizen Plans & Develop Robot & Create SOP and Simulation & Observe Performance: This sub-process was developed straightforwardly since it only needed to run a query, obtain the results, build a table with the necessary information, and send it to ABC by email. This can become a standard methodology for upcoming, similar processes/sub-processes.

Step 4 - Maintenance & Review.

Review Goals: The first goal was met, as stated in the following subsection. The second goal was also met. Emailing ABC with all the necessary details makes it easier for the team to know how to proceed.

Go Live & Maintenance: The process went live. This generates valuable logs for further maintenance (and provides results for evaluation).

The second process using the cycle was completed but this time it was simpler and more practical.

5.2.3. Process #3

Step 1 - Process Selection.

Choose Value Stream & Choose Process: According to the first process and bank intentions, the ABC team is still the chosen value stream. The ABC team is composed of four members, and in every working hour, at least two members must validate documents. This is because every operation related to accounts requires it. Thus, the following process should relieve this burden.

One of the most prominent processes in the bank is the “Accounts Opening”. This sub-process consists of a Portuguese customer entering one of the bank agencies and proceeding to open an account with the banker. After this, the banker sends all the documents back to the ABC team to validate basic information and open the account.

Map Current State & Identify Waste: The original state is mapped abstractly (high-level) in Fig. 7.

Fig. 7.

Original “Accounts Opening in the Agency” process.

In Fig. 7, the waste is represented in purple in the Commercial lane. “Contact customer for missing documents” and “Receive missing documents” are activities that result from over-processing and defect waste. The banker is obligated to repeat the action of digitalizing documents and sending them to ABC. The orange activities represent the skill type of waste.

Despite the marked waste activities, there is also inventory waste. The bank keeps every document, even what is not necessary to open an account, or the customer is idle and stops sending the remaining documents.

Although opening an account requires cognitive actions, validating documents is straightforward since it is only necessary to read and check if it conforms with the rules. Therefore, the project advanced to step 2.

Step 2 - Process Study.

RPA Analysis & Define Kaizen Plans: Applying straightforward RPA development to the process would entail ABC's verification for every account due to today's low OCR reliability. This could not be practical nor reduce any waste. However, checking documents and sending the process for conclusion is accessible to RPA and reduces some work time for ABC team members.

Nonetheless, the process flow needs modifications.

Map Future State & Detailed Study of the Process: The future state is mapped in Fig. 8. The most significant change is in the Commercial lane instead of the robot.

Fig. 8.

Accounts Opening in the Agency process, with Lean RPA.

The banker checks with the customer for the necessary documents before starting the opening account process. If the customer does not bring the mandatory documents, then they are informed by the banker about the missing documents and how to proceed with the opening of the account.

Afterwards, the robot must open the account by checking the documents and sending the opening process for conclusion. As seen, the ABC team is now spared from this process.

Defined SMART Goals: This process needs to reduce its average time by half to spare one FTE. Additionally, after the final project goes live, the ABC team can no longer interact with the normal flux of the process.

Once settled, the project was meant to advance to step 3. However, it did not progress any further. The Lean RPA results presented in the next section are obtained through simulation.

5.3. Collection of RPA/lean RPA results

To collect RPA results, only RPA processes were designed and simulated for twenty-two days (one working day per month). This was also used to collect Lean RPA results from Process #3.

The Lean RPA results were collected in the field for one month. Every time the robot ran a specific process (or sub-process), it generated a log with what was done and the processing times.

5.3.1. DMIF Forms Fulfilment results

Table 3 shows the obtained results from the DMIF Forms Fulfilment process. The presented values are the number of minutes wasted on the process per weekday. The average of DMIF alterations is usually four. However, this is only a partially reliable value since the customer initially triggers the process and is therefore not constant.

Table 3.

DMIF Forms Fulfilment process time results, in minutes per day, without waiting time.

Team		Original	RPA	Lean RPA
ABC	Avg	27	19.5	0
	Min	15	0	0
Robot	Avg	–	0.11	0.76
	Min	–	0.08	0.08

5.3.2. Searching for password requests (sub-processes) results

Table 4 shows the obtained results from the automated sub-process “Searching for Password Requests”. This table does not include a “Process w/RPA” column because investing in automation for a sub-process as simple as this would not be rewarding. It was only automated as a result of the Lean approach.

Table 4.

Searching for Password Requests subprocess time results in minutes per day.

Team		Original	Lean RPA
ABC	Avg	15	0
Robot	Avg	–	1

5.3.3. Account Opening results

Table 5 shows the obtained results in the actual field (original) and simulation (RPA & Lean RPA) from the Account Opening process. The written values are the minutes wasted on the process per every new account. Minimum values are ignored for Lean RPA due to the absence of work repetition.

Table 5.

Account Opening process time results in minutes per new account without waiting time.

Team		Original	RPA	Lean RPA
Com	Avg	32	32	36
	Min	27.5	27.5	–
ABC	Avg	12.5	7.87	0
	Min	7.25	5	–
Robot	Avg	–	1.76	0.7
	Min	–	1.76	–

6. Evaluation

This section is connected to the “Evaluation” step of the DSR Methodology. Evaluation of an Information System is dependent on its context and chronologic relationship to the creation of the artefact, according to Pries-Heje et al. [39]. Ex ante refers to when the evaluation occurs before the artefact is developed, and ex-post refers to when it occurs after the artefact has been created. If the evaluation environment occurs in a real-world situation, it is referred to as naturalistic. It would be considered artificial if the evaluation was carried out using simulation, criteria-based analysis, or lab tests. The method developed as a result of this research proposal was evaluated according to its demonstration. The demonstration assessed the generated artefact's Usability and efficacy in a real-world scenario to determine whether the suggested method can be used in a practical setting. Therefore, this evaluation is categorized as ex-post and naturalistic.

It follows some of the evaluation criteria proposed by Ref. [40], such as Efficacy, Generality and Validity from the Goal dimension, Utility, Fit with the Organization, and Harnessing of Recent Technologies from the Consistency with organization criterion from the Environment dimension. The evaluation criteria used are described in Table 6.

Table 6.

Evaluation criteria used (adapted from Ref. [39]).

System Dimension	Evaluation Criterion	Definition
Goal	Efficacy	The degree to which the artefact produces its desired effect.
	Generality	The broader the goal addressed by the artefact, the more general the artefact.
	Validity	The degree to which the artefact works correctly, i.e. correctly achieves its goal.
Environment	Consistency with organization – Utility	Measures the quality of the artefact in practical use.
	Consistency with organization – Fit with Organization	Characterizes the alignment of the IS artefact with its organizational environment.
	Consistency with technology – Harnessing of Recent Technologies	Considers if the artefact is a new layer built on new IT artefacts.

6.1. #1 sub-objective – RPA Tools Assessment

The bank had already bought an RPA license for UiPath. However, the bank's reasons correspond to the results of the assessment. It was due to its price and overall appropriateness and Usability. Therefore, the assessment meets the validity criteria, as it matches the bank's choices.

6.2. #2 sub-objective – lean RPA framework

Regarding generality, it determines how general the artefact is. The proposed framework must have a broader range of possible processes to act upon. The framework was validated in the bank, and there were no barriers in any phase. However, it is impossible to guarantee that the evaluation is entirely positive on this criterion because it needs to be tested on more realistic scenarios.

After applying the solution in the bank and getting positive results from the teams involved, the bank intends to continue improving its processes. Consequently, the framework passes the following evaluation criteria: utility and fit with the organization.

Finally, it arose from the necessity to approach a new technology – RPA – in a manner that is different from how companies have approached. Thus, the framework harnesses recent technologies.

6.3. Primary objective

To recall, the primary objective of the proposal was to understand how much more effective and efficient Lean RPA is, when compared to RPA.

Regarding the efficacy criterion, which is the degree to which the artefact produces its desired effect, table 8 supports the primary objective evaluation.

Table 7 represents the three processes presented in Demonstration (section 5), on the monthly average processing time difference. The following table needs to consider the waiting time each process has. It is assumed one month equals 22 working days, that the new accounts average is 20 per day, and that the average of DMIF alterations is 4 per day.

Table 7.

Average time difference (in hours) in one month for each process, without waiting time.

Process	Original Process	Process w/RPA	Process w/Lean RPA
1. DMIF Forms Fulfillment	9.9	7.15	0.28
2. Searching for Password Requests	5.5	–	0.37
3. Accounts Opening in Agency	326.3	305.3	269.1

Although only three processes were studied, the bank naturally has more manual and rules-based processes, specifically the back-office department. Continuing the automation journey, reducing FTE will be organic to the bank. It is adequate to assert that, in these cases, Lean RPA was more efficient and effective than RPA. It is efficient because the processes reduce processing time and are effective. After all, changing processes considering RPA's current capabilities will reduce runtime mistakes. The sum of all the time saved using Lean RPA instead of normal RPA equals a little over six work days for one FTE during one month (27.39%).

7. Conclusion

Using Design Science Research Methodology, this study explained the problem with typical RPA implementations and objectives. Being RPA a lightweight technology, it is a quick automation that may fix some problems, but organizations are underestimating its value.

To try to prove it, a primary objective has been defined: to understand how much more effective and efficient Lean RPA projects were compared to RPA projects.

Primarily, it was necessary to assess an RPA tool. Blue Prism and UiPath were used and put to the test. It was concluded that although the first is more robust and reliable, UiPath is the correct choice for RPA starters due to its functional appropriateness and price. Secondarily, it was essential to obtain Lean RPA results by creating a framework to follow its steps. The framework has incremental activities aiming at everyone's involved participation since the project's beginning.

After applying the first two sub-objectives, the outcome was evaluated with the gathered results. The framework was applied in one bank for three processes, and the results were mostly positive. Despite the organic time reduction that RPA projects already secure, every process significantly reduced time compared to RPA and Lean RPA. It was also successful concerning its utility since the referred bank has continued following the activities.

Concerning the two research questions in section 1 (Research Problems): How can RPA take advantage of a continuous process improvement approach? Moreover, what is its impact? Lean RPA takes advantage of a continuous improvement approach by automating and changing processes (and subprocesses) that simple RPA projects would not approach since it does not fit the typical process choice. The studied processes had an easy and secure development and implementation, whereas other complex processes would take longer. Due to its price, fast development and effectiveness, Lean RPA projects can change how processes flow inside an entire organization with the right improvements and considering the processes modelling and execution. It does not leverage the overall cost by much since it uses basic ideas and takes advantage of the internal teams’ help that already knows the processes and workflows.

In this study, we find limitations in the number of processes used. The framework should be tested on processes in different organizations and business realities. Also, these real-field studies need a bigger team, and more time to perform the changes the proposed processes may need.

Additionally, the proposed Lean RPA framework is not a stand-alone tool since it needs to read the described methodology and parts of the bibliography, referring to the models and notations.

To conclude the DSR, the activity Communication covered by this article, communicates the results.

In the future, the Lean RPA framework needs to be evaluated for its understandability by the users. Future efforts are also required for an improved framework, such as merging Lean with Six Sigma. Six Sigma consists of improving the quality of the output of a process using quality management methods, mainly statistical ones. This would bring a new perspective on the process flow's actual values (time and cost). Some authors even defend that Lean without Six Sigma lacks tools to leverage improvement to its full potential [41].

Using this article as a basis is valuable for further research into this area.

More RPA tools should be assessed and compared together. The other market leader, Automation Anywhere (AA), is a good starting point to begin this analysis.

OCR mechanisms are also improving. When OCR finally reaches a satisfactory result, there will be more processes to automate, and the analysis is undoubtedly different from the one mentioned in this study.

Author contribution statement

Carina Maria Gonçalves Martins: conceived and designed the experiments; performed the experiments; analyzed and interpreted the data; Contributed reagents, materials, analysis tools or data; wrote the paper.

Henrique S. Mamede: conceived and designed the experiments; performed the experiments; analyzed and interpreted the data; Contributed reagents, materials, analysis tools or data; wrote the paper.

Miguel Mira da Silva: conceived and designed the experiments; performed the experiments; analyzed and interpreted the data; Contributed reagents, materials, analysis tools or data.

Funding statement

This study was supported by National Funds through the Portuguese funding agency, FCT - Fundação para a Ciência e a Tecnologia, within project LA/P/0063/2020.

Data availability statement

No data was used for the research described in the article.

Additional information

No additional information is available for this paper.

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.