Towards Quantifying the Effects of Robotic Process Automation [original]

Towards Quantifying the Effects

of Robotic Process Automation

Judith Wewerka

Institute of Databases and Information Systems

Ulm University

Ulm, Germany

0000-0002-4809-2480

Manfred Reichert

Institute of Databases and Information Systems

Ulm University

Ulm, Germany

0000-0003-2536-4153

Abstract—Robotic Process Automation (RPA) is the automa-

tion of rule-based routine processes to increase process efficiency

and to reduce process costs. In practice, however, RPA is often

applied without knowledge of the concrete effects its introduction

will have on the automated process and the involved stakeholders.

Accordingly, literature on the quantitative effects of RPA is

scarce. The objective of this paper is to provide empirical in-

sights into improvements and deteriorations of business processes

achieved in twelve RPA projects in the automotive industry. The

results indicate that the positive benefits promised in literature

are not always achieved in practice. In particular, shorter case

duration and better quality are not confirmed by the empirical

data gathered in the considered RPA projects. These quantitative

insights constitute a valuable contribution to the currently rather

qualitative literature on RPA.

Index Terms—Robotic Process Automation, Quantify RPA

Effects, Measure RPA, Monitor RPA Bots

I. INTRODUCTION

Robotic Process Automation (RPA) aims to automate pro-

cesses by software bots mimicking human interactions [2].

In particular, RPA supports organizations with optimizing

and implementing their business processes [21] or parts of

these processes by exploiting automation opportunities. Con-

sequently, expectations on the benefits introduced by RPA

are high, although the value created by RPA projects is not

granted [30]. Enterprises therefore crave for insights into the

effects created by the implementation and introduction of RPA,

particularly into whether or not the expected benefits can be

actually achieved. In the following, implementation refers to

the coding and testing of the RPA bot, whereas introduction

considers the roll out and actual use of the bot.

Though the usefulness of implementing and introducing

RPA is generally acknowledged by enterprise architects, con-

crete RPA effects are not sufficiently reported in literature.

The benefits of RPA appear pervasive, but to the best of

our knowledge there are no empirical evaluations confirming

that RPA actually improves business processes. This lack

of empirical evidence confirming RPA effects necessitates

empirical studies for quantifying these effects. The term effects

is used, as we do not want to solely focus on RPA benefits,

but look at negative RPA effects as well.

This paper qualifies and quantifies the effects of twelve RPA

projects (i.e., P01-P12) on the product engineering process of

an automotive vendor. For this purpose, 14 interviews (i.e.,

I01-I14) were conducted to qualify RPA effects. Afterwards,

RPA effects were quantified by questionnaires asking for

performance indicators, e.g., speed or quality. The data were

collected from professionals involved in the RPA projects and

shall help to properly assess RPA effects. Note that the paper

is less about offering a specific study for individual effects,

but rather about presenting expected and achieved effects in

twelve real-life projects in a knowledge-intensive domain.

II. METHODOLOGY

We derived relevant research questions (RQs). First of all,

we investigated RPA projects in the domain of automotive

engineering and tried to qualify the effects the involved

stakeholders expected from the respective RPA initiative.

This resulted in our first research question RQ 1: What

effects should be achieved with RPA projects? Then,

we investigated whether and how the occurrence of the

respective effects can be measured. This was formulated in

the second research question RQ 2: How is it currently

measured whether or not the expected RPA effects are

achieved? Based on RQ 2, we investigated, which measures

are appropriate to quantify these effects. This led to the

third research question RQ 3: Which measures provide

information on the occurrence of the RPA effects? Finally,

the last research question aimed to quantify the discovered

effects in detail: RQ 4: Were the expected RPA effects

achieved?

Our methodical approach is illustrated by Fig. 1. In partic-

ular, we wanted to consider insights from both literature and

practice. Regarding the former, literature on RPA effects was

systematically reviewed to answer RQ 1 - RQ 3 [29]. Regard-

ing the latter, semi-structured interviews and a questionnaire

were used. We conducted semi-structured interviews with

seven RPA product owners and seven RPA creators to qualify

the effects that shall be achieved with twelve RPA projects.

