Co to jest system OMS i jak pomaga zarządzać zamówieniami?

Klient składa zamówienie w sklepie internetowym. Kupuje trzy produkty, wybiera dostawę do punktu odbioru i płaci online.

Jeden produkt znajduje się w magazynie głównym. Drugi jest dostępny wyłącznie w sklepie stacjonarnym. Trzeci ma zostać wysłany bezpośrednio przez dostawcę.

Z punktu widzenia klienta jest to jedno zamówienie.

Z punktu widzenia firmy proces może obejmować:

• potwierdzenie płatności,
• rezerwację produktów w kilku lokalizacjach,
• utworzenie dwóch albo trzech zleceń realizacji,
• przekazanie części zamówienia do magazynu,
• wysłanie części do dostawcy,
• utworzenie kilku przesyłek,
• zebranie numerów śledzenia,
• aktualizację statusu klienta,
• wystawienie dokumentów,
• obsługę ewentualnego anulowania lub zwrotu.

Jeżeli każdy kanał sprzedaży, magazyn i dostawca działa w osobnym systemie, zarządzanie takim procesem staje się trudne.

Zamówienie może istnieć jednocześnie w:

• WooCommerce,
• panelu marketplace’u,
• BaseLinkerze,
• ERP,
• WMS,
• systemie kurierskim,
• systemie płatności,
• platformie dostawcy.

Każdy z tych systemów może posiadać własny numer, status i zakres danych.

System OMS pomaga zarządzać całym cyklem zamówienia oraz koordynować działania wykonywane przez pozostałe narzędzia.

Nie musi samodzielnie przechowywać produktów, fizycznie sterować magazynem ani wystawiać dokumentów księgowych. Może jednak decydować, co powinno wydarzyć się z konkretnym zamówieniem, gdzie ma zostać zrealizowane i kiedy proces można uznać za zakończony.

W swojej pracy spotykam firmy, które posiadają sprawny sklep, ERP, magazyn i integracje kurierskie, ale nadal nie mają jednego miejsca pokazującego rzeczywisty stan obsługi zamówienia.

Sklep pokazuje status „w trakcie realizacji”, ERP „potwierdzone”, magazyn „częściowo skompletowane”, a klient otrzymał już informację o wysyłce. Nikt nie wie, który status jest najważniejszy i co dokładnie pozostało do wykonania.

Spotykam również procesy, w których jedno zamówienie trafia do ERP dwukrotnie, ponieważ zostało przekazane jednocześnie przez sklep i BaseLinker. Z kolei anulowanie wykonane przez klienta dociera do jednego systemu, ale nie zatrzymuje kompletacji w magazynie.

Dobrze zaprojektowany OMS nie jest tylko wspólną listą zamówień. Jest warstwą koordynującą przepływ danych, decyzji i statusów pomiędzy kanałem sprzedaży, płatnością, zapasem, realizacją, wysyłką oraz obsługą posprzedażową.

Co to jest system OMS?

OMS to skrót od angielskiego określenia Order Management System, czyli systemu zarządzania zamówieniami.

OMS centralizuje informacje o zamówieniach i pomaga zarządzać ich pełnym cyklem życia.

Może obsługiwać między innymi:

• pobieranie zamówień z różnych kanałów,
• normalizację danych,
• weryfikację płatności,
• rezerwację zapasu,
• wybór miejsca realizacji,
• podział zamówienia,
• przekazanie zadań do magazynu lub dostawcy,
• kontrolę statusów,
• tworzenie i śledzenie przesyłek,
• częściową realizację,
• anulowania,
• zwroty,
• reklamacje,
• komunikację z klientem,
• raportowanie procesu.

Zakres funkcji zależy od konkretnego systemu i modelu sprzedaży firmy.

Do czego służy OMS?

OMS odpowiada przede wszystkim na pytanie:

Co powinno wydarzyć się z zamówieniem od momentu jego złożenia aż do pełnego zakończenia?

System może ustalić:

• czy zamówienie jest prawidłowe,
• czy płatność została potwierdzona,
• czy produkty są dostępne,
• gdzie powinny zostać zarezerwowane,
• który magazyn lub dostawca ma je zrealizować,
• czy zamówienie trzeba podzielić,
• jakie statusy należy przekazać do kanału sprzedaży,
• kiedy wysłać informację klientowi,
• jak obsłużyć anulowanie lub zwrot.

OMS może koordynować pozostałe systemy, nie przejmując wszystkich ich funkcji.

Czy OMS jest panelem zamówień?

Panel zamówień pokazuje listę transakcji i umożliwia ręczną zmianę statusu.

OMS może dodatkowo posiadać logikę, która:

• rozpoznaje źródło zamówienia,
• przekształca dane do wspólnego formatu,
• sprawdza dostępność w wielu lokalizacjach,
• przydziela realizację,
• dzieli zamówienia,
• kontroluje zależności pomiędzy etapami,
• wykrywa błędy i wyjątki,
• zapobiega duplikacji operacji.

Nie każdy centralny panel jest pełnym OMS.

Cykl życia zamówienia

Cykl życia może obejmować następujące etapy:

1. Utworzenie zamówienia.
2. Walidacja danych.
3. Weryfikacja płatności.
4. Kontrola dostępności.
5. Rezerwacja towaru.
6. Wybór źródła realizacji.
7. Przekazanie do magazynu lub dostawcy.
8. Kompletacja.
9. Pakowanie.
10. Wysyłka albo odbiór.
11. Dostarczenie.
12. Zamknięcie procesu.
13. Ewentualny zwrot lub reklamacja.

Nie każde zamówienie przechodzi przez wszystkie etapy.

Produkt cyfrowy nie wymaga magazynu i kuriera. Odbiór osobisty nie wymaga tradycyjnej wysyłki. Zamówienie B2B może wymagać ręcznej akceptacji i odroczonej płatności.

OMS a WooCommerce

WooCommerce przyjmuje zamówienia z własnego sklepu internetowego.

Obsługuje między innymi:

• koszyk,
• checkout,
• płatności,
• konto klienta,
• statusy zamówień,
• zwroty,
• podstawowe zarządzanie stanami.

Dla prostego sklepu WooCommerce może być wystarczającym miejscem obsługi zamówień.

OMS ma większe znaczenie, gdy firma:

• sprzedaje w wielu kanałach,
• posiada kilka magazynów,
• realizuje zamówienia przez dostawców,
• obsługuje sklepy stacjonarne,
• dzieli zamówienia na kilka wysyłek,
• potrzebuje wspólnego procesu dla różnych platform.

WooCommerce może pozostać źródłem zamówienia, a OMS przejąć jego dalszą orkiestrację.

OMS a BaseLinker

BaseLinker może pełnić wiele funkcji zbliżonych do systemu OMS.

Może centralizować zamówienia z kanałów, zarządzać statusami, przesyłkami i automatyzacjami.

W zależności od skali firmy może być:

• głównym systemem zarządzania zamówieniami,
• warstwą integrującą marketplace’y,
• źródłem zamówień dla osobnego OMS,
• narzędziem wykonującym wybrane operacje.

Dedykowany OMS może być potrzebny, gdy firma wymaga bardziej rozbudowanej logiki dotyczącej:

• wielu magazynów,
• realizacji ze sklepów stacjonarnych,
• zaawansowanego dzielenia zamówień,
• dynamicznego wyboru źródła zapasu,
• niestandardowych procesów B2B,
• własnych zasad anulowania i zwrotów,
• dużej skali operacji.

