Transporto valdymo sistema (TMS): maršrutų optimizavimas ir krovinių sekimas 2026 m.

1. Kur dingsta EBITDA: tuščia rida, Excel chaosas ir dispečerių perkrova

Vidutinė Lietuvos transporto ar distribucijos įmonė, valdanti 20–50 transporto priemonių parką, kas mėnesį „sudegina“ nuo 8 000 iki 18 000 eurų vien dėl fragmentuotų procesų: tuščių kilometrų, vėluojančių statusų atnaujinimų ir rankinio duomenų suvedinėjimo tarp el. pašto, „Viber“ žinučių bei apskaitos programų. Kai dispečeris privalo atidaryti atskirą GPS sekimo platformą („Mapon“, „Ruptela“ ar „Teltonika“), rankiniu būdu suvesti važtaraščio duomenis į „Rivilę“ ar „Directo“, suformuoti XML bylą VMI i.VAZ posistemei ir dar sužiūrėti vairuotojo darbo-poilsio režimą pagal tachografo duomenis – vėlavimai tampa neišvengiami.

Kiekviena papildoma 100 kilometrų tuščia rida vienam vilkikui generuoja apytiksliai 32–36 litrus dyzelino tiesioginių sąnaudų, neskaičiuojant vilkiko nusidėvėjimo ir vairuotojo atlyginimo. Esant 30 vilkikų parkui, tai reiškia daugiau nei 3 800 eurų grynojo pelno praradimą kiekvieną mėnesį vien dėl to, kad atgalinio krovinio paieška ar maršruto perskirstymas nebuvo sinchronizuotas realiuoju laiku. Šiuolaikinė transporto valdymo sistema tms nebėra prabanga stambiesiems vežėjams; 2026 m. tai yra pagrindinis inžinerinis svertas, apsaugantis įmonės maržą nuo augančių degalų akcizų, mobilumo paketo reikalavimų ir darbo jėgos brangimo.

2. Šiuolaikinės TMS anatomija: algoritminis maršrutizavimas ir telemetrija

Standartinės „dėžutinės“ sistemos dažniausiai siūlo tik statinį maršrutų planavimą pagal atstumą. Tačiau reali logistika reikalauja dinaminio planavimo algoritmais (VRP – Vehicle Routing Problem su laiko langais ir krovos apribojimais). Moderni transporto valdymo sistema tms privalo vienu metu apdoroti kelis kintamųjų sluoksnius:

Fizikiniai transporto priemonės apribojimai: Ašių apkrovos, bendroji masė, puspriekabės tūris, temperatūrinis režimas (šaldytuvų sekimas) ir ADR pavojingumo klasės.
Dinaminiai maršrutizavimo faktoriai: Kelių mokesčių (Toll collect, BelToll, Eurovignette) kaštai, eismo kamščiai realiuoju laiku, tiltų aukščių ribojimai ir kuro stočių tinklo lojalumo nuolaidos.
Reguliaciniai apribojimai: ES reglamento (EB) Nr. 561/2006 vairavimo ir poilsio laiko taisyklės, likęs vairuotojo paros/savaitės vairavimo laikas tiesiai iš skaitmeninio tachografo (DDD failų telemetrija).
Verslo prioritetai: Kliento pristatymo laiko langai (Time-Windows, SLA baudos), iškrovimo rampos pralaidumas ir grįžtamųjų pakuočių (padėklų) apskaita.

Suvedus šiuos parametrus į optimizavimo variklį, maršrutas suformuojamas per kelias sekundes, sumažinant bendrąjį maršruto ilgį 8–14%, palyginti su patyrusio logisto rankiniu planavimu. Be to, sistema automatiškai generuoja geozonų (Geofencing) įvykius: vilkikui kirtus kliento sandėlio perimetrą, gavėjui išsiunčiamas automatinis pranešimas su ETA (Estimated Time of Arrival), o sandėlio valdymo sistemai (WMS) perduodamas signalas ruošti krovos rampą.

