Robotic Process Automation and Business Rules: A Perfect Match

Abderrahmane Leshob

1,2

, Maxime Bédard

1,2

and Hafedh Mili

Laboratory for Research on Technology for Ecommerce, University of Quebec at Montreal, Montreal, Canada

UQAM School of Management (ESG UQAM), Montreal, Quebec, Canada

Keywords:

Robotic Process Automation, Business Process, Business Rules, Goal-oriented Requirements Language.

Abstract:

Robotic Process Automation (RPA) is a new technology that uses software robots to perform certain tasks

in business processes. These robots mimic how humans use software systems when performing repetitive

tasks with “robotic” precision, thereby limiting errors and improving efﬁciency. RPA provides many beneﬁts

including increased productivity, better service quality, and decreased delivery time while automating business

processes. However, there are several challenges in adopting RPA, the ﬁrst and foremost of which is to identify

the kinds of tasks that lend themselves to RPA. In this paper, we present a novel easy-to-use method that

identiﬁes the most suitable processes for RPA; as such, our method will help organizations to effectively adopt

RPA. More precisely, this research proposes to compute an RPA score to assess if a process is suitable for

RPA. Moreover, this paper aims to provide guidelines for RPA implementation. The novelty of this work

is threefold: i) it uses an extensible classiﬁcation of business rules to weight the RPA score, ii) It is usable

and ﬂexible (e.g., we can extend it to support Intelligent Digital Robots -RPA 2- ), and iii) it automatically

computes the RPA score using the Goal-Oriented Requirements Language (GRL) model evaluation.

1 INTRODUCTION

RPA is an emerging technology that uses software

robots to capture and interpret existing applications

for processing transactions, manipulating data

and communicating with other software systems

(IRPAAI, 2018). These software robots are used

to perform work that requires manual labor and to

automate repetitive tasks across multiple business

applications without altering existing infrastructure

and systems. RPA provides many beneﬁts including

increased productivity, better service quality,

decreased delivery time while automating business

processes and freeing employees from tedious

and repetitive tasks (IRPAAI, 2018). For Anagnoste

(Anagnoste, 2018), one of the reasons why companies

are starting to use RPA massively is because of the

fact that robots can work 24/7 cutting entry costs to

70 percent.

For Alberth and Mattern (Alberth and Mattern,

2017), the RPA automation logic is still mainly

rule-based and robots can relieve workers to do

routine process work. According to Aguirre and

Rodriguez (Aguirre and Rodriguez, 2017), RPA ﬁts

well with rule-based processes that involve routine

tasks, structured data and deterministic outcomes.

According to Geyer-Klingeberg et al. (Geyer-

Klingeberg et al., 2018), successful process

automation requires assessing the potential

for automation. In this context, organizations

are constantly looking to effectively identify

processes that can be automated using RPA to

achieve maximum results (Leshob et al., 2018).

Unfortunately, to date and to the best of our

knowledge, there is no easy-to-use and automatic

method that guides practitioners to identify business

processes that are most suitable for RPA.

This paper proposes a semi-automatic and easy-

to-use method that computes an RPA score to assess

if a process is suitable for RPA. We also provide

guidelines for RPA implementation by assigning

business rule classes to process activities. The

proposed method uses i) business rules that govern

process activities to weigh the RPA score and ii)

the Goal-Oriented Requirements Language (GRL) to

link process activities to RPA objectives/goals and

to automatically compute the RPA score using GRL

model evaluation.

The remainder of the paper is organized as

follows. Section 2 describes the proposed rule-based

framework to compute the RPA score of business

processes in order to measure their suitability for

Leshob, A., Bédard, M. and Mili, H.

Robotic Process Automation and Business Rules: A Perfect Match.

DOI: 10.5220/0009886701190126

In Proceedings of the 17th International Joint Conference on e-Business and Telecommunications (ICETE 2020) - Volume 3: ICE-B, pages 119-126

ISBN: 978-989-758-447-3

119

RPA. Section 3 surveys related work. We conclude

in Section 4.

2 PROPOSED APPROACH: A

RULE-BASED FRAMEWORK

TO ADOPT RPA

We propose a four-step method to assign an “RPA

suitability score” to business processes to help

organizations identify those among their processes

