W transporcie i spedycji pracę często zjada nie sam przewóz, tylko to, co go otacza. Zlecenie przychodzi mailem, potwierdzenie wraca w PDF, dokument CMR jedzie z kierowcą, a stawka ląduje w arkuszu jednej osoby. Dla dyrektora transportu albo rozliczeń oznacza to jedno: informacja o zleceniu rozjeżdża się po dziesiątkach miejsc, a żadne z nich nie jest źródłem prawdy. Dobrze zaprojektowany system TMS scala ten obieg, od przyjęcia zlecenia po wystawienie faktury.
Z naszego doświadczenia najtrudniejsze nie jest narysowanie ekranu „lista zleceń”, tylko domknięcie całego łańcucha dokumentów i pieniędzy tak, żeby się zgadzał, a liczą się tu zgodność danych, audytowalność i integracje. Nie udajemy, że mamy gotowe pudełko na każdą spedycję, za to obsadzamy projekt ludźmi, którzy takie systemy projektują i utrzymują w modelu wzmocnienia zespołu lub zespołu dedykowanego.
Dlaczego fracht tonie w papierach i mailach?
Papier i skrzynka mailowa działają, dopóki wolumen jest mały. Problem zaczyna się przy skali: każda zmiana trasy, korekta stawki i brakujący dokument wymagają ręcznego przeklejania, a rozliczenie powstaje „z pamięci”. Najczęściej widzimy kilka powtarzalnych źródeł tarcia:
- zlecenia w wielu kanałach naraz (mail, telefon, portal klienta, EDI), bez jednego rejestru,
- dokumenty luzem w PDF i skanach, oderwane od konkretnej przesyłki,
- stawki w arkuszach, które nie nadążają za aneksami i dopłatami paliwowymi,
- rozliczenia na koniec miesiąca, kiedy połowy szczegółów już nikt nie pamięta.
Jak uporządkujemy ewidencję zleceń i przesyłek?
Fundamentem TMS jest spójny rejestr, w którym zlecenie, przesyłka i dokumenty to jeden połączony rekord, a nie trzy osobne światy. Projektujemy go tak, by odwzorowywał realny przepływ pracy spedytora: warstwa prowadzi zlecenie przez kolejne statusy, od przyjęcia, przez przydział przewoźnika i pojazdu, po dostawę i zamknięcie, a każda zmiana zostawia ślad. Przesyłkę opisujemy atrybutami używanymi w rozliczeniu i raportach (wymiary, waga, liczba palet, Incoterms, trasa, przewoźnik), a te same dane napędzają potem taryfikację i fakturę.
Czym jest e-CMR i jak cyfryzujemy dokumenty transportowe?
Klasyczny list przewozowy CMR to papier z podpisami, który łatwo zgubić i trudno przeszukać. e-CMR to jego elektroniczny odpowiednik oparty na protokole dodatkowym do konwencji CMR, z podpisem cyfrowym i śladem czasowym zamiast długopisu. Dla rozliczeń zmienia to regułę gry: dokument jest dostępny od razu po dostawie, a nie po tygodniu, kiedy wróci teczka kierowcy.
W projektach dokumentowych spinamy obieg tak, aby każdy dokument był przypięty do konkretnej przesyłki i statusu. Cyfryzujemy nie tylko sam e-CMR, lecz całą rodzinę papierów: potwierdzenia dostawy (POD), zlecenia, dokumenty magazynowe, listy pakowe. Gdy klient nadal potrzebuje papieru, zostawiamy wydruk zgodny z wersją cyfrową.
Jak przygotować dane do odprawy celnej?
Przy przewozach międzynarodowych odprawa celna wymaga danych kompletnych i spójnych, inaczej przesyłka staje na granicy. TMS może te dane przygotować raz, u źródła, i podać dalej zamiast kazać je przepisywać do kolejnego systemu.
Dokładamy do rejestru pola potrzebne do zgłoszeń: kody taryfy celnej (HS/CN), kraj pochodzenia, wartość towaru, waga, dane nadawcy i odbiorcy. Nie udajemy agencji celnej, więc projektujemy raczej czysty eksport i integrację z systemami celnymi lub brokerem: dane wychodzą w uzgodnionym formacie, gotowe do zgłoszenia.
Jak działa silnik kalkulacji stawek i taryf?
Stawka w transporcie rzadko jest jedną liczbą. To zwykle taryfa zależna od relacji, wagi, objętości, stref, dopłat paliwowych i indywidualnych aneksów z klientem, a kiedy to wszystko żyje w arkuszu, każda zmiana jest ryzykiem. Dlatego sercem TMS jest silnik taryf liczący stawkę regułami, a nie z pamięci handlowca.
Taki silnik składamy z kilku elementów, które muszą ze sobą grać:
- cenniki i taryfy per klient, relacja, strefa i rodzaj ładunku,
- reguły dopłat (paliwowa, celna, ADR, awizacja) nakładane automatycznie,
- wersjonowanie cenników z datami obowiązywania, żeby stara stawka nie policzyła się na nowym zleceniu,
- symulacja i porównanie wariantów przed potwierdzeniem zlecenia.
Ta sama logika wycenia zlecenie na wejściu i rozlicza je na wyjściu, więc oferta i faktura nareszcie się zgadzają.
Jak automatyzujemy fakturowanie i rozliczenia (settlement)?
Rozliczenie pokazuje wszystkie wcześniejsze braki. Jeśli dane zlecenia, dokumenty i stawki siedzą w jednym miejscu, faktura i rozliczenie z przewoźnikiem powstają niemal same. Budujemy warstwę settlement, która zestawia to, co uzgodnione, z tym, co wykonane, i wyłapuje różnice, zanim trafią do księgowości.
Ta warstwa robi kilka rzeczy naraz: nalicza należność z klienta i koszt przewoźnika, zbiera dopłaty i korekty, sprawdza, czy komplet dokumentów (POD, e-CMR) jest na miejscu, i przygotowuje dane do systemu finansowo-księgowego. Rozliczenie przewoźników działa na tej samej logice, więc marża jest widoczna na każdym zleceniu, a nie dopiero w raporcie miesięcznym.
Jak spiąć TMS z EDI i ERP (integracje)?
TMS nie żyje sam. Po jednej stronie są klienci i ich zlecenia przez EDI, po drugiej ERP, księgowość, telematyka i portale przewoźników. Wartość systemu rośnie tam, gdzie przestaje być wyspą.
Spinamy TMS z otoczeniem tak, aby dane krążyły bez ręcznego przepisywania:
- EDI (np. EDIFACT, komunikaty IFTMIN/IFTSTA) do wymiany zleceń i statusów z klientami,
- ERP i system FK dla faktur, kosztów i kartotek kontrahentów,
- telematyka i GPS dla statusów dostawy i czasów na trasie,
- API i webhooki do portali klientów oraz giełd transportowych.
Każdą integrację traktujemy jak kontrakt: ustalony format, obsługa błędów, ponawianie i monitoring, żeby jeden błędny komunikat nie zatrzymał całego obiegu.
Jakie kompetencje dostarczamy do projektu TMS?
W tym temacie nie sprzedajemy wdrożenia „z półki”, tylko ludzi, którzy potrafią taki system zaprojektować, zbudować i utrzymać. Skład dobieramy pod konkretny zakres, nie na zapas. Zwykle obsadzamy role, które realnie pchają projekt TMS do przodu:
- analityk / architekt rozumiejący procesy spedycyjne i mapujący je na model danych,
- backend developer budujący silnik taryf, settlement i warstwę integracji,
- frontend developer odpowiadający za czytelny panel spedytora i rozliczeń,
- specjalista od integracji / EDI łączący TMS z ERP, celnym i telematyką,
- opcjonalnie DevOps, który stawia środowiska, pipeline CI/CD i monitoring.
Kompetencje weryfikujemy przed startem, a zespół wpinamy w rytm pracy klienta.
Jak robimy to w RITS?
Robimy to jako partner nearshore z Polski, z doświadczeniem w projektach o wysokiej złożoności danych i integracji. Nie udajemy, że mamy w szufladzie wdrożenie TMS dla konkretnej spedycji, za to dostarczamy kompetencje, które domykają taki projekt od analizy po utrzymanie.
Najpierw rozumiemy proces, a dopiero potem dobieramy technologię i skład. Pracujemy w zbliżonej strefie czasowej, więc zespół wchodzi bez długiego rozruchu i stopniowo przejmuje odpowiedzialność za obieg zleceń, dokumentów i rozliczeń. Najczęściej działamy jako dedykowane oprogramowanie budowane przez nasz zespół albo w modelu wzmocnienia zespołu.
Od czego zacząć budowę systemu TMS?
Zacznij od jednego, najbardziej bolesnego odcinka, zwykle jest nim droga od zlecenia do faktury. To on pokazuje, jakich danych brakuje, które dokumenty trzeba scyfryzować i gdzie taryfa rozjeżdża się z rozliczeniem. Reszta modułów dokłada się potem na tym samym fundamencie. Różnice między modelami współpracy opisaliśmy w artykule o modelach współpracy IT.
Porządkujesz fracht, dokumenty i rozliczenia? Porozmawiajmy, dobierzemy zespół i architekturę pod Twój system TMS.