Wycofywanie się z AI: prawdziwe historie liderów
Lekcje dotyczące AI: Wielu liderów pomija wartościowe lekcje płynące z nieudanych lub wstrzymanych projektów AI, choć dostarczają one kluczowych spostrzeżeń.
Zatrzymanie zamiast parcia naprzód: Firmy często odnoszą korzyści z wstrzymania inicjatyw związanych z AI, aby ustanowić podstawowe procesy i zapewnić wysoką jakość danych.
Najpierw ręcznie: Automatyzacja powinna nastąpić dopiero po ręcznym wykonaniu zadania, co gwarantuje, że procesy są jasno zdefiniowane i zrozumiane.
Mierz wpływ: Kluczem do sukcesu jest ocena obecnych procesów i potencjalnego wpływu AI przed rozpoczęciem wdrożenia.
Znaczenie dokumentacji: Skuteczna dokumentacja powinna obejmować nie tylko procesy, lecz także uzasadnienie decyzji i przypadki wyjątkowe.
Większość historii o wdrażaniu AI opowiada się z perspektywy zwycięskiego podium. Znacznie mniej liderów mówi o momencie, w którym wycofali się z projektu — anulowanej automatyzacji, wstrzymanym wdrożeniu czy projekcie pilotażowym, który trzeba było zbudować od podstaw. Jednak to właśnie w tych historiach często kryją się najważniejsze lekcje.
Zapytaliśmy troje ekspertów, którzy przez to przeszli: co zostało cofnięte, dlaczego i co zrobilibyście inaczej? Ich odpowiedzi łączy zaskakująco spójny wątek — problemem niemal nigdy nie jest samo AI.
Kiedy rozsądnym posunięciem jest wstrzymanie działań, a nie przeć naprzód
W przypadku większości organizacji całkowite wycofanie inwestycji w AI nie jest realistyczne, gdy wydano już na nią środki. Tejinder, starszy menedżer w Deloitte Consulting, mówi wprost, że całkowite usunięcie rozwiązania nie wchodziło w grę ze względu na poczynione inwestycje — możliwe było jednak celowe wstrzymanie działań. Gdy wyniki nie spełniały oczekiwań, jego zespół zrobił krok wstecz i „najpierw przyjrzał się podstawom”, zadając sobie pytanie, czy podstawowe procesy zostały ustanowione, czy „jakość danych” jest „dobra” oraz czy planiści rozumieją rolę agentów w porównaniu z własną rolą. „Myślę, że gdy uzyskaliśmy odpowiedzi na te pytania, ponowne uruchomienie miało sens” — mówi.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Priyanka Dave, PhD, liderka ds. podnoszenia kwalifikacji i właścicielka procesu uczenia się na Oregon State University, wielokrotnie obserwowała ten sam schemat. „Zaobserwowałam, że kilka organizacji celowo opóźniło rozszerzanie inicjatyw związanych z AI po uświadomieniu sobie, że nie było jeszcze gotowych operacyjnie”. W takich przypadkach wycofanie się nie było porażką — było zmianą kierunku. „Zamiast natychmiast rozszerzać wykorzystanie AI, kierownictwo skupiło się na wzmacnianiu fundamentów organizacji” — wyjaśnia Dave. Oznaczało to, że „organizacje inwestowały w dokumentowanie procesów biznesowych, standaryzację przepływów pracy, poprawę zarządzania danymi oraz rozwijanie kompetencji pracowników poprzez ustrukturyzowane uczenie się i zarządzanie zmianą”.
Zamiast natychmiast rozszerzać wykorzystanie AI, kierownictwo skupiło się na wzmacnianiu fundamentów organizacji.
Nie automatyzuj tego, czego wcześniej nie wykonano ręcznie
Czasami cofnięcie się oznacza całkowite anulowanie projektu — i odkrycie, że od początku była to właściwa decyzja. Jaime Gil Martinez, założyciel i główny konsultant w Swift Ops Solutions, przekonał się o tym na własnej skórze. „Kiedyś zbudowałem automatyzację do tworzenia materiałów marketingowych dla klienta, który nigdy wcześniej nie realizował tego procesu ręcznie” — wspomina. „Ponieważ było to dla niego nowe, oboje uznaliśmy, że lepiej będzie od razu zbudować ten proces w sposób zautomatyzowany. Na papierze miało to sens. Z perspektywy czasu był to błąd początkującego”.
System działał pod względem technicznym. „Automatyzacja działała” — mówi Gil Martinez. „Problem polegał na tym, że za każdym razem, gdy potrzebny był jakiś rezultat, trzeba było ponownie rozważyć pewne kwestie lub coś dostosować (inny odbiorca, inny format, inny układ), więc ciągle ją przebudowywałem. Po kilku takich rundach schemat stał się oczywisty — automatyzowałem proces, którego nikt jeszcze nie zdefiniował”.
Po kilku rundach [wprowadzania poprawek] stało się oczywiste, że automatyzowałem proces, którego nikt jeszcze nie zdefiniował.
Rozwiązaniem było cofnięcie się. „Anulowaliśmy więc projekt i wróciliśmy do ręcznego tworzenia materiałów” — mówi. „I właśnie o to chodziło: każda ręczna iteracja dostarczała nam tego, czego wcześniej brakowało, czyli przykładów najwyższej jakości oraz jasnego obrazu tego, co się zmieniało, a co pozostawało niezmienne. Później wznowiliśmy automatyzację, a ręcznie przygotowane materiały stały się bazą wiedzy, którą przekazaliśmy AI”. To doświadczenie doprowadziło do sformułowania zasady, którą stosuje teraz w swojej firmie i u swoich klientów: „nie automatyzuj niczego, dopóki nie wykonasz tego ręcznie co najmniej trzy razy. Dopiero wtedy możesz zacząć się nad tym zastanawiać”.
Krok pomijany przez wszystkich: zmierz, zanim zbudujesz
Zapytaj Gila Martineza, czego brakuje w większości planów wdrażania AI, a odpowie natychmiast: „Pomiarów wykonanych przed rozpoczęciem budowy. W momencie rozpoczęcia prac większości firm brakuje dwóch informacji: tego, jak dobry lub zły jest ich obecny proces, oraz jaki wpływ AI może realnie na niego wywrzeć. Bez obu tych danych nie da się stwierdzić, jak skuteczne było wdrożenie ani czy jego koszt był uzasadniony”.
Wskazuje na klinikę medyczną, która chciała zautomatyzować planowanie wizyt dla ponad 100 pacjentów. „Nie wiedzieli, ile czasu im to zajmuje, wiedzieli tylko, że jest to czasochłonne i frustrujące” — mówi. „A jeśli nie wiesz, ile czasu coś zajmuje, nie wiesz też, ile cię to kosztuje”. Dlatego przed zbudowaniem czegokolwiek jego pierwszym krokiem było obliczenie liczby godzin pochłanianych przez planowanie wizyt oraz finansowej wartości tych godzin. „Dało nam to punkt odniesienia: dwa tygodnie pełnej pracy ręcznej. Automatyzacja skróciła ten czas do jednego dnia pracy wspomaganej przez AI, a koszt był niższy niż ich obecne równoważne wydatki”. Mając te liczby, „decyzja nasunęła się sama”.
Dave dostrzega inne, ale równie istotne przeoczenie: gotowość nie dotyczy wyłącznie technologii. „Najczęściej pomijanym przez organizacje krokiem, który obserwuję, jest ocena kompetencji pracowników przed wdrożeniem AI” — mówi. Luki rzadko okazują się jednak związane ze szkoleniem z obsługi narzędzi. W ramach kilku ocen kompetencji „konsekwentnie ujawniały się większe braki w zakresie myślenia analitycznego, myślenia krytycznego, biegłości w pracy z danymi, komunikacji konsultacyjnej i rozwiązywania problemów”. Jego najważniejszy wniosek brzmi: „Gotowość technologiczna i gotowość pracowników to różne wyzwania. Zrównoważone wdrażanie AI wymaga obu”.
Co się dzieje, gdy AI trafia do niegotowego procesu
Co właściwie się psuje, gdy AI zostaje nałożona na niedojrzały proces? Tejinder zobaczył to na własne oczy, gdy „AI została osadzona w procesie biznesowym (przetwarzaniu zamówień i alokacji), który nie był wystarczająco dojrzały” — rezultatem było rozwiązanie pełne błędów. Jednocześnie jasno wskazuje, gdzie leżała przyczyna: „Uważam, że problemem nie była tutaj AI” — mówi, wskazując zamiast tego na dojrzałość procesu, problemy z danymi podstawowymi, niezlikwidowane luki w wymaganiach oraz niewystarczające testy.
AI została osadzona w procesie biznesowym (przetwarzaniu zamówień i alokacji), który nie był wystarczająco dojrzały.
Dave opisuje tę samą dynamikę na podstawie swoich ocen: różne działy wykonujące tę samą pracę na różne sposoby, niepełną dokumentację oraz wyjątki istniejące wyłącznie w głowach pracowników. „Obawiano się, że AI będzie po prostu powielać niespójne praktyki w całej organizacji” — mówi. Jest to konsekwencja zasady, do której często wraca: „AI nie rozwiązuje problemów organizacyjnych. Wzmacnia istniejące systemy. Jeśli procesy są niespójne lub słabo udokumentowane, AI często skaluje te niespójności, zamiast je poprawiać”. Wniosek, jej słowami, brzmi: „Powtarzająca się lekcja była taka, że organizacje powinny usprawnić procesy, zanim spróbują je zautomatyzować”.
Jeśli procesy są niespójne lub słabo udokumentowane, AI często skaluje te niespójności, zamiast je poprawiać.
Gil Martinez ma w tej kwestii własne bolesne doświadczenia — aplikację do generowania potencjalnych klientów, która „za pierwszym razem spektakularnie zawiodła”. Budowa przeskoczyła z poziomu częściowo ręcznego do w pełni zautomatyzowanego bez zdefiniowanych wymagań i testów. „Moim błędem było założenie, że AI sama rozpracuje część logiki, ponieważ logika wydawała się oczywista i prosta” — przyznaje. Od tego momentu sytuacja zaczęła się wymykać spod kontroli. „Kod stał się niemożliwy do opanowania i w całości zależny od AI, do tego stopnia, że nie mogłem wrócić do bezpiecznego etapu. Wtedy zrozumiałem, że problem miał charakter strukturalny, a nie dotyczył tylko błędów”.
Odzyskanie kontroli wymagało pełnego resetu. „Naprawa była równie bolesna, co oczywista: zacząć od nowa” — mówi. „Tym razem opisałem każde wymaganie i test dla każdego z nich, budowałem rozwiązanie stopniowo, a także przekazałem AI jasne instrukcje dotyczące rejestrowania niepowodzeń i sukcesów oraz właściwego zarządzania wersjami”. Zdyscyplinowana druga próba „zajęła mniej więcej połowę czasu, który zmarnowałem przy pierwszej próbie, aby osiągnąć działające rozwiązanie gotowe do użytku produkcyjnego”.
Jak naprawdę wygląda dobra dokumentacja na potrzeby AI
U podstaw wszystkich trzech historii leży to samo rozwiązanie: dokumentacja opisująca, jak faktycznie wykonywana jest praca. Dla Dave oznacza to wyjście poza listy zadań. „Dobra dokumentacja procesu wyjaśnia nie tylko, co robią ludzie, lecz także dlaczego podejmują określone decyzje” — mówi. Najcenniejsze informacje to zazwyczaj te, które nigdy nie zostają zapisane. „Jednym z najczęstszych błędów popełnianych przez organizacje jest dokumentowanie wyłącznie standardowego przebiegu pracy. Największa wiedza organizacyjna często kryje się w wyjątkach, decyzjach wymagających osądu oraz decyzjach kontekstowych podejmowanych przez doświadczonych pracowników”.
Gil Martinez ujmuje to z perspektywy, którą PM-y będą coraz częściej rozpoznawać: „Dobra dokumentacja procesów odzwierciedla inżynierię promptów. Te same elementy, które nauczyliśmy się przekazywać AI w prompcie (rola, kontekst, zadanie, instrukcje, ograniczenia), powinny pojawiać się na poziomie projektu”. Ta zmiana ma wpływ na sposób, w jaki praktycy spędzają swój czas. „Czas realizacji zadań przez ludzi zanika, ponieważ jest przekazywany AI, więc musimy skupić się na dobrym planowaniu i weryfikowaniu wyników. Musimy działać jak menedżerowie AI”.
Wnioski: kolejność jest strategią
Żaden z tych liderów nie żałuje inwestycji w AI. Żałują natomiast — lub obserwowali, jak inni żałują — kolejności podejmowanych działań. Tejinder podsumowuje to tak: „Wdrożenia AI w przedsiębiorstwach kończą się niepowodzeniem, gdy model zostaje wdrożony przed przygotowaniem podstaw operacyjnych. Właściwa kolejność to najpierw dojrzałość procesów, jakość danych i jasność ról. Dopiero potem AI. Gdy organizacje odwracają tę kolejność, obwiniają AI, ale podstawowym problemem jest niemal zawsze środowisko, w którym AI zostało zastosowane”. Okazuje się, że cofnięcie się nie jest porażką. Porażką jest wdrożenie, zanim organizacja będzie gotowa.
Chcesz uzyskać więcej podobnych informacji? Załóż bezpłatne konto DPM, aby poznać opinie większej liczby ekspertów.
