Zadanie w BPMN oznacza jednostkę pracy wykonywaną w procesie. Powinno mieć wykonawcę, wyraźny początek i rezultat istotny na poziomie modelu. „Wniosek otrzymany” jest zdarzeniem, „czy wniosek poprawny?” — decyzją, a „Sprawdź kompletność wniosku” — zadaniem.
Nazwa zadania jest miniaturową umową
Stosuj czasownik i obiekt: „Zweryfikuj rachunek dostawcy”, „Nadaj numer sprawy”, „Wyślij prośbę o uzupełnienie”. Unikaj samotnych rzeczowników („Weryfikacja”), nazw aplikacji („CRM”) i rezultatów bez pracy („Faktura zaakceptowana”). Jeśli potrzebujesz doprecyzowania, opis zadania może zawierać wejście, wyjście, regułę i definicję ukończenia — nie upychaj ich wszystkich w prostokącie.
| Typ | Kto wykonuje | Kiedy użyć | Przykład |
|---|---|---|---|
| User task | Człowiek z pomocą systemu | Praca ma trafić na listę zadań aplikacji | Zweryfikuj dane klienta |
| Manual task | Człowiek poza silnikiem procesu | Praca fizyczna lub organizacyjna | Oznacz paczkę etykietą |
| Service task | Usługa automatyczna | Wywołanie systemu lub integracji | Pobierz kurs waluty |
| Business rule task | Silnik reguł | Wyliczenie decyzji z jawnej tabeli reguł | Wyznacz poziom ryzyka |
| Send task | Uczestnik wysyłający | Wysłanie komunikatu kończy pracę | Wyślij zlecenie do przewoźnika |
| Receive task | Uczestnik czekający | Proces oczekuje na jeden komunikat | Odbierz potwierdzenie dostawy |
User task nie znaczy „każde kliknięcie”
Na modelu biznesowym zadanie „Rozpatrz wniosek” może obejmować otwarcie danych, sprawdzenie załączników i zapis decyzji. Rozbij je, gdy kroki mają różnych wykonawców, mogą być rozdzielone oczekiwaniem, prowadzą do niezależnych rezultatów albo wymagają osobnej kontroli. Nie rozbijaj tylko po to, aby odwzorować każdy ekran. Poziom szczegółowości powinien wspierać cel diagramu.
Przypadek: realizacja wysyłki
Pierwsza wersja procesu zawierała zadania „System magazynowy”, „Pakowanie” i „Kurier”. Nie było wiadomo, co robi system ani kiedy praca jest skończona. Po warsztacie powstał przepływ: service task „Zarezerwuj towar”, user task „Potwierdź kompletację”, manual task „Zapakuj przesyłkę”, service task „Wygeneruj etykietę”, send task „Wyślij zlecenie odbioru” i receive task „Odbierz numer śledzenia”.
Model ujawnił wyjątek: etykieta może nie powstać z powodu błędnego adresu. Do service task dołączono przerywające zdarzenie błędu kierujące do user task „Popraw dane dostawy”. Do receive task dodano timer; po dwóch godzinach następuje sprawdzenie statusu integracji. Typy zadań pomogły odróżnić pracę magazyniera, działanie automatyczne i oczekiwanie na zewnętrzną wiadomość.
Karta zadania jako artefakt uzupełniający
| Pole | Przykład: Potwierdź kompletację |
|---|---|
| Wykonawca | Magazynier przypisany do strefy |
| Wejście | Lista rezerwacji i zeskanowane pozycje |
| Rezultat | Kompletacja potwierdzona albo zgłoszony brak |
| Reguła | Numer partii wymagany dla towarów śledzonych |
| Termin | 30 minut od przydzielenia |
| Powiązanie | REQ-WMS-31, ekran K-04, KPI czasu kompletacji |
Zadanie, podproces czy wywołanie?
Jeżeli fragment ma wiele kroków, własne wyjątki i może być analizowany osobno, użyj podprocesu. Call activity jest właściwe, gdy ten sam, niezależnie zarządzany proces jest wywoływany z wielu miejsc. Zwykłe zadanie pozostaw wtedy, gdy wewnętrzna realizacja nie ma znaczenia dla odbiorcy modelu. Rozwinięcie powinno zachować zgodne wejścia i zakończenia z widokiem nadrzędnym.
Checklista zadania
- Nazwa opisuje czynność i obiekt, a nie dział, system lub stan.
- Tor wskazuje rzeczywistego wykonawcę; typ zadania zgadza się ze sposobem pracy.
- Można określić wejście, rezultat i moment ukończenia.
- Poziom szczegółowości jest spójny z sąsiednimi elementami.
- Błąd, timeout i anulowanie mają jawne zachowanie, jeśli są istotne.
Pętla, multi-instance i powtarzalna praca
Znacznik pętli oznacza ponawianie tej samej aktywności do spełnienia warunku, np. „Popraw dane” aż formularz przejdzie walidację. Multi-instance tworzy osobne wykonanie dla elementów kolekcji: każdej pozycji zamówienia albo każdego wybranego eksperta. Wariant równoległy uruchamia instancje jednocześnie, sekwencyjny — po kolei. Ustal warunek zakończenia; czasem wystarczy wynik dwóch z trzech recenzentów, więc oczekiwanie na wszystkich byłoby błędem.
Nie używaj pętli do ukrycia niekontrolowanego „próbuj do skutku”. Określ limit, timeout i ścieżkę po wyczerpaniu prób. Dla service task ponawianie powinno rozróżniać błąd przejściowy od biznesowego odrzucenia. Ponowienie żądania musi też być bezpieczne: integracja nie może utworzyć drugiej płatności lub wysyłki.
Granica transakcji i kompensacja
Jeśli zestaw działań musi zostać logicznie wycofany, rozważ podproces transakcyjny i kompensację. Kompensacja nie cofa czasu; uruchamia uzgodnioną pracę odwrotną, np. zwolnienie rezerwacji po anulowaniu zamówienia. Każde działanie kompensacyjne powinno mieć właściciela, dane potrzebne do odwrócenia skutku i obsługę sytuacji, w której samo wycofanie się nie powiedzie.
Przydział i cykl życia zadania użytkownika
User task na diagramie nie definiuje automatycznie kolejki pracy. W wymaganiach doprecyzuj regułę przydziału, możliwość przejęcia, zastępstwo, priorytet, termin i widoczność danych. Ustal stany operacyjne: dostępne, przypisane, rozpoczęte, zakończone, anulowane. Jeśli zadanie wraca po poprawce, zdecyduj, czy trafia do tej samej osoby i czy wcześniejsza decyzja pozostaje w audycie.
W procesie wysyłki „Potwierdź kompletację” może zostać przejęte przez magazyniera ze strefy. Po 30 minutach nieprzerywający timer przypomina, a po 60 minutach przerywający timer zwalnia przydział i eskaluje. Model powinien pokazać skutek procesowy; szczegółowa reguła kolejki pozostaje w wymaganiach. Takie rozdzielenie zachowuje czytelność bez utraty informacji potrzebnej do implementacji.
Dane wejściowe i wyjściowe
Obiekty danych pomagają pokazać, na czym pracuje zadanie, ale nie zastępują modelu danych. Przy ważnych dokumentach zaznacz stan, np. „wniosek roboczy” i „wniosek zatwierdzony”. Jeśli dwa zadania równolegle modyfikują ten sam obiekt, ustal regułę scalenia lub blokady — poprawna sekwencja BPMN nie rozwiązuje automatycznie konfliktu danych.
O obsłudze błędu, czasu i wiadomości przeczytasz w materiale zdarzenia BPMN. Jeśli zadania mają stać się podstawą backlogu, przejdź do łączenia BPMN z wymaganiami.
