ROI z AI w produkcji: jak liczyć, czego nie wpisywać w business case

Krótka odpowiedź: ROI z AI w produkcji liczy się jak każdy inny business case, z jedną różnicą. Korzyści trzeba przypiąć do konkretnego procesu, a nie do ogólnego „wzrostu produktywności”. Weź dwa, trzy workflowy, dla których masz dane o czasie dziś (baseline), policz oszczędzony czas razy stawka, dodaj koszt wdrożenia i utrzymania i sprawdź payback. Przy uczciwych, konserwatywnych założeniach pierwszy workflow zwraca się zwykle w 9 do 18 miesięcy. Jeśli wychodzi poniżej 6 miesięcy, założenia są prawdopodobnie za optymistyczne. Poniżej rozkładamy, co wpisać do licznika korzyści, jak wyłapać ukryte koszty i dajemy ramkę do wypełnienia własnymi liczbami.

Zanim firma podpisuje umowę z vendorem AI, ktoś musi stanąć przed finansowym i powiedzieć, kiedy się to zwróci. I zazwyczaj w tym momencie pojawiają się dwa błędy: albo business case jest za optymistyczny i po roku nikt nie może wytłumaczyć, dlaczego liczby „jakoś nie wyszły”, albo jest tak zachowawczy, że projekt nigdy nie dostaje zielonego światła.

Ten post jest o tym, jak liczyć uczciwie.

Co wchodzi do licznika korzyści (i co do niego nie wchodzi)

Zacznijmy od strony przychodów. W AI dla produkcji realnie amortyzują się trzy kategorie korzyści:

Oszczędność czasu specjalistów. Jeśli asystent serwisowy skraca czas potrzebny do przygotowania kroków rozwiązania, a serwisanci obsługują dużą liczbę zgłoszeń miesięcznie, zaoszczędzone godziny sumują się do wymiernej pozycji na jednym workflow. To akurat da się policzyć twardo: liczba zgłoszeń razy skrócenie czasu razy stawka godzinowa.

Skrócenie cyklu ofertowego. Biuro techniczne, które dziś potrzebuje kilku dni na draft oferty przy zapytaniach z rysunkami, z AI w pętli schodzi do części dnia. Przy stałym strumieniu zapytań i typowym dla firmy win rate to bezpośrednio więcej zamkniętych deali w tym samym czasie zespołu.

Redukcja błędów i rework. Instrukcje pracy generowane z dokumentacji źródłowej mają mniej odchyleń od standardu niż te pisane z pamięci. Trudniej to policzyć niż godziny, ale jeśli firma ma historię kosztów rework, to warto spojrzeć.

Czego nie wpisujemy do business case:

• „Wzrost produktywności o X%” bez konkretnego procesu za tym stojącego.
• „Oszczędność z nieprzyjmowania ludzi”, o ile nie ma otwartego wakatu, którego naprawdę nie chcemy zapełniać.
• Korzyści z workflowów, które jeszcze nie istnieją w scope wdrożenia.
• „Możliwy wzrost sprzedaży”, chyba że jest bezpośrednie przełożenie przez konkretny proces (np. cykl ofertowy).

Doświadczenie pokazuje, że business case z trzema konkretnymi, mierzalnymi pozycjami jest twardszy niż jeden z ośmioma „szacunkowymi”.

Jak liczyć koszty (bez pomijania ukrytych)

Koszty wdrożenia AI mają zwyczaj rosnąć poza fakturą vendora. Typowe ukryte pozycje:

Czas wewnętrzny przy onboardingu. Ktoś musi zebrać dokumentację źródłową, sprawdzić jej jakość, opisać procesy. Przy solidnym wdrożeniu to kilkadziesiąt godzin pracy właściciela procesu w pierwszych tygodniach. Przy stawce specjalisty warto to wycenić.

Integracje. Jeśli AI ma czytać z systemu ERP lub ticketingowego, ktoś musi to podłączyć. Prosty konektor: kilka dni. Niestandardowy: kilka tygodni i dedykowany dev.

Utrzymanie modelu wiedzy. Dokumentacja się starzeje. Ktoś musi pilnować, żeby baza wiedzy była aktualna. To nie jest jednorazowy koszt, to operacyjny.

Sprzęt lub infrastruktura (jeśli on-prem). GPU appliance, serwer, licencje systemowe. Amortyzuje się inaczej niż subskrypcja SaaS, trzeba liczyć TCO, nie tylko rok 1.

Dla średniej firmy produkcyjnej koszt wdrożenia pierwszego workflow z integracją i roczny koszt utrzymania to dwie osobne pozycje, które trzeba wycenić u vendora, a nie zakładać z góry. Przy bardziej złożonych integracjach obie rosną, a sprzęt on-prem dochodzi osobno. Sama decyzja, czy zbudować własny model, czy kupić gotowy, zmienia strukturę tych kosztów, rozkładamy ją w build vs buy AI w produkcji.

Prosty szablon do business case

Struktura, która działa na komitecie inwestycyjnym:

Pozycja	Sposób liczenia
Czas zaoszczędzony na miesiąc	liczba zgłoszeń × czas delta × stawka
Przychód z szybszego ofertowania	liczba ofert × skrócenie czasu × win rate × ACV
Redukcja rework	% defektów × koszty rework na rok
Razem korzyści na rok	suma powyższych
Koszt wdrożenia (jednorazowy)	faktura + czas wewnętrzny + integracja
Koszt utrzymania (roczny)	subskrypcja lub amortyzacja sprzętu + czas ops
ROI (rok 1)	(korzyści - koszty) / koszty
Payback period	koszt całkowity / korzyści na miesiąc

Ramka do wypełnienia dla Twojej firmy

Zamiast gotowych kwot, które łatwo odczytać jako benchmark, tabela do wypełnienia własnymi danymi. Wpisz swój baseline w ostatnią kolumnę, środkowa kolumna mówi, skąd wziąć każdą liczbę.

Pozycja	Skąd wziąć liczbę	Twoja wartość
Czas zaoszczędzony na miesiąc	liczba zgłoszeń × delta czasu × stawka	____
Przychód z szybszego ofertowania	liczba ofert × skrócenie czasu × win rate × ACV	____
Redukcja rework	% defektów × koszt rework na rok	____
Korekta na realną efektywność (× 0,75)	pomnóż sumę korzyści, nie zakładaj 100%	____
Koszt wdrożenia (jednorazowy)	oferta vendora + integracja + czas wewnętrzny	____
Koszt utrzymania (roczny)	subskrypcja lub amortyzacja + czas ops	____
ROI rok 1	(korzyści - koszty) / koszty	____
Payback	koszt całkowity / korzyść na miesiąc	____

Kiedy już wypełnisz ramkę, sprawdź wynik pod kątem zdrowego rozsądku. Poniższe zakresy nie są obietnicą wyniku, tylko punktem odniesienia z typowych wdrożeń pierwszego workflow:

Wskaźnik	Co zwykle wychodzi	Co powinno zapalić lampkę
Payback pierwszego workflow	9 do 18 miesięcy	poniżej 6 miesięcy (za optymistycznie) lub powyżej 36 miesięcy (zły pierwszy proces)
ROI rok 1	często ujemny, bo wdrożenie to koszt jednorazowy	dodatni już w rok 1: sprawdź, czy nie pominięto kosztów
Liczba pozycji korzyści	2 do 3 twarde, mierzalne	6 i więcej „szacunkowych”: business case się rozjeżdża
Korekta na efektywność	mnożnik 0,7 do 0,8	brak korekty (100%): przeszacowanie

Najważniejsza intuicja: rok 1 pierwszego workflow najczęściej wychodzi na minusie, bo koszt wdrożenia jest jednorazowy, a korzyści narastają w czasie. Payback poniżej 6 miesięcy powinien zapalić lampkę, że albo koszt wdrożenia policzono za nisko, albo korzyści za wysoko.

Kiedy nie liczyć, tylko pilotować

Bywa, że business case jest trudny do zbudowania z góry, bo nie ma historycznych danych o czasie procesu albo scope jest niejasny. W takim przypadku lepiej zaproponować ograniczony pilotaż z wyraźnymi metrykami sukcesu, niż spędzać 3 tygodnie na modelu finansowym opartym na założeniach.

Dobry pilot ma:

• jeden konkretny proces (np. asystent do zgłoszeń serwisowych),
• baseline przed wdrożeniem (ile trwa dziś),
• mierzalny cel (np. zdefiniowane skrócenie czasu na zgłoszenie),
• horyzont czasowy (6 do 8 tygodni to minimum).

Po pilocie masz dane, nie założenia. I znacznie łatwiej obronić decyzję o skalowaniu.

Czego ten post nie pokrywa

To jest ramka do policzenia business case, nie gotowy model finansowy pod Twoją firmę. Nie wchodzimy w metody amortyzacji księgowej ani w podatkowe ujęcie wydatku na AI, bo to zależy od jurysdykcji i polityki firmy. Nie porównujemy tu konkretnych vendorów ani cenników, i nie rozstrzygamy wyboru on-prem kontra chmura, bo to osobny temat kosztowy. Nie podajemy też gotowych kwot w ramce ROI, bo każdy wynik zależy od Twojego baseline, wzory pokazują tylko, jak liczyć.

Powiązane notatki

• Pięć workflowów AI, które już dziś amortyzują się w polskiej produkcji, przegląd pięciu procesów, których ROI liczymy w tym poście.
• Asystent serwisowy AI: dlaczego średnia firma produkcyjna to dobry kandydat, workflow, z którego pochodzi przykład oszczędności czasu serwisantów.
• AI do generowania instrukcji pracy: jak to działa i ile kosztuje, skąd się bierze redukcja błędów i rework w kalkulacji.
• Jak ocenić gotowość firmy produkcyjnej do wdrożenia AI: 5 pytań, zanim policzysz ROI, sprawdź, czy w ogóle jest co liczyć.