Robotic Process Automation in the Automotive
Industry - Lessons Learned from an Exploratory
Case Study
Judith Wewerka
1,2[0000−0002−4809−2480] and
Manfred Reichert1[0000−0003−2536−4153]
1Institute of Databases and Information Systems, Ulm University, Germany
{judith.wewerka,manfred.reichert}@uni-ulm.de
2Research and Development, BMW Group, Germany
Abstract. Robotic Process Automation (RPA) is the rule-based au-
tomation of business processes by software bots mimicking human in-
teractions. The aims of this paper are to provide insights into three
RPA use cases from the automotive domain as well as to derive the
main challenges to be tackled when introducing RPA in this domain. By
means of an exploratory case study, the three use cases are selected from
real RPA projects. A systematic method for analyzing the cases is ap-
plied. The results are structured along the stages of the lifecycle model
of software development. We provide information on every lifecycle stage
and discuss the respective lessons learned. In detail, we derive five chal-
lenges that should be tackled for any successful RPA implementation in
the automotive domain: (1) identifying the right process to automate,
(2) understanding the factors influencing user acceptance, (3) explaining
RPA to the users, (4) designing human bot interaction, and (5) providing
software development guidelines for RPA implementation.
Keywords: Robotic Process Automation, RPA, Exploratory Case
Study, Use Case, Automotive Industry.
1 Introduction
To stay competitive in their market, companies need to organize their business
processes in an efficient and cost-effective manner [11]. They, therefore, demand
for an increasing degree of process automation. A promising approach is pro-
vided by Robotic Process Automation (RPA), which aims to automate business
processes or parts of them by software robots (bots for short) mimicking human
interactions. Thus, an increasing number of companies have been running RPA
initiatives [2].
Scientifically, RPA has been investigated in various directions, e.g., system-
atic literature reviews [6, 17], case studies in areas like shared services [10, 22]
and telecommunications [16, 23], methods fostering RPA implementation [4, 7],
and attempts to quantify RPA effects [20]. However, there exists little research
on introducing RPA in the automotive industry. Consequently, lessons learned
2 J. Wewerka and M. Reichert
resulting from RPA application in this domain have not been extensively re-
ported in literature yet. This raises the question whether and–if yes–how RPA
projects in automotive industry can be successfully completed.
The purpose of this paper is to gain a better understanding of RPA projects.
Moreover, we want to highlight the challenges that need to be tackled to enable
a successful RPA implementation. We conduct an exploratory case study in the
automotive industry to find out what is happening, to gain novel insights into
real world projects, and to generate ideas for new research [21].
The remainder of the paper is organized as follows: Section 2 summarizes
existing RPA case studies and the lessons learned in their context. Section 3
describes the method we applied for this case study research. The results are
presented in Section 4, followed by a cross-case analysis and a systematic deriva-
tion of the challenges in automotive industry in Section 5.
2 Related Work
We summarize results from existing RPA case studies with a focus on the lessons
learned for a successful RPA implementation. To the best of our knowledge, no
case study exists that has been conducted in the automotive domain. Therefore,
we focus on giving an overview of RPA case studies in general. These lessons
learned are used in Section 5 to classify our results.
In [8], RPA in business process outsourcing is introduced with the goal to
create and validate premium advice notes. Overall, 14 processes are automated
with 120.000 cases per month resulting in cost savings of 30%. Eight lessons
learned are emphasized: (1) RPA needs a sponsor, (2) a culture of business
innovation and technology accelerates RPA adoption, (3) RPA should sit in the
business, (4) processes should be standardized and stabilized before automation,
(5) RPA must comply with enterprise architecture policies, (6) internal RPA
capability should be built, (7) bots should be multi-skilled, and (8) internal
communication is highly important for RPA projects.
The RPA journey of an energy supplier is presented in [9]. One process is au-
tomated to resolve infeasible customer meter readings. In total, 25 processes are
automated with 1 million cases per month. The lessons learned that are reported
in [8] are picked up and expanded with further aspects: the composition of the
RPA teams should evolve over time, continuous prototyping becomes necessary
to expand RPA to new business contexts, RPA should complement enterprise
information systems, and components should be reused to scale quickly and to
reduce development costs.
The RPA journey of a shared service company automating the generation of
the financial close is described in [10]. Overall, 44 processes are automated saving
45 Full Time Equivalents (FTEs). The lessons learned are to pick the right RPA
approach (i.e., to differentiate between screen automation and process automa-
tion), to redesign work prior to implementation, and to prepare the employees.
[22] presents another RPA journey in shared service highlighting sub-processes
that may be subject to RPA, e.g., copy data from an Excel sheet to a human
RPA - Exploratory Case Study 3
resource management system. Finally, [22] emphasizes that RPA benefits are
immense, but results (e.g., faster processes or FTE savings) cannot be always
guaranteed.
An RPA journey of a telecommunication company is presented in [16]. Two
processes are discussed, i.e., bundle support tools for the field service techni-
cian on one hand and proactive problem solving on the other. During the RPA
journey, 800 FTEs are saved. As lessons learned, RPA should be designed and
implemented in an agile way, RPA impact on staff members should be carefully
managed, and technical and organizational interrelations should be investigated
from the beginning. Another RPA journey in telecommunications is described in
[23]: 15 processes are automated with around 500.000 cases per month. RPA is
considered as one tool working hand in hand with process elimination, process
improvement, and other business process tools. As the two main lessons learned,
bots require more explicit instructions than humans and some risks need to be
taken to successfully introduce RPA.
How to automate the generation of a payment receipt with a business pro-
cess outsourcing provider is described in [1]. The as-is and to-be processes are
described, and it is shown how RPA increases productivity, e.g., the group using
the RPA bot could handle 21% more cases than the one without bot. Another
RPA use case in the same domain is presented in [5]–the automated processes up-
date employee payment details and create employment relationships. The lessons
learned include preparing the IT department and developing RPA capabilities,
addressing fears about losing jobs, selecting processes carefully, and measuring
process improvements.
In [3], RPA is applied to digital forensics in two use cases: keyword search on
forensic platforms and import evidence files to a forensic platform. As main lesson
learned, special forensic software cannot be properly automated with available
RPA software solutions.
The case study presented in [12] emphasizes the benefits of RPA for mastering
data management. Companies are accompanied to show the qualitative benefits
achieved with RPA, including improved data quality, reduced human errors,
increased productivity, and decreased costs. As particular lesson learned it is
mentioned to overcome the lack of understanding RPA technology.
In [24], an RPA system supporting corporate service providers is presented.
Both the as-is and the to-be processes are described, and RPA is evaluated
quantitatively. Concrete numbers to productivity improvements (over 1,000%)
are provided and managerial impacts are derived. No lessons learned are given.
Finally, [18] investigates RPA use cases in procurement to explore practical
implications and the impact on the procurement functions. The use cases are fur-
ther analyzed regarding challenges during RPA implementation, e.g., employees
fear to change their working habits, or the procurement function needs to be
mature. Details on the concrete cases are missing.
4 J. Wewerka and M. Reichert
3 Methodology
This section presents the method we applied to conduct the RPA case study in
the automotive domain. A case study in software engineering is “an empirical
enquiry that draws on multiple sources of evidence to investigate one instance
(or a small number of instances) of a contemporary software engineering phe-
nomenon within its real-life context” [14] to improve the software engineering
process and the resulting product, i.e., the RPA bot in the context of this work
[14]. We combine the methodologies presented in [14], [21], and [25] and obtain
the following method: first, the case study is designed, research questions are
derived, and use cases are selected (cf. Section 3.1). Second, the data collection
method is defined (cf. Section 3.2). Third, the data analysis method is selected
(cf. Section 3.3).
3.1 Case Study Design
Introducing RPA in the automotive domain has been little studied in the litera-
ture and, hence, concrete RPA applications, i.e., use cases, are still rare. Existing
case studies, e.g., [1], focus on the benefits, risks, and results of RPA. The aim of
the study presented in this paper is to explore RPA use cases in the automotive
industry along the software lifecycle model [13]. Furthermore, the challenges to
be tackled for each lifecycle stage are derived [4, 7]:
–The Analysis Stage focuses on understanding and analyzing the as-is process,
which is the candidate to be automated with RPA.
–The Product Design Stage defines the to-be process that shall be executed
by the bot.
–The Coding and Testing Stage implements the RPA bot according to the
design defined in the previous stage. The bot is tested to determine whether
it behaves correctly.
–The Operation Stage deploys, maintains, and operates the RPA bot. More-
over, it measures its performance.
Research Question Definition. In [20], we discovered that RPA projects
in the automotive industry do not always achieve the positive benefits promised
in the literature. Therefore, our general research question is “What challenges
are raised in each lifecycle stage?”. In detail, different aspects in each stage are
questioned to answer the general research question. For the analysis stage we
consider the following aspects: (1) How does the as-is process look like? (2) What
problems exist with the as-is process?, and (3) What are the goals of the RPA
project? The product design stage, in turn, addresses the two aspects: (1) How
does the to-be process look like? and (2) Is the process standardized, i.e., can the
number of process variants be kept small? For the coding and testing stage we
consider the following aspects: (1) How long does coding and testing of the RPA
bot take? and (2) What problems arise in this stage? Finally, the operation stage
addresses four aspects, namely: (1) When is the bot released? (2) How is the bot
RPA - Exploratory Case Study 5
communicated to the users? (3) How much time is needed for maintenance?, and
(4) What are the lessons learned in the RPA project?
Case Selection. In order to select appropriate cases to identify general
challenges of RPA implementation in the automotive domain, we consider the
following criteria [21]: availability of information, variation of cases, and repeata-
bility. In this context, it is noteworthy that one of the authors deals with the
selection of processes in RPA projects in automotive engineering. Over a period
of one and a half years, she decided in 42 cases whether or not the suggested
process should be automated with RPA (cf. Figure 1). 31 of them were rejected
as they were unsuitable for RPA (19), did not save enough FTEs (8), or for
other reasons (4). Hence, 11 processes were automated with RPA, of which two
each failed during coding and testing, respectively. Two processes are still in the
testing stage, five were successfully completed. Thereof two are retired and three
are actively used. Information was available for all 42 processes as one of the
author is part of the RPA team. To ensure the variation of cases, we want to
explore one process that failed after testing, one successfully completed, and one
being active. Finally, the repeatability criteria results in the selection of the pro-
cesses called Process 1 (Ordering), Process 2 (Construction Report Creation),
and Process 3 (Report Generation).
suggested
processes
42
rejected
processes
31
unsuitable for
RPA
19
not enough
FTEs saved
8
other reasons
4
implemented
processes
11
failed
4
during Coding
2
during Testing
2
in Testing
2
completed
5
retired
2
actively used
3
Process 1 Process 2 Process 3
Fig. 1. Processes suggested for automation with RPA.
3.2 Data Collection Method
The data is collected from primary and secondary data sources to ensure data tri-
angulation [21]. We conducted semi-structured interviews with the main actors
involved in RPA projects. Each interview lasted around one hour. The inter-
views were recorded and transcribed. The basis for the interview are the general
research question, the aspects defined above, and our observations during the
RPA projects. The interview guideline is, therefore, structured as follows:
6 J. Wewerka and M. Reichert
1. Analysis: process before automation, problems with manual process, and
RPA expectations.
2. Product Design: process standardization and process after automation.
3. Coding and Testing: duration and problems.
4. Operation: release date, communication of RPA, problems during usage,
effort for maintenance, and lessons learned.
5. Additional comments.
Secondary data originated from (1) the observations we made during pro-
cess analyses and (2) archival data (e.g., meeting minutes, technical documents,
management documents, and reports). In addition, these data were used to val-
idate the statements made during the interviews. Note that the combination of
primary and secondary data fosters internal validity of the collected data [21].
3.3 Data Analysis Method
All gathered data are analyzed in a structured way to draw conclusions [25]
and to answer our research question. First of all, the three cases are treated
separately. Problems and challenges are reported for each lifecycle stage and are
summarized as lessons learned. Afterwards a cross-case synthesis is performed to
generalize the lessons learned from the three cases [21]. The general challenges
are derived from the interview results and are presented to the participants for
confirmation. After this confirmation, we compare our challenges with findings
from the literature to classify our results in current research.
Confidentiality and privacy rules set out by the company are followed all
time.
Special attention is paid to validity and reliability of the data analysis [21].
Internal validity is achieved by analyzing data from different data sources. There-
fore, eventually biased interview data can be objectified.
4 Results
This section describes, analyses, and explains the three selected cases, i.e., Pro-
cess 1 (Ordering), Process 2 (Construction Report Creation), and Process 3
(Report Generation), separately along the aforementioned lifecycle stages [21].
4.1 Process 1 - Ordering
Analysis. Figure 2 visualizes Process 1 before RPA implementation using the
Business Process Model and Notation (BPMN). If engineers need a part, they
send the order to an employee checking for its completeness. If the order is
incomplete, the engineer is notified accordingly to provide the missing details.
Otherwise, the employee logs into the order system, copies and pastes the order
details from the e-mail into the system, saves and submits the order, and notifies
the engineer about the creation of the order. As problems of this as-is process the
RPA - Exploratory Case Study 7
system is very slow and, therefore, takes a long time to completion. Additionally,
the task is a simple copy and paste task. Hence, the management supported the
implementation of the bot to relieve the employees from this tedious task.
Human Workforce
Engineer
Engineer
Send e-mail
with order
details
Complete
order details
Engineer
creates order
Notification received Notification received
Employee
Employee
Order received
Check
completeness
of order
details Check passed
Login
order
system
Copy, paste
order details
from e-mail
into system
Save and
send order
Notify of
creation of
order
Notify of
missing order
details
order
format
No
Yes
Fig. 2. BPMN Model of Process 1 (Ordering) before RPA implementation.
Product Design. The process has not been standardized prior to RPA
implementation. For the engineer the procedure remains the same. For the em-
ployee, in turn, an additional check becomes necessary: if the received order is
suitable for the RPA bot, it is forwarded to the bot, which then performs the
subsequent process steps. Afterwards, the employee is informed, and then needs
to submit the order and notify the engineer (cf. Figure 3). If the bot fails, the
employee receives a generic error message not providing any details. Therefore,
the results from the bot are not the same as if done manually, as one cannot see
exactly what error has occurred where.
Pr
ocess 1 with RP A
Human Workforce
Employee
Employee
Order received
Check
completeness
of order
details Check passed
Notify of
missing order
details
Check
suitability for
RPA bot
Check passed
Send e-mail
to RPA bot
Notification received Login system
and send
order
Notify of
creation of
order
order
format
Login order
system
Save and
send order
Engineer
Engineer
Engineer
creates order
Send e-mail
with order
details
Notification received Complete
order details
Notification received
Robotic Workforce (bot)
Robotic Workforce (bot)
Order received
Login order
system
Copy, paste
order details
from e-mail
into system
Save order
and send
notification
No
Yes
Yes
No
Copy, paste
order details
from e-mail
into system
Fig. 3. BPMN Model of Process 1 (Ordering) after RPA implementation.
8 J. Wewerka and M. Reichert
Coding/Testing. Coding the RPA bot took the RPA developer 1.5 months,
followed by 2 months spent on testing. As major problem during coding, selectors
(i.e., attributes of a graphical user interface element to tell the bot how to interact
with the interface) did not work properly with the order system and a lot of
workarounds with keyboard shortcuts became necessary. Obtaining the necessary
access rights for the bot turned out to be difficult. The IT department did not
want a bot operating in their order system.
Operation. The operation stage started with problems, as moving the code
from integration to production did not work properly. Problems undiscovered
in the testing stage occurred, e.g., selectors no longer worked. Employees who
should test the bot did not use it after it had turned out that the process differs
from the manual one and input documents need to be generated solely for the
bot. Therefore, the users preferred staying with the manual process. The RPA
developer still spent around 1-2 hours per week for maintaining the bot. In the
end, the bot did not go live but was retired after testing due to the sketched
problems. In addition, management changed and the new management no longer
supported the project.
Lessons Learned. As the most important lesson learned from this RPA
project significantly more efforts and time need to be spent in process analysis
and documentation. The selected process should be standardized and mature.
Furthermore, the process should be precisely documented to facilitate the cod-
ing of the RPA bot. Another lesson learned concerns user acceptance: In the
given project users did not accept the bot and preferred to execute the process
manually.
4.2 Process 2 - Construction Report Creation
Analysis. Process 2 describes the generation of reports informing other engi-
neers about changed data (cf. Figure 4). After engineers have corrected construc-
tion data, they log into the reporting system to download the report with the
newly corrected data. Further, they run an Excel Macro to highlight important
data, then save the report on the filesystem, and runs another macro to com-
pare the new version with the previous one. Afterwards, they comment on the
changes and inform all concerned engineers accordingly. As a major problem of
this process, the reporting system is a legacy system. During the generation of
the report, which takes around one hour, the engineers can no longer work on
their computers and just have to wait. Additionally, the process is error-prone.
The expected savings of using RPA with this process were 2.4 FTEs. Hence,
even though management did not support the RPA project and it was clear that
the reporting system will soon change, this RPA use case was realized.
Product Design. During product design, the folder structure of the filesys-
tem was standardized. Special attention was paid to design the RPA bot to
deliver exactly the same result as if performing the process manually. This re-
sulted in the process depicted in Figure 5: The engineers correct data and log into
the reporting system. However, instead of downloading the report right away,
they assign the task to the RPA bot. The next day, they can find all prepared
RPA - Exploratory Case Study 9
Process 2
Engineer
Engineer
Start process
Correct data Login system
Download
report with
corrected data
Run Excel
Macro to
highlight
important data
Save report
on filesystem
Run Excel Macro
to compare with
previous version
of report
Explain
changes and
inform affected
engineers End process
corrected
report reports
Colleagues
Information
Fig. 4. BPMN Model of Process 2 (Construction Report Creation) before RPA imple-
mentation.
documents in the filesystem and focus on commenting and communicating the
changes. Twice a day, the RPA bot logs into the reporting system and down-
loads all assigned reports, runs the Excel Macro to highlight important data, and
saves the reports on the filesystem. On the latter, a second Excel Macro is run
to compare the new report with its previous version and to save the prepared
files on the filesystem. The two processes are decoupled, except for the report
database used by both the bot and the engineer.
Process 2 with RPA
Engineer
Engineer
Start process
Correct data Login system
Explain
changes and
inform affected
engineers End process
Store RPA
bot as proce-
ssor of report
download next day
Open
prepared files
from
filesystem
reports
Robotic Workforce (bot)
Robotic Workforce (bot)
Download all
assigned
reports
Run Excel
Macro to
highlight
important data
Save report
on filesystem
Run Excel Macro
to compare with
previous version
of report
Login system
Save
prepared files
on filesystem End process
twice per day
Reports reports
Colleagues
Information
same report
database
same report
database
Fig. 5. BPMN Model of Process 2 (Construction Report Creation) after RPA imple-
mentation.
Coding/Testing. Coding the RPA bot took the RPA developer 2 weeks,
afterwards 2 weeks were spent for testing. No major problems occurred. The bot
went live in April 2019. The reporting system was changed one year later, the
documents are now generated via server and the bot is no longer needed.
Operation. After going live, the employees who had to use the bot received
training, a detailed description of how to use the bot, and a live demonstration.
During usage of the bot, no problems occurred for users. Concerning mainte-
nance, the RPA developer spent around one hour per week.
10 J. Wewerka and M. Reichert
Lessons Learned. The most important lessons learned from this RPA case
are to ensure management support and to standardize inputs. Without support
from the management, as in the case of Process 2, it is hard to successfully
complete such a project. To ensure the support, it is important to understand
what RPA is and what can be done with this technology. According to the RPA
developer, most problems with RPA are caused by errors of the employee, e.g.,
typing errors. Therefore, he suggests only using input from IT tools and design
the human bot interaction accordingly. Overall, the RPA developer emphasizes
the huge potential for RPA in future, but wishes more support for the RPA
developers concerning guidelines and best practices of RPA implementation.
4.3 Process 3 - Report Generation
Analysis. In Process 3, reports are generated by logging into the report system
and creating the desired specifications (cf. Figure 6). Every Sunday, the engi-
neer receives an automated e-mail from the reporting system. By clicking on the
attachment, the report is generated and the engineer can save it on the filesys-
tem. As major problem of this process, the time it takes to generate the report
from the attachment is too long. For around 10 minutes the engineer cannot do
anything else than waiting for the desired report to be loaded. Therefore, the
management supported the RPA implementation of this process.
Process 3
Engineer
Engineer
Start process
Login
reporting
system
Create
specifications
for report
Receive
automated
e-mail from
system
every Sunday
Click on
attachement
to generate
report
Save report
on filesystem
End process
report
specification
rules
report
format
report
Fig. 6. BPMN Model of Process 3 (Report Generation) before RPA implementation.
Product Design. The product design stage started with standardizing the
process and, in particular, the filesystem. The engineers were asked whether a
weekly report is sufficiently up-to-date, which they agreed on, especially as the
results remain the same as for the manual process. After RPA implementation,
the process works as follows (cf. Figure 7): the engineers log into the system,
specify the reports they need, and configure the e-mail client such that the
bot receives the automated e-mails from the system. For this purpose, every
Sunday the bot receives these e-mails, clicks on the attachments, and generates
the report. Afterwards, an Excel Macro is executed for comparing the current
reports with the one-week old ones and the reports are saved on the filesystem.
Consequently, the engineers can always find a weekly up-to-date report on the
filesystem. The two workforces work decoupled from one another. However, the
RPA - Exploratory Case Study 11
report is shared among them. If engineers need it, they load it from the filesystem
where the bot has saved the report before.
Process 3 with RPA
Human Workforce
Engineer
Engineer
Start process
Login
reporting
system
Specify
reports and
e-mail
configuration End process
report
specification
rules
report
format
Robotic Workforce (bot)
Robotic Workforce (bot)
Receive
automated
e-mail from
system
Click on
attachment to
generate
report
Run Excel
Macro for
comparison
Store report
on filesystem
End process
every Sunday
Fig. 7. BPMN Model of Process 3 (Report Generation) after RPA implementation.
Coding/Testing. After two months, the bot was coded and tested by the
RPA developer. During this period, no problems occurred. Especially, the bot
only required reading access rights for the report system and writing access to
the filesystem managed by the department.
Operation. The bot has been live since May 2019 and will be outdated in
about 2 years when a new reporting system will be built. Despite the maintenance
effort of 2 hours per week, the bot is a great success.
Lessons Learned. Again, the lesson learned in this case is to use standard-
ized input, ideally provided by an IT tool, and to design the human bot inter-
action accordingly. The developer believes that he has implemented the most
appropriate process for RPA. Subsequently proposed processes were not suited
for an automation using RPA. Therefore, it is challenging to identify the right
process to automate. In general, RPA is difficult to understand for colleagues
believing in the automation of everything. The department is quite disillusioned
and has no ideas what else could be automated by RPA. Additionally, the de-
veloper adds that RPA can still be optimized for maintenance, e.g., to receive
information about the bot via e-mail. Finally, the bot developer wishes support
in terms of guidelines for RPA development.
5 Cross-Case Analysis and Derivation of Challenges
This section discusses the results of all three cases along the bot lifecycle and
elaborates on the main challenges of applying RPA in the automotive domain.
12 J. Wewerka and M. Reichert
These challenges are compared with the ones reported in RPA literature (cf.
Section 2). Finally, threats to validity and limitations of the study are discussed.
5.1 Cross-Case Analysis
Analysis. In the analysis stage, the as-is process is analyzed, problems are
detected, and goals of the RPA project are recorded. Compared to Processes
2 and 3, Process 1 is rather complex before RPA automation. Processes 2 and
3 are sequential processes without decision points and only one involved actor.
All processes shall be automated to save time, which the respective actor would
otherwise spend on waiting for the output of different systems. Management
support is provided for Processes 1 and 3, whereas this is not the case for Process
2.
Product Design. During this stage the to-be process is designed and stan-
dardized as far as possible. While standardization is possible for Processes 2 and
3, Process 1 cannot be standardized. For Process 1, the to-be process is more
complex than the as-is process as an additional check becomes necessary. Still,
the results of using the bot differ from the ones of the manual process and are
less understandable for the employee. The other two processes require less work
than before and the robotic workforce is decoupled from the one of humans. For
Processes 2 and 3, special attention is paid to ensure that the results of the bot
and the manual process are the same.
Coding/Testing. The coding and testing stage is analyzed with respect
to the problems and efforts. Coding and testing are accomplished the fastest
for Process 2, after one month the bot is ready and no major issues arise. The
implementation of process 3 takes two months with no major problems. Finally,
coding and testing of Process 1 takes 3.5 months. Two problems hinder a faster
implementation: the selectors do not work properly in the system and getting
the access rights granted for the bot is difficult.
Operation. In the operation stage, ongoing maintenance efforts as well as
lessons learned are documented. For all three projects maintenance efforts are
around 1-2 hours per week.
Lessons Learned. Lessons learned for the three use cases are:
1. Identify the right process to automate and spend sufficient time and efforts
into process analysis and documentation. (Processes 1 and 3)
2. Understand the factors influencing user acceptance of RPA. (Process 1)
3. Explain RPA and the benefits of this technology. (Processes 2 and 3)
4. Properly design the interaction between human and RPA bot. (Processes 2
and 3)
5. Provide software development guidelines for RPA. (Processes 2 and 3)
Table 1 summarizes our main findings and compares the three cases.
5.2 Derivation of Challenges
The five lessons learned are compared with findings from literature. Further, we
highlight future research possibilities to overcome the challenges.
RPA - Exploratory Case Study 13
Table 1. Overview of the three use cases.
Lifecycle
stage Aspect Process 1 Process 2 Process 3
Analysis As-is process complex, decision
points, multiple ac-
tors involved
linear, one actor in-
volved linear, one actor in-
volved
Reason for au-
tomation time savings time savings, error
reductions time savings
Management
support yes no yes
Product
Design
Standard-
ization no yes yes
To-be process additional check,
more complex less work less work
Human-Bot-
Interaction
interaction via e-
mail and user input
user assigns task to
bot, gets result the
next day
specify once the re-
port and receive
it up-to-date every
week
Manual vs.
Bot Result different same same
Coding/
Testing
Time effort 3.5 months 1 month 2 months
Problems with selectors and
access right for bot no no
Opera-
tion Maintenance
effort 1-2h/week 1h/week 2h/week
Lessons
Learned identify the right
processes to auto-
mate, understand
factors influencing
user acceptance
design the human
bot interaction,
explain RPA and
its merits, provide
software develop-
ment guidelines
design the human
bot interaction,
explain RPA and
its merits, provide
software develop-
ment guidelines,
identify the right
process to auto-
mate,
Evaluation failed before go-
live, money and
FTEs spent
2.4 FTEs saved, 13
months of usage 1.2 FTEs saved,
used for 15 months,
will be used for 2
years
The challenge to identify the right processes for automation is ad-
dressed in [5, 8, 10]. [5] emphasizes that the processes need to be carefully se-
lected and recommends the choice of rule-based processes, which usually require
a lot of time and resources. [8] suggests selecting standardized and stabilized
processes as candidates for RPA. [10] points out that RPA is one process au-
tomation approach among others (e.g., screen scraping) and, therefore, processes
for RPA need to be chosen with care. However, to the best of our knowledge,
there is no comprehensive overview of existing process selection methods. Apart
from an overview of these methods, an assessment regarding applicability in
the automotive domain is desirable. Future research should, therefore, focus on
providing an overview and assessment of process selection methods for RPA.
The challenge to understand the factors influencing RPA user ac-
ceptance is covered partly in [5, 8, 18]. [5] suggests addressing concerns about
job losses early on such that the employees are more comfortable using the
14 J. Wewerka and M. Reichert
software bots. Similarly, [18] encounters the challenge of convincing employees
to change their work habit. [8] indicates that a culture of business innovation
and technology fosters RPA adoption. Nonetheless, these are only some aspects,
which probably influence user acceptance of RPA. A more general approach that
covers the variety of factors influencing RPA user acceptance needs to be devel-
oped. Based on the identified factors, further RPA software improvements can
be achieved.
How to explain RPA and its merits is discussed in [10, 12, 16]. [10] sug-
gests preparing the employees accordingly, whereas [16] emphasizes the need to
manage the impact of RPA carefully. In any case, a transparent communication
with the concerned employees becomes necessary from the beginning. In [12],
the same challenge is discussed, namely, the lack of RPA understanding, with
the recommendation to provide background knowledge to the employees. Future
work should, therefore, provide new ways of explaining RPA to employees. To
the best of our knowledge, there are no sophisticated communication concepts
for explaining RPA and its advantages to the concerned employees. Special at-
tention needs to be paid to adapt these concepts to highly skilled engineers.
The challenge to design the interactions between the employee and
the bot could be linked to user acceptance, e.g., the interactions should be
designed in a way such that the change of work habit becomes minimal [18].
[23] states that robots need more explicit instructions than humans. This is one
aspect to be considered in the interaction design. However, many more aspects
should be considered to provide guidance for a good user interface design in
RPA. Future work should develop an evaluation model to assess the interac-
tion between employee and RPA bot. The results could then be used to derive
recommendations for the user interface design resolving the discovered challenge.
Finally, the challenge of how to implement RPA solutions has been tack-
led by only few works. [9] states that components should be reused to enable
faster bot implementation, [16] emphasizes the need for an agile RPA devel-
opment. Details, models or recommendation for an RPA development consti-
tute another aspect of future work. Finally, the software development guidelines
should be tailored to the requirements of an engineer as well.
In a nutshell, the challenges we discovered in the automotive domain have
been at least partly addressed in the literature that deals with RPA implemen-
tations in other domains.
5.3 Threats to Validity and Limitations
With the presented exploratory case study, we gathered experiences with RPA
projects in a real environment. However, there are several threats to validity and
limitations of our research.
As a first limitation, the case study is solely conducted in one domain, i.e.,
automotive engineering, covering three different projects. Nevertheless, we be-
lieve that the obtained results are generalizable to other domains and projects
for the following two reasons: 1) In the literature, we can find RPA case studies in
different areas deriving similar challenges and 2) we have insights into additional
RPA - Exploratory Case Study 15
RPA projects from the automotive industry (cf. Figure 1), which confirm this.
Unfortunately, we cannot provide more information on these additional studies
due to confidentiality reasons. To ensure external validity and confirm the gen-
eralization of our results, new case studies in other domains and companies need
to be conducted as well.
Second, one may argue that the discovered challenges are not RPA-specific,
but might be observed in other software projects as well. We briefly sketch dif-
ferences between RPA and traditional software projects [15]: The goal of RPA
is to create bots that run independently and human only hand over the task.
Contrariwise, traditional software is designed to support the human in execut-
ing tasks. Further, RPA bots are mostly implemented by domain experts [22],
whereas the implementation of traditional software is done by software engi-
neers from the IT department. Therefore, RPA projects have to be addressed in
another way than traditional software projects.
6 Summary and Outlook
The presented exploratory case study provides insights into concrete RPA
projects from the automotive industry. The discovered challenges, i.e., to identify
the appropriate processes for RPA, to understand the factors influencing user
acceptance, to explain RPA to employees, to design human bot interaction, and
to provide RPA software development guidelines, will be further addressed by
us to ensure a successful application of RPA in practice.
To be more precise, we are working on a framework addressing these chal-
lenges holistically. For example, the challenge to understand the factors influ-
encing user acceptance is addressed in [19], which develops a model for assessing
RPA user acceptance as well as the factors influencing it. These factors are
used to derive recommendations for designing and implementing RPA bots with
increased user acceptance among employees using the bots in their daily work.
Further case studies and studies are necessary to enhance these results, con-
firm findings, and ensure external validity. The same case study method should
be used by further research to discuss RPA use cases and to generate comparable
results.
References
1. Aguirre, S., Rodriguez, A.: Automation of a Business Process Using Robotic Pro-
cess Automation (RPA): A Case Study. In: Workshop on Eng Appl. pp. 65–71.
Springer (2017)
2. Asatiani, A., Penttinen, E.: Turning robotic process automation into commercial
success - Case OpusCapita. J Inf Technol Teach Cases 6(2), 67–74 (2016)
3. Asquith, A., Horsman, G.: Let the robots do it! - Taking a look at Robotic Pro-
cess Automation and its potential application in digital forensics. Forensic Sci Int
Reports 1(2019)
16 J. Wewerka and M. Reichert
4. Chac´on-Montero, J., Jim´enez-Ram´ırez, A., Enr´ıquez, J.G.: Towards a Method for
Automated Testing in Robotic Process Automation Projects. In: 14th Int Work-
shop on Automation Softw Test. pp. 42–47. IEEE Press (2019)
5. Hallikainen, P., Bekkhus, R., Pan, S.L.: How OpusCapita Used Internal RPA Ca-
pabilities to Offer Services to Clients. MIS Q Exec 17(1), 41–52 (2018)
6. Ivanˇci´c, L., Vugec, D.S., Vukˇsi´c, V.B.: Robotic Process Automation : Systematic
Literature Review. In: Int Conf Bus Process Manag, vol. 361, pp. 280–295 (2019)
7. Jim´enez-Ram´ırez, A., Chac´on-Montero, J., Wojdynsky, T., Gonz´alez Enr´ıquez, J.:
Automated testing in robotic process automation projects. J Softw Evol Process
pp. 1–11 (2020)
8. Lacity, M., Willcocks, L., Craig, A.: Robotic Process Automation at Xchanging.
Outsourcing Unit Work Res Pap Ser 15(3), 1–26 (2015)
9. Lacity, M., Willcocks, L., Craig, A.: Robotic Process Automation: Mature Capa-
bilities in the Energy Sector. Outsourcing Unit Work Pap Ser pp. 1–19 (2015)
10. Lacity, M., Willcocks, L., Craig, A.: Robotizing Global Financial Shared Services
at Royal DSM. Outsourcing Unit Work Res Pap Ser 16(2), 1–26 (2016)
11. Lohrmann, M., Reichert, M.: Effective application of process improvement patterns
to business processes. Softw & Systs Model 15(2), 353–375 (2016)
12. Radke, A.M., Dang, M.T., Tan, A.: Using Robotic Process Automation (RPA) to
enhance item master data maintenance process. LogForum 16(1), 129–140 (2020)
13. Royce, W.W.: Managing the development of large software systems: concepts and
techniques. In: 9th Int Conf Softw Eng. pp. 328–338 (1987)
14. Runeson, P., H¨ost, M., Rainer, A., Regnell, B.: Case Study Research in Software
Engineering: Guidelines and Examples (2012)
15. Rutschi, C., Dibbern, J.: Towards a framework of implementing software robots:
Transforming Human-executed Routines into Machines. Data Base Adv Inform
Syst 51(1), 104–128 (2020)
16. Schmitz, M., Dietze, C., Czarnecki, C.: Enabling digital transformation through
robotic process automation at Deutsche Telekom. In: Urbach, N., R¨oglinger, M.
(eds.) Digitalization Cases, Management for Professionals, pp. 15–33 (2019)
17. Syed, R., Suriadi, S., Adams, M., Bandara, W., Leemans, S.J., Ouyang, C., ter
Hofstede, A.H., van de Weerd, I., Wynn, M.T., Reijers, H.A.: Robotic Process
Automation: Contemporary Themes and Challenges. Comput Ind 115 (2020)
18. Viale, L., Zouari, D.: Impact of digitalization on procurement: the case of robotic
process automation. Supply Chain Forum An Int J pp. 1–11 (2020)
19. Wewerka, J., Dax, S., Reichert, M.: A User Acceptance Model for Robotic Process
Automation. In: IEEE Int Ent Dist Obj Comp Conf (2020)
20. Wewerka, J., Reichert, M.: Towards Quantifying the Effects of Robotic Process
Automation. In: IEEE Int Ent Dist Obj Comp Conf Workshop on Front Process
Aware Sys (2020)
21. Wieringa, R.J.: Design science methodology for information systems and software
engineering. Springer (2014)
22. Willcocks, L., Lacity, M.: Robotic Process Automation: The Next Transformation
Lever for Shared Services. Outsourcing Unit Work Res Pap Ser 15(7), 1–35 (2015)
23. Willcocks, L., Lacity, M.: Robotic Process Automation at Telef´onica O2. MIS Q
Exec 15(1), 21–35 (2016)
24. William, W., William, L.: Improving Corporate Secretary Productivity using
Robotic Process Automation. In: Int Conf Technol Appl Artif Intell. pp. 1–5 (2019)
25. Yin, R.K., et al.: Case Study Research: Design and methods (2003)
