Bij aanvang van de rit meldt de chauffeur zich aan. Gedurende het werk geeft de boordcomputer steeds aan wat de status is. Bij het rijden gebeurt dat automatisch, veel systemen ‘weten' dat boven de 30 kilometer per uur de auto vertrokken is. Anderzijds is na het afzetten van het contact of minimaal 2 minuten op dezelfde plaats meestal de status ‘rust'. Als dat anders is, dan moet de chauffeur dat zelf aangeven. Vaak zijn er 1-knops keuzes te maken met de meest voorkomende activiteiten. Naast rijden en rust zijn de meest voorkomende activiteiten ‘laden', ‘lossen', ‘omkoppelen', ‘tanken', ‘garage' en soms ‘standplaats' (op de thuisbasis voorbereidend of resterend administratief werk verrichten). Vanzelfsprekend zijn er meer opties, bijvoorbeeld ‘reinigen' bij tanktransport.

 

Bij boordcomputers die met een datacartridge werkten bestond de optie ‘tijd terug correctie'. Hierbij kon een chauffeur die bijvoorbeeld op ‘pauze' stond achteraf dit nog veranderen in bijvoorbeeld ‘laden'. Bij de nieuwere systemen worden alle statussen direct doorgestuurd naar de thuisbasis zodat de planner mee kan kijken wat de chauffeur op dat moment uitvoert. De ‘tijdterug' functie is dan ook langzamerhand aan het verdwijnen. In het belang van de planner en zijn eigen sluitende tijdregistratie moet hij eraan wennen gelijk de goede status in te geven.

 

Een grijs gebied is de situatie bij een langdurige laad- of losactie. Normaal neemt een chauffeur dan ook zijn pauze, zodat hij bijvoorbeeld bij anderhalf uur wachten tot de auto geladen of gelost is dit als drie kwartier pauze registreert en drie kwartier ‘lossen'. Lastiger wordt het als tussendoor de auto even verplaatst moet worden naar een ander dock. Voorheen was deze situatie alleen via de tacho-schijf te beoordelen. Deze situatie blijft echter lastig, zeker als er ook nog een digitale tachograaf aanwezig is. Het herpositioneren wordt niet door alle landen in Europa gelijk uitgelegd. Goede afspraken vooraf over hoe de uren geregistreerd moeten worden zijn dus van groot belang.

 

Uiteindelijk komen alle activiteiten op de thuisbasis in een database. De database heeft meerdere doeleinden:

• Het informeren van de planner: wat heeft iedere chauffeur gedaan en wat kan hij die dag of week nog doen.
   
• Het geven van een overzicht van de ongecorrigeerde uren voor de chauffeur (wettelijk verplicht)
   
• Input voor een CAO module waarin de ongecorrigeerde uren eventueel gecorrigeerd worden (bijvoorbeeld als de werkgever heeft afgesproken dat maximaal x minuten geladen, gelost of getankt wordt). De uitvoer hiervan is vaak de basis voor de loonstrook waarbij ook zaken als onkostenvergoedingen toegevoegd worden.

 

Het informeren van de planner heeft meerdere doelstellingen:

• De planner informeren als dat de chauffeur niet genoeg opschiet (al dan niet door eigen toedoen) zodat er actie ondernomen kan worden (zoals bijvoorbeeld tijdig een afleveradres bellen om te vragen wat de mogelijkheden zijn). Vaak zijn er instelbare popups of signaleringen in de software dat de planner aandacht moet besteden aan zo'n activiteit.
   
• De planner informeren dat een chauffeur te lang aan het laden of lossen is, zodat hij tijdig met de chauffeur of het adres kan bellen. Logischer is het trouwens de chauffeur te informeren bij vertragingen zelf contact op te nemen met de planner en hem ongevraagd een toelichting te geven zodat gepaste actie ondernomen kan worden.
   
• Informatie over gewerkte uren en het bereiken van het rijtijdenbesluit: hoe lang kan de chauffeur nog rijden zonder boetes en met de mogelijkheid een goede rustplaats te vinden? Of is het verstandiger een chauffeur met ‘meer uren' te laten omkoppelen? De planner moet niet overvallen worden maar anticiperen op dit soort knelpunten zonder dat het probleem zich opeens openbaart.

 

De twee overige rapportages zijn achteraf en niet tijd-kritisch. Het informeren van de planner is echter real-time. Een nieuwe optie die opkomt is het verwerken van file-informatie, zodat nog beter ingeschat kan worden wat de chauffeur kan bereiken. Door alleen de afwijkingen te tonen (management by exception) hoeft de planner zich alleen druk te maken over (opkomende) problemen, en kan hij ze zo mogelijk zelfs voorkomen. Op een goede manier gebruikt voorkomt dit heel veel problemen en kan het werk van de planning aanzienlijk verlicht worden.