Han-na Yang

Rediscovering Workflow Models from Event-Based Data using Little Thumb

Introduction

Work flow management systems Offer generic modeling and enactment capabilities for structured business

processes Too restrictive Have problems dealing with change (=not flexible) ex) Staffware, IBM MQSeries, COSA, etc.

Many problems are resulting from discrepancy between workflow design and workflow enactment

“Reverse the process”: Process Mining

We start by gathering information about the workflow processes as they take place. Do not start with a workflow design. Any information system using transactional system or workflow manage-

ment system will offer this information in some form Assumption: it is possible to construct workflow logs with event data

Process mining The method of distilling a structured process description from a set of real

executions.

We focus on workflow processes with concurrent behavior Detecting concurrency is one of our prime concerns Distinguishing AND/OR splits/joins explicitly

Workflow Process Model

Workflows ‘Case-based’: every piece of work is executed for a specific case Case: handled by executing tasks in a specific order (ex. Insurance claim,

mortgage)

Workflow process model Specifies which tasks need to be executed and in what order Routing elements: describe sequential, conditional, parallel and iterative

routing

Petri nets

OR-join

OR-split

AND-split

AND-join

Tasks are modeled by transitions Places and arcs model causal dependencies

Split & Join

WorkFlow net (WF-net)

A Petri net that models the control-flow dimension of a workflow Focuses on the process perspective and abstract from the func-

tional, organization, information and operation perspectives

Sound WF-nets Termination is guaranteed No dangling tokens are left behind No dead task

Workflow log is sequence of events

A Heuristic Process Mining Technique

Four ordering relation in the α-algorithm (Let A, B be events, W a work-flow log) A>B: if and only if there is trace line in W in which event A is directly fol-

lowed by B A→B: dependency relation, B depends on A A#B: non-parallel relation, no dependency between A and B A∥B: parallel relation, used to detect the kinds of splits and joins

Heuristic mining technique Less sensitive for noise and the incompleteness of logs than α-algorithm Three mining steps

① The construction of a dependency/frequency table(D/F-table)

② The induction of a D/F-graph out of a D/F-table

③ The reconstruction of the WF-net out of the D/F-table and the D/F-graph

Step 1: Construction of the dependency/frequency table

For each task A these information is abstracted out of the workflow log① The overall frequency of task (#A)

② The frequency of task A directly preceded by another task B (#B>A)

③ The frequency of A directly followed by another task B (#A>B)

④ A local metric that indicates the strength of the dependency relation between task A and another task B ($A→LB)

⑤ A more global metric that indicates the strength of the dependency relation ($A→B)

$A→B-dependency counter It is incremented with a factor (δ)n

Dependency fall factor(δ: delta) is [0.0 … 1.0] n is the number of intermediary events between them Therefore, if task B appears directly after task A then (δ)n=1(n=0). $A→B-dependency counter decreases if the distance between tasks in-

creases.

Step 1: Construction of the dependency/frequency table

Example T6 is never directly

preceded by T10

(#B>A=0) T6 is often directly fol-

lowed by T10

(#A>B=581)

>

Step 2: Induction of dependency/fre-quency graphs

Heuristic rules

Four conditions demand that specific values of the D/F graph (#A>B, #B<A, $A→LB, $A→B) are higher or lower than a certain threshold value(σ, N1, N2)

Only task-pattern occurrences above a threshold frequency are reliable enough for our induction process

Formulating a rule that for each pair of events A and B takes the decision if they are in the dependency relation or not is not really necessary.

First (temporally) version of mining rule 1. given a task A: A→ X if and only if X is the event for which DS(A,X) is maximal Y→A if and only if Y is the event for which DS(Y,A) is maximal

Dependency score: DS(X,Y) = (($X→LY )2 + ($X → Y )2) / 2 New rule does not contain any parameter

>

Step 2: Induction of dependency/fre-quency graphs

For each arc the dependency score(DS) is given and for each task the number of event occurrences in the log

Step 2: Induction of dependency/fre-quency graphs

The first version of mining rule 1 is updated Mining rule 1 (definite version). Given a task A

Suppose X is the event for which DS(A,X)=M is maximal. Then A→Y if and only if DS(A,Y)<0.95*M

Suppose X is the event for which DS(X,A)=M is maximal. Then Y→A if and only if DS(Y,A)<0.95*M

Threshold value is(0.95) only one parameter and the parameter seems robust for noise and concurrent processes.

Step 3: Generating WF-nets from D/F-graphs

The types of the splits and joins are not represented in the D/F-graph

Useful information to indicate the type of a join and split Information in the D/F-table: determine split or join

A to B AND C (AND-split): pattern B,C and pattern C,B can both appear A to B OR C (OR-split): pattern B,C and pattern C,B will not appear

The frequency of the nodes in the D/F-graph Used for the validation of the induced workflow model

After observations, apply the α-algorithm to translate this infor-mation into a WF-net

Little Thumb

A tool that attempts to induce a workflow model from a workflow log The workflow log may contain errors(noise) and can be incomplete

Steps to analyze the loaded workflow log① Already executed (D/F-table in the Figure 4)

② Induction of a D/F-graph out of D/F-table (Figure 5)

③ Use the information in the extended D/F-table to indicate join and split (Figure 6)

Check WF-net tab: possibility to validate the WF-net First check: checks if the trace can be parsed by the WF-net Second check: test out the frequency information of the events is in accor-

dance with the structure of the minded WF-net

Little Thumb

Generate WF-log tab

It is possible to load a WF-net and to gener-ate workflow logs, with or without noise

Select-events tab We can concentrate

our mining process on the most frequent events and neglect low frequent events

Little Thumb

The types of the splits and joins are not represented in the D/F-graph

Little Thumb

First Experiments

Six different free-choice workflow models All models contain concurrent processes and loops

For each model we generate three random workflow logs with 1000event sequences A workflow log without noise One with 5% noise A log with 10% noise

Four different types of noise Delete the head of a event sequence Delete the tail of a event sequence Delete a part of the body Interchange two random chosen events

First Experiments

Six noise free workflow logs results in six perfect D/F-graphs If we add 5% or 10% noise to the work flow logs, the resulting

D/F-graphs and WF-nets are still perfect

>

Second experiments

Four elements strongly influence the behavior of a WF-net and/or the workflow mining process The number of event types in the WF-net

12, 22, 32, 42 event types The amount of material in the workflow log

100, 200, 600, 1000, 1400, 2000 trace lines The amount of noise

5%, 10%, 20%, 50% noise The unbalance res to the probability that enabled event will fire

Generate 480 different workflow logs by varying each of the above enumerated elements

Second experiments

Conclusion Under all circumstances most dependency relations, the type of split and

the type of joins are correctly found Mining technique appears especially robust for the number of trace lines

and the amount of unbalance 50% noise cause serious problems Most errors have to do with short loops An improvement of the heuristic rules for short loops seems necessary

ProM Tool (1)

ProM Tool (2)

ProM Tool (3)

ProM Tool (4)

Questions ?