Er is zo veel data in transport dat het (bijna) vanzelfsprekend wordt

Vervoerders willen steeds meer informatie beschikbaar hebben. Data over de voertuigen, prestaties van chauffeurs, klantprestaties, planningsstatistieken, informatie over laad- en losadressen, financiële gegevens en ga zo maar door. In de eerste plaats natuurlijk voor de eigen bedrijfsvoering, maar klanten vragen ook steeds meer, verzenders en ontvangers willen meer informatie en bijvoorbeeld ook overheidsinstanties gaan meer data verlangen. Voor al deze partijen is de beschikbaarheid van deze data vanzelfsprekend, maar is dat voor de vervoerder ook wel zo?

Rendement met of door data?

De afgelopen maanden zijn we in samenwerking Powerblocks en TLN gestart met de uitrol van het ORM dashboard, een realtime monitor om het operationele rendement van vervoerders zichtbaar te maken. Een aardige uitdaging. Vanwege de verschillende systemen in de markt en wat geschaad vertrouwen bij sommige vervoerders door eerdere mislukkingen. En daar kwamen de twee belangrijke uitgangspunten ook nog eens bij: het moest laagdrempelig zijn en de vervoerder moet uiteindelijk ook zelfredzaam kunnen zijn. Het heeft ons niet tegengehouden om te starten met het ontsluiten van data uit TMS en de boordcomputer systemen naar een veilige, maar zeker ook toegankelijke database in de cloud. Ruim 20 bedrijven zijn inmiddels aangesloten en er wordt data ontvangen van 8 verschillende TMS-en en 6 boordcomputersystemen. Een bijzonder waardevolle operatie. Niet alleen om de ORM dashboards werkend te krijgen, maar zeker ook voor de inzichten en de mogelijkheden die hiermee zijn ontstaan.

Data van ieder TMS en boordcomputersysteem beschikbaar

In z’n algemeenheid wordt er makkelijk over gedacht. De vervoerder heeft genoeg data en als we op de systemen aldaar “inpluggen”, dan kunnen we er gelijk leuke dingen mee doen. In theorie klopt dat aardig, maar de praktijk is wat weerbarstiger. Allereerst hebben we met diverse systemen te maken. De diversiteit van TMS-en en boordcomputers is groot. Van oud naar nieuw met alle smaken van databases, platformen en ontwikkelomgevingen. Idealiter roepen we een API aan en vragen we de benodigde data op. In de meeste gevallen wordt deze service nog niet aangeboden voor de veelal on-premise (lokaal) draaiende systemen. Uiteraard hebben we daar een oplossing voor bedacht. Met een stukje integratiesoftware op de server wordt een databridge aangelegd. Via een beveiligde verbinding wordt de benodigde data overgehaald naar een afgeschermde cloudopslag; de ADF (Azure Data Factory). Met een afgesproken interval wordt een extractie van de benodigde data overgehaald. De ADF database is belangrijk. Hier wordt data vanuit het TMS en boordcomputers heen geleid en op een slimme manier samengevoegd. Het ORM dashboard is een van de mogelijkheden, maar de toegankelijke data biedt de vervoerder zo veel meer mogelijkheden. Is het dan werkelijk zo eenvoudig? Vaak wel, maar er zijn zeker ook een paar uitdagingen op het pad gekomen. Niet van deze tijd maar een enkele TMS-leverancier (hier niet met naam genoemd) verbiedt externe partijen toegang tot de database. De data van de vervoerder voor de duidelijkheid. Of een technische uitdaging (voor de techneuten: een 32-bits connectie in plaats van 64-bits). Hulde voor de technici, want vooralsnog is ieder TMS en boordcomputersysteem nog aangesloten en is de benodigde data met succes gevonden.

Aansluiten en dan wordt het leuk

Voordat er überhaupt een rapportage gemaakt wordt, werkt de vervoerder mee aan een quickscan. Uit de quickscan blijkt of de benodigde data aanwezig is in de systemen en de uitkomsten geven bovendien een aardig beeld van de wijze waarop de organisatie met data omgaat. In de basis hebben we niet eens heel veel informatie nodig om het operationele rendement in kaart te brengen. Aan de kostenkant zijn de kosten per uur en kilometer per voertuiggroep benodigd. Voor de chauffeurs is een bedrag per uur gewenst. Voor de omzet kijken we o.a. naar ritten, orders en opbrengsten, bij voorkeur per afdeling of plangroep. Uit de boordcomputer komen de kilometers en bij voorkeur de gecorrigeerde uren. Geen hele bijzondere dingen, maar toch… de aanwezigheid van deze data is lang niet altijd een vanzelfsprekendheid. Bij ieder bedrijf zijn aardige dingen aan het licht gekomen. Te veel om allemaal te benoemen, maar een aantal van de belangrijkste bevindingen:

  • Van sommige opdrachten of werkzaamheden zijn wel ritten in het TMS, maar geen orders met een opbrengst. Sommige systemen staan toe dat direct vanuit de rit gefactureerd wordt.
  • Niet alle orders, die in de planning staan, worden ook gefactureerd. Vervoerders zijn soms erg creatief in het bedenken van workarounds om aan de facturatiewensen van de opdrachtgever te voldoen.
  • Geen zuivere verdeling van omzet per plangroep, doordat ritten gepland worden in de ene groep en afgerekend worden in de andere groep.
  • Uren en kilometers zijn aanwezig, maar niet direct terug te leiden naar een ritnummer of een ingezette resource combinatie (voertuig/chauffeur).
  • De ruwe uren en kilometers zijn aanwezig in de rit, maar niet de gecorrigeerde uren.
  • Uren en kilometers zijn op papier aanwezig en handmatig ingevoerd (geen boordcomputer).
  • Uren en kilometers staan niet in het TMS of in een boordcomputersysteem, maar enkel in de applicatie van de digitale tachograaf.
  • Voertuigen en chauffeurs zijn wel ingevoerd, maar niet op een juiste en uniforme wijze naar type ingedeeld.
  • Extra kosten waaronder ferry- en tolkosten zijn niet altijd in de rit terug te vinden.

