Data: 20.11.2022

Notacja BPMN – zdarzenia końcowe
Spis treści
- Notacja BPMN – zdarzenia końcowe
- Kiedy używamy zdarzeń końcowych?
- Wyniki zdarzeń końcowych
- Wiadomość jako wynik zdarzenia końcowego
- Błąd jako wynik zdarzenia końcowego
- Eskalacja jako wynik zdarzenia końcowego
- Kompensacja jako wynik zdarzenia końcowego
- Sygnał jako wynik zdarzenia końcowego
- Bezwarunkowe zakończenie jako wynik zdarzenia końcowego
- Zdarzenie złożone jako wynik zdarzenia końcowego
Artykuł zawiera informacje na temat zdarzeń końcowych notacji BPMN, które umieszczamy na końcu procesu biznesowego.
Procesy biznesowe modeluję w programie MS Visio. W Visio diagramy BPMN znajdują się w kategorii schematów blokowych.
Kiedy używamy zdarzeń końcowych?
Zdarzenie końcowe kończy instancję procesu.
Używanie zdarzeń końcowych i początkowych nie jest wymagane w ramach procesu biznesowego. Jeśli jednak w procesie wystąpi zdarzenie początkowe, musimy też użyć co najmniej jednego zdarzenia końcowego.
Zdarzenia początkowe opisaliśmy w artykule BPMN zdarzenia początkowe
Oprócz oprócz zdarzenia początkowego i końcowego, w modelach procesów biznesowych mamy również do dyspozycji zdarzenia pośrednie. Przedstawiliśmy je w artykule BPMN zdarzenia pośrednie
Proces biznesowy może zawierać więcej niż jeden poziom tzn. możemy mieć główny proces i podprocesy. Użycie zdarzeń początkowych i końcowych jest niezależne dla każdego poziomu diagramu.
Na jednym poziomie procesu możemy użyć więcej niż jednego zdarzenia końcowego. Każda ścieżka procesu może być zakończona swoim zdarzeniem końcowym.
Wyniki zdarzeń końcowych
Zdarzenie końcowe oznaczamy pojedynczą pogrubioną linią.

Specyfikacja BPMN umożliwia uzupełnienie ikony zdarzania końcowego jednym z następujących symboli:
- Wiadomość
- Błąd
- Eskalacja
- Anulowanie
- Kompensacja
- Sygnał
- Bezwarunkowe zakończenia
- Złożone zakończenie
Wiadomość jako wynik zdarzenia końcowego
Wiadomość (ang. message) – ten rodzaj zakończenia wskazuje, że po zakończeniu procesu do uczestnika procesu wysyłana jest wiadomość.
Oznaczamy ją następująco:

W poniższym przykładzie przebieg procesu prowadzi od zdarzenia początkowego „Wpłynięcie zamówienia” do zdarzenia końcowego zawierającego komunikat „Poinformowanie zamawiającego o realizacji zamówienia”.
Bramka równoległa oznacza, że obydwa zadania („Zarejestrowanie zamówienia” i „Sprawdzenie płatności”) muszą być wykonane, aby żeton mógł popłynąć dalej wzdłuż sekwencji przepływu. Zadania te nie muszą być wykonane w tym samym czasie.
Przepływy sekwencji (obiekty łączące) – czarne strzałki z wypełnionym grotem łączą poszczególne obiekty przepływu (bramki, zadania, zdarzenia, obiekty danych).

Użycie komunikatu w zdarzeniu końcowym pozwala wyeliminować jedną czynność. Proces ten moglibyśmy narysować ze zdarzeniem końcowym bez określania wyniku. Wówczas mamy dodatkową czynność „Poinformowanie zamawiającego o realizacji zamówienia”.

Poniższy rysunek zawiera proces, w którym wykorzystane są dwie bramki:
- bramka wykluczająca sterowana danymi – za jej pomocą rozgałęziamy proces na dwie ścieżki w zależności od tego, czy jest wpłata
- bramka wykluczająca sterowana zdarzeniami – za jej pomocą rozgałęziamy proces na trzy ścieżki. W zależności od tego, które ze zdarzeń wystąpi tą ścieżką proces będzie się kontynuował.
Proces kończymy zdarzeniem końcowym z wynikiem komunikatu.

