Systemy IT w TSL - mapa systemów i integracje między nimi

Mapa systemów IT w TSL

Firma z branży TSL rzadko ma jeden system. Zwykle działa kilka programów, z których każdy powstał z innego powodu i w innym czasie. Systemy IT w TSL dzielą się na pięć klas, które tabela poniżej wymienia po kolei. Kłopoty zaczynają się na styku tych klas, bo każda z nich opisuje ten sam towar albo ten sam pojazd własnym językiem.

Tabela zestawia klasy z ich zadaniem oraz z danymi wytwarzanymi i pobieranymi. Dobrze przygotowana mapa systemów jest pierwszym dokumentem każdego projektu integracyjnego.

Reguła: każdy rodzaj danych ma jeden system nadrzędny, który jest jedynym miejscem jego edycji; pozostałe systemy tylko go odbierają.

Szerszy kontekst oprogramowania dla całego łańcucha opisuje artykuł o oprogramowaniu logistycznym, a zakres funkcji samego TMS wyjaśnia tekst o oprogramowaniu dla firm transportowych.

Systemy IT w TSL a właściciel danych

Pojęcie systemu nadrzędnego ma praktyczne znaczenie. Gdy klient zmienia adres rozładunku, zmiana powinna powstać w jednym miejscu i dotrzeć do pozostałych. Jeśli adres można edytować zarówno w ERP, jak i w TMS, po tygodniu istnieją dwie wersje, a dyspozytor nie wie, która jest prawdziwa.

Podział odpowiedzialności za dane

Poniższa tabela pokazuje typowy podział. Nie jest obowiązującym wzorcem, tylko punktem wyjścia do rozmowy, bo w każdej firmie część danych ma inne źródło.

Identyfikatory wspólne dla systemów

Wymiana danych wymaga wspólnego klucza. Numer zamówienia z ERP powinien przechodzić do WMS, do zlecenia w TMS i do awizacji w YMS bez zmian, a nie być przepisywany. W praktyce oznacza to tabelę powiązań albo dodatkowe pole zewnętrznego identyfikatora w każdym systemie. Bez niego zestawienie dostawy z fakturą odbywa się ręcznie na podstawie daty i nazwy klienta, a takie zestawienie zawodzi przy klientach z wieloma zamówieniami jednego dnia.

Jakość danych podstawowych przed integracją

Integracja przenosi także błędy. Jeśli w ERP ten sam kontrahent figuruje pod trzema kartami z różnymi adresami, po połączeniu z TMS dyspozytor zobaczy trzy pozycje i wybierze dowolną. Dlatego przed uruchomieniem wymiany warto oczyścić kartoteki, zwłaszcza kartotekę kontrahentów.

Podstawowym testem jest wyszukanie duplikatów po identyfikatorze podatkowym. Zapytanie poniżej wskazuje kontrahentów zapisanych więcej niż raz, a nazwy tabeli i kolumn są przykładowe.

SELECT nip, COUNT(*) AS liczba_kart
FROM dbo.kontrahent
WHERE nip IS NOT NULL
GROUP BY nip
HAVING COUNT(*) > 1
ORDER BY liczba_kart DESC;

Wynik nie musi oznaczać błędu, bo firma bywa zapisana osobno dla każdego oddziału. Wymaga jednak decyzji, która karta jest nadrzędna i jak pozostałe są z nią powiązane. Ta decyzja poprzedza integrację, a nie wynika z niej.

Przepływ jednego zamówienia przez systemy

Mapę najłatwiej sprawdzić na jednym zamówieniu. Zamówienie powstaje w ERP i trafia do magazynu, gdzie WMS przygotowuje kompletację. W tym czasie TMS tworzy zlecenie przewozu, a YMS rezerwuje okno na bramie. Kierowca przyjeżdża, a pozycja pojazdu z telematyki pozwala przewidzieć godzinę wjazdu. Po załadunku WMS zdejmuje towar ze stanu, TMS zmienia status kursu, a ERP dostaje dane do faktury.

Punkty styku i ich zdarzenia

Każde przejście między systemami jest zdarzeniem, które ma nazwę oraz wskazuje nadawcę i odbiorcę. Zdarzenie zamówienia przechodzi z ERP do WMS. Zdarzenie gotowości ładunku idzie z WMS do YMS i TMS. Zdarzenie dostawy wraca z TMS do ERP. Spisanie takiej listy zdarzeń przed rozpoczęciem prac integracyjnych pozwala uniknąć sytuacji, w której dwa systemy wysyłają to samo zdarzenie różnymi kanałami.

Połączenie magazynu z ERP opisuje szczegółowo tekst o integracji WMS z ERP przez REST i kolejki, a zestaw możliwych integracji programu magazynowego przedstawia artykuł o integracjach programu magazynowego z systemami zewnętrznymi.

Sposoby integracji systemów TSL