Nie zawsze potrzebne są oba systemy. Najpierw trzeba ustalić, które funkcje już realizuje BaseLinker i gdzie rzeczywiście występują ograniczenia.

OMS a ERP

ERP zarządza szerszym zakresem procesów firmy.

Może odpowiadać za:

• produkty,
• ceny,
• stany,
• kontrahentów,
• zamówienia handlowe,
• dokumenty,
• płatności,
• księgowość,
• zakupy.

OMS koncentruje się na koordynowaniu realizacji zamówienia klienta pomiędzy kanałami i systemami.

Podział może wyglądać następująco:

• OMS zarządza przebiegiem zamówienia,
• ERP tworzy dokument handlowy i rozlicza sprzedaż,
• WMS zarządza operacjami magazynowymi,
• system kurierski obsługuje przesyłkę.

ERP może posiadać własny moduł zarządzania zamówieniami i w prostszym modelu zastępować osobny OMS.

OMS a WMS

OMS decyduje, co powinno zostać zrealizowane.

WMS decyduje, jak fizycznie wykonać operację magazynową.

OMS może przekazać do WMS:

• zamówienie,
• produkty,
• ilości,
• priorytet,
• metodę dostawy,
• termin realizacji.

WMS może zwrócić:

• potwierdzenie rezerwacji,
• status kompletacji,
• informację o braku,
• status pakowania,
• potwierdzenie wydania.

OMS wykorzystuje te informacje do zarządzania całym zamówieniem oraz komunikacją z kanałem sprzedaży.

OMS a PIM

PIM zarządza informacjami produktowymi.

OMS zarządza zamówieniami.

PIM może dostarczać:

• nazwy produktów,
• parametry,
• zdjęcia,
• identyfikatory,
• informacje wymagane do sprzedaży.

OMS wykorzystuje przede wszystkim identyfikatory, warianty i dane potrzebne do prawidłowej realizacji.

Nie powinien być głównym miejscem tworzenia opisów marketingowych produktów.

OMS a CRM

CRM przechowuje historię relacji, leady, szanse sprzedażowe i zadania handlowe.

OMS przechowuje i przetwarza zamówienia.

Integracja może przekazywać do CRM:

• informację o zakupie,
• wartość zamówienia,
• produkty,
• status realizacji,
• zwrot,
• problem z dostawą.

CRM może uruchomić działania opiekuna, ale nie powinien samodzielnie sterować magazynem i przesyłką.

Centralizacja zamówień

OMS może pobierać zamówienia z:

• WooCommerce,
• marketplace’ów,
• sklepów stacjonarnych,
• aplikacji mobilnej,
• platformy B2B,
• telefonu,
• formularza handlowego,
• zewnętrznego API.

Każdy kanał może posiadać inną strukturę danych.

OMS przekształca je do wspólnego modelu operacyjnego.

Normalizacja danych zamówień

Normalizacja polega na ujednoliceniu różnych wartości.

Może obejmować:

• statusy,
• metody płatności,
• metody dostawy,
• formaty adresów,
• waluty,
• numery telefonów,
• identyfikatory produktów,
• kody krajów.

Przykładowo różne kanały mogą przesyłać metodę dostawy jako:

• parcel_locker,
• paczkomat,
• locker,
• odbiór w automacie.

OMS może przekształcić je do wspólnego typu, zachowując jednocześnie dane źródłowe.

Walidacja zamówienia

Przed rozpoczęciem realizacji system może sprawdzić:

• czy zamówienie posiada produkty,
• czy wszystkie pozycje mają SKU,
• czy adres jest kompletny,
• czy kod punktu odbioru istnieje,
• czy metoda płatności jest rozpoznana,
• czy kwota pozycji zgadza się z sumą,
• czy waluta jest obsługiwana,
• czy klient nie anulował zamówienia.

Zamówienie z błędem nie powinno przechodzić automatycznie do realizacji.

Może trafić do statusu wymagającego ręcznej kontroli.

Identyfikatory zamówienia

Jedno zamówienie może posiadać:

• ID WooCommerce,
• numer widoczny dla klienta,
• ID marketplace’u,
• ID BaseLinkera,
• ID OMS,
• numer zamówienia ERP,
• numery zleceń WMS,
• numery przesyłek.

OMS powinien przechowywać wszystkie powiązania.

Jeden identyfikator nie zastępuje pozostałych.

Numer zamówienia widoczny dla klienta

Numer prezentowany klientowi może różnić się od technicznego ID rekordu.

Ma to znaczenie przy:

• kontaktach z obsługą,
• zwrotach,
• dokumentach,
• integracji z BaseLinkerem,
• wyszukiwaniu zamówień.

OMS powinien pozwalać wyszukiwać po różnych numerach i nie zakładać, że identyfikator sklepu jest jedyną wartością.

Rozpoznawanie produktów

Pozycja zamówienia powinna zostać połączona z właściwym produktem lub wariantem.

Można wykorzystywać:

• SKU,
• EAN,
• ID produktu źródłowego,
• ID wariantu,
• mapowanie zapisane w systemie.

Nazwa produktu nie jest bezpiecznym identyfikatorem.

Może się zmienić, zawierać dodatkowy opis albo być identyczna dla kilku wariantów.

Produkty nierozpoznane

Jeżeli OMS nie potrafi połączyć pozycji z katalogiem, powinien:

• zatrzymać automatyczną realizację tej pozycji,
• oznaczyć problem,
• pokazać dane źródłowe,
• umożliwić ręczne mapowanie,
• zapisać powiązanie na przyszłość.

Nie powinien samodzielnie wybierać podobnego produktu wyłącznie na podstawie nazwy.

Weryfikacja płatności

OMS może otrzymywać informację o płatności ze sklepu, operatora albo ERP.

Powinien rozróżniać:

• płatność rozpoczętą,
• płatność oczekującą,
• płatność potwierdzoną,
• płatność odrzuconą,
• płatność częściową,
• płatność zwróconą,
• pobranie,
• odroczony termin płatności.

Utworzenie zamówienia nie jest równoznaczne z otrzymaniem płatności.

Źródło prawdy dla płatności

Trzeba ustalić, który system wiarygodnie potwierdza transakcję.

Może nim być:

• operator płatności,
• WooCommerce,
• ERP,
• system finansowy.

OMS może korzystać z informacji pośredniej, ale powinien wiedzieć, skąd naprawdę pochodzi status.

Płatność częściowa

W sprzedaży B2B albo przy droższych zamówieniach klient może wpłacić zaliczkę.

OMS może przechowywać:

• wartość zamówienia,
• kwotę zapłaconą,
• pozostałą kwotę,
• termin płatności,
• warunki rozpoczęcia realizacji.

Proces może pozwalać rozpocząć produkcję po zaliczce, ale blokować wysyłkę do czasu pełnego rozliczenia.

Kontrola ryzyka i oszustw

Przed realizacją system może przekazać zamówienie do weryfikacji ryzyka.

Może uwzględniać:

• nietypową wartość,
• różnicę adresu płatnika i odbiorcy,
• historię klienta,
• wiele nieudanych płatności,
• nietypowy kraj,
• zamówienie produktu wysokiego ryzyka.

OMS nie musi sam obliczać ryzyka. Może jednak zatrzymać proces do czasu otrzymania decyzji.

Dostępność produktu

OMS może sprawdzać dostępność w:

• magazynie głównym,
• magazynie regionalnym,
• sklepie stacjonarnym,
• magazynie dostawcy,
• produkcji,
• towarze w drodze.

Nie każda fizyczna sztuka jest dostępna do obietnicy klientowi.

Trzeba uwzględnić rezerwacje, blokady, czas realizacji i możliwość przesunięcia.