that lend themselves to RPA. We start by providing

an overview of the method (Section 2.1). Section

2.2 presents the foundations of the method. The

four steps of the method are described in sections 2.3

through 2.6.

2.1 Overview of the Method

A business process is a set of activities that together

produce a result of value to a “customer” (Hammer

and Champy, 1993). Business process involves

automated activities, performed by an automated

(information or otherwise) system, and user activities

which are process activities performed by a human

actor, possibly with the help of one or several

information systems. RPA concerns such user

activities and our method is concerned with scoring

such activities.

Our approach relies on assigning an RPA score

to user activities to assess whether they can be

automated with RPA; the higher the score, the higher

priority for RPA adoption. We consider the RPA score

as a combination of two factors: 1) RPA potential,

which measures the feasibility of automation, and

2) RPA relevance, which assesses whether RPA

automation is worthwhile. The RPA potential is

a reﬂection of whether the activity lends itself to

automation, i.e., involves well-deﬁned (business)

logic. RPA relevance is a ‘cost-beneﬁt’ issue: is

the activity in question performed enough times to

warrant investment in automation.

Figure 1 illustrates the overall approach. The ﬁrst

step assigns a business rule class (or classes) to each

user activity of a process. This will enable us to

weigh the potential of automating user activities with

RPA. The second step assesses the relevance of using

RPA for each user activity. The third step uses a

goal-oriented language to create a goal model that

links process activities to RPA goals (i.e., the potential

and the relevance). More precisely, our approach

proposes to use the Goal-Oriented Requirements

Language (GRL) (ITU-T, 2012). The fourth step

computes the RPA score of the business process using

a native GRL model evaluation algorithm.

2.2 Classifying User Activities

Broadly speaking, RPA is suitable for those user

activities that are “automatable”. A number of

research efforts aimed at identifying the required

characteristics of process activities that lend

themselves to RPA. Table 1 summarizes those

criteria.

Roughly speaking, the criteria for automation fall

into two categories: 1) the mechanics of the user

activity, and 2) the cognitive or decisioning content

of the activity. In particular, the mechanics of the user

activity have to be well-deﬁned, and this is reﬂected

in criteria C1 (availability of a system or systems to

support the activity), C5 (well-speciﬁed interactions),

and C6 (digital availability of relevant data). The

cognitive/decisioning aspects are captured by criteria

C2 (low cognitive requirement), C3 (stable context),

and C4 (well-deﬁned rules).

The mechanics of a user activity are relatively

easy to assess. However, the nature of the

cognitive/decisioning content of a user activity is

more complex to assess. This is the aspect that we

propose to tackle.

The business rules approach advocates the

representation of the decision logic within

repeatable business processes using the business

rules formalism. The business rules approach

covers the full lifecycle of decision logic, from the

requirements stage (rule discovery or capture) to

automation (execution), testing and maintenance

(Boyer and Mili, 2011). Indeed, when the decision

logic that underlies a business process activity can

be fully expressed using business rules that refer

to digitally available data, then the decision can be

automated using rule languages and rule engines.

By contrast, if a business decision involves creativity

or complex interpretation skills (see criterion C2 in

Table 1), then the decision can hardly be formalized,

let alone be automated.

Accordingly, we propose to look at the RPA

potential of user activities through the lens of the

business rules approach: if the decision that underlies

a user activity lends itself to automation under the

business rules approach, then it lends itself to RPA–

regardless of the technology used by RPA.

Business rules fall into many categories,

depending on different characteristics, including

their scope (e.g., data versus behavior), modality

(guideline versus mandatory), and others (Hay

and Healy, 2000; Wagner, 2005; Van Eijndhoven

ICE-B 2020 - 17th International Conference on e-Business

120

Figure 1: Overall process for assessing business processes suitability for RPA.

Table 1: Criteria to assess RPA suitability of process activities. Adapted from (Asatiani and Penttinen, 2016; Leshob et al.,

2018).

Id Criteria Description

C1 Access/use of software

applications

The activity is performed by a human actor with the use of a

system or multiple systems.

C2 Low cognitive requirements The activity does not require creativity or complex

interpretation skills.

C3 Stable context The activity is executed within stable context (e.g., systems).

C4 Well-deﬁned and stable rules The activity is based on unambiguous rules.

C5 Well-speciﬁed interactions with

software applications

The interactions between the activity and the applications are

well-speciﬁed and predictable.

C6 High availability of digital data The activity uses available digital and correct data.

et al., 2008; Steinke and Nickolette, 2003). We

