Dlaczego pilotaże AI nie wychodzą poza pilotaż

Typowy pilotaż AI kończy się udaną prezentacją i niczym więcej. Rzadko winna jest technologia. Pilotaż projektuje się tak, żeby się udał: proces bez wyjątków, dane wyczyszczone ręcznie przed startem, zespół, który sam się zgłosił. Przy wdrożeniu żaden z tych warunków nie jest już spełniony. Rozwiązanie działa dokładnie tak dobrze jak w pilotażu – tylko na innym materiale.

Kluczowe wnioski

• Pilotaż wybiera się pod dowód, że technologia działa. Wdrożenie wymaga dowodu, że działa na materiale, którego nikt wcześniej nie posprzątał.
• Trzy warunki, które znikają po pilotażu: proces bez wyjątków, dane przygotowane ręcznie i zespół, który chciał.
• Sukces pilotażu na wyselekcjonowanej próbce nie mówi nic o skali. Mówi o niej dopiero wynik na próbce losowej, razem z przypadkami odrzuconymi.
• Pilotaż powinien kończyć się decyzją i liczbą kosztu jednostkowego po rozszerzeniu, a nie prezentacją.
• Przerwanie pilotażu, który dowiódł, że proces wymaga wcześniej przeprojektowania, jest jego prawidłowym wynikiem, nie porażką.
• Automatyzacja źle zaprojektowanego procesu sprawia, że działa on szybciej i drożej.

Na czym polega dobór pod sukces

Wybór procesu do pilotażu prawie zawsze przebiega tak samo. Szuka się obszaru, w którym jest dużo powtarzalnej pracy, dane są w jednym miejscu, a zespół zgłosił się sam. To rozsądny wybór, jeśli celem jest sprawdzenie, czy technologia w ogóle działa.

Problem pojawia się, gdy ten sam wynik traktuje się jako dowód gotowości do wdrożenia. Obszar wybrany jako najłatwiejszy jest z definicji niereprezentatywny. Rozszerzenie oznacza wejście w procesy, których nikt nie wybierał, bo są trudne.

Drugi mechanizm jest mniej widoczny. Przed pilotażem ktoś zwykle porządkuje dane: uzupełnia braki, ujednolica nazewnictwo, odrzuca rekordy niekompletne. Ta praca nie trafia do raportu, bo nie jest częścią rozwiązania. Przy wdrożeniu nikt jej nie wykonuje, a jakość wyniku spada w sposób, którego pilotaż nie przewidział.

Jest sytuacja, w której dobór pod sukces jest właściwy: organizacja styka się z technologią pierwszy raz i celem jest oswojenie, nie decyzja o wdrożeniu. Trzeba to tylko nazwać z góry – i nie udawać potem, że wynik czegoś dowiódł.

Trzy warunki, które znikają

Pierwszy to brak wyjątków. Proces wybrany do pilotażu zwykle ma jedną ścieżkę. Ten sam proces w innym kraju, dla innego typu klienta albo dla umowy sprzed pięciu lat ma ich kilkanaście. Każdy wyjątek wymaga decyzji, a decyzje są tym, czego rozwiązanie nie umie podjąć samo.

Drugi to jakość danych. Wynik na danych przygotowanych ręcznie opisuje działanie modelu, nie działanie procesu. Wartość praktyczną ma dopiero pomiar na danych w takim stanie, w jakim rzeczywiście są.

Trzeci to nastawienie zespołu. Zespół, który sam się zgłosił, wybacza błędy i zgłasza usterki. Zespół, który dostaje narzędzie odgórnie, przestaje z niego korzystać po drugim złym wyniku i nikomu tego nie zgłasza. Ta różnica bywa większa niż różnica w skuteczności samego rozwiązania.

Każdy z tych trzech warunków dotyczy otoczenia, nie samego rozwiązania. Model, integracja i reguły działają po rozszerzeniu tak samo. Zmienia się materiał, na którym pracują, i to on decyduje o wyniku. Dlatego poprawianie rozwiązania po nieudanym rozszerzeniu zwykle nic nie daje – problem leży poza nim.

Bywa też odwrotnie. Zespół, który sam się zgłosił, broni rozwiązania dłużej, niż ono na to zasługuje. Entuzjazm zaniża liczbę zgłaszanych błędów tak samo skutecznie jak niechęć.

Czego pilotaż ma dowieść

Pilotaż ma odpowiedzieć na pytanie o koszt jednostkowy po rozszerzeniu, a nie o to, czy technologia działa. To drugie wiadomo z góry.

Żeby taką odpowiedź uzyskać, próbka musi być losowa, a nie wybrana. Powinna zawierać przypadki, które rozwiązanie odrzuci – bo to one wyznaczają, ile pracy zostanie po stronie człowieka. Odsetek przypadków wymagających ręcznego rozstrzygnięcia jest ważniejszy od skuteczności na przypadkach typowych.

Druga potrzebna liczba to czas obsługi przypadku odrzuconego. Rozwiązanie, które przepuszcza osiemdziesiąt procent spraw, wygląda dobrze do momentu, w którym okazuje się, że pozostałe dwadzieścia zajmuje więcej czasu niż wcześniej. Człowiek dostaje wtedy sprawy najtrudniejsze, pozbawione kontekstu wypracowanego przy obsłudze łatwych. Ten efekt trzeba zmierzyć w pilotażu, bo po wdrożeniu jest już kosztem stałym.

