W poprzednim tekście pisałem, że AI nie naprawi chaosu w procesie. Najpierw trzeba sprawdzić, czy firma rzeczywiście ma proces, który da się opisać, powtórzyć i usprawnić.

Załóżmy, że ten etap jest już za nami.

Masz kilka procesów, które wyglądają na dobrych kandydatów do automatyzacji. Każdy ma jasny początek, wynik końcowy i da się wskazać fragmenty, które dziś zabierają ludziom czas.

Pojawia się więc kolejne pytanie:

Od którego procesu zacząć?

W wielu firmach odpowiedź przychodzi szybko: od najważniejszego. Od procesu, który najbardziej boli. Od takiego, który po udanym wdrożeniu zrobiłby największe wrażenie na zarządzie, właścicielu albo inwestorach.

To brzmi rozsądnie.

I właśnie dlatego jest niebezpieczne.

Najważniejszy proces w firmie nie zawsze jest najlepszym pierwszym procesem do automatyzacji. Często jest zbyt złożony, zbyt widoczny i zbyt kosztowny, żeby organizacja uczyła się automatyzacji właśnie na nim.

Dobrze dobrany pierwszy proces nie musi być tym największym. Powinien mieć jednak dobry stosunek wpływu do kosztu i ryzyka. Ma dać firmie zauważalny efekt, ale jednocześnie pozwolić jej nauczyć się nowego sposobu pracy bez niepotrzebnego ryzyka.

Ten tekst jest dla CEO, właścicieli i zarządów, którzy mają już kilka pomysłów na automatyzację, ale nie chcą przepalić budżetu na źle wybrany pierwszy projekt.

Pierwszy projekt ma nauczyć firmę automatyzować

Często słyszymy podobny argument:

Zacznijmy od kluczowego procesu. Jeśli to się uda, będzie wielki sukces. Zarząd zobaczy efekt i odblokuje budżet na kolejne automatyzacje.

Rozumiem ten sposób myślenia. CEO chce widzieć wpływ na biznes. Zarząd chce mieć uzasadnienie inwestycji. Właściciel nie chce finansować projektu, który będzie tylko eksperymentem bez znaczenia.

Problem w tym, że pierwsza automatyzacja rzadko jest tylko projektem technologicznym.

To moment, w którym firma uczy się wielu rzeczy naraz: jak opisywać procesy, przygotowywać dane, ustalać poprawny wynik, rozmawiać o błędach, testować rozwiązanie przed produkcją i decydować, kiedy system może działać sam, a kiedy człowiek powinien zatwierdzić wynik.

To dużo nauki jak na jeden projekt.

Dlatego nie zawsze warto zdobywać to doświadczenie na procesie, którego nie można bezpiecznie zepsuć.

Jeśli pierwsza automatyzacja dotyczy obszaru strategicznego, każdy błąd jest droższy. Każde opóźnienie jest bardziej widoczne. Każde nieporozumienie między biznesem a technologią szybciej zamienia się w frustrację.

A presja na szybki sukces może prowadzić do złych decyzji: zbyt szerokiego zakresu, zbyt dużej automatyzacji albo zbyt małej liczby testów.

Dobry pierwszy projekt powinien być wystarczająco ważny, żeby jego efekt miał znaczenie, ale nie tak krytyczny, żeby firma nie mogła się na nim uczyć.

Jeśli uda się zautomatyzować mniejszy, powtarzalny proces i pokazać konkretny efekt, rozmowa z zarządem staje się dużo łatwiejsza:

Skoro ten mniej strategiczny proces dał się uporządkować i przyniósł mierzalne korzyści, zobaczmy, co możemy osiągnąć w procesach kluczowych.

To bezpieczniejsza droga niż zaczynanie od najtrudniejszego miejsca w firmie.

Największy problem nie zawsze jest najlepszym pierwszym projektem

Najważniejsze procesy zwykle mają kilka cech, które utrudniają start.

Po pierwsze, są złożone. Mają wyjątki, zależności, decyzje, nieformalne ustalenia i ludzi, którzy „po prostu wiedzą”, co trzeba zrobić. Dopóki wszystko działa ręcznie, firma często tego nie widzi. Widać to dopiero wtedy, gdy trzeba opisać proces systemowi.

Po drugie, mają wysoki koszt błędu. Pomyłka przy drobnym zadaniu administracyjnym zwykle oznacza korektę. Pomyłka w procesie finansowym, prawnym, sprzedażowym albo operacyjnym może mieć dużo poważniejsze konsekwencje.

