thomas hildebrandt process design 19062013

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


mailto:[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






Introduktion

Præsenta5on af deltagere

• Navn, beskæftigelse, uddannelse, ...

• Erfaring med procesdesign

• Hvorfor deltager du ?

4






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






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






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:







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







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







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







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






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





Informa5on Control Net

13

z c :=

Computer Science and Office Information Systems

By Clarence A. Ellis and Gary J. Nutt








13

z c :=



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








13

z c :=



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.








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







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






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







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







Ski1ende standarder...

18

CMMN1.0 - Beta 1

2013

http://www.omg.org/spec/CMMN/http://www.omg.org/spec/BPMN/




http://www.omg.org/spec/CMMN/

http://www.omg.org/spec/CMMN/

http://www.omg.org/spec/BPMN/

http://www.omg.org/spec/BPMN/




BPMN processer

19






BPMN 2.0 Processer

Proces-‐elementer i BPMN• En eller flere sluthændelser

• En eller flere starthændelser

• Mellemliggende aktiviteter/hændelser

• Aktører (roller)

• Data/artefakter

• Beslutninger og

• Valg mellem alternative forløb

20


10 Process

Note . The content of this chapter is REQUIRED for BPMN Process Modeling 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.


10 Process












Definitions.






BPMN 2.0 Processer

Private BPMN processer

21


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)






BPMN 2.0 Processer


21


7.1.1 Uses of BPMN




< Choreographies






Public Processes



Policy

Determine Order is

Complete


Approve or Reject

Policy



start







BPMN 2.0 Processer


21


7.1.1 Uses of BPMN




< Choreographies






Public Processes



Policy

Determine Order is

Complete


Approve or Reject

Policy



startslut







BPMN 2.0 Processer

Hændelser og forgreninger

22


10 Process












Definitions.

start slut

hændelser (events)

beslutnings-(service)aktivitet

forgreninger (gateways)

Sekvens-flow






BPMN 2.0 Processer

Data-‐baserede valg

23


10 Process












Definitions.

Kaldes også et internt eller ekslusivt valg.

Obs: Skal altid være mindst een vej at gå.






BPMN 2.0 Processer


23


10 Process












Definitions.



beslutning baseret på data






BPMN 2.0 Processer


23


10 Process












Definitions.



data-based exclusive (XOR) gateway

X







BPMN 2.0 Processer

fletningforgrening/valg


23


10 Process












Definitions.



data-based exclusive (XOR) gateway

X







BPMN 2.0 Processer

Hændelses-‐baserede valg

24


10 Process












Definitions.

Første hændelse (event) afgør valget af vej.

event-based gateway






BPMN 2.0 Processer


24


10 Process












Definitions.


event-based gateway


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:






BPMN 2.0 Processer


24


10 Process












Definitions.


event-based gateway











Condition 1

Condition 2

Condition 2

Condition 1


Brugt som start-hændelser:






BPMN 2.0 Processer


24


10 Process












Definitions.


event-based gateway


10 Process












Definitions.

Gateway overflødig, hvis vi kun venter på een hændelse:











Condition 1

Condition 2

Condition 2

Condition 1


Brugt som start-hændelser:






BPMN 2.0 Processer

Parallelle forløb

25

Parallel gateway (eller AND Split)

AND Join






BPMN 2.0 Processer

Parallelle forløb II

26

inklusivt valg (inclusive choice)

inklusiv fletning/forening






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å






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 ?



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.!

!

!

!!!

!






Eksempel: Bankkonto

27




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 ?




HOSPITAL!PROCESS!













pert.!


!

!

!!!

!

Fleksibilitet ved valg på designtidspunkt






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):











Condition 1

Condition 2

Condition 2

Condition 1






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






Aktører via svømmebaner

30






Aktører og forgreninger

31






Tid 5l en pause !

32

• Registrer jer til 30 dages gratis prøve på Signavio BPMN designer

https://editor.signavio.com/p/register










Signavio Process Editor

33






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.”







Tid 5l frokost!

35






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







Pools: Offentlige processer

37







Eksempel: Rejsebes5lling

38




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?!

!

!

!!!

!




HOSPITAL!PROCESS!













pert.!


!

!

!!!

!








38




TRAVEL!BOOKING!


!

!

QUESTIONS!






!

!

!!!

!




HOSPITAL!PROCESS!













pert.!


!

!

!!!

!

Request-reply pattern








38




TRAVEL!BOOKING!


!

!

QUESTIONS!






!

!

!!!

!




HOSPITAL!PROCESS!













pert.!


!

!

!!!

!

Request-reply pattern multiple-requests pattern







Example: Salgsproces

39




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?!!

!

!

!!!

!




HOSPITAL!PROCESS!













pert.!


!

!

!!!

!







Koreografier

40


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


Pickup your medicine, then

leave

Hver aktivitet er en interaktion mellem to eller flere aktører







Proces vs Koreografi

41


Figure 7.3 - An example of a Collaborative Process

Choreographies

A self-contained Choreography (no Pools or Orchestration) is a definition of the expected behavior, basically a procedural contract, between interacting Participants. While a normal Process exists within a Pool, a Choreography exists between Pools (or Participants).

The Choreography looks similar to a private Business Process since it consists of a network of Activities, Events, and Gateways (see Figure 7.4). However, a Choreography is different in that the Activities are interactions that represent a set (1 or more) of Message exchanges, which involves two (2) or more Participants. In addition, unlike a normal Process, there is no central controller, responsible entity or observer of the Process.


Send Doctor Request

I want to see doctor

Illness Occurs

Send Appt.

Receive Appt.

Go see doctor

Send Symptoms

Receive Symptoms

I feel sick

Receive Prescription

Pickup

Pickup your medicine and you can leave

Send Medicine Request

Receive Medicine Request

I need my medicine

Receive Medicine


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


Go see the Doctor




leave


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.


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


Go see the Doctor




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






BPMNs begræsninger

42






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






BPMNs begræsninger

42






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





BPMNs begræsninger

42






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 ?






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.






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






Beslutningsmodellering

• Adskil beslutninger og proces

• Nemmere at opdatere og genbruge

• Indfører ikke unødvendige rækkefølger i beslutningslogikken

45






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






Option 1

Option 2

Option 3Rule

Pattern


1 is Low is Bad = ?




Person Debt

Person Employment

History

Person Credit

Rating







Impera5v vs Deklara5v

47

5 | P a g e






Option 1

Option 2

Option 3Rule

Pattern


1 is Low is Bad = ?




Person Debt

Person Employment

History

Person Credit

Rating


5 | P a g e






Option 1

Option 2

Option 3Rule

Pattern


1 is Low is Bad = ?




Person Debt

Person Employment

History

Person Credit

Rating







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


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.


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


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 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


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.


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


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


(P2)Insured Major

Location Change (P1)

Policy Annual Premium (P3)

Policy Discontinued Agent (P4)

Policy Manual Flag (P5)


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






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







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 over 1000 Beløb over

20000








50






faktura modtaget




20000

condition and response






condition



50






faktura modtaget




20000







condition



50






faktura modtaget




20000


exclude

exclude

include

include






Design and Simula5on

51






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




http://www.itu.dk/research/models/wiki/index.php/DCR_Graphs_Editor








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






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






Opsamling og evaluering

55




thomas hildebrandt process design 19062013

Education