Dlaczego pilotaż AI nie wchodzi do produkcji

Pilotaż zwykle wypada dobrze. To jest w tym najgorsze.

W firmach, z którymi rozmawiamy, powtarza się ten sam przebieg: dwa tygodnie testu, pokaz dla zarządu, zadowolenie, potem cisza. Pół roku później nikt nie umie powiedzieć, dlaczego się nie przyjęło, bo przecież działało.

Nie działało wdrożenie. Działała demonstracja, a to nie jest to samo. Poniżej pięć mechanizmów, które regularnie zatrzymują projekt na tym etapie, i decyzje, które trzeba podjąć przed startem, żeby ich uniknąć.

Pilotaż na danych, których w firmie nie ma#

Żeby pokaz wypadł dobrze, ktoś przygotowuje dane. Wybiera dwustu reprezentatywnych klientów, poprawia literówki, uzupełnia braki, ujednolica statusy. Robi to w dobrej wierze — chce pokazać, jak działa narzędzie, a nie jak wygląda firmowy bałagan.

Skutek jest taki, że pilotaż odpowiada na pytanie, którego nikt nie zadawał: czy to zadziała na czystych danych. Zadziała.

Bez odpowiedzi zostaje pytanie właściwe. Co się stanie przy czterdziestu tysiącach rekordów, w których ten sam klient występuje trzy razy pod trzema nazwami, połowa zleceń nie ma daty zamknięcia, a status „w realizacji" znaczy co innego u handlowców i co innego na produkcji.

Odpowiedź poznaje się dopiero po pilotażu i zwykle brzmi: zadziała, ale po pracy, na którą nikt nie zarezerwował czasu — bo pilotaż jej nie ujawnił.

Właściciel siedzi po stronie dostawcy#

W trakcie pilotażu konfiguruje ktoś z zewnątrz albo jedna szczególnie zainteresowana osoba z firmy. Do niej idą pytania, do niej poprawki, ona pilnuje, żeby w dniu pokazu wszystko stało na swoim miejscu.

To jest wygodne i dlatego groźne. Po pilotażu zostaje proces, którego nikt nie ma wpisanego w zakres obowiązków.

Praktyczny test: kto zauważy w środę rano, że wtorkowa automatyzacja nie zadziałała. Jeżeli odpowiedź brzmi „ktoś w końcu zgłosi", to właściciela nie ma, a pierwsza cicha awaria zakończy wdrożenie — nie decyzją, tylko zaniechaniem.

Właściciel to nie sponsor. Sponsor podpisuje budżet i pyta o efekty na zarządzie. Właściciel odpowiada za to, że proces działa w przyszły wtorek, i ma prawo zmienić go bez zwoływania spotkania.

To rozróżnienie zapada wcześniej, przy wyborze pierwszego procesu. Pilotaż tylko pokazuje, ile kosztowało jego pominięcie.

Sukces mierzony pokazem, a nie liczbą#

Pilotaż kończy się demonstracją, a demonstracja jest oceniana wrażeniem. Wrażenie ma krótki termin ważności i nie przechodzi przez kolejny budżet.

Przewodnik tego klastra kładzie nacisk na zmierzenie stanu wyjściowego przed startem. Tutaj dokładam drugą połowę tej zasady: liczba musi mieć właściciela, termin i próg.

Kto mierzy. Jedna osoba wskazana z imienia, nie „zespół".

Kiedy. Data w kalendarzu, ustalona przed startem. Pilotaż bez daty decyzji się nie kończy — on się rozmywa.

Co uznajemy za wynik dobry. Próg podany z góry. Bez niego każdy wynik da się opowiedzieć jako sukces i każdy jako porażkę, a rozstrzygnie to, kto lepiej mówi na spotkaniu.

Warto od razu ustalić, że wynik poniżej progu kończy projekt. Pilotaż, którego nie da się przegrać, niczego nie sprawdza.

Proces działa obok systemu, nie w systemie#

