Jak zaprojektować zarządzanie zamówieniami, podział wysyłek i połączenia z magazynem?

Modułowe zarządzanie zamówieniami jest zaprojektowane jako zestaw jasno nazwanych odpowiedzialności i połączeń między systemami, a nie jako nierozdzielna część jednego monolitu sprzedaży internetowej. Może korzystać z MedusaJS jako rdzenia sprzedaży, NestJS jako miejsca dla niestandardowych reguł, PostgreSQL jako bazy stanu operacyjnego, kolejek dla procesów działających w tle oraz połączeń z systemem finansowo-magazynowym, systemem magazynowym, systemem kasowym, zewnętrznymi operatorami logistycznymi i przewoźnikami.

Architektura oparta na niezależnych modułach nie oznacza, że każdy proces musi być osobną usługą. Oznacza, że granice systemu są świadome: sklep nie zawiera reguł magazynowych, ścieżka zakupu nie czeka na każdy system zewnętrzny, a zarządzanie zamówieniami nie miesza statusu realizacji z księgowością. Dobre podejście modułowe zmniejsza zależności tam, gdzie zmienność biznesowa jest największa.

Nie każdy sklep potrzebuje osobnego systemu zarządzania zamówieniami. Jeden magazyn, jeden kraj, standardowe dostawy, mała liczba zwrotów i brak sprzedaży firmowej zwykle mieszczą się w platformie sprzedażowej albo systemie finansowo-magazynowym. Problem zaczyna się wtedy, gdy zasady realizacji zamówień stają się zmienną biznesową, a nie prostym następstwem złożenia zamówienia.

Sygnały są konkretne: wiele lokalizacji magazynowych, wysyłka ze sklepu, odbiór w sklepie, platformy zewnętrzne, zewnętrzny operator logistyczny, zamówienia oczekujące na towar, przedsprzedaż, zestawy produktów, produkty gabarytowe, częściowe wysyłki, różne terminy obsługi dla segmentów klientów, ścieżka akceptacji zamówień firmowych, limity kredytowe, zwroty do innych lokalizacji niż wysyłka oraz obsługa klienta, która musi zmienić źródło realizacji bez proszenia programisty o ręczną poprawkę.

Moduł stanów magazynowych w Medusa obsługuje stany w wielu lokalizacjach, zarządzanie rezerwacjami i sprawdzanie dostępności. To dobry fundament, ale projekt i tak musi odpowiedzieć na pytanie biznesowe: kiedy stan magazynowy przestaje być obietnicą w katalogu, a staje się rezerwacją dla konkretnego zamówienia?

W praktyce potrzebujesz osobnego zestawu statusów dla stanów: dostępny, zarezerwowany, przypisany, skompletowany, wysłany, zwrócony i uszkodzony. Rezerwacja powinna mieć właściciela, powód, czas wygaśnięcia, lokalizację, powiązanie z zamówieniem lub koszykiem oraz reguły zwolnienia. Bez tego szczyt sprzedaży kończy się sprzedażą ponad dostępny stan albo odwrotnie: dobry towar zostaje zamrożony przez porzucone koszyki i niedokończone płatności.

W sprzedaży firmowej dochodzi dodatkowy wymiar: rezerwacja stanu może być powiązana ze ścieżką akceptacji, limitem kredytowym, terminem płatności albo minimalną wartością zamówienia. System zarządzania zamówieniami musi wtedy rozumieć, czy zamówienie jest gotowe do realizacji, czy tylko do kolejnego kroku akceptacji.

Mechanizm zleceń realizacji w Shopify pokazuje ważny wzorzec: po utworzeniu zamówienia osobny proces kierowania decyduje, które lokalizacje będą odpowiedzialne za realizację, a jedno zamówienie klienta może mieć więcej niż jedno zlecenie dla magazynu. To dobry sposób myślenia także poza Shopify: zamówienie klienta i praca operacyjna magazynu to nie zawsze jeden obiekt.

