BPMN, czyli Business Process Model and Notation, służy do opisywania przebiegu pracy w sposób czytelny dla biznesu i dostatecznie precyzyjny dla zespołu wdrożeniowego. Na początek nie trzeba znać całej notacji. Wystarczy umieć prześledzić, co uruchamia proces, kto wykonuje pracę, gdzie wybierana jest ścieżka i jak proces się kończy.
Czytaj diagram jak ruch tokenu
Wyobraź sobie znacznik — token — pojawiający się w zdarzeniu startowym. Przesuwa się on po przepływach sekwencji. Gdy dociera do zadania, praca musi zostać wykonana. Przy bramce token wybiera jedną ścieżkę albo dzieli się na kilka, zależnie od typu bramki. Zdarzenie końcowe pochłania token. To proste wyobrażenie ujawnia, czy diagram może utknąć, uruchomić dwie czynności naraz albo zakończyć się inaczej, niż zakłada autor.
| Element | Jak go rozpoznać | Pytanie przy czytaniu |
|---|---|---|
| Zdarzenie | Okrąg; cienka, podwójna lub gruba krawędź | Co się stało i czy proces czeka? |
| Zadanie | Prostokąt z zaokrąglonymi rogami | Kto wykonuje jaką pracę i z jakim wynikiem? |
| Bramka | Romb ze znacznikiem typu | Czy wybieramy, uruchamiamy równolegle czy czekamy? |
| Przepływ sekwencji | Ciągła strzałka | Jaki jest następny krok w tym samym uczestniku? |
| Przepływ komunikatu | Przerywana linia z otwartą strzałką | Co wysyłają sobie odrębni uczestnicy? |
| Basen i tor | Obszar uczestnika oraz jego podział | Kto odpowiada za czynność? |
Przypadek: wniosek o dostęp do systemu
Pracownik składa wniosek. Przełożony ocenia zasadność. Jeśli odrzuci wniosek, pracownik dostaje informację i proces się kończy. Jeśli zatwierdzi, administrator nadaje dostęp, a system wysyła potwierdzenie. Gdy administrator nie wykona zadania przez dwa dni robocze, sprawa trafia do eskalacji.
Tekstowy szkic przepływu
○ Otrzymano wniosek → [Oceń zasadność] → ◇ decyzja XOR → „nie”: [Powiadom o odrzuceniu] → ● Odrzucono; „tak”: [Nadaj dostęp] z timerem 2 dni → [Wyślij potwierdzenie] → ● Dostęp nadany. Timer prowadzi do [Eskaluj sprawę] i dalej do ponownej obsługi.
Ten zapis nie zastępuje diagramu, ale pomaga ustalić semantykę przed rysowaniem. XOR oznacza, że dla jednego tokenu wybierana jest dokładnie jedna z alternatyw. Timer przypięty do zadania opisuje reakcję na upływ czasu. Role należy umieścić w torach: pracownik, przełożony i administrator. Jeżeli pracownik jest zewnętrznym uczestnikiem, warto modelować go jako osobny basen i użyć komunikatów zamiast przepływów sekwencji.
Pięć kroków czytania diagramu
- Znajdź granice: co inicjuje instancję procesu i jakie ma ona możliwe zakończenia.
- Przejdź ścieżkę podstawową: bez wyjątków, od lewej do prawej lub zgodnie ze strzałkami.
- Sprawdź odpowiedzialność: każda czynność leży w torze wykonawcy, nie w torze obiektu.
- Odczytaj warunki: nazwa strzałki mówi, kiedy ścieżka jest aktywna; pytanie nie powinno wisieć bez odpowiedzi.
- Odegraj wyjątki: brak danych, odrzucenie, anulowanie, błąd i przekroczenie czasu.
Trzy typy rozdzielenia, które trzeba odróżnić
Bramka XOR wybiera jedną ścieżkę na podstawie danych, np. „zaakceptowano / odrzucono”. AND uruchamia wszystkie ścieżki równocześnie, np. przygotowanie konta i sprzętu; odpowiadający join czeka na token z każdej aktywnej gałęzi. OR uruchamia jedną lub kilka ścieżek spełniających warunki i przy łączeniu czeka tylko na te, które rzeczywiście wystartowały. Szczegółowe przykłady zawiera materiał bramki BPMN.
Najczęstsze nieporozumienia na starcie
- Romb nie zawsze oznacza pytanie; bramka może również synchronizować równoległe tokeny.
- Tor nie jest etapem procesu. Oznacza odpowiedzialność uczestnika lub roli.
- Zdarzenie opisuje fakt lub oczekiwanie, a zadanie pracę. „Odbierz zgłoszenie” i „Zgłoszenie otrzymane” mają inną semantykę.
- Diagram biznesowy nie powinien mieszać czynności „Rozpatrz wniosek” z kliknięciami interfejsu.
- Wiele zdarzeń końcowych jest dopuszczalnych; warto nazwać ich rezultat, np. „dostęp nadany” i „wniosek odrzucony”.
Checklista pierwszego modelu
- Cel i granica procesu są zapisane jednym zdaniem.
- Nazwy zadań zaczynają się od czasownika i opisują rezultat pracy.
- Każda ścieżka ma warunek, wykonawcę i możliwe zakończenie.
- Rozdzielenie oraz łączenie tokenów odpowiada rzeczywistemu zachowaniu.
- Diagram został przejrzany na przykładzie prawdziwej sprawy, nie tylko „na sucho”.
Basen, tor i granica odpowiedzialności
Basen reprezentuje niezależnego uczestnika procesu, na przykład klienta i organizację. Pomiędzy basenami przesyła się komunikaty; nie prowadzi się przepływu sekwencji. Tory dzielą jeden basen na role lub jednostki odpowiedzialne za zadania. Nie umieszczaj dokumentu ani systemu w torze, jeżeli nie jest wykonawcą. Tor „Wniosek” nie wyjaśnia odpowiedzialności, a tor „Dział obsługi” — tak.
W przykładzie dostępu pracownik może być osobnym basenem, jeśli model opisuje usługę organizacji dla uczestnika zewnętrznego. Złożenie wniosku i potwierdzenie są wtedy komunikatami. Jeśli natomiast modelujesz wewnętrzną orkiestrację firmy, pracownik, przełożony i administrator mogą być torami jednego basenu. Wybór zależy od celu modelu, ale powinien być konsekwentny.
Jak ćwiczyć bez rozbudowanego narzędzia
Weź jedną zakończoną sprawę i zapisz na karteczkach zdarzenia, pracę, decyzje oraz rezultaty. Ułóż ścieżkę typową, a potem zmień jedną informację: brak załącznika, odmowa albo przekroczenie czasu. Dopiero po uzgodnieniu przebiegu dobierz symbole. Druga osoba powinna przejść model bez wyjaśnień autora i powiedzieć, ile tokenów istnieje po każdej bramce.
Jeżeli model staje się zbyt duży, nazwij podproces i pokaż jego rozwinięcie osobno. Widok nadrzędny musi zachować te same wejścia i możliwe rezultaty. Dzięki temu odbiorca rozumie całość, a zespół analizuje szczegóły bez zmniejszania diagramu do nieczytelnego plakatu.
Po opanowaniu tej podstawy warto osobno poznać typy zadań BPMN oraz zdarzenia i obsługę czasu. Notacja jest środkiem do wspólnego rozumienia pracy. Poprawny model to taki, którego ścieżki dają się jednoznacznie odegrać i zweryfikować z osobami wykonującymi proces.
