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
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)
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.
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.
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.
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 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.
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.
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ń.
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).
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).
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.
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
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:
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”.
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).
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.
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.
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!
