Jak wybrać pierwszy proces do wdrożenia AI i uniknąć 'pilot purgatory'

Zacznij od procesu o wysokim wolumenie i niskim ryzyku błędu, gdzie człowiek może łatwo zweryfikować wynik. Wybór procesu, który wymaga 100% precyzji w pierwszym dniu (np. automatyczna wysyłka pism prawnych), to najkrótsza droga do utraty budżetu. Celuj w zadania typu „drafting” lub „triage”, gdzie AI przygotowuje wsad dla pracownika, skracając czas realizacji tego zadania nawet o 60-80%, a nie zastępuje go całkowicie.

Pułapka „prestiżowego” pilota: dlaczego pierwszy proces AI nie może być najtrudniejszy

Pokusa wyboru najbardziej skomplikowanego problemu w firmie jako pierwszego projektu AI jest ogromna. Zarządy często wychodzą z założenia, że skoro technologia radzi sobie z prostymi zadaniami, należy rzucić jej wyzwanie w obszarze, który od lat stanowi wąskie gardło operacyjne. To błąd logiczny. Pierwsze wdrożenie AI w organizacji wykracza poza samo rozwiązanie problemu biznesowego. Jego nadrzędnym celem jest przetestowanie infrastruktury, jakości danych i - co najważniejsze - zbudowanie zaufania do nowych narzędzi wśród pracowników.

Problem „pilot purgatory” w polskich organizacjach

Zjawisko „czyśćca pilotów” (pilot purgatory) obserwujemy regularnie w firmach z sektora Enterprise i B2B w regionie CEE. Organizacja uruchamia kilka inicjatyw AI jednocześnie, celując w złożone procesy, takie jak kompleksowa automatyzacja obsługi klienta czy prognozowanie łańcucha dostaw. Projekty te miesiącami tkwią w fazie testów laboratoryjnych. Dlaczego? Ponieważ poprzeczka akceptacji postawiona jest zbyt wysoko dla niedojrzałej jeszcze infrastruktury danych w firmie.

Wybierając na start proces o wysokiej złożoności, zmuszasz zespół do walki z wyjątkami (edge cases), zamiast dostarczać wartość. Jeśli proces ma setki odnóg i wymaga integracji z pięcioma systemami legacy, czas potrzebny na „czyszczenie danych” zje cały budżet, zanim model wygeneruje pierwszy poprawny wynik. W efekcie po sześciu miesiącach zarząd widzi faktury za chmurę i godziny developerskie, ale nie widzi zwrotu z inwestycji. Projekt trafia do szuflady, a organizacja nabiera sceptycyzmu do automatyzacji procesów na kolejne dwa lata.

Proof of Concept vs. Proof of Value: co naprawdę buduje budżet na AI?

Rozróżnienie tych dwóch pojęć jest fundamentalne dla utrzymania finansowania projektu. Proof of Concept (PoC) odpowiada na pytanie techniczne: „Czy to w ogóle da się zrobić?”. Przy obecnej dostępności gotowych modeli LLM odpowiedź na tak postawione pytanie niemal zawsze brzmi „tak”. Dlatego PoC straciło na znaczeniu jako kamień milowy. Sukces techniczny nie oznacza sukcesu biznesowego.

Skupiamy się na Proof of Value (PoV). Tutaj pytanie brzmi: „Czy wdrożenie tego rozwiązania przyniesie mierzalny zwrot w akceptowalnym czasie?”. PoV wymaga zdefiniowania konkretnych KPI przed napisaniem pierwszej linii kodu. Mniej istotne jest to, czy model potrafi strescić dokument; kluczowe jest to, czy dzięki temu streszczeniu analityk jest w stanie przetworzyć 20 dokumentów dziennie zamiast 10. Tylko twarde dane o oszczędności czasu (FTE savings) lub wzroście konwersji są argumentem dla dyrektora finansowego (CFO). Budżet na dalszy rozwój otrzymują projekty, które w fazie pilotażowej wykazały realny wpływ na P&L (rachunek zysków i strat), a nie te, które są technologicznie imponujące.

Ryzyko porzucenia projektu: dane Gartnera i McKinsey o konwersji eksperymentów

Statystyki wdrożeniowe są nieubłagane dla firm, które ignorują etap selekcji use-case’ów. Raporty wskazują, że projekty generatywnej AI będą porzucane w 30% przypadków do końca 2025 roku, zaraz po fazie testowej. Główne przyczyny to niska jakość danych, nieadekwatne szacowanie ryzyk oraz niejasna wartość biznesowa. Organizacje często nie doceniają kosztów „ostatniej mili” - doprowadzenia modelu z 90% skuteczności do 99%, co jest niezbędne w procesach krytycznych. Z kolei analizy McKinsey potwierdzają, że wdrożenie rozwiązań poza fazę pilotażu pozostaje głównym wyzwaniem, a wiele firm ma trudności z przejściem od eksperymentów do wdrożeń generujących stałą wartość.

Z perspektywy wdrożeniowca widzimy, że ryzyko porzucenia rośnie wykładniczo wraz ze stopniem skomplikowania pierwszego procesu. Projekt, który nie dowozi wartości w 8-12 tygodni, traci impet polityczny wewnątrz firmy. Decydenci, nie widząc szybkich efektów, przesuwają zasoby do bardziej przewidywalnych zadań IT. Dlatego pierwszy proces musi być „nudny”, powtarzalny i bazujący na dostępnych danych.

Wybierając pierwszy cel, szukaj procesów, które:

• Posiadają ustrukturyzowane dane wejściowe (tekst, JSON, ustandaryzowane pliki).
• Mają jasnego właściciela biznesowego (business owner), któremu zależy na wyniku.
• Generują duży wolumen prostych zadań, które obecnie zatykają zespoły (np. kwalifikacja leadów, routing zgłoszeń).
• Pozwalają na łatwe wdrożenie weryfikacji ludzkiej bez zatrzymywania procesu.
• Nie wymagają przebudowy całej architektury IT w firmie.

Odpowiednia selekcja to gra o prawdopodobieństwo. Im mniej zmiennych na starcie, tym szybszy Time-to-Value (TTV).

Scoring use-case’ów w praktyce: 7 kryteriów selekcji podpartych twardymi liczbami

Matematyka wdrożeniowa jest bezwzględna: pierwszy projekt AI w organizacji ma za zadanie walidację modelu biznesowego, a nie tylko testowanie technologii. Decyzja o wyborze procesu nie może opierać się na przeczuciu dyrektora operacyjnego ani na tym, który dział najgłośniej zgłasza zapotrzebowanie. Niezbędna jest chłodna kalkulacja oparta na macierzy decyzyjnej. W iMakeable stosujemy system scoringowy oceniający procesy w skali 1-5 (lub 1-10) w siedmiu wymiarach. Tylko procesy, które uzyskują wysoki wynik łączny, kwalifikują się do fazy pilotażowej. Poniżej rozbijamy te kryteria na czynniki pierwsze, pokazując, dlaczego technologia to często najmniejszy problem w całym równaniu.

Wolumen i powtarzalność: silnik statystyczny modeli AI

Podstawowym błędem firm jest próba automatyzacji procesów rzadkich, ale trudnych merytorycznie. Modele językowe (LLM) oraz algorytmy uczenia maszynowego (ML) zyskują przewagę ekonomiczną tam, gdzie występuje efekt skali. Jeśli zespół obsługuje 50 zapytań miesięcznie, koszt wdrożenia AI, utrzymania infrastruktury i tokenów przewyższy koszt pracy człowieka. Szukamy procesów o wysokim wolumenie (np. tysiące faktur, ticketów, maili), gdzie nawet niewielkie przyspieszenie jednostkowe (np. o 30 sekund na sprawie) generuje wyraźny zysk w skali roku.

Liczba wyjątków i edge cases jako zabójca marży projektu

Wolumen to nie wszystko - liczy się jednorodność procesu. Idealny kandydat na start posiada tzw. happy path obejmującą minimum 70-80% przypadków. Jeśli proces wymaga interwencji człowieka w co drugim zgłoszeniu ze względu na niestandardowe warunki umowy czy specyficzną relację z klientem, automatyzacja stanie się nieopłacalna. Algorytmy świetnie radzą sobie z powtarzalnymi wzorcami, ale „rozbijają się” o nieustrukturyzowane wyjątki, generując halucynacje lub błędy logiczne. Im więcej reguł warunkowych („jeśli klient jest z grupy X, ale napisał w piątek, to…”), tym wyższe ryzyko niepowodzenia.

Dostępność danych i dług technologiczny integracji

Drugim filtrem jest jakość i dostępność danych historycznych. AI nie zadziała w próżni. Wymaga dostępu do ustrukturyzowanych (bazy SQL, CRM) lub nieustrukturyzowanych (treść maili, pliki PDF) zbiorów danych, które posłużą jako kontekst (RAG) lub materiał treningowy (fine-tuning). Częstym problemem jest rozproszenie wiedzy - jeśli proces opiera się na informacjach przekazywanych ustnie między pracownikami lub zapisywanych w prywatnych notatkach, wdrożenie jest niemożliwe bez wcześniejszej cyfryzacji.

Kryteria techniczne i biznesowe

Analizując otoczenie techniczne, weryfikujemy czy systemy źródłowe posiadają otwarte API, czy też wymagają budowy niestabilnych konektorów typu RPA (screen scraping). Dług technologiczny w postaci przestarzałych systemów ERP bez dokumentacji API potrafi wydłużyć wdrożenie trzykrotnie. Płynna wymiana danych jest krytyczna, co potwierdza analiza wdrożeń w contact center i operacjach back-office, gdzie szybkość dostępu do informacji warunkuje możliwość obsługi złożonych zapytań przez agentów AI.

Ocenie podlegają również twarde bariery techniczne:

• Dostępność środowisk testowych - brak stagingu oznacza ryzykowne testy na produkcji.
• Format danych - konieczność OCR dla skanów niskiej jakości drastycznie obniża skuteczność.
• Stabilność procesu - jeśli procedura zmienia się co kwartał, algorytm będzie wymagał ciągłej rekonfiguracji.
• Bezpieczeństwo - czy dane mogą opuścić infrastrukturę firmy (wymogi RODO/compliance).

Koszt błędu a mechanizmy Human-in-the-loop (HITL)

Wybierając pierwszy use-case, musimy zdefiniować tolerancję na błędy. W procesach krytycznych (np. diagnostyka medyczna, autoryzacja dużych przelewów, obsługa prawna) margines błędu jest zerowy, co czyni je złym wyborem na start. Zdecydowanie lepiej sprawdzają się obszary o umiarkowanym ryzyku, takie jak wstępna kategoryzacja maili, draftowanie odpowiedzi czy ekstrakcja danych z faktur, gdzie ostateczna decyzja i tak jest weryfikowana przez człowieka.

Podejście Human-in-the-loop (HITL) jest obligatoryjne w fazie pilotażowej. System AI zamiast działać autonomicznie, przygotowuje „wsad” dla pracownika, który zatwierdza lub koryguje wynik. Taka architektura pozwala zbierać feedback, douczać model i stopniowo zwiększać poziom automatyzacji, minimalizując ryzyko operacyjne.

Przekładalność na P&L: oszczędności FTE vs. przyspieszenie cash-flow

Ostatnie kryterium to mierzalny wpływ na wynik finansowy. Wiele firm skupia się wyłącznie na redukcji etatów (FTE), co jest podejściem krótkowzrocznym i często budzi opór zespołu. Bardziej wartościowym wskaźnikiem jest wpływ na przychody lub cash-flow. Przykładowo: automatyzacja windykacji miękkiej może przyspieszyć spływ należności o 5 dni, co dla firmy o dużych obrotach oznacza realny zysk odsetkowy i płynnościowy. Z kolei skrócenie czasu ofertowania z 2 dni do 2 godzin bezpośrednio zwiększa konwersję sprzedaży. Dlatego w scoringu wyżej punktujemy procesy, które oprócz oszczędzania czasu, realnie generują pieniądze.

Architektura wag: jak matematycznie wyłonić najlepszy use case AI na start

Subiektywne odczucia managerów to najczęstsza przyczyna porażek wczesnych inicjatyw AI. Przekonanie, że dany proces jest „uciążliwy” lub „trudny”, rzadko koreluje z techniczną wykonalnością i biznesową opłacalnością jego automatyzacji. Aby uniknąć przepalania budżetu na projekty, które nigdy nie wyjdą poza fazę laboratoryjną, należy zastosować rygorystyczny model scoringowy. Sprowadza on dyskusję o wdrożeniu AI do mianownika matematycznego, usuwając z równania politykę wewnątrzfirmową i fascynację technologicznymi nowinkami.

Formuła Weighted Score: od subiektywnej opinii do twardej punktacji

Skuteczna ocena szans powodzenia opiera się na systemie ważonym, który odzwierciedla realne ryzyka projektowe, a nie tylko hipotetyczne korzyści. W naszym modelu każdemu z sześciu krytycznych wymiarów przypisujemy wagę procentową, sumującą się do 100%. Te wartości nie są przypadkowe - wynikają z analizy setek wdrożeń i najczęstszych przyczyn ich niepowodzenia (brak danych, zbyt niska marżowość, złożoność integracji).

Model przyjmuje następującą strukturę wag dla poszczególnych kryteriów:

• Wpływ na zysk/koszt (30%): Parametr dominujący. Projekt musi generować twardy zwrot z inwestycji (ROI). Oceniamy tu bezpośredni wpływ na EBITDA lub Cash Flow. Rozwiązania „nice-to-have”, które jedynie poprawiają komfort pracy, ale nie przekładają się na wynik finansowy, otrzymują tutaj niską punktację.
• Dostępność i jakość danych (20%): Paliwo dla modelu. Jeśli dane są rozproszone, nieustrukturyzowane (skany, ręczne notatki) lub wymagają wielotygodniowego czyszczenia, projekt traci punkty. Wysoka ocena w tej kategorii oznacza dostęp do czystych datasetów lub ustrukturyzowanych logów.
• Koszt błędu (15%): Ryzyko operacyjne. Czy pomyłka modelu zatrzyma linię produkcyjną lub spowoduje pozew sądowy? Im pomyłka łatwa do wyłapania i tania do naprawienia, tym wyższa punktacja. Szukamy procesów, gdzie błąd AI jest łatwy do wyłapania i tani do naprawienia (np. weryfikacja przez człowieka w pętli HITL).
• Złożoność integracji (15%): Aspekt techniczny. Premiujemy procesy obsługiwane przez systemy z otwartym API. Konieczność budowy niestabilnych rozwiązań typu RPA lub skomplikowanych konektorów do systemów legacy drastycznie obniża atrakcyjność wdrożenia na start.
• Wolumen operacji (10%): Częstotliwość występowania. Choć wydaje się istotny, ma niższą wagę niż wpływ finansowy. Milion operacji o wartości 1 grosza jest mniej warty niż tysiąc operacji o wartości 1000 złotych. Wolumen jest mnożnikiem, a nie celem samym w sobie.
• Liczba wyjątków (10%): Stopień standaryzacji. Im mniej ścieżek alternatywnych w procesie (tzw. edge cases), tym lepiej. AI najszybciej zwraca się w procesach liniowych i powtarzalnych.

Każdy z tych wymiarów oceniany jest w skali 0-10, a następnie mnożony przez przypisaną wagę. Przykładowo, jeśli „Dostępność danych” ocenimy na 8/10, do wyniku końcowego (Weighted Score) wliczamy 1.6 punktu (8 * 0.20 * 10). Maksymalny możliwy wynik to 100 punktów. Taka struktura wymusza na zespole wdrożeniowym analizę faktów. Odpowiednie sekwencjonowanie wdrożeń pozwala uniknąć sytuacji, w której firma utyka na ambitnym, ale technicznie niemożliwym do realizacji projekcie, zamiast zbierać niskowiszące owoce.

Progi decyzyjne i kategoryzacja portfela projektów AI

Sam wynik liczbowy wymaga osadzenia w kontekście decyzyjnym. Bez jasnych progów odcięcia (cut-off points), zarząd nadal może forsować projekty o niskich rokowaniach, ignorując wyniki scoringu. Przyjmujemy rygorystyczną kategoryzację, która dzieli backlog pomysłów na trzy grupy: kandydatów do wdrożenia, projekty do inkubacji oraz inicjatywy do odrzucenia.

Strong Candidate (Wynik > 70 pkt)
To projekty, które powinny trafić na ścieżkę wdrożeniową w pierwszej kolejności. Charakteryzują się wysokim wpływem na biznes, relatywnie łatwą integracją i dostępnymi danymi. Ryzyko techniczne jest tu niskie, a przewidywany czas do uzyskania wartości (Time-to-Value) krótki. W tej grupie zazwyczaj znajdują się procesy takie jak automatyczny routing zgłoszeń supportowych czy ekstrakcja danych z ustrukturyzowanych faktur, gdzie mamy jasny kosztorys i przewidywalne API. Wybór projektu z tej puli gwarantuje szybkie „zwycięstwo” i buduje zaufanie organizacji do technologii AI.

Incubation / Re-evaluation (Wynik 50-70 pkt)
Strefa szara. Projekty te są obiecujące, ale jeden z głównych parametrów zaniża ich ocenę - najczęściej jest to jakość danych lub złożoność integracji. Nie odrzucamy ich, ale nie kierujemy do natychmiastowego wdrożenia. Wymagają one fazy przygotowawczej: wdrożenia procedur Data Governance, zmiany w architekturze IT lub uproszczenia procesu biznesowego. Uruchamianie ich jako pierwszego projektu to proszenie się o kłopoty: harmonogramy ulegną wydłużeniu, a budżet zostanie przekroczony przez nieprzewidziane prace inżynieryjne.

Reject (Wynik < 50 pkt)
Projekty do natychmiastowego odrzucenia. Zazwyczaj są to procesy o zbyt wysokim koszcie błędu (np. automatyczna diagnoza medyczna bez nadzoru lekarza w fazie MVP), zbyt rzadkie, by uzasadnić koszt trenowania modelu, lub oparte na wiedzy plemiennej, której nie da się zapisać w danych. Inwestowanie czasu w analizę tych przypadków to strata zasobów. Brutalna eliminacja tych pomysłów na wczesnym etapie uwalnia moce przerobowe zespołu dla inicjatyw z grupy „Strong Candidate”.

Zastosowanie tej matrycy zmienia dynamikę spotkań zarządczych. Zamiast pytać „Czy możemy to zrobić?”, pytamy „Jaki jest Weighted Score?”. Jeśli wynik wynosi 45, dyskusja się kończy, niezależnie od tego, jak bardzo medialny jest dany temat. Taka inżynieryjna dyscyplina zabezpiecza budżet przed technologiami niegotowymi na szerokie wdrożenie w konkretnym środowisku operacyjnym.

Po przeprowadzeniu scoringu i odrzuceniu inicjatyw o niskiej wartości biznesowej (poniżej 50 punktów), pozostaje grupa projektów oznaczonych jako „Strong Candidates”. Nie wszystkie jednak nadają się na pierwsze wdrożenie. Macierz priorytetów wskazuje matematyczną zasadność, ale rzeczywistość operacyjna wymaga nałożenia filtra ryzyka wdrożeniowego. Pierwszy projekt ma za zadanie dowieźć Proof of Value (PoV) w czasie krótszym niż 90 dni, budując zaufanie wewnątrz organizacji do dalszych inwestycji w AI.

Klasyfikacja procesów: co wdrażać najpierw, a co zostawić na później

Najbezpieczniejszą strategią dla pierwszego wdrożenia jest wybór procesu o wysokim wolumenie, ale niskiej złożoności decyzyjnej. Szukamy obszarów, gdzie praca polega na kategoryzacji, ekstrahowaniu danych lub prostym wnioskowaniu na podstawie ustrukturyzowanych reguł. Unikamy procesów wymagających „ludzkiej intuicji”, negocjacji czy oceny estetycznej.

Quick Wins: Triage maili, routing ticketów i automatyzacja AP

Idealny kandydat na start to proces, który obecnie generuje wąskie gardło (bottleneck) nie z powodu trudności zadania, ale z powodu jego masowości. Wdrożenie w takim obszarze jest natychmiast odczuwalne przez zespół operacyjny - odzyskuje on godziny spędzane dotychczas na przeklejaniu danych.

Case studies operacyjne

Klasycznym przykładem „dobrego startu” jest inteligentny triage skrzynek mailowych (np. [email protected] lub [email protected]). W modelu manualnym pracownik otwiera wiadomość, czyta ją, pobiera załącznik i decyduje, do jakiego działu ją przekazać. W modelu AI, model NLP klasyfikuje intencję nadawcy (np. „reklamacja”, „faktura”, „zapytanie ofertowe”), ekstrahuje istotne metadane (NIP, numer zamówienia) i automatycznie tworzy ticket w systemie CRM lub ERP.

Kolejnym sprawdzonym wzorcem jest routing ticketów w IT Service Desk. Zamiast manualnego przypisywania zgłoszeń przez pierwszą linię wsparcia, model AI analizuje opis błędu i historyczne rozwiązania podobnych problemów, kierując zgłoszenie bezpośrednio do odpowiedniego zespołu inżynierskiego, często sugerując od razu bazę wiedzy (knowledge base articles) dla użytkownika końcowego. Redukuje to MTTR (Mean Time To Resolve) i odciąża najbardziej kosztowne zasoby techniczne od trywialnej pracy administracyjnej.

Automatyzacja faktur: dlaczego back-office to bezpieczny poligon doświadczalny

Procesy back-office, takie jak automatyzacja procesów w obszarze Accounts Payable (AP), stanowią bezpieczne środowisko testowe, ponieważ błędy modelu nie są widoczne bezpośrednio dla klienta końcowego. W przeciwieństwie do chatbotów obsługi klienta, gdzie „halucynacja” AI może spowodować kryzys wizerunkowy, błąd w odczycie faktury zostanie wychwycony przez pracownika księgowości na etapie weryfikacji.

Wykorzystanie modeli wizyjnych i LLM do procesowania faktur pozwala na osiągnięcie skuteczności rzędu 90-95% w ekstrahowaniu pozycji kosztowych, mapowaniu ich do odpowiednich kont księgowych i wykrywaniu duplikatów. Co więcej, automatyzacja faktur pozwala nie tylko na redukcję kosztów pracy manualnej, ale przede wszystkim na uszczelnienie procesu i szybsze zamykanie okresów rozliczeniowych. Jest to wdrożenie o wysokiej przewidywalności - struktura faktury jest relatywnie stała, a reguły księgowania jasne.

Czerwone flagi: procesy bez decyzji, bez danych i bez właściciela

Istnieje kategoria procesów, które na papierze wyglądają atrakcyjnie, ale w praktyce stają się grobem dla projektów AI. Technologia rzadziej przesądza o porażce niż brak osadzenia procesu w strukturze organizacyjnej.

Analiza błędów: procesy rzadkie i niestandardowe jako pułapka kosztowa

Pierwszą czerwoną flagą są procesy o niskim wolumenie i wysokiej zmienności („rzadkie wyjątki”). Jeśli dany proces występuje raz w tygodniu i za każdym razem wymaga indywidualnego podejścia (np. rozpatrywanie nietypowych reklamacji prawnych), koszt wytrenowania i utrzymania modelu przewyższy oszczędności wynikające z automatyzacji. AI potrzebuje powtarzalności. Procesy „ad hoc” są domeną ekspertów, nie algorytmów.

Drugim krytycznym błędem jest wybór procesu bez właściciela biznesowego (LOB Owner). Raporty McKinsey i Deloitte spójnie wskazują, że projekty inicjowane wyłącznie przez działy IT lub rozwoju, bez silnego sponsora po stronie biznesu (np. Dyrektora Sprzedaży czy Finansów), najczęściej utykają w fazie „wiecznego pilota”. Brak właściciela oznacza brak decyzyjności przy zmianie procesu - a wdrożenie AI zawsze wymusza zmianę sposobu pracy. Jeśli nikt nie jest odpowiedzialny za wynik biznesowy (np. skrócenie czasu obsługi), nikt nie będzie walczył o adopcję narzędzia przez pracowników.

Ostrzeżenie: Unikaj procesów, w których decyzje podejmowane są w oparciu o „niezapisane reguły plemienne”. Jeśli pracownik nie potrafi wytłumaczyć w procedurze step-by-step, dlaczego podjął daną decyzję („to zależy od przeczucia”), model AI nie będzie w stanie tego zreplikować z zadowalającą skutecznością.

Skuteczna selekcja procesu wymaga chłodnej kalkulacji i analizy faktów, a nie demokratycznego głosowania. Etap generowania pomysłów macie już za sobą, dlatego warsztat priorytetyzacyjny pełni funkcję stricte decyzyjną. Jego celem jest odrzucenie 80% propozycji i wyłonienie jednego kandydata z najwyższym prawdopodobieństwem zwrotu z inwestycji w ciągu kwartału. Aby zamknąć ten proces w 90 minut, musisz narzucić rygorystyczną strukturę dyskusji i wyeliminować opinie niepoparte liczbami.

Warsztat priorytetyzacji: jak w 90 minut przejść od pomysłu do wyboru procesu

Spotkanie bez twardych danych wejściowych zamieni się w licytację, kto głośniej krzyczy o swoich problemach operacyjnych. Aby tego uniknąć, warsztat musi być poprzedzony fazą pre-worku, a na sali muszą znaleźć się osoby decyzyjne, a nie tylko obserwatorzy. Wymagany skład to: COO lub Head of Operations (właściciel budżetu i wyniku biznesowego), Tech Lead lub Senior Developer (weryfikacja wykonalności) oraz Business Owner danego obszaru (osoba, która zna proces „od podszewki”). Nie zapraszaj szerokiego grona interesariuszy - tłum rozmywa odpowiedzialność.

Przygotowanie danych: co musisz wiedzieć przed spotkaniem?

Decyzja o wdrożeniu AI zapada w oparciu o arkusz kalkulacyjny, nie slajdy w PowerPoincie. Przed wejściem na salę, Business Owner każdego zgłoszonego use-case’u musi dostarczyć „metrykę procesu”. Jeśli nie potrafi jej uzupełnić, temat spada z agendy. Brak danych historycznych oznacza, że proces jest niezarządzany, a automatyzowanie chaosu to prosty sposób na przepalenie budżetu i utknięcie w tzw. „pilot purgatory”, przed czym ostrzega McKinsey. Wymagane minimum informacyjne obejmuje trzy obszary: wolumen, koszty i architekturę.

Wolumen określamy w skali miesięcznej i rocznej, uwzględniając sezonowość. Musisz wiedzieć, czy proces dotyczy 50 czy 5000 zgłoszeń miesięcznie. Koszt wyliczamy przez pryzmat roboczogodzin (FTE) - ile czasu zajmuje obsługa jednej instancji procesu człowiekowi, a ile całemu zespołowi w skali roku. Architektura to lista systemów, które biorą udział w procesie (CRM, ERP, skrzynka pocztowa) oraz status dostępu do nich (otwarte API, konieczność RPA, pliki płaskie). Najczęstszym błędem jest niedoszacowanie liczby wyjątków - jeśli „szczęśliwa ścieżka” to mniej niż 60% przypadków, proces nie nadaje się na pierwszy ogień.

• Wolumen: Średnia miesięczna liczba instancji procesu (np. faktur, ticketów) z ostatnich 6 miesięcy.
• Czas obsługi (AHT): Średni czas, jaki człowiek poświęca na jedną sprawę (bez czasu oczekiwania).
• Koszt błędu: Finansowa lub wizerunkowa konsekwencja pomyłki (np. wysłanie cennika VIP do klienta standard).
• Dokumentacja: Czy istnieje spisana procedura (SOP) lub diagram BPMN? (Brak dyskwalifikuje proces).
• Dane: Czy dane wejściowe są cyfrowe (tekst, JSON), czy analogowe (skan ręcznego pisma, rozmowa telefoniczna)?

Moderacja i konsensus: rola właściciela biznesowego i lidera IT

Dynamika spotkania opiera się na konfrontacji perspektywy „Impact” (Biznes) z perspektywą „Feasibility” (IT). Twoim zadaniem jako moderatora jest niedopuszczenie do dominacji jednej strony. Biznes ma tendencję do ignorowania długu technologicznego („przecież to prosta integracja”), a IT do szukania dziury w całym („nie mamy zasobów na wystawienie endpointu”). Warsztat dzielimy na trzy bloki: kalibracja kryteriów (15 min), scoring kandydatów (45 min) i wybór finalny (30 min).

W trakcie scoringu każdy proces oceniamy w macierzy Impact-Feasibility. Jeśli Tech Lead zgłasza weto techniczne (np. brak dostępu do danych, konieczność przebudowy core systemu), proces natychmiast trafia na listę „Long-term” lub „Do kosza”, niezależnie od tego, jak wysoki ROI obiecuje biznes. Z kolei jeśli proces jest technicznie trywialny, ale jego wpływ na wynik firmy jest marginalny (oszczędność 2 godzin w miesiącu), odrzucamy go jako nieopłacalny w kosztach utrzymania. Szukamy wyłącznie tych tematów, które znajdują się w prawej górnej ćwiartce macierzy: wysoki wpływ, wysoka wykonalność.

Dokumentacja decyzji jako fundament pod budżetowanie AI

Wynikiem warsztatu nie jest luźna notatka, ale dokument „Decision Log”, który stanowi podstawę do uruchomienia finansowania. Musi on zawierać jasne uzasadnienie wyboru: dlaczego proces X wygrał z procesem Y. Kluczowym elementem tej strategii jest wyłonienie nie jednego, a dwóch procesów: Głównego (Primary) i Zapasowego (Backup). Prognozy Gartnera wskazują na 30% ryzyko porzucenia projektu po PoC, a nasze doświadczenie wdrożeniowe potwierdza, że często już podczas głębokiej analizy technicznej (Discovery) pierwszego wyboru wychodzą na jaw krytyczne błędy w danych lub blokady bezpieczeństwa. Posiadanie zatwierdzonego procesu zapasowego pozwala zespołowi płynnie przekierować prace bez konieczności zwoływania kolejnego warsztatu i tracenia impetu.

Dokument końcowy definiuje również właściciela wdrożenia po stronie klienta. To osoba, która będzie akceptować efekty pracy agenta AI i odpowiadać za dostarczenie wiedzy dziedzinowej. Bez przypisanego nazwiska przy procesie („Accountable” w macierzy RACI), projekt nie rusza. Taki rygor na starcie buduje autorytet zespołu wdrażającego i wysyła jasny sygnał do organizacji: realizujemy projekt operacyjny z konkretnym celem biznesowym, zamiast kolejnego eksperymentu R&D.

Wybranie procesu głównego i zapasowego (zasada 1+1) to moment przejścia od strategii do inżynierii. Posiadanie alternatywy jest bezpiecznikiem operacyjnym - często dopiero przy próbie podłączenia się do API lub ekstrakcji danych historycznych okazuje się, że „czysty” proces w rzeczywistości jest technicznie niedostępny bez wielomiesięcznego czyszczenia legacy data. W takim scenariuszu natychmiast uruchamiamy proces zapasowy, nie tracąc impetu wdrożeniowego.

Uruchomienie pilota: od wyboru 1+1 do produkcyjnego wdrożenia AI

Skuteczne wdrożenie pilotażowe (Proof of Value) musi zamknąć się w oknie czasowym 6-12 tygodni. Projekty trwające dłużej wpadają w strefę „zmęczenia nowością” (lub tzw. pilot purgatory), gdzie początkowy entuzjazm biznesu wygasa, a budżet jest kwestionowany przy każdej rewizji kwartalnej. Celem pilota nie jest zbudowanie idealnego systemu, ale walidacja hipotezy: czy AI w tym konkretnym procesie dowozi zakładany zwrot z inwestycji (ROI)?