Po trzecie, są widoczne politycznie. Jeśli pierwszy projekt automatyzacji dotyczy procesu, na który patrzy cały zarząd, margines na naukę jest niewielki. A pierwsze wdrożenie prawie zawsze ujawnia coś, czego firma wcześniej nie widziała: braki w danych, niespójne zasady, nieopisane wyjątki albo różnice w sposobie pracy między zespołami.

To nie znaczy, że kluczowych procesów nie należy automatyzować. Często właśnie tam znajduje się największa wartość.

Chodzi o kolejność.

Najpierw warto zbudować zdolność automatyzowania na bezpieczniejszym procesie. Dopiero potem przechodzić do obszarów strategicznych z większą pewnością.

Dobry pierwszy proces ma dać efekt i ograniczyć ryzyko

Nie szukałbym na start procesu idealnego. Takie rzadko istnieją.

Szukałbym procesu, który spełnia kilka prostych warunków.

Po pierwsze, występuje wystarczająco często. Jeśli coś dzieje się raz na kwartał, nawet dobrze zrobiona automatyzacja może nie dać efektu, który przekona organizację.

Po drugie, jest powtarzalny. Nie musi być prosty, ale powinien mieć elementy, które da się opisać i sprawdzić.

Po trzecie, błąd nie powinien od razu powodować dużych strat. Na początku lepiej wybierać procesy, w których pomyłkę systemu da się szybko wykryć i poprawić.

Po czwarte, dobrze, jeśli proces pozwala na wdrożenie hybrydowe. W praktyce pierwszy projekt często nie polega na tym, że system robi wszystko sam. Częściej polega na tym, że system przejmuje część pracy, a człowiek zostaje przy trudniejszych przypadkach.

I po piąte: pierwszy efekt powinien być widoczny szybko. Nie chodzi o pełny system produkcyjny po dwóch tygodniach. Chodzi o to, żeby w ciągu 30–60 dni dało się pokazać, że kierunek ma sens: mniej ręcznej pracy, szybsza obsługa, mniej błędów albo lepiej przygotowane dane.

Macierz wpływu, kosztu i ryzyka

Żeby nie wybierać pierwszego procesu na podstawie intuicji albo presji, warto użyć prostej macierzy.

Nie musi to być rozbudowany model finansowy. Na początek wystarczy ocenić każdy proces w sześciu obszarach.

Pierwsze trzy kryteria pokazują potencjał. Im wyżej, tym lepiej.

Ostatnie trzy pokazują koszt i ryzyko. Im wyżej, tym ostrożniej trzeba podchodzić do procesu jako pierwszego projektu.

Nie chodzi o to, żeby z macierzy zrobić matematykę dla zarządu. Chodzi o coś prostszego: żeby rozmowa o automatyzacji przestała opierać się na wrażeniu, kto głośniej mówi o swoim problemie.

Przykład użycia macierzy

Załóżmy, że firma rozważa trzy procesy.

Ta tabela nie ma zastąpić dokładnej analizy. Ma pomóc w pierwszej decyzji.

Widać w niej prostą rzecz: proces finansowy może mieć największy wpływ, ale jednocześnie ma wysoki koszt wdrożenia i wysokie ryzyko błędu. To nie znaczy, że nie warto go automatyzować. To znaczy, że może nie być najlepszym miejscem do nauki.

Z kolei klasyfikacja dokumentów nie musi być najbardziej strategicznym procesem w firmie, ale ma dobry wolumen, szybki efekt i kontrolowane ryzyko. To często lepszy pierwszy projekt.

Jak interpretować wynik

Po ocenie kilku procesów zwykle widać trzy grupy kandydatów.

Najlepszy pierwszy kandydat

To proces o wysokim albo średnim wpływie, dużej powtarzalności, szybkim pierwszym efekcie, rozsądnym koszcie wdrożenia i kontrolowanym ryzyku błędu.

Często są to procesy związane z klasyfikacją dokumentów, wstępną analizą zgłoszeń, odczytem danych z powtarzalnych dokumentów, przygotowaniem odpowiedzi dla człowieka albo porządkowaniem danych przed decyzją.

Nie zawsze są najbardziej strategiczne, ale są dobre do nauki, budowania zaufania i pokazania efektu.

Dobry kandydat, ale nie na start

To proces o dużym wpływie, ale też dużym koszcie wdrożenia albo wysokim ryzyku błędu.

Taki proces może być wart automatyzacji. Po prostu lepiej wrócić do niego później: kiedy firma ma już doświadczenie, dane testowe, monitoring, lepiej opisane wyjątki i większe zaufanie do sposobu pracy z AI.

Zły pierwszy kandydat

To proces o niskim wolumenie, wysokim koszcie błędu, trudnej integracji i efekcie trudnym do zmierzenia.

