thomas hildebrandt process design 19062013
DESCRIPTION
Thomas Hildebrandt underviser i design af digitale processer ved temadag i VidenDanmark den 19. juni 2013.TRANSCRIPT
Design af (digitale) processerThomas HildebrandtFacilitator for videngruppen Digitalisering og procesorienteringLektor ved IT Universitetet i København
VidenDanmark AkademiTemadag 19. juni 2013
Wednesday, June 19, 13
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
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
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
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
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
Introduktion
Præsenta5on af deltagere
• Navn, beskæftigelse, uddannelse, ...
• Erfaring med procesdesign
• Hvorfor deltager du ?
4
Wednesday, June 19, 13
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
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
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
Introduktion
Mål med temadagenDeltagerne 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
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
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
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
Introduktion til processer
Ak5viteter og hændelserog 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
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
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
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
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
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
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
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
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
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
Introduktion til processer
Informa5on Control Net
13
z c :=
Computer Science and Office Information Systems
By Clarence A. Ellis and Gary J. Nutt
Wednesday, June 19, 13
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
Introduktion til processer
Informa5on Control Net
13
z c :=
Computer Science and Office Information Systems
By Clarence A. Ellis and Gary J. Nutt
ORDE
R PR
OCES
SING
Log
Requ
est
Type
Ord
er
Send
Ord
er
Rece
ive
Ord
er
Broces
s I I J I I • :1.
\ 1
Custo
mer
Re
ques
t A
rriv
al lL
-""
/ I I r • r J /. I I A / I
" Ord
er
Form
'" I +0
I
, Cu
s tam
er
J j
Fi le
I
II
Bill
ing
File
I I I J I J I I I I I I
I /
I ,
lOut
"
1\:;;1
tJ .
lOu
t \.
I t
Form
'-
---
----
/--"
"
',---
- ... _
----
--_
.. _-.
.,.-
'
F.ig
ure
2
Wednesday, June 19, 13
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
Introduktion til processer
Informa5on Control Net
13
z c :=
Computer Science and Office Information Systems
By Clarence A. Ellis and Gary J. Nutt
ORDE
R PR
OCES
SING
Log
Requ
est
Type
Ord
er
Send
Ord
er
Rece
ive
Ord
er
Broces
s I I J I I • :1.
\ 1
Custo
mer
Re
ques
t A
rriv
al lL
-""
/ I I r • r J /. I I A / I
" Ord
er
Form
'" I +0
I
, Cu
s tam
er
J j
Fi le
I
II
Bill
ing
File
I I I J I J I I I I I I
I /
I ,
lOut
"
1\:;;1
tJ .
lOu
t \.
I t
Form
'-
---
----
/--"
"
',---
- ... _
----
--_
.. _-.
.,.-
'
F.ig
ure
2 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
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
Introduktion til processer
Business Process Model and Nota2on (BPMN)
Business Process Model and Notation, v2.0 47
Figure 7.8 - An example of a stand-alone Process (Orchestration) diagram
14
OMG, January 2011
Wednesday, June 19, 13
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
Introduktion til processer
Process-‐Aware Informa2on Systems
offerworkenactment
service
man
agem
ent
tool
sdesign tools
run-time data
processdata
organizationaldata
performwork worker
management
designerhistoricaldata
casedataapplications
Figure 9: The architecture of a PAIS.
ing a simple workflow process. Work is offered through so-called work queues.One worker can have multiple work queues and one work queue can be sharedamong multiple workers. The window in the middle shows the set of availablework queues (left) and the content of one of these work queues (right). The bottomwindow shows an audit trail of a case. The three windows show only some of thecapabilities offered by contemporary workflow management systems. It is fairlystraightforward to map these windows onto the architecture. In other processes-aware information systems such as for example enterprise resource planning sys-tems, one will find the architecture shown in Figure 9 embedded in a larger archi-tecture.
The architecture shown in Figure 9 assumes a centralized enactment service.Inside a single organization such an assumption may be realistic. However, in across-organizational setting this is not the case. Fortunately, most vendors nowsupport the SOA mentioned earlier. In a SOA tasks are subcontracted to otherparties, i.e., what is one task for the service consumer may be a complex processfor a service consumer. The web-services stack using standards such as WSDLand BPEL facilitates the development of cross-organizational workflows.
Despite the acceptance of PAISs, the current generation of products leavesmuch to be desired. To illustrate this, we focus on the current generation ofWFMSs. We will use Figure 9 to identify five problems.
18
15
However, the focus is not on data but on process-related information (e.g., theordering of activities). Process mining is also related to monitoring and businessintelligence [41].
8 ConclusionProcess-aware information systems (PAISs) follow a characteristic life-cycle. Fig-ure 13 shows the four phases of such a life-cycle [7]. In the design phase, theprocesses are (re)designed. In the configuration phase, designs are implementedby configuring a PAIS (e.g., a WFMS). After configuration, the enactment phasestarts where the operational business processes are executed using the system con-figured. In the diagnosis phase, the operational processes are analyzed to identifyproblems and to find things that can be improved. The focus of traditional work-flow management (systems) is on the lower half of the life-cycle. As a result thereis little support for the diagnosis phase. Moreover, support in the design phase islimited to providing an editor while analysis and real design support are missing.
Figure 13: PAIS life-cycle.
In this article, we showed that PAISs support operational business processesby combining advances in information technology with recent insights from man-agement science. We started by reviewing the history of such systems and thenfocused on process design. From the many diagramming techniques available, wechose one particular technique (Petri nets) to show the basics. We also emphasizedthe relevance of process analysis, e.g., by pointing out that 20 percent of the morethan 600 process models in the SAP reference model are flawed [24]. We also
26Wednesday, June 19, 13
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
Introduktion til processer
BPMS & Service-‐Orienteret Arkitektur
COBOL PL1
.NETSAPJava
service
Enterprise Service Bus (ESB)
service service
Risk Department Credit Department Customer Department
Task
Sub Process
Sub Process
16
offerworkenactment
service
man
agem
ent
tool
s
design tools
run-time data
processdata
organizationaldata
performwork worker
management
designerhistoricaldata
casedataapplications
Figure 9: The architecture of a PAIS.
ing a simple workflow process. Work is offered through so-called work queues.One worker can have multiple work queues and one work queue can be sharedamong multiple workers. The window in the middle shows the set of availablework queues (left) and the content of one of these work queues (right). The bottomwindow shows an audit trail of a case. The three windows show only some of thecapabilities offered by contemporary workflow management systems. It is fairlystraightforward to map these windows onto the architecture. In other processes-aware information systems such as for example enterprise resource planning sys-tems, one will find the architecture shown in Figure 9 embedded in a larger archi-tecture.
The architecture shown in Figure 9 assumes a centralized enactment service.Inside a single organization such an assumption may be realistic. However, in across-organizational setting this is not the case. Fortunately, most vendors nowsupport the SOA mentioned earlier. In a SOA tasks are subcontracted to otherparties, i.e., what is one task for the service consumer may be a complex processfor a service consumer. The web-services stack using standards such as WSDLand BPEL facilitates the development of cross-organizational workflows.
Despite the acceptance of PAISs, the current generation of products leavesmuch to be desired. To illustrate this, we focus on the current generation ofWFMSs. We will use Figure 9 to identify five problems.
18
Wednesday, June 19, 13
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
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
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
Introduktion til processer
Ski1ende standarder...
18
CMMN1.0 - Beta 1
2013
http://www.omg.org/spec/CMMN/http://www.omg.org/spec/BPMN/
Wednesday, June 19, 13
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
Introduktion til processer
BPMN processer
19
Wednesday, June 19, 13
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
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
Business Process Model and Notation, v2.0 149
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.
Business Process Model and Notation, v2.0 149
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.
Wednesday, June 19, 13
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
BPMN 2.0 Processer
Private BPMN processer
21
Business Process Model and Notation, v2.0 23
7.1.1 Uses of BPMN
Business Process modeling is used to communicate a wide variety of information to a wide variety of audiences. BPMN is designed to cover many types of modeling and allows the creation of end-to-end Business Processes. The structural elements of BPMN allow the viewer to be able to easily differentiate between sections of a BPMN Diagram. There are three basic types of sub-models within an end-to-end BPMN model:
< Processes (Orchestration), including:
< Private non-executable (internal) Business Processes< Private executable (internal) Business Processes< Public Processes
< Choreographies
< Collaborations, which can include Processes and/or Choreographies< A view of Conversations
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
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
BPMN 2.0 Processer
Private BPMN processer
21
Business Process Model and Notation, v2.0 23
7.1.1 Uses of BPMN
Business Process modeling is used to communicate a wide variety of information to a wide variety of audiences. BPMN is designed to cover many types of modeling and allows the creation of end-to-end Business Processes. The structural elements of BPMN allow the viewer to be able to easily differentiate between sections of a BPMN Diagram. There are three basic types of sub-models within an end-to-end BPMN model:
< Processes (Orchestration), including:
< Private non-executable (internal) Business Processes< Private executable (internal) Business Processes< Public Processes
< Choreographies
< Collaborations, which can include Processes and/or Choreographies< A view of Conversations
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
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
BPMN 2.0 Processer
Private BPMN processer
21
Business Process Model and Notation, v2.0 23
7.1.1 Uses of BPMN
Business Process modeling is used to communicate a wide variety of information to a wide variety of audiences. BPMN is designed to cover many types of modeling and allows the creation of end-to-end Business Processes. The structural elements of BPMN allow the viewer to be able to easily differentiate between sections of a BPMN Diagram. There are three basic types of sub-models within an end-to-end BPMN model:
< Processes (Orchestration), including:
< Private non-executable (internal) Business Processes< Private executable (internal) Business Processes< Public Processes
< Choreographies
< Collaborations, which can include Processes and/or Choreographies< A view of Conversations
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
startslut
(angiver ikke processer som beskeder sendes til og modtages fra)
Wednesday, June 19, 13
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
BPMN 2.0 Processer
Hændelser og forgreninger
22
Business Process Model and Notation, v2.0 149
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
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
BPMN 2.0 Processer
Data-‐baserede valg
23
Business Process Model and Notation, v2.0 149
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.
Kaldes også et internt eller ekslusivt valg.
Obs: Skal altid være mindst een vej at gå.
Wednesday, June 19, 13
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
BPMN 2.0 Processer
Data-‐baserede valg
23
Business Process Model and Notation, v2.0 149
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.
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
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
BPMN 2.0 Processer
Data-‐baserede valg
23
Business Process Model and Notation, v2.0 149
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.
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
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
BPMN 2.0 Processer
fletningforgrening/valg
Data-‐baserede valg
23
Business Process Model and Notation, v2.0 149
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.
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
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
BPMN 2.0 Processer
Hændelses-‐baserede valg
24
Business Process Model and Notation, v2.0 149
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.
Første hændelse (event) afgør valget af vej.
event-based gateway
Wednesday, June 19, 13
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
BPMN 2.0 Processer
Hændelses-‐baserede valg
24
Business Process Model and Notation, v2.0 149
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.
Første hændelse (event) afgør valget af vej.
event-based gateway
Business Process Model and Notation, v2.0 37
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.
There are two versions of this type of Deci-sion:
M The first uses a collection of conditional Sequence Flows, marked with mini-diamonds (see top-right figure).
M The second uses an Inclusive Gateway (see bottom-right picture).
Table 7.2 - BPMN Extended Modeling Elements
Condition 1
Condition 2
Condition 2
Condition 1
alternativ notation:
Wednesday, June 19, 13
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
BPMN 2.0 Processer
Hændelses-‐baserede valg
24
Business Process Model and Notation, v2.0 149
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.
Første hændelse (event) afgør valget af vej.
event-based gateway
Business Process Model and Notation, v2.0 37
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.
There are two versions of this type of Deci-sion:
M The first uses a collection of conditional Sequence Flows, marked with mini-diamonds (see top-right figure).
M The second uses an Inclusive Gateway (see bottom-right picture).
Table 7.2 - BPMN Extended Modeling Elements
Condition 1
Condition 2
Condition 2
Condition 1
alternativ notation:
Brugt som start-hændelser:
Wednesday, June 19, 13
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
BPMN 2.0 Processer
Hændelses-‐baserede valg
24
Business Process Model and Notation, v2.0 149
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.
Første hændelse (event) afgør valget af vej.
event-based gateway
Business Process Model and Notation, v2.0 149
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.
Gateway overflødig, hvis vi kun venter på een hændelse:
Business Process Model and Notation, v2.0 37
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.
There are two versions of this type of Deci-sion:
M The first uses a collection of conditional Sequence Flows, marked with mini-diamonds (see top-right figure).
M The second uses an Inclusive Gateway (see bottom-right picture).
Table 7.2 - BPMN Extended Modeling Elements
Condition 1
Condition 2
Condition 2
Condition 1
alternativ notation:
Brugt som start-hændelser:
Wednesday, June 19, 13
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
BPMN 2.0 Processer
Parallelle forløb
25
Parallel gateway (eller AND Split)
AND Join
Wednesday, June 19, 13
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
BPMN 2.0 Processer
Parallelle forløb II
26
inklusivt valg (inclusive choice)
inklusiv fletning/forening
Wednesday, June 19, 13
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
BPMN 2.0 Processer
Parallelle forløb II
26
inklusivt valg (inclusive choice)
inklusiv fletning/foreningOBS: Kan ikke se “lokalt” hvor mange forløb der ventes på
Wednesday, June 19, 13
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
Eksempel: Bankkonto
27
Signavio(Oryx-Academic-Initiative--http://acadmic.signavio.com--
!published!under!the!terms!of!the!Creative(Commons(License(BY/NC/SA!!http://creativecommons.org/licenses/by:nc:sa/3.0/!
EXERCISE! UNDERSTAND!BPMN!MODELS!
TRAVEL!BOOKING!
A!given!model!describes!steps!to!open!a!bank!account.!
!
QUESTIONS!
1. Does!“Verify!Customer!ID”!always!happen!after!“Record!Customer!Info”?!
2. Does!“Schedule!Status!Review”!happen!in!any!case?!
3. How!many!tasks!are!executed!at!least!/!at!most?!
4. How!many!tasks!can!happen!between!“Schedule!Status!Review”!and!“Open!Account”?!!
!
!
1.Vil “Verify Customer ID” altid forekomme efter “Record Customer Info”?
2. Hvilke aktiviteter vil altid blive udført ?
Signavio(Oryx-Academic-Initiative--http://acadmic.signavio.com--
!published!under!the!terms!of!the!Creative(Commons(License(BY/NC/SA!!http://creativecommons.org/licenses/by:nc:sa/3.0/!
EXERCISE! CREATE!BPMN!MODELS!
HOSPITAL!PROCESS!
A!hospital!wants!to!establish!a!rating!workflow!for!their!doctors.!To!make!the!workflow!reliable!two!dif:
ferent! roles!are!assigned.!The! first!one! is!a! referee! from! the!newly! created!quality!assurance!depart:
ment!while!the!second!one!represents!the!managing!director!of!the!hospital.!Both!roles!execute!all!of!
their!tasks!independently!from!each!other.!
The!referee!starts!a!new!case!regarding!a!certain!doctor!by!interviewing!patients.!Since!a!patient!inter:
view!workflow!is!already!established,!it!is!simply!integrated!in!the!new!workflow.!Meanwhile,!the!direc:
tor!asks!an!external!expert!to!review!the!work!of!the!doctor!under!rating.!Unfortunately,!since!the!ex:
pert! only! gets! a! low! expenses! fee,! it! can! happen! that! the! expert! is! not! responding! in! time.! If! that!
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
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
Eksempel: Bankkonto
27
Signavio(Oryx-Academic-Initiative--http://acadmic.signavio.com--
!published!under!the!terms!of!the!Creative(Commons(License(BY/NC/SA!!http://creativecommons.org/licenses/by:nc:sa/3.0/!
EXERCISE! UNDERSTAND!BPMN!MODELS!
TRAVEL!BOOKING!
A!given!model!describes!steps!to!open!a!bank!account.!
!
QUESTIONS!
1. Does!“Verify!Customer!ID”!always!happen!after!“Record!Customer!Info”?!
2. Does!“Schedule!Status!Review”!happen!in!any!case?!
3. How!many!tasks!are!executed!at!least!/!at!most?!
4. How!many!tasks!can!happen!between!“Schedule!Status!Review”!and!“Open!Account”?!!
!
!
1.Vil “Verify Customer ID” altid forekomme efter “Record Customer Info”?
2. Hvilke aktiviteter vil altid blive udført ?
Signavio(Oryx-Academic-Initiative--http://acadmic.signavio.com--
!published!under!the!terms!of!the!Creative(Commons(License(BY/NC/SA!!http://creativecommons.org/licenses/by:nc:sa/3.0/!
EXERCISE! CREATE!BPMN!MODELS!
HOSPITAL!PROCESS!
A!hospital!wants!to!establish!a!rating!workflow!for!their!doctors.!To!make!the!workflow!reliable!two!dif:
ferent! roles!are!assigned.!The! first!one! is!a! referee! from! the!newly! created!quality!assurance!depart:
ment!while!the!second!one!represents!the!managing!director!of!the!hospital.!Both!roles!execute!all!of!
their!tasks!independently!from!each!other.!
The!referee!starts!a!new!case!regarding!a!certain!doctor!by!interviewing!patients.!Since!a!patient!inter:
view!workflow!is!already!established,!it!is!simply!integrated!in!the!new!workflow.!Meanwhile,!the!direc:
tor!asks!an!external!expert!to!review!the!work!of!the!doctor!under!rating.!Unfortunately,!since!the!ex:
pert! only! gets! a! low! expenses! fee,! it! can! happen! that! the! expert! is! not! responding! in! time.! If! that!
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
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
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):
Business Process Model and Notation, v2.0 37
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.
There are two versions of this type of Deci-sion:
M The first uses a collection of conditional Sequence Flows, marked with mini-diamonds (see top-right figure).
M The second uses an Inclusive Gateway (see bottom-right picture).
Table 7.2 - BPMN Extended Modeling Elements
Condition 1
Condition 2
Condition 2
Condition 1
Wednesday, June 19, 13
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
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
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
Aktører via svømmebaner
30
Wednesday, June 19, 13
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
Aktører og forgreninger
31
Wednesday, June 19, 13
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
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
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
Signavio Process Editor
33
Wednesday, June 19, 13
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
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
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
Tid 5l frokost!
35
Wednesday, June 19, 13
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
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
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
Andre typer modeller
Pools: Offentlige processer
37
Wednesday, June 19, 13
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
Andre typer modeller
Eksempel: Rejsebes5lling
38
Signavio(Oryx-Academic-Initiative--http://acadmic.signavio.com--
!published!under!the!terms!of!the!Creative(Commons(License(BY/NC/SA!!http://creativecommons.org/licenses/by:nc:sa/3.0/!
EXERCISE! UNDERSTAND!BPMN!MODELS!
TRAVEL!BOOKING!
A!given!model!describes!necessary!steps!for!travel!booking!where!a!traveler!interacts!with!a!travel!agent!
!
!
QUESTIONS!
1. How!often!is!task!“Ack!change”!executed?!
2. How!often!is!task!“Reserve!tickets”!executed?!
3. Who!decides!whether!a!reservation!or!cancellation!is!chosen?!
4. What!is!the!semantics!of!the!event:based!gateway!contained!in!the!lower!pool?!
5. Is!data!flow!reflected!in!this!diagram?!
!
!
!!!
!
Signavio(Oryx-Academic-Initiative--http://acadmic.signavio.com--
!published!under!the!terms!of!the!Creative(Commons(License(BY/NC/SA!!http://creativecommons.org/licenses/by:nc:sa/3.0/!
EXERCISE! CREATE!BPMN!MODELS!
HOSPITAL!PROCESS!
A!hospital!wants!to!establish!a!rating!workflow!for!their!doctors.!To!make!the!workflow!reliable!two!dif:
ferent! roles!are!assigned.!The! first!one! is!a! referee! from! the!newly! created!quality!assurance!depart:
ment!while!the!second!one!represents!the!managing!director!of!the!hospital.!Both!roles!execute!all!of!
their!tasks!independently!from!each!other.!
The!referee!starts!a!new!case!regarding!a!certain!doctor!by!interviewing!patients.!Since!a!patient!inter:
view!workflow!is!already!established,!it!is!simply!integrated!in!the!new!workflow.!Meanwhile,!the!direc:
tor!asks!an!external!expert!to!review!the!work!of!the!doctor!under!rating.!Unfortunately,!since!the!ex:
pert! only! gets! a! low! expenses! fee,! it! can! happen! that! the! expert! is! not! responding! in! time.! If! that!
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
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
Andre typer modeller
Eksempel: Rejsebes5lling
38
Signavio(Oryx-Academic-Initiative--http://acadmic.signavio.com--
!published!under!the!terms!of!the!Creative(Commons(License(BY/NC/SA!!http://creativecommons.org/licenses/by:nc:sa/3.0/!
EXERCISE! UNDERSTAND!BPMN!MODELS!
TRAVEL!BOOKING!
A!given!model!describes!necessary!steps!for!travel!booking!where!a!traveler!interacts!with!a!travel!agent!
!
!
QUESTIONS!
1. How!often!is!task!“Ack!change”!executed?!
2. How!often!is!task!“Reserve!tickets”!executed?!
3. Who!decides!whether!a!reservation!or!cancellation!is!chosen?!
4. What!is!the!semantics!of!the!event:based!gateway!contained!in!the!lower!pool?!
5. Is!data!flow!reflected!in!this!diagram?!
!
!
!!!
!
Signavio(Oryx-Academic-Initiative--http://acadmic.signavio.com--
!published!under!the!terms!of!the!Creative(Commons(License(BY/NC/SA!!http://creativecommons.org/licenses/by:nc:sa/3.0/!
EXERCISE! CREATE!BPMN!MODELS!
HOSPITAL!PROCESS!
A!hospital!wants!to!establish!a!rating!workflow!for!their!doctors.!To!make!the!workflow!reliable!two!dif:
ferent! roles!are!assigned.!The! first!one! is!a! referee! from! the!newly! created!quality!assurance!depart:
ment!while!the!second!one!represents!the!managing!director!of!the!hospital.!Both!roles!execute!all!of!
their!tasks!independently!from!each!other.!
The!referee!starts!a!new!case!regarding!a!certain!doctor!by!interviewing!patients.!Since!a!patient!inter:
view!workflow!is!already!established,!it!is!simply!integrated!in!the!new!workflow.!Meanwhile,!the!direc:
tor!asks!an!external!expert!to!review!the!work!of!the!doctor!under!rating.!Unfortunately,!since!the!ex:
pert! only! gets! a! low! expenses! fee,! it! can! happen! that! the! expert! is! not! responding! in! time.! If! that!
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
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
Andre typer modeller
Eksempel: Rejsebes5lling
38
Signavio(Oryx-Academic-Initiative--http://acadmic.signavio.com--
!published!under!the!terms!of!the!Creative(Commons(License(BY/NC/SA!!http://creativecommons.org/licenses/by:nc:sa/3.0/!
EXERCISE! UNDERSTAND!BPMN!MODELS!
TRAVEL!BOOKING!
A!given!model!describes!necessary!steps!for!travel!booking!where!a!traveler!interacts!with!a!travel!agent!
!
!
QUESTIONS!
1. How!often!is!task!“Ack!change”!executed?!
2. How!often!is!task!“Reserve!tickets”!executed?!
3. Who!decides!whether!a!reservation!or!cancellation!is!chosen?!
4. What!is!the!semantics!of!the!event:based!gateway!contained!in!the!lower!pool?!
5. Is!data!flow!reflected!in!this!diagram?!
!
!
!!!
!
Signavio(Oryx-Academic-Initiative--http://acadmic.signavio.com--
!published!under!the!terms!of!the!Creative(Commons(License(BY/NC/SA!!http://creativecommons.org/licenses/by:nc:sa/3.0/!
EXERCISE! CREATE!BPMN!MODELS!
HOSPITAL!PROCESS!
A!hospital!wants!to!establish!a!rating!workflow!for!their!doctors.!To!make!the!workflow!reliable!two!dif:
ferent! roles!are!assigned.!The! first!one! is!a! referee! from! the!newly! created!quality!assurance!depart:
ment!while!the!second!one!represents!the!managing!director!of!the!hospital.!Both!roles!execute!all!of!
their!tasks!independently!from!each!other.!
The!referee!starts!a!new!case!regarding!a!certain!doctor!by!interviewing!patients.!Since!a!patient!inter:
view!workflow!is!already!established,!it!is!simply!integrated!in!the!new!workflow.!Meanwhile,!the!direc:
tor!asks!an!external!expert!to!review!the!work!of!the!doctor!under!rating.!Unfortunately,!since!the!ex:
pert! only! gets! a! low! expenses! fee,! it! can! happen! that! the! expert! is! not! responding! in! time.! If! that!
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 multiple-requests pattern
Wednesday, June 19, 13
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
Andre typer modeller
Example: Salgsproces
39
Signavio(Oryx-Academic-Initiative--http://acadmic.signavio.com--
!published!under!the!terms!of!the!Creative(Commons(License(BY/NC/SA!!http://creativecommons.org/licenses/by:nc:sa/3.0/!
EXERCISE! UNDERSTAND!BPMN!MODELS!
SALES!PROCESS!
A!given!model!describes!quote!creation!(sales!representative)!and!approval!(sales!executive)!as!well!as!
automated!order!processing!for!a!customer.!!
!
!
QUESTIONS!
1. Who!approves!the!quote?!!
2. How!often!can!a!quote!be!redone?!!
3. Is!the!sales!representative!directly!interacting!with!the!customer?!!
!
!
!!!
!
Signavio(Oryx-Academic-Initiative--http://acadmic.signavio.com--
!published!under!the!terms!of!the!Creative(Commons(License(BY/NC/SA!!http://creativecommons.org/licenses/by:nc:sa/3.0/!
EXERCISE! CREATE!BPMN!MODELS!
HOSPITAL!PROCESS!
A!hospital!wants!to!establish!a!rating!workflow!for!their!doctors.!To!make!the!workflow!reliable!two!dif:
ferent! roles!are!assigned.!The! first!one! is!a! referee! from! the!newly! created!quality!assurance!depart:
ment!while!the!second!one!represents!the!managing!director!of!the!hospital.!Both!roles!execute!all!of!
their!tasks!independently!from!each!other.!
The!referee!starts!a!new!case!regarding!a!certain!doctor!by!interviewing!patients.!Since!a!patient!inter:
view!workflow!is!already!established,!it!is!simply!integrated!in!the!new!workflow.!Meanwhile,!the!direc:
tor!asks!an!external!expert!to!review!the!work!of!the!doctor!under!rating.!Unfortunately,!since!the!ex:
pert! only! gets! a! low! expenses! fee,! it! can! happen! that! the! expert! is! not! responding! in! time.! If! that!
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
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
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
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
Pat
ient
Rec
eptio
nist
/D
octo
r
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 sickI need my medicine
Here is your medicine
Pickup your medicine, then
leave
Hver aktivitet er en interaktion mellem to eller flere aktører
Wednesday, June 19, 13
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
Andre typer modeller
Proces vs Koreografi
41
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
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
Pat
ient
Rec
eptio
nist
/D
octo
r
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 sickI need my medicine
Here is your medicine
Pickup your medicine, then
leave
Business Process Model and Notation, v2.0 317
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 Shipper, Retailer etc.). Message Flows connect the elements in the different Pools related to different participants, indicating Message exchanges. For example, a Planned Order Variations Message is sent by the Supplier to the Retailer; the corresponding send and receive have been modeled using regular BPMN messaging Activities. Also, a number of Messages of the same type being sent, for example a number of Retailer Order and Delivery Variations Messages can be sent from the Retailer to the Supplier, indicated by respective multi-instances constructs (for brevity, the actual elements for sending/receiving inside the multi-instances construct have been omitted).
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 sickI 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
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
BPMNs begræsninger
42
Wednesday, June 19, 13
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
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 AnalysisWil M.P. van der AalstDepartment ofMathematics and Computer Science, Eindhoven University of Tech-nology, P.O. Box 513, NL-5600 MB Eindhoven, [email protected]
Abstract. Process-aware information systems support operational business pro-cesses by combining advances in information technology with recent insightsfrom management science. Workflow management systems are typical examplesof such systems. However, many other types of information systems are also“process aware” even if their processes are hard-coded or only used implicitly(e.g., ERP systems). The shift from data orientation to process orientation has in-creased the importance process-aware information systems. Moreover, advancedanalysis techniques ranging from simulation and verification to process miningand activity monitoring allow for systems that support process improvement invarious ways. This article provides an overview of process-aware informationsystems and also relates these to business process management, workflow man-agement, process analysis techniques, and process flexibility.
Keywords: Process-Aware Information Systems, Workflow Management, Busi-ness Process Management, Petri Nets, Process Mining, Process Verification, Sim-ulation
1 IntroductionInformation technology has changed business processes within and between enter-prises. More and more work processes are being conducted under the supervisionof information systems that are driven by process models. Examples are work-flow management systems such as FileNet P8, Staffware, WebSphere, FLOWerand YAWL and Enterprise Resource Planning (ERP) systems such as SAP andOracle. Moreover, many domain specific systems have components driven by(process) models. It is hard to imagine enterprise information systems that areunaware of the processes taking place. Although the topic of business processmanagement using information technology has been addressed by consultants
1
Wednesday, June 19, 13
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
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 AnalysisWil M.P. van der AalstDepartment ofMathematics and Computer Science, Eindhoven University of Tech-nology, P.O. Box 513, NL-5600 MB Eindhoven, [email protected]
Abstract. Process-aware information systems support operational business pro-cesses by combining advances in information technology with recent insightsfrom management science. Workflow management systems are typical examplesof such systems. However, many other types of information systems are also“process aware” even if their processes are hard-coded or only used implicitly(e.g., ERP systems). The shift from data orientation to process orientation has in-creased the importance process-aware information systems. Moreover, advancedanalysis techniques ranging from simulation and verification to process miningand activity monitoring allow for systems that support process improvement invarious ways. This article provides an overview of process-aware informationsystems and also relates these to business process management, workflow man-agement, process analysis techniques, and process flexibility.
Keywords: Process-Aware Information Systems, Workflow Management, Busi-ness Process Management, Petri Nets, Process Mining, Process Verification, Sim-ulation
1 IntroductionInformation technology has changed business processes within and between enter-prises. More and more work processes are being conducted under the supervisionof information systems that are driven by process models. Examples are work-flow management systems such as FileNet P8, Staffware, WebSphere, FLOWerand YAWL and Enterprise Resource Planning (ERP) systems such as SAP andOracle. Moreover, many domain specific systems have components driven by(process) models. It is hard to imagine enterprise information systems that areunaware of the processes taking place. Although the topic of business processmanagement using information technology has been addressed by consultants
1
office information systems. In the seventies, people like Skip Ellis [10], AnatolHolt [11], and Michael Zisman [12] already worked on so-called office informa-tion systems, which were driven by explicit process models. It is interesting tosee that the three pioneers in this area independently used Petri-net variants tomodel office procedures. During the seventies and eighties there was great op-timism about the applicability of office information systems. Unfortunately, fewapplications succeeded. As a result of these experiences, both the application ofthis technology and research almost stopped for a decade. Consequently, hardlyany advances were made in the eighties. In the nineties, there again was a hugeinterest in these systems. The number of WFMSs developed in the past decadeand the many papers on workflow technology illustrate the revival of office infor-mation systems. Today WFMSs are readily available. However, their applicationis still limited to specific industries such as banking and insurance. As indicatedby Skip Ellis it is important to learn from these ups and downs. The failures inthe eighties can be explained by both technical and conceptual problems. In theeighties networks were slow or not present at all, there were no suitable graphicalinterfaces, and proper development software was missing. However, there werealso 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 ofthe technical problems have been resolved by now. However, the more conceptualproblems remain. Good standards for business process modeling are still missingand 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 thesystem. One of the problems is that software developers and computer scientistsare typically inspired by processes inside a computer system rather than processesoutside a computer. As a result, these engineers think in terms of control systemsrather than support systems. This explains that few of the existing WFMSs allowfor the so-called implicit choice, i.e., a choice resolved by the environment ratherthan the system.
To summarize we would like to state that, although the relevance of PAISs isundisputed, many fundamental problems remain to be solved. In the remainder ofthis article, we will try to shed light on some of these problems.
7Wednesday, June 19, 13
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
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 AnalysisWil M.P. van der AalstDepartment ofMathematics and Computer Science, Eindhoven University of Tech-nology, P.O. Box 513, NL-5600 MB Eindhoven, [email protected]
Abstract. Process-aware information systems support operational business pro-cesses by combining advances in information technology with recent insightsfrom management science. Workflow management systems are typical examplesof such systems. However, many other types of information systems are also“process aware” even if their processes are hard-coded or only used implicitly(e.g., ERP systems). The shift from data orientation to process orientation has in-creased the importance process-aware information systems. Moreover, advancedanalysis techniques ranging from simulation and verification to process miningand activity monitoring allow for systems that support process improvement invarious ways. This article provides an overview of process-aware informationsystems and also relates these to business process management, workflow man-agement, process analysis techniques, and process flexibility.
Keywords: Process-Aware Information Systems, Workflow Management, Busi-ness Process Management, Petri Nets, Process Mining, Process Verification, Sim-ulation
1 IntroductionInformation technology has changed business processes within and between enter-prises. More and more work processes are being conducted under the supervisionof information systems that are driven by process models. Examples are work-flow management systems such as FileNet P8, Staffware, WebSphere, FLOWerand YAWL and Enterprise Resource Planning (ERP) systems such as SAP andOracle. Moreover, many domain specific systems have components driven by(process) models. It is hard to imagine enterprise information systems that areunaware of the processes taking place. Although the topic of business processmanagement using information technology has been addressed by consultants
1
office information systems. In the seventies, people like Skip Ellis [10], AnatolHolt [11], and Michael Zisman [12] already worked on so-called office informa-tion systems, which were driven by explicit process models. It is interesting tosee that the three pioneers in this area independently used Petri-net variants tomodel office procedures. During the seventies and eighties there was great op-timism about the applicability of office information systems. Unfortunately, fewapplications succeeded. As a result of these experiences, both the application ofthis technology and research almost stopped for a decade. Consequently, hardlyany advances were made in the eighties. In the nineties, there again was a hugeinterest in these systems. The number of WFMSs developed in the past decadeand the many papers on workflow technology illustrate the revival of office infor-mation systems. Today WFMSs are readily available. However, their applicationis still limited to specific industries such as banking and insurance. As indicatedby Skip Ellis it is important to learn from these ups and downs. The failures inthe eighties can be explained by both technical and conceptual problems. In theeighties networks were slow or not present at all, there were no suitable graphicalinterfaces, and proper development software was missing. However, there werealso 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 ofthe technical problems have been resolved by now. However, the more conceptualproblems remain. Good standards for business process modeling are still missingand 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 thesystem. One of the problems is that software developers and computer scientistsare typically inspired by processes inside a computer system rather than processesoutside a computer. As a result, these engineers think in terms of control systemsrather than support systems. This explains that few of the existing WFMSs allowfor the so-called implicit choice, i.e., a choice resolved by the environment ratherthan the system.
To summarize we would like to state that, although the relevance of PAISs isundisputed, many fundamental problems remain to be solved. In the remainder ofthis article, we will try to shed light on some of these problems.
7
• 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
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
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
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
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
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
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
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
5 | P a g e
Figure 3 Procedural vs. Declarative Solutions
Source: The Decision Model (von Halle & Goldberg) © 2009 Auerbach Publications/Taylor & Francis LLC. Reprinted with the permission of the Publisher.)
The Rule Family, by definition, implies no particular sequence among the conditions to be tested. The Rule Family in Figure 3 also indicates via the “?” that there are other possible combinations of conditions to consider. The Rule Family can contain as many rows as are needed to reach the correct conclusion. For that matter, it can contain additional columns if other conditions are needed to determine a person’s credit rating. The Rule Family table also contains business logic for the logic not modeled in the business process models of option 1 and option 2. These include the adjudication of the credit rating for all values of person’s debt and employment history other than “low” and “good.” Incorporating these into the business process model rather than in the Decision Model would have enlarged and added unnecessary complexity and unnecessary sequence to the business process model. To change or add conditions in such a business process model is far more cumbersome than doing so in the corresponding Rule Family.
Immediate observations are that Option 3 is an improvement over Options 1 and 2 because it:
• Allows a much simpler business process model
Option 1
Option 2
Option 3Rule
Pattern
1 is Low is Good = "A"
1 is Low is Bad = ?
1 is High is Good = ?
1 is High is Bad = ?
Conditions Conclusion
Person Debt
Person Employment
History
Person Credit
Rating
Process Model Rule Family Table Decision Model Diagram
Eksempel
46
5 | P a g e
Figure 3 Procedural vs. Declarative Solutions
Source: The Decision Model (von Halle & Goldberg) © 2009 Auerbach Publications/Taylor & Francis LLC. Reprinted with the permission of the Publisher.)
The Rule Family, by definition, implies no particular sequence among the conditions to be tested. The Rule Family in Figure 3 also indicates via the “?” that there are other possible combinations of conditions to consider. The Rule Family can contain as many rows as are needed to reach the correct conclusion. For that matter, it can contain additional columns if other conditions are needed to determine a person’s credit rating. The Rule Family table also contains business logic for the logic not modeled in the business process models of option 1 and option 2. These include the adjudication of the credit rating for all values of person’s debt and employment history other than “low” and “good.” Incorporating these into the business process model rather than in the Decision Model would have enlarged and added unnecessary complexity and unnecessary sequence to the business process model. To change or add conditions in such a business process model is far more cumbersome than doing so in the corresponding Rule Family.
Immediate observations are that Option 3 is an improvement over Options 1 and 2 because it:
• Allows a much simpler business process model
Option 1
Option 2
Option 3Rule
Pattern
1 is Low is Good = "A"
1 is Low is Bad = ?
1 is High is Good = ?
1 is High is Bad = ?
Conditions Conclusion
Person Debt
Person Employment
History
Person Credit
Rating
Process Model Rule Family Table Decision Model Diagram
Wednesday, June 19, 13
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
Impera5v vs Deklara5v
47
5 | P a g e
Figure 3 Procedural vs. Declarative Solutions
Source: The Decision Model (von Halle & Goldberg) © 2009 Auerbach Publications/Taylor & Francis LLC. Reprinted with the permission of the Publisher.)
The Rule Family, by definition, implies no particular sequence among the conditions to be tested. The Rule Family in Figure 3 also indicates via the “?” that there are other possible combinations of conditions to consider. The Rule Family can contain as many rows as are needed to reach the correct conclusion. For that matter, it can contain additional columns if other conditions are needed to determine a person’s credit rating. The Rule Family table also contains business logic for the logic not modeled in the business process models of option 1 and option 2. These include the adjudication of the credit rating for all values of person’s debt and employment history other than “low” and “good.” Incorporating these into the business process model rather than in the Decision Model would have enlarged and added unnecessary complexity and unnecessary sequence to the business process model. To change or add conditions in such a business process model is far more cumbersome than doing so in the corresponding Rule Family.
Immediate observations are that Option 3 is an improvement over Options 1 and 2 because it:
• Allows a much simpler business process model
Option 1
Option 2
Option 3Rule
Pattern
1 is Low is Good = "A"
1 is Low is Bad = ?
1 is High is Good = ?
1 is High is Bad = ?
Conditions Conclusion
Person Debt
Person Employment
History
Person Credit
Rating
Process Model Rule Family Table Decision Model Diagram
5 | P a g e
Figure 3 Procedural vs. Declarative Solutions
Source: The Decision Model (von Halle & Goldberg) © 2009 Auerbach Publications/Taylor & Francis LLC. Reprinted with the permission of the Publisher.)
The Rule Family, by definition, implies no particular sequence among the conditions to be tested. The Rule Family in Figure 3 also indicates via the “?” that there are other possible combinations of conditions to consider. The Rule Family can contain as many rows as are needed to reach the correct conclusion. For that matter, it can contain additional columns if other conditions are needed to determine a person’s credit rating. The Rule Family table also contains business logic for the logic not modeled in the business process models of option 1 and option 2. These include the adjudication of the credit rating for all values of person’s debt and employment history other than “low” and “good.” Incorporating these into the business process model rather than in the Decision Model would have enlarged and added unnecessary complexity and unnecessary sequence to the business process model. To change or add conditions in such a business process model is far more cumbersome than doing so in the corresponding Rule Family.
Immediate observations are that Option 3 is an improvement over Options 1 and 2 because it:
• Allows a much simpler business process model
Option 1
Option 2
Option 3Rule
Pattern
1 is Low is Good = "A"
1 is Low is Bad = ?
1 is High is Good = ?
1 is High is Bad = ?
Conditions Conclusion
Person Debt
Person Employment
History
Person Credit
Rating
Process Model Rule Family Table Decision Model Diagram
Wednesday, June 19, 13
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
The Decision Model
48
• A patented way of describing Decision Logic proposed by von Halle and Goldberg
• Business Decision Maturity Model (BDMM)
• Graphical presentation
• Normalization to eliminate redundancies
3 | P a g e
Figure 1 Decision Model Diagram
Source: The Decision Model (von Halle & Goldberg) © 2009 Auerbach Publications/Taylor & Francis LLC. Reprinted with the permission of the Publisher.)
Building Test Cases for the Decision Model Consider the Decision Model example found in the Decision Model Primer, and contained in
Figure 1. The Decision Rule Family for this Decision Model is shown in Table 1.
Conditions Conclusion
Pattern Policy Manual Override Policy Tier Within Bounds Policy Renewal Method 1 Is Yes is Manual Renewal Process
2 is No is Manual Renewal Process
3 Is No is Yes is Automatic Renewal Process
Table 1 Decision Rule Family
Source: The Decision Model (von Halle & Goldberg) © 2009 Auerbach Publications/Taylor & Francis LLC. Reprinted with the permission of the Publisher.)
A brief inspection of this Rule Family is necessary to develop a test case that has all the possible logical inputs of this Rule Family, ensuring that the test case has all possible logical outputs of the Rule Family.
Policy Renewal Method
Policy Tier Within Bounds (P2, P3)Policy Renewal
Override (P1), (P3)
Policy Renewal Override
Insured Major Ownership Change
(P2)Insured Major
Location Change (P1)
Policy Annual Premium (P3)
Policy Discontinued Agent (P4)
Policy Manual Flag (P5)
Insured Major Ownership Change
Insured Minority Stockholder(P2) Insured Majority Stockholder(P3)Insured Board
Change(P1)Insured CEO Change
(P1)(P3)
Insured Major Location Change
Insured Location Zip-5 (P1)
Insured Location Occupied Square
Footage (P2)Insured Location Construction (P3)
Policy Tier Within Bounds
Policy Discount (P2)Policy Tier(P1)(P2)
Policy Discount
Policy Grade (P1)Package Grade (P1)Package Discount
(P1)Location State Category (P1)
Determine Policy
Renewal Method
3 | P a g e
Figure 1 Decision Model Diagram
Source: The Decision Model (von Halle & Goldberg) © 2009 Auerbach Publications/Taylor & Francis LLC. Reprinted with the permission of the Publisher.)
Building Test Cases for the Decision Model Consider the Decision Model example found in the Decision Model Primer, and contained in
Figure 1. The Decision Rule Family for this Decision Model is shown in Table 1.
Conditions Conclusion
Pattern Policy Manual Override Policy Tier Within Bounds Policy Renewal Method 1 Is Yes is Manual Renewal Process
2 is No is Manual Renewal Process
3 Is No is Yes is Automatic Renewal Process
Table 1 Decision Rule Family
Source: The Decision Model (von Halle & Goldberg) © 2009 Auerbach Publications/Taylor & Francis LLC. Reprinted with the permission of the Publisher.)
A brief inspection of this Rule Family is necessary to develop a test case that has all the possible logical inputs of this Rule Family, ensuring that the test case has all possible logical outputs of the Rule Family.
Policy Renewal Method
Policy Tier Within Bounds (P2, P3)Policy Renewal
Override (P1), (P3)
Policy Renewal Override
Insured Major Ownership Change
(P2)Insured Major
Location Change (P1)
Policy Annual Premium (P3)
Policy Discontinued Agent (P4)
Policy Manual Flag (P5)
Insured Major Ownership Change
Insured Minority Stockholder(P2) Insured Majority Stockholder(P3)Insured Board
Change(P1)Insured CEO Change
(P1)(P3)
Insured Major Location Change
Insured Location Zip-5 (P1)
Insured Location Occupied Square
Footage (P2)Insured Location Construction (P3)
Policy Tier Within Bounds
Policy Discount (P2)Policy Tier(P1)(P2)
Policy Discount
Policy Grade (P1)Package Grade (P1)Package Discount
(P1)Location State Category (P1)
Determine Policy
Renewal Method
Wednesday, June 19, 13
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
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 Graphs49
Wednesday, June 19, 13
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
Beløb registreresgodkend
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
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
Beløb registreresgodkend
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
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
Beløb registreresgodkend
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
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
Beløb registreresgodkend
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
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
condition
Beløb registreresgodkend
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
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
condition
Beløb registreresgodkend
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
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
condition
Beløb registreresgodkend
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
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
Design and Simula5on
51
Wednesday, June 19, 13
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
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
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
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
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
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
Design af (digitale) processer, 19. juni 2013
VidenDanmark [email protected]
Opsamling og evaluering
55
Wednesday, June 19, 13