Zdarzenia początkowe w notacji BPMN 2.0

Odkryj znaczenie zdarzeń w notacji BPMN 2.0 i ich wpływ na procesy biznesowe
Karol Marciniak
Zdarzenia początkowe w notacji BPMN 2.0

Zdarzenia w notacji BPMN 2.0 to kluczowy element standardu pozwalający na graficzne przedstawienie i zdefiniowanie sytuacji mającej wpływ na rozpoczęcie procesu biznesowego.

Artykuł przedstawia analizę zdarzeń początkowych najwyższego rzędu w notacji BPMN 2.0, skupiając się na ich znaczeniu i wpływie na przebieg procesów biznesowych. W kolejnej części opracowania omówione zostaną pozostałe typy zdarzeń początkowych

W notacji BPMN 2.0 wyróżniamy trzy główne typy zdarzeń:

1.     Zdarzenia początkowe – rozpoczynają, inicjują proces biznesowy. Rozpoczęcie procesu uwarunkowane jest urzeczywistnieniem sytuacji (np. spełnienie warunku, otrzymanie wiadomości;

2.     Zdarzenia pośrednie – oznaczają sytuacje występujące w trakcie procesu (np. upływ czasu, spełnienie się określonego warunku)

3.     Zdarzenia końcowe – oznaczają wystąpienie sytuacji będące zakończeniem procesu (np. przesłanie wiadomości, spełnienie określonego warunku)

Zdarzenia początkowe mogą określać rozpoczęcia procesów na różnych poziomach:

1.     Procesów głównego poziomu;

2.     Zagnieżdżonych podprocesów;

3.     Podprocesów zdarzeniowych.

W poniższym artykule omówię specyfikę i rodzaje określonych w standardzie BPMN 2.0 zdarzeń początkowych procesów głównego poziomu.

Zdarzenia początkowe dla procesów nadrzędnych reprezentowane są symbolem okręgu z pojedynczą linią ciągłą.


Zdarzenie nieokreślone

Jeśli chcemy zaznaczyć rozpoczęcie procesu nie wskazując na konkretny typ zdarzenia (wyzwalacza) inicjującego proces możliwe jest zastosowanie zdarzenia początkowego nieokreślonego (Rysunek nr 1).


Zdarzenie Komunikat

Zdarzenie Komunikat jest reprezentacją sytuacji, w której proces inicjowany jest w momencie otrzymania określonej wiadomości (komunikatu) od uczestnika procesu. W zależności od przyjętej konwencji modelowania i tworzonej mapy, proces inicjowany komunikatem może być pokazany jako odrębny, autonomiczny proces (Rysunek nr 2) lub jako proces, który rozpoczyna się w momencie przechwycenia komunikatu wpływającego z innego procesu (Rysunek nr 3). Przy zastosowaniu takiej konwencji możemy pokazać powiązania między innymi basenami pokazywanymi na mapie.

Na rysunku nr 2 przedstawiono zastosowanie zdarzenia początkowego inicjującego proces po stronie serwisu. Z tej prostej mapy wynika, że rozpoczęcie procesu następuje w momencie wpłynięcia zlecenia przeprowadzenia przeglądu. W tej konwencji nie koncentrujemy się na źródle tego komunikatu a tylko na fakcie jego wpłynięcia, który powoduje inicjację procesu.

Rysunek nr 2 Przykład procesu rozpoczynającego się zdarzeniem początkowym „Komunikat”.


Na kolejnej mapie procesu mamy do czynienia z diagramem komunikacji (Rysunek nr 3). Pokazujemy realizację procesu w szerszym kontekście z uwzględnieniem dwóch uczestników – Klienta i Serwisu. De facto mamy do czynienia z dwoma realizowanymi procesami. Proces realizowany przez serwis jest wyzwalany w momencie przechwycenia komunikatu od Klienta.

Rysunek nr 3 Przykład procesu rozpoczynającego się zdarzeniem początkowym „Komunikat” – diagram komunikacji


Na przykładzie powyższego procesu Klient w trakcie korzystania z maszyny może wysłać komunikat do serwisu o potrzebie realizacji zgłoszenia (jest to zobrazowane zdarzeniem pośrednim granicznym typu „timer” nieprzerywającym realizacji zadania, do którego jest ono dołączone– zgodnie ze standardem BPMN 2.0 jest ono reprezentowane ikoną kółka z przerywaną podwójną obwolutą), gdy zostanie wysłany komunikat jest on jednocześnie odbierany i staje się wyzwalaczem procesu zapoczątkowanego po stronie serwisu.

Zdarzenie sygnał

Zdarzenie początkowe typu sygnał inicjuje proces w momencie wychwycenia sygnału pochodzącego z zewnątrz, od uczestnika procesu. Sygnał może być przechwytywany przez więcej niż jednego uczestnika procesu, może więc inicjować więcej niż jeden proces. I to odróżnia ten typ zdarzenia od zdarzenia typu komunikat. Ten drugi jest kierowany do konkretnego odbiorcy, podczas gdy sygnał jest wysyłany „w eter” i może być inicjatorem wielu procesów.

Rysunek nr 4 ilustruje przykład prostego procesu wykorzystującego zdarzenie typu sygnał. Proces dotyczy działania systemu alarmowego. W momencie naruszenia czujników ruchu emitowany jest sygnał – „Powiadomienie o włamaniu”.

Sygnał ten jest przechwytywany i inicjuje procesy realizowane przez 3 kolejnych uczestników: administratora budynku, właściciela lokalu i firmy ochroniarskiej. Sygnał więc jest aktywatorem trzech niezależnych procesów.

Rysunek nr 4 Przykład procesu rozpoczynającego się zdarzeniem początkowym „Sygnał”  


Zdarzenie początkowe czasowe (timer)

Zdarzenie początkowe czasowe inicjuje proces w momencie nastąpienia określonego momentu w czasie. Może to być np. konkretna godzina, termin lub wyrażenie oznaczające cykl.

Poniższy przykład  (Rysunek nr 5) ilustruje proces działania wentylatora. Wentylator załączany jest co dwie godziny. Po 20 minutach działania następuje wyłączenie wentylatora.

Rysunek nr 5 Przykład procesu rozpoczynającego się zdarzeniem początkowym „Timer”  


Rysunek nr 6 pokazuje z kolei proces inicjowany 5 dnia każdego miesiąca. Można założyć, że mamy do czynienia z procesem księgowania dokumentów przez system na podstawie danych otrzymanych od Klienta. System, 5 dnia każdego miesiąca wysyła powiadomienie o potrzebie dostarczenia dokumentów. Następnie po 48 godzinach sprawdzany jest warunek „Czy dostarczono dokumenty?”. Jeśli tak proces zostaje zakończony, jeśli nie proces się zapętla i wysyłane jest kolejne powiadomienie.

Rysunek nr 6 Przykład procesu rozpoczynającego się zdarzeniem początkowym „Timer”  


Zdarzenie początkowe warunek

Zdarzenie początkowe typu warunek inicjuje proces w momencie spełniania się określonej sytuacji określonej wyrażeniem.

Zgodnie z poniższym przykładem (Rysunek nr 7) w momencie spełnienia się warunku dotyczącego podniesienia się temperatury do 24 stopni proces zostaje aktywowany i następuje włączenie klimatyzacji. Gdy w trakcie chłodzenia temperatura w pomieszczeniu spadnie do 22 stopni klimatyzator jest wyłączany.

Rysunek nr 7 Przykład procesu rozpoczynającego się zdarzeniem początkowym „Warunek”


W kolejnym przykładzie mamy do czynienia z prostym procesem realizacji zamówienia. Proces jest ten inicjowany w momencie spełnienia warunku „Zamówienie potwierdzone”. Gdy to twierdzenie okaże się prawdziwe proces jest uruchamiany i następuje realizacja określonej sekwencji zadań.

Rysunek nr 8 Przykład procesu rozpoczynającego się zdarzeniem początkowym „Warunek”  


Podkreślić należy, że notacja BPMN 2.0 daje nam szerokie możliwości wyboru określonych elementów notacji do przedstawienia procesu z perspektywy istotnego dla nas kontekstu.

Na tym przykładzie zastosowano zdarzenie początkowe typu warunek. Proces koncentruje się zatem na fakcie spełnienia określonego warunku.

Gdybyśmy chcieli podkreślić, że to potwierdzenie zamówienie pochodzi od innego konkretnego uczestnika procesu (np. potwierdzenie mailowe) moglibyśmy zastosować np. zdarzenie początkowe typu komunikat (Rysunek nr 9).

Rysunek nr 9 Przykład procesu rozpoczynającego się zdarzeniem początkowym „Komunikat”  


Natomiast jeśli chcielibyśmy podkreślić, że gdzieś w innym procesie nastąpiło potwierdzenie zamówienia, co inicjuje procesy kilku uczestników to poprawnym byłoby również zastosowanie zdarzenia początkowego typu sygnał (Rysunek nr 10).

Rysunek nr 10 Przykład procesu rozpoczynającego się zdarzeniem początkowym „Sygnał”  


Zgodnie z logiką procesu Klient potwierdzając zamówienie wysyła sygnał (nieskierowany do konkretnie jednego uczestnika), który odbierany i inicjuje procesy realizowane przez uczestników procesu:

1.     Sklep – gdzie rozpoczyna się proces realizacji zamówienia;

2.     Księgowość – gdzie następuje  proces przygotowania dokumentów księgowych;

3.     Marketing – gdzie następuje przygotowanie oferty lojalnościowej.

Jest to ogromna przewaga notacji BPMN 2.0. Pozwala nam na zastosowanie różnych konwencji modelowania danego procesu w zależności od tego co chcemy pokazać na mapie. Możemy zatem pokazywać rzeczywistość w zależności od kontekstu i uzgodnionej z Interesariuszami konwencji modelowania.

Wielozdarzenie

W przypadku zastosowania zdarzenia początkowego typu „wielozdarzenie” proces rozpoczyna się w momencie uruchomienia jednego z możliwych wyzwalaczy. Innymi słowy wielozdarzenie reprezentuje kilka warunków (sytuacji), jeśli jedna ze zdefiniowanych warunków zostanie spełnionych proces jest uruchamiany.

Zgodnie z poniższym rysunkiem proces rusza w momencie gdy zostanie spełniona jedna z opisanych sytuacji:

1.     W magazynie jest mniej niż 5 szt. produktu

2.     Termin ważności produktu jest krótszy niż 3 miesiąca

Rysunek nr 11 Przykład procesu rozpoczynającego się zdarzeniem początkowym „Wielozdarzenie”


Jeśli jedno z tych twierdzeń okaże się prawdziwe to uruchamiany jest proces, w którym zamówiona zostanie partia produktu.

Powyższą logikę można przedstawić również następująco:

Rysunek nr 12 Przykład procesu rozpoczynającego się zdarzeniami początkowymi „Warunek”  


Na tym rysunku zdarzenie początkowe „Wielozdarzenie” zastąpiono dwoma warunkami, które zostają bezpośrednio podpięte pod zadanie „Zamówienie partii produktu”.  Tym samym wielozdarzenie zostało podzielone na dwa odrębne warunki. Wyzwolenie każdego z nich powodować będzie aktywację procesu i realizację zadania „Zamówienie partii produktu”.

Wielozdarzenie równoległe

W przypadku zastosowania wielozdarzenia równoległego proces uruchamia się dopiero w momencie wszystkich zdefiniowanych wyzwalaczy. O ile w przypadku zdarzenia początkowego „Wielozdarzenie” proces ruszał w momencie aktywowania jednego z określonych wyzwalaczy, o tyle w przypadku wielozdarzenia równoległego proces wystartuje w momencie, gdy aktywowane zostaną wszystkie zdefiniowane wyzwalacze (Rysunek nr 13).

Rysunek nr 13 Przykład procesu rozpoczynającego się zdarzeniem początkowym „Wielozdarzenie równoległe”


Proces dotyczący realizacji zamówienia uruchomi się, gdy zamówienie zostanie potwierdzone oraz zostanie opłacone. Kolejność wydarzeń nie ma znaczenia, proces uruchomi się w momencie, gdy zostaną spełnione wszystkie zdefiniowane twierdzenia.

Drugi przykład (Rysunek nr 14) obrazuje proces złożenia Kandydatowi oferty zatrudnienia. Proces ten zostanie inicjowany w momencie, gdy spełnione zostaną wszystkie z określonych wyzwalaczy:

1. Pozytywna ocena znajomości j. angielskiego;

2. Pozytywna opinia Zarządu;

3. Pozytywna opinia HR.

Rysunek nr 14 Przykład procesu rozpoczynającego się zdarzeniem początkowym „Wielozdarzenie równoległe”

Innymi słowy złożenie oferty zatrudnienia jest możliwe wtedy i tylko wtedy, gdy Kandydat spełnił wszystkie 3 warunki:


a)     został pozytywnie oceniony pod kątem znajomości języka angielskiego

