Program WMS online - sugestie uzupełnień i synchronizacja z ERP w warstwie AI

Program WMS online i warstwa AI - co system liczy

Program WMS online w wersji Studio WMS.net od SoftwareStudio zapisuje przyjęcia i wydania towaru oraz korekty stanów. Opis producenta wskazuje cztery funkcje oparte na tych danych: predykcyjną optymalizację poziomu zapasów, sugestie uzupełnień, dwukierunkową synchronizację z ERP oraz uczenie wzorców sezonowości. Ten artykuł omawia wyłącznie te cztery funkcje. Mechanizmy matematyczne, które za nimi stoją, opisano jako ogólną wiedzę o planowaniu zapasów, a nie jako specyfikację algorytmów produktu.

Warstwa AI nie jest osobnym modułem obok magazynu. Korzysta z tych samych dokumentów i kartotek, które obsługują program WMS.net na co dzień, więc jakość prognozy zależy bezpośrednio od dyscypliny ewidencji. Brakujący dokument wydania to brakujący punkt w historii popytu, a system nie odróżni braku sprzedaży od braku zapisu.

Dane wejściowe prognozy

Tabela zestawia dane, na których opiera się każda z czterech funkcji, oraz miejsce, w którym te dane powstają.

Reguła: prognoza jest tak dobra, jak najsłabsze ogniwo ewidencji - dokument wydania zaksięgowany po tygodniu przesuwa popyt w czasie i zaniża rotację.

Prognoza zapotrzebowania z historii wydań

Predykcyjna optymalizacja polega na tym, że algorytm wylicza poziom minimalny i maksymalny osobno dla każdej pozycji, zamiast opierać się na stałym progu wpisanym do kartoteki. Towar o rosnącej rotacji dostaje wyższy poziom docelowy, a asortyment wolno rotujący niższy. Ogranicza to zamrożony kapitał w nadmiarowych zapasach i skraca listę braków.

Punktem wyjścia jest szereg czasowy: wydania danej pozycji zsumowane do doby albo tygodnia. Z takiego szeregu wylicza się średni popyt oraz jego rozrzut. Im dłuższa i pełniejsza historia, tym stabilniej zachowuje się średnia. Kilka tygodni danych pozwala jedynie oszacować poziom, a rozpoznanie powtarzalnych cykli wymaga co najmniej kilku pełnych sezonów.

Prognoza jako przedział, nie pojedyncza liczba

Wynikiem prognozy jest przedział. System wskazuje spodziewane zapotrzebowanie razem ze skonfigurowanym zapasem bezpieczeństwa, który uwzględnia zmienność popytu i ryzyko opóźnienia dostawy u danego dostawcy. Pojedyncza liczba sugeruje dokładność, której dane historyczne nie dają, dlatego przedział jest uczciwszą formą.

Odchylenie standardowe dziennych wydań można wyliczyć bezpośrednio w bazie. Poniższe zapytanie T-SQL pokazuje ideę na przykładowej tabeli; nazwy nie pochodzą ze schematu produktu.

SELECT sku,
       AVG(CAST(ilosc AS float))   AS popyt_sredni_dzienny,
       STDEV(CAST(ilosc AS float)) AS odchylenie_dzienne,
       COUNT(*)                    AS liczba_dni
FROM   dbo.wydania_dzienne_przyklad
WHERE  data_wydania >= DATEADD(DAY, -180, CAST(GETDATE() AS date))
GROUP  BY sku
HAVING COUNT(*) >= 60;

Warunek HAVING COUNT(*) >= 60 odrzuca pozycje z zbyt krótką historią, dla których odchylenie nie ma sensu statystycznego. Funkcja STDEV w dokumentacji Microsoft Learn liczy odchylenie z próby, co jest właściwym wyborem przy ograniczonym oknie obserwacji.

Punkt zamówienia i zapas bezpieczeństwa

