Zamawiający nie musi znać wszystkich znaczników BPMN, aby skutecznie odebrać model. Powinien natomiast potrafić odpowiedzieć, czy diagram pokazuje właściwy zakres, odpowiedzialność i zachowanie w sytuacjach innych niż ścieżka idealna. Ładny obraz nie jest dowodem kompletności procesu.
Co diagram ma rozstrzygać
Przed przeglądem zapisz cel modelu. Diagram koncepcyjny ma wyjaśnić współpracę jednostek; model operacyjny może służyć do zmiany procedury; model wykonawczy opisuje zachowanie automatyzacji. Ocena wszystkich według tego samego poziomu prowadzi albo do nadmiernego szczegółu, albo do braków. Zamawiający powinien oczekiwać jawnej informacji: kto jest odbiorcą, jaki wariant procesu przedstawiono i czego celowo nie modelowano.
Przegląd w sześciu rozmowach
| Obszar | Pytanie zamawiającego | Oczekiwany dowód |
|---|---|---|
| Granica | Co uruchamia sprawę i kiedy uznajemy ją za zakończoną? | Nazwane starty i rezultaty końcowe |
| Role | Kto wykonuje, zatwierdza i odpowiada za wynik? | Zadania w torach rzeczywistych ról |
| Reguły | Na jakiej podstawie wybierana jest ścieżka? | Warunki, właściciel i źródło reguły |
| Czas | Gdzie czekamy i co dzieje się po terminie? | Timery, eskalacje i terminy biznesowe |
| Wyjątki | Co przy braku danych, błędzie, rezygnacji lub powtórzeniu? | Ścieżki negatywne z zakończeniem |
| Zakres systemu | Które kroki są ręczne, a które wspiera rozwiązanie? | Powiązanie z wymaganiami i interfejsami |
Przypadek: odbiór procesu akceptacji faktury
Dostawca pokazał diagram: rejestracja faktury, weryfikacja, akceptacja, księgowanie i płatność. Wszystko mieściło się na jednej prostej linii. Zamawiający przeszedł jednak przez rzeczywistą fakturę bez numeru zamówienia. Okazało się, że dokument wraca do zgłaszającego, ale nie wiadomo na jak długo. Następnie zapytał o fakturę powyżej limitu dyrektora i fakturę dotyczącą dwóch centrów kosztów. Każdy przypadek ujawnił nową, ręczną ścieżkę.
Po poprawie model zawierał równoległą kontrolę formalną i merytoryczną, tabelę progów akceptacji, timer przypominający oraz eskalację po trzech dniach. Faktura bez zamówienia nie była po prostu „odrzucona”: trafiała do wyjaśnienia, mogła wrócić poprawiona albo zakończyć się statusem „nieprzyjęta”. Dzięki temu zamawiający zobaczył nie tylko automatyzację, ale również pracę, która pozostaje po stronie organizacji.
Artefakt odbiorowy: karta ścieżki
Dla ważnych wariantów warto do diagramu dołączyć krótką kartę. Pozwala ona odbierać znaczenie, a nie położenie symboli.
| Pole | Przykład dla faktury bez zamówienia |
|---|---|
| Wyzwalacz | System wykrywa brak numeru zamówienia przy rejestracji |
| Odpowiedzialny | Zgłaszający koszt |
| Termin | 2 dni robocze; potem przypomnienie, po 5 dniach eskalacja |
| Rezultat pozytywny | Uzupełnione uzasadnienie i powrót do kontroli |
| Rezultat negatywny | Faktura nieprzyjęta z kodem przyczyny |
| Powiązane wymagania | REQ-FIN-14, REQ-FIN-18, NFR-NOT-03 |
Jak rozmawiać o bramkach bez nauki symboli
Zapytaj, czy w danym miejscu wykonywana jest jedna alternatywa, wszystkie czynności, czy dowolny zestaw spełniający warunki. Pierwsza sytuacja odpowiada zwykle XOR, druga AND, trzecia OR. Przy łączeniu trzeba ustalić, na które ścieżki proces czeka. Szczególnie niebezpieczne jest rozdzielenie równoległe i połączenie wykluczające: dwa tokeny mogą uruchomić następny krok dwukrotnie. Techniczne wyjaśnienie split/join znajduje się w artykule bramki BPMN.
Sygnały ostrzegawcze
- Diagram pokazuje tylko wariant udany, choć rzeczywiste sprawy wracają, wygasają lub są anulowane.
- Nazwy zadań typu „obsługa”, „weryfikacja” i „system” nie mówią, jaki rezultat powstaje.
- Warunki brzmią „OK / nie OK”, ale nie mają definicji ani właściciela.
- Automatyczne i ręczne kroki są nierozróżnialne, więc zakres wdrożenia pozostaje ukryty.
- Diagram zawiera kilkadziesiąt skrzyżowanych strzałek, a autor nie potrafi odegrać konkretnej sprawy.
- Zmiana diagramu nie prowadzi do aktualizacji wymagań, instrukcji ani testów.
Checklista zatwierdzenia
- Model ma określony cel, poziom szczegółowości, właściciela i datę wersji.
- Odegrano co najmniej przypadek typowy, odrzucenie, brak danych, timeout i anulowanie.
- Każda reguła ma źródło, a każdy krok wykonawcę i mierzalny rezultat.
- Wiadomo, które zmiany dotyczą organizacji, systemu, integracji i danych.
- Diagram jest powiązany z wymaganiami oraz kryteriami odbioru, nie istnieje jako osobny obrazek.
Jak prowadzić spotkanie odbiorowe
Zamiast prezentacji od początku do końca wybierz pięć konkretnych spraw i poproś autora o przeprowadzenie tokenu. Przy każdym kroku pytaj o wykonawcę, dane wejściowe, rezultat oraz zachowanie po błędzie. Decyzje zapisuj obok identyfikatora elementu diagramu. Nie poprawiaj symboli podczas rozmowy biznesowej, jeżeli najpierw trzeba rozstrzygnąć regułę — notacja ma odwzorować ustalenie, a nie je zastąpić.
Po spotkaniu powinna powstać lista: zaakceptowane ścieżki, pytania z właścicielem i terminem, zmiany zakresu oraz wpływ na wymagania. „Diagram zaakceptowany z uwagami” jest zbyt nieprecyzyjne, gdy uwaga dotyczy progu finansowego albo odpowiedzialności. Wersja po poprawkach wymaga krótkiego przeglądu regresyjnego ścieżek, które mogły zostać naruszone.
Kryteria gotowości do odbioru
Dostawca powinien wcześniej przekazać wersję, legendę użytych rozszerzeń, listę otwartych pytań i powiązania z zakresem. Model z nierozstrzygniętą regułą można omówić, ale nie zatwierdzać jako podstawy implementacji. Zamawiający zapewnia obecność właścicieli reguł i osób wykonujących proces; sam sponsor nie potwierdzi wszystkich operacyjnych wyjątków.
Odbiór nie wymaga, aby każdy szczegół znalazł się na płótnie. Wymaga natomiast, aby szczegóły istotne dla zachowania miały wskazany artefakt: tabelę decyzji, wymaganie, słownik danych albo instrukcję. Brak miejsca na diagramie nie może oznaczać braku odpowiedzialności.
Dobry odbiór modelu kończy się listą decyzji, pytań i zakresu zmian. Jeśli potrzebujesz podstaw czytania symboli, zacznij od BPMN dla początkujących. Gdy model opisuje przejście od obecnej pracy do rozwiązania docelowego, użyj także metody AS-IS i TO-BE.