An RPA product owner is the person responsible for the RPA

project on the management side. An RPA creator, in turn, is

the person programming the RPA bot. The interview guide

was structured as follows: First, general information on the

RPA project and the resulting RPA bot was gathered. Second,

Fig. 1. Research Method.

TABLE I

OVERVIEW OF THE TWELVE RPA PROJECTS.

Project Interview Bot description

P01 I01 Bot downloads and uploads data into a system

for comparison.

P02 I02 Bot gathers data from different IT systems and

provides dashboards for engineers.

P03 I03, I13 Bot generates reports with data from different

systems for communication to the customer.

P04 I04 Bot archives old files according to a predefined

logic.

P05 I05 Bot assigns tasks to the responsible employee.

P06 I06 Bot checks material orders and triggers the inter-

nal order process.

P07 I07 Bot calculates prices based on given information

and sends the result to the requester.

P08 I08 Bot reads data from Excel files and creates claim

reports.

P09 I09 Bot gets data from Excel files and creates com-

mercial invoices in the respective system.

P10 I10 Bot exports and saves data for quality checks.

P11 I11 Bot checks whether an order is correct; if this is

not the case, it sends an email to the requester.

P12 I12, I14 Bot generates, stores, and compares data. Further-

more, it records process-related events to check

for business process compliance.

we asked for the effects expected from the RPA project.

Finally, information on monitoring the bot was collected. Each

interview lasted around 30 minutes and data was analysed

using an inductive approach.

Based on the interview results we developed a questionnaire

that surveyed data before and after introducing RPA (cf.

Appendix). We measured improvements and deteriorations

with the RPA introduction. The questionnaire was distributed

to the RPA creators of the twelve projects. Note that the

data retrieved with the questionnaire are estimations made by

experts to the best of their knowledge, which constitutes a

widely accepted approach [12].

The interviewees and participants of the questionnaire were

selected from twelve different RPA projects in the area of

product engineering in the automotive industry. Due to lack

of space, the twelve software bots of the RPA projects cannot

be described in detail. However, some background on the

respective bot functions is provided in Table I.

III. RESULTS

A. RQ 1: What Effects Should Be Achieved with RPA Projects?

As a preparation step, a systematic literature review was

performed [29]. Based on well-defined criteria, relevant litera-

ture on RPA was studied. The insights from literature on RPA

effects are summarized in the following.

Based on this review, the effects expected from RPA projects

can be divided into the ones on the enterprise and its business

processes on one hand and the effects on enterprise staff on the

other. Due to space limitations, we only consider the expected

effects on the enterprise, which are mostly positive:

•Speed: Automated processes shall run faster and the

average case duration (i.e., the time needed for processing

the business case) shall become shorter. Accordingly, it

is expected that more work can be accomplished with

the same resources or full time equivalents (FTE) can be

saved [1], [5], [7], [10], [13], [14], [17], [23], [26], [27],

[30], [32].

•Availability: Most RPA bots are available 24/7 and in-

stant access is granted. Moreover, RPA is highly scalable

to meet varying intensity of demands [1], [4], [7], [13],

[16], [19], [23], [24], [31], [33].

•Compliance: Processes executed by a bot become trans-

parent and are documented in detail fostering compliance

[13], [15]–[17], [19], [24], [31].

•Quality: RPA eliminates human errors, improves ac-

curacy and data quality, and leads to higher customer

satisfaction [4]–[7], [17], [19], [23], [24], [26], [27], [30],

[31], [33].

Negative effects or limitations of RPA are seldomly re-

ported in literature, e.g., [11] characterizes RPA solutions as

workarounds and [2] and [10] emphasize that RPA constitutes

atemporary solution. According to [3], there are software

suites (e.g., special forensic software) not being compatible

with current RPA solutions.

In the 14 conducted interviews (i.e., I01-I14), we asked

RPA professionals, which effects they expected from their RPA

projects. Most effects mentioned by the interviewees comply

with the ones reported in literature. Overall, we discovered six

different effects (FTE savings, improvement of result quality,

faster processes, RPA as temporary solution, improvement

of availability, and improvement of compliance). Moreover,

