Improving Exception Handling by Discovering Change Dependencies in Adaptive Process Management Systems [original]

Improving Exception Handling by

Discovering Change Dependencies in

Adaptive Process Management Systems

Barbara Weber1,, Werner Wild2, Markus Lauer3, and Manfred Reichert4

1Quality Engineering Research Group, University of Innsbruck, Austria

[email protected]

2Evolution Consulting, Innsbruck, Austria

[email protected]

3Dept. Databases and Information Systems, University of Ulm, Germany

[email protected]

4Information Systems Group, University of Twente, The Netherlands

[email protected]

Abstract. Process-aware information systems should enable the ﬂexi-

ble alignment of business processes to new requirements by supporting

deviations from the predeﬁned process model at runtime. To facilitate

such dynamic process changes we have adopted techniques from case-

based reasoning (CBR). In particular, our existing approach allows to

capture the semantics of ad-hoc changes, to support their memorization,

and to enable their reuse in upcoming exceptional situations. To further

improve change reuse this paper presents an approach for discovering

dependencies between ad-hoc modiﬁcations from change history. Based

on this information better user assistance can be provided when dynamic

process changes have to be made.

1 Introduction

Due to frequent changes in its business environment an enterprise must be able

to ﬂexibly and continuously align its information systems (IS) and its business

processes. Enterprise IS therefore must provide for ﬂexible process support while

still enforcing some degree of control [1]. In particular, there is an essential

requirement for maintaining a close ”ﬁt” between real-world business processes

and the workﬂows as supported by the IS, their current generation is known as

Process-Aware Information Systems (PAIS) [2].

Recently, signiﬁcant eﬀorts have been undertaken to make PAIS more ﬂexible

and several approaches for adaptive process management have emerged [1,3,4].

The underlying idea is to enable (dynamic) changes of diﬀerent process aspects

(e.g., control ﬂow, organizational, functional, and informational perspectives)

and at diﬀerent process levels (e.g., instance and type level). In particular, au-

thorized users must be able to deviate from the pre-deﬁned process model as

needed, i.e., ad-hoc changes (e.g., to add or shift activities) of individual process

Part of this research was funded by a grant from the Tiroler Wissenschaftsfond.

J. Eder, S. Dustdar et al. (Eds.): BPM 2006 Workshops, LNCS 4103, pp. 93–104, 2006.

Springer-Verlag Berlin Heidelberg 2006

94 B. Weber et al.

instances must be possible at runtime to deal with exceptional or changing sit-

uations. For example, during a medical treatment process the patient’s current

medication may have to be changed due to an allergic reaction, i.e., the process

instance representing this treatment procedure must be dynamically adapted.

To facilitate exception handling we have adopted techniques from case-based

resoning (CBR) [5,6,7]. This allows us to capture contextual knowledge about

ad-hoc changes and to assist actors in reusing it. For this we apply an interactive

variant of CBR (i.e., conversational CBR [8]), describe ad-hoc changes as cases

and memorize them in a case base CB. In its simplest form a case covers a

single change operation (e.g., insertion of a process activity). However, cases may

contain several (semantically) related change operations as well. For example, in

a medical treatment process a magnet resonance tomography (MRT) may have

to be skipped for a patient with cardiac pacemaker, instead, another imaging

procedure (e.g., computer tomography) might have to be applied. Our objective

is to support reuse of such complex changes in similar situations to enable actors

to operate at a higher semantical level and to relieve them from specifying the

change from scratch each time.

Since ad-hoc changes are often applied in exceptional situations, we cannot

expect that semantically related adaptations are always conducted at the same

time, i.e., they are not always added as a single case to the PAIS. This happens

when end users are rather inexperienced and do not think through all conse-

quences, when changes to the same instance are performed by diﬀerent actors

or when these dependencies are not known when adding a case. Over time, the

PAIS may end up with several inter-related cases which are frequently applied in

combination with each other. By discovering such inter-case dependencies and

by considering this knowledge in the context of change reuse we provide for bet-

ter user assistance. When reusing a certain case the PAIS can suggest users to

apply dependent cases as well. To further improve this approach, cases which

always co-occur shall be merged and the CB should be refactored accordingly.

Section 2 summarizes background information needed for the understanding of

our approach. In Section 3 we introduce the notion of co-occuring cases. Based on

this, in Section 4 we sketch how actors can be assisted in reusing inter-dependent

