Agent AI podłączony do ERP – co faktycznie potrafi, gdzie zawodzi i ile kosztuje bałagan w danych

Rozmowa o agencie AI w ERP staje się konkretna dopiero wtedy, gdy padnie pytanie o zakres uprawnień. Nie chodzi o to, „czy podłączamy agenta do ERP”, tylko o to, co dokładnie wolno mu zrobić z rekordem. Trzy poziomy – odczyt, propozycja, zapis – to trzy różne projekty pod jedną nazwą.

Poziom pierwszy to odczyt. Agent odpytuje ERP i odpowiada zdaniami zamiast tabelą: jaki jest status zlecenia, ile zostało na magazynie, kiedy wystawiono ostatnią fakturę temu kontrahentowi. Ryzyko jest ograniczone do ujawnienia danych osobie, która nie powinna ich widzieć – więc kluczowa jest tu warstwa uprawnień, nie logika biznesowa. To najtańszy i najszybszy wariant startowy.

Poziom drugi to propozycja. Agent przygotowuje dokument, ale go nie zatwierdza: projekt zamówienia, projekt korekty, wstępne dopasowanie płatności do faktur. Człowiek widzi gotowy rekord, sprawdza i akceptuje jednym kliknięciem. Ten poziom daje zwykle najlepszy stosunek efektu do ryzyka, bo skraca pracę o 60–80% przy zachowaniu kontroli nad każdym zapisem.

Poziom trzeci to zapis. Agent samodzielnie zmienia stan w systemie – zakłada kontrahenta, zmienia status zlecenia, generuje dokument magazynowy. Tu kończy się integracja, a zaczyna projekt inżynieryjny: potrzebne są limity, walidacja przed zapisem, log operacji, ścieżka wycofania i test regresji przy każdej zmianie API systemu źródłowego. Większość wdrożeń, które sprawiają kłopoty, przeskoczyła z poziomu pierwszego na trzeci, pomijając drugi.

Pierwszy: przyjęcie zamówienia od klienta. Zamówienie przychodzi mailem, w PDF-ie albo w formacie arkusza – za każdym razem innym. Agent czyta dokument, dopasowuje pozycje do indeksów w ERP, oznacza to, czego nie potrafi dopasować jednoznacznie, i wystawia projekt zamówienia. Handlowiec zatwierdza zamiast przepisywać. Największa oszczędność powstaje nie na wpisywaniu, tylko na wyszukiwaniu właściwego indeksu.

Drugi: statusy i terminy. Pytania w rodzaju „co z dostawą dla klienta X” pochłaniają w firmach handlowych i produkcyjnych kilkadziesiąt minut dziennie na osobę, bo wymagają zajrzenia w dwa lub trzy systemy. Agent z dostępem do odczytu odpowiada w jednym miejscu i podaje źródło każdej liczby. To najprostszy wariant startowy z natychmiast widocznym efektem.

Trzeci: kontrola spójności rekordów. Agent porównuje dane między systemami i zgłasza rozjazdy: kontrahent z innym NIP-em w CRM i ERP, zlecenie bez przypisanego kosztu, dostawa bez dokumentu magazynowego. Publikowane przykłady z rynku pokazują skrócenie uzgadniania kont z kilku dni pracy do godzin. Tu agent nie zapisuje – tylko wskazuje, gdzie człowiek ma zajrzeć.

Czwarty: dopasowanie płatności do dokumentów. Klasyczny proces, w którym reguły pokrywają 70–80% przypadków, a reszta wymaga oceny. Agent obsługuje resztę: czyta tytuł przelewu, kojarzy skróconą nazwę firmy, rozpoznaje płatność zbiorczą za kilka faktur i proponuje rozksięgowanie do akceptacji.

Piąty: przygotowanie danych do rozmowy handlowej. Agent zbiera historię zakupów, otwarte zlecenia, przeterminowane należności i ostatnie reklamacje w jedną notatkę przed spotkaniem. Nie zmienia niczego w systemie, a oszczędza handlowcowi kwadrans przed każdą wizytą.

Najgroźniejsza usterka agenta w ERP nie wygląda jak usterka. Agent nie odmawia odpowiedzi ani nie zmyśla nieistniejącego klienta – podaje liczbę, która jest policzona poprawnie, tylko z innej definicji niż ta, o którą pytał człowiek. „Ilu mamy aktywnych klientów” ma trzy odpowiedzi, jeśli w systemie są trzy pola statusu: flaga w kartotece, brak daty zakończenia współpracy i fakt zakupu w ostatnich dwunastu miesiącach. Model wybierze jedną z nich i nie zasygnalizuje, że wybór w ogóle miał miejsce.

Druga postać tego samego problemu to niestandaryzowane kodowanie. Jeżeli ten sam wyrób funkcjonuje w kartotece pod trzema indeksami, bo przez lata wprowadzały go trzy osoby, agent dopasowujący pozycje zamówienia będzie generował dokumenty na zły indeks. Różnica w stosunku do błędu człowieka jest taka, że człowiek pomyli się raz, a agent powtórzy ten sam schemat na całym wolumenie – kilkaset dokumentów, zanim ktokolwiek zauważy.

Trzecia postać dotyczy pól opisowych. Uwagi do zlecenia, notatki z rozmów, komentarze do reklamacji – to często jedyne miejsce, gdzie zapisano ustalenie handlowe, i jednocześnie pole, w którym nie ma żadnej dyscypliny formatu. Agent czytający taką kolumnę potrafi wyciągnąć z niej wniosek, który był prawdziwy dwa lata temu.

Wniosek dla planowania projektu jest praktyczny: zanim zaczniecie porównywać dostawców i modele, sprawdźcie, ile jednoznacznych definicji ma pięć pojęć, których agent będzie używał najczęściej. To jest jednodniowe zadanie dla osoby, która zna dane, i najlepiej wydany dzień w całym projekcie.

Audyt danych brzmi jak osobny projekt konsultingowy, a w praktyce dla średniej firmy to od trzech do dziesięciu dni pracy i cztery pytania zadane każdemu obszarowi, którego agent dotknie.

Pytanie pierwsze – definicje. Dla każdego pojęcia, którego agent będzie używał (aktywny klient, zrealizowane zlecenie, dostępny stan, przeterminowana należność) spisujemy jedną obowiązującą definicję i wskazujemy pole, z którego ma być liczona. Jeżeli obszar nie potrafi wskazać jednej – to jest ustalenie projektowe, nie techniczne, i musi je podjąć właściciel procesu.

Pytanie drugie – kompletność. Jaki procent rekordów ma wypełnione pola, na których agent ma się opierać? Kartoteka kontrahentów, w której 30% pozycji nie ma przypisanej branży, nie nadaje się do segmentacji, choćby model był najlepszy. Ten pomiar jest prosty do wykonania zapytaniem i natychmiast urealnia zakres pierwszego etapu.

Pytanie trzecie – duplikaty i kodowanie. Ilu kontrahentów występuje więcej niż raz, ile indeksów opisuje ten sam wyrób, czy jednostki miary są spójne. Pytanie czwarte – uprawnienia. Kto może zobaczyć dane, które agent będzie zwracał, i czy model uprawnień da się odwzorować w warstwie agenta. To ostatnie bywa zaskoczeniem: wiele ERP-ów ma uprawnienia zaszyte w ekranach, a nie w danych, więc agent czytający bezpośrednio z bazy omija je w całości.

Agent z prawem zapisu potrzebuje trzech mechanizmów, które w klasycznej integracji nie były potrzebne, bo integracja robiła dokładnie to, co zaprogramowano, a agent podejmuje decyzję.

Pierwszy to limit wolumenu i wartości. Agent może wystawić dwadzieścia dokumentów na godzinę, nie dwa tysiące, i nie może samodzielnie zatwierdzić operacji powyżej progu kwotowego ustalonego przez firmę. Limit nie jest wyrazem nieufności do modelu – jest wyrazem tego, że każdy system popełnia błędy seriami, a limit zamienia serię w incydent do naprawienia.

Drugi to log i ścieżka wycofania. Każda operacja agenta musi być oznaczona w systemie jako wykonana przez agenta, z zapisem, na jakiej podstawie została podjęta. Bez tego nie da się ani odtworzyć przyczyny błędu, ani wycofać serii dokumentów, ani odpowiedzieć audytorowi na pytanie, kto zatwierdził zapis.

Trzeci to spisany podział odpowiedzialności między człowiekiem a agentem. Według badania Capgemini Research Institute ma go zaledwie 48% organizacji – i to jest dokładnie ten dokument, którego brak ujawnia się dopiero przy pierwszym poważnym błędzie, gdy okazuje się, że nikt nie umie odpowiedzieć na pytanie, kto miał to sprawdzić. Jedna strona z podziałem decyzji, progami i osobą odpowiedzialną za przegląd wyników wystarcza.

Poniższe widełki odzwierciedlają publikowane stawki dla polskiego rynku i pokrywają się z tym, co widzimy w wycenach. Główna obserwacja jest taka, że o cenie nie decyduje model ani liczba użytkowników, tylko liczba systemów, z którymi agent rozmawia, i to, czy wolno mu w nich zapisywać.

Koszt utrzymania jest tu ważniejszy niż w klasycznym projekcie IT, bo agent żyje na styku systemów, które zmieniają się niezależnie od niego. Zmiana API w ERP po aktualizacji, nowe pole w kartotece, zmiana schematu uprawnień – każda z tych rzeczy wymaga poprawki po stronie konektora i przejścia testów regresji. Firmy, które planują tylko wdrożenie bez pozycji na utrzymanie, po roku mają agenta, który cicho przestał obsługiwać część przypadków.

Warto też rozdzielić dwie pozycje, które często wrzuca się do jednego worka: koszt modelu i koszt integracji. Sam koszt zapytań do modelu jest w typowym wdrożeniu operacyjnym mniejszą pozycją niż utrzymanie konektorów i monitoring. Rośnie natomiast szybko przy złych decyzjach projektowych – zbyt długich instrukcjach, pobieraniu kilkunastu dokumentów do każdego zapytania czy używaniu najdroższego modelu do klasyfikacji, którą zrobiłby najprostszy.