Firma chce automatycznie odczytywać zamówienia przychodzące pocztą elektroniczną i zapisywać je w ERP. Otrzymuje wycenę budowy aplikacji oraz prognozę kosztu używania modelu AI. Obie liczby wyglądają rozsądnie. Czy na tej podstawie można zatwierdzić budżet?
Jeszcze nie. W wycenie może brakować opłat za odczytywanie załączników, dostęp do firmowych danych, integrację z ERP, działającą przez całą dobę infrastrukturę i obsługę zamówień, z którymi system sobie nie poradzi. Część tych kosztów pojawi się tylko przy określonej architekturze. Inne zaczną rosnąć dopiero po zwiększeniu liczby zamówień.
Koszt modelu można policzyć poprawnie i nadal znacząco pomylić się w budżecie całego rozwiązania. Dlatego przed wdrożeniem trzeba wiedzieć nie tylko, ile kosztuje jedna operacja AI, lecz także jakie usługi i działania są potrzebne do zakończenia sprawy biznesowej.
Budowa, użytkowanie i późniejsze zmiany to trzy różne koszty
Pierwszy budżet obejmuje przygotowanie procesu, danych, aplikacji i integracji, a także testy oraz uruchomienie. Drugi dotyczy codziennej pracy systemu: przetwarzania spraw, utrzymywania usług i angażowania pracowników. Trzeci to wydatki na zmiany po uruchomieniu, na przykład dostosowanie integracji po aktualizacji ERP. Takie prace nie muszą występować co miesiąc, ale w perspektywie kilku lat nie można zakładać, że system pozostanie niezmienny.
Trzeba też rozróżnić nowy wydatek gotówkowy od kosztu wykorzystania istniejących zasobów. Jeśli firmowa platforma pozwala uruchomić nową automatyzację bez dopłaty, nie należy przedstawiać całego opłacanego wcześniej abonamentu jako nowego wydatku. Przy liczeniu pełnego kosztu systemu można jednak przypisać mu uzasadnioną część wspólnych zasobów. Podobnie czas pracy obecnego pracownika ma wartość ekonomiczną, choć jego zaangażowanie w nowy proces nie musi zwiększać wydatków na wynagrodzenia. To ta sama różnica między godzinami a pieniędzmi, o której była mowa w części o business case.
Skąd konkretnie biorą się koszty systemu AI?
Jedno zamówienie może oznaczać kilka płatnych operacji
Prosty rachunek zakłada czasem, że jedno zamówienie to jedno zapytanie do modelu. Tymczasem wiadomość może zawierać PDF ze skanem, tabelę produktów i dopisek klienta zmieniający warunki dostawy. System może osobno odczytać załącznik, wydobyć pozycje zamówienia, sprawdzić niejednoznaczne dane i przygotować wynik do zapisania. Jeśli korzysta z płatnego rozpoznawania dokumentów, dochodzi również opłata za przetworzone strony. Nie każda architektura wymaga osobnej usługi OCR.
Podczas wdrożenia płacimy za zaprojektowanie tych kroków i sprawdzenie, które są rzeczywiście potrzebne. Podczas użytkowania koszt może zależeć od liczby wywołań, długości wiadomości, liczby stron i rodzaju użytego modelu. Jeśli dokumenty stają się dłuższe, miesięczny rachunek może wzrosnąć nawet bez zwiększenia liczby zamówień.
Dlatego w wycenie warto zobaczyć koszt prostego zamówienia, zamówienia z obszernym załącznikiem oraz sprawy wymagającej dodatkowej analizy. Jedna średnia stawka za „obsługę wiadomości” może ukryć tę różnicę.
Osobna baza wiedzy może kosztować nawet przy małej liczbie zapytań
Jeśli system ma tylko rozpoznać numer zamówienia, nie potrzebuje rozbudowanej bazy wiedzy. Jeżeli musi porównywać pozycje zamówienia z aktualnym katalogiem produktów, może wystarczyć odczyt danych bezpośrednio z ERP. Osobna wyszukiwarka i indeks mogą być potrzebne wtedy, gdy system przeszukuje nieustrukturyzowane dokumenty, na przykład procedury, opisy produktów lub umowy. Taki indeks trzeba również aktualizować.
Na etapie wdrożenia płacimy za przygotowanie dokumentów, zbudowanie indeksu i ustalenie zasad jego aktualizacji. Podczas użytkowania mogą pojawić się koszty przechowywania indeksu, wykonywania zapytań i zasobów potrzebnych do działania wyszukiwarki. Niektóre usługi naliczają opłaty również za utrzymywaną pojemność, więc koszt może powstawać nawet przy niewielkiej liczbie wyszukiwań.
W kosztorysie należy sprawdzić trzy rzeczy: ile dokumentów będzie przechowywanych, jak często trzeba je aktualizować i czy wyszukiwarka pobiera opłatę za zapytania, za utrzymywane zasoby czy za oba te elementy. Najważniejsza decyzja zapada jednak wcześniej: czy w ogóle potrzebujemy osobnej usługi wyszukiwania, skoro część danych jest już dostępna w ERP?
Integracja z ERP to nie tylko napisanie połączenia
Automatyzacja zamówień musi sprawdzić, czy klient i produkt istnieją w ERP, ustalić właściwe identyfikatory oraz bezpiecznie zapisać wynik. Wdrożenie obejmuje więc uzgodnienie danych, uprawnień, walidacji i postępowania w przypadku nieudanego zapisu. Samo wywołanie API zwykle nie rozwiązuje tych problemów.
Na starcie kosztuje zbudowanie i przetestowanie integracji. Po uruchomieniu mogą dochodzić opłaty za korzystanie z API, płatne konektory, dodatkowe moduły lub licencje. Sam fakt, że firma ma dostęp do ERP, nie gwarantuje, że obecna licencja pozwala także na automatyczne odczytywanie i zapisywanie danych przez zewnętrzną aplikację. Czasami trzeba dokupić moduł integracyjny, przejść na wyższy pakiet lub opłacić dodatkowy dostęp.
Przed wyborem sposobu integracji warto sprawdzić zapisy umowy i limity: czy API jest objęte licencją, czy konektor jest płatny, czy są ograniczenia liczby wywołań i jak zmieni się opłata, kiedy automatyzacja zacznie obsługiwać więcej zamówień. Nie każde ERP wymaga dopłat, ale pominięcie tego sprawdzenia może zmienić opłacalność wybranego rozwiązania.
Do kosztorysu powinien też trafić zakres późniejszych zmian integracji. Jeżeli dostawca ERP zmieni interfejs lub firma przebuduje kartotekę produktów, połączenie może wymagać dostosowania mimo braku zmian w samym AI.
Za gotowość do pracy czasem płacisz nawet bez zamówień
System przetwarzający zamówienia raz na godzinę ma inne wymagania niż rozwiązanie, które musi odpowiedzieć natychmiast, o każdej porze i przy dużym ruchu. W drugim przypadku mogą być potrzebne stale uruchomione zasoby, większa przepustowość lub rozwiązania awaryjne.
Podczas wdrożenia kosztuje dobór i konfiguracja środowiska oraz ustalenie wymaganej dostępności. Później część usług rozlicza się za faktycznie wykonane operacje, a część za czas, przez jaki zasoby są uruchomione lub zarezerwowane. W tym drugim modelu firma może płacić za serwer czy określoną przepustowość również w godzinach bez zamówień. Czasami system uruchamia się na ustalony okres i opłata za ten czas nie zależy od liczby obsłużonych w nim żądań.
To bezpośrednio zmienia koszt jednego zamówienia. Jeżeli te same zasoby wystarczają do obsłużenia zarówno 100, jak i 1000 zamówień miesięcznie, stała część kosztu przypadająca na zamówienie przy większym wolumenie jest dziesięciokrotnie niższa. Przy małym ruchu może być natomiast wysoka, mimo że pojedyncze wywołanie modelu kosztuje niewiele. Gdy obciążenie przekroczy dostępną pojemność, pojawi się kolejny wydatek na zwiększenie zasobów.
Przy wycenie należy określić godziny działania, spodziewane szczyty obciążenia i akceptowalny czas odpowiedzi. Dodatkowe wymagania dotyczące dostępności, regionu przetwarzania danych lub infrastruktury zapasowej mogą zwiększyć koszt niezależnie od liczby spraw. Nie ma powodu płacić za parametry, których proces nie potrzebuje, ale nie można też projektować krytycznej usługi tak, jakby była okazjonalnym eksperymentem.
Sprawy przekazane pracownikom nadal kosztują
System może prawidłowo odczytywać większość zamówień, a pozostałe przekazywać człowiekowi. Przy wycenie nie wystarczy wtedy podać kosztów modelu ani samego odsetka automatyzacji. Trzeba oszacować również czas rozwiązywania wyjątków.
Załóżmy hipotetycznie 3000 zamówień miesięcznie. Jeśli 10% wymaga ręcznej obsługi trwającej średnio 8 minut, daje to 40 godzin pracy miesięcznie. Przy przyjętym do obliczenia koszcie czasu 80 zł za godzinę jest to 3200 zł wykorzystanej pracy. Nie musi oznaczać zatrudnienia nowej osoby lub wyższej listy płac. Oznacza jednak, że pracownicy nie przeznaczą tych 40 godzin na inne zadania.
Podczas wdrożenia firma musi ustalić, kto będzie odbierał wyjątki i jakie informacje powinien otrzymać. Podczas użytkowania koszt zależy od liczby takich spraw i czasu ich obsługi. Jeśli liczba zamówień się podwoi, a udział wyjątków nie spadnie, zapotrzebowanie na pracę może wzrosnąć podobnie. Gdy istniejący zespół wyczerpie dostępność, pojawi się też możliwość nowego wydatku na zatrudnienie lub outsourcing.
Sprawdzanie działania systemu nie kończy się po testach odbiorowych
Gdy klient zgłasza nieprawidłowe zamówienie, firma musi ustalić, co system odczytał, jakie dane pobrał i co zapisał w ERP. Dlatego już podczas implementacji trzeba przewidzieć odpowiednie zapisy działania, identyfikację spraw i sposób wykrywania problemów.
Podczas użytkowania koszty mogą obejmować gromadzenie i przechowywanie zapisów działania, alerty, analizę incydentów oraz ponowne sprawdzanie jakości po istotnych zmianach. U dostawców chmurowych część opłat zależy od ilości przetwarzanych logów, a niekiedy także od czasu ich przechowywania. Dostępne bywają bezpłatne limity i funkcje wliczone w inne usługi. Nie można więc założyć, że każdy zapis generuje dodatkową opłatę, ale bardzo szczegółowe logowanie i długa retencja mogą podnieść rachunek.
W wycenie trzeba więc określić, jakie informacje naprawdę będą zapisywane, przez jak długo i kto ma analizować problemy. Sama pozycja „monitoring” bez zakresu i odpowiedzialności niczego nie wyjaśnia. Jak taki nadzór wygląda w praktyce, opisuje część o monitorowaniu systemu i reagowaniu na błędy AI.
System wymaga zmian również wtedy, gdy firma nie zamawia nowych funkcji
Model AI, na którym zbudowano rozwiązanie, niekoniecznie będzie dostępny przez całe jego życie. Dostawcy publikują harmonogramy wycofywania starszych modeli, co może wymagać zmiany konfiguracji, aktualizacji aplikacji i ponownych testów. Nawet jeśli firma nie zamówi żadnej nowej funkcji, musi sprawdzić, czy nowy model nadal poprawnie obsługuje jej przypadki biznesowe.
Podczas wdrożenia warto zadbać o możliwość wymiany modelu i aktualizowania połączeń bez przebudowy całej aplikacji. Później mogą wystąpić nieregularne koszty dostosowania, testów i wdrożenia poprawionej wersji. Podobne konsekwencje mają zmiany w ERP oraz nowe wymagania dotyczące danych i dostępu. Nie jest to argument za naliczaniem dowolnego miesięcznego procentu „na utrzymanie”. W kosztorysie powinien jednak pojawić się zakres regularnego wsparcia i osobna informacja, jak rozliczane będą większe zmiany.
Tańsza implementacja może zwiększyć późniejszy rachunek
Rozważmy dwa sposoby obsługi tych samych zamówień. W prostszym rozwiązaniu każde zamówienie, także łatwe i powtarzalne, trafia do kosztownego modelu z dużą porcją danych. Drugi wariant wymaga więcej pracy przy budowie: wstępnie rozpoznaje proste sprawy, wykorzystuje reguły do walidacji i uruchamia droższą analizę tylko wtedy, gdy jest potrzebna. Może dzięki temu ograniczyć opłaty za modele i pracę przy wyjątkach. Musimy jednak sprawdzić, czy dodatkowe mechanizmy same nie będą droższe od uzyskanych oszczędności. O tym, które kroki procesu w ogóle potrzebują modelu, była część o doborze technologii.
Załóżmy wyłącznie dla ilustracji, że pierwszy wariant kosztuje 50 tys. zł przy wdrożeniu i 10 tys. zł miesięcznie podczas użytkowania, a drugi 100 tys. zł przy wdrożeniu i 6 tys. zł miesięcznie. Zakładamy tę samą jakość obsługi, porównywalny wolumen i uwzględnienie tych samych kategorii wydatków. Przy takich warunkach drugi wariant staje się łącznie tańszy po 12,5 miesiąca. Jeżeli jego rzeczywista miesięczna przewaga wyniesie tylko 2 tys. zł, dodatkowy nakład zwróci się dopiero po 25 miesiącach. Są to liczby modelowe, nie ceny rynkowe ani wyniki realnych wdrożeń.
Oszczędności wynikają z konkretnych decyzji projektowych i skali wykorzystania, a nie z samego faktu, że zbudowano droższy system.
Jak koszty zmienią się wraz z liczbą zamówień?
Opłata za stale uruchomioną usługę może pozostać taka sama przy 500 i 5000 zamówień, dopóki wystarcza jej pojemność. Płatne przetwarzanie stron rośnie z ich liczbą, a ręczna obsługa z liczbą i trudnością wyjątków. Po przekroczeniu określonego obciążenia może być potrzebny wyższy plan, dodatkowa infrastruktura albo kolejna osoba. To wzrost skokowy.
Dlatego scenariusz „dziesięć razy więcej zamówień” nie oznacza automatycznie dziesięć razy większego rachunku. Trzeba też znać wielkość dokumentów, udział nietypowych spraw, godziny szczytu i wymagania dotyczące czasu odpowiedzi. Wycena oparta wyłącznie na średniej liczbie zamówień nie pokazuje, co naprawdę uruchamia dodatkowe opłaty.
Co powinno znaleźć się w kosztorysie przed podpisaniem umowy?
CEO nie musi samodzielnie dobierać usług chmurowych ani obliczać cen tokenów. Powinien natomiast oczekiwać od zespołu lub wykonawcy zestawienia, które jasno odpowiada na kilka pytań:
- Co zapłacimy przy wdrożeniu? Osobno prace dostawcy, zakupy usług i czas osób po stronie firmy.
- Ile zapłacimy za działanie systemu? Osobno opłaty stałe, zależne od liczby i złożoności spraw, koszt pracy ludzi oraz wydatki pojawiające się dopiero po przekroczeniu określonej skali.
- Które pozycje naprawdę są nowym kosztem? Co mieści się już w licencjach i zasobach firmy, a co wymaga dopłaty? Jak unikniemy podwójnego liczenia?
- Co wyłączono z oferty i jakie zmiany będą rozliczane dodatkowo? Dotyczy to szczególnie integracji, dostosowań po zmianach modeli i aktualizacji danych.
- Jak zmieni się budżet w ciągu 12 i 24 miesięcy? Potrzebne są scenariusze dla małego, oczekiwanego i dużego wolumenu, z uwzględnieniem różnej złożoności spraw.
Pomocną miarą będzie koszt poprawnie zakończonego zamówienia, obejmujący odpowiedni udział kosztów technicznych i pracy ludzi. Trzeba ustalić, czy do zakończonych spraw zaliczamy również te obsłużone z pomocą pracownika. W pilotażu można zmierzyć liczbę operacji i czas pracy na sprawę, a następnie poprawić prognozę. Osobno należy oszacować koszty dużych szczytów obciążenia, których mały pilot może nie ujawnić.
Dobra wycena nie przewidzi każdej przyszłej faktury. Powinna jednak wskazywać, za co firma płaci na starcie, za co będzie płacić później, co zwiększy rachunek i których wydatków jeszcze nie oszacowano. Dopiero wtedy można porównywać oferty na wykonanie tego samego procesu, a nie tylko ceny modeli i budowy aplikacji.