Keynote talk at ATAED 2017 @ PN/ACSD 2017

Modelling & Mining Event-based Concurrent
Declarative Processes as
Dynamic Condition Response (DCR) Graphs
Thomas T. Hildebrandt  
joint work with
S. Debois, K. R. Ulrik, P. H. Laursen (ITU),T. Slaats (KU), R. Mukkamala (CBS), M. Marquard (Exformatics)
Process Intelligence, Modelling & Optimisation Group
IT University of Copenhagen (ITU) Denmark
Invited talk - ATAED 2017 @ PN/ACSD2017
June26th, 2017
IT UNIVERSITY OF COPENHAGENITUNIVERSITYOFCOPENHAGEN SUBMISSION OF WRITTEN WORK
Class code:
Name of course:
Danish Defence Agency

IT UNIVERSITY OF COPENHAGEN
Modelling & Mining Event-based Concurrent Declarative Processes as DCR Graphs ATAED 26/6/17
Thomas T. Hildebrandt (hilde@itu.dk)
Motivation
2
IT systems increasingly control and
support critical processes & interactions
between humans and machines

Motivation
2
and operate in
unpredictable and
changing contexts

Motivation
2
Need for ﬂexibility, adaptability & compliance with
legal, safety and security regulations
and operate in
unpredictable and
changing contexts

40 years of ﬂow diagrams…
3
zc
:=
Computer Science and
Office Information Systems
By Clarence A. Ellis and Gary J. Nutt
ORDERPROCESSING
LogRequest
TypeOrder
SendOrder
ReceiveOrder
BrocessII
J
I
I
•
:1.1
Customer
Request
Arrival
lL
-""/
I
I
r
•r
J/.I
I
A/I
"
Order
Form
'"I
+0I,Custamer
JjFile
I
IIBillingFile
I
I
I
J
I
J
I
I
I
I
I
I
I
/
I,
lOut"
1:;;1tJ.lOut.I
tForm'--------/--""
',----..._------_.._-..,.-'
F.igure2
70’ties:
2010 - now:

What is the problem with ﬂows?
4

4
Inflexible execution and development
IT UN
Towards effective, flexible & legally compliant digital knowledge workflows
The computer says no….
5
Performance
goals
Best
practice
the computer
says no
The baby is
coming!

4
Only describe how not why
difﬁcult to adapt when regulations change
IT UN
5
Performance
goals
Best
practice
the computer
says no
The baby is
coming!

4
Only describe how not why
difﬁcult to adapt when regulations change
Limited support for modularity & re-use
IT UN
5
Performance
goals
Best
practice
the computer
says no
The baby is
coming!

The true process landscape
5
Completely predictable &
many repetitions, few changes
Completely unpredictable,
few repetitions & changes
Partially predictable,
some repetition
& some changes
Very few (<5%) work processes fully predictable
Workﬂows and it-systems contain unpredictable parts and
need to be changed over time
A FUTURE
THAT WORKS:
the impact of automation
in Denmark

Flexibility versus Support
6
Motivation
Flexibility versus Support in workflows
• Flexibility: ability to defer, change,
and deviate
• support: provide analysis and
guidance
• unstructured: do what ever you
want, but get no support
• structured: support, but no
flexibilityClassical trade-off between flexibility and support1
[1] W.M.P. van der Aalst et al. Declarative workflows: Balancing between flexibility and support
Sunday, March 14, 2010
Motivation
and deviate
guidance
[1]W.M.P. van der Aalst et al. Declarative workflows: Balancing between flexibility and support
unday, March 14, 2010
[Schmidt & Bannon:Taking CSCW Seriously: Supporting Articulation Work, 1992]
Already in 1983, researchers in
Computer Supported Cooperative
Work (CSCW) concluded that office
automation systems “do not deal
well with unanticipated
conditions” (Barber) & “were
automating a fiction” (Sheil)

