Drogi czytelniku,
Organizacja, która przygotowuje się do skalowania AI, wykonuje ten sam pierwszy ruch, co wiele innych. Kupuje narzędzie do rysowania procesów i zaczyna przeprowadzać wywiady z ludźmi wykonującymi pracę, aby udokumentować procesy w stanie obecnym przed przystąpieniem do automatyzacji. Instynkt stojący za tym ruchem jest słuszny (nie można przeprojektować czegoś, czego się nie rozumie), ale narzędzie jest niewystarczające. Diagram typu swimlane daje ci wierny schemat tego, jak ludzie wykonywali tę pracę, ale nic nie mówi o tym, jak ma to robić AI.
Badanie Deloitte z 2025 roku, w którym wzięło udział 1854 europejskich menedżerów wyższego szczebla, pokazuje liczbowo, co się dzieje z organizacjami, które polegają na takim modelu: te, które stosują AI w istniejących procesach, są 1,6 razy bardziej narażone na niespełnienie oczekiwań niż te, które przeprojektowują pracę przed deploymentem. Raport GBTEC z 2025 roku — Global Process Excellence i AI-Readiness Report (600 liderów operacyjnych) stawia sprawę jeszcze ostrzej. 84% z nich wskazuje chaos operacyjny jako cichego zabójcę transformacji, a 87% twierdzi, że agenty AI wymagają ustrukturyzowanych, dobrze zarządzanych procesów przed deploymentem. Oba zbiory danych prowadzą do tego samego wniosku: to nie BPMN tu decydował o powodzeniu.
Problem stanu obecnego
Argument Michaela Hammera o reengineeringu z 1990 roku często sprowadza się do jednego zdania: nie automatyzuj, zlikwiduj. Jego prawdziwy przekaz sięgał głębiej niż to hasło. Każdy istniejący proces nosi odciski palców epoki, w której powstał. Procesy z epoki papierowej miały łańcuchy akceptacji, dlatego że żadna pojedyncza osoba nie miała pełnego obrazu sprawy. Pracownicy zmianowi przekazywali sobie zadania (handoff), ponieważ żaden człowiek nie mógł pracować bez przerw przez szesnaście godzin. Specjaliści odpowiadali za wąskie wycinki pracy, bo nauczenie kogoś wielu rzeczy naraz było drogie. Projekty cyfryzacji, które zachowały te struktury, utrwalały rozwiązania problemów, które technologia właśnie zlikwidowała.
Ten sam wzorzec powtarza się przy AI. Twój obecny proces ma taki kształt, bo wykonywali go ludzie. Rytm pracy w trybie batch wynika z tego, jak długo człowiek może utrzymać skupienie. Wielostopniowe łańcuchy akceptacji wynikają z rozproszonego kontekstu, którego żaden pojedynczy człowiek nie był w stanie objąć w całości. AI usuwa część tych ograniczeń — pozwala na ciągłe przetwarzanie tam, gdzie ludzie potrzebowali batchu, i na syntezę pełnego kontekstu tam, gdzie konieczny był handoff. W ich miejsce wprowadza nowe: przede wszystkim koszt inferencji oraz nieprzejrzystość decyzji (black box) tam, gdzie człowiek na żądanie potrafiłby wyjaśnić, dlaczego zdecydował tak, a nie inaczej.
Pytanie Hammera zaktualizowane dla ery AI brzmi: jak ten proces musiał wyglądać, ponieważ wykonywali go ludzie, a jak będzie wyglądał, gdy to ograniczenie zniknie?
Gdy to pytanie zostanie pominięte, automatyzacja wzmacnia to, co już się dzieje — i dobre, i złe. Jeśli zmapujesz proces bez jego przeprojektowania, uprzemysławiasz wczorajsze kompromisy.
Trzy aspekty, których BPMN nie ujmuje
Mapa pomija trzy rzeczy, które decydują o tym, czy deployment AI zadziała.
Typ decyzji — jawny vs. ukryty. BPMN pokazuje bramki decyzyjne. Nie rozróżnia jednak decyzji wynikających z udokumentowanych reguł (z którymi AI radzi sobie dobrze i tanio, albo można je podjąć stosując metody deterministyczne) od decyzji wymagających doświadczenia, kontekstu lub osądu (te wymagają albo architektury human-in-the-loop, albo restrukturyzacji procesu, tak aby ukryty osąd stał się jawny przed wdrożeniem AI). Większość procesów zawiera jedne i drugie, a większość map procesów nie odnotowuje tej różnicy. Wielostopniowy łańcuch akceptacji, który istnieje dlatego, że żaden pojedynczy decydent nie ma pełnego kontekstu, można często scalić, gdy AI syntetyzuje kontekst w momencie decyzyjnym — ale tylko pod warunkiem, że decyzja jest rzeczywiście jawna. Jeśli doświadczony decydent opierał się na niepisanym osądzie, którego nie mieli pozostali, to wraz z jego rolą z procesu znika również ten osąd.
Asymetria kosztu błędu. Pięcioprocentowy wskaźnik błędów w kategoryzacji wydatków jest naprawialny. Taki sam błąd w ocenie zdolności kredytowej lub w sprawozdawczości dla regulatora to już naruszenie compliance. Identyczny symbol na diagramie BPMN, zupełnie inny rachunek wdrożeniowy. Decyzji o automatyzacji nie da się oddzielić od kosztu pomyłki na danym kroku. Artykuł 14 EU AI Act nakazuje nadzór człowieka nad systemami wysokiego ryzyka, ale business case dla takiego nadzoru istnieje niezależnie od regulacji.
Architektura nadzoru człowieka jako wybór projektowy. Większość organizacji przyjmuje domyślnie HITL (AI proponuje, człowiek zatwierdza) dla każdego kroku. To domyślne ustawienie eliminuje przewagę kosztową automatyzacji. W praktyce do wyboru są trzy architektury, każda z innym profilem kosztów i ryzyka (rozróżnienie omawiałem szerzej w wydaniu numer 33):
- HITL (Human-in-the-Loop): człowiek zatwierdza output AI przed podjęciem działania. Maksymalna odpowiedzialność, największe opóźnienie i najwyższy koszt jednostkowy. Uzasadnione tam, gdzie koszt pomyłki jest poważny lub nieodwracalny. Wariantem rozluźnionym jest batch audit (audyt batchowy), w którym AI działa samodzielnie, a ludzie okresowo weryfikują próbki wyników po fakcie — niższy koszt operacyjny w zamian za opóźnione wykrywanie błędów.
- HOTL (Human-on-the-Loop): AI działa samodzielnie w zdefiniowanych granicach, a ludzie interweniują tylko przy wyjątkach oflagowanych jako niepewne. Najniższy koszt na transakcję. Jakość zależy w pełni od poprawności wyzwalaczy wyjątków — jeśli są źle skalibrowane, człowiek nigdy nie zobaczy tych przypadków, na których naprawdę zależy.
- HIC (Human-in-Command): człowiek ustala granice, cele i warunki uruchomienia kill-switcha, ale nie nadzoruje pojedynczych transakcji. Jedyny sensowny model tam, gdzie system działa szybciej, niż człowiek jest w stanie reagować — trading algorytmiczny, real-time fraud screening, szybkie pętle agentowe.
Pytanie projektowe dla każdego kroku brzmi: która z tych architektur jest w danym miejscu uzasadniona i jak należy zmienić strukturę procesu, aby to przejście było bezpieczne. Odpowiedź z osobna dla każdego kroku — to praca, której rysowanie BPMN nie wykonuje.
Kto obsługuje poszczególne kroki
Przeprojektowanie jest niepełne bez decyzji o tym, kto — lub co — realizuje dany krok. Domyślnym wyborem we wczesnych korporacyjnych pilotach jest użycie najmocniejszego dostępnego modelu frontier, w przekonaniu, że wyższa jakość obniża ryzyko. W zadaniach o dużej skali jest to zły rachunek.
Zasada jest prozaiczna i często ignorowana: najmniejszy i najtańszy model, który przekracza poprzeczkę jakościową dla tego konkretnego kroku. Klasyfikator dokumentów nie potrzebuje modelu rozumującego. Kategoryzator wydatków nie potrzebuje modelu klasy GPT-5. Przypisanie właściwego modelu do właściwego kroku to różnica między programem AI z dodatnią ekonomią jednostkową a takim, który dobrze wygląda w kwartalnej prezentacji, ale w produkcji pochłania gotówkę.
Praktyka pokazuje, dlaczego to ma znaczenie. Gemini 3.5 jest mniej więcej dwukrotnie droższy za token niż Gemini 3.1 i zużywa średnio dwa razy więcej tokenów na zadanie. Najwięksi dostawcy oferują inferencję na bardzo niskich lub wręcz ujemnych marżach w stosunku do całkowitego kosztu zbudowania modelu. Kierunek dalszych zmian cen nie jest z góry przesądzony. Architektury, które zakładają, że inferencja na poziomie frontier będzie z czasem tańsza za jednostkę pracy, to zakład, który może się nie sprawdzić.
Wielkość tego zakładu łatwiej zobaczyć na konkretnym przykładzie. Acropolium policzyło ekonomikę korporacyjnego agenta AI obsługującego trzy miliony interakcji z klientami rocznie. Business case zakłada, że AI zajmie się 50% z nich end-to-end, co daje 575% ROI w cyklu życia programu. Jeśli rzeczywisty deployment zautomatyzuje jedynie 40%, ROI spada do około 440%. Jeśli osiągnie 60%, ROI rośnie do około 680%. Pomyłka o dziesięć punktów w jednym założeniu projektowym przesuwa opłacalność całego programu o blisko 130 punktów ROI w obie strony. Opłacalność programu silnie zależy od tej jednej liczby — a wyznacza ją właśnie praca włożona w przeprojektowanie.
Wynikają z tego dwa wnioski. Zdefiniuj wymóg jakości dla każdego kroku, zanim przypiszesz mu klasę modelu — i sprawdź, że tańszy model rzeczywiście nie spełnia wymagań, zanim sięgniesz po droższy. Następnie zaprojektuj proporcję pracy człowieka do AI w każdym kroku tak, aby dało się ją dostroić bez przepisywania procesu. To zasada Hammera zastosowana do ryzyka ekonomicznego: nie wbudowuj w system założeń, których potem nie da się dostroić.
Jak prowadzić odkrywanie procesu pod AI
Skoro narzędzie do rysowania BPMN jest niewystarczające, zastępuje je inny rodzaj odkrywania procesu, a nie inne narzędzie do rysowania.
Minimalny skuteczny stack do odkrywania procesu w przedsiębiorstwie, które poważnie traktuje redesign pod AI, składa się z trzech warstw działających równolegle. Pierwsza to process-mining oparty na logach systemowych (ERP, CRM, system zgłoszeniowy), który odtwarza proces tak, jak naprawdę przebiega. Większość organizacji w tym momencie odkrywa, że proces udokumentowany i proces rzeczywiście wykonywany rozjeżdżają się znacznie bardziej, niż zarząd zakładał — i to w sposób, który zmienia rachunek automatyzacji. Druga to warstwa ustrukturyzowanych wywiadów prowadzonych przez LLM (wspartego analitykami) z odpowiednio skonstruowanym promptem, który wie, o co pytać w kwestii decyzji niejawnych, obsługi wyjątków i ukrytego osądu wbudowanego w to, jak praca naprawdę się odbywa. Taki wywiad wychwytuje to, czego BPMN nie ujmuje. Trzecia to warstwa mapująca, która klasyfikuje każdy wykryty krok przez pryzmat trzech opisanych wyżej aspektów i przypisuje mu docelową architekturę wykonawczą.
Efektem nie jest diagram swimlane, tylko specyfikacja procesu gotowa pod wdrożenie AI: każdy krok otrzymuje etykietę — rodzaj decyzji, poziom kosztu błędu, schemat nadzoru (HITL / HOTL / HIC), klasę modelu i warunki, w których któryś z tych elementów powinien zostać zrewidowany.
Od czego zacząć
BPMN pozostaje przydatny jako punkt startowy mapowania procesu i tak należy go traktować. Końcowy efekt powinien wyglądać zupełnie inaczej. Praktyczna kolejność wygląda tak:
- Odkryj, co tak naprawdę się dzieje (process-mining zamiast mapowania z dokumentacji wszędzie tam, gdzie istnieją logi).
- Przeanalizuj poszczególne kroki przez trzy aspekty: typ decyzji, asymetria kosztu błędu, wybór architektury nadzoru (HITL / HOTL / HIC).
- Zdecyduj o warstwie wykonawczej każdego kroku: klasa modelu, proporcja pracy AI do człowieka, możliwość dostrojenia.
- Sklasyfikuj kroki: zautomatyzuj as-is, zautomatyzuj z nowym schematem nadzoru, przeprojektuj proces przed automatyzacją, zostaw ręczne.
- Zacznij od kroków o dużej skali, jawnych decyzjach i odwracalnych błędach. Projektuj je od pierwszego dnia z HOTL (interwencja na wyjątkach) i z wymienialną klasą modelu. Duża skala to dokładnie miejsce, gdzie zmiany cen i modeli uderzają najmocniej — buduj pod te warunki już od pierwszego wdrożenia, nie od trzeciego.
Efektem jest uporządkowana mapa drogowa automatyzacji. Definiuje, jakie zmiany w procesie muszą poprzedzić wdrożenie technologiczne i jaki model został przypisany do którego kroku (wraz z wyzwalaczami w warstwie governance, które uruchamiają rewizję tego wyboru przy zmianie warunków).
Briefing
W kwietniu MIT Technology Review opublikował artykuł Enabling agent-first process redesign, stawiając tę samą tezę w nieco innym języku. Scott Rodgers (global chief architect w Deloitte Microsoft Technology Practice) podsumowuje zmianę modelu operacyjnego w jednym zdaniu: ludzie nadzorują, agenty AI operują. Artykuł przyznaje też coś, co większość publikacji branżowych pomija — doklejanie agentów AI do pofragmentowanych, starszych workflowów (legacy) przy użyciu dotychczasowych metod optymalizacyjnych to ten sam błąd, co w poprzednich falach modernizacji IT. “Agent-first” staje się dzisiaj standardową ramą analityków rynku.
Analiza Eda Zitrona oparta na wycieku danych Microsoftu o podziale przychodów z OpenAI pokazuje, że koszt samej inferencji znacząco przewyższa generowany z niej przychód. Artykuł badacza z Google z początku 2026 roku wskazuje koszt inferencji jako główne wąskie gardło, które uniemożliwia największym dostawcom osiągnięcie progu opłacalności. Inferencja pochłania już około 85% korporacyjnych budżetów na AI. Systemy agentowe, które rozbijają jedno polecenie użytkownika na wiele wywołań modelu, zużywają szacunkowo od 5 do 30 razy więcej tokenów na zadanie niż typowa tura z chatbotem — a ten mnożnik ląduje bezpośrednio na rachunku organizacji, która korzysta z agentów. Kierunek dalszych zmian cen nie jest przesądzony.
Pytania do zespołu zarządzającego
Czy zespół przygotowujący naszą “mapę procesów AI” pracuje narzędziem do rysowania, czy frameworkiem decyzji? Co konkretnie chcemy z tej mapy odczytać przed wdrożeniem?
Dla każdego procesu kandydującego do automatyzacji — które decyzje opierają się na jawnej regule, a które na ocenie eksperckiej? Kto i kiedy to formalnie sklasyfikował?
Gdzie koszt błędu byłby nieodwracalny (regulacyjnie, finansowo, reputacyjnie)? Czy projekt nadzoru człowieka w tych punktach wynika z analizy, czy z domyślnego ustawienia “AI proponuje, człowiek zatwierdza” wszędzie?
Dla każdego planowanego wdrożenia — jaki model planujemy uruchamiać i dlaczego ten, a nie tańszy? Czy testowaliśmy, że tańszy nie wystarczy, czy zakładamy?
Podsumowanie
Organizacje, które realnie uzyskują zwrot z inwestycji w AI, podjęły dwie decyzje projektowe tam, gdzie większość poprzestała na jednej. Pierwsza dotyczy tego, jak proces ma wyglądać, gdy nie ograniczają go już ludzie, którzy go dotąd obsługiwali. Druga dotyczy tego, ile z tego projektu powinno pozostać dostrajalne, gdy zmienia się koszt inferencji, klasa modelu i poprzeczka jakości. Mapa procesu zrobiona z wywiadów z obecnymi operatorami nie odpowiada na żadne z tych pytań. Dokumentuje stan obecny — czyli dokładnie to, od czego cała przebudowa miała nas oddalić.
Zachowaj równowagę, Krzysztof Goworek
Krzysztof Goworek jest założycielem Quintant — doradztwo w zakresie AI governance i EU AI Act dla przedsiębiorstw regulowanych.