Zo’n centraal deurtje naar de marktpartijen maakt het eenvoudiger om andere partijen of toepassingen toe te voegen aan de keten, ook wel MaaS – Mobility As A Service – genoemd. Toch zijn er nog heel wat obstakels die nog moeten genomen worden om het protocol volwassen te noemen. Tomp werd wellicht net iets teveel door techneuten ontwikkeld. Belangrijke schakels om het ketenvervoer sluitend te maken missen en dat blijkt nu meer en meer nu iedereen Tomp wil omarmen om te implementeren. De TOMP-API (Transport Operator to Mobility Provider-Application Programming Interface) is een gestandaardiseerde en technische interface tussen MaaS-dienstverleners en vervoerders.
wat is een koppeling?
Vergelijk een koppeling in software tussen twee partijen maar met het gebruik van Google Translate. Je verstuurt het in de linkse zijde en het komt er in een andere taal uit aan de rechtse zijde. Maar zoals dat bij Google Translate ook vaak het geval is, wat er rechts uitkomt kan je beter niet helemaal voor waarheid aannemen en onaangepast gebruiken of publiceren. En dat is nu precies waar het aan schort bij veel koppelingen. Een standaard, zeg maar een correcte vertaalslag, is er niet en de uitkomst na elke vertaling is vatbaar voor interpretatie van de gebruiker. Hoog tijd voor afspraken en een standaard. De laatste tijd zien we het woordenboek voor doelgroepenvervoer van het kennisplatform CROW opduiken wat de kenmerken van de reiziger moet beschrijven. Een goed begin, maar we zijn er nog lang niet.
een stukje historie
Kritisch of niet, er moet geschreven worden dat de Tomp API meer voor elkaar kreeg in de taxisector dan alles wat er ooit aan vooraf ging. Wat ging er dan fout in het verleden? Leveranciers van softwaresystemen bedachten keer op keer eigen koppelingen om een opdrachtgever gelukkig te maken. Iedereen had een eigen visie en wilde vooral niet doorbouwen op datgene wat er al was. Strak plan om de markt naar je toe te trekken was het idee. Van een open standaard geregisseerd door de sector zelf is nog steeds geen sprake. Uit elke aanbesteding komt een nieuwe koppeling voort met als gevolg dat we nu beschikken over een pallet van te onderhouden software. Maar wat erger is, innovatie wordt tegengehouden door alle beperkingen van het bestaande ‘oude’ communicatiemodel tussen partijen.
Ook de branchevereniging KNV die, als innovatief omslagpunt in haar beleid, koploper wil zijn in alles wat MaaS gebruikt als verbindende factor, heeft zich de laatste jaren mede schuldig gemaakt aan de spaghetti van koppelingen. Ondanks het bezit van haar eigen innovatie commissie, waar met regelmaat de laatste 10 jaar voorstellen werden ingediend om dit probleem aan te pakken, kwam men niet verder dan dat wat elke ‘praatgroep’ de afgelopen jaren heeft gedaan. Gemiste kans, een standaard of protocol kwam er niet uit. Alle reden dus om door te pakken en TOMP geschikt te maken voor de sector.
reizigerskenmerken
Toch is de Tomp API vandaag helaas nog niet geschikt om alle facetten van het taxivervoer te bedienen. Het mist nog steeds een afsprakenstelsel. Niet op technisch vlak, integendeel, petje af. Maar op het vlak van reizigerskenmerken, budgetafspraken en ketelreizen waar een taxi in betrokken is, moet er nog veel gebeuren. Dat wil niet zeggen dat het een gemiste kans is want de Tomp werkgroep doet er alles aan om het tot een succes te maken en luistert vooral naar signalen van vervoerders en marktpartijen.
Er is lang gewacht met de komst van een universele koppeling in de taxisector. Al 20 jaar bestaat de noodzaak om centrales te koppelen maar ieder ICT bedrijf heeft z'n eigen wiel uitgevonden. De trein is nu op volle gang met allemaal verschillende wielen. De kosten voor onderhoud van al deze systemen rijzen de pan uit.
De Tomp werkgroep moet nu afwegen wat werkelijk technisch noodzakelijk is om een boeking te realiseren en wat onderlinge partijen zelf moeten regelen. Een budgetproduct door een budgetverstrekker toegekend aan een reiziger is hier een mooi voorbeeld van. Alle reizigerskenmerken die worden vastgelegd in het account van de reiziger zoals het soort budget product, machtigingsnummer, geldigheidsduur en een verwijzing naar voorwaarden en reiscondities zijn niet binnen de Tomp API terug te vinden, dit terwijl ze een essentieel onderdeel van de boeking uitmaken. Maar dan komen andere factoren weer om de hoek kijken zoals de privacywetgeving waar menig innovatie op stuk loopt de laatste jaren.
De Tomp werkgroep is een publiek-private samenwerking tussen MaaS providers, Transport Operators, andere mobiliteit gerelateerde organisaties en overheden. De werkgroep is ervan overtuigd dat de Dragonfly versie van de API nu voor langere tijd stabiel is. De gegevensuitwisseling via de Tomp omvat alle informatie met betrekking tot het plannen, reserveren, boeken, betalen en de reisondersteuning.
Lees ook: TOMP moet einde maken aan spaghetti van verbindingen
