00 wprowadzenie kluczowe elementy...
Post on 17-Jul-2020
2 Views
Preview:
TRANSCRIPT
Piotr Sawicki | Zarządzanie procesami
Politechnika Poznańska | WILiT | IT | ZST 1
00Tytuł:
WprowadzenieKluczowe elementy BPM
Przedmiot:
Zarządzanie procesami transportowo-logistycznymiSpecjalność:
Logistyka transportuWersja:
2020.03.03
Autor:
Piotr SAWICKI, dr hab. inżZakład Systemów Transportowych | WILiT | PPpiotr.sawicki@put.poznan.pl piotr.sawicki.pracownik.www.put.poznan.plwww.facebook.com/Piotr.Sawicki.PUT
2
Kluczowe elementy wykładuAgendaWPROWADZENIE
Cel i zakres wykładu. Poznajmy się.Kluczowe pojęcia.
BPM – BUSINESS PROCESS MANAGEMENT
Cykl życia BPM. Główne fazy.
NOTACJE I NARZĘDZIA BPMKluczowe notacje – różnice
i podobieństwa
ŹRÓDŁA WIEDZY O BPMLiteratura podstawowa
i uzupełniająca
PODSUMOWANIEPewnie są pytania :-)
Piotr Sawicki | Zarządzanie procesami
Piotr Sawicki | Zarządzanie procesami
Politechnika Poznańska | WILiT | IT | ZST 2
3
Cel i zakres wykładuWprowadzenie
Piotr Sawicki | Zarządzanie procesami
à Cel• zdefiniowanie pojęć kluczowych dla
całego przedmiotu
• nakreślenie obszaru zainteresowania w ramach przedmiotu
• ustalenie zasad współpracy
4
à Kluczowe pytania• Co to jest proces?
• Czym różni się proces transportowy od innych?
• Co wspólnego mają ze sobą proces i struktura organiza-cyjna?
• Kim jest klient?
• Czym jest Business ProcessManagament (BPM?
• Z jakich narzędzi wspierania BPM będziemy korzystać?
• Jaka jest dostępność tych narzędzi?
• Co stanowi główne źródła wiedzy pozwalające przygotować się do zajęć?
Cel i zakres wykładuWprowadzenie
Piotr Sawicki | Zarządzanie procesami
Piotr Sawicki | Zarządzanie procesami
Politechnika Poznańska | WILiT | IT | ZST 3
5
Proces wg. Melao i Pidd, 2000Wprowadzenie
2. Zarządzanie procesami 29
tywa postrzegania procesu jako konstrukcji społecznej według Arlbjørna i Hauga oraz Melão i Pidda zdecydowanie różni się od wcześniejszych.
a) b)
c) d)
Rys. 2.1. Porównanie czterech kluczowych podejść do rozumienia procesu Proces jako: a) mechanizm o charakterze deterministycznym, b) złożony system o cha-
rakterze dynamicznym, c) zbiór powiązanych pętli, d) konstrukcja społeczna Źródło: opracowanie własne na podstawie: Arlbjørn i Haug [8], Melão i Pidd [75]
Autorzy podkreślają, że proces realizowany jest przede wszystkim przez ludzi, którzy z definicji charakteryzują się zróżnicowanym systemem wartości, oczekiwań i celów. Z tego względu pojęcie procesu ma charakter bardziej su-biektywny, abstrakcyjny i domyślny - stanowi rezultat konstrukcji myślowej
Pion A Pion B Pion C
Proces transformacji
Wyjście Wejście Wyjście Wejście
Zasoby ludzkie
Zadania i
Technologia
Regulator 1
Poziom 2
Poziom 3
Regulator 2
Regulator 3
Regulator 4 Regulator 5
Regulator 7
Regulator 6 Wejście
Poziom 1
Poziom 4 Wyjście Wyjście Wejście
Osoba
1
Osoba
2
Osoba
3
Osoba
5
Osoba
7
Osoba
4 Osoba
6
Transformacja poprzez ludzi
Proces jako mechanizm deterministyczny
2. Zarządzanie procesami 29
tywa postrzegania procesu jako konstrukcji społecznej według Arlbjørna i Hauga oraz Melão i Pidda zdecydowanie różni się od wcześniejszych.
a) b)
c) d)
Rys. 2.1. Porównanie czterech kluczowych podejść do rozumienia procesu Proces jako: a) mechanizm o charakterze deterministycznym, b) złożony system o cha-
rakterze dynamicznym, c) zbiór powiązanych pętli, d) konstrukcja społeczna Źródło: opracowanie własne na podstawie: Arlbjørn i Haug [8], Melão i Pidd [75]
Autorzy podkreślają, że proces realizowany jest przede wszystkim przez ludzi, którzy z definicji charakteryzują się zróżnicowanym systemem wartości, oczekiwań i celów. Z tego względu pojęcie procesu ma charakter bardziej su-biektywny, abstrakcyjny i domyślny - stanowi rezultat konstrukcji myślowej
Pion A Pion B Pion C
Proces transformacji
Wyjście Wejście Wyjście Wejście
Zasoby ludzkie
Zadania i
Technologia
Regulator 1
Poziom 2
Poziom 3
Regulator 2
Regulator 3
Regulator 4 Regulator 5
Regulator 7
Regulator 6 Wejście
Poziom 1
Poziom 4 Wyjście Wyjście Wejście
Osoba
1
Osoba
2
Osoba
3
Osoba
5
Osoba
7
Osoba
4 Osoba
6
Transformacja poprzez ludzi
Złożony system o charakterze dynamicznymPiotr Sawicki | Zarządzanie procesami
6
Proces wg. Melao i Pidd, 2000Wprowadzenie
2. Zarządzanie procesami 29
tywa postrzegania procesu jako konstrukcji społecznej według Arlbjørna i Hauga oraz Melão i Pidda zdecydowanie różni się od wcześniejszych.
a) b)
c) d)
Rys. 2.1. Porównanie czterech kluczowych podejść do rozumienia procesu Proces jako: a) mechanizm o charakterze deterministycznym, b) złożony system o cha-
rakterze dynamicznym, c) zbiór powiązanych pętli, d) konstrukcja społeczna Źródło: opracowanie własne na podstawie: Arlbjørn i Haug [8], Melão i Pidd [75]
Autorzy podkreślają, że proces realizowany jest przede wszystkim przez ludzi, którzy z definicji charakteryzują się zróżnicowanym systemem wartości, oczekiwań i celów. Z tego względu pojęcie procesu ma charakter bardziej su-biektywny, abstrakcyjny i domyślny - stanowi rezultat konstrukcji myślowej
Pion A Pion B Pion C
Proces transformacji
Wyjście Wejście Wyjście Wejście
Zasoby ludzkie
Zadania i
Technologia
Regulator 1
Poziom 2
Poziom 3
Regulator 2
Regulator 3
Regulator 4 Regulator 5
Regulator 7
Regulator 6 Wejście
Poziom 1
Poziom 4 Wyjście Wyjście Wejście
Osoba
1
Osoba
2
Osoba
3
Osoba
5
Osoba
7
Osoba
4 Osoba
6
Transformacja poprzez ludzi
2. Zarządzanie procesami 29
tywa postrzegania procesu jako konstrukcji społecznej według Arlbjørna i Hauga oraz Melão i Pidda zdecydowanie różni się od wcześniejszych.
a) b)
c) d)
Rys. 2.1. Porównanie czterech kluczowych podejść do rozumienia procesu Proces jako: a) mechanizm o charakterze deterministycznym, b) złożony system o cha-
rakterze dynamicznym, c) zbiór powiązanych pętli, d) konstrukcja społeczna Źródło: opracowanie własne na podstawie: Arlbjørn i Haug [8], Melão i Pidd [75]
Autorzy podkreślają, że proces realizowany jest przede wszystkim przez ludzi, którzy z definicji charakteryzują się zróżnicowanym systemem wartości, oczekiwań i celów. Z tego względu pojęcie procesu ma charakter bardziej su-biektywny, abstrakcyjny i domyślny - stanowi rezultat konstrukcji myślowej
Pion A Pion B Pion C
Proces transformacji
Wyjście Wejście Wyjście Wejście
Zasoby ludzkie
Zadania i
Technologia
Regulator 1
Poziom 2
Poziom 3
Regulator 2
Regulator 3
Regulator 4 Regulator 5
Regulator 7
Regulator 6 Wejście
Poziom 1
Poziom 4 Wyjście Wyjście Wejście
Osoba
1
Osoba
2
Osoba
3
Osoba
5
Osoba
7
Osoba
4 Osoba
6
Transformacja poprzez ludzi
Proces jako zbiór powiązanych pętli Proces jako konstrukcja społecznaPiotr Sawicki | Zarządzanie procesami
Piotr Sawicki | Zarządzanie procesami
Politechnika Poznańska | WILiT | IT | ZST 4
7
à Proces to:• ustrukturyzowany zbiór czynności
realizowanych z wykorzystaniem niezbędnych zasobów
• przetwarza elementy wejściowe w oczekiwane rezultaty
• przebieg kształtują interakcje wewnętrzne w procesie, z otoczeniem wewnętrznym (inne procesy) i zewnętrznym (rynek i klienci)
Proces wg. Sawicki P. (2013)Wprowadzenie2"
Czynności
Logika, kolejność,
związki przyczynowo-
skutkowe
Zasoby
Wykonawcy,
wyposażenie techniczne,
informacja, kapitał, materiały, energia
PROCES
Rezultaty
Rezultaty,
wyniki
Wejście
Dane,
zdarzenia,
oczekiwania,
wymogi
2"
Piotr Sawicki | Zarządzanie procesami
8
à Jak rozumiesz proces?• przewozu pasażerów w transporcie
zbiorowym• kompletacji dostaw do sklepów
ProcesWprowadzenie2"
Czynności
Logika, kolejność,
związki przyczynowo-
skutkowe
Zasoby
Wykonawcy,
wyposażenie techniczne,
informacja, kapitał, materiały, energia
PROCES
Rezultaty
Rezultaty,
wyniki
Wejście
Dane,
zdarzenia,
oczekiwania,
wymogi
2"
Piotr Sawicki | Zarządzanie procesami
Piotr Sawicki | Zarządzanie procesami
Politechnika Poznańska | WILiT | IT | ZST 5
9
Proces vs. struktura organizacyjnaWprowadzenie
Rozwój
nowego
wyrobu
Proukcja
wyrobu
Promowanie
wyrobu
Dystrybucja
Zaopatrzenie
Obsługa
zamówień
Gotowy wyrób
Wzór nowego
wyrobu
Kampania
promocyjna
Przyjęte
zamówienia
Zrealizowana
dostawa
Dostępne
surowce
Controling
finansowy
Rentowność
wyrobu
Klient
Klient
Dostawca
Potrzeba
Surowce
Zaspokojona
potrzeba
Zamówienia
Piotr Sawicki | Zarządzanie procesami
10
Proces vs. struktura organizacyjnaWprowadzenie
Finanse
i księgowość Marketing
Projektowanie
i rozwój Produkcja Sprzedaż Logistyka
ZARZĄD
Rozwój
nowego
wyrobu
Proukcja
wyrobu
Promowanie
wyrobu
Dystrybucja
Zaopatrzenie
Obsługa
zamówień
Gotowy wyrób
Wzór nowego
wyrobu
Kampania
promocyjna
Przyjęte
zamówienia
Zrealizowana
dostawa
Dostępne
surowce
Controling
finansowy
Rentowność
wyrobu
Klient
Klient
Dostawca
Potrzeba
Surowce
Zaspokojona
potrzeba
Zamówienia
Finanse i księgowość Marketing
Projektowanie i rozwój Produkcja Sprzedaż Logistyka
ZARZĄD
A. Orientacja funkcjonalna B. Orientacja procesowa
- komunikacja
Piotr Sawicki | Zarządzanie procesami
Piotr Sawicki | Zarządzanie procesami
Politechnika Poznańska | WILiT | IT | ZST 6
11
Proces vs. struktura organizacyjna vs. klientWprowadzenie
Finanse
i księgowość Marketing
Projektowanie
i rozwój Produkcja Sprzedaż Logistyka
ZARZĄD
Rozwój
nowego
wyrobu
Proukcja
wyrobu
Promowanie
wyrobu
Dystrybucja
Zaopatrzenie
Obsługa
zamówień
Gotowy wyrób
Wzór nowego
wyrobu
Kampania
promocyjna
Przyjęte
zamówienia
Zrealizowana
dostawa
Dostępne
surowce
Controling
finansowy
Rentowność
wyrobu
Klient
Klient
Dostawca
Potrzeba
Surowce
Zaspokojona
potrzeba
Zamówienia
Klient ZEwnętrzny Klient WEwnętrznyPiotr Sawicki | Zarządzanie procesami
12
Konfiguracja
Realizacja
Monitoring
Ocena
Analiza
Projektowanie
Projektowanie
Modelowanie Doskonalenie
Cykl życia BPMBPM – business process mngt
- Wymagania biznesu- Niezbędne zasoby
- Formalny zapis procesu
- Uruchomienie procesu- Przeszkolenie
wykonawców- Ustalanie parametrów
funkcjonalnych- Regularna realizacja procesu
- Obserwacja - Kontrola efektów
- Możliwości poprawy- Optymalizacja,
symulacja Cykl zarządzania procesem
(BPM)
Piotr Sawicki | Zarządzanie procesami
Piotr Sawicki | Zarządzanie procesami
Politechnika Poznańska | WILiT | IT | ZST 7
13
Konfiguracja
Realizacja
Monitoring
Ocena
Analiza
Projektowanie
Projektowanie
Modelowanie Doskonalenie
Cykl życia BPMBPM
- Wymagania biznesu- Niezbędne zasoby- Formalny zapis procesu
- Uruchomienie procesu- Przeszkolenie
wykonawców- Ustalanie parametrów
funkcjonalnych- Regularna realizacja procesu
- Możliwości poprawy- Optymalizacja,
symulacja- Obserwacja- Kontrola efektów
Cykl zarządzania procesem
(BPM)
1
2
3
4
Piotr Sawicki | Zarządzanie procesami
14
àAnaliza, projektowanie i modelowanie• (1.1) Jak identyfikować / budować
proces? Podstawy metodyczne– Istota budowy modelu – po co
modelować? – Architektura procesów – Notacja EPC vs. BPMN2.0
Podstawy narzędziowe– Narzędzie ARIS Architect & Designer
(10.0)
Kluczowe elementy BPMBPM
Konfiguracja
Realizacja
Monitoring
Ocena
Analiza
Projektowanie
Projektowanie
Modelowanie Doskonalenie 1
Piotr Sawicki | Zarządzanie procesami
Piotr Sawicki | Zarządzanie procesami
Politechnika Poznańska | WILiT | IT | ZST 8
15
àAnaliza, projektowanie i modelowanie• (1.2) Modelowanie w praktyce
Podstawy narzędziowe– Narzędzie ARIS Architect & Designer
(10.0)– Raportowanie procesu
Kluczowe elementy BPMBPM
Konfiguracja
Realizacja
Monitoring
Ocena
Analiza
Projektowanie
Projektowanie
Modelowanie Doskonalenie 1
Piotr Sawicki | Zarządzanie procesami
16
à Konfigurowanie• (2.1) Konfigurowanie procesu
Podstawy metodyczne
– Konwersja modelu procesu do modelu symulacyjnego
– Miary charakteryzujące proces czas trwania procesuczas przetwarzania funkcji/czynnościwydajność procesucałkowity czas przetwarzaniastopień wykorzystania zasobów zjawisko wąskiegoliczba / czas oczekiwania w kolejce gardła …
Kluczowe elementy BPMBPM
Piotr Sawicki | Zarządzanie procesami
Konfiguracja
Realizacja
Monitoring
Ocena
Analiza
Projektowanie
Projektowanie
Modelowanie Doskonalenie
2
Piotr Sawicki | Zarządzanie procesami
Politechnika Poznańska | WILiT | IT | ZST 9
17
à Konfigurowanie• (2.2) Konfigurowanie procesu
Podstawy narzędziowe
– Parametryzacja modelu procesu –tworzenie modelu symulacyjnego
– Sterowanie symulacjąustawienie zakresu czasowegookreślanie dostępności zasobów
– Ocena wyników symulacjądobór statystyk rezultatówinterpretacja wyników
Kluczowe elementy BPMBPM
Piotr Sawicki | Zarządzanie procesami
Konfiguracja
Realizacja
Monitoring
Ocena
Analiza
Projektowanie
Projektowanie
Modelowanie Doskonalenie
2
18
àOcena, monitorowanie i doskonalenie• (4.1) Jak doskonalić procesy?
Zastosowanie symulacji do oceny skutków zmian
Kluczowe elementy BPMBPM
Piotr Sawicki | Zarządzanie procesami
Konfiguracja
Realizacja
Monitoring
Ocena
Analiza
Projektowanie
Projektowanie
Modelowanie Doskonalenie
4
Piotr Sawicki | Zarządzanie procesami
Politechnika Poznańska | WILiT | IT | ZST 10
19
àNotacja to formalny zapis procesu• Czy potrafisz zbudować czytelny opis procesu?
Notacje modelowaniaNarzędzia i notacje w BPM
Piotr Sawicki | Zarządzanie procesami
20
àNotacja - język modelowania• opisu przebiegu i zasobów
procesu
• istnieją różne koncepcje opisu– EPC
ang. Event-driven process chaindiagram (Scheer, 1999)
– BPMN v.2.0 ang. Business process modelingnotation (OMG, 2011)
– inne: Petri-net, YAWL, UML,… (Waske, 2012; Sawicki, 2013)
Notacje modelowaniaNarzędzia i notacje w BPM
!14!
Rys. 2.9. Model procesu weryfikacji i przydziału zlecenia przewozowego do realizacji, opisany w notacji BPMN v.2.0 (po korektach)
Zax $$
Dyspozy
tor
Wpłynęło zlecenie
na pojazd 32EUR
Wpłynęło zlecenie na
pojazd do18EUR
Wprowadzanie
zlecenia do systemu
Odmowa realizacji
zlecenia
Przydzielanie zamówienia do
pojazdu
Spedyto
r
Brak zaległości
Stwierdzone zaległości
`$Zlecenie
przydzielone do pojazdu
Poinformowano klienta o braku
możliwości realizacji zlecenia
Dostępne pojazdy
Chwilowy brak wolnych pojazdów
Za$
Klie
nt
4.7 Business Process Modeling Notation 211
final version of the paper that will be printed in the conference proceedings.In case the paper is rejected, the join gateway is triggered. To clarify the be-haviour of the split gateway, the outgoing sequence flows are associated withthe respective annotations.
The participants that cooperate in the context of a business process com-municate by sending and receiving messages. In business process diagrams,messages are represented by message flow. Typically a message flow connectsan activity of one participant to an activity or an event of another participant.
Depending on the kind of business process diagram (abstract or global),message flows can link pairs of flow objects, pools, and events. Detailed ruleson message flow connections are discussed below. “A Message Flow is used toshow the flow of messages between two participants that are prepared to sendand receive them. In BPMN, two separate Pools in the Diagram will representthe two participants (e.g., business entities or business roles).”
The notational elements of the BPMN regarding transactional behaviour ofbusiness processes (transaction groups, compensation flow, and cancellation)will not be covered, because their semantics is not laid out in su�cient detailand precision.
Events
Events play a central role in business process management, since they are theglue between situations in business organizations and processes that will be en-acted if these situations occur. Events in a business process can be partitionedinto three types, based on their position in the business process: start eventsare used to trigger processes, intermediate events can delay processes, or theycan occur during processes. End events signal the termination of processes.The notational elements for the event trigger types are shown in Figure 4.80.
Start
Intermediate
End
Termination
Message Timer Rule Error Link Multiple
Fig. 4.80. Event types in the BPMN, Object Management Group (2006)
Start events can have di↵erent triggers.
4.7 Business Process Modeling Notation 211
final version of the paper that will be printed in the conference proceedings.In case the paper is rejected, the join gateway is triggered. To clarify the be-haviour of the split gateway, the outgoing sequence flows are associated withthe respective annotations.
The participants that cooperate in the context of a business process com-municate by sending and receiving messages. In business process diagrams,messages are represented by message flow. Typically a message flow connectsan activity of one participant to an activity or an event of another participant.
Depending on the kind of business process diagram (abstract or global),message flows can link pairs of flow objects, pools, and events. Detailed ruleson message flow connections are discussed below. “A Message Flow is used toshow the flow of messages between two participants that are prepared to sendand receive them. In BPMN, two separate Pools in the Diagram will representthe two participants (e.g., business entities or business roles).”
The notational elements of the BPMN regarding transactional behaviour ofbusiness processes (transaction groups, compensation flow, and cancellation)will not be covered, because their semantics is not laid out in su�cient detailand precision.
Events
Events play a central role in business process management, since they are theglue between situations in business organizations and processes that will be en-acted if these situations occur. Events in a business process can be partitionedinto three types, based on their position in the business process: start eventsare used to trigger processes, intermediate events can delay processes, or theycan occur during processes. End events signal the termination of processes.The notational elements for the event trigger types are shown in Figure 4.80.
Start
Intermediate
End
Termination
Message Timer Rule Error Link Multiple
Fig. 4.80. Event types in the BPMN, Object Management Group (2006)
Start events can have di↵erent triggers.
Zlecenie
Business Process Model and Notation, v2.0 261
Table 10.93 – Types of Events and their Markers
Types Start Intermediate EndTop-Level
EventSub-ProcessInterrupting
EventSub-ProcessNon-Interrupting
Catching BoundaryInterrupting
BoundaryNon-Interrupting
Throwing
None
Message
Timer
Error
Escalation
Cancel
Compensation
Conditional
Link
Signal
Terminate
Multiple
Business Process Model and Notation, v2.0 261
Table 10.93 – Types of Events and their Markers
Types Start Intermediate EndTop-Level
EventSub-ProcessInterrupting
EventSub-ProcessNon-Interrupting
Catching BoundaryInterrupting
BoundaryNon-Interrupting
Throwing
None
Message
Timer
Error
Escalation
Cancel
Compensation
Conditional
Link
Signal
Terminate
Multiple
Business Process Model and Notation, v2.0 261
Table 10.93 – Types of Events and their Markers
Types Start Intermediate EndTop-Level
EventSub-ProcessInterrupting
EventSub-ProcessNon-Interrupting
Catching BoundaryInterrupting
BoundaryNon-Interrupting
Throwing
None
Message
Timer
Error
Escalation
Cancel
Compensation
Conditional
Link
Signal
Terminate
Multiple
Business Process Model and Notation, v2.0 261
Table 10.93 – Types of Events and their Markers
Types Start Intermediate EndTop-Level
EventSub-ProcessInterrupting
EventSub-ProcessNon-Interrupting
Catching BoundaryInterrupting
BoundaryNon-Interrupting
Throwing
None
Message
Timer
Error
Escalation
Cancel
Compensation
Conditional
Link
Signal
Terminate
Multiple
Ocena wiarygodności
klienta
`$
Dzi
ał t
ransport
u
36 Business Process Model and Notation, v2.0
Data Object Data Objects provide information about what Activities require to be performed and/or what they produce (see page 205), Data Objects can represent a singular object or a collection of objects. Data Input and Data Output provide the same information for Processes.
Data Object
Data Objec (Collection)
Data Input Data Output
Message A Message is used to depict the contents of a communication between two Participants (as defined by a business PartnerRole or a business PartnerEntity—see on page 93).
Fork BPMN uses the term “fork” to refer to the dividing of a path into two or more parallel paths (also known as an AND-Split). It is a place in the Process where activities can be performed concurrently, rather than sequentially.
There are two options:
• Multiple Outgoing Sequence Flows can be used (see figure top-right). This represents “uncontrolled” flow is the preferred method for most situations.
• A Parallel Gateway can be used (see figure bottom-right). This will be used rarely, usually in combination with other Gateways.
Table 7.2 - BPMN Extended Modeling Elements
Odrzucenie zlecenia
36 Business Process Model and Notation, v2.0
Data Object Data Objects provide information about what Activities require to be performed and/or what they produce (see page 205), Data Objects can represent a singular object or a collection of objects. Data Input and Data Output provide the same information for Processes.
Data Object
Data Objec (Collection)
Data Input Data Output
Message A Message is used to depict the contents of a communication between two Participants (as defined by a business PartnerRole or a business PartnerEntity—see on page 93).
Fork BPMN uses the term “fork” to refer to the dividing of a path into two or more parallel paths (also known as an AND-Split). It is a place in the Process where activities can be performed concurrently, rather than sequentially.
There are two options:
• Multiple Outgoing Sequence Flows can be used (see figure top-right). This represents “uncontrolled” flow is the preferred method for most situations.
• A Parallel Gateway can be used (see figure bottom-right). This will be used rarely, usually in combination with other Gateways.
Table 7.2 - BPMN Extended Modeling Elements
Business Process Model and Notation, v2.0 161
Receive Task
A Receive Task is a simple Task that is designed to wait for a Message to arrive from an external Participant (relative to the Process). Once the Message has been received, the Task is completed.
The actual Participant from which the Message is received can be identified by connecting the Receive Task to a Participant using a Message Flows within the definitional Collaboration of the Process – see Table 10.1.
A Receive Task is often used to start a Process. In a sense, the Process is bootstrapped by the receipt of the Message. In order for the Receive Task to instantiate the Process its instantiate attribute MUST be set to true and it MUST NOT have any incoming Sequence Flow.
A Receive Task object shares the same shape as the Task, which is a rectangle that has rounded corners. However, there is an unfilled envelope marker (the same marker as a catch Message Event) in the upper left corner of the shape that indicates that the Task is a Receive Task.
A Receive Task is a rounded corner rectangle that MUST be drawn with a single thin line and includes an unfilled envelope marker that distinguishes the shape from other Task types (as shown in Figure 10.15). If the instantiate attribute is set to true, the envelope marker looks like a Message Start Event (as shown in Figure 10.16).
Figure 10.15 - A Receive Task Object
Table 10.9 – Send Task model associations
Attribute Name Description/Usage
messageRef: Message [0..1] A Message for the messageRef attribute MAY be entered. This indicates that the Message will be sent by the Task. The Message in this context is equivalent to an out-only message pattern (Web service). One or more corresponding outgoing Message Flows MAY be shown on the diagram. However, the display of the Message Flows is NOT REQUIRED. The Message is applied to all outgoing Message Flows and the Message will be sent down all outgoing Message Flows at the completion of a single instance of the Task.
operationRef: Operation This attribute specifies the operation that is invoked by the Send Task.
implementation: string = ##webService
This attribute specifies the technology that will be used to send and receive the Messages. Valid values are "##unspecified" for leaving the implementation technology open, "##WebService" for the Web service technology or a URI identifying any other technology or coordination protocol A Web service is the default technology.
160 Business Process Model and Notation, v2.0
A Send Task is a rounded corner rectangle that MUST be drawn with a single thin line and includes a filled envelope marker that distinguishes the shape from other Task types (as shown in Figure 10.13).
Figure 10.13 - A Send Task Object
Figure 10.14 - The Send Task and Receive Task class diagram
The Send Task inherits the attributes and model associations of Activity (see Table 10.3). In addition the following constraints apply when the Send Task references a Message: The Send Task has at most one inputSet and one Data Input. If the Data Input is present, it MUST have an ItemDefinition equivalent to the one defined by the associated Message. At execution time, when the Send Task is executed, the data automatically moves from the Data Input on the Send Task into the Message to be sent. If the Data Input is not present, the Message will not be populated with data from the Process.
Table 10.9 presents the additional model associations of the Send Task.
Zlecenie
4.7 Business Process Modeling Notation 209
Pool
Flow Objects
Events
Activities Place Order
Gateways
Connecting Objects
Sequence Flow
Message Flow
Association
Swimlanes
Lane
Data Object
Group
Artefacts
Annotation
Fig. 4.78. Business Process Modeling Notation: categories of elements
Since the goal of this example is to introduce the core elements, simplifica-tions are in place: the business process model provides a simplified view of howreview processes are actually conducted. In addition, there are many authorsand there are also many reviewers. For convenience, just one author and onereviewer are shown. As will be discussed below, situations in which multipleparticipants are involved in the same role cannot be covered conveniently.
The pools in this example represent roles and not concrete participants in abusiness process. Each role at run time has multiple concrete participants whoare actually involved in the business process instance. The BPMN standardindicates that “a pool represents a participant in a process. It is also acts as a“swimlane” and a graphical container for partitioning a set of activities fromother pools, usually in the context of B2B situations.”
The process starts when the PC Chair is asked to organize the scientificprogram of a conference. This is reflected by the start event of the process atthe PC Chair. An event is something that ‘happens’ during the course of abusiness process. These events a↵ect the flow of the process and usually havea cause (trigger) or an impact (result). Events are circles with open centresto allow internal markers to di↵erentiate di↵erent triggers or results.”
The activity enacted first is the publication of a call for papers with de-tailed information on the conference, such as name and location, and alsoinformation regarding the topics addressed by the conference. The receipt ofa message can be an event that is relevant for the process. This concept isused in the sample process when the published call for papers activity sendsa message that the author receives. Receiving this message is represented bythe start event of the author process. The cause of this event is receiving the
Business Process Model and Notation, v2.0 163
User Task
A User Task is a typical “workflow” Task where a human performer performs the Task with the assistance of a software application and is scheduled through a task list manager of some sort.
A User Task is a rounded corner rectangle that MUST be drawn with a single thin line and includes a human figure marker that distinguishes the shape from other Task types (as shown in Figure 10.17).
Figure 10.17 - A User Task Object
See “User Task” on page 163 within the larger section of “Human Interactions” for the details of User Tasks.
Manual Task
A Manual Task is a Task that is expected to be performed without the aid of any business process execution engine or any application. An example of this could be a telephone technician installing a telephone at a customer location.
A Manual Task is a rounded corner rectangle that MUST be drawn with a single thin line and includes a hand figure marker that distinguishes the shape from other Task types (as shown in Figure 10.17).
Figure 10.18 - A Manual Task Object
See “Manual Task” on page 165 within the larger section of “Human Interactions” for the details of Manual Tasks.
Business Rule
A Business Rule Task provides a mechanism for the Process to provide input to a Business Rules Engine and to get the output of calculations that the Business Rules Engine might provide. The InputOutputSpecification of the Task (see page 211) will allow the Process to send data to and receive data from the Business Rules Engine.
A Business Rule Task object shares the same shape as the Task, which is a rectangle that has rounded corners. However, there is a graphical marker in the upper left corner of the shape that indicates that the Task is a Business Rule Task (see Figure 10.11).
Business Process Model and Notation, v2.0 163
User Task
A User Task is a typical “workflow” Task where a human performer performs the Task with the assistance of a software application and is scheduled through a task list manager of some sort.
A User Task is a rounded corner rectangle that MUST be drawn with a single thin line and includes a human figure marker that distinguishes the shape from other Task types (as shown in Figure 10.17).
Figure 10.17 - A User Task Object
See “User Task” on page 163 within the larger section of “Human Interactions” for the details of User Tasks.
Manual Task
A Manual Task is a Task that is expected to be performed without the aid of any business process execution engine or any application. An example of this could be a telephone technician installing a telephone at a customer location.
A Manual Task is a rounded corner rectangle that MUST be drawn with a single thin line and includes a hand figure marker that distinguishes the shape from other Task types (as shown in Figure 10.17).
Figure 10.18 - A Manual Task Object
See “Manual Task” on page 165 within the larger section of “Human Interactions” for the details of Manual Tasks.
Business Rule
A Business Rule Task provides a mechanism for the Process to provide input to a Business Rules Engine and to get the output of calculations that the Business Rules Engine might provide. The InputOutputSpecification of the Task (see page 211) will allow the Process to send data to and receive data from the Business Rules Engine.
A Business Rule Task object shares the same shape as the Task, which is a rectangle that has rounded corners. However, there is a graphical marker in the upper left corner of the shape that indicates that the Task is a Business Rule Task (see Figure 10.11).
System dyspozytorski
Baza klientów
Ocena możliwości
warunkowego
przyjęcia zlec.
164 Business Process Model and Notation, v2.0
A Business Rule Task is a rounded corner rectangle that MUST be drawn with a single thin line and includes a marker that distinguishes the shape from other Task types (as shown in Figure 10.19).
Figure 10.19 - A Business Rule Task Object
The Business Rule Task inherits the attributes and model associations of Activity (see Table 10.3). Table 10.11 presents the additional attributes of the Business Rule Task.
Script Task
A Script Task is executed by a business process engine. The modeler or implementer defines a script in a language that the engine can interpret. When the Task is ready to start, the engine will execute the script. When the script is completed, the Task will also be completed.
A Script Task object shares the same shape as the Task, which is a rectangle that has rounded corners. However, there is a graphical marker in the upper left corner of the shape that indicates that the Task is a Script Task (see Figure 10.11).
A Script Task is a rounded corner rectangle that MUST be drawn with a single thin line and includes a marker that distinguishes the shape from other Task types (as shown in Figure 10.20).
Figure 10.20 - A Script Task Object
Table 10.11 – Business Rule Task attributes and model associations
Attribute Name Description/Usage
implementation: string = ##unspecified
This attribute specifies the technology that will be used to implement the Business Rule Task. Valid values are "##unspecified" for leaving the implementation technology open, "##WebService" for the Web service technology or a URI identifying any other technology or coordination protocol. The default technology for this task is unspecified.
Warunkowo przyjęto zlecenie
do realizacji
Business Process Model and Notation, v2.0 261
Table 10.93 – Types of Events and their Markers
Types Start Intermediate EndTop-Level
EventSub-ProcessInterrupting
EventSub-ProcessNon-Interrupting
Catching BoundaryInterrupting
BoundaryNon-Interrupting
Throwing
None
Message
Timer
Error
Escalation
Cancel
Compensation
Conditional
Link
Signal
Terminate
Multiple
Brak możliwości realizacji zlecenia
Business Process Model and Notation, v2.0 261
Table 10.93 – Types of Events and their Markers
Types Start Intermediate EndTop-Level
EventSub-ProcessInterrupting
EventSub-ProcessNon-Interrupting
Catching BoundaryInterrupting
BoundaryNon-Interrupting
Throwing
None
Message
Timer
Error
Escalation
Cancel
Compensation
Conditional
Link
Signal
Terminate
Multiple
Business Process Model and Notation, v2.0 261
Table 10.93 – Types of Events and their Markers
Types Start Intermediate EndTop-Level
EventSub-ProcessInterrupting
EventSub-ProcessNon-Interrupting
Catching BoundaryInterrupting
BoundaryNon-Interrupting
Throwing
None
Message
Timer
Error
Escalation
Cancel
Compensation
Conditional
Link
Signal
Terminate
Multiple
Zbyt długi okres oczekiwania na wolny pojazd !
13!
Rys. 2.7. Model procesu weryfikacji i przydziału zlecenia przewozowego do realizacji, opracowany w notacji EPC
(po korektach)
Ocena
wiarygodności
klienta
Na koncie klienta
brak jest zaległych
płatności
Na koncie klienta
widnieją zaległe
płatności
Odmowa
realizacji
zlecenia
Wprowadzanie
zlecenia do
systemu
Wpłynęło zlecenie
na pojazd 32EUR
Wpłynęło
zlecenie na pojazd
do18EUR
Zamówienie
dostępne
w systemie
Przydzielanie
zlecenia
do pojazdu
Oczekiwanie na
dostępność
wolnych pojazdów
jest zbyt długie
Chwilowo brak
dostępnych
pojazdów
Spedytor
Spedytor
Spedytor
Klienta
poinformowano
o braku możliwości
realizacji zlecenia
Dyspozytor
Baza
klientów
System
dyspozytorski
System
dyspozytorski Baza
klientów
Zlecenie
Ocena możliwości
warunkowego
przyjęcia zlecenia
Spedytor Baza
klientów
Brak możliwości
realizacji zlecenia
Warunkowo
przyjęto
zlecenie do
realizacji
Zlecenie
przydzielono do
pojazdu
Realizacja
zleceń
Piotr Sawicki | Zarządzanie procesami
Piotr Sawicki | Zarządzanie procesami
Politechnika Poznańska | WILiT | IT | ZST 11
21
Notacja EPCNarzędzia i notacje w BPM
!13!
Rys. 2.7. Model procesu weryfikacji i przydziału zlecenia przewozowego do realizacji, opracowany w notacji EPC
(po korektach)
Ocena
wiarygodności
klienta
Na koncie klienta
brak jest zaległych
płatności
Na koncie klienta
widnieją zaległe
płatności
Odmowa
realizacji
zlecenia
Wprowadzanie
zlecenia do
systemu
Wpłynęło zlecenie
na pojazd 32EUR
Wpłynęło
zlecenie na pojazd
do18EUR
Zamówienie
dostępne
w systemie
Przydzielanie
zlecenia
do pojazdu
Oczekiwanie na
dostępność
wolnych pojazdów
jest zbyt długie
Chwilowo brak
dostępnych
pojazdów
Spedytor
Spedytor
Spedytor
Klienta
poinformowano
o braku możliwości
realizacji zlecenia
Dyspozytor
Baza
klientów
System
dyspozytorski
System
dyspozytorski Baza
klientów
Zlecenie
Ocena możliwości
warunkowego
przyjęcia zlecenia
Spedytor Baza
klientów
Brak możliwości
realizacji zlecenia
Warunkowo
przyjęto
zlecenie do
realizacji
Zlecenie
przydzielono do
pojazdu
Realizacja
zleceń
Ocena wiarygodności
klienta
Na koncie
klienta brak
jest zaległych
płatności
Na koncie klienta
widnieją zaległe
płatności
Wpłynęło
zlecenie na
pojazd 32EUR
Wpłynęło
zlecenie na pojazd
do18EUR
Spedytor
Baza
klientów
Zlecenie
Piotr Sawicki | Zarządzanie procesami
22
Notacja BPMN 2.0Narzędzia i notacje w BPM
!14!
Rys. 2.9. Model procesu weryfikacji i przydziału zlecenia przewozowego do realizacji, opisany w notacji BPMN v.2.0 (po korektach)
Zax $$
Dyspozy
tor
Wpłynęło zlecenie
na pojazd 32EUR
Wpłynęło zlecenie na
pojazd do18EUR
Wprowadzanie
zlecenia do systemu
Odmowa realizacji
zlecenia
Przydzielanie zamówienia do
pojazdu
Spedyto
r
Brak zaległości
Stwierdzone zaległości
`$Zlecenie
przydzielone do pojazdu
Poinformowano klienta o braku
możliwości realizacji zlecenia
Dostępne pojazdy
Chwilowy brak wolnych pojazdów
Za$
Klie
nt
4.7 Business Process Modeling Notation 211
final version of the paper that will be printed in the conference proceedings.In case the paper is rejected, the join gateway is triggered. To clarify the be-haviour of the split gateway, the outgoing sequence flows are associated withthe respective annotations.
The participants that cooperate in the context of a business process com-municate by sending and receiving messages. In business process diagrams,messages are represented by message flow. Typically a message flow connectsan activity of one participant to an activity or an event of another participant.
Depending on the kind of business process diagram (abstract or global),message flows can link pairs of flow objects, pools, and events. Detailed ruleson message flow connections are discussed below. “A Message Flow is used toshow the flow of messages between two participants that are prepared to sendand receive them. In BPMN, two separate Pools in the Diagram will representthe two participants (e.g., business entities or business roles).”
The notational elements of the BPMN regarding transactional behaviour ofbusiness processes (transaction groups, compensation flow, and cancellation)will not be covered, because their semantics is not laid out in su�cient detailand precision.
Events
Events play a central role in business process management, since they are theglue between situations in business organizations and processes that will be en-acted if these situations occur. Events in a business process can be partitionedinto three types, based on their position in the business process: start eventsare used to trigger processes, intermediate events can delay processes, or theycan occur during processes. End events signal the termination of processes.The notational elements for the event trigger types are shown in Figure 4.80.
Start
Intermediate
End
Termination
Message Timer Rule Error Link Multiple
Fig. 4.80. Event types in the BPMN, Object Management Group (2006)
Start events can have di↵erent triggers.
4.7 Business Process Modeling Notation 211
final version of the paper that will be printed in the conference proceedings.In case the paper is rejected, the join gateway is triggered. To clarify the be-haviour of the split gateway, the outgoing sequence flows are associated withthe respective annotations.
The participants that cooperate in the context of a business process com-municate by sending and receiving messages. In business process diagrams,messages are represented by message flow. Typically a message flow connectsan activity of one participant to an activity or an event of another participant.
Depending on the kind of business process diagram (abstract or global),message flows can link pairs of flow objects, pools, and events. Detailed ruleson message flow connections are discussed below. “A Message Flow is used toshow the flow of messages between two participants that are prepared to sendand receive them. In BPMN, two separate Pools in the Diagram will representthe two participants (e.g., business entities or business roles).”
The notational elements of the BPMN regarding transactional behaviour ofbusiness processes (transaction groups, compensation flow, and cancellation)will not be covered, because their semantics is not laid out in su�cient detailand precision.
Events
Events play a central role in business process management, since they are theglue between situations in business organizations and processes that will be en-acted if these situations occur. Events in a business process can be partitionedinto three types, based on their position in the business process: start eventsare used to trigger processes, intermediate events can delay processes, or theycan occur during processes. End events signal the termination of processes.The notational elements for the event trigger types are shown in Figure 4.80.
Start
Intermediate
End
Termination
Message Timer Rule Error Link Multiple
Fig. 4.80. Event types in the BPMN, Object Management Group (2006)
Start events can have di↵erent triggers.
Zlecenie
Business Process Model and Notation, v2.0 261
Table 10.93 – Types of Events and their Markers
Types Start Intermediate EndTop-Level
EventSub-ProcessInterrupting
EventSub-ProcessNon-Interrupting
Catching BoundaryInterrupting
BoundaryNon-Interrupting
Throwing
None
Message
Timer
Error
Escalation
Cancel
Compensation
Conditional
Link
Signal
Terminate
Multiple
Business Process Model and Notation, v2.0 261
Table 10.93 – Types of Events and their Markers
Types Start Intermediate EndTop-Level
EventSub-ProcessInterrupting
EventSub-ProcessNon-Interrupting
Catching BoundaryInterrupting
BoundaryNon-Interrupting
Throwing
None
Message
Timer
Error
Escalation
Cancel
Compensation
Conditional
Link
Signal
Terminate
Multiple
Business Process Model and Notation, v2.0 261
Table 10.93 – Types of Events and their Markers
Types Start Intermediate EndTop-Level
EventSub-ProcessInterrupting
EventSub-ProcessNon-Interrupting
Catching BoundaryInterrupting
BoundaryNon-Interrupting
Throwing
None
Message
Timer
Error
Escalation
Cancel
Compensation
Conditional
Link
Signal
Terminate
Multiple
Business Process Model and Notation, v2.0 261
Table 10.93 – Types of Events and their Markers
Types Start Intermediate EndTop-Level
EventSub-ProcessInterrupting
EventSub-ProcessNon-Interrupting
Catching BoundaryInterrupting
BoundaryNon-Interrupting
Throwing
None
Message
Timer
Error
Escalation
Cancel
Compensation
Conditional
Link
Signal
Terminate
Multiple
Ocena wiarygodności
klienta
`$
Dzi
ał t
ransport
u
36 Business Process Model and Notation, v2.0
Data Object Data Objects provide information about what Activities require to be performed and/or what they produce (see page 205), Data Objects can represent a singular object or a collection of objects. Data Input and Data Output provide the same information for Processes.
Data Object
Data Objec (Collection)
Data Input Data Output
Message A Message is used to depict the contents of a communication between two Participants (as defined by a business PartnerRole or a business PartnerEntity—see on page 93).
Fork BPMN uses the term “fork” to refer to the dividing of a path into two or more parallel paths (also known as an AND-Split). It is a place in the Process where activities can be performed concurrently, rather than sequentially.
There are two options:
• Multiple Outgoing Sequence Flows can be used (see figure top-right). This represents “uncontrolled” flow is the preferred method for most situations.
• A Parallel Gateway can be used (see figure bottom-right). This will be used rarely, usually in combination with other Gateways.
Table 7.2 - BPMN Extended Modeling Elements
Odrzucenie zlecenia
36 Business Process Model and Notation, v2.0
Data Object Data Objects provide information about what Activities require to be performed and/or what they produce (see page 205), Data Objects can represent a singular object or a collection of objects. Data Input and Data Output provide the same information for Processes.
Data Object
Data Objec (Collection)
Data Input Data Output
Message A Message is used to depict the contents of a communication between two Participants (as defined by a business PartnerRole or a business PartnerEntity—see on page 93).
Fork BPMN uses the term “fork” to refer to the dividing of a path into two or more parallel paths (also known as an AND-Split). It is a place in the Process where activities can be performed concurrently, rather than sequentially.
There are two options:
• Multiple Outgoing Sequence Flows can be used (see figure top-right). This represents “uncontrolled” flow is the preferred method for most situations.
• A Parallel Gateway can be used (see figure bottom-right). This will be used rarely, usually in combination with other Gateways.
Table 7.2 - BPMN Extended Modeling Elements
Business Process Model and Notation, v2.0 161
Receive Task
A Receive Task is a simple Task that is designed to wait for a Message to arrive from an external Participant (relative to the Process). Once the Message has been received, the Task is completed.
The actual Participant from which the Message is received can be identified by connecting the Receive Task to a Participant using a Message Flows within the definitional Collaboration of the Process – see Table 10.1.
A Receive Task is often used to start a Process. In a sense, the Process is bootstrapped by the receipt of the Message. In order for the Receive Task to instantiate the Process its instantiate attribute MUST be set to true and it MUST NOT have any incoming Sequence Flow.
A Receive Task object shares the same shape as the Task, which is a rectangle that has rounded corners. However, there is an unfilled envelope marker (the same marker as a catch Message Event) in the upper left corner of the shape that indicates that the Task is a Receive Task.
A Receive Task is a rounded corner rectangle that MUST be drawn with a single thin line and includes an unfilled envelope marker that distinguishes the shape from other Task types (as shown in Figure 10.15). If the instantiate attribute is set to true, the envelope marker looks like a Message Start Event (as shown in Figure 10.16).
Figure 10.15 - A Receive Task Object
Table 10.9 – Send Task model associations
Attribute Name Description/Usage
messageRef: Message [0..1] A Message for the messageRef attribute MAY be entered. This indicates that the Message will be sent by the Task. The Message in this context is equivalent to an out-only message pattern (Web service). One or more corresponding outgoing Message Flows MAY be shown on the diagram. However, the display of the Message Flows is NOT REQUIRED. The Message is applied to all outgoing Message Flows and the Message will be sent down all outgoing Message Flows at the completion of a single instance of the Task.
operationRef: Operation This attribute specifies the operation that is invoked by the Send Task.
implementation: string = ##webService
This attribute specifies the technology that will be used to send and receive the Messages. Valid values are "##unspecified" for leaving the implementation technology open, "##WebService" for the Web service technology or a URI identifying any other technology or coordination protocol A Web service is the default technology.
160 Business Process Model and Notation, v2.0
A Send Task is a rounded corner rectangle that MUST be drawn with a single thin line and includes a filled envelope marker that distinguishes the shape from other Task types (as shown in Figure 10.13).
Figure 10.13 - A Send Task Object
Figure 10.14 - The Send Task and Receive Task class diagram
The Send Task inherits the attributes and model associations of Activity (see Table 10.3). In addition the following constraints apply when the Send Task references a Message: The Send Task has at most one inputSet and one Data Input. If the Data Input is present, it MUST have an ItemDefinition equivalent to the one defined by the associated Message. At execution time, when the Send Task is executed, the data automatically moves from the Data Input on the Send Task into the Message to be sent. If the Data Input is not present, the Message will not be populated with data from the Process.
Table 10.9 presents the additional model associations of the Send Task.
Zlecenie
4.7 Business Process Modeling Notation 209
Pool
Flow Objects
Events
Activities Place Order
Gateways
Connecting Objects
Sequence Flow
Message Flow
Association
Swimlanes
Lane
Data Object
Group
Artefacts
Annotation
Fig. 4.78. Business Process Modeling Notation: categories of elements
Since the goal of this example is to introduce the core elements, simplifica-tions are in place: the business process model provides a simplified view of howreview processes are actually conducted. In addition, there are many authorsand there are also many reviewers. For convenience, just one author and onereviewer are shown. As will be discussed below, situations in which multipleparticipants are involved in the same role cannot be covered conveniently.
The pools in this example represent roles and not concrete participants in abusiness process. Each role at run time has multiple concrete participants whoare actually involved in the business process instance. The BPMN standardindicates that “a pool represents a participant in a process. It is also acts as a“swimlane” and a graphical container for partitioning a set of activities fromother pools, usually in the context of B2B situations.”
The process starts when the PC Chair is asked to organize the scientificprogram of a conference. This is reflected by the start event of the process atthe PC Chair. An event is something that ‘happens’ during the course of abusiness process. These events a↵ect the flow of the process and usually havea cause (trigger) or an impact (result). Events are circles with open centresto allow internal markers to di↵erentiate di↵erent triggers or results.”
The activity enacted first is the publication of a call for papers with de-tailed information on the conference, such as name and location, and alsoinformation regarding the topics addressed by the conference. The receipt ofa message can be an event that is relevant for the process. This concept isused in the sample process when the published call for papers activity sendsa message that the author receives. Receiving this message is represented bythe start event of the author process. The cause of this event is receiving the
Business Process Model and Notation, v2.0 163
User Task
A User Task is a typical “workflow” Task where a human performer performs the Task with the assistance of a software application and is scheduled through a task list manager of some sort.
A User Task is a rounded corner rectangle that MUST be drawn with a single thin line and includes a human figure marker that distinguishes the shape from other Task types (as shown in Figure 10.17).
Figure 10.17 - A User Task Object
See “User Task” on page 163 within the larger section of “Human Interactions” for the details of User Tasks.
Manual Task
A Manual Task is a Task that is expected to be performed without the aid of any business process execution engine or any application. An example of this could be a telephone technician installing a telephone at a customer location.
A Manual Task is a rounded corner rectangle that MUST be drawn with a single thin line and includes a hand figure marker that distinguishes the shape from other Task types (as shown in Figure 10.17).
Figure 10.18 - A Manual Task Object
See “Manual Task” on page 165 within the larger section of “Human Interactions” for the details of Manual Tasks.
Business Rule
A Business Rule Task provides a mechanism for the Process to provide input to a Business Rules Engine and to get the output of calculations that the Business Rules Engine might provide. The InputOutputSpecification of the Task (see page 211) will allow the Process to send data to and receive data from the Business Rules Engine.
A Business Rule Task object shares the same shape as the Task, which is a rectangle that has rounded corners. However, there is a graphical marker in the upper left corner of the shape that indicates that the Task is a Business Rule Task (see Figure 10.11).
Business Process Model and Notation, v2.0 163
User Task
A User Task is a typical “workflow” Task where a human performer performs the Task with the assistance of a software application and is scheduled through a task list manager of some sort.
A User Task is a rounded corner rectangle that MUST be drawn with a single thin line and includes a human figure marker that distinguishes the shape from other Task types (as shown in Figure 10.17).
Figure 10.17 - A User Task Object
See “User Task” on page 163 within the larger section of “Human Interactions” for the details of User Tasks.
Manual Task
A Manual Task is a Task that is expected to be performed without the aid of any business process execution engine or any application. An example of this could be a telephone technician installing a telephone at a customer location.
A Manual Task is a rounded corner rectangle that MUST be drawn with a single thin line and includes a hand figure marker that distinguishes the shape from other Task types (as shown in Figure 10.17).
Figure 10.18 - A Manual Task Object
See “Manual Task” on page 165 within the larger section of “Human Interactions” for the details of Manual Tasks.
Business Rule
A Business Rule Task provides a mechanism for the Process to provide input to a Business Rules Engine and to get the output of calculations that the Business Rules Engine might provide. The InputOutputSpecification of the Task (see page 211) will allow the Process to send data to and receive data from the Business Rules Engine.
A Business Rule Task object shares the same shape as the Task, which is a rectangle that has rounded corners. However, there is a graphical marker in the upper left corner of the shape that indicates that the Task is a Business Rule Task (see Figure 10.11).
System dyspozytorski
Baza klientów
Ocena możliwości
warunkowego
przyjęcia zlec.
164 Business Process Model and Notation, v2.0
A Business Rule Task is a rounded corner rectangle that MUST be drawn with a single thin line and includes a marker that distinguishes the shape from other Task types (as shown in Figure 10.19).
Figure 10.19 - A Business Rule Task Object
The Business Rule Task inherits the attributes and model associations of Activity (see Table 10.3). Table 10.11 presents the additional attributes of the Business Rule Task.
Script Task
A Script Task is executed by a business process engine. The modeler or implementer defines a script in a language that the engine can interpret. When the Task is ready to start, the engine will execute the script. When the script is completed, the Task will also be completed.
A Script Task object shares the same shape as the Task, which is a rectangle that has rounded corners. However, there is a graphical marker in the upper left corner of the shape that indicates that the Task is a Script Task (see Figure 10.11).
A Script Task is a rounded corner rectangle that MUST be drawn with a single thin line and includes a marker that distinguishes the shape from other Task types (as shown in Figure 10.20).
Figure 10.20 - A Script Task Object
Table 10.11 – Business Rule Task attributes and model associations
Attribute Name Description/Usage
implementation: string = ##unspecified
This attribute specifies the technology that will be used to implement the Business Rule Task. Valid values are "##unspecified" for leaving the implementation technology open, "##WebService" for the Web service technology or a URI identifying any other technology or coordination protocol. The default technology for this task is unspecified.
Warunkowo przyjęto zlecenie
do realizacji
Business Process Model and Notation, v2.0 261
Table 10.93 – Types of Events and their Markers
Types Start Intermediate EndTop-Level
EventSub-ProcessInterrupting
EventSub-ProcessNon-Interrupting
Catching BoundaryInterrupting
BoundaryNon-Interrupting
Throwing
None
Message
Timer
Error
Escalation
Cancel
Compensation
Conditional
Link
Signal
Terminate
Multiple
Brak możliwości realizacji zlecenia
Business Process Model and Notation, v2.0 261
Table 10.93 – Types of Events and their Markers
Types Start Intermediate EndTop-Level
EventSub-ProcessInterrupting
EventSub-ProcessNon-Interrupting
Catching BoundaryInterrupting
BoundaryNon-Interrupting
Throwing
None
Message
Timer
Error
Escalation
Cancel
Compensation
Conditional
Link
Signal
Terminate
Multiple
Business Process Model and Notation, v2.0 261
Table 10.93 – Types of Events and their Markers
Types Start Intermediate EndTop-Level
EventSub-ProcessInterrupting
EventSub-ProcessNon-Interrupting
Catching BoundaryInterrupting
BoundaryNon-Interrupting
Throwing
None
Message
Timer
Error
Escalation
Cancel
Compensation
Conditional
Link
Signal
Terminate
Multiple
Zbyt długi okres oczekiwania na wolny pojazd
!14!
Rys. 2.9. Model procesu weryfikacji i przydziału zlecenia przewozowego do realizacji, opisany w notacji BPMN v.2.0 (po korektach)
Zax $$
Dyspozy
tor
Wpłynęło zlecenie
na pojazd 32EUR
Wpłynęło zlecenie na
pojazd do18EUR
Wprowadzanie
zlecenia do systemu
Odmowa realizacji
zlecenia
Przydzielanie zamówienia do
pojazdu
Spedyto
r
Brak zaległości
Stwierdzone zaległości
`$Zlecenie
przydzielone do pojazdu
Poinformowano klienta o braku
możliwości realizacji zlecenia
Dostępne pojazdy
Chwilowy brak wolnych pojazdów
Za$
Klie
nt
4.7 Business Process Modeling Notation 211
final version of the paper that will be printed in the conference proceedings.In case the paper is rejected, the join gateway is triggered. To clarify the be-haviour of the split gateway, the outgoing sequence flows are associated withthe respective annotations.
The participants that cooperate in the context of a business process com-municate by sending and receiving messages. In business process diagrams,messages are represented by message flow. Typically a message flow connectsan activity of one participant to an activity or an event of another participant.
Depending on the kind of business process diagram (abstract or global),message flows can link pairs of flow objects, pools, and events. Detailed ruleson message flow connections are discussed below. “A Message Flow is used toshow the flow of messages between two participants that are prepared to sendand receive them. In BPMN, two separate Pools in the Diagram will representthe two participants (e.g., business entities or business roles).”
The notational elements of the BPMN regarding transactional behaviour ofbusiness processes (transaction groups, compensation flow, and cancellation)will not be covered, because their semantics is not laid out in su�cient detailand precision.
Events
Events play a central role in business process management, since they are theglue between situations in business organizations and processes that will be en-acted if these situations occur. Events in a business process can be partitionedinto three types, based on their position in the business process: start eventsare used to trigger processes, intermediate events can delay processes, or theycan occur during processes. End events signal the termination of processes.The notational elements for the event trigger types are shown in Figure 4.80.
Start
Intermediate
End
Termination
Message Timer Rule Error Link Multiple
Fig. 4.80. Event types in the BPMN, Object Management Group (2006)
Start events can have di↵erent triggers.
4.7 Business Process Modeling Notation 211
final version of the paper that will be printed in the conference proceedings.In case the paper is rejected, the join gateway is triggered. To clarify the be-haviour of the split gateway, the outgoing sequence flows are associated withthe respective annotations.
The participants that cooperate in the context of a business process com-municate by sending and receiving messages. In business process diagrams,messages are represented by message flow. Typically a message flow connectsan activity of one participant to an activity or an event of another participant.
Depending on the kind of business process diagram (abstract or global),message flows can link pairs of flow objects, pools, and events. Detailed ruleson message flow connections are discussed below. “A Message Flow is used toshow the flow of messages between two participants that are prepared to sendand receive them. In BPMN, two separate Pools in the Diagram will representthe two participants (e.g., business entities or business roles).”
The notational elements of the BPMN regarding transactional behaviour ofbusiness processes (transaction groups, compensation flow, and cancellation)will not be covered, because their semantics is not laid out in su�cient detailand precision.
Events
Events play a central role in business process management, since they are theglue between situations in business organizations and processes that will be en-acted if these situations occur. Events in a business process can be partitionedinto three types, based on their position in the business process: start eventsare used to trigger processes, intermediate events can delay processes, or theycan occur during processes. End events signal the termination of processes.The notational elements for the event trigger types are shown in Figure 4.80.
Start
Intermediate
End
Termination
Message Timer Rule Error Link Multiple
Fig. 4.80. Event types in the BPMN, Object Management Group (2006)
Start events can have di↵erent triggers.
Zlecenie
Business Process Model and Notation, v2.0 261
Table 10.93 – Types of Events and their Markers
Types Start Intermediate EndTop-Level
EventSub-ProcessInterrupting
EventSub-ProcessNon-Interrupting
Catching BoundaryInterrupting
BoundaryNon-Interrupting
Throwing
None
Message
Timer
Error
Escalation
Cancel
Compensation
Conditional
Link
Signal
Terminate
Multiple
Business Process Model and Notation, v2.0 261
Table 10.93 – Types of Events and their Markers
Types Start Intermediate EndTop-Level
EventSub-ProcessInterrupting
EventSub-ProcessNon-Interrupting
Catching BoundaryInterrupting
BoundaryNon-Interrupting
Throwing
None
Message
Timer
Error
Escalation
Cancel
Compensation
Conditional
Link
Signal
Terminate
Multiple
Business Process Model and Notation, v2.0 261
Table 10.93 – Types of Events and their Markers
Types Start Intermediate EndTop-Level
EventSub-ProcessInterrupting
EventSub-ProcessNon-Interrupting
Catching BoundaryInterrupting
BoundaryNon-Interrupting
Throwing
None
Message
Timer
Error
Escalation
Cancel
Compensation
Conditional
Link
Signal
Terminate
Multiple
Business Process Model and Notation, v2.0 261
Table 10.93 – Types of Events and their Markers
Types Start Intermediate EndTop-Level
EventSub-ProcessInterrupting
EventSub-ProcessNon-Interrupting
Catching BoundaryInterrupting
BoundaryNon-Interrupting
Throwing
None
Message
Timer
Error
Escalation
Cancel
Compensation
Conditional
Link
Signal
Terminate
Multiple
Ocena wiarygodności
klienta
`$
Dzi
ał t
ransport
u
36 Business Process Model and Notation, v2.0
Data Object Data Objects provide information about what Activities require to be performed and/or what they produce (see page 205), Data Objects can represent a singular object or a collection of objects. Data Input and Data Output provide the same information for Processes.
Data Object
Data Objec (Collection)
Data Input Data Output
Message A Message is used to depict the contents of a communication between two Participants (as defined by a business PartnerRole or a business PartnerEntity—see on page 93).
Fork BPMN uses the term “fork” to refer to the dividing of a path into two or more parallel paths (also known as an AND-Split). It is a place in the Process where activities can be performed concurrently, rather than sequentially.
There are two options:
• Multiple Outgoing Sequence Flows can be used (see figure top-right). This represents “uncontrolled” flow is the preferred method for most situations.
• A Parallel Gateway can be used (see figure bottom-right). This will be used rarely, usually in combination with other Gateways.
Table 7.2 - BPMN Extended Modeling Elements
Odrzucenie zlecenia
36 Business Process Model and Notation, v2.0
Data Object Data Objects provide information about what Activities require to be performed and/or what they produce (see page 205), Data Objects can represent a singular object or a collection of objects. Data Input and Data Output provide the same information for Processes.
Data Object
Data Objec (Collection)
Data Input Data Output
Message A Message is used to depict the contents of a communication between two Participants (as defined by a business PartnerRole or a business PartnerEntity—see on page 93).
Fork BPMN uses the term “fork” to refer to the dividing of a path into two or more parallel paths (also known as an AND-Split). It is a place in the Process where activities can be performed concurrently, rather than sequentially.
There are two options:
• Multiple Outgoing Sequence Flows can be used (see figure top-right). This represents “uncontrolled” flow is the preferred method for most situations.
• A Parallel Gateway can be used (see figure bottom-right). This will be used rarely, usually in combination with other Gateways.
Table 7.2 - BPMN Extended Modeling Elements
Business Process Model and Notation, v2.0 161
Receive Task
A Receive Task is a simple Task that is designed to wait for a Message to arrive from an external Participant (relative to the Process). Once the Message has been received, the Task is completed.
The actual Participant from which the Message is received can be identified by connecting the Receive Task to a Participant using a Message Flows within the definitional Collaboration of the Process – see Table 10.1.
A Receive Task is often used to start a Process. In a sense, the Process is bootstrapped by the receipt of the Message. In order for the Receive Task to instantiate the Process its instantiate attribute MUST be set to true and it MUST NOT have any incoming Sequence Flow.
A Receive Task object shares the same shape as the Task, which is a rectangle that has rounded corners. However, there is an unfilled envelope marker (the same marker as a catch Message Event) in the upper left corner of the shape that indicates that the Task is a Receive Task.
A Receive Task is a rounded corner rectangle that MUST be drawn with a single thin line and includes an unfilled envelope marker that distinguishes the shape from other Task types (as shown in Figure 10.15). If the instantiate attribute is set to true, the envelope marker looks like a Message Start Event (as shown in Figure 10.16).
Figure 10.15 - A Receive Task Object
Table 10.9 – Send Task model associations
Attribute Name Description/Usage
messageRef: Message [0..1] A Message for the messageRef attribute MAY be entered. This indicates that the Message will be sent by the Task. The Message in this context is equivalent to an out-only message pattern (Web service). One or more corresponding outgoing Message Flows MAY be shown on the diagram. However, the display of the Message Flows is NOT REQUIRED. The Message is applied to all outgoing Message Flows and the Message will be sent down all outgoing Message Flows at the completion of a single instance of the Task.
operationRef: Operation This attribute specifies the operation that is invoked by the Send Task.
implementation: string = ##webService
This attribute specifies the technology that will be used to send and receive the Messages. Valid values are "##unspecified" for leaving the implementation technology open, "##WebService" for the Web service technology or a URI identifying any other technology or coordination protocol A Web service is the default technology.
160 Business Process Model and Notation, v2.0
A Send Task is a rounded corner rectangle that MUST be drawn with a single thin line and includes a filled envelope marker that distinguishes the shape from other Task types (as shown in Figure 10.13).
Figure 10.13 - A Send Task Object
Figure 10.14 - The Send Task and Receive Task class diagram
The Send Task inherits the attributes and model associations of Activity (see Table 10.3). In addition the following constraints apply when the Send Task references a Message: The Send Task has at most one inputSet and one Data Input. If the Data Input is present, it MUST have an ItemDefinition equivalent to the one defined by the associated Message. At execution time, when the Send Task is executed, the data automatically moves from the Data Input on the Send Task into the Message to be sent. If the Data Input is not present, the Message will not be populated with data from the Process.
Table 10.9 presents the additional model associations of the Send Task.
Zlecenie
4.7 Business Process Modeling Notation 209
Pool
Flow Objects
Events
Activities Place Order
Gateways
Connecting Objects
Sequence Flow
Message Flow
Association
Swimlanes
Lane
Data Object
Group
Artefacts
Annotation
Fig. 4.78. Business Process Modeling Notation: categories of elements
Since the goal of this example is to introduce the core elements, simplifica-tions are in place: the business process model provides a simplified view of howreview processes are actually conducted. In addition, there are many authorsand there are also many reviewers. For convenience, just one author and onereviewer are shown. As will be discussed below, situations in which multipleparticipants are involved in the same role cannot be covered conveniently.
The pools in this example represent roles and not concrete participants in abusiness process. Each role at run time has multiple concrete participants whoare actually involved in the business process instance. The BPMN standardindicates that “a pool represents a participant in a process. It is also acts as a“swimlane” and a graphical container for partitioning a set of activities fromother pools, usually in the context of B2B situations.”
The process starts when the PC Chair is asked to organize the scientificprogram of a conference. This is reflected by the start event of the process atthe PC Chair. An event is something that ‘happens’ during the course of abusiness process. These events a↵ect the flow of the process and usually havea cause (trigger) or an impact (result). Events are circles with open centresto allow internal markers to di↵erentiate di↵erent triggers or results.”
The activity enacted first is the publication of a call for papers with de-tailed information on the conference, such as name and location, and alsoinformation regarding the topics addressed by the conference. The receipt ofa message can be an event that is relevant for the process. This concept isused in the sample process when the published call for papers activity sendsa message that the author receives. Receiving this message is represented bythe start event of the author process. The cause of this event is receiving the
Business Process Model and Notation, v2.0 163
User Task
A User Task is a typical “workflow” Task where a human performer performs the Task with the assistance of a software application and is scheduled through a task list manager of some sort.
A User Task is a rounded corner rectangle that MUST be drawn with a single thin line and includes a human figure marker that distinguishes the shape from other Task types (as shown in Figure 10.17).
Figure 10.17 - A User Task Object
See “User Task” on page 163 within the larger section of “Human Interactions” for the details of User Tasks.
Manual Task
A Manual Task is a Task that is expected to be performed without the aid of any business process execution engine or any application. An example of this could be a telephone technician installing a telephone at a customer location.
A Manual Task is a rounded corner rectangle that MUST be drawn with a single thin line and includes a hand figure marker that distinguishes the shape from other Task types (as shown in Figure 10.17).
Figure 10.18 - A Manual Task Object
See “Manual Task” on page 165 within the larger section of “Human Interactions” for the details of Manual Tasks.
Business Rule
A Business Rule Task provides a mechanism for the Process to provide input to a Business Rules Engine and to get the output of calculations that the Business Rules Engine might provide. The InputOutputSpecification of the Task (see page 211) will allow the Process to send data to and receive data from the Business Rules Engine.
A Business Rule Task object shares the same shape as the Task, which is a rectangle that has rounded corners. However, there is a graphical marker in the upper left corner of the shape that indicates that the Task is a Business Rule Task (see Figure 10.11).
Business Process Model and Notation, v2.0 163
User Task
A User Task is a typical “workflow” Task where a human performer performs the Task with the assistance of a software application and is scheduled through a task list manager of some sort.
A User Task is a rounded corner rectangle that MUST be drawn with a single thin line and includes a human figure marker that distinguishes the shape from other Task types (as shown in Figure 10.17).
Figure 10.17 - A User Task Object
See “User Task” on page 163 within the larger section of “Human Interactions” for the details of User Tasks.
Manual Task
A Manual Task is a Task that is expected to be performed without the aid of any business process execution engine or any application. An example of this could be a telephone technician installing a telephone at a customer location.
A Manual Task is a rounded corner rectangle that MUST be drawn with a single thin line and includes a hand figure marker that distinguishes the shape from other Task types (as shown in Figure 10.17).
Figure 10.18 - A Manual Task Object
See “Manual Task” on page 165 within the larger section of “Human Interactions” for the details of Manual Tasks.
Business Rule
A Business Rule Task provides a mechanism for the Process to provide input to a Business Rules Engine and to get the output of calculations that the Business Rules Engine might provide. The InputOutputSpecification of the Task (see page 211) will allow the Process to send data to and receive data from the Business Rules Engine.
A Business Rule Task object shares the same shape as the Task, which is a rectangle that has rounded corners. However, there is a graphical marker in the upper left corner of the shape that indicates that the Task is a Business Rule Task (see Figure 10.11).
System dyspozytorski
Baza klientów
Ocena możliwości
warunkowego
przyjęcia zlec.
164 Business Process Model and Notation, v2.0
A Business Rule Task is a rounded corner rectangle that MUST be drawn with a single thin line and includes a marker that distinguishes the shape from other Task types (as shown in Figure 10.19).
Figure 10.19 - A Business Rule Task Object
The Business Rule Task inherits the attributes and model associations of Activity (see Table 10.3). Table 10.11 presents the additional attributes of the Business Rule Task.
Script Task
A Script Task is executed by a business process engine. The modeler or implementer defines a script in a language that the engine can interpret. When the Task is ready to start, the engine will execute the script. When the script is completed, the Task will also be completed.
A Script Task object shares the same shape as the Task, which is a rectangle that has rounded corners. However, there is a graphical marker in the upper left corner of the shape that indicates that the Task is a Script Task (see Figure 10.11).
A Script Task is a rounded corner rectangle that MUST be drawn with a single thin line and includes a marker that distinguishes the shape from other Task types (as shown in Figure 10.20).
Figure 10.20 - A Script Task Object
Table 10.11 – Business Rule Task attributes and model associations
Attribute Name Description/Usage
implementation: string = ##unspecified
This attribute specifies the technology that will be used to implement the Business Rule Task. Valid values are "##unspecified" for leaving the implementation technology open, "##WebService" for the Web service technology or a URI identifying any other technology or coordination protocol. The default technology for this task is unspecified.
Warunkowo przyjęto zlecenie
do realizacji
Business Process Model and Notation, v2.0 261
Table 10.93 – Types of Events and their Markers
Types Start Intermediate EndTop-Level
EventSub-ProcessInterrupting
EventSub-ProcessNon-Interrupting
Catching BoundaryInterrupting
BoundaryNon-Interrupting
Throwing
None
Message
Timer
Error
Escalation
Cancel
Compensation
Conditional
Link
Signal
Terminate
Multiple
Brak możliwości realizacji zlecenia
Business Process Model and Notation, v2.0 261
Table 10.93 – Types of Events and their Markers
Types Start Intermediate EndTop-Level
EventSub-ProcessInterrupting
EventSub-ProcessNon-Interrupting
Catching BoundaryInterrupting
BoundaryNon-Interrupting
Throwing
None
Message
Timer
Error
Escalation
Cancel
Compensation
Conditional
Link
Signal
Terminate
Multiple
Business Process Model and Notation, v2.0 261
Table 10.93 – Types of Events and their Markers
Types Start Intermediate EndTop-Level
EventSub-ProcessInterrupting
EventSub-ProcessNon-Interrupting
Catching BoundaryInterrupting
BoundaryNon-Interrupting
Throwing
None
Message
Timer
Error
Escalation
Cancel
Compensation
Conditional
Link
Signal
Terminate
Multiple
Zbyt długi okres oczekiwania na wolny pojazd
Piotr Sawicki | Zarządzanie procesami
Piotr Sawicki | Zarządzanie procesami
Politechnika Poznańska | WILiT | IT | ZST 12
23
Jak to zrobić … w ARIS?
Piotr Sawicki | Zarządzanie procesami
|Symulacja procesu|Modelowanie procesu
https://youtu.be/N6A2pH2rHCE https://youtu.be/5lyXzBmdQUU
23
Jak to zrobić … w ARIS?
Piotr Sawicki | Zarządzanie procesami
|Symulacja procesu|Modelowanie procesu
https://youtu.be/N6A2pH2rHCE https://youtu.be/5lyXzBmdQUU
24
Jak to zrobić … w ARIS?
Piotr Sawicki | Zarządzanie procesami
|Symulacja procesu
Piotr Sawicki | Zarządzanie procesami
Politechnika Poznańska | WILiT | IT | ZST 13
26
àWILiT PP jest partnerem w programie ARIS Community• Studenci mają darmowo do
dyspozycji 100 licencji na ARIS Architect & Designer
• Warunek skorzystania– rejestracja na stronie
ariscommunity.com i posiadanie adresu e-mailowego z domeną put.poznan.pl
– licencja ważna jest na 1 rok
– zastosowanie wyłącznie dydaktyczne
Dostępność narzędzia ARIS
Piotr Sawicki | Zarządzanie procesami
27
Dostępność narzędzia ARIS
Piotr Sawicki | Zarządzanie procesami
ariscommunity.com
Piotr Sawicki | Zarządzanie procesami
Politechnika Poznańska | WILiT | IT | ZST 14
28
Mela o N., Pidd M., A conceptual framework for under-standing business process and business process modeling. Information System Journal, 2000, vol. 10, no. 2, s.105-129.
Object Management Group, Business process model and notation (BPMN) – Version 2.0, January 2011, http://www.omg.org/spec/BPMN/2.0 (doste p: 08.02.2013)
Sawicki P., Wielokryterialna optymalizacja procesów w trans-porcie. ITE, Radom, 2013
Scheer A.W., ARIS - Business Process Frameworks, Berlin, Springer-Verlag, 1999.
Weske M., Business Process Management. Concepts, Languages, Architectures. Springer-Verlag Berlin Heidelberg, 2012
BibliografiaPodsumowanie
Piotr Sawicki | Zarządzanie procesami
29
Bibliografia – materiały wykładoweŹródła wiedzy
Piotr Sawicki | Zarządzanie procesami
Sawicki P.
http://piotr.sawicki.pracownik.put.poznan.pl
Piotr Sawicki | Zarządzanie procesami
Politechnika Poznańska | WILiT | IT | ZST 15
30
Scheer A.-W.
ARIS – Business Process ModelingSpringer, 2000
BibliografiaŹródła wiedzy
Davis R., Brabänder E.
ARIS Design Platform. Getting started with BPMSpringer, 2010
Piotr Sawicki | Zarządzanie procesami
31
Weske M.,
Business Process Management.Concepts, Languages, ArchitecturesSpringer, 2012
BibliografiaŹródła wiedzy
Scheer A-W., Abolhassan R.,Jost W., Kirchmer M.
Business Process Excellence. ARIS in PracticeSpringer, 2004
Piotr Sawicki | Zarządzanie procesami
Piotr Sawicki | Zarządzanie procesami
Politechnika Poznańska | WILiT | IT | ZST 16
32
Gabryelczyk R.
ARIS w modelowaniu procesówbiznesuDifin, 2010
BibliografiaŹródła wiedzy
Sawicki P.
Wielokryterialna optymalizacja procesów w transporcieITE, Radom, 2013
WIELOKRYTERIALNA OPTYMALIZACJA
PROCESÓW W TRANSPORCIE
ISBN 978-83-7789-222-0
Piotr SAWICKI
WIELOKRYTERIALNA OPTYM
ALIZACJA PROCESÓW W
TRANSPORCIEPiotr SAW
ICKI
studiai
rozprawy
Piotr Sawicki | Zarządzanie procesami
33
Zapraszam do dyskusji i zadawania pytańPodsumowanie
Piotr Sawicki | Zarządzanie procesami
Piotr Sawicki | Zarządzanie procesami
Politechnika Poznańska | WILiT | IT | ZST 17
00Tytuł:
WprowadzenieKluczowe elementy BPM
Przedmiot:
Zarządzanie procesami transportowo-logistycznymiSpecjalność:
Logistyka transportuWersja:
2020.03.03
Autor:
Piotr SAWICKI, dr hab. inżZakład Systemów Transportowych | WILiT | PPpiotr.sawicki@put.poznan.pl piotr.sawicki.pracownik.www.put.poznan.plwww.facebook.com/Piotr.Sawicki.PUT
top related