2. Overview
Chapter 1
Introduction
Part I: Preliminaries
Chapter 2 Chapter 3
Process Modeling and Data Mining
Analysis
Part II: From Event Logs to Process Models
Chapter 4 Chapter 5 Chapter 6
Getting the Data Process Discovery: An Advanced Process
Introduction Discovery Techniques
Part III: Beyond Process Discovery
Chapter 7 Chapter 8 Chapter 9
Conformance Mining Additional Operational Support
Checking Perspectives
Part IV: Putting Process Mining to Work
Chapter 10 Chapter 11 Chapter 12
Tool Support Analyzing “Lasagna Analyzing “Spaghetti
Processes” Processes”
Part V: Reflection
Chapter 13 Chapter 14
Cartography and Epilogue
Navigation
PAGE 1
3. Process mining spectrum
supports/
“world” business
controls
processes software
people machines system
components
organizations records
events, e.g.,
messages,
specifies transactions,
models
configures etc.
analyzes
implements
analyzes
discovery
(process) event
conformance
model logs
enhancement
PAGE 2
4. Refined process mining framework
people organizations
machines
business “world”
processes documents
information system(s)
provenance
event logs
“pre “post
mortem” current historic mortem”
data data
navigation auditing cartography
recommend
diagnose
compare
enhance
discover
promote
explore
predict
detect
check
models
de jure models de facto models
control-flow control-flow
data/rules data/rules
resources/ resources/
organization organization
PAGE 3
5. Business process provenance
people organizations
machines
business “world”
processes documents
information system(s)
provenance
event logs
“pre “post
mortem” current historic mortem”
data data
PAGE 4
6. Two types of event data:
post and pre mortem
• “Post mortem” event data refer to information about
cases that have completed, i.e., these data can be
used for process improvement and auditing, but not
for influencing the cases they refer to.
• “Pre mortem” event data refer to cases that have not
yet completed. If a case is still running, i.e., the case
is still “alive” (pre mortem), then it may be possible
that information in the event log about this case (i.e.,
current data) can be exploited to ensure the correct
or efficient handling of this case.
PAGE 5
7. Two types of models: “de jure models”
and “de facto models”
• A de jure model is normative, i.e., it specifies how
things should be done or handled. For example, a
process model used to configure a BPM system is
normative and forces people to work in a particular
way.
• A de facto model is descriptive and its goal is not to
steer or control reality. Instead, de facto models aim
to capture reality.
PAGE 6
8. Cartography
“post
historic
• Discover. This activity is data
mortem”
concerned with the extraction of
(process) models. cartography
• Enhance. When existing process
diagnose
enhance
discover
models (either discovered or
hand-made) can be related to
events logs, it is possible to
enhance these models. models
de facto models
• Diagnose. This activity does not
directly use event logs and control-flow
focuses on classical model-based
analysis. data/rules
resources/
organization
PAGE 7
9. Auditing
event logs
• Detect. Compares de jure models “pre “post
with current “pre mortem” data. The mortem” current
data
historic
data
mortem”
moment a predefined rule is
violated, an alert is generated auditing
(online).
compare
promote
detect
check
• Check. The goal of this activity is to
pinpoint deviations and quantify the
level of compliance (offline). models
de jure models de facto models
• Compare. De facto models can be
compared with de jure models to see control-flow control-flow
in what way reality deviates from
what was planned or expected. data/rules data/rules
• Promote. Promote parts of the de resources/ resources/
organization organization
facto model to a new de jure model.
PAGE 8
10. Navigation
event logs
• Explore. The combination of event “pre “post
mortem” current historic mortem”
data and models can be used to data data
explore business processes at
run-time. navigation
recommend
• Predict. By combining information
explore
predict
about running cases with models,
it is possible to make predictions
about the future, e.g., the
models
remaining flow time and the
probability of success.
• Recommend. The information
used for predicting the future can
also be used to recommend
suitable actions (e.g. to minimize
costs or time).
PAGE 9
11. Operational support:
online process mining using “pre mortem” event data
T=10
current
state
known unknown
past future a b a b ? ? a b c ?
detect: b does not fit the predict: some prediction is recommend: based on past
a b c d model (not allowed, too
late, etc.)
made about the future (e.g.
completion date or outcome)
experiences c is recommended
(e.g., to minimize costs)
PAGE 10
15. Example
b alert!!!!
examine
c3
thoroughly
g
c1 pay
c compensation
a examine
e
start register casually decide c5 end
request
h
c2 d c4 reject
check ticket request
f
reinitiate
request
PAGE 14
16. Declare specifications for
detecting violations
pay
• Satisfied: the LTL formula
compensation evaluates to true for the
g current partial trace.
c2
• Temporarily violated: the
c1 LTL formula evaluates to
a c4 e
register decide false, however, there is a
request c3 longer trace that evaluates
h to true.
reject
request • Permanently violated: the
LTL formula evaluates to
false for current trace and
all its extensions
PAGE 15
17. Conflicting constraints
• A Declare specification is
pay
satisfied for a case if all of its
compensation constraints are satisfied.
g • A Declare specification is
c4 c2
temporarily violated by a case if
c1
for the current partial trace at
a e
decide
least one of the constraints is
register
request c5 c3 violated, however, there is a
h possible future in which all
reject constraints are satisfied.
request
• A Declare specification is
permanently violated by a case if
no such future exists.
Note that c1, c2, and c3 imply that e cannot
be executed without permanently violating
the specification. PAGE 16
19. Examples of predictions
• the predicted remaining flow time is 14 days;
• the predicted probability of meeting the legal
deadline is 0.72;
• the predicted total cost of this case is 4500 euro;
• the predicted probability that activity a will occur is
0.34;
• the predicted probability that person r will work on
this case is 0.57;
• the predicted probability that a case will be rejected
is 0.67; and
• the predicted total service time is 98 minutes.
PAGE 18
23. Recommend
• Possible recommendations:
− next activity;
− suitable resource; or
− routing decision.
• A recommendation is always given with respect to a
specific goal.
• Examples of goals are:
− minimize the remaining flow time;
− minimize the total costs;
− maximize the fraction of cases handled within 4 weeks;
− maximize the fraction of cases that is accepted; and
− minimize resource usage.
PAGE 22
24. Relation between prediction and
recommendation
possible next state
prediction
current state
a1
a2
ak
...
PAGE 23
25. Process mining spectrum
people organizations
machines
business “world”
processes documents
information system(s)
Chapter 1
Introduction
provenance
event logs
Part I: Preliminaries
“pre “post Chapter 2 Chapter 3
mortem” current historic mortem”
Process Modeling and
Analysis
Data Mining
data data
Part II: From Event Logs to Process Models
Chapter 4 Chapter 5 Chapter 6
Getting the Data Process Discovery: An Advanced Process
navigation auditing cartography Introduction Discovery Techniques
recommend
Part III: Beyond Process Discovery
diagnose
compare
enhance
discover
promote
explore
predict
detect
Chapter 7 Chapter 8 Chapter 9
check
Conformance Mining Additional Operational Support
Checking Perspectives
Part IV: Putting Process Mining to Work
Chapter 10 Chapter 11 Chapter 12
Tool Support Analyzing “Lasagna Analyzing “Spaghetti
Processes” Processes”
models Part V: Reflection
de jure models de facto models Chapter 13 Chapter 14
Cartography and Epilogue
Navigation
control-flow control-flow
data/rules data/rules
resources/ resources/
organization organization
PAGE 24
