Linkway.BRIDGE i integracja systemów w logistyce

Integrację systemów w logistyce linkway.BRIDGE realizuje jako warstwę pośrednią: pobiera dane z TMS i ERP firmy i przekazuje je automatycznie tam, gdzie oczekuje ich kontrahent, na przykład do Project44, Transporeon, uTMS albo do jego własnego API. Połączenia konfiguruje i utrzymuje zespół Linkway, bez zmian w systemach firmy. Spedytor przestaje przepisywać te same statusy do kilku platform naraz.

Poniżej pokazujemy, kiedy firma transportowa potrzebuje takiej warstwy i jak płyną przez nią dane. Opisujemy też etapy konfiguracji oraz różnice wobec integracji budowanej przez własny dział IT. Opis funkcji modułu zawiera strona linkway.BRIDGE, a ten artykuł skupia się na zastosowaniach i decyzjach przed wdrożeniem.

Problem wielu platform kontrahentów

Przewoźnik albo spedycja w transporcie drogowym, która obsługuje kilku dużych zleceniodawców, szybko trafia na ten sam problem. Jeden klient wymaga statusów w Transporeon, drugi śledzi przewozy w Project44, trzeci pracuje w systemie uTMS, a czwarty udostępnia własne API REST. Każda platforma ma własny format danych i własny słownik statusów.

Bez warstwy integracji dane przenosi człowiek. Spedytor kopiuje status z TMS do jednej platformy, potem do drugiej, a przewidywany czas przyjazdu szacuje na podstawie ostatniej pozycji z GPS. Każda pomyłka jest widoczna u klienta, a spóźniony status wygląda w jego systemie tak samo jak spóźniony przewóz.

Źródłem problemu jest architektura: te same dane muszą trafić do wielu miejsc, a jedynym łącznikiem między systemami jest pracownik. Przy jednym kontrahencie ręczne przepisywanie mieści się w godzinach pracy. Każdy kolejny dokłada następną platformę do obsługi, więc praca rośnie szybciej niż liczba zleceń. Ile kosztuje taki sposób pracy, pokazuje porównanie Excel w transporcie kontra system TMS.

Firma potrzebuje warstwy integracji, gdy widzi u siebie takie sygnały:

• ten sam status przewozu trafia ręcznie do więcej niż jednej platformy,
• kontrahent zgłasza braki statusów albo spóźnione ETA, choć przewóz szedł zgodnie z planem,
• zlecenia z ERP trafiają do TMS przez eksport do pliku albo przez przepisywanie,
• dział IT odkłada kolejną integrację, bo utrzymuje poprzednie,
• nowy kontrahent wymaga platformy, której firma jeszcze nie obsługuje.

Skala ręcznego przekazywania danych

Skalę problemu łatwo policzyć na własnych danych. Przykład: firma obsługuje dziennie 40 zleceń dla zleceniodawców korzystających z platform, a każdy z nich oczekuje czterech statusów na zlecenie. To 160 ręcznych wpisów dziennie, zanim doliczy się aktualizacje ETA przy każdym opóźnieniu.

Każdy wpis jest okazją do pomyłki, a spóźniony wpis psuje wskaźnik terminowości tak samo jak spóźnione auto. Firmy, które przekazują dane ręcznie, wybierają więc między dwiema złymi opcjami: zatrudniają osobę do przepisywania albo godzą się na luki w danych u klienta.

Zleceniodawca, który korzysta z platformy, widzi jakość danych od każdego przewoźnika osobno i może brać ją pod uwagę przy kolejnych zleceniach. Braki w statusach stają się więc sprawą handlową, a nie tylko operacyjną.

Jak dane płyną przez linkway.BRIDGE

linkway.BRIDGE stoi między systemami firmy a platformami kontrahentów. Po stronie firmy łączy się z TMS i z systemem ERP, takim jak Comarch czy SAP. Obsługuje też systemy WMS, YMS, CRM oraz dane GPS. Po stronie kontrahentów przekazuje dane do Project44, Transporeon, uTMS, do API REST kontrahenta i do giełd ładunków.

Kierunek przepływu zależy od rodzaju danych. Zlecenia transportowe synchronizują się między ERP a TMS, więc zamówienie przewozu wpisane w ERP nie wymaga ponownego wprowadzenia w systemie transportowym. Dane o realizacji płyną w drugą stronę: z TMS do platform kontrahentów, które śledzą przewóz.