i

b)     otrzymał pozytywną opinię Zarządu

i

c)     otrzymał pozytywną działu  HR.

Tak zdefiniowane zdarzenie początkowe można również zamodelować z wykorzystaniem bramki równoległej Parallel (Rysunek nr 15). W tak zamodelowanym procesie zadanie „Złożenie Kandydatowi oferty zatrudnienia” zostanie uruchomione w momencie aktywacji bramki łączącej Parallel.

Bramka ta zostanie aktywowana w momencie dotarcia do niej 3 wyzwalaczy procesów. Wspomnieć należy na marginesie, że tak zamodelowany proces formalnie ruszy w przypadku aktywacji jednego (pierwszego) wyzwalacza. Brak aktywacji pozostałych spowoduje, że uruchomiony proces utknie na bramce, która czekać będzie na spełnienie się pozostałych warunków.

Cel procesu został zrealizowany tak, jak w przypadku procesu z zastosowaniem zdarzenia początkowego „Wielozdarzenie równoległe”.   Jednakże zastosowanie „Wielozdarzenia rownoległego” pozwala na wstrzymanie uruchomienia się procesu do aktywacji wszystkich wyzwalaczy, podczas gdy zastosowanie 3 odrębnych zdarzeń początkowych spowoduje rozpoczęcie procesu jako takiego w momencie aktywacji pierwszego warunku. Sam proces nie pozwoli na aktywację zadania do czasu dotarcia do bramki decyzyjnej wszystkich pozostałych wyzwalaczy.