Flexibility versus Support
6
Motivation
and deviate
guidance
[1] W.M.P. van der Aalst et al. Declarative workflows: Balancing between flexibility and support
Sunday, March 14, 2010
Motivation
and deviate
guidance
[1]W.M.P. van der Aalst et al. Declarative workflows: Balancing between flexibility and support
unday, March 14, 2010
[Schmidt & Bannon:Taking CSCW Seriously: Supporting Articulation Work, 1992]
Already in 1983, researchers in
Computer Supported Cooperative
Work (CSCW) concluded that office
automation systems “do not deal
well with unanticipated
conditions” (Barber) & “were
automating a fiction” (Sheil)
“Good standards for business process
modelling are still missing and even today’s
WFMSs are too rigid”
Process-Aware Information Systems:
Design, Enactment, and Analysis
Wil M.P. van der Aalst
Department of Mathematics and Computer Science, Eindhoven University o
nology, P.O. Box 513, NL-5600 MB Eindhoven, w.m.p.v.d.aalst@tue.nl
Abstract. Process-aware information systems support operational busine
cesses by combining advances in information technology with recent in

Example from local government
7
Compliant?
• Lov om Aktiv beskæftigelsesindsats
(LBK nr 1428 af 14/12/2009)
• Lov om Aktiv socialpolitik
(LBK nr 946 af 01/10/2009)
• Lov om Arbejdsløshedsforsikring
(LBK nr 574 af 27/05/2010)
• Lov om Integration af udlændinge
(LBK nr 1062 af 20/08/2010)
• Lov om Sygedagpenge
(LOV nr 563 af 09/06/2006)
• Retssikkerhedsloven
(LBK nr 1054 af 07/09/2010)
• Datagrundlag
(BEK nr 418 af 23/04/2010)
arbejdsgangsbanken.dk2010: Case Studies of Best
Practice Workﬂow and
Workﬂow in Practice
(Innovation Network Project)

7
Change in law Compliant?
(LBK nr 1428 af 14/12/2009)
(LBK nr 946 af 01/10/2009)
(LBK nr 574 af 27/05/2010)
(LBK nr 1062 af 20/08/2010)
(LOV nr 563 af 09/06/2006)
(LBK nr 1054 af 07/09/2010)
• Datagrundlag
(BEK nr 418 af 23/04/2010)

7
(LBK nr 1428 af 14/12/2009)
(LBK nr 946 af 01/10/2009)
(LBK nr 574 af 27/05/2010)
(LBK nr 1062 af 20/08/2010)
(LOV nr 563 af 09/06/2006)
(LBK nr 1054 af 07/09/2010)
• Datagrundlag
(BEK nr 418 af 23/04/2010)
How to change??

7
(LBK nr 1428 af 14/12/2009)
(LBK nr 946 af 01/10/2009)
(LBK nr 574 af 27/05/2010)
(LBK nr 1062 af 20/08/2010)
(LOV nr 563 af 09/06/2006)
(LBK nr 1054 af 07/09/2010)
• Datagrundlag
(BEK nr 418 af 23/04/2010)
How to change??
arbejdsgangsbanken.dk
Change in practice
2010: Case Studies of Best

7
(LBK nr 1428 af 14/12/2009)
(LBK nr 946 af 01/10/2009)
(LBK nr 574 af 27/05/2010)
(LBK nr 1062 af 20/08/2010)
(LOV nr 563 af 09/06/2006)
(LBK nr 1054 af 07/09/2010)
• Datagrundlag
(BEK nr 418 af 23/04/2010)
How to change??
Change in practice
Still compliant ??

7
(LBK nr 1428 af 14/12/2009)
(LBK nr 946 af 01/10/2009)
(LBK nr 574 af 27/05/2010)
(LBK nr 1062 af 20/08/2010)
(LOV nr 563 af 09/06/2006)
(LBK nr 1054 af 07/09/2010)
• Datagrundlag
(BEK nr 418 af 23/04/2010)
How to change??
Change in practice
Still compliant ??
gave up January 2013

Flow diagrams are like…
8

8
following pre-speciﬁed route(s)

8
If you leave the route,
you are on your own &
can not see the road

8
you are on your own &
can not see the road
If the map changes,
you have no idea how to
update the routes

We need a workﬂow GPS
9

9
where the route is calculated
from the map and your goal

9
a new one can be calculated

9
If the map changes, 
the route can be adjusted

9
If the map changes, 
the route can be adjusted
- achieved by modelling processes
declaratively as DCR Graphs

DCR Graphs: A decade of R&D
10
2007-11: Computer Supported Mobile Adaptive Business Processes
(Danish Research Foundation for Technology and Production)

10
2008-2012: Trustworthy Pervasive Healthcare Processes
(Danish Strategic Research Council)

10
2009-13: Services in Context  

10

10
DCRGraphs.com
2011-2014: Flexible Cross-organizational Case Management
(Industrial PhD)

