Z własnej praktyki wiem, że logika stosowania bramek przysparza wiele trudności zarówno analitykom opracowującym dokumentację modeli procesów biznesowych, jak i Klientom oraz Interesariuszom, którzy czytają, interpretują i stosują modele w codziennej praktyce realizacji procesów biznesowych. Często prowadzi to do tworzenia modeli błędnych formalnie, niezgodnych z specyfikacją BPMN 2.0 lub - co najistotniejsze - modeli niewykonywalnych bądź niezgodnych z celem i logiką procesu biznesowego Klienta.
W niniejszym artykule omówię i przedstawię najczęściej stosowanie bramki logiczne wykorzystywane w modelowaniu procesów w oparciu o notację BPMN 2.0. Zwrócę uwagi na potencjale pułapki, zależności oraz błędy które często pojawiają się przy tworzeniu dokumentacji procesów biznesowych właśnie w kontekście projektowania logiki przepływu procesów z wykorzystaniem bramek decyzyjnych.
Jest to jedna z najczęściej wykorzystywanych bramek w modelowaniu. Notacja BPMN 2.0 przedstawia ją jako symbol pustego diamentu lub diamentu ze znakiem (x) wewnątrz. Bramka ta często traktowana jest jako punkt decyzyjny. Za bramką decyzyjną określone zostają alternatywy przebiegu procesu natomiast sama bramka decyzyjna sprawdza warunki określone dla danych ścieżek procesu. Spełnienie jednego z warunków powoduje, że następne nie są już sprawdzane a proces realizowany jest ścieżką, dla której warunek został spełniony. Jakiekolwiek inne warunki są ignorowane nawet jeśli hipotetycznie zostaną spełnione.
Popatrzmy na prosty przykład wykorzystania bramki decyzyjnej typu XOR:
Rysunek nr 1 Model procesu z zastosowaniem bramki XOR
Model pokazuje prosty element procesu, w którym następuje zadanie „Ocena wniosku”, po czym w zależności od wyniku oceny następuje zadanie „Przyjęcie wniosku” – w przypadku, gdy spełniony zostanie warunek pozytywnej oceny albo „Odrzucenie wniosku” – w przypadku, gdy spełniony zostanie warunek oceny negatywnej. Przebieg procesu uzależniony jest więc od tego, jaki warunek zostanie spełniony warunku na bramce decyzyjnej XOR.
Popatrzmy zatem na analogiczny proces uzupełniony o kolejną alternatywę przebiegu procesu „Poprawa wniosku” (Rysunek nr 2).
Rysunek nr 2 Model procesu z zastosowaniem bramki XOR ze ścieżką domyślną
Oto warianty zachowania procesu:
albo
albo
W takim przypadku ścieżka domyślna może być oznaczona bez podawania warunku. Taką ścieżkę domyślną należy intepretować jako „ostatnią deskę ratunku”, umożliwiając kontynuację procesu w przypadku, gdy nie został spełniony żaden z określonych dla innych ścieżek wyrażeń warunkowych. Ścieżka domyślna rozważana jest jako ostatnia i może zostać realizowana tylko wtedy, gdy nie został spełniony żaden z określonych warunków determinujących realizację procesu inną ścieżką.
Jak zatem zachowa się proces na przedstawionym przykładzie (Rysunek 2)? Najpierw sprawdzane jest spełnienie przez proces określonych warunków. Jeśli zatem wniosek wymaga uzupełnień nastąpi zadanie „Poprawa wniosku”. Jeśli wynik oceny będzie negatywny to wniosek zostanie odrzucony. W każdym innym przypadku, tj. wtedy, kiedy wniosek nie zostanie odrzucony oraz nie zostanie skierowany do poprawy nastąpi zadanie „Przyjęcie wniosku”.
Na marginesie należy zaznaczyć, że na modelu do zadania „Ocena wniosku” przypisano dwa przepływy wchodzące. Tym samym zadanie “Ocena wniosku” może nastąpić po rozpoczęcia procesu albo po zadaniu „Poprawa wniosku”. Na modelu nie zastosowałem w tym przypadku bramki łączącej XOR. Specyfikacja BPMN 2.0 dopuszcza w takim przypadku łączenie przepływów bez bramki typu XOR.
Rysunek nr 3 Model procesu z zastosowaniem bramki XOR dzielącej i łączącej
Na kolejnym przykładzie nasz proces rozbudowujemy o zadanie „Wydanie decyzji”. Przed tym zadaniem zastosowano bramkę łączącą XOR. Celem bramki łączącej jest łączenie wariantów przebiegów w jeden. Bramka łącząca typu XOR zachowuje się w taki sposób, że przepuszcza każdy przepływ, który do niej dotrze. W tym przypadku, gdy zastosowaliśmy bramkę decyzyjną typu XOR logiczne jest, że do bramki łączącej dotrze tylko przepływ z jednej ścieżki aktywującej się po spełnieniu warunku określonego na bramce decyzyjnej. Jednakże sposób zachowania tej bramki łączącej ma duże znaczenie dla przebiegu procesu w momencie, kiedy w punkcie decyzyjnym zastosujemy inną niż XOR bramką decyzyjną, co będę chciał pokazać w dalszej części artykułu.
Częstym błędem popełnianym na etapie modelowania jest brak umieszczania wyrażeń warunkowych przy definiowaniu alternatywnych ścieżek przepływu lub próba uwzględnienia logiki przepływu z wykorzystaniem elementu typu Zadanie (Rysunek nr 4).
Rysunek nr 4 Model procesu z opisem warunków na Zadaniach (błędny)
W pierwszym przypadku, brak umieszczenia wyrażeń warunkowych spowoduje, że z modelu nie będzie wynikać, jaką decyzję będzie podejmować bramka i jakie warunki będą poddawane ocenie przy określaniu dalszego przebiegu procesu.
Element typu „Zadanie” reprezentuje podjęcie konkretnej aktywności w procesie i dobrą praktyką jest umieszczanie w nazwie zadania czasownika lub rzeczownika odczasownikowego opisującego istotę realizowanej w ramach zadania czynności. Wykorzystywanie komponentu „Zadanie” do reprezentacji warunku jest zatem niezgodne z modelowaniem w oparciu o specyfikację BPMN 2.0.
Notacja BPMN 2.0 daje jednak możliwość wykorzystania innej konwencji przy modelowaniu procesów i wizualizacji przebiegu, czynności i zdarzeń pojawiających w procesie. Służą temu elementy takie jak „Zdarzenia pośrednie” i „Bramki sterowane zdarzeniami”. Zdarzenia pośrednie w przeciwieństwie do zadań nie reprezentują konkretnej akcji czy działania, które muszą zostać wykonane w procesie. Zgodnie z notacją BPMN 2.0 „Zdarzenie pośrednie” to wystąpienie jakiejś sytuacji w procesie na tyle istotnej, że warto ją nazwać i zdefiniować. Zdarzenia mogą mieć przykładowo charakter wystąpienia upływu czasu lub realizacji określonego warunku.
Na poniższym rysunku (Rysunek nr 5) przedstawiono reprezentację procesu z użyciem omawianych elementów notacji:
Rysunek nr 5 Model procesu z zastosowaniem bramki XOR sterowanej zdarzeniami.
Na diagramie zastąpiono typową bramkę typu XOR bramką XOR sterowaną zdarzeniami. Jak sama nazwa wskazuje bramka podejmie decyzję o dalszym przebiegu procesu w zależności od zdarzenia, które nastąpi w procesie. W tym przypadku zastosowano zdarzenia pośrednie typu warunek (Conditional event). Ten typ zdarzenia jest wyzwalany w momencie, gdy określony warunek stanie się prawdziwy. Jeśli zatem wystąpi zdarzenie i spełniony zostanie warunek „ocena pozytywna” nastąpi zadanie „Przyjęcie wniosku”.
Natomiast jeśli wystąpi zdarzenie pośrednie typu warunek „Ocena negatywna” proces przebiegnie alternatywną ścieżką i nastąpi Zadanie „Odrzucenie wniosku”. Taka konstrukcja także umożliwia zobrazowanie na modelu wyrażeń, których wypełnienie warunkuje realizację procesu zgodnie z określoną ścieżką alternatywną. Proces zachowa się tak samo jak w przypadku modelu z użytą bramką wykluczającą XOR. Inna jest jedynie konwencja i sposób wizualizacji procesu i wyrażeń warunkujących zachowanie bramki decyzyjnej.
Warunki nie są opisane na strzałkach wskazujących przebieg procesu a są reprezentowane poprzez właśnie zdarzenia pośrednie. Jest to bardzo cenna cecha notacji BPMN, gdyż na etapie ustaleń z Klientem sposobu i formy dokumentacji procesów istotne jest, aby ustalić nie tylko potrzeby biznesowe i wymagania merytoryczne co do modeli, ale również warstwę techniczną i graficzną. Należy zawsze pamiętać, że modelujemy w jakimś celu i dla określonej grupy odbiorców. Odbiorcy Ci mogą mieć różne potrzeby, sposób percepcji i znajomość zasad modelowania zgodnie z BPMN (lub nawet jej brak).
Dlatego niezwykle ważne jest, aby na etapie ustaleń oczekiwań Klienta omówić również konwencję przedstawiania procesów, tak aby udokumentować je w formie (lub formach) dostosowanych do kontekstu, potrzeb i celu biznesowego Klienta.
Kolejnym istotnym zagadnieniem, na które powinno zwracać się uwagę przy ustalaniu oczekiwań Klienta jest oraz dokumentacji procesów jest kontrola upływu czasu w procesie. Wracając do naszego prostego przykładu procesu z dwiema alternatywnymi ścieżkami przebiegu procesu (Rysunek nr 3) należy podkreślić, że model ten nie odzwierciedla przebiegu procesu, w odniesieniu do czasu. Innymi słowy w przypadku, gdy mówiąc kolokwialnie nasz wniosek utknąłby na etapie oceny, nie podjęłoby się żadnej decyzji to według modelu proces się zatrzymuje i czeka na wystąpienie określnego warunku tak, aby można było podejmować określone w danej ścieżce alternatywnej działania.
Często jednak Klientowi zależy, aby na diagramie uwzględnić również sytuację, w której mija określony okres czasu, warunki nie zostają spełnione a proces powinien w jakiś sposób mimo to kontynuować swoje działanie.
Na rysunku nr 6, przedstawiono jedną z możliwości zamodelowania kontynuacji procesu pomimo niespełnienia jednego z warunków przez określony okres czasu
Rysunek nr 6 Model procesu z wykorzystaniem bramek XOR z uwzględnieniem upływu czasu
Na modelu zastosowałem kolejną alternatywę dla procesu, która jest wyzwalana wystąpieniem zdarzenia pośredniego typu „Timer”. Warunek wystąpienia zdarzenia to minięcie 30 dni od wpłynięcia wniosku. Tym samym, w przypadku, gdy w ciągu 30 dni od wpłynięcia wniosku nie zostanie on oceniony ani pozytywnie, ani negatywnie aktywowane zostanie zdarzenie pośrednie, które wyzwoli bramkę łączącą oraz realizację zadania typu wydanie decyzji. W taki sposób obrazować można procesy, w którym brak podjęcia określonych działań w określonym terminie determinuje wystąpienie określonych skutków.
Przykładem może być sytuacja, w której po zgłoszeniu robót budowlanych niewymagających pozwolenia na budowę Inwestor może przystąpić do realizacji robót po upływie 21 dni od dnia złożenia wniosku, jeśli w tym terminie nie zostaw wniesiony sprzeciw w formie decyzji.
Kolejną często wykorzystywaną w modelowaniu bramką decyzyjną jest bramka niewykluczająca OR (Inclusive Gateway). W notacji BPMN 2.0 bramka niewykluczająca oznaczona jest znakiem diamentu z symbolem „O” wewnątrz. Symbol „O” odnosi się do angielskiej nazwy operatora „albo” „OR”. Analogicznie jak w przypadku bramki XOR bramka OR może funkcjonować jako punkt decyzyjny (rozgałęzienie ścieżek alternatywnych) oraz bramka łącząca, jako punkt zrównoleglenia ścieżek.
Bramka niewykluczająca OR oznacza, że w procesie sprawdzane są warunki dla wszystkich ścieżek określonych za daną bramką. Uruchamiana jest każda ścieżka, dla której warunek został spełniony. Jest to więc kluczowa różnica względem omawianej wyżej bramki XOR. Bramka Exclusive Gateway aktywuje tylko jedną ścieżkę, gdy spełniony zostanie jeden z warunków (a jeśli nie to uruchomiana zostanie ścieżka domyślna). I na tym sprawdzanie warunków się kończy. W przypadku bramki OR sprawdzane są wszystkie warunki i aktywowane jest tyle ścieżek, ile warunków zostało spełnionych.
Spójrzmy na przykład procesu związany przygotowaniem zakresu działań onboardingowych dla nowego pracownika (Rysunek nr 7).
Rysunek nr 7 Model procesu z zastosowaniem bramki OR dzielącej i łączącej
Proces rozpoczyna się zdarzeniem początkowym typu „Wiadomość” w momencie, gdy wpłynie zlecenie przeprowadzenia onboardingu. Później następuje zadanie "Przygotowanie zakresu onboardingu”.
Następnie poprzez zastosowanie bramki decyzyjnej OR następuje rozwidlenie ścieżek i sprawdzanie dwóch niezależnych od siebie warunków:
Proces uwzględnia również trzeci warunek określony zdarzeniem pośrednim „Onboarding niepotrzebny” stanowiący zaprzeczenie pozostałych dwóch warunków. Logika procesu zakłada, że warunek ten zostaje spełniony tylko wtedy, gdy żaden z pozostałych wyżej nie zostanie spełniony.
Wskazałem na wstępie, że bramka typu OR sprawdza wszystkie warunki określone, w tym przypadku możliwe są zatem następujące sytuacje wynikające z możliwych kombinacji wariantów:
Bramka łącząca typu OR sprawdzi wszystkie określone przy bramce decyzyjnej warunki. Kiedy zostaną zrealizowane zadania określone w ścieżce lub ścieżkach aktywowanych po spełnieniu określonych dla ścieżek warunków bramka scalająca OR złączy przepływy a proces kontynuowany będzie poprzez zadanie „Sporządzenie raportu”.
Rysunek nr 8 Model procesu z zastosowaniem bramki XOR dzielącej i łączącej (niezgodny z logiką omawianego procesu)
Wyobraźmy sobie inną sytuację. Jak zadziałałby proces, gdybyśmy w modelu zastosowali omówioną wcześniej bramkę decyzyjną oraz łączącą typu XOR (Rysunek nr 8). Jak wspomnieliśmy bramka dzieląca typu XOR aktywuje jedynie jedną ścieżkę po odnotowaniu spełnienia danego warunku, a weryfikacja spełnienia innych warunków jest pomijana.
Tym samym w sytuacji, gdy pracownik wymagałby realizacji szkolenia BHP oraz potrzebowałby telefonu model nie zadziałałby zgodnie z naszym potrzebami, bo bramka uruchomiłaby tylko jedną ścieżkę, w zależności od tego, który warunek zostałby spełniony jako pierwszy. W konsekwencji bramka łącząca typu XOR zostałaby aktywowana, gdy dotrze do niej jeden przepływ z aktywowanej ścieżki, co oczywiście logicznie jest błędne, bo celem tego procesu jest realizacja nie jednego (pierwszego) a wszystkich działań onboardingowych wynikających ze zdefiniowanych potrzeb pracownika.
Rysunek nr 9 Model procesu z zastosowaniem bramki OR dzielącej i XOR łączącej (niezgodny z logiką omawianego procesu)
Przeanalizujmy jeszcze inny wariant. Przy punkcie decyzyjnym zastosujemy bramkę Inclusive, natomiast do scalenia ścieżek wykorzystamy bramkę łączącą typu XOR (Rysunek nr 9).
Oczywiście, na wejściu dzięki zastosowaniu bramki decyzyjnej typu OR sprawdzone zostanie spełnienie wszystkich określonych warunków na bramach. Możliwe będzie zatem w przypadku spełnienia warunku uruchomienie jednej lub dwóch niewykluczających się ścieżek alternatywnych („Przekazanie telefonu” lub „Realizacja szkolenia BHP”) albo ścieżki wynikającej z niespełnienia min. żadnego z powyższych warunków „Onboarding niepotrzebny”.
Jak jednak zadziała bramką łącząca XOR? Kolokwialnie mówiąc bramka łącząca typu XOR przepuści wszystko co do niej trafi. Tym samym, jeśli zostanie zakończone zadanie „Realizacja szkolenia BHP” bramka spowoduje przejście procesu do zadania „Sporządzenie raportu”.
Jeśli natomiast następnie zostanie zakończone zadanie „Przekazanie telefonu” bramka ponownie spowoduje rozpoczęcie zadania „Sporządzenie raportu”. Innymi słowy bramka typu XOR nie będzie ówcześnie uzbrojona w wiedzę co się zadziało na bramce decyzyjnej i nie będzie czekać na dotarcie do bramki wszystkich aktywowanych ścieżek, celem ich scalenia tylko uaktywni czynność znajdującą się za bramką tyle razy, ile ścieżek do niej dotrze.
W takim wiec przypadku zadanie „Sporządzenie raportu” mogłoby zostać uruchomione dwa razy. Nie jest to celem naszego procesu, bo chcemy sporządzić jeden raport onboardingowy zawierający informacje o wszystkich zrealizowanych czynnościach.
Powyższe dwa przykłady formalnie poprawnych, lecz logicznie niecelowych modeli są wizualizacją często pojawiających się błędów popełnianych na etapie modelowania i interpretowania procesów biznesowych. Zrozumienie zasad dzielenia i łączenia przepływów jest kluczowe z punktu widzenia tworzenia wykonywalnych i logicznych biznesowo modeli zgodnie z potrzebami biznesowymi Klienta lub pozostałych odbiorców korzystających z opracowywanej dokumentacji.
Omówmy zatem sposób działania kolejnej często wykorzystywanej w modelu procesów bramki.
Jeśli modelujemy proces, w którym jakieś czynności realizowane są w sposób niezależny stosujemy tzw. Bramkę równoległą (AND) (Parallel Gateway).
W notacji BPMN 2.0 bramka ta jest reprezentowana symbolem diamentu ze znakiem (+) wewnątrz. Tak jak pozostałe omawiane bramki, może ona mieć charakter rozwidlający proces na dwie lub więcej niezależnie realizowanych ścieżek oraz może występować jako bramka synchronizująca, która łączy niezależne, współbieżne fragmenty procesu.
Rysunek nr 10 przedstawia przykład zastosowania bramki równoległej i synchronizującej.
Rysunek nr 10 Model procesu wykorzystujący bramki Parallel
Kiedy wpłynie zamówienie jest ono analizowane. Następnie proces dzieli się na trzy niezależnie realizowane ścieżki. Współbieżnie realizowane są zadania:
Celowo używam sformułowania „niezależnie realizowane ścieżki” zamiast „jednocześnie realizowane ścieżki”. Powyższe trzy zadania nie muszą być realizowane jednocześnie tj. w tym samym czasie. Realizacja każdego z nich przebiega w sposób od siebie niezależny, niepowiązany ze sobą. Bramka synchronizująca czekać będzie na zakończenie aktywności w każdej ze ścieżek. Możliwe są zatem sytuacje, gdzie np. „Wystawienie faktury VAT” nastąpi przed rozpoczęciem zadania „Kompletowanie zamówionych produktów” lub zadania „Dołączenie produktów promocyjnych”. A zadanie „Dołączenie produktów promocyjnych” odbędzie się po zadaniu „Skompletowanie zamówionych produktów”. Dopiero kiedy wszystkie ścieżki zostaną zakończone i dotrą do bramki synchronizującej bramka scali współbieżne procesy w jeden i nastąpi przejście do zadania „Wysyłka zamówienia”.
Sposób działania bramki Parallel jest zatem inny niż bramek warunkowych typu XOR czy OR. Tam przebieg procesu uwarunkowany był spełnieniem warunków aktywujących dany przebieg procesu (weryfikacja spełnienia jednego przy bramce typu XOR oraz wszystkich warunków przy bramce OR). W tym przypadku nie weryfikujemy spełnienia warunków a ścieżki współbieżne aktywują się automatycznie po zakończeniu aktywności (lub zaistnienia zdarzenia) poprzedzającej zastosowaną bramkę.
Rysunek nr 11 Model procesu z pominięciem bramki równoległej
Notacja BPMN pozwala na zastosowanie zrównoleglenia ścieżek także bez bramki równoległej (Rysunek nr 11).
W takim przypadku proces zadziała identycznie jak na omówionym wyżej przykładzie (Rysunek nr 10). Trzy przepływy wychodzące z zadania „Analiza zamówienia” spowodują uruchomienie trzech niezależnych ścieżek procesu. W momencie, kiedy wszystkie trzy zostaną zrealizowane bramka synchronizująca scali proces i nastąpi realizacja zadania „Wysłanie zamówienia”.
O ile ominiecie bramki równoległej jest dozwolone w przypadku rozgałęziania procesu to w przypadku synchronizacji i łączenia procesów nadal wymagane jest zastosowanie bramki synchronizującej. Częstym błędem w modelowaniu jest pomijanie bramki synchronizującej przy scalaniu procesów poprzez intuicyjne zastosowanie analogii do możliwości zastosowania bezpośrednio przepływów wychodzących z zadania, co oznaczać będzie uruchomienie ścieżek współbieżnych Rysunek nr 12).
Rysunek nr 12 Model procesu z pominięciem bramki równoległej oraz bramki synchronizującej (błędny)
Jak zachowa się zatem proces na podstawie takiego modelu? Przez to, że przed zadaniem „Wysłanie zamówienia” nie zastosowaliśmy bramki synchronizującej do tego zadania dotrą trzy przepływy wchodzące z trzech niezależnych, współbieżnych ścieżek. Proces zachowa się tak, jakby przez zadaniem ”Wysłanie zamówienia” pojawiła się brama łącząca typu XOR.
Jak wspomniałem wyżej bramka ta nie ma „wiedzy”, co wydarzyło się wcześniej na bramce rozdzielającej, jest „przeźroczysta” i przepuści wszystkie przepływy, które do niej dotrą, nie będzie czekać na zakończenie wszystkich ścieżek celem ich scalenia. Tym samym czynność „Wysłanie zamówienia” zgodnie z modelem wykonałaby się aż trzykrotnie, po zakończeniu każdej z poszczególnych ścieżek współbieżnych, co oczywiste nie jest celem naszego procesu.
W powyższym artykule skupiłem się na omówieniu kilku (ale nie wszystkich) bramek wykorzystywanych w modelowaniu z użyciem notacji BPMN 2.0. Zrozumienie działania bramek, będących jednym z najczęściej wykorzystywanych elementów notacji jest kluczowe do prawidłowego modelowania procesów oraz czytania i interpretacji diagramów.
Dlatego skupiłem się na przekazaniu praktycznej wiedzy, omówieniu zależności i najczęściej występujących błędów w modelowaniu z użyciem (lub z pominięciem) bramek. Wszystkich zainteresowanych poznaniem dogłębnie notacji BPMN 2.0 zachęcam do zapoznania się ze specyfikacją, którą można znaleźć na stronie organizacji Object Management Group oraz do wzięcia udziału w autorskim webinarze dotyczącym Mapowania Procesów Biznesowych na który można rejestrować się TUTAJ >>>