no negative effects were mentioned. Table II summarizes the

results. A “+” indicates that the person expected the effect to

be positive in the RPA project, whereas a “-” indicates that

the effect is not relevant. In the context of “RPA as temporary

solution” a “+” indicates that the person expects RPA to be

a temporary solution being replaced, e.g., by an IT interface,

whereas a “-” emphasizes that the interviewee expects RPA

to be a permanent solution. Note that interviewees from the

same project, e.g., I03 and I13, might expect different RPA

effects.

TABLE II

EFFECTS MENTIONED IN THE INTERVIEW.

Interview FTE savings Improvement of

result quality Faster process RPA as temporary

solution

Improvement of

availability

Improvement of

compliance

I01 + + +

I02 + -

I03 + +

I04 + + -

I05 + + +

I06 +

I07 +

I08 - + +

I09 + + -

I10 + - +

I11 + -

I12 + + +

I13 + +

I14 + + +

B. RQ 2: How Is It Currently Measured Whether or Not the

Expected RPA Effects Are Achieved?

When studying current literature on measuring RPA effects

and their occurrence, results are very scarce. Reference [19]

indicates that “You need to track and monitor the effective-

ness”. Several papers emphasize the importance of monitoring

the implemented bots [8], [19], whereas [9] and [23] suggest

evaluating key performance indicators before and after imple-

menting and introducing the RPA approach in order to measure

actual improvements. No details on how to accomplish such

measurements are given. According to [30] “results are not

guaranteed”. In [13], cost savings of 30% per process are

achieved. Reference [31] emphasizes that cycle time is reduced

from days to minutes and an accuracy of 99.99% can be

accomplished.

Only few suggestions are made in respect to concrete

measures for RPA effects, i.e., to measure

•quality improvements based on the number of mistakes

made [25],

•speed of the RPA bot based on the number of transactions

it performs in a certain time frame [1], [8], [23], [32],

•cost savings in terms of the number of saved FTE [8],

[9], [23], [30],

•FTE savings by average numbers of staff and cases per

staff per month [32].

Except in [1] and [32], no concrete numbers are provided

on respective measures. To measure productivity, [1] observes

that the mean case duration required when using RPA is 9

seconds less than without RPA and agents are able to handle

21% more cases with RPA than before. In [32], productivity

is measured by the average number of cases per staff per

month. After introducing RPA, productivity improves by over

1,051%. The mean case duration is reduced from 360 minutes

without RPA to 15 minutes with RPA in the first use case

and from 120 minutes without RPA to 15 minutes with RPA

in the second use case.

During the interviews, we investigated the situation in

the RPA projects in the product engineering process. The

interviewees were asked whether or not the RPA bot provided

as a result of their project is monitored. Only five out of 14

confirmed such a monitoring of the bot. In detail, monitoring

means that the RPA creators look at the errors made by the

bot to properly react and to document the number of errors.

Additionally, two interviewees monitor the case duration of

the RPA bot. Most RPA professionals agreed that “the main

thing is that the bot works properly”.

C. RQ 3: Which Measures Provide Information on the Occur-

rence of the RPA Effects?

RQ 3 combines the results from the two preceding research

questions. For every effect identified in the context of RQ 1,

we either obtain a measure from RQ 2 or develop a new one.

Each measure is taken before as well as after introducing RPA.

Table III summarizes the effects and corresponding measures.

D. RQ 4: Were the Expected RPA Effects Achieved?

To answer RQ 4, we evaluated the twelve questionnaires

filled by RPA experts. The measures proposed in Table III

served as a basis for this evaluation.

Fig. 2 shows the FTE savings per RPA project (P01-

P12), calculated by the formula from Table III. Some projects

achieve minor FTE savings (P03, P04, P08) in their business

processes, only two of them save 1.43 FTE (P09, P12). All

other have FTE savings between 0.2 and 0.6 FTE.

To assess the improvement of result quality [18], we

evaluated the percentage of cases with error before and after

introducing the RPA bot. A case with error is considered to be

a case that does not produce the expected result and manual

rework is necessary. Fig. 3 visualizes the percentage of cases

with error before and after RPA introduction, as well as the