10
2014-17: Computational Artifacts: Design Oriented Theory of
Computational Artifacts in Cooperative Work Practices
(Velux Foundation, www.COMPART.ku.dk)
DCR.Tools
DCRGraphs.com
(Industrial PhD)

10
2015: Finance Case:
Visualising for Customers, Business & IT
(Copenhagen Fintech Innovation & Research)
DCR.Tools
DCRGraphs.com
(Industrial PhD)

10
2015-16: ProSec: Cyber security and ICT Infrastructure with importance to crucial functions
in Denmark - Mapping Emergency and Security Processes in the Danish Public Transport
Sector and their Dependency on ICT (Royal Danish Defence College)
2015: Finance Case:
Visualising for Customers, Business & IT
(Copenhagen Fintech Innovation & Research)
DCR.Tools
DCRGraphs.com
(Industrial PhD)

DCRGraphs.com & DCR.Tools
11
Commercial tool
(free for test &
academia)
Academic tool

Events & roles
12
Events as
“Post-it notes”

Events & roles
12
Events as
“Post-it notes”
Can simulate at
any time

Simulation
13

Simulation
13
add computer as users

Simulation
13
add computer as users
add friends as users

Any task is possible
14

Swim lane view of simulation
15

Save simulation as Happy
16

Write description
17

Hurried case
18

Hurried case not compliant
19
Fig. 10.1 Prespecified process model Smed
Table 10.1 Examples of compliance rules for medical processes
c1 Before a surgery may be performed the patient must be prepared for it and be sent to
the surgical suite.
c2 After examining the patient a decision must be made. However, this must not be done
before the examination.
c3 After the examination, the patient must be informed about the risks of the (planned)
surgery.
c4 Before scheduling the surgery the patient has to be informed about anesthesia.
c5 If a surgery has not been scheduled it must not be performed.
c6 After a patient is discharged a discharge letter must be written.
c7 After performing the surgery and before writing the discharge letter, a surgery report
must be created and a lab test be made.
particularly crucial for process instances defined or adapted on-the-fly (cf. Chap. 7),
i.e., for which there is no fully prespecified process model. Likewise, compliance
monitoring at run-time is required if a priori compliance checking is not feasible,
e.g., if the process model is too large or the compliance rules are too complex.

Save unhappy hurried case
20

Re-run or re-play simulations
21
re-run as test on current graph
re-play on
original graph

Re-run or re-play simulations
22

Add condition constraints
23

Re-run simulations
24

Conditions disable events
25

Make decision enabled
26

Also response constraints
27
Table 10.1 Examples of compliance rules for medical processes
c1 Before a surgery may be performed the patient must be prepared for it and be sent to
the surgical suite.
c2 After examining the patient a decision must be made. However, this must not be done
before the examination.
c3 After the examination, the patient must be informed about the risks of the (planned)
surgery.
c4 Before scheduling the surgery the patient has to be informed about anesthesia.
c5 If a surgery has not been scheduled it must not be performed.
c6 After a patient is discharged a discharge letter must be written.
c7 After performing the surgery and before writing the discharge letter, a surgery report
must be created and a lab test be made.
particularly crucial for process instances defined or adapted on-the-fly (cf. Chap. 7),
i.e., for which there is no fully prespecified process model. Likewise, compliance
monitoring at run-time is required if a priori compliance checking is not feasible,
e.g., if the process model is too large or the compliance rules are too complex.
Regarding completed process instances, in addition, a process-aware information
system (PAIS) needs to be able to determine whether these instances were executed
Responses

Simulation with responses
28
required before the process can complete

No more pending responses
29
no more pending responses, process can end

Excluded = irrelevant events
30
events may be excluded initially
http://www.dcrgraphs.net/Tool?id=4863#

Dynamic inclusion & exclusion
31

Thomas T. Hildebrandt (hilde@itu.dk) 32
Dynamic inclusion & exclusion

Complete constraint map
33
http://www.dcrgraphs.net/Tool?id=4864#

DCR Graphs as formulars
34