Punkt zamówienia wyznacza poziom zapasu, po którego przekroczeniu w dół system generuje sugestię uzupełnienia. W programie nie jest to wartość wpisana ręcznie do kartoteki, lecz wynik bieżącego przeliczenia z tempa sprzedaży, czasu realizacji dostawy i przyjętego zapasu bezpieczeństwa. Punkt rośnie w okresach wzmożonego popytu i spada, gdy sprzedaż słabnie.

Klasyczny wzór stosowany w planowaniu zapasów ma dwa składniki. Pierwszy to popyt w czasie dostawy, drugi to zapas bezpieczeństwa chroniący przed wahaniami popytu.

W tabeli d oznacza średni popyt dobowy, L czas dostawy w dobach, σ_d odchylenie dobowego popytu, a z współczynnik poziomu obsługi. Wartość z = 1,65 odpowiada w przybliżeniu 95 procentom cykli bez braku towaru, a z = 2,33 odpowiada 99 procentom. Wyższy poziom obsługi podnosi zapas bezpieczeństwa, więc kosztuje więcej zamrożonego kapitału.

Obliczenie punktu zamówienia w T-SQL

Ten sam rachunek da się wykonać zapytaniem, które łączy statystyki popytu z czasem dostawy dostawcy. Przykład używa tabeli pomocniczej z terminami dostaw; jest ilustracją mechanizmu, a nie kodem produktu.

DECLARE @z float = 1.65;   -- poziom obsługi ok. 95%

SELECT s.sku,
       s.popyt_sredni_dzienny * d.czas_dostawy_dni AS popyt_w_dostawie,
       @z * s.odchylenie_dzienne * SQRT(d.czas_dostawy_dni) AS zapas_bezp,
       s.popyt_sredni_dzienny * d.czas_dostawy_dni
         + @z * s.odchylenie_dzienne * SQRT(d.czas_dostawy_dni) AS punkt_zamowienia
FROM   dbo.statystyka_popytu_przyklad s
JOIN   dbo.dostawcy_sku_przyklad d ON d.sku = s.sku;

Funkcja SQRT działa na typie float, więc czas dostawy trafia do niej po niejawnej konwersji. Parametry takiego rachunku pozostają dostępne do przeglądu i korekty w konfiguracji programu magazynowego dla wybranych grup towarowych.

Sugestie uzupełnień i decyzja człowieka

Sugestia uzupełnienia przekłada wynik prognozy na gotową rekomendację: jaki towar, w jakiej ilości i od którego dostawcy zamówić. Zamiast codziennego przeglądania listy stanów osoba odpowiedzialna za zakupy widzi pozycje zbliżające się do punktu zamówienia, uszeregowane według pilności. Miarą pilności bywa liczba dni pokrycia, czyli stan bieżący podzielony przez średni popyt dobowy.

Po zaakceptowaniu sugestii system może przygotować szkic dokumentu magazynowego zamówienia, co skraca czas od wykrycia niedoboru do złożenia zamówienia. Rekomendacja pozostaje propozycją, a ostateczną decyzję zawsze podejmuje człowiek.

Reguła: sugestia nie tworzy zobowiązania wobec dostawcy - zamówienie powstaje dopiero po zatwierdzeniu przez osobę z uprawnieniami zakupowymi.

Jak wyliczyć ilość do zamówienia

Ilość w sugestii zwykle wynika z poziomu docelowego pomniejszonego o stan dostępny i zamówienia w drodze. Poziom docelowy to punkt zamówienia powiększony o popyt w cyklu przeglądu. Wynik zaokrągla się do wielokrotności opakowania zbiorczego lub palety, bo dostawca nie sprzeda 289 sztuk, gdy paleta liczy 300.

Zaokrąglenie do opakowań jest jednym z powodów, dla których sugestię trzeba konfigurować per grupa towarowa. Drobnica w kartonach po 24 sztuki wymaga innego kroku niż profile sprzedawane na sztuki.

Synchronizacja z ERP jako źródło danych dla prognozy