ATP – dostępność do obiecania

ATP opisuje ilość, którą firma może realnie obiecać klientowi.

Może uwzględniać:

• stan fizyczny,
• istniejące rezerwacje,
• bufor bezpieczeństwa,
• zaplanowane dostawy,
• czas transportu,
• priorytety kanałów.

Stan magazynowy równy dziesięć nie oznacza automatycznie, że można przyjąć dziesięć nowych zamówień.

Obietnica terminu dostawy

OMS może obliczać przewidywany termin na podstawie:

• dostępności produktu,
• lokalizacji zapasu,
• godziny granicznej,
• czasu kompletacji,
• harmonogramu kuriera,
• kraju odbiorcy,
• weekendów i dni wolnych,
• produkcji lub dostawy od dostawcy.

Termin pokazywany klientowi powinien wynikać z rzeczywistej możliwości realizacji.

Rezerwacja towaru

OMS może utworzyć rezerwację samodzielnie albo zlecić ją ERP lub WMS.

Trzeba określić:

• kiedy rezerwacja powstaje,
• w którym systemie,
• jak długo obowiązuje,
• kiedy jest potwierdzana,
• kiedy zostaje zwolniona,
• co zrobić w razie częściowego braku.

Rezerwacja miękka i twarda

Rezerwacja miękka może tymczasowo ograniczać dostępność, ale nie przypisywać konkretnej sztuki lub lokalizacji.

Rezerwacja twarda może być powiązana z konkretnym magazynem, partią albo pozycją zapasu.

Model zależy od etapu procesu.

Przed płatnością może wystarczyć rezerwacja czasowa. Po przekazaniu do WMS potrzebna może być konkretna rezerwacja magazynowa.

Wybór źródła realizacji

OMS może zdecydować, skąd zrealizować zamówienie.

Może uwzględniać:

• dostępność,
• odległość od klienta,
• koszt wysyłki,
• czas realizacji,
• obciążenie magazynu,
• priorytet zapasu,
• termin ważności,
• możliwość skompletowania całości.

Najbliższa lokalizacja nie zawsze jest najlepsza.

Może posiadać tylko jeden z trzech produktów, podczas gdy dalszy magazyn zrealizuje całe zamówienie w jednej paczce.

Routing zamówień

Routing oznacza przydzielanie zamówienia lub jego części do konkretnego miejsca realizacji.

Reguły mogą brzmieć:

• wybierz magazyn najbliższy klientowi,
• preferuj realizację całego zamówienia z jednego miejsca,
• wykorzystaj najpierw zapas sklepu stacjonarnego,
• nie wysyłaj produktu wielkogabarytowego z magazynu bez odpowiedniego kuriera,
• przekaż produkt określonej marki bezpośrednio do dostawcy.

Podział zamówienia

Zamówienie może zostać podzielone, gdy:

• produkty znajdują się w różnych magazynach,
• część jest dostępna od razu,
• część pochodzi od dostawcy,
• produkty wymagają innych metod transportu,
• jedna pozycja jest produktem cyfrowym,
• klient zaakceptował częściową realizację.

Podział może tworzyć kilka zleceń realizacji i kilka przesyłek.

Koszt podziału zamówienia

Podział może przyspieszyć dostawę, ale zwiększyć:

• koszty kurierskie,
• koszt pakowania,
• liczbę komunikatów,
• ryzyko pomyłki,
• złożoność zwrotu.

Reguła powinna uwzględniać zarówno czas, jak i rentowność.

Łączenie zamówień

Klient może złożyć kilka zamówień w krótkim czasie.

OMS może umożliwiać ich połączenie, jeżeli:

• należą do tego samego klienta,
• posiadają ten sam adres,
• nie rozpoczęto kompletacji,
• metoda płatności i dostawy są zgodne,
• kanał sprzedaży na to pozwala.

Łączenie powinno zachować historię i powiązanie ze wszystkimi zamówieniami źródłowymi.

Częściowa realizacja

Nie wszystkie pozycje muszą zostać wysłane jednocześnie.

OMS powinien przechowywać na poziomie każdej pozycji:

• ilość zamówioną,
• ilość zarezerwowaną,
• ilość skompletowaną,
• ilość wysłaną,
• ilość anulowaną,
• ilość zwróconą.

Sam ogólny status zamówienia może nie wystarczyć.

Zamówienie zaległe

Jeżeli produktu brakuje, pozycja może oczekiwać na dostawę.

System powinien określać:

• czy klient zaakceptował oczekiwanie,
• jaki jest przewidywany termin,
• czy pozostałe produkty mają zostać wysłane wcześniej,
• kiedy wysłać aktualizację,
• kiedy anulować pozycję.

Przedsprzedaż

Produkt może być sprzedawany przed fizycznym przyjęciem do magazynu.

OMS powinien rozróżniać:

• stan obecny,
• planowaną dostawę,
• ilość przeznaczoną do przedsprzedaży,
• zamówienia już przyjęte,
• przewidywany termin wysyłki.

Nie powinien obiecywać całej planowanej dostawy, jeżeli część została już zarezerwowana.

Dropshipping

W modelu dropshippingowym dostawca wysyła produkt bezpośrednio do klienta.

OMS może:

• rozpoznać produkt dostawcy,
• przekazać zamówienie,
• odebrać potwierdzenie,
• pobrać numer przesyłki,
• kontrolować termin realizacji,
• obsługiwać błąd lub brak zapasu.

Przekazanie zamówienia nie oznacza jeszcze jego przyjęcia przez dostawcę.

System powinien oczekiwać na potwierdzenie.

Ship from store

Produkt może zostać wysłany ze sklepu stacjonarnego.

OMS powinien uwzględniać:

• rzeczywisty stan sklepu,
• godziny pracy,
• możliwości pakowania,
• dostępność pracowników,
• obsługiwanych kurierów,
• priorytet sprzedaży lokalnej.

Sklep stacjonarny nie zawsze powinien być traktowany jak pełny magazyn wysyłkowy.

Click and collect

Klient zamawia online i odbiera produkt w wybranym punkcie.

Proces może obejmować:

1. Rezerwację zapasu.
2. Przygotowanie produktu.
3. Potwierdzenie gotowości.
4. Powiadomienie klienta.
5. Weryfikację odbioru.
6. Zakończenie zamówienia.

Informacja „zamówienie przyjęte” nie oznacza jeszcze, że produkt czeka na odbiór.

Transfer do punktu odbioru

Jeżeli produktu nie ma w wybranym sklepie, może zostać przesunięty z magazynu.

OMS powinien kontrolować:

• rezerwację w magazynie źródłowym,
• status transportu,
• przyjęcie w punkcie,
• termin odbioru,
• wygaśnięcie rezerwacji.

Statusy zamówień

Status powinien opisywać rzeczywisty etap procesu.

Możliwe statusy to:

• nowe,
• oczekujące na płatność,
• opłacone,
• weryfikowane,
• zarezerwowane,
• przekazane do realizacji,
• częściowo skompletowane,
• spakowane,
• częściowo wysłane,
• wysłane,
• dostarczone,
• anulowane,
• częściowo zwrócone,
• zwrócone.

Status główny i statusy szczegółowe

Jedno zamówienie może posiadać:

• status płatności,
• status realizacji,
• status magazynowy,
• status wysyłki,
• status dokumentu,
• status zwrotu.

Próba zapisania całego procesu w jednym statusie prowadzi do niejasności.

Zamówienie może być opłacone, częściowo skompletowane i jeszcze niewysłane.

Mapowanie statusów