3. Sistemos architektūra: nuo CAN-bus magistralės iki debesis

Efektyvi TMS architektūra remiasi asinchroniniais mikropaslaugų moduliais, kurie atskiria didelės spartos telemetrijos duomenų srautus nuo transakcinių verslo logikos operacijų. Toliau pateikta schema iliustruoja, kaip duomenys iš vilkiko CAN magistralės ir GPS įrenginių pasiekia dispečerio ekraną bei ERP sistemą realiuoju laiku:

+----------------------------------------------------------------------------------------------------+
|                                    TRANSPORTO TELEMETRIJOS SLUOKSNIS                              |
|  [Vilkikas: Teltonika / Ruptela] ---> MQTT / TCP Srautas ---> [API Gateway / Event Ingestion]     |
|   - CAN-bus (Kuras, RPM, Greitis)                                                                  |
|   - Skaitmeninis Tachografas (DDD)                                                                 |
|   - BLE Temperatūros Davikliai                                                                     |
+-------------------------------------------------+--------------------------------------------------+
                                                  |
                                                  v
+----------------------------------------------------------------------------------------------------+
|                                   TMS BRANDUOLYS (CENTRAL CORE)                                    |
|  +---------------------------+  +---------------------------+  +--------------------------------+  |
|  | Dinaminis Maršrutizatorius|  | Renginių & Būsenų Variklis|  | Vairuotojų PWA Aplikacija      |  |
|  | (VRP / Geofence Engine)   |  | (Status Machine, Alerts)  |  | (Task List, e-CMR, Dokobit)    |  |
|  +---------------------------+  +---------------------------+  +--------------------------------+  |
|                                 | PostgreSQL + TimescaleDB  |                                      |
+---------------------------------+-------------+-------------+--------------------------------------+
                                                |
                                                v
+----------------------------------------------------------------------------------------------------+
|                                INTEGRACIJŲ IR ATASKAITYBOS SLUOKSNIS                               |
|  +------------------------+   +-----------------------+   +-------------------------------------+  |
|  | Valstybinės Sistemos   |   | Įmonės ERP Sistemos   |   | B2B Klientų Portalas                |  |
|  | - VMI i.VAZ (SOAP/REST)|   | - Rivilė GAMA REST API|   | - Gyvas žemėlapis (Live Track &     |  |
|  | - i.SAF sąskaitos      |   | - Directo / B1.lt API |   |   Trace per UUID)                   |  |
|  | - Regitra / Kelių Mok. |   | - Automatizuotas Actas|   | - El. parašas (Smart-ID / Dokobit)  |  |
|  +------------------------+   +-----------------------+   +-------------------------------------+  |
+----------------------------------------------------------------------------------------------------+

Duomenų srautas prasideda transporto priemonėje: borto kompiuteris fiksuoja kuro sąnaudas, tachografo būseną ir GPS koordinates kas 5–15 sekundžių. Šie duomenys per MQTT protokolą siunčiami į apdorojimo vartus. Čia geofencing modulis tikrina, ar koordinatės patenka į iškrovimo/pakrovimo taškus. Jei aptinkamas atvykimas, įvykis aktyvuoja atitinkamą verslo logikos grandinę: atnaujinamas užsakymo statusas, siunčiama notifikacija klientui ir automatiškai paruošiamas elektroninis važtaraštis.

4. Integracijos su Lietuvos ekosistema: Rivilė, Directo, i.VAZ ir Dokobit

Lietuvos logistikos sektorius turi griežtą teisinį ir reguliacinį rėmą, kurio tarptautinės TMS sistemos (pvz., vokiškos ar JAV platformos) dažniausiai nepalaiko be itin brangių modifikacijų. Mūsų diegiama transporto valdymo sistema tms yra pilnai pritaikyta vietos reikalavimams:

VMI i.VAZ posistemė (Elektroniniai važtaraščiai)