Trafność prognozy zależy od świeżości danych. Program WMS online utrzymuje automatyczną, dwukierunkową synchronizację z systemem ERP. Wydanie zarejestrowane w magazynie aktualizuje odpowiedni dokument w ERP, a zamówienie sprzedaży lub zmiana cennika z ERP trafia do modeli predykcyjnych WMS w tym samym cyklu wymiany.

Do prognozy wpływają przede wszystkim informacje o zamówieniach klientów i planowanych promocjach oraz dokumenty operacji magazynowych. Dzięki temu algorytm nie pracuje wyłącznie na historii z magazynu, tylko uwzględnia także sygnały z działu handlowego. Szczegóły techniczne tej wymiany opisuje strona Program WMS.net - specyfikacja techniczna.

Jak wymiana danych zasila model

Jeśli dział handlowy wprowadzi do ERP promocję na dany towar, informacja trafia do WMS przed wzrostem sprzedaży. Model podnosi wtedy prognozowane zapotrzebowanie z wyprzedzeniem, zamiast reagować po fakcie, gdy zapas już się kurczy. W drugą stronę działa dostępność: zmiana stanu w WMS aktualizuje dostępność widoczną w module sprzedaży ERP, co ogranicza ryzyko przyjęcia zamówienia na towar, którego już nie ma.

Ogólny wzorzec takiej integracji opiera się na kolejce komunikatów z unikalnym identyfikatorem każdej zmiany. Odbiorca potwierdza przetworzenie, a nadawca ponawia komunikaty bez potwierdzenia. Ponowienie nie może zdublować dokumentu, dlatego przetwarzanie musi być idempotentne, czyli powtórzony komunikat o tym samym identyfikatorze nie zmienia stanu po raz drugi. Ten wzorzec omawia osobno artykuł o integracji WMS z ERP przez REST i kolejki.

Sezonowość sprzedaży w prognozie

Sezonowość opisuje powtarzalny wzorzec zmian popytu: wzrost przed świętami, cykliczny szczyt w wybranych miesiącach albo regularne wahania tygodniowe. Program porównuje bieżące zamówienia z analogicznymi okresami poprzednich sezonów, więc administrator nie musi ręcznie oznaczać okresów szczytowych. Z każdym sezonem model ma więcej porównywalnych danych i lepiej odróżnia zdarzenie jednorazowe, na przykład pojedynczą promocję, od trwałego trendu.

Najprostszą formą opisu sezonowości jest wskaźnik sezonowy: średnia sprzedaż w okresie podzielona przez średnią ze wszystkich okresów. Wskaźnik 1,30 oznacza, że dany okres sprzedaje o 30 procent więcej niż przeciętny. Prognozę bazową mnoży się wtedy przez wskaźnik okresu, którego dotyczy plan.

Liczby w tabeli są poglądowe; średnia ze wszystkich kwartałów wynosi w nich 1000 sztuk tygodniowo. Ten sam rachunek w T-SQL wymaga dwóch kroków, bo funkcja okna działa na wyniku agregacji.

WITH okres AS (
  SELECT sku, DATEPART(QUARTER, data_wydania) AS kwartal,
         SUM(ilosc) * 1.0 / COUNT(DISTINCT DATEPART(WEEK, data_wydania)) AS srednia_tyg
  FROM   dbo.wydania_dzienne_przyklad
  GROUP  BY sku, DATEPART(QUARTER, data_wydania)
)
SELECT sku, kwartal,
       srednia_tyg / AVG(srednia_tyg) OVER (PARTITION BY sku) AS wskaznik_sezonowy
FROM   okres;

Klauzula OVER z PARTITION BY pozwala policzyć średnią po wszystkich kwartałach tej samej pozycji bez zwijania wierszy. Przy wielu latach danych ten sam schemat rozszerza się o rok, co daje wskaźniki uśrednione z kilku sezonów.

Cykle roczne i tygodniowe

