Większość pilotaży AI utyka z powodów, które mają niewiele wspólnego z modelem. Dane są bardziej chaotyczne niż w demie, ERP nie ma użytecznego połączenia, nikt nie odpowiada za wynik, nikt nie zatwierdza rezultatów i nikt nie ustalił, co oznacza „gotowe”. Pilotaż trafia na produkcję, gdy jeden przebieg pracy dostaje właściciela, etap zatwierdzania i miarę sukcesu, zanim cokolwiek powstanie.
#Najważniejsze wnioski
- Pilotaż, który zadziałał na demie, potwierdził model, a nie przebieg pracy wokół niego.
- Typowe blokady to dane, integracja ze starszymi systemami, odpowiedzialność, zatwierdzanie i brak definicji ukończenia.
- Podłączenie AI do starego ERP bez użytecznego API to projekt integracyjny, którego większość planów pilotażowych nigdy nie przewidywała.
- Pilotaż trafia na produkcję, gdy jedna wskazana osoba jest jego właścicielem, a inna zatwierdza to, co tworzy.
- Zacznij od jednego przebiegu pracy i prawdziwych użytkowników, a nie od trzech pilotaży i komitetu sterującego.
#Dlaczego pilotaże AI utykają przed produkcją?
Nie jesteś wyjątkiem, jeśli trzy pilotaże skończyły się jako trzy dema. Gartner, lipiec 2024 przewidywał, że 30% projektów generatywnej AI zostanie porzuconych po etapie proof of concept, wskazując na słabą jakość danych, słabą kontrolę ryzyka i niejasną wartość biznesową. Raport MIT, omówiony przez Virtualization Review w artykule o raporcie MIT NANDA, sierpień 2025, wykazał, że 95% organizacji nie odnotowało żadnego zwrotu biznesowego z generatywnej AI.
W firmach o rozbudowanych operacjach wciąż powracają te same pięć luk:
- Dane: pilotaż działał na czystej próbce. Prawdziwe dane wejściowe przychodzą jako zeskanowane pliki PDF, w połowie wypełnione formularze i wiadomości po arabsku i po angielsku.
- Integracja: przebieg pracy działa w piętnastoletnim ERP. Odczytu z niego i zapisu zwrotnego nigdy nie uwzględniono w zakresie.
- Brak właściciela: pilotaż należał do zespołu innowacji, a dział, który miałby z niego korzystać, nigdy o niego nie prosił.
- Brak etapu zatwierdzania: nikt nie ustalił, kto sprawdza wynik, zanim trafi do klienta, dostawcy lub księgi.
- Brak miary ukończenia: pilotaż oceniano po tym, czy zrobił wrażenie, a nie według liczby, którą dział już śledzi.
#Co się zmienia, gdy pilotaż jest budowany z myślą o produkcji?
Zmienia się kolejność pracy. Zamiast zaczynać od modelu, Stennir zaczyna od opisania jednego przebiegu pracy z osobą, która go prowadzi: skąd przychodzą dane wejściowe, jakie zasady obowiązują, dokąd trafia wynik i które wyjątki wymagają osądu. Ten opis staje się specyfikacją i wcześnie pokazuje, czy prawdziwą blokadą są dane, czy integracja.
Następnie przed budową uzgadnia się trzy rzeczy: kto po stronie klienta jest właścicielem przebiegu pracy, kto zatwierdza wynik i jaka miara oznacza ukończenie, na przykład wielkość zaległości lub udział spraw obsłużonych bez poprawek. Budowa odbywa się w systemach, z których zespół już korzysta, każde działanie trafia do dziennika, a prawdziwi użytkownicy widzą rozwiązanie od pierwszej wersji.
#Jak bezpiecznie przenieść prototyp z hackathonu na produkcję?
Prototyp z hackathonu to cenny dowód. Pokazuje, że zadanie jest wykonalne. Zwykle brakuje mu obsługi błędów, kontroli dostępu, rejestrowania działań, zestawu testowego z prawdziwych przypadków i sposobu wyłączenia. Traktuj prototyp jako szkic specyfikacji, a nie pierwszą wersję produkcyjną.
Bezpieczna ścieżka to przebudowa elementów, które dotyczą klientów lub pieniędzy, za etapem zatwierdzania, przetestowanie ich na zestawie prawdziwych, wcześniejszych przypadków i dodanie monitorowania, zanim dołączą kolejni użytkownicy. Przykład przeniesienia prototypu AI na produkcję przeprowadza przez te kroki na jednym przebiegu pracy.
We are
Stennir przenosi jeden przebieg pracy z pilotażu na produkcję w twoich własnych systemach, ze wskazanym właścicielem, osobą zatwierdzającą wynik i miarą uzgodnioną z góry.
We aren't
Stennir nie jest laboratorium, które prowadzi kolejne pilotaże, ani dostawcą platformy, który każe ci przenieść pracę do nowego narzędzia.
#Nasz projekt utknął na etapie testów. Od czego zacząć?
Wybierz pilotaż, którego dział naprawdę go chce, i poproś osobę, która korzystałaby z niego na co dzień, o opisanie pracy, którą zastępuje. Jeśli nie potrafi, pilotaż rozwiązywał niewłaściwy problem. Jeśli potrafi, spisz wyjątki, wskaż osobę zatwierdzającą i uzgodnij miarę. To zwykle pokazuje, czy luka dotyczy danych, integracji, czy odpowiedzialności.
Zespoły w regionie Zatoki często dodają jeszcze jeden krok: przebieg pracy musi obsługiwać dane wejściowe po arabsku i po angielsku, a nie tylko angielską próbkę, na której testowano pilotaż. Sprawdzenie tego wcześnie oszczędza kolejnego zastoju później.
#Co powinien zrobić dyrektor operacyjny z utkniętymi pilotażami w następnej kolejności?
Wybierz jeden utknięty pilotaż i jednego właściciela, a potem przyjdź z nimi na rozmowę o wdrożeniach AI, w ramach których Stennir buduje jeden przebieg pracy działający z prawdziwymi użytkownikami i monitoruje go później. Jeśli nie wiesz, który pilotaż na to zasługuje, doradztwo AI najpierw uszereguje opcje. Zobacz też AI dla operacji. Możesz wypełnić bezpłatną ocenę gotowości albo umówić 30-minutową rozmowę.
#Najczęstsze pytania
Czego potrzebujecie od nas, aby wznowić utknięty pilotaż?
Samego pilotażu, osoby, która korzystałaby z niego na co dzień, zestawu prawdziwych, wcześniejszych przypadków i dostępu do systemów, z których musi czytać i do których musi zapisywać. Wskazujesz też osobę zatwierdzającą wynik. Stennir wykorzystuje to, by opisać przebieg pracy i ustalić, która z pięciu luk go zatrzymała.
Czy możecie wykorzystać to, co już zbudowali nasi programiści?
Często tak. Prototyp pokazuje, które prompty i kroki działają. Stennir zachowuje to, co sprawdza się na prawdziwych przypadkach, i dobudowuje to, czego brakuje do produkcji: kontrolę dostępu, rejestrowanie, obsługę błędów, etap zatwierdzania i monitorowanie. Twoi programiści mogą nadal uczestniczyć w pracy i zachować kod, który pozostaje na twoich kontach.
Czy to działa ze starym ERP bez porządnego API?
Może działać, ale to praca integracyjna i od początku jest tak traktowana w zakresie. Możliwości obejmują odczyt eksportów, bezpośredni dostęp do bazy danych tylko do odczytu albo pracę przez ekrany, z których zespół już korzysta. Stennir określa podejście przed budową, aby nikogo później nie zaskoczyło.
Co może pójść nie tak na produkcji, choć nie poszło nie tak w pilotażu?
Prawdziwe dane wejściowe są bardziej chaotyczne, wolumeny wyższe, a pojawiają się nietypowe przypadki, których w próbce nie było. Dlatego Stennir zostawia zatwierdzanie wyniku człowiekowi, zapisuje każde działanie w dzienniku, testuje na prawdziwych, wcześniejszych przypadkach i monitoruje wyniki, gdy tylko zaczną korzystać prawdziwi użytkownicy, aby problemy ujawniały się w liczbach, a nie w skargach.