Data & Declarative Forms
35
Fig. 1. Reimbursement claim approval form (rejecting).
f the manager chooses “Approve”, the form is complete and may be sub-
mitted.
f the manager chooses “Reject”, a new field appears—the “Justify rejection”
ext box of Figure 1.
When this field appears, it must be filled in before the form can be submitted.
f the manager changes his mind and reverts his choice from “Reject” to
“Approve”, the description field should disappear again.
Fig. 2. Reimbursement claim approval form (initial appearance).
make two notes about this form and its behaviour.
irst, even this seemingly exceedingly simple form has fairly complex be-
our when you sit down and write it out as we did in the above list. Getting
behaviour right is not necessarily di cult, but it is time-consuming and
nsive because of the required programmer intervention.
econd, the form and the rules governing it are inextricably linked with the
ess to which the form contributes. The little list above is littered with men-
3. If the manager chooses “Approve”, the form is complete and ma
mitted.
4. If the manager chooses “Reject”, a new field appears—the “Justify
text box of Figure 1.
5. When this field appears, it must be filled in before the form can be s
6. If the manager changes his mind and reverts his choice from “R
tions; this is an extension to the syntax and semantics of DCR graphs
has not yet appeared in the scientific literature.
DCR comprises (1) a set of activities and (2) a set of relations between
tivities. Activities are there to be executed, and relations indicate what
es happen to the state of the DCR graph as activities are executed. By
ntion, executing an activity in a DCR graph may input a data value for
tivity.
the name suggests a DCR graph is a graph: the nodes are activities, and
ges relations.
a running example, we will use the DCR graph depicted in Figure 3. This
graph is a minimal model of the travel reimbursement workflow sketched
tion 2. It has just two activities (boxes): Approve or reject (to the left) and
Rejection (to the right).
Fig. 3. Example DCR graph (reimbursement workflow)
*
*
*

35
mitted.
mitted.
tivity.
ges relations.
*
*
*
ust have put data into it. In particular, the user is free to subsequently
validate the contents of the field.
eviate this tension, we must model more faithfully the dynamic be-
the form, taking into account the event of invalidating the required
do so by adding to our model a response arrow from the pending
itself, guarded by value = null. This means that whenever the field is
with a null value, it will be marked as pending again, ensuring that the
s not, in fact, complete before the activity/field is either excluded or
non-null value. Of course, one could define more complex criteria for
lue is invalid and thus trigger the response. In particular, the guard
end on the value entered in other fields.
4. Variant of DCR graph in Figure 3 taking null-values into account.

35
Forms are Declarative Processes! [BPM Case paper 2016]
mitted.
mitted.
tivity.
ges relations.
*
*
*
ust have put data into it. In particular, the user is free to subsequently
validate the contents of the field.
eviate this tension, we must model more faithfully the dynamic be-
the form, taking into account the event of invalidating the required
do so by adding to our model a response arrow from the pending
itself, guarded by value = null. This means that whenever the field is
with a null value, it will be marked as pending again, ensuring that the
s not, in fact, complete before the activity/field is either excluded or
non-null value. Of course, one could define more complex criteria for
lue is invalid and thus trigger the response. In particular, the guard
end on the value entered in other fields.
4. Variant of DCR graph in Figure 3 taking null-values into account.

Modelling & Validation
37
Papers: [ACM15,BPM13-15]
Papers: [BPM14]

DCR Graphs for execution
38
Workﬂow engine
Papers: [ACM15,BPM13-15]

Seamless & safe distribution
39
Workﬂow engine Workﬂow engine
Papers: [SEFM2011,FHIES2011,BPM15]

Monitoring & Compliance
40
Run-time monitor
Papers: [R. Mukkamala PhD,CSF 2016]

Policy enforcement
41
Policy enforcement point
Papers: [CSF 2016]

What is special for DCR graphs?
42

• Formal and close to natural language: 
Conditions, Responses, Inclusions and Exclusions
42

• Expressive and decidable: 
Can express all regular safety and liveness properties
42

• Operational and understandable: 
Run-time state as “check-list” on events
42

• Operational and understandable: 
Run-time state as “check-list” on events
• Efﬁcient distributed monitoring & enactment 
Locally determine enabledness & effect of events
42

Additional work
• Time & Dynamic Subprocesses
• Independence analysis (true concurrency)
• Applications to case studies [FHIES2011,ACM14,BPM15,S4CIP16] 
(Healthcare, funding agency, ﬁnance & emergency management)
• Run-time adaptation & reﬁnement 
[EDOC2013][ACM14][FM15]
• Programming Language, Data & Forms
43
[JLAP82,2013, BPM14,FM15]
[DEBS2012,REBLS15,
BPM CASE 2016]
[BPM15]

