W logistyce żaden system nie działa w próżni. Jedna przesyłka przechodzi przez ERP, w którym powstaje zamówienie, TMS planujący transport, WMS sterujący magazynem, portal przewoźnika i skaner w ręku magazyniera. Jeśli systemy nie rozmawiają ze sobą automatycznie, ktoś przepisuje dane ręcznie, a każdy taki punkt styku to opóźnienie, błąd i koszt. Dla dyrektora IT integracje przestały być projektem pobocznym, a stały się fundamentem operacji.
Z naszego doświadczenia najtrudniejsze nie jest połączenie dwóch systemów na demo, tylko utrzymanie dziesiątek takich połączeń przy obciążeniu, awariach i ciągle zmieniających się partnerach. Nie mamy wdrożenia logistycznego, którym moglibyśmy się tu chwalić, ale mamy inżynierów, którzy integracje systemowe robią od lat - w projektach przemysłowych, embedded i tam, gdzie spinaliśmy systemy klasy enterprise z zewnętrznymi dostawcami. Te kompetencje przenosimy do logistyki.
Dlaczego logistyka to pajęczyna integracji, a nie pojedynczy system?
Bo w logistyce wartość powstaje na stykach. Towar przemieszcza się między nadawcą, przewoźnikiem, magazynem i odbiorcą, a równolegle musi płynąć jego cyfrowy ślad: status, dokumenty, pozycja, potwierdzenie dostawy - przy czym każdy uczestnik łańcucha ma własny system, format danych i tempo pracy.
Nie rozwiąże tego jeden wielki system. Zamiast tego buduje się warstwę integracyjną, która tłumaczy komunikaty między światami, pilnuje kolejności zdarzeń i dba o to, by status z portalu przewoźnika trafił do TMS, a stamtąd do ERP i do klienta. To ona decyduje, czy firma widzi swoją operację na bieżąco, czy z opóźnieniem.
Czym jest EDI i jak poukładać integracje z partnerami?
EDI to wciąż najpowszechniejszy sposób, w jaki partnerzy w logistyce wymieniają ustrukturyzowane dokumenty: zamówienia, awizacje, potwierdzenia dostawy, faktury. Problem w tym, że „EDI” to nie jeden standard, tylko rodzina standardów i wariantów, które trzeba pogodzić.
W praktyce integracje EDI sprowadzają się u nas do kilku powtarzalnych zadań:
- mapowanie formatów - tłumaczenie komunikatów EDIFACT, ANSI X12 czy branżowych plików na model danych klienta i z powrotem,
- transport komunikatów - obsługa kanałów AS2, SFTP czy VAN, przez które partnerzy faktycznie wysyłają pliki,
- walidacja i obsługa błędów - wyłapywanie niekompletnych lub niezgodnych komunikatów, zanim trafią w głąb systemu,
- onboarding nowych partnerów - szybkie dołożenie kolejnego kontrahenta bez przepisywania całej logiki od zera.
Mapowania muszą przy tym pozostać łatwe w utrzymaniu, bo partnerów przybywa, a ich formaty różnią się w drobnych, ale bolesnych szczegółach.
Jak połączyć ERP i TMS, żeby planowanie i rozliczenia się zgadzały?
ERP i TMS to dwa serca firmy logistycznej. W ERP powstają zamówienia, kontrahenci i rozliczenia, a TMS planuje trasy, przydziela przewoźników i śledzi transport. Jeśli nie są zsynchronizowane, planista pracuje na innych danych niż księgowość, a klient dostaje fakturę niezgodną z tym, co przyjechało.
Integracja TMS i ERP polega u nas na zaprojektowaniu spójnego przepływu zdarzeń: zamówienie z ERP zasila planowanie w TMS, a wykonane zlecenie, koszty i potwierdzenia wracają do ERP do rozliczenia. Pilnujemy przy tym jednego źródła prawdy dla każdego obiektu - żeby adres, waga czy numer zlecenia nie żyły własnym życiem w trzech miejscach. Zwykle budujemy cienką warstwę pośrednią zamiast sztywnego połączenia punkt-punkt, bo wtedy wymiana jednego z systemów nie wywraca całej integracji.
Jak korzystać z API przewoźników i marketplace’ów logistycznych?
Dziś większość przewoźników i platform udostępnia nowoczesne API przewoźników zamiast samego EDI. To otwiera możliwości, ale mnoży liczbę połączeń do utrzymania. Najczęściej spinamy przez te interfejsy:
- wycenę i zamawianie transportu w czasie rzeczywistym u wielu przewoźników naraz,
- generowanie etykiet i dokumentów przewozowych bez ręcznego logowania do portali,
- śledzenie przesyłek przez webhooki i odpytywanie statusów,
- marketplace’y i giełdy transportowe, gdzie podaż i popyt na fracht spotykają się dynamicznie.
Wyzwaniem nie jest pojedyncze API, tylko ich różnorodność - inne limity zapytań, inne uwierzytelnianie, inne znaczenie tego samego statusu. Dlatego projektujemy wspólny model przewoźnika, pod który podpinamy kolejne integracje zamiast pisać każdą od nowa.
Jak wpiąć urządzenia, skanery i czujniki do systemów?
Integracja nie kończy się na systemach IT, bo logistyka dzieje się w świecie fizycznym. Skanery kodów, terminale mobilne, drukarki etykiet, wagi, bramki RFID i czujniki w pojazdach generują strumień zdarzeń, który musi trafić do WMS i TMS we właściwym momencie.
Tutaj przydaje się nasze doświadczenie z projektów embedded i przemysłowych, bo integracja urządzeń rządzi się innymi prawami niż integracja aplikacji: dochodzi niestabilna sieć w magazynie, protokoły specyficzne dla sprzętu i to, że urządzenie nie zaczeka na serwer. Budujemy warstwę, która zbiera zdarzenia lokalnie, buforuje je przy braku łączności i dosyła do systemów centralnych, gdy połączenie wróci.
Jak zapewnić niezawodność integracji: idempotencja, retry, kolejki?
To różnica między integracją, która działa na demo, a taką, której można zaufać w produkcji. W logistyce komunikaty się gubią, sieci się rwą, a ten sam status potrafi przyjść dwa razy - nieprzygotowana integracja pokaże wtedy zdublowane przesyłki albo zgubi potwierdzenia dostawy. Dlatego projektujemy je wokół kilku zasad odporności:
- idempotencja - ten sam komunikat odebrany dwa razy daje jeden skutek, nie dwa,
- kolejki i brokery - zdarzenia przechodzą przez kolejkę, która wyrównuje ruch i nie gubi komunikatów przy skoku obciążenia,
- retry z wycofaniem - nieudane wywołanie jest ponawiane według rosnących odstępów, a nie w pętli co sekundę,
- kolejka komunikatów martwych - to, czego nie da się przetworzyć, ląduje w osobnym miejscu do analizy, a nie znika,
- monitoring i alerty - zespół widzi, że coś się zatkało, zanim zadzwoni klient.
Jakie kompetencje dostarczamy do integracji logistycznych?
Pod integracje dobieramy skład do konkretnej architektury, a nie „na zapas”. W takich projektach obsadzamy zwykle:
- architekta integracji, który projektuje przepływy, model danych i warstwę pośrednią,
- backend developerów budujących same połączenia, API i logikę mapowań,
- specjalistów od EDI, którzy znają realia EDIFACT, X12 i transportu plików,
- inżynierów DevOps, którzy stawiają kolejki, monitoring i wdrożenia.
Nie uczymy się więc integracji na koszt klienta - wchodzimy z ludźmi, którzy łączyli już systemy klasy enterprise z zewnętrznymi dostawcami.
Jak robimy to w RITS?
Robimy to jako partner nearshore z Polski, który dokłada kompetencje tam, gdzie ich brakuje. Nie udajemy, że mamy gotowe wdrożenie logistyczne na półce - dajemy za to inżynierów z realnym doświadczeniem w integracjach systemowych i projektach przemysłowych, którzy udźwigną EDI, API przewoźników i urządzenia w jednym projekcie.
Najczęściej działamy w modelu dedykowanego oprogramowania, gdy warstwę integracyjną trzeba zbudować od podstaw, albo wzmocnienia zespołu, gdy klient ma własny zespół i chce szybko dołożyć brakującą kompetencję. Różnice między tymi modelami rozpisaliśmy w artykule o modelach współpracy IT.
Od czego zacząć integracje systemów logistycznych?
Zacznij od zmapowania jednego, najważniejszego przepływu - na przykład od zamówienia w ERP, przez planowanie w TMS, po status od przewoźnika i potwierdzenie dla klienta. Ten jeden przepływ pokaże, które systemy muszą się spiąć, jakie formaty wchodzą w grę i gdzie dziś dane przepisuje się ręcznie - a to wyznacza zakres pierwszego etapu, architekturę warstwy integracyjnej i role, których potrzebujesz. Kolejnych partnerów dokłada się później, już na sprawdzonym fundamencie.
Spinasz systemy logistyczne, EDI, TMS, ERP i API przewoźników? Porozmawiajmy, dobierzemy zespół i architekturę integracji pod Twoją operację.