Warstwa pośrednia ma też uzasadnienie w liczbie połączeń. Gdy każdy system firmy łączy się bezpośrednio z każdą platformą, liczba połączeń szybko rośnie: cztery systemy i pięć platform mogą wymagać nawet 20 połączeń do zbudowania i utrzymania. Przy jednej warstwie pośredniej każdy system i każda platforma mają po jednym połączeniu, czyli razem dziewięć. Nowa platforma dokłada wtedy jedno połączenie, a nie cztery.

Pojęcia, które padają w projekcie integracji

• Middleware. Warstwa oprogramowania, która łączy niezależne systemy bez ich przebudowy. Przyjmuje dane w formacie jednego systemu i przekazuje je w formacie drugiego.
• API REST. Standard wymiany danych między aplikacjami przez zapytania HTTP. Przez takie interfejsy linkway.BRIDGE łączy się z platformami kontrahentów.
• Mapowanie statusów. Przypisanie statusów z TMS do słownika platformy kontrahenta. Status „rozładowano” z aplikacji kierowcy musi odpowiadać zdarzeniu, którego oczekuje platforma.
• Platforma widoczności. System, w którym zleceniodawca śledzi przewozy wielu przewoźników naraz, na przykład Project44.
• KPI. Mierzalne wskaźniki realizacji transportu, które kontrahent zbiera o przewoźniku, na przykład terminowość załadunku i rozładunku.
• EDI. Elektroniczna wymiana dokumentów między firmami w uzgodnionych formatach, na przykład EDIFACT, zwykle w plikach wysyłanych cyklicznie. API REST pozwala wymieniać dane na bieżąco, w chwili zdarzenia, a kanał dla każdego kontrahenta ustala się w analizie.

Jak wygląda interfejs udostępniający dane o pojazdach, opisuje artykuł o interfejsie API do śledzenia floty.

Co kontrahent widzi w swojej platformie

Dla kontrahenta wartość integracji zależy od jakości danych u źródła. Platforma pokaże tylko to, co wcześniej zapisał TMS, więc najpierw trzeba zadbać o statusy i pozycje pojazdów, a dopiero potem o ich przekazywanie.

Statusy powstają w aplikacji linkway.TRACKER, w której kierowca zmienia je jednym dotknięciem: dojazd na załadunek, w trasie, rozładowano, koniec zadania. Gdy traci zasięg, aplikacja zapisuje zdarzenie w telefonie i wysyła je później, z rzeczywistym czasem zdarzenia. Dla kontrahenta ma to znaczenie, bo wskaźniki terminowości liczy się z godzin zdarzeń, a nie z godziny, o której dane dotarły.

W TMS statusy trafiają do historii zlecenia z datą i źródłem zmiany. System odróżnia status wpisany w biurze od potwierdzenia z aplikacji kierowcy.

ETA wynika z pozycji pojazdu i planu trasy. Pozycje z ponad 230 systemów GPS zbiera linkway.INTEGRATOR, bez wymiany urządzeń, także w pojazdach podwykonawców. Sposób wyliczania opisuje artykuł ETA od Linkway, a znaczenie pozycji w pracy spedycji tekst o monitoringu dla branży transportowej.

ETA ma wartość tylko wtedy, gdy jest aktualne. Kontrahent planuje na jego podstawie przyjęcie towaru, więc przesunięcie o dwie godziny, które dotrze do niego po fakcie, szkodzi bardziej niż brak prognozy. Warto więc ustalić z kontrahentem, przy jakiej zmianie ETA oczekuje aktualizacji.

Mapowanie statusów na przykładzie

Aplikacja kierowcy i platforma kontrahenta rzadko używają tych samych nazw zdarzeń. Tabela pokazuje, jak statusy z linkway.TRACKER można przełożyć na zdarzenia, których zwykle oczekuje platforma śledzenia przewozów. Ostateczne mapowanie ustala się osobno dla każdej platformy.

Gdy platforma wymaga zdarzenia, którego aplikacja nie rejestruje, na przykład osobnego przyjazdu i odjazdu z każdego punktu, trzeba ustalić jego źródło. Może nim być status wpisany w biurze albo inne dane z TMS. Decyzja zapada w analizie, a nie po pierwszej reklamacji kontrahenta.

Zestaw KPI ustala kontrahent. Zwykle dotyczy terminowości załadunku i rozładunku albo kompletności statusów, a definicje wskaźników są częścią analizy przed konfiguracją. Warto je poznać wcześniej, bo wskaźnik liczony z niepełnych danych obciąża przewoźnika, choć przewóz przebiegł zgodnie z planem.

