Klient przychodzi zwykle z tym samym problemem: magazyn działa od lat na starym systemie, który wszyscy znają i który “po prostu robi swoje”, ale nowy sklep internetowy nie ma z niego jak czytać stanów. Padają dwie opcje: wymienić cały WMS albo znaleźć sposób, żeby oba systemy zaczęły się ze sobą dogadywać. Druga opcja jest tańsza, szybsza i w 90% przypadków w ogóle wystarczająca.
Szybka odpowiedź
Integrację starego systemu magazynowego z nowym sklepem internetowym najczęściej realizuje się przez warstwę middleware, która komunikuje się z WMS przez API (lub bazę danych, gdy API nie istnieje) i synchronizuje dane ze sklepem w czasie zbliżonym do rzeczywistego. Taki projekt trwa 6-12 tygodni i kosztuje 40-90 tys. zł, czyli wielokrotnie mniej niż wymiana całego systemu magazynowego.
Najważniejsze wnioski
- Wymiana WMS to projekt na 6-18 miesięcy i koszt liczony w setkach tysięcy złotych, integracja przez middleware zamyka się zwykle w kilka tygodni i kilkadziesiąt tysięcy złotych.
- Warstwa middleware oddziela logikę starego systemu od nowego sklepu, dzięki czemu zmiana platformy e-commerce w przyszłości nie wymaga przebudowy całej integracji.
- Jeśli stary WMS nie ma API, dane można pobierać z bazy danych lub plików eksportu, choć wymaga to dodatkowej walidacji i częściej generuje błędy synchronizacji.
- Kluczowe dane do zsynchronizowania to stany magazynowe, statusy zamówień, ceny i czasem dane o dostawcach, resztę procesów zwykle warto zostawić po stronie starego systemu.
- Największym ryzykiem integracji nie jest technologia, a niekonsekwentne dane w starym systemie, np. duplikaty SKU czy brakujące jednostki miary.
Dlaczego wymiana całego systemu jest zwykle błędem
Firmy sięgają po wymianę WMS, bo wydaje się prostsza konceptualnie: jeden nowy system, jedna integracja, koniec problemu. W praktyce wygląda to inaczej. Stary system magazynowy, nawet ten napisany 15 lat temu, zwykle zawiera setki reguł biznesowych wpisanych w kod: sposoby liczenia rezerwacji, logikę rabatów dostawców, procedury zwrotów specyficzne dla danej branży. Te reguły rzadko są udokumentowane, a ich odtworzenie w nowym systemie to miesiące pracy i ryzyko, że coś przeoczysz.
Widzieliśmy projekty, w których firma zdecydowała się na wymianę WMS równolegle z wdrożeniem nowego sklepu. Efekt: dwa duże projekty IT naraz, każdy z własnym ryzykiem, każdy zależny od drugiego. Kiedy jeden się przesunął, drugi stał w miejscu. Finalny koszt przekroczył budżet o 60%, a termin wydłużył się z 8 do 16 miesięcy.
Integracja przez API i middleware rozwiązuje ten problem inaczej. Stary system magazynowy zostaje tam, gdzie jest, robi to, co robił zawsze, a nowa warstwa pośrednia tłumaczy dane między nim i sklepem. Ryzyko jest ograniczone do jednego, dobrze zdefiniowanego zakresu prac.
Jak działa integracja przez API i middleware
Middleware to osobna aplikacja (najczęściej mikroserwis), która stoi pomiędzy WMS (Warehouse Management System, system zarządzania magazynem) i platformą e-commerce. Jej zadanie jest proste: pobrać dane z jednego systemu, przekształcić je do formatu, który rozumie drugi, i przesłać dalej. W drugą stronę robi to samo, np. przekazując nowe zamówienia ze sklepu do magazynu.
Trzy typowe scenariusze dostępu do starego systemu
Jeśli stary WMS ma udokumentowane API (REST, SOAP lub nawet starsze protokoły jak XML-RPC), integracja jest najprostsza. Middleware odpytuje endpointy, pobiera stany magazynowe i zamówienia, mapuje je na strukturę oczekiwaną przez sklep. To scenariusz, który realizujemy najczęściej i który daje najbardziej przewidywalny koszt.
Gorzej, gdy API nie istnieje, a jedynym dostępem do danych jest baza danych systemu magazynowego. Wtedy middleware łączy się bezpośrednio z bazą (najczęściej w trybie tylko do odczytu, dla bezpieczeństwa), odpytuje odpowiednie tabele i buduje na tej podstawie dane do synchronizacji. Wymaga to dobrej znajomości struktury bazy, która w starszych systemach bywa chaotyczna, z tabelami nazwanymi skrótami bez sensu i logiką rozrzuconą po triggerach.
Trzeci, najmniej wygodny scenariusz, to systemy, które komunikują się tylko przez pliki: eksport CSV lub XML generowany raz dziennie, importowany ręcznie albo przez skrypt. Da się to zautomatyzować, ale synchronizacja odbywa się z opóźnieniem, co bywa problemem przy dużym ruchu w sklepie, gdzie stan magazynowy zmienia się co kilka minut.
Co dokładnie synchronizuje middleware
Nie każdy proces trzeba przenosić do integracji. W praktyce sensowny zakres to: stany magazynowe (dostępność produktów), statusy zamówień (nowe zamówienie ze sklepu trafia do magazynu, magazyn informuje o wysyłce), ceny i czasem dane o wariantach produktów. Resztę procesów, np. zarządzanie dostawcami czy inwentaryzację, zostawia się po stronie starego systemu, bo nie ma powodu, żeby sklep internetowy w to wnikał.
Koszt i czas wdrożenia w praktyce
Podajemy tu realne liczby z projektów, które realizowaliśmy, nie orientacyjne szacunki z internetu. Zakres: stary WMS z bazą SQL Server, bez publicznego API, nowy sklep na Shopware. Middleware synchronizujący stany magazynowe, zamówienia i ceny w interwałach 5-minutowych.
| Etap | Czas | Koszt (orientacyjnie) |
|---|---|---|
| Analiza starego systemu i mapowanie danych | 1-2 tygodnie | 5 000-10 000 zł |
| Budowa middleware (podstawowy zakres) | 3-5 tygodni | 20 000-40 000 zł |
| Integracja z API sklepu | 1-2 tygodnie | 8 000-15 000 zł |
| Testy, poprawki, wdrożenie produkcyjne | 1-2 tygodnie | 7 000-15 000 zł |
| Suma | 6-11 tygodni | 40 000-80 000 zł |
Dla porównania: wymiana całego systemu magazynowego na nowy WMS z pełną migracją danych i szkoleniem zespołu to projekt liczony w setkach tysięcy złotych i minimum 6-9 miesięcy, zwykle więcej, jeśli magazyn obsługuje kilka lokalizacji albo ma niestandardowe procesy logistyczne.
Warto dodać jeden koszt, o którym firmy często zapominają: utrzymanie middleware. To dodatkowy komponent w infrastrukturze, który trzeba monitorować i aktualizować, gdy zmienia się np. wersja API sklepu. W praktyce to 1-3 dni pracy miesięcznie, znacznie mniej niż utrzymanie całego nowego systemu ERP.
Najczęstsze pułapki przy łączeniu starego ERP z nowym systemem
Największym problemem nie jest sama technologia integracji, a jakość danych w starym systemie. Widzieliśmy magazyny, w których jeden produkt miał trzy różne kody SKU w zależności od tego, kto go wprowadzał do systemu, albo jednostki miary zapisane niekonsekwentnie (raz “szt”, raz “1”, raz puste pole). Middleware trzeba wtedy uzupełnić o warstwę walidacji i normalizacji danych, co wydłuża projekt, ale jest niezbędne. Bez tego sklep będzie pokazywał błędne stany magazynowe, a to prowadzi do sprzedaży produktów, których faktycznie nie ma na stanie.
Drugą pułapką jest częstotliwość synchronizacji dobrana bez zastanowienia. Synchronizacja co godzinę brzmi bezpiecznie, ale przy sklepie z dużym ruchem prowadzi do overselling, czyli sprzedaży towaru, który w międzyczasie się skończył. Z drugiej strony synchronizacja co minutę przy starym systemie, który nie był projektowany pod takie obciążenie, może go po prostu zawiesić. Dobrą praktyką jest różnicowanie częstotliwości: stany magazynowe co 5 minut, ceny co godzinę, dane o produktach raz dziennie.
Trzeci problem to brak obsługi błędów. Stary system czasem nie odpowiada, baza danych bywa zablokowana przez inny proces, plik eksportu czasem jest uszkodzony. Middleware musi mieć wbudowaną logikę ponownych prób i alertowania, inaczej firma dowiaduje się o awarii integracji od klienta, który złożył zamówienie na produkt niedostępny od tygodnia.
Kiedy integracja nie wystarczy
Są sytuacje, w których żadna warstwa middleware nie pomoże. Jeśli stary system magazynowy fizycznie nie obsługuje procesów, których potrzebuje nowoczesny e-commerce, np. rezerwacji stanów na czas realizacji płatności albo wielomagazynowości z automatycznym wyborem lokalizacji wysyłki, to nie da się tego “domiddlewarować”. W takich przypadkach trzeba rozważyć częściową wymianę, np. tylko modułu zarządzania stanami, przy zachowaniu resztę starego systemu bez zmian. To hybrydowe podejście, rzadziej stosowane, ale czasem jest optymalnym kompromisem między kosztem a funkcjonalnością.
Zanim zdecydujesz się na jedną z dróg, warto zrobić krótki audyt techniczny starego systemu, sprawdzić dostępność API czy struktury bazy, ocenić realny zakres procesów do zintegrowania. To dzień lub dwa pracy, które pozwalają uniknąć decyzji podjętej na wyczucie, a nie na podstawie faktycznego stanu systemu.
Najczęściej zadawane pytania
Czy da się zintegrować stary WMS bez API z nowym sklepem internetowym?
Tak, choć wymaga to dodatkowej warstwy pośredniej. Jeśli system magazynowy nie ma API, dane pobiera się z bazy danych, plików eksportu (CSV, XML) lub przez zapis do wspólnych tabel. Middleware odpowiada za konwersję tych danych do formatu zrozumiałego dla e-commerce. To rozwiązanie mniej elegantne niż integracja przez REST API, ale w praktyce działa stabilnie, jeśli częstotliwość synchronizacji jest odpowiednio dobrana.
Ile kosztuje integracja starego ERP z nowym sklepem internetowym?
Dla typowego przypadku, czyli WMS z bazą SQL i sklepu na popularnej platformie (Shopware, PrestaShop, Sylius), koszt middleware obsługującego stany magazynowe, zamówienia i ceny wynosi zwykle 40 000-90 000 zł. Cena zależy od liczby integrowanych procesów, jakości dokumentacji starego systemu i tego, czy trzeba budować logikę mapowania danych od zera.
Jak długo trwa wdrożenie integracji magazynu ze sklepem online?
Realistyczny czas to 6-12 tygodni dla podstawowego zakresu (stany magazynowe, zamówienia, ceny). Największą zmienną jest jakość dostępu do starego systemu. Jeśli WMS ma dokumentację API, projekt można zamknąć w 6-8 tygodni. Bez dokumentacji, z koniecznością analizy struktury bazy danych, realny czas rośnie do 10-14 tygodni.
Czy middleware spowalnia działanie sklepu internetowego?
Dobrze zaprojektowany middleware nie wpływa na czas odpowiedzi sklepu, ponieważ dane magazynowe są cache’owane i synchronizowane asynchronicznie, a nie odpytywane w czasie rzeczywistym przy każdym wejściu klienta na stronę produktu. Problemy z wydajnością pojawiają się głównie wtedy, gdy integrację robi się na skróty, bez warstwy pośredniej, odpytując stary system bezpośrednio przy każdym żądaniu.
Kiedy lepiej wymienić cały system magazynowy, a kiedy go integrować?
Wymiana ma sens, gdy stary WMS nie obsługuje kluczowych procesów biznesowych (np. wielomagazynowości, rezerwacji stanów) albo gdy koszt utrzymania przewyższa koszt integracji w perspektywie 2-3 lat. Integracja jest lepszym wyborem, gdy system działa stabilnie operacyjnie, a problem dotyczy tylko komunikacji z nowymi kanałami sprzedaży. W większości projektów, które realizujemy, integracja jest tańsza i szybsza niż wymiana całego stacku.
Słowniczek
WMS (Warehouse Management System)
System informatyczny do zarządzania procesami magazynowymi: stanami, lokalizacjami towaru, kompletacją zamówień i wysyłkami.
Middleware
Warstwa oprogramowania pośrednicząca między dwoma systemami, która tłumaczy i synchronizuje dane, bez konieczności ich bezpośredniej integracji.
API (Application Programming Interface)
Interfejs programistyczny umożliwiający dwóm systemom komunikację i wymianę danych w ustandaryzowany, przewidywalny sposób.
Overselling
Sytuacja, w której sklep sprzedaje więcej jednostek produktu, niż faktycznie znajduje się na stanie magazynowym, zwykle z powodu opóźnień w synchronizacji danych.
Legacy system
Starszy system informatyczny, wciąż używany operacyjnie, ale zbudowany na przestarzałej technologii lub bez aktualnej dokumentacji.
