Jak spiąć sprzedaż firmową z systemem finansowym, bazą produktową i magazynem?

Najbezpieczniejszy model jest prosty do wyjaśnienia: system finansowo-magazynowy pozostaje źródłem prawdy dla finansów, cenników bazowych, limitów kredytowych i faktur; baza produktowa odpowiada za treści, zdjęcia i atrybuty; system magazynowy za fizyczne stany i realizację zamówień; MedusaJS v2 obsługuje koszyk, ścieżkę zakupu, zamówienia, promocje kanałowe i opisane ścieżki wymiany danych dla kanałów sprzedaży; a warstwa NestJS oraz kolejki tłumaczą reguły między systemami.

MACH w sprzedaży firmowej nie oznacza, że każdy proces musi być osobną usługą. To skrót od czterech zasad: modułowych obszarów, projektowania połączeń przed wdrożeniem, infrastruktury gotowej na chmurę i oddzielonej warstwy klienta. W praktyce ważniejsze od samego skrótu są jawne granice odpowiedzialności: cena, stan magazynowy, warunki klienta, akceptacje, cykl życia zamówienia, realizacja i płatności.

Dzięki temu portal zakupowy dla firm nie jest kopią systemu finansowo-magazynowego w przeglądarce. Jest narzędziem zakupowym, które używa finansów, danych produktowych i magazynu tam, gdzie mają przewagę, ale nie uzależnia doświadczenia klienta od każdej wolnej odpowiedzi starszego systemu.

Hurtownicy, producenci i dystrybutorzy potrzebują wielu cenników, rabatów warunkowych, limitów kredytowych, wieloetapowych akceptacji, dokumentów handlowych, indywidualnych terminów płatności i często podziału realizacji na kilka magazynów. To nie są ozdobniki. To logika przychodu i ryzyka finansowego.

Platformy konsumenckie zaczynają pękać, gdy kupujący firmowy widzi cenę zależną od oddziału, historii kontraktu, wolumenu, waluty, progu dostawy i aktualnego limitu. BigCommerce w swoim materiale o sprzedaży firmowej wskazuje personalizowane ceny, zarządzanie kontami, połączenie z systemem finansowo-magazynowym i skalowalność jako kluczowe potrzeby; to dobry sygnał, że problem jest operacyjny, nie tylko wizualny.

Dobrze zaprojektowana architektura pozwala oddzielić reguły biznesowe od witryny Next.js. Zmiana progu kredytowego, akceptacji menedżera albo reguły kosztu dostawy nie powinna wymagać wdrożenia całej witryny ani ręcznego obejścia w systemie finansowo-magazynowym.

Cena bazowa i warunki płatności zwykle powinny pozostawać w systemie finansowo-magazynowym, bo tam są księgowość, limity, waluty, faktury i reguły podatkowe. MedusaJS v2 może liczyć koszyk, promocje kanałowe i ścieżkę zakupu, ale musi wiedzieć, kiedy sprawdzić dane od razu, a kiedy użyć krótkotrwałej kopii danych lub zapisanego stanu zamówienia.

Produkt i treści produktowe powinny mieć rozdzieloną odpowiedzialność. System finansowo-magazynowy zna kod produktu w systemie firmy, jednostki miary, koszty i status sprzedażowy. Baza informacji produktowych zna opisy, zdjęcia, atrybuty techniczne, tłumaczenia i kompletność danych. System magazynowy zna fizyczny stan, rezerwacje i priorytety realizacji zamówień.

Zamówienie jest najtrudniejsze: witryna sklepowa potrzebuje natychmiastowego potwierdzenia, system finansowo-magazynowy potrzebuje dokumentu handlowego, magazyn potrzebuje zlecenia kompletacji, a dział finansów potrzebuje faktury lub blokady limitu. Dlatego cykl życia zamówienia powinien być opisanym procesem, który bezpiecznie rozpoznaje ponowne wysłanie tej samej operacji i pokazuje status obsłudze klienta.

Nie łącz witryny sklepowej bezpośrednio z systemem finansowo-magazynowym. Wstaw warstwę pośrednią w Node.js/NestJS, która ma opisane zasady komunikacji: OpenAPI dla zapytań natychmiastowych oraz AsyncAPI albo zdarzenia dla synchronizacji, importów i statusów. OpenAPI formalnie opisuje rozmowę przez HTTP i znaczenie operacji; w sprzedaży firmowej działa jak umowa między warstwą sprzedażową a systemami zaplecza.