Integracja TMS z ERP i magazynem

Druga grupa połączeń działa wewnątrz firmy. Zlecenia transportowe synchronizują się z systemami ERP, takimi jak Comarch i SAP, oraz z systemem magazynowym. Zamówienie przewozu nie jest więc przepisywane z maila do linkway.TMS, a zmiana w ERP nie wymaga telefonu do spedytora.

Integracja z ERP wymaga porządku w danych podstawowych. Jeśli ten sam klient ma w ERP inny identyfikator niż w TMS, a adres rozładunku zapisano w dwóch wersjach, połączenie przeniesie ten bałagan dalej. Na etapie analizy warto więc ustalić, który system jest źródłem danych o kontrahentach i adresach.

Systemy WMS i YMS pozostają produktami innych dostawców. Gdy praca magazynu albo placu manewrowego wpływa na transport, linkway.BRIDGE włącza te systemy do obiegu zleceń. Na liście obsługiwanych systemów wewnętrznych jest też CRM. Firma nie musi więc wymieniać narzędzi, z których korzysta, żeby dane zaczęły płynąć automatycznie.

Najwięcej zyskuje firma, która pracuje na systemach kilku dostawców i nie chce migrować na jedną platformę. Każdy system zostaje na swoim miejscu, a między nimi powstaje spójna warstwa wymiany danych. Szerzej pisze o tym artykuł o integracji systemów magazynowych i ERP z TMS, a rolę samego TMS w takim układzie tekst dlaczego system TMS jest niezbędny w logistyce.

Obieg zlecenia od ERP do platformy kontrahenta

Na przykładzie jednego przewozu połączenia działają w takiej kolejności:

1. Dział sprzedaży rejestruje zamówienie klienta w ERP, a zlecenie transportowe pojawia się w linkway.TMS bez przepisywania.
2. Spedytor planuje trasę i wybiera przewoźnika, a reguły kontroli sprawdzają zlecenie przed wysyłką.
3. Kierowca zmienia statusy w aplikacji, a pozycję pojazdu dostarcza system GPS.
4. linkway.BRIDGE przekazuje statusy z ETA do platformy, z której korzysta zleceniodawca.
5. Po rozładunku faktura powstaje w linkway.TMS z danych zlecenia, z obsługą KSeF.

Każdy krok korzysta z danych wprowadzonych w poprzednim. Jeśli któryś odbywa się poza systemem, na przykład zamówienie przychodzi mailem, łańcuch się przerywa. Wtedy wraca ręczne przepisywanie.

Cztery etapy konfiguracji po stronie Linkway

Konfigurację i utrzymanie integracji prowadzi zespół Linkway, więc firma nie angażuje programistów ani nie modyfikuje swoich systemów. Projekt przechodzi przez cztery etapy:

1. Analiza środowiska. Zespół Linkway mapuje systemy firmy i platformy kontrahentów, a potem ustala, jakie dane i w jakim formacie mają przepływać w każdą stronę. Na tym etapie powstaje też mapowanie statusów i lista wskaźników dla każdego kontrahenta.
2. Konfiguracja połączeń. Zespół Linkway konfiguruje połączenia API. Systemy firmy zostają bez zmian, a Linkway nie potrzebuje dostępu do ich kodu.
3. Uruchomienie i testy. Przepływ danych jest sprawdzany we wszystkich kierunkach, zanim kontrahent zacznie z niego korzystać. Po testach statusy i ETA płyną automatycznie.
4. Utrzymanie i rozwój. Gdy kontrahent zmienia API swojej platformy, integrację dostosowuje Linkway. Nowe platformy dochodzą bez przebudowy całości i bez wpływu na działające połączenia.

Czas trwania etapów zależy od liczby platform i od tego, jak dobrze firma jest przygotowana. Po stronie firmy przydaje się kilka rzeczy przygotowanych przed analizą:

• lista kontrahentów z platformami, których wymagają, i osobami kontaktowymi po ich stronie,
• przykładowe zlecenia z pełnym przebiegiem statusów, na których da się sprawdzić mapowanie,
• wymagania kontrahentów dotyczące wskaźników i terminów przekazywania danych,
• osoba po stronie firmy, która zna obieg zleceń i zatwierdza wynik testów.

Dobrze przygotowana lista kontrahentów skraca analizę, bo każda platforma oznacza osobny słownik statusów i osobny zestaw wymagań. Kolejność uruchamiania platform warto ustalić według tego, który kontrahent najbardziej potrzebuje danych, a nie według tego, której integracji najłatwiej dokonać.

