Telematica en verhuursoftware: van machinedata naar operationele beslissingen

Een groter deel van het materieel dat vandaag door verhuurvloten circuleert, komt uit de fabriek met een vorm van verbonden sensor of GPS-eenheid dan tien jaar geleden. Generatoren, compressoren, graafmachines, hoogwerkers en steeds vaker ook kleiner elektrisch gereedschap komen van de fabrikant met een reeds geïnstalleerde telematicamodule die ergens data naartoe stuurt, als standaardfunctie en niet als optie. Die verschuiving is zo geleidelijk gegaan dat het makkelijk is om te onderschatten hoe ver ze al is doorgedrongen: een verhuurbedrijf dat nooit bewust op zoek is gegaan naar telematica, kan toch een vloot draaien waarvan een aanzienlijk deel al data verstuurt, of iemand op kantoor daar nu iets mee doet of niet.

Gegeven dat is de vraag die er echt toe doet niet meer zozeer "heeft mijn materieel telematica". Steeds vaker heeft een deel van uw vloot dat waarschijnlijk al, een beslissing van de fabrikant, niet van het verhuurbedrijf. De nuttigere vraag is waar die data eenmaal gegenereerd daadwerkelijk naartoe gaat, en of ze iemand bereikt die een beslissing neemt over dat specifieke asset. Locatie-, gebruiks- en storingsdata die blijven hangen in de eigen app van de fabrikant, af en toe bekeken door de ene persoon die de inlog nog kent, doen weinig voor een bedrijf dat leveringen plant, verhuurperiodes calculeert of beslist wanneer materieel onderhoud nodig heeft. Diezelfde data terechtkomend in het systeem waar beschikbaarheid, prijs en onderhoud daadwerkelijk beslist worden, is een wezenlijk andere zaak, ook al is de sensor zelf helemaal niet veranderd.

Over dat gat, meer dan over de hardwarevraag, gaat dit artikel: niet of telematica geïnstalleerd moet worden, want veel materieel heeft het al, maar wat er met die data gebeurt daarna, en wat er verandert wanneer ze ophoudt een geïsoleerde stroom te zijn die niemand bekijkt en in plaats daarvan naast alles komt te staan wat al bekend is over dat asset.

Telematica is geen eenduidig begrip; het is een brede categorie van verbonden sensoren en rapportage, en wat een bepaalde eenheid meldt hangt af van de fabrikant, het type materieel en hoe de module bij installatie is geconfigureerd. Toch komen bij het meeste voor verhuur relevante materieel steeds dezelfde soorten data terug, en het is zinvol om eerst duidelijk te maken wat dit in het algemeen inhoudt, voordat het gaat over waar die data moet belanden.

Locatie is het meest bekende: GPS-coördinaten die met tussenpozen, of bij beweging, worden doorgegeven, zodat iemand ongeveer kan zien waar een stuk materieel zich bevindt zonder het fysiek op te sporen. Gebruiks- of motoruren zijn net zo gangbaar en vaak operationeel nog nuttiger: hoelang heeft deze generator daadwerkelijk gedraaid sinds hij het depot verliet, in tegenstelling tot hoelang hij simpelweg verhuurd is geweest. Die twee cijfers zijn niet hetzelfde, en juist in dat verschil zit vaak de interessante informatie. Daarnaast melden veel eenheden ook basale storings- of diagnosecodes: een motorwaarschuwing, een lage brandstofstand, een fout die anders pas aan het licht zou komen als iemand toevallig langs de machine loopt, of een klant belt om te klagen dat ze het begeven heeft.

Niets hiervan is uitzonderlijk of specifiek voor één leverancier; het is in grote lijnen wat telematica al jaren rapporteert, met name bij bouw-, materieel- en generatorapparatuur. Wat in de praktijk enorm verschilt, is niet wat er gemeten wordt, maar wat er met die meting gebeurt zodra ze bestaat, en of ze ooit een scherm bereikt dat iemand bij het verhuurbedrijf daadwerkelijk bekijkt.

