Firma dystrybucyjna chce wykorzystać AI do przygotowywania ofert handlowych. Zapytania przychodzą e-mailem, często z załącznikami. Pracownicy odczytują pozycje, wyszukują produkty w ERP, sprawdzają ceny i dostępność, a potem przygotowują odpowiedzi. Zarząd liczy, że automatyzacja skróci czas oczekiwania klientów.
Na pierwszym spotkaniu dostawca pokazuje system, który w kilkanaście sekund zamienia przykładowe zapytanie w gotową ofertę. Prezentacja robi wrażenie. Rozmowa szybko schodzi na cenę, czas wdrożenia i wybór modelu AI.
Tylko że nikt jeszcze nie sprawdził, dlaczego przygotowanie oferty trwa tak długo. Być może przepisywanie danych jest rzeczywistym problemem. A być może oferta czeka dwa dni na akceptację kierownika, choć w większości przypadków taka akceptacja nie jest już potrzebna. Zautomatyzowanie tworzenia dokumentu nie usunie wtedy głównej przyczyny opóźnienia.
Dobrego partnera do wdrożenia AI poznaje się nie po tym, jak szybko pokazuje rozwiązanie, ale po tym, czy potrafi ustalić, jaki rezultat firma chce osiągnąć, dlaczego obecnie go nie osiąga i co naprawdę należy zmienić.
Pierwsza rozmowa: co chcemy osiągnąć i dlaczego dziś się to nie udaje?
Rozmowa discovery nie musi być wielodniowym audytem. Na początku chodzi o zrozumienie celu biznesowego, skali problemu i jego konsekwencji. „Chcemy automatycznie generować oferty” opisuje pomysł na narzędzie. „Chcemy szybciej odpowiadać klientom, bez zwiększania liczby handlowców i bez błędów cenowych” opisuje oczekiwany rezultat.
Wykonawca powinien zainteresować się liczbą zapytań, czasem ich obsługi, najczęstszymi pomyłkami i sprawami, które utknęły na dłużej. Ale równie ważne jest pytanie: dlaczego firma wykonuje ten proces właśnie w taki sposób?
Dlaczego handlowiec ręcznie wyszukuje produkt, skoro firma ma katalog? Dlaczego ceny sprawdza w kilku miejscach? Dlaczego każda oferta przechodzi przez kierownika? I dlaczego ta zasada nadal obowiązuje, jeśli sposób ustalania cen zmienił się od czasu jej wprowadzenia?
Nie chodzi o mechaniczne zadawanie pięciu pytań „dlaczego”. Chodzi o docieranie do przyczyn i sprawdzanie, czy odpowiedzi znajdują potwierdzenie w codziennej pracy. Czasami za niewygodną procedurą stoi istotna kontrola ryzyka. Innym razem pozostałość po dawnym systemie, której od lat nikt nie zakwestionował.
Dobry dostawca powinien umieć podsumować pierwsze ustalenia własnymi słowami, a także oddzielić to, co już wiadomo, od przypuszczeń. Jeśli mówi: „Najwięcej czasu tracicie na generowanie ofert”, powinien potrafić wskazać, skąd to wie. Jeżeli jeszcze tego nie sprawdził, nie powinien przedstawiać generatora jako gotowej odpowiedzi.
Demo może pomóc pokazać możliwości technologii. Nie powinno jednak zastępować rozmowy o przyczynach problemu.
Warsztat: nie wystarczy poznać, jak działa proces
Wstępna rozmowa wskazuje kierunek. Warsztat pozwala sprawdzić rzeczywisty przebieg pracy, najlepiej z udziałem osób, które codziennie przygotowują oferty, a nie tylko zarządu i działu IT.
Zespół może przejść przez kilka zakończonych spraw: od wiadomości klienta do wysłania odpowiedzi. Zobaczyć, skąd pochodzą dane, kto podejmuje decyzje, co odbywa się poza ERP i CRM, gdzie powstają opóźnienia i jakie wyjątki wymagają dodatkowej pracy.
Mapa czynności to dopiero połowa zadania. Przy każdym ważnym etapie trzeba też zapytać, po co on istnieje. Co zabezpiecza? Komu dostarcza informację? Jakie ryzyko powstałoby po jego usunięciu? Czy nie da się osiągnąć tego samego celu prościej?
Załóżmy, że w analizowanej firmie wszystkie oferty wymagają akceptacji kierownika. Zespół odkrywa, że zasadę wprowadzono kilka lat wcześniej, gdy handlowcy samodzielnie wyliczali ceny i mogli przyznać zbyt wysoki rabat. Dziś standardowe ceny i limity rabatowe są zapisane w ERP, lecz procedura pozostała niezmieniona. Kierownik nadal zatwierdza także oferty, które mieszczą się w przyjętych zasadach.
Pierwszym pomysłem mogłoby być użycie AI do przygotowywania wniosków o akceptację, przesyłania powiadomień i przypominania kierownikowi o zaległych ofertach. To przyspieszyłoby pewne czynności, ale pozostawiłoby kolejkę decyzji.
Kolejne pytanie „dlaczego?” prowadzi do innej możliwości: czy standardowe oferty w ogóle wymagają ręcznej akceptacji? Być może wystarczy zachować zatwierdzanie tylko dla nietypowych rabatów lub innych wyjątków.
Zanim firma usunie ten etap, trzeba jednak sprawdzić, czy kierownik nie kontroluje również ryzyka klienta, warunków płatności, dostępności produktów albo zobowiązań wynikających z umów. Nie każda historyczna procedura jest zbędna. Wartość warsztatu polega na zweryfikowaniu jej celu, a nie na założeniu, że wszystko, co ręczne, należy wyeliminować.
Rezultatem warsztatu powinno być nie tylko opisanie obecnego procesu, ale również uzasadnienie, które kroki należy zachować, zmienić lub zakwestionować.
Najpierw lepszy proces. Dopiero potem technologia
Po takim rozpoznaniu odpowiedzialny partner może zaproponować rozwiązanie inne niż to, o które początkowo poprosiła firma.
W naszym przykładzie możliwy docelowy proces jest prostszy: standardowe zapytania trafiają do przygotowania oferty na podstawie aktualnych danych, bez dodatkowej akceptacji kierownika, jeśli spełniają potwierdzone warunki. Sprawy niestandardowe nadal wymagają decyzji uprawnionej osoby. Dla obu grup wiadomo, kto odpowiada za wynik i co zrobić, gdy brakuje informacji.
Dopiero teraz jest właściwy moment na wybór narzędzi. Model AI może pomóc rozpoznać produkty i warunki w swobodnym e-mailu. Ceny i dostępność powinny pochodzić z właściwych systemów, a warunki rabatowe mogą być sprawdzane przez zwykłe reguły. O tym, jak dobierać technologię do poszczególnych kroków, była część o wyborze między LLM a prostszymi narzędziami. Jeśli istniejące ERP potrafi obsłużyć uproszczoną ścieżkę, nie trzeba budować osobnej aplikacji do zatwierdzania ofert.
W takim wariancie część korzyści pochodzi z usunięcia niepotrzebnej czynności, a nie z jej automatyzacji. AI pozostaje użyteczna tam, gdzie rzeczywiście rozwiązuje problem, na przykład przy interpretacji niejednoznacznych wiadomości klientów.
Dobra propozycja powinna zatem pokazywać docelowy sposób pracy, spodziewany efekt, elementy możliwe do usunięcia, obszary wymagające automatyzacji oraz założenia, które nadal trzeba sprawdzić. Powinna również dopuszczać wniosek, że w konkretnym obszarze bardziej opłaca się zmienić procedurę lub połączyć dwa systemy, niż wdrażać AI.
Partner technologiczny nie powinien być przywiązany do pomysłu, z którym klient przyszedł na pierwsze spotkanie. Powinien być przywiązany do rezultatu, który klient chce osiągnąć.
Rozumienie biznesu nie zastępuje kompetencji AI i inżynierskich
Dobrze poprowadzony warsztat nie dowodzi jeszcze, że dostawca potrafi zbudować działające rozwiązanie. Po uzgodnieniu docelowego procesu musi umieć przełożyć go na realistyczny projekt techniczny i wskazać ograniczenia.
W przypadku ofert handlowych powinien rozumieć, jak pozyskać aktualne dane z ERP, jak uzgodnić nazwy produktów z katalogiem, kto może zatwierdzać wyjątki oraz kiedy AI powinna przekazać sprawę pracownikowi. Powinien odróżniać przygotowanie propozycji od wykonania operacji, na przykład wysłania oferty klientowi, i wiedzieć, jak potwierdzić jej rzeczywisty wynik.
Potrzebne są również konkretne odpowiedzi dotyczące jakości AI: jak ją zmierzymy, na jakich rzeczywistych przypadkach sprawdzimy rozwiązanie, które pomyłki są niedopuszczalne oraz jak będziemy kontrolować poprawność po uruchomieniu. Dochodzą do tego bezpieczeństwo danych, koszt działania całego rozwiązania, a nie tylko modeli, integracje, obsługa wyjątków i utrzymanie.
Warto poprosić o przykłady wcześniejszych realizacji i sposób prowadzenia testów odbiorowych. Nie chodzi o ujawnianie poufnych szczegółów klientów, ale o dowody, że zespół rozumie różnicę między atrakcyjnym prototypem a systemem, na którym firma może codziennie polegać.
Dobry partner musi połączyć zdolność zakwestionowania procesu ze zdolnością bezpiecznego wdrożenia tego, co po analizie rzeczywiście ma sens. Jedno bez drugiego nie wystarczy.
Etap discovery ma prowadzić do decyzji, nie do kolejnego warsztatu
Nie każdy projekt da się rzetelnie wycenić po pierwszej rozmowie. Płatny etap analizy może mieć sens, jeśli trzeba zbadać przebieg pracy, ustalić przyczyny opóźnień, zweryfikować możliwość zmiany procedur albo sprawdzić dostęp do systemów.
Taki etap powinien mieć uzgodniony zakres, koszt, termin i rezultaty. Firma powinna otrzymać opis celu biznesowego i zidentyfikowanych problemów, mapę istotnego fragmentu procesu, ocenę zasadności jego kluczowych kroków, propozycję zmiany oraz listę założeń i ryzyk. Tam, gdzie jest to możliwe, warto porównać wariant obecny z proponowanym i wskazać, jak sprawdzimy spodziewane korzyści.
Jeżeli decyzja wymaga testu technicznego, dostawca powinien określić, co dokładnie ma on potwierdzić. Samo przeprowadzenie warsztatu lub zbudowanie prototypu nie jest jeszcze dowodem opłacalności wdrożenia.
Discovery nie musi być obowiązkowym, płatnym wstępem do każdej współpracy. Gdy problem, proces i integracje są już wystarczająco rozpoznane, można od razu przejść do ograniczonego projektu. Ważne, aby rezultat prac analitycznych dało się wykorzystać również wtedy, gdy firma wybierze innego wykonawcę albo zrezygnuje z wdrożenia.
Wartościowe discovery może zakończyć się także decyzją, by nie budować planowanego systemu. Jeżeli analiza wykazała, że usunięcie zbędnej akceptacji rozwiązuje główny problem, to dla klienta może być lepszy wynik niż zakup kolejnej aplikacji.
Jak porównać partnerów przed podpisaniem umowy?
Wróćmy do dwóch dostawców. Jeden zaczyna od pokazu generatora ofert. Drugi najpierw pyta o cel, analizuje proces i kwestionuje sens części jego etapów. To ważna różnica, ale sam porządek pierwszego spotkania nie rozstrzyga wyboru. Pierwszy wykonawca może być gotowy zweryfikować założenia, a drugi może prowadzić przekonujące warsztaty bez zdolności wdrożenia rezultatu.
Przed podpisaniem umowy warto sprawdzić pięć rzeczy:
- Zrozumienie celu. Czy wykonawca potrafi wyjaśnić, jaki wynik biznesowy firma chce poprawić, skąd bierze się obecny problem i co jeszcze wymaga sprawdzenia?
- Zadawanie pytań „dlaczego?”. Czy poznał nie tylko sposób wykonywania czynności, ale również ich uzasadnienie? Czy wskazał etapy, które można uprościć lub usunąć, i sprawdził konsekwencje takiej zmiany?
- Projekt rozwiązania. Czy proponuje lepszy proces przed doborem technologii? Czy rozważył wariant bez AI, z mniejszą automatyzacją albo z wykorzystaniem istniejących systemów?
- Wiarygodność wykonania. Czy potrafi uzasadnić architekturę, sposób integracji, wymagania dotyczące danych, metody sprawdzania jakości AI, kontrolę ryzyka i zasady utrzymania?
- Warunki inwestycji. Czy wiadomo, co firma otrzyma po każdym etapie, jak zostanie potwierdzony efekt, kto za co odpowiada oraz kiedy można ograniczyć lub zakończyć projekt?
Jeżeli wykonawca proponuje od razu wdrożenie, powinien wyjaśnić, dlaczego rozpoznanie jest już wystarczające. Jeżeli proponuje długie discovery, musi pokazać, jakie istotne niewiadome dzięki niemu wyjaśni. W obu przypadkach liczą się dowody, a nie nazwy etapów i efektowność prezentacji.
Dobry partner do wdrożenia AI zaczyna od pytania, po co firma chce coś zmienić. Potem sprawdza, dlaczego obecnie pracuje w określony sposób, co warto zachować, co zmienić, a z czego można zrezygnować. Dopiero do tak zaprojektowanego procesu dobiera technologię i bierze odpowiedzialność za sprawdzenie wyniku. Dzięki temu firma nie płaci za przyspieszanie czynności, których być może wcale nie musi wykonywać.