Dealing with state space explosion
• Safe distribution & infer concurrency
• Modularity & step-wise reﬁnement
• Static analysis for reachability & enforceability [CSF15]
44
[SEFM2011,BPM15]
[FM15]
vs

True concurrency
45
Provides an asynchronous transition system

Timed DCR Graphs
46
Eventually is often not good enough….

Timed DCR Graphs
46
and delays may be required

Timed DCR Graphs
46
and delays may be required
Timed DCR Graphs introduce
delays on conditions, and deadlines on responses
[JLAP82,2013,
CSF2016]

Delays & Deadlines
47
“After eating you must wait 12 hours before surgery”
“After surgery, a checkup must be done within 7 days”

Enforceability & Escalation
48
Some events are uncontrollable
in particular progress of time and human activities

48
Need compensation/escalation &
pro-active enforcement [CSF2016]

48
Need compensation/escalation &
pro-active enforcement [CSF2016]
Try research-prototype at dcr.tools/obligations

Sub processes & inﬁnity
• Dynamically spawned sub processes
• supported in theory and tools - but makes
termination undecidable
• not a problem for enactment, run-time monitoring &
(some) static analysis (reﬁnement)
49
[FM15]
[FM15]

Reﬁnement & Security
50

Reﬁnement & Security
50
(EU General
Data Protection
Requirement)

Mining Declarative Processes
51
Process log Statistically inferred
constraints
Inferred ﬂows
Avoid mined spaghetti diagrams

First DCR mining algorithm
52
Contradiction based mining:
1) Start with every possible
condition, response, exclusion
and every activity excluded,
pending & not executed
2) Remove relation & include
activity when contradiction
found in log
Declarative Process Mining for DCR Graphs⇤
Søren Debois
IT University of Copenhagen
Copenhagen, Denmark
debois@itu.dk
Thomas T. Hildebrandt
Copenhagen, Denmark
hilde@itu.dk
Paw Høvsgaard Laursen
Copenhagen, Denmark
pawh@itu.dk
Kenneth Ry Ulrik
Copenhagen, Denmark
kulr@itu.dk
ABSTRACT
We investigate process mining for the declarative Dynamic
Condition Response (DCR) graphs process modelling lan-
guage. We contribute (a) a process mining algorithm for
DCR graphs, (b) a proposal for a set of metrics quantifying
output model quality, and (c) a preliminary example-based
comparison with the Declare Maps Miner. The algorithm
takes a contradiction-based approach, that is, we initially
assume that all possible constraints hold, subsequently re-
moving constraints as they are observed to be violated by
traces in the input log.
Keywords
Declarative process mining; DCR graphs
1. INTRODUCTION
Business process management (BPM) technologies [33]
support the management and digitalisation of workflows and
business processes by employing explicit process models, fol-
lowing a cycle of process (re)design, validation, execution
and monitoring.
Process mining algorithms [32] have been proposed for the
identification of process models from process logs, support-
ing both process design and compliance monitoring.
Most industrial BPM tools and process miners describe
processes as imperative flow diagrams such as BPMN. How-
ever, flow diagrams tend to get either too rigid or too com-
plex, in particular for knowledge work processes having a
high degree of variation [28]. Moreover, flow diagrams only
describe how to perform a process, leaving a gap to the legal
regulations and guidelines, that are often more declarative
in nature, describing why the process must be performed in
⇤Authors listed alphabetically. This work supported in part
by the Velux Foundation, grant 33295, and Exformatics
A/S.
Permission to make digital or hard copies of part or all of this work for personal or
classroom use is granted without fee provided that copies are not made or distributed
for profit or commercial advantage and that copies bear this notice and the full citation
on the first page. Copyrights for third-party components of this work must be honored.
For all other uses, contact the owner/author(s).
SAC 2017 April 03-07, 2017, Marrakech, Morocco
c 2017 Copyright held by the owner/author(s).
ACM ISBN 978-1-4503-4486-9/17/04.
DOI: http://dx.doi.org/10.1145/3019612.3019622
certain ways, not how exactly it must be performed. For
instance, a clinical guideline may state, that a patient must
consent to a blood transfusion [13]. It does not state ex-
actly when such consent should be obtained, only “prior to
the transfusion”.
For this reason, it is recommended to use flow diagrams
only for routine processes, or for describing common stan-
dard practices and allow deviations [28]. It has been advo-
cated that declarative notations should be used as output of
process mining (e.g. [17]) and for run-time process support
(e.g. [25, 24, 29]). For the former, one hopes to extract
from a process log the rules obeyed in practice (the “why”)
as opposed to a flow-diagram describing the usual executions
(the “how”). For the latter, one hopes to guide knowledge
workers to activities in conformance with rules and regula-
tions.
Implementation techniques for most declarative models
such as Declare [27] and DecSerFlow [31], rely on translating
the declarative constraints to an imperative model (e.g., an
automaton [20]) to enable execution. Such translation usu-
ally entail a state-space explosion, and run-time adaptation
of constraints becomes more di cult, because the automa-
ton must be recomputed when constraints change.
A notable exception is the Dynamic Condition Response
(DCR) graphs process language [11, 30]. DCR graphs can be
executed without intermediate transformation to an imper-
ative model creating the entire transition graph, and more
directly support run-time adaptive case management [24,
5]. DCR graphs are supported by industrial design and case
management tools (see e.g. dcrgraphs.net and [5]).
In the present paper, we present the first process mining
algorithm for DCR graphs.
2. DCR GRAPHS
In this Section, we briefly recall DCR graphs. For a formal
introduction and applications, refer to [11, 23, 30, 3, 5, 6].
Dynamic Condition Response graphs is a declarative mod-
elling notation describing at the same time a process and
its run-time state. The core notation comprises activities,
activity states, and four relations between activities. An ac-
tivity state comprises three booleans, indicating respectively
whether the activity has been executed, is included, and
is pending. Intuitively, activities that are not included are
treated as temporarily absent from the workflow; activities
that are pending must eventually be executed or excluded
before the workflow may complete.
[SAC 2017]
Implemented at dcr.tools