changes and in refactoring a CB by merging cases. Section 5 discusses related

work and Section 6 concludes with a summary and outlook.

2 Supporting Change Reuse Through CBR

This section covers backgrounds needed for the understanding of this paper.

First, we introduce basic notions related to process management. Second, we

discuss how CBR is used in our approach for capturing the semantics of ad-hoc

changes, for memorizing these changes, and for reusing them in similar situations.

2.1 Basic Notions

For each supported business process a corresponding process type Texists. It

can be related with one or more process schemes representing diﬀerent versions

Improving Exception Handling by Discovering Change Dependencies 95

of the process. Each process schema Sis described in a graph-like fashion, and

comprises a set of activities and control connectors between them. Based on a

schema Snew process instances can be created and executed accordingly. For

example, in instance I1in Fig. 1 activities Aand Care completed whereas activity

Bis activated (i.e., its work items are oﬀered to users in their worklists).

9completed

9activated

Process Type Level

BAND-Split

AND-Join

OR-Split

OR-Join

Process Instance I1

(unbiased):

Process Instance Level

d=‘yes’

d=‘no’

Process Schema S: Process Schema S‘:

Process Instance I2

(biased):

9completed

9activated

Process Instance I3

(biased):

Process Type

Change

Fig. 1. Process Type and Process Instance

To deal with exceptional situations at the instance level, users must deviate

from the pre-modeled schema (e.g., by deleting activities) [1,5,9]. Ad-hoc changes

are instance-speciﬁc and do not aﬀect the execution schema of any other running

process instances. In Fig. 1, instance I2has undergone an individual modiﬁcation

(i.e., the dynamic deletion of activity B). Thus the execution schema of I2devi-

ates from its original process schema S. Individually modiﬁed process instances

are called biased, unchanged ones are denoted as unbiased.

2.2 Capturing Semantics of Ad-Hoc Changes with CBR

Our approach uses case-based reasoning (CBR) techniques to capture the se-

mantics of an ad-hoc change, to memorize it and to support its reuse in similar

situations (for details see [6,7]). Case-based reasoning (CBR) is a contemporary

approach to problem solving and learning [10]. New problems are dealt with by

drawing on past experiences – described in cases and stored in case bases – and

by adapting their solutions to the new problem situation. For representing a

concrete ad-hoc change we use the concept of a case, which captures the context

of, and the reasons for the respective deviation (cf. Fig. 2). More precisely, a case

contains a textual problem description pd which brieﬂy summarizes the excep-

tional situation that led to the ad-hoc deviation. The reasons for the change are

described in question-answer (QA) pairs {q1a1,...,qnan}each of which denotes

one particular condition (for details see below). The solution part sol (i.e., the

action list) of a case contains the concrete change operations applied.

96 B. Weber et al.

The ad-hoc changes covered by a particular case ccan be reused, i.e., they can

be re-applied to other instances. QA pairs are used to retrieve cases handling

similar problems. If an adequate case is found its solution part can be applied

to the given process instance. All instances to which case chas been applied to

are kept in its instance set instanceSetc. If no similar cases can be found the

user adds a new case with the respective change information to the system.

Deﬁnition 1 (Case). Acasecisatuple(pdc,qaSetc,solc,instanceSetc)

where

–pdcis a textual problem description

–qaSetc={q1a1, ..., qnan}denotes a set of question-answer pairs

–solc={opj|opj=(opT ypej,s

j, paramListj), j = 1, ..., k}is the solution

part of the case denoting a list of change operations (i.e., the changes that

have been applied to one or more process instances) 1

–instanceSetcis the set of process instances to which case chas been applied

The question of a QA pair is usually entered as free text, however, to reduce

duplicates it can alternatively be selected from a list of already existing questions.

The answer can either be free text or a structured answer expression (cf. Fig 2

(a)). Answer expressions allow us to use contextual knowledge already kept in

the PAIS (e.g., due to legal requirements), thus avoiding redundant data entry.

Questions with answer expressions can be evaluated automatically by retrieving

values for their context attributes from existing data in the system (e.g., the

medical problems of a patient as stored in his electronic patient record), i.e.,

they do not have to be answered by users, thus preventing errors and saving

time. Free text answers are used when no suitable context attributes are deﬁned

within the system or the user is not trained to write answer expressions. For

example, the second QA pair in Fig. 2 (a) contains an answer expression using