Dla procesów działających w tle używaj kolejek i zadań, które bezpiecznie rozpoznają ponowne wykonanie tej samej pracy, na przykład RabbitMQ, Amazon SQS lub podobnego mechanizmu. Awaria systemu finansowo-magazynowego nie powinna wyłączać sklepu. Powinna oznaczyć zamówienie jako "oczekuje na synchronizację", uruchomić ponowienie i pokazać zespołowi status operacyjny.

W rozpoznaniu biznesu, projektu i technologii dokumentujemy: ścieżki wymiany danych, zdarzenia, ponowienia, limity wywołań, mapowanie identyfikatorów, kolejkę błędnych wiadomości, właściciela powiadomienia i reguły konfliktu. To bywa bardziej wartościowe niż makieta kolejnej strony kategorii, bo właśnie w połączeniach między systemami najczęściej znika budżet.

Baza informacji produktowych ma sens, gdy katalog ma wiele atrybutów technicznych, wiele języków, wiele kanałów, warianty, dokumenty PDF, zdjęcia, certyfikaty i proces akceptacji treści. Wikipedia opisuje ten obszar jako zarządzanie informacjami potrzebnymi do marketingu i sprzedaży produktów przez kanały dystrybucji; w sprzedaży firmowej to często różnica między skalowalnym katalogiem a Excelem wysyłanym mailem.

Akeneo pokazuje dojrzały wzorzec połączenia z bazą produktową: opisany sposób komunikacji, zdarzenia, powiadomienia systemowe i specyfikację OpenAPI. To jest dokładnie kierunek, którego potrzebuje sprzedaż firmowa z oddzieloną warstwą klienta: baza produktowa nie jest "ładnym panelem", tylko źródłem danych, które może zasilać witrynę sklepową, aplikację mobilną, platformę wielu sprzedawców i materiały dla handlowców.

Ale baza informacji produktowych nie naprawia procesu. Jeśli firma nie ma właścicieli atrybutów, słownika jednostek, zasad jakości zdjęć i procesu akceptacji, to połączenie z kolejnym systemem tylko szybciej przeniesie bałagan do kolejnych kanałów. W projektach GMI najpierw robimy mapę danych i odpowiedzialności, dopiero potem skalujemy sprzedaż.

Płatność kartą jest w sprzedaży firmowej często najprostsza technicznie i najmniej ważna biznesowo. Prawdziwe reguły to odroczony termin, limit kredytowy, blokada po przeterminowanych fakturach, koszyk przekraczający próg akceptacji i zamówienia składane przez pracownika w imieniu oddziału.

W modułowej architekturze robimy osobny obszar polityki kredytowej. Może on sprawdzać system finansowo-magazynowy od razu przy ścieżce zakupu dla wysokiego ryzyka, używać krótkotrwałej kopii danych dla niskiego ryzyka, a dla wyjątków uruchamiać proces akceptacji. Commercetools dokumentuje jednostki biznesowe, role użytkowników, reguły akceptacji, zapytania ofertowe i oferty jako osobne zasoby sprzedaży firmowej; to pokazuje, że role i akceptacje są pełnoprawnym obszarem, a nie dodatkiem do konta klienta.

Granice zgodności regulacyjnej muszą być jasne: co trzyma Medusa, co system finansowo-magazynowy, co dostawca płatności, co trafia do dzienników działania i jak długo przechowujemy dane. PCI DSS, RODO i audyt przed sezonem sprzedażowym są częścią architektury, nie dokumentem po wdrożeniu.

Najczęstsze awarie nie są spektakularne. Cena aktualizuje się 20 minut za późno. Baza produktowa opublikuje opis bez certyfikatu. System magazynowy zwróci stan sprzed rezerwacji. System finansowo-magazynowy odrzuci zamówienie po tym, jak klient dostał potwierdzenie. Handlowiec zmieni limit w systemie, którego sklep jeszcze nie widzi.

Dla każdego takiego przypadku potrzebujesz decyzji produktowej: blokujemy ścieżkę zakupu czy przyjmujemy zamówienie warunkowo? Pokazujemy "dostępne od ręki" czy "potwierdzimy termin"? Rezerwujemy stan magazynowy w koszyku czy dopiero po potwierdzeniu? Kto dostaje powiadomienie i w jakim czasie musi zareagować?

Tu widać wartość podejścia modułowego. Osobne obszary odpowiedzialności, zdarzenia, kolejki i nadzór nad całą ścieżką pozwalają ograniczyć pojedynczą funkcję zamiast wyłączać cały kanał sprzedaży firmowej. Klient widzi spokojny komunikat, a zespół widzi listę wyjątków do obsłużenia.