Example
53
Provide Budget
Calculate Maximum Cost
Find Houses
Buy
Provide Budget
Find Houses
Logs

Remove redundancy
54
Provide Budget
Find Houses
Buy
Provide Budget
Find Houses
Logs

Add trace & remove redundancy
55
Provide Budget
Find Houses
Buy
Provide Budget
Find Houses
Provide Budget
Find Houses
Provide Budget
Logs
ProvideBudget CalculateMaximumCost FindHouses
http://dcr.itu.dk/Workbench/Default/2265168991/1033131530

Not always perfect ﬁt
56

Can view as transition system
57

What is the new LTS?
58

What is the new LTS?
59

Thoughts on DCR process Miner
• DCR process miner heavily uses include/exclude
• Future work:
• Most frequent activities included initially ?
• Parallelise (seems promising)
• Time? Map to true concurrent model
We collaborate with KMD and danish municipalities.  
Look out for possibilities to join our team as postdoc -
write me if interested.
60

True Concurrent Mining
61

Conclusions
62

Conclusions
• Flow-graphs take routes as starting point: Often too
inﬂexible, do not capture why, difﬁcult to maintain
62

Conclusions
• DCR graphs take events and constraints as starting
point: Support ﬂexibility, adaptability and formal
validation of compliance and correctness 
Can express all omega-regular concurrent languages
62

Conclusions
• Tool support & applied with success in industry
62

Conclusions
• Early work on mining [SAC17] and reﬁnement [FM15]
62

Conclusions
• Early work on mining [SAC17] and reﬁnement [FM15]
• Look out for postdoc & ph.d. positions to join us!
62

The future
63
S (Italy)
d
gi,
m
Municipality partners
as early adopters:
Koncern IT - Copenhagen Municipality
IT & Digitalisation,
Syddjurs Municipality
Kammeradvokaten
& Globeteam
ve case management for knowledge workers
ation of knowledge work processes
regulations (e.g. data protection)
ness and legal compliance
Enabling technologies
shared as open source tools
via the OS2 open source
digitalisation community
Effective, co-created & compliant
adaptive case management solutions
for knowledge workers
decision
support
enter
(LOV nr 563 af 09/06/2006)
(LBK nr 1054 af 07/09/2010)
• Datagrundlag
(BEK nr 418 af 23/04/2010)
of log-ﬁles
Process-mining
Pro-active compliance
Prescriptive BPM

Keynote talk at ATAED 2017 @ PN/ACSD 2017

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Keynote talk at ATAED 2017 @ PN/ACSD 2017

Similar to Keynote talk at ATAED 2017 @ PN/ACSD 2017 (20)

Recently uploaded

Recently uploaded (20)

Keynote talk at ATAED 2017 @ PN/ACSD 2017