AN EVOLUTIONARY APPROACH

FOR BUSINESS PROCESS REDESIGN

Towards an Intelligent System

Mariska Netjes

, Selma Limam Mansar

, Hajo A. Reijers

and Wil M. P. van der Aalst

Department of Technology Management, Eindhoven University of Technology, Eindhoven, The Netherlands

Business Sciences College, Zayed University, Dubai, UAE

Keywords:

Business Process Redesign, Process Modelling, Business Process Management, Workﬂows, Best Practices.

Abstract:

Although extensive literature on BPR is available, there is still a lack of concrete guidance on actually chang-

ing processes for the better. It is our goal to provide a redesign approach which describes and supports the

steps to derive from an existing process a better performing redesign. In this paper we present an evolutionary

approach towards business process redesign and explain its ﬁrst three steps: 1) modelling the existing process,

2) computing process measures, and 3) evaluating condition statements to ﬁnd applicable redesign “best prac-

tices”. We show the applicability of these steps using an example process and illustrate the remaining steps.

Our approach has a formal basis to make it suitable for automation.

1 INTRODUCTION

Although numerous papers and books on Business

Process Redesign (BPR) were published during the

past 15 years (e.g. (Grover et al., 1995; Kettinger

et al., 1997; Al-Mashari and Zairi, 1999)), guidance

for concrete process redesign is scarce. Valiris and

Glykas (Valiris and Glykas, 1999) identify that “there

is a lack of a systematic approach that can lead a

process redesigner through a series of steps for the

achievement of process redesign”. This paper ﬁts

within our aim to ﬁll this void by providing a redesign

approach which describes and supports the steps to

derive from an existing process a better performing

one.

A key element of the approach that we propose in

this paper is the generation of diagnostic information

on an existing business process. Such a diagnosis is

performed using so-called process measures, which

provide a global view on the characteristics of the

process. Actual values for the process measures may

reveal weaknesses in the process. Identiﬁed weak-

nesses are removed by the application of one or more

redesign best practices. A redesign best practice de-

scribes a well-tried way to remove a particular prob-

lem from a process to improve its performance. In

our earlier work we have described 29 redesign best

practices and presented a qualitative description, the

potential effects and possible drawbacks for each best

practice (Reijers and Limam Mansar, 2005). Finally,

in our approach, the application of redesign best prac-

tices leads to one or more alternative candidates for

the existing process. The evaluation of the perfor-

mance of each alternative shows the best candidate

process which should replace the existing one.

Our approach builds on the formal representation

of a business process with Petri nets, in particular

WorkFlow nets (Aalst, 1998). Some of the features

of our model are inspired by the process modelling

tool Protos (Pallas-Athena, 2004). Current versions

of Protos are in use by thousands of organizations in

more than 25 countries. In The Netherlands alone,

more than half of all municipalities and insurance

companies use Protos for the speciﬁcation of their

business processes. The focus on this real-life tool

gives our approach a practical edge, while it is still

easy to see how our approach can be generalized to

other modelling techniques and tools (e.g. ARIS).

We envision as the ultimate goal of our research

the delivery of an automated redesign tool. This tool

would support all steps of the approach in an “intelli-

gent” way. By this, we mean that the tool will not only

automate the various steps of the approach, but will

also interact with the redesigner. The redesigner will

Netjes M., Limam Mansar S., A. Reijers H. and M. P. van der Aalst W. (2007).

AN EVOLUTIONARY APPROACH FOR BUSINESS PROCESS REDESIGN - Towards an Intelligent System.

In Proceedings of the Ninth International Conference on Enterprise Information Systems - ISAS, pages 47-54

DOI: 10.5220/0002356900470054

 SciTePress

be able to indicate which performance dimensions

(time, costs, quality) should be improved, whether

certain process characteristics should perhaps not be

changed, and which promising alternatives should be

combined in constructing the best alternative. Our

approach is a solution that should primarily help re-

design novices in ﬁnding process alternatives based

on best practices. Secondly, more experienced re-

designers are supported in the creation and evalua-