percentage change. Accordingly, projects P02, P04, P05, and

P09 are successful RPA introductions reducing the number

of errors and improving quality. Some projects achieve slight

improvements and the bot is at least as good as a human.

Fig. 2. FTE savings per project.

TABLE III

MEASURES FOR RPA EFFECTS.

Effect Measure proposed

in literature Developed measure

FTE savings Cost savings [8], [9],

[23], [30]

#cases per day ×minutes per case

daily working time of employee

Improvement

of result quality

Number of mistakes

[25]

Percentage of cases with er-

ror

Faster process

Number of cases [1],

[8], [23],

mean case duration

[1], [32]

Temporary so-

lution -Polar question: RPA as tem-

porary solution

Improvement

of availability -Polar question: unexpected

downtime of the bot

Improvement

of compliance -Percentage of cases with

compliance issues

Regarding P07, P08, and P12, severe deteriorations with up

to 24 times more cases with error than before occur with the

implementation and introduction of the RPA bot.

To measure whether the process is faster, the number

of cases per day and the mean case duration before and

after RPA introduction were evaluated. For the investigated

projects, the number of cases does not change after introducing

the bot. Apparently, all cases were already handled before

the RPA introduction. Therefore, Fig. 4 displays the mean

case duration in minutes for the twelve projects before and

after RPA introduction and the percentage change. Only one

project achieves a clear reduction of the case duration (P05).

Five projects achieve a bit faster process and the process

supported by the RPA bot takes between 50% to 75% of the

manual process (P02, P06, P07, P10, and P12). The other

processes deteriorate and the process becomes slower than

before. Interestingly, two projects (P03 and P08) significantly

slow down the process due to the introduction of the RPA bot.

For seven projects, RPA is seen as a temporary solution,

contrary to five projects considering RPA as long-term solution

(cf. Fig. 5).

Improvement of availability is achieved in every project.

There are no unexpected downtime of the bot. Therefore, the

bot is virtually available 24/7 compared to a human worker

with fixed working hours and absence times.

As none of the projects had compliance problems before

implementing and introducing the RPA bot, improvement of

compliance is not measurable.

IV. DISCUSSION

The presented results enable us to answer the RQs. In

the following, the results are discussed and interpreted along

the RQs using the insights gained through accompanying the

Fig. 3. Percentage of cases with error per project before and after RPA introduction and percentage change.

twelve projects for one year. The data was gathered over a

period of six months after the introduction of the respective

RPA bot.

Comparing the results of the literature review and the

interviews for RQ 1, all effects considered as important in

practice are covered by literature, although granularity differs:

In literature, the aspect “speed” covers three aspects, i.e., faster

process, more work with same resources, and less FTE. In the

interviews, FTE savings and faster processes were considered

as two different effects. Most interviewees wanted to save

FTE, but this did not necessarily mean that the process runs

faster. Some explicitly stated that the speed of the bot does

not matter at all as long as no person has to do the process

anymore and the quality of the output is satisfying. Half of

the interviewees expected improvements in result quality, an

aspect being equally covered in literature. Improvements of

compliance and availability are often emphasized in literature,

but seem to be less important in practice according to the inter-

views. Though RPA is - per definition - a temporary solution

[2], some RPA professionals consider it as a permanent one.

Neither literature nor practice focuses on the monitoring

of RPA bots (RQ 2). The interviews emphasized that it is

important that the bot works, whereas the exact effects are less

interesting. Some interviewees confirmed that they “want to be

first” meaning they wanted to be the first ones implementing

and introducing an RPA bot in the company. Accordingly,

monitoring the effects of the bot is not important to them.

Reference [20] investigates benefits of applying RPA to master

data management in two companies. However, the benefits

are only qualified, but not quantified. As a result, in both

cases quality and productivity are improved. Moreover, human

errors, transaction time, and costs are reduced, and employees

are relieved from repetitive tasks. Details on how the data

are gathered are missing. Reference [28] presents a structured

literature review identifying RPA benefits while stating that

“future research on RPA benefits realisation” constitutes a

challenge to be tackled.

Concerning RQ 3, the developed measures are a first step

