Obsługa wyjątków w automatyzacji — kolejka, właściciel i pętla doskonalenia
Jak klasyfikować wyjątki, projektować kolejkę, właściciela, SLA, eskalację, analizę przyczyn i pętlę doskonalenia.
Wyjątek jest częścią procesu, która wymaga określonego właściciela, sposobu obsługi, SLA i decyzji zwrotnej.
Wyjątek nie jest dowodem porażki automatyzacji. Jest przypadkiem, którego ścieżka podstawowa nie może bezpiecznie zakończyć. Dojrzały proces wykrywa wyjątek, klasyfikuje go, przekazuje właściwej osobie i wykorzystuje dane do poprawy reguł.
Odpowiedź w 60 sekund
Obsługa wyjątku wymaga klasy, właściciela, priorytetu, SLA i danych potrzebnych do decyzji. Sprawa powinna trafić do jawnej kolejki i wskazanej roli, a nie do anonimowej skrzynki. Powtarzające się przypadki należy mierzyć, grupować i analizować, aby poprawiać dane, reguły, integracje lub model.
Przeczytaj analizę, dlaczego automatyzacja nie usuwa wyjątków.
Taksonomia wyjątków
Warto rozróżnić wyjątki biznesowe, danych, techniczne, bezpieczeństwa i modelu AI. Brak limitu budżetu jest wyjątkiem biznesowym. Niepoprawny format pliku — danych. Timeout API — techniczny. Próba dostępu bez uprawnień — bezpieczeństwa. Niska pewność klasyfikacji — modelu.
Każda klasa ma inny właściciel, SLA i sposób powrotu do procesu.
Kolejka i priorytet
Kolejka powinna pokazywać typ, wiek, wpływ, właściciela, wymagane dane i ostatnią próbę. Priorytet wynika z wpływu oraz czasu, nie tylko kolejności pojawienia się. Sprawa blokująca klienta albo płatność może wymagać szybszej reakcji niż starszy przypadek administracyjny.
Eskalacja
Po przekroczeniu SLA sprawa powinna trafić do wskazanej roli, nie do anonimowej skrzynki. Eskalacja musi mieć kontekst potrzebny do decyzji. Przekazanie człowiekowi bez danych źródłowych i historii automatyzacji przenosi problem, a nie go rozwiązuje.
Analiza przyczyn
Powtarzające się wyjątki należy grupować i analizować. Część wynika z jakości danych, część z brakującej reguły, część z błędu integracji. Największa grupa nie zawsze ma najwyższy priorytet; istotny jest koszt i ryzyko.
Feedback loop
Korekta może prowadzić do poprawy danych, reguły, interfejsu lub modelu. Zmiana powinna przejść testy i zatwierdzenie. Automatyczne uczenie się z każdej ręcznej decyzji może utrwalać błędy i niespójne praktyki.
Przykład praktyczny
Proces dokumentów ma pięć klas wyjątków. 42% kolejki stanowi brak numeru kontrahenta, 25% duplikaty, 18% niska pewność OCR, 10% błąd ERP, 5% naruszenie reguł bezpieczeństwa. Zespół nie „uczy modelu wszystkiego”. Najpierw naprawia dane kontrahentów, bo ta jedna przyczyna tworzy największy koszt ręczny.
Tabela decyzyjna
| Klasa | Przykład | Właściciel | Działanie |
|---|---|---|---|
| Biznesowa | przekroczony limit | biznes | decyzja/akceptacja |
| Dane | brak pola | właściciel danych | korekta |
| Techniczna | timeout API | IT | retry/incydent |
| Bezpieczeństwo | brak uprawnienia | security/IT | blokada i analiza |
| AI | niska pewność | recenzent | walidacja i feedback |
Checklista
- [ ] Zdefiniowano taksonomię wyjątków.
- [ ] Każda klasa ma właściciela i SLA.
- [ ] Kolejka pokazuje kontekst i historię.
- [ ] Eskalacja prowadzi do konkretnej roli.
- [ ] Mierzone są liczba, wiek i koszt wyjątków.
- [ ] Zmiany reguł przechodzą kontrolowany feedback loop.
Ryzyka i ograniczenia
- Jedna kolejka dla wszystkiego: Sprawy techniczne mieszają się z biznesowymi.
- Eskalacja bez danych: Człowiek odtwarza cały przypadek od początku.
- Wieczna obsługa ręczna: Powtarzalne przyczyny nie są usuwane.
- Automatyczne uczenie bez kontroli: Korekty utrwalają lokalne błędy.
Następny krok
- Zaprojektuj kolejkę i SLA.
- Dodaj dashboard przyczyn i czasu obsługi.
- Ustal cykl przeglądu oraz zmian reguł.
Źródła i data weryfikacji
- Camunda 8 — dealing with problems and exceptions
- Google SRE — Monitoring Distributed Systems
- NIST AI Risk Management Framework
Data weryfikacji źródeł: 1 sierpnia 2026 r.