Pytania, na które odpowiada analiza

• Identyfikacja zlecenia. Po czym obie strony rozpoznają ten sam przewóz: po numerze zlecenia z TMS czy po numerze referencyjnym zleceniodawcy zapisanym w zleceniu.
• Zakres zdarzeń. Które statusy kontrahent chce dostawać i w jakim czasie od ich wystąpienia.
• Przewozy podwykonawców. Skąd wezmą się pozycja i statusy, gdy przewóz realizuje przewoźnik spoza floty własnej, na przykład z jego systemu GPS przez linkway.INTEGRATOR albo z aplikacji kierowcy po wpisaniu kodu zlecenia.
• Dane osobowe. Których danych kierowcy i pojazdu kontrahent naprawdę potrzebuje, a które mogą zostać w firmie.
• Kryteria odbioru. Jakie przypadki testowe muszą przejść, zanim połączenie obejmie wszystkie zlecenia danego kontrahenta.

Testy warto przeprowadzić na przypadkach brzegowych, bo przewóz wzorcowy działa prawie zawsze. Chodzi o zlecenie anulowane w trakcie, zmianę punktu rozładunku, przewóz realizowany przez podwykonawcę i status wysłany z opóźnieniem po utracie zasięgu. Każdy z nich wygląda po stronie platformy kontrahenta inaczej niż zwykły przewóz.

Własna integracja czy linkway.BRIDGE

Firma z własnym działem IT może zbudować połączenia samodzielnie. Pierwsza integracja zwykle nie jest problemem. Kłopot zaczyna się przy utrzymaniu: każda zmiana API po stronie kontrahenta wymaga pracy programisty, a każda nowa platforma to kolejny projekt.

Własna integracja ma sens, gdy połączenie jest jedno i rzadko się zmienia, a dział IT ma czas na jego utrzymanie. linkway.BRIDGE sprawdza się tam, gdzie kontrahentów przybywa, a każdy ma inną platformę. Ręczne przepisywanie danych nie jest tu trzecią drogą, tylko jej brakiem: działa przy jednym kontrahencie i przestaje działać przy kolejnych.

Przykład: spedycja z dwoma programistami obsługuje jednego dużego zleceniodawcę na Transporeon i własna integracja może jej wystarczyć. Gdy dochodzą zleceniodawcy z Project44 i z własnym API, programiści zaczynają spędzać czas na utrzymaniu połączeń zamiast na rozwoju systemów firmy. To dobry moment, żeby porównać koszt tego czasu z usługą utrzymywaną przez Linkway.

Własna integracja niesie też ryzyko kadrowe. Wiedza o połączeniu zostaje u programisty, który je napisał, a gdy ten odchodzi z firmy, każda zmiana po stronie kontrahenta zaczyna się od odtwarzania, jak działa kod.

Decyzji nie trzeba podejmować raz na zawsze. Firma może zacząć od jednej platformy i dokładać kolejne, bo nowe integracje nie wpływają na działające połączenia.

Pytania do dostawcy integracji

Niezależnie od wyboru warto zadać kilka pytań, zanim pierwsze połączenie ruszy:

• Kto utrzymuje połączenie, gdy kontrahent zmieni wersję API albo sposób logowania?
• Czy integracja wymaga zmian w systemach firmy albo dostępu do ich kodu?
• Kto widzi błąd przepływu i w jakim czasie na niego reaguje?
• Czy każdy przepływ danych jest zapisywany, tak żeby dało się odtworzyć wysyłkę sprzed miesiąca?
• Ile trwa dodanie kolejnej platformy kontrahenta i czy wpływa na działające połączenia?

Łatwo niedoszacować kosztu utrzymania. Platformy kontrahentów zmieniają wersje interfejsów i wygaszają stare metody logowania. Połączenie, którego nikt nie pilnuje, przestaje działać po cichu, a firma dowiaduje się o tym z reklamacji klienta.

Bezpieczeństwo i kontrola przepływów

Przez warstwę integracji przechodzą dane handlowe i operacyjne, w tym pozycje pojazdów i dane kierowców. linkway.BRIDGE szyfruje transmisję, kontroluje uprawnienia, prowadzi audyt każdego przepływu i monitoruje połączenia. Dla każdej wysyłki widać więc datę i kontrahenta, do którego trafiła.