towards quantifying RPA effects. Still, other measures are

useful, for example, FTE savings can be measured more

precisely by subtracting the time needed to trigger the bot

and necessary manual rework if the bot makes an error. A

faster process execution can be measured by different aspects

like, e.g., the service and waiting times, i.e., the time spent

by resources on process execution and the idle time of a case

(e.g., [22] measures the effectiveness of workflow management

systems).

In the following, results concerning RQ 4 (i.e., whether or

not the expected RPA effects were achieved) are discussed

and related to the effects expected according to the interview

results.

All projects save FTE. Although I12 did not mention FTE

savings, P12 saves 1.43 FTE. I08 stated that FTE savings are

not the prior focus of introducing RPA, still 0.07 FTE are

saved in P08. Low FTE savings are due to a small number of

process transactions and/or a short case duration.

Improvements of result quality are not granted. Only

nine of the twelve projects achieve at least slight quality

Fig. 4. Mean case duration in minutes before and after RPA introduction and percentage change per project.

Fig. 5. Is RPA a temporary solution?

improvements. No project manages 99.99% of accuracy as

reported in [31]. The best improvements are achieved in P05

and P09, which both constitute projects with a high number

of process executions (50 respectively 200 cases per day).

Obviously, human process execution is error prone and an

RPA bot helps to reduce human errors. Concerning P12,

which suffers deteriorations in quality, the filled questionnaire

indicates that the bot works perfectly, but the employees do not

provide the correct input. Here, a training for the employees

working with the bot would be a reasonable approach. In

general, it would be interesting to understand why processes

are prone to errors. Different root-causes seem plausible: the

implementation is not correct, or the human input is not

precise, or the process is too complex for a bot and human

interaction becomes necessary. In the interviews, improvement

of result quality was seen as an important aspect in P01-P04,

P09, and P12. For the first five projects, a reduction of 40%

up to 99% of the errors is achieved with RPA. Only P12 does

not attain the expected improvement as employees have not

always provided the correct input.

In [31], the speed of process execution is improved from

days to minutes. None of the investigated project reaches

such an improvement. Reference [32] improves the mean

case duration from 360 to 15 minutes, leading to a 96%

faster process by using RPA. The use case in [13] achieves a

30% faster process. Regarding Fig. 4, six of the investigated

projects improve by 25% to 80% concerning the mean case

duration of the automated process. Reference [1] presents a

mean case duration improvement from 440 seconds to 431

seconds, which is an improvement of only around 2%. Some

of the studied projects slow down the mean case duration.

Note that according to the interviews, a faster process is

not always the focus (I02, I09, I11). As motivation, the

interviewees mention that “no person has to execute the

process anymore, no matter how long the bot takes.” In

contrast, I05, I08, and I13 wanted to speed up the process by

RPA. Only P05 achieves this improvement with the process

taking 5 minutes before and 1 minute after RPA introduction.

Interestingly, P03 and P08 have a longer mean case duration

with RPA.

TABLE IV

OVERVIEW P03: ACHIEVED EFFECTS.

P03 Bot generates reports with data from different systems

for communication to the customer.

Expected effects

(interview)

FTE savings, improvement of result quality, faster

process

FTE savings 0.02 FTE

Result quality 5% of erroneous cases before RPA

3% of erroneous cases with RPA

-40% improvement

Faster process 5 minutes mean case duration before RPA

120 minutes mean case duration with RPA

+2300% deterioration

TABLE V

OVERVIEW P05: ACHIEVED EFFECTS.

P05 Bot assigns tasks to the responsible employee.

Expected effects

(interview)

FTE savings, faster process, improvement of avail-

ability

FTE savings 0.6 FTE

Faster process 5 minutes mean case duration before RPA

1 minute mean case duration with RPA

-80% improvement

Availability fixed working hours and absence times before RPA

24/7 availability with RPA

Result quality

(not expected)

10% of erroneous cases before RPA

0.1% of erroneous cases with RPA

-99% improvement

Finally, we assess the twelve projects on whether or not

the expected effects were achieved with the respective RPA

initiative. Tables IV and V present exemplary overviews of

two projects (P03 and P05). Each table depicts the automated

