Dlaczego pilotaż AI kończy się prezentacją i niczym więcej
Trzy powody, dla których udany pokaz nie zamienia się we wdrożenie. Wszystkie trzy dają się rozpoznać w pierwszym tygodniu projektu.
Pilotaż wypada dobrze. Na zarządzie system rozpoznaje dokumenty, odpowiada sensownie, wszyscy kiwają głowami. Pół roku później nic z tego w firmie nie działa, a temat wraca na kolejne spotkanie jako „sprawdziliśmy, nie dla nas”.
Widzieliśmy ten przebieg kilkanaście razy i za każdym razem stał za nim jeden z trzech powodów.
Powód pierwszy: pilotaż policzony na danych, jakich w produkcji nie ma
Do pokazu bierze się trzydzieści dokumentów. Zwykle starannie dobranych: czytelnych, kompletnych, takich, które wyglądają jak typowy przypadek. System radzi sobie z nimi w 95% i ta liczba trafia na slajd.
W produkcji dokumenty wyglądają inaczej. Jest skan zrobiony pod kątem, jest załącznik, w którym połowa danych siedzi w stopce, jest klient wysyłający zamówienie w treści maila, bez żadnej struktury. Skuteczność spada do siedemdziesięciu procent i nagle okazuje się, że co trzeci przypadek wymaga człowieka. Trzeba więc zbudować całą ścieżkę obsługi wyjątków, której nikt nie wycenił.
Jak tego uniknąć. Próbkę do pilotażu losuj, nie wybieraj. Weź dwieście dokumentów z ostatniego kwartału, wylosuj je i wcześniej do nich nie zaglądaj. Wynik wyjdzie gorszy i dobrze, bo właśnie taki dostaniesz w produkcji.
Powód drugi: nikt nie jest właścicielem procesu
Pilotaż prowadzi dział IT albo firma zewnętrzna. Proces należy do handlu, logistyki albo produkcji. Kiedy przychodzi moment wdrożenia, okazuje się, że nikt w firmie nie podjął decyzji, że od teraz pracujemy tak.
To nie jest opór przed zmianą. To najczęściej brak rozstrzygnięcia, kto odpowiada za to, żeby zapytania szły nowym trybem, i kto rozsądza sporne sytuacje w pierwszych tygodniach. Bez takiej osoby zespół wraca do starego sposobu przy pierwszym problemie, bo stary sposób ma właściciela, a nowy nie.
Jak tego uniknąć. Przed startem wskaż jedną osobę z działu, który ten proces prowadzi, i daj jej odpowiedzialność za wynik. Nie za projekt informatyczny, tylko za to, że proces działa po nowemu. Jeśli takiej osoby nie da się wskazać, to znak, że firma nie jest gotowa, a nie że technologia nie działa.
Powód trzeci: pilotaż odpowiada na złe pytanie
Pilotaże najczęściej pytają, czy AI to potrafi. Odpowiedź prawie zawsze brzmi „tak” i prawie zawsze jest do niczego.
O wdrożeniu decydują inne pytania. Czy poradzi sobie na naszych danych. Co się dzieje z przypadkami, których nie rozpozna. Ile kosztuje utrzymanie przez trzy lata. Kto to obsłuży, kiedy przestanie działać w czwartek o siedemnastej. Czy proces po zmianie ma sens, czy tylko szybciej kręci się w tym samym bałaganie.
Pilotaż, który na te pytania nie odpowiada, może wypaść świetnie i nie posunąć decyzji ani o krok.
Jak tego uniknąć. Spisz przed startem, jaki wynik oznacza wdrożenie, a jaki rezygnację. Konkretnie: skuteczność powyżej 85% na losowej próbce przy koszcie utrzymania poniżej ustalonej kwoty rocznie. Bez takiego progu każdy wynik da się obronić i każdy da się podważyć.
Czwarty powód, rzadszy, ale droższy
Czasem automatyzuje się proces, który w ogóle nie powinien istnieć.
Firma przepisuje dane z jednego systemu do drugiego, bo te systemy się nie widzą. Automatyzacja przepisywania działa i kosztuje osiemdziesiąt tysięcy. Połączenie tych dwóch systemów kosztowałoby trzydzieści i usunęłoby problem, zamiast go przyspieszać.
Zanim zaczniesz, zapytaj, po co ta praca w ogóle jest wykonywana. Jeśli odpowiedź brzmi „bo systemy się nie widzą”, pierwszym projektem jest integracja, nie AI.
Jak wygląda pilotaż, który przechodzi dalej
Trwa od czterech do sześciu tygodni, nie pół roku. Działa na losowej próbce z produkcji. Ma jednego właściciela w firmie i spisany próg decyzyjny. Kończy się liczbą, nie prezentacją.
Od pierwszego dnia zakłada też, że część przypadków trafi do człowieka, i to jest w tym wszystkim najważniejsze. Pilotaż, który tego nie zakłada, mierzy coś innego niż produkcja.
Usługa powiązana z tematem: Automatyzacje AI