En dan hebben we het hierboven alleen nog maar over ontbrekende of verkeerd geregistreerde data. Wat te denken van de data-consistentie of betrouwbaarheid van gegevens? Afdelingen met een record omzet, voertuigen met een negatieve kilometerstand zijn echt geen uitzonderingen. Wie durft er nog te beweren dat goede systemen ook automatisch betrouwbare data uitspugen?

Zijn dit dan ook show-stoppers voor een goede rapportage? Nee! Het kan uiteraard altijd beter, maar in deze fase wordt het juist leuk. Er is creativiteit, kennis en ervaring binnen de transportsector benodigd om het proces van veranderen en verbeteren in gang te zetten.

Validatie van de data levert altijd op

Uit de ervaringen van de eerste aangesloten bedrijven kan zonder aarzelen de conclusie getrokken worden dat validatie van de data voordelen heeft opgeleverd. Dit komt vooral tot uitdrukking in het administratieve proces. Vervoerders worden gedwongen kritisch te kijken naar de wijze van ordervastlegging, manier van plannen, de gebruikte tarief- en kostenstructuren en facturatie. Ook hier zijn interessante zaken gesignaleerd, waaronder: orders ten onrechte niet gefactureerd, verkeerde tarieven berekend en gefactureerd, onjuiste opbrengst- en kosten verdelingen, toeslagen niet berekend, vertraagde afhandeling of facturatie. Het ORM dashboard zoomt weliswaar niet verder in dan op dagniveau, maar afwijkingen in de operatie, in het bijzonder gericht op omzet en bijbehorende kosten, worden direct zichtbaar. Voor een vervoerder werd bijvoorbeeld duidelijk dat de uitgevoerde ritten weliswaar een leuke marge opleverden, maar ook dat de meeste voertuigen simpelweg niet lang genoeg ingezet worden.

Slimme bedrijven pakken door

Voor het ene bedrijf is het valideren van de data al dan niet gecombineerd met het aanpassen van processen een flinke opgave. Het zijn de eerste stappen naar data volwassenheid. De ander is verder en snel overtuigd van de kracht van data en de geboden oplossingen, waardoor zij direct door kunnen pakken. De architectuur staat immers, de dataset kan eenvoudig worden uitgebreid en via de bibliotheek kan gebruik gemaakt worden van een uitgebreide verzameling aan rapportages. De zelfredzaamheid van organisaties is een van de belangrijkste uitgangspunten geweest in het partnership met TLN. Een paar ORM gebruikers van het eerste uur worden nu al geholpen met hun groeipad met als startpunt het op orde krijgen van operationele data, via uitgebreidere rapportages op rit- en klantniveau tot aan een SLA-portal, waarop klanten de gewenste performancerapportages kunnen inzien.

Het Open Trip Model als uniforme stekker

Zoals eerder al gemeld, biedt beschikbare en toegankelijke data tal van nieuwe mogelijkheden voor vervoerders. Deze blog begon met het feit dat steeds meer partijen data nodig hebben. Vervoerders missen vaak de kennis en tools om dit snel mogelijk te maken. Leveranciers van TMS en boordcomputersystemen zijn hierin vaak nog terughoudend. De ontwikkeling het Open Trip Model (OTM versie 5) als uniforme taal voor data-uitwisseling kan mogelijk voor een verschuiving zorgen. TLN ORM gebruikers kunnen in ieder geval gaan profiteren. Hun data is in de cloud beschikbaar en binnenkort ook met een OTM5 stekker te ontsluiten. Denk in mogelijke toepassingen als vrachtuitwisseling, plannen van capaciteit en aansluiting op BigMile (CO2 rapportage).

Geef een reactie

Vul je gegevens in of klik op een icoon om in te loggen.

WordPress.com logo

Je reageert onder je WordPress.com account. Log uit /  Bijwerken )

Google photo

Je reageert onder je Google account. Log uit /  Bijwerken )

Twitter-afbeelding

Je reageert onder je Twitter account. Log uit /  Bijwerken )

Facebook foto

Je reageert onder je Facebook account. Log uit /  Bijwerken )

Verbinden met %s

Deze site gebruikt Akismet om spam te bestrijden. Ontdek hoe de data van je reactie verwerkt wordt.