Een gemeente zocht geen ritregistratiesysteem, maar een oplossing voor haar mobiliteitsvraagstuk
Soms komt een organisatie met een vraag waarvan je in eerste instantie denkt dat de oplossing redelijk eenvoudig is. Totdat je goed gaat luisteren.
Jaren geleden raakte ik betrokken bij een mobiliteitsvraagstuk van een gemeente in Nederland. De gemeente beschikte over een wagenpark met poolauto's die door verschillende medewerkers werden gebruikt.
Op papier was dat prima georganiseerd. In de praktijk ontstond echter een probleem. Medewerkers reserveerden een auto en kregen daarvoor een fysieke sleutel. Die sleutel bleef soms langer bij een medewerker dan noodzakelijk. Het gevolg was dat auto's niet beschikbaar leken, terwijl ze feitelijk gewoon stilstonden.
De eerste gedachte zou kunnen zijn: dan hebben we dus een beter reserveringssysteem nodig.
Maar als je verder vraagt, blijkt de werkelijke behoefte veel groter.
Niet meteen verkopen, maar eerst luisteren
Dat is iets wat ik in mijn jaren in sales en accountmanagement altijd belangrijk heb gevonden. Een klant die met een vraag komt, vraagt niet automatisch om het product dat jij toevallig verkoopt.
Eerst wil ik weten waarom die vraag wordt gesteld:
• Waar loopt de organisatie daadwerkelijk tegenaan?
• Hoe werken medewerkers nu?
• Waar gaat het mis?
• Welke informatie ontbreekt?
• Wat wil de organisatie uiteindelijk bereiken?
Bij deze gemeente ging het namelijk helemaal niet alleen om het reserveren van een auto. Men wilde af van de fysieke autosleutel. Medewerkers beschikten al over een persoonlijke bedrijfspas en de wens ontstond om diezelfde pas ook te gebruiken voor toegang tot een gereserveerd voertuig.
Daarmee veranderde het vraagstuk.
Van reserveren naar identificeren
Stel dat een medewerker een voertuig reserveert voor een bepaald tijdstip. Het systeem weet dan wie de reservering heeft gemaakt, welk voertuig is gereserveerd en wanneer dat voertuig gebruikt mag worden.
Als vervolgens de persoonlijke bedrijfspas wordt gebruikt om het voertuig te openen en beschikbaar te maken, ontstaat een koppeling tussen planning, medewerker en voertuig.
Maar dan komt automatisch de volgende vraag:
Wat gebeurt er met de ritregistratie?
Wanneer meerdere medewerkers dezelfde voertuigen gebruiken, moet namelijk niet alleen bekend zijn dát een voertuig heeft gereden. Ook de relatie tussen voertuig, bestuurder en rit moet goed worden georganiseerd.
Een eenvoudige vraag over poolauto's groeide daarmee uit tot een veel breder mobiliteitsvraagstuk.
De oplossing zat niet in één product
Er moest uiteindelijk worden gekeken naar verschillende onderdelen die met elkaar moesten samenwerken:
• planning;
• voertuigtoegang;
• bestuurdersidentificatie;
• ritregistratie;
• beheer;
• rapportage.
En precies daar zit voor mij een belangrijk verschil tussen verkopen en adviseren vanuit de praktijk.
Je kunt proberen een bestaand product bij een klant neer te zetten. Je kunt ook eerst analyseren wat een organisatie werkelijk nodig heeft en vervolgens kijken hoe techniek, processen en mensen bij elkaar kunnen worden gebracht.
Dat laatste vraagt soms ook dat een leverancier verder kijkt dan zijn bestaande oplossing.
Niet zeggen: "Dit is wat ons systeem kan."
Maar vragen: "Wat moet het voor de klant kunnen?"
Toen ontstond er nóg meer inzicht
Door de verschillende onderdelen met elkaar te verbinden, kreeg de gemeente uiteindelijk niet alleen grip op de beschikbaarheid van haar poolauto's. Er ontstond ook inzicht in het daadwerkelijke gebruik van het wagenpark.
Dat leverde ineens heel andere informatie op:
• Welke voertuigen worden veel gebruikt en welke nauwelijks?
• Hoeveel kilometers worden ermee gereden?
• Zijn alle voertuigen werkelijk noodzakelijk?
• Moet voor iedere korte zakelijke verplaatsing eigenlijk wel een auto worden ingezet?
Voor korte afstanden konden bijvoorbeeld ook andere vormen van vervoer worden aangeboden. De data uit het mobiliteitsproces werd daarmee bruikbaar voor veel meer dan alleen een fiscale rittenregistratie.
Het werd ook informatie waarmee de organisatie haar wagenpark en mobiliteitsbeleid kon beoordelen.
Privacy én fiscale betrouwbaarheid als uitgangspunt
Bij zo'n oplossing ontstaat een belangrijk vraagstuk. Wanneer een persoonlijke bedrijfspas, een reservering, een voertuig en ritgegevens met elkaar worden verbonden, ontstaat informatie over individuele medewerkers.
Voor deze gemeente waren daarom twee zaken belangrijk: zorgvuldig omgaan met persoonsgegevens én kunnen vertrouwen op een ritregistratie die geschikt was voor fiscale verantwoording.
Privacy moest vanaf het begin onderdeel zijn van de inrichting. Er werden duidelijke afspraken gemaakt over:
• welke gegevens werden vastgelegd;
• wie toegang had tot persoonsgebonden informatie;
• wie bepaalde rapportages mocht bekijken;
• hoe de gegevens binnen de organisatie werden gebruikt.
Tegelijkertijd stelde de gemeente eisen aan de betrouwbaarheid van de ritregistratie. Daarbij speelde het Normenkader RitRegistratieSystemen en het bijbehorende keurmerk een belangrijke rol.
Dat is een onderscheid dat ik belangrijk vind. Een systeem dat automatisch ritten registreert, is niet uitsluitend een technisch product. De organisatie moet ook nadenken over de betrouwbaarheid van de registratie, bestuurdersidentificatie, beheer, privacy en toegang tot de gegevens.
Omdat techniek iets kan registreren, betekent dat niet automatisch dat iedereen binnen een organisatie die informatie ook moet kunnen inzien. En omdat een systeem ritten registreert, betekent dat niet automatisch dat de registratie daarmee ook fiscaal voldoende is.
Juist die combinatie moet vooraf goed worden ingericht.
De techniek was niet het moeilijkste onderdeel
Als ik jaren later op deze case terugkijk, vind ik de gebruikte techniek eigenlijk niet eens het interessantste gedeelte. Het interessante zat in het proces dat eraan voorafging:
• luisteren;
• doorvragen;
• analyseren;
• begrijpen hoe de organisatie werkelijk werkte;
• verschillende disciplines bij elkaar brengen.
Dat is ook waarom ik vind dat goede sales binnen deze markt veel verder gaat dan het verkopen van een blackbox, abonnement of softwarepakket.
Een accountmanager zou niet alleen moeten weten wat zijn product kan. Hij moet vooral willen begrijpen wat zijn klant nodig heeft.
Soms blijkt dan dat de oplossing al beschikbaar is. Soms moeten bestaande onderdelen slimmer met elkaar worden verbonden. En soms ontdekt een leverancier dankzij de vraag van een klant dat zijn product verder ontwikkeld kan worden.
Wat deze gemeente mij vooral leerde
Een grote organisatie koopt uiteindelijk geen kastje. Ze probeert een probleem op te lossen.
Dat kan gaan over:
• fiscale controle;
• beschikbaarheid van voertuigen;
• privacy;
• kosten;
• duurzaamheid;
• planning;
• efficiënt wagenparkbeheer.
Vaak spelen meerdere onderwerpen tegelijkertijd.
Wie alleen vanuit het product redeneert, ziet slechts een deel van die vraag. Wie luistert, doorvraagt en analyseert, ziet het complete proces.
En juist daar ontstaat naar mijn mening de werkelijke toegevoegde waarde tussen klant en leverancier.
Ritmeester-tip
Begin niet bij het systeem. Begin bij de organisatie.
Breng eerst in kaart wat er in de dagelijkse praktijk gebeurt. Wie gebruikt welk voertuig? Hoe vindt reservering en identificatie plaats? Welke gegevens zijn nodig? Wie mag deze gegevens inzien? Welke fiscale eisen spelen een rol en welke eisen stelt de organisatie aan de betrouwbaarheid van de ritregistratie?
Kijk daarna pas naar de techniek die daarbij past.
Een goede mobiliteitsoplossing begint wat mij betreft namelijk niet met de vraag:
"Wat kunnen we verkopen?"
Maar met de vraag:
"Wat moeten we voor deze organisatie oplossen?"
Wie goed luistert, ontdekt vaak dat de werkelijke klantvraag veel groter is dan de oorspronkelijke vraag waarmee het gesprek begon.