Monitorowanie i sygnalizacja brzmi jak dashboard. Zwykle jest to coś innego: system, który nieustannie odbiera dane, porównuje je z oczekiwaniem lub wartością progową i wysyła sygnał, gdy coś się odchyla. Może to być maszyna, która wibruje inaczej niż normalnie, zapas, który zmniejsza się szybciej niż zaplanowano, sieć, przez którą przechodzi nietypowy ruch, lub proces obsługi klienta, w którym czas realizacji się wydłuża. Komponent AI polega na rozpoznawaniu wzorców, których nie da się uchwycić za pomocą stałych reguł — nie na zastąpieniu człowieka, który reaguje na sygnał.
System monitorowania dostarcza trzy rzeczy: ciągły pomiar, normę, do której ten pomiar jest odnoszony, oraz sygnał, gdy odchylenie przekracza określoną granicę. To, co dzieje się potem, zależy od sposobu wdrożenia. W najprostszej formie powiadomienie trafia do człowieka, który ocenia i działa. W bardziej zaawansowanej formie sygnał automatycznie uruchamia kolejny krok — powiadomienie dostawcy, korektę w planowaniu, zablokowanie transakcji. Ta druga forma dotyka obszaru łańcuchów, w których kroki następują po sobie: monitorowanie staje się wtedy punktem wyjścia procesu, który przebiega bez interwencji, a to wymaga innego rodzaju zaufania niż powiadomienie, które ktoś może jeszcze odrzucić.
Różnica między tymi dwiema formami nie jest trywialna. Sygnał, który trafia do człowieka, może być błędny, bez natychmiastowej szkody — człowiek filtruje. Sygnał, który wywołuje działanie, musi być poprawny, albo organizacja musi mieć sposób na wycofanie tego działania. Wiele organizacji zaczyna więc od pierwszej formy i przechodzi do drugiej tylko wtedy, gdy sygnał się udowodnił.
Monitorowanie i sygnalizacja wymagają przede wszystkim ciągłych, wiarygodnych danych. System, który co tydzień otrzymuje eksport z innego systemu, nie może wysłać sygnału — może jedynie raportować z opóźnieniem. Musi istnieć przepływ: czujniki, logi, transakcje, zdarzenia, które napływają nieprzerwanie i których jakość nie zmienia się w zależności od tego, kto wprowadza dane.
Dodatkowo wymaga to normy. Odchylenie jest odchyleniem tylko w odniesieniu do czegoś. W przypadku maszyn jest to często specyfikacja techniczna; w przypadku procesów częściej jest to średnia historyczna lub wartość docelowa, którą ktoś ustalił. Tam, gdzie ta norma jest nieobecna lub niestabilna — proces, który nieustannie się zmienia, rynek, który się wahnie — system daje albo zbyt wiele sygnałów, albo zbyt mało. Obie sytuacje podważają zaufanie do niego.
Po trzecie, wymaga to ustalonej ścieżki postępowania z sygnałem. Kto otrzymuje powiadomienie, w jakim czasie jest ono oceniane, jaka jest eskalacja, jeśli nie nastąpi reakcja. Bez tej ścieżki sygnał trafia do skrzynki, którą nikt nie czyta, a system traci swoją funkcję. To dotyka tego samego zagadnienia co przy rozmowach, które są rejestrowane i monitorowane: rejestrowanie bez dalszej obsługi daje jedynie archiwum, a nie usprawnienie.
Najczęstszą wadą jest system monitorowania, który generuje zbyt wiele sygnałów. Jeśli każde małe odchylenie powoduje powiadomienie, ludzie uczą się je ignorować — odwrotny efekt niż ten, do którego system był przeznaczony. Ustalanie wartości progowej jest więc nieustającym kompromisem między nadmiarem szumu a ostrzeganiem za późno, a ten kompromis przesuwa się wraz z napływem większej ilości danych.
Druga wada polega na tym, że sygnał się uruchamia, ale nikt nie jest właścicielem dalszej obsługi. Zdarza się to często, gdy monitorowanie jest wdrażane jako projekt IT, bez zaangażowania działu, który musi pracować z sygnałami. Technika działa, organizacja nie.
Trzecia wada powstaje, gdy sygnał wymaga decyzji, która w rzeczywistości jest pracą ludzką — czy to odchylenie jest akceptowalne, czy trzeba zadzwonić do klienta, czy to ryzyko warte jest zatrzymania. Tam, gdzie ta ocena staje się cięższa niż to, co stała reguła może obsłużyć, monitorowanie przesuwa się w kierunku wspomagania decyzji, a wtedy obowiązują inne wymagania dotyczące uzasadnienia i wyjaśnialności niż przy prostym sygnale progowym.
Większość projektów monitorowania, które nie ruszają z miejsca, utyka na przepływie danych, nie na modelu. Czujniki, które się wyłączają, logi, które są niekonsekwentne, systemy, które nie komunikują się ze sobą — to nie są problemy AI, to problemy infrastrukturalne, które trzeba najpierw rozwiązać. Rolę odgrywa też koordynacja: sygnał, który powstaje w jednym dziale, często musi trafić do innego działu, aby coś znaczył, a to dotyka pytania, jak zorganizowana jest koordynacja między działami.
Ta strona opisuje, co monitorowanie i sygnalizacja mogą przynieść, i co organizacja musi mieć uporządkowane, aby to zadziałało. Innym pytaniem jest to, jaka część pracy związanej z tymi sygnałami — ocena, dalsza obsługa, eskalacja — może być faktycznie przejęta przez AI. To jest pytanie na poziomie zadań, a odpowiada na nie skan pracy FTE TO AI: wylicza on dla każdego zadania, jaką część pracy można przejąć, a nie na poziomie całego procesu czy całej funkcji.
Vraag maar wat er moet staan voordat AI in uw organisatie kan landen.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.