Checklista startowa: KPI, dane i właściciele procesu

Zanim napiszesz pierwszą linię kodu lub skonfigurujesz pierwszy prompt w modelu LLM, musisz zdefiniować sztywne ramy sukcesu. W iMakeable stosujemy zasadę, że brak mierzalnego KPI oznacza brak wdrożenia. Metryki muszą być biznesowe, a nie techniczne. Zamiast „poprawności modelu na poziomie 90%”, definiujemy „skrócenie czasu obsługi ticketu o 40%” lub „redukcję kosztu procesowania faktury do 2 PLN”.

Niezbędne elementy checklisty przed startem:

• Dostęp do danych (Data Access Plan): Czy mamy fizyczny dostęp do API, bazy SQL lub dokumentów? Deklaracje „mamy to w chmurze” często zderzają się z rzeczywistością VPN-ów, brakiem dokumentacji API czy bałaganem w uprawnieniach.
• Właściciel procesu (Business Owner): Kto podejmuje decyzję o akceptacji wyników? To nie może być Project Manager. Musi to być osoba odpowiedzialna za P&L (Profit and Loss) danego działu, która na koniec powie: „Tak, to rozwiązanie realnie pomaga mojemu zespołowi”.
• Kryteria sukcesu i porażki: Musimy ustalić próg, poniżej którego uznajemy pilota za nieudanego. Jeśli AI myli się w 20% przypadków przy procesowaniu płatności, ryzyko może przewyższać korzyści z wdrożenia.

Shadow mode i testy A/B: jak bezpiecznie weryfikować model AI?

Największym błędem przy wdrażaniu agentów AI jest zbyt szybkie „puszczenie ich na żywo” do klientów lub do systemów produkcyjnych. Profesjonalne wdrożenia zaczynają się od trybu cienia (Shadow Mode). W tej konfiguracji model AI otrzymuje te same dane wejściowe co pracownik (np. treść maila od klienta), generuje odpowiedź lub wykonuje zadanie, ale nie wysyła wyniku nigdzie poza bazę testową.

Pozwala to na bezpieczne porównanie: co zrobił człowiek, a co zaproponowało AI. Dopiero gdy zgodność (accuracy) w Shadow Mode stabilnie przekracza ustalony próg (np. 85%), przechodzimy do fazy Human-in-the-Loop. W tym etapie AI przygotowuje drafty (np. odpowiedzi, wpisy w CRM), które człowiek musi tylko zatwierdzić lub lekko skorygować. To drastycznie przyspiesza pracę, zachowując pełną kontrolę jakości.

Traktuj fazę Shadow Mode jako poligon doświadczalny - błędy tutaj są darmowe, błędy na produkcji kosztują utratę klienta.

Kryteria skali: kiedy nacisnąć przycisk „produkcja”?

Decyzja o zakończeniu pilota opiera się na modelu: Scale / Iterate / Kill. Jest to brutalna weryfikacja założeń. Jeśli po 8 tygodniach model nadal wymaga ręcznej poprawy w 50% przypadków, a koszt developmentu rośnie, należy mieć odwagę nacisnąć „Kill” i przejść do procesu zapasowego. Stanowi to oszczędność zasobów, a nie porażkę.

Opcja „Scale” jest dostępna tylko wtedy, gdy system jest stabilny, a koszt jego utrzymania (tokeny, infrastruktura) jest wielokrotnie niższy niż wartość pracy, którą wykonuje. Pamiętaj, że udane skalowanie pilota AI wymaga architektury przygotowanej na obciążenia produkcyjne od pierwszego dnia (podejście pilot with production in mind). Wdrożenie, które działa na 100 rekordach, może się załamać przy 10 000, jeśli nie zadbano o rate limits, kolejkowanie zapytań czy monitoring kosztów LLM.

Jeżeli wyniki są obiecujące, ale nie idealne, wybieramy „Iterate”. Wracamy do prompt engineeringu, doczyszczamy bazę wiedzy (RAG) lub doprecyzowujemy logikę biznesową. Ważne, by iteracja miała ściśle określony time-box (np. 2 sprinty). Jeśli po tym czasie nie ma poprawy - wracamy do opcji „Kill”.

Wybór pierwszego procesu i jego skuteczna egzekucja to fundament ewolucji firmy w organizację napędzaną przez AI. Nie ma tu miejsca na zgadywanie. Jeśli szukasz partnera, który przeprowadzi Twoją firmę przez proces selekcji use-case’ów, audyt danych i bezpieczne wdrożenie - skontaktuj się z zespołem iMakeable. Pomożemy Ci zidentyfikować procesy, które realnie wpłyną na Twój wynik finansowy, zamiast generować tylko medialny szum.