Od pilotażu AI do wdrożenia: jak nie utknąć w pilot purgatory

Czas czytania: ok. 6 min

Odpowiedź najpierw

Pilot purgatory to stan, w którym pilot AI skończył się „w miarę dobrze", ale firma nigdy nie przechodzi do wdrożenia. Pilot się nie wykłada i nie wygrywa, po prostu tkwi: kolejny raz przedłużany, rozszerzany o nowe przypadki, prezentowany na kolejnych spotkaniach. Główna przyczyna nie jest techniczna, tylko decyzyjna. Pilot ruszył bez ustalonego z góry kryterium sukcesu i bez właściciela, który po jego zakończeniu ma mandat powiedzieć „go" albo „no-go". Żeby nie utknąć, potrzebujecie trzech rzeczy jeszcze przed startem: jednego liczbowego lub jakościowego progu sukcesu, jednej osoby odpowiedzialnej za decyzję i wstępnego zarysu, co konkretnie oznacza pełne wdrożenie. Niżej rozkładamy, dlaczego piloty grzęzną i po czym poznać, że wasz jest gotowy do decyzji.

Czym jest pilot purgatory i dlaczego tyle firm w nim ląduje

Pilot purgatory to nie porażka pilota. Porażka jest zdrowa: dostajecie jasny sygnał „to nie działa na naszych danych" i idziecie dalej. Purgatory jest gorsze, bo wygląda na sukces. Demo działa, ludzie kiwają głowami, a mimo to po trzech, czterech miesiącach nic się nie zmieniło w codziennej pracy.

Firmy lądują w tym stanie, bo pilot startuje jako ćwiczenie techniczne, nie decyzyjne. Pytanie brzmi „czy da się to zbudować", a nie „co zrobimy z odpowiedzią". Kiedy pilot potwierdza, że owszem, da się, nikt nie ma przygotowanej ścieżki, co dalej. Zaczyna się dokładanie kolejnych przypadków użycia, bo to łatwiejsze niż podjęcie decyzji o budżecie, integracji i utrzymaniu.

Ten post domyka wątek z materiału o pilocie AI w 8 tygodni. Tam pokazaliśmy, co realnie mieści się w oknie pilotażu. Tutaj chodzi o to, co dzieje się po nim.

Cztery powody, dla których piloty grzęzną

Brak kryterium sukcesu ustalonego na starcie. Jeśli nie wiecie z góry, jaki wynik uznacie za wystarczający, żaden wynik nie będzie wystarczający. Zawsze da się powiedzieć „prawie, dołóżmy jeszcze jeden przypadek". Kryterium spisane przed pilotem odbiera tę furtkę.

Brak właściciela decyzji. Pilot bywa prowadzony przez zespół techniczny lub dostawcę, ale decyzja go/no-go jest biznesowa. Jeśli nikt po stronie firmy nie ma mandatu i budżetu, żeby powiedzieć „wchodzimy", pilot czeka na decyzję, która nie ma gdzie zapaść.

Mylenie zakresu pilota z zakresem wdrożenia. Pilot celowo dotyka wąskiego wycinka. Wdrożenie wymaga integracji z systemami, uprawnień, szkoleń i utrzymania. Jeśli tego drugiego nikt nie oszacował, przejście wygląda na skok w nieznane i naturalnie się odkłada.

Rozjazd między wynikiem technicznym a operacyjnym. Model może odpowiadać trafnie w teście, a mimo to nie wchodzić do codziennej pracy, bo nie pasuje do istniejącego procesu. Bez testu z realnymi użytkownikami ten rozjazd wychodzi dopiero przy próbie wdrożenia, kiedy jest już drożej.

Kryteria przejścia z pilota do skali

Zanim ogłosicie „go", warto mieć odpowiedź na pięć pytań. To nie jest lista dostawcy, tylko minimum, które chroni was przed wdrożeniem na wyczucie.

Czy wynik pilota przekroczył próg ustalony na starcie, a nie próg dopisany po fakcie. Jeśli kryterium zmieniało się w trakcie, wróćcie do wersji pierwotnej.

Czy realni użytkownicy, nie tylko zespół projektowy, potwierdzają, że rozwiązanie pomaga w ich pracy. Opinia trzech techników z hali waży tu więcej niż najlepsze demo.

Czy znacie stan swoich danych. Pilot zwykle obnaża, że dokumentacja jest mniej uporządkowana, niż zakładano. Wdrożenie na całości oznacza uporządkowanie reszty, i to trzeba wycenić.

Czy macie wstępny obraz kosztu i zakresu wdrożenia. Nie co do złotówki, ale na tyle, żeby wiedzieć, czy mówimy o jednym dziale, czy o całej firmie, i co jest po drodze.

Czy jest osoba, która podejmie decyzję i weźmie za nią odpowiedzialność. Bez tego reszta kryteriów jest ćwiczeniem teoretycznym.

Jeśli na którekolwiek z tych pytań nie ma odpowiedzi, pilot nie dojrzał do skali, niezależnie od tego, jak dobrze wypadł technicznie. To nie znaczy „no-go", znaczy „jeszcze nie teraz, brakuje tego elementu".

Jak wygląda dobre go i uczciwe no-go

Dobre „go" nie oznacza wdrożenia wszystkiego naraz. Oznacza rozszerzenie na jeden dobrze zrozumiany zakres, z jasnym właścicielem, budżetem i planem utrzymania. Skalowanie etapami jest wolniejsze na papierze, ale rzadziej kończy się cofnięciem.

Uczciwe „no-go" też jest wynikiem, nie stratą. Jeśli pilot pokazał, że dane nie są gotowe albo że proces nie skorzysta z narzędzia w obecnym kształcie, zapłaciliście niewielką cenę za informację, zamiast przepłacić za nią w pełnym wdrożeniu. Najgorszy scenariusz to nie „no-go", tylko brak decyzji: kolejny przedłużony pilot, który konsumuje czas i uwagę, a nie zmienia niczego w pracy.

Praktyczny sposób, żeby wymusić decyzję, to wpisać datę go/no-go do harmonogramu pilota już na starcie, tak jak wpisuje się datę zakończenia. Pilot bez daty decyzji to pilot z otwartym zaproszeniem do purgatory.

Jeśli dopiero wybieracie dostawcę i chcecie, żeby pilot od początku prowadził do decyzji, pomaga zadanie właściwych pytań przed umową. Rozkładamy je w materiale 10 pytań przed RFP.

Czego ten post nie pokrywa

Nie wchodzimy tu w to, jak zaplanować i poprowadzić sam pilot, bo to temat materiału o pilocie w 8 tygodni. Pomijamy też kwestie regulacyjne, bezpieczeństwo danych i architekturę wdrożenia, bo każde z nich ma własną logikę i zasługuje na osobne omówienie. Skupiamy się wyłącznie na momencie przejścia: dlaczego piloty grzęzną i po czym poznać, że wasz jest gotowy do decyzji.

Powiązane

• Pilot AI w fabryce w 8 tygodni: co możliwe, a co marketing
• Jak wybrać vendora AI dla produkcji: 10 pytań przed RFP
• Jak ocenić gotowość firmy produkcyjnej do wdrożenia AI: 5 pytań
• ROI z AI w produkcji: jak liczyć, czego nie wpisywać w business case