tion of such alternatives in a structured and less time-

consuming manner. The structure of the paper is as

follows, section II describes the related work, section

III details the steps of our approach using an illustra-

tive example and section IV presents our conclusions

and future work.

2 RELATED WORK

Various more structured approaches to process re-

design were proposed earlier, most notably the Pro-

cessWise methodology (Calvert, 1994) and the MIT

Process Handbook (Malone et al., 2003). Also, a

variety of tools is available, e.g. MIT’s process re-

combinator tool (Bernstein et al., 1999), a number of

tools that apply case-based reasoning (Ku and Suh,

1996; Min et al., 1996), and the KOPeR tool by Nis-

sen (Nissen, 1996; Nissen, 1997; Nissen, 1998; Nis-

sen, 2000). Many existing approaches and tools are

limited in their application domain, while none of the

approaches has succeeded to gain widespread adop-

tion in industry. We have provided a more extensive

literature review on this topic in (Netjes et al., 2006).

Nissen’s work is most related to our approach

which motivates its following deeper discussion. Its

main contribution with the KOPeR tool is the con-

struction of a set of measures that, applied to pro-

cesses, would at ﬁrst help to diagnose pathologies.

The pathologies are then mapped to matching trans-

formations that may be applied to the processes in

order to improve their performances. Nissen used a

process model based on nodes, attributes and edges

(Nissen, 1998).

Nissen’s work has inspired us to come up with a

similar approach that nonetheless overcomes some of

the KOPeR tool’s shortcomings:

• On the process modelling side, the process model

in use by KOPeR is yet simple and the provided

examples are rather simplistic (Nissen, 1996; Nis-

sen, 1997; Nissen, 1998). Our process model is

deﬁned as an enriched WorkFlow net allowing for

the modelling of realistic, complex business pro-

cesses.

• Nissen used graph-based deﬁnitions of the mea-

sures in order to operationalize them. We have

noticed that the exact meaning of some of the

measures is unclear. We use a formal notation to

overcome this and deﬁne our measures unambigu-

ously.

• Nissen adds an extra layer of indirection (process

pathologies and process transformations). We

only deﬁne a set of measures and a set of trans-

formation rules to immediately ﬁnd the applicable

transformations.

• Nissen’s set of presented transformation serves as

an illustration and is far from a complete coverage

of the spectrum of redesign options. We provide a

more exhaustive list of rules based on our set of 29

best practices (Reijers and Limam Mansar, 2005).

3 EVOLUTIONARY APPROACH

In our evolutionary approach towards workﬂow pro-

cess redesign we take an existing process model and

improve it using redesign best practices. It is evolu-

tionary, because an existing process is taken as start-

ing point instead of a clean sheet. Our approach con-

sists of six steps: 1) model an existing process (us-

ing a formal model), 2) compute process measures

(which can be seen as global process characteristics.

Values for the process measures are derived from the

existing process model and point out weaknesses in

the process), 3) evaluate condition statements to ﬁnd

applicable best practices (For each best practice it is

known which process weaknesses it could solve and

the corresponding process measures are combined in

one condition statement per best practice. When a

statement evaluates to true it suggests the application

of the associated best practice. All condition state-

ments are evaluated to ﬁnd the best practices which

are eligible to be applied to the process. We strive to

include as many redesign best practices as possible in

our approach and we assume that our set of best prac-

tices is complete), 4) create alternative models based

on the selected best practices (The selected best prac-

tices are used to create alternative models. A best

practice has essentially the followingparts: some kind

of construction or pattern that can be distinguished in

the existing process, an alternative to be incorporated

for the redesign and a context-sensitive justiﬁcation

for this redesign), 5) evaluate the performance of the

created alternatives, and ﬁnally 6) choose the best al-

ternative and implement the new process after com-

paring the performance of the various alternatives to

ﬁnd the best alternative model, cf. Figure 1.

ICEIS 2007 - International Conference on Enterprise Information Systems

Existing

process model

Process

measures

Condition

statements

Alternative

models

Evaluation of

alternatives

New

process model

