Masz presję, żeby „wdrożyć AI”. Masz kilka pomysłów, kilka zgłoszeń od managerów i raport od doradcy z listą dziesięciu obszarów do automatyzacji. I masz problem: nie wiesz, od czego naprawdę zacząć.
To jest moment, w którym większość organizacji popełnia błąd. Wybierają albo największy problem (bo „będzie efekt”), albo najłatwiejszy (bo „szybko pójdzie”), albo ten, przy którym najgłośniej krzyczy manager. Żadne z tych kryteriów nie wystarczy.
Poniżej pięć pytań, które zadajemy na każdej kwalifikacji - zanim uruchomimy cokolwiek.
Kryterium 1: Czy masz baseline, który możesz zmierzyć przed i po?
AI w procesach operacyjnych nie ma sensu bez mierzalnego punktu wyjścia. Nie chodzi o raporty z systemu - chodzi o konkretną liczbę, którą dzisiaj znasz i którą za trzy miesiące możesz porównać z nową.
Przykłady baselines, które działają:
- Czas obsługi jednej sprawy: 18 minut (mierzony stoperem na próbce 50 spraw)
- Odsetek spraw z błędem przy pierwszym wprowadzeniu: 12%
- Liczba eskalacji do managera dziennie: 23
- SLA dotrzymane: 71%
Jeśli nie masz takiej liczby - nie znaczy to, że nie można zacząć. Znaczy to, że pierwszym krokiem jest pomiar, a nie wdrożenie AI.
Często widzimy organizacje, które zaczynają PoV bez baseline’u i po trzech miesiącach nie mogą powiedzieć, czy zadziałało. To strata budżetu i czasu.
Kryterium 2: Czy proces jest powtarzalny i wolumenowy?
AI w procesach sprawdza się najlepiej tam, gdzie wolumen jest wysoki, a logika przebiegu - przewidywalna. Setki spraw dziennie o podobnej strukturze: faktury, wnioski, zgłoszenia reklamacyjne, dokumenty do klasyfikacji.
Procesy jednorazowe, kreatywne lub silnie zależne od kontekstu relacyjnego (np. negocjacje, eskalacje VIP) to nie jest dobry start. Można do nich dojść - ale po tym, jak AI sprawdzi się w warunkach powtarzalnych.
Sprawdzające pytanie: „Czy typowy pracownik, który obsługuje ten proces, może opisać go w dziesięciu krokach - i czy każdy kolejny pracownik zrobiłby to samo?”
Jeśli odpowiedź brzmi „tak, mniej więcej” - jesteś we właściwym miejscu.
Kryterium 3: Gdzie są wyjątki i kto je obsługuje?
To jest pytanie, które oddziela projekty udane od projektów utknąłych w połowie.
Każdy proces ma wyjątki. Faktury bez numeru zamówienia. Wnioski z brakującą dokumentacją. Zgłoszenia, które nie pasują do żadnej kategorii. W większości automatyzacji to właśnie wyjątki zjadają cały czas zaoszczędzony na przypadkach standardowych - i to dlatego ROI z RPA często nie dowozi oczekiwań.
Dobry use case AI to taki, gdzie:
- wyjątki są przewidywalne (można je skatalogować),
- AI może obsłużyć część z nich autonomicznie,
- dla reszty istnieje jasna ścieżka eskalacji do człowieka z pełnym kontekstem.
Jeśli nikt w organizacji nie umie powiedzieć, ile jest wyjątków i co się z nimi dzieje - zanim zaplanujesz wdrożenie AI, musisz ten obraz zbudować.
Kryterium 4: Kto jest właścicielem procesu i czy ma mandat do zmiany?
To kryterium nie jest techniczne. Jest organizacyjne - i dyskwalifikuje więcej projektów niż problemy z danymi.
Najlepsze narzędzie AI nie zadziała, jeśli manager procesu nie ma pełnomocnictwa do zmiany sposobu pracy zespołu. Jeśli decyzje o tym, jak wygląda workflow, wymagają zatwierdzenia przez trzy szczeble - każda iteracja PoV będzie ciągnąć się miesiącami.
Właściciel procesu, który jest gotowy do PoV, to osoba, która:
- może zaangażować dwóch pracowników do współpracy przy PoV,
- może zmienić sposób pracy (choćby pilotażowo) bez pytania o zgodę w każdym kroku,
- jest gotowa powiedzieć „nie działa” i wyciągnąć wnioski, nie tylko „działa” i świętować.
Brak takiego właściciela to twarda dyskwalifikacja - nie dlatego, że organizacja jest „zła”, ale dlatego, że bez niego nie ma jak dostarczyć efektu.
Kryterium 5: Czy dane są dostępne, a ograniczenia bezpieczeństwa - znane i możliwe do zarządzenia?
AI potrzebuje danych. To oczywiste. Mniej oczywiste jest to, że dane muszą być:
- dostępne w formacie, który da się przetworzyć (nie tylko „są w systemie”),
- opisane pod kątem ograniczeń: co może trafić do zewnętrznego modelu, co nie, co wymaga anonimizacji,
- wystarczająco reprezentatywne - próbka, na której będzie uczył się lub operował model, musi pokrywać typowe przypadki i kluczowe wyjątki.
Brak danych lub trwały blocker bezpieczeństwa bez planu to dyskwalifikacja. Ale „dane są wrażliwe, więc nie można nic zrobić” - to często fałszywy impas. W wielu projektach anonimizacja lub praca na wyizolowanym środowisku rozwiązuje problem compliance, zanim PoV się zaczął.
Podsumowanie: pięć pytań kwalifikacyjnych
Przed wyborem use case’u zadaj sobie i swojemu zespołowi te pięć pytań:
- Jaki jest baseline KPI, który możemy zmierzyć przed i po?
- Czy proces jest powtarzalny i wolumenowy?
- Ile jest wyjątków, kto je obsługuje i czy AI może przejąć część z nich?
- Kto jest właścicielem i czy ma mandat do zmiany sposobu pracy?
- Czy dane są dostępne i czy ograniczenia compliance są możliwe do zarządzenia w ramach PoV?
Jeśli na cztery z pięciu możesz odpowiedzieć konkretnie - masz dobry punkt startowy do rozmowy o PoV. Jeśli na trzy lub mniej - zacznij od warsztatu, który te luki wypełni.