Nawet jeśli brzmi atrakcyjnie, może być złym wyborem na pierwszą automatyzację. Ryzyko jest zbyt duże, a szansa na szybki, mierzalny sukces zbyt mała.

Czego uczą przykłady

Automatyzacja weryfikacji dokumentów jako proces hybrydowy

Dobrym przykładem jest ręczna weryfikacja dokumentów.

Do firmy trafiały tysiące dokumentów, które były sprawdzane ręcznie. Naturalny pomysł brzmiał: zautomatyzujmy weryfikację dokumentów.

Po analizie okazało się jednak, że nie wszystkie dokumenty są równie dobre do automatyzacji. Część była standardowa i powtarzalna. Inne były bardziej skomplikowane, mniej przewidywalne albo wymagały interpretacji.

Pełna automatyzacja wszystkiego byłaby droga i ryzykowna. Lepsze okazało się rozwiązanie hybrydowe.

Schemat był prosty:

1. Dokument trafia do systemu
2. System klasyfikuje dokument
3. Prosty, standardowy przypadek jest weryfikowany automatycznie
4. Trudniejszy przypadek jest wstępnie klasyfikowany przez system
5. Człowiek dostaje go do szybkiej weryfikacji i może potwierdzić albo zmienić wybór

Efekt był praktyczny: znacząco ograniczono pracę ludzi tam, gdzie dokumenty były powtarzalne, ale nie próbowano na siłę automatyzować przypadków trudnych.

To ważna lekcja dla pierwszego projektu automatyzacji:

Nie trzeba automatyzować 100% przypadków, żeby projekt miał sens biznesowy.

Czasem najlepszy wynik daje podział: standardowe przypadki obsługuje system, a trudne trafiają do człowieka.

AI nie zawsze oznacza LLM

Wybór procesu to jedno. Wybór technologii to drugie.

W jednym z analizowanych procesów dokumenty wyglądały na dobrego kandydata do użycia modeli językowych. Były różne, część danych pochodziła ze zdjęć, a treść wymagała analizy.

Po dokładniejszym sprawdzeniu okazało się jednak, że mimo różnic dokumenty mają wystarczająco powtarzalną strukturę. Tańsze algorytmy, reguły i heurystyki mogły dowieźć oczekiwany efekt lepiej kosztowo niż rozwiązanie oparte głównie na LLM.

Wniosek jest prosty:

Nie pytaj najpierw, jak użyć LLM. Zapytaj, jakie najprostsze rozwiązanie dowiezie oczekiwany efekt.

Więcej w osobnym tekście: kiedy naprawdę potrzebujesz LLM, a kiedy prostsza automatyzacja jest lepsza od modeli językowych.

Nie każda dokładność jest warta swojej ceny

W innym procesie automatyzacja klasyfikacji dokumentów była opłacalna przy skuteczności na poziomie około 95%.

Dało się poprawić wynik, ale koszt dojścia do wyższej dokładności był większy niż koszt obsługi pozostałych błędów.

To ważne, bo celem automatyzacji nie zawsze jest maksymalna możliwa skuteczność. Celem jest najlepszy wynik biznesowy.

W jednym procesie 95% może być bardzo dobrym wynikiem, jeśli pozostałe błędy są tanie do wykrycia i poprawienia. W innym procesie nawet 99% może być za mało, jeśli pojedyncza pomyłka ma wysokie konsekwencje.

Ten temat warto rozwinąć osobno przy omawianiu testowania AI, kosztu błędów i akceptowalnego poziomu skuteczności.

Kiedy nie zaczynać od automatyzacji, nawet jeśli technicznie jest możliwa

Nie każdy proces, który da się automatyzować, powinien być pierwszym projektem.

Analizowaliśmy proces pracy z długimi dokumentami tekstowymi. Na podstawie treści trzeba było zapisywać określone wydarzenia, o których była mowa w dokumentach.

Technicznie automatyzacja była możliwa. Problem był gdzie indziej.

Dokumentów było stosunkowo niewiele, a koszt pojedynczego błędu był bardzo wysoki. Pomyłka mogła prowadzić do konsekwencji większych niż potencjalna oszczędność z automatyzacji. Pełna automatyzacja nie miała więc sensu jako pierwszy krok.

To dobry przykład procesu, który może wyglądać atrakcyjnie technologicznie, ale słabo wypada w macierzy wpływu, kosztu i ryzyka.

Niski wolumen, wysoki koszt błędu i trudność w ocenie jakości to sygnały ostrzegawcze.

W takim przypadku lepiej zacząć od wsparcia człowieka: podsumowania dokumentu, wskazania potencjalnych fragmentów, przygotowania rekomendacji albo kontroli kompletności. Pełna automatyzacja decyzji może poczekać.

