System zarządzający magazynem - nadzór zmiany w czasie rzeczywistym

Posiadanie danych o stanie magazynu i bieżący nadzór nad tym, co się w nim dzieje, to dwie różne rzeczy. Raport z końca dnia pokazuje, ile zamówień zrealizowano, ale nie mówi, że kompletacja od jedenastej idzie wyraźnie wolniej niż zwykle albo że dla zamówienia priorytetowego towar w przypisanej lokalizacji się nie zgadza.

System zarządzający magazynem w ujęciu tego artykułu jest czymś więcej niż bazą stanów. To panel pokazujący postęp pracy w danej minucie, z perspektywy osoby odpowiedzialnej za zmianę. Poniżej opisano różnicę między nadzorem bieżącym a raportowaniem oraz sposób pracy kierownika zmiany. Osobno omówiono mechanikę alertów i wpływ nadzoru na terminy wysyłek. Ogólną definicję klasy systemów podaje strona o Warehouse Management System.

Dane o magazynie a bieżący nadzór nad procesami

Wiele magazynów ma dane, których nikt nie ogląda w trakcie zmiany. Ewidencja stanów oraz historia wydań i raporty inwentaryzacyjne bywają dokładne, ale odczytuje się je po fakcie, gdy zamówienie nie zdążyło wyjechać albo klient zgłosił reklamację. Nadzór bieżący działa inaczej: pokazuje stan magazynu w tej minucie, a nie w podsumowaniu z wczoraj.

Różnica wychodzi najlepiej w dużym magazynie, gdzie jedna osoba nadzoruje kilkudziesięciu magazynierów w wielu strefach. Bez podglądu kierownik dowiaduje się o problemie, gdy ktoś zadzwoni albo przyjdzie do biura zmiany. Podglądowi towarzyszy wcześniej uporządkowana gospodarka magazynowa, bo panel oparty na niepełnych danych pokazuje obraz nieprawdziwy.

Co pokazuje panel w czasie rzeczywistym

Nadzór w czasie rzeczywistym nie oznacza zalewu liczb, tylko wybór zdarzeń istotnych dla bieżącej zmiany. Panel prezentuje, ile zamówień z porannej fali zostało skompletowanych, ile jest w toku, a ile czeka na przypisanie. Osobno widać zlecenia, których czas znacząco odbiega od typowego, bo to one zwykle wymagają uwagi kierownika.

Postęp kompletacji w podziale na strefy

Postęp prezentuje się według stref lub tras, co pozwala szybko zauważyć, gdzie tempo spada. Wartości pochodzą ze statusów zadań zapisywanych przez terminale, więc panel jest agregatem tych samych danych, na których pracują operatorzy. Przykładowe zapytanie liczy zadania w trzech statusach dla każdej strefy.

-- Postęp kompletacji w podziale na strefy, od początku dnia (tabele przykładowe)
SELECT s.Nazwa                                                     AS Strefa,
       COUNT(*)                                                    AS Wszystkie,
       SUM(CASE WHEN z.Status = 'ZAKONCZONE' THEN 1 ELSE 0 END)    AS Zakonczone,
       SUM(CASE WHEN z.Status = 'W_TOKU'     THEN 1 ELSE 0 END)    AS WToku,
       SUM(CASE WHEN z.Status = 'OCZEKUJE'   THEN 1 ELSE 0 END)    AS Oczekuje
FROM dbo.ZadanieKompletacji AS z
JOIN dbo.Strefa AS s ON s.IdStrefy = z.IdStrefy
WHERE z.DataUtworzenia >= CAST(SYSDATETIME() AS date)
GROUP BY s.Nazwa
ORDER BY s.Nazwa;

Panel odpytuje bazę regularnie, a to rodzi problem współbieżności: odczyty agregujące nie powinny blokować zapisów z terminali. W SQL Server rozwiązuje to izolacja migawkowa dla poziomu READ COMMITTED, w której odczyt korzysta z wersji wierszy zamiast z blokad współdzielonych. Włącza się ją na poziomie bazy, a szczegóły opisuje dokumentacja poziomów izolacji transakcji.

-- Odczyty panelu nie blokują zapisów z terminali (nazwa bazy przykładowa)
ALTER DATABASE MagazynPrzyklad SET READ_COMMITTED_SNAPSHOT ON WITH ROLLBACK IMMEDIATE;

Odświeżanie po stronie przeglądarki zwykle realizuje się asynchronicznym zapytaniem AJAX w stałym odstępie. Poniższy fragment jest przykładem mechanizmu, a nie kodem rzeczywistego produktu.

// Odświeżanie panelu co 15 s bez przeładowania strony (adres przykładowy)
async function odswiezPanel() {
  const odp = await fetch('/api/panel/postep', { headers: { 'Accept': 'application/json' } });
  if (!odp.ok) return;
  const dane = await odp.json();
  document.querySelector('#panel-postep').textContent =
    dane.zakonczone + ' / ' + dane.wszystkie;
}
setInterval(odswiezPanel, 15000);
odswiezPanel();

Wyjątki i opóźnienia widoczne na bieżąco

Osobną kategorią są wyjątki, czyli sytuacje odbiegające od standardowego przebiegu: brak towaru w miejscu wskazanym przez system, uszkodzone opakowanie zbiorcze albo przerwane skanowanie. Dane o stanach magazynowych aktualizują się w chwili zapisu zdarzenia, więc kierownik widzi rozbieżność zapisu z rzeczywistością niemal od razu, a nie dopiero przy następnej inwentaryzacji.

Klasyfikacja wyjątków i kody przyczyn

Panel pokazuje wyjątki użytecznie tylko wtedy, gdy każdy z nich ma kod przyczyny wybierany z ograniczonej listy. Wpis dowolnym tekstem nie daje się policzyć, a zestawienie „ile razy w tym tygodniu brakowało towaru w strefie A” staje się wtedy niemożliwe. Lista przyczyn powinna być krótka, bo magazynier wybiera ją przy regale, na małym ekranie.

• Brak towaru - lokalizacja jest pusta lub ilość jest mniejsza niż w zadaniu.
• Uszkodzenie - opakowanie lub towar nie nadaje się do wydania, więc dostaje status blokady.
• Błąd identyfikacji - etykieta jest nieczytelna albo nie pasuje do indeksu w zadaniu.
• Przerwa techniczna - terminal lub sieć nie pozwalają dokończyć operacji.

Zliczane po strefie i godzinie, kody przyczyn wskazują wzorce. Częste błędy identyfikacji w jednej alei sugerują problem z etykietami, a przerwy techniczne w jednym rogu hali problem z zasięgiem sieci. Kierownik zgłasza wtedy sprawę do właściwego działu, zamiast rozwiązywać ją za każdym razem od nowa.

Rola kierownika zmiany w nadzorze

Kierownik zmiany odpowiada za wykonanie zaplanowanej pracy w wyznaczonym czasie, niezależnie od obsady i liczby nieprzewidzianych sytuacji. Panel staje się jego podstawowym narzędziem: zamiast obchodzić halę w poszukiwaniu informacji, sprawdza stan realizacji z jednego ekranu i decyduje, gdzie skierować dodatkowe osoby. Musi też odróżnić chwilowe spiętrzenie zamówień od powtarzającego się problemu, który wymaga zgłoszenia dalej, na przykład do działu utrzymania sprzętu.

Jak kierownik korzysta z panelu

Zmiana zaczyna się od przeglądu panelu: ile zamówień czeka, które strefy są najbardziej obciążone i czy ktoś pracuje wolniej niż zwykle. Bywa to sygnał problemu osobistego albo sprzętowego, na przykład niesprawnego terminala radiowego. Kolejne spojrzenia w ciągu dnia służą już do korekty: przesunięcia magazyniera z lżejszej strefy do tej, w której narasta zaległość, albo zmiany kolejności zamówień o wcześniejszym terminie.

Zakres widocznych danych zależy od roli, więc kierownik zmiany widzi więcej niż pojedynczy magazynier. Zasady opisuje strona o rolach i użytkownikach systemu WMS.

Decyzje podejmowane na podstawie bieżących danych

Decyzje mają charakter operacyjny i krótkoterminowy, dotyczą najbliższej godziny lub dwóch. Kierownik może wstrzymać przydzielanie nowych zleceń do jednej strefy, dopóki nie zniknie opóźnienie, albo poprosić transport o przesunięcie godziny podstawienia auta. Koordynację kolejek zadań pomiędzy operatorami opisuje strona o pracy dyspozytorów magazynowych. Decyzja podjęta o kilkanaście minut wcześniej oddziela często wysyłkę na czas od reklamacji zgłoszonej następnego dnia.

Alerty i progi powiadomień

Nadzór traci sens, jeśli kierownik musi bez przerwy patrzeć w ekran. Uzupełniają go alerty, czyli powiadomienia uruchamiane automatycznie po przekroczeniu progu. Zbyt wolna kompletacja w strefie, brak towaru w lokalizacji lub zamówienie zbliżające się do granicznej godziny bez statusu gotowości to typowe wyzwalacze.

Technicznie alert jest wierszem w tabeli, który tworzy zadanie cykliczne. W SQL Server takie zadania uruchamia agent, opisany w dokumentacji SQL Server Agent. Poniższy przykład wpisuje alert dla zamówień, do których granicznej godziny zostało mniej niż 45 minut, a które nadal nie są gotowe. Warunek NOT EXISTS chroni przed dublowaniem wpisu przy kolejnych przebiegach.

