Czasem uczestnicy szkolenia BPMN zadają mi powtarzające się pytanie: kiedy właściwie użyć zdarzenia brzegowego, a kiedy bramki po zadaniu? Bo przecież i tak wszystko sprowadza się do obsługi alternatywnego przebiegu procesu… Przykład. Podejmujemy decyzję (kredytową, ale może być dowolna inna). Czy brak decyzji spowodowanej brakiem odpowiedniej ilości informacji (dokumentów) zamodelować bramką za zadaniem? Czy może zrobić to zdarzeniem brzegowym, natomiast samą obsługę decyzji wykonać na bramce po wyjściu z zadania? Spotykam się z obiema sytuacjami i obie sytuacje mogą wydawać się prawidłowe. Chodzi przecież o zrozumienie. Jeśli wszyscy się rozumieją, po co komplikować sytuację i używać wielu elementów notacji. Czy nie warto zrezygnować ze zdarzeń w ogóle?      

Bez zdarzenia brzegowego

Ze zdarzeniem brzegowym

Po pierwsze chciałbym dobrze zrozumieć powyższą sytuację, żeby móc odwzorować ją w sposób wyczerpujący. Dochodzę do kroku w procesie, w którym mam podjąć decyzję. Efektem kroku (czyli celem istnienia kroku) będzie wydanie decyzji, obiektem wejściowym – wniosek przygotowany do rozpatrzenia (czyli zestaw danych, w oparciu o które podejmę decyzję). Decyzję podejmuję tylko w oparciu o wszystkie wymagane dane. Niepełny wniosek (np. brak określonych danych) przerwie podejmowanie decyzji i wymusi przekazanie wniosku do innego wątku. Czyli mam sytuację, która przerwie realizację zadania i sytuację, która doprowadzi do wydania decyzji czyli zrealizowania celu kroku. Niby alternatywa ale nie do końca.  

W jaki sposób zrozumieć zadania jednolicie i jednolicie (równo) je rysować? Załóżmy na chwilę, że zadanie to zamknięta czynność (lub zestaw czynności) prowadzący do realizacji określonego celu. Modelując proces każdorazowo gdy myślę o zadaniu, myślę o efekcie jaki wywoła. Czyli podjęcie decyzji skończy się podjętą decyzją, rejestracja sprawy skończy się zarejestrowaną sprawą. Wszystko, co zaistnieje i doprowadzi do przerwania realizacji celu zadania będzie zdarzeniem brzegowym.  

Sprawa wyjaśnia się jeszcze bardziej, jeśli dodatkowo nałożę na diagram obiekty danych. Załóżmy że:    

Obiekt „wniosek kredytowy” jest potrzebny aby podjąć decyzję. Na wyjściu mam wniosek kredytowy i wydaną decyzję kredytową (w postaci obiektu „Wniosek kredytowy” wraz z różnymi statusami, przekazywanego do innych zadań). Jasno wiem co jest celem zadania i jaki obiekt „wytwarza” oraz jakie sytuacje spowodują, że zadanie nie zakończy się „wytworzeniem” oczekiwanego obiektu (bądź zmianą stanu już istniejącego). Przerwanie zadania odkrytą w trakcie prac niepełną informacją nie pozwoli wydać decyzji.  

Jak pomóc sobie w trakcie modelowania?  

1.Rysuj obiekty danych, to pomaga i weryfikuje Twój sposób myślenia. Nałożenie na proces obiektów danych zmienia pierwotny przebieg procesu – sprawia, że zadania osadzone są w kontekście danych, ich zakres zaczyna być „weryfikowalny”. Wiesz, jakie informacje potrzebne są, aby zadanie zostało zrealizowane, jakie obiekty danych są efektem realizacji zadania. Nałożenie obiektów danych pomoże Ci również dodatkowo na weryfikację, czy istotne z perspektywy procesu obiekty nie „wiszą w powietrzu” – są stworzone, ale nie wykorzystywane w procesie dalej (być może zadanie tworzące je jest nadmiarowe bądź nie przewidziano innego zadania, które taki obiekt otrzymałby na wejściu i dalej przetworzył). Następnie zamodeluj i zweryfikuj model przetwarzający obiekty i za każdym razem zastanawiaj się czym (jakim celem do osiągnięcia) kończy się zadanie. Wówczas łatwiej będzie Ci zidentyfikować sytuacje, które uniemożliwią realizację zadania i je przerwą, oraz takie, które są efektem (produktem) realizacji zadania.  

2. Zadanie w obrębie jednego uczestnika procesu (toru) tworzy, usuwa bądź zmienia obiekt biznesowy (jego stan). Takie kryterium można zastosować do identyfikowania granic zadania (generalnie do wszystkich sytuacji podczas modelowania procesu biznesowego na poziomie analitycznym). Zapewni ono równe ujmowanie zadań na całym diagramie (każde zadanie ma ten sam poziom szczegółowości; wiadomo też kiedy zadanie się pojawi). Przed umieszczeniem zadania zastanawiam się jaki obiekt przekazuję i jaki obiekt z niego wyjdzie. Zarejestrowanie, Podjęcie decyzji, Zrealizowanie bądź Poinformowanie o odrzuceniu… każdy z kroków tworzy obiekt „wniosek”, zmienia jego stan albo go usuwa. Czasem jakieś zadanie otrzymuje 3 obiekty, ale zmienia stan tylko jednego z nich. Czasem otrzymuje kilka obiektów ale na wyjściu tworzy nowy obiekt. Takie podejście do identyfikowania granic zadania na diagramie analitycznym jest bardzo spójną zasadą. Jeśli natomiast zadanie otrzymuje kolekcję obiektów danych, na wyjściu wystawia te same obiekty w niezmienionym stanie, następnie przekazuje je do kolejnego zadania, które znów nic nimi nie robi i przekazuje dalej, a wszystko w tym samym torze (realizuje je ten sam uczestnik), być może trzeba byłoby te zadania ująć w jedno. Jeśli zadanie ma stworzyć obiekt, albo zmienić jego stan i określone zdarzenie uniemożliwia mi to, stanie się zdarzeniem brzegowym przerywającym to zadanie, a nie obsługą ścieżki alternatywnej po tym zadaniu.  

3. I na koniec. Mój dodatkowy sposób na spójne modelowanie zadań i zdarzeń z nimi związanych na diagramie to forma, jakiej używam do nazywania zadań. To zdawałoby się niuans, ale bardzo przydatna zasada. Używam formy świadczącej o wyniku zadania (formę dokonaną). „Rejestrowanie wniosku” czy „Zarejestrowanie wniosku”? Rejestrowanie może nigdy się nie skończyć. „Zarejestrowanie wniosku” sugeruje mi cel oraz wynik zadania, realizację którego mogę przerwać przy każdej zaistniałej sytuacji, która odwiedzie mnie od tego celu. Sprawdza się to również bez rysowania obiektów danych. Łatwo zorientować się, kiedy zdarzenie obsługuje wynik, kiedy wyjątek/ przerwanie.