Połączenie sklepu internetowego z magazynem: jak uniknąć niespójnych stanów magazynowych

Problem nie powstaje, gdy dwa systemy ze sobą rozmawiają: powstaje, gdy podają różne liczby, a nikt wcześniej nie zdecydował, któremu z nich wierzyć. Sprzedaż sztuki, której nie ma, kosztuje zwrot pieniędzy, przeprosiny, a czasem klienta; zablokowanie sztuki, która jest, kosztuje sprzedaż, której nikt nie liczy. Połączenie sklepu internetowego z magazynem oznacza przede wszystkim ustalenie, kto decyduje, i co się dzieje, gdy coś pójdzie nie tak.

Część techniczna jest najprostsza. Trudne decyzje mają charakter handlowy i trzeba je podjąć przed połączeniem: później stają się prowizorką.

Stan magazynowy i dostępność sprzedażowa to nie ta sama liczba

Najkosztowniejsza pomyłka dotyczy różnicy między tym, ile sztuk jest w magazynie, a tym, ile można teraz sprzedać. Między tymi dwiema liczbami mieści się wszystko, co zostało już komuś obiecane.

• Stan fizyczny: to, co liczy się na półkach, łącznie ze zwrotami jeszcze nieumieszczonymi z powrotem.
• Zaangażowane: sztuki z przyjętych, a jeszcze niewysłanych zamówień, w tym sprzedaż dokonana w sklepie stacjonarnym, telefonicznie i przez przedstawicieli handlowych.
• W drodze: towar zamówiony u dostawcy, z datą, która jest prognozą, a nie faktem.
• Zastrzeżone: zapas bezpieczeństwa, próbki, wadliwe sztuki oczekujące na weryfikację, materiał przeznaczony dla konkretnego klienta.

Dostępność sprzedażowa online to to, co zostaje po odjęciu tego wszystkiego. Jeśli publikowana liczba to stan fizyczny, sprzedają Państwo także to, co jest już czyjeś.

Jedno oficjalne źródło, ustalone przed połączeniem

Gdy dwa systemy się rozjeżdżają, jeden z nich musi mieć rację z definicji, a nie w wyniku dyskusji. Trzy możliwe rozwiązania wraz z przypadkiem, w którym każde z nich się sprawdza.

Rozwiązania, w których oba systemy mogą zmieniać dostępność tego samego kodu, generują niespójności najtrudniejsze do odtworzenia: dwie prawdy i brak arbitra.

Ostatnia sztuka: sekwencja, która wszystko psuje

Przypadkiem, który trzeba zaprojektować, nie jest zwykła sprzedaż, lecz sprzedaż równoczesna. Przykładowa sekwencja, przy jednej dostępnej sztuce.

1. O 10:31 klient online wkłada sztukę do koszyka. Jeśli koszyk niczego nie rezerwuje, sztuka pozostaje dostępna do sprzedaży dla każdego.
2. O 10:32 właściciel sprzedaje tę samą sztukę w sklepie stacjonarnym i odpisuje ją z systemu do zarządzania firmą.
3. O 10:33 klient online płaci. Sklep przyjmuje zamówienie, bo jego kopia dostępności nadal wskazuje poprzednią wartość.
4. O 10:35 synchronizacja wyrównuje liczby, a dostępność spada poniżej zera. Sztuka jest jedna, zamówienia są dwa.
5. O 10:36 ktoś musi to zauważyć. Jeśli nie ma powiadomienia, zauważy to magazynier podczas kompletacji albo klient, gdy nic nie otrzyma.

Trzy dźwignie ograniczające ten przypadek: rezerwowanie dostępności w momencie płatności, a nie wysyłki, skrócenie interwału synchronizacji dla kodów o niskim stanie oraz wcześniejsze ustalenie, kto ma pierwszeństwo, gdy dojdzie do takiej sytuacji. Żadna z nich jej nie eliminuje: równoczesność to fakt, a nie błąd do poprawienia.