the context attribute Patient.age. It can therefore be evaluated automatically.

By contrast, the answer in the ﬁrst QA pair is free text provided by the user.

To be able to reason about the changes applied to a particular process instance

Iwe introduce caseListIas the list of all cases which have been applied to I,

in their application order. If an instance Iis biased its caseListIis not empty.

All cases applied to process instances created from schema version Sare stored

in a case base CBSassociated with S.

Deﬁnition 2 (Case Base). A case base CBSis a tuple (S, {c1,...,c

m})where

–S denotes the schema version to which the case base is related

–{c1,...,c

m}denotes a set of cases (cf. Def. 1)

When deviations from the pre-deﬁned process schema become necessary the user

initiates a case retrieval dialogue (cf. Fig 2 (b)). The system then assists her in

ﬁnding already stored similar cases (i.e., change scenarios in our context) by pre-

senting a set of questions to be answered in any number and any order. Questions

1An operation opj:= (opT ypej,s

j, paramListj) (j = 1, ..., k) consists of operation

type opTypej,subjectsjof the change, and parameter list paramListj.

Improving Exception Handling by Discovering Change Dependencies 97

Additional lab test required

Title

Description An additonal lab test has to be performed as

the patient has diabetes and is older than 40

Question-Answer Pairs

Question Answer

Patient has diabetes? Yes

Is the patient’s age greater than 40? Patient.age > 40

Actions

Insert LabTest

Operation Type Subject Parameters

Select Operation Type Insert

Select Activity/Edge Lab Test

Please Answer the Questions

Question Answer

Patient has diabetes? Yes

Is the patient’s age greater than 40? Yes

Lab Test required

Title

125

Case ID

100%

Similarity

Reputation Score

Display List of Cases

Into S Between Preparation and Examination

(a) (b)

Fig. 2. CCBR Dialogs - Adding a New Case (a) and Retrieving Similar Cases (b)

with an answer expression are automatically evaluated by retrieving the values of

the respective context attributes from the PAIS without user intervention. Based

on this the system then searches for similar cases by calculating the similarity

for each case in the case base CBS. Similarity is calculated by dividing the num-

ber of correctly answered questions minus the number of incorrectly answered

questions by the total number of questions in the case. It then displays the top

nranked cases (ordered by decreasing similarity) as well as related information

(e.g., reputation scores). The user then has several options:

1. The user can directly answer any of the remaining unanswered questions (in

arbitrary order), similarity is then recalculated and the nmost similar cases

are displayed to the user.

2. The user can apply a ﬁlter to the case base (e.g., by only considering cases

whose solution part contains a particular change operation). All cases not

matching the ﬁlter criteria are removed from the displayed list of cases.

3. The user can decide to review displayed cases in detail.

4. The user can select one of the displayed cases for reuse. The actions speciﬁed

in the case’s solution part are then forwarded to and executed by the PAIS.

The instance set of the selected case is adjusted accordingly.

3 Inter-case Dependencies

This section ﬁrst gives a typical example for inter-case dependencies and then

introduces the formal notation to be used in this paper.

3.1 Motivating Example

Fig. 3 shows the cruciate rupture treatment process for a particular patient.

This treatment process had to be modiﬁed due to an unanticipated situation.

To conﬁrm the suspicion of a cruciate rupture usually an x-ray as well as a

magnet resonance tomography (MRT) are performed. However, as this patient

has a cardiac pacemaker the radiologist decided to skip the MRT. To still get a

98 B. Weber et al.

reliable diagnosis, the attending physician ordered a computer tomography (CT)

instead. Though these two changes are related to each other they were added

to the system by diﬀerent actors at diﬀerent times. Case c1was added by the

radiologist and resulted in the deletion of the MRT activity. Some time later the

attending physician added case c17 to insert the CT activity.

Ad-hoc Changed

Process Instance I:

…

Patient

Admission

Anamnesis &

Clinical

Examination

Suspicion of Cruciate

Rupture =“Yes”

Suspicion of Cruciate

Rupture =“No”

X-Ray

MRT

Non Operative

Therapy

…

Problem

MRT cannot be performed

Question-Answer Pairs

Solution

Delete MRT

Cardiac Pacemaker Yes?

Problem

Additionl CT required

Question-Answer Pairs

Solution

Insert CT

Cardiac Pacemaker Yes?

C17