Figure 1: Evolutionary approach towards redesign.

The following details the six steps we have de-

scribed in Figure 1. An illustrative case study is used.

3.1 Process Model

The starting point of our evolutionary approach to

workﬂow process redesign is the existing process

model. In order to illustrate our ﬁndings we use a

case study that describes the process of handling in-

surance claims.

Let us ﬁrst describe the process: The process handles

the insurance claims of both individual and business

clients. The process starts when a claim is received.

After receipt, the claim is classiﬁed as “individual”

or “business”. Then the claim is checked for valid-

ity. Three checks, Check policy, Check amount (only

for business clients, requires the receipt of a damage

report) and Check legal are performed. A check ei-

ther results in OK (proceed with next check) or not

OK (reject claim). Claims that pass all checks are ac-

cepted and paid. Payments are authorized at the end

of each day by the ﬁnance manager. For all claims

(both rejected and accepted) a letter is written and the

claim is archived.

To model this process, we use the Worklow nets and

we deﬁne a formal process called Proto. A workﬂow

process is case-based, i.e. every piece of work is ex-

ecuted for a speciﬁc case, and make-to-order. A Petri

net (Reisig and Rozenberg, 1998) which models a

workﬂow process deﬁnition (i.e. the life-cycle of one

case in isolation) is called a WorkFlow net (WF-net).

In a WF-net, the workﬂow management concept task

is modelled as the Petri net concept transition, condi-

tions are modelled by places, and cases are modelled

by tokens. For a deﬁnition of WF-nets the reader is

referred to (Aalst, 1998).

The process model is created based on a formal pro-

cess deﬁnition called Proto net. The Proto net in-

cludes a process structure, related information and an

organizational model. The process structure consists

of places, transitions and ﬂow relations just as is the

case in a WF-net. The process structure is enriched

with information related to transitions (such as exter-

nal triggers, the type of activity to be executed, XOR-

splits and -joins to model choices, responsible depart-

ments, required applications, and handled products

and services). The organizational model uses roles

at its foundation. A role is a collection of comple-

mentary skills. Allocating roles to transitions ensures

that work is performed by the relevant person. Roles

have a hierarchical relation, i.e. if two roles have the

following relation (r

′

, r) this means that role r is one

step higher in the hierarchy than role r

′

and that role

r is also able to perform the transition(s) allocated to

role r

′

The Proto net is formally deﬁned in Deﬁnition 1.

Deﬁnition 1 (Proto net) A Proto net PN is a tuple

(P, T, F, B,C, S, J, D, DT, E, ET, G, GT, R, H,U, A, AH)

with:

• P is a non empty, ﬁnite set of places;

• T is a non empty, ﬁnite set of transitions (P∩ T =

0). Task and activity are used as synonyms for

transition;

• F ⊆ (P× T) ∪ (T × P) is a set of arcs (ﬂow rela-

tion);

• B : T →

P ({time, periodic, digital, mail, telephone})

relates each transition to zero, one or more trigger

types;

• C : T →

P ({basic, communication, check, authorize,

batch}) relates each transition to zero, one or

more activity types;

• S : T → {AND, XOR} relates each transition to a

split type element;

• J : T → {AND, XOR} relates each transition to a

join type element;

• D is a non empty, ﬁnite set of departments;

• DT : T →

P (D) relates each transition to zero,

one or more departments;

• E is a ﬁnite set of applications (i.e. software

tools);

• ET : T →

P (E) relates each transition to zero,

one or more applications;

• G is a non empty, ﬁnite set of products and ser-

vices;

• GT : T → P (G) relates each transition to zero,

one or more products and services;

• R is a non empty, ﬁnite set of roles;

• H ⊆ (R× R) is a (acyclic) set of hierarchical role

relations;

• U ∈ R →

N is a non empty ﬁnite bag of users. N

is the set of natural numbers {0, 1, 2, ...}. U is

a bag, i.e., for some role r ∈ R, U(r) denotes the

number of users having role r as the highest role;

• A : T 6→ R relates each transition to zero or one

roles (allocation);