Pagal LR teisės aktus, krovinių gabenimas Lietuvos keliais reikalauja laiku pateikti važtaraščio duomenis į i.MAS (i.VAZ posistemę). Rankinis važtaraščių suvedimas VMI portale atima nuo 5 iki 10 minučių kiekvienam reisui. TMS sistemoje suformuotas maršrutas automatiškai išsiunčia XML pranešimą per VMI SOAP/REST žiniatinklio paslaugą, gauna unikalų i.VAZ registracijos numerį ir brūkšninį kodą, kuris iškart atvaizduojamas vairuotojo mobiliajame įrenginyje. Nutikus maršruto pakeitimui (pvz., pasikeitus transporto priemonei ar vairuotojui), atnaujinimas VMI sistemai perduodamas per kelias sekundes be dispečerio įsikišimo.

Buhalterinės ir ERP sistemos: Rivilė GAMA, Directo, B1.lt

Didžiausia įmonių klaida – duomenų dubliavimas. Sukūrus reisą TMS sistemoje, sąskaitos-faktūros, kuro nurašymo aktai ir vairuotojų komandiruočių dienpinigiai privalo automatiškai sinchronizuotis su apskaitos programa:

Rivilė GAMA (REST API): Automatinis važtaraščio importas į vidinį judėjimą arba pardavimus. Kuro likučių suderinimas pagal degalinių kvitų importą ir telemetrijos parodymus.
Directo API: Užsakymų būsenų sinchronizavimas realiuoju laiku, automatinis pardavimo sąskaitų generavimas klientui vos tik vairuotojas gauna parašą apie sėkmingą pristatymą.
B1.lt: Lengvas krovinių ir atsiskaitymų duomenų eksportas mažesnėms distribucijos įmonėms.

Dokobit ir Smart-ID integracija vairuotojų dokumentams

Popieriniai CMR važtaraščiai kelia nuolatinę riziką: jie pasimeta, ištepami, o sąskaitos išrašymas užtrunka 2–4 savaites, kol originalas grįžta į buhalteriją. Integravus el. pasirašymą per Dokobit API arba kvalifikuotą Smart-ID parašą, krovinio perdavimo aktas patvirtinamas vietoje. Skaitmeninis e-CMR su laiko žyma ir GPS koordinatėmis iškart tampa prieinamas buhalterijai, todėl sąskaitą faktūrą klientui galima pateikti tą pačią dieną.

5. Palyginimas: Excel vs Standartinis SaaS vs Individuali TMS

Daugelis vadovų renkasi tarp dviejų kraštutinumų: „nemokamo“ Excel lapo, kuris ilgainiui tampa nevaldomu monstru, arba brangaus standartinio užsienietiško SaaS sprendimo, reikalaujančio brangios mėnesinės licencijos už kiekvieną vilkiką ir neturinčio integracijų su Lietuvos sistemomis. Žemiau pateikta reali technologijų palyginimo analizė:

Procesas	Tradicinis būdas (Excel / rankinis)	Suderinta.lt individualus sprendimas	Finansinis efektas / sutaupymas
Reisų ir maršrutų planavimas	Dispečeris planuoja „iš atminties“, maršrutas siunčiamas SMS/Viber žinute.	Automatinis VRP algoritmas, atsižvelgiantis į krovos langus ir vairuotojo poilsį.	Tuščios ridos sumažinimas 9–14%, sutaupoma ~1 200 €/mėn. vilkikui.
i.VAZ važtaraščių deklaravimas	Rankinis duomenų vedimas į VMI portalą (5–10 min. vienam važtaraščiui).	100% automatinis generavimas per API vos patvirtinus krovinio planą.	Sutaupoma 40–60 dispečerio darbo valandų per mėnesį (~800–1 200 €).
Kuro apskaita ir kontrolė	Kuro kortelių išklotinių lyginimas su odometro parodymais kartą per mėnesį.	CAN-bus duomenų ir kuro pylimo kvitų sutikrinimas realiuoju laiku (L/100 km).	Eliminuojami kuro nutekėjimai, kuro sąnaudų kritimas 3–6%.
Klientų informavimas (Track & Trace)	Nuolatiniai telefono skambučiai dispečeriui: „Kur dabar mašina?“.	Unikali nuoroda klientui su gyvu vilkiko judėjimu ir tiksliu ETA laiku.	70% mažiau skambučių, didesnis klientų lojalumas ir aukštesnis SLA.
Sąskaitų išrašymas ir buhalterija	Laukiama fizinio CMR grįžimo (10–25 d.), rankinis vedimas į Rivilę/Directo.	e-CMR su skaitmeniniu parašu akimirksniu sukuria sąskaitą ERP sistemoje.	Pinigų srauto (Cash Flow) pagreitėjimas 14–20 dienų.

