Modelowanie logiki procesów biznesowych zgodnie z BPMN 2.0

Bramki w notacji BPMN to podstawowy mechanizm projektowania i prezentowania logiki przepływu procesu biznesowego.
Modelowanie logiki procesów biznesowych zgodnie z BPMN 2.0

Bramki w notacji BPMN to podstawowy mechanizm projektowania i prezentowania logiki przepływu procesu biznesowego.

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.

Bramka wykluczająca XOR (Exclusive Gateway)

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:

Obraz zawierający diagram, linia, Czcionka, zrzut ekranuOpis wygenerowany automatycznie

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).  

Obraz zawierający diagram, Plan, Rysunek techniczny, tekstOpis wygenerowany automatycznie

Rysunek nr 2 Model procesu z zastosowaniem bramki XOR ze ścieżką domyślną

Oto warianty zachowania procesu:

  1. Jeśli wniosek wymaga poprawek nastąpi zadanie „Poprawa wniosku”, po czym proces zapętli się i wróci do zadania „Ocena wniosku”

albo

  1. Jeśli wniosek został negatywnie oceniony nastąpi zadanie „Odrzucenie wniosku”

albo

  1. „Przyjęcie wniosku”. Ta alternatywa przebiegu procesu ma charakter domyślny i na modelu oznaczona jest znakiem ukośnika umieszczonego na linii z zamkniętym grotem oznaczającej Przebieg Domyślny dla Wyrażenia Warunkowego (Default Sequence Flow).

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.  

Obraz zawierający diagram, linia, Plan, Rysunek technicznyOpis wygenerowany automatycznie

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).  

Obraz zawierający diagram, linia, Czcionka, PlanOpis wygenerowany automatycznie

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:

Obraz zawierający diagram, linia, Czcionka, białyOpis wygenerowany automatycznie

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

Obraz zawierający diagram, linia, szkic, PlanOpis wygenerowany automatycznie

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.

Bramka niewykluczająca OR (Incclusive Gateway)

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).

Obraz zawierający diagram, linia, tekst, PlanOpis wygenerowany automatycznie

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:

  1. Pracownik potrzebuje telefonu służbowego.
  1. Pracownik zatrudniony jest na umowę o pracę.

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:

  1. Pracownikowi zostanie przeprowadzone szkolenie BHP i przekazany telefon służbowy.
  1. Pracownik jedynie weźmie udział w szkoleniu BHP.
  1. Pracownik jedynie otrzyma telefon służbowy.
  1. Pracownik nie zostanie objęty żadnym działaniem.

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”.

Obraz zawierający diagram, tekst, linia, PlanOpis wygenerowany automatycznie

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.

Obraz zawierający diagram, tekst, linia, PlanOpis wygenerowany automatycznie

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).

Jak zachowa proces na podstawie takiego diagramu?

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.

Bramka równoległa (Parallel Gateway)

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.

Obraz zawierający diagram, linia, Plan, CzcionkaOpis wygenerowany automatycznie

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:

  1. Kompletowanie zamówionych produktów
  1. Wystawienie faktury VAT
  1. Dołączenie produktów promocyjnych.

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ę.

Obraz zawierający diagram, linia, Plan, Rysunek technicznyOpis wygenerowany automatycznie

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).

Obraz zawierający diagram, Plan, linia, Rysunek technicznyOpis wygenerowany automatycznie

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.

Podsumowanie

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 >>>

Podziel się tą publikacją z innymi!
Tagi:
No items found.

POPULARNE W TEJ DZIEDZINIE

No items found.
No items found.
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!