Wybór sposobu połączenia zależy od tego, czy system ma interfejs, jak szybko dane muszą dotrzeć i co ma się stać, gdy druga strona nie odpowiada. Cztery rozwiązania spotyka się najczęściej, a większość projektów łączy dwa z nich.

Ogólne zasady projektowania interfejsów REST zebrano w wytycznych Microsoft dotyczących projektowania API. Ich najważniejsza lekcja dla logistyki dotyczy idempotencji: to samo wywołanie wysłane dwa razy nie może utworzyć dwóch zleceń.

Komunikat zdarzenia i jego treść

Dobrze zaprojektowany komunikat niesie identyfikator zdarzenia oraz identyfikatory obiektu w obu systemach. Dochodzą do nich czas zdarzenia i dane, których potrzebuje odbiorca. Poniższy przykład jest komunikatem o dostarczeniu ładunku. Nazwy pól są przykładowe i nie opisują interfejsu żadnego produktu.

{
  "id_zdarzenia": "b0f6a8d2-6b7c-4c1e-9d3a-2f0a1e5c7a10",
  "typ": "ZlecenieDostarczone",
  "nr_zlecenia_tms": "ZT-2026-01042",
  "nr_zamowienia_erp": "ZAM/2026/08811",
  "czas_zdarzenia": "2026-09-30T13:42:10Z",
  "potwierdzenie": { "dokument": "CMR", "odebral": "Jan Kowalski" }
}

Pole id_zdarzenia pozwala odbiorcy rozpoznać ponowną dostawę tej samej wiadomości i zignorować ją. Bez niego ponowienie po błędzie sieci utworzyłoby drugą fakturę albo drugą zmianę stanu.

Spójność między zmianą a komunikatem

Najczęstszy błąd integracji polega na tym, że system zmienia status zlecenia, a wysyłka komunikatu się nie udaje. Dane w systemach rozjeżdżają się bez śladu. Rozwiązaniem jest zapisanie komunikatu do tabeli wychodzącej w tej samej transakcji co zmiana, a wysyłanie go dopiero z tej tabeli w osobnym procesie. Przykład w T-SQL pokazuje ten wzorzec. Składnię instrukcji opisuje dokumentacja transakcji w T-SQL.

DECLARE @id int = 1042;
DECLARE @json nvarchar(max) =
    N'{"typ":"ZlecenieDostarczone","nr_zlecenia_tms":"ZT-2026-01042"}';

BEGIN TRANSACTION;

UPDATE dbo.zlecenie
SET status = 'Dostarczone'
WHERE id_zlecenia = @id;

INSERT INTO dbo.wiadomosc_wychodzaca (id_wiadomosci, tresc_json, utworzono, wyslano)
VALUES (NEWID(), @json, SYSUTCDATETIME(), NULL);

COMMIT TRANSACTION;

Osobny proces odczytuje wiersze z pustą kolumną wyslano, wysyła je i po potwierdzeniu odbioru wpisuje czas. Wiadomość nie zginie. Obie operacje zostają zapisane razem albo obie zostają wycofane.

Integracja z telematyką i danymi GPS

Telematyka jest klasą systemów, w której integracja jest najtrudniejsza z przyczyn organizacyjnych, a nie technicznych. Flota bywa zróżnicowana, a każdy producent pojazdów i dostawca urządzeń ma własny interfejs. Firmy współpracujące z podwykonawcami dostają dane od kilku dostawców jednocześnie, bo przewoźnik zewnętrzny ma własny system.

Według opisu producenta Linkway.INTEGRATOR pobiera dane z wielu źródeł i prezentuje je w jednym systemie. Producent wymienia między innymi TomTom oraz Scania Fleet Management. Szczegóły działania zawiera artykuł o kontroli danych GPS w Linkway.INTEGRATOR, a przykład konkretnej integracji urządzeń opisuje tekst o Hertz GPS i Linkway.

Zasady udostępniania lokalizacji pojazdu

Integracja dotyczy nie tylko techniki, lecz także zgody na udostępnienie danych. Producent opisuje mechanizm, w którym właściciel pojazdu wskazuje kontrahenta oraz czas, na jaki udostępnia lokalizację, a zgodę można potwierdzić wiadomością e-mail i w każdej chwili cofnąć. Dane mogą dotyczyć wyłącznie czasu trwania zlecenia. Można też zdecydować, czy przekazywana ma być sama lokalizacja, czy także inne parametry, takie jak temperatura w chłodni.

Reguła: lokalizacja cudzego pojazdu jest danymi, którymi zarządza jego właściciel, więc dostęp powinien wygasać razem ze zleceniem.

Wspólna oś czasu dla magazynu i transportu

Trzy systemy operacyjne opisują ten sam przewóz z trzech stron. Magazyn wie, kiedy towar będzie gotowy. Plac wie, kiedy pojazd może wjechać. Transport wie, kiedy pojazd faktycznie dojedzie. Dopiero zestawienie tych trzech czasów pozwala ustalić realne okno załadunku.

