Unlocking the untapped potential of
Robotic Process Automation:
Assessing the applicability of Software Robots to
Knowledge-intensive Business Processes
J.A. Smits
1
(11880643), j.a.smits@student.vu.nl
1
MSc. Information Studies: Business Information Systems
Faculty of Science, University of Amsterdam
Supervisor: dr. H. Leopold, Department of Computer Science, VU Amsterdam
Examiner: prof. dr. T.M. van Engers, University of Amsterdam
Company supervisors: M. Jungbluth
2
(Sr. Manager), A. Baars
2
(Sr. Consultant)
2
Deloitte Netherlands, Technology Consulting, Enterprise Architecture
August 30, 2018
Abstract.
Businesses today face digitalization, demand for more customer-centric
pro-cesses, and cost and efficiency pressures. To stay competitive, organizations are looking
into Robotic Process Automation (RPA), as it serves as an inexpensive enabler for digital
transformation and is able to reduce costs and increase efficiency. Additionally, companies
shifted their focus towards knowledge-intensive business processes (KiBPs), as these
processes have a major impact on business value and offer a source for competitive
differentiation. However, improving KiBPs remains a fundamental issue for organizations.
Numerous business process improvement methods have been applied in vain. This gap in
research will be addressed in this study. So far, RPA has only been utilized to a limited
extent, while the real potential of RPA lies in its ability to support the more complex
processes, such as KiBPs. Through a task-based approach, this research investigates the
extent to which RPA can be leveraged to improve KiBPs. The contribution of this study
is threefold. Based on a meta-analysis of 121 case studies, it offers new insights on the
current deployment and utilization of RPA, issues that drive RPA adoption, objectives
set before and impact realized after an RPA project. Moreover, it provides a taxonomy
of types of tasks and allocates these to either a knowledge worker or robot along with
pointers to identify them. Lastly, as effective identification of suitable RPA candidate tasks
is a considerable challenge, it proposes a framework, derived from literature as well as
21 expert interviews, to structure this search. As research on RPA is scarce and its impact
on organizational performance is extensive this study is seen as relevant. It is valuable
for academics and practitioners alike as it provides theoretical ground to expand on and
offer organizations a structured operational approach to determine the extent to which
RPA can be leveraged to improve KiBPs.
Keywords.
Digitalization, Digital Transformation, Knowledge-intensive Business Processes,
Knowl-edge Work, Lightweight IT, Robotic Process Automation, Software Robots, Virtual Workforce.
1
Introduction
Businesses are increasingly affected by new technological innovations (Seethamraju &
Marjanovic, 2009) and growing customer and market demands. The ongoing digitalization,
one of the main challenges, (Stople et al., 2017), has led to an increasing need for companies
to become more digital (Leopold, van der Aa, & Reijers, 2018). As the integration of
digital technologies affects multiple aspects of a business (Legner et al., 2017), such as
IT architectures, organizational structures and business processes (BPs), it “changes the
way organizations operate dramatically” (Kirchmer, 2017, p.1). It requires companies to
undergo a digital transformation (Matt et al., 2015; Lacity & Willcocks, 2016c). Moreover,
the demand for customer-centric BPs is growing (Mansveld et al., 2016) and there is immense
pressure to lower costs, improve efficiency, and provide exceptional service (Işik et al., 2013).
These increasing customer and market demands are the result of the ever strengthening
competition (Işik et al., 2012). In response, businesses have been looking for new ways to
create opportunities for competitive differentiation, such as (1) Robotic Process Automation
(RPA), as it serves as an inexpensive enabler for digital transformation (Kirchmer, 2017)
and offers promising results for business process improvement (BPI) by increasing efficiency
while reducing costs (Cewe et al., 2018). Concurrently, organizations shifted their focus
from the traditional transactional BPs, towards (2) knowledge work (KW) (Drucker, 1959) as
this higher-order, value-adding work cannot be easily imitated (Marjanovic & Seethamraju,
2008; Işik et al., 2012).
The interest in KW is growing rapidly (Auer et al., 2016) as organizations recognize its
significant importance (Işik et al., 2012; Scheithauer & Hellmann, 2013). This increased
the focus on the role of creativity and expert knowledge in BPs (Işik et al., 2013) and
demanded a higher degree of complexity (Slembek, 2003; Marjanovic, 2005), flexibility
and adaptability (Auer et al., 2016) of them. As these BPs comprise a major KW component,
they are considered knowledge-intensive business processes (KiBPs). Due to the important
role of knowledge workers (Davenport, 2005) and the major impact they have on business
value, the need to deal with KiBPs has become a leading research topic in the BPM domain
(Işik et al., 2013; Di Ciccio et al., 2015). Currently, KiBPs are the most important BPs for
organizations (Işik et al., 2013) as they offer a sustainable competitive advantage (Marjanovic
& Freeze, 2012). Estimates show that, nowadays, knowledge workers represent almost 40%
of the workforce (Motahari-Nezhad & Swenson, 2013).
Nevertheless, KiBPs have not been the focus of systematic BPI initiatives (White, 2009).
Some authors focused on examining the notion of KiBPs (Işik et al., 2012; Di Ciccio et al.,
2012, 2015), knowledge-intensity (Marjanovic & Seethamraju, 2008) or knowledge workers
(Davenport, 2005). Others have studied knowledge-based improvements (Dalmaris et al.,
2007; Eppler et al., 2008) or modeling languages (Gronau & Weber, 2004). Moreover, there
is extensive research on the integration of knowledge management practices (Kulkarni &
Ipe, 2010; Sarnikar & Deokar, 2010; Marjanovic & Freeze, 2012) and on supporting KiBPs
through Adaptive Case Management (Swenson & Palmer, 2010; Swenson, 2011; Herrmann
& Kurz, 2011). However, literature about improving KiBPs is very limited (Manfreda et al.,
2015). This gap in research will be addressed in this study as recent discussions show there
is a pressing need for solutions to improve KiBPs (Marjanovic & Freeze, 2011, 2012; Işik
et al., 2013; ter Hofstede et al., 2015). Marjanovic and Freeze (2012) stress that further
research is required to help organizations with the improvement of KiBPs whereas Işik et al.
(2013, p.582) hope their work encourages researches “to dig deeper into the dynamics of
KiBPs” to find solutions for improvement.
The thesis proceeds as follows. The next section illustrates the problem being addressed
in this thesis. Section 3 discusses the aforementioned concepts by means of literature review.
This is followed by the research design, next are the findings, finishing with the discussion,
conclusions and future research.
2
Problem Statement
To make sense of the research problem, causal mapping (Ackermann & Eden, 2010) has
been used to structure the problematic situation and reveal the “nub of the issue”
1
. The
underlying cause to the research problem turns out to be the fundamentally different nature
of KiBPs (Kemsley, 2011). Therefore, KiBPs should be improved differently (Dalmaris et al.,
2007; Seethamraju & Marjanovic, 2009; Marjanovic & Freeze, 2011, 2012). Işik et al.
(2013) found that despite these differences, organizations apply the same traditional BPI
techniques (e.g. Lean, Six Sigma) to improve their KiBPs and they are struggling as these
methods are proven to be ineffective and unsuitable.
Meanwhile, the time that knowledge workers actually spend performing
knowledge-intensive tasks that require capabilities such as creativity and emotional intelligence is
minimal (Lacity & Willcocks, 2015; Chui et al., 2015). Due to the inability of traditional
IT systems to complete BPs end-to-end, knowledge workers currently spend a substantial
amount of time dealing with systemantics (Lacity & Willcocks, 2015), a form of motion
waste, which arises when the knowledge worker has to switch between applications during
the performance of a task (Dumas et al., 2018b). Knowledge workers have to perform
repetitive, data-intensive tasks manually, such as extracting and merging data, or
copy-pasting information from one system to another (Aguirre & Rodriguez, 2017), which hinders
them from delivering business value. There is a high demand from knowledge workers to
be liberated from these mundane tasks (Lacity & Willcocks, 2015). Fortunately, these tasks
are ideal candidates to be handled by RPA, so knowledge workers have more time to focus
on higher-order, value added tasks (Leopold et al., 2018).
Even though RPA has been deployed within various organizations, research is very
limited. Apart from case studies verifying the proclaimed benefits (Aguirre & Rodriguez,
2017), investigating its effect on the IT function (Willcocks et al., 2015b) or its utilization in
Global Business Services (Willcocks et al., 2017) and Shared Services (Lacity & Willcocks,
2016c; Suri et al., 2017), insights on how multiple organizations within different sectors
have utilized and deployed RPA, are missing. Therefore, the first research goal is to: (1)
create a mapping of the as-is situation of RPA with regards to deployment and utilization. So far,
RPA has been utilized to a limited extent, as it is mostly targeted at simple, standardized BPs
(Barnett, 2015), without any customer involvement (Aguirre & Rodriguez, 2017). Multiple
authors (Barnett, 2015; Hill, 2016; Penttinen et al., 2018) claim that the real potential of
RPA lies in its ability to support the more complex BPs, traditionally the domain of knowledge
workers. This untapped potential could offer a solution to the research problem at hand.
However, as KiBPs cannot be handled without human participation (Scheithauer &
Hellmann, 2013), end-to-end automation is not possible. So, one could argue that due to
the different nature of KiBPs, RPA is not an applicable solution. This research will challenge
that point of view, as KiBPs are not monolithic entities (Davenport et al., 1996). Besides
the unstructured, creative and knowledge related aspects, more often than not, KiBPs also
consist of recurring, predefined tasks (Huber et al., 2013; Hauder et al., 2014; Kemsley,
2015; Auer et al., 2016), which might be suitable for automation. This is acknowledged by
Işik et al. (2013), as they conclude that certain parts of KiBPs are eligible for automation,
while other parts depend entirely on human knowledge and execution. So, looking at a BP
as a whole for automation is too coarse-grained (Koorn, Leopold, & Reijers, 2018) and a
focus on task-level is recommended (Chui et al., 2015; Arntz et al., 2016). Therefore, a
task-based approach (Aarons et al., 2006) is proposed to be able to decompose KiBPs and
determine the extent to which RPA can be leveraged. The suggested solution refers to an
interplay between human and robot, each performing tasks for which they are suited best
(Lacity & Willcocks, 2016a; vom Brocke et al., 2018). However, this rises the question,
“what should be done by humans and what should be automated?” (van der Aalst et al.,
2018). Accordingly, the second goal is to: (2) derive a taxonomy of types of tasks, allocate
these to either a software robot or knowledge worker and offer pointers to identify them.
While knowing the types of tasks that are eligible for RPA, it is still a considerable challenge
to effectively identify suitable candidate tasks (Leopold et al., 2018). Consequently, targeting
the wrong candidate is found to be the root cause of most failed RPA projects (Lamberton
et al., 2017; Rutaganda et al., 2017). Therefore, the third research goal is to: (3) structure
the search for suitable RPA candidates by designing a framework that provides guidance in such
an assessment, as structured procedures are a helpful instrument to support organizations
in addressing such a challenge (Zellner, 2013).
This thesis is structured by two parts consisting of three sub-questions [Table 1]. By
answering the sub-questions, this study will meet the aforementioned research goals and
address the main research question, which is formulated as follows: “To what extent can
RPA
2
be leveraged in order to improve KiBPs?”.
Part
Sub-question
A
What is the as-is situation with regards to the deployment and utilization of RPA within organizations?
B
What is the applicability of RPA to KiBPs?
B
How can the suitability of tasks in relation to the potential of RPA be assessed in a structured way?
Table 1:
Overview of the sub-questions, which each consist of multiple implicitly answered questions [Fig. 13, Appx. A.1],
which are related to the relevant concepts as shown in Fig. 14, Appx. A.2.
3
Theoretical Background
As the research problem cannot be meaningfully examined in reference to only one theory
or concept, the existing views in literature have been synthesized (Jabareen, 2009; Imenda,
2014) into a conceptual framework [Fig. 1] to provide a comprehensive understanding of
the phenomena within the scope of this research. Two major streams of research are related
to this thesis: (1) knowledge-intensive business processes (KiBPs) and (2) Robotic Process
Automation (RPA). These concepts together form the theoretical base of this research. In the
upcoming subsections both concepts will be explained as well as their relations to others.
Figure 1:
The conceptual framework underlying this research, constructed in UML (OMG, 2015). Extended from: Dumas et al.
(2013a, p.6). The concepts in bold represent the core of this thesis. An enlarged version can be found in Fig. 18, Appx. B.3.
2
This study focuses specifically on RPA, as this technology is maturing, whereas more advanced solutions, such
3.1 Business processes
Organizations perform BPs to deliver a product or a service to its customers. Dumas et al.
(2013a, p.1) define a BP as “a chain of events, activities and decisions” that ultimately add
value to the organization and its customers. These activities are performed in coordination
to realize a certain business goal (Weske, 2012b, p.5). There are different types of BPs and
they can be classified along different dimensions.
BPs can be categorized according to their degree of structuring (Weske, 2012b; Di Ciccio
et al., 2015). Highly structured BPs, such as (1) administrative BPs and (2) production
work-flows, reflect predictable routine work with low flexibility and controlled interactions among
process participants. All outcomes and decisions are defined a priori. Programmed BPs such
as (3) Straight Through Processing do not require any human involvement. Structured work
with ad hoc exceptions is similar, but includes external events and exceptions. In many BPs,
(e.g. insurance claim handling) work is rather unstructured, but with predefined segments and
proceed on an ad hoc basis. For these (4) ad hoc BPs, a process model is not defined, but
there are structured parts (e.g. explicit actions, specified templates or guidelines). Loosely
structured BPs are not subject to any prescriptive procedures, but policies and business rules
implicitly frame the BP. A set of possible tasks may be predefined, but their execution order
is not known. These (5) collaborative BPs rely heavily on the collaboration between the
process participants. Unstructured BPs are unpredictable and highly flexible, only their goal
is known. In these (6) truly unique cases, knowledge workers, rely on their experience and
the BP emerges as they decide on the tasks to be executed as well as their order.
The degree of repetition (Weske, 2012b) follows more or less from the degree of
structur-ing, (i.e. if a process is highly structured it is often very repetitive, whereas an unstructured
process is likely to be unrepeatable). Moreover, the focus of a BP can be either human-centric
or system-centric (Georgakopoulos et al., 1995), which is related to another important
dimen-sion: the knowledge involved, a continuum between explicit and tacit knowledge (Marjanovic
& Seethamraju, 2008). Explicit knowledge prescribes how tasks should be executed and
defines the roles and responsibilities and can be documented (e.g. work instructions,
proce-dures and policies), whereas tacit knowledge, such as know-how or experience, is usually
not documented anywhere. It is very difficult to communicate but could be externalized
into practices. Combining these four dimensions leads to the following model [Fig. 2].
Figure 2:
This model indicates the types of BPs according to their focus, the degree of repetition, structuring and the knowledge
that is involved. It is only conceptual and is intended to serve as a general visual overview. In this model the core concepts of this
thesis will be positioned [Fig. 20]. An enlarged version is shown in Fig. 19, which can be found in Appx. C.1.
3.1.1 Knowledge-intensive business processes
To better support knowledge workers, BPs can be defined less rigidly, so that tasks can be
executed in any order or repeatedly until the goal is met. These type of BPs, also KiBPs,
are characterized by high levels of complexity, the occurrence of unexpected events (Unger,
Leopold, & Mendling, 2015) and depend largely on human involvement for decision-making
(Işik et al., 2012). The knowledge worker has to deal with a high degree of uncertainty,
as the order of the tasks they need to perform may be highly variable (ter Hofstede et
al., 2015). To address this uncertainty, a goal is defined to align activities and resources
accordingly (Panian, 2011). The most important discriminator
3
in determining if a BP is
knowledge-intensive or not, is the knowledge-prevalence, it refers to the extensive knowledge
required and number knowledge sources consulted during execution. Other important
discriminators are the required collaboration and creativity, goal-orientation, data-centricity,
adaptability, and process as well as decision-making complexity. For predictability, eligibility
for automation, structuredness and repeatability, no clear discretionary power was found (Işik
et al., 2013). Moreover, Marjanovic (2005) shows that there are BPs which are very-well
structured, routine, and knowledge-intensive at the same time. So, these discriminators
are not suitable to differentiate between KiBPs and non-KiBPs. In conclusion, although the
knowledge-intensity of a BP generally increases along the degree of structuring, almost all
the types of BPs discussed above may include elements that make them knowledge-intensive
(Di Ciccio et al., 2015). KiBPs are positioned in the BP model accordingly [Fig. 5].
Interpretation / Judgement
Integrative
Collaborative
L evel of in te rdepen den ce Complexity of workTransactional
Expert
Routine Collaborative groups Individual actors Information-intensive Knowledge-intensiveFigure 3:
Classification structure for KiBPs
(Dav-enport, 2015), with a split to information-intensive
BPs (Megill, 2013).
As this research proposes a task-based approach,
KiBPs need to be decomposed. A first step is to
clas-sify them according to a validated structure
(Dav-enport, 2015; Margaryan et al., 2011). This
ma-trix [Fig. 3], based on the degree of expertise and
the level of coordination in work, indicates four
dif-ferent types of KiBPs and has similarities to the BP
model in [Fig. 2]. Transactional work, is structured,
routine and reliant on formal rules and procedures
whereas collaborative work is more improvisational
and reliant on deep expertise across multiple
func-tions and teams. Integrative work is fairly structured,
systematic and repeatable, although higher levels of
collaboration often lead to more process complexity.
Lastly, expert work is more judgment-oriented and reliant on individual expertise and
ex-perience. More recent, Megill (2013) argues that transactional and integrative work is
rather information-intensive whereas expert and collaborative work is considered
knowledge-intensive. Looking at ends of the knowledge dimension, Marjanovic and Seethamraju (2008)
identified at the left, operational BPs, which are highly repetitive, reliant on procedures
(explicit knowledge), and often supported by Workflow Management Systems (WfMSs).
At the right, there are practice-oriented BPs, highly knowledge-intensive, dependant on
experiential knowledge, collaboration and problem solving activities, and best supported
by groupware systems. In between, there is case handling [Fig. 20], an approach that
supports knowledge workers by taking into account their expertise and experience to drive
and control the case (Reijers et al., 2003; van der Aalst et al., 2005). Typically, there is
one customer-facing officer in charge of each case (Weske, 2012a, p.362) and policies are
used to help the knowledge worker stay within predefined boundaries, whereas practices
develop while they handle the non-standard cases. More recent, case handling is referred
to as Dynamic (Le Clair & Moore, 2009) or Adaptive Case Management (ACM) (Hauder
et al., 2014). WfMSs are very restrictive, as they prescribe the activities and their execution
ordering, there is little room for knowledge workers to deviate, therefore, KiBPs are often
supported by ACM systems (Pillaerds & Eshuis, 2017). ACM systems coordinate the work
3
For example, “required creativity” instead of “needs a lot of creativity”. A complete overview of all discriminators
needed to handle a case in a flexible manner by organizing all of the relevant information
into one place and allows for unexpected changes (Motahari-Nezhad & Swenson, 2013).
3.2 Business process automation
To improve BPs, organizations can either follow the principles of Business Process
Re-engineering (BPR) or BPI. BPR is a radical reorganization of the process whereas BPI aims
at a continuous and incremental improvement (Zellner, 2011). Richter-von Hagen et al.
(2005) argue that it is not possible to reorganize KiBPs in such a radical way as often the
improvement has to be realized in an environment where the BPs are still being executed.
As incremental improvement for KiBPs is recommended (Davenport, 2015; Manfreda et al.,
2015), the suggested solution aims to realize improvement trough BPI by means of BPA.
Apart from the automation of human labor, BPA can be realized through either heavyweight
IT, which are proven technologies (e.g. back-end system automation) developed through
software engineering by IT professionals, or lightweight IT, which is driven by business users’
need for quick solutions and enabled by new digital technologies such as RPA (Bygstad,
2017; Stople et al., 2017; Penttinen et al., 2018). To realize BPA, organizations can, extend
the current IT system (e.g. create new features through software development), purchase a
BPM solution with BPA extension or buy a middleware solution. In contrast, they can acquire
a special purpose tool such as RPA (Mohapatra, 2009).
3.2.1 Robotic Process Automation
C
as
e fr
equ
en
cy
(# o f sim ila r cases) RPA candidates requires human capabilities traditional BPADifferent case types
(sorted by frequency)Figure 4:
The long tail of work indicating the
poten-tial RPA candidates. Adapted from: van der Aalst et
al. (2018).
RPA is an inexpensive software-based solution, and
differs from traditional IT solutions in various ways
4
.
The most important aspects are its short time to
imple-ment, its easiness to configure and the quick return
on investment. As the robot mimics the human
inter-action with IT systems, it is able to move the mouse,
replicate keystrokes and navigate within an UI by
following conditional logic. Other capabilities are
re-lated to data handling and processing (e.g. accessing,
gathering, migrating, analyzing, validating,
manip-ulating, and updating data across multiple systems).
RPA is not a part of the organization’s IT
infrastruc-ture, but rather sits on top of it. As it operates via the
presentation layer, no underlying systems
program-ming logic is touched. So, it provides a non-invasive way for integration with limited to no
change to the IT landscape and BPs. Due to its modular design, and versatility, robots are
easily modifiable, components can be easily reused and the robot switch to other processes
if needed. A robot can be configured as “unattended” (i.e. on a server) to automate BPs
end-to-end, or when human intervention is needed, as “attended” (i.e. on the desktop,
triggered by the user). Furthermore, it creates an audit trail of every step executed, so it can
provide insight to process performance. Since it leverages existing IT, access authorization
is inherited and RPA is considered enterprise-safe.
Fig. 4
depicts the “long tail of work”, which shows that in work, 80% of the cases can
be explained by 20% of the case types. Traditional BPA through heavyweight IT addresses
the most frequent cases types. The remaining 20% of the cases are not considered for
BPA, as it would be too expensive (e.g. due to unavailable APIs, or because of legacy or
proprietary systems) and are therefore often handled manually. However, these cases, cover
4
A complete overview of all relevant characteristics, capabilities, benefits and success measures in relation to
80% of the case types and are much more time-consuming. RPA shows its potential here, as
it enables automation of BPs which have been previously considered too costly. As RPA is
technology-agnostic, it provides multi-system support via front-end-integration. Therefore, it
is possible to integrate RPA with any software used by a human worker, regardless of its
openness to third party integration. So, RPA can be leveraged to automate the middle part
of the graph, where costly and difficult IT development would otherwise be needed.
Once implemented, RPA is able to realize a major impact in all four performance
di-mensions (Reijers & Mansar, 2005). It enables significant cost savings (e.g. through FTE
reduction), is able to decrease throughput time by increasing efficiency and realizes
produc-tivity gains as it has the ability to work 24/7. In terms of external quality, implementations
often result in a higher customer satisfaction, enhanced compliance and improved accuracy.
Looking at internal quality, robots enable the workers to refocus on higher value activities
which increases job satisfaction. With regards to flexibility, the robots enhance agility as they
can easily be scaled up and down to handle demand fluctuations and seasonal variations.
The most common pitfalls, barriers, risks and limitations are shown in Table 2.
Type
Description
Sources
Challenges
Targeting an unsuitable candidate, using a wrong delivery method
(e.g. waterfall), not taking the IT infrastructure into account,
incor-rect leadership, no long term vision and weak change management.
Rutaganda et al. (2017),
Lamberton et al. (2017),
Suri et al. (2017)
Barriers
Lack of resources, potential suitable BPs or higher management
support. Also, fear of job loss and budget constraints.
Suri et al. (2017)
Limitations
RPA is limited as it makes use of isolated systems and is inferior to
back-end integration when it comes to performance and robustness.
Grung-Olsen (2017)
Risks
Underestimating the complexity involved in coordinating a large
number of robots, its proneness to failure due to dependencies to
underlying applications, and security and privacy issues.
Penttinen et al. (2018)
Table 2:
Overview of the challenges, barriers, risks and limitations in relation to RPA.
Currently, RPA is predominantly used to automate routine administrative tasks that
typically require a person to interact with multiple IT systems (Barnett, 2015). Fig. 5
depicts the position of RPA accordingly. It shows that there is no overlap with KiBPs. As
stated, the real potential of RPA lies in its ability to support KiBPs. This untapped potential
indicates the focus area of this research. The scope of this study is limited to KiBPs that are
supported through case handling as these rely on both practices as well as procedures, which
offer ground for RPA.
Figure 5:
The overlap between the untapped potential of RPA (in red), KiBPs (in blue) and BPs supported by case handling (in
black), indicating the focus area of the BPs that will be targeted by the framework. An enlarged version along with separate ones
can be found in Appx. C.2, pp.34-36.
4
Research Design
This research follows a cross-sectional design (Bryman, 2015). As RPA is a relatively new
type of technology and academic research on the topic is scarce, an inductive research
approach is taken on (Bryman, 2015), because this will set some ground for future research.
This study is considered exploratory as it seeks to generate theoretical insights rather than
test theory (Flick, 2014). A qualitative research strategy is construed because it allows for
small sample sizes, intense contact with the field of study and can be used to acquire a
broad understanding of the problem at hand as well as analyzing the issue from multiple
perspectives (Gray, 2013). The research methodology of this study [Fig. 6] adapted the
principles of design science (Hevner et al., 2004), which is based on the design of an artifact
to solve the research problem at hand. By use of the proposed artifact (the framework), this
thesis aims to address the main research question.
4.1 Approach to literature review
To determine relevant literature, several search criteria have been used within conference
proceedings and bibliographic databases [Appx. B.2]. A concept-centric approach (Webster
& Watson, 2002) has been adopted, as this allows for a better synthesis of the literature
and thus constructing a conceptual framework. This is complemented with a backward and
forward author search (Levy & Ellis, 2006). A systematic method [Fig. 16, Appx. B.1]
was followed to ensure a relatively complete census of the literature. Literature analysis was
performed through keywording (Petersen et al., 2008) and open coding (Khandkar, 2009),
so (categories of) concepts and other factors (e.g. characteristics and capabilities of RPA, or
discriminators of KiBPs) relevant to the research could be derived.
(Academic) literature
Problem statement; Suggested solution
Definitions; Relevant factors to KiBPs and RPA Theoretical background; Model of BPs 1. Case studies; 2. Transcripts; 3. (Academic) iterature Framework to identify candidate tasks for RPA Mapping of the as-is situation of RPA; Case studies Recordings of the interviews Interview guideline; List with experts
Taxonomy of types tasks; Role allocation to robots and knowledge workers;
Input
(Academic) literature
Output
Conclusion
Write up results, discussion, conclusions, implications and future research
Mapping and Design
Map as-is situation of RPA Derive taxonomy of types of tasksand design framework
Analysis
Meta-analysis of
case studies Content analysis of transcriptsand literature analysis
Data collection
Gather case studies from
vendors and service providers Conduct semi-structuredexpert interviews
Definition and Identification
Literature analysis (e.g. RPA capabilities or KiBP characteristicsDerive relevant factors )
Exploration and Problem formulation
Literaturereview Synthesize to conceptual framework Explorativeinterviews
A B A A B B
Contribution of
this study
Figure 6:
The research methodology consisting of five phases (based on Hevner et al. (2004)). Per phase the the in and output are
indicated along with the contribution of this study. Note the split between part A and B. More detailed intermediate procedural
steps are shown in Fig. 21 and Table 5, which can be found Appx. D.
4.2 Data collection and data analysis methods
Data was gathered through methodological triangulation. Next to literature, the three primary
sources were: (1) explorative interviews, (2) conducted case studies, and (3) in-depth expert
interviews. Three unstructured explorative interviews were conducted in the first phase of
the research to explore the field, gain a better understanding of the problem domain, set
up an interview guideline and compile a list of suitable interviewees. For part A, to gain
insights into RPA implementations in practice, a multitude of conducted case studies has
been collected from five different vendors
5
complemented with two service providers. With
regards to part B, to obtain useful knowledge, in-depth interviews with experts in the field
were conducted (Bogner et al., 2009).
These interviews were semi-structured as it allowed for the coverage of different topics
(i.e. RPA as well as KiBPs) during the span of the interview. Moreover, it offered the ability
to explore the perceptions and opinions of the interviewees, to probe and to adjust the
guide to interviewees with a different background (Barriball & While, 1994). To avoid
group thinking, the interviews were individual (Bryman, 2015). Interview guidelines were
prepared in advance, based on literature and relate to the three sub-questions. The sequence
of the questions asked varied per interview and based on what was considered a significant
reply, further questions were asked (Bryman, 2015). After an initial group of interviewees
was identified, others were found through snowball sampling (Biernacki & Waldorf, 1981).
To include different perspectives, four categories of experts
6
have been identified: (1) service
providers, (2) vendors, (3) domain experts and (4) end-users. The interviewees have been
selected based on their background, experience and expertise on the subject (Bogner et al.,
2009). The interviewee was considered to be an expert when they had at least one year of
(work) experience on the matter.
To find emergent themes and patterns in the gathered qualitative data, inductive content
analysis (Elo & Kyngäs, 2008) and open coding (Khandkar, 2009) was applied. Next to
this, deductive content analysis (Elo & Kyngäs, 2008) was used against the coding scheme
derived from literature. To realize a mapping of the current deployment and utilization
of RPA implementations, a meta-analysis, traditionally a quantitative measure but adapted
to qualitative case studies (Stall-Meadows & Hyle, 2010), was carried out so that the data
from these studies could be assimilated, compared and systematically analyzed.
5
Analysis, Mapping and Design
5.1 Part A: The as-is situation of the deployment and utilization of RPA implementations
Findings from the expert interviews as well as meta-analysis on the case studies (N=121)
show that the majority of RPA implementations have been carried out on basic, standardized
BPs where the customer is not directly involved (e.g.) as these BPs are the most
straightfor-ward to automate and often present the largest business case. Furthermore, as mentioned
by many interviewees, currently, RPA is almost always set up as an unattended solution,
meaning the BP is automated end-to-end, with little or no human involvement. In the cases
where there were still human workers involved this was either for exception handling or
the BP was redesigned in such away that all the tasks performed by humans are clustered
together at a single point in the BP (either at the start, middle or end).
RPA is for most part deployed in the FSI (40.5%) and TMT (14.9%) sector [Fig. 8].
Within these sectors, banking, telecom and insurance are the largest industries [Fig. 7] in
5
These vendors are considered to be leaders or strong performers in the RPA market [Fig. 22, Appx. F.1].
6
Service providers implement RPA or ACM systems, vendors develop the actual RPA or ACM technology, domain
experts have expertise in field of KiBPs and end-users are organizations where RPA is already implemented. For an
overview of all interviewees, see Table 6 and Table 7, in Appx. E.
terms of RPA deployment. With regards to utilization, seven unique use-case categories have
been identified along with a multitude of sample use-cases, these could either be related
to the (1) back office, such as back office administration (e.g. finance, accounting, HR or
payroll), IT operations, or supply chain management (e.g. sales, order management or
procurement), (2) front office, such as customer service or (3) non-function specific use-cases,
such as data handling and processing, enabling digital transformation and services, or
connecting process islands and legacy systems. Looking at the total sample, Fig. 8 shows
that the majority (53%) of projects have been utilized in back office related BPs.
14 15 11 9 13 5 9 4 1 5 3 2 2 8 3 9 3 3 2 0.0% 2.0% 4.0% 6.0% 8.0% 10.0% 12.0% 14.0% 0 2 4 6 8 10 12 14 16 Insu ranc e Bank ing & Ca pital M arke ts Fina ncia l Ser vices Inve stmen t Man agem ent Tele com , Med ia & E nter tainm ent Tech nolo gy Heal th & Soc ial C are Civi l Gov ernm ent Defe nse, S ecur ity & Just ice Cons umer Pro duct s Tran spor t, Ho spita lity & Serv ices Auto motiv e Reta il, W hole sale & D istrib ution Heal th C are Life S cienc es Busin ess Pr oces s Ou tsou rcing Oil, Gas & C hem icals Powe r & U tilities Mining & M etal s Overview of # and % of cases per industry, N=121
Figure 7:
An overview of the percentage and number of cases per industry, sample of case studies is N=121. As the majority of
case studies is from internal material, the sector and industry grouping used by Deloitte is adopted. An enlarged version can be
found in Appx. G.1, pp.75-77.
By use of deductive content analysis, a mapping of the current deployment per sector
and industry plotted against the utilization per use-case has been constructed in the form
of a heatmap
7
. It can be seen, that in almost all sectors back office administration is the
highest ranked use-case. Exceptions are the TMT and BPO sector, where the customer service
use-case is utilized most. Lastly, the projects deployed within the FSI sector and utilized for
back office administration show a major outlier whereas supply chain management shows
with 3.3% the lowest utilization in the sample.
Figure 8:
Overview of the percentage of cases per sector, sample of case studies is N=121. The categories of use-cases that
organizations could utilize are adapted from Redwood (n.d.) and Thoughtonomy (2017), two RPA vendors. Enlarged versions
can be found in Appx. G.1, pp.75-77, whereas an overview of the sample use-cases can be found on p.78
Through inductive content analysis and open coding, three different categories of
prob-lems that drive organizations to adopt RPA solutions have been identified. These categories
can be broken down into eleven distinct issues and reasons for adoption. These could be
(1) performance related (e.g. a lack of quality or insight in the process), (2) due to external
forces and pressures, such as (expected) increasing volumes, cost and efficiency pressures
because of a highly competitive market, strict regulatory demands or increased customer
expectations or (3) the complexity involved, such as a complex IT landscape (e.g. high number
of legacy systems or mainframes) or data-intensive processes (i.e. a lot of different screens,
applications or sources). The data shows that more than half of the issues organizations
face, which drive RPA adoption, are performance related, whereas the external forces such
as regulatory, customer and market demands (e.g. cost and efficiency pressures) are least
relevant in the decision to initiate an RPA project. However, pinpointing to one particular
reason is not possible, as in practice, multiple factors play a role.
Looking at the objectives and what is achieved afterwards, by far most of the success
measures are related to the time, internal quality and cost dimension. Moreover, the focus on
customer satisfaction (8.6%) and compliance (5.9%) is minimal. Apart from a few interesting
exceptions, the goals set-up beforehand and the impact realized correspond roughly for
almost all the success measures. Zooming in on the heatmaps, the most notable differences
are seen in the decrease in throughput time, which is not much of a focus point beforehand
(10.2%) but turns out to be a relevant success factor after implementation (17.2%). In
addition, one sees that the objectives set on productivity and customer satisfaction are far
higher than what is realized afterwards.
To conclude, looking at the approaches to automation (Sampath & Khargonekar, 2018),
with respect to the issues that drive adoption, the goals organizations have set, and the
impact realized afterwards, the as-is situation is categorized as performance-driven. The
heatmaps show that the majority (56.5%) of underlying reasons that drive organizations
to adopt RPA are performance related. Furthermore, the data shows that the main goals
set-up beforehand are related to FTE reduction, improvement of accuracy and productivity
gains while the focus on customer and job satisfaction is the lowest.
5.2 Part B: Towards an interplay between software robot and knowledge worker
Interpretation / Judgement
Integrative
Collaborative
L evel of in te rdepen den ce Complexity of workTransactional
Expert
Routine Collaborative groups Individual actorsSoftware robot Knowledge worker
Figure 9:
The four different types of KiBPs as
in-dicated by the classification structure, (Davenport,
2015) allocated to either a software robot or a
knowledge worker.
In contrast to the as-is situation, which is performance
focused and has only 10.2% of the cases targeted at
the enhancement of employee morale, the suggested
solution is an “attended” RPA solution, which aims to
be human worker centered (Sampath & Khargonekar,
2018), meaning the solution will not replace
work-ers, but initiate new forms of interaction between
humans, the knowledge workers, and technology,
the software robots (Lacity & Willcocks, 2016a; vom
Brocke et al., 2018). It will redefine the role of the
knowledge worker in such a way that they are
liber-ated from mundane non-value adding tasks and be
able to focus at tasks that require human intelligence.
Given the nature of KiBPs, and the capabilities and
characteristics of RPA, it is impossible to automate a KiBP end-to-end, meaning the process
will be fully automated without any human involvement. Therefore, RPA can only be applied
to certain extent. This extent depends largely on the composition of the KiBP. Given the
classification structure [Fig. 9], KiBPs that are largely transactional or integrative can
be automated to a higher extent than collaborative or expert KiBPs. However, a more
fine granular view is required on work in which automated and manual tasks are blended
together (Koorn et al., 2018). To allocate roles at a task-level, a taxonomy of types of tasks
has been derived from literature.
A taxonomy of types of tasks.
The taxonomy is constructed along the focus dimension
(from system to human-centric), where Dumas, van der Aalst, and ter Hofstede (2005)
have identified three classifications of BPs: Application-to-Application (A2A),
Person-to-Application (P2A), and Person-to-Person (P2P). As this research proposes a task-based
approach, these classifications will be drilled down to the finest level of detail: types of
tasks. These classifications reflect three groups of tasks as indicated by Dumas et al. (2018a,
p.372), which each consist of different types. A2A BPs only involve fully automated tasks,
which are carried out by applications or external (web) services. These tasks are related to
data exchange or execution (e.g. running a script or service). In contrast, P2P BPs primarily
involve manual tasks, which require are performed by process participants without the aid
of any IT. These tasks are in need of typical human traits (e.g. emotions or compassion),
creativity or innovation. They are characterized by a cognitive component, such as the
ability to think, reason, solve problems or interact with others. P2A BPs, consist mostly of
user tasks, which sit in-between automated and manual tasks. These tasks are performed by
a process participant with the assistance of IT (i.e. human-computer-interaction). Besides
information exchange and low cognitive tasks, these tasks are mostly related to information
processing (i.e. information acquisition, unification, basic analysis and decision-making).
The interplay between robot and knowledge worker.
Given the capabilities and
char-acteristics of RPA and the multiple interviews with vendors, service providers and domain
experts the types of task indicated in the taxonomy have been allocated to either a software
robot or a knowledge worker [Fig. 10]. While constructing this role allocation, any task
that is already automated by a traditional heavyweight IT solution, has been excluded. User
tasks that require the process participant to interact with IT systems are perfect candidates
for RPA, whereas manual tasks are well suited to be performed by knowledge workers as
these require typical human cognitive capabilities.
Figure 10:
A classification of BPs according to their
focus, drilled down to a taxonomy of types tasks
(left) and an overview of the role allocation per task
type (right). A more detailed version can be found
in Appx. G.2, p.83.
Software robots are able to perform information
exchange tasks (e.g. handling incoming email), some
low cognitive tasks (e.g. performing predefined
calcu-lations or standardized reporting) or tasks related to
information processing. Typically, these types of tasks
require a lot of keystroke operations, UI navigation
and access to multiple different sources (i.e. working
through multiple screens of IT systems, applications
or websites). As they often require a high degree of
repetitive manual handling, these types of tasks are
seen as unsatisfying, and are prone to human error,
labor-intensive and time-consuming. Other
impor-tant pointers for identification, is that these types of
tasks are the most suitable for the robot if they are
methodical, simple, highly standardized and occur
with limited to no exceptions during its execution (i.e.
a basic procedure). Moreover, if the tasks involves
a lot of legacy IT or proprietary systems that have
no (publicly) available API, it is a perfect candidate
for RPA. However, it is important to note, that for
the robot to work properly, the task at hand should
include only digitized and structured data, and
de-cisions that are rule-based (i.e. follow explicit and
well-documented, predefined rules). Also, the task
should be mature and stable (i.e. executed within a
landscape with a predefined set of IT systems that
remain the same every time a task is performed and
is not affected by any major IT-driven development effort). Lastly, software robots are
ideal for types of tasks where, regulatory or compliance requirements ask for an audit trail,
out-of-office support is needed (i.e. it should be available 24/7) or when accuracy and
consistency, with regards to the output, are of importance.
On the other hand, the knowledge worker is suited best to perform tasks that require
human intelligence, interaction or physical activity. So, tasks that are typically performed
without without any aid of IT systems. Typically, these kind of tasks include complex
decisions which call for (subjective) judgment, human interpretation, social intelligence,
such as being aware of others’ reactions, or emotions (i.e. the ability to provide support
or compassion). Moreover, knowledge workers are capable of handling tasks that involve
non-digitized (e.g. speech or handwritten input) or unstructured data (e.g. images, video).
Other important pointers to look out for are the communication and collaboration skills
involved. As opposed to software robots, knowledge workers have the ability to work and
interact with others and communicating effectively through verbal conversation and writing.
Lastly, tasks that are in need of unusual or clever ideas about a certain situation, creative
ways to solve a problem or a response to a sudden change in the environment are best
handled by a knowledge worker.
As shown in cases in practice
8
, knowledge workers and robots can work together. This
is in the form of an attended solution, which is installed on the desktop of the user. As
stated by the KiBP domain experts, in such an interplay, the robot will serve as a “digital
assistant” to the knowledge worker. For example, the robot could gather and consolidate the
required information, while the knowledge worker is then guided by the robot via on-screen
prompts or pop-ups to provide support on how to handle the situation. When input from the
knowledge worker is needed, an “user-exit” appears, along with the relevant information
to take action. Typically, the knowledge worker will then analyze the information, make
a decision based on judgment, or validate the steps realized by a robot. However, both
Appian as well as Pega, two ACM vendors with RPA add-ons, argued that to achieve this
synergy between human and robot, you would need an ACM platform to realize the process
orchestration. RPA software solutions itself are not able to route the process between human
and robot. Furthermore, such a platform offers the ability to create a new unified interface
which is linked to all the underlying systems so information only needs to be entered once,
after which they will be synced across all the relevant applications.
Task Task Task Task Task Task Task Task Task Task Task
Suitability
Im
pact
Figure 11:
The result of the framework,
which plots the potential candidate tasks
based on their score on suitability as well as
impact.
Unlocking the untapped potential.
The
aforemen-tioned pointers offer some direction, however it still does
not provide a methodical approach to assess the
suitabil-ity of candidate tasks. So, how can the suitabilsuitabil-ity of tasks
in relation to the untapped potential of RPA be assessed
in a structured way? Based on extensive literature
anal-ysis, a list with 18 characteristics which determine the
suitability of candidates have been identified
9
. This has
been cross-referenced with the transcripts from the expert
interviews to ensure no important aspects were missing.
Next, these characteristics have been categorized into
three main levels, each with their own conditions, which
comprise the framework [Fig. 12]. The potential
candi-date tasks should meet different criteria in all three levels in order to determine its potential.
The framework starts with the (0) knock-outs, which are a series of hard criteria (yes or no
questions) that need to be met in order for RPA to function properly. Any condition that is
not met leads to termination of this task to move through the rest of the framework. Second,
the framework assesses the (2) suitability, which is a series of soft requirements on which
the user of the framework should appoint a score (0-5). Even without meeting some of these
8
See Appx. G.2, p.86, for an overview of exemplar cases with an interplay between human and robot.
conditions, the task could still be a suitable candidate. However, the higher the score of the
task at hand the more suitable it is for RPA. This level verifies if it is logical to automate the
candidate task and checks it against some technical related criteria. Lastly, the framework
forces the candidate through a series of factors which determine the potential impact in
terms of business value. The framework appoints a score based on the number of questions
that are addressed satisfactory.
The framework results in a graph which indicates the potential of the candidates based
on their score with regards to suitability and impact [Fig. 11]. It is limited to assessing
the initial potential, before any configuration, and is intended to serve as a supporting tool
for organizations who are considering to adopt RPA to improve KiBPs. The tool results in a
shortlist of suitable candidates. The tasks that show the most potential (top right corner)
need to be evaluated in more detail, but this is for future studies.
Knock-outs
A series of hard criteria that need to be met in order for RPA to function properly, any condition that is not met leads to termination of this task to move through the rest of the framework.
Suitability
A series of soft requirements, the higher the score of the task at hand the more suitable it is for RPA, these criteria could either task or technical related.
Impact
A series of factors which determine the potential impact of the task in terms of business value.