Najczęstsza forma pilotażu wygląda tak: ktoś kopiuje dane z systemu do asystenta, dostaje odpowiedź i przekleja ją z powrotem.

Działa. I dokładnie dlatego jest pułapką — działa tak długo, jak długo robi to jedna zmotywowana osoba w spokojnym tygodniu.

Proces oparty na przekładaniu danych między dwoma oknami ma wbudowany limit. Nie rozciąga się na dziesięć osób, znika w tygodniu, w którym jest gorąco, i nie zostawia śladu: nie wiadomo, kto o co pytał, na jakich danych i co z tego wyszło.

„W systemie" znaczy trzy rzeczy. AI czyta te same rekordy, które widzi zespół. Propozycja pojawia się tam, gdzie ludzie i tak pracują, razem z przyciskiem zatwierdzenia. Zmiana zapisuje się w tym samym miejscu, z historią, którą da się cofnąć.

Wtedy korzystanie przestaje wymagać dyscypliny, bo jest tańsze niż niekorzystanie. Pilotaż obok systemu mierzy motywację jednej osoby. Pilotaż w systemie mierzy proces.

Nie ma ścieżki utrzymania po odejściu entuzjasty#

W każdym wdrożeniu jest jedna osoba, która ciągnie temat. Zmienia stanowisko, wpada w gorący kwartał albo odchodzi z firmy — i proces kończy się razem z nią.

To nie jest problem lojalności, tylko zapisu. Konfiguracja siedziała w jej głowie, uzasadnienia decyzji nigdzie, a ostatnie poprawki robiła wieczorami, poza swoim właściwym zakresem obowiązków.

Trzy pytania, które odsłaniają to zawczasu:

Czy da się zobaczyć, jak proces jest ustawiony, bez pytania autora. Jeżeli nie, firma kupiła zależność od człowieka, a nie narzędzie.

Czy zmianę wprowadzi ktoś, kto nie programuje. Proces wymagający przy każdej korekcie zewnętrznego wsparcia umrze na pierwszej zmianie w firmie, a te zdarzają się częściej niż wdrożenia.

Czy ktoś przejął to formalnie. Przekazanie musi być czynnością z datą i nazwiskiem, nie założeniem.

Co ustawić inaczej#

Cztery decyzje, wszystkie do podjęcia przed startem. Żadna nie wymaga większego budżetu, każda zmienia to, co pilotaż w ogóle sprawdza.

Prawdziwe dane, wąski wycinek. Zamiast dwustu wyczyszczonych rekordów — pełny, nieuporządkowany zbiór, ale z jednego działu albo jednego miesiąca.

Nazwisko właściciela. Jedna osoba z działu, którego proces dotyczy, z tym zadaniem wpisanym w obowiązki, a nie dołożonym po godzinach.

Liczba, próg i data. Ustalone przed startem, spisane w jednym zdaniu, znane obu stronom.

Zakaz przeklejania. Jeżeli praca wymaga ręcznego przenoszenia danych między dwoma oknami, pilotaż sprawdza coś innego niż wdrożenie.

Do tego jeden warunek, który nie jest decyzją organizacyjną: agent powinien działać dopiero po zatwierdzeniu przez człowieka, a każda jego zmiana powinna dać się cofnąć. Bez tego pierwszy błąd na prawdziwych danych zakończy projekt szybciej niż jakikolwiek brak zwrotu.

Podsumowanie#

Udany pilotaż nie jest dowodem, że wdrożenie się uda — bywa dowodem, że pytanie było za łatwe. Sprawdzaj na prawdziwych danych, w systemie, z nazwiskiem właściciela i z liczbą ustaloną przed startem, a przekazanie zaplanuj, zanim zaczniesz.

Wtedy różnica między pilotażem a produkcją przestaje być przepaścią i staje się kolejnym tygodniem tej samej pracy. Szerszy kontekst — od wyboru pierwszego procesu po rozszerzanie dopiero po dowodzie — opisujemy w przewodniku wdrożenie AI w firmie.