AI rješenja za logistiku
Last-mile route optimization sa real-time saobraćajem i customer time-window-ima, plus predictive freight matching koji smanjuje empty miles - sve sa offline-capable driver app-om i EDI integracijom prema carrier-ima.
Operativni izazovi u industriji
- ● VRP-TW sa 80-150 stops po vozaču, pickup+delivery hybrid, službena vremena, pauze vozača (HOS regulacija)
- ● Real-time traffic re-routing bez gubljenja konzistentnosti customer ETA komunikacija
- ● Failed delivery prediction - prosječan customer no-show rate 6-9%, preusmjeravanje na susjedne stopove dinamički
- ● Backhaul matching za FTL/LTL hibrid sa dwell time predikcijom po terminal-u
- ● EDI 204/214/990 + REST/API mix prema carrier-ima različitih digital maturity-ja
Demo case studies
Last-mile route optimization sa real-time saobraćajem i constraint-aware re-planning-om
Regionalni 3PL operator sa fokusom na e-commerce last-mile (Adria regija), 340 vozila, 6 distribucijskih centara, dnevno oko 28.000 stopova. Klijenti uključuju nekoliko velikih e-commerce platformi i lokalne retailer-e sa kombinovanim B2C i B2B isporukama. Postojeći TMS (legacy SaaS) generisao je rute jednom ujutro pa nije reagovao na real-time događaje, što je rezultiralo on-time delivery rate-om od 81%.
Klasični VRP-TW solver-i ne nose se dobro sa instance-ovima 80-150 stops po vozaču - solution time eksplodira preko 10 minuta, što je neprihvatljivo za jutarnje planiranje 340 vozila. Pickup+delivery hybrid (return shipments + forward delivery iste rute) dodatno komplikuje constraint set. Real-time re-routing tokom dana zahtijeva inkrementalno rješenje koje ne lomi customer ETA komunikacije već poslane (kupac je dobio SMS sa prozorom 14:00-16:00, novi optimum bi bio 13:30 ali to ne smijemo unilateralno mijenjati). HOS (hours of service) regulacija nameće obavezne pauze koje moraju biti integrisane u solver, ne samo dodate post-hoc. Failed delivery rate od 7.4% značio je da se vozači vraćaju u depot sa neisporučenom robom, ili improviziraju re-attempt sa varijabilnim uspjehom.
Arhitektura ima tri sloja - planning, execution, learning. Planning sloj kombinuje OR-Tools routing solver sa custom Adaptive Large Neighborhood Search (ALNS) heuristikom. OR-Tools daje feasible početno rješenje u 30 sekundi, ALNS ga onda refine-uje 4-7 minuta sa destroy/repair operatorima specifičnim za pickup+delivery + time windows. HOS pauze modeliraju se kao soft constraints sa visokim penalty-jem unutar solver-a. Distance/time matrix kalkulira se kroz GraphHopper self-hosted instance preko OSM podataka sa custom traffic profilima per-region. Execution sloj prati izvršavanje preko driver mobilne aplikacije (Flutter) koja šalje GPS pozicije, status updates (arrived, delivered, failed_no_one_home) i scan-ove preko Kafka topic-a. Re-planning servis koristi inkrementalnu strategiju: za svaki disturbance (delay, failed delivery, traffic incident) generiše lokalni neighborhood (vozač + susjedni vozači u radijusu) i radi ALNS samo na tom subset-u sa constraint da već-komunicirani ETA-ovi ostaju validni. Failed delivery prediction model (gradient boosted classifier) skor stop-ove na osnovu (customer history, dan u sedmici, vrijeme dana, weather) i sortira ih da rizični stopovi budu rano u ruti, kad ima više opcija za re-attempt ili re-route. Driver app ima offline caching - rute, mape, customer kontakti se sync-uju jednom na početku smjene i app radi normalno bez konekcije, sa background sync kad signal dođe. Service time learning: per-customer i per-customer-tip prosječno vrijeme isporuke uči se iz historijskih scan-to-scan intervala, što značajno poboljšava ETA tačnost (od ±18 min prosječno na ±7 min).
Google OR-Tools, Python (custom ALNS implementacija), GraphHopper self-hosted, PostGIS, Apache Kafka, Redis Streams, Flutter (driver app, offline-capable), HERE Technologies live traffic API, Snowflake za historijske analize
Demo primjer baziran na stvarnoj inženjerskoj praksi. Identitet klijenta povjerljiv prema NDA.
Predictive freight matching za FTL/LTL kombinovanje sa multi-carrier auto-tendering-om
Freight forwarder koji opslužuje regionalne shipper-e (proizvodnja, distribucija, retail) sa miks-om FTL i LTL pošiljaka kroz CEE i Western Europe. Volumen oko 1.400 pošiljaka sedmično, mreža od 38 carrier-a (interni truck pool plus partneri). Glavni operativni gubitak bio je empty miles - prosječno 27% vozne kilometraže bilo je bez tereta, sa direktnim trošak gorivat i dispatcher vremena.
Backhaul matching radio se ručno od strane 5 dispatcher-a koji su gledali planirane FTL pošiljke u Excelu i pokušavali povezati povratne rute. Dispatcheri su radili sa nepotpunim informacijama - dwell time po terminal-u (vrijeme čekanja kod utovara/istovara) varirao je od 30 minuta do 8 sati i nije bio sistematski praćen, što je značilo da se često prihvatao backhaul koji se na papiru činio profitabilan ali je kasnio sa gubitkom drugog tereta. Multi-carrier rate sourcing radio se kroz email - dispatcher pošalje upit na 3-7 carrier-a, sačeka 1-3 sata, izabere najbolju ponudu. Spot vs. contract pricing odluke (kada koristiti dugoročni contract carrier vs. aktivni spot market) bile su intuitivne, sa varijabilnim ishodom. EDI integracija postojala je sa 4 najveća carrier-a (X12 204 tender, 214 status, 990 response), ostali su išli kroz portal/email.
Arhitektura ima tri komponente - matching engine, dwell predictor, tendering orchestrator. Matching engine je MILP problem (Pyomo + CBC solver) koji se rješava 4 puta dnevno na rolling horizonu od 5 dana. Decision varijable: (shipment, leg, carrier, vehicle_assignment), constraint set uključuje vehicle capacity, time windows, driver HOS, contract MOG (minimum obligation guarantee), i backhaul kompatibilnost (geografsku i vremensku). Objective minimizuje (total cost - carbon score weight) gdje cost uključuje empty miles penalty. Dwell time predictor je gradient boosted regressor (XGBoost) sa features (terminal_id, day_of_week, hour, shipment_type, carrier, recent_dwell_avg). Treniran na 14 mjeseci historijskih podataka iz EDI 214 status događaja (in-gate, loaded, out-gate timestamps). MAPE 14% na out-of-sample, što je dovoljno da matching engine pravi informisane odluke o realnoj profitability backhaul-a. Spot vs. contract decisioning koristi reinforcement learning policy (offline trained kroz historical replay) koji optimizuje long-term carrier relationship value vs. short-term cost. Tendering orchestrator automatizuje carrier outreach - generiše X12 204 tender messages prema EDI carrier-ima, REST API call-ove prema modernim carrier-ima sa API-jem, i fallback na strukturirane email templates za ostale (sa parsing-om response-a kroz LLM-assisted ekstraktor). Auto-acceptance logika: ako je rate u top 25% historijskih za tu lane i carrier ima EVS (Equipment Visibility Score) iznad 0.85, sistem automatski prihvati i pošalje confirmation. Dispatcher dashboard u React-u + Mapbox GL daje vidljivost real-time statusa svih aktivnih pošiljaka, exception alerts, i decision support pri ručnoj intervenciji.
Python (Pyomo + CBC, XGBoost), Apache Spark za batch optimization, Snowflake, Kafka Connect, custom EDI X12 parser (204/214/990), REST/API gateways prema carrier-ima, React + Mapbox GL dispatcher dashboard, PostgreSQL za operativnu bazu
Demo primjer baziran na stvarnoj inženjerskoj praksi. Identitet klijenta povjerljiv prema NDA.
Tehnologije koje koristimo
Kako radimo
Discovery
Audit TMS/WMS sistema, EDI carrier konekcija, vozilo i ruta historije, baseline KPI (on-time, empty miles, dispatcher load).
Pilot
Pilot na 1-2 distribucijska centra ili 50 ruta, paralelno sa postojećim TMS-om, A/B usporedba na ključnim KPI-jevima.
Implementacija
Roll-out kroz cijelu mrežu, EDI/API integracije sa carrier-ima, deploy driver mobilne aplikacije, training dispatcher-a i vozača.
Operacija
Mjesečni retraining service time i dwell modela, kvartalni review carrier scoring-a i tendering pravila.
Razgovarajmo o pilotu za vašu firmu
Discovery sesija je 60 minuta - razumijemo vaš problem i predlažemo konkretan pilot pristup.
Kontaktirajte nas