Wstęp do tworzenia czytelnych modeli BPMN
BPMN (Business Process Model and Notation) to graficzna notacja służąca do opisywania procesów biznesowych, stworzona przez OMG (Object Management Group). Jej główną zaletą jest prostota i zrozumiałość dla wszystkich interesariuszy – pod warunkiem, że procesy są modelowane zgodnie z najlepszymi praktykami. Tylko czym są te najlepsze praktyki?
Najlepsze praktyki w modelowaniu BPMN
Ważne jest, aby zarówno zespół, jak i cała organizacja posiadała spójną konwencję tworzenia procesów. Przedstawione poniżej zasady to przykład takiej właśnie konwencji, którą można wdrożyć aby poprawić jakość modelowanych procesów i uniknąć potencjalnych błędów.
Spójne nazewnictwo
W BPMN, podobnie jak w programowaniu, odpowiednie nazewnictwo jest kluczowe. Spójne nazewnictwo ułatwia wszystkim interesariuszom (zarówno technicznym, jak i nietechnicznym) zrozumienie procesu. Czytelne i zrozumiałe nazwy budują przejrzystość i pomagają w komunikacji między działami.
- Wielkość liter: Zaczynaj nazwy od wielkiej litery, a kolejne wyrazy pisz małą literą (np. Sprawdzanie dokumentów). Wyjątki stanowią nazwy własne i akronimy. Brak konsekwencji (np. naprzemienne rozpoczynanie wyrazów małą i wielką literą) utrudni szybkie rozpoznanie elementów procesu.
- Unikanie terminów technicznych: Zamiast używać klas czy metod z kodu, stosuj język zrozumiały dla biznesu. Niejasne lub zbyt techniczne nazwy mogą wprowadzić w błąd, np. użycie „ExecuteDocumentCheck” zamiast „Weryfikuj dokumenty” sprawia, że proces staje się trudniejszy do zrozumienia dla osób nietechnicznych, takich jak menedżerowie czy analitycy biznesowi.
Jak opisywać komponenty BPMN?
Zadania (Tasks)
Stosuj dopełnienie i czasownik w bezokoliczniku, aby jasno określić wykonywaną czynność, np.:
- „Sprawdzanie poczty”
- „Weryfikuj dokumenty klienta”
Podprocesy (Call Activities)
Opisuj je podobnie jak zadania – jasno i z konkretami, unikając ogólników. Nazwa procesu powinna odzwierciedlać jego działania w kontekście biznesowym.
Zdarzenia (Eventy)
Nazywaj zdarzenia w sposób odzwierciedlający stan obiektu, np.:
- „Faktura do sprawdzenia”
- „Dokumenty zweryfikowane”
- „15 minut (timer)”
Bramki (Gateways)
- Exclusive lub Inclusive Gateway: Formułuj pytania, a przepływy nazwij odpowiedziami (np. „Tak”, „Nie”). Jeśli pytanie nie jest możliwe, określ warunki wykonania każdej ścieżki.
- Event-based Gateway: Upewnij się, że kolejne zdarzenia są poprawnie nazwane. Unikaj używania innych bramek lub podprocesów w tych punktach.
Zasady modelowania procesów
Modelowanie od lewej do prawej
Twórz diagramy w logicznym kierunku od lewej do prawej, dbając o ich przejrzystość. Ludzie naturalnie czytają od lewej do prawej (w większości kultur), dlatego procesy modelowane w tym kierunku są bardziej intuicyjne. Modele stworzone „chaotycznie” (np. z przepływami w różnych kierunkach) są trudne do odczytania i mogą być źródłem nieporozumień.
Początek i koniec procesu
Zawsze uwzględniaj zdarzenie początkowe i końcowe. Zgodnie ze standardem BPMN zdarzenia początkowe są opcjonalne, o ile nie dodamy zdarzenia końcowego. Jest to niezalecana praktyka, ponieważ zaprojektowanie procesów z niejawnymi zdarzeniami początkowymi i końcowymi może doprowadzić do ich błędnej interpretacji. Brak zdarzenia początkowego sprawia, że nie wiadomo, co uruchamia proces (np. zdarzenie zewnętrzne, ręczne działanie, czas). Z kolei brak zdarzenia końcowego sugeruje, że proces trwa wiecznie, co może prowadzić do błędów w projektowaniu.
Przejrzystość bramek
Bramki są kluczowe w podejmowaniu decyzji i rozdzielaniu przepływów. Ich przejrzyste użycie pozwala jasno określić, co dzieje się na każdym etapie procesu. Chaos w modelowaniu, np. używanie tej samej bramki do rozdzielania i łączenia, może prowadzić do błędnych interpretacji procesu. Niejasne warunki w bramkach mogą powodować błędy w przepływach procesów, co skutkuje nieprzewidzianymi rezultatami. Aby bramki były czytelne:
- Używaj bramek zamiast przepływów warunkowych. (1)
- Nie łącz i nie zamykaj procesu tą samą bramką. (2)
- Stosuj ten sam typ bramek do rozdzielania i łączenia przepływów. (3)
Happy path
Trzymaj główną ścieżkę procesu („happy path”) w centrum diagramu, utrzymując proste i czytelne sekwencje przepływów. Jej przejrzystość ułatwia analizę i dalsze projektowanie procesu. Procesy z chaotycznym przepływem mogą utrudnić identyfikację głównej ścieżki, co zwiększa ryzyko przeoczenia kluczowych kroków.
Unikaj modelowania ponowień
Wśród osób projektujących modele BPMN często pojawia się pokusa modelowania ponowień. Co ciekawe jest to traktowane jako anty pattern i należy tego unikać. Modelowanie ponowień może niepotrzebnie komplikować proces. Unikanie modelowania ponowień chroni nas przed nadmiernym rozbudowaniem diagramu, które utrudnia jego zrozumienie, poniżej przykładowy antypattern
Podsumowanie
MModelowanie procesów w BPMN wymaga zwracania szczególnej uwagi na istotne detale i przestrzegania zasad, które zwiększają ich czytelność i zrozumiałość. Dzięki powyższym praktykom Twój diagram będzie bardziej klarowny, spójny i łatwiejszy do zrozumienia dla wszystkich interesariuszy.
Podobne wpisy
Czy wiesz, że w Angular 17 została wprowadzona alternatywa dla *ngFor?
