Po co w ogóle liczyć opłacalność AI w IT, zamiast „iść za trendem”
Presja na wdrażanie AI w działach IT jest duża: zarząd pyta, konkurencja chwali się na konferencjach, dostawcy pokazują efektowne demo. Tymczasem większość projektów AI rozbija się nie o technologię, ale o to, że nie bronią się w Excelu – nie mają policzonych korzyści, kosztów i scenariuszy ryzyka.
Różnica między „fajnym use casem” a opłacalnym wdrożeniem AI polega na tym, że ten drugi ma klarowną odpowiedź na pytania: ile to kosztuje, ile przyniesie oszczędności lub dodatkowej wartości i kiedy to się zwróci. Bez tego AI w IT staje się kolejną kosztowną zabawką zamiast narzędzia do poprawy efektywności utrzymania, rozwoju systemów czy bezpieczeństwa.
W IT istnieje kilka obszarów, gdzie AI ma szansę realnie zarabiać lub znacząco ograniczać koszty:
Utrzymanie – wsparcie Service Desk, automatyczna klasyfikacja i routing zgłoszeń, predykcja awarii, analiza logów.
Rozwój – wsparcie programistów (np. generowanie kodu, podpowiedzi), automatyczne testy, analiza regresji.
Wsparcie użytkowników biznesowych – chatboty, asystenci do analizy danych, generowanie dokumentacji technicznej i instrukcji.
W każdym z tych obszarów da się policzyć roboczogodziny, opóźnienia, błędy, kary czy utracone szanse sprzedażowe wynikające z przestojów. To właśnie jest punkt wyjścia do analizy ROI AI w IT.
Definicja decyzji: co właściwie chcesz rozstrzygnąć
Krok 1 przed jakimikolwiek kalkulacjami: nazwanie decyzji, którą trzeba podjąć. To brzmi banalnie, ale zaskakująco często projekty AI ruszają bez jasnego pytania biznesowego. Przykłady dobrze postawionych decyzji:
„Czy opłaca się wdrożyć AI do klasyfikacji zgłoszeń w Service Desk L1 w ciągu najbliższych 12 miesięcy?”
„Czy lepiej kupić gotową platformę AIOps, czy zbudować rozwiązanie in-house w oparciu o dostępne modele?”
„Czy automatyzacja testów z wykorzystaniem AI pozwoli skrócić czas release’ów na tyle, by uzasadnić koszt wdrożenia?”
Od konkretnego pytania zależy, jakie dane zbierzesz, jak policzysz TCO rozwiązań AI i jaką strukturę będzie miał business case dla AI w dziale IT. Bez tego liczby będą w próżni.
Hype kontra twarde scenariusze
Decyzja „wdrażamy AI, bo inni wdrażają” to prosta droga do przepalenia budżetu. W praktyce potrzebne są minimum trzy scenariusze:
Scenariusz 0 – status quo: co się stanie, jeśli nic nie zrobimy przez 2–3 lata (koszty utrzymania obecnego procesu, ryzyko wzrostu wolumenów, presja na SLA).
Scenariusz 1 – podejście minimalne: np. mały proof of concept AI w jednym procesie IT, tylko najbardziej oczywistych przypadków użycia.
Scenariusz 2 – podejście ambitniejsze: szersze wdrożenie AI, większy efekt, ale też większe koszty startowe i większe ryzyko.
Dopiero porównanie tych scenariuszy (bez AI i z AI) pozwala uczciwie porozmawiać z zarządem. Sama obietnica „oszczędzimy 20% czasu zespołu” bez pokazania kosztów implementacji i utrzymania w czasie nie ma większej wartości.
Co sprawdzić na tym etapie
Czy potrafisz jednym zdaniem nazwać decyzję biznesową, którą chcesz podjąć dzięki analizie opłacalności AI?
Czy wiesz, w którym konkretnie procesie IT AI ma zadziałać – zamiast ogólnego „AI w IT”?
Czy masz przynajmniej szkic trzech scenariuszy: brak zmian, małe wdrożenie AI, większy rollout?
Czy główny powód rozważania AI to mierzalny problem (koszty, SLA, brak ludzi), a nie „bo zarząd pyta, gdzie mamy AI”?
Źródło: Pexels | Autor: Kindel Media
Jakie procesy IT w ogóle nadają się do AI – szybkie mapowanie
Zanim zacznie się liczyć opłacalność AI, trzeba wiedzieć, gdzie w ogóle AI ma sens. Nie każdy proces w IT nadaje się do automatyzacji lub wsparcia przez modele. Najczęściej największy potencjał kryje się tam, gdzie jest duży wolumen powtarzalnych zadań oraz dużo danych historycznych.
Krok 1: spis procesów IT z potencjałem
Najprostszy sposób na start to krótki warsztat (1–2 dni) z kluczowymi osobami z IT. Podejście krok po kroku:
Krok 1: Zbierz przedstawicieli z kluczowych obszarów:
Service Desk / wsparcie użytkowników,
utrzymanie systemów, monitoring, NOC,
DevOps / CI/CD,
testy i QA,
bezpieczeństwo (SOC, IAM),
architektura / zarządzanie zmianą.
Krok 2: Na tablicy (fizycznej lub Miro) wypisz wszystkie główne procesy IT w tych obszarach. Bez oceny, czy nadają się do AI. Chodzi o pełny obraz: od przyjęcia zgłoszenia, przez diagnozę, działania naprawcze, po dokumentowanie i raportowanie.
Krok 3: Przy każdym procesie zapisz:
szacunkową liczbę zdarzeń miesięcznie (zgłoszeń, incydentów, deployów, testów itp.),
średni czas pracy człowieka na jedno zdarzenie,
główne narzędzia używane obecnie (system zgłoszeń, monitoring, CI/CD).
Na tym etapie nie trzeba znać dokładnych liczb. Wystarczą dobre szacunki od ludzi, którzy na co dzień wykonują te zadania. Celem jest zbudowanie mapy, aby łatwo wychwycić procesy, gdzie AI może przynieść oszczędności z automatyzacji procesów IT.
Gdy lista procesów IT jest gotowa, pora sprawdzić, które z nich są „dobrymi kandydatami” na AI. Do szybkiej kwalifikacji przydają się trzy kryteria:
Powtarzalność – czy zadania w procesie są do siebie podobne, mają podobny przebieg, podobne dane wejściowe?
Wolumen – czy zdarzeń jest dużo w skali miesiąca/roku?
Koszt błędu – co się stanie, jeśli AI popełni błąd lub zaproponuje złą akcję?
Można posłużyć się prostą skalą 1–3 (niski, średni, wysoki) dla każdego kryterium i przyznać każdemu procesowi punkty. Procesy z wysoką powtarzalnością i wysokim wolumenem, ale akceptowalnym kosztem błędu, powinny wylądować na górze listy.
Przykładowe obszary z potencjałem
W praktyce wiele firm zaczyna od podobnych use case’ów:
Service Desk / L1 – automatyczne klasyfikowanie zgłoszeń, sugerowanie odpowiedzi na bazie bazy wiedzy, prosty chatbot dla użytkowników.
Wsparcie L1 – wysoki wolumen zgłoszeń, duża powtarzalność (hasła, dostęp, proste błędy), względnie niski koszt błędu, o ile AI jedynie sugeruje odpowiedź człowiekowi.
Testy automatyczne w CI/CD – początkowo niższy wolumen, za to wysoki koszt błędu przy krytycznych systemach. Tu AI często lepiej stosować jako wsparcie (np. sugestie przypadków testowych), a nie całkowitą automatyzację decyzyjną.
Jak zorganizować warsztat mapujący pod AI
Praktyczny scenariusz warsztatu 1–2 dniowego:
Dzień 1, rano: spis wszystkich procesów IT w kluczowych obszarach, bez cenzury i ocen.
Dzień 1, popołudnie: pierwsza kwalifikacja według powtarzalności, wolumenu i kosztu błędu.
Dzień 2, rano: doprecyzowanie danych ilościowych do top 5–10 procesów (wolumen, FTE, SLA, incydenty krytyczne).
Dzień 2, popołudnie: wybór 1–3 procesów, które trafią do szczegółowej analizy opłacalności i ewentualnego proof of concept AI w IT.
Ważne, by na warsztacie był ktoś z finansów lub controlling – dzięki temu już na starcie wiadomo, jakich danych będą wymagać przy ocenie business case’u.
Co sprawdzić po mapowaniu procesów
Czy każdy wybrany proces ma właściciela, który może dostarczyć dane i współdecydować o zmianach?
Czy proces ma mierniki (SLA, czas obsługi, liczba błędów, liczba incydentów), na których można oprzeć metryki efektywności wdrożeń AI?
Czy dostępne są dane historyczne (logi, zgłoszenia, tickety, wyniki testów) w ilości sensownej dla trenowania lub konfiguracji modeli?
Czy rozumiesz, jaki jest koszt błędu AI w tym konkretnym procesie i jakie mechanizmy „human in the loop” będą konieczne?
Źródło: Pexels | Autor: Kindel Media
Jakie liczby są potrzebne: fundamenty kalkulacji (koszty i korzyści)
Ocena opłacalności wdrożenia AI w procesach IT wymaga dwóch podstawowych zestawów danych: kosztów obecnego procesu (as-is) oraz kosztów i korzyści przyszłego procesu z AI (to-be). Bez rzetelnego policzenia obu stron porównania analiza ROI AI w IT będzie czystą spekulacją.
Koszty obecnego procesu „as-is”
Krok 1: zmapowanie i policzenie pełnego kosztu funkcjonowania wybranego procesu w obecnej formie. Warto rozbić to na kilka składowych:
Roboczogodziny – ile czasu miesięcznie zespół spędza na danym procesie (np. obsługa zgłoszeń L1)? Można to policzyć jako: liczba zdarzeń × średni czas na zdarzenie + czas „ukryty” (koordynacja, eskalacje, poprawki).
Koszt pracy – ile kosztuje godzina pracy (lub FTE) osób zaangażowanych w proces? Dobrze użyć stawek z controllingu: pełny koszt zatrudnienia, nie tylko wynagrodzenie brutto.
SLA i opóźnienia – jak często dochodzi do przekroczenia SLA, jakie są skutki (kary, eskalacje, niezadowolenie klientów wewnętrznych/zewnętrznych)?
Błędy i poprawki – ile błędów pojawia się w procesie, ile czasu i kosztów generują poprawki (np. rollback release’ów, ręczne łatanie incydentów, awaryjne patche)?
Utracone szanse – np. przestoje systemów sprzedażowych, opóźnione wdrożenia funkcji potrzebnych biznesowi, utracone przychody z niedostępnych systemów.
Przykład podejścia: dla Service Desk można zliczyć czas pracy analityków L1 w miesiącu, wskaźnik rozwiązania przy pierwszym kontakcie (FCR), liczbę eskalacji do L2/L3 oraz ewentualne kary za przekroczenia SLA. To daje solidny obraz, ile „kosztuje” bieżąca obsługa bez AI.
Koszty wdrożenia i utrzymania AI „to-be”
Krok 2: policzenie pełnego kosztu AI, a nie tylko licencji lub projektu wdrożeniowego. Należy wziąć pod uwagę:
Licencje i subskrypcje – koszty platform AI (SaaS, PaaS), opłaty za tokeny, modele, specjalistyczne narzędzia (np. AIOps).
Infrastruktura – koszty chmury (GPU, storage, transfer danych) lub serwerów on-prem, jeśli firma planuje hostować rozwiązanie sama.
Wdrożenie – prace deweloperskie, integracja z istniejącymi systemami (ITSM, monitoring, CI/CD), konfiguracja modeli, przygotowanie danych.
Szkolenia – przeszkolenie zespołu IT, użytkowników końcowych, administratorów AI (MLOps, AIOps).
Zmiany procesów – przeprojektowanie procedur, runbooków, ról, uprawnień, a często także aktualizacja dokumentacji i polityk bezpieczeństwa.
Ukryte koszty AI, które łatwo pominąć
Przy pierwszych kalkulacjach wiele organizacji skupia się na licencjach i wdrożeniu. Tymczasem największe zaskoczenia finansowe pojawiają się później. Żeby ich uniknąć, przejdź etapami przez mniej oczywiste obszary.
Utrzymanie i tuning modeli – modele wymagają doglądania: dostrajania, aktualizacji, monitoringu jakości (drift danych, spadek trafności). To konkretne roboczogodziny zespołu lub zewnętrznego dostawcy.
Obsługa wyjątków – wszystko, czego AI „nie ogarnia”, wraca do ludzi. Jeśli proces jest krytyczny, trzeba zapewnić dyżury, ścieżki eskalacji, dodatkowe procedury.
Governance i compliance – komitety sterujące, przeglądy modeli, audyty bezpieczeństwa i zgodności (RODO, regulacje branżowe). To nowa warstwa zarządzania, która zużywa czas doświadczonych ludzi.
Zarządzanie zmianą po stronie biznesu – komunikacja, materiały dla użytkowników, aktualizacja instrukcji, pilotaże na mniejszej grupie. Bez tego wdrożenie techniczne nie przełoży się na realne użycie.
„Shadow AI” – jeśli oficjalne rozwiązanie jest niewygodne, zespoły zaczną obchodzić je własnymi narzędziami. Późniejsze porządkowanie i standaryzacja również kosztują.
Przy szacowaniu kosztu „to-be” dodaj konserwatywną rezerwę (np. 20–30%) na te elementy, zwłaszcza przy pierwszym projekcie AI w IT.
Co sprawdzić przy kosztach „to-be”
Czy ktoś jest formalnie odpowiedzialny za monitoring jakości modelu (i ma na to czas w budżecie)?
Czy policzono koszt utrzymania integracji (API, konektory, pipeline’y danych) oraz ewentualnych zmian w innych systemach?
Czy w budżecie projektu jest pozycja na zarządzanie zmianą i szkolenia, nie tylko na development?
Czy oszacowano minimum 12–24 miesiące utrzymania po wdrożeniu produkcyjnym, a nie tylko sam projekt?
Jak mierzyć oszczędności czasu – i zamienić je na konkretne złotówki
Większość business case’ów AI zaczyna się od zdania „zaoszczędzimy X% czasu zespołu”. To dobry punkt wyjścia, ale sam w sobie nic nie znaczy. Trzeba przejść przez kilka kroków.
Krok 1: Ustal, jaki czas faktycznie się skróci Nie cały czas w procesie da się zautomatyzować. Policz tylko te czynności, które realnie przejmie AI (np. klasyfikacja zgłoszenia, propozycja odpowiedzi, wstępna analiza logów).
Krok 2: Ustal, czy to będzie redukcja czy uwolnienie Jeżeli plan zakłada zmniejszenie liczby FTE, oszczędność jest stosunkowo prosta do policzenia. Jeżeli czas ma być tylko „uwolniony”, trzeba wskazać, na co zostanie realnie przeznaczony (np. mniejsza liczba nadgodzin, mniejszy backlog zmian).
Krok 3: Przelicz na złotówki Pomnóż godziny, które przejmie AI, przez pełny koszt godziny pracy. Uwzględnij, że w pierwszych miesiącach zespół często pracuje wolniej (uczy się nowego rozwiązania), więc przyjmij stopniowe dojście do docelowej oszczędności.
Dobrym podejściem jest przyjęcie konserwatywnej ścieżki: 30–50% deklarowanej oszczędności w pierwszym kwartale, dopiero później pełny efekt.
Co sprawdzić przy oszczędnościach czasu
Czy zdefiniowano, jak zostanie wykorzystany uwolniony czas (redukcja etatów, mniej nadgodzin, nowe projekty)?
Czy przeliczono oszczędność czasu nie tylko dla L1, ale też dla L2/L3 i innych działów, jeśli AI zmniejszy liczbę eskalacji?
Czy uwzględniono okres adaptacji (learning curve) zespołu w pierwszych miesiącach?
Jak mierzyć korzyści z AI w procesach IT – poza samą automatyzacją
Oszczędność czasu to tylko jedna część obrazu. W wielu projektach AI kluczowe są efekty, które nie są widoczne od razu w headcouncie, ale mocno wpływają na koszty lub przychody firmy. Dobrze jest rozbić je na cztery grupy.
1. Jakość i stabilność usług IT
AI, które wspiera monitoring, obsługę incydentów czy deploymenty, może zmniejszyć liczbę awarii i skrócić czas ich trwania. Tu przydają się konkretne wskaźniki:
MTTR (Mean Time To Repair) – średni czas usunięcia incydentu.
Liczba incydentów krytycznych w miesiącu/kwartale.
Łączny czas niedostępności (downtime) kluczowych systemów.
Jeżeli masz dane, ile kosztuje godzina przestoju konkretnego systemu (np. sprzedaż online, call center), łatwo przeliczyć każdą minutę skróconego MTTR na pieniądze.
2. Wydajność procesów zmian i wdrożeń
AI w DevOps i CI/CD może:
zmniejszyć liczbę nieudanych buildów i rollbacków,
przyspieszyć przygotowanie testów,
zredukować liczbę błędów wychwytywanych dopiero na produkcji.
Kiedy policzysz, ile kosztuje jedno nieudane wdrożenie (czas zespołu, opóźnione funkcje, potencjalny wpływ na klientów), każda redukcja tego wolumenu staje się konkretną pozycją w kalkulacji korzyści.
3. Doświadczenie użytkownika (UX) i satysfakcja
W procesach takich jak Service Desk czy wsparcie użytkowników wewnętrznych/externalnych AI może podnieść jakość obsługi bez zwiększania zespołu. Korzyści można oprzeć na:
NPS / CSAT dla obsługi IT,
średnim czasie oczekiwania na reakcję,
liczbie zgłoszeń na użytkownika (jeśli AI lepiej rozwiązuje problemy przy pierwszym kontakcie).
Lepszy UX przekłada się pośrednio na mniej eskalacji, mniejsze obciążenie menedżerów i często na mniejszą rotację w zespołach frontowych.
4. Ryzyko i zgodność
AI w bezpieczeństwie, audycie czy zarządzaniu uprawnieniami (IAM) pozwala szybciej wyłapywać nietypowe zachowania i luki. Wskaźnikiem nie jest tu „oszczędzony czas analityka”, ale:
mniejsza liczba incydentów bezpieczeństwa,
mniejsza liczba niezgodności wykrytych przez audyt,
krótszy czas zamykania luk wykrytych w testach bezpieczeństwa.
Wycenę można oprzeć na historycznych kosztach incydentów (kary, koszty reakcji, przestoje) lub na benchmarkach branżowych, jeśli brak własnych danych.
Co sprawdzić przy korzyściach „miękkich”
Czy jesteś w stanie przeliczyć choć część „miękkich” efektów (mniej awarii, mniej kar, krótsze przestoje) na złotówki?
Czy dla wybranych procesów masz już bazowe KPI, żeby porównać stan sprzed i po wdrożeniu AI?
Czy w kalkulacji założyłeś ostrożne wartości (np. połowę oczekiwanego efektu), zamiast wpisywać maksymalne scenariusze?
Jak wycenić zmniejszenie ryzyka i przestojów
Ryzyko i przestoje to często największe, a jednocześnie najgorzej policzone elementy. Pomaga tu podejście probabilistyczne – wystarczy prosty model.
Krok 1: Zbierz historię Policz średnią liczbę incydentów krytycznych i poważnych awarii w ostatnich 12–24 miesiącach. Dla każdej kategorii spróbuj oszacować średni koszt pojedynczego przypadku (czas ludzi, downtime, kary).
Krok 2: Oszacuj wpływ AI Na podstawie POC, benchmarków dostawcy lub doświadczeń innych organizacji przyjmij konserwatywną redukcję (np. 10–20% mniej incydentów krytycznych lub skrócenie MTTR o 15–30%).
Krok 3: Policz roczną oszczędność Pomnóż średni koszt roczny incydentów przez procent redukcji. Otrzymasz wartość, która wchodzi do kolumny „korzyści finansowe”.
Przykład z praktyki: w jednej z firm AI w monitoringu logów nie wyeliminowało wszystkich awarii, ale skróciło czas dojścia do przyczyny z kilku godzin do kilkunastu minut w typowych incydentach. Samo to dało setki godzin mniej przestojów rocznie w systemach sprzedażowych.
Co sprawdzić przy wycenie ryzyka
Czy posiadasz choć przybliżone dane o kosztach awarii z ostatnich lat (czas, kary, utracone przychody)?
Czy redukcja ryzyka przypisana do AI nie jest podwójnie zaliczona razem z innymi projektami (np. migracją do chmury, modernizacją aplikacji)?
Czy założony procent redukcji nie jest nadmiernie optymistyczny względem rzeczywistych możliwości i jakości danych wejściowych?
Korzyści organizacyjne: rotacja, wiedza, morale
Nie wszystkie efekty da się szybko przeliczyć na złotówki, ale część da się przynajmniej oszacować. AI, które przejmuje najbardziej monotonne czynności, często zmniejsza wypalenie i rotację w zespołach operacyjnych.
Niższa rotacja – każdy odejście doświadczonej osoby to koszt rekrutacji, wdrożenia i niższej produktywności nowej osoby.
Lepsze wykorzystanie wiedzy seniorów – jeśli AI uczy się na bazie runbooków i ticketów, część wiedzy eksperckiej staje się dostępna dla L1 lub chatbotów. Seniorzy mniej gaszą pożary, więcej projektują rozwiązania.
Mniej „mikrozadań” i kontekstu – AI może przejąć część zadań typu: szukanie informacji, tłumaczenie logów, wstępne analizy. To zmniejsza ciągłe przerywanie pracy specjalistom.
Można przyjąć szacunkowy koszt jednej rekrutacji i wdrożenia (kilka miesięcy pensji + czas zespołu) i przemnożyć przez różnicę w rotacji, którą realnie spodziewasz się osiągnąć.
Co sprawdzić przy korzyściach organizacyjnych
Czy posiadasz dane o rotacji w zespołach IT z ostatnich 2–3 lat?
Czy AI realnie usuwa najbardziej frustrujące czynności, czy tylko dokładane są nowe zadania (np. walidacja AI)?
Czy korzyści organizacyjne są użyte jako uzupełnienie business case’u, a nie jego główny filar?
Prosty model ROI i TCO dla AI w IT – krok po kroku
Gdy zebrane są już dane o kosztach i korzyściach, można złożyć je w prosty model, zrozumiały zarówno dla IT, jak i dla finansów. Nie trzeba od razu budować skomplikowanych arkuszy – na start wystarczy kilka kolejnych kroków.
Krok 1: Zdefiniuj okres analizy i scenariusze
Dla rozwiązań AI w IT sensowny horyzont to zwykle 3–5 lat. Dobrze jest przygotować co najmniej dwa scenariusze:
Konserwatywny – niższe korzyści, wyższe koszty utrzymania, wolniejsze tempo adopcji.
Docelowy – realistyczne założenia, oparte na POC lub doświadczeniach innych organizacji.
Dla pierwszych wdrożeń lepiej bazować na konserwatywnym wariancie przy podejmowaniu decyzji.
Krok 2: Policz TCO – całkowity koszt posiadania AI
TCO (Total Cost of Ownership) pokazuje, ile naprawdę kosztuje rozwiązanie w całym cyklu życia. Struktura może wyglądać tak:
sprzęt / przygotowanie środowiska (jeśli wymagane),
pierwsze szkolenia i materiały.
Koszty powtarzalne roczne (OPEX):
licencje / subskrypcje / koszty chmury,
utrzymanie i rozwój (MLOps, support, monitoring),
koszty danych (przechowywanie logów, backupy, audyty).
W prostym modelu w arkuszu kalkulacyjnym rozbij te koszty w wierszach i rozłóż w kolumnach na kolejne lata. Otrzymasz sumę TCO dla całego okresu.
Co sprawdzić przy TCO
Czy koszty utrzymania (roczne) nie są niedoszacowane względem wdrożenia? W praktyce często sięgają 15–25% wartości projektu rocznie.
Co sprawdzić przy TCO (ciąg dalszy)
Czy uwzględniłeś koszt ludzi zaangażowanych w utrzymanie (FTE), a nie tylko faktury od dostawców?
Czy koszty danych (logi, storage, transfer) są policzone z perspektywą wzrostu wolumenu na kilka lat do przodu?
Czy w kalkulacji pojawiły się koszty zmian w procesach (aktualizacja procedur, audyty, certyfikacje), jeśli AI dotyka obszarów regulowanych?
Krok 3: Zbuduj roczny strumień korzyści
Żeby policzyć ROI, potrzebny jest nie tylko całkowity koszt, ale też rozkład korzyści w czasie. Tu przydaje się podejście etapowe.
Krok 1: Zacznij od „twardych” efektów Weź trzy główne kategorie:
oszczędność czasu pracy zespołów (po przeliczeniu na FTE),
mniej incydentów / krótsze przestoje (po przeliczeniu na złotówki),
mniej błędów i nieudanych wdrożeń (koszt jakości).
Dla każdej kategorii przypisz wartość roczną w zł oraz przewidywane tempo wzrostu efektu (np. w pierwszym roku 50% docelowego efektu, w drugim 80%, w trzecim 100%).
Krok 2: Dodaj efekty „miękkie”, ale ugruntowane W osobnej grupie umieść:
redukcję rotacji (jeśli masz dane HR),
lepsze KPI UX (np. mniej reklamacji, mniej eskalacji),
mniejsze ryzyko kar/regresów (jeśli możesz przyjąć rozsądne prawdopodobieństwo).
Te korzyści oznacz jako dodatkowe – niech nie stanowią większości całego strumienia.
Krok 3: Rozłóż efekty na lata W arkuszu dodaj kolumny „Rok 1”, „Rok 2”, „Rok 3…” i rozpisz, w jakim stopniu dany efekt ujawni się w danym roku. W pierwszym roku zwykle zakłada się niższe korzyści ze względu na czas wdrożenia i uczenia modeli.
W efekcie otrzymasz tabelę, w której na każdy rok przypada suma korzyści w złotówkach. To będzie baza do dalszych obliczeń.
Co sprawdzić przy strumieniu korzyści
Czy roczne wartości nie zakładają pełnego efektu od miesiąca 1, zanim AI zostanie realnie zaadoptowane w procesach?
Czy uniknąłeś podwójnego liczenia korzyści (np. ten sam skrócony przestój jako „mniej downtime” i „lepszy UX”)?
Czy przynajmniej część założeń jest zweryfikowana w POC/pilocie, a nie tylko na podstawie deklaracji dostawcy?
Krok 4: Policz ROI dla AI w IT
Mając TCO i roczne korzyści, można przejść do podstawowych wskaźników finansowych. Nie trzeba od razu sięgać po skomplikowane metody – zacznij od prostego ROI.
Krok 1: Określ całkowite korzyści w okresie Zsumuj wszystkie korzyści finansowe w horyzoncie analizy (np. 3 lata). Otrzymasz „Total Benefits”.
Krok 2: Zsumuj TCO dla tego samego okresu Dodaj wszystkie koszty CAPEX + OPEX z rozbiciem na lata (jeśli chcesz, możesz je też zdyskontować, ale na początek można pominąć dyskonto).
Krok 3: Zastosuj prosty wzór ROI
ROI = (Total Benefits − TCO) / TCO
Wynik wyrażasz w procentach. Jeżeli ROI wynosi 0,4, oznacza to 40% zwrotu w całym okresie.
W praktyce często przydaje się również wskaźnik payback period, czyli czas zwrotu inwestycji. Liczysz, w którym roku skumulowane korzyści przekraczają skumulowane koszty – to pokazuje, kiedy projekt zaczyna zarabiać na siebie.
Co sprawdzić przy ROI
Czy okres analizy nie jest sztucznie wydłużony tylko po to, by ROI „wyszło dobrze” (np. 8–10 lat dla narzędzia, które realnie będzie wymienione wcześniej)?
Czy porównujesz różnicę między stanem z AI i bez AI, a nie sam scenariusz z AI oderwany od bazy?
Czy payback period jest akceptowalny z perspektywy polityki inwestycyjnej firmy (często zakłada się maks. 3–4 lata zwrotu dla rozwiązań IT)?
Krok 5: Dodaj perspektywę alternatyw – „AI vs. inne rozwiązania”
AI nie jest jedyną drogą do poprawy wskaźników. W modelu finansowym dobrze jest porównać scenariusz z AI z innymi wariantami.
Oszacuj, jakie koszty i korzyści przyniósłby ten wariant w tym samym okresie.
Krok 2: Porównaj TCO i efekt końcowy Zobacz, czy AI daje:
mniejszy TCO przy podobnym efekcie, czy
znacznie większy efekt przy porównywalnym koszcie.
To porównanie często jest bardziej przekonujące dla finansów niż absolutna wartość ROI.
Krok 3: Ujmij ryzyka i zależności Do tabeli możesz dodać kolumnę z oceną ryzyka (np. niskie/średnie/wysokie) dla każdego scenariusza: dojrzałość technologii, zależność od dostawcy, ryzyko compliance.
Co sprawdzić przy porównywaniu scenariuszy
Czy scenariusz alternatywny nie jest sztucznie „podbity” lub „obniżony”, żeby AI wyglądało lepiej?
Czy uwzględniasz realne ograniczenia kadrowe (np. brak możliwości szybkiego zwiększenia zespołu L2) w scenariuszu bez AI?
Czy w wariancie AI policzyłeś koszt kompetencji (szkolenia, zatrudnienie MLOps/architekta AI), których w innych scenariuszach nie potrzebujesz?
Krok 6: Przeprowadź analizę wrażliwości – jak zmienia się ROI
Model finansowy wdrożenia AI jest z natury obarczony niepewnością. Zamiast udawać, że liczby są dokładne co do złotówki, lepiej pokazać, jak zmienia się ROI przy różnych założeniach.
Krok 1: Wybierz 3–4 kluczowe parametry Najczęściej są to:
stopień redukcji czasu pracy (np. 10%, 20%, 30%),
stopień redukcji incydentów/downtime,
koszt licencji / chmury,
tempo adopcji (procent zadań faktycznie przejętych przez AI).
opłaca się tylko przy bardzo optymistycznych założeniach.
To ważny sygnał przy decyzji, czy wchodzić w pełne wdrożenie, czy zatrzymać się na pilocie.
Co sprawdzić przy analizie wrażliwości
Czy wybrane parametry rzeczywiście mają największy wpływ na ROI, czy po prostu są najłatwiejsze do modyfikacji?
Czy pesymistyczny scenariusz nie jest fikcją (np. -5% korzyści zamiast -50%), tylko realnym „co jeśli się nie uda”?
Czy wyniki analizy wrażliwości są omówione z właścicielami procesów, a nie przygotowane wyłącznie przez IT lub wyłącznie przez finanse?
Krok 7: Uporządkuj założenia i dane wejściowe
Nawet najlepiej policzony model traci sens, jeżeli po kilku miesiącach nikt nie pamięta, skąd wzięły się poszczególne liczby. Dlatego do modelu ROI/TCO potrzebny jest „spis założeń”.
Krok 1: Zbierz źródła danych Przy każdej kluczowej liczbie (stawka godzinowa, liczba incydentów, koszt downtime) zapisz, skąd pochodzi:
raport z systemu ITSM / monitoringu,
dane z controllingu,
szacunek ekspercki – jeśli nie ma twardych danych.
Krok 2: Oznacz poziom pewności Prosty kod (np. A/B/C) wystarczy:
A – dane z systemów, wysokie zaufanie,
B – dane mieszane, część szacunkowa,
C – głównie szacunki ekspertów.
Dzięki temu rozmówcy wiedzą, gdzie model jest solidny, a gdzie bardziej orientacyjny.
Krok 3: Ustal cykl aktualizacji Określ, jak często model będzie przeliczany (np. raz na kwartał w pierwszym roku wdrożenia). Po kilku miesiącach można zastąpić część szacunków rzeczywistymi danymi operacyjnymi.
Co sprawdzić przy zarządzaniu założeniami
Czy wszystkie kluczowe liczby mają przypisane źródło i właściciela (osobę/rolę, która może je zaktualizować)?
Czy w modelu odróżniasz dane twarde od szacunków, czy wszystko jest wrzucone do jednego worka?
Czy proces aktualizacji modelu jest powiązany z przeglądami KPI IT/finansów, a nie zostawiony „na kiedyś”?
Krok 8: Połącz model finansowy z roadmapą AI w IT
Model ROI/TCO dla pojedynczego wdrożenia to dopiero początek. W praktyce organizacje budują stopniowo portfel projektów AI w IT – z różnym poziomem ryzyka i zwrotu.
Krok 1: Skategoryzuj inicjatywy Możesz użyć prostego podziału:
inicjatywy oszczędnościowe (redukcja kosztów operacyjnych),
inicjatywy jakościowe (stabilność, bezpieczeństwo, SLA),
inicjatywy rozwojowe (nowe możliwości, wsparcie innowacji biznesowych).
Dla każdej inicjatywy przygotuj skrócony model ROI/TCO według tej samej struktury.
W pierwszej kolejności zwykle wybiera się połączenie: średnie ryzyko, wysokie korzyści, dobra mierzalność.
Krok 3: Zaplanuj fazowanie inwestycji Zamiast jednego dużego projektu, zaplanuj kilka kroków:
pilotaż w wybranym procesie,
rozszerzenie na kolejne zespoły/regiony,
konsolidacja i optymalizacja utrzymania.
Do każdego etapu możesz przypisać oddzielny mini‑business case z aktualizacją liczb.
Co sprawdzić przy łączeniu z roadmapą
Czy poszczególne projekty AI w IT nie konkurują o te same zasoby kluczowe (dane, zespoły, budżet), co czyni plan nierealnym?
Czy dla każdego etapu masz jasne kryteria „go / no‑go” oparte na KPI i liczbach, a nie tylko na ekscytacji technologią?
Czy roadmapa AI w IT jest zszyta z roadmapą transformacji całego IT (modernizacja, chmura, bezpieczeństwo), a nie żyje swoim życiem?
Najczęściej zadawane pytania (FAQ)
Jak policzyć, czy wdrożenie AI w IT jest opłacalne?
Krok 1: nazwij decyzję biznesową jednym zdaniem, np. „Czy opłaca się wdrożyć AI do klasyfikacji zgłoszeń w Service Desk L1 w ciągu 12 miesięcy?”. Bez tego nie da się sensownie liczyć kosztów i korzyści.
Krok 2: policz obecny koszt procesu (status quo): roboczogodziny zespołu, nadgodziny, kary za SLA, koszty incydentów krytycznych, utracone przychody przy przestojach. Krok 3: oszacuj, ile z tego realnie może zdjąć AI (np. skrócenie czasu obsługi zgłoszenia o 30%, zmniejszenie liczby błędów, mniej incydentów). Do tego dodaj pełne TCO AI: licencje, infrastrukturę, integracje, utrzymanie i rozwój modelu.
Co sprawdzić: czy masz policzony koszt obecnego procesu, czy uwzględniasz zarówno oszczędności, jak i koszty wdrożenia oraz utrzymania AI w horyzoncie minimum 2–3 lat.
Jakie procesy IT najlepiej nadają się do wdrożenia AI?
Pierwsze sito to trzy proste kryteria: powtarzalność zadań, wysoki wolumen zdarzeń i akceptowalny koszt błędu. Dobrzy kandydaci to np. Service Desk L1 (reset haseł, proste problemy użytkowników), klasyfikacja i routing zgłoszeń, analiza logów pod kątem anomalii, generowanie dokumentacji technicznej.
Przykładowy proces: w Service Desk L1 codziennie spływa kilkaset podobnych zgłoszeń o dostępie do systemu. AI może je automatycznie klasyfikować i podpowiadać gotowe odpowiedzi agentom, którzy tylko zatwierdzają akcję.
Krok 1: spisz wszystkie procesy w obszarach: Service Desk, utrzymanie, DevOps/CI/CD, testy, bezpieczeństwo, dokumentacja.
Krok 2: przy każdym oceń powtarzalność, wolumen i koszt błędu w skali 1–3.
Krok 3: wybierz te z wysoką powtarzalnością i wolumenem, ale średnim lub niskim kosztem błędu.
Co sprawdzić: czy masz listę procesów z oceną 1–3 dla każdego kryterium oraz wyłonione 1–3 procesy z najwyższym potencjałem.
Jakie scenariusze porównać przy analizie ROI z AI w IT?
Minimum to trzy scenariusze: scenariusz 0 – status quo (nic nie zmieniasz przez 2–3 lata), scenariusz 1 – małe, kontrolowane wdrożenie AI w jednym procesie (np. tylko klasyfikacja zgłoszeń L1), scenariusz 2 – ambitniejsze wdrożenie na kilku procesach lub większej skali.
W każdym scenariuszu policz: koszty (licencje, infrastruktura, wdrożenie, utrzymanie, szkolenia), oszczędności (mniej roboczogodzin, mniej kar SLA, mniej incydentów krytycznych) oraz ryzyka (np. spadek jakości, opór zespołu, zależność od dostawcy). Różnica kosztów i korzyści między scenariuszem 0 a scenariuszami z AI pokaże realny efekt finansowy.
Co sprawdzić: czy scenariusz 0 jest dobrze opisany liczbowo, a scenariusze 1 i 2 mają jasno zdefiniowany zakres, koszty i spodziewane efekty, zamiast ogólnych haseł „oszczędzimy czas”.
Jak krok po kroku zorganizować warsztat mapujący procesy pod AI?
Krok 1: zbierz kluczowe osoby z obszarów Service Desk, utrzymania, DevOps/CI/CD, testów, bezpieczeństwa i architektury – plus kogoś z finansów lub controllingu. Krok 2: na tablicy (fizycznej lub Miro) wypisz wszystkie główne procesy IT, bez oceniania ich przydatności pod AI.
Krok 3: przy każdym procesie dopisz: szacunkowy wolumen zdarzeń miesięcznie, średni czas pracy człowieka na zdarzenie oraz główne narzędzia. Następnie przejdź prostą kwalifikację według powtarzalności, wolumenu i kosztu błędu, wybierz top 5–10 procesów i dla nich doprecyzuj dane ilościowe (FTE, SLA, liczba incydentów krytycznych).
Co sprawdzić: czy na warsztacie są osoby faktycznie wykonujące procesy, czy masz oszacowane wolumeny i czasy oraz czy na końcu wybrałeś maksymalnie 1–3 procesy do szczegółowej analizy opłacalności.
Jakich błędów unikać przy liczeniu opłacalności AI w IT?
Najczęstsze błędy to: brak jasno zdefiniowanej decyzji („co chcemy rozstrzygnąć”), pomijanie scenariusza „nic nie robimy”, liczenie tylko oszczędności bez pełnych kosztów (wdrożenia, utrzymania, rozwoju modelu) oraz zakładanie zbyt optymistycznych efektów („AI zdejmie 80% pracy zespołu”).
Częsty problem to także wybór procesu o wysokim koszcie błędu (np. krytyczne decyzje bezpieczeństwa) jako pierwszego wdrożenia end-to-end. W takim przypadku lepiej, by AI wspierało człowieka (rekomendacje, podpowiedzi), zamiast podejmować decyzje automatycznie.
Co sprawdzić: czy w business case uwzględniasz pełne TCO, realne ograniczenia jakości modeli oraz rolę człowieka w procesie, a nie zakładasz „magicznej automatyzacji wszystkiego”.
Jak przygotować dane i zespół do wdrożenia AI w procesach IT?
Krok 1: sprawdź, czy masz wystarczająco dużo danych historycznych dla wybranych procesów (zgłoszenia, logi, incydenty, wyniki testów) oraz czy są one w miarę spójne i opisane. Krok 2: zidentyfikuj właściciela procesu i osobę odpowiedzialną za jakość danych – bez tego projekty AI szybko się rozsypują.
Krok 3: przygotuj zespół: pokaż, jaki problem biznesowy ma rozwiązać AI (np. skrócenie czasu obsługi, zmniejszenie liczby incydentów), jak zmieni się ich praca i gdzie człowiek pozostaje w roli decydującej. Dobry, krótki PoC na jednym procesie jest często najlepszym sposobem na zbudowanie zaufania i zebra-nie realnych danych do dalszej analizy opłacalności.
Co sprawdzić: czy wybrany proces ma sensowną historię danych, czy jest jasno wskazany właściciel procesu i danych oraz czy zespół rozumie, że AI ma ich odciążyć, a nie „zastąpić bez planu”.
Najważniejsze wnioski
Krok 1: zanim pojawi się technologia, trzeba policzyć biznes – każde wdrożenie AI w IT musi mieć jasno określone koszty, spodziewane oszczędności lub dodatkową wartość oraz horyzont zwrotu, inaczej staje się drogą ciekawostką bez obrony w Excelu.
Krok 2: decyzja musi być konkretna – trzeba jednym zdaniem nazwać, co chcemy rozstrzygnąć (np. „czy opłaca się automatyzować klasyfikację zgłoszeń L1 w 12 miesięcy”), bo od tego zależy, jakie dane zbierzemy, jak policzymy TCO i jak skonstruujemy business case.
Krok 3: zawsze porównuj scenariusze – status quo, małe wdrożenie AI i szerszy rollout; dopiero zestawienie kosztów, ryzyk i efektów dla tych trzech wariantów pozwala sensownie rozmawiać z zarządem, zamiast opierać się na hasłach „oszczędzimy 20% czasu zespołu”.
AI ma największy sens tam, gdzie są powtarzalne zadania, duży wolumen i dobre dane historyczne – typowo w obszarach utrzymania, rozwoju, bezpieczeństwa i wsparcia użytkowników (np. Service Desk, monitoring, testy, SOC, chatboty do pytań o systemy).
Kluczowy błąd to wybieranie use case’ów „na czuja” – najpierw trzeba zrobić szybkie mapowanie procesów IT: spisać główne procesy, oszacować liczbę zdarzeń, czas pracy na zdarzenie i używane narzędzia, żeby zobaczyć, gdzie realnie leży największy potencjał na oszczędności.