argue that the different categories have different

automation–and thus RPA–potential, and thus,

propose to categorize the decision logic inherent a

user activity, as a ﬁrst step towards assessing the

suitability of a user activity for RPA. But ﬁrst, we

must: 1) adopt a categorization of business rules, and

2) assign an automation score for each category. We

discuss both steps in turn below.

Many business rule classiﬁcations have been

proposed in the literature, including (Hay and Healy,

2000; Wagner, 2005; Van Eijndhoven et al., 2008;

Steinke and Nickolette, 2003; Boyer and Mili, 2011).

According to Graml, Bracht, and Spies (Graml et al.,

2008), a business rule is deﬁned in two different ways

depending on which perspective to be addressed: i)

from the business perspective, a rule should be seen

as a directive, intended to govern, guide or inﬂuence

the business behavior, ii) from the IT perspective, a

rule is deﬁned as an atomic piece of reusable business

logic that is speciﬁed declaratively. Hay and Healy

(Hay and Healy, 2000), classiﬁed business rules in

three categories: structural assertion, action assertion,

and derivation. A structural assertion is a concept or

a statement of a fact that expresses some aspect of

the structure of an enterprise. An action assertion is

a statement of a constraint or condition that limits or

controls the actions of the enterprise. A derivation is

a statement of knowledge that is derived from other

knowledge in the business.

In (Steinke and Nickolette, 2003), authors

proposed four classes of business rules: Deﬁnition,

Guideline, Inference, and Mandate. Deﬁnition

includes all terms that are speciﬁc to the business.

Guidelines are the rules that should be followed in

most contexts but occasionally needs to be overlooked

in a particular situation. Mandates are action rules

that cannot be ignored in any circumstances to avoid

repercussions on the business. An inference is a rule

that creates a new value/fact that is derived using one

or more business rules.

In (Wagner, 2005), Wagner classiﬁes business

rules in ﬁve categories: integrity rules, derivation

rules, reaction rules, production rules, and

transformation rules. Integrity rules express

constraints to data and its interrelationships.

Derivation rules create derived facts by using one

or multiple already known facts. Reaction rules or

more commonly called event-condition-action rules

(ECA Rules) verify a condition once a particular

event is triggered. After the condition is veriﬁed, an

action is initiated. Production rules, or also called

condition-action rules, verify a condition before

initiating an action. Unlike reaction rules, production

Robotic Process Automation and Business Rules: A Perfect Match

121

Figure 2: Business rules classiﬁcation.

rules do not need any particular event to take place

to start testing a condition. Transformation rules set

limitations to the alteration of an object in a system.

In (Van Eijndhoven et al., 2008), authors split

business rules into two main categories: Rules that

inﬂuence the operational process and constraints.

Rules that inﬂuence the operational process include

derivation rules and action rules. Derivation rules use

deduction and/or computation to enact information of

a particular process. There are two different types

of action rules: condition-action rules and event-

condition-action (ECA) rules. The second category is

constraints. Those rules restrain an organization or a

system by setting limits to its structure, behavior and

information.

To illustrate the feasibility of our method, we

elaborated a ﬁrst sketch of an RPA classiﬁcation

model as shown in Figure 2. Recall that all

process activities that govern RPA rules are user

tasks. Therefore, all RPA rules of the proposed

classiﬁcation model are triggered and/or performed

totally or partially by human actors.

1. RPA production rules are condition-action rules

that operate within a context (i.e., systems) to

produce new facts. RPA production rules use

digital data through well-speciﬁed interactions

with software applications.

2. RPA Derivation rules (RPA computation or

inference) create new derived facts from input

facts using rules. The difference with production

rules is that they have no conditions that trigger

the actions.

3. RPA Guideline rules are rules that operate within

a stable context, use digital data through well-

speciﬁed interactions with software applications.

However, RPA Guidelines are not stable rules and

are not well-deﬁned (see (Steinke and Nickolette,

2003)).

To better explain our approach and for the sake of

