Notacja BPMN podprocesy

W artykule przedstawiam podprocesy używane w notacji BPMN do modelowania procesów biznesowych. Dowiesz się, w jaki sposób modelować podprocesy oraz do czego one służą.

Modele procesów biznesowych rysuję w narzędziu MS Visio.

Notacja BPMN podprocesy – co to jest podproces?

W BPMN podproces to złożone działanie, które zawiera zbiór zadań i podprocesów.

Podprocesy to dobry sposób na organizację i uproszczenie diagramu poprzez grupowanie powiązanych działań w jeden element, który możemy rozwinąć, aby zobaczyć szczegóły lub zwinąć, aby zobaczyć ogólny przebieg procesu.

Rodzaje podprocesów w modelach notacji BPMN 2.0

W standardzie BPMN (ang. Business Process Model and Notation) mamy do dyspozycji kilka rodzajów podprocesów (ang. sub-processes). Każdy z nich służy innemu celowi i ma swoje zastosowania.

Podstawowe rodzaje podprocesów:

podproces zwinięty (ang. Collapsed Sub-Process) – jest reprezentowany jako jeden element na diagramie głównym, a jego szczegóły są ukryte.
podproces rozwinięty (ang. Expanded Sub-Process) – jest widoczny wewnątrz procesu nadrzędnego. Wszystkie jego szczegóły są widoczne na diagramie głównym.

Podproces zwinięty

Szczegóły podprocesu nie są widoczne na diagramie procesu głównego. Znak „plus” w dolnej środkowej części kształtu wskazuje, że działanie jest procesem podrzędnym i ma niższy poziom szczegółowości.

Podproces zwinięty oznaczamy za pomocą symbolu prostokąta ze znakiem plusa na dole:

W przykładzie poniżej mamy proces główny (nadrzędny), w którym są następujące elementy:

zdarzenie początkowe
krok pierwszy to zadanie „Przyjęcie reklamacji”
krok drugi to podproces zwinięty „Rozpatrzenie reklamacji”. Po kliknięciu znaku + możemy zobaczyć podproces, w ramach którego szczegółowo przedstawiamy, w jaki sposób przebiega rozpatrywanie reklamacji
krok trzeci to Wysłanie odpowiedzi
zdarzenie końcowe

W programie MS Visio schemat podprocesu rysujemy na oddzielnej stronie. Stronę z podprocesem możemy utworzyć na dwa sposoby:

zaznaczamy podproces Rozpatrzenie reklamacji i na karcie Proces klikamy ikonę Utwórz nowy
Utworzy się wówczas strona o nazwie Rozpatrzenie reklamacji, na której możemy narysować schemat podprocesu.
jeśli strona z podprocesem już istnieje zamiast opcji Utwórz nowy klikamy ikonę Połącz z istniejącym i klikamy nazwę strony, do której chcemy utworzyć link

Poniżej podproces Rozpatrzenie reklamacji:

Elementy diagramu zawarte w ramach podprocesu Rozpatrzenie reklamacji:

zdarzenie początkowe
zdarzenia końcowe
bramka logiczna sterowana danymi reprezentowana przez romb ze znakiem X, która rozgałęzia przepływ procesu na dwie ścieżki
strzałki łączące elementy procesu (sekwencje przepływu)

Podproces rozwinięty

Kształty umieszczone w podprocesie są widoczne w procesie głównym.

Według specyfikacji BPMN, jeśli podproces został rozwinięty w obrębie diagramu, obiekty znajdujące się w ramach podprocesu nie mogą być łączone z obiektami poza podprocesem.

Przepływy sekwencji nie mogą przekroczyć granicy podprocesu.

Zdarzenie początkowe i końcowe możemy umieścić w granicy podprocesu. Wówczas sekwencja przepływu łączy się ze zdarzeniami a nie z granicą podprocesu.

Inne rodzaje podprocesów używane w diagramach BPMN

Podprocesy zwinięte oraz rozwinięte mogą występować jako procesy:

wywoływane – wielokrotnego użycia
zdarzeniowe
transakcyjne
zdarzeniowe kompensacji
ad-hoc

Podprocesy wywoływane

Podproces wywoływany (ang. Reusable Sub-Process) zwinięty lub rozwinięty może być wielokrotnie wykorzystany w różnych miejscach jednego procesu lub w różnych procesach.

Oznaczamy go za pomocą pogrubionej linii.

W przykładzie mamy proces rozpatrywania reklamacji w formie procesu wywoływanego. Jeśli w różnych działach firmy proces ten wygląda tak samo i ma tych samych uczestników procesu, nie musimy rysować go za każdym razem od początku. Możemy narysować proces w jednym miejscu i używać go w różnych diagramach jako podprocesu wywoływanego.

Podprocesy zdarzeniowe

Podproces zdarzeniowy (ang. Event Sub-Processes) jest to specjalizowany podproces używany w ramach procesu lub podprocesu. Wywoływany jest on przez zdarzenie. Oznaczamy go za pomocą cienkiej kropkowanej linii.

Nie jest częścią normalnego przepływu procesu rodzica (nadrzędnego procesu). Nie przychodzą do niego żadne sekwencje przepływu oraz nie wychodzą z niego żadne sekwencje przepływu.

Podproces zdarzeniowy może ale nie musi wystąpić, kiedy proces nadrzędny (rodzic) jest aktywny. Może on wystąpić więcej niż jeden raz.

Standardowy podproces używa przepływu nadrzędnego procesu jako wyzwalacza. Dla podprocesu zdarzeniowego wyzwalaczem jest zdarzenie.