6. Finansinis ROI modelis: 25 vilkikų parko atsipirkimas per 68 dienas

Norint įvertinti, ar individuali transporto valdymo sistema tms yra finansiškai pagrįsta investicija, pažvelkime į realius skaičius. Paimkime tipinę Lietuvos distribucijos/logistikos įmonę:

Parko dydis: 25 transporto priemonės (vilkikai arba tolimųjų reisų furgonai).
Vidutinė vieno automobilio rida: 9 000 km per mėnesį.
Bendra parko rida: 225 000 km/mėn.
Vidutinės degalų sąnaudos: 29 l / 100 km, dyzelino kaina: 1,35 €/l be PVM.
Dispečerių / administratorių komanda: 3 darbuotojai (valandinis įkainis su mokesčiais: 20 €/val.).

Mėnesiniai nuostoliai prieš diegiant TMS:

Neoptimizuoti maršrutai ir tuščia rida: Iš 225 000 km apie 12% sudaro neefektyvūs kilometrai (27 000 km). Optimizavimo algoritmas sumažina šią ridą bent 5% (11 250 km). Degalų nuostoliai: (11 250 km / 100) * 29 l * 1,35 € = 4 404,38 €/mėn.
Dispečerių laiko švaistymas: Kiekvienas dispečeris sugaišta 2,5 val. per dieną rankiniam i.VAZ pildymui, skambučiams vairuotojams ir ataskaitų darymui Excel. 3 darbuotojai * 2,5 val. * 21 d.d. = 157,5 val./mėn. Finansinė išraiška: 157,5 val. * 20 € = 3 150,00 €/mėn.
Vėluojantis sąskaitų pateikimas: Apyvartinio kapitalo įšaldymas dėl vėluojančių CMR dokumentų generuoja vidutiniškai 800 € palūkanų/faktorigo kaštų per mėnesį.

Bendras mėnesinis sutaupymas įdiegus sistemą: 4 404 € + 3 150 € + 800 € = 8 354 € / mėn.

Investicijos atsipirkimo (ROI) skaičiavimas:

Individualios TMS sistemos architektūros sukūrimas, integracija su Rivilė GAMA, GPS telemetrijos pajungimas ir i.VAZ automatizavimas vidutiniškai reikalauja 18 000 – 19 000 € vienkartinės investicijos.

Atsipirkimo laikas: 19 000 € / 8 354 €/mėn. ≈ 2,27 mėnesio (apytiksliai 68 kalendorinės dienos).

Po truputį daugiau nei dviejų mėnesių sistema pradeda generuoti grynąjį pelną, o įmonės gebėjimas aptarnauti daugiau užsakymų su ta pačia komanda padidėja bent 30%.

7. Techniniai spąstai ir Edge Cases: kodėl logistikos IT projektai stringa

Mūsų praktikoje matėme ne vieną nesėkmingą TMS projektą, kuomet įmonė įsigijo brangią licenciją, tačiau po pusmečio grįžo prie Excel. Pagrindinės priežastys dažniausiai slypi ne vartotojo sąsajoje, o techninių „kraštutinių atvejų“ (Edge Cases) neįvertinime:

