Pilot skończył się sukcesem, demo poszło dobrze, wszyscy byli zadowoleni. Pół roku później nikt tego nie używa i nikt nie potrafi powiedzieć, kiedy dokładnie temat umarł. To najczęstszy sposób, w jaki kończą się projekty AI, i prawie nigdy nie chodzi o technologię.
Powody są zwykle cztery: nie ma właściciela po stronie biznesu, kryteria sukcesu ustawiono technicznie zamiast biznesowo, w budżecie nie ma pozycji na produkcję, a efektu nikt nie zmierzył. Każdy z nich da się rozbroić przed startem pilota, a po fakcie prawie nie da się nadrobić.
Pilot ma odpowiedzieć na pytanie, czy to działa. Wdrożenie ma odpowiedzieć na pytanie, czy organizacja jest w stanie z tym pracować codziennie. To są inne pytania, inne ryzyka i inne kompetencje.
Dlatego udany pilot niczego nie przesądza. Pokazuje, że technologia daje się użyć w kontrolowanych warunkach, przy zaangażowanym zespole, na wybranych danych i bez presji czasu. Produkcja nie ma żadnej z tych rzeczy.
Najgorszy scenariusz to pilot zaprojektowany tak, żeby na pewno się udał. Dobiera się wtedy najprostszy przypadek, najczystsze dane i najbardziej entuzjastyczny zespół, a potem dziwi się, że reszta firmy nie powtarza wyniku.
Nie ma właściciela po stronie biznesu. Projekt prowadzi IT albo firma zewnętrzna, a po zakończeniu pilota nie ma nikogo, kto ma w swoich celach rocznych to, żeby narzędzie było używane. Sponsor z zarządu nie wystarczy, potrzebny jest ktoś, kto odpowiada za wynik operacyjny.
Kryteria sukcesu ustawione technicznie. Model osiąga zakładaną skuteczność, integracja działa, testy przechodzą. Nikt nie umówił się wcześniej, o ile ma spaść czas obsługi sprawy albo ile godzin miesięcznie ma wrócić do zespołu. Bez tego nie da się napisać uzasadnienia dla wydatku na produkcję.
W budżecie nie ma pozycji na produkcję. Pilot sfinansowano z rezerwy albo z budżetu innowacji. Wdrożenie wymaga licencji, integracji, utrzymania i czyjegoś czasu, a te pieniądze trzeba zaplanować rok wcześniej. Pilot kończy się w kwietniu, budżet układa się we wrześniu i temat wypada z kalendarza.
Efektu nikt nie zmierzył. Zespół twierdzi, że jest szybciej. Zarząd pyta, o ile. Odpowiedzi nie ma, bo nikt nie zapisał, jak było przed pilotem. Projekt bez liczby przed i po nie ma czym się obronić w konkurencji z projektami, które ją mają.
Zapisz stan wyjściowy. Ile czasu zajmuje dzisiaj ta czynność, ile spraw obsługujecie miesięcznie, ile kosztuje jedna. Pomiar zrobiony po starcie pilota jest już zanieczyszczony samym faktem, że ludzie wiedzą, że są mierzeni.
Ustal jedno kryterium biznesowe i jedną liczbę. Nie pięć wskaźników, tylko jeden, który przesądzi o decyzji. Kryteria techniczne mogą zostać obok, ale nie one rozstrzygają.
Wskaż właściciela z nazwiska i wpisz mu to w cele. Osoba z biznesu, nie z IT, i nie osoba z firmy wdrożeniowej.
Umów decyzję i jej datę. Kto podejmuje decyzję o wejściu na produkcję, na podstawie czego i kiedy. Pilot bez umówionej decyzji nie kończy się odmową, tylko ciszą, a cisza jest trudniejsza do zaadresowania.
Sprawdź dane, zanim obiecasz termin. Większość pilotów, które utknęły, utknęła na danych, nie na modelu. Dostępność, jakość, struktura, własność i zgodność to pięć rzeczy, które warto ocenić wcześniej niż w połowie projektu.
Na spotkaniach statusowych rozmawiacie o technologii, a nie o procesie.
Nikt z zespołu, który ma z tego korzystać na co dzień, nie był na warsztacie startowym.
Sukces jest opisany słowami, które nie mają jednostki: sprawniej, nowocześniej, wygodniej.
Na pytanie, kto to przejmie po zakończeniu pilota, pada odpowiedź, że to się ustali.
Termin decyzji przesuwa się drugi raz, za każdym razem o miesiąc.
Nie zaczynaj od kolejnego pilota. Powtórzenie tego samego z inną technologią daje ten sam wynik i zużywa resztę cierpliwości organizacji.
Odtwórz liczbę, choćby szacunkowo. Zapytaj zespół, ile czasu zajmowała ta praca wcześniej i ile zajmuje teraz. Szacunek zapisany z datą i opisem sposobu liczenia jest wart znacznie więcej niż brak jakiejkolwiek liczby.
Znajdź właściciela albo zamknij temat świadomie. Projekt bez właściciela nie umiera po cichu za darmo, tylko obciąża każdą kolejną rozmowę o AI w tej firmie.
Jeśli zamykasz, spisz wnioski, dopóki ludzie pamiętają szczegóły. Za pół roku zostanie z tego zdanie, że kiedyś próbowaliśmy i nie wyszło, a to najgorszy możliwy materiał na start następnego projektu.
Tyle, ile potrzeba na zebranie danych do jednej decyzji, zwykle od czterech do dwunastu tygodni. Dłuższy pilot rzadko przynosi lepszą odpowiedź, a częściej oznacza, że pytanie nie zostało dobrze postawione na starcie.
Osoba odpowiedzialna za proces, który ma się zmienić, a nie za technologię. Jeśli projekt dotyczy obsługi klienta, właścicielem jest ktoś z obsługi klienta. IT odpowiada za wykonalność, nie za to, czy narzędzie będzie używane.
Odtworzyć go z tego, co zostało: raportów operacyjnych, ewidencji czasu, liczby obsłużonych spraw sprzed wdrożenia. Jeśli nie ma nic, warto zapytać zespół o szacunek i zapisać go razem ze sposobem liczenia oraz datą. Szacunek opisany uczciwie broni się lepiej niż liczba bez źródła.
Zwykle nie. Częściej oznacza, że wybrano zły proces, dane nie były gotowe albo nikt nie odpowiadał za wynik. Warto rozdzielić te trzy przyczyny przed decyzją o rezygnacji, bo każda prowadzi do innego wniosku.
Zaktualizowano: 21.08.2026.