task, expected effects mentioned in the interviews, and con-

crete numbers for the actually achieved effects. P03 achieves

minor FTE savings (0.02 FTE) and result quality is improved

by 40%. Before introducing RPA, 5% of the cases were

error prone, and after RPA introduction 3% of the cases are

erroneous. The fastening of the process is not achieved as

expected, the mean case duration deteriorates from 5 minutes

to 120 minutes (cf. Table IV). By contrast, P05 constitutes a

successful RPA initiative: 0.6 FTE are saved, the mean case

duration improves by 80% from 5 minutes to 1 minute, and

the expected improvement in respect to availability is achieved.

Additionally, RPA improves result quality by 99% even though

the effect was not expected beforehand (cf. Table V).

Table VI summarizes all projects as well as expected and

achieved effects on a more abstract level. “+” and “-” indicate

an expected or achieved positive respective negative effect, and

“/” indicates that the achieved effect is minimal (e.g. less than

0.1 FTE are saved). The concrete numbers can be retrieved

from Figures 2-4.

Eight of the twelve RPA projects, i.e., P01, P02, P05-P07,

and P09-P11, may be considered as successful achieving all

effects expected beforehand. By contrast, P03 does not attain

the expected FTE savings and speed effects, P04 does not

fulfill the expected FTE savings, P08 does not improve in

TABLE VI

OVERVIEW OF EXPECTED AND ACHIEVED EFFECTS.

FTE savings Improvement

of result quality Faster process

Expected Achieved Expected Achieved Expected Achieved

P01 + + + + -

P02 + + + - +

P03 + / + + + -

P04 + / + + -

P05 + + + + +

P06 + + / +

P07 + + - +

P08 - / - + -

P09 + + + + - -

P10 + + + +

P11 + + / - -

P12 + + + - +

speed as expected, and P12 does not attain better result quality.

The major lessons learned are as follows:

•FTE savings are the main expectation articulated when

introducing RPA in a knowledge-intensive domain.

•A faster process is regarded as a positive side-effect of

introducing RPA, but is not the main motivation.

•Expected effects are not always achieved.

•RPA effect measures should be further developed, as also

emphasized in [28] that calls to research “comprehensive

metrics for benefits” which we support.

As a thread to validity, the number of participants filling

in the questionnaire is rather small, only RPA experts of

one large company from the automotive domain participated.

Nevertheless, insights into twelve different RPA projects from

the automotive industry were gained, constituting a valuable

contribution to the currently rather qualitative literature on

RPA. The results further show that no general statement re-

garding the effects of an RPA implementation and introduction

can be made.

V. SUMMARY AND OUTLOOK

The positive effects reported in literature cannot be taken for

granted in RPA projects. Therefore, it is desirable to predict the

effects of an RPA project beforehand, e.g., based on business

process criteria. For this, many more RPA implementations

need to be investigated, which could be part of future research.

For future RPA projects the effects to be achieved should be

explicitly defined at the beginning. Accordingly, the current -

not yet automated - business process can be measured to these

effects. After implementing and introducing RPA, the same

effects are measured and it is monitored whether the expected

effects are accomplished. For example, sometimes a faster

process is not necessarily expected, therefore, the measure of

the mean case duration needs not be evaluated. Hence, an

RPA project can be successful even if general measures do

not indicate the success.

REFERENCES

[1] S. Aguirre and A. Rodriguez, “Automation of a Business Process Using

Robotic Process Automation (RPA): A Case Study,” in Workshop on

Eng Appl. Springer, 2017, pp. 65–71.

[2] A. Asatiani and E. Penttinen, “Turning robotic process automation into

commercial success - Case OpusCapita,” J Inf Technol Teach Cases,

vol. 6, no. 2, pp. 67–74, 2016.

[3] A. Asquith and G. Horsman, “Let the robots do it! - Taking a look

at Robotic Process Automation and its potential application in digital

forensics,” Forensic Science International: Reports, vol. 1, 2019.

[4] J. Bruno, S. Johnson, and J. Hesley, “Robotic disruption and the new

revenue cycle: robotic process automation represents an immediate new

