Każda większa firma, z którą rozmawiałem w ostatnich dwóch latach, ma za sobą przynajmniej jeden projekt AI, który utknął. Demo wyglądało dobrze. Zarząd powiedział: „sprawdźmy to”. Zespół uruchomił pilotaż. Po kilku miesiącach pojawiło się jednak pytanie, na które nikt nie potrafił odpowiedzieć: czy to rozwiązanie faktycznie działa w naszym procesie?
Problem zwykle nie leży w samej technologii. Leży w braku metody oceny. Firmy testują narzędzia AI, ale nie ustalają wcześniej, co dokładnie oznacza sukces, jaki proces podlega ocenie, z jakim punktem odniesienia porównają wynik i kto podejmie decyzję po zakończeniu testu.
Sektor finansowy ma tu szczególną sytuację. Regulacje, bezpieczeństwo danych, wymogi audytowe i wrażliwość procesów sprawiają, że organizacje muszą działać ostrożnie. To zrozumiałe. W praktyce ta ostrożność często zamienia się jednak w wielomiesięczny pilotaż AI, który nie daje ani większego bezpieczeństwa, ani decyzji biznesowej.
Można uniknąć obu skrajności: nieprzemyślanego pośpiechu i paraliżu decyzyjnego. Do tego służy Proof of Value AI.
To sposób pracy, którego używamy przy ocenie zastosowań AI w procesach operacyjnych, back-office i wytwarzaniu oprogramowania. Jego cel jest prosty: sprawdzić na realnych danych, w konkretnym procesie, czy AI poprawia ustalone wcześniej wskaźniki. Wynikiem ma być decyzja GO albo NO-GO w ciągu 2-4 tygodni.
Dlaczego pilotaże AI tak często nie kończą się decyzją
Projekty AI rzadko zatrzymują się od razu. Zwykle zaczynają się energicznie: jest prezentacja, zainteresowanie zarządu, szybka zgoda na test, czasem nawet wydzielony zespół. Problem pojawia się później, gdy trzeba przejść od zachwytu technologią do decyzji inwestycyjnej.
Pierwszy częsty scenariusz to demo, które działa tylko w warunkach pokazowych. Dostawca pokazuje rozwiązanie na przygotowanych danych. System klasyfikuje dokumenty, odpowiada na pytania, generuje podsumowania albo wspiera decyzje operacyjne. Prezentacja robi dobre wrażenie, ale nie odpowiada na najważniejsze pytanie: czy to samo rozwiązanie poradzi sobie z realnymi danymi firmy, z wyjątkami, brakami, historycznymi odstępstwami i niejednoznacznymi przypadkami?
Demo pokazuje potencjał technologii. Nie pokazuje jeszcze wartości biznesowej.
Drugi scenariusz to pilotaż, który trwa coraz dłużej. Mija miesiąc, potem kolejny. Każdy przegląd kończy się podobnym komunikatem: „wyniki są obiecujące, potrzebujemy jeszcze trochę czasu”. W praktyce często oznacza to, że przed startem nie ustalono kryterium sukcesu ani kryterium zatrzymania. Po sześciu miesiącach trudno już powiedzieć, co właściwie jest testowane: technologia, dostawca, jakość danych, proces, gotowość zespołu czy cierpliwość zarządu.
Trzeci scenariusz pojawia się wtedy, gdy temat trafia na poziom zarządu. Padają pytania o ROI, koszty, skalowalność i wpływ na proces. O ile skrócił się czas obsługi? Ile spraw przeszło bez ręcznej interwencji? Czy spadła liczba błędów? Czy można to przenieść na inne zespoły?
Zespół nie potrafi odpowiedzieć, bo nie zmierzył punktu wyjścia. Nie wiadomo, jak proces działał przed AI. Nie ma baseline’u, więc nie ma z czym porównać wyniku. Projekt traci finansowanie nie dlatego, że AI nie działa, ale dlatego, że nikt nie potrafi pokazać efektu.
Czym jest Proof of Value AI
Proof of Value to krótki, kontrolowany test biznesowy, którego celem jest ocena, czy AI daje mierzalny efekt w konkretnym procesie. To nie jest klasyczny pilotaż ani wersja demo. To także nie jest jeszcze wdrożenie produkcyjne.
Najprościej: Proof of Value odpowiada na pytanie, czy AI poprawia konkretny wskaźnik w naszym procesie, na naszych danych i w naszych warunkach.
Różnica wobec typowego pilotażu jest bardzo praktyczna. W klasycznym pilotażu czas trwania bywa nieokreślony, kryteria sukcesu zmieniają się w trakcie, dane są często dobrane tak, żeby rozwiązanie dobrze wyglądało, a końcowa decyzja jest odkładana na później. W Proof of Value czas, KPI, dane, właściciel biznesowy i kryterium decyzji są ustalone przed startem.
Najważniejsze jest to, że wynik negatywny nie jest porażką. NO-GO jest pełnoprawną informacją biznesową. Oznacza, że dany proces, dane albo warunki organizacyjne nie uzasadniają wdrożenia AI na tym etapie. Lepiej wiedzieć to po kilku tygodniach niż po sześciu miesiącach i po wydaniu znaczącego budżetu.
Proof of Value przesuwa rozmowę z poziomu „czy AI jest ciekawe?” na poziom „czy AI daje mierzalny efekt w tym procesie?”.
Jak działa Proof of Value AI w praktyce
Dobrze przeprowadzony Proof of Value ma prostą logikę. Zaczyna się od wyboru procesu i wskaźników, nie od wyboru modelu. Dopiero później pojawia się technologia.
Krok 1. Wybór procesu, nie technologii
Większość projektów AI zaczyna się od niewłaściwego pytania. Firmy pytają: jakiego modelu użyjemy, czy to będzie Copilot, OpenAI, rozwiązanie lokalne, platforma dostawcy, integracja z obecnym systemem. To są ważne pytania, ale nie powinny być pierwsze.
Pierwsze pytanie brzmi: który proces chcemy sprawdzić i jaki efekt biznesowy chcemy zmierzyć?
Dobry kandydat do Proof of Value ma czytelny przepływ. Sprawa, dokument, wniosek albo zgłoszenie powinny mieć identyfikator i znaczniki czasu. Trzeba móc prześledzić drogę od wejścia do zamknięcia. Procesy, które żyją wyłącznie w mailach i nieformalnych ustaleniach, są trudne do rzetelnej oceny.
Proces powinien mieć też odpowiedni wolumen. Przy kilku przypadkach miesięcznie trudno ocenić efekt. W praktyce sensowny test wymaga zwykle kilkuset przypadków historycznych albo powtarzalnego strumienia bieżących spraw.
Trzeci warunek to punkt decyzyjny lub klasyfikacyjny. Może to być decyzja, czy faktura pasuje do zamówienia, czy reklamacja wymaga eskalacji, czy dokument jest kompletny, czy korespondencja powinna trafić do konkretnego zespołu. To właśnie tam AI ma największy potencjał: w porządkowaniu informacji, klasyfikacji, wstępnej analizie i rekomendowaniu kolejnego kroku.
W sektorze finansowym dobrymi kandydatami są często obsługa reklamacji, triage wniosków kredytowych, weryfikacja dokumentów, klasyfikacja korespondencji przychodzącej, analiza kompletności spraw, wsparcie procesów windykacyjnych albo obsługa powtarzalnych zapytań klientów i partnerów.
Na tym etapie nie wybiera się jeszcze narzędzia. Wybiera się proces, w którym można rzetelnie zmierzyć wpływ AI.
Krok 2. Ustalenie baseline’u przed startem
Baseline to zmierzony stan procesu przed uruchomieniem AI. Nie chodzi o opinię zespołu, deklarację menedżera ani ogólne przekonanie, że „jest dużo ręcznej pracy”. Potrzebne są konkretne liczby.
Najczęściej mierzymy czas cyklu, czyli czas od wejścia sprawy do jej zamknięcia. Warto patrzeć na medianę, nie tylko średnią, bo pojedyncze anomalne sprawy mogą mocno zniekształcić obraz procesu.
Drugim ważnym wskaźnikiem jest odsetek eskalacji, czyli udział spraw wymagających ręcznej interwencji poza standardowym przepływem. Przydatny jest także wskaźnik First Time Right, pokazujący, ile spraw zostało zamkniętych poprawnie za pierwszym razem, bez powrotu, reworku albo przekierowania. Przy dużych wolumenach warto mierzyć również koszt jednostkowy oraz udział pracy ręcznej.
Bez baseline’u Proof of Value staje się demonstracją. Z baseline’em staje się testem biznesowym.
Jeżeli już na tym etapie okazuje się, że firma nie ma danych pozwalających zmierzyć proces, to też jest cenna informacja. Może oznaczać, że najpierw trzeba uporządkować sposób rejestracji spraw, definicje KPI albo jakość danych. Lepiej dowiedzieć się tego przed startem niż po kilku miesiącach pilotażu.
Krok 3. Minimalne rozwiązanie na realnych danych
Proof of Value powinien działać na realnych danych klienta. Inaczej nie jest dowodem.
Dane demo pokazują, co technologia potrafi w kontrolowanych warunkach. Realne dane pokazują, czy technologia poradzi sobie z procesem takim, jaki faktycznie istnieje w organizacji: z wyjątkami, brakami, duplikatami, niepełnymi opisami, starymi formatami dokumentów i niespójnościami w systemach.
Na potrzeby PoV zwykle nie jest potrzebna pełna integracja z systemami produkcyjnymi. Wystarczą eksporty danych z CRM, systemu workflow, repozytorium dokumentów, systemu ticketowego, platformy reklamacyjnej albo systemów finansowo-księgowych. Format może być prosty: CSV, Excel, JSON albo paczka dokumentów. W wielu przypadkach wystarcza 200-300 zamkniętych spraw z ostatnich kilku miesięcy, choć dokładny zakres zależy od procesu, celu testu i jakości danych.
Rozwiązanie budowane w PoV powinno być minimalne. Ma sprawdzić hipotezę biznesową, nie zastępować docelowego systemu. W praktyce może to być model klasyfikujący sprawy, mechanizm ekstrakcji danych z dokumentów, narzędzie wspierające decyzję operatora albo asystent pomagający zespołowi szybciej obsłużyć powtarzalne przypadki.
W procesach regulowanych decyzja końcowa powinna pozostać po stronie człowieka. AI może rekomendować, klasyfikować, wskazywać ryzyka, porządkować dane i skracać czas analizy. Przy decyzjach o wysokim ryzyku potrzebny jest model human-in-the-loop: AI wspiera, ale człowiek podejmuje decyzję.
Bezpieczeństwo danych musi być częścią metody
W sektorze finansowym bezpieczeństwo danych nie jest dodatkiem do projektu. Jest warunkiem wejścia. Dlatego model bezpieczeństwa trzeba ustalić przed pierwszym eksportem danych, a nie dopiero wtedy, gdy test zaczyna działać.
W praktyce oznacza to kilka zasad. Dane osobowe powinny zostać zanonimizowane albo pseudonimizowane, jeśli cel testu na to pozwala. Środowisko PoV powinno być odizolowane od produkcji. Dostęp do danych musi być ograniczony do osób zaangażowanych w test. Działania systemu powinny być logowane. Po zakończeniu projektu trzeba jasno określić, co dzieje się z danymi. NDA i DPA powinny być uzgodnione przed rozpoczęciem pracy na danych klienta.
W zależności od wymagań organizacji modele mogą działać w infrastrukturze klienta, w środowisku chmurowym klienta albo w innym uzgodnionym modelu technicznym. W firmach regulowanych trzeba dodatkowo uwzględnić wymogi RODO, oczekiwania nadzorcze, audytowalność oraz klasyfikację ryzyka związaną z AI Act.
Najgorszy scenariusz to szybki test na wrażliwych danych bez wcześniejszego ustalenia, gdzie dane trafiają, kto ma do nich dostęp i czy są wykorzystywane do trenowania modeli zewnętrznego dostawcy. Tego ryzyka można uniknąć, jeśli bezpieczeństwo jest elementem Proof of Value od pierwszego dnia.
Krok 4. Pomiar efektu względem baseline’u
Po zakończeniu testu mierzy się dokładnie te same wskaźniki, które zostały ustalone przed startem. Jeśli baseline obejmował czas cyklu, odsetek eskalacji i First Time Right, to te same parametry mierzymy po zastosowaniu AI.
Nie dodajemy nowych KPI tylko dlatego, że wypadły lepiej. Nie zmieniamy definicji sukcesu w trakcie testu. Nie uznajemy „obiecujących wyników” za decyzję.
Wynik powinien prowadzić do jednej z trzech decyzji: GO, NO-GO albo GO warunkowe. GO oznacza, że AI poprawia ustalone wskaźniki w sposób uzasadniający dalsze wdrożenie. NO-GO oznacza, że efekt jest za słaby, ryzyko przewyższa potencjalną korzyść albo proces nie jest dobrym kandydatem. GO warunkowe oznacza, że rozwiązanie działa w wybranym fragmencie procesu, ale przed skalowaniem trzeba spełnić konkretne warunki.
Takim warunkiem może być poprawa jakości danych, ograniczenie zakresu procesu, doprecyzowanie ról użytkowników, zmiana modelu bezpieczeństwa albo przygotowanie zespołu do pracy z AI.
Proof of Value powinien kończyć etap niepewności. Nawet jeśli wynik nie jest idealny, organizacja powinna wiedzieć, co dalej.
Krok 5. Decyzja i warunki skalowania
Jeśli wynik to GO, kolejnym krokiem jest projekt wdrożeniowy. Dopiero wtedy pojawia się pełna integracja z systemami, automatyzacja przepływu, standardy operacyjne, szkolenia użytkowników, monitoring KPI i governance.
Proof of Value nie jest produkcyjnym wdrożeniem. Jest dowodem, że wdrożenie ma sens.
Jeśli wynik to NO-GO, organizacja również zyskuje wartość. Wie, że dany proces nie uzasadnia wdrożenia AI w obecnych warunkach. Może też wskazać przyczynę: słabą jakość danych, niski wolumen, niestabilny przebieg procesu, zbyt niejednoznaczne decyzje, zbyt wysokie ryzyko regulacyjne albo brak gotowości użytkowników.
To nie jest strata. To ochrona przed kosztownym wdrożeniem bez uzasadnienia.
Błędy, które zatrzymują projekty AI
W większości organizacji projekty AI nie zatrzymują się z powodu samej technologii. Zatrzymują się przez błędy organizacyjne, decyzyjne i procesowe.
Pierwszy błąd to brak właściciela z mandatem. Projekt ma sponsora, kilku interesariuszy i zespół roboczy, ale nikt nie ma prawa powiedzieć „kontynuujemy” albo „zatrzymujemy”. W efekcie projekt trwa, bo formalne zamknięcie byłoby trudniejsze niż kolejne spotkanie statusowe. Proof of Value wymaga jednej osoby, która może podjąć decyzję po zakończeniu testu.
Drugi błąd to testowanie AI na danych demo. Dane demo są czyste, kompletne i przewidywalne. Dane produkcyjne zwykle takie nie są. Zawierają wyjątki, duplikaty, stare formaty, niepełne pola i błędy użytkowników. Jeśli AI ma działać w realnym procesie, musi zostać sprawdzone właśnie na takich danych.
Trzeci błąd to brak baseline’u. Bez punktu odniesienia każdy wynik można zinterpretować dowolnie. Model obsłużył 70% spraw? To dużo czy mało? Skrócił czas analizy o 15%? Czy to wystarczy, żeby uzasadnić wdrożenie? Baseline porządkuje rozmowę. Zamiast opinii pojawia się porównanie.
Czwarty błąd to mylenie Proof of Value z wdrożeniem. PoV ma odpowiedzieć, czy AI działa w danym procesie. Nie ma zbudować gotowego systemu produkcyjnego. Między PoV a wdrożeniem są jeszcze integracje, bezpieczeństwo, role, procedury, szkolenia, utrzymanie i monitoring.
Piąty błąd to pominięcie adopcji użytkowników. Technicznie dobry model, którego nikt nie używa, nie ma wartości biznesowej. Dlatego już w Proof of Value trzeba sprawdzić, jak użytkownicy pracują z rekomendacjami AI. Czy im ufają? Czy rozumieją ograniczenia? Czy wiedzą, kiedy zaakceptować rekomendację, a kiedy ją zakwestionować?
Szósty błąd to praca na danych wrażliwych bez modelu bezpieczeństwa. W finansach, ubezpieczeniach, windykacji, pożyczkach i procesach dokumentowych nie można zaczynać od podejścia „wrzućmy dane i zobaczmy, co się stanie”. Najpierw trzeba ustalić architekturę, dostęp, anonimizację, logowanie, retencję danych i odpowiedzialność stron.
Jak Proof of Value wygląda w praktyce
Dwa poniższe przykłady pokazują logikę PoV bez ujawniania nazw organizacji. W obu przypadkach problemem nie była sama technologia, ale brak decyzji opartej na danych.
Organizacja z dużym wolumenem dokumentów finansowych
Jedna z organizacji zarządzała dziesiątkami tysięcy dokumentów rocznie: fakturami, protokołami, deklaracjami cyklicznymi i korespondencją przychodzącą. Wcześniejszy pilotaż AI trwał ponad rok. Każde spotkanie kończyło się podobnym komunikatem: „wyniki są obiecujące”. Problem polegał na tym, że nikt nie zmierzył punktu wyjścia.
Po uporządkowaniu podejścia projekt został sprowadzony do Proof of Value. Najpierw zdefiniowano procesy i KPI. Następnie pobrano dane historyczne, przygotowano minimalne rozwiązanie i porównano wynik z baseline’em.
Efekt był jednoznaczny. W obszarze faktur udział dokumentów przetwarzanych bez ręcznej interwencji wzrósł do około 80%. W przypadku deklaracji cyklicznych skrócenie czasu obsługi przełożyło się na odzyskanie kilkudziesięciu dni roboczych rocznie w jednym obszarze.
Decyzja GO zapadła na podstawie liczb, nie ogólnego wrażenia.
Organizacja technologiczna i wykorzystanie AI przez deweloperów
W dużej organizacji technologicznej narzędzia AI były dostępne od kilku miesięcy. Część deweloperów korzystała z nich regularnie, część sporadycznie, część wcale. Zarząd pytał o ROI, ale nie było danych pozwalających odpowiedzieć.
Proof of Value został ustawiony wokół cyklu wytwarzania oprogramowania. Baseline zbudowano na podstawie danych z systemu ticketowego, historii commitów i informacji o wykorzystaniu narzędzi AI.
Po trzech tygodniach organizacja wiedziała, gdzie adopcja jest realna, a gdzie tylko deklaratywna. W zespołach, które faktycznie pracowały z AI według ustalonych zasad, lead time skrócił się o 18%. Około 75% licencji było aktywnie używanych tygodniowo.
Decyzja o rozszerzeniu platformy została oparta na danych z procesu, nie na ankietach ani deklaracjach.
Kiedy warto zastosować Proof of Value AI
Proof of Value ma największy sens wtedy, gdy organizacja planuje wdrożenie AI, ale nie wie jeszcze, czy konkretny proces jest dobrym kandydatem. To dobra metoda dla firm, które chcą uniknąć długiego pilotażu bez jasnej decyzji, a jednocześnie nie chcą podejmować decyzji inwestycyjnej wyłącznie na podstawie prezentacji dostawcy.
PoV sprawdza się szczególnie dobrze w procesach z regularnym przepływem spraw, dokumentów albo zgłoszeń. Potrzebne są dane historyczne z kilku ostatnich miesięcy, możliwość zdefiniowania mierzalnego KPI oraz powtarzalny punkt decyzyjny, klasyfikacyjny albo analityczny.
W sektorze finansowym takie podejście jest szczególnie użyteczne, bo pozwala pogodzić ostrożność regulacyjną z potrzebą szybkiej decyzji. Test jest krótki, kontrolowany, oparty na realnych danych i możliwy do udokumentowania.
To dobra forma pracy dla firm pożyczkowych, leasingowych, faktoringowych, windykacyjnych, ubezpieczeniowych, banków, fintechów oraz organizacji z dużym wolumenem procesów back-office.
Proof of Value a AI w procesach biznesowych
AI w firmie nie powinna być traktowana jako osobny projekt technologiczny oderwany od operacji. Jeśli ma przynieść efekt, musi zostać podłączona do konkretnego procesu, konkretnego KPI i konkretnej decyzji zarządczej.
Inaczej szybko stanie się kolejnym narzędziem, które „wszyscy testują”, ale nikt nie potrafi ocenić jego wpływu na wynik.
Proof of Value porządkuje tę rozmowę. Zamiast pytać ogólnie, czy warto wdrożyć AI, organizacja pyta: w którym procesie AI może dać efekt, jaki wskaźnik chcemy poprawić, jakie dane są potrzebne do testu, jaki wynik uzasadnia wdrożenie, jakie ryzyka musimy kontrolować i kto podejmie decyzję po zakończeniu testu.
To przesuwa rozmowę z poziomu trendu technologicznego na poziom zarządzania operacyjnego.
Co powinno być gotowe przed startem PoV
Przed rozpoczęciem Proof of Value nie trzeba mieć pełnej strategii AI. Trzeba jednak mieć uporządkowanych kilka spraw.
Potrzebny jest kandydat procesowy. Nie musi być idealny, ale powinien mieć powtarzalny przebieg i mierzalny wolumen. Potrzebny jest też właściciel biznesowy z mandatem, bo bez niego PoV stanie się kolejnym projektem analitycznym bez decyzji.
Organizacja powinna mieć dostęp do danych historycznych. Nie muszą być perfekcyjne, ale muszą pozwalać na ocenę procesu. Trzeba też ustalić zasady bezpieczeństwa danych. W firmach regulowanych to warunek rozpoczęcia pracy, nie formalność do załatwienia później.
Najważniejsze są jednak kryteria GO/NO-GO. Powinny być zdefiniowane przed startem, nie po pierwszych wynikach i nie w trakcie testu. Dopiero wtedy Proof of Value daje wiarygodną odpowiedź.
Co dalej po decyzji GO albo NO-GO
Decyzja GO oznacza, że AI ma uzasadnienie biznesowe w danym procesie. Kolejny etap powinien obejmować projekt wdrożeniowy: integracje, role, procedury, szkolenia, monitoring, utrzymanie i kontrolę ryzyka.
Decyzja NO-GO oznacza, że organizacja uniknęła nietrafionej inwestycji. To także wynik biznesowy. Wskazuje, gdzie trzeba poprawić dane, proces albo założenia, zanim AI będzie miała sens.
Najgorszy wynik to brak decyzji. To on generuje największy koszt: czas zespołów, rozproszenie uwagi, kolejne spotkania, utratę zaufania zarządu i rosnący sceptycyzm wobec AI.
Proof of Value ma temu zapobiec. AI nie potrzebuje kolejnego pilotażu bez końca. Potrzebuje procesu, baseline’u, KPI, bezpiecznego środowiska i osoby, która na końcu podejmie decyzję.
