ERP – WMS: magazynowe stany zapalne

ERP – WMS
Jednym z licznych zadań oprogramowania klasy WMS jest bieżące i bardzo precyzyjne zarządzanie stanami magazynowymi. Po przetłumaczeniu na stany w rozumieniu systemów ERP, są one kluczowe dla działów sprzedażowych. Warto zatem wiedzieć, na czym polega różnica w postrzeganiu stanów magazynowych przez magazyn oraz sprzedaż.

Z uwagi na rosnącą popularność segmentu e-commerce za przykład weźmy zamówienie ze sklepu internetowego, które pojawia się w systemie ERP i jest widoczne dla działu sprzedaży. Ten, widząc zapotrzebowanie na konkretny produkt w konkretnej ilości, sprawdza w systemie ERP stan magazynowy, czyli możliwość realizacji dokonanego w sieci zakupu. Dane, jakie zostaną mu wyświetlone, będą niejako zero-jedynkowe. Co to znaczy? Osoba odpowiedzialna za realizację zamówienia zobaczy, czy na magazynie znajduje się wystarczająca ilość towaru. I to w zasadzie wszystko, ponieważ nie musi wiedzieć więcej. A już na pewno nie musi wiedzieć, jakie były losy tego towaru, co się z nim działo, jakim fizycznym operacjom podlegał. Nad odpowiedziami na te szczegółowe pytania czuwa oprogramowanie WMS, które zarządza stanami magazynowymi, aktualizując je w odpowiedzi na procesy, jakim towar podlega.

Każda firma ma własną politykę i schematy postępowania, rządzi się swoimi prawami i realizuje poszczególne procesy nieco inaczej. W obliczu tej różnorodności niezwykle trudno byłoby przedstawić wszystkie przypadki, dlatego będę posługiwał się tylko jednym przykładem potencjalnego magazynu.

Dostawa

Dla systemu WMS, i raczej również dla ERP, towar wypakowywany z samochodu nie istnieje w sensie „stanu na magazynie”. System może co najwyżej „mieć wiedzę” o planowanej dostawie. Dopiero po zaewidencjonowaniu, kontroli ilości oraz jakości, odbywa się skanowanie etykiet, co jest równoznaczne z utworzeniem określonych stanów magazynowych i pojawieniem się nowego asortymentu w systemie WMS. W dalszej kolejności jednostkom magazynowym (np. paletom) system przydziela miejsca magazynowe. Natomiast system ERP otrzymuje informację o konieczności aktualizacji stanów o nowy asortyment, ale dopiero po fizycznym zeskładowaniu towaru. Wówczas stany magazynowe widoczne w WMS oraz ERP pokrywają się i powinny się pokrywać. Dlaczego? O tym niżej.

Składowanie

Odłożenie palety na właściwym miejscu jest tylko jedną z czynności magazynowych. W dodatku – podobnie jak sam proces składowania – obarczona jest pewnym ryzykiem. Nie brakuje bowiem sytuacji, w których towar może zostać uszkodzony. Traci wówczas swoją jakość, w wyniku czego może zostać wycofany ze sprzedaży. Aby to stwierdzić, konieczne jest przeprowadzenie inwentaryzacji lub natychmiastowe zgłoszenie zaistniałej szkody w systemie WMS, dla którego uszkodzony towar wciąż będzie na stanie, ale ze zmienionym statusem jakości. Zupełnie inaczej jest w ERP, który po otrzymaniu od WMS-a komunikatu o zmianie statusu towaru, automatycznie zdejmuje go ze stanu magazynu sprzedaży i przesuwa do magazynu wirtualnego, oznaczonego jako towary uszkodzone lub – w zależności od sytuacji i asortymentu – przeterminowane. W przypadku asortymentu pochodzącego ze zwrotu jest nieco inaczej, ponieważ może on trafić do ponownego obrotu, ale po wcześniejszej kontroli jakości. Zależnie od wyniku takiej kontroli, może on powiększyć stany magazynowe w ERP lub trafić do magazynu logicznego przeznaczonego dla produktów nienadających się do sprzedaży. Wszystko odbywa się oczywiście w magazynie w systemie WMS, który na bieżąco wymienia dane z ERP i zasila jego stany.

W tym miejscu można zadać sobie pytanie – dlaczego towar uszkodzony nie jest na dobre wymazywany z systemu ERP, tylko przekazywany do wirtualnego magazynu. Odpowiedź jest prosta – nie może być rozbieżności w stanach. Jeśli towar, nieważne jaki, znajduje się fizycznie na magazynie sprzedaży, to dział sprzedażowy, za pośrednictwem ERP, musi o tym wiedzieć. W innym przypadku powstałby chaos.

Źródłem zamieszania nie są tylko uszkodzenia towaru albo zwroty, ale również zwykły ludzki błąd polegający np. na odłożeniu towaru w niewłaściwe miejsce. W konsekwencji, osoba kompletująca zamówienie nie znajdzie asortymentu tam, gdzie powinien się znajdować. W innym scenariuszu miejsce, które powinno być puste i zostało wyznaczone przez system do odłożenia nośnika, jest w wyniku błędu zajęte. Oba przypadki wymagają przeprowadzenia inwentaryzacji, która zaktualizuje stany w systemie WMS. Ten przekaże stosowne dane do ERP, który zaktualizuje stan o wynik inwentaryzacji.

Kompletacja

Interfejs wymiany danych działa również w trakcie procesu kompletowania zamówień, kiedy towary znajdujące się w zamówieniach są automatycznie blokowane przez system WMS, a następnie również przez ERP. Dzieje się tak, aby uniemożliwić włączenie do innej operacji magazynowej lub zakup towarów, które zostały już sprzedane i lada chwila powędrują do odbiorcy – dystrybutora lub końcowego.

Kompletowanie towarów pod wysyłkę jest w zasadzie ostatnim etapem, na którym mogą pojawić się niezgodności. Zazwyczaj wynikają one z błędów ludzkich, pomyłek podczas pobierania towaru, dotyczących zarówno jego ilości jak i rodzaju. Konieczna staje się wówczas inwentaryzacja, połączona z blokowaniem stanów – towarów, których dotyczą niezgodności – w systemie WMS, który stosowne dane natychmiast przekaże do ERP.

Zgodność przede wszystkim

Powyższe przykłady pokazują, że stany magazynowe, choć odnoszą się do tego samego, mogą być postrzegane nieco inaczej. Dla działu sprzedaży liczą się dostępność oraz ilość jednostek sprzedaży danego asortymentu, ponieważ na podstawie tych danych asortyment ten może pozostawać w obrocie. Co innego magazyn i system WMS, którego zadanie polega na precyzyjnym zarządzaniu dostępnością i ruchem towaru, a więc siłą rzeczy jego stany są znacznie bardziej szczegółowe. Uwzględnia również cały szereg zdarzeń oraz dowolną liczbę scenariuszy, które pisze toczące się w magazynie życie. Jednak pomimo tych wszystkich różnic, najważniejsza jest zgodność danych, ponieważ stany magazynowe, widziane oczami obydwu światów, muszą być zgodne. Jakiekolwiek rozbieżności mogłyby być źródłem kłopotów w realizowaniu zamówień oraz ognisk zapalnych pomiędzy działami.

Autor artykułu
Poleć innym
LinkedIn
Facebook
Twitter

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

The reCAPTCHA verification period has expired. Please reload the page.

Copyright
Copyright