Więcej informacji na temat bramek znajdziesz w artykule BPMN bramki logiczne
Błąd jako wynik zdarzenia końcowego
Błąd (ang. error) – ten typ zakończenia wskazuje, że dana ścieżka procesu zakończy się zdarzeniem końcowym z wynikiem błędu. W rezultacie wszystkie aktualnie aktywne wątki w danym podprocesie zostają zakończone.
Błąd oznaczamy w procesie następująco:

W poniższym przykładzie mamy proces płatności za zakupy przy kasie samoobsługowej. W pierwszym zadaniu klient skanuje zakupy, następnie dokonuje płatności kartą kredytową. Jeśli transakcja nie zostanie zaakceptowana pojawi się błąd, który kończy proces.

Notacja BPMN umożliwia przechwytywanie błędów. W przykładzie poniżej mamy model procesu biznesowego, który zawiera proces główny i podproces rozwinięty. W podprocesie bramka wykluczająca rozdziela jego przebieg na dwie ścieżki:
- jeśli karta zostanie zaakceptowana, klient może odebrać zakupy i ścieżka procesu kończy się zdarzeniem końcowym bez oznaczenia wyniku.
- jeśli karta nie zostanie zaakceptowana ścieżka procesu kończy się zdarzeniem końcowym z wynikiem Błąd. Błąd ten jest przechwycony przez zdarzenie pośrednie z wyzwalaczem Błąd umieszczone w krawędzi podprocesu.

Eskalacja jako wynik zdarzenia końcowego
Eskalacja (ang. escalation) – ten typ zakończenia wskazuje, że należy wyzwolić eskalację. Oznaczamy ją następująco:

Zdarzenie eskalacji dla jednej ścieżki procesu nie ma wpływu na pozostałe ścieżki – są one nadal wykonywane.
W poniższym procesie:
- w procesie głównym otrzymujemy zamówienie na rower
- w podprocesie sprawdzamy, czy są dostępne części. Bramka wykluczająca sterowana danymi rozdziela proces na dwie ścieżki.
-
Jeśli części są dostępne realizujemy zamówienie i wysyłane jest potwierdzenie realizacji zamówienia.
-
W przypadku braku części zamawiamy je z magazynu.
Jeśli magazyn w ciągu 2 dni nie dostarczy części wysyłamy ponaglenie. Jeśli po upływie jednego dnia nadal nie ma części podproces kończy się zdarzeniem końcowym z wynikiem eskalacji.
Eskalacja jest przechwycona przez zdarzenie pośrednie umieszczone w granicy podprocesu.
-

Anulowanie jako wynik zdarzenia końcowego
Zdarzeń anulowania w notacji BPMN używamy jedynie w kontekście modelowania podprocesów transakcyjnych. Oznaczamy je następująco:

Jeśli ścieżka procesu w podprocesie transakcyjnym kończy się zdarzeniem końcowym anulowania, do granicy podprocesu możemy dołączyć zdarzenie pośrednie anulowanie. Zdarzenie to dołączone do granicy podprocesu przechwyci zdarzenie końcowe anulowania.
Anulowanie oznacza, że transakcja powinna zostać anulowana i wywołane powinno zostać zdarzenie anulowania dołączone do granicy podprocesu.
Gdy transakcja zostanie anulowana, anulowane zostaną wszystkie działania w ramach transakcji.
Anulowanie spowoduje zakończenie wszystkich uruchomionych działań i zrekompensuje wszystkie działania pomyślnie zakończone w podprocesie, którego dotyczy. Jeśli podproces jest transakcją, transakcja jest wycofana.
W poniższym przykładzie w procesie głównym przyjmujemy zamówienie na organizację urodzin. W podprocesie transakcyjnym mamy trzy zadania. Jeśli czynność zakończy się błędem jej realizacja jest anulowana. Każde zakończone zadanie jest kompensowane.

Kompensacja jako wynik zdarzenia końcowego
Kompensacja (ang. compensation) to rodzaj zakończenia, który wskazuje, że konieczne jest skompensowanie (odwrócenie) wykonanego zadania lub wielu zadań. Oznaczamy ją następująco:

