See discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/335935603
How Robot/human Orchestration Can Help in an HR Department: A Case
Study From a Pilot Implementation
Article in Organizacija · August 2019
DOI: 10.2478/orga-2019-0013
CITATIONS
29
READS
1,090
2 authors:
Some of the authors of this publication are also working on these related projects:
Cross-cultural study of individual and contextual factors of cyberbullying and prejudice-based cyberbullying among high school students View project
SGS/8/2018 – Advanced Methods and Procedures of Business Processes Improvement View project
Dalibor Šimek
Silesian University in Opava
1 PUBLICATION 29 CITATIONS
SEE PROFILE
Roman Šperka
Silesian University in Opava
53 PUBLICATIONS 217 CITATIONS
SEE PROFILE
All content following this page was uploaded by Roman Šperka on 28 September 2019.
The user has requested enhancement of the downloaded file.
204
Organizacija, Volume 52 Research Papers Issue 3, August 2019
How Robot/human Orchestration Can
Help in an HR Department: A Case Study
From a Pilot Implementation
Dalibor ŠIMEK and Roman ŠPERKA
Silesian University in Opava, School of Business Administration in Karvina, Univerzitní náměstí 1934/3, 733 40
Karviná, Czech Republic, [email protected], [email protected]
Background and Purpose: Motivation of this research is to explore the current trend in automating the business
processes through software robots (Robotic Process Automation – RPA) and its managing within enterprise environment where most of the processes are executed by human workforce. As the RPA technology expands the demand
for its coordinating grows as well. The possible solution to this challenge is shown in case study research in form
of implementing orchestration platform to a concrete business process of onboarding in HR department of a multinational company. The aim of this paper is to explore the phases and activities of the pilot project implementation
of Robotic Service Orchestration (RSO) in combination with RPA technology and to assess the potential benefits.
Design/Methodology/Approach: Case study research approach was selected to explore the research phenomena, which is the implementation of RSO platform in combination with RPA technology and assessing incoming benefits. The case is formed with 2 companies – (1) multinational company with ongoing effort of automating onboarding
process, (2) technology and consulting company delivering the automation solution. Data were collected through
semi-structured interviews with respondents from two involved companies and by analysing internal documents.
Results: The analysis of case provided in this paper revealed some key insights: (1) strategical position of RSO and
tactical position of RPA towards the existing legacy systems, (2) need for increased focus on initial process modelling phase, (3) Application Programming Interface (API) integration is more viable solution for RPA, (4) the biggest
benefit of RPA – its agility, (5) future potential of the RSO replacing the BPMS.
Conclusions: First of all, there is a need of higher number of software robots adopted in a company before orchestration could pay off. On the other side, current Business Process Management Systems (BPMS) solutions don’t
offer functionalities for managing human and software robots workforce altogether. RPA is expected to expand and
without proper orchestration the effectivity will not grow constantly.
Keywords: Robotic service orchestration, Robotic process automation, Pilot implementation, Case study, Human
resources.
DOI: 10.2478/orga-2019-0013
1
Received: May 14, 2019; revised: June 28, 2019; accepted: July 30, 2019
1 Introduction
Workflow management (WfM) was trending at the end of
the 20th century, but as Abbott and Sarin (1994) noted,
the emphasis in workflow management was on using computers to help manage business processes, which could
be comprised of many individual tasks, and not on using
computers to automate the individual tasks. This approach
distinguishes between WfM and the recent practical trend
of Robotic Process Automation (RPA). Van der Aalst et al.
(2018) shared his opinion about RPA. According to his research, “RPA is an umbrella term for tools that operate on
the user interface of other computer systems in the way
a human would do. RPA aims to replace people by automation done in an ‘outside-in’ manner.” This ‘outside-in’
manner is considered to be a great advantage, mainly in
comparison with WfM. In this approach, existing informaUnauthentifiziert | Heruntergeladen 28.09.19 16:26 UTC
205
Organizacija, Volume 52 Research Papers Issue 3, August 2019
tion systems (IS) remain unchanged. Redesigning old IS
or designing new IS is often costly in the context of an
automation project as a whole. These steps are replaced
by robot agents with RPA usage. RPA is a tool that adopts
some profound elements from WFMSs but enhances them
with the latest technology options. The practical defnition provided by Gartner is as follows: “Robotic process automation tools perform ‘if, then, else’ statements
on structured data, typically using a combination of user
interface interactions, or by connecting to APIs to drive
client servers, mainframes or HTML code. An RPA tool
operates by mapping a process in the RPA tool language
for the software ‘robot’ to follow, with runtime allocated
to execute the script by a control dashboard.” (according
to Tornbohm and Dunie (2017)).
To support the statement of the trending RPA, the predictions of research companies are clear. This discipline
arises from real companies’ problems and the fact that
they have been trying to automate routine tasks and business processes for so long, often without proper Return
on Investment (ROI). The RPA market has reached US
$250 million in 2016 according to the US research company Forrester (Le Clair, 2017), and they are expecting
to grow signifcantly with help of Artifcial Intelligence
(AI), which is starting to be implemented in existing RPA
solutions. There are approximately 12 key vendors of RPA
solutions on the market. The estimated growth provided by
Forrester (Le Clair, 2017) is that the RPA market will reach
US $2.9 billion in 2021. These numbers are too large to be
ignored. Academic researchers are catching up, but RPA in
the academic environment is still in its infancy.
With RPA, organizations are deploying technology
that can create virtual workforces of robotic workers. They
are operating within the company’s computational capacity to automate structured ofce processes. The difference
opposite classic business process automation is the scope,
where previous automation capabilities were there to assist the human process participants and owners. With RPA,
we are dealing with potential replacement of the whole resource, which takes care of the workflow execution with
no need to interrupt or redesign the background system.
As Brocke et al. (2018) noted, RPA uses AI technologies
to bring decision-making intelligence, flexibility and adaptability into business process environments. With this
increase in AI incorporation into the processes, RPA became a signifcant tool in the BPM domain. Mendling et
al. (2018) panel report construe the question of AI in RPA
more specifcally by raising question which RPA brings to
the BPM research domain: “how to design and program
robots and to integrate them with BPM systems, how to
leverage RPA as a vehicle to support AI-enhanced processes, and how to use artifcial intelligence techniques to program RPA solutions based on goals”.
Human-robot cooperation (HRC), used in the research
in manufacturing and assembly productions (Pellegrinelli
et al., 2016; Michalos et al., 2014) has a different conception, than the human/robot orchestration – the Robotic Service Orchestration (RSO) – used in this paper, perceives
robots as a physical embodiment rather than intangible
software. Because the BPMSs classifcation is quite broad,
the RSO belongs into one of its categories. The purpose
of RSO is similar because, according to the developers of
Enate software tool, RSO is a platform that enables the
delivery, management and execution of business processes
that stand behind every service across both the digital and
human workforce. The business logic is largely the same,
but the distinction comes with the technology they are using to automate the business processes. RSO is built for
close cooperation with external services such as RPA. RSO
cooperates most of its functionalities from BPMSs, but it
upgrades the redistribution of work among the available
resources while considering humans, as well as robots. It
attempts to answer a formidable question: which processes
should be automated, and which should be performed by
humans (Aalst et al., 2018).
With the growth of the RPA domain also comes some
criticisms. As it was with Business Process Reengineering
in the 1990s or BPM in the beginning of the new century,
new trending technologies are very attractive to consulting or software vendor companies, which are offering a
solution in the B2B market but often fail to deliver real
value in terms of increasing the process effectiveness.
According to Ernst & Young report, 30-50% (Lamberton,
2016) of initial RPA implementations fail. Nevertheless,
a research report from Hindle et al. (2017), provides data
about different aspects of RPA implementation (specifcally the Blue Prism software tool) based on a survey research
strategy. This report (Hindle et al., 2017) shows that except
for one case, every other case (23) had positive ROI. This
contradiction shows how this rapidly growing industry is
unstable and unclear. This circumstance, of course, provides a great opportunity for researchers to uncover the
vail of uncertainty and bring valid conclusions into this
newly formed domain.
The aim of this paper is to explore the phases and
activities of the pilot project implementation of RSO in
combination with RPA technology and to assess the potential benefts. The subject of the research is the whole
implementation process, which consists of different phases
and activities sorted on a time scale. Two companies are
cooperating on showcasing the benefts of RSO and RPA
technology with the aim of improving the process of onboarding (HR department). The research questions support
the aim of the paper, as follows:
What was the process of the implementation of the examined project?
What are the benefts for companies A and B that arise
from the examined project?
According to our knowledge, this type of a case study,
Unauthentifiziert | Heruntergeladen 28.09.19 16:26 UTC
206
Organizacija, Volume 52 Research Papers Issue 3, August 2019
with implementation of BPO and RPA, has never been
covered in academic journals. Thus, this research area is a
white space in the literature, and only the research process
will demonstrate how this particular research design suits
the new wave of approaching process improvement and
automation. This circumstance often occurs in exploratory
research projects.
As is usual with a new stream of research, the frst exploratory studies in the feld are necessary for achieving
in-depth insights, which is the reason why we choose exploratory study, and the subsequent content is structured
accordingly. After the related work section, a methodology
section is offered where an appropriate research design is
described. Next, we present an actual case study that is
subsequently structured as the project (case). A discussion
followed by conclusion is provided at the end of this paper.
2 Related work
Recently, papers on RPA have started to emerge. Most
of them are presented in the form of a case study, such
as (Fernandez and Aman, 2018; Aguirre and Rodriguez,
2018; Lacity et al., 2015a; Lacity et al., 2015b; Lacity and
Willcocks, 2016). In research from Lacity et al. (2015),
single case studies are presented. They investigate real examples of practical usage of RPA in companies such as
O21. In the case of O2, 2 pilot processes were selected, and
the results show higher ROI in comparison with BPMS
implementation. Other interesting results are displayed in
the Aguirre and Rodriguez (2018) case of implementing
RPA into a business process outsourcing company, where
an increase in productivity and capacity of approximately
20% was reported.
From a methodological standpoint, researchers should
be aware of the overall methodological selection and
preparation of case studies. There is a need to distinguish
between the case study, which is commonly presented as
marketing material from software providers and consulting companies, and case study research (Saunders et al.,
2016). The most signifcant paper is that of Fernandez and
Aman (2018), because it is the only paper that outlines the
research design and methodological selection. They also
used a single case study, and data were collected through
semi-structured interviews with various respondents, mostly process participants. They conducted 11 interviews, and
the results from those interviews are presented, including
the impact on individuals and the company context.
The most positive results are shown in the case studies
from Lacity et al. (2015) and Lacity and Willcocks (2017),
where the subjects were the companies Xchanging and
UTILITY (anonymized name). In the frst case of Xchanging, the results exceeded the frst expectations. Overall, 14
key processes were automated with a help of 27 implemented robots. They processed 120 thousand instances per
month with an average savings of 30% on every automated
process. The UTILITY case was even larger, with 25 processes involved in the RPA initiative and with 1 million
instances per month. This amount of work is performed by
300 robots, which are orchestrated with 2 employees, and
they substitute for the work of 600 people. The ROI from
this project is 200% for the frst year after the implementation. The overall return on investment with the RPA project
mentioned in the work of Lacity and Willcocks (2016) is
typically 1 year.
In the most recent work from 2019 is clear that the RPA
technology is starting to engage with diverse industries.
The research paper from Houy et. al. (2019) demonstrates
an example of implementing cognitive RPA to public administration, Moftt (2018) outlined how audit could beneft from use of RPA and another research is testing RPA
in digital forensics (Asquith and Horsman 2019). Also another case studies from more traditional industries are still
emerging. For example Schmitz et al. (2019) described
case of German telecommunications operator where RPA
was use as an enabler to realize digital strategy. The RPA
is not used only in new areas, but with help of AI, to a new
strategic business task such as decision-making (Ranerup,
Henriksen 2019).
3 Research methodology
The aim of this section is to construct research questions
and to propose a research design that will serve to answer
the research questions. The research design guides the investigator in the process of collecting, analysing and interpreting the observations during the case (Yin 2014).
To better understand this methodology section, a case
defnition is presented frst. The defnition specifes the
scope of the case. In this study, a case is a pilot project implementation, which involves two companies in a specifc
time horizon. The frst company is developing and providing an RSO and RPA solution (company A) to another
company, which is a multinational company that operates
in a business process service market (company B). Company A is a start-up company, which was founded in 2014
in the Czech Republic and currently has 12 employees.
Company B is an international enterprise founded in 2004
in the Czech Republic that specializes in providing business processes and services for large corporations across
the globe, with approximately 1600 employees.
Company A operates in the RPA market and has a
strong background in data science and text mining. They
already cooperate with company B on a project on the automation of a certain task through the deployment of an
11
https://www.telefonica.com/en/home
Unauthentifiziert | Heruntergeladen 28.09.19 16:26 UTC
207
Organizacija, Volume 52 Research Papers Issue 3, August 2019
RPA solution. Given the fact that Company B is operating
on a business process services market, they are embracing
new automation technology, which company A is deploying. Their cooperation creates a mutually benefcial synergic effect. The case in this case study research is a pilot
project of implementing RSO and RPA in the HR department of company B, in particular, an onboarding process.
The implementation is led by company A.
The methodological choice of this paper reflects the
fresh essence of this domain. That is precisely why we
decided on an exploratory study in our research. A small
sample and deep dive into the research phenomenon are
characteristics of a qualitative exploratory study. As a
prime research technique, unstructured interviews were
chosen.
It is necessary to defne the purpose and scope of the
case study. As Schramm (1971) noted, the essence of a
case study and the central tendency among all types of
case studies is that it attempts to illuminate a decision or
set of decisions – why they were taken, how they were implemented, and with what result. This illumination comes
from examining the contextual conditions, believing that
they might be highly pertinent to the phenomenon of study
(Yin, 2014). According to Feagin et al. (1991), case studies
concern decisions, programmes, implementation processes and organizational change. The case study in this paper
concerns implementation processes.
Only one case was chosen, and thus, it is single case
study research, which is common for exploratory studies.
A rationale justifcation for building this paper on only one
case comes from Yin (2014). He states that the reasoning
for single case study research comes from a situation in
which the case represents an extreme or unique case, such
as conducting a pilot project.
The units of analysis are the individuals who are part of
this project and the documents, which provide data about
the course of the project and about the deployed technology. Case boundaries are set by the pilot project, which
determines everything directly related to the implementation process: its content, participants, procedures, logical
structure and IT technology. On the other side, everything
outside is context – the ambient conditions that influence
the project as well. Another boundary is the time frame of
this case: the beginning is when both sides (companies A
and B) kick-off the frst idea of this pilot project, and the
end is when the deployment was evaluated in the form of a
report with a follow-up meeting.
To secure the construct validity in the research design,
Yin (2014) recommends using multiple sources of evidence, which in our case study are narratives from different participants (from both company A and company B),
project documentation and other documents (about the
BPO and RPA solution).
To obtain access to the data within these companies,
the authors had to negotiate frst. They were involved in
the project during its realization, and they signed a nondisclosure agreement with company B, which has strict rules
for research within its span.
One unit of analysis is formed by the technique for collecting data – semi-structured interviews. They were conducted in the frst half of 2018 and form the main source
of data for this case study. Access to four respondent (Table 1) narratives was negotiated, and the methodological
preparation for these interviews was completed. Clear
boundaries for the interview were set for the pilot project.
Each interview took approximately 2 hours. This span is
the average length for in-depth exploratory interviews, and
they were recorded for consequent transcription. First, the
respondents were acquainted with the flow of the interview
and with moral and ethical concerns. After this acknowledgement, the respondents were invited to interpret their
narrative onto this pilot project. Next, additional questions
were asked to gain supplementary information, which
provided thoughts that emerged from a further narrative.
Other questions addressed the information that shapes the
broad illustration of the context that surrounds the case.
These questions were split into a few groups, each of
which addressed different aspects:
• Describing the motivation for the examined project
• Describing the phases and activities in the pilot
project
• Addressing success in these different phases
• Evaluating the benefts that resulted from the examined project
Respondent number |
From company |
Position within the project |
Length of the interview |
1 | A | solution designer | 1,5 hours |
2 | A | RPA Developer | 2 hours |
3 | A | CEO | 2 hours |
4 | B | process owner | 1,5 hours |
Table 1: Summary of Respondents
The composition of the respondents can be seen in Table
1. Three are from company A, and one is from company
B. This aspect is caused mainly by the fact that most of
the work in the project was performed by company A representatives and that this project was taken as a pilot to
validate the new technology for optional launch and further implementation projects. These interviews provide
authors with the main source of evidence, but the conclusions cannot be based entirely on interviews. For this
reason, the authors asked for documents from software
providers (supplied with software instructions and training
materials) and project documentation (including process
models) held by company A in an unstructured format, but
supported with tutorial videos. After the interviews, addiUnauthentifiziert | Heruntergeladen 28.09.19 16:26 UTC
208
Organizacija, Volume 52 Research Papers Issue 3, August 2019
tional conversations via email were engaged because, as
Yin (2014) noted, case study data collection is not merely a
matter of recording data in a mechanical fashion. You must
be able to interpret the information as it is being collected
and to know immediately, for example, if several sources
of information contradict one another and lead to the need
for additional evidence. This assertion is aligned with the
authors’ interpretative research philosophy.
As Yin (2014) noted, critics often discuss the subjective manner in which judgements are used to collect the
data in case study research. The same circumstance occurs
for generating interpretations in the research philosophy,
since its purpose is to understand and not necessarily to
measure a phenomenon (Saunders et al., 2016). For this
reason, we discuss the methodology very broadly to ensure
the validity and reliability, which will preventively serve
to eliminate errors and biases in the study.
4 Pilot implementation of RSO and
RPA
A brief introduction of the company involved in the project
was given in the previous section, but to provide broader
information, the specifc software used in this case must
be introduced. One product is the RSO software platform
called Enate. The next important technologies in this case
are two RPA tools – Blue Prism and UiPath. There are additional systems (HR system Target, K2 BPMS) that were
incorporated into the process within this cooperation, but
they did not represent the main units of analysis, and thus
their introduction is not needed.
The internal training materials provided to company A by Enate allow an operations manager to remain in
control of “who does what”, even when the work is being
performed by robots. In other words, Enate is a platform
where the workflow is created and human workers, RPA
robots or other digital agents execute activities within this
workflow, which comprises the end-to-end service. Additionally, a console for monitoring and measurement is
provided by Enate. Process owners can manually intervene
when pertinent to override the standard business rules that
are being used by the system to prioritize and distribute
the work. Another large beneft in the context of this case
is that the operations manager can decide which robots are
assigned to individual work queues. Thus, multiple RPA
solutions can be integrated to draw coherent benefts. This
integration is accomplished through API. As the CEO of
company A said in an interview “Enate is a workflow management system (WfMS) with the function to integrate and
thus manage robots as well as the human workforce.”
Both UiPath and Blue Prism work within the premise
of RPA. According to the Forrester report (Le Clair, 2017),
UiPath, Blue Prism and AutomationAnywhere are the top
3 RPA vendors. UiPath uses Microsoft´s Workflow Foundation in its design studio, and it relies on external partners
for direct implementation. UiPath’s advantages come out
form an open platform and in the creation of their global
community, which serves as a home for RPA developers.
On the other hand, Blue Prism provides strong load balancing, restart functionality, encryption at rest, audits, and
desktop-aligned robots, which are defned and managed
centrally. Blue Prism does not have open access to training
materials, and it is harder for users to learn and explore its
capabilities.
Next, we outline the motivation component, where the
summary of reasons to participate from both companies is
presented. Subsequently, the concrete flow of activities is
described, and in the end, the evaluation of the project is
showcased. The next part is already interpreting the interviews as a source of primary data.
4.1 Motivation from both companies to
participate
Because the scope of this pilot project implementation is
large and its potential is far-reaching in terms of investments and costs, which are primarily signifcant for company A, there should be a strong motivation toward this
case. This stands at the very beginning of applying the new
approach and sparks its initiation. This section unveils the
initial expectations, which are to be further compared with
actual outcomes.
The CEO of company A attended an international conference where he met the CEO of Enate, who has a strong
opinion about his product, which was aligned with how
he was thinking about the future for RPA and BPM as a
whole. The CEO of company A said “I see in the last 2-3
years a tendency of enterprises to pull back from traditional tools, which are in most cases burned out and already
fully used on behalf of process change. Therefore, they already have their processes straightened, but now they are
facing an unpleasant situation with inhouse systems and
with their centralization or transition towards one system,
which is tedious and complicated. That’s the reason why
RPA has a chance to catch their attention.” His statement
is supplemented with a review in the introduction of this
paper, where one of the main benefts of RPA is that it is
built upon existing systems. The outcome from this part of
the interview is that this beneft is the number one reason
why RPA attracted a large number of enterprises.
As he continued, he explained the role of RSO: “The
tendency of RPA is reaching enterprises not only in Western Europe but also Central and Eastern Europe, and this
trend will continue. Enterprises will continue to invest in
increasing robot capacities, gaining more robot instances
and of course combining robots and the human workforce.
In this stage, there is a room for manager or orchestrator,
who will have the ambition and power to manage the task
in real time, organize working queues, manage robot utilization and coordinate how transfer between robot/human
or human/robot works. This kind of orchestration will have
Unauthentifiziert | Heruntergeladen 28.09.19 16:26 UTC
209
Organizacija, Volume 52 Research Papers Issue 3, August 2019
signifcant importance in the future.” This statement also
concurs with researchers in the BPM domain, who already
see this shift, and as Aalst (2018) noted, the larger question
is which processes should be automated and which should
be performed by humans? RSO has the ambition and potential to answer this question. This point was the beginning, where company A started to think about initiating the
orchestration of a project. Another reason was that they
wanted to expand their portfolio of RPA tools from Blue
Prism to another platform – UiPath – to be able to leverage
advantages for different opportunities.
On the other side, motivation to start this cooperation
from company B is built on the ongoing initiative, which
has been already running since 2017 and has an ambition
for improving 4 large processes in the HR department of
company B:
• Onboarding
• Change in labour-law relationship
• Offboarding
• Managing maternity/parental leave
According to the owner of the onboarding process, who
is also incorporated in this initiative: “These 4 processes
are administratively very demanding, and activities within
them are repetitive, which offers great potential for their
standardization and automatization.” This initiative starts
with the onboarding process, where migration to the K2
BPM system was initiated to manage the whole process
under one system. During the implementation, they ran
into a problem, where data from the K2 system to the HR
system Target had to be imported. While solving this problem, they encountered RPA, which struck them as a “great
solution” according to the onboarding process owner. That
is how the cooperation between the companies involved in
this case study started.
Choosing the right partner for company A in this pilot
project was clear because of the good relationship between
the two companies and because of the RPA implementation, which was already in place at company B. Another
reason for testing the RSO comes from the initiative at
company B (described earlier), where the implementation
of additional robots is planned for future projects. Thus,
the CEO from company A and the HR process owner from
company B started to negotiate the conditions and course
of the pilot orchestration project. According to the solution
designer, who also attended this negotiation, the aim of the
project was “to improve the business process.”
4.2 Process discovery and building an
as-is process model
After approval from both sides, an appropriate process
must be selected. Given the fact that the RPA robot is already incorporated into one process, while company B is
under an ongoing change initiative in the HR department,
the onboarding process within the HR department was
chosen as an ideal candidate for this pilot project. Parts
of this process are highly structured. Two core systems
and two external services operate within the process, and
before the RPA implementation, a large amount of manual work (data manipulation) must be done. As Fersht and
Slaby (2012) noted, these are the very fundamental characteristics for the process to be the right candidate for RPA
implementation. The proper selection for RSO subjects
uses the same criteria as suitable RPA candidates, with the
exception that it is advantageous if the process has handovers between human and robot workers throughout the
flow. That is correct in the case of onboarding processes,
where a large number of personal contacts with the applicant is required. When the process for the project was
set, working groups were organized on both sides. On the
company B side, an onboarding process owner and a project manager supported the owner from the IT standpoint.
On the company A side, a group around the main solution
designer had the RPA developer at their disposal with the
support of the CEO of company A.
Company B did not have the initial workflow model
according to the CEO of company A, but in the interviews,
the process owner from company B said that they already
had “some” model that served as the main input for building an as-is process model. This contradiction only shows
insufcient terminology alignment, which could cause further problems in a project. Thus, according to team members from company A, the frst phase led to process discovery, which fnished with as-is process. The discovery
was based on several interviews with process owners and
process participants and on process documentation from
company B. After a few weeks, the workflow model was
built and validated.
Company B operates with K2 software, which is presenting itself as a BPM system. In the workflow, the map
is represented in green activities. Another system entering
into workflow model is the so-called portal, which runs
under the K2 system. It is a cloud solution, where applicants have an access point and can communicate through
it. It is symbolized by red colour activities. Finally, yellow
activities represent email actions, and one blue activity
(entering data into the HR system), Target, represents the
HR system.
Unauthentifiziert | Heruntergeladen 28.09.19 16:26 UTC
210
Organizacija, Volume 52 Research Papers Issue 3, August 2019
Figure 1: As-is process model. Source: internal documents of Company A
Unauthentifiziert | Heruntergeladen 28.09.19 16:26 UTC
211
Organizacija, Volume 52 Research Papers Issue 3, August 2019
4.2.1 As-is process description
The as-is process description was put together by analysing a transcript of narratives of representatives from both
companies which was done by project team from company
A. Final process model is shown in fgure 1. It should clarify the onboarding process itself, which is a prerequisite for
grasping the whole implementation project. The onboarding process starts with a requestor creating a request that
contains details about the position (job description). This
requestor is typically a team leader who has the competency to raise a request about the new job. This step must be
approved in the internal portal by an approver, and then it
routes to the request buffer in the K2 BPM system. From
this buffer, the individual cases are pulled from the queue
by recruiters or are directly assigned to some of the recruiters. Then, the actual selection of the right candidate
is performed through a series of interviews – one phone
interview and then two rounds of recruitment procedure.
From this step, the successful candidate is chosen, and at
the same time, a job offer is generated, and a recruiter then
determines if the candidate will be onboarded. After this
step, there are two options. If the applicant is (1) an internal employee, the process is now fnished because he/
she had already been through the following steps. If it is
(2) an external applicant, then a series of further actions is
necessary. After flling out the personal questionnaire in
the portal, the RPA robot (Blue Prism) performs 2 tasks
(Figure 2). The frst task is to enter data from the K2 portal
into the HR system in Target, and the second task is the
OFAC (Ofce of Foreign Assets Control) check, which is
done through a publicly available database on the internet and ensures foreign verifability in terms of terrorism,
fnancial crimes, and so on. Hereafter, the applicant is
requested to upload documents such as a certifcate confrming their education, personal photo and, depending on
the position, specifc security documents. This step is not
dependent on tasks performed by a robot, but the series of
subsequent tasks already are. These steps assure a medical
check-up for the applicant and that the document will head
back to the recruiter. In combination with a successful
background check performed by the external agency, the
HR admin fnishes this process with complete onboarding.
The onboarding process frequency is approximately 30-50
instances per month.
Figure 2: Illustration of part of the workflow from Blue Prism, representing the “enter data in HR system” task. Source: Internal documents from company A
Unauthentifiziert | Heruntergeladen 28.09.19 16:26 UTC
212
Organizacija, Volume 52 Research Papers Issue 3, August 2019
4.3 Process discovery and building an
as-is process model
Simultaneously with the process discovery phase, the
training in the RSO took place in company A. They already obtained training in the RPA because that is the core
business of company A, but RSO and Enate software were
completely new for them. There were 3 levels of training.
A total of 3 developers entered training level 1, which was
more generally focused on an introduction to the Enate
tool from the end-user viewpoint. Level 2 training continued as a gradual to-be process model was built. Only
one RPA developer advanced to this level. Training in this
phase was based on individual appointments via online
calls to discuss the progress on the case. The content of
this training was formed around the developers’ issues,
such as the connectivity to RPA platforms. Right after the
frst level of training, the RPA developer and solution designer from company A started to build the to-be process
model in Enate, which was to experiment with all of the
tool capabilities. Training in the RPA implementation was
not necessary because the RPA developer and solution designer were already trained in the Blue Prism and UiPath
software.
4.4 Designing the to-be process model
and implementation
As a solution designer said: “In order to succeed with this
project, we needed to consult the support from Enate iteratively within weekly cycles because this type of project
was a pilot even for them”. The solution designer meant
that even Enate did not integrate these two (Blue Prism,
UiPath) RPA platforms before. The reason is the new essence of RSO tools such as Enate. This support from the
solution provider turned out to be crucial. The aim of this
phase was to transform the as-is model to the to-be process model in Enate and to secure its functionality. First,
the overall process logic had to be created in Enate. The
complexity of the as-is model was altered by a simple 5
phase workflow. To better understand the logic of Enate,
the basic archetype defnition from the Enate training materials is required. First, there is a case, which represents
one process instance and a series of follow up steps. On
the same level as a case, there is a ticket (used for do-done
diagrams). The case is split into steps, and steps are further divided into actions. The initial reflection was that
this process will be composed of several cases, but after
the feedback from Enate’s designers, they decided that the
whole process will be classifed as one case to simplify the
process logic. As was previously stated in the motivation
section of the paper, one of the incentives was to widen
the portfolio of provided RPA solutions by company A. To
fully exhibit and discover the potential of Enate, the main
idea was that two RPA platforms (Blue Prism, already engaged in the as-is process, and UiPath) will be deployed to
this process – each of them integrated within Enate. “We
can talk about real human/robot orchestration only by providing this solution”, the solution designer noted.
When the overall logic was set, there was time for RPA
integration. The RPA developer proclaimed: “We used the
API interface working on REST services for integrating
both robots from UiPath and Blue Prism. The original solutions were that robots will work just like a human, even
on this interface, which could cause problems. However,
our fnal solution was that the robot was not working on
the Enate interface as a human worker, but instead entered
orders through the web service.” Robots were working
based on the pre-defned scheduler because of RPA robots
interacting with the pull from the queue command, which
serves as a check on whether there is some instance in the
queue waiting for a robot. There are 3 types of working
items in Enate:
• Manual type action
• Email action
• Actions that could be performed by a robot – run
the robot task
4.4.1 To-be process description
The description was obtained from the internal documents
(project video) of company A. The to-be process model itself is showcased in fgure 3. First, part of this phase was to
determine the potential for process redesign and enables the
process to enter the next step in the best manner possible.
The process redesign merged the frst 2 steps of the process
because there were 2 non-value adding steps to create and
approve the new request, and they were redesigned into a
request validation step. This redesign is rather cosmetic,
but it provides simplifcation for the process model, which
is now more defnite. By opening a new position, the new
case (work packet) in Enate is created. The output from
this initial step is assigned to a specifc recruiter. Further
actions are dedicated to selecting the right candidate, and
after the selection, the right candidate’s profle is created
in Enate by the recruiter. Next, it is time for processing all
of the necessary documents and data about the candidate.
These actions are performed by the RPA robots – each of
them (Blue Prism, UiPath) performing different tasks. The
UiPath robot now performs the OFAC check previously
done by Blue Prism, and the Blue Prism robot retains the
execution of administrating HR related data in the Target
HR system. All of these steps are performed in real time
and are controlled by Enate. When both of the robots are
fnished, the Enate automation capacities come into play.
Enate generates a new email to the applicant with medical check instructions attached, and the system sends out
the information automatically. When the medical check-up
is completed, a new email is generated with on-boarding
information. After this step, the candidate is ready to be
on-boarded, the case is closed, and a full history of action
is provided and available.
Unauthentifiziert | Heruntergeladen 28.09.19 16:26 UTC
213
Organizacija, Volume 52 Research Papers Issue 3, August 2019
Figure 3: To-be process model designed in Enate
Unauthentifiziert | Heruntergeladen 28.09.19 16:26 UTC
214
Organizacija, Volume 52 Research Papers Issue 3, August 2019
4.5 Testing and Validation
To validate the proposed solution, a series of tests must be
done to secure the proper functionalities. According to the
solution designer, the testing was logically split into two
phases. Separate testing is performed for the RPA robots
and – then for the RSO platform – Enate. In the case of
RPA robots, according to the RPA developer: “Testing was
done in close cooperation with company B, where we obtain an anonymous dataset that we ran through the workflow.” This is an ordinary procedure, which focuses on the
part of the workflow where a human worker makes many
mistakes. From this part of the testing exception handling
models are created and built into the original workflow.
Company B established the test environment in the fnal
destination – Target system. The RPA developer then could
set up the robot on the real interface without potentially
causing issues in the real-time version. After the exception
handling models are created and the data test shows no
more exceptions arising, the access to the real-time version
of Target was managed. Under the tight supervision of HR
administrator, the frst real workflow was done through robots and then was checked to confrm the correctness of
the embedded data. This test was conducted several times,
and then the robot went fully into life. The overall time
requirement for testing the RPA robots was the same as the
time intended for robot developing, and thus, if one robot
took 10 hours to construct, an additional 10 hours was the
approximate time required for the testing. The follow-up
testing continued onto the RSO layer. Here, the integration of robots was tested to validate the ability of Enate to
communicate with both RPA platforms – Blue Prism and
UiPath.
4.6 Innovation and benefts (evaluation)
The original agreement between companies A and B did
not account for advancing the project into the production
phase – live operations. The main purpose of this pilot project was to show the potential and test the new platform
(Enate) in real conditions and to prove technical feasibility,
much as it is in proof-of-concept scenarios. Outputs from
this pilot project will be used in the future when company
B is planning to scale robot capacities within the broad HR
initiative, as was mentioned in the motivation section. The
RPA developer noted: “To achieve real results, there is a
need to scale the robots, which will proportionally increase
the value brought by the RSO.” This claim is supported by
the HR process owner from company B: “In the context of
our whole initiative in HR, we are talking about hundreds
of cases per month, where several robots will participate.
When this happens, Enate will run above K2, and other
systems and managers will have a global view on the human/robot execution of processes.”
The evaluation went on immediately after testing and
validation. According to the CEO of company A, the evaluation was split into two groups, namely, internal (company A) and external (company B) factors (Table 2). Internal
here means the amount of time resources dedicated towards this project in order to assess it on behalf of similar
future projects. Quantifcation was measured in Man Days
(MD), which represents one working day (8 hours) of one
employee. According to the RPA developer of the company A, this whole pilot project took 28 MD: 5 MD for the
process analysis, 13 MD for RPA development and 10 for
RSO implementation.
The external factors are further split into soft and hard
benefts. As the CEO of A company said, “The hard metrics
remain the same as usual – different sets of key performance
indicators (KPIs), processing time, quality, throughput, resource utilization or bottleneck identifcation.” A boost to
all of these metrics could be delivered by RPA and RSO, as
seen in the presented case. According to the process owner
of company B, the improvements in partial activities performed by robots are astonishing. The processing time of
the frst robotic workflow – entering data into the HR system (Target), was reduced from 15 minutes (done before
by humans) to 3 minutes (done now by a robot), without
any intervention needed. The OFAC check workflow time
was reduced from 5 minutes to 1 minute. Based on the
reported average number of cases per month (30-50), the
overall savings from these two workflows are 10 hours per
month, which could be recalculated to 1,25 MD saved for
every month. In the context of the entire onboarding process, these savings did not cause much improvement in the
processing time because the process is too complex. It still
takes several days or weeks to be completed and relies on
the participation of external subjects such as applicants,
external companies, medical check-ups, job interviews,
and so on. However, the most important qualitative beneft
according to the process owner and solution designer is
rooted in the reduction of error rates, in which the robots
contribute close to zero errors.
Another large beneft arises from the soft metrics. The
CEO of Company A shares thoughts on this topic: “Our
company could use this robotic capacity when human resources are over-utilized or when the HR department can’t
manage to onboard or train on time. Another huge feld of
opportunity is the highly repetitive tasks, which are still
done by humans and could cause burnout and other professional issues. This could be undertaken by robot capabilities, and in a time where work-life balance is a trend,
it could be communicated as an employee beneft.” Next,
advantages are provided to the HR managers, who can organize work in real time and obtain reports with analytics.
The RPA developer mentioned additional value for the
process participants, who execute the workflow, as it is an
opportunity to obtain support when guidance through the
process is needed. Then, the participant could ask directly for support through Enate to the IT department or colleague. The perspective of the process owner from compaUnauthentifiziert | Heruntergeladen 28.09.19 16:26 UTC
215
Organizacija, Volume 52 Research Papers Issue 3, August 2019
ny B is rather pragmatic. She said that with the shortening
of the processing time of key activities by transferring the
workload to robots within onboarding process, there is
additional space for recruiters to take care of applicants
and to serve them more quickly, which is a competitive
advantage in the labour market. Simplifcation of process
management is achieved as well. The HR process owner
claims that “I didn’t have to go through several systems to
manage the process. I will have everything organized on
one dashboard.” This feature is a great beneft because it
saves time for the manager, who is considered to be a more
expensive resource in the company.
The CEO of company A speaks about the innovation
in the approach taken in this project as one of the frst
of its type, when both human and robot workforces are
working together under one auspice. He explained the
situation by saying: “If we use BPMSs, we can manage
human resources and through this platform see everything
we need except for the work done by robots. On the other hand, RPA provides us with analytics and dashboards
to support our decision making, but only on the robotic
part. Enate is standing above both these systems to provide
managers with a complex picture of robots and humans
working together.” The interview shows that respondents
perceive RPA as a main provider of quantitative benefts
(improvement in the processing time) and RSO as a technology that brings qualitative benefts (better management
and quality). Even though the last part of the case study
is presenting an evaluation, it is meant to strengthen the
exploratory fndings. The authors consider the evaluation
of such a unique case important because it will affect the
future potential of this type of technology.
5 Discussion
The overall case study brings insight into the implementation of orchestration solution. This could inspire other
companies which are considering usage of RPA or RSO
technology and provide them with exemplary case outlying the course of implementation project. The theoretical
implications are predetermined by exploratory nature of
this study which helps authors deeply analyse this trendy
technology and grasp for the future research. It also uncovers the future potential for this technology and showcase
its strengths.
The limitations of this study are rooted in single case
study research, where every outcome arises from the one
particular case. Even though this case is a very specifc and
unique case, it draws the additional question of how these
outcomes are replicable and useful for future research. The
authors consider the pilot nature of the project to be a limitation because it could cause divergence in behaviour in
comparison with the fact that the involved participants will
anticipate that this project will transfer to live operations.
These questions can only be answered by further research
because of the RPA and the predominant RSO frame are
white space in the BPM community. Another limitation of
this study is the number of respondents from company B.
Authors interviewed only one respondent from company
B, which limits the conclusions.
For future research, the authors intend to work with the
premise that RPA and RSO are changing the BPM domain
from the standpoint of implementation/deployment approaches and/or critical success factors. Authors intend to
create a valid framework for implementing RPA as an effective automation tool. It should help companies adapt to
even more agile approach of automating business processes. Additionally, with increases in the numbers of robots
implemented and growing RPA initiatives in companies
such as company B, the need for robot/human orchestration will increase. Hence, multiple case study research or
research based on larger samples is required, which could
bring these assumptions to a more reliable and generalizable form.
RSO expansion is according to CEO of company A
not matter of present. Companies are occupied with digital transformation and implementing RPA, so RSO will
come after RPA achieves higher level of maturity, which
will lead to broader adoption. Authors predict that human/
robot orchestration will be an emerging topic in BPM
community.
In the interview, the solution designer stumbled upon
the forecast for the RSO. “The development of IT capacity and overall technology will move forward to a state
where robots will not only execute the workflow but also
assign the work across the company to both robots and
humans. This step needs considerable development of AI
and self-learning algorithms.” Another associated topic is
Company A | Company B | |||
Activities | Time con sumption |
Task | Done by human |
Done by robot |
Process analysis |
5 MDs | Enter data from K2 to Target |
15 min. | 3 min. |
Develop ing UiPath |
3 MDs | Perform the OFAC check |
5 min. | 1 min. |
Develop ing Blue Prism |
10 MDs | Number of cases per month |
30-50 cases | |
Develop ing Enate |
10 MDs | Savings | 1.25 MDs/per month |
|
Sum | 28 MDs |
Table 2: Summary of quantified evaluation
Unauthentifiziert | Heruntergeladen 28.09.19 16:26 UTC
216
Organizacija, Volume 52 Research Papers Issue 3, August 2019
a question of ethics and morale, because the robot in this
forecast serves more as a manager. This shift is considered
across society and is a controversial theme for discussion,
but as was said by the CEO of company A in the evaluation
section, robots are made for serving humans in automating
highly repetitive tasks, which are often quite unpleasant
and implacable for human workers. Another interesting
topic of future research could be how internally communicate changes in ration of human-to-software robots workforce.
6 Conclusion
Our research paper addresses the current trend in the feld
of automation of business processes among consulting and
technology companies – RPA, and adding an orchestration
layer assured by the RSO system Enate.
In presented exploratory case study, the main focus was
to explore the driving forces, the variables and the overall
approach, which are represented by a set of consecutive
phases and activities in implementing the pilot project
To distill the descriptive form of case study to the usable ideas which are signature for exploratory studies, authors extract these key insights:
• The implementation phase shows that the integration through API is a more reliable solution as
using screen scraping or screen recordings techniques. When using screen scraping, the RPA robots are depending on the stability of underlying
IS.
• The BPM maturity or previous experience is not
needed for RPA as it is „only“ the automation tool.
On the other hand, in terms of RSO, BPM maturity is needed. RSO have to build on existing process architecture or outgoing process initiative.
RPA is perceived by respondents as a tactical tool
but RSO is already implemented in the strategy
level of management.
• RSO is concurrent and RPA is complemented towards BPMS. The positioning of RPA and RSO
in comparison with BPMS is crucial. In analyzed case, there was mentioned about potential replacement of existing BPMS (K2) with RSO as
the RPA robots will scale up.
• The biggest advantage of RPA is agility and flexibility provided to users with its short implementation cycles. It enables the RPA to quick scale up
and to reach to the point where the robots have to
be manageable inhouse – potential for RSO platform.
• Focus on process modelling and description is a
key initial phase as the RPA is built on exact rules.
The selection of process needs to focus on the
ones precisely specifed. The AI in RPA or RSO
is still in its infancy and according to respondents,
RPA tools are still rule-based.
Next few years will show if RPA and RSO are considered
as a generally accepted tools for automating business processes and not only another package of existing technology, which is hyped by consulting and software houses.
Further rigorous view has to be taken in order to reliably
discover the benefts of this technology and how to achieve
them.
Acknowledgement
This paper was supported by the SGS project of Silesian
University in Opava, Czechia SGS/8/2018 “Advanced
Methods and Procedures of Business Processes Improvement”.
Literature
Aalst, W.M.P. van der, Bichler M. & Heinzl A. (2018).
Robotic Process Automation. Bus Inf Syst Eng,
60(4), 269-272, https://10.1007/s12599-018-0542-4
Abbott, K.R. & Sarin, S.K. (1994). Experiences with Workflow Management: Issues for the
Next Generation. In: Proceedings of the 1994
ACM Conference on Computer Supported Cooperative Work. (pp. 113-120). New York: ACM.
Aguirre, S. & Rodriguez, A. (2017). Automation of a Business Process Using Robotic Process Automation (RPA):
A Case Study. In Workshop on Engineering Applications, 27 September 2017 (pp. 65-71). Cham: Springer.
Asquith, A., Horsman, G. (2019). Let the robots do
it! – Taking a look at Robotic Process Automation and its potential application in digital forensics. Forensic Science International: Reports, https://doi.org/10.1016/j.fsir.2019.100007
Dumas, M., Rosa, M.L., Mendling, J. & Reijers, H. (2013). Fundamentals of Business
Process Management. New York: Springer.
Feagin, J.R., Orum, A.M. & Sjoberg, G. (1991). A Case
for the Case Study. Chapel Hill: UNC Press Books.
Fersht, P. & Slaby, R.J. (2012). Robotic automation emerges
as a threat to traditional low-cost outsourcing. Bangalore:
HfS Research. Retrieved from https://www.horsesforsources.com/wp-content/uploads/2016/06/RS-1210_
Robotic-automation-emerges-as-a-threat-060516.pdf
Fernandez, D. & Aman, A. (2018). Impacts of Robotic Process Automation on Global Accounting Services. Asian
Journal of Accounting and Governance, 9(1), 127-
140. http://dx.doi.org/10.17576/AJAG-2018-09-11
Hindle, J., Lacity, M., Willcocks, L. & Khan, S. (2018). ROBOTIC PROCESS AUTOMATION: Benchmarking the
Client Experience. London: Knowledge Capital Partners.
Houy, C., Hamberg, M. & Fettke, P. (2019). Robotic Process Automation in Public Administrations. Gesellschaft für Informatik e.V.
Lacity, M., Willcocks, L.P. & Craig, A. (2015a). Robotic process automation: mature capabilities in the energy secUnauthentifiziert | Heruntergeladen 28.09.19 16:26 UTC
217
Organizacija, Volume 52 Research Papers Issue 3, August 2019
tor. London: LSE Library. Retrieved from http://eprints.
lse.ac.uk/64520/1/OUWRPS_15_06_published.pdf
Lacity, M., Willcocks, L.P. & Craig, A. (2015b).
Robotic Process Automation at Telefónica O2. MIS Quarterly Executive, 15(1), 21-35.
Lacity, M. & Willcocks L.P. (2017). A new approach
to automating services. London: LSE Library. Retrieved from http://eprints.lse.ac.uk/68135/1/
W i l l c o c k s _ N e w % 2 0 a p p r o a c h _ 2 0 1 6 . p d f
Lamberton, C. (2016). Get ready for robots: Why planning makes the difference between success and disappointment, London: Ernst & Young. Retrieved from
https://www.ey.com/Publication/vwLUAssets/Get_
ready_for_robots/$FILE/ey-get-ready-for-robots.pdf
Le Clair, C. (2017). The Forrester wave: robotic process automation: the 12 providers that matter
most and how they stack up. Cambridge: Forrester. Retrieved from http://www.bluvaultsolutions.
com/wp-content/uploads/2017/11/Robotics.pdf
Mendling, J., Decker, G., Hull, R., Reijers, H.A. & Weber,
I. (2018). How do Machine Learning, Robotic Process Automation, and Blockchains Affect the Human
Factor in Business Process Management? Communications of the Association for Information Systems,
43, 297–320, https://doi.org/10.17705/1CAIS.04319
Michalos, G., Makris, S., Spiliotopoulos, J., Misios,
I., Tsarouchi, P. & Chryssolouris, G. (2014). ROBO-PARTNER: Seamless Human-Robot Cooperation
for Intelligent, Flexible and Safe Operations in the
Assembly Factories of the Future. Procedia CIRP,
23(1), 71–76, https://10.1016/j.procir.2014.10.079
Moftt, K. C., Rozario, A. M., & Vasarhelyi, M. A.
(2018). Robotic Process Automation for Auditing.
Journal of Emerging Technologies in Accounting,
15(1), 1-10. https://doi.org/10.2308/jeta-10589
Pellegrinelli, S., Moro, F. L., Pedrocchi, N., Molinari Tosatti, L. & Tolio, T. (2016). A probabilistic approach to workspace sharing for human–robot cooperation in assembly tasks. CIRP Annals,
65(1), 57–60, https://10.1016/j.cirp.2016.04.035
Ranerup, A., Henriksen, H. Z. (2019). Value positions
viewed through the lens of automated decision-making:
The case of social services. Government Information
Quarterly, https://doi.org/10.1016/j.giq.2019.05.004
Saunders, M., Lewis, P. & Thornhill, A.
(2016). Research Methods for Business Students (7th ed.). Edinburgh: Pearson.
Schmitz, M., Dietze, C. & Czarnecki, C. (2019). Enabling
Digital Transformation Through Robotic Process Automation at Deutsche Telekom. In N. Urbach & M.
Röglinger (Eds.), Digitalization Cases: How Organizations Rethink Their Business for the Digital Age,
Management for Professionals (pp. 15 – 33): Springer, https://doi.org/10.1007/978-3-319-95273-4_2
Schramm, W. (1971). Notes on Case Studies of Instructional Media Projects. Stanford: California Institute for Communication Research.
Tornbohm, C., Dunie, R. (2017). Gartner market guide for robotic process automation software. Stamford: Gartner. Retrieved from https://
www.gartner.com/en/documents/3835771/market-guide-for-robotic-process-automation-software
Vom Brocke, J., Maaß, W., Buxmann, P., Maedche, A., Leimeister, J. M. & Pecht, G. (2018).
Future Work and Enterprise Systems. Business & Information Systems Engineering, 60(4),
357–366, https://10.1007/s12599-018-0544-2
Yin, R.K. (2014). Case Study Research: Design and Method (5th ed.). London: Sage.
Dalibor Šimek, PhD Student at the Department of
Business Economics and Management at Silesian
University in Opava, School of Business Administration
in Karvina, Czech Republic. He is leading the project
funded by Silesian University Grant System in area of
Business Process Management. Research interests:
Business Process Management, Robotic Process
Automation, Process Improvement.
Roman Šperka, Associate Professor and Head of the
Business Economics and Management Department
at Silesian University in Opava, School of Business
Administration in Karvina, Czech Republic. He has
participated in several EU and institutional projects. He
is Programme Co-Chair of the KES-AMSTA conference.
Research interests: business process management,
process mining, modelling and simulation of social
systems.
Unauthentifiziert | Heruntergeladen 28.09.19 16:26 UTC
View publication stats