Rysunek nr 15 Przykład procesu rozpoczynającego się zdarzeniami początkowymi „Warunek”


Jeżeli jesteś zainteresowany/a współpracą z nami w obszarze zmapowania procesów biznesowych (niezależnie od działu) - wypełnij formularz i powiedz nam, czego potrzebujesz!

Karol Marciniak
Podziel się tą publikacją z innymi!

POPULARNE W TEJ DZIEDZINIE

preview-image
Mapowanie Procesów
Odkryj znaczenie zdarzeń w notacji BPMN 2.0 i ich wpływ na procesy biznesowe.
preview-image
Mapowanie Procesów
Zarządzanie zasobami ludzkimi firmy pochłania mnóstwo energii i czasu. Angażuje wiele osób w organizacji, a ze względu na obostrzenia prawne wymaga stałego trzymania ręki
No items found.
engave-Dostarczamy-kompleksowe-rozwiazania technologiczne-dla-biznesu

POROZMAWIAJMY!

Jesteśmy gotowi by słuchać, odkrywać, wprowadzać innowacje
Imię i Nazwisko
Email
Numer Telefonu
Twoja Firma
Wiadomość
Dziękujemy za kontakt! Ktoś z nas skontaktuje się z Tobą jak najszybciej.
Miłego dnia! :)
Oops! Coś poszło nie tak. Spróbuj jeszcze raz!
engave-Dostarczamy-kompleksowe-rozwiazania technologiczne-dla-biznesu
Informacja Cookies
Na naszej stronie internetowej www.engave.pl wykorzystujemy pliki cookies. Klikając „Akceptuję wszystkie”, wyrażasz zgodę na instalację wszystkich plików cookies oraz przetwarzanie Twoich danych osobowych. Zgodę możesz wycofać w dowolnym momencie. Administratorem Twoich danych osobowych jest Engave Spółka Akcyjna z siedzibą w Warszawie, ul. Czarodzieja 16, 03-116 Warszawa. Twoje dane osobowe mogą być także przetwarzane przez strony trzecie.

Klikając „Wyłącznie niezbędne cookies”, umożliwiasz funkcjonowanie strony internetowej. Więcej informacji o przysługujących Ci prawach znajduje się w naszej Polityce Prywatności Serwisu i Polityce Plików Cookies.
Szczegóły
Akceptuj Wszystkie
engave-Dostarczamy-kompleksowe-rozwiazania technologiczne-dla-biznesu
Newsletter

ZAPISZ SIĘ DO DIGITALIZATORA,
A NIC CI NIE UMKNIE!

Dziękujemy! Twoja subskrybcja została przyjęta!
Ups! Coś poszło nie tak, spróbuj jeszcze raz!