SeriaOd statusu do rezultatuCzęść 4 z 5

Jak odzyskać kontrolę nad procesami w firmie

  1. Raport pokazuje porządek. Dlaczego firma odkrywa problem dopiero po fakcie?
  2. Zespół działa szybko. Dlaczego klient nadal czeka?
  3. Każdy dział zrobił swoje. Dlaczego sprawa nie idzie dalej?
  4. Automat działa, dopóki nie pojawi się nietypowy przypadek
  5. AI działa. Kiedy można przestać robić tę pracę ręcznie?

Automat działa, dopóki nie pojawi się nietypowy przypadek

Automat może poprawnie odczytać zamówienie, a mimo to nie mieć podstaw do wyboru właściwego produktu. Problem pojawia się wtedy, gdy system potrafi wskazać możliwe odpowiedzi, ale żadnej z nich nie może bezpiecznie uznać za prawidłową.

Przykład modelowy: klient B2B zamawia „moduł Z w wersji przemysłowej”. W katalogu są dwa produkty odpowiadające temu opisowi: jeden zasilany napięciem 24 V DC, drugi 230 V AC. Nie są zamienne. Zamówienie zawiera wszystkie pola wymagane w obecnym procesie, ale nie wskazuje wariantu zasilania. W danych dostępnych automatowi nie ma też obowiązującego uzgodnienia, które pozwalałoby wybrać jedną wersję. Pomyłka może skończyć się dostarczeniem niewłaściwego towaru, reklamacją i ponowną realizacją.

Można wymusić wybór, zablokować całe zamówienie albo poprosić pracownika o zatwierdzenie jednej z propozycji. Żadna z tych reakcji sama nie usuwa niepewności. Trzeba określić, której decyzji na razie nie wolno podjąć, jakie działania mogą trwać dalej i skąd uzyskać podstawę do rozstrzygnięcia.

Kiedy brak odpowiedzi jest rzeczywistym wyjątkiem?

Nie każde zatrzymanie automatyzacji wymaga osobnej ścieżki wyjątków. Brak pola, które formularz jednoznacznie uznaje za obowiązkowe, można obsłużyć walidacją. Jeśli opis produktu ma aktualne, zatwierdzone mapowanie na konkretny indeks, system może zastosować je automatycznie. Gdy natomiast nie wiadomo, czy polecenie zapisania zamówienia w ERP wykonało się poprawnie, problem dotyczy działania systemu, nie wyboru produktu.

W modelowym zamówieniu kłopot jest inny: proces uznał dane za kompletne, choć nie wystarczają one do wyboru jednej z dwóch niezamiennych pozycji. Firma nie ma podstaw, by zgadywać, który wariant klient miał na myśli. To wyjątek merytoryczny w obecnie przyjętym sposobie obsługi zamówień.

Jeżeli takie sytuacje powtarzają się regularnie, rozsądnym rozwiązaniem może być zmiana wymagań dotyczących zamówienia: obowiązkowe wskazanie napięcia zasilania albo zatwierdzona reguła odczytywania wariantu z uzgodnionych dokumentów. Nie warto utrzymywać kolejki ręcznych decyzji dla przypadku, który można rozstrzygnąć jednoznaczną zasadą.

Dopóki podstawy do wyboru nie ma, automat powinien zablokować zatwierdzenie spornej pozycji i czynności zależne od tego wyboru, a nie z definicji całe zamówienie. Może sprawdzać inne pozycje i przygotować projekt dokumentu. Ich niezależna realizacja jest dopuszczalna tylko wtedy, gdy pozwalają na to warunki handlowe i zależności w zamówieniu. Zakres wstrzymania powinien wynikać z konsekwencji błędu i możliwości jego odwrócenia, a nie z wygody konfiguracji.

Jedno zamówienie, dwie grupy czynności. Zablokowane: zatwierdzenie spornej pozycji i zwolnienie jej do kompletacji. Mogą trwać dalej: sprawdzanie pozostałych pozycji i przygotowanie projektu dokumentu. Częściowa realizacja tylko wtedy, gdy pozwalają na to warunki handlowe

Człowiek potrzebuje podstawy do decyzji, nie przycisku „zaakceptuj”

Przekazanie niepewnego wyniku pracownikowi pomaga tylko wtedy, gdy może on wnieść coś nowego: sprawdzić niedostępny systemowi dokument, zastosować specjalistyczną wiedzę, skorzystać z odpowiedniego uprawnienia lub zapytać źródło informacji. Jeśli widzi jedynie ten sam opis i dwa warianty, ręczna akceptacja wciąż oznacza zgadywanie. O tym, że zgoda człowieka musi dotyczyć konkretnej decyzji, jest też osobny tekst o granicach samodzielności AI.

