Diagram może wyglądać logicznie i nadal zachowywać się błędnie. Przegląd BPMN powinien obejmować semantykę tokenów, odpowiedzialność, kompletność wariantów i zgodność poziomu szczegółowości. Poniższy katalog pomaga diagnozować skutek, a nie tylko poprawiać estetykę.
| Błąd | Skutek | Naprawa |
|---|---|---|
| Mieszanie „Rozpatrz wniosek” z „Kliknij Zapisz” | Brak wspólnego poziomu i nieczytelny zakres | Ustal odbiorcę; szczegół przenieś do podprocesu |
| Tory jako etapy, nie role | Nie wiadomo, kto odpowiada | Tory nazwij wykonawcami, etapy oznacz grupą |
| AND-split połączony XOR-join | Następne zadanie wykona się wielokrotnie | Synchronizuj AND-join, jeśli czekasz na wszystkie tokeny |
| XOR-split połączony AND-join | Zakleszczenie na nieaktywnej gałęzi | Użyj XOR-join lub przebuduj logikę |
| Bramka bez warunków | Nie da się przewidzieć ścieżki | Nazwij reguły, granice i ścieżkę domyślną |
| Tylko happy path | Wyjątki wracają do e-maili i pracy ręcznej | Dodaj brak danych, odrzucenie, błąd, timeout i anulowanie |
Przypadek: onboarding pracownika
Model po akceptacji zatrudnienia uruchamiał przez AND przygotowanie laptopa i konta. Konto mogło jednak zostać pominięte dla współpracownika zewnętrznego. Obie ścieżki łączył AND-join, który zawsze czekał na konto — proces zakleszczał się. Autor dodał też timer jako zwykłe zdarzenie w przepływie, więc proces czekał trzy dni nawet wtedy, gdy sprzęt był gotowy wcześniej.
Po poprawie OR uruchamiał wymagane zestawy przygotowań, a OR-join czekał tylko na aktywne gałęzie. Timer stał się nieprzerywającym zdarzeniem brzegowym wysyłającym przypomnienie. Osobny przerywający termin eskalował sprawę po pięciu dniach. Przejście tokenem dla pracownika, współpracownika i osoby bez sprzętu potwierdziło poprawne zachowanie.
Błędy komunikacji między uczestnikami
Przepływ sekwencji nie może przekraczać granicy basenu. Między klientem, organizacją i zewnętrznym operatorem stosuje się przepływy komunikatów. Sam message flow nie oznacza jednak, że odbiorca poprawnie skoreluje wiadomość ze sprawą. Model powinien wskazać oczekiwanie, błąd lub timeout, jeśli komunikat może nie nadejść. Częstym błędem jest też narysowanie wysłania wiadomości bez żadnego odbiorcy albo procesu odbiorcy bez zdarzenia inicjującego.
Błędy granicy i zakończenia
Start „Rozpoczęto proces” nie mówi, co tworzy instancję. Koniec „Koniec” nie ujawnia rezultatu. Nazywaj rezultaty: „wniosek odrzucony”, „umowa aktywna”, „sprawa anulowana”. Sprawdź, czy none end kończy tylko jedną gałąź, czy naprawdę potrzebny jest terminate end usuwający wszystkie tokeny. Nie używaj terminate jako szybkiej naprawy źle zaprojektowanej synchronizacji.
Błędy treści, których walidator notacji nie wykryje
- Nazwa zadania nie opisuje rezultatu albo maskuje kilka decyzji.
- Diagram przedstawia procedurę, nie rzeczywistą pracę z obejściami.
- Reguła „kompletne / niekompletne” nie ma definicji i właściciela.
- Baseny sugerują komunikację, choć uczestnicy należą do jednej organizacyjnej orkiestracji.
- Zakończenia są identyczne wizualnie, mimo różnych rezultatów biznesowych.
- Model nie ma wersji, celu ani powiązania z wymaganiami.
Czytelność jest warunkiem walidacji
Ogranicz krzyżowanie strzałek, zachowuj jeden kierunek przepływu i rozwijaj złożone fragmenty w podprocesach. Nie powtarzaj tego samego kroku tylko po to, aby uniknąć długiej linii — odbiorca może uznać kopie za dwie różne aktywności. Używaj adnotacji do wyjaśnienia zakresu, lecz reguły zarządzaj w powiązanym artefakcie. Diagram powinien dać się wydrukować lub wyświetlić bez mikroskopijnego tekstu.
Procedura przeglądu
- Sprawdź granicę, starty, końce i poziom modelu.
- Przejdź tokenem każdą kombinację bramek; szukaj czekania i duplikacji.
- Zweryfikuj role oraz komunikację przez granice basenów.
- Odegraj rzeczywiste sprawy: typową, graniczną, błędną i anulowaną.
- Porównaj model z wymaganiami, procedurą, logami i wiedzą wykonawców.
- Zapisz nie tylko poprawkę, ale też decyzję i wpływ na inne artefakty.
Błędy wersjonowania i zakresu
Diagram bez daty i statusu łatwo zaczyna funkcjonować jako aktualny, choć przedstawia niezatwierdzony wariant. Oznaczaj AS-IS, TO-BE, wersję obowiązującą i roboczą. Przy zmianie nie nadpisuj śladu decyzji. W opisie modelu zapisz, które jednostki, produkty, kanały i typy spraw obejmuje; wyjątek spoza zakresu nie jest błędem diagramu, o ile granica została jawnie uzgodniona.
Drugim antywzorcem jest „model wszystkiego”: jeden diagram łączy proces klienta, orkiestrację systemową i obsługę techniczną integracji. Zamiast tego przygotuj widoki z kontrolowanymi powiązaniami. Zdarzenie końcowe jednego poziomu powinno odpowiadać rezultatowi widocznemu na poziomie nadrzędnym, a nazwy wspólnych obiektów powinny pochodzić ze słownika.
Walidacja z wykonawcami, nie tylko z kierownikiem
Kierownik potwierdzi odpowiedzialność formalną, lecz może nie znać ręcznych obejść i rzeczywistej kolejki. Przeglądaj model z osobami z różnych zmian oraz z odbiorcą wyniku. Poproś o wskazanie ostatniej nietypowej sprawy i odtwórz ją na diagramie. Gdy przebiegu nie da się pokazać, zapisz świadomą granicę albo uzupełnij model — nie dopowiadaj ścieżki ustnie.
Rejestr usterek modelu
Dla każdej uwagi zapisz element, scenariusz ujawniający problem, spodziewane i obecne zachowanie, skutek oraz właściciela poprawki. „Zmień bramkę” nie wystarcza, bo poprawka może naruszyć inną ścieżkę. Po zmianie powtórz przypadki przechodzące przez sąsiedni split i join. Rejestr staje się zestawem regresyjnym diagramu oraz materiałem do aktualizacji wymagań.
Checklista publikacji
- Każdy token może dotrzeć do właściwego końca bez zakleszczenia.
- Praca równoległa synchronizuje się raz i we właściwym miejscu.
- Warunki są kompletne, rozłączne tam, gdzie wymaga tego XOR, i mają domyślną ścieżkę.
- Zdarzenia brzegowe świadomie przerywają lub nie przerywają aktywności.
- Odbiorca potrafi wyjaśnić diagram bez komentarza autora.
Mechanikę tokenów rozwija materiał bramki BPMN, a zasady budowania stanu obecnego opisuje AS-IS i TO-BE.