simplicity, we will support activities that require low

Table 2: RPA business rules.

Business rule Criteria

Weight

class C3 C4 C5 C6

RPA

Production

25 25 25 25 100

RPA

Derivation

25 25 25 25 100

RPA

Guideline

25 0 25 25 75

cognitive requirements. We argue that this does not

represent a limitation of our approach since RPA

2.0 robots support intelligent/high cognitive process

activities. Therefore, our approach deals with user

activities (i.e., the criterion C1) with low cognitive

requirements (i.e., the criterion C2) (see Figure 1).

Table 2 shows an example of RPA business rules

and their associated RPA potential weights. As

illustrated, we assigned a maximum importance value

of 25 to each criterion. However, users of our method

(e.g., business analysts) can change these default

values.

2.3 Step 1: Assign Business Rule

Classes to the Decision Logic

Underlying Process Activities

This step consists of categorizing the decision logic

that underlies a user activity by identifying the types

of business rules (business rule classes) that are

inherent in that decision. This will enable us to assess

the RPA potential of user activities using the values

from Table 2. A single decision (activity) may involve

different types/classes of business rules. In this case,

the RPA potential score may be computed using a

weighted average of the values from Table 2.

A key aspect of our approach is our claim that it is

easy to implement by users (e.g., business analysts,

process engineers) without having to become RPA

specialists. Thus, to assign business rules classes

to process activities, we adopted a question-based

approach using rule deﬁnitions to guide the users to

select the rules that match the process activities.

Consider the credit card approval process of

Figure 3. This process is based on a service task

activity (i.e., automatic task) and a user task activity

(i.e., performed by a human actor with the use

of software applications). The process starts by

receiving a credit card application. The ﬁrst activity

(the service task), then retrieves the applicant credit

history. After that, an employee assesses the applicant

credit card eligibility. To perform this task, the

employee applies production rules that are based on

ICE-B 2020 - 17th International Conference on e-Business

122

whether the credit ﬁle history is local (i.e., retrieved

from the ﬁnancial institution country) or retrieved

from a foreign country. Therefore, the RPA weight of

the activity ‘Assess Applicant Credit Card Eligibility’

is set to 100 (see Table 2).

2.4 Step 2: Assess the RPA Relevance of

the Activities

To assign a relevance score to an activity/sub-

process activity, we use a variation of the approach

proposed in (Leshob et al., 2018). According

to Asatiani and Penttinen (Asatiani and Penttinen,

2016), non-routine tasks with no or little recurring

patterns are not relevant for automation with RPA.

According to Willcocks et al. (Willcocks, 2015;

Willcocks et al., 2017) and Asatiani and Penttinen

(Asatiani and Penttinen, 2016), the RPA approach

is suitable when i) business processes have a high-

volume of transactions with manual affordance and

ii) the process activities are prone to human errors.

Thus, to assess the RPA suitability of an activity,

we propose to measure: i) the average number of

transactions performed per day and ii) its proneness

to human errors. To assess these two metrics, we

experimented the resulting quadrant illustrated in

(Leshob et al., 2018) in the context of processes from

major companies from the banking and insurance

domains. In order to propose a method that is

easy-to-use and adaptable, we propose to assess the

RPA potential of process activities using the model

illustrated in Figure 4.

2.5 Step 3: Create the GRL Model

To compute the RPA score of a business process, we

propose to use a goal-oriented modeling language.

More precisely, we propose to use the Goal-Oriented

Requirements Language (GRL) (ITU-T, 2012). GRL

allows to i) connect each process activity to the RPA

goals (e.g., RPA relevance, RPA Potential) through

quantiﬁed links, ii) visualize process activities, RPA

goals and the links that connect them using a

graphical GRL model, and iii) automatically calculate

the RPA score using a GRL evaluation algorithm.

2.5.1 Goal-oriented Requirements Language

GRL (ITU-T, 2012) allows to model the objectives,

requirements, and their relationships. Figure 5

presents the subset of the GRL intentional elements

used by our approach. A goal (or hard-goal) is

quantiﬁable. It is usually related to functional

requirements. Soft-goal refers to qualitative aspects

that cannot be measured directly (Amyot et al.,

2010). Soft-goals are usually related to non-