Gdy synchronizacja zawodzi, a prędzej czy później zawiedzie

Połączenie między dwoma systemami się przerywa: prace konserwacyjne, wygasłe dane dostępowe, zmieniony kod, awaria sieci. Pytanie nie brzmi, czy to się zdarzy, lecz co dzieje się w międzyczasie.

• Niedostarczone zmiany pozostają w kolejce i są przetwarzane po kolei, gdy połączenie wraca, zamiast się gubić.
• Zmiana przekazana dwukrotnie nie może odpisać towaru dwa razy. Przesyła się wynikową wartość zamiast różnicy albo każdy ruch magazynowy ma identyfikator, który uniemożliwia jego podwójne zastosowanie.
• Jeśli synchronizacja jest zatrzymana od określonego czasu, ktoś otrzymuje powiadomienie. Połączenie zerwane w milczeniu jest gorsze niż jego brak, bo liczby nadal wyglądają na aktualne.
• Okresowe uzgadnianie danych porównuje oba systemy kod po kodzie i tworzy listę różnic do przejrzenia, a nie automatyczną korektę, która ukrywa przyczynę.

Bufor bezpieczeństwa czy sprzedaż do zera: to decyzja handlowa

Utrzymywanie kilku sztuk niedostępnych do sprzedaży online zmniejsza liczbę anulowań, ale zamraża towar; sprzedaż do ostatniej sztuki wykorzystuje cały magazyn i zwiększa liczbę wyjątków. Nie ma odpowiedzi technicznej: zależy to od tego, ile kosztują Państwa obie te rzeczy.

• Bufor ma sens przy kodach sprzedawanych w kilku kanałach i szybko rotujących.
• Przy kodach wolno rotujących i o wysokiej wartości bufor to zamrożone pieniądze: lepiej sprzedawać do zera i obsłużyć wyjątek, gdy się pojawi.
• Dla produktów na zamówienie dostępność nie jest właściwą liczbą: obietnicą jest termin realizacji i tak też trzeba go zapisać.
• Inwentaryzacja nigdy nie zgadza się idealnie z systemem, przez uszkodzenia, braki i błędy lokalizacji: bufor wchłania także to.

Przypadki graniczne do przetestowania przed uruchomieniem

Zanim sklep zostanie udostępniony publicznie, trzeba sprawdzić przypadki, które nigdy nie pojawiają się podczas prezentacji — z prawdziwym towarem i prawdziwymi ludźmi.

1. Równoczesna sprzedaż ostatniej sztuki w dwóch kanałach, przy aktywnej synchronizacji.
2. Zamówienie anulowane przez klienta i zamówienie anulowane przez Państwa: sztuka wraca do sprzedaży, sprawdza się, w jakim czasie.
3. Otrzymany zwrot: sztuka wraca jako dostępna do sprzedaży, do weryfikacji albo jako odpad, i ustala się, kto o tym decyduje.
4. Produkt z wariantami rozmiaru, koloru lub opakowania: dostępność zarządzana jest na poziomie wariantu, nie produktu nadrzędnego.
5. Zestawy i produkty złożone: co dzieje się z zestawem, gdy kończy się jeden z jego elementów.
6. Połączenie przerwane na godzinę w trakcie sprzedaży i następnie przywrócone: żaden ruch magazynowy nie zaginął, żaden nie został zastosowany dwukrotnie.
7. Nowy kod utworzony w systemie do zarządzania firmą: kiedy pojawia się online i z jakimi minimalnymi danymi.

Czego ten przewodnik nie obejmuje

Tutaj mowa jest o spójności dostępności między systemami. Sposób fizycznej organizacji magazynu — lokalizacje, ruchy magazynowe, inwentaryzacje — to inny problem, który czasem jest prawdziwą przyczyną błędnych liczb. Również weryfikacje, jakie trzeba przeprowadzić przed obiecaniem integracji dwóch programów, gdy jeden z nich nie został zaprojektowany do współpracy z innymi, są omówione osobno.