Prognoza mówi, ile sprzedasz. Ale między „sprzedasz 300 sztuk w październiku" a „zamów 250 sztuk do 4 września u tego dostawcy" stoi kilka nudnych liczb: czas dostawy, minimalna wielkość zamówienia, opakowanie zbiorcze, cena zakupu. To są master data — dane podstawowe. Najmniej efektowna część planowania zakupów i jednocześnie ta, która decyduje, czy plan da się wykonać.
Czym są master data?
Master data (dane podstawowe) to informacje, które opisują Twoje produkty i warunki współpracy z dostawcami — w odróżnieniu od danych transakcyjnych, które opisują zdarzenia. Sprzedaż z wczoraj to transakcja. Stan magazynowy to zdjęcie chwili. A to, że dostawca wozi towar 21 dni, pakuje po 40 sztuk w karton i nie przyjmuje zamówień poniżej 200 sztuk — to master data. Zmieniają się rzadko, ale gdy są błędne, psują każdą decyzję liczoną na ich podstawie.
Jeśli prowadzisz magazyn w Subiekcie GT, Subiekcie nexo albo Navireo, znasz je jako kartoteki towarów. W Comarch ERP Optima, Comarch ERP XL czy enova365 — jako karty towarów i cenniki. WAPRO Mag, Sage Symfonia, Streamsoft Prestiż czy Raks SQL mają swoje odpowiedniki pod innymi nazwami. Nazwa jest inna, idea ta sama: jedno miejsce, w którym system trzyma prawdę o produkcie.
W e-commerce kluczem, który spina to wszystko, jest SKU — unikalny identyfikator produktu. Bez spójnych identyfikatorów nie połączysz sprzedaży ze stanami ani kartoteki z zamówieniem — i żadna analiza nie ruszy.
Jakie master data wykorzystuje Planislav i co dzięki nim działa
Planislav do działania potrzebuje tylko historii sprzedaży. Ale każde pole master data, które dodasz, włącza konkretną funkcję planu:
- Czas dostawy (lead time) — odpowiada na pytanie „kiedy zamówić". Zamówienie musi wyjść odpowiednio wcześnie, żeby towar zdążył przed wyczerpaniem zapasu. Przy produktach sezonowych to podwójnie ważne: im dłuższy czas dostawy, tym wcześniej trzeba zobaczyć nadchodzący szczyt — dlatego sezonowość sprzedaży i lead time zawsze pracują razem. Nieaktualny czas dostawy to najprostsza droga do braku towaru, a brak towaru kosztuje więcej, niż widać na pierwszy rzut oka.
- Minimalna wielkość zamówienia (MOQ) — dolna granica „ile zamówić". Plan, który proponuje 30 sztuk u dostawcy z MOQ 200, nie jest planem, tylko sugestią do ręcznego poprawienia.
- Opakowanie zbiorcze (wielokrotność) — zamówienie zaokrągla się do pełnych kartonów czy palet. Drobiazg, dopóki nie policzysz, ile razy w roku ktoś poprawia „247 sztuk" na „240, bo karton po 40".
- Dostawca — pozwala złożyć jedną listę zakupową na dostawcę zamiast osobnej decyzji per produkt, i planować w rytmie, w którym u danego dostawcy faktycznie zamawiasz.
- Cena zakupu — zamienia sztuki w złotówki: wartość zamówienia, zamrożony kapitał i analizę ABC, czyli wiedzę, które produkty robią wynik, a które tylko zajmują półkę.
- Zapas bezpieczeństwa (w dniach lub sztukach) — poduszka na wahania popytu i spóźnienia dostaw. Czym jest i ile go trzymać — o tym osobno w artykule o zapasie bezpieczeństwa.
- Nazwa, kategoria, zdjęcie — nie wpływają na obliczenia, ale decydują, czy plan czyta się w 5 minut, czy w godzinę.
Brakujące pola nie blokują planu — system przyjmuje wtedy rozsądne wartości domyślne. Różnica jest taka, że plan bez master data działa, a plan z master data wie o Twoim biznesie.
Dlaczego zarządzanie danymi jest trudne
Bo dane podstawowe psują się po cichu. Nikt nie dostaje powiadomienia „lead time tego dostawcy właśnie przestał być aktualny".
Typowe scenariusze wyglądają tak. Kartoteka została wypełniona raz, przy zakładaniu produktu — czas dostawy wpisany trzy lata temu, gdy dostawca był inny. Ten sam towar istnieje pod trzema indeksami, bo dostawca zmienił kod, a ktoś w międzyczasie założył drugą kartotekę „na chwilę". Pole EAN trzyma kod dostawcy, MOQ siedzi w polu uwag, a jednostką raz jest sztuka, raz opakowanie — zależnie od tego, kto wprowadzał. Sprzedajesz zestawy, ale magazyn schodzi z komponentów, więc sprzedaż i stany mówią o innych bytach. I najważniejsze: nikt nie jest właścicielem tych danych — zakupy wpisują swoje, magazyn swoje, e-commerce swoje.
Żaden z tych problemów nie jest widoczny na co dzień. Widoczne są skutki: zamówienia poprawiane ręcznie, brakujące bestsellery i nadwyżki produktów, których nikt nie zamawiał „aż tyle".
Dlaczego integracja systemów jest trudna
Na papierze to proste: każdy system ma towary, dokumenty i stany magazynowe. W praktyce standardowe dane nie oznaczają standardowego użycia — każda firma używa tych samych pól inaczej.
Co jest „sprzedażą"? W jednej firmie paragon, w drugiej faktura, w trzeciej dokument WZ. Zwrot bywa sprzedażą ujemną albo osobnym typem dokumentu. Stan magazynowy bywa fizyczny albo dostępny — po odjęciu rezerwacji, które każdy system liczy po swojemu. Do tego magazyny wirtualne, konsygnacja, towar w drodze. Dwie firmy na tym samym Subiekcie GT potrafią używać go na dwa zupełnie różne sposoby — a co dopiero porównanie instalacji Comarch ERP Altum z iHurt, Corax, PC-Market czy LoMag.
Osobna liga to systemy branżowe: Gastro w gastronomii, KS-APTEKA w aptekach, motoFirma w motoryzacji. Każdy z nich modeluje towar tak, jak wymaga branża — i słusznie, tylko że „standard wymiany danych" robi się wtedy pojęciem czysto teoretycznym. Dlatego integracja to nigdy nie jest „podłączymy API i gotowe". To za każdym razem odpowiedź na pytanie: co te dane znaczą w tej konkretnej firmie.
Od czego zacząć: porządki w wersji 80/20
Nie porządkuj wszystkiego. Porządkuj to, co zmienia decyzje:
- Krok 1. Zacznij od produktów A. Analiza ABC wskaże 20% produktów, które robią 80% wyniku — tam błędna kartoteka kosztuje najwięcej.
- Krok 2. Pięć pól, które robią różnicę: czas dostawy, MOQ, opakowanie zbiorcze, dostawca, cena zakupu. Reszta może poczekać.
- Krok 3. Czas dostawy policz, nie zgaduj: data dostawy minus data zamówienia z ostatnich trzech dostaw. Tyle wystarczy.
- Krok 4. Aktualizuj przy okazji, nie projektem. Każde złożone zamówienie to moment, żeby sprawdzić jedną kartotekę. Porządki „na raz, na kwartał" kończą się jak każdy taki projekt.
I jedna rzecz, której master data nie zastąpią: prognozy. Aktualna kartoteka powie, jak zamawiać, ale nie ile się sprzeda — średnia z 30 dni to za mało, żeby na to odpowiedzieć.
Jak robi to Planislav
W Planislav wgrywasz historię sprzedaży (to jedyny wymagany plik), a master data dodajesz plikiem albo przez integrację — w takim zakresie, w jakim je masz. System liczy plan od pierwszego dnia i doprecyzowuje go z każdym uzupełnionym polem. Jeśli poprawisz coś ręcznie, Twoja poprawka zostaje — synchronizacja z integracji jej nie nadpisze.
Efekt jest zawsze ten sam: lista zakupowa „zamów X sztuk do dnia Y u dostawcy Z", która zna Twoje czasy dostaw, minima i kartony. Przestań zgadywać — sprawdź na swoich danych.