W modułowym systemie decyzja o źródle realizacji powinna brać pod uwagę nie tylko dostępność. Liczą się koszt wysyłki, czas graniczny nadania, pojemność magazynu, uzgodniony termin obsługi klienta, gabaryt, temperatura, kraj, ograniczenia przewoźnika, ryzyko zwrotu, marża, promocje i priorytety biznesowe. Najtańszy magazyn nie zawsze jest najlepszy, jeśli opóźni wysyłkę do kluczowego klienta albo wymusi trzy osobne paczki i trzy powiadomienia.

Podzielona wysyłka jest narzędziem, nie celem. Trzeba jasno ustalić, kiedy dzielimy zamówienie, kiedy czekamy na kompletację, kiedy proponujemy zamiennik, kiedy anulujemy linię, a kiedy obsługa klienta podejmuje decyzję ręcznie. Bez tych reguł system zarządzania zamówieniami zamienia złożoność operacyjną w złożoność komunikacji z klientem.

Moduł realizacji zamówień w Medusa dostarcza zarządzanie realizacją, połączenia z dostawcami, ograniczenia według lokalizacji i reguł oraz różne formy realizacji, takie jak wysyłka i odbiór osobisty. Mechanizm przepływów w Medusa pozwala budować procesy z kroków i zasadami odwrócenia zmian. To pomaga, gdy operacje muszą być spójne mimo połączeń z wieloma systemami.

W praktycznej architekturze GMI MedusaJS zwykle nie jest całym systemem zarządzania zamówieniami. Traktujemy go jako rdzeń sprzedaży i modułowy fundament, a niestandardowe reguły wyboru źródeł realizacji, terminów obsługi, sprzedaży firmowej, uzgadniania danych lub połączenia z finansami i magazynem często trafiają do usług NestJS i kolejek. Dzięki temu ścieżka zakupu nie czeka na odpowiedź operatora logistycznego, a krytyczne połączenia mają bezpieczne ponawianie, ochronę przed zdublowaniem operacji i obsługę zdarzeń, których nie udało się przetworzyć.

Architektura zdarzeniowa nie oznacza "wszystko w tle". Pobranie płatności, rezerwacja stanu i utworzenie zamówienia mają inne wymagania spójności niż wysłanie e-maila, wygenerowanie etykiety kurierskiej albo aktualizacja panelu. Dobry projekt mówi, które decyzje muszą wydarzyć się od razu, które mogą zostać uzgodnione z opóźnieniem i gdzie potrzebny jest ręczny proces odblokowania.

Największe problemy w zarządzaniu zamówieniami nie wynikają z braku połączeń technicznych, tylko z niejasności, który system odpowiada za który fakt. System finansowo-magazynowy może odpowiadać za faktury i rozrachunki, system magazynowy za pracę magazynu, baza produktów za dane produktowe, a system zamówień za decyzje operacyjne. Jeśli każdy system próbuje być wszystkim, statusy rozjeżdżają się po pierwszym zwrocie.

Dla każdego połączenia warto spisać zasady współpracy między systemami: kto tworzy rekord, kto może go zmienić, kto wysyła zdarzenie, co pozwala bezpiecznie ponowić operację bez duplikatu, które statusy są ostateczne, co robimy z częściową awarią i kto ma widok do ręcznego odblokowania sprawy. To nie jest dokumentacja dla dokumentacji. To materiał, który potem ratuje obsługę klienta i finanse.

W wielu firmach system finansowo-magazynowy powinien dostać uporządkowany efekt operacji, a nie uczestniczyć w każdym kliknięciu ścieżki zakupu. System zarządzania zamówieniami może utrzymywać operacyjny stan realizacji i synchronizować go z finansami w punktach kontrolnych: zamówienie przyjęte, faktura gotowa, wysyłka potwierdzona, zwrot przyjęty, korekta wystawiona.

Jeśli system obsługuje tylko bezproblemową ścieżkę, nie jest gotowy na produkcję. Zwrot częściowy, anulowanie po przekazaniu do operatora logistycznego, brak jednego indeksu produktu, uszkodzony produkt, odmowa odbioru, obciążenie zwrotne, korekta faktury, zamiana produktu i ręczna decyzja obsługi klienta muszą mieć statusy oraz zasady księgowe.

