Załóżmy, że mamy już proces, który wygląda na sensownego kandydata do automatyzacji. Jest w nim wystarczająco dużo powtarzalnej pracy, znamy problem i wiemy, że technicznie da się część tej pracy przejąć systemem.

W tym miejscu bardzo łatwo przejść do prostego rachunku: skoro proces zajmuje ludziom 200 godzin miesięcznie, a automatyzacja może przejąć 70% pracy, to wystarczy wycenić 140 godzin i porównać je z kosztem wdrożenia.

Sam często zaczynam od podobnego szacunku. Jest szybki i pozwala sprawdzić skalę możliwości.

Problem zaczyna się wtedy, kiedy odzyskany czas zaczynamy traktować jak pieniądze, które rzeczywiście znikną z kosztów firmy. W praktyce te dwie rzeczy bardzo często nie są tym samym.

Dlatego zanim przejdę do ROI, wolę zadać inne pytanie:

Co naprawdę zmieni się w ekonomice procesu, jeśli wdrożymy automatyzację?

Dobry kandydat nie zawsze oznacza dobrą inwestycję

To rozróżnienie wydaje się oczywiste, ale w rozmowach o automatyzacji regularnie się zaciera.

Proces może być świetnym kandydatem od strony operacyjnej: ręczny, powtarzalny, czasochłonny i możliwy do zautomatyzowania. To nadal nie mówi nam jednak, czy warto wydać na niego pieniądze.

W jednym z analizowanych przez nas tematów technicznie mogliśmy zautomatyzować znaczną część analizy dokumentów, ale po policzeniu wolumenu, pracy pozostającej po stronie człowieka i konsekwencji błędu nie rekomendowaliśmy pełnej automatyzacji. System dało się zbudować. Business case się nie bronił.

I właśnie ten drugi krok interesuje mnie tutaj najbardziej.

Dobry business case powinien pokazać nie tylko, że system wykona pracę, ale że po wdrożeniu firma rzeczywiście będzie w lepszej sytuacji (finansowo, operacyjnie albo jedno i drugie), a poprawa będzie wystarczająco duża w stosunku do kosztu i ryzyka.

200 odzyskanych godzin może być warte bardzo dużo. Albo prawie nic

Najczęstsze uproszczenie wygląda tak:

odzyskane godziny × koszt godziny pracy = oszczędność.

Czasem ten rachunek jest całkowicie uzasadniony. Jeśli dzięki automatyzacji ograniczamy outsourcing, nadgodziny albo inny realny wydatek, korzyść rzeczywiście trafia do wyniku finansowego.

Czasem wartość pojawia się w przyszłości. Firma rośnie i bez automatyzacji za kilka miesięcy musiałaby zatrudnić kolejną osobę. Wtedy projekt nie obniża dzisiejszych kosztów, ale pozwala uniknąć wydatku, który prawdopodobnie pojawiłby się później.

Jest też sytuacja, z którą spotykam się bardzo często: ludzie odzyskują czas, ale koszt zespołu się nie zmienia. Taka korzyść nadal może być bardzo cenna, jeśli dzięki niej firma obsłuży większy wolumen, szybciej zamknie sprawy albo przeniesie ludzi do pracy o większej wartości.

Tyle że trzeba jeszcze umieć tę zdolność operacyjną rzeczywiście wykorzystać.

Wyobraźmy sobie, że automatyzacja oszczędza 20 minut dziennie trzydziestu osobom. W skali miesiąca robi się z tego około 200 godzin. W arkuszu wygląda to jak ponad jeden pełny etat.

W rzeczywistości firma nie może „zwolnić 1,25 osoby”. Jeśli te 20 minut jest rozrzucone po całej organizacji i nie przekłada się na większą przepustowość albo konkretną pracę, wartość finansowa może być znacznie niższa, niż sugeruje suma godzin.

Dlatego w takich projektach zadaję dwa pytania:

Co konkretnie zrobimy z odzyskanym czasem?

oraz:

Czy potrafimy ten odzyskany czas przełożyć na konkretny wynik biznesowy?