Fig. 3. Application Example

Cases applied to the same instance may be independent of, or dependent on

each other. In our example the deletion of the MRT activity caused the insertion of

the CT activity, i.e., the additional CT compensates the missing MRT. When such

inter-case dependencies exist, the reuse of a particular case might necessitate

further changes. In our example, reusing case c1may require the application of

case c17 as well since an alternative imaging procedure is needed. Discovering

such inter-case dependencies is crucial to better assist users when they need to

make complex changes to the system.

3.2 Co-occuring Cases

Let CBSbe a case base and let c1and c2be two cases in CBS.Ametricsabout

inter-case dependencies is the conditional co-occurence rate CoRate(c2|c1). For

a set of process instances this metrics denotes the relative frequency of the

application of case c2on condition that case c1has been applied too.

Deﬁnition 3 (Conditional Co-Occurrence Rate). Let S be a process

schema with case base CBSand let c1,c2∈CBSbe two cases. The condi-

tional co-occurence rate CoRate(c2|c1)denotes the relative frequency of case c2

on condition that case c1has already been applied. Formally:

CoRate(c2|c1)=|instanceSetc2∩instanceSetc1|

|instanceSetc1|

When a user wants to reuse a case c∈CBSwe present her all other cases

ck∈CBSwith CoRate(ck|c) exceeding threshold thres ≤1. Section 4 describes

how we assist actors in reusing inter-dependent changes. In this context cases

with strong co-occurence are of particular interest.

Improving Exception Handling by Discovering Change Dependencies 99

Deﬁnition 4 (Strong Co-Occurence of Cases). Let S be a process schema

with case base CBS.Letfurtherc1,c

2∈CBS.Then:

1. If CoRate(c2|c1)= 1 holds we denote case c2as strongly co-occurrent with

case c1(i.e., c2must only have been applied when c1has been applied too).

2. If CoRate(c2|c1)=CoRate(c1|c2)= 1 holds we denote cases c2and c1as

being strongly co-occurent with each other (i.e., c2always occurs when c1has

been applied and vice versa).

If c2is strongly co-occurrent with c1(cf. Def. 4.1), obviously, instanceSetc1

⊆instanceSetc2must hold. Consequently, we obtain CoRate(c2|c1)=1and

CoRate(c1|c2)=|instanceSetc1|

|instanceSetc2|. As a special scenario consider two cases c1and

c2which are strongly co-occurent with each other (cf. Def. 4.2). Trivially, we

then obtain |instanceSetc1|=|instanceSetc2|.Ifcasesc1and c2are strongly

co-occurent with each other and the total number of co-occurrences exceeds

threshold minOccur ∈N, the process engineer is notiﬁed about the option to

merge these inter-dependent cases (cf. Section 4.2).

4 Discovering and Utilizing Knowledge About Inter-case

Dependencies

To discover co-occurent changes we analyze a process schema’s CB. We utilize

the obtained knowledge to assist actors in reusing complex changes (cf. Section

4.1) and to support process engineers in refactoring CBs (cf. Section 4.2).

4.1 Assisting Actors in Reusing Dependent Cases

When a case c∈CBSis reused (i.e., cis applied to a process instance I)the

system displays all cases cse ∈CBSfor optional reuse2which co-occur with cand

for which the co-occurence rate CoRate(cse|c) exceeds a given threshold. This is

accomplished by Algorithm 1. First, Algorithm 1 adds case cto the list of cases

(caseListI) which have already been applied to instance I(line 3). For each case

cse (except for already applied cases to instance I), Algorithm 1 then determines

the conditional co-occurence rate CoRate(cse|c). This is done by determining

the total number of co-occurences between cse and cover all instances of process

schema Sand by dividing it by the total number of occurences for case c(line 6).

Finally, only those cases ckare displayed (for potential reuse) whose co-occurence

rate CoRate(cse|c) exceeds the given threshold thres.

For example, consider the scenario depicted in Fig. 4. Assume that the changes

represented by case c5shall be applied to process instance I132. According to Al-

gorithm 1 the system adds case c5to CaseListI132 and then determines the con-

ditional co-occurence rate CoRate(cse|c5) for each case cse ∈CBs\CaseListI132

(i.e., {c3,c

19}) related to any instance from InstanceSetc5={I44,I

143,I

147}.We

2Cases which have already been applied to process instance I are not shown.

100 B. Weber et al.