• AH : T →

P (R) relates each transition to zero,

one or more roles (hierarchical allocation) [Note

that for t ∈ dom(A): AH(t) = {r ∈ R| (A(t), r) ∈

AN EVOLUTIONARY APPROACH FOR BUSINESS PROCESS REDESIGN - Towards an Intelligent System

∗

} (with H

∗

being the reﬂexive transitive closure

of H) and for t 6∈ dom(A): AH(t) =

0].

A process can be modeled according to the Proto

net deﬁnition with the modelling tool Protos (Pallas-

Athena, 2004). We have made several assumptions

regarding the creation of a process model. In our

deﬁnition of the Proto net we only take into account

the structural properties of a process model and

abstract from behavioral information.

Let us now use the Protos model for our insurance

claim process. The model of the insurance claim pro-

cess is shown in Figure 2 and is easy to understand.

individual

Claim

Damage report

End of the day Authorize pay

Manager Finance

Finance Individual & Business, FinProg

Check legal

(both XOR)

Law expert

Claim handling Individual & Business

Classify

Administrator

Distribution, Claim handling Individual & Business, Word

Receive

damage report

Postal worker

Distribution Business

Receive claim

Postal worker

Distribution Individual & Business

Pay

Assistant Finance

Finance Individual & Business, FinProg

Check policy

(XOR-split)

Administrator

Claim handling Individual & Business

Check amount

(XOR-split)

Damage expert

Claim handling Business

Archive

Administrator

Claim handling Individual & Business

Write letter

(XOR-join)

Administrator

Claim handling Individual & Business, Word

finish

class

business2

check

business3

authpay

business1

acc

not OK

Figure 2: The existing insurance claim process.

The rectangular boxes in the process model are the

transitions deﬁned in the Proto net (T), each transi-

tion has an activity type indicated by the symbol in

the box (C). The talking balloon indicates the activity

type “communication”, the trapezium indicates “ba-

sic”, the check box “check”, and the V-symbol “au-

thorize”. The three rectangles on the left side of the

process are triggers (B). A trigger indicates that a cer-

tain (external) condition has to be fulﬁlled before the

transition it links to can be executed. In this exam-

ple, a “Claim”, a “Damage report” and the “End of

the day” are used. The split and join types are set to

their values in the transition properties, but to show

them in the model XOR-splits and -joins are also ex-

plicitly stated in the name of a transition. On the top

right side of the transition the role allocated to the

transition is indicated (For example, the ﬁrst transi-

tion “Receive claim” is executed by the role “Postal

worker”), on the bottom left side the related depart-

ment(s) (Department “Distribution” for the transition

“Receive claim”), and on the bottom right side the

products / services and the required applications (“In-

dividual and business” services for the transition “Re-

ceive claim”). The organizational model related to the

process model is depicted in Figure 3 and is also cre-

ated with Protos. It shows the roles and the number of

resources per department.

Distribution department

Finance department

Claim handling

department

Assistant

Finance

Administrator

Postal worker

Damage expert

Law expert

Manager

Finance

Manager

Distribution

Supervisor

Claim handling

Administrator

Manager Claim

handling

Figure 3: Organizational model of insurance claim process.

Looking at Figure 2 and 3, it is not easy to spot

inefﬁciencies in the process. Even experienced prac-

titioners will certainly need to use their expertise and

perhaps tools such as simulation to deﬁne what will

need to be improved in the process. Hence the next

step of our approach, the use of process measures.

3.2 Process Measures

The second step of our evolutionary approach is the

computation of the process measures for the existing

process model. In this section we deﬁne our set of

process measures. The starting point for the creation

of the process measures has been the work of Nissen

(Nissen, 1998). Nissen identiﬁed 19 (static) process

measures (Nissen, 1996) of which ten appeared to be

relevant in relation to the redesign best practices. The

ICEIS 2007 - International Conference on Enterprise Information Systems

graph-based deﬁnition Nissen presented for these

measures is replaced by our formal deﬁnition because

the formal deﬁnition provides a more precise and

