Przyjęcie zamówień do ERP: reguły, kolejka i decyzja operatora

Zamówienia przychodzą jako e-maile i pliki opisane językiem klienta. System odczytuje z nich pozycje, ilości i jednostki. O tym, co wolno zapisać do ERP, decydują sprawdzalne reguły katalogowe.

Pracownik hurtowni, który przepisuje zamówienia, wykonuje trzy rodzaje pracy: rozpoznaje indeksy, przelicza jednostki i opakowania oraz odróżnia bezpieczny zamiennik od sytuacji wymagającej decyzji. Dwa pierwsze zadania można opisać regułami. Trzecie wymaga osądu i powinno pozostać po stronie człowieka.

Które zadania wykonuje system, a które człowiek

W systemie przyjęcia zamówień każdy krok ma jasno określonego wykonawcę.

Automatyzacja przyjmuje e-mail lub plik, prowadzi sprawę przez kolejne kroki, ponawia nieudane operacje i chroni przed ponowną obsługą tego samego zamówienia. Treść trafia do ustalonego zestawu pól. Dopiero wtedy reguły katalogowe sprawdzają indeksy, jednostki i zamienniki.

Dopasowanie indeksu, przeliczenia jednostek i ocena zamiennika są zapisane w regułach. Te same dane zawsze prowadzą do tej samej decyzji katalogowej, którą można przetestować. Model odczytujący zamówienie nie może tych reguł ominąć.

Pozycja bez pewnego potwierdzenia katalogowego nie trafia do ERP. System tworzy zadanie dla operatora i pokazuje proponowany indeks, pozostałych kandydatów oraz powód ich odrzucenia. Operator dostaje materiał do decyzji bez ponownego przeszukiwania katalogu.

Dlaczego decyzja katalogowa nie może być zgadywana

Osąd jest potrzebny tylko wtedy, gdy kilka indeksów lub zamienników wygląda podobnie. Właśnie ten krok pozostaje po stronie człowieka. Cichy zapis niejednoznacznej pozycji ujawnia się zwykle dopiero przy dostawie i oznacza zwrot, korektę oraz rozmowę z klientem.

Automatyczny odczyt pomaga uporządkować zamówienie. Wybór indeksu, zamiennika i zgoda na zapis muszą jednak wynikać z reguł lub jawnej decyzji operatora. Dzięki temu każdą decyzję można odtworzyć.

Jak podzielić proces przed wyborem technologii

Najlepszym punktem wyjścia jest rozpisanie jednej pozycji zamówienia od wiadomości klienta do rekordu w ERP. Przy każdym kroku trzeba wskazać, czy wynik wynika z jednoznacznej reguły, interpretacji treści, czy decyzji handlowej.

Taki podział zwykle pokazuje, że model jest potrzebny na początku, gdzie język klienta jest nieregularny. Środek procesu powinien być przewidywalny, a końcowa niejednoznaczność musi mieć właściciela. Framework agentowy nie naprawi braku mapowań jednostek ani niespójnego katalogu.

Najczęstsze awarie po uruchomieniu

Zmiana kartoteki w trakcie dnia. Indeks zostaje wycofany lub zmienia się opakowanie. Każda decyzja powinna więc wskazywać wersję katalogu, z której korzystała.

Podwójna obsługa wiadomości. Klient ponownie wysyła ten sam plik albo pracownik przekazuje go na inną skrzynkę. Klucz przeciw duplikatom musi obejmować wiadomość, załącznik oraz numer zamówienia klienta.

Pozornie poprawny zapis. ERP przyjmuje rekord, choć jedna pozycja zawiera błędną jednostkę lub cenę. Odpowiedź techniczna z integracji nie zastępuje kontroli biznesowej kompletności.

Kolejka bez czasu reakcji. System poprawnie zatrzymuje wyjątki, ale nikt ich nie odbiera. Pilot powinien mierzyć również wiek najstarszej sprawy i czas do decyzji operatora.

Co sprawdziliśmy

Wersję demonstracyjną sprawdziliśmy na przygotowanym zestawie 480 zamówień i 2 400 pozycji. W 12 kontrolowanych przypadkach reguły poprawnie wskazały indeksy, a 21 prób niebezpiecznego zapisu zostało zatrzymanych. W osobnej próbie odczyt nieuporządkowanego zamówienia po polsku zużył 602 tokeny, trwał 3,99 s i kosztował szacunkowo 0,0027 zł. Jakość i koszt dla katalogu klienta trzeba zmierzyć przed uruchomieniem.

Wniosek wykracza poza obsługę zamówień: automatyczny odczyt jest przydatny przy nieuporządkowanych danych, ale decyzje katalogowe i zapis do systemu powinny pozostać w testowalnych regułach.

Pomiar demonstracyjny odpowiada na wąskie pytania: czy przygotowane reguły zachowały się zgodnie ze specyfikacją i czy bramka zablokowała kontrolowane próby. Nie odpowiada jeszcze na pytanie o odsetek zamówień, które przejdą bez operatora w konkretnej hurtowni. Ten wynik zależy od jakości katalogu, zwyczajów klientów i liczby wyjątków.

Lista do pilotażu na własnych zamówieniach

Przed decyzją o uruchomieniu warto przygotować:

• próbkę zamówień od różnych klientów, wraz z ręcznie potwierdzonym wynikiem,
• aktualny katalog produktów, jednostek, opakowań i dopuszczalnych zamienników,
• listę pól wymaganych przez ERP oraz reguły blokujące niepełny zapis,
• definicję duplikatu i sposób bezpiecznego ponowienia po błędzie,
• kolejkę wyjątków z właścicielem i czasem reakcji,
• osobne miary dla odczytu pól, dopasowania indeksów, blokad i czasu pracy operatora,
• plan powrotu do ręcznego przyjmowania zamówień, gdy integracja albo katalog są niedostępne.

W pilotażu najważniejszy jest udział pozycji zakończonych poprawnie bez poprawki oraz czas potrzebny na obsługę pozostałych. Sam koszt odczytu przez model jest tylko jedną, zwykle niewielką częścią kosztu całego procesu.

Szczegóły znajdziesz na karcie systemu. Podczas bezpłatnego przeglądu procesu możemy wspólnie oddzielić kroki oparte na regułach od decyzji wymagających człowieka.