Przepływ zwrotu powinien wiedzieć, czy towar wraca do sprzedaży, do kontroli jakości, do utylizacji czy do dostawcy. Zwrot płatności nie powinien być tylko akcją u operatora płatności; musi być powiązany z zamówieniem, fakturą, wysyłką, stanem magazynowym i komunikacją do klienta. W sprzedaży firmowej dochodzą korekty, akceptacje i limity.

To właśnie wyjątki pokazują, czy architektura modułowa działa. Jeśli każda korekta wymaga programisty, architektura jest tylko technicznie modułowa. Operacyjnie nadal jest monolitem w głowach kilku osób.

System zarządzania zamówieniami powinien mieć mierniki biznesowe, operacyjne i techniczne. Same "zamówienia przetworzone" niewiele mówią. Lepsze mierniki to czas cyklu zamówienia, czas przekazania do magazynu, udział podzielonych wysyłek, koszt realizacji na zamówienie, odsetek błędów kompletacji, odsetek sprzedaży ponad dostępny stan, wiek rezerwacji stanów, czas obsługi zwrotu, udział ręcznych interwencji i liczba zaległych uzgodnień.

Dla zespołu technicznego ważne są też sygnały systemowe: długość kolejki, opóźnienie zdarzeń, odsetek błędów wywołań zewnętrznych, liczba ponowień, liczba zdarzeń nieprzetworzonych, próby zdublowania tej samej operacji, czas odpowiedzi każdego połączenia i liczba zamówień w statusie "utknięte". Jeśli tych mierników nie ma, system będzie wyglądał dobrze podczas prezentacji, ale nie da się nim zarządzać w grudniu.

Najlepsza decyzja o wdrożeniu zaczyna się od punktu odniesienia. Zmierz obecny koszt i czas obsługi zamówienia, liczbę ręcznych korekt, czas odpowiedzi obsługi klienta i koszt błędów logistycznych. Dopiero wtedy wiadomo, czy inwestycja powinna zacząć się od stanów magazynowych, reguł kierowania, połączenia z systemem magazynowym czy zwrotów.

W GMI nie zaczynamy od wyboru narzędzia do zamówień. Zaczynamy od rozpoznania biznesu, projektu i technologii: mapujemy cykl życia zamówienia, lokalizacje magazynowe, odpowiedzialność za dane, uzgodnione terminy obsługi, wyjątki, zwroty, akceptację zamówień firmowych, system finansowo-magazynowy, system magazynowy, operatora logistycznego, obsługę klienta i miary sukcesu. Dopiero wtedy decydujemy, co powinno zostać w MedusaJS, co w usługach NestJS, a co w zewnętrznym systemie magazynowym albo systemie finansowo-magazynowym.

Typowy zestaw technologii dla modułowego zarządzania zamówieniami to sklep w Next.js, rdzeń sprzedaży MedusaJS, NestJS dla koordynacji zamówień i połączeń z innymi systemami, PostgreSQL dla stanu operacyjnego, Redis, SQS lub RabbitMQ dla kolejek, wgląd w działanie zdarzeń i widoków nadzoru oraz ewentualnie React Native/Expo dla aplikacji magazynowej, sklepowej lub kurierskiej. Nazwy technologii są tu mniej ważne niż odpowiedzialność: każdy krok zamówienia musi mieć właściciela, status i sposób naprawy.

Po takim rozpoznaniu można odpowiedzialnie rozmawiać o stałej cenie, bo zakres nie jest już hasłem "zróbmy system do zamówień". Zakres opisuje konkretne przepływy: przyjęcie zamówienia, rezerwacje, wybór źródła realizacji, podział wysyłek, przekazanie zlecenia do systemu magazynowego, zwroty, uzgadnianie danych, wgląd w działanie systemu i przekazanie projektu. Kod, dokumentacja i kontekst zostają po stronie klienta, bez uzależnienia od dostawcy.