unambiguous meaning for the measures.

Besides the measures included from Nissen we

developed eight new measures. These measures are

all related to the additional information incorporated

in the Proto net. In Table 1 the process measures are

deﬁned, their range is given and it is indicated which

measures are taken from Nissen and which are new.

For Table 1 we assume the following context: PN =

(P, T, F, B,C, S, J, D, DT, E, ET, G, GT, R, H,U, A, AH)

is a Proto net.

To illustrate our results on the process measures,

let us apply them to our insurance claim process. Us-

ing the set of measures deﬁned in Table 1 we compute

the process measures. The computed values are pre-

sented in Table 2. For instance, the measure level of

control is deﬁned as the percentage of control tasks.

In the insurance claim process, there are 3 (control

transitions) divided by 10 (transitions) resulting in a

level of control of 0.3. Another measure, knock outs,

is deﬁned as the percentage of knock outs in the pro-

cess. A knock out is a part of the process where cases

are checked. The result of a check can be not OK

(leading to a direct rejection of the case) or OK (lead-

ing to an acceptance of the case if all checks are OK).

The knock out can be distinguished based on the pres-

ence of a special place called the knock out place. In

our example process, there is one knock out place,

namely “not OK”, on a total of 11 places resulting in

a knock outs measure of 0.1.

Table 2: Values for process measures.

Parallelism = 0 Department share = 0.1

Process contacts = 0.2 Process hand offs = 0.4

Batch = 0 Specialization = 0.7

Periodic = 0.1 Role usage = 0.7

Level of control = 0.3 Manag. layers = 0.3

L. of authorization = 0.1 Knock outs = 0.1

IT automation = 0.2 Process size = 10

IT communication = 0 Process versions = 2

Department inv. = 0.3 User involvement = 2

In the next step, we use and combine the set of

process measures to determine condition statements

per best practice. We know which weaknesses in a

process a best practice would help to alleviate and we

derive in the next section condition statements accord-

ingly. Let us note that the complete set of measures

has been created and deﬁned iteratively with the de-

velopment of the condition statements. Each condi-

tion statement is connected to one best practice. We

assume our set of best practices is complete and in

this work we include all best practices which require

process, data or resource information for their selec-

tion. We hypothesize that all relevant measures which

could be derived from this information and which are

necessary for the condition statements are included in

our set of measures.

3.3 Condition Statements

The third step of our evolutionary approach is the

evaluation of condition statements to select applica-

ble redesign best practices. For each best practice

we derive one condition statement which includes

one or more process measures. The application of

a certain best practice should be suggested when

the condition statement is fulﬁlled. The values

used in the condition statements are based on our

own redesign experience and expectation of when a

certain best practice is applicable. The validation of

these values will be future work.

We have created condition statements for 17 out of

the 29 best practices: Task elimination, Task addi-

tion, Task composition, Task automation, Knock-out,

Control relocation, Parallelism, Triage, Case man-

ager, Split responsibilities, Numerical involvement,

Specialist-generalist, Empower, Contact reduction,

Case types, Technology, Case-Based Work.

Regarding the remaining 12 best practices: 1) four

best practices appeared to have conditions similar to

other best practices and are combined, 2) four best

practices are not included because measures beyond

the process level are necessary to come to a proper

condition statement, 3) four best practices can not be

covered due to behavioral dependencies which are

not incorporated in the process deﬁnition.

For the sake of conciseness, we will only illustrate

a subset of condition statements. Moreover, the

examples are based on measures which were not

included in Nissen’s work.

For the insurance claim process 11 of the 17 condition

statements we have deﬁned evaluate to true resulting

in the selection of a number of best practices that

appear to be applicable to redesign this process. In

what follows we describe a subset of best practices

for which the condition statements evaluated to true:

Task elimination: When applying task elimina-

tion unnecessary tasks are removed (remember: task

is a synonym for transition).

Condition statement: Apply task elimination IF Level

of control > 0.2.

Knock-out: When applying knock out tasks re-

sulting in a knock out are re-ordered.