opportunity for healthcare organizations to perform repetitive, ongoing

revenue cycle processes more efficiently and accurately,” Healthc Financ

Manag, vol. 71, no. 9, pp. 54–62, 2017.

[5] T. R. Eikebrokk and D. H. Olsen, “Robotic Process Automation and

Consequences for Knowledge Workers; a Mixed-Method Study,” in Conf

e-Business, e-Services e-Society. Springer, 2020, pp. 114–125.

[6] D. Fernandez and A. Aman, “Impacts of Robotic Process Automation on

Global Accounting Services,” Asian J Account Gov, vol. 9, pp. 123–132,

2018.

[7] H. P. Fung, “Criteria, Use Cases and Effects of Information Technology

Process Automation (ITPA),” Adv Robot Autom, vol. 3, no. 3, 2014.

[8] J. Geyer-Klingeberg, J. Nakladal, and F. Baldauf, “Process Mining and

Robotic Process Automation: A Perfect Match,” in BPM (Disserta-

tion/Demos/Industry, 2018, pp. 124–131.

[9] P. Hallikainen, R. Bekkhus, and S. L. Pan, “How OpusCapita Used

Internal RPA Capabilities to Offer Services to Clients,” MIS Q Exec,

vol. 17, no. 1, pp. 41–52, 2018.

[10] J. Hindel, L. M. Cabrera, and M. Stierle, “Robotic process automation:

Hype or hope?” in WI2020 Zentrale Tracks, 2020, pp. 1750–1762.

[11] C. Houy, M. Hamberg, and P. Fettke, “Robotic Process Automation in

Public Administrations,” in Digitalisierung von Staat und Verwaltung,

M. R¨

ackers, S. Halsbenning, D. R¨

atz, D. Richter, and E. Schweighofer,

Eds. Gesellschaft f¨

ur Informatik eV, 2019, pp. 62–74.

[12] M. Jørgensen, “A review of studies on expert estimation of software

development effort,” J Syst Softw, vol. 70, pp. 37–60, 2004.

[13] M. Lacity and L. Willcocks, “A New Approach to Automating Services,”

MIT Sloan Manag Rev, 2017.

[14] M. Lacity, L. Willcocks, and A. Craig, “Robotic process automation at

Xchanging,” Outsourcing Unit Work Pap Ser, vol. 15, no. 3, pp. 1–26,

2015.

[15] ——, “Robotizing Global Financial Shared Services at Royal DSM,”

Outsourcing Unit Work Pap Ser, vol. 16, no. 2, pp. 1–26, 2016.

[16] ——, “Service Automation: Cognitive Virtual Agents at SEB Bank,”

London Sch Econ Polit Sci, pp. 1–29, 2017.

[17] V. Leno, M. Dumas, F. M. Maggi, and M. La Rosa, “Multi-Perspective

process model discovery for robotic process automation,” in CEUR

Workshop Proceedings, vol. 2114, 2018, pp. 37–45.

[18] M. Lohrmann and M. Reichert, “Understanding business process qual-

ity,” in Bus Process Manag, M. Glykas, Ed. Springer, 2013, vol. 444,

pp. 41–73.

[19] S. Mohanty and S. Vyas, “Intelligent Process Automation = RPA +

AI,” in How to Compete in the Age of Artificial Intelligence. Apress,

Berkeley, CA, 2018, pp. 125–141.

[20] A. M. Radke, M. T. Dang, and A. Tan, “Using Robotic Process

Automation (RPA) to enhance item master data maintenance process,”

LogForum, vol. 16, no. 1, pp. 129–140, 2020.

[21] M. Reichert and B. Weber, Enabling flexibility in process-aware infor-

mation systems: challenges, methods, technologies. Springer Science

& Business Media, 2012.

[22] H. A. Reijers, I. Vanderfeesten, and W. M. Van Der Aalst, “The

effectiveness of workflow management systems: A longitudinal study,”

Int J Inf Manag, vol. 36, no. 1, pp. 126–141, 2016.

[23] M. Schmitz, C. Dietze, and C. Czarnecki, “Enabling digital transfor-

mation through robotic process automation at Deutsche Telekom,” in

Digitalization Cases, Management for Professionals, N. Urbach and

M. R¨

oglinger, Eds. Springer, 2019, pp. 15–33.

[24] M. Schmitz, C. Stummer, and G. Michael, “Smart Automation as

Enabler of Digitalization? A Review of RPA/AI Potential and Barriers

to Its Realization,” in Future Telco, Management for Professionals,

P. Kr¨

ussel, Ed. Springer, 2019, pp. 349–358.

[25] M. Smeets, R. Erhard, and T. Kaußler, “Robotic Process Automation

(RPA) in der Finanzwirtschaft,” Springer Books, 2019.

[26] V. K. Suri, M. Elia, P. Arora, and J. van Hillegersberg, “Automation of

Knowledge-Based Shared Services and Centers of Expertise,” in Digital

Services and Platforms, Considerations for Sourcing, Global Sourcing,

Lecture Notes in Business Information Processing, J. Kotlarsky, I. Oshri,

and L. Willcocks, Eds. Springer, 2018, vol. 344.

[27] V. K. Suri, M. Elia, and J. van Hillegersberg, “Software bots - The

next frontier for shared services and functional excellence,” in Global

Sourcing of Digital Services: Micro and Macro Perspectives,Global

Sourcing, Lecture Notes in Business Information Processing, I. Oshri,

J. Kotlarsky, and L. Willcocks, Eds., vol. 306. Springer, 2017, pp.

81–94.

[28] R. Syed, S. Suriadi, M. Adams, W. Bandara, S. J. Leemans, C. Ouyang,

A. H. ter Hofstede, I. van de Weerd, M. T. Wynn, and H. A. Reijers,

“Robotic Process Automation: Contemporary Themes and Challenges,”

Comput Ind, vol. 115, 2020.

[29] J. Wewerka and M. Reichert, “Robotic process automation - a systematic

literature review and assessment framework,” Enterp Inf Sys, submitted

for publication.

[30] L. Willcocks and M. Lacity, “Robotic Process Automation: The Next

Transformation Lever for Shared Services,” Outsourcing Unit Work Pap

Ser, vol. 15, no. 7, pp. 1–35, 2015.

[31] ——, “Robotic Process Automation at Telef´

onica O2,” MIS Q Exec,

vol. 15, no. 1, pp. 21–35, 2016.

[32] W. William and L. William, “Improving Corporate Secretary Productiv-

ity using Robotic Process Automation,” Proc - 2019 Int Conf Technol

Appl Artif Intell TAAI 2019, 2019.

[33] A. Wr´

oblewska, T. Stanisławek, B. Prus-Zaja¸czkowski, and Ł. Gar-

ncarek, “Robotic Process Automation of Unstructured Data with Ma-

chine Learning,” Ann Comput Sci Inf Syst, vol. 16, pp. 9–16, 2018.

APPENDIX - QUESTIONNAIRE

In the following, the questionnaire used to survey data

before and after introducing RPA can be found.

Dear RPA Creator,

Thank you, for the time you took for the interview. I

developed a questionnaire to measure the effects that were

mentioned in the interviews and would be very happy if you

take 2 minutes and fill it out. Participation in the survey is

voluntary. The results are scientifically evaluated. If you have

any questions, I can be reached by email. If you would like to

be informed about the results, please contact me.

Thanks for your support!

Put yourself in the situation before the process was sup-

ported by RPA and please answer the following questions.

If your process did previously not exist in the current form,

please provide estimates for questions 2-4.

1. Did your process exist in the current form before the RPA

implementation?

O Yes O No

2. The process was executed times a day by all

employees. On average, an employee needed

minutes.

3. An error occurred in approximately percent

of the process executions.

4. Compliance guidelines were not complied with in around

percent of the process executions.

The RPA bot is now running and supporting the process.

Please answer the following questions.

1. The bot runs a day and takes an average of

minutes.

2. The bot is

O always available.

O not always available without any consequences

on the process.

O not always available with consequences on the

process. Consequences:

3. The bot throws an error in percent of the

process execution and manual rework is necessary.

4. Is RPA planned to be a temporary solution?

O Yes O No

Please provide a short description of your bot: