← Wszystkie artykuły

Stan minimalny dla każdego produktu: dlaczego działa przy 50 SKU i cicho psuje się przy 2000

Zespół Planislav··14 min czytania
Stan minimalny 240 sztuk na tle popytu w czasie dostawy: 63 sztuki poza sezonem, 525 sztuk w szczycie

Każdy system, w którym prowadzisz magazyn, ma pole „stan minimalny". Wpisujesz liczbę, a gdy stan spadnie poniżej, system podświetla produkt albo dokłada go do zamówienia. Skąd ta liczba, to osobne pytanie, i wrócimy do niego za chwilę. Przy 50 produktach próg wystarcza, bo prawdziwym planistą jesteś Ty, a on tylko przypomina. Przy 2000 produktach próg zostaje sam. Ten artykuł jest o tym, co wtedy naprawdę liczy Twój system, dlaczego jeden próg dla wszystkich SKU zawodzi w przewidywalny sposób i ile to kosztuje.

Skąd się bierze stan minimalny (reorder point)

Podręcznikowo stan minimalny to punkt ponownego zamówienia, po angielsku reorder point (ROP): poziom zapasu, przy którym trzeba złożyć zamówienie, żeby towar zdążył przed wyczerpaniem. Wzór ma dwa składniki, popyt w czasie dostawy i zapas bezpieczeństwa:

ROP = średnia dzienna sprzedaż × czas dostawy w dniach + zapas bezpieczeństwa

Przykład: sprzedajesz średnio 10 sztuk dziennie, dostawca wozi 21 dni, zapas bezpieczeństwa to 30 sztuk. ROP = 10 × 21 + 30 = 240. Gdy stan spada do 240, zamawiasz. O tym, jak policzyć drugi składnik, jest osobny artykuł o zapasie bezpieczeństwa.

Wzór jest poprawny. Problem tkwi w założeniach, których zwykle nikt nie czyta: średnia dzienna sprzedaż jest stała w czasie, wahania wokół niej rozkładają się symetrycznie, czas dostawy się nie zmienia, a o każdym produkcie decyduje się osobno, niezależnie od reszty. Tak wygląda to w podręcznikach (przykład wykładu z University of Iowa) i tak samo opisuje to Lokad, który w nagłówku własnego poradnika dopisał, że podręcznikowe podejście jest „vastly dysfunctional". Ani jedno z tych założeń nie jest prawdziwe w sklepie z sezonem, długim ogonem produktów i dostawcą, który raz wozi 14 dni, a raz 60.

Zanim pójdziemy dalej: skąd wziął się Twój próg?

Wzór wyżej zakłada, że ktoś go użył. Zanim przejdziesz do zestawienia systemów, cztery pytania, na które warto odpowiedzieć sobie szczerze:

  • W jaki sposób ustawiłeś stan minimalny? Policzyłeś go z czasu dostawy i sprzedaży, czy wpisałeś „10, bo okrągło", „jeden karton", „tyle co przy podobnym produkcie", „tyle, żeby nie zabrakło"?
  • Czy patrzyłeś przy tym na historię sprzedaży tego produktu, czy na ostatnie dwa tygodnie i przeczucie?
  • Kiedy ostatnio ktoś ten próg zmienił? Wiesz kto i dlaczego?
  • Ile produktów ma dziś dokładnie ten sam próg, bo ustawiłeś go zbiorczo?

Nie znamy badania, które policzyłoby, jak polskie sklepy ustawiają progi (jeśli znasz, napisz). Wiemy za to, jak projektują to narzędzia. Dokumentacja InsERT opisuje stan minimalny jako pole, które „służy do filtrowania na listach", nie jako wynik obliczeń, a operacja zbiorcza wpisuje jedną liczbę do wszystkich zaznaczonych kartotek. W Base.com próg wpisujesz w puste pole, bez podpowiedzi. WAPRO opublikowało poradnik o generatorze zamówień z uzasadnieniem, że „niewiele osób korzysta z generatora zamówień (mało zgłaszanych pytań, wątpliwości)", czyli nawet tam, gdzie narzędzie potrafi coś policzyć, mało kto z tego korzysta. Żaden z systemów z zestawienia niżej nie zapyta, skąd wzięła się liczba, i żaden nie powie, kiedy przestała pasować.

Reszta tego artykułu zakłada najlepszy przypadek: próg policzony ze wzoru, z historii sprzedaży, z aktualnym czasem dostawy. Jeśli u Ciebie wygląda to inaczej, każdy z opisanych niżej problemów zaczyna się wcześniej.

Co naprawdę liczy Twój system, gdy mówi „zamów"

Przejrzeliśmy dokumentację systemów, na których pracuje większość polskiego e-commerce (stan na wrzesień 2026). Interesowały nas trzy rzeczy: kto wpisuje próg, z czego wynika proponowana ilość i czy czas dostawy w ogóle wchodzi do wyliczenia.

Base.com (dawniej BaseLinker). Jedyny parametr zakupowy na karcie produktu to „Stan – próg", osobno dla każdego magazynu. Wpisujesz go ręcznie, a masowo tylko przez import CSV, bo z poziomu panelu „nie ma takiej możliwości". Funkcja „Prognozowanie dostaw" wylicza ilość do zamówienia jako średnią sprzedaż z ostatnich 7, 14, 30, 60 lub 90 dni pomnożoną przez liczbę dni zapasu, którą podajesz; opcjonalnie dodaje próg i odejmuje stan bieżący. Te ustawienia dotyczą całego przebiegu, nie pojedynczego produktu. Czas dostawy, sezonowość, minimum logistyczne dostawcy i opakowanie zbiorcze nie występują w formularzu. Dla kilkudziesięciu produktów o stabilnej sprzedaży to wystarczająca funkcja, i dokładnie taką rolę pełni.

Polskie systemy ERP i magazynowe. Tu jest więcej opcji, ale mechanika okazuje się zaskakująco podobna. Dla każdego systemu: jaki jest próg, skąd bierze się ilość do zamówienia i czy czas dostawy wchodzi do wyliczenia.

  • Subiekt GT — próg: stan minimalny, wpisywany ręcznie (zbiorczo: jedna liczba dla zaznaczonych). Ilość: brak wbudowanego generatora; zamówienie do dostawcy wystawiasz ręcznie lub przez dodatki partnerów. Czas dostawy w wyliczeniu: nie.
  • Subiekt nexo PRO — próg: ilość minimalna i optymalna, na magazyn. Ilość: ilość optymalna minus stan dostępny (plus zamówienia od klientów). Czas dostawy w wyliczeniu: nie (pole istnieje, nie wchodzi do wyliczenia).
  • Comarch ERP Optima — próg: ilość minimalna, maksymalna, „zamawiać po". Ilość: dopełnienie do stanu min/max albo raport braków: sprzedaż za okres (domyślnie poprzedni miesiąc) minus stan minus otwarte zamówienia. Czas dostawy w wyliczeniu: nie.
  • WAPRO Mag — próg: stan min/max. Ilość: generator bierze największą z wartości z kilku sekcji (dopełnienie do max, rozchody z okresu × dni zapasu, regresja liniowa). Czas dostawy w wyliczeniu: tylko do wyboru dostawcy.
  • Symfonia Handel — próg: stany min/max, na magazyn. Ilość: zamówienia od klientów plus różnica do stanu minimalnego. Czas dostawy w wyliczeniu: nie (w wersji ERP: osobny moduł).
  • enova365 — próg: stan min/max, na magazyn. Ilość: według obrotów w okresie albo dopełnienie do stanu min/max. Czas dostawy w wyliczeniu: nie potwierdzono.
  • Streamsoft Prestiż — próg: stan min/max, mogą być naliczane ze średniej sprzedaży z N dni. Ilość: zamówienia klientów plus stan min/max; sugestia uwzględnia czas dostawy i dni wolne. Czas dostawy w wyliczeniu: tak.

Prawdziwa prognoza (taka, która próbuje wyłapać sezonowość i trend) pojawia się dopiero w osobno licencjonowanych modułach: w Comarch ERP XL i w Symfonia ERP. Ten drugi wymaga, żeby użytkownik ustawił dla produktu „rozmiar ramki" analizy, a dokumentacja uczciwie dodaje: „Nie ma jednego wspólnego ustawienia ramki idealnego dla wszystkich przypadków". Czyli prognoza jest, ale ktoś musi ją nastroić osobno dla każdego produktu.

Wspólny mianownik wszystkich tych systemów: próg wpisuje człowiek; proponowana ilość to dopełnienie do jakiegoś poziomu; jeśli w ogóle patrzą na historię sprzedaży, to jako na płaską średnią albo sumę z wybranego okna; czas dostawy prawie nigdy nie wchodzi do wyliczenia. Najuczciwiej ujęła to dokumentacja WAPRO w poradniku o generatorze zamówień: „generator nie potrafi odróżnić czy brak sprzedaży w wybranym okresie wynika z rzeczywistego braku popytu, czy tylko z fizycznego braku towaru w magazynie". To zdanie dotyczy każdego narzędzia, które liczy średnią z ostatnich N dni.

Dlaczego jeden próg dla wszystkich SKU zawodzi w przewidywalny sposób

Przy małej liczbie produktów żaden z poniższych problemów nie boli, bo widzisz każdy produkt na oczy. Skala je włącza.

1. Próg nie starzeje się głośno

Próg ustawiasz raz, zwykle przy zakładaniu kartoteki, i nawet jeśli wtedy był policzony, to na sprzedaży sprzed roku albo dwóch. Potem produkt rośnie, spada albo umiera, a próg zostaje. Joannes Vermorel z Lokad ujmuje to wprost: metoda min/max uruchomi zamówienie „no matter what", więc produkt, który gaśnie od roku, i tak zostanie domówiony, a odpisy zapasu są w nią wpisane z założenia. Żeby to działało, próg trzeba by rewidować niemal codziennie. Przy 2000 SKU nikt tego nie robi, a systemy w tym nie pomagają: w Base.com masowa zmiana progu wymaga importu CSV, w Subiekcie GT zbiorcza operacja wpisuje jedną liczbę do wszystkich zaznaczonych kartotek. Wróć do czterech pytań z początku: jeśli odpowiedź na „kiedy ostatnio ktoś zmienił próg" brzmi „nie pamiętam", to nie jest wyjątek, tylko domyślny stan każdego systemu z zestawienia.

2. Sezonowość: ten sam próg jest za niski przed szczytem i za wysoki po nim

Wróćmy do przykładu: średnio 10 sztuk dziennie, 21 dni dostawy, próg 240. Tyle że „średnio" to fikcja księgowa. Załóżmy, że w szczycie ten produkt schodzi po 25 sztuk dziennie, a poza sezonem po 3.

Przed szczytem stan spada do 240 i system zamawia. Przez 21 dni dostawy sprzedasz 25 × 21 = 525 sztuk. Masz 240. Brakuje 285 sztuk, czyli mniej więcej 11 dni bez towaru w najlepszym momencie roku. Poza sezonem ten sam próg 240 to 80 dni sprzedaży, a system i tak domawia, bo stan spadł poniżej progu. Jeden produkt, jeden próg, dwa różne błędy: brak w szczycie, nadmiar w dołku. Żeby próg był trafny, musiałby wynosić około 555 sztuk przed szczytem i około 93 poza sezonem. Żaden z opisanych wyżej systemów nie zmieni go sam z wyprzedzeniem; Streamsoft potrafi przeliczyć próg ze średniej z ostatnich dni, ale taka średnia dogania sezon, zamiast go wyprzedzać.

To nie jest kwestia niedopracowanego wzoru, tylko konsekwencja założenia o stałym popycie. Tunc, Kilic, Tarim i Eksioglu policzyli w badaniu w „Omega" (2011), ile kosztuje trzymanie się stałych parametrów polityki zapasów, gdy popyt jest sezonowy lub ma trend: przy łagodnym sezonie koszt był wyższy średnio o kilkanaście procent, przy wyraźnym o ponad 30%, a w skrajnych przypadkach popytu nieregularnego polityka stała okazała się 2,3 raza droższa od dopasowanej do przebiegu popytu. O tym, jak rozpoznać sezon w swoich danych, piszemy w artykule o sezonowości sprzedaży.

3. Jeden rozkład dla bardzo różnych produktów

Wzór na ROP zakłada, że popyt wygląda tak samo dla każdego produktu, tylko z inną średnią. W praktyce w katalogu masz co najmniej trzy różne światy: bestsellery sprzedające się codziennie, produkty sezonowe i długi ogon, który sprzedaje się dwie sztuki w marcu, zero w kwietniu i pięć w maju. Dla tego ostatniego „średnia dzienna sprzedaż" opisuje dzień, który nigdy się nie zdarza. Ile jest takich produktów? W danych sklepów Walmart z konkursu M5 (30 tys. serii produkt–sklep) tylko około 7% serii miało popyt „gładki"; w dwóch innych sieciach handlowych analizowanych w tej samej pracy było to 11% i 23%, a reszta to popyt sporadyczny albo nieregularny. Do tego dochodzi wartość: ten sam „zapas na 30 dni" znaczy co innego dla produktu za 2 zł i za 400 zł, o czym więcej w artykule o analizie ABC. Teunter, Babai i Syntetos pokazali na trzech dużych rzeczywistych zbiorach danych, że nawet sztywny poziom obsługi przypisany do klasy ABC daje rozwiązania „far from cost optimal". Jeden próg dla wszystkich jest jeszcze grubszym uproszczeniem.

4. Próg mówi „ile", nie mówi „kiedy" ani „które najpierw"

Z zestawienia wyżej wynika, że czas dostawy prawie nigdy nie wchodzi do wyliczenia. A to on decyduje o momencie zamówienia: Lokad przypomina, że czas dostawy działa na zapas liniowo, dwa razy dłuższy czas dostawy oznacza dwa razy większy zapas. Drugi brak jest mniej oczywisty. Próg patrzy na każdy produkt osobno, a Twoja gotówka jest jedna. Gdy tego samego dnia próg przekroczy 80 produktów, system wygeneruje 80 pozycji do zamówienia i nie powie, które z nich zamówić, jeśli budżet starcza na 50. Lokad nazywa alternatywę priorytetyzacją zamówień: każda kolejna sztuka każdego produktu ma inny oczekiwany zwrot i to według niego układa się listę, a nie według tego, kto akurat spadł poniżej progu.

Co znaczy „polityka dopasowana do towaru" (i dlaczego to nie oznacza 500 pokręteł)

Odpowiedzią nie jest ERP z 20 parametrami na kartotece, bo wtedy problem z punktu 1 wraca w większej skali: ktoś musiałby te 20 parametrów utrzymywać dla 2000 produktów. Polityka dopasowana do towaru oznacza, że dla każdego produktu osobno rozstrzyga się pięć pytań, ale rozstrzyga je system na podstawie danych, a nie człowiek na podstawie przeczucia:

  • Jak przewidywać ten konkretny produkt: po sezonie, po trendzie, czy jako popyt sporadyczny, gdzie liczy się prawdopodobieństwo sprzedaży, a nie średnia. Dlaczego średnia z 30 dni to nie prognoza, opisaliśmy osobno.
  • Ile bufora trzymać: więcej tam, gdzie brak kosztuje dużo, a popyt jest zmienny; mniej tam, gdzie produkt jest tani i przewidywalny.
  • Kiedy zamówić: prognoza na okres czasu dostawy, nie średnia z przeszłości, i nie „gdy stan spadnie poniżej".
  • Ile zamówić: z uwzględnieniem minimum dostawcy, opakowania zbiorczego i tego, co już jest w drodze. To wymaga aktualnych danych podstawowych.
  • Co najpierw, gdy pieniędzy nie starczy na wszystko.

Różnica względem progu nie polega na tym, że wzór jest bardziej skomplikowany. Polega na tym, że wejściem jest prognoza na najbliższe tygodnie zamiast średniej z ostatnich, a parametry zmieniają się razem z danymi, a nie wtedy, gdy ktoś sobie o nich przypomni.

Ile to jest warte: liczby, które da się obronić

Tu trzeba uczciwie oddzielić to, co wiadomo z badań, od tego, co jest przykładem.