AN EVOLUTIONARY APPROACH FOR BUSINESS PROCESS REDESIGN - Towards an Intelligent System

Table 1: Process measures.

Process measures with range [0, ..., 1]

Parallelism

∗

par

|T|

, perc. of parallel tasks

Process =

|{t∈T| communication∈C(t)}|

|T|

, perc. of communication tasks

contacts

Batch =

|{t∈T| batch∈C(t)}|

|T|

, perc. of batch tasks

Periodic =

|{t∈T| periodic∈B(t)}|

|T|

, perc. of periodic tasks

Level of =

|{t∈T| check∈C(t)}|

|T|

, perc. of control tasks

control

Level of =

|{t∈T| authorize∈C(t)}|

|T|

, perc. of authorization tasks

authorization

IT automation

∗

α·|{t∈T|ET(t)6=

0∧t6∈dom(A)}| + β·|{t∈T|ET(t)6=

0∧t∈dom(A)}|

(α+β)·|T|

, perc. of (semi-)automated tasks

IT comm.

∗



|{t∈T |digital∈B(t)∧communication∈C(t)}|

|{t∈T |communication∈C(t)}|

, for {t∈T|communication∈C(t)} 6=

1 , for {t∈T|communication∈C(t)} =

Department =

|D|

|T|

, perc. of departments

involvement

∗

Department =

|{t∈T| |DT(t)|≥2}|

|T|

, perc. of tasks shared by departments

Process =

|{t

∈T | t

•∩•t

0∧AH(t

)∩AH(t

0}|

|{t

∈T | t

•∩•t

0}|

, perc. of work that is handed over to another role

hand offs

∗

Specialization

∗

|{A(t)| t∈dom(A)}|

|T|

, specialization of roles (with a higher perc. meaning more specialists)

Role usage

∗

|{A(t)| t∈dom(A)}|

|R|

, perc. of actively involved roles

Managerial =

|lrp|

|R|

, perc. of hierarchical layers

layers

∗

Knock outs =

|{p∈P| |•p|>1∧(∀

t∈ •p

check∈C(t)∧S(t)=XOR∧|t•|>1)∧(∃ep∈EP

| •p⊆||ep||)}|

|P|

, perc. of k.outs

Range

Process size

∗

= |T|, the number of transitions [1, 2, ..., number of transitions]

Versions = |G|, the number of products and services [1, 2, ..., number of products and services]

User =

|U|

|T|

, the average number of users per task

[0, ..., 1, ..., number of users]

involvement

∗

* = measure taken from Nissen (Nissen, 1996)

1. A parallel transition, T

par

, is deﬁned as T

par

⊆ T such that t ∈ T

par

if and only if there exist two elementary

paths that both start in an AND-split and end in an AND-join, t is on only one of these two paths, and the

AND-split and AND-join are the only two nodes these paths have in common.

2. A role path, rp, in PN is deﬁned as a nonempty sequence r

...r

of roles which satisﬁes

, r

k−1

), ..., (r

, r

) ∈ H. Let RP

be the set of all role paths in PN. Then a longest role path, lrp ∈ RP

, is

deﬁned as a role path which satisﬁes ∀

rp∈RP

|lrp| ≥ |rp|.

3. An elementary path, ep, in PN is deﬁned as a nonempty sequence a

...a

of nodes which satisﬁes

, a

), ..., (a

k−1

, a

) ∈ F ∧ ∀

1≤i< j≤k

6= a

. Further, let EP

be the set of elementary paths in PN and let

||ep|| be the set of all nodes in the elementary path ep.

ICEIS 2007 - International Conference on Enterprise Information Systems

Condition statement: Apply knock-out IF Knock outs

> 0.

Split responsibilities: When applying split re-

sponsibilities the responsibility for a task will be

given to one department.

Condition statement: Apply split responsibilities IF

Department share > 0.

Case types: When applying case types new workﬂow

processes and product types are distinguished.

Condition statement: Apply case types IF Process

versions > 1.

Case-Based Work: When applying case-based

work each case is handled individually.

Condition statement: Apply case-based work IF

Batch > 0 OR Periodic work > 0.

It is straightforward, using Table 2, to check

that these condition statements are true for the

insurance claim process.

3.4 Alternative Models

The fourth step of our approach derives new process

models based on the selected best practices. At this

stage our approach does not support an automatic

identiﬁcation of where in the process a best practice

should be applied. This is included in our future work.

However, for the sake of completeness, we here il-

lustrate the remainder of the approach for the insur-

ance claim process. Hence the following list of the 5

selected best practices for which the condition state-

ments evaluated to true, including a possible applica-

tion:

• Task elimination: eliminate the control task Check

legal and ask the client to indicate whether (s)he

or some one else was responsible for causing the

damage.

• Knock out: perform Check amount and Check le-

gal in a different order if Check amount requires

longer service times and / or has a lower rejection

probability than Check legal.

• Split responsibilities: give the responsibility for

the task Classify solely to the Distribution depart-

ment.

• Case types: distinguish one workﬂow process for

the individual claims and one for the business

claims.

• Case-based work: remove or change the periodic

activity Authorize pay which should reduce wait-

ing times.

3.5 Evaluation of Alternatives and New

Process Model

In the ﬁnal steps of our approach, the performance of

the various alternatives is evaluated and one redesign

alternative is selected for implementation. For the

evaluation, performance data (time, cost and quality

indicators) are necessary. Evaluation can be done

by simulating the model or (in simple processes)

with calculation. The alternative that provides the

best performance is selected. We have earlier found

that 11 condition statements (thus best practices)

evaluated to true for the insurance claim process (and

we only illustrated ﬁve of them). Implementing the

best practices separately would lead to 11 redesign

alternatives for the insurance claim process. Each

redesign project has goals (for instance improvement

on throughput time or operational costs) and project

risks (Limam Mansar et al., 2006) which makes

some alternatives more promising than others. For

the insurance claim process an improvement in

throughput time will be achieved with the application

of Task elimination. An improvement on costs could

result from the use of the Knock out best practice. A

careful evaluation with performance data is necessary

to see which alternative will indeed be the best and

should replace the existing insurance claim process.

At this point in time our approach ends with the

selection of the best practices that seem fruitful for

application to the existing process. Based on the de-

scription of the best practices it is straightforward to

come up with possible applications of the best prac-

tices as we showed in our illustration. It should give a

redesign novice enough input to create an alternative

that will perform better than the existing process. In

the future our approach and the supporting redesign

tool should provide redesign alternatives which are

based on the selected best practices and evaluate the

alternatives to ﬁnd the best one. This would support

both redesign novices and experts.

4 CONCLUSION AND OUTLOOK

In this paper we describe and illustrate a six steps

evolutionary approach towards workﬂow process re-

design. Our contribution in this paper focuses on

the ﬁrst three steps leading to suggesting applicable

best practices. This suggestion will already help re-

design novices with the creation of redesign alterna-

tives. We introduced a formal process deﬁnition suit-

able for modelling realistic, complex business pro-

cesses. Our process measures have a clear and un-

AN EVOLUTIONARY APPROACH FOR BUSINESS PROCESS REDESIGN - Towards an Intelligent System

ambiguous meaning because of their formal notation.

Furthermore, our process measures are directly re-

lated to the redesign best practices with condition

statements.

Our current work holds limitations that we will

be addressing in the future. One direction for fu-

ture research is the extension of the current process

deﬁnition, for instance with performance information

about historic process instantiations, to be able to set

up condition statements for all redesign best practices

(steps 1, 2 and 3). Another important direction will

be the exact place in the process model where a suit-

able best practice should be applied and the deriva-

tion of the alternative model (step 4). We also aim at

automating our approach with a highly interactive re-

design tool. In addition to merely generating process

alternatives on the basis of an existing model, such

a tool will be able to process the preferences of the

redesigner for a subset of the alternatives to continue

its search for a satisfying design (steps 5 and 6). The

interaction with the redesigner and the advanced sup-

port will hopefully make our tool a truly “intelligent”

system for BPR.