Potrzebna jest też liczba opisująca utrzymanie. Rozwiązanie agentowe wymaga aktualizacji przy każdej zmianie w systemie źródłowym, w formacie dokumentu i w przepisach. Pilotaż trwający sześć tygodni tego nie pokaże, ale można oszacować częstotliwość takich zmian z ostatnich dwóch lat.

Warto przy tym oddzielić dwie rzeczy, które często się mylą. Pilotaż technologiczny sprawdza, czy narzędzie potrafi wykonać zadanie na wybranej próbce. Pilotaż operacyjny sprawdza, czy organizacja potrafi z tego korzystać codziennie, przy danych w takim stanie, w jakim są. Pierwszy trwa kilka tygodni i kończy się demonstracją. Drugi trwa co najmniej dwa cykle procesu i kończy się liczbą. Decyzję o wdrożeniu podejmuje się na podstawie drugiego, a większość organizacji przeprowadza wyłącznie pierwszy.

Co musi być gotowe przed startem

Trzy rzeczy, bez których wynik pilotażu nie da się wykorzystać.

Opis procesu w wersji rzeczywistej, nie docelowej. Chodzi o to, jak praca jest wykonywana dzisiaj, razem z obejściami, arkuszami poza systemem i ustaleniami, których nikt nie spisał. Jeśli ten opis powstaje dopiero w trakcie pilotażu, połowa czasu schodzi na odkrywanie procesu zamiast na testowanie rozwiązania.

Wskazana osoba decyzyjna po stronie biznesu, która rozstrzyga wątpliwe przypadki. Bez niej pilotaż zatrzymuje się na pierwszym wyjątku i czeka.

Ustalone z góry kryterium przerwania. Pilotaż bez takiego kryterium trwa dopóty, dopóki ktoś nie straci cierpliwości, a jego wynik nikogo nie zobowiązuje.

Kiedy przerwać

Pilotaż należy przerwać, gdy okaże się, że proces wymaga przeprojektowania, zanim się go zautomatyzuje. To jest prawidłowy wynik, nie porażka – i zwykle najcenniejszy, jaki pilotaż może dać.

Sygnał jest zawsze ten sam. Rozwiązanie działa poprawnie, a mimo to praca nie ubywa, ponieważ czas schodzi na uzgadnianie, czekanie na dane albo poprawianie tego, co powstało wcześniej w procesie. Automatyzacja tego etapu niczego nie zmieni. Źle zaprojektowany proces po automatyzacji działa szybciej i drożej, bo do kosztu pracy dochodzi koszt utrzymania rozwiązania.

Drugi sygnał to rosnąca liczba wyjątków w miarę poszerzania próbki. Jeśli każdy nowy tydzień przynosi kolejne warianty, których wcześniej nie było, przedmiotem pracy nie jest wdrożenie, tylko uporządkowanie procesu.

Trzeci sygnał dotyczy danych. Jeśli w trakcie pilotażu ktoś regularnie poprawia dane wejściowe, żeby rozwiązanie mogło je przyjąć, wynik opisuje pracę tej osoby, a nie rozwiązania. Jej czas trzeba policzyć i dopisać do kosztu – zwykle zmienia to całą kalkulację.

Ostatnia uwaga dotyczy sposobu przedstawienia wyniku. Raport z pilotażu powinien podawać koszt jednostkowy po rozszerzeniu, odsetek spraw wymagających człowieka i szacunek pracy utrzymaniowej w skali roku. Trzy liczby wystarczą do podjęcia decyzji. Prezentacja opisująca możliwości technologii nie wystarczy do niczego, bo nie zawiera informacji, której odbiorca nie miał wcześniej.

FAQ

Ile powinien trwać pilotaż?

Tyle, ile potrzeba na zebranie losowej próbki obejmującej pełny cykl procesu, razem z okresami nietypowymi. Dla procesu miesięcznego oznacza to co najmniej dwa pełne cykle. Pilotaż krótszy niż jeden cykl mierzy przypadek, nie proces.

Czy warto zaczynać od najprostszego procesu?

Do sprawdzenia technologii tak, do podjęcia decyzji o wdrożeniu nie. Najprostszy proces daje wynik, którego nie da się przenieść. Lepszym wyborem jest proces reprezentatywny, nawet jeśli wynik będzie słabszy – bo ten wynik coś znaczy.

Kto powinien odbierać wynik pilotażu?

Osoba odpowiadająca za koszt procesu, nie za technologię. Pytanie brzmi, ile pracy zostaje po wdrożeniu i ile kosztuje utrzymanie, a nie jak skuteczny jest model.

Co zrobić z pilotażem, który się udał, ale nikt go nie rozszerzył?

Sprawdzić, czy nie zabrakło wskazanej osoby odpowiedzialnej za utrzymanie i budżetu na nie. Rozwiązanie bez właściciela przestaje działać przy pierwszej zmianie w systemie źródłowym i nikt tego nie zauważa, dopóki ktoś nie zapyta o wynik.