Z badań wiadomo trzy rzeczy. Koszt utrzymania zapasu (kapitał, magazyn, ubezpieczenie, ryzyko przeterminowania) szacuje się w literaturze na około 20–25% wartości zapasu rocznie; to stara reguła kciuka, którą Lokad wywodzi z podręcznika Stocka i Lamberta z 1987 r. Każde 100 tys. zł nadmiarowego towaru kosztuje więc 20–25 tys. zł rocznie, zanim ktokolwiek go przeceni. Druga rzecz: w jedynym niezależnym, opublikowanym studium przypadku, jakie znaleźliśmy dla firmy podobnej skali, greckiego dystrybutora z blisko 10 tys. SKU (Nenes, Panagiotidou, Tagaras, „European Journal of Operational Research", 2010), przejście z „reguł empirycznych" zakupowców na politykę liczoną osobno dla każdego produktu obniżyło średni zapas o około 8% w pierwszym roku, bez pogorszenia poziomu obsługi i przy 3% wzroście sprzedaży. Trzecia: w metaanalizie badań o brakach towaru w handlu (Gruen, Corsten, Bharadwaj, 2002; 29 krajów, 71 tys. konsumentów) typowy sprzedawca tracił około 4% sprzedaży z powodu braków, a około połowa braków wynikała z zamawiania i prognozowania w sklepie, nie z winy dostawców. To badanie dotyczy sklepów stacjonarnych sprzed dwóch dekad, więc traktuj je jako rząd wielkości, nie jako Twoją liczbę.

A teraz przykład, z założeniami na wierzchu, żebyś mógł podstawić własne. Sklep z 2000 SKU, zapas w cenach zakupu 1,2 mln zł, przychód 8 mln zł rocznie, marża brutto 30%.

  • Koszt utrzymania zapasu: 1,2 mln × 20–25% = 240–300 tys. zł rocznie. To płacisz dziś, niezależnie od narzędzia.
  • Zapas niższy o 8% (jak w studium przypadku): 96 tys. zł gotówki wraca do firmy jednorazowo, a koszt utrzymania spada o 19–24 tys. zł rocznie.
  • Utracona sprzedaż 4% z 8 mln = 320 tys. zł, czyli 96 tys. zł marży. Jeśli połowa braków wynika z zamawiania i uda się wyeliminować połowę z nich, to 24 tys. zł marży rocznie.

Razem około 43–48 tys. zł rocznie plus 96 tys. zł uwolnionej gotówki, i to przy założeniach, które celowo trzymamy nisko. Jeśli Twój sklep ma wyraźny sezon, straty z punktu 2 (brak w szczycie, nadmiar w dołku) są wyższe niż w tym przykładzie, bo badanie Tunca i współautorów pokazuje, że koszt stałej polityki rośnie razem z amplitudą sezonu. Jeśli sezonu nie ma, a produkty rotują równo, będą niższe. Własne liczby możesz podstawić w kalkulatorze oszczędności. O tym, co składa się na koszt braku poza utraconą marżą, piszemy w artykule o koszcie braku towaru.

Kiedy stan minimalny wystarczy

Żeby nie było, że próg jest zły z definicji. Stan minimalny w Base.com albo w Subiekcie jest dobrym narzędziem, jeśli spełniasz większość z tych warunków: masz do kilkuset produktów i znasz je z pamięci, sprzedaż nie ma wyraźnego sezonu, dostawca wozi w kilka dni, a nie kilka tygodni, zamawiasz u jednego lub dwóch dostawców, próg został policzony, a nie wpisany na oko, i raz w tygodniu ktoś naprawdę przegląda listę produktów poniżej progu. W takiej firmie prognozą jesteś Ty, a próg przypomina, żeby nie zapomnieć. Problemy z tego artykułu zaczynają się wtedy, gdy któryś z tych warunków przestaje być prawdziwy, a próg zostaje, bo nikt nie ma czasu go zmienić.

Jak robi to Planislav

W Planislav nie ustawiasz progów. Wgrywasz historię sprzedaży (plikiem albo przez integrację z Base.com), a system dla każdego produktu osobno rozpoznaje wzorzec popytu: sezon, trend albo sprzedaż sporadyczną, i na tej podstawie liczy prognozę na okres czasu dostawy, nie średnią z przeszłości. Czas dostawy, minimum dostawcy, opakowanie zbiorcze i towar w drodze wchodzą do wyliczenia, jeśli je podasz. Zapas bezpieczeństwa jest liczony w dniach pokrycia na bazie prognozy tego produktu, więc przed sezonem rośnie, a po nim maleje, bez zmieniania czegokolwiek ręcznie. Efekt to lista zakupowa „zamów X sztuk do dnia Y u dostawcy Z", którą możesz sprawdzić: każdą pozycję da się rozwinąć i zobaczyć, z czego wynika. Przestań zgadywać, ile zamówić. Sprawdź na swoich danych.

Źródła