Stan
Faktycznie nie ma towaru (zero / poniżej progu).
- OOS:STAN
- 0 szt.
- próg
W większości firm braki nie bolą dlatego, że „nie ma towaru”. Braki bolą, bo dowiadujesz się o nich za późno i rozwiązujesz je chaotycznie: telefon do dostawcy, ręczne notatki, operator „odkłada zamówienie na bok”. Ten materiał pokazuje prosty, wdrażalny model: wykrycie braku → status STOP → zadanie uzupełnienia → decyzja → powrót do realizacji. Dostajesz też gotowe reguły dla multi-magazynu, wyjątki (split, alternatywy) i KPI kontroli.
Cel: wykryć brak automatycznie i przerobić go na zadanie z decyzją, zanim rozwali SLA.
Operacyjnie „brak” to sytuacja, w której zamówienie nie może być zrealizowane w standardowym flow, bo ilość dostępna do kompletacji jest mniejsza niż wymagana (z powodów: stan, rezerwacje, split, routing magazynu).
Faktycznie nie ma towaru (zero / poniżej progu).
Towar jest „na papierze”, ale zarezerwowany pod inne zamówienia.
Towar jest, ale w innym magazynie / zły routing.
SKU w zamówieniu wymaga substytutu albo pakietu.
To jest kręgosłup procesu. Jeśli go nie masz, reszta jest kosmetyką.
Najlepszy moment na wykrycie braku to jak najwcześniej, ale bez generowania fałszywych alarmów.
Warunek: po imporcie zamówienia (lub po płatności) weryfikujesz dostępność. Jeśli brakuje – STOP zanim trafi do kompletacji.
Warunek: rezerwacja stanów się nie powiodła (albo rezerwacja powoduje zejście poniżej zera). To sygnał OOS:REZERWACJA.
Jeśli mimo wszystko brak wychodzi dopiero przy zbieraniu, automat przerzuca do STOP i tworzy zadanie. To ostatnia bariera.
Ustaw progi minimalne / alerty stanów. To nie zatrzyma zamówienia, ale daje wcześniejszy sygnał do zakupów.
Minimalny zestaw statusów pozwala oddzielić produkcję od braków i robić powrót automatem.
Zadanie jest Twoim „ticketem” operacyjnym. Ma być jednoznaczne i raportowalne.
jedna linia = jedna decyzja
koszt spóźnienia = priorytet
Jeśli masz kilka magazynów, braki często wynikają nie z braku towaru, tylko z routingu i źródła wysyłki.
Najpierw przypisz magazyn i źródło wysyłki, dopiero potem sprawdzaj dostępność. Inaczej OOS będzie zły, bo sprawdzasz „nie ten magazyn”.
Jeśli towar jest w innym magazynie, zadanie powinno tworzyć transfer, a nie „kup to”. To skraca czas i koszty.
Brak to nie zawsze „czekamy na dostawę”. Czasem lepsza jest alternatywa albo split — ale tylko według reguł.
Brak ma swój czas. Jeśli go przekroczysz, koszt rośnie wykładniczo (SLA, negatywy, anulacje).
Braki zawsze będą. Różnica jest taka, czy są pod kontrolą i czy wiesz, dlaczego powstają.
Ile zamówień trafia do STOP z powodu braków (trend tygodniowy).
Median/95p. Jeśli rośnie – zadania nie działają albo brak właściciela.
OOS:STAN vs OOS:REZERWACJA vs OOS:MW – to mówi, co naprawiać.
Split/dosyłki/anulacje/negatywy – koszt procesu, nie tylko „brak towaru”.
Szybkie wdrożenie działa lepiej niż „idealny projekt”, który nigdy nie startuje.
Braki to „wyjątki”. Żeby działały, muszą być częścią porządku statusów, priorytetów i (opcjonalnie) splitu.
Braki powinny być zdarzeniem w flow, a nie ręczną decyzją operatora.
Braki muszą mieć osobną kolejkę, inaczej rozwalają priorytety produkcji.
Jeśli często wysyłasz częściowo, reguły splitu muszą być spójne z OOS.
Braki to jeden typ STOP. Inne STOP to płatność, adres, fraud – warto spiąć to w jeden model.
Podeślij: 10 zamówień z brakami, listę magazynów, reguły rezerwacji i statusy. Dostaniesz: model STOP, tagi przyczyn, automaty wykrycia/odblokowania, szablony zadań i KPI.