Od pomysłu do problemu, który można sprawdzić
„Chcemy wdrożyć AI w sprzedaży” jest kierunkiem zainteresowania, ale jeszcze nie opisem projektu. Sprzedaż obejmuje pozyskanie zapytania, kwalifikację klienta, przygotowanie oferty, negocjacje i dalszą obsługę. Każdy etap ma inne dane i inne ryzyko. Próba usprawnienia wszystkiego jednocześnie utrudnia ocenę, która zmiana rzeczywiście pomogła. Zespół otrzymuje nowe obowiązki, zanim ustali, jak rozpoznać dobry wynik.
Znacznie konkretniejszy problem brzmi: pracownicy potrzebują długo szukać informacji, aby przygotować projekt odpowiedzi na powtarzające się zapytania. Wtedy można sprawdzić liczbę takich spraw, czas zebrania danych i częstotliwość poprawek. Wiadomo także, kto korzysta z rozwiązania i kto ocenia jego pracę. Podobnie można zawęzić analizę dokumentów, klasyfikację zgłoszeń lub wyszukiwanie wiedzy wewnętrznej.
Projekt powinien zaczynać się od zdania, które opisuje pracę do poprawienia i jej znaczenie dla firmy. Jeśli nie umiemy tego powiedzieć bez nazwy aplikacji, warto wrócić do rozmów z zespołem. Może się okazać, że przyczyną opóźnienia jest brak zatwierdzonego cennika albo niejasne przekazywanie spraw. Taki problem wymaga najpierw decyzji organizacyjnej, a dopiero później wyboru narzędzia.
Wybierz zastosowanie, które ma właściciela
Dobry kandydat na pierwszą próbę powtarza się wystarczająco często, aby można było zobaczyć efekt. Pracownik powinien móc ocenić, czy wynik jest użyteczny, a firma posiadać dostęp do potrzebnych danych. Liczy się również konsekwencja pomyłki. Projekt szkicu wiadomości, który ktoś sprawdza, ma inne wymagania niż automatyczne ustalanie warunków umowy i wysłanie ich klientowi.
W raporcie OECD, BCG i INSEAD o adopcji AI w przedsiębiorstwach wskazano między innymi niepewność zwrotu z inwestycji i niedojrzałość danych jako przeszkody we wdrożeniach. To międzynarodowe opracowanie, którego zasadnicze badanie przeprowadzono w latach 2022–2023. Nie jest prognozą wyniku konkretnej polskiej firmy. Pomaga jednak nazwać pytania, które pozostają aktualne przy planowaniu projektu.
Właściciel procesu musi mieć czas na te pytania oraz możliwość podejmowania decyzji. Powinien ustalić priorytet, rozstrzygać wątpliwości dotyczące materiałów i zatwierdzać kryteria jakości. Jeśli odpowiedzialność rozmywa się między dostawcą, IT i kierownikiem działu, pilotaż będzie czekał na decyzje. Sponsor w zarządzie może pomóc usunąć takie przeszkody, lecz nie zastąpi osoby znającej codzienną pracę.
Zmierz stan wyjściowy, zanim zmienisz sposób pracy
Ocena wdrożenia wymaga punktu odniesienia. Warto przeanalizować reprezentatywny zestaw spraw z okresu przed uruchomieniem narzędzia. Oprócz czasu wykonania trzeba zapisać rodzaj zadania, jego trudność i wynik. Inaczej skrócenie obsługi prostych przypadków może zostać porównane z wcześniejszym okresem, w którym dominowały trudne zgłoszenia. Liczba wygląda wtedy dobrze, ale nie opisuje rzeczywistej zmiany.
Przy przygotowywaniu ofert można mierzyć czas zebrania informacji, opracowania dokumentu i kontroli przez przełożonego. W obsłudze zapytań ważne bywają czas odpowiedzi oraz liczba spraw, do których klient musi wrócić. Przy wyszukiwaniu wiedzy znaczenie ma trafność znalezionego dokumentu i jego aktualność. Każdy miernik powinien odpowiadać temu, co firma chce poprawić, zamiast dostępności statystyki w panelu narzędzia.
Szybsze wygenerowanie odpowiedzi nie oznacza jeszcze szybszego zakończenia sprawy. Jeżeli pracownik długo sprawdza tekst albo poprawia brakujące dane, należy uwzględnić ten czas. Warto zapisywać również przypadki, w których narzędzie nie pomaga. Wynik obejmujący tylko udane próby utrudnia podjęcie decyzji o szerszym zastosowaniu i tworzy zbyt optymistyczny obraz kosztów.
Ustal, co będzie dowodem powodzenia
Przed rozpoczęciem prac firma powinna określić minimalny poziom jakości i warunki dalszej inwestycji. W hipotetycznym projekcie odpowiedzi na zapytania kryterium może obejmować krótszy czas przygotowania, poprawne użycie danych oraz brak nieautoryzowanych obietnic. Nie chodzi o uniwersalny próg dla wszystkich firm. Wymagania wynikają z charakteru zadania i konsekwencji błędu.
Warto wskazać także warunek zatrzymania próby. Może nim być brak dostępu do aktualnych danych, zbyt duża liczba poprawek albo koszt kontroli wyższy od uzyskanej korzyści. Ustalenie tego z góry ogranicza skłonność do ciągłego rozszerzania projektu tylko dlatego, że wydano już pieniądze. Zespół powinien wiedzieć, kiedy zgłosić problem i kto podejmuje decyzję o zmianie zakresu.
Podczas oceny trzeba oddzielić wymagania konieczne od wygodnych dodatków. Rozwiązanie może działać poprawnie bez rozbudowanego panelu, ale nie powinno działać bez kontroli uprawnień. Może wymagać ręcznego zatwierdzenia odpowiedzi, jeśli taki jest uzgodniony zakres. Jasny podział umożliwia przeprowadzenie pierwszej próby bez budowania całego systemu docelowego i bez pomijania ważnych zabezpieczeń.
Przygotuj dane tylko w zakresie potrzebnym do próby
Prace nad AI mogą ujawnić, że dokumenty są nieaktualne, mają różnych właścicieli lub powielają sprzeczne instrukcje. Nie zawsze trzeba naprawiać całą bazę przed rozpoczęciem projektu. Można wybrać ograniczony zestaw materiałów dla jednego zadania i ustalić sposób ich utrzymania. Ważne, aby narzędzie korzystało z informacji, które firma rzeczywiście uznaje za obowiązujące.
Przygotowanie obejmuje także ocenę, czy materiały wolno przetwarzać w wybranym środowisku. Dokument klienta, dane pracownika i ogólnodostępna instrukcja mają różny charakter. Dostęp do nich powinien wynikać z roli użytkownika i celu zadania. Decyzji o przesłaniu danych nie należy opierać wyłącznie na tym, że aplikacja umożliwia dodanie pliku lub posiada płatny abonament.
Przydatne są wskazówki NIST dotyczące zarządzania ryzykiem generatywnej AI. Stanowią dobrowolne ramy pracy z ryzykiem, a nie potwierdzenie zgodności z prawem europejskim. W praktyce pomagają przypomnieć, że odpowiedzialność dotyczy zarówno przygotowania danych, jak i użycia wyników oraz monitorowania rozwiązania po uruchomieniu.
Policz koszt całego sposobu pracy
Cena licencji jest tylko częścią wydatku. Dochodzi do niej przygotowanie danych, integracja, konfiguracja, szkolenie i czas pracowników biorących udział w testach. Po uruchomieniu trzeba utrzymywać dokumentację, kontrolować jakość i obsługiwać sytuacje nietypowe. Model korzystający z dużych plików lub wykonujący wiele prób może generować zmienny koszt, który nie jest widoczny w krótkiej prezentacji.
W kalkulacji warto rozdzielić jednorazowy koszt projektu od kosztu wykonania sprawy. Ten drugi obejmuje wykorzystanie modelu, działanie systemów i kontrolę człowieka. Pozwala to porównać nowe rozwiązanie z dotychczasowym procesem. Osobno należy ocenić, czy uzyskany czas przełoży się na mniejszy wydatek, więcej obsłużonych klientów czy po prostu większą dostępność pracowników.
Przykład może być prosty: jeżeli projekt skraca pracę administracyjną, ale firma nadal ponosi taki sam koszt zatrudnienia, nie należy przedstawiać całego odzyskanego czasu jako oszczędności gotówkowej. Można opisać zwiększoną zdolność obsługi lub możliwość przeznaczenia czasu na inne zadania. Uczciwa kalkulacja odróżnia odzyskane godziny, poprawę jakości i rzeczywistą zmianę kosztów.
Testuj również sprawy trudne i niejednoznaczne
Prezentacja narzędzia zwykle pokazuje przypadek, w którym dostępne są wszystkie potrzebne dane. Codzienna praca zawiera braki, niejasne wiadomości i dokumenty z błędami. Zestaw testowy powinien obejmować oba rodzaje sytuacji. Jeśli AI nie potrafi udzielić poprawnej odpowiedzi, użytecznym wynikiem może być skierowanie sprawy do pracownika zamiast stworzenia wiarygodnie brzmiącego wyjaśnienia.
Na potrzebę takiej oceny wskazuje badanie Dell’Acqui i współautorów o granicach możliwości modeli. W eksperymencie z 2023 r. efekty różniły się w zależności od zadania, a poza możliwościami badanego modelu korzystanie z niego mogło pogorszyć poprawność rozwiązania. To starszy wynik dotyczący konkretnego środowiska, ale dobrze uzasadnia sprawdzanie własnych przypadków.
Testowanie nie powinno kończyć się na ocenie tekstu. Trzeba sprawdzić, jak rozwiązanie zachowa się, gdy nie odpowiada system źródłowy, pracownik cofnie uprawnienia albo ten sam dokument pojawi się ponownie. Jeśli projekt obejmuje integrację, znaczenie ma prawidłowe wykonanie całej czynności. Poprawna analiza z błędnym zapisem w CRM nadal jest błędem procesu.
Przeprowadź pilotaż z ludźmi, którzy będą używali narzędzia
Użytkownicy powinni wiedzieć, jakiego rodzaju zadania obejmuje próba i w jakich przypadkach wracają do dotychczasowej metody. Potrzebują też miejsca do zgłaszania uwag. Krótki opis błędu wraz z kontekstem sprawy bywa bardziej wartościowy niż ogólna ocena, że aplikacja jest dobra lub słaba. Pozwala rozróżnić problem modelu, instrukcji, dokumentów i projektu interfejsu.
Pierwsza grupa może być niewielka, ale powinna reprezentować rzeczywisty sposób pracy. Wybranie wyłącznie entuzjastów technologii utrudnia ocenę późniejszej adopcji. Warto zobaczyć, czy osoba mniej doświadczona rozumie ograniczenia i potrafi sprawdzić wynik. Przeszkodą może być również brak czasu na naukę albo konieczność ręcznego kopiowania danych między aplikacjami.
W takim projekcie szkolenie zespołu powinno dotyczyć konkretnych czynności, materiałów i zasad. Uczestnicy muszą umieć rozpoznać wynik niegotowy do użycia, a nie tylko otrzymać instrukcję uruchomienia narzędzia. Wdrożenie zmieniające pracę wymaga uzgodnienia, kto sprawdza rezultat i co się dzieje, gdy pracownik nie może podjąć decyzji samodzielnie.
Uzgodnij odbiór projektu i możliwość zmiany dostawcy
Zakres współpracy powinien wskazywać, co firma otrzyma po zakończeniu próby. Poza samym dostępem do rozwiązania potrzebne mogą być opis konfiguracji, instrukcja dla użytkowników i wyniki testów. Warto ustalić, kto utrzymuje integrację, kto aktualizuje materiały oraz jaki koszt będzie obowiązywał po pilotażu. Krótka próba nie powinna ukrywać zobowiązania do długiej współpracy, którego organizacja nie rozumie.
Szczególne znaczenie mają prawa do danych i możliwość ich eksportu. Firma powinna wiedzieć, co stanie się z dokumentami, zapisami spraw i konfiguracją po zakończeniu umowy. Jeżeli rozwiązanie zależy od jednego konta dostawcy, trzeba omówić możliwość przejęcia utrzymania lub wyłączenia systemu. Te pytania warto rozstrzygnąć przed rozpoczęciem prac, gdy można jeszcze porównać kilka sposobów realizacji.
Odbiór powinien obejmować uzgodnione przypadki, w tym takie, na których rozwiązanie nie było wcześniej dopracowywane. Samo poprawne przejście przez przykłady używane podczas budowy może dawać zbyt dobry obraz. Nowy zestaw pokazuje, czy system radzi sobie z podobną pracą, czy tylko z przygotowaną demonstracją. Wynik trzeba odnieść do wcześniejszych kryteriów jakości i dopuszczalnego zakresu ręcznej kontroli.
Warto również ustalić sposób postępowania po zmianie modelu lub integracji. Dostawca może proponować aktualizację poprawiającą jeden rodzaj zadania, ale pogarszającą inny. Organizacja potrzebuje możliwości sprawdzenia ważnych przypadków przed przeniesieniem całej pracy. Dokumentacja zmian i ponowna ocena pozwalają utrzymać odpowiedzialność za wynik także po zakończeniu fazy projektowej.
Te uzgodnienia mają wpływ na budżet. Tania próba może okazać się kosztowna, jeśli firma później nie potrafi samodzielnie utrzymać materiałów albo każda korekta wymaga dodatkowego zamówienia. Z kolei bardziej szczegółowe przygotowanie może być uzasadnione, gdy proces ma pozostać w codziennym użyciu przez dłuższy czas. Nie chodzi o rozbudowanie każdego pilotażu, lecz o widoczność kosztów i warunków kontynuacji.
Przed startem warto wiedzieć zarówno, jak projekt zostanie odebrany, jak i jak można go zakończyć. Możliwość odłożenia rozwiązania, przeniesienia danych lub powrotu do wcześniejszej metody daje firmie realny wybór. Ułatwia także ocenę wyników bez presji, że dalsza inwestycja jest jedyną drogą po przeprowadzeniu próby.
Podejmij decyzję o dalszym projekcie na podstawie wyników
Po pilotażu trzeba wrócić do wcześniej ustalonych kryteriów. Jeśli jakość jest odpowiednia, koszt akceptowalny, a użytkownicy potrafią pracować z rozwiązaniem, można rozszerzać zakres stopniowo. Każdy nowy rodzaj spraw i każde dodatkowe źródło danych mogą jednak zmienić ryzyko. Wynik próby w jednym dziale nie jest automatycznym potwierdzeniem przydatności w całej organizacji.
Jeżeli efekt jest mieszany, warto ustalić przyczynę. Być może narzędzie działa dobrze dla części zapytań, a pozostałe powinny trafiać bezpośrednio do człowieka. Może też potrzebować lepiej przygotowanej wiedzy. Zakończenie nietrafionego pilotażu pozwala ograniczyć dalsze wydatki, o ile zespół zapisze wnioski. Firma nie powinna wracać za kilka miesięcy do tego samego pomysłu bez pamięci o wcześniejszych problemach.
Przed uruchomieniem szerszego projektu pomocne bywa doradztwo i strategia AI, a po wyborze zastosowania wdrożenie w konkretnym procesie. Rozmowa powinna dotyczyć danych, warunków powodzenia i odpowiedzialności. Najlepszym pierwszym krokiem jest opisanie jednej sprawy, która dzisiaj wymaga zbyt wiele pracy, oraz ustalenie, co musi się zmienić, aby firma uznała projekt za wartościowy.
Bibliografia
- OECD, BCG, INSEAD, „The Adoption of Artificial Intelligence in Firms”, 2025.
- NIST, „Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile”, 2024.
- Dell’Acqua, F. i współautorzy, „Navigating the Jagged Technological Frontier”, 2023, Working Paper 24-013.