ACKNOWLEDGEMENTS

This research is supported by the Technology Founda-

tion STW, applied science division of NWO and the

technology programme of the Dutch Ministry of Eco-

nomic Affairs.

REFERENCES

Aalst, W. (1998). The application of petri nets to workﬂow

management. The Journal of Circuits, Systems and

Computers, 8(1):21–66.

Al-Mashari, M. and Zairi, M. (1999). Bpr implementation

process: An analysis of key success and failure fac-

tors. Business Process Management Journal, 5(1):87–

112.

Bernstein, A., Klein, M., and Malone, T. (1999). The pro-

cess recombinator: a tool for generating new business

process ideas. International Conference on Informa-

tion Systems, pages 178–192.

Calvert, P. (1994). An advanced bpr methodology with

integrated, computer-based tools. In Glasson, B.,

Hawryszkiewycz, I., Underwood, B., and Weber, R.,

editors, Business Process Re-engineering: Informa-

tion Systems Opportunities and Challenges, pages

161–170. Elsevier.

Grover, V., Jeong, S., Kettinger, W., and Teng, J. (1995).

The implementation of business process reengineer-

ing. Journal of Management Information Systems,

12(1):109–144.

Kettinger, W., Teng, J., and Guha, J. (1997). Business pro-

cess change: A study of methodologies, techniques,

and tools. MIS Quarterly, 21(1):55–80.

Ku, S. and Suh, Y. (1996). An investigation of the k-

tree search algorithm for efﬁcient case representa-

tion and retrieval. Expert Systems with Applications,

11(4):571–581.

Limam Mansar, S., Reijers, H., and Ounnar, F. (2006).

Bpr implementation: A decision-making strategy. In

Bussler, C. and Haller, A., editors, Business Process

Management Workshops: BPM 2005, volume 3812 of

Lecture Notes in Computer Science, pages 421–431.

Springer Verlag, Berlin.

Malone, T., Crowston, K., and Herman, G. (2003). Orga-

nizing Business Knowledge: The MIT Process Hand-

book. MIT Press.

Min, D., Kim, J., Kim, W., Min, D., and Ku, S. (1996).

Ibrc: Intelligent bank reengineering system. Decision

Support Systems, 18(1):97–105.

Netjes, M., Vanderfeesten, I., and Reijers, H. (2006). “in-

telligent” tools for workﬂow process redesign: A re-

search agenda. In Bussler, C. and Haller, A., edi-

tors, Business Process Management Workshops: BPM

2005, volume 3812 of Lecture Notes in Computer Sci-

ence, pages 444–453. Springer Verlag, Berlin.

Nissen, M. (1996). Knowledge-based organizational

process redesign: Using process ﬂow measures to

transform procurement, phd. dissertation. Uni-

versity of Southern California, downloadable at

http://web.nps.navy.mil/ menissen/.

Nissen, M. (1997). Reengineering support through

measurement-driven inference. Intelligent Systems in

Accounting, Finance and Management, 6(2):109–120.

Nissen, M. (1998). Redesigning reengineering through

measurement-driven inference. MIS Quarterly,

22(4):509–534.

Nissen, M. (2000). An experiment to assess the perfor-

mance of a redesign knowledge system. Journal of

Management Information Systems, 17(3):25–44.

Pallas-Athena (2004). Protos User Manual. Pallas Athena

BV, Apeldoorn, The Netherlands.

Reijers, H. and Limam Mansar, S. (2005). Best prac-

tices in business process redesign: An overview and

qualitative evaluation of successful redesign heuris-

tics. Omega: The International Journal of Manage-

ment Science, 33(4):283–306.

Reisig, W. and Rozenberg, G., editors (1998). Lectures on

Petri Nets I: Basic Models, volume 1491 of Lecture

Notes in Computer Science. Springer Verlag, Berlin.

Valiris, G. and Glykas, M. (1999). Critical review of ex-

isting bpr methodologies. Business Process Manage-

ment Journal, 5(1):65–86.

ICEIS 2007 - International Conference on Enterprise Information Systems