Business case AI bez fikcyjnych oszczędności

Uczciwy business case dla AI pokazuje przedział wyników, a nie jedną obiecaną stopę zwrotu. Najpierw policz koszt obecnej pracy, następnie wpływ zmiany na cały proces, a na końcu koszt wdrożenia i utrzymania. Oddziel korzyści potwierdzone od tych, które pojawią się tylko wtedy, gdy firma przeznaczy odzyskany czas na dodatkową pracę.

Szerszy sposób porównywania korzyści, kosztu i ryzyka opisuje przewodnik po strategii i opłacalności AI.

Punkt wyjścia: jedna jednostka pracy

Wybierz sprawę, którą da się policzyć od początku do końca: ofertę, reklamację lub zamówienie. Zmierz liczbę spraw w miesiącu, czas pracy, poprawki, opóźnienia i koszt obsługi wyjątku. Nie buduj modelu z średniej „oszczędności czasu pracownika”, jeśli nikt nie mierzy, ile spraw człowiek rzeczywiście zamyka. Koszt wyjątków jest często ważniejszy niż oszczędność na najprostszych przypadkach.

Załóżmy dydaktycznie, że przygotowanie jednej oferty zajmuje 50 minut, a AI może skrócić część redakcyjną o 15. Jeśli kontrola danych i poprawek zajmuje dodatkowe 10 minut, realny zysk to około 5 minut na ofertę. Nie oznacza to automatycznie pięciu minut wypłaty mniej. Można mówić o dodatkowej przepustowości, krótszym terminie lub mniejszej liczbie nadgodzin, jeżeli te skutki rzeczywiście wystąpią.

Trzy scenariusze, te same założenia

W ostrożnym scenariuszu uwzględnij wolniejszą adopcję, większy nakład kontroli i brak zmiany wolumenu sprzedaży. W bazowym użyj wyników z próbki rzeczywistych spraw oraz planowanego tempa wdrożenia. W ambitnym pokaż korzyść możliwą przy lepszej jakości danych i większej skali, ale nazwij warunki jej osiągnięcia. Wszystkie trzy scenariusze muszą zawierać koszt integracji, danych, testów, szkoleń, pracy nadzorcy i miesięcznego działania.

Jeśli projekt ma zmniejszyć liczbę błędów, pokaż osobno, jak mierzono błędy przed zmianą. Jeśli ma zwiększyć przychód, wykaż drogę od krótszej oferty do rzeczywiście wygranych zamówień. Nie dodawaj obu korzyści na podstawie tej samej grupy klientów bez sprawdzenia, czy nie liczysz jej dwa razy.

Ustal, które założenie najbardziej zmienia wynik

Nie wszystkie niepewności są równie ważne. W jednym projekcie wynik zależy głównie od liczby spraw. W innym — od czasu ręcznej korekty albo od tego, czy integracja z systemem źródłowym wymaga dużych zmian. Zrób prostą próbę wrażliwości: zmień kolejno jedno założenie i zobacz, czy inwestycja nadal ma sens. Jeśli niewielka zmiana czasu kontroli odwraca wynik, właśnie ten parametr trzeba zmierzyć w pilocie najdokładniej.

Warto też pokazać, co stanie się przy mniejszym wolumenie. Rozwiązanie może mieć stały koszt utrzymania, więc przy sezonowym spadku liczby spraw koszt jednostkowy rośnie. Nie ukrywaj tej zależności w rocznej średniej. Zarząd powinien znać próg, poniżej którego projekt przestaje być opłacalny, oraz możliwość ograniczenia usługi bez utraty danych.

Przedstaw liczby wraz z pochodzeniem: pomiar z systemu, próbka ręczna, oferta dostawcy albo założenie kierownika. Wtedy po pilocie łatwo widać, co się potwierdziło. Business case nie musi przewidzieć wszystkiego; musi wskazać, które dowody zmienią decyzję.

Decyzja po próbie

Ustal z góry, jaki wynik byłby wystarczający w scenariuszu ostrożnym. Jeśli projekt opłaca się wyłącznie w ambitnym, traktuj go jak eksperyment, nie pewną inwestycję. Kryteria sukcesu pilotażu powinny potwierdzić kluczowe założenia przed zwiększeniem budżetu. Jeśli zarząd nie potrafi uzgodnić jednostki pracy i właściciela danych, zacznij od prezentacji diagnostycznej.