Algorithm 1. Display CoOccurent Cases

1: Input: Case c; ProcessInstance I; ﬂoat thres;

3: add case c to CaseListI;

4: Integer TotalOccurenceOfC := |InstanceSetc|;

5: for all cse ∈CBS\CaseListIdo

6: CoOccurenceRatecse := |instanceSetc∩instanceSetcse|

T otalOccurenceOf C ;

7: if CoOccurenceRatecse ≥thres then

8: DISPLAY(cse)

9: end if

10: end for

....................................................................................................

2006-01-17 09:15: case c1 applied to process instance I1

2006-01-17 10:25: case c17 applied to process instance I1

2006-01-17 14:00: case c3 applied to process instance I8

2006-01-17 18:21: case c3 applied to process instance I11

2006-01-18 12:27: case c1 applied to process instance I27

2006-01-18 12:31: case c19 applied to process instance I29

2006-01-18 13:01: case c17 applied to process instance I27

2006-01-18 16:12: case c3 applied to process instance I44

2006-01-18 17:57: case c5 applied to process instance I44

2006-01-19 17:55: case c1 applied to process instance I132

2006-01-21 06:01: case c5 applied to process instance I143

2006-01-21 07:35: case c3 applied to process instance I147

2006-01-22 15:34: case c3 applied to process instance I209

2006-01-22 18:01: case c5 applied to process instance I147

......................................................................................................

I29

c19

I1, I132

c17

I44, I143, I147

I8, I11, I44, I147, I209

I1, I27, I132

InstanceSetC

Case c

I143

c3, c5

I44

I209

c3, c5

I147

c1, c17

I132

c19

I29

I27

I11

c1,c17

CaseListI

Instance I

Fig. 4. Log File

obtain CoRate(c3|c5)=2

3and CoRate(c19|c5)=0

3. For example, if we have cho-

sen thres =0.6casec3will be displayed to the users (for optional reuse) when

applying c5to instance I132.

When reusing a case a wizard opens and all dependent cases are displayed to

the user (cf. Fig. 5). For each dependent case its identiﬁer, title and co-occurrance

rate are shown. The co-occurance rate reﬂects the conﬁdence of the system that

the dependent case should be applied too in this particular situation. The user

can then optionally reuse any of the displayed cases.

At ﬁrst glance the described approach seems to be easy to implement. How-

ever, when reusing a case and applying its changes it must be guaranteed that

the respective process instance still meets certain correctness and consistency

constraints. In particular, the pre-conditions for applying the change operations

captured by a case must be met when reusing it. As an illustrative example

consider the medical treatment process depicted in Fig. 6. Assume that the re-

spective patient complains about pains in his knee. The attending physician

therefore orders an additional examination. This change is represented by case

c22 which captures the insertion of activity Follow-up examination between ac-

tivities Non Operative Therapy and Documentation and Discharge.Assume

further that during the follow-up examination it is found that the patient suf-

fers from a contusion and the physician therefore decides that a puncture has

Improving Exception Handling by Discovering Change Dependencies 101

Fig. 5. Presenting Dependent Cases to the User

to be performed as well. This change is captured by case c35 (subsequent in-

sertion of activity Puncture between activities Follow-up examination and

Documentation and Discharge). Note that the deﬁnition of the latter change

depends on the presence of activity Follow-up examination which was intro-

duced by case c22. Such dependencies, in turn, could result in parameterization

problems or inconcistencies when a user solely wants to reuse case c35. Generally,

the change framework we use allows us to eﬃciently detect such undesired situ-

ations [11]. In our example, a user who wants to reuse case c35 has two options.

Either she can apply case c22 as well or she may adapt the case by modifying

the parameterization of the respective change (e.g., by replacing the position

parameter Follow-up examination with Non Operative Therapy).

Ad-hoc Changed

Process Instance I:

…

Patient

Admission

Anamnesis &

Clinical

Examination

Suspicion of Cruciate

Rupture =“Yes”

Suspicion of Cruciate

Rupture =“No”

X-Ray

MRT

Non Operative

Therapy Follow-up

examination

Puncture

Discharge and

Documentation

C22: (…{Insert Follow-up

Examination in schema S between

„Non Operative Therapy“ and

„Discharge and Documentation“})

C35: (…{Insert Puncture in schema

S between „Follow-up

Examination“ and „Discharge and

Documentation“})