Jeśli odpowiedź brzmi: „obsłużymy 20% więcej spraw bez zwiększania zespołu”, mamy konkretny mechanizm wartości. Jeśli odpowiedź brzmi: „każdy będzie miał trochę mniej pracy”, ostrożniej podchodziłbym do wpisywania pełnej wartości tych godzin po stronie oszczędności.

I jeszcze jedna rzecz: tej samej korzyści nie należy liczyć dwa razy. Jeśli odzyskany czas pozwala uniknąć nowego etatu, to uniknięty koszt jest już efektem biznesowym. Nie dodawałbym do niego ponownie wartości tych samych godzin.

Wartość projektu to nie tylko niższe koszty

Przy automatyzacji łatwo skupić się wyłącznie na redukcji pracy. Tymczasem w praktyce wartość może powstawać w kilku miejscach.

Może zniknąć realny koszt. Możemy uniknąć przyszłego kosztu. Możemy zwiększyć przepustowość i dzięki temu wygenerować dodatkową marżę. Może też zmienić się koszt błędów, poprawek i opóźnień.

Szczególnie uważałbym na trzeci przypadek. Jeśli automatyzacja pozwala obsłużyć dodatkowy 1 mln zł sprzedaży, nie wpisywałbym do business case'u miliona złotych korzyści. Interesuje mnie dodatkowa marża, która rzeczywiście zostaje w firmie dzięki zwiększonej przepustowości.

To drobna różnica w języku, ale bardzo duża w arkuszu.

Nie porównuj dzisiejszego procesu z idealnym jutrem

Drugi częsty problem pojawia się wtedy, kiedy zestawiamy koszt procesu dzisiaj z kosztem procesu „po automatyzacji”.

Ja wolę patrzeć na dwie możliwe przyszłości w tym samym okresie.

Pierwsza to przyszłość bez projektu. Co stanie się z wolumenem? Czy trzeba będzie zwiększyć zespół? Czy wzrośnie outsourcing? Jak będą wyglądać koszty błędów, poprawek i opóźnień, jeśli proces pozostanie bez zmian?

Druga to przyszłość po wdrożeniu. Tutaj trzeba policzyć nie tylko to, co system przejmie, ale też to, co nadal pozostanie po stronie ludzi: weryfikację, wyjątki, poprawki i obsługę trudniejszych przypadków.

Do tego dochodzi technologia.

I tu stosuję prostą zasadę: porównuję pełny koszt procesu w obu scenariuszach, a nie cenę projektu IT z kosztem pracy ludzi.

W praktyce oznacza to uwzględnienie kosztu dojścia do rozwiązania i jego późniejszego działania: wdrożenia, integracji, czasu własnego zespołu, technologii oraz pracy, która po automatyzacji nadal pozostaje. Nie rozwijałbym na tym etapie pełnego TCO systemu na kilka lat, ale pominięcie tych pozycji potrafi sztucznie poprawić wynik.

Podobnie patrzę na błędy. Obecny proces również może generować pomyłki, więc nie interesuje mnie sam „koszt błędów AI”, tylko zmiana kosztu błędów i poprawek między scenariuszem bez projektu i po wdrożeniu.

Pięć pozycji, które wystarczą do pierwszej decyzji

Na początku nie potrzeba modelu finansowego na dwadzieścia zakładek. Zwykle wystarczy odpowiedzieć na pięć pytań:

1. Bez projektu: jak proces będzie wyglądał za 12–24 miesiące?
2. Po wdrożeniu: co naprawdę zniknie, a co nadal zostanie po stronie ludzi i systemu?
3. Różnica: jaki koszt znika, jakiego unikamy, jaką dodatkową marżę możemy wygenerować i jak zmienia się koszt błędów?
4. Inwestycja: ile naprawdę kosztuje dojście do tego stanu?
5. Próg decyzji: jak dobry musi być wynik, żeby firma uznała projekt za wart inwestycji?

Ta ostatnia pozycja jest ważniejsza, niż może się wydawać. Dodatni wynik nie oznacza jeszcze dobrej inwestycji. Projekt trzeba porównać z ryzykiem, oczekiwanym przez firmę okresem zwrotu i innymi sposobami wykorzystania tego samego kapitału.

