Workflow — sterowanie przepływem pracy, decyzji i odpowiedzialności

Workflow porządkuje proces, który trwa w czasie, przechodzi między rolami i wymaga zapisu stanu. Jego wartość nie polega na samym przesuwaniu zadania z kolumny do kolumny, lecz na pilnowaniu reguł, terminów, odpowiedzialności i wyjątków.

Porównaj workflow z RPA przed wyborem architektury automatyzacji.

Kiedy potrzebny jest workflow

Workflow jest przydatny, gdy sprawa ma identyfikator, status, właściciela i historię. Sprawdza się w obiegach akceptacji, reklamacjach, zamówieniach, onboardingu, obsłudze dokumentów i procesach regulowanych. Pozwala zatrzymać proces, poczekać na zdarzenie, przekazać zadanie człowiekowi i wznowić wykonanie.

Prosty skrypt wystarcza, gdy działanie jest krótkie, atomowe i nie wymaga pamiętania stanu. Jeżeli po awarii trzeba wiedzieć, na którym etapie znajdowała się każda z tysiąca spraw, skrypt bez modelu stanu szybko staje się własnym, nieudokumentowanym silnikiem workflow.

Role, statusy i SLA

Status powinien opisywać stan biznesowy, nie techniczny szczegół. „Oczekuje na akceptację” jest użyteczne, „krok_17” nie mówi nic użytkownikowi. Każdy status powinien mieć możliwe przejścia, właściciela, warunki i maksymalny czas.

SLA wymaga zegara, kalendarza biznesowego, progów ostrzegawczych i eskalacji. Samo wysłanie przypomnienia nie rozwiązuje problemu, jeżeli nikt nie odpowiada za przekroczony termin.

Model obiegu

Dobry model zawiera zdarzenie początkowe, zadania automatyczne i ludzkie, bramki decyzyjne, komunikaty, wyjątki oraz jednoznaczne zakończenia. BPMN może być użyty jako wspólny język biznesu i IT, ale diagram powinien pozostać czytelny.

Każda integracja w workflow powinna mieć obsługę odpowiedzi negatywnej, timeoutu, retry i duplikatu. Proces nie może zakładać, że każdy system zawsze odpowie poprawnie.

Eskalacje i wyjątki

Wyjątek biznesowy, na przykład przekroczenie limitu, powinien prowadzić do jawnej ścieżki decyzyjnej. Wyjątek techniczny, na przykład niedostępność API, powinien uruchomić retry, alert lub kolejkę techniczną. Mieszanie obu klas utrudnia raportowanie i odpowiedzialność.

Eskalacja powinna wskazywać właściciela, wymagane dane, czas reakcji i sposób powrotu do procesu.

Kiedy workflow nie wystarczy

Workflow nie zastępuje systemu dziedzinowego, warstwy integracyjnej, jakości danych ani decyzji wymagającej specjalistycznego modelu. Może koordynować RPA, API i AI, ale nie powinien przechowywać wszystkich danych biznesowych ani implementować każdej reguły w jednym monolicie.

Przykład praktyczny

Wniosek zakupowy ma statusy: szkic, weryfikacja danych, akceptacja budżetu, akceptacja merytoryczna, realizacja i zamknięcie. Kwoty do 10 000 zł wymagają jednej akceptacji, wyższe dwóch. Brak odpowiedzi po 24 godzinach wysyła przypomnienie, po 48 godzinach eskaluje do przełożonego. Błąd integracji z ERP trafia do kolejki technicznej, a nie do akceptującego.

Tabela decyzyjna

Checklista

• [ ] Zdefiniowano stany biznesowe.
• [ ] Opisano role i możliwe przejścia.
• [ ] Ustalono SLA, przypomnienia i eskalacje.
• [ ] Rozdzielono wyjątki biznesowe i techniczne.
• [ ] Zaplanowano retry, idempotencję i audyt.
• [ ] Wskazano dane przechowywane poza silnikiem workflow.

Ryzyka i ograniczenia

• Techniczny model statusów: Użytkownik nie rozumie stanu sprawy.
• Brak idempotencji: Ponowienie tworzy duplikat operacji.
• Monolit procesowy: Workflow przejmuje logikę wszystkich systemów.
• Eskalacja bez właściciela: Alert istnieje, ale nie prowadzi do decyzji.

Następny krok

1. Zmapuj proces i jego stany.
2. Porównaj workflow z RPA dla konkretnego przypadku.
3. Przygotuj kryteria monitoringu i obsługi wyjątków.

Źródła i data weryfikacji

• OMG — Business Process Model and Notation 2.0
• Camunda 8 — process orchestration concepts
• Camunda 8 — dealing with problems and exceptions

Data weryfikacji źródeł: 1 sierpnia 2026 r.