Integracja Bitrix24 z WMS to jeden z najtrudniejszych problemów technicznych w e-commerce B2B — szczególnie gdy system magazynowy jest zamknięty, legacy i nie ma publicznego API. Ten artykuł pokazuje jak to rozwiązaliśmy bez wymiany żadnego z systemów.
Technologiczna entropia: gdy dwa doskonałe systemy tworzą jeden dysfunkcyjny proces
Istnieje pewien paradoks, który obserwujemy regularnie w firmach e-commerce B2B na etapie skalowania. Firma inwestuje w najlepszy dostępny CRM — Bitrix24, z pełnym pipeline’em sprzedażowym, automatyzacją leadów i raportowaniem dla zarządu. Jednocześnie buduje lub kupuje dedykowany WMS, który bezbłędnie zarządza tysiącami SKU, lokalizacjami w magazynie i procesami kompletacji.
Oba systemy działają perfekcyjnie. Osobno.
Razem tworzą wąskie gardło, które kosztuje firmę więcej niż oba systemy łącznie.
Kiedy duże zamówienie B2B wpływało do systemu — powiedzmy: 200 pozycji od kluczowego odbiorcy hurtowego — handlowiec w Bitrix24 nie miał dostępu do aktualnych stanów magazynowych. WMS był osobnym bytem, zamkniętą bazą danych bez publicznego API, zarządzaną przez zewnętrznego dostawcę sprzed dekady.
Procedura wyglądała tak: handlowiec dzwonił do magazynu. Magazyn sprawdzał ręcznie lub w swoim systemie. Oddzwaniał. Handlowiec aktualizował ofertę. Jeśli w międzyczasie inny klient zamówił ten sam towar — zaczynało się od nowa.
Średni czas procesowania jednego zamówienia: 4,5 godziny.
Przy 15–20 zamówieniach dziennie oznaczało to, że cały dział sprzedaży spędzał niemal połowę dnia roboczego na koordynacji — zamiast na sprzedaży.
Dlaczego standardowe podejście było nie do przyjęcia
Pierwsza propozycja, którą klient dostał przed rozmową z nami, była klasyczna: wymiana WMS-a na nowy system z natywną integracją Bitrix24.
Koszt migracji: 180 000–250 000 zł. Czas wdrożenia: 8–14 miesięcy. Ryzyko operacyjne podczas migracji: wysokie — firma procesowała ponad 300 zamówień tygodniowo.
Druga propozycja: integracja przez Zapier lub Make.com w modelu SaaS. Problem techniczny był jednak fundamentalny — WMS klienta nie udostępniał webhooka ani REST API. Jedyną możliwością odczytu danych był bezpośredni dostęp do bazy SQL przez sieć wewnętrzną. Żaden SaaS tego nie obsługuje.
Obydwa rozwiązania łączyła ta sama logika: dostosuj swój biznes do narzędzia. My zaproponowaliśmy odwrotnie.
Architektura hybrydowa: integracja Bitrix24 z WMS przez dedykowany middleware
Założenie projektowe
WMS klienta pozostaje nienaruszony. Żadnej migracji, żadnego ryzyka operacyjnego. Zamiast tego — piszemy dedykowany łącznik, który działa między systemami jak tłumacz: rozumie język WMS-a i mówi językiem Bitrix24 API.
Diagram architektury integracji Bitrix24 z WMS:
[WMS — baza SQL]
↓ (zapytanie co 5s przez sieć wewnętrzną)
[Middleware Node.js — VPS klienta]
↓ (transformacja i mapowanie danych)
[Bitrix24 REST API — aktualizacja produktów]
↓
[Handlowiec widzi stany w czasie rzeczywistym]
Stack techniczny
Middleware zbudowaliśmy w Node.js, postawiony na dedykowanym VPS w infrastrukturze klienta — za jego firewallem, z dostępem do wewnętrznej sieci magazynowej. To był kluczowy wybór architektoniczny: dane stanów magazynowych nigdy nie opuszczają sieci klienta w surowej formie.
Mechanika działania integracji Bitrix24 z systemem magazynowym
Skrypt działa w pętli z interwałem 5 sekund. Każdy cykl wykonuje trzy operacje:
1. Odczyt z WMS — zapytanie SQL do bazy magazynowej pobiera aktualne stany wszystkich SKU zmienionych od ostatniego cyklu (delta sync, nie pełny dump — kluczowe dla wydajności przy 12 000+ SKU).
2. Transformacja danych — middleware tłumaczy wewnętrzne identyfikatory produktów WMS na ID produktów w Bitrix24. Mapowanie budowaliśmy przez 3 dni, testując na danych produkcyjnych w trybie read-only.
3. Aktualizacja Bitrix24 — REST API Bitrix24 (crm.product.update) aktualizuje pola stanów magazynowych bezpośrednio na kartach produktów. Handlowiec otwiera deal, widzi aktualny stan — bez odświeżania, bez dzwonienia, bez czekania.
Obsługa błędów i monitoring
Każda nieudana próba synchronizacji jest logowana z timestampem, kodem błędu i identyfikatorem SKU. System wysyła alert na dedykowany kanał Slack jeśli liczba błędów w oknie 15-minutowym przekroczy próg. W ciągu pierwszych 30 dni produkcyjnych: zero alertów krytycznych.
Matematyka i ROI: twarde liczby po 90 dniach
Przed wdrożeniem
| Metryka | Wartość |
|---|---|
| Średni czas procesowania zamówienia | 4,5 godziny |
| Liczba telefonów do magazynu dziennie | 35–50 |
| Zamówienia z błędem stanów magazynowych | ~12% |
| Godziny pracy handlowców na koordynację | 3,2h/os./dzień |
Po wdrożeniu integracji Bitrix24 z WMS (pomiar po 90 dniach)
| Metryka | Wartość | Zmiana |
|---|---|---|
| Średni czas procesowania zamówienia | 2,7 godziny | −40% |
| Liczba telefonów do magazynu dziennie | 0 | −100% |
| Zamówienia z błędem stanów magazynowych | < 0,3% | −97% |
| Godziny pracy handlowców na koordynację | 0,4h/os./dzień | −87% |
Kalkulacja oszczędności
Dział sprzedaży: 6 handlowców × 2,8 odzyskanych godzin dziennie × 220 dni roboczych = 3 696 godzin roczniezwróconych do pracy produkcyjnej.
Przy średnim koszcie godziny pracy handlowca na poziomie 80 zł brutto: 295 680 zł rocznie — tylko z odzyskanego czasu.
Koszt wdrożenia middleware: 28 000 zł netto.
Zwrot z inwestycji: poniżej 5 tygodni.
Trzy zasady architektury hybrydowej
Po pierwsze: nie ruszaj tego co działa. WMS klienta działał bezbłędnie od 7 lat. Żadna migracja nie jest warta ryzyka zakłócenia tego co przynosi wartość.
Po drugie: dane zostają w sieci klienta. Middleware na VPS klienta to wybór dotyczący bezpieczeństwa i zgodności z RODO. Stany magazynowe, identyfikatory produktów, wolumeny zamówień — żadna z tych informacji nie przechodzi przez zewnętrzny SaaS.
Po trzecie: delta sync zamiast pełnego dumpu. Przy dużych katalogach produktów synchronizacja pełna co 5 sekund to katastrofa wydajnościowa. Pobieramy tylko to co się zmieniło od ostatniego cyklu. Obciążenie bazy WMS: minimalne.
Kiedy warto rozważyć integrację CRM z WMS przez middleware?
Ten model sprawdza się gdy masz dwa systemy które nie komunikują się ze sobą, a migracja któregokolwiek jest zbyt ryzykowna lub kosztowna. Gdy Twój WMS nie ma publicznego API — ale ma bazę danych dostępną sieciowo. Gdy potrzebujesz synchronizacji bliskiej czasu rzeczywistego, nie raz na godzinę przez Zapiera.
Jeśli rozpoznajesz w tym opisie swoją organizację — prawdopodobnie tracisz setki godzin miesięcznie na koordynację między systemami które mogłyby rozmawiać ze sobą automatycznie.
Policz swoje straty w 3 minuty
Zbudowaliśmy kalkulator który pokazuje roczny koszt manualnej koordynacji między systemami.
→ Kalkulator ROI Automatyzacji — ile tracisz na ręcznych procesach?
→ Kalkulator Przestojów Sieci — ile kosztują Cię awarie IT?
Jeśli chcesz omówić architekturę swojej integracji — umów bezpłatną sesję diagnostyczną (30 minut, konkretna ocena sytuacji).
Artur Jaźwiec — DC House / Dimensione Creativa. 13+ lat w projektach Enterprise (Credit Suisse, HP Inc., Impel). Specjalizacja: integracje systemów, automatyzacja procesów B2B, UX/UI Design
DC Tech Intel — cotygodniowa analiza technologiczna dla CEO i dyrektorów. Bez buzzwordów. Tylko dane i wnioski operacyjne.