functional requirements. A task is a solution which

achieves goals or satisﬁes soft-goals (Amyot et al.,

2010).

Figure 6 illustrates the basic GRL links and

contribution types used by our approach. GRL links

(section a), such as the contribution and means-end

links are used to connect GRL elements (e.g., goals,

soft-goals, and tasks) in a goal model. Means-

End links describe how goals are achieved (Amyot

et al., 2010). It is used by tasks achieving goals.

Means-ends should only have goals as destinations

(Amyot et al., 2010). Contribution links specify

desired impacts of one element on another element

(Amyot et al., 2010). A contribution link can have a

qualitative contribution type (Section b of Figure 6),

or a quantitative contribution (integer values between

-100 and 100) (Amyot et al., 2010). A contribution

link can be labeled using icons, numbers, or texts.

2.5.2 Build the Goal Model

The goal of this step is to create a GRL model that

links user activities to the RPA high-level objective

(RPA SUITABILITY) that assesses if the process is

suitable for RPA automation. The resulting goal

model links each user activity (hard-goal or simply

goal) to the RPA RELEVANCE and RPA POTENTIAL

(soft-goals); two subgoals of the high-level soft-goal

RPA SUITABILITY. To connect process activities to

RPA objectives, we use GRL tasks (solutions) that

achieve the goals (through means-end links) or satisfy

soft-goals (through contribution links).

After creating the GRL model, the user must

quantify it by assigning initial values to the

contribution links and intentional elements (goals,

soft-goals and solutions). The quantitative values of

the contribution links between the GRL tasks and

the RPA POTENTIAL soft-goal are based on the

weight of the rule class associated to the process

activity (see Table 2). The quantitative values of the

contribution links between the GRL tasks and the

RPA RELEVANCE soft-goal are based on the quadrant

(see Figure 4). For the importance values of the

intentional elements (goals, soft-goals and solutions),

we propose a default quantitative value of 100, which

is the higher importance value. The modeller (e.g.,

business analyst) can modify these default values. For

example, the user can assign different values if he/she

wants to prioritize the automation of certain tasks.

Figure 7 shows an example of a GRL model for

the activity ‘Assess Applicant Credit Card Eligibility’

of the Credit Card Approval process of Figure 3.

Robotic Process Automation and Business Rules: A Perfect Match

123

Figure 3: A Generic Credit Card Application Process.

Figure 4: RPA relevance quadrant.

Figure 5: Basic GRL Intentional Elements (adapted from

(Amyot et al., 2010)).

2.6 Step 4: Evaluate the GRL Model

GRL provides algorithms to evaluate models,

allowing us to compute the RPA score of the business

process. To evaluate the RPA score of a process,

we propose to use the quantitative GRL evaluation

algorithm described in (Amyot et al., 2010). This

algorithm uses Integer values for the evaluation. In

our case, the RPA score of a process is based on i) the

values of the contribution links and ii) the quantitative

importance value of the intentional elements.

The algorithm starts by propagating values using

a bottom-up approach to obtain evaluation values for

the intentional elements (see (Amyot et al., 2010)).

The evaluation values are propagated through GRL

links. For example, the evaluation value of the soft-

goal RPA RELEVANCE is computed by i) multiplying

the evaluation value of the solution Credit Card

Approver (i.e., 100) by the value of the contribution

link that connects them together (i.e., 75) and ii) then

dividing the result by 100 (i.e., (100 x 75) /100).

Figure 6: GRL Links and Contributions Types (adapted

from (Amyot et al., 2010)).

Figure 7: The GRL model for the activity ‘Assess Applicant

Credit Card Eligibility’.

The evaluation value of the soft-goal (sgoal.evValue)

reached by N contribution links is the sum of the

products of the evaluation value of each source

element (srcElt

.evValue) by its contribution value to

the element (elt

.cnValue). Then, the result is divided

by (N X 100). Therefore, the evaluation value of a

soft-goal (sgoal) is computed as follows:

sgoal.evValue =

∑

i=1

srcElt

.evValue × elt

.cnValue

Nx100

The algorithm ensures that the evaluation value of

ICE-B 2020 - 17th International Conference on e-Business

124

each goal will not go above 100. The algorithm also

ensures that the evaluation values of each intentional