Monitoring integracji pokazuje przepływ danych w czasie rzeczywistym. Błąd połączenia, na przykład komunikat odrzucony po zmianie po stronie platformy kontrahenta, zespół Linkway widzi od razu i reaguje na niego bez czekania na zgłoszenie klienta. Zapis przepływów przydaje się też w rozmowie handlowej: gdy kontrahent twierdzi, że statusy nie dochodziły, widać, co i kiedy zostało wysłane.

Pozycja pojazdu w godzinach pracy kierowcy wymaga ostrożności, bo pośrednio mówi o konkretnej osobie. Dobrą praktyką jest przekazywanie kontrahentowi tylko tego, czego wymaga umowa, na przykład pozycji w czasie realizacji jego zlecenia, a nie przez całą dobę. Zakres danych dla każdej platformy ustala się na etapie analizy. Konfiguracja wiąże przepływ z konkretnym zleceniodawcą, więc jego platforma dostaje dane jego zleceń, a nie całej firmy.

Udostępnienie kontrahentowi danych, które pozwalają zidentyfikować kierowcę, jest przetwarzaniem danych osobowych. Przed uruchomieniem połączenia warto potwierdzić z działem prawnym, na jakiej podstawie się odbywa i czy obejmują je umowy z kontrahentem.

Po stronie linkway.TMS dane klienta są w osobnej instancji i osobnej bazie, a uprawnienia sprawdzane są aż do poziomu zapytania do bazy danych. Szerzej o ochronie danych w branży pisze artykuł o bezpieczeństwie danych w systemach logistycznych.

Dla kogo jest linkway.BRIDGE

Moduł ma sens wszędzie tam, gdzie kilka systemów musi wymieniać dane bez udziału człowieka. W praktyce chodzi o cztery grupy firm:

• Przewoźnicy i spedycje z wieloma zleceniodawcami. Przekazują statusy i ETA kilku kontrahentom, a każdy wymaga ich w innej platformie.
• Operatorzy logistyczni 3PL. Obsługują zleceniodawców z różnymi systemami i nie chcą budować osobnej integracji dla każdego klienta. Praktykę takiego operatora opisuje artykuł 3PL w praktyce.
• Duże przedsiębiorstwa z własnym IT. Mają kilka systemów, na przykład TMS, ERP, WMS i CRM, ale dane między nimi nie płyną automatycznie.
• Firmy z systemami różnych dostawców. Chcą spójnej wymiany danych bez migracji na jedną platformę.

Mniejsza firma, której klienci nie wymagają statusów we własnych platformach, zwykle nie potrzebuje jeszcze warstwy integracji. Wystarcza jej linkway.TMS z aplikacją dla kierowcy, a linkway.BRIDGE dokłada w chwili, gdy pojawi się pierwszy zleceniodawca z własną platformą.

Ta kolejność ma uzasadnienie w danych. Integracja przekazuje dalej to, co powstaje w TMS i w aplikacji kierowcy, więc firma, która najpierw uporządkuje statusy i pozycje pojazdów, uruchamia połączenia z kontrahentami na gotowym materiale.

linkway.BRIDGE a pozostałe moduły

linkway.BRIDGE przekazuje dane, które powstają w innych modułach platformy Linkway. Każdy z nich działa osobno, więc firma dokłada je w kolejności, jakiej potrzebuje:

• linkway.TMS jest źródłem zleceń i historii ich statusów, z informacją, kto i skąd wprowadził zmianę.
• linkway.INTEGRATOR dostarcza pozycje pojazdów z ponad 230 systemów GPS, także z flot podwykonawców.
• linkway.TRACKER przysyła statusy i zdjęcia dokumentów z telefonu kierowcy, również po utracie zasięgu.
• linkway.AI pracuje na tych samych danych i sygnalizuje zlecenia zagrożone opóźnieniem, więc spedytor może uprzedzić kontrahenta.

Opublikowano: 18 maja 2024. Aktualizacja: 29 września 2026.

O autorze

Mikołaj Siemiątkowski - Project Manager w firmie Linkway

Specjalista w zakresie zarządzania procesami i optymalizacji projektów. Absolwent studiów podyplomowych Big Data - Analytics & Society w Collegium Da Vinci oraz Zarządzania i Inżynierii Produkcji na Uniwersytecie Ekonomicznym w Poznaniu. Z wykształcenia inżynier projektowania mebli, w swojej pracy łączy techniczne podejście z analitycznym spojrzeniem na dane.

Wszystkie artykuły autora - profil LinkedIn