-- Zadanie cykliczne: zamówienia bliskie granicznej godziny, jeszcze niegotowe
INSERT INTO dbo.AlertMagazynowy (Typ, IdZamowienia, Utworzono)
SELECT 'TERMIN_WYSYLKI', z.IdZamowienia, SYSDATETIME()
FROM dbo.ZamowienieWydania AS z
WHERE z.Status IN ('OCZEKUJE', 'W_TOKU')
  AND z.TerminWysylki <= DATEADD(MINUTE, 45, SYSDATETIME())
  AND NOT EXISTS (SELECT 1 FROM dbo.AlertMagazynowy AS a
                  WHERE a.IdZamowienia = z.IdZamowienia AND a.Typ = 'TERMIN_WYSYLKI');

Alert trafia na panel kierownika, a przy konfiguracji z wysyłką wiadomości także na telefon lub terminal, jeśli kierownik nie stoi przy stanowisku. Rozbieżność zapisu z fizycznym stanem lokalizacji to jeden z częstszych powodów alertu. Zanim wstrzyma ona kompletację całego zamówienia, przyczynę sprawdza się doraźnie, a większe różnice zapisuje do najbliższej inwentaryzacji cząstkowej strefy.

Reguła: zbyt czuły próg prowadzi do zmęczenia alertami, a zbyt luźny milczy, gdy problem jest już poważny. Progi konsultuje się z kierownikami zmian po pierwszych tygodniach pracy, zamiast ustawiać je raz na zawsze podczas wdrożenia.

Kanały powiadomień

Ekran panelu jest najprostszym kanałem, ale wymaga obecności przy komputerze. Uzupełnia go wiadomość e-mail wysyłana z bazy, na przykład przez funkcję Database Mail, albo komunikat na terminalu brygadzisty. Wybór kanału zależy od pilności: alert o zbliżającej się godzinie wysyłki powinien dotrzeć w ciągu minut, a zestawienie wyjątków z całej zmiany może poczekać na koniec dnia.

Ten sam alert nie może wracać w kolejnych przebiegach zadania. Z tego powodu w przykładzie wyżej pojawia się warunek sprawdzający, czy wpis już istnieje, a osoba potwierdzająca alert zamyka go w tabeli, co zatrzymuje dalsze powiadomienia.

Sytuacja na magazynie i reakcja na sygnał systemu

Tabela porządkuje typowe sytuacje na zmianie, sposób sygnalizacji w systemie oraz reakcję kierownika.

Uprawnienia do panelu i dane o pracownikach

Panel pokazuje wydajność zmiany, a czasem także pojedynczych operatorów, więc dostęp do niego wymaga rozważnych uprawnień. Kierownik strefy powinien widzieć własną strefę, kierownik magazynu wszystkie, a pracownik biura tylko statusy zamówień. Widok szczegółów operatora ma sens do koordynacji pracy, a nie do publicznego porównywania ludzi.

Przy przetwarzaniu danych o pracownikach obowiązują przepisy o ochronie danych osobowych, więc zakres zbieranych informacji, czas ich przechowywania i cel wykorzystania warto opisać w regulaminie pracy z systemem. Sam mechanizm zapisu operacji nie zależy od tych decyzji, ale to one określają, co można z zapisów wyczytać.

Wpływ nadzoru na terminowość wysyłek

Terminowość zależy w dużej mierze od tego, jak szybko odchylenie zostanie zauważone, a nie tylko od liczby osób na zmianie. Magazyn, w którym opóźnienie ujawnia się po zamknięciu okna załadunku, traci możliwość korekty i może tylko poinformować klienta o przesunięciu. Magazyn z nadzorem bieżącym ma zwykle zapas czasu, w którym da się zmienić przydział pracy albo uzgodnić z transportem inną godzinę odbioru. Okna odbioru i ich planowanie opisuje strona o planowaniu wysyłek z magazynu.

Zapas czasu ma konkretną wartość, którą da się oszacować: to różnica między chwilą wykrycia odchylenia a graniczną godziną wysyłki. Jeśli alert pojawia się czterdzieści minut przed granicą, a przesunięcie ludzi do strefy i skompletowanie zaległości zajmuje trzydzieści, kierownik ma jeszcze margines. Gdy ten sam sygnał dociera dziesięć minut przed granicą, jedyną opcją pozostaje rozmowa z transportem o późniejszym odbiorze.

W dłuższej perspektywie panel zmienia też planowanie kolejnych zmian. Kierownik widzi strefy oraz pory dnia generujące opóźnienia i uwzględnia to w grafiku. Nadzór bieżący nie zastępuje planowania ani raportowania, tylko wypełnia lukę między nimi, czyli moment, w którym plan zderza się z rzeczywistością zmiany. Szersze ujęcie rozwoju firmy z systemem magazynowym opisuje strona o roli WMS w rozwoju firmy, a funkcje Studio WMS.net prezentuje serwis produktowy.