element will not go below −100 where negative values

from -100 to 0 are used.

After propagating values, the RPA score is

calculated using the quantitative evaluations for actors

proposed in (Amyot et al., 2010). Thus, we compute

the RPA score of processes using the importance

and the evaluation values of its intentional elements

(goals, soft-goals, and tasks). Therefore, the RPA

score of a business process P is computed as follows:

rpaScore(p) =

∑

i=1

.impValue × ie

.evValue

∑

i=1

.impValue

where ie.impValue and ie.evValue are the importance

value and the evaluation value of the intentional

element ie respectively.

Finally, we propose to classify the RPA suitability

of a process P as follows.

1. If r paScore(p) >= 70, the process is considered

as highly suitable for the RPA approach.

2. If 50 < rpaScore(p) < 70, the process is

considered as moderately suitable for the RPA

approach.

3. If r paScore(p) <= 50, the process is considered

as not suitable for the RPA approach.

3 RELATED WORK

RPA is a new emerging approach to automate

business processes. Hence, a limited number of works

have been proposed in the RPA literature to tackle

the problem of assessing if business processes are

suitable for RPA. According to (Willcocks et al.,

2017; Willcocks, 2015; Lacity and Willcocks, 2016),

RPA ﬁts well when: i) the process is mature and

standardized, ii) the volume of transactions is high,

and iii) the business rules that govern the process

activities are well-deﬁned. For Willcocks et al.,

(Lacity and Willcocks, 2016), processes with high

workload and low complexity are good candidates for

RPA automation. Lowers et al. (Lowers et al., 2016),

suggest that the business function and the industry

are important to determine if the RPA approach is

appropriate. According to (Lowers et al., 2016), RPA

is relevant for standardized and repetitive processes

that i) follow well-deﬁned business rules, ii) consume

a signiﬁcant amount of time, and iii) require manual

interaction with a computer interface.

In (Leshob et al., 2018), authors proposed a

method to analyze business processes and classify

them from ‘Not suitable’ to ‘Highly suitable’ using an

RPA quadrant. The classiﬁcation is based on: i) the

process maturity and standardization, ii) the business

rules that govern process activities, iii) the use of

interfaces with a software application, iv) the volume

of transactions, and v) the degree of the process

complexity (Leshob et al., 2018).

In (Asatiani and Penttinen, 2016), authors

proposed a set of criteria to assess if a process

task is suitable for RPA. These criteria include

the: high volume of transactions, need to access

multiple systems, low cognitive requirements, easy

decomposition into unambiguous rules, proneness

to human error, and the limited need for exception

handling. In (Madakam et al., 2019), authors

identiﬁed some processes that are more suitable for

RPA based on the business function/industry. These

processes include: accounts payable and receivable,

invoice processing, purchase to order, payroll, hiring,

customer service, cards activation, claims processing,

and some speciﬁc processes from the banking and

insurance domains. The author also pointed out

that the rise of artiﬁcial intelligence (AI) will enable

new functions for RPA as digital robots will become

intelligent, allowing them to achieve complex and

cognitive tasks such as processing unstructured data.

4 CONCLUSION AND FUTURE

WORK

RPA is an emerging approach for automating business

processes. It uses software robots that replace

humans in order to interact with existing applications

through user interfaces for processing transactions,

manipulating data and communicating with other

systems (IRPAAI, 2018). RPA offers many beneﬁts

including improved efﬁciency, increased productivity,

data security, reduced cycle time, and improved

accuracy (IRPAAI, 2018).

In this paper, we proposed a novel rule-based

method that helps organizations to adopt RPA. More

precisely, the method proposed to compute an RPA

score to assess if a process is suitable for RPA. The

score is based on two goals: RPA Potential and RPA

Relevance. The beneﬁts of this work is threefold: i) it

uses generic and extensible classiﬁcation of business

rules that govern process activities to weight the RPA

score, ii) It is easy-to-use and ﬂexible (e.g., we can

extend it to support Intelligent Digital Robots -RPA

2- by adapting the business rule classiﬁcation), and

iii) it automatically computes the RPA score using a

native GRL model evaluation algorithm.

This work is still at an early stage. To advance

Robotic Process Automation and Business Rules: A Perfect Match