W omawianej sprawie pracownik powinien zobaczyć oryginalne zamówienie, porównanie wariantów 24 V DC i 230 V AC oraz aktualne dokumenty klienta. Jeśli ważny załącznik do umowy rozstrzyga wariant, może stanowić podstawę decyzji. Jeśli o wyborze decyduje wyłącznie niewyrażona intencja klienta, trzeba zapytać klienta, a nie prosić operatora o domysł.

Karta wyjątku: co ustalić dla jednej klasy spraw

Do zaprojektowania takiej ścieżki właściciel procesu może użyć Karty wyjątku. To praktyczne narzędzie proponowane przez Codino, a nie formalny standard. W przeciwieństwie do zwykłego przekazania zadania, opisanego w poprzedniej części Kartą przekazania kroku, karta wyjątku określa przede wszystkim granice dopuszczalnej decyzji, sposób pozyskania dowodu i wynik postępowania przy braku rozstrzygnięcia.

UstalenieModelowy proces obsługi zamówień
1. Granica decyzji: czego nie wolno zgadnąć?Nie wolno wybrać wariantu 24 V DC ani 230 V AC wyłącznie na podstawie opisu „moduł Z, wersja przemysłowa”
2. Stan kontrolowany: co blokujemy?Nie zatwierdzać spornej pozycji ani nie zwalniać jej do kompletacji. Niesporne pozycje można weryfikować, a ich częściowa realizacja wymaga osobnej podstawy biznesowej
3. Dowód: co może rozstrzygnąć?Oryginalne zamówienie, aktualny katalog, obowiązujący załącznik do umowy, zatwierdzone mapowania klienta albo jednoznaczna odpowiedź klienta
4. Droga rozstrzygnięcia: kto i kiedy działa?Specjalista ds. zamówień sprawdza dokumenty do końca następnego dnia roboczego. Gdy brak podstaw, opiekun klienta pyta wprost: „24 V DC czy 230 V AC?”. Jeśli klient nie odpowie w przykładowym terminie dwóch dni roboczych, opiekun ponawia kontakt i przekazuje sprawę kierownikowi sprzedaży do decyzji o dalszym terminie lub postępowaniu zgodnym z umową
5. Dopuszczalne decyzje: kto i na jakiej podstawie?Uprawniony pracownik potwierdza wariant wyłącznie na podstawie aktualnego dokumentu lub odpowiedzi klienta. Bez dowodu pozostawia pozycję w kontrolowanym oczekiwaniu. Ewentualne nieprzyjęcie zatwierdza kierownik sprzedaży, jeśli pozwalają na to warunki umowy i zasady firmy
6. Wynik i ślad: co dzieje się ze sprawą?Pozycja jest gotowa do standardowej realizacji, oczekuje na konkretną informację z wyznaczoną kolejną czynnością albo została formalnie nieprzyjęta. Zapis obejmuje wynik, źródło dowodu, osobę odpowiedzialną i datę

Role, terminy i uprawnienia w tabeli są założeniami modelowymi, nie uniwersalnymi zasadami. Ich rzeczywistą postać musi uzgodnić właściciel procesu. Karta ma umożliwić podjęcie tej decyzji przed konfiguracją narzędzia, a nie wymuszać dodatkowy formularz czy rozbudowany system statusów.

Dwa rozstrzygnięcia i jedno kontrolowane oczekiwanie

Warto odróżnić zamknięcie wyjątku od poprawnego wstrzymania decyzji. W naszym przykładzie są dwa możliwe rozstrzygnięcia biznesowe i jeden stan przejściowy.

Produkt został potwierdzony. Specjalista znajduje ważny załącznik do umowy, który wskazuje, że „moduł Z w wersji przemysłowej” oznacza u tego klienta wariant 24 V DC. Sprawdza, czy zapis obejmuje bieżące zamówienie, a następnie uprawniona osoba potwierdza ten wariant i zapisuje źródło. Pozycja może wrócić do standardowej realizacji. To zakończenie wyjątku, choć nie całego zamówienia.

Czekamy na konkretną odpowiedź. W dostępnych dokumentach nie ma rozstrzygnięcia. Opiekun klienta pyta o napięcie zasilania, a pozycja pozostaje zablokowana przed realizacją. W sprawie zapisano odpowiedzialną osobę, pytanie i termin ponownego sprawdzenia. Jeśli odpowiedź nie nadejdzie, opiekun ponawia kontakt, a kierownik podejmuje dalszą decyzję zgodnie z umową: może wyznaczyć nowy termin lub uruchomić procedurę nieprzyjęcia pozycji. Samo „oczekuje na wyjaśnienie” nie kończy wyjątku. Każde przedłużenie musi mieć powód, właściciela i kolejny moment kontroli.