Każdy kanał może używać innych statusów.

OMS powinien określić:

• jak status źródłowy jest interpretowany,
• który status wewnętrzny zostaje ustawiony,
• kiedy aktualizacja wraca do kanału,
• jak obsługiwać brak odpowiednika,
• których statusów nie wysyłać na zewnątrz.

Wewnętrzny status „oczekuje na uzupełnienie lokalizacji” nie musi być widoczny dla klienta.

Maszyna stanów

Proces zamówienia można opisać jako zestaw dozwolonych przejść.

Przykładowo:

• nowe może przejść do opłacone albo anulowane,
• opłacone może przejść do zarezerwowane,
• zarezerwowane może przejść do realizacji,
• wysłane nie powinno bez kontroli wrócić do nowe.

Maszyna stanów pomaga zablokować przypadkowe i nielogiczne przejścia.

Anulowanie zamówienia

Anulowanie może nastąpić:

• przed płatnością,
• po płatności,
• po rezerwacji,
• podczas kompletacji,
• po spakowaniu,
• po wysyłce.

Każdy etap wymaga innej reakcji.

Co powinno zrobić anulowanie?

W zależności od etapu może być konieczne:

• zatrzymanie realizacji,
• zwolnienie rezerwacji,
• anulowanie zlecenia w WMS,
• anulowanie zamówienia u dostawcy,
• anulowanie przesyłki,
• zwrot płatności,
• korekta dokumentu,
• aktualizacja kanału sprzedaży,
• powiadomienie klienta.

Zmiana jednego statusu bez wykonania pozostałych działań nie jest pełnym anulowaniem.

Anulowanie części zamówienia

Klient może zrezygnować z jednej pozycji.

OMS powinien:

• zmniejszyć ilość aktywną,
• zwolnić odpowiednią rezerwację,
• zaktualizować kwotę,
• obsłużyć częściowy zwrot płatności,
• zachować pozostałe pozycje w realizacji.

Zmiana zamówienia po złożeniu

Klient może poprosić o:

• zmianę adresu,
• zmianę metody dostawy,
• dodanie produktu,
• usunięcie pozycji,
• zmianę wariantu,
• zmianę danych faktury.

OMS powinien wiedzieć, do którego momentu zmiana jest możliwa.

Zmiana adresu po utworzeniu etykiety może wymagać anulowania przesyłki i utworzenia nowej.

Blokada edycji

Po rozpoczęciu określonego etapu system może zablokować bezpośrednią zmianę danych.

Zamiast edycji może wymagać kontrolowanej operacji, która:

• zatrzyma proces,
• cofnie rezerwację,
• zaktualizuje systemy,
• zapisze historię,
• uruchomi ponowną walidację.

Przekazanie do realizacji

OMS może utworzyć jedno albo kilka zleceń realizacji.

Zlecenie może zawierać:

• pozycje,
• ilości,
• magazyn,
• priorytet,
• termin,
• metodę dostawy,
• instrukcje pakowania,
• dane odbiorcy.

Potwierdzenie przyjęcia zlecenia powinno wrócić do OMS.

Odrzucenie zlecenia przez magazyn

WMS może odrzucić realizację z powodu:

• braku produktu,
• blokady zapasu,
• nieprawidłowego SKU,
• braku lokalizacji,
• zamknięcia magazynu,
• błędu danych.

OMS powinien zdecydować, czy:

• wybrać inne źródło,
• podzielić zamówienie,
• oczekiwać na dostawę,
• przekazać problem pracownikowi,
• anulować pozycję.

Wysyłki i przesyłki

Jedno zamówienie może posiadać wiele przesyłek.

Każda przesyłka może mieć:

• przewoźnika,
• usługę,
• numer śledzenia,
• listę produktów,
• liczbę paczek,
• status,
• datę nadania,
• datę doręczenia.

OMS powinien wiedzieć, które pozycje znajdują się w której przesyłce.

Utworzenie etykiety a wysłanie paczki

Utworzenie etykiety oznacza przygotowanie danych przewozowych.

Nie musi oznaczać, że paczka została:

• spakowana,
• odebrana przez kuriera,
• zeskanowana w sortowni,
• faktycznie wysłana.

Komunikat do klienta powinien odpowiadać rzeczywistemu zdarzeniu.

Śledzenie przesyłki

OMS może pobierać statusy takie jak:

• etykieta utworzona,
• odebrana od nadawcy,
• w transporcie,
• w doręczeniu,
• dostarczona,
• nieudana próba,
• zwrot do nadawcy.

Status dostawy może uruchamiać dalsze działania, na przykład zakończenie procesu albo kontakt z klientem.

Komunikacja z klientem

OMS może uruchamiać wiadomości dotyczące:

• przyjęcia zamówienia,
• płatności,
• opóźnienia,
• częściowej realizacji,
• gotowości do odbioru,
• wysyłki,
• doręczenia,
• anulowania,
• zwrotu.

Wiadomość powinna bazować na wiarygodnym statusie.

Nie należy informować o wysyłce tylko dlatego, że zlecenie trafiło do magazynu.

Unikanie podwójnych wiadomości

Klient może otrzymywać wiadomości ze:

• sklepu,
• OMS,
• BaseLinkera,
• ERP,
• kuriera,
• marketplace’u.

Trzeba ustalić, który system odpowiada za każdy rodzaj komunikatu.

W przeciwnym razie klient może otrzymać kilka różnych wiadomości o tym samym zdarzeniu.

Dokumenty sprzedaży

OMS może zlecać utworzenie:

• faktury,
• paragonu,
• korekty,
• dokumentu wydania,
• potwierdzenia zamówienia.

Najczęściej dokumenty powstają w ERP albo systemie księgowym.

OMS powinien przechowywać ich identyfikatory i statusy, ale nie musi być systemem księgowym.

Zwroty

Zwrot może dotyczyć całego zamówienia albo wybranych pozycji.

Proces może obejmować:

1. Zgłoszenie zwrotu.
2. Weryfikację terminu i warunków.
3. Utworzenie numeru zwrotu.
4. Przyjęcie przesyłki.
5. Kontrolę produktu.
6. Decyzję o stanie towaru.
7. Zwrot płatności.
8. Korektę dokumentu.
9. Aktualizację zapasu.
10. Zamknięcie sprawy.

RMA

RMA jest procesem autoryzacji zwrotu lub reklamacji.

Może posiadać własny numer, statusy i powiązanie z zamówieniem.

OMS może zarządzać:

• zgłoszeniem,
• pozycjami,
• powodem,
• metodą odesłania,
• decyzją,
• zwrotem środków,
• wymianą produktu.

Zwrot produktu a zwrot pieniędzy

Fizyczne przyjęcie produktu i finansowy zwrot środków są oddzielnymi zdarzeniami.

Firma może zwrócić pieniądze:

• po zgłoszeniu,
• po otrzymaniu przesyłki,
• po kontroli jakości,
• po zatwierdzeniu pracownika.

OMS powinien kontrolować, czy zwrot płatności został wykonany i w jakiej kwocie.

Wymiana produktu

Wymiana może wymagać:

• przyjęcia zwracanego produktu,
• rezerwacji nowego wariantu,
• utworzenia nowej przesyłki,
• rozliczenia różnicy ceny,
• aktualizacji dokumentów.

Nie powinna być obsługiwana jako nieudokumentowana ręczna podmiana pozycji.

Marketplace’y

Zamówienia marketplace mogą posiadać własne zasady dotyczące:

• statusów,
• terminu wysyłki,
• numerów śledzenia,
• anulowań,
• zwrotów,
• komunikacji z klientem,
• dokumentów.