Domyślny model GMI dla średnich firm sprzedających klientom firmowym: witryna Next.js, MedusaJS v2 jako rdzeń sprzedażowy, NestJS jako warstwa połączeń i reguł, PostgreSQL dla danych transakcyjnych, Redis dla szybkich odczytów i krótkich blokad, kolejki dla synchronizacji, baza produktowa dla treści, system finansowo-magazynowy dla finansów i dokumentów, system magazynowy dla realizacji zamówień oraz React Native, gdy kupujący potrzebują aplikacji mobilnej lub zamawiania w terenie.

MedusaJS v2 pasuje tu dlatego, że moduły są centralne dla dostosowań i połączeń z innymi systemami. Dokumentacja Medusa opisuje moduł jako pakiet funkcji związanych z jednym obszarem albo połączeniem; to pozwala budować politykę kredytową, łącznik do systemu finansowo-magazynowego, niestandardowe ceny lub reguły akceptacji bez przepisywania całego rdzenia sprzedażowego.

To nie jest architektura "najwięcej technologii wygrywa". To minimalny zestaw niezależnych elementów, który usuwa realne ograniczenia: ceny kontraktowe, połączenia z systemami, sprzedaż w kilku kanałach, odpowiedzialność za dane i możliwość dalszej rozbudowy bez uzależnienia od dostawcy.

Nie mierz tylko dostępności witryny sklepowej. Mierz czas od kliknięcia do faktury, opóźnienie synchronizacji zamówienia z systemem finansowo-magazynowym, procent zamówień z ręczną korektą, czas publikacji produktu z bazy produktowej do sklepu, skalę sprzedaży ponad dostępny stan, błędy cenowe, czas dotarcia powiadomień systemowych, czas obsługi kolejki błędnych wiadomości i liczbę zgłoszeń "nie zgadza się z systemem finansowym".

Dobre wskaźniki są finansowe i operacyjne jednocześnie. Jeśli po wdrożeniu handlowcy dalej przepisują zamówienia, a dział finansów dalej ręcznie zwalnia limity, projekt jest niedokończony nawet wtedy, gdy wyniki techniczne strony wyglądają dobrze.

W GMI wpisujemy te wskaźniki do rozpoznania biznesu, projektu i technologii. Dzięki temu stała cena po rozpoznaniu zakresu obejmuje nie tylko ekrany, ale ryzyka połączeń między systemami i sposób utrzymania. To chroni klienta przed projektem, który "działa na pokazie", ale nie skraca pracy zespołu.

Poproś o mapę źródeł prawdy: cena, produkt, stan magazynowy, klient, limit, zamówienie, faktura, wysyłka i zwrot. Każdy obszar powinien mieć właściciela, uzgodniony czas reakcji i regułę konfliktu.

Poproś o przykładowy opis wymiany danych dla natychmiastowego sprawdzenia ceny i dostępności oraz AsyncAPI lub opis zdarzeń dla importu produktów, statusu zamówień i aktualizacji stanów magazynowych.

Poproś o instrukcję operacyjną: co robimy, gdy system finansowo-magazynowy nie odpowiada, baza produktowa wysyła niepełny produkt, system magazynowy odrzuca rezerwację, bramka płatności zwraca opóźnione potwierdzenie, a kolejka błędnych wiadomości rośnie w sezonie.

Poproś o model kosztu: rozpoznanie zakresu, prace programistyczne, migracja danych, połączenia z systemami, testy wydajnościowe, nadzór działania, utrzymanie i odpowiedzialność po wdrożeniu. Jeśli oferta nie rozdziela tych pozycji, ryzyko ukrywa się w liście zadań.

Dokumentacja modułów Medusa: https://docs.medusajs.com/learn/fundamentals/modules

Dokumentacja przepływów pracy Medusa: https://docs.medusajs.com/learn/fundamentals/workflows

Specyfikacja OpenAPI: https://spec.openapis.org/oas/latest.html

Specyfikacja AsyncAPI: https://www.asyncapi.com/docs/reference/specification/v3.0.0

Dokumentacja API i zdarzeń Akeneo: https://api.akeneo.com/

commercetools - jednostki biznesowe i role kupujących: https://docs.commercetools.com/api/projects/business-units

Przewodnik BigCommerce po sprzedaży firmowej: https://www.bigcommerce.com/articles/b2b-ecommerce/

Przewodnik GMI o sprzedaży firmowej z Medusa: https://gmi.software/blog/medusa-b2b-ecommerce-guide

Modułowy system zarządzania zamówieniami: https://gmi.software/blog/composable-commerce-oms-fulfilment