Fig. 6. System Supported Conﬂict Resolution

102 B. Weber et al.

4.2 Refactoring Case Bases by Merging Cases

In order to increase problem solving eﬃciency we can compress the case base

by merging strongly co-occurent cases. For this scenario, consider the reuse of

acasecand its application to a particular process instance. Whenever such

an event occurs, it triggers an analysis of the case base. More precisely, it is

checked whether the reused case is strongly co-occurent with other cases. If so,

the knowledge engineer is notiﬁed accordingly and may then decide to merge

respective cases. Note that in this scenario we can restrict the analysis (i.e.,

the comparison of case cwith other cases) to those cases belonging to the case

list caseListI, as only cases within that list can be strongly co-occurent with

case c. Algorithm 2 is applied to detect cases which strongly co-occur with each

other (cf. Def. 4). For the sake of readability we treat this algorithm separately

from Algorithm 1, however, for a practical implementation they can easily be

merged.

Algorithm 2. Notify About Strongly CoOccurent Cases

1: Input: Case c; ProcessInstance I; int minOccur;

3: Add Ito instanceSetc;

4: for all cse ∈CaseListIdo

5: if instanceSetcse =instanceSetcthen

6: if |instanceSetc|≥minOccur then

7: NOTIFY(c, cse)

8: end if

9: end if

10: end for

Again consider the example from from Fig. 4. Assume that case c17 is applied

to instance I27. Instance I27 is then added to the instance set of case c17.Further,

Algorithm 2 (with, e.g., minOccur = 3) identiﬁes case c1as being strongly

co-occurent with case c17. Consequently, the process engineer is notiﬁed that

c1and c17 are strongly co-occurent which each other and thus could merge

these two cases. In this situation a new case ccan be created in CBSand the

original cases are deactivated3, i.e., a refactoring of the case base takes place. The

problem descriptions and QA pairs related to the two cases have to be manually

merged by the process engineer; the corresponding solution parts, in turn, can

be automatically merged by unifying the change operations of the original cases

in the correct order. Diﬀerent optimizations for purging the resulting operation

sets can be applied in this context. However, this is beyond the scope of this

paper. In addition, the schema-speciﬁc case base CBScan be regularly searched

for any strongly co-occurent cases by applying Algorithm 3.

3For traceability reasons respective cases are not deleted, but only deactivated.

Improving Exception Handling by Discovering Change Dependencies 103

Algorithm 3. Scan For Strongly CoOccurent Cases

1: Input: Case Base CBS; int minOccur;

3: CB =CBS

4: while CB =∅do

5: take arbitrary case cse from CB

6: CB =CB \{cse}

7: for all case ∈CB do

8: if instanceSetcase =instanceSetcse then

9: if |instanceSetcase|≥minOccur then

10: NOTIFY(case, cse)

11: end if

12: end if

13: end for

14: end while

5 Related Work

Similar to our approach process mining aims at extracting process knowledge

from log data. So far, focus of mining techniques has been on the extraction of

process models from execution logs [12,13,14]. For example, the alpha algorithm

can be used to construct a Petri net model describing the behavior observed in

the log. Similarly, the Multi-Phase Mining approach can be used to construct

event-driven process chains from logs. Recent approaches also use event-based

data for mining model perspectives other than control ﬂow (e.g., process perfor-

mance [15]). Mature tools like the ProM framework allow constructing diﬀerent

types of models from real process executions. However, process mining research

has not yet addressed applying minig techniques to change logs.

The necessity to support the user in exceptional situations has been addressed

by adaptive process management technology [1,9,16]. ADEPT [1], for instance,

supports the user in deﬁning (syntactically) correct process changes during run-

time. For example, when an activity is deleted at the process instance level, the

system might suggest the deletion of data dependent activities as well. However,

ADEPT does not consider semantical dependencies between changes yet.

Complementary to this paper [17] covers quality aspects relevant when ap-

plying CBR for the memorization and the reuse of ad-hoc modiﬁcations and the

deriviation of process type changes. While [17] broadly deals with quality issues

and aims at increasing the performance of the CBR system by increasing prob-

lem solving eﬃciency, CB competence and solution quality, this paper addresses

how user assistance can be improved through mining inter-case dependencies.

6 Summary and Outlook

We have proposed an approach to improve exception handling in adaptive pro-

cess management systems through discovering and utilizing knowledge about