Rozmowa o wdrożeniu zwykle zaczyna się od zdania „zastanawiamy się nad AI” albo „szukamy nowego CRM-a”. To zdanie już jest błędem — nie dlatego, że narzędzie jest złe, ale dlatego, że zaczyna od odpowiedzi, zanim padło pytanie. Zanim wybierzesz technologię, opisz use case: problem, proces, właściciela, dane, oczekiwany wynik, sposób pomiaru, ograniczenia i sposób weryfikacji. Narzędzie — AI, automatyzację, SaaS czy coś zbudowanego u siebie — wybierasz dopiero wtedy. Ten tekst dotyczy każdego z nich, nie tylko AI. Kolejność jest ważniejsza, niż się wydaje, bo to ona decyduje, czy wdrożenie rozwiąże realny problem, czy tylko doda kolejny system do utrzymania.
Dlaczego firmy zaczynają od narzędzia
Narzędzie jest konkretne, a problem bywa niewygodny. Łatwiej powiedzieć „wdrożymy AI”, niż przyznać „nie wiemy dokładnie, gdzie tracimy szanse i dlaczego”. Do tego dochodzi presja: konkurencja coś wdraża, zarząd pyta o AI, a na rynku jest gotowe demo na każdą potrzebę. Więc firma kupuje rozwiązanie, zanim opisała problem, a potem szuka problemu, który to rozwiązanie rozwiąże. Koszt tej kolejności jest przewidywalny: licencja i wdrożenie idą, a wynik nie, ponieważ narzędzie trafiło w proces, którego nikt nie zdefiniował. Po kilku miesiącach narzędzie ląduje na półce, a w firmie zostaje przekonanie, że „to nie działa” — choć nie zadziałał wybór, nie technologia.
Dlaczego demo wygląda lepiej niż twoje wdrożenie
Demo jest zaprojektowane tak, żeby wyglądać lepiej niż rzeczywistość, i nie jest to zarzut wobec dostawcy, tylko cecha demo. Działa na czystych danych, na jednym idealnym przypadku, bez twoich wyjątków, integracji i historii. Twoje wdrożenie dostaje dane niekompletne, proces z kilkoma wariantami i ludzi, którzy mają swój sposób pracy. Dlatego to, co na demie zajmuje jedno kliknięcie, u ciebie zajmuje tygodnie ustaleń. Jeśli decyzję podejmujesz na podstawie demo, kupujesz wersję świata, w której twoje wyjątki nie istnieją. Dlatego dobra rozmowa z dostawcą nie zaczyna się od „pokażcie, co potraficie”, tylko od „oto nasz proces i nasze dane — pokażcie, gdzie się to rozjedzie”.
Feature czy use case: jak je odróżnić
Ciekawy feature odpowiada na pytanie „co to potrafi”. Business use case odpowiada na pytanie „jaki nasz problem to rozwiązuje i skąd będziemy wiedzieć, że zadziałało”. Feature opisuje się możliwościami, use case opisuje się skutkiem. „Model umie streścić rozmowę” to feature. „Handlowiec traci codziennie mierzalny czas na notatki po spotkaniach, chcemy ten czas oddać na kontakt z klientem i sprawdzić to liczbą spotkań” to use case. Różnica nie jest kosmetyczna: z feature nie da się zaprojektować wdrożenia ani sprawdzić, czy się udało.
Use-case-first canvas: osiem pól przed wyborem technologii
Zanim porozmawiasz z jakimkolwiek dostawcą, wypełnij osiem pól. Problem: co konkretnie nie działa i dla kogo. Proces: jak ten fragment przebiega dziś, krok po kroku. Właściciel procesu: kto odpowiada za wynik po wdrożeniu, ponieważ narzędzie bez właściciela kończy jako półka. Dane wejściowe: co musi być dostępne i w jakiej jakości, żeby to w ogóle miało sens. Oczekiwany wynik: jak wygląda „lepiej” wyrażone skutkiem, nie funkcją. KPI: po jakiej mierze poznasz, że wynik nastąpił. Ograniczenia i uprawnienia: czego automatowi nie wolno i do czego nie ma dostępu. Weryfikacja: jak sprawdzisz efekt, zanim zainwestujesz w pełne wdrożenie. Jeśli któregokolwiek pola nie umiesz wypełnić, to jest twoje zadanie na teraz, a nie wybór narzędzia. Najczęściej puste zostają dwa pola: właściciel procesu i weryfikacja. Brak właściciela oznacza, że po wdrożeniu nikt nie odpowiada za wynik; brak weryfikacji oznacza, że nikt nie będzie umiał powiedzieć, czy było warto. Te dwa pola rozstrzygają o wdrożeniu więcej niż wybór dostawcy.
Kiedy AI, kiedy zwykła automatyzacja, a kiedy nic
Dopiero z wypełnionym canvasem wybór technologii staje się prosty. Jeśli proces jest powtarzalny i przewidywalny — te same kroki, jasne reguły — zwykła automatyzacja często bywa prostsza, bardziej przewidywalna i łatwiejsza w utrzymaniu niż AI. AI ma sens tam, gdzie wejście jest zmienne i wymaga interpretacji: streszczenie, klasyfikacja, wersja robocza tekstu do zatwierdzenia przez człowieka. Są też sytuacje, w których najlepszą decyzją jest nie automatyzować: proces jest niestabilny, więc automat utrwali bałagan, albo zdarza się na tyle rzadko, że koszt utrzymania automatu przewyższy oszczędność. To, czy potrzebujesz AI, czy wystarczy automatyzacja, rozstrzyga się właśnie tutaj, i warto zrobić to świadomie. Reguła jest prosta: im bardziej powtarzalny i jednoznaczny proces, tym mniej potrzebujesz AI; im więcej interpretacji i wyjątków, tym bardziej. Wybór technologii jest wtedy konsekwencją opisu, a nie punktem wyjścia.
Oczekiwany wynik i KPI: definiuj tak, by dało się sprawdzić
Najczęstszy błąd w polu „oczekiwany wynik” to cel, którego nie da się zweryfikować, na przykład „większa efektywność zespołu”. Zweryfikować da się skutek przypięty do miary: czas od zgłoszenia do pierwszego kontaktu spada z obecnego poziomu do ustalonego, liczba spotkań na handlowca rośnie. KPI nie jest po to, żeby dobrze wyglądać w prezentacji — jest po to, żeby po kwartale dało się powiedzieć „zadziałało” albo „nie” bez sporu o interpretację. Jeśli nie umiesz zapisać wyniku jako mierzalnego skutku, wdrożenie nie ma jak się rozliczyć. Dobry KPI ma jeszcze jedną cechę: da się go odczytać zanim minie rok. Jeśli efekt zobaczysz dopiero po długim czasie, nie odróżnisz wpływu narzędzia od zmian, które i tak zaszły w firmie.
Human-in-the-loop: gdzie zostaje człowiek
Osobne pole zasługuje na uwagę, bo najczęściej się o nim zapomina: gdzie w procesie zatrzymuje się automat i pyta człowieka. Nie każdą decyzję wolno oddać maszynie, szczególnie tam, gdzie skutek jest widoczny na zewnątrz albo nieodwracalny. W systemach z AI, które budujemy, automat wykonuje pracę powtarzalną, ale przy decyzjach ryzykownych zatrzymuje się i czeka na akceptację człowieka. To nie jest brak automatyzacji, to jej projekt. Use case, który tego nie określa, zostawia lukę, którą wdrożenie wypełni przypadkiem. A luka wypełniona przypadkiem to zwykle albo automat, który robi za dużo i trzeba go potem hamować, albo człowiek, który dubluje pracę maszyny, bo nikt nie ustalił granicy.
Mały pilot, zanim wdrożysz całość
Ostatnie pole, weryfikacja, ma jedną praktyczną formę: mały pilot z góry ustalonym kryterium sukcesu. Pilot nie służy temu, żeby zobaczyć, czy coś jest ciekawe. Służy temu, żeby na wąskim wycinku, na twoich danych, rozstrzygnąć, czy oczekiwany wynik faktycznie występuje, zanim zapłacisz za pełne wdrożenie i przezbroisz cały zespół. Jeśli pilot nie daje sygnału, że zakładany wynik występuje, pełne wdrożenie zwiększa ryzyko skalowania kosztu bez potwierdzonego efektu. Dobrze zdefiniowane kryterium pilotu jest tańszą wersją tej samej decyzji, którą i tak podejmiesz, tylko podjętą, zanim jest droga.
Zacznij więc od pytania, nie od odpowiedzi. Najpierw zdefiniuj use case — te osiem pól — a dopiero potem wybieraj technologię. Jeśli chcesz zrobić to z kimś, kto policzy z tobą, gdzie AI ma sens, gdzie wystarczy automatyzacja, a gdzie lepiej nie ruszać, od tego zaczynamy wdrożenie systemu sprzedaży z AI.