Agent AI dla Subiekta GT: kolejka, której Subiekt Ci nie da

Dlaczego to piszę

Dwa tygodnie temu wrzuciłem tu przewodnik programisty po Sferze dla Subiekta GT, a wczoraj porównanie API trzech systemów, w którym enova365, Optima i Subiekt stanęły obok siebie. Od tamtej pory jeden wiersz tej tabeli nie daje mi spokoju. enova365 daje bufor. Optima daje trzy miejsca, w których dokument jest jeszcze tymczasowy. Subiekt GT nie daje nic — a ja zostawiłem w tej komórce notkę: „zaprojektuj to po swojej stronie".

Ta notka to cały projekt. Poniżej piszę, co „po swojej stronie" znaczy w praktyce. Subiektowy odpowiednik tego, co opisałem już dla enova365 i dla Optimy.

Brak bufora to nie jest szczegół

W enova365 agent tworzy dokument z ustawioną flagą Bufor. Zapisany, widoczny, edytowalny, bez ruchu na stanach i bez śladu w rejestrze VAT. Człowiek go otwiera, poprawia, co trzeba, zatwierdza. Jeśli agent wyprodukował bzdurę, ktoś kasuje szkic i nic się nie wydarzyło.

Sfera tak nie działa — i to świadoma decyzja InsERT-u, nie przeoczenie. Dokument utworzony przez Sferę jest prawdziwym dokumentem. Bierze kolejny numer z serii. Wycenia się tymi samymi regułami, które uruchomiłby handlowiec. WZ albo FS zdejmuje stan, FS tworzy należność. Dokładnie dlatego używa się Sfery zamiast zapisu wprost do tabel: dokument zachowuje się tak, jak kazałby mu Subiekt. Druga strona tej samej monety: nie ma tu bezpiecznego miejsca na pomyłkę.

Powiem tę asymetrię wprost, bo to ona zmienia koszt błędu w każdym z trzech systemów:

• Zły szkic w enova365 kosztuje jedno skasowanie.
• Zły dokument w Subiekcie GT kosztuje numer w serii, ruch magazynowy do odkręcenia i — jeśli zdążył wyjść — rozmowę z klientem, który trzyma już PDF w ręku.

Sprawdź na własnej instalacji, co faktycznie dzieje się przy usunięciu. Zależy to od typu dokumentu i od konfiguracji Waszych serii, a odpowiedź nigdy nie brzmi „wszystko wraca do stanu poprzedniego". To jest sufit odwagi agenta w tym systemie.

Produktem jest kolejka

Reszta z tego wynika. W Subiekcie agent nie jest czymś, co zapisuje do ERP-a i zostawia ludziom sprzątanie. Jest procesem, który kończy się jednym kliknięciem — a wywołanie Sfery przychodzi po kliknięciu. Nigdy przed. Nigdy „a potem ktoś to przejrzy".

Konkretnie: usługa pośrednicząca z przewodnika, ta mała usługa na Windowsie trzymająca sesję COM, trzyma też kolejkę. Każda pozycja w kolejce to propozycja. Ten mail, od tego klienta, znaczy taki dokument, z takimi pozycjami, po takich cenach — i oto dlaczego tak sądzę. Człowiek widzi propozycję obok oryginalnej wiadomości, zmienia, co trzeba, zatwierdza. Dopiero wtedy usługa dotyka Sfery.

To odwrócenie ma skutek uboczny, którego nikt się nie spodziewa. Skoro przegląd dzieje się w Twoim interfejsie, a nie w Subiekcie, osoba zatwierdzająca nie potrzebuje stanowiska licencyjnego, nie musi siedzieć przy hoście z Windowsem i nie musi znać ERP-a. W hurtowni zwykle znaczy to jedno: zamówienia zatwierdza z telefonu ten, kto naprawdę zna klientów. Sam ERP nigdy by mu na to nie pozwolił.

Zacznij od ZK, nie od FS

Jeśli masz cokolwiek zapisywać, zapisuj zamówienie od klienta. ZK to najbliżej stanu do przeglądu, jak Subiekt GT potrafi: trzyma rezerwację, nie tworzy należności, a do WZ albo FS realizuje je człowiek, który i tak musi je otworzyć. Porównaj to z wystawieniem faktury prosto z maila. Właśnie zrobiłeś dokument podatkowy ze sparsowanej wiadomości, a jedynym recenzentem został klient.

Jest i drugi powód, handlowy, nie techniczny. W większości hurtowni, z którymi pracowałem, zamówienie przychodzi mailem albo PDF-em i ktoś przepisuje je ręcznie. Logika rezerwacji, poziomy cen, kontrola limitu — to wszystko siedzi już w ERP-ie i po prostu się nie uruchamia, bo zamówienia w ERP-ie jeszcze nie ma. To samo pisałem od strony kredytu kupieckiego w tekście o limitach: najwcześniejsza kontrola jest najtańsza, a jednocześnie najrzadsza, bo zamówienie nie dociera do systemu jako zamówienie. Jak rezerwacje zachowują się naprawdę — co trzymają, czego nie, gdzie po cichu wygasają — opisałem w tekście o rezerwacji odbiorcy w Optimie. Mechanika inna, pułapka ta sama.

Wprowadzenie maila do Subiekta jako ZK — poprawnie, z rezerwacją, która z niego wynika — to jest cały projekt. Reszta to Subiekt robiący to, co i tak robi.

Gdzie naprawdę jest robota

Wszystko, co kosztowne, dzieje się przed kliknięciem — i nic z tego nie jest pracą nad modelem:

Kontrahent. NIP rozwiązuje się prawie zawsze. Nazwa firmy ze stopki maila rozwiązuje się kiepsko, a bliźniacze kartoteki, które siedzą w każdej bazie Subiekta — ta sama firma wpisana dwa razy przez dwóch handlowców — pogarszają sprawę. Dopasowuj po NIP-ie, potem po domenie nadawcy, jeśli ją przechowujesz, i na tym koniec. Wszystko mniej pewne idzie do kolejki jako pytanie „który z tych dwóch?", na które człowiek odpowiada w sekundę.

Towary. Tu umierają projekty i nie ma to nic wspólnego z AI. Klienci zamawiają własnym językiem: „dziesięć kartonów tej pięciolitrowej", zdjęcie zeszłomiesięcznego WZ-tu, arkusz z ich wewnętrznymi kodami. Zanim ktokolwiek cokolwiek zbuduje, policz, jaki udział pozycji zamówień da się przypisać do dokładnie jednego towaru w Subiekcie. W praktyce wychodzi od 40 do 70 procent, chyba że klient zamawia z Waszych indeksów. Poniżej połowy lekarstwem jest tabela aliasów per klient — jego kod, Wasz symbol — uzupełniona z historii. Ruszy tę liczbę bardziej niż jakikolwiek model.

Cena. Subiekt zna odpowiedź, ma poziomy cen i rabaty przypisane klientowi. Zadaniem agenta jest ją odczytać, a nie policzyć. Propozycja pokazująca cenę, której ERP by nie wyprodukował, to błąd, nie funkcja.

Stan i limit. Odczytaj oba przed propozycją i wstaw je do propozycji. „To zamówienie na 3 400 zł dobija klienta do 96 procent limitu" zamienia zatwierdzenie z formalności w decyzję.

Problem ponowienia

To awaria charakterystyczna dla systemu bez szkiców. Wywołujesz Sferę, wywołanie przekracza limit czasu i nie wiesz, czy dokument powstał. Nie ma też na co spojrzeć, bo dokument zrobiony przez agenta niczym nie różni się od tego, który wyklikał człowiek.

Nigdy nie ponawiaj w ciemno. Dwie zasady:

1. Wnieś do dokumentu własny klucz. Zapisuj identyfikator pozycji z kolejki w polu, które dokument faktycznie ze sobą niesie — Uwagi albo pole własne, jeśli Twój typ dokumentu je przez Sferę wystawia — i przed każdym ponowieniem odpytaj Subiekta o dokument z tym kluczem. To jedyny element higieny integracyjnej, bez którego odmówiłbym wdrożenia.
2. Uzgadniaj. Co kilka minut porównuj otwarte pozycje kolejki z dokumentami utworzonymi w ostatniej godzinie. Timeouty rozwiązują się same, wystarczy patrzeć.

Tu należy też druga awaria z przewodnika. Sfera trzyma żywy uchwyt do działającego subiekt.exe. Ktoś go zamknie, aktualizacja go zrestartuje, maszyna wstanie po nocnym restarcie — i uchwyt jest martwy, a sam się nie naprawi. Kolejka, która po cichu przestaje produkować dokumenty, wygląda dokładnie jak spokojny tydzień. Alarmuj na „brak udanego wywołania Sfery od N godzin", a nie na błędy. Martwy uchwyt zwykle żadnego błędu nie zgłasza.

Kim jest agent po zalogowaniu

Połączenie Sfery niesie dwie tożsamości: login do SQL Servera i operatora Subiekta. Daj agentowi własne konto operatora, zamiast pożyczać mu czyjeś. Nie dla teatru bezpieczeństwa — dla śladu audytowego. Każdy utworzony dokument nosi wtedy nazwę, która nie jest nazwiskiem handlowca. Pół roku później, kiedy ktoś zapyta, jak to zamówienie tu trafiło, odpowiedź siedzi w dokumencie, a nie w czyjejś pamięci.

To ta sama granica, którą opisałem jako cztery poziomy uprawnień: czytaj, proponuj, zapisuj, wyślij. W Subiekcie agent mieszka na poziomie drugim i przechodzi na trzeci wyłącznie na kliknięcie. Nigdy nie wystawia FS z własnej inicjatywy, nie zdejmuje stanu, nie wysyła klientowi dokumentu. Kliknięcie jest podpisem, a podpis należy do człowieka.

Pierwsza wersja bez ryzyka

Przez pierwszy miesiąc nie zapisuj nic. Skieruj agenta na skrzynkę, na którą przychodzą zamówienia, i każ mu produkować dzienny raport tylko do odczytu z trzema liczbami:

• Wskaźnik dopasowania: pozycje zamówień przypisywalne do dokładnie jednego towaru w Subiekcie, plus lista tych, które się nie przypisały. Ta druga lista to Wasza tabela aliasów, gotowa do uzupełnienia.
• Zostałoby zablokowane: zamówienia od klientów już ponad limitem albo z przeterminowanymi fakturami. Każde takie zamówienie ktoś kiedyś przyjął, nie wiedząc o tym.
• Czas do systemu: godziny między przyjściem maila a pojawieniem się odpowiadającego mu ZK w Subiekcie. Nikt tego nie mierzy, a wszyscy zaniżają.

Miesiąc takiego raportu nic nie kosztuje i zamyka sprawę. Dopasowanie wysokie, czas do systemu dwie godziny? Macie dobry proces i nie macie projektu — to też jest wynik, kupiony tanio. Połowa pozycji nierozwiązana, a zamówienia leżą półtora dnia? Wiesz, co zbudować, i masz punkt odniesienia, żeby później udowodnić, że pomogło. Wtedy włącz propozycje dla jednego klienta, patrz, jaki ich udział człowiek poprawia przed zatwierdzeniem, i rozszerzaj, kiedy spadnie poniżej dziesięciu procent.

Pracujesz na Subiekcie GT, a zamówienia przychodzą mailem? Odezwij się. Takie właśnie agenty AI dla firm buduję — na Subiekcie, na Optimie i na enova365: najpierw odczyt, potem propozycja, a kliknięcie zostaje przy osobie, która odpowiada za klienta.