Het praktische probleem waar de meeste verhuurbedrijven tegenaan lopen, is geen tekort aan telematicadata. Het is dat die data op de verkeerde plek zit. Materieel dat door de fabrikant is uitgerust met een GPS-eenheid en gebruikssensor, meldt doorgaans terug naar het eigen portaal of de eigen app van die fabrikant, gebouwd voor precies dat ene machinemerk en met een aparte inlog los van al het andere waarmee het bedrijf dagelijks werkt. Dat systeem is nooit ontworpen om met verhuurbeheersoftware te communiceren, simpelweg omdat het niet is gebouwd door de leverancier van die verhuurbeheersoftware. Het is gebouwd door de materieelfabrikant, als functie van de machine, niet van de verhuuractiviteit eromheen.

Een illustratief voorbeeld

Stel u een middelgroot materieelverhuurbedrijf voor dat een generatorenvloot draait waarvan de meeste eenheden al met GPS-trackers vanuit de fabriek zijn geleverd — niet iets dat het verhuurbedrijf heeft aangevraagd of extra voor heeft betaald, gewoon een standaardfunctie op nieuwere modellen. De locatie- en draaiuurdata die die trackers opleveren, zouden in principe echt nuttig zijn: ze zouden laten zien of een generator die al drie weken op een bouwplaats staat voor een verhuur van twee weken, daadwerkelijk draait of al sinds de eerste week stilstaat. In de praktijk staat die data in de eigen app van de fabrikant, onder een inlog die iemand op de werkplaats achttien maanden geleden heeft aangemaakt en zelden meer opent, losgekoppeld van het boekingsdossier, het onderhoudsschema, of wat het kantoor ook maar raadpleegt bij de beslissing of die generator vrij is voor de volgende offerte. De telematicahardware doet gewoon zijn werk. De data bereikt alleen nooit de plek waar de verhuurbeslissing daadwerkelijk wordt genomen.

Dat gat verdient meer aandacht dan de sensor zelf. Een aparte app die niemand in de dagelijkse operatie bekijkt, verschilt vanuit het oogpunt van wie de volgende offerte opstelt of beslist of een asset voor onderhoud terug moet komen, niet wezenlijk van helemaal geen telematica hebben. De belofte van telematica, weten wat er daadwerkelijk gebeurt met een stuk materieel terwijl het verhuurd is, hangt volledig af van of die data ergens terechtkomt dat verbonden is met de beslissingen die ze zou moeten onderbouwen.

Het is de moeite waard om dit direct te zeggen in plaats van het vaag te laten: Renttix produceert, verkoopt of installeert geen telematicahardware. Het maakt geen GPS-trackers, sensoren of enig fysiek apparaat dat op materieel wordt gemonteerd. Wat Renttix wél doet, is telematicadata ontvangen en gebruiken van materieel dat al is aangesloten — de sensor en de connectiviteit zijn van de fabrikant, of van een gespecialiseerde telematicaleverancier, en de rol van Renttix begint zodra die data al bestaat en ergens nuttigs terecht moet komen.

Dat onderscheid doet ertoe, en een verhuurbedrijf dat telematicasoftware voor verhuur overweegt, moet precies weten wat het beoordeelt: geen hardwareproduct dat op de vloot geïnstalleerd moet worden, maar een manier om telematicadata die het materieel al genereert onder te brengen in hetzelfde systeem als al het andere dat over dat asset bekend is, in plaats van het geïsoleerd te laten in het eigen portaal van een fabrikant.

Binnen Renttix maakt dit deel uit van asset intelligence: live telematica staat daar naast gezondheids- en kostenrapporten per asset, beheerste levenscyclusstatussen met blokkades en onderzoeken, barcode-voorraadtellingen en RFID, in plaats van te bestaan als apart module dat er alleen bij is geplakt voor materieel dat toevallig locatie rapporteert. Het gaat niet om een telematicafunctie om de functie zelf. Het gaat erom dat de live locatie- en gebruiksdata van een asset weer een stukje informatie is dat de moeite waard is om over dat specifieke asset te weten, naast wat het oplevert, wat het kost en in welke staat het verkeert, niet een apart onderwerp dat ergens anders wordt bijgehouden door iemand die moet onthouden in te loggen.