W ofercie SoftwareStudio magazyn obsługuje Studio WMS.net. Awizacje oraz okna czasowe obsługuje moduł opisany w tekście o awizacjach w Studio VSS.net. Podstawy działania systemu magazynowego wyjaśnia artykuł o systemie zarządzania magazynem WMS. Strony produktowe zawierają dokładny opis funkcji: Studio WMS.net oraz Studio VSS.net.

Awizacja jako zdarzenie integracyjne

Awizacja jest naturalnym punktem styku, bo zawiera dane potrzebne każdej ze stron. Są to numer zlecenia oraz planowana godzina, do których dochodzą typ ładunku i numer bramy. Jeśli TMS przekazuje ją do YMS automatycznie, a YMS odsyła potwierdzony termin, dyspozytor nie musi dzwonić na magazyn. To samo dotyczy zmiany: przesunięcie kursu w TMS powinno przesunąć okno na bramie bez dodatkowej czynności.

Giełdy transportowe i platformy sprzedaży

Poza pięcioma klasami wewnętrznymi firma łączy się z systemami zewnętrznymi. Giełda transportowa dostarcza zapytania o przewóz, które powinny trafiać do TMS jako szkice zleceń, a nie być przepisywane. Platforma sprzedaży internetowej przekazuje zamówienia, z których ERP tworzy dokumenty wydania. Oba przypadki obciążają integrację nieprzewidywalnym ruchem, bo to zewnętrzny partner ustala moment oraz liczbę wysyłanych wiadomości.

Dlatego integracja z partnerem zewnętrznym powinna kończyć się walidacją na wejściu. Wiadomość z brakującym adresem albo nieznanym kodem produktu trafia do kolejki wyjątków i czeka na decyzję człowieka, zamiast zatrzymywać całą wymianę.

Monitorowanie i zabezpieczenie integracji

Integracja, która działa, dopóki nikt nie patrzy, nie jest integracją, lecz nadzieją. Każde połączenie potrzebuje dziennika wymienionych komunikatów oraz mechanizmu ponawiania. Potrzebna jest też kolejka wiadomości nieprzetworzonych, do której ktoś regularnie zagląda. Wiadomości, które nie przeszły walidacji, nie mogą blokować całej kolejki.

• Ponawianie z opóźnieniem - po błędzie system czeka coraz dłużej między próbami, żeby nie przeciążać drugiej strony, a po kilku nieudanych próbach przenosi wiadomość do kolejki błędów.
• Alert na brak ruchu - jeśli przez ustalony czas nie przyszedł żaden komunikat, choć zwykle przychodzą, system zgłasza awarię łącza, zanim zauważy ją użytkownik.

Osobną kwestią jest zestawianie danych z kilku systemów w jednym raporcie. Sprawdza się osobna baza raportowa albo widoki, z których korzysta narzędzie raportujące. Zasady pracy z takimi raportami opisuje tekst o SQL Report Builder.

Bezpieczeństwo i uprawnienia w integracjach

Każde połączenie między systemami jest kanałem, przez który mogą wyciec dane o klientach i ładunkach. Interfejs korzysta z osobnego konta technicznego z minimalnymi uprawnieniami, ograniczonymi do potrzebnych operacji. Konto integracji z telematyką nie powinno mieć dostępu do faktur, a konto integracji z ERP nie powinno mieć dostępu do pozycji pojazdów.

• Szyfrowanie połączenia - komunikacja między systemami przechodzi wyłącznie przez TLS, także wewnątrz sieci firmowej, bo wtedy przechwycenie ruchu nic nie daje.
• Rotacja kluczy - klucze i tokeny mają datę ważności, a ich wymiana nie wymaga przerwy w działaniu, ponieważ przez pewien czas obowiązują dwa klucze.

Dziennik integracji zawiera także dane osobowe, na przykład imię i nazwisko odbierającego towar. Okres jego przechowywania powinien wynikać z zasad ochrony danych obowiązujących w firmie, co warto uzgodnić z inspektorem ochrony danych lub prawnikiem.

Kolejność wdrażania systemów w firmie TSL

Firma, która kupuje kolejne systemy, powinna zaczynać od integracji ze zleceniem, a nie od funkcji. System bez interfejsu do ERP oznacza ręczne przepisywanie, które szybko zniweczy oszczędności. Przy każdym wdrożeniu warto zapytać, w jaki sposób system odbiera dane z nadrzędnego źródła i jak zwraca wynik.

Firmy z rozbudowanym transportem zaczynają zwykle od TMS, bo to on generuje przychód. Magazyn i plac dołączają później. Przegląd funkcji TMS zawiera artykuł o TMS jako programie do zarządzania transportem, a wariant chmurowy opisuje tekst o systemie TMS online. Połączenia w logistyce, w tym portal klienta i wymianę EDI, omawia artykuł o Linkway.BRIDGE.