OMS powinien zachować wymagane dane i terminowo aktualizować kanał.

SLA kanałów sprzedaży

Kanał może wymagać wysyłki w określonym czasie.

OMS może monitorować:

• czas od utworzenia zamówienia,
• termin przekazania do realizacji,
• termin wysyłki,
• ryzyko opóźnienia,
• brak numeru przesyłki.

Może podnosić priorytet albo wysyłać alert przed przekroczeniem terminu.

Sprzedaż B2B

Zamówienie B2B może wymagać:

• indywidualnego cennika,
• limitu kredytowego,
• akceptacji opiekuna,
• terminu płatności,
• podziału dostawy,
• rezerwacji przyszłej produkcji,
• specjalnych dokumentów.

OMS może prowadzić inny proces niż w przypadku standardowego klienta detalicznego.

Limity kredytowe

Przed przyjęciem zamówienia B2B system może sprawdzić:

• obecne należności,
• wartość aktywnych zamówień,
• dostępny limit,
• zaległe płatności,
• indywidualne wyjątki.

Decyzja może pochodzić z ERP lub systemu finansowego.

Subskrypcje i zamówienia cykliczne

OMS może obsługiwać zamówienia odnawiane regularnie.

Proces wymaga kontroli:

• terminu odnowienia,
• statusu płatności,
• aktualnej ceny,
• dostępności produktów,
• adresu klienta,
• wstrzymania lub anulowania subskrypcji.

Nieudana płatność nie powinna tworzyć kolejnych identycznych zleceń realizacji.

Orkiestracja zamówienia

Orkiestracja oznacza koordynowanie wielu działań i systemów według jednego procesu.

OMS może:

1. Odebrać zamówienie.
2. Sprawdzić płatność.
3. Zarezerwować produkty.
4. Wybrać magazyn.
5. Przekazać zlecenie.
6. Odebrać potwierdzenie kompletacji.
7. Utworzyć przesyłkę.
8. Przekazać status do kanału.
9. Zapisać dokument.

Każdy krok powinien posiadać warunek sukcesu i sposób obsługi błędu.

Automatyzacje w OMS

Automatyzacja może reagować na:

• nowe zamówienie,
• potwierdzenie płatności,
• brak produktu,
• przekroczenie terminu,
• zmianę statusu,
• częściową wysyłkę,
• anulowanie,
• zwrot.

Może:

• wybrać źródło realizacji,
• zmienić priorytet,
• utworzyć zadanie,
• wysłać wiadomość,
• uruchomić webhook,
• przekazać zamówienie do ERP,
• zablokować proces.

Reguły i wyjątki

Reguła może działać dla większości zamówień, ale proces powinien obsługiwać wyjątki.

Przykłady:

• produkt wielkogabarytowy wymaga innego kuriera,
• zamówienie powyżej określonej wartości wymaga weryfikacji,
• klient B2B posiada indywidualny magazyn,
• produkt nie może być wysłany do określonego kraju,
• zamówienie prezentowe wymaga dodatkowego pakowania.

Kolejki zadań

OMS powinien wykonywać wiele operacji asynchronicznie.

Kolejka może przechowywać:

• importy zamówień,
• rezerwacje,
• przekazania do ERP,
• zlecenia WMS,
• aktualizacje statusów,
• wiadomości,
• zwroty płatności.

Awaria jednego systemu nie powinna powodować utraty zamówienia.

Dlaczego OMS potrzebuje kolejki?

System zewnętrzny może:

• nie odpowiadać,
• odpowiadać wolno,
• przekroczyć limit API,
• odrzucić dane,
• przerwać połączenie.

OMS powinien zapisać zadanie, ponowić je zgodnie z zasadami i powiadomić administratora, jeżeli problem nie ustąpi.

Idempotencja

Idempotencja chroni przed wielokrotnym wykonaniem tej samej operacji.

Jest potrzebna przy:

• tworzeniu zamówień,
• rezerwacji towaru,
• tworzeniu dokumentów,
• przesyłkach,
• zwrotach płatności,
• aktualizacjach statusów.

Ponowienie zadania nie może stworzyć drugiego zamówienia w ERP ani zwrócić klientowi pieniędzy kilka razy.

Klucz idempotencji

Operacja może posiadać unikalny identyfikator.

System docelowy sprawdza, czy wcześniej przetworzył ten sam klucz.

Można wykorzystywać:

• ID zamówienia i typ operacji,
• ID zdarzenia,
• unikalny token,
• numer zwrotu,
• numer zlecenia realizacji.

Duplikaty zamówień

Duplikat może powstać, gdy:

• kanał wyśle dane kilka razy,
• webhook zostanie ponowiony,
• sklep i BaseLinker niezależnie przekażą zamówienie,
• pracownik uruchomi import ręcznie,
• system nie zapisze odpowiedzi po udanym utworzeniu.

OMS powinien wykrywać duplikaty na podstawie stabilnych identyfikatorów, a nie tylko nazwiska i kwoty.

Kolejność zdarzeń

Zdarzenia mogą dotrzeć w innej kolejności.

Przykładowo:

1. Zamówienie zostaje opłacone.
2. Następuje anulowanie.
3. Opóźniony webhook płatności dociera po anulowaniu.

OMS nie powinien automatycznie przywracać zamówienia do realizacji bez sprawdzenia aktualnego stanu.

Wersjonowanie zamówienia

Rekord może posiadać numer wersji lub czas ostatniej aktualizacji.

System może odrzucić starszą zmianę, jeżeli została już przetworzona nowsza.

Ma to znaczenie przy:

• równoległych aktualizacjach,
• opóźnionych webhookach,
• pracy wielu systemów,
• edycji zamówienia.

API systemu OMS

API może umożliwiać:

• tworzenie zamówień,
• pobieranie szczegółów,
• aktualizowanie statusów,
• tworzenie rezerwacji,
• rejestrowanie przesyłek,
• anulowanie pozycji,
• tworzenie zwrotów,
• pobieranie historii.

Integracja powinna obsługiwać:

• uwierzytelnianie,
• uprawnienia,
• limity,
• paginację,
• wersje API,
• błędy,
• idempotencję.

Webhooki OMS

OMS może wysyłać webhook po:

• utworzeniu zamówienia,
• potwierdzeniu rezerwacji,
• zmianie statusu,
• utworzeniu przesyłki,
• anulowaniu,
• utworzeniu zwrotu,
• zakończeniu procesu.

Odbiorca powinien:

• zweryfikować autentyczność,
• zapisać ID zdarzenia,
• obsłużyć duplikat,
• szybko potwierdzić odbiór,
• przetwarzać dalsze działania w kolejce.

Integracje synchroniczne

Operacja synchroniczna może być potrzebna, gdy wynik jest wymagany natychmiast.

Przykładem może być sprawdzenie dostępności przed potwierdzeniem obietnicy klientowi.

Ryzykiem jest zależność od szybkości i dostępności systemu zewnętrznego.

Krytyczny proces klienta nie powinien bez potrzeby czekać na kilka wolnych integracji.

Integracje asynchroniczne

Po zapisaniu zamówienia system może przekazywać je do kolejnych narzędzi w tle.

Model sprawdza się przy:

• tworzeniu dokumentów,
• przekazaniu do WMS,
• wysyłce wiadomości,
• aktualizacji CRM,
• raportowaniu.

Wymaga jednak widocznego statusu i monitoringu.

Błędy techniczne i biznesowe

Błąd techniczny może oznaczać:

• brak połączenia,
• timeout,
• awarię API,
• przekroczenie limitu,
• wygaśnięcie tokenu.

Błąd biznesowy może oznaczać:

• brak SKU,
• nieprawidłowy adres,
• brak zapasu,
• niedozwolony status,
• niezgodną kwotę,
• brak punktu odbioru.

Błąd techniczny może być ponawiany. Błąd danych zwykle wymaga poprawy.

Obsługa błędów

Każdy etap powinien określać:

• co oznacza sukces,
• jak rozpoznać błąd,
• czy można ponowić operację,
• ile razy,
• kiedy zatrzymać proces,
• kogo powiadomić,
• jak wznowić zamówienie.

Status wymagający interwencji

Zamówienie z błędem może trafić do osobnej kolejki operacyjnej.

Pracownik powinien zobaczyć:

• numer zamówienia,
• etap,
• komunikat błędu,
• dane źródłowe,
• liczbę prób,
• możliwe działania.

Sam komunikat „wystąpił błąd” nie wystarcza do skutecznej obsługi.

Monitoring OMS

Monitoring powinien obejmować:

• liczbę nowych zamówień,
• zamówienia bez płatności,
• zamówienia bez rezerwacji,
• zamówienia bez zlecenia realizacji,
• przekroczone terminy,
• kolejki,
• błędy integracji,
• częściowe realizacje,
• brak numerów przesyłek,
• niezamknięte zwroty.

Brak oczekiwanych zamówień

Brak błędów nie oznacza, że integracja działa.

Jeżeli zwykle system pobiera kilkaset zamówień dziennie, a nagle nie pobiera żadnego, może to oznaczać:

• awarię webhooka,
• problem z autoryzacją,
• zmianę endpointu,
• zatrzymaną kolejkę,
• błąd kanału sprzedaży.

Monitoring powinien wykrywać również nietypowy brak aktywności.

Alerty

Alert może zostać wysłany, gdy:

• zamówienie nie zmieniło statusu przez określony czas,
• nie udało się utworzyć rezerwacji,
• magazyn odrzucił zlecenie,
• kolejka przekroczyła limit,
• nie otrzymano potwierdzenia od dostawcy,
• przesyłka nie została nadana w terminie,
• zwrot płatności nie powiódł się.

Logi i historia zamówienia

Historia powinna pokazywać:

• źródło zamówienia,
• kolejne statusy,
• wykonane automatyzacje,
• przesłane dane,
• odpowiedzi systemów,
• ręczne zmiany,
• błędy,
• ponowienia,
• użytkownika wykonującego operację.

Obsługa powinna móc odtworzyć cały przebieg bez przeszukiwania kilku niezależnych paneli.

Raportowanie

OMS może analizować:

• liczbę zamówień,
• czas potwierdzenia płatności,
• czas rezerwacji,
• czas przekazania do realizacji,
• czas wysyłki,
• liczbę podzielonych zamówień,
• koszt realizacji,
• liczbę anulowań,
• liczbę zwrotów,
• błędy według kanałów.

Order cycle time

Całkowity czas realizacji może być mierzony od złożenia zamówienia do wysyłki albo dostarczenia.

Warto rozdzielić:

• czas oczekiwania na płatność,
• czas rezerwacji,
• czas kompletacji,
• czas pakowania,
• czas transportu.

Pozwala to ustalić, który etap rzeczywiście powoduje opóźnienia.

Wskaźnik pełnej realizacji

Można mierzyć, ile zamówień zostało zrealizowanych:

• w całości,
• za pierwszym razem,
• w obiecanym terminie,
• bez podziału,
• bez błędu.

Wysoki poziom sprzedaży nie oznacza dobrego procesu, jeżeli wiele zamówień wymaga późniejszych korekt.

Koszt realizacji

OMS może pomagać analizować:

• koszt przesyłki,
• koszt podziału,
• koszt dropshippingu,
• koszt pakowania,
• koszt zwrotu,
• koszt ręcznej obsługi błędu.

Najkrótszy czas realizacji nie zawsze oznacza najbardziej rentowną decyzję.

Bezpieczeństwo OMS

System może posiadać dostęp do:

• danych klientów,
• zamówień,
• płatności,
• adresów,
• stanów,
• integracji,
• zwrotów pieniędzy.

Powinien stosować:

• indywidualne konta,
• uwierzytelnianie wieloskładnikowe,
• ograniczone uprawnienia,
• szyfrowanie komunikacji,
• historię operacji,
• ochronę kluczy API,
• monitoring logowań,
• kopie zapasowe.

Uprawnienia użytkowników

Pracownik obsługi może potrzebować:

• podglądu zamówień,
• edycji danych przed realizacją,
• anulowania wybranych pozycji,
• tworzenia zwrotu.

Nie musi posiadać dostępu do:

• kluczy API,
• reguł routingu,
• konfiguracji integracji,
• masowych eksportów,
• nieograniczonych zwrotów płatności.

Zatwierdzanie operacji wysokiego ryzyka

Niektóre działania mogą wymagać dodatkowej akceptacji:

• zwrot dużej kwoty,
• zmiana zamówienia po wysyłce,
• ręczne oznaczenie płatności,
• usunięcie zamówienia,
• ponowne utworzenie dokumentu,
• zmiana źródła realizacji po kompletacji.

Dane osobowe

OMS może przetwarzać:

• imię i nazwisko,
• adres,
• telefon,
• e-mail,
• dane firmy,
• historię zakupów,
• informacje o zwrotach.

Firma powinna kontrolować:

• zakres danych,
• cel przetwarzania,
• dostępy,
• integracje,
• okres przechowywania,
• eksporty,
• logi.

Kopie zapasowe i odtwarzanie

Kopia powinna obejmować:

• zamówienia,
• pozycje,
• statusy,
• mapowania identyfikatorów,
• historię,
• konfigurację reguł,
• integracje,
• kolejki.

Odtworzenie bazy bez bieżącego stanu systemów zewnętrznych może spowodować ponowne wykonanie operacji.

Procedura musi uwzględniać synchronizację po awarii.

OMS gotowy czy dedykowany?

Gotowy system może oferować:

• integracje kanałów,
• statusy,
• routing,
• rezerwacje,
• zwroty,
• raporty,
• API.

Dedykowany OMS może mieć sens, gdy firma posiada:

• niestandardowy proces,
• wiele magazynów i sklepów,
• specyficzne reguły routingu,
• własne systemy,
• dużą liczbę zamówień,
• wymagania niemożliwe do obsłużenia gotowymi narzędziami.

Własny system wymaga jednak:

• analizy,
• projektu,
• programowania,
• testów,
• monitoringu,
• utrzymania,
• bezpieczeństwa,
• ciągłego rozwoju integracji.

Nie buduję dedykowanego OMS wyłącznie dlatego, że firma korzysta z kilku kanałów. Najpierw sprawdzam, czy właściwa konfiguracja BaseLinkera, ERP albo obecnych automatyzacji nie rozwiąże problemu prościej.

Kiedy firma potrzebuje OMS?

OMS ma szczególne znaczenie, gdy:

• zamówienia pochodzą z wielu kanałów,
• firma posiada kilka magazynów,
• realizacja odbywa się również ze sklepów stacjonarnych,
• część produktów wysyłają dostawcy,
• zamówienia są często dzielone,
• proces obejmuje wiele systemów,
• statusy są niespójne,
• brakuje jednego widoku całego cyklu,
• ręczna obsługa błędów zabiera dużo czasu.

Kiedy osobny OMS może być zbędny?

Pełny system może być nadmierny, gdy firma:

• sprzedaje w jednym sklepie,
• posiada jeden magazyn,
• realizuje proste zamówienia,
• nie dzieli wysyłek,
• korzysta ze sprawnie skonfigurowanego WooCommerce lub ERP,
• obsługuje niewielką liczbę zamówień.

W takim przypadku wystarczające mogą być:

• poprawne statusy WooCommerce,
• integracja z kurierem,
• BaseLinker,
• prosta automatyzacja,
• monitoring błędów.

Analiza przed wdrożeniem OMS

Przed wyborem systemu trzeba opisać:

• wszystkie źródła zamówień,
• statusy,
• płatności,
• źródła zapasu,
• magazyny,
• dostawców,
• metody dostawy,
• zasady anulowania,
• zwroty,
• dokumenty,
• komunikację.

Warto rozpisać również wyjątki i sytuacje awaryjne.

Projekt modelu zamówienia

Model powinien rozróżniać:

• zamówienie źródłowe,
• pozycje,
• płatności,
• rezerwacje,
• zlecenia realizacji,
• przesyłki,
• dokumenty,
• zwroty,
• zdarzenia.

Przechowywanie wszystkiego w jednym rekordzie utrudnia częściową realizację i zwroty.

Migracja aktywnych zamówień

Przy uruchomieniu trzeba zdecydować, co zrobić z zamówieniami będącymi już w realizacji.

Można:

• pozostawić je w starym systemie,
• zaimportować wybrane etapy,
• uruchomić OMS tylko dla nowych zamówień,
• przeprowadzić kontrolowaną migrację.

Import aktywnych procesów jest trudniejszy niż import zamkniętej historii.

Testowanie OMS

Testy powinny obejmować:

• prawidłowe zamówienie,
• nieudaną płatność,
• produkt bez SKU,
• brak zapasu,
• kilka magazynów,
• podział zamówienia,
• częściową wysyłkę,
• dropshipping,
• odbiór osobisty,
• anulowanie,
• częściowy zwrot,
• powtórzony webhook,
• awarię ERP,
• awarię WMS,
• opóźnione zdarzenie.

Środowisko testowe

Testy powinny korzystać z osobnych:

• kont kanałów,
• kluczy API,
• magazynów,
• serii dokumentów,
• operatorów płatności,
• integracji kurierskich,
• adresów e-mail.

Test zwrotu płatności nie powinien przypadkowo zwracać środków prawdziwemu klientowi.

Uruchomienie etapowe

System można uruchomić najpierw dla:

• jednego kanału,
• jednego magazynu,
• wybranej kategorii produktów,
• jednego kraju,
• ograniczonej grupy zamówień.

Pozwala to sprawdzić reguły bez ryzyka objęcia całej sprzedaży błędną konfiguracją.

Tryb obserwacyjny

OMS może początkowo obliczać, jaką decyzję podjąłby, ale nie wykonywać jej automatycznie.

Może zapisywać:

• wybrane źródło realizacji,
• planowany podział,
• przewidywany termin,
• wykryte błędy.

Porównanie z decyzjami pracowników pomaga zweryfikować reguły routingu.

Dokumentacja

Dokumentacja OMS powinna zawierać:

• źródła zamówień,
• model danych,
• mapowanie statusów,
• reguły płatności,
• zasady rezerwacji,
• routing,
• anulowania,
• zwroty,
• integracje,
• obsługę błędów,
• procedury awaryjne.

Właściciel procesu

OMS powinien posiadać osobę odpowiedzialną za:

• statusy,
• reguły,
• integracje,
• jakość danych,
• monitoring,
• zmiany procesu,
• dokumentację.

Bez właściciela system stopniowo wypełnia się wyjątkami, których nikt nie kontroluje.

Najczęstsze błędy we wdrożeniach OMS

Brak jednego źródła prawdy o statusie

WooCommerce, ERP i BaseLinker pokazują różne etapy i wzajemnie je nadpisują.

Dwie drogi importu zamówień

Sklep i system pośredni niezależnie tworzą ten sam rekord.

Łączenie produktów po nazwie

Zmiana tytułu powoduje brak rozpoznania lub błędne mapowanie.

Brak kontroli płatności

Nieopłacone zamówienie trafia do realizacji.

Rezerwacja w kilku systemach

Każdy system niezależnie zmniejsza dostępny stan.

Brak zasad zwalniania rezerwacji

Anulowane zamówienia blokują produkty przez wiele dni.

Nieprawidłowy routing

System wybiera najbliższy magazyn, ale dzieli zamówienie na kilka kosztownych przesyłek.

Brak obsługi częściowej realizacji

Jedna brakująca pozycja blokuje wysyłkę całego zamówienia bez decyzji biznesowej.

Jeden status dla całego procesu

Nie wiadomo, czy problem dotyczy płatności, magazynu czy wysyłki.

Informacja o wysyłce po utworzeniu etykiety

Klient otrzymuje komunikat, choć paczka nadal znajduje się w magazynie.

Brak idempotencji

Ponowienie tworzy drugi dokument, przesyłkę albo zwrot płatności.

Założenie prawidłowej kolejności zdarzeń

Opóźniony webhook cofa zamówienie do wcześniejszego etapu.

Brak kolejki

Chwilowa awaria ERP powoduje utratę zamówienia.

Nieograniczone ponowienia

Błędne dane są wysyłane bez końca i obciążają systemy.

Brak monitoringu braku aktywności

Import przestaje działać, ale nie pojawia się jawny błąd.

Podwójna komunikacja

Klient otrzymuje różne wiadomości ze sklepu, OMS i BaseLinkera.

Brak kontroli anulowania

Status zmienia się w sklepie, ale magazyn nadal wysyła paczkę.

Automatyczny zwrot bez zabezpieczenia

Powtórzone zdarzenie zwraca klientowi środki kilka razy.

Zbyt szerokie uprawnienia

Każdy pracownik może zmieniać routing i wykonywać zwroty finansowe.

Brak dokumentacji

Nikt nie wie, dlaczego określone zamówienie trafiło do konkretnego magazynu.

Jak samodzielnie ocenić proces zarządzania zamówieniami?

Podstawową analizę można rozpocząć od odpowiedzi na pytania:

1. Z ilu kanałów pochodzą zamówienia?
2. Gdzie znajduje się ich centralna lista?
3. Który system nadaje główny status?
4. Jak potwierdzana jest płatność?
5. Który system tworzy rezerwację?
6. Kiedy rezerwacja powstaje?
7. Kiedy jest zwalniana?
8. Jak wybierane jest miejsce realizacji?
9. Czy zamówienia mogą być dzielone?
10. Jak obsługiwana jest częściowa wysyłka?
11. Kto tworzy przesyłkę?
12. Kiedy klient otrzymuje wiadomość o wysyłce?
13. Jak obsługiwane jest anulowanie?
14. Czy anulowanie zatrzymuje magazyn?
15. Jak obsługiwane są zwroty?
16. Jak system zapobiega duplikatom?
17. Co dzieje się podczas awarii ERP lub WMS?
18. Gdzie widoczne są błędy?
19. Kto otrzymuje alert?
20. Czy cały proces jest udokumentowany?

Jak wygląda prawidłowe wdrożenie OMS?