Pozycja nie zostaje przyjęta. Jeśli nie udało się uzyskać wymaganej specyfikacji, a umowa i polityka firmy pozwalają w tej sytuacji odmówić przyjęcia pozycji, uprawniony kierownik podejmuje i zapisuje taką decyzję. Klient otrzymuje odpowiednią informację. To drugi możliwy stan kończący wyjątek. Nie należy mylić go z automatycznym odrzuceniem zamówienia po upływie dowolnie ustawionego terminu.

Dwa rozstrzygnięcia i jeden stan przejściowy. Produkt potwierdzony na podstawie dokumentu lub odpowiedzi klienta oraz pozycja formalnie nieprzyjęta kończą wyjątek. Oczekiwanie na konkretną odpowiedź go nie kończy i wymaga powodu, właściciela oraz terminu kolejnej kontroli

Jest również sytuacja, która nie wymaga żadnej z tych ścieżek: firma ma dla danego klienta obowiązujące, jednoznaczne mapowanie nazwy na wariant 24 V DC i nic mu nie przeczy. Wtedy zatwierdzona reguła może rozstrzygnąć sprawę bez ręcznej akceptacji. Powtarzalny przypadek powinien przestać być wyjątkiem, gdy firma potrafi bezpiecznie opisać jego rozstrzygnięcie.

Po czym można poznać, że obsługa wyjątku działa?

Zamiast zaczynać od budowy uniwersalnej kolejki wyjątków, warto zlecić właścicielowi procesu test jednej klasy niejednoznacznych zamówień. Odbiór powinien dotyczyć zachowania w konkretnych scenariuszach, nie samego faktu, że ktoś uruchomił test.

Scenariusz testowyWarunek zaliczenia
Dwa niezamienne warianty, brak dowoduSporna pozycja nie zostaje automatycznie wybrana ani skierowana do realizacji
Obowiązujący załącznik jednoznacznie wskazuje 24 V DCUprawniona osoba potwierdza właściwy wariant, a w sprawie wskazano aktualny dokument stanowiący podstawę
Tylko klient zna wymagany wariantKlient otrzymuje precyzyjne pytanie, a sprawa ma właściciela i termin kolejnej czynności
Klient potwierdza wariant 230 V AC po wyjaśnieniuNa podstawie jednoznacznej odpowiedzi uprawniona osoba potwierdza wariant, zapisuje dowód i dopuszcza pozycję do standardowej realizacji
Klient nie odpowiada w terminieUruchomiono uzgodniony kontakt lub decyzję kierownika, a pozycja nie pozostaje bezterminowo bez właściciela
Brak rozstrzygnięcia, a umowa dopuszcza nieprzyjęcie pozycjiUprawniona osoba podejmuje formalną decyzję zgodnie z warunkami, zapisuje powód i informuje klienta
Istnieje zatwierdzone mapowanie, bez sprzecznych danychSystem stosuje regułę bez zbędnej ręcznej akceptacji
W zamówieniu są również niesporne pozycjeMożna kontynuować dozwolone czynności niezależne, bez automatycznego założenia, że wolno dokonać częściowej wysyłki

Przykładowy wynik jednego testu: system rozpoznał dwa warianty, nie zatwierdził żadnego z nich, a opiekun klienta wysłał pytanie „24 V DC czy 230 V AC?” i ma wyznaczony termin kontroli odpowiedzi. Niesporne pozycje pozostały dostępne do walidacji, ale nie zostały samowolnie wysłane. Ten scenariusz testowy przechodzi, ponieważ poprawnie zabezpieczono decyzję i określono drogę do jej rozstrzygnięcia. Wybór wariantu nadal czeka jednak na informację. Nie oznacza to zaliczenia całej ścieżki. Osobno trzeba sprawdzić przyjęcie odpowiedzi klienta i formalne zakończenie sprawy, gdy rozstrzygnięcie jest niemożliwe. Scenariusz nie przeszedłby testu, gdyby system zgadł produkt albo pozostawił pozycję w ogólnym „do sprawdzenia” bez odpowiedzialnej osoby i terminu.

To hipotetyczne kryteria odbioru, nie wyniki wdrożenia Codino. Potwierdzają logikę ścieżki, a nie rzeczywistą częstość wyjątków czy oszczędności operacyjne. Takie efekty trzeba mierzyć osobno.

Automatyzacja nie musi rozstrzygać każdej sytuacji. Musi natomiast jasno oddzielać decyzje, do których ma podstawy, od tych, których podjąć jeszcze nie wolno. Wtedy nietypowe zamówienie nie kończy się zgadywaniem, niepotrzebnym zatrzymaniem całej pracy ani sprawą pozostawioną na zawsze „do sprawdzenia”.