Prosty przykład: 60 tys. zł rocznej korzyści. I co z tego?

Załóżmy, że firma przetwarza dziś około 4 tysięcy dokumentów miesięcznie, a za rok spodziewa się 6 tysięcy. Obecny zespół jest już blisko granicy możliwości.

Bez automatyzacji firma zakłada, że przy takim wzroście będzie potrzebowała dodatkowej osoby, której pełny roczny koszt wyniesie około 150 tys. zł. Zakładamy też, że przy tym wolumenie koszt błędów i poprawek wyniesie około 30 tys. zł rocznie.

Po automatyzacji dodatkowy etat nie jest potrzebny, ale pojawiają się inne koszty: około 60 tys. zł rocznie za działanie rozwiązania, 40 tys. zł za zewnętrzną weryfikację trudniejszych przypadków, a koszty błędów i poprawek spadają do około 20 tys. zł.

Roczna korzyść wynikająca z różnicy między scenariuszami wynosi więc około 60 tys. zł.

Jeśli wdrożenie kosztuje 120 tys. zł, prosty okres zwrotu wynosi około dwóch lat.

To jest payback, nie ROI.

Przy tym samym uproszczeniu trzyletni ROI wyniósłby około 50%: przez trzy lata projekt wygenerowałby 180 tys. zł korzyści, a po odjęciu 120 tys. zł początkowej inwestycji zostałoby 60 tys. zł, czyli połowa zainwestowanej kwoty. Przy większej, wieloletniej inwestycji taki prosty rachunek oczywiście nie zastępuje normalnej analizy finansowej.

Ale ważniejsze pytanie brzmi: czy dwa lata to dla tej firmy dobry wynik?

Nie ma jednej odpowiedzi.

Jeżeli firma oczekuje zwrotu z tego typu projektu w maksymalnie 18 miesięcy, ten projekt w obecnej formie nie przechodzi. Przy inwestycji 120 tys. zł potrzebowałby około 80 tys. zł rocznej korzyści, a nie 60 tys.

I właśnie tutaj business case zaczyna pomagać w podjęciu decyzji, zamiast tylko ją uzasadniać.

Możemy zapytać: co musiałoby się zmienić, żeby dojść z 60 do 80 tys. zł? Niższy koszt wyjątków? Większy wolumen? Większa część przypadków obsługiwana bez człowieka? Dodatkowa marża dzięki większej przepustowości?

Jeśli najważniejszą niewiadomą jest na przykład odsetek spraw, które system obsłuży samodzielnie, można odwrócić rachunek i policzyć minimalny wymagany poziom automatyzacji. Dopiero potem zrobić pilotaż i sprawdzić, czy realne dane pokazują wynik powyżej tego progu.

To jest dla mnie znacznie bardziej użyteczne niż stwierdzenie: „zakładamy 80% automatyzacji”.

Dobra decyzja nie zawsze kończy się wdrożeniem

Po takim rachunku zwykle widzę trzy możliwe sytuacje.

Projekt broni się również przy ostrożnych założeniach i spełnia wymagany próg zwrotu. Wtedy warto iść dalej.

Wynik zależy od jednej lub dwóch rzeczy, których jeszcze nie znamy. Wtedy nie potrzebujemy pełnego wdrożenia, tylko testu zaprojektowanego właśnie po to, żeby zmierzyć te niewiadome.

Albo projekt wygląda dobrze wyłącznie wtedy, gdy przyjmiemy bardzo optymistyczne założenia. Wtedy lepiej zmniejszyć zakres albo na razie go nie robić.

W rozmowach z firmami czasem właśnie to jest najcenniejszym wynikiem analizy: nie znalezienie sposobu na wdrożenie AI, ale szybkie dojście do wniosku, że w danym miejscu inwestycja się nie broni.

Dobry business case nie ma uzasadnić projektu. Ma pomóc zdecydować, czy firma rzeczywiście powinna wydać na niego pieniądze.

A jeśli odpowiedź brzmi „tak”, dopiero wtedy warto przejść do następnego pytania: jakie najprostsze rozwiązanie dowiezie ten wynik i czy rzeczywiście potrzebujemy do tego AI.