125

our research project to design a complete end-to-

end method, we plan to: i) improve the business

rules classiﬁcation by linking it to RPA properties,

ii) support high cognitive tasks as we believe that

artiﬁcial intelligence will enable software robots to

automate more work of humans in the near future,

iii) develop a tool that supports the method, and iv)

evaluate the method.

ACKNOWLEDGMENTS

This research was supported by the Natural Sciences

and Engineering Research Council of Canada

(NSERC).

REFERENCES

Aguirre, S. and Rodriguez, A. (2017). Automation of

a business process using robotic process automation

(RPA): A case study. In Communications in Computer

and Information Science, pages 65–71. Springer

Verlag.

Alberth, M. and Mattern, M. (2017). Understanding robotic

process automation (RPA). Journal of Financial

Transformation, 46:54–60.

Amyot, D., Ghanavati, S., Horkoff, J., Mussbacher,

G., Peyton, L., and Yu, E. (2010). Evaluating

goal models within the goal-oriented requirement

language. International Journal of Intelligent

Systems, 25(8):841–877.

Anagnoste, S. (2018). Setting Up a Robotic Process

Automation Center of Excellence. Management

Dynamics in the Knowledge Economy, 6(2):307–322.

Asatiani, A. and Penttinen, E. (2016). Turning robotic

process automation into commercial success - Case

OpusCapita. Journal of Information Technology

Teaching Cases.

Boyer, J. and Mili, H. (2011). Agile Business Rule

Development. Springer-Verlag Berlin Heidelberg.

Geyer-Klingeberg, J., Nakladal, J., Baldauf, F., and Veit,

F. (2018). Process mining and Robotic process

automation: A perfect match. In 16th International

Conference on Business Process Management (BPM),

pages 124–131, Sydney, Australia. CEUR-WS.

Graml, T., Bracht, R., and Spies, M. (2008). Patterns

of business rules to enable agile business processes.

Enterprise Information Systems, 2(4):385–402.

Hammer, M. and Champy, J. (1993). Reengineering the

Corporation : A Manifesto For Business Revolution.

Harper Business.

Hay, D. and Healy, K. A. (2000). Deﬁning Business Rules :

What are they really? Technical report, The Business

Rules Group.

IRPAAI (2018). Robotic Process Automation in the Real

World: How 3 Companies are Innovating with RPA.

ITU-T (2012). ITU-T,User Requirements Notation (URN)–

Language deﬁnition.

Lacity, M. C. and Willcocks, L. P. (2016). Robotic

process automation at telefónica O2. MIS Quarterly

Executive.

Leshob, A., Bourgouin, A., and Renard, L. (2018).

Towards a Process Analysis Approach to Adopt

Robotic Process Automation. In Proceedings - 2018

IEEE 15th International Conference on e-Business

Engineering, ICEBE 2018, pages 46–53. Institute of

Electrical and Electronics Engineers Inc.

Lowers, P., Cannata, F. R., Chitre, S., Barkham, J., Deloitte,

L., and D (2016). Automate this - The business

leader’s guide to robotic and intelligent automation.

Technical report.

Madakam, S., M. Holmukhe, R., and Kumar Jaiswal, D.

(2019). The Future Digital Work Force: Robotic

Process Automation (RPA). Journal of Information

Systems and Technology Management, 16.

Steinke, G. and Nickolette, C. (2003). Business rules as

the basis of an organization’s information systems.

Industrial Management and Data Systems, 103(1-

2):52–63.

Van Eijndhoven, T., Iacob, M. E., and Ponisio, M. L.

(2008). Achieving business process ﬂexibility with

business rules. Proceedings - 12th IEEE International

Enterprise Distributed Object Computing Conference,

EDOC 2008, pages 95–104.

Wagner, G. (2005). Rule modeling and markup. In Lecture

Notes in Computer Science, pages 251–274. Springer

Berlin Heidelberg.

Willcocks, L. (2015). Robotic Process Automation at

Xchanging. MIS Quarterly Executive.

Willcocks, L., Lacity, M., and Craig, A. (2017). Robotic

process automation: Strategic transformation lever for

global business services? Journal of Information

Technology Teaching Cases.

ICE-B 2020 - 17th International Conference on e-Business

126