Najczęstszy błąd przy planowaniu projektów AI nie dotyczy technologii. Dotyczy kolejności pytań.
Wiele organizacji zaczyna od pytania: jakie narzędzie AI wdrożymy? Czy będzie to Copilot, model językowy, rozwiązanie lokalne, platforma dostawcy, aplikacja no-code albo integracja z obecnym systemem? To są ważne pytania, ale nie powinny paść jako pierwsze.
Pierwsze pytanie powinno brzmieć inaczej: który proces chcemy przetestować i po czym poznamy, że AI faktycznie go poprawiło?
Wybór procesu determinuje prawie wszystko. Od niego zależy, czy wynik testu będzie mierzalny, czy AI będzie miało na czym pracować, czy dane będą możliwe do przygotowania, czy po kilku tygodniach pojawi się podstawa do decyzji GO/NO-GO, czy tylko kolejna prezentacja z „obiecującymi wynikami”.
Dobry model użyty w źle wybranym procesie nie daje wartości biznesowej. Może wygenerować ciekawe przykłady, usprawnić fragment pracy albo dobrze wyglądać na warsztacie, ale nie pozwoli organizacji odpowiedzieć na najważniejsze pytanie: czy warto wdrażać to rozwiązanie szerzej?
Dlatego wybór procesu nie jest formalnością przed projektem AI. Jest jedną z najważniejszych decyzji operacyjnych w całym podejściu Proof of Value.
Dlaczego wybór procesu jest ważniejszy niż wybór narzędzia
W projektach AI bardzo łatwo dać się wciągnąć w rozmowę o technologii. Modele, dostawcy, integracje, architektura, bezpieczeństwo, automatyzacje, interfejsy użytkownika - to wszystko jest potrzebne, ale dopiero na właściwym etapie.
Jeśli organizacja nie wie, który proces testuje, rozmowa o technologii szybko staje się abstrakcyjna. Zespół zaczyna porównywać funkcje narzędzi, ale nie potrafi powiedzieć, jak zmierzy efekt. Dostawca pokazuje możliwości modelu, ale nie wiadomo, czy odpowiadają one realnemu problemowi operacyjnemu. Zarząd pyta o zwrot z inwestycji, a projekt nie ma punktu odniesienia.
To właśnie dlatego wiele inicjatyw AI nie wychodzi poza fazę pilotażu. Nie dlatego, że technologia jest zbyt słaba. Częściej dlatego, że proces został źle wybrany albo w ogóle nie został precyzyjnie nazwany.
„Obsługa klienta”, „back-office”, „dział reklamacji”, „analiza dokumentów” czy „wsparcie sprzedaży” to jeszcze nie są procesy do testu AI. To obszary albo aktywności. Proces do testu powinien mieć wejście, wyjście, powtarzalny przebieg, właściciela, dane historyczne i mierzalny wynik.
Dopiero wtedy można sprawdzić, czy AI poprawia czas, jakość, koszt, kompletność, trafność klasyfikacji albo udział spraw obsługiwanych bez ręcznej interwencji.
W praktyce dobrze wybrany proces ma trzy cechy: sprawa ma tożsamość i da się ją śledzić, proces ma wystarczający wolumen, istnieje punkt decyzyjny oparty na treści.
Każde z tych kryteriów można sprawdzić w kilka dni. Bez budowania modelu, bez integracji i bez uruchamiania pełnego projektu.
Kryterium 1. Sprawa ma tożsamość
Pierwsze pytanie brzmi: czy każdy przypadek w procesie da się prześledzić od wejścia do zamknięcia?
Nie chodzi o ogólne przekonanie, że „mamy to gdzieś w systemie”. Chodzi o konkret: unikalny identyfikator sprawy, znacznik czasu wejścia, znacznik czasu zamknięcia, statusy po drodze i zapisany wynik decyzji.
Bez tego nie da się rzetelnie zmierzyć procesu.
Jeżeli nie wiemy, kiedy sprawa wpłynęła i kiedy została zamknięta, nie policzymy czasu cyklu. Jeżeli nie wiemy, jaki był wynik decyzji, nie ocenimy jakości klasyfikacji. Jeżeli nie wiemy, które sprawy wymagały eskalacji, nie sprawdzimy, czy AI ograniczyło pracę ręczną.
Tożsamość sprawy jest fundamentem pomiaru. Bez niej Proof of Value zmienia się w demonstrację możliwości narzędzia, a nie w test biznesowy.
Dobrym kandydatem jest proces, w którym sprawy mają numer, historię i status. Może to być system ticketowy, CRM, system reklamacyjny, workflow dokumentowy, system obsługi korespondencji, repozytorium wniosków albo narzędzie do zarządzania zgłoszeniami. Ważne, żeby dało się wyeksportować historię pojedynczych przypadków.
Złym kandydatem jest proces, który żyje głównie w mailach, nieformalnych ustaleniach i arkuszach tworzonych ad hoc. AI może tam potencjalnie pomóc, ale wynik testu będzie trudny do interpretacji. Jeśli nie wiemy, jaki był punkt wyjścia, nie wiemy też, czy po zastosowaniu AI jest lepiej.
To nie oznacza, że taki proces należy na zawsze wykluczyć. Oznacza tylko, że najpierw trzeba uporządkować rejestrację spraw. Dopiero potem ma sens testować AI.
W praktyce pierwszy test kwalifikacyjny jest prosty: czy jesteśmy w stanie wyeksportować listę spraw z ostatnich 3-6 miesięcy, zawierającą co najmniej numer sprawy, datę otwarcia, datę zamknięcia, status i wynik decyzji?
Jeśli tak, proces przeszedł pierwszy warunek. Jeśli nie, ryzyko niejednoznacznego wyniku jest bardzo wysokie.
Kryterium 2. Proces ma wystarczający wolumen
Drugi warunek to wolumen.
Test AI przeprowadzony na trzydziestu przypadkach nie jest testem biznesowym. Jest anegdotą. Może pokazać potencjał, ale nie da stabilnej podstawy do decyzji inwestycyjnej.
W wielu procesach operacyjnych sensowny punkt startowy to minimum 200-300 zamkniętych spraw miesięcznie oraz dane historyczne z ostatnich 3-6 miesięcy. Nie jest to sztywna reguła dla każdego przypadku, ale dobry praktyczny próg przy ocenie procesów dokumentowych, reklamacyjnych, obsługowych i back-office.
Wolumen jest ważny z dwóch powodów.
Po pierwsze, pozwala sprawdzić skuteczność AI na wystarczająco zróżnicowanych przypadkach. W procesach operacyjnych rzadko problemem są tylko przypadki standardowe. Prawdziwy test zaczyna się przy wyjątkach, niepełnych danych, nietypowych opisach, błędnych dokumentach, duplikatach i sprawach, które wymagają interpretacji.
Przy małej próbie trudno ocenić, czy model radzi sobie stabilnie, czy tylko trafił na łatwe przypadki.
Po drugie, wolumen decyduje o opłacalności wdrożenia. AI może zadziałać poprawnie w procesie, który występuje kilka razy w miesiącu, ale efekt ekonomiczny będzie ograniczony. Przy niskim wolumenie koszt wdrożenia, integracji, utrzymania, nadzoru i szkoleń może przewyższyć korzyści.
Wartość AI rośnie wraz z powtarzalnością i skalą. Przy stu sprawach miesięcznie temat może być interesujący. Przy tysiącu spraw miesięcznie zaczyna być poważnym kandydatem do wdrożenia. Przy kilkunastu tysiącach rocznie zwykle warto bardzo dokładnie sprawdzić potencjał.
Wolumen powinien być też stabilny. Jednorazowy wzrost liczby spraw, sezonowy pik albo projekt specjalny mogą zniekształcić wynik. Jeśli proces był przez trzy miesiące przeciążony z powodu zmiany regulacyjnej, a potem wróci do normalnego poziomu, test AI przeprowadzony w takim okresie może dać fałszywy obraz potencjału.
Dlatego przy kwalifikacji trzeba zapytać nie tylko „ile spraw mamy?”, ale też „czy ten wolumen jest powtarzalny?”.
Warto dodatkowo uważać na szacunki operacyjne. W wielu organizacjach liczba spraw jest zawyżana, bo ktoś liczy wszystko, co wpływa do skrzynki, a nie zamknięte sprawy z kompletną historią. Po eksporcie z systemu często okazuje się, że zamiast tysiąca spraw miesięcznie mamy trzysta, które rzeczywiście nadają się do analizy.
To nadal może być wystarczające. Ale decyzja powinna opierać się na danych, nie na intuicji.
Kryterium 3. Istnieje punkt decyzyjny oparty na treści
Trzecie kryterium dotyczy natury pracy wykonywanej w procesie.
AI, zwłaszcza duże modele językowe, najlepiej sprawdza się tam, gdzie człowiek czyta, interpretuje i podejmuje decyzję na podstawie treści. Może to być opis sprawy, dokument, mail, zgłoszenie, reklamacja, uzasadnienie, notatka, umowa, załącznik albo historia kontaktu z klientem.
Typowe punkty decyzyjne, które dobrze nadają się do testu AI, to klasyfikacja sprawy, routing do właściwego zespołu, triage i priorytetyzacja, ekstrakcja danych z dokumentu, ocena kompletności dokumentacji, porównanie dokumentu z zamówieniem lub wymaganiem, wskazanie braków, ryzyk albo niespójności, przygotowanie rekomendacji dla operatora.
To są sytuacje, w których AI może skrócić czas analizy, uporządkować informacje, ograniczyć ręczną klasyfikację i odciążyć pracowników od powtarzalnej pracy poznawczej.
Nie każdy proces jest jednak dobrym kandydatem dla LLM.
Pierwsza grupa słabszych kandydatów to zadania czysto obliczeniowe. Jeśli wynik wynika z prostego algorytmu, tabeli, formuły albo jednoznacznej kalkulacji, model językowy nie jest właściwym narzędziem. Tam potrzebna jest automatyzacja regułowa, klasyczny algorytm, model statystyczny albo integracja systemowa.
Druga grupa to decyzje, które ze względów regulacyjnych lub biznesowych muszą pozostać decyzjami człowieka. Scoring kredytowy, ocena zdolności kredytowej, wypowiedzenie umowy, istotne decyzje windykacyjne, rozstrzygnięcia reklamacyjne czy decyzje wpływające bezpośrednio na sytuację klienta nie powinny być oddane modelowi jako finalna decyzja.
To nie znaczy, że AI nie ma tam zastosowania. Ma, ale w innym modelu. Może przygotować podsumowanie, wskazać braki, sklasyfikować typ sprawy, wyłapać ryzyko, zarekomendować ścieżkę albo pomóc pracownikowi szybciej przeanalizować materiał. Finalna decyzja zostaje jednak po stronie człowieka.
To model human-in-the-loop. W sektorze finansowym i innych branżach regulowanych powinien być traktowany jako standard przy przypadkach wysokiego ryzyka.
Dobry proces do Proof of Value nie musi oddawać decyzji AI. Wystarczy, że ma punkt, w którym AI może realnie wesprzeć człowieka i da się zmierzyć efekt tego wsparcia.
Jakich procesów nie wybierać do pierwszego testu AI
Poza pozytywnymi kryteriami są też kategorie procesów, które wyglądają atrakcyjnie, ale zwykle są złymi kandydatami do pierwszego Proof of Value.
Pierwsza kategoria to procesy bez mierzalnego przepływu. Wszystko dzieje się w mailach, głowach pracowników, na spotkaniach i w nieformalnych ustaleniach. Brakuje rejestru spraw, statusów, decyzji i historii. W takim procesie AI może nawet usprawnić fragment pracy, ale trudno będzie udowodnić efekt.
Najpierw trzeba ustrukturyzować proces. Dopiero potem testować AI.
Druga kategoria to procesy właśnie przebudowywane. Jeśli równolegle trwa wdrożenie nowego CRM, reorganizacja zespołu, migracja danych, zmiana outsourcingu albo aktualizacja procedur, wynik testu AI będzie trudny do interpretacji. Nie będzie wiadomo, czy poprawa wynika z modelu, czy z innych zmian.
To ryzyko dotyczy również wyników pozytywnych. Jeśli test pokaże poprawę, zarząd może zapytać: skąd wiemy, że to efekt AI? Bez stabilnego kontekstu odpowiedź będzie słaba.
Trzecia kategoria to procesy, które wymagają pełnej integracji z systemami legacy już na etapie testu. Proof of Value powinien możliwie często pracować na eksportach danych, a nie na dużej integracji produkcyjnej. Jeśli sam test wymaga wielotygodniowego projektu IT, koszt i czas mogą przekroczyć wartość informacji, którą chcemy uzyskać.
Czwarta kategoria to procesy o zbyt małym wolumenie. Kilka spraw tygodniowo to zwykle za mało. Nawet jeśli model zadziała, skala nie uzasadni inwestycji. Taki proces może być interesujący strategicznie, ale rzadko powinien być pierwszym kandydatem do testu AI.
Piąta kategoria to procesy wybrane ze względów politycznych. W praktyce zdarza się, że proces trafia do testu nie dlatego, że spełnia kryteria, ale dlatego, że dany departament najbardziej naciska albo konkretny dyrektor jest najbardziej entuzjastyczny. To zrozumiałe organizacyjnie, ale ryzykowne biznesowo.
Lista kandydatów powinna powstać na podstawie kryteriów, a nie siły wewnętrznego lobbingu.
Jakie procesy najczęściej są dobrymi kandydatami
W sektorze finansowym, ubezpieczeniowym, technologicznym i operacyjnym powtarza się kilka typów procesów, które często spełniają trzy warunki dobrego kandydata: mają tożsamość sprawy, odpowiedni wolumen i punkt decyzyjny oparty na treści.
Pierwszym przykładem jest obsługa reklamacji. Zwykle ma jasny początek, statusy, historię korespondencji i wynik. AI może pomóc w klasyfikacji reklamacji, routingu, wykrywaniu braków w dokumentacji, przygotowaniu streszczenia sprawy albo wskazaniu podobnych przypadków.
Drugim przykładem jest triage wniosków. Może dotyczyć wniosków kredytowych, leasingowych, ubezpieczeniowych, serwisowych, IT albo operacyjnych. AI nie musi podejmować decyzji. Może wstępnie kwalifikować sprawy, flagować braki, grupować przypadki i kierować uwagę człowieka tam, gdzie ryzyko albo złożoność są największe.
Trzecim przykładem jest weryfikacja dokumentów. W wielu organizacjach zespoły sprawdzają kompletność, spójność i zgodność dokumentów z wymaganiami. To praca powtarzalna, oparta na treści, często obciążająca operacyjnie. AI może przyspieszyć odczyt, ekstrakcję danych, wskazywanie braków i porównanie dokumentów z kryteriami.
Czwartym przykładem jest klasyfikacja korespondencji przychodzącej. To obszar, w którym duży wolumen i ograniczona skalowalność pracy ręcznej szybko tworzą wąskie gardło. AI może przypisywać wiadomości do kategorii, zespołów, priorytetów i ścieżek obsługi.
Piątym przykładem są procesy wsparcia IT i software delivery. Jeśli organizacja ma dane z systemu ticketowego, repozytoriów kodu i narzędzi pracy zespołów, można testować AI w triage ticketów, analizie zgłoszeń, przygotowaniu odpowiedzi, wsparciu dokumentacji albo ocenie jakości wymagań.
W każdym z tych przykładów szczegóły będą inne. Kryteria kwalifikacji pozostają jednak takie same: identyfikowalność sprawy, wolumen i treściowy punkt decyzyjny.
Obserwacja z projektu: technologia nie była problemem
W jednej z dużych organizacji zarządzającej dokumentami finansowymi przez długi czas trwała dyskusja o tym, który proces wybrać do testu AI. Na stole było kilka kandydatur. Wszystkie wydawały się sensowne na poziomie ogólnej rozmowy.
Dopiero zastosowanie kryteriów kwalifikacyjnych uporządkowało decyzję.
Jeden proces odpadł, bo miał za mały wolumen. Drugi żył głównie w mailach i nie miał spójnej rejestracji spraw. Trzeci przechodził właśnie reorganizację, więc wynik testu byłby trudny do obrony. Czwarty był ciekawy technologicznie, ale wymagał pełnej integracji już na etapie testu.
Wybór padł na matchowanie dokumentów z zamówieniami.
Nie dlatego, że był to najbardziej efektowny przypadek użycia. Wręcz przeciwnie - był dość operacyjny i konkretny. Ale spełniał wszystkie warunki: każdy dokument miał identyfikator, wolumen był wystarczający, dane historyczne były dostępne, a punkt decyzyjny był czytelny. Pracownik czytał dokument i oceniał, czy pasuje do zamówienia.
Dzięki temu wynik testu był interpretowalny. Organizacja mogła porównać pracę z AI do punktu odniesienia, ocenić efekt i podjąć decyzję GO/NO-GO w krótkim czasie.
Najważniejszy wniosek z tego przypadku nie brzmi: „AI dobrze zadziałała”. Brzmi raczej: właściwy wybór procesu umożliwił rzetelną ocenę AI.
To jest często kluczowa różnica między pilotażem bez końca a Proof of Value zakończonym decyzją.
Jak przeprowadzić wstępną kwalifikację procesu
Wstępna kwalifikacja procesu nie musi być dużym projektem. W wielu przypadkach można ją przeprowadzić w kilka godzin z osobą, która naprawdę zna proces od środka, oraz z kimś, kto potrafi sprawdzić dostępność danych.
Warto przejść przez pięć pytań.
Pierwsze: czy sprawa ma unikalny identyfikator i historię? Jeśli tak, można ją śledzić. Jeśli nie, wynik testu będzie trudny do zmierzenia.
Drugie: ile zamkniętych spraw mamy miesięcznie? Nie chodzi o szacunek, ale o liczbę potwierdzoną danymi. Najlepiej liczyć sprawy zamknięte, z kompletną historią, a nie wszystko, co wpłynęło do organizacji.
Trzecie: co dokładnie robi człowiek w tym procesie? Jeśli odpowiedź brzmi: „czyta opis i klasyfikuje”, „porównuje dokumenty”, „sprawdza kompletność”, „kieruje sprawę do zespołu”, to proces może być dobrym kandydatem. Jeśli odpowiedź brzmi: „różnie, zależy od sytuacji”, trzeba doprecyzować zakres.
Czwarte: czy proces będzie stabilny przez najbliższe dwa miesiące? Jeśli w tym czasie nie ma dużych zmian systemowych, organizacyjnych ani regulacyjnych, wynik testu będzie łatwiejszy do interpretacji.
Piąte: czy możemy przygotować dane bez pełnej integracji? Proof of Value powinien być możliwy do wykonania na eksportach danych. Jeśli nawet test wymaga dużego projektu integracyjnego, warto zastanowić się, czy nie wybrać prostszego procesu na start.
Jeśli odpowiedzi są pozytywne, proces jest dobrym kandydatem do kolejnego kroku: pomiaru baseline’u.
Bez baseline’u nadal nie ma testu biznesowego. Jest tylko przygotowanie danych i hipoteza. Dopiero punkt odniesienia pozwala po zakończeniu Proof of Value powiedzieć, czy AI realnie poprawiło proces.
Najczęstsze błędy przy wyborze procesu
Pierwszy błąd to mylenie aktywności z procesem. „AI pomoże w obsłudze klienta” albo „AI wesprze dział operacji” to nie są wystarczająco precyzyjne definicje. Proces ma wejście, wyjście, wynik i przepływ. Jeśli nie da się powiedzieć, co jest początkiem sprawy, co jest decyzją i kiedy sprawa jest zamknięta, to proces nie jest jeszcze gotowy do testu.
Drugi błąd to przecenianie wolumenu. W wielu organizacjach na starcie pojawiają się duże liczby, ale po sprawdzeniu okazuje się, że realna liczba przypadków z kompletną historią jest dużo mniejsza. Dlatego wolumen trzeba weryfikować na eksporcie, nie na deklaracji.
Trzeci błąd to wybór procesu najciekawszego technologicznie. Organizacje często chcą testować AI tam, gdzie przypadek brzmi nowocześnie albo dobrze wygląda w prezentacji. To zrozumiałe, ale ryzykowne. Pierwszy Proof of Value powinien być przede wszystkim mierzalny, nie efektowny.
Czwarty błąd to wybór procesu bez właściciela. Nawet dobrze wybrany proces nie zadziała, jeśli nikt po stronie biznesu nie odpowiada za wynik i nie może podjąć decyzji po teście. Właściciel procesu jest potrzebny od początku, nie dopiero przy wdrożeniu.
Piąty błąd to próba testowania AI w zbyt szerokim zakresie. Zamiast jednego procesu organizacja chce objąć cały obszar, kilka zespołów i kilka typów spraw. To zwiększa złożoność i utrudnia ocenę. Lepiej zacząć wężej, ale z pełną mierzalnością.
Szósty błąd to ignorowanie stabilności procesu. Jeśli równolegle trwa reorganizacja albo wdrożenie nowego systemu, test AI może dostarczyć danych, których nie da się obronić przed zarządem. W takich sytuacjach warto albo poczekać, albo zawęzić zakres do fragmentu, który pozostaje stabilny.
Dobra kwalifikacja skraca cały projekt
Kwalifikacja procesu może wyglądać jak dodatkowy krok. W praktyce zwykle skraca cały projekt.
Jeśli proces jest dobrze wybrany, dane do baseline’u są dostępne szybciej. Model ma na czym pracować od pierwszego dnia testu. Właściciel procesu rozumie, jaki wynik jest oczekiwany. Zespół wie, które przypadki analizować. Decyzja GO/NO-GO opiera się na liczbach, a nie na intuicji.
Zły wybór procesu działa odwrotnie. Projekt zaczyna się sprawnie, ale po kilku tygodniach pojawiają się problemy: dane są niepełne, wolumen jest mniejszy niż zakładano, nie wiadomo, jak mierzyć wynik, proces równolegle się zmienia, a użytkownicy inaczej rozumieją decyzję, którą AI miała wspierać.
Wtedy projekt zaczyna dryfować. Zamiast testować AI, zespół wyjaśnia dane, porządkuje definicje, doprecyzowuje proces i zmienia zakres. To wszystko są potrzebne działania, ale powinny wydarzyć się przed startem testu.
Widziałem projekty, w których kilka dni dobrze przeprowadzonej kwalifikacji eliminowało miesiące niejasności. Widziałem też projekty, które bez kwalifikacji przez trzy miesiące szukały odpowiedzi na pytanie, dlaczego wyniki są niejednoznaczne.
Różnica zwykle nie polegała na technologii. Polegała na jakości przygotowania.
Wybór procesu to decyzja operacyjna, nie technologiczna
Większość organizacji ma procesy, w których AI mogłaby realnie pomóc. Problem polega na tym, że często zaczynają od złego pytania.
Pytają: jakie narzędzie wdrożyć?
Lepsze pytanie brzmi: który konkretny proces ma problem, jak dziś mierzymy ten problem i czy AI może poprawić wynik w sposób możliwy do udowodnienia?
To przesuwa rozmowę z poziomu technologii na poziom zarządzania operacyjnego. I właśnie tam projekty AI powinny być osadzone, jeśli mają przynieść wartość.
Dobry kandydat do testu AI nie musi być najbardziej spektakularny. Powinien być mierzalny, powtarzalny i oparty na pracy z treścią. Powinien mieć właściciela, dane historyczne i punkt decyzyjny, w którym AI może wesprzeć człowieka.
Jeżeli proces spełnia te warunki, Proof of Value ma sens. Jeśli ich nie spełnia, lepiej to wiedzieć przed startem niż po kilku miesiącach pilotażu.
Wybór procesu to pierwszy krok metody Proof of Value. Od niego zależy, czy organizacja uzyska decyzję, czy tylko kolejne obserwacje.