Zdarzenie początkowe podprocesu zdarzeniowego musi mieć wyzwalacz. Wyzwalaczem mogą być następujące elementy:

wiadomość (ang. Message)
błąd (ang. Error)
eskalacja (ang. Escalation)
kompensacja (ang. Compensation)
warunkowe (ang. Conditional)
sygnał (ang. Signal)
złożone (ang. Multiple)

Podproces zdarzeniowy może mieć tylko jedno zdarzenie początkowe. Gdy podproces zdarzeniowy zostanie wyzwolony proces nadrzędny może zostać przerwany lub może się kontynuować.

Przykład procesu głównego ze zdarzeniem pośrednim krawędziowym wykorzystanym do oznaczenia rezygnacji klienta z pożyczki.

Zdarzenie pośrednie przerywa normalny przebieg procesu i zostaje obsłużone przez podproces zdarzeniowy.

Zamiast podprocesu zdarzeniowego możemy użyć przepływu wyjątku:

Szczegółowe informacje na temat zdarzeń pośrednich znajdziesz w artykule BPMN zdarzenia pośrednie.

Z kolei w artykule BPMN zdarzenia początkowe są opisane zdarzenia początkowe również dla procesów zdarzeniowych.

Podprocesy transakcyjne

Podproces transakcyjny (ang. Transaction Sub-Processes) to podproces, który jest obsługiwany przez specjalny protokół np. WS-Transaction, który określa, że wszystkie działania w ramach podprocesu powinny być zrealizowane lub anulowane.

Możliwe wyniki transakcji:

pomyślne zakończenie – będzie to przedstawione jako normalny przepływ sekwencji opuszczający podproces transakcji
nieudane zakończenie (anulowanie) – kiedy transakcja jest anulowana, anulowane są znajdujące się w niej działania co może obejmować cofnięcie procesu i kompensację dla określonych aktywności. Inne niż Anulowanie np. Błąd, Zegar mechanizmy przerwania podprocesu transakcji nie spowodują kompensacji.

Zdarzenia pośredniego Anulowania można użyć tylko wtedy, gdy jest dołączone do granicy podprocesu transakcji. Nie można go używać w żadnym normalnym przebiegu i nie można go dołączyć do podprocesu innego niż transakcyjny.

Kiedy każda ścieżka podprocesu transakcji osiągnie zdarzenie końcowe inne niż anulowanie, przepływ nie powraca natychmiast do procesu nadrzędnego wyższego poziomu, jak ma to miejsce w przypadku normalnego podprocesu. Najpierw protokół transakcji musi zweryfikować, czy wszyscy uczestnicy pomyślnie zakończyli transakcję. Jeśli któryś z uczestników napotka problem, który spowoduje Anulowanie przepływ zostanie przeniesiony do odpowiedniego zdarzenia pośredniego.

Przykład z podprocesem transakcyjnym:

W przykładzie:

przyjmujemy rezerwację
w podprocesie transakcyjnym rezerwujemy hotel i wycieczki
jeśli transakcja zakończy się powodzeniem wysyłamy potwierdzenie rezerwacji
jeśli transakcja nie zakończy się powodzeniem zostaje anulowana. Zdarzenie pośrednie w granicy podprocesu przechwytuje anulowanie
po anulowaniu transakcji wysyłamy informację do IT i do klienta

Podproces zdarzeniowy kompensacji

Podproces zdarzeniowy kompensacji (ang. Compensation Event Sub-Process) służy do obsłużenia w modelu BPMN zdarzenia kompensacji.

W przykładzie poniżej:

w procesie głównym jest zadanie Przyjęcie zamówienia
w ramach podprocesu transakcyjnego Rezerwujemy hotel i pobieramy opłatę oraz Rezerwujemy wycieczki i pobieramy opłatę
jeśli transakcja w ramach podprocesu zostanie zrealizowana poprawnie, w procesie głównym wysyłamy do klienta potwierdzenie rezerwacji
jeśli w procesie głównym nastąpi zdarzenie pośrednie rezygnacji klienta z zamówienia wysyłane jest zdarzenie pośrednie z wyzwalaczem kompensacji. Zdarzenie kompensacji zostaje przechwycone w podprocesie transakcyjnym. W podprocesie zdarzeniowym kompensacji obsłużona zostaje kompensacja

Kompensację możemy zastosować jedynie wtedy, gdy transakcja zostanie zakończona poprawnie.

Podproces ad-hoc

Podproces ad-hoc (ang. Ad-Hoc Sub-Process) to wyspecjalizowany typ podprocesu stanowiący grupę działań, dla których nie są wymagane relacje w sekwencji tzn. zadania mogą być wykonywane w dowolnej kolejności.

Możemy zdefiniować zestaw działań, ale kolejność i liczbę wykonań działań ustalają ich wykonawcy.

Podprocesy ad-hoc ograniczają użycie elementów BPMN, które normalnie byłyby używane w podprocesach. Nie możemy w nich używać zdarzeń początkowych i końcowych.

W jakim celu modelujemy podprocesy w diagramach procesów biznesowych?

Podproces umożliwia:

prezentację szczegółów procesu z danego obszaru na oddzielnym modelu
przedstawienie grupy zadań, do których należy odwołać się w wielu miejscach w ramach procesu.

Dzięki podprocesom możemy uprościć diagramy modeli biznesowych, gdyż część zadań możemy umieścić poza procesem głównym.

Możemy również ograniczyć ilość wykonywanej pracy. Jeśli jakaś grupa czynności wykonywana jest w wielu miejscach organizacji, nie musimy jej modelować kilka razy w różnych miejscach. Możemy przygotować jeden model i wywoływać go w innych modelach.