Finals of Kant get Marx 2.0 : a general politics quiz
Thomas Hildebrandt process design 19062013
1. Design af (digitale) processer
Thomas Hildebrandt
Facilitator for videngruppen Digitalisering og procesorientering
Lektor ved IT Universitetet i København
VidenDanmark Akademi
Temadag 19. juni 2013
Wednesday, June 19, 13
2. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
Introduktion
Program
for
formiddag
• 9-9.30: Introduktion og præsentation af deltagere
• 9.30-10: Introduktion til processer
• 10-10.30: Introduktion til BPMN-processer
• 10.30-11: Pause - registrer dig i Signavio
• 11-12: Signavio-demo og opgave
• 12-13: Frokost
2
Wednesday, June 19, 13
3. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
Andre typer modeller
Program
for
e1ermiddag
• 13-14:Andre typer modeller:
• Offentlige, kollaborative processer: Pools
• Koreografier: Globale Interaktioner vs lokale aktioner
• Deklarative modeller: Beslutninger og Proceskrav
• 14-14.30: Pause
• 14.30-15.30: Beskriv din egen process
• 15.30-16: Opsamling og evaluering
3
Wednesday, June 19, 13
4. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
Introduktion
Præsenta5on
af
deltagere
• Navn, beskæftigelse, uddannelse, ...
• Erfaring med procesdesign
• Hvorfor deltager du ?
4
Wednesday, June 19, 13
5. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
Introduktion
Hvorfor
designe
processer?
• Dokumentere hvordan en proces udføres
• Beskrive hvordan en proces ønskes udført
• Leve op til regler og lovgivning
• Analyse, best-practice/vejledning, kravspecifikation, ...
• Forbedre, omstille, it-støtte, digitalisere, automatisere
Det stiller store krav til det “proces-sprog” vi bruger!
5
Wednesday, June 19, 13
6. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
Introduktion
Mål
med
temadagen
Deltagerne skal efter temadagen kunne:
• Forstå og bruge grundelementerne i Business Process
Model and Notation (BPMN) 2.0 standarden
• Forstå og bruge et state-of-the-art BPMN-værktøj til
at beskrive arbejdsgange og forretningsprocesser
• Forstå baggrunden for BPMN og Business Process
Management og begrænsningerne i BPMN
6
Wednesday, June 19, 13
7. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
Introduktion til processer
• låner, bibliotekar,...
• medarbejder, regnskab,
nærmeste leder, ....
• studerende,
studieadministrator, ...
• arbejdsløs,
jobcentermedarbejder,..
• Læge, patient, sygeplejerske
Hvad
er
en
proces
?
• Udlån af bog
• Betaling af faktura
• Udbetaling af løn
• Uddannelse af person
• Arbejdsløs i arbejde
• Udført en behandling
7
En proces har et mål: Og nogle aktører:
Wednesday, June 19, 13
8. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
Introduktion til processer
Ak5viteter
og
hændelser
og en række aktiviteter og hændelser, der fører
processen fra start til mål:
• Eksempler på starthændelser/aktiviteter:
Forespørgsel om bog,
modtagelse af faktura,
ansættelse i job,
ansøgning om uddannelse,
henvendelse hos jobcenter,
henvendelse hos læge, ...
8
Wednesday, June 19, 13
9. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
Introduktion til processer
Data
og
beslutninger
• Der bliver som regel indsamlet og bearbejdet data/
artefakter undervejs i en proces, som f.eks.
udlånsstatus, fakturabeløb, udgiftshaver,
eksamensresultater, recept, ...
• Data og artefakter bliver brugt til at
- beregne/fremstille (del)-resultater
- tage beslutninger og vælge mellem alternative
hændelsesforløb
9
Wednesday, June 19, 13
10. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
Introduktion til processer
Så,
en
proces
har...
• Et mål ( en sluthændelse)
• En (eller flere) starthændelser og mellemliggende
aktiviteter/hændelser, der fører frem til målet
• Aktører (roller) der udfører aktiviteterne
• Data/artefakter der indsamles, udveksles og
bearbejdes
• Beslutninger og valg mellem alternative forløb
10
Wednesday, June 19, 13
11. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
Introduktion til processer
Hvordan
beskrives
den
så?
• Processen skal kunne bruges til forskellige formål og
af forskellige aktører:
• Medarbejder, patient, borger, ...
• IT-systemer
• Jurister og revisore
• Den skal kunne verificeres og holdes ved lige -
ændres når verden ændrer sig..
11
Wednesday, June 19, 13
12. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
Introduktion
Ikke
nogen
ny
idé
....
• Aristoteles (384 f.kr.) - Algoritmik (år 700-800)
• Logik og matematik 1920 -
• Hjerneforskning, automat-teori, datalogi, temporal
logik (igen) 1940 -
• “Office automation” 1970 -
• Computer Supported Cooperative Work 1980-
• Unified Modeling Language (UML) 1990-
• Workflow & Business Process Management 1990 -
12
Wednesday, June 19, 13
13. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
Introduktion til processer
Informa5on
Control
Net
13
zc
:=
Computer Science and
Office Information Systems
By Clarence A. Ellis and Gary J. Nutt
Wednesday, June 19, 13
14. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
Introduktion til processer
Informa5on
Control
Net
13
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
Wednesday, June 19, 13
15. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
Introduktion til processer
Informa5on
Control
Net
13
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
By considering the specification language, the internal representation, and the design of a prototype
system using one unified model, Zisman has been able to study the office as a system rather than
simply as a collection of isolated tasks and pieces of equipment. Although Zisman suggests the
language and the model need refinement, his basic notions will probably have great impact on the
office of the future.
Wednesday, June 19, 13
16. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
Introduktion til processer
Business
Process
Model
and
Nota2on
(BPMN)
14
OMG,
January
2011
Wednesday, June 19, 13
17. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
Introduktion til processer
Process-‐Aware
Informa2on
Systems
offer
workenactment
service
management
tools
design tools
run-time data
process
data
organizational
data
perform
work worker
management
designerhistorical
data
case
dataapplications
Figure 9: The architecture of a PAIS.
simple workflow process. Work is offered through so-called work queues.
worker can have multiple work queues and one work queue can be shared
15
8 Conclusion
Process-aware information systems (PAISs) follow a characteristic lif
ure 13 shows the four phases of such a life-cycle [7]. In the desig
processes are (re)designed. In the configuration phase, designs are i
by configuring a PAIS (e.g., a WFMS). After configuration, the enac
starts where the operational business processes are executed using the
figured. In the diagnosis phase, the operational processes are analyze
problems and to find things that can be improved. The focus of tradi
flow management (systems) is on the lower half of the life-cycle. As
is little support for the diagnosis phase. Moreover, support in the de
limited to providing an editor while analysis and real design support
Figure 13: PAIS life-cycle.
In this article, we showed that PAISs support operational busine
by combining advances in information technology with recent insigh
agement science. We started by reviewing the history of such syste
focused on process design. From the many diagramming techniques a
chose one particular technique (Petri nets) to show the basics. We also
the relevance of process analysis, e.g., by pointing out that 20 percen
than 600 process models in the SAP reference model are flawed [2
26
Wednesday, June 19, 13
18. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
Introduktion til processer
BPMS
&
Service-‐Orienteret
Arkitektur
COBOL
PL1
.NET
SAP
Java
service
Enterprise Service Bus (ESB)
service service
Risk Department Credit Department Customer Department
Task
Sub
Process
Sub
Process
16
offer
workenactment
service
management
tools
design tools
run-time data
process
data
organizational
data
perform
work worker
management
designerhistorical
data
case
dataapplications
Figure 9: The architecture of a PAIS.
simple workflow process. Work is offered through so-called work queues.
worker can have multiple work queues and one work queue can be shared
ng multiple workers. The window in the middle shows the set of available
queues (left) and the content of one of these work queues (right). The bottom
ow shows an audit trail of a case. The three windows show only some of the
bilities offered by contemporary workflow management systems. It is fairly
ghtforward to map these windows onto the architecture. In other processes-
e information systems such as for example enterprise resource planning sys-
, one will find the architecture shown in Figure 9 embedded in a larger archi-Wednesday, June 19, 13
19. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
Introduktion til processer
BPM
og
SOA
17
Steen Brahe, Industrial PhD, Danske Bank & IT University of Copenhagen
“BPM on Top of SOA: Experiences from the Financial Industry”, BPM 2007
Wednesday, June 19, 13
20. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
Introduktion til processer
Ski1ende
standarder...
18
CMMN
1.0 - Beta 1
2013
http://www.omg.org/spec/CMMN/
http://www.omg.org/spec/BPMN/
Wednesday, June 19, 13
21. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
Introduktion til processer
BPMN
processer
19
Wednesday, June 19, 13
22. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
BPMN 2.0 Processer
Proces-‐elementer
i
BPMN
• En eller flere sluthændelser
• En eller flere starthændelser
• Mellemliggende aktiviteter/hændelser
• Aktører (roller)
• Data/artefakter
• Beslutninger og
• Valg mellem alternative forløb
20
10 Process
Note . The content of this chapter is REQUIRED for BPMN Process Modeling Co
Conformance. However, this chapter is NOT REQUIRED for BPMN Process Chor
Process Execution Conformance, or BPMN BPEL Process Execution Conforman
conformance types, see page 2.
A Process describes a sequence or flow of Activities in an organization with th
BPMN a Process is depicted as a graph of Flow Elements, which are a set of A
Sequence Flows that define finite execution semantics (see Figure 10.1). Proce
enterprise-wide Processes to Processes performed by a single person. Low-le
together to achieve a common business goal.
10 Process
Note . The content of this chapter is REQUIRED for BPMN Process Modeling C
Conformance. However, this chapter is NOT REQUIRED for BPMN Process Cho
Process Execution Conformance, or BPMN BPEL Process Execution Conforma
conformance types, see page 2.
A Process describes a sequence or flow of Activities in an organization with t
BPMN a Process is depicted as a graph of Flow Elements, which are a set of A
Sequence Flows that define finite execution semantics (see Figure 10.1). Proc
enterprise-wide Processes to Processes performed by a single person. Low-l
together to achieve a common business goal.
Wednesday, June 19, 13
23. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
BPMN 2.0 Processer
Private
BPMN
processer
21
Business Process Model and Notation, v2.0 23
Private (Internal) Business Processes
Private Business Processes are those internal to a specific organization. These Processes have been generally
called workflow or BPM Processes (see Figure 10.4). Another synonym typically used in the Web services area is the
Orchestration of services. There are two (2) types of private Processes: executable and non-executable. An executable
Process is a Process that has been modeled for the purpose of being executed according to the semantics defined in
Chapter 14. Of course, during the development cycle of the Process, there will be stages where the Process does not
have enough detail to be Pexecutable.Q A non-executable Process is a private Process that has been modeled for the
purpose of documenting Process behavior at a modeler-defined level of detail. Thus, information needed for execution,
such as formal condition Expressions are typically not included in a non-executable Process.
If a swimlanes-like notation is used (e.g., a Collaboration, see below) then a private Business Process will be
contained within a single Pool. The Process flow is therefore contained within the Pool and cannot cross the
boundaries of the Pool. The flow of Messages can cross the Pool boundary to show the interactions that exist between
separate private Business Processes.
Figure 7.1 - Example of a private Business Process
Public Processes
A public Process represents the interactions between a private Business Process and another Process or
Participant (see Figure 7.2). Only those Activities that are used to communicate to the other Participant(s) are included
in the public Process. All other PinternalQ Activities of the private Business Process are not shown in the public
Process. Thus, the public Process shows to the outside world the Message Flows and the order of those Message
Flows that are needed to interact with that Process. Public Processes can be modeled separately or within a
Collaboration to show the flow of Messages between the public Process Activities and other Participants. Note
that the public type of Process was named PabstractQ in BPMN 1.2.
Determine
Premium of
Policy
Determine
Order is
Complete
Check
Record of
Applicant
Approve
or Reject
Policy
Notify
Applicant of
Approval or
Rejection
Bruger, service og besked-aktiviteter
(angiver ikke processer som beskeder sendes til og modtages fra)
Wednesday, June 19, 13
24. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
BPMN 2.0 Processer
Private
BPMN
processer
21
Business Process Model and Notation, v2.0 23
Private (Internal) Business Processes
Private Business Processes are those internal to a specific organization. These Processes have been generally
called workflow or BPM Processes (see Figure 10.4). Another synonym typically used in the Web services area is the
Orchestration of services. There are two (2) types of private Processes: executable and non-executable. An executable
Process is a Process that has been modeled for the purpose of being executed according to the semantics defined in
Chapter 14. Of course, during the development cycle of the Process, there will be stages where the Process does not
have enough detail to be Pexecutable.Q A non-executable Process is a private Process that has been modeled for the
purpose of documenting Process behavior at a modeler-defined level of detail. Thus, information needed for execution,
such as formal condition Expressions are typically not included in a non-executable Process.
If a swimlanes-like notation is used (e.g., a Collaboration, see below) then a private Business Process will be
contained within a single Pool. The Process flow is therefore contained within the Pool and cannot cross the
boundaries of the Pool. The flow of Messages can cross the Pool boundary to show the interactions that exist between
separate private Business Processes.
Figure 7.1 - Example of a private Business Process
Public Processes
A public Process represents the interactions between a private Business Process and another Process or
Participant (see Figure 7.2). Only those Activities that are used to communicate to the other Participant(s) are included
in the public Process. All other PinternalQ Activities of the private Business Process are not shown in the public
Process. Thus, the public Process shows to the outside world the Message Flows and the order of those Message
Flows that are needed to interact with that Process. Public Processes can be modeled separately or within a
Collaboration to show the flow of Messages between the public Process Activities and other Participants. Note
that the public type of Process was named PabstractQ in BPMN 1.2.
Determine
Premium of
Policy
Determine
Order is
Complete
Check
Record of
Applicant
Approve
or Reject
Policy
Notify
Applicant of
Approval or
Rejection
Bruger, service og besked-aktiviteter
start
(angiver ikke processer som beskeder sendes til og modtages fra)
Wednesday, June 19, 13
25. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
BPMN 2.0 Processer
Private
BPMN
processer
21
Business Process Model and Notation, v2.0 23
Private (Internal) Business Processes
Private Business Processes are those internal to a specific organization. These Processes have been generally
called workflow or BPM Processes (see Figure 10.4). Another synonym typically used in the Web services area is the
Orchestration of services. There are two (2) types of private Processes: executable and non-executable. An executable
Process is a Process that has been modeled for the purpose of being executed according to the semantics defined in
Chapter 14. Of course, during the development cycle of the Process, there will be stages where the Process does not
have enough detail to be Pexecutable.Q A non-executable Process is a private Process that has been modeled for the
purpose of documenting Process behavior at a modeler-defined level of detail. Thus, information needed for execution,
such as formal condition Expressions are typically not included in a non-executable Process.
If a swimlanes-like notation is used (e.g., a Collaboration, see below) then a private Business Process will be
contained within a single Pool. The Process flow is therefore contained within the Pool and cannot cross the
boundaries of the Pool. The flow of Messages can cross the Pool boundary to show the interactions that exist between
separate private Business Processes.
Figure 7.1 - Example of a private Business Process
Public Processes
A public Process represents the interactions between a private Business Process and another Process or
Participant (see Figure 7.2). Only those Activities that are used to communicate to the other Participant(s) are included
in the public Process. All other PinternalQ Activities of the private Business Process are not shown in the public
Process. Thus, the public Process shows to the outside world the Message Flows and the order of those Message
Flows that are needed to interact with that Process. Public Processes can be modeled separately or within a
Collaboration to show the flow of Messages between the public Process Activities and other Participants. Note
that the public type of Process was named PabstractQ in BPMN 1.2.
Determine
Premium of
Policy
Determine
Order is
Complete
Check
Record of
Applicant
Approve
or Reject
Policy
Notify
Applicant of
Approval or
Rejection
Bruger, service og besked-aktiviteter
start
slut
(angiver ikke processer som beskeder sendes til og modtages fra)
Wednesday, June 19, 13
26. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
BPMN 2.0 Processer
Hændelser
og
forgreninger
22
10 Process
Note . The content of this chapter is REQUIRED for BPMN Process Modeling Conformance or for BPMN Complete
Conformance. However, this chapter is NOT REQUIRED for BPMN Process Choreography Conformance, BPMN
Process Execution Conformance, or BPMN BPEL Process Execution Conformance. For more information about BPMN
conformance types, see page 2.
A Process describes a sequence or flow of Activities in an organization with the objective of carrying out work. In
BPMN a Process is depicted as a graph of Flow Elements, which are a set of Activities, Events, Gateways, and
Sequence Flows that define finite execution semantics (see Figure 10.1). Processes can be defined at any level from
enterprise-wide Processes to Processes performed by a single person. Low-level Processes can be grouped
together to achieve a common business goal.
Figure 10.1 - An Example of a Process
Note that BPMN uses the term Process specifically to mean a set of flow elements. It uses the terms Collaboration and
Choreography when modeling the interaction between Processes.
The Process package contains classes which are used for modeling the flow of Activities, Events, and Gateways,
and how they are sequenced within a Process (see Figure 10.2). When a Process is defined it is contained within
Definitions.
start slut
hændelser (events)
beslutnings-
(service)aktivitet
forgreninger (gateways)
Sekvens-flow
Wednesday, June 19, 13
27. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
BPMN 2.0 Processer
Data-‐baserede
valg
23
A Process describes a sequence or flow of Activities in an organization with the objective of carrying out work. In
BPMN a Process is depicted as a graph of Flow Elements, which are a set of Activities, Events, Gateways, and
Sequence Flows that define finite execution semantics (see Figure 10.1). Processes can be defined at any level from
enterprise-wide Processes to Processes performed by a single person. Low-level Processes can be grouped
together to achieve a common business goal.
Figure 10.1 - An Example of a Process
Note that BPMN uses the term Process specifically to mean a set of flow elements. It uses the terms Collaboration and
Choreography when modeling the interaction between Processes.
The Process package contains classes which are used for modeling the flow of Activities, Events, and Gateways,
and how they are sequenced within a Process (see Figure 10.2). When a Process is defined it is contained within
Definitions.
Kaldes også et internt
eller ekslusivt valg.
Obs: Skal altid være
mindst een vej at gå.
Wednesday, June 19, 13
28. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
BPMN 2.0 Processer
Data-‐baserede
valg
23
A Process describes a sequence or flow of Activities in an organization with the objective of carrying out work. In
BPMN a Process is depicted as a graph of Flow Elements, which are a set of Activities, Events, Gateways, and
Sequence Flows that define finite execution semantics (see Figure 10.1). Processes can be defined at any level from
enterprise-wide Processes to Processes performed by a single person. Low-level Processes can be grouped
together to achieve a common business goal.
Figure 10.1 - An Example of a Process
Note that BPMN uses the term Process specifically to mean a set of flow elements. It uses the terms Collaboration and
Choreography when modeling the interaction between Processes.
The Process package contains classes which are used for modeling the flow of Activities, Events, and Gateways,
and how they are sequenced within a Process (see Figure 10.2). When a Process is defined it is contained within
Definitions.
Kaldes også et internt
eller ekslusivt valg.
Obs: Skal altid være
mindst een vej at gå.
beslutning
baseret på data
Wednesday, June 19, 13
29. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
BPMN 2.0 Processer
Data-‐baserede
valg
23
A Process describes a sequence or flow of Activities in an organization with the objective of carrying out work. In
BPMN a Process is depicted as a graph of Flow Elements, which are a set of Activities, Events, Gateways, and
Sequence Flows that define finite execution semantics (see Figure 10.1). Processes can be defined at any level from
enterprise-wide Processes to Processes performed by a single person. Low-level Processes can be grouped
together to achieve a common business goal.
Figure 10.1 - An Example of a Process
Note that BPMN uses the term Process specifically to mean a set of flow elements. It uses the terms Collaboration and
Choreography when modeling the interaction between Processes.
The Process package contains classes which are used for modeling the flow of Activities, Events, and Gateways,
and how they are sequenced within a Process (see Figure 10.2). When a Process is defined it is contained within
Definitions.
Kaldes også et internt
eller ekslusivt valg.
Obs: Skal altid være
mindst een vej at gå.
data-based exclusive (XOR) gateway
X
beslutning
baseret på data
Wednesday, June 19, 13
30. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
BPMN 2.0 Processer
fletningforgrening/valg
Data-‐baserede
valg
23
A Process describes a sequence or flow of Activities in an organization with the objective of carrying out work. In
BPMN a Process is depicted as a graph of Flow Elements, which are a set of Activities, Events, Gateways, and
Sequence Flows that define finite execution semantics (see Figure 10.1). Processes can be defined at any level from
enterprise-wide Processes to Processes performed by a single person. Low-level Processes can be grouped
together to achieve a common business goal.
Figure 10.1 - An Example of a Process
Note that BPMN uses the term Process specifically to mean a set of flow elements. It uses the terms Collaboration and
Choreography when modeling the interaction between Processes.
The Process package contains classes which are used for modeling the flow of Activities, Events, and Gateways,
and how they are sequenced within a Process (see Figure 10.2). When a Process is defined it is contained within
Definitions.
Kaldes også et internt
eller ekslusivt valg.
Obs: Skal altid være
mindst een vej at gå.
data-based exclusive (XOR) gateway
X
beslutning
baseret på data
Wednesday, June 19, 13
31. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
BPMN 2.0 Processer
Hændelses-‐baserede
valg
24
N Process Modeling Conformance or for BPMN Complete
or BPMN Process Choreography Conformance, BPMN
s Execution Conformance. For more information about BPMN
an organization with the objective of carrying out work. In
s, which are a set of Activities, Events, Gateways, and
ee Figure 10.1). Processes can be defined at any level from
a single person. Low-level Processes can be grouped
an a set of flow elements. It uses the terms Collaboration and
rocesses.
modeling the flow of Activities, Events, and Gateways,
10.2). When a Process is defined it is contained within
Første hændelse (event) afgør valget af vej.
event-based gateway
Wednesday, June 19, 13
32. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
BPMN 2.0 Processer
Hændelses-‐baserede
valg
24
N Process Modeling Conformance or for BPMN Complete
or BPMN Process Choreography Conformance, BPMN
s Execution Conformance. For more information about BPMN
an organization with the objective of carrying out work. In
s, which are a set of Activities, Events, Gateways, and
ee Figure 10.1). Processes can be defined at any level from
a single person. Low-level Processes can be grouped
an a set of flow elements. It uses the terms Collaboration and
rocesses.
modeling the flow of Activities, Events, and Gateways,
10.2). When a Process is defined it is contained within
Første hændelse (event) afgør valget af vej.
event-based gateway
This Decision represents a branching point
where Alternatives are based on an Event
that occurs at that point in the Process (see
page 305) or Choreography (see page 360).
The specific Event, usually the receipt of a
Message, determines which of the paths will
be taken. Other types of Events can be used,
such as Timer. Only one of the Alternatives
will be chosen.
There are two options for receiving Mes-
sages:
M Tasks of Type Receive can be used
(see figure top-right).
M Intermediate Events of Type Message
can be used (see figure bottom-right).
This Decision represents a branching point
where Alternatives are based on conditional
Expressions contained within the outgo-
ded Modeling Elements
Condition 1
alternativ
notation:
Wednesday, June 19, 13
33. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
BPMN 2.0 Processer
Hændelses-‐baserede
valg
24
N Process Modeling Conformance or for BPMN Complete
or BPMN Process Choreography Conformance, BPMN
s Execution Conformance. For more information about BPMN
an organization with the objective of carrying out work. In
s, which are a set of Activities, Events, Gateways, and
ee Figure 10.1). Processes can be defined at any level from
a single person. Low-level Processes can be grouped
an a set of flow elements. It uses the terms Collaboration and
rocesses.
modeling the flow of Activities, Events, and Gateways,
10.2). When a Process is defined it is contained within
Første hændelse (event) afgør valget af vej.
event-based gateway
This Decision represents a branching point
where Alternatives are based on an Event
that occurs at that point in the Process (see
page 305) or Choreography (see page 360).
The specific Event, usually the receipt of a
Message, determines which of the paths will
be taken. Other types of Events can be used,
such as Timer. Only one of the Alternatives
will be chosen.
There are two options for receiving Mes-
sages:
M Tasks of Type Receive can be used
(see figure top-right).
M Intermediate Events of Type Message
can be used (see figure bottom-right).
This Decision represents a branching point
where Alternatives are based on conditional
Expressions contained within the outgo-
ded Modeling Elements
Condition 1
alternativ
notation:
Brugt som start-
hændelser:
Wednesday, June 19, 13
34. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
BPMN 2.0 Processer
Hændelses-‐baserede
valg
24
N Process Modeling Conformance or for BPMN Complete
or BPMN Process Choreography Conformance, BPMN
s Execution Conformance. For more information about BPMN
an organization with the objective of carrying out work. In
s, which are a set of Activities, Events, Gateways, and
ee Figure 10.1). Processes can be defined at any level from
a single person. Low-level Processes can be grouped
an a set of flow elements. It uses the terms Collaboration and
rocesses.
modeling the flow of Activities, Events, and Gateways,
10.2). When a Process is defined it is contained within
Første hændelse (event) afgør valget af vej.
event-based gateway
10 Process
Note . The content of this chapter is REQUIRED for BPMN Process Modeling Conformance or for BPMN Complete
Conformance. However, this chapter is NOT REQUIRED for BPMN Process Choreography Conformance, BPMN
Process Execution Conformance, or BPMN BPEL Process Execution Conformance. For more information about BPMN
conformance types, see page 2.
A Process describes a sequence or flow of Activities in an organization with the objective of carrying out work. In
BPMN a Process is depicted as a graph of Flow Elements, which are a set of Activities, Events, Gateways, and
Sequence Flows that define finite execution semantics (see Figure 10.1). Processes can be defined at any level from
enterprise-wide Processes to Processes performed by a single person. Low-level Processes can be grouped
together to achieve a common business goal.
Gateway overflødig, hvis vi
kun venter på een hændelse:
This Decision represents a branching point
where Alternatives are based on an Event
that occurs at that point in the Process (see
page 305) or Choreography (see page 360).
The specific Event, usually the receipt of a
Message, determines which of the paths will
be taken. Other types of Events can be used,
such as Timer. Only one of the Alternatives
will be chosen.
There are two options for receiving Mes-
sages:
M Tasks of Type Receive can be used
(see figure top-right).
M Intermediate Events of Type Message
can be used (see figure bottom-right).
This Decision represents a branching point
where Alternatives are based on conditional
Expressions contained within the outgo-
ded Modeling Elements
Condition 1
alternativ
notation:
Brugt som start-
hændelser:
Wednesday, June 19, 13
35. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
BPMN 2.0 Processer
Parallelle
forløb
25
Parallel gateway (eller AND Split)
AND Join
Wednesday, June 19, 13
36. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
BPMN 2.0 Processer
Parallelle
forløb
II
26
inklusivt valg (inclusive choice)
inklusiv fletning/forening
Wednesday, June 19, 13
37. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
BPMN 2.0 Processer
Parallelle
forløb
II
26
inklusivt valg (inclusive choice)
inklusiv fletning/forening
OBS: Kan ikke se “lokalt” hvor mange forløb der ventes på
Wednesday, June 19, 13
38. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
Eksempel:
Bankkonto
27
EXERCISE! UNDERSTAND!BPMN!MODELS!
TRAVEL!BOOKING!
A!given!model!describes!steps!to!open!a!bank!account.!
!
QUESTIONS!
1.Vil “Verify Customer ID”
altid forekomme efter
“Record Customer Info”?
2. Hvilke aktiviteter vil altid
blive udført ?
!published!under!the!terms!of!the!Creative(Commons(License(BY/NC/SA!!
http://creativecommons.org/licenses/by:nc:sa/3.0/!
happens,!another!expert!has!to!be!asked!(who!could!also!not!respond!in!time,!i.e.!the!procedure!re:
peats).!If!an!expert!finally!sends!an!expertise,!it!is!received!by!the!director!and!forwarded!to!the!referee.!
The!referee!files!the!results!containing!the!patient!interviews!as!well!as!the!expertise!and!afterward!
creates!a!report.!While!the!referee!is!doing!this,!the!manager!fills!a!check!to!pay!the!expenses!of!the!ex:
pert.!
Visualize!this!business!process!using!BPMN.!
!
!
!!
!
!
Wednesday, June 19, 13
39. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
Eksempel:
Bankkonto
27
EXERCISE! UNDERSTAND!BPMN!MODELS!
TRAVEL!BOOKING!
A!given!model!describes!steps!to!open!a!bank!account.!
!
QUESTIONS!
1.Vil “Verify Customer ID”
altid forekomme efter
“Record Customer Info”?
2. Hvilke aktiviteter vil altid
blive udført ?
!published!under!the!terms!of!the!Creative(Commons(License(BY/NC/SA!!
http://creativecommons.org/licenses/by:nc:sa/3.0/!
happens,!another!expert!has!to!be!asked!(who!could!also!not!respond!in!time,!i.e.!the!procedure!re:
peats).!If!an!expert!finally!sends!an!expertise,!it!is!received!by!the!director!and!forwarded!to!the!referee.!
The!referee!files!the!results!containing!the!patient!interviews!as!well!as!the!expertise!and!afterward!
creates!a!report.!While!the!referee!is!doing!this,!the!manager!fills!a!check!to!pay!the!expenses!of!the!ex:
pert.!
Visualize!this!business!process!using!BPMN.!
!
!
!!
!
!
Fleksibilitet ved valg på designtidspunkt
Wednesday, June 19, 13
40. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
BPMN 2.0 Processer
• Data-baseret (ekslusivt) valg:
• Hændelses-baseret valg:
• Parallelt forløb (And-split):
• Inklusivt valg:
Opsumering:
Gateways
28
Vi har set følgende gateways (forgreninger):
Event-Based This Decision represents a branching point
where Alternatives are based on an Event
that occurs at that point in the Process (see
page 305) or Choreography (see page 360).
The specific Event, usually the receipt of a
Message, determines which of the paths will
be taken. Other types of Events can be used,
such as Timer. Only one of the Alternatives
will be chosen.
There are two options for receiving Mes-
sages:
M Tasks of Type Receive can be used
(see figure top-right).
M Intermediate Events of Type Message
can be used (see figure bottom-right).
Inclusive This Decision represents a branching point
where Alternatives are based on conditional
Expressions contained within the outgo-
ing Sequence Flows (see page 300).
In some sense it is a grouping of related inde-
pendent Binary (Yes/No) Decisions. Since
each path is independent, all combinations of
the paths MAY be taken, from zero to all.
However, it should be designed so that at
least one path is taken. A Default Condition
could be used to ensure that at least one path
is taken.
Table 7.2 - BPMN Extended Modeling Elements
Condition 1
Condition 2
Wednesday, June 19, 13
41. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
Hyppige
designmønstre
• Proces starter med modtagelse af besked:
• Beslutningsaktivitet umidelbart før data-baseret valg:
• Time-out i hændelsesbaseret valg:
• Betingede hændelser:
29
Wednesday, June 19, 13
42. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
Aktører
via
svømmebaner
30
Wednesday, June 19, 13
43. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
Aktører
og
forgreninger
31
Wednesday, June 19, 13
44. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
Tid
5l
en
pause
!
32
• Registrer jer til 30 dages gratis prøve på
Signavio BPMN designer
https://editor.signavio.com/p/register
Wednesday, June 19, 13
45. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
Signavio
Process
Editor
33
Wednesday, June 19, 13
46. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
BPMN 2.0 Processer
Opgave
i
Signavio
(25
min)
• Lav et (privat) proces-diagram for følgende proces:
• Prøv først at identificére mål, aktører, hændelser,
aktiviteter, valg
• Prøv dernæst quick-model, editor og simulator
34
“Når en faktura modtages skal den scannes, hvis den ikke er elektronisk. Derefter skal den
elektroniske kopi gemmes. Derefter tastes data for fakturaen ind i faktureringssystemet (hvis
ikke data automatisk er overført ved elektronisk fakturering), hvorefter den skal godkendes.
Hvis beløbet er mindre end 1000 Euro skal kun den ansvarlige for udgiften godkende
fakturaen. Hvis beløbet er større end 1000 Euro skal den nærmeste leder også godkende.
Hvis beløbet er større end 20000 Euro, skal direktøren også godkende. Når alle der skal
godkende har godkendt registreres betalingen i faktureringssystemet.”
Wednesday, June 19, 13
47. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
Tid
5l
frokost!
35
Wednesday, June 19, 13
48. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
Program
for
e1ermiddag
• 13-14:Andre typer modeller:
• Offentlige, kollaborative processer: Pools
• Koreografier: Globale Interaktioner vs lokale aktioner
• Deklarative modeller: Beslutninger og Proceskrav
• 14-14.30: Pause
• 14.30-15.30: Beskriv din egen process
• 15.30-16: Opsamling og evaluering
36
Wednesday, June 19, 13
49. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
Andre typer modeller
Pools:
Offentlige
processer
37
Wednesday, June 19, 13
50. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
Andre typer modeller
Eksempel:
Rejsebes5lling
38
TRAVEL!BOOKING!
A!given!model!describes!necessary!steps!for!travel!booking!where!a!traveler!interacts!with!a!trave
!
!
!published!under!the!terms!of!the!Creative(Commons(License(BY/NC/SA!!
http://creativecommons.org/licenses/by:nc:sa/3.0/!
happens,!another!expert!has!to!be!asked!(who!could!also!not!respond!in!time,!i.e.!the!procedure!re:
peats).!If!an!expert!finally!sends!an!expertise,!it!is!received!by!the!director!and!forwarded!to!the!referee.!
The!referee!files!the!results!containing!the!patient!interviews!as!well!as!the!expertise!and!afterward!
creates!a!report.!While!the!referee!is!doing!this,!the!manager!fills!a!check!to!pay!the!expenses!of!the!ex:
pert.!
Visualize!this!business!process!using!BPMN.!
!
!
!!
!
!
Wednesday, June 19, 13
51. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
Andre typer modeller
Eksempel:
Rejsebes5lling
38
TRAVEL!BOOKING!
A!given!model!describes!necessary!steps!for!travel!booking!where!a!traveler!interacts!with!a!trave
!
!
!published!under!the!terms!of!the!Creative(Commons(License(BY/NC/SA!!
http://creativecommons.org/licenses/by:nc:sa/3.0/!
happens,!another!expert!has!to!be!asked!(who!could!also!not!respond!in!time,!i.e.!the!procedure!re:
peats).!If!an!expert!finally!sends!an!expertise,!it!is!received!by!the!director!and!forwarded!to!the!referee.!
The!referee!files!the!results!containing!the!patient!interviews!as!well!as!the!expertise!and!afterward!
creates!a!report.!While!the!referee!is!doing!this,!the!manager!fills!a!check!to!pay!the!expenses!of!the!ex:
pert.!
Visualize!this!business!process!using!BPMN.!
!
!
!!
!
!
Request-reply
pattern
Wednesday, June 19, 13
53. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
Andre typer modeller
Example:
Salgsproces
39
SALES!PROCESS!
A!given!model!describes!quote!creation!(sales!representative)!and!approval!(sales!executive)!as
automated!order!processing!for!a!customer.!!
!
!
QUESTIONS!
!published!under!the!terms!of!the!Creative(Commons(License(BY/NC/SA!!
http://creativecommons.org/licenses/by:nc:sa/3.0/!
happens,!another!expert!has!to!be!asked!(who!could!also!not!respond!in!time,!i.e.!the!procedure!re:
peats).!If!an!expert!finally!sends!an!expertise,!it!is!received!by!the!director!and!forwarded!to!the!referee.!
The!referee!files!the!results!containing!the!patient!interviews!as!well!as!the!expertise!and!afterward!
creates!a!report.!While!the!referee!is!doing!this,!the!manager!fills!a!check!to!pay!the!expenses!of!the!ex:
pert.!
Visualize!this!business!process!using!BPMN.!
!
!
!!
!
!
Wednesday, June 19, 13
54. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
Andre typer modeller
Koreografier
40
Business Process Model and Notation, v2.0 25
Figure 7.3 - An example of a Collaborative Process
Choreographies
A self-contained Choreography (no Pools or Orchestration) is a definition of the expected behavior, basically a
procedural contract, between interacting Participants. While a normal Process exists within a Pool, a Choreography
exists between Pools (or Participants).
The Choreography looks similar to a private Business Process since it consists of a network of Activities,
Events, and Gateways (see Figure 7.4). However, a Choreography is different in that the Activities are interactions
that represent a set (1 or more) of Message exchanges, which involves two (2) or more Participants. In addition, unlike
a normal Process, there is no central controller, responsible entity or observer of the Process.
Figure 7.4 - An example of a Choreography
Doctor
Request
Patient
Dr. Office
Handle
Symptoms
Patient
Dr. Office
Handle
Prescription
Patient
Dr. Office
Handle
Medicine
Patient
Dr. Office
I want to see
the Doctor
Go see the
Doctor
I feel sick
I need my
medicine
Here is your
medicine
Pickup your
medicine, then
leave
Hver aktivitet er en interaktion mellem to eller flere aktøre
Wednesday, June 19, 13
55. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
Andre typer modeller
Proces
vs
Koreografi
41
Figure 7.3 - An example of a Collaborative Process
Choreographies
A self-contained Choreography (no Pools or Orchestration) is a definition of the expected behavior, basically a
procedural contract, between interacting Participants. While a normal Process exists within a Pool, a Choreography
exists between Pools (or Participants).
The Choreography looks similar to a private Business Process since it consists of a network of Activities,
Events, and Gateways (see Figure 7.4). However, a Choreography is different in that the Activities are interactions
that represent a set (1 or more) of Message exchanges, which involves two (2) or more Participants. In addition, unlike
a normal Process, there is no central controller, responsible entity or observer of the Process.
Send Doctor
Request
I want to
see doctor
Illness
Occurs
Send Appt.
Receive
Appt.
Go see doctor
Send
Symptoms
Receive
Symptoms
I feel sick
Receive
Prescription
Pickup
Pickup your medicine
and you can leave
Send
Medicine
Request
Receive
Medicine
Request
I need my medicine
Receive
Medicine
Here is your medicine
Receive
Doctor
Request
Send
Medicine
Send
Prescription
Pickup
Patient
Receptionist/
Doctor
Doctor
Request
Patient
Dr. Office
Handle
Symptoms
Patient
Dr. Office
Handle
Prescription
Patient
Dr. Office
Handle
Medicine
Patient
Dr. Office
I want to see
the Doctor
Go see the
I feel sick
I need my
medicine
Here is your
Pickup your
medicine, then
a Choreography does not exist in a single Pool—it is not the purview of a single Participant. Each step in the
Choreography involves two or more Participants (these steps are called Choreography Activities—see below).
This means that the Choreography, in BPMN terms, is defined outside of any particular Pool.
The key question that needs to be continually asked during the development of a Choreography is “what information
do the Participants in the Choreography have?” Basically, each Participant can only understand the status of the
Choreography through observable behavior of the other Participants–which are the Messages that have been sent and
received. If there are only two Participants in the Choreography, then it is very simple—both Participants will be
aware of who is responsible for sending the next Message. However, if there are more than two Participants, then the
modeler needs to be careful to sequence the Choreography Activities in such a way that the Participants know when
they are responsible for initiating the interactions.
Figure 11.2 presents a sample Choreography. The details of Choreography behavior and elements will be described
in the sections below.
Figure 11.2 - An example of a Choreography
To illustrate the correspondence between Collaboration and Choreography, consider an example from logistics.
Figure 11.3 shows a Collaboration where the Pools are expanded to reveal orchestration details per participant (for
Doctor
Request
Patient
Dr. Office
Handle
Symptoms
Patient
Dr. Office
Handle
Prescription
Patient
Dr. Office
Handle
Medicine
Patient
Dr. Office
I want to see
the Doctor
Go see the
Doctor
I feel sick
I need my
medicine
Here is your
medicine
Pickup your
medicine, then
leave
Message
The unshaded Participant is
the initiator of the Activity
The bands display the names of the
Participants (Roles/Entities)
Additional Participants can be added on
additional bands (for Sub-Processes)
The Message is shaded, so it
is not the initiating Message
Message
Exchange
Pattern
Wednesday, June 19, 13
56. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
BPMNs
begræsninger
42
Wednesday, June 19, 13
57. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
BPMNs
begræsninger
42
“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 Universit
nology, P.O. Box 513, NL-5600 MB Eindhoven, w.m.p.v.d.aalst@tue.nl
Abstract. Process-aware information systems support operational busi
cesses by combining advances in information technology with recent
from management science. Workflow management systems are typical
of such systems. However, many other types of information systems
“process aware” even if their processes are hard-coded or only used i
(e.g., ERP systems). The shift from data orientation to process orientatio
creased the importance process-aware information systems. Moreover,
analysis techniques ranging from simulation and verification to proces
and activity monitoring allow for systems that support process improv
various ways. This article provides an overview of process-aware inf
systems and also relates these to business process management, workfl
agement, process analysis techniques, and process flexibility.
Keywords: Process-Aware Information Systems, Workflow Manageme
ness Process Management, Petri Nets, Process Mining, Process Verificat
ulation
1 Introduction
Information technology has changed business processes within and betwe
prises. More and more work processes are being conducted under the su
of information systems that are driven by process models. Examples a
flow management systems such as FileNet P8, Staffware, WebSphere,
and YAWL and Enterprise Resource Planning (ERP) systems such as
Oracle. Moreover, many domain specific systems have components d
(process) models. It is hard to imagine enterprise information system
unaware of the processes taking place. Although the topic of busines
management using information technology has been addressed by co
1
Wednesday, June 19, 13
58. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
BPMNs
begræsninger
42
“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 Universit
nology, P.O. Box 513, NL-5600 MB Eindhoven, w.m.p.v.d.aalst@tue.nl
Abstract. Process-aware information systems support operational busi
cesses by combining advances in information technology with recent
from management science. Workflow management systems are typical
of such systems. However, many other types of information systems
“process aware” even if their processes are hard-coded or only used i
(e.g., ERP systems). The shift from data orientation to process orientatio
creased the importance process-aware information systems. Moreover,
analysis techniques ranging from simulation and verification to proces
and activity monitoring allow for systems that support process improv
various ways. This article provides an overview of process-aware inf
systems and also relates these to business process management, workfl
agement, process analysis techniques, and process flexibility.
Keywords: Process-Aware Information Systems, Workflow Manageme
ness Process Management, Petri Nets, Process Mining, Process Verificat
ulation
1 Introduction
Information technology has changed business processes within and betwe
prises. More and more work processes are being conducted under the su
of information systems that are driven by process models. Examples a
flow management systems such as FileNet P8, Staffware, WebSphere,
and YAWL and Enterprise Resource Planning (ERP) systems such as
Oracle. Moreover, many domain specific systems have components d
(process) models. It is hard to imagine enterprise information system
unaware of the processes taking place. Although the topic of busines
management using information technology has been addressed by co
1
by Skip Ellis it is important to learn from these ups and downs. The failures in
the eighties can be explained by both technical and conceptual problems. In the
eighties networks were slow or not present at all, there were no suitable graphical
interfaces, and proper development software was missing. However, there were
also more fundamental problems: a unified way of modeling processes was miss-
ing and the systems were too rigid to be used by people in the workplace. Most of
the technical problems have been resolved by now. However, the more conceptual
problems remain. Good standards for business process modeling are still missing
and even today’s WFMSs are too rigid.
One of the great challenges of PAISs is to offer both support and flexibility.
Today’s systems typically are too rigid, thus forcing people to work around the
system. One of the problems is that software developers and computer scientists
are typically inspired by processes inside a computer system rather than processes
outside a computer. As a result, these engineers think in terms of control systems
rather than support systems. This explains that few of the existing WFMSs allow
for the so-called implicit choice, i.e., a choice resolved by the environment rather
than the system.
To summarize we would like to state that, although the relevance of PAISs is
undisputed, many fundamental problems remain to be solved. In the remainder of
this article, we will try to shed light on some of these problems.
Wednesday, June 19, 13
59. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
BPMNs
begræsninger
42
“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 Universit
nology, P.O. Box 513, NL-5600 MB Eindhoven, w.m.p.v.d.aalst@tue.nl
Abstract. Process-aware information systems support operational busi
cesses by combining advances in information technology with recent
from management science. Workflow management systems are typical
of such systems. However, many other types of information systems
“process aware” even if their processes are hard-coded or only used i
(e.g., ERP systems). The shift from data orientation to process orientatio
creased the importance process-aware information systems. Moreover,
analysis techniques ranging from simulation and verification to proces
and activity monitoring allow for systems that support process improv
various ways. This article provides an overview of process-aware inf
systems and also relates these to business process management, workfl
agement, process analysis techniques, and process flexibility.
Keywords: Process-Aware Information Systems, Workflow Manageme
ness Process Management, Petri Nets, Process Mining, Process Verificat
ulation
1 Introduction
Information technology has changed business processes within and betwe
prises. More and more work processes are being conducted under the su
of information systems that are driven by process models. Examples a
flow management systems such as FileNet P8, Staffware, WebSphere,
and YAWL and Enterprise Resource Planning (ERP) systems such as
Oracle. Moreover, many domain specific systems have components d
(process) models. It is hard to imagine enterprise information system
unaware of the processes taking place. Although the topic of busines
management using information technology has been addressed by co
1
by Skip Ellis it is important to learn from these ups and downs. The failures in
the eighties can be explained by both technical and conceptual problems. In the
eighties networks were slow or not present at all, there were no suitable graphical
interfaces, and proper development software was missing. However, there were
also more fundamental problems: a unified way of modeling processes was miss-
ing and the systems were too rigid to be used by people in the workplace. Most of
the technical problems have been resolved by now. However, the more conceptual
problems remain. Good standards for business process modeling are still missing
and even today’s WFMSs are too rigid.
One of the great challenges of PAISs is to offer both support and flexibility.
Today’s systems typically are too rigid, thus forcing people to work around the
system. One of the problems is that software developers and computer scientists
are typically inspired by processes inside a computer system rather than processes
outside a computer. As a result, these engineers think in terms of control systems
rather than support systems. This explains that few of the existing WFMSs allow
for the so-called implicit choice, i.e., a choice resolved by the environment rather
than the system.
To summarize we would like to state that, although the relevance of PAISs is
undisputed, many fundamental problems remain to be solved. In the remainder of
this article, we will try to shed light on some of these problems.
• BPMN processer beskriver procedurer
• Men hvad hvis vi bliver nød til at bryde proceduren ?
• Hvordan får vi beskrevet kravene til proceduren ?
Wednesday, June 19, 13
60. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
Fores5l
dig
en
BPMN-‐GPS....
43
Du kan se ruten - men den er givetvis baseret på et
gammelt kort og regler, som du iøvrigt ikke kan se.
Wednesday, June 19, 13
61. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
Hvad
vi
ønsker...
44
Du kan se ruten og kort - og hvis du afviger, eller
regler eller kort ændrer sig undervejs så kan kort,
regler og rute nemt opdateres
Wednesday, June 19, 13
62. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
Beslutningsmodellering
• Adskil beslutninger og proces
• Nemmere at opdatere og genbruge
• Indfører ikke unødvendige rækkefølger i
beslutningslogikken
45
Wednesday, June 19, 13
63. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
Option 1
Option 2
Option 3
Rule
Conditions Conclusion
Person Employment Person Credit
Eksempel
46
Option 1
Option 2
Wednesday, June 19, 13
66. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
Deklara5ve
processer
• Kravene til processerne kan også angives deklarativt
• Istedet for en procedure, beskrive krav til rækkefølge
mellem hændelser/aktiviteter
• To grundlæggende krav: Betingelser og opfølgninger
(på engelsk: Conditions and responses)
• Hændelser/aktiviteter kan udelukke og inddrage
andre hændelser/aktiviteter i processen
• Notation: Dynamic Condition Response Graphs
49
Wednesday, June 19, 13
67. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
Beløb registreres
godkend
Fakturaeksempel
igen
50
“Når en faktura modtages skal data for fakturaen tastes ind i faktureringssystemet (hvis
ikke data automatisk er overført ved elektronisk fakturering), hvorefter den skal godkendes.
Hvis beløbet er mindre end 1000 Euro skal kun den ansvarlige for udgiften godkende
fakturaen. Hvis beløbet er større end 1000 Euro skal den nærmeste leder også godkende.
Hvis beløbet er større end 20000 Euro, skal direktøren også godkende. Når alle der skal
godkende har godkendt registreres betalingen i faktureringssystemet.”
Betaling registreres
Godkendt af direktør
Godkendt af
nærmeste leder
Godkendt af
medarbejder
faktura modtaget
Beløb ikke
over 1000
Beløb ikke
over 20000
Beløb over
1000
Beløb over
20000
Wednesday, June 19, 13
68. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
Beløb registreres
godkend
Fakturaeksempel
igen
50
“Når en faktura modtages skal data for fakturaen tastes ind i faktureringssystemet (hvis
ikke data automatisk er overført ved elektronisk fakturering), hvorefter den skal godkendes.
Hvis beløbet er mindre end 1000 Euro skal kun den ansvarlige for udgiften godkende
fakturaen. Hvis beløbet er større end 1000 Euro skal den nærmeste leder også godkende.
Hvis beløbet er større end 20000 Euro, skal direktøren også godkende. Når alle der skal
godkende har godkendt registreres betalingen i faktureringssystemet.”
Betaling registreres
Godkendt af direktør
Godkendt af
nærmeste leder
Godkendt af
medarbejder
faktura modtaget
Beløb ikke
over 1000
Beløb ikke
over 20000
Beløb over
1000
Beløb over
20000
Wednesday, June 19, 13
69. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
Beløb registreres
godkend
Fakturaeksempel
igen
50
“Når en faktura modtages skal data for fakturaen tastes ind i faktureringssystemet (hvis
ikke data automatisk er overført ved elektronisk fakturering), hvorefter den skal godkendes.
Hvis beløbet er mindre end 1000 Euro skal kun den ansvarlige for udgiften godkende
fakturaen. Hvis beløbet er større end 1000 Euro skal den nærmeste leder også godkende.
Hvis beløbet er større end 20000 Euro, skal direktøren også godkende. Når alle der skal
godkende har godkendt registreres betalingen i faktureringssystemet.”
Betaling registreres
Godkendt af direktør
Godkendt af
nærmeste leder
Godkendt af
medarbejder
faktura modtaget
Beløb ikke
over 1000
Beløb ikke
over 20000
Beløb over
1000
Beløb over
20000
Wednesday, June 19, 13
70. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
Beløb registreres
godkend
Fakturaeksempel
igen
50
“Når en faktura modtages skal data for fakturaen tastes ind i faktureringssystemet (hvis
ikke data automatisk er overført ved elektronisk fakturering), hvorefter den skal godkendes.
Hvis beløbet er mindre end 1000 Euro skal kun den ansvarlige for udgiften godkende
fakturaen. Hvis beløbet er større end 1000 Euro skal den nærmeste leder også godkende.
Hvis beløbet er større end 20000 Euro, skal direktøren også godkende. Når alle der skal
godkende har godkendt registreres betalingen i faktureringssystemet.”
Betaling registreres
Godkendt af direktør
Godkendt af
nærmeste leder
Godkendt af
medarbejder
faktura modtaget
Beløb ikke
over 1000
Beløb ikke
over 20000
Beløb over
1000
Beløb over
20000
condition and response
Wednesday, June 19, 13
71. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
condition
Beløb registreres
godkend
Fakturaeksempel
igen
50
“Når en faktura modtages skal data for fakturaen tastes ind i faktureringssystemet (hvis
ikke data automatisk er overført ved elektronisk fakturering), hvorefter den skal godkendes.
Hvis beløbet er mindre end 1000 Euro skal kun den ansvarlige for udgiften godkende
fakturaen. Hvis beløbet er større end 1000 Euro skal den nærmeste leder også godkende.
Hvis beløbet er større end 20000 Euro, skal direktøren også godkende. Når alle der skal
godkende har godkendt registreres betalingen i faktureringssystemet.”
Betaling registreres
Godkendt af direktør
Godkendt af
nærmeste leder
Godkendt af
medarbejder
faktura modtaget
Beløb ikke
over 1000
Beløb ikke
over 20000
Beløb over
1000
Beløb over
20000
condition and response
Wednesday, June 19, 13
72. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
condition
Beløb registreres
godkend
Fakturaeksempel
igen
50
“Når en faktura modtages skal data for fakturaen tastes ind i faktureringssystemet (hvis
ikke data automatisk er overført ved elektronisk fakturering), hvorefter den skal godkendes.
Hvis beløbet er mindre end 1000 Euro skal kun den ansvarlige for udgiften godkende
fakturaen. Hvis beløbet er større end 1000 Euro skal den nærmeste leder også godkende.
Hvis beløbet er større end 20000 Euro, skal direktøren også godkende. Når alle der skal
godkende har godkendt registreres betalingen i faktureringssystemet.”
Betaling registreres
Godkendt af direktør
Godkendt af
nærmeste leder
Godkendt af
medarbejder
faktura modtaget
Beløb ikke
over 1000
Beløb ikke
over 20000
Beløb over
1000
Beløb over
20000
condition and response
Wednesday, June 19, 13
73. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
condition
Beløb registreres
godkend
Fakturaeksempel
igen
50
“Når en faktura modtages skal data for fakturaen tastes ind i faktureringssystemet (hvis
ikke data automatisk er overført ved elektronisk fakturering), hvorefter den skal godkendes.
Hvis beløbet er mindre end 1000 Euro skal kun den ansvarlige for udgiften godkende
fakturaen. Hvis beløbet er større end 1000 Euro skal den nærmeste leder også godkende.
Hvis beløbet er større end 20000 Euro, skal direktøren også godkende. Når alle der skal
godkende har godkendt registreres betalingen i faktureringssystemet.”
Betaling registreres
Godkendt af direktør
Godkendt af
nærmeste leder
Godkendt af
medarbejder
faktura modtaget
Beløb ikke
over 1000
Beløb ikke
over 20000
Beløb over
1000
Beløb over
20000
condition and response
exclude
exclude
include
include
Wednesday, June 19, 13
74. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
Design
and
Simula5on
51
Wednesday, June 19, 13
75. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
Tid
5l
en
pause
!
52
• Prøv evt. at hente DCR-Graf editoren
• http://www.itu.dk/research/models/wiki/
index.php/DCR_Graphs_Editor
Wednesday, June 19, 13
76. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
Opgave:
Egen
proces
• “Find” din egen proces i din beskrivelse:
• Hændelser/aktiviteter, aktører,
• Lav model af krav som DCR Graf:
Conditions, responses, exclusions, inclusions
• Beskriv en procedure som BPMN proces
• Sammenlign BPMN proces med DCR Graf
53
Wednesday, June 19, 13
77. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
Konklusioner
• BPMN kan bruges til at beskrive procedurer - med
henblik på bla. dokumentation, krav, analyse,
digitalisering, automatisering,...
• Digitaliseres/automatiseres en procedure bliver
processen hurtigt for rigid
• Deklarativ beslutningsmodellering og
procesmodellering kan bruges til at beskrive krav så
beslutninger og processer forbliver fleksible mht
udførsel og ændringer
54
Wednesday, June 19, 13
78. Design af (digitale) processer, 19. juni 2013
VidenDanmark
AkademiThomas.Hildebrandt@gmail.com
Opsamling
og
evaluering
55
Wednesday, June 19, 13