Wszystkie zadania, które zostały pomyślnie ukończone a podlegają kompensacji, zostaną odwrócone i zrekompensowane.
W poniższym przykładzie użyliśmy bramki równoległej aby oznaczyć, że obydwie czynności (Rezerwacja pokoju i Rezerwacja wycieczek) muszą być wykonane, aby proces mógł się kontynuować.
Jeśli zadania wykonane zostaną poprawnie i skuteczne będzie obciążenie karty, proces zakończy się wysłaniem wiadomości.
Jeśli obciążenie karty się nie uda, proces zakończy zdarzenie kompensacji. Wówczas następuje wycofanie wykonanych czynności rezerwacji pokoju i wycieczek.

Sygnał jako wynik zdarzenia końcowego
Sygnał (ang. signal) – ten rodzaj zakończenia oznacza, że po zakończeniu procesu nadawany będzie sygnał. Oznaczamy go następująco:

Sygnał w modelowaniu procesów można porównać do wystrzelenia w niebo sygnału świetlnego. Każdy odbiorca, który sygnał zobaczy może na niego zareagować.
W przykładzie poniżej w firmie przygotowana została aktualizacja oprogramowania. Informacja do pracowników jest przekazna w formie komunikatu. Nie ma określonego odbiorcy. Każdy w organizacji, kto komunikat zobaczy może oprogramowanie pobrać i zaktualizować.

Bezwarunkowe zakończenie jako wynik zdarzenia końcowego
Bezwarunkowe zakończenie (ang. terminate) – wskazuje, że wszystkie działania w procesie powinny zostać natychmiast zakończone. Oznaczamy je następująco:

„Normalne” (nieokreślone) zdarzenie zakończenia wskazuje, że kończy się pojedyncza sekwencja procesu. Bezwarunkowe zakończenie kończy cały proces, a tym samym zakończy każdą czynność i instancję procesu, która może być uruchomiona.
W przykładzie poniżej mamy proces, w którym obsługujemy wniosek o kredyt. Po zadaniu „Przyjęcie wniosku o kredyt” jest bramka równoległa, która rozgałęzia proces na dwie ścieżki. Żeton „popłynie” każdą ze ścieżek:
- wykonane zostanie zadanie „Weryfikacja klienta w bazie banku”. Jeśli weryfikacja jest pozytywna żeton „popłynie” do zadania „Udzielenie kredytu”. Jeśli nie jest pozytywna, cały proces jest natychmiast kończony zdarzeniem końcowym z wynikiem bezwarunkowe zakończenie. Zadanie „Weryfikacja klienta w bazie banku” zostanie wykonane pod warunkiem, że proces nie zostanie przerwany w wyniku weryfikacji klienta w BIK.
- wykonane zostanie zadanie „Weryfikacja klienta w BIK”. Jeśli weryfikacja jest pozytywna żeton „popłynie” do zadania „Udzielenie kredytu”. Jeśli weryfikacja nie jest pozytywna, cały proces jest natychmiast kończony zdarzeniem końcowym z wynikiem bezwarunkowe zakończenie. Zadanie „Weryfikacja klienta w BIK” zostanie wykonane pod warunkiem, że proces nie zostanie przerwany w wyniku weryfikacji klienta w bazie.

Zdarzenie złożone jako wynik zdarzenia końcowego
Zdarzenie złożone (ang. multiple) oznacza, że istnieje wiele konsekwencji zakończenia procesu. Wszystkie z nich wystąpią np. może być wysłanych wiele wiadomości. Oznaczamy je następująco:

Zdarzenie złożone jest rzadko stosowane do modelowania procesów i nie wszystkie systemy mają zaprogramowaną jego obsługę. W programie MS Visio trzeba ręcznie zdefiniować dane kształtu i dodać w nim opcję „Wielokrotne”.
W poniższym przykładzie mamy proces, w którym przyjmujemy zgłoszenie szkody, rejestrujemy je i rozpatrujemy. Proces kończy się zdarzeniem końcowym z wynikiem „Zdarzenie złożone”. Konsekwencje zakończenia procesu są dwie:
- wysłanie informacji do klienta i
- archiwizacja dokumentacji
Obydwie te czynności wystąpią.

Ten sam proces z nieokreślonym wynikiem zdarzenia końcowego wyglądałby następująco:

