Poprawnie wykonana inferencja może prowadzić do złego zakupu, gdy model otrzyma nieaktualny zapas, błędną jednostkę albo niepełną listę zamówień. Źródłem problemu są wtedy zasady dopuszczania danych ERP do prywatnego AI, a nie algorytm. Scoring jakości ma zatrzymać niewiarygodny materiał przed obliczeniem, wskazać przyczynę i dobrać reakcję do kosztu pomyłki. Dla planisty oznacza to prostą ochronę: automatyczna rekomendacja pojawia się tylko przy wystarczająco dobrych danych, a w pozostałych przypadkach praca przechodzi na jawny tryb ręczny.
Błąd zaczyna się w danych
Model analizuje otrzymane rekordy, nie pracę magazynu widzianą przez użytkownika. Jeżeli ostatnie wydanie materiału nie trafiło do eksportu, rekomendacja uzupełnienia zapasu może pasować do liczb w paczce i jednocześnie szkodzić firmie. Ponowne uruchomienie obliczeń na tym samym materiale nie zmieni rezultatu.
Diagnoza powinna rozdzielać źródło ERP, przygotowanie danych, scoring, inferencję i publikację raportu. Identyfikator paczki, czas pobrania oraz wersja słownika wskazują, kiedy informacja straciła aktualność albo znaczenie. Bez tego administrator może szukać problemu w modelu, choć błąd nadal znajduje się w kartotece towaru.
Zakres wejścia wynika z decyzji, którą ma wspierać analiza. Uzupełnienie zapasu wymaga innych pól niż ocena należności. Ograniczenie eksportu ułatwia wyjaśnienie rekomendacji, zmniejsza ilość danych kopiowanych z ERP i zawęża miejsce poszukiwania błędu.
Skutki rozchodzą się dalej niż jedna liczba w raporcie. Zawyżony zapas może wstrzymać potrzebne zamówienie, zaniżony zwiększyć je bez uzasadnienia, a błędna jednostka przenieść pomyłkę na całą partię. W innym procesie ten sam rodzaj braku spowoduje nietrafną rezerwację, opóźnienie produkcji albo ręczną korektę dokumentów.
Jakość ma cztery osobne miary
Kompletność określa, czy paczka zawiera wymagane rekordy i pola. Aktualność porównuje czas zapisu z chwilą planowania. Spójność wykrywa sprzeczności między zapasem, rezerwacją, sprzedażą i zakupem. Zgodność słowników kontroluje jednostki, kody, statusy oraz klasyfikacje używane w ERP i procesie analitycznym.
Każda miara musi wskazywać konkretny rekord i przyczynę. Ogólna informacja o słabych danych nie mówi magazynowi, co poprawić, ani planiście, czy problem dotyczy jednej pozycji czy całej grupy. Stara data, brak jednostki lub rozbieżna rezerwacja kierują korektę do właściwego źródła.
Jeden wskaźnik dla całego ERP zwykle zaciera istotne różnice. Scoring może obejmować tylko pola używane przez dany model i proces. Gdy firma zmienia cel analizy, zmienia również kryteria, ale zachowuje informację, która wersja reguł oceniła daną paczkę. Miary pozostają widoczne osobno, zamiast ukrywać problem w jednej średniej.
Próg zależy od kosztu błędu
Kolor statusu skraca komunikat. Reguła nadal określa sposób postępowania. Materiał mieszczący się w uzgodnionym zakresie trafia do inferencji. Dane graniczne wymagają oceny człowieka albo ograniczenia publikacji. Poważny brak zatrzymuje automatyczne obliczenie i wymusza ręczne planowanie.
Progi ustala się według konsekwencji pomyłki. Tygodniowy raport pomocniczy może tolerować opóźnienie, którego nie można przyjąć przy zamówieniu składanym tego samego dnia. IT wdraża mechanizm i zapisuje zdarzenia, natomiast ekonomiczna granica akceptacji wynika z pracy zakupów, produkcji lub finansów.
Awaria mechanizmu scoringu lub brak odpowiedzi zatrzymują automatyczną ścieżkę. Bez oceny jakości danych model nie jest uruchamiany. ERP nadal przyjmuje transakcje, a planista korzysta z ręcznego zestawienia lub ostatniego zaakceptowanego materiału z widoczną datą.
Korekta nie może usuwać pierwotnej wartości. Historia obejmuje wersję wejścia, opis wyjątku, osobę, czas i dalszą czynność. Pozwala to odróżnić przypadkową pomyłkę od regularnej wady w danych źródłowych oraz policzyć koszt ręcznej obsługi.
Prywatna bramka przed modelem
ERP pozostaje źródłem transakcji, a kopie robocze, scoring i model działają w wydzielonym środowisku. G2E zapewnia warstwę serwerów wirtualnych, na której firma może utrzymać ERP, bazę SQL i prywatne obciążenie AI. Usługa daje zasoby, ale scoring oraz reguły zakupowe pozostają elementami rozwiązania przygotowanego dla konkretnego procesu.
Konto eksportowe odczytuje uzgodnione pola. Planista widzi rekomendację, ocenę wejścia i opis wyjątku bez praw administracyjnych do zaplecza. Osoba zmieniająca reguły nadaje im wersję i datę obowiązywania, dzięki czemu późniejsza analiza nie miesza dwóch różnych kryteriów.
Dane robocze mają własny okres przechowywania i dostęp ograniczony do potrzeb procesu. Historia powinna wystarczyć do wyjaśnienia użytej rekomendacji oraz obsługi incydentu, a później podlegać zasadom firmy. Samo umieszczenie modelu w prywatnym środowisku nie zastępuje minimalizacji danych.
Historia potrzebna po incydencie
W standardzie G2E kopia zapasowa serwera powstaje raz na 24 godziny, a okres jej retencji wynosi 3 dni. Chroni ona maszynę, ale odzyskanie bramki wymaga również reguł scoringu, konfiguracji zadań, wersji modelu, słowników, logów i powiązania z paczkami ERP.
Kopia SQL służy do odtworzenia bazy. Kopia danych roboczych zachowuje paczki i historię scoringu, a backup VM obejmuje system operacyjny, konfigurację maszyny oraz pliki. Planista powinien wiedzieć, ile może czekać na wznowienie oceny i z jakiego momentu wrócą dane. Dopiero wtedy zespół dobiera częstotliwość kopii, kolejność przywracania i sposób pracy ręcznej. Uruchomiona maszyna bez właściwej wersji reguł nie odtworzy wiarygodnej rekomendacji.
Po awarii stara paczka z błędem powinna ponownie zostać zatrzymana przez tę samą wersję scoringu. Nowszy rekord z poprawionym zapasem przechodzi osobno i zachowuje własny identyfikator. Dzięki historii można wyjaśnić zmianę bez podmieniania wcześniejszych danych i bez ponownego użycia nieaktualnej rekomendacji.
Automatyzacja może kontynuować pracę tylko wtedy, gdy wejście spełnia kryteria ustalone dla danej decyzji. Przy brakach lub niepewnej aktualności lepszy jest widoczny wyjątek i ręczne wyliczenie niż płynny raport oparty na fałszywym obrazie ERP. Taka reguła chroni zakupy przed kosztowną pomyłką, a system transakcyjny może dalej obsługiwać bieżące operacje.