Algorytm bierze pod uwagę zarówno cykle roczne, jak i krótsze wahania, na przykład zwiększony ruch w wybrane dni tygodnia w magazynach obsługujących wiele lokalizacji jednocześnie. Dla asortymentu ogrodowego system rozpozna wiosenny wzrost zamówień, a dla artykułów świątecznych szczyt w listopadzie i grudniu, i uwzględni go z odpowiednim wyprzedzeniem.

Prognoza zmienia się samoczynnie z sezonu na sezon. Im więcej pełnych cykli przetworzy system, tym mniej ręcznych poprawek wymaga plan uzupełnień przed kolejnym szczytem.

Wdrożenie funkcji AI w programie WMS online

Uruchomienie funkcji AI przebiega etapami, aby algorytm zebrał dane przed samodzielnym podpowiadaniem poziomów. Poniższa lista pokazuje kolejność, w której zespół wdrożeniowy i zakupowy weryfikuje wyniki.

1. Import historii transakcji - do systemu trafiają dane o zamówieniach oraz o ruchach magazynowych z możliwie długiego okresu.
2. Połączenie z ERP - uruchomienie dwukierunkowej synchronizacji, dzięki której model dostaje bieżące dane spoza magazynu.
3. Kalibracja na wybranej grupie towarowej - funkcje predykcyjne działają najpierw dla ograniczonej liczby SKU, aby ocenić trafność sugestii.
4. Weryfikacja i rozszerzenie - zespół zakupowy sprawdza rekomendacje przez pierwsze tygodnie, a po potwierdzeniu trafności zakres obejmuje cały asortyment.

Wdrożenie stopniowe pozwala porównać poziom zapasów i liczbę braków sprzed oraz po uruchomieniu funkcji na tej samej grupie asortymentowej. Taka próba kontrolna daje rzetelną ocenę wpływu automatyzacji, zanim obejmie ona wszystkie kategorie.

Jak mierzyć trafność prognozy

Najprostszą miarą jest średni błąd bezwzględny: średnia z modułów różnic między prognozą a sprzedażą rzeczywistą w tym samym okresie. Wartość odniesiona do średniej sprzedaży daje błąd procentowy, który można porównać między pozycjami o różnej skali. Osobno warto śledzić liczbę dni z brakiem towaru oraz dni pokrycia zapasu, bo prognoza z małym błędem nadal może kończyć się zbyt dużym stanem.

Rozbieżności między sugestią a decyzją zakupową trafiają z powrotem do modelu jako dodatkowy sygnał. Jeśli człowiek konsekwentnie zamawia mniej niż podpowiada system dla danej grupy, przyczyną bywa źle wpisany czas dostawy albo pominięte ograniczenie miejsca na regałach.

Funkcje opisane w tym artykule można obejrzeć na przykładowych danych w demo magazynu udostępnionym przez SoftwareStudio. Opis pełnego systemu znajduje się na stronie program magazynowy WMS.net w serwisie producenta.

Ograniczenia prognoz i kontrola jakości

Model uczony na historii nie przewidzi zdarzeń, których historia nie zawiera. Nowy produkt bez sprzedaży, zmiana dostawcy albo nagłe zamknięcie konkurenta zaburzają prognozę, dopóki nie pojawią się nowe dane. Dla takich pozycji sensowniejsze bywa ręczne ustawienie poziomów w konfiguracji, z wyłączeniem sugestii do czasu zebrania kilku tygodni wydań.

Kontrola jakości sprowadza się do regularnego porównania prognozy ze sprzedażą rzeczywistą oraz stanu z liczbą braków. Rozbieżność utrzymująca się przez kilka okresów wskazuje na błąd w danych albo w konfiguracji, a nie na słabość samego algorytmu. Sama synchronizacja z ERP nie naprawi nierzetelnej ewidencji, ponieważ przekazuje dane w takiej postaci, w jakiej je zapisano. Szerszy kontekst dają strony o prognozowaniu popytu w magazynie oraz o analityce w logistyce.