Ryšio praradimas ir Offline režimas

Vilkikai nuolat kerta zonas, kuriose mobilusis ryšys yra silpnas arba jo visai nėra (pvz., pasienio punktai, pramoniniai angarai, Lenkijos miškai). Jeigu vairuotojo PWA programėlė reikalauja pastovaus interneto ryšio e-CMR pasirašymui, sistema sustoja. Architektūra privalo turėti Offline-First palaikymą su vietiniu „IndexedDB“ saugojimu ir automatine konfliktų sprendimo sinchronizacija (Conflict-free Replicated Data Types – CRDT), kai ryšys atsistato.

VMI i.VAZ API trikdžiai

Valstybinių institucijų serveriai periodiškai susiduria su perkrovomis arba techniniais profilaktikos darbais. Jei jūsų sistema siunčia užklausas sinchroniškai ir laukia atsakymo – dispečerio darbas užstringa. Teisingas inžinerinis sprendimas: asinchroninė pranešimų eilė (RabbitMQ arba Redis BullMQ) su pakartotinių bandymų logika (Exponential Backoff), garantuojanti, kad važtaraštis bus užregistruotas vos tik VMI tarnyba vėl pradės veikti, o vilkikas gali pajudėti su laikinuoju numeriu.

Tachografų DDD failų nuskaitymo nesuderinamumas

VDO, Stoneridge ir kitų gamintojų tachografai naudoja skirtingus duomenų perdavimo formatus. Nuskaitant vairuotojų kortelių duomenis nuotoliniu būdu, svarbu užtikrinti griežtą kriptografinį atitikimą, kad failai būtų validūs Lietuvos transporto saugos administracijos (LTSA) patikrų metu.

8. 4 savaičių įgyvendinimo planas nuo audito iki produkcijos

Mes netikime metus trunkančiais IT diegimo projektais, kurie pasensta dar nepasiekę starto linijos. Veikianti transporto valdymo sistema tms gali būti paleista per 4 savaites taikant iteracinį inžinerinį metodą:

1 Savaitė: Procesų ir telemetrijos auditas. Išanalizuojame jūsų transporto parko įrangą (turimi GPS sekikliai, tachografai). Aprašome esamus Rivilė, Directo ar kitos ERP duomenų modelius. Suformuojame tikslią VRP optimizavimo specifikaciją.
2 Savaitė: TMS branduolys ir i.VAZ integracija. Įdiegiame duomenų bazės struktūrą, paleidžiame automatinį važtaraščių siuntimą į VMI i.VAZ per REST/SOAP. Sukuriame dispečerio valdymo skydelio karkasą.
3 Savaitė: ERP sinchronizacija ir vairuotojų PWA portalas. Sujungiame TMS su jūsų apskaitos sistema (automatinis sąskaitų ir kuro aktų kūrimas). Įdiegiame mobilią aplikaciją vairuotojams krovinių statusams žymėti ir skaitmeniniam parašui gauti.
4 Savaitė: Testavimas lauko sąlygomis ir paleidimas (Go-Live). Atliekame sistemos bandymus su 2–3 bandomaisiais vilkikais. Ap训ome dispečerius, sukalibruojame geozonų radiusus ir pervedame visą parką į naująją sistemą.

9. Veikiantis prototipas per 48 valandas

Nustokite toleruoti maržos praradimus dėl tuščios ridos, pasiklydusių popierinių CMR ir chaotiško bendravimo susirašinėjimo programėlėse. Atsiųskite mums savo šiuo metu naudojamą maršrutų Excel lentelę arba trumpą proceso aprašymą.

Per 48 valandas mes nemokamai sukonfigūruosime veikiantį jūsų įmonės TMS prototipą su interaktyviu žemėlapiu, parodysime, kaip jūsų duomenys sinchronizuojasi su Rivilė/Directo, ir pateiksime tikslų jūsų parko kaštų sutaupymo auditą.

Turinio rodyklė