Kiedy można zacząć od procesu kluczowego?

Nie chodzi o zasadę: nigdy nie zaczynaj od ważnego procesu.

Są sytuacje, w których start od procesu kluczowego ma sens, ale wtedy muszą być spełnione konkretne warunki.

Proces powinien być dobrze opisany. Firma powinna wiedzieć, kiedy się zaczyna, kiedy kończy, jakie dane są potrzebne i co oznacza poprawny wynik.

Powinien mieć duży wolumen albo bardzo wyraźny wpływ biznesowy. Jeśli proces jest strategiczny, ale zdarza się rzadko, trudno będzie szybko pokazać efekt.

Automatyzacja powinna być możliwa etapami. Lepiej zacząć od klasyfikacji, rekomendacji, przygotowania danych albo wsparcia człowieka niż od pełnej automatyzacji decyzji.

Człowiek powinien zostać w krytycznych punktach procesu, przynajmniej na początku. To ogranicza ryzyko i pozwala zbierać dane o działaniu systemu.

Zarząd powinien też zaakceptować podejście pilotażowe. Jeśli oczekiwaniem jest pełna automatyzacja strategicznego procesu od pierwszego dnia, ryzyko rozczarowania jest wysokie.

W takim układzie kluczowy proces może być dobrym kandydatem, ale nie dlatego, że jest najważniejszy. Dlatego, że mimo swojej ważności spełnia warunki bezpiecznego startu.

Procesy, których nie wybierałbym jako pierwszych

Są procesy, które mogą być ważne, ale rzadko są dobrym pierwszym projektem automatyzacji.

Uważałbym szczególnie na te, które mają kilka z poniższych cech:

• niski wolumen
• wysoki koszt pojedynczego błędu
• dużo wyjątków
• brak danych testowych
• niejasne kryteria poprawnego wyniku
• trudne integracje z wieloma systemami
• konieczność pełnej automatyzacji decyzji
• efekt widoczny dopiero po wielu miesiącach
• duże ryzyko prawne, finansowe lub reputacyjne

To nie znaczy, że takich procesów nigdy nie należy automatyzować. Często warto się nimi zająć, ale zwykle lepiej robić to wtedy, gdy organizacja ma już za sobą pierwsze wdrożenia, lepiej rozumie swoje dane i potrafi oceniać jakość działania systemu.

Co zrobić przed wyborem pierwszego procesu

Najprostsze ćwiczenie wygląda tak: Wybierz trzy procesy, które przeszły wstępny test z poprzedniego artykułu. Dla każdego z nich odpowiedz na sześć pytań:

1. Jaki realny wpływ biznesowy da automatyzacja?
2. Jak często proces się powtarza?
3. Czy da się pokazać pierwszy efekt w 30–60 dni?
4. Jak trudne będzie wdrożenie i integracja?
5. Jaki będzie koszt działania technologii?
6. Co się stanie, jeśli system się pomyli?

Następnie odrzuć procesy, które mają jednocześnie wysoki koszt błędu, niski wolumen i trudną integrację.

Z pozostałych wybierz taki, który daje widoczny efekt, ale pozwala organizacji uczyć się bez nadmiernego ryzyka.

To zwykle najlepszy pierwszy kandydat.

Najpierw zbuduj zdolność automatyzowania

Pierwsza automatyzacja nie powinna być pokazem siły. Powinna być dobrze dobranym projektem, który buduje zaufanie, kompetencje i dane do kolejnych wdrożeń.

Jeśli pierwszy projekt będzie zbyt duży, zbyt ryzykowny albo zbyt trudny, firma może dojść do błędnego wniosku, że automatyzacja „u nas nie działa”. Tymczasem problemem nie musi być technologia. Problemem może być zły wybór pierwszego procesu.

Dlatego nie zaczynaj od największego problemu tylko dlatego, że jego rozwiązanie zrobiłoby największe wrażenie.

Zacznij od procesu, który ma dobry stosunek wpływu do kosztu i ryzyka.

Jeśli mniejszy, powtarzalny proces da się zautomatyzować i przyniesie konkretne korzyści, będzie to dużo mocniejszy argument za automatyzacją procesów kluczowych niż prezentacja pełna obietnic.

Dopiero kiedy wybierzesz dobrego pierwszego kandydata, warto przejść do kolejnego pytania:

Czy automatyzacja tego procesu faktycznie się opłaca?

To wymaga już prostego rachunku ROI: koszt pracy, koszt błędów, koszt wdrożenia, koszt utrzymania i koszt działania technologii.