1. Opisuję źródła zamówień – ustalam wszystkie sklepy, marketplace’y, kanały B2B i sprzedaż ręczną.
2. Mapuję cykl życia – rozpisuję proces od utworzenia do zwrotu lub pełnego zamknięcia.
3. Definiuję model danych – oddzielam zamówienie, pozycje, płatności, rezerwacje, realizacje i przesyłki.
4. Porządkuję identyfikatory – łączę numery źródłowe, OMS, ERP, WMS i kurierów.
5. Normalizuję dane – ujednolicam statusy, dostawy, płatności, adresy i waluty.
6. Wskazuję źródła prawdy – określam odpowiedzialność za płatność, stan, dokument i wysyłkę.
7. Projektuję walidację – zatrzymuję zamówienia z brakującymi lub niespójnymi danymi.
8. Projektuję rezerwacje – ustalam moment, typ, czas ważności i sposób zwolnienia.
9. Tworzę reguły routingu – uwzględniam dostępność, czas, koszt i możliwości magazynów.
10. Projektuję podziały – ustalam zasady częściowej realizacji i wielu przesyłek.
11. Definiuję statusy – rozdzielam płatność, realizację, wysyłkę, dokumenty i zwroty.
12. Projektuję anulowania – zatrzymuję wszystkie powiązane operacje i zwalniam zasoby.
13. Projektuję zwroty – łączę przyjęcie produktu, decyzję jakościową, korektę i płatność.
14. Integruję ERP i WMS – tworzę jednoznaczne kierunki przepływu zamówień oraz potwierdzeń.
15. Dodaję kolejki – zabezpieczam proces przed chwilową niedostępnością systemów.
16. Wdrażam idempotencję – chronię zamówienia, dokumenty, przesyłki i zwroty przed duplikacją.
17. Projektuję obsługę błędów – rozdzielam problemy techniczne i wymagające poprawy danych.
18. Wdrażam monitoring – kontroluję brakujące zamówienia, opóźnienia, kolejki i wyjątki.
19. Testuję scenariusze – sprawdzam płatności, braki, podziały, anulowania, zwroty i awarie.
20. Uruchamiam etapami – rozpoczynam od ograniczonego kanału lub magazynu.
21. Szkolę użytkowników – pokazuję proces, obsługę wyjątków i odpowiedzialność systemów.
22. Dokumentuję rozwiązanie – zapisuję statusy, reguły, integracje i procedury awaryjne.
23. Wyznaczam właściciela procesu – wskazuję osobę odpowiedzialną za dalszy rozwój.
24. Regularnie analizuję wyniki – poprawiam czas realizacji, koszty, jakość i liczbę błędów.

Czy OMS może zastąpić pracowników obsługi?

Może automatycznie wykonać wiele powtarzalnych działań, ale nadal potrzebna jest obsługa wyjątków.

Pracownik może zajmować się:

• nietypowymi zamówieniami,
• problemami z płatnością,
• zmianami po rozpoczęciu realizacji,
• brakami produktów,
• reklamacjami,
• indywidualnym kontaktem z klientem.

Dobrze wdrożony OMS ogranicza ręczne przepisywanie i pilnowanie etapów, ale pozostawia człowiekowi decyzje wymagające oceny.

Czy każdy sklep potrzebuje OMS?

Nie.

Prosty sklep z jednym magazynem może prawidłowo działać na WooCommerce, systemie ERP lub BaseLinkerze.

OMS daje największą wartość, gdy proces obejmuje:

• wiele kanałów,
• wiele magazynów,
• różne modele realizacji,
• częściowe wysyłki,
• zaawansowane rezerwacje,
• dużą skalę zamówień,
• wiele integracji,
• skomplikowaną obsługę anulowań i zwrotów.

Nie wdrażam OMS tylko dlatego, że firma chce posiadać kolejne narzędzie. Najpierw sprawdzam, czy obecny problem wynika z braku systemu, czy z nieprawidłowo skonfigurowanych statusów, integracji i odpowiedzialności.

Najważniejsze wnioski

• OMS służy do centralnego zarządzania całym cyklem zamówienia.
• Może pobierać zamówienia ze sklepów, marketplace’ów, sprzedaży B2B i innych kanałów.
• Nie jest tylko wspólną listą zamówień, lecz warstwą koordynującą proces.
• WooCommerce może być źródłem zamówienia, a OMS zarządzać dalszą realizacją.
• BaseLinker może pełnić funkcję OMS albo współpracować z bardziej rozbudowanym systemem.
• ERP odpowiada za szersze procesy handlowe i dokumentowe.
• WMS steruje fizycznymi operacjami magazynu.
• PIM zarządza informacjami produktowymi, a CRM relacją z klientem.
• OMS powinien normalizować dane pochodzące z różnych kanałów.
• Każde zamówienie może posiadać wiele identyfikatorów, które trzeba ze sobą powiązać.
• Produkty powinny być rozpoznawane przez stabilne identyfikatory, a nie nazwy.
• Utworzenie zamówienia nie oznacza potwierdzenia płatności.
• Źródło prawdy dla płatności powinno być jasno określone.
• Stan fizyczny nie zawsze odpowiada ilości możliwej do obiecania klientowi.
• Rezerwacja musi posiadać określony moment utworzenia, potwierdzenia i zwolnienia.
• Routing wybiera miejsce realizacji na podstawie dostępności, czasu, kosztu i innych reguł.
• Podział zamówienia może przyspieszyć wysyłkę, ale zwiększa koszty i złożoność.
• Częściowa realizacja wymaga śledzenia ilości na poziomie każdej pozycji.
• Jeden ogólny status nie wystarcza do opisania płatności, magazynu, wysyłki i zwrotu.
• Anulowanie powinno zatrzymać wszystkie powiązane operacje, a nie tylko zmienić etykietę.
• Utworzenie etykiety kurierskiej nie oznacza fizycznego wysłania paczki.
• Jedno zamówienie może posiadać wiele przesyłek i numerów śledzenia.
• Zwrot produktu i zwrot pieniędzy są oddzielnymi etapami.
• OMS może obsługiwać dropshipping, realizację ze sklepów oraz odbiór osobisty.
• Automatyzacje powinny posiadać scenariusz sukcesu, błędu, ponowienia i ręcznej interwencji.
• Kolejki chronią zamówienia przed utratą podczas awarii systemów zewnętrznych.
• Idempotencja zapobiega podwójnym zamówieniom, dokumentom, przesyłkom i zwrotom.
• Zdarzenia mogą docierać wielokrotnie i w nieprawidłowej kolejności.
• Monitoring powinien wykrywać błędy, opóźnienia oraz brak oczekiwanych zamówień.
• Historia powinna umożliwiać odtworzenie całego przebiegu zamówienia.
• Uprawnienia należy ograniczać według rzeczywistych obowiązków użytkowników.
• Wdrożenie OMS wymaga analizy procesu, danych, statusów, integracji i wyjątków.
• Najlepszy OMS nie zastępuje pozostałych systemów, lecz sprawnie koordynuje ich pracę.

Nie wiesz, czy Twoja firma potrzebuje systemu OMS?

Podczas analizy sprawdzam nie tylko liczbę zamówień. Rozpisuję wszystkie kanały sprzedaży, płatności, źródła zapasu, rezerwacje, magazyny, statusy, przesyłki, anulowania i zwroty.

Mogę wskazać miejsca, w których zamówienia powstają podwójnie, statusy wzajemnie się nadpisują, anulowanie nie zatrzymuje magazynu albo jedna nieudana integracja pozostawia zamówienie bez dalszej realizacji.

Nie zakładam automatycznie, że potrzebny jest osobny, rozbudowany OMS. Najpierw sprawdzam możliwości WooCommerce, BaseLinkera, ERP i WMS. Dopiero później projektuję brakującą warstwę zarządzania zamówieniami, automatyzacje, kolejki, monitoring i bezpieczną obsługę wyjątków.