Dopóki sprzedajesz w jednym sklepie, zamówienie jest proste: wpada, rezerwuje towar, idzie do wysyłki. Problem zaczyna się, gdy dokładasz marketplace, aplikację mobilną, sprzedaż B2B i sklep stacjonarny. Nagle to samo zamówienie wygląda inaczej w każdym systemie, a dostępność towaru przestaje być jedną liczbą. Dla dyrektora operacji czy fulfilmentu oznacza to overselling, opóźnione wysyłki i obsługę klienta, która zgaduje, co się właściwie stało.
Z naszego doświadczenia najtrudniejsze w takich projektach nie jest dołożenie kolejnego kanału, tylko zbudowanie jednej, spójnej warstwy, która wie wszystko o każdym zamówieniu i potrafi nim sterować. Nawet jeśli nie dostarczamy tu gotowego pudełka, obsadzamy role i spinamy kompetencje potrzebne, żeby taki system OMS powstał i działał w produkcji, bez budowania zespołu od zera.
Dlaczego zamówienia rozjeżdżają się między kanałami?
Bo każdy kanał ma własny model danych, własne tempo i własną prawdę o stanie magazynu. Sklep zdejmuje towar w momencie koszyka, marketplace synchronizuje się co kilka minut, a system ERP księguje dopiero po zapłacie. Te opóźnienia się kumulują i ta sama sztuka potrafi zostać sprzedana dwa razy.
Do tego dochodzą różne statusy („opłacone”, „w realizacji”, „spakowane”) nazywane inaczej w każdym narzędziu, zwroty wracające inną ścieżką niż wysyłki oraz ręczne korekty w arkuszach. Bez wspólnego języka dla zamówienia każdy zespół pracuje na innym obrazie rzeczywistości, a rozbieżności wychodzą dopiero przy reklamacji.
Czym jest orkiestracja zamówień omnichannel i routing do magazynów?
Orkiestracja zamówień to serce OMS: warstwa, która przyjmuje zamówienie z dowolnego kanału, sprowadza je do jednego formatu i decyduje, jak je zrealizować. To tutaj zamówienie przestaje należeć do kanału, a zaczyna należeć do firmy.
Kluczowa jest tu logika routingu, czyli odpowiedź na pytanie „skąd to wysłać”. Projektujemy reguły, które biorą pod uwagę:
- dostępność w poszczególnych magazynach i sklepach,
- odległość i koszt wysyłki do klienta,
- priorytety (np. opróżnianie magazynu sezonowego, SLA dla klienta B2B),
- zdolność realizacji danej lokalizacji w danym dniu.
Dobrze ułożony routing potrafi też rozdzielić jedno zamówienie na kilka źródeł, gdy żadne pojedyncze nie ma kompletu, i zrobić to tak, żeby klient dostał jak najmniej paczek przy akceptowalnym koszcie.
Jak synchronizować stany i dostępność między kanałami?
To pytanie, na którym najwięcej wdrożeń się przewraca. Zamiast utrzymywać osobny stan w każdym kanale, budujemy jedno źródło prawdy o dostępności i z niego zasilamy wszystkie punkty sprzedaży. OMS pośredniczy między magazynem a kanałami, więc każdy widzi spójną liczbę.
W praktyce stosujemy mechanizmy, które chronią przed oversellingiem i „duchami” na stanie:
- rezerwacje i soft-locki towaru na czas realizacji zamówienia,
- dostępność do obiecania (ATP), która liczy nie tylko stan, ale i towar w drodze,
- bufory bezpieczeństwa dla kanałów o wolniejszej synchronizacji,
- zdarzeniowa aktualizacja stanów zamiast ciężkiego przeliczania co noc.
Jak obsłużyć podział wysyłek i backorder?
Rzadko kiedy całe zamówienie jedzie jedną paczką z jednego miejsca. Realny e-commerce musi radzić sobie z sytuacją, gdy część towaru jest dostępna od ręki, a część trzeba zamówić. Modelujemy zamówienie tak, żeby pozycje mogły żyć własnym cyklem - jedne spakowane i wysłane dziś, inne w backorderze z oczekiwaną datą dostawy.
To pociąga za sobą konkretne decyzje: jak komunikować częściową wysyłkę, kiedy pobrać płatność i co zrobić, gdy backorder się nie domknie. Projektujemy te reguły razem z zespołem operacji, bo to one, a nie sam kod, decydują o doświadczeniu klienta.
Jakich narzędzi obsługi klienta do zamówień potrzebujesz?
Nawet najlepszy routing nie pomoże, jeśli konsultant nie widzi, co się dzieje z zamówieniem. Dlatego częścią OMS jest warstwa narzędziowa dla obsługi i operacji - panel, w którym jedno zamówienie ma jeden, pełny obraz.
Budujemy w nim funkcje, których realnie używa się przy telefonie od klienta:
- pełną historię zamówienia (statusy, płatności, wysyłki, zwroty) w jednym miejscu,
- akcje naprawcze: korekta adresu, anulowanie pozycji, ponowna wysyłka,
- podgląd rezerwacji i źródła realizacji, żeby odpowiedzieć „gdzie jest paczka”,
- obsługę zwrotów i reklamacji spiętą z tym samym zamówieniem.
Jak spiąć integracje z ERP, WMS i płatnościami?
OMS nie żyje w próżni - jego wartość bierze się z tego, że rozmawia z resztą krajobrazu systemowego. Traktujemy go jako warstwę integracyjną, która tłumaczy zamówienie między światem sprzedaży a światem realizacji i finansów.
Typowo spinamy go z:
- ERP - po stronie towaru, cen, faktur i księgowania,
- WMS - po stronie kompletacji, pakowania i ruchu magazynowego,
- bramkami płatności - autoryzacje, pobrania, zwroty środków,
- przewoźnikami - etykiety, tracking, statusy doręczenia.
Projektujemy te integracje jako odporne na błędy drugiej strony: z kolejkami, ponowieniami i jasnym zachowaniem, gdy ERP czy WMS chwilowo nie odpowiada. Dzięki temu awaria jednego systemu nie zatrzymuje całego przepływu zamówień.
Jak zadbać o niezawodność i spójność zamówień?
Zamówienie to pieniądze i obietnica wobec klienta, więc OMS musi być spójny i idempotentny - ta sama wiadomość przetworzona dwa razy nie może wygenerować drugiej wysyłki ani drugiego pobrania środków. Stawiamy na architekturę zdarzeniową, w której każdy krok ma jednoznaczny stan, a historia zmian jest odtwarzalna.
W praktyce oznacza to projektowanie pod przypadki brzegowe: zdublowane webhooki z marketplace’u, płatność potwierdzaną z opóźnieniem albo magazyn zgłaszający brak już po rezerwacji. Budujemy mechanizmy uzgadniania (rekoncyliacji) i monitoring, który wyłapuje rozjazdy, zanim zrobi to klient. To ta warstwa decyduje, czy w szczycie sprzedażowym system trzyma, czy generuje chaos.
Jakie kompetencje dostarczamy do projektu OMS?
Dobieramy skład pod konkretną specyfikę zarządzania zamówieniami, a nie „na zapas”. W tego typu projektach współtworzymy zespół z ról, które realnie domykają temat:
- architekt / backend developer projektujący model zamówienia i logikę orkiestracji,
- integratorzy znający realia ERP, WMS, płatności i API przewoźników,
- specjalista od danych i spójności pilnujący stanów, rezerwacji i rekoncyliacji,
- DevOps budujący wdrożenia, kolejki i monitoring pod ruch szczytowy.
Opieramy się przy tym na realnym doświadczeniu w projektach e-commerce i systemach transakcyjnych, w których liczą się wolumen i poprawność danych.
Jak robimy to w RITS?
Działamy jako partner nearshore z Polski, który wzmacnia Twój zespół kompetencjami potrzebnymi do zbudowania i utrzymania OMS. Zamiast sprzedawać gotowe pudełko, wchodzimy w Twój krajobraz systemowy i projektujemy warstwę zamówień pod Twoje kanały i procesy.
- obsadzamy role od architektury po integracje i DevOps, dopasowane do zakresu projektu,
- kompetencje weryfikujemy przed startem, a nasz proces rekrutacji zwykle zamyka się w około trzy tygodnie,
- jako partner w zbliżonej strefie czasowej wchodzimy w rytm przeglądów kodu i spotkań bez długiego rozruchu,
- pracujemy w modelu, który najbardziej pasuje: dedykowane oprogramowanie budowane przez nasz zespół albo wzmocnienie zespołu, gdy trzeba szybko uzupełnić kompetencje.
Od czego zacząć budowę systemu OMS?
Zacznij od jednego, najboleśniejszego przepływu - najczęściej jest to overselling albo rozjazd stanów między sklepem a marketplace’em. Opisz, jak dziś wygląda życie zamówienia od wpadnięcia do wysyłki, i gdzie tracicie spójność. To wyznaczy, czy potrzebujesz pełnego OMS, czy najpierw samej orkiestracji i synchronizacji stanów.
Dobór modelu współpracy ma tu znaczenie równe technologii. Różnice między poszczególnymi modelami opisaliśmy w artykule o modelach współpracy IT.
Walczysz z zamówieniami w wielu kanałach? Porozmawiajmy - dobierzemy zespół i architekturę OMS pod Twój e-commerce.