De waarde van het koppelen van telematicadata aan verhuurbeheersoftware, in plaats van ze in een losstaande fabrikantsapp te laten, zit niet echt in het feit dat die data nieuw zou zijn. De sensor produceerde ze toch al. De waarde zit in wat zichtbaar wordt zodra die meting naast al het andere komt te staan wat het bedrijf al weet over datzelfde asset.

Het duidelijkste voorbeeld is het verschil tussen geboekt en gebruikt. Een boekingsdossier zegt dat een asset tussen twee data verhuurd is; het zegt niet wat er in die tijd daadwerkelijk mee gebeurde. Gebruiksurendata die op hetzelfde assetdossier terechtkomt als de boeking, begint dat gat te dichten door te laten zien of een generator bij een verhuur van twee weken daadwerkelijk twee weken heeft gedraaid, of het grootste deel van de tijd stilstond na de eerste paar dagen. Dat is echt andere informatie dan simpelweg "is het geboekt", en het is meestal iets dat een verhuurbedrijf op geen andere manier te weten komt dan door de bouwplaats te bellen en het aan iemand daar te vragen.

Hetzelfde patroon geldt voor zichtbaarheid over meerdere depots: locatiedata uit telematica voedt hetzelfde live overzicht van waar assets zich daadwerkelijk bevinden over locaties en terreinen heen, in plaats van een aparte controle op de eigen kaart van een fabrikant te vereisen, en dat alleen voor de eenheden die toevallig GPS rapporteren. En het is even eerlijk om te benoemen waar dit nog niet reikt: gebruiksdata naast kosten- en opbrengstinformatie zou in principe ooit gebruiksgebaseerde factureringsbeslissingen kunnen informeren, iets waar sommige verhuurbedrijven al over nadenken. Maar dat is een algemene richting waarin de sector zich beweegt, geen specifieke Renttix-factureringsfunctie om vandaag te claimen. Wat nu wél echt is, is de zichtbaarheid zelf: een vollediger beeld van of een specifiek asset daadwerkelijk gebruikt wordt, beschikbaar op dezelfde plek als het gezondheids- en kostenrapport, in plaats van weggestopt in een aparte app waar niemand aan zou hebben gedacht voordat die beslissing genomen werd.

Als uw vloot al materieel bevat met door de fabrikant geïnstalleerde telematica, en steeds vaker is dat waarschijnlijk voor een deel het geval, dan is de praktische oefening niet om te beslissen of u telematica moet invoeren. Het is om uit te zoeken waar die data nu daadwerkelijk naartoe gaat, en of iemand die een beschikbaarheids-, prijs- of onderhoudsbeslissing neemt, er ook echt naar kijkt.

Een redelijk startpunt: maak een lijst van het materieel in uw vloot waarvan u weet dat het een vorm van verbonden tracking heeft, of het nu GPS, gebruiksuren of basale storingscodes betreft. Vraag voor elk stuk materieel wie die data bekijkt, hoe vaak, en of dat ook maar in de buurt komt van het systeem dat gebruikt wordt om verhuur te offreren, onderhoud te plannen of te controleren wat een bepaald asset daadwerkelijk kost om rijdend te houden. Als het eerlijke antwoord is "het staat in een app op de telefoon van één persoon" of "we loggen eigenlijk nooit in op dat portaal", dan is de hardware niet het probleem. Dan is het de kloof tussen waar de data leeft en waar de beslissingen worden genomen.

Verhuurtelematica die terechtkomt op dezelfde plek als het opbrengst-, kosten- en gezondheidsdossier van een asset, is wat de sensor van een fabrikant, tot dusver een functie die niemand controleerde, verandert in informatie die daadwerkelijk verandert wat het kantoor vervolgens doet. Als u wilt zien hoe dat eruitziet voor uw eigen vloot, inclusief materieel dat al vanaf de fabriek van telematica is voorzien, boek dan een demo en breng een echt voorbeeld mee.