25-04-2018

Mens, durf gepland te falen: proef OV-chip mobiel was juist geslaagd

Joris Dirks

De proef is juist geslaagd: de conclusie is dat het systeem niet voldoet aan de criteria. En, hoera: de managers luisteren naar de conclusies.

Laten we even de casus met teleurstellende resultaten bekijken - en haar voorloper, dan leg ik daarna uit wat meer bestuurders moeten durven. Omdat zelfs architecten geen glazen bol hebben. Proef, Pilot, Proof of Concept; als je een test goed positioneert kan je met de uitkomst, onzekerheden oplossen in je IT-architectuur.

Translink is namens vervoerders de uitvoeringsorganisatie voor de gezamenlijke infrastructuur van de OV-chipkaart. Zoals alle ketenprojecten betaamt, is het een wirwar van organisaties, verantwoordelijkheden en gegevensstromen. De OV-chipkaart zelf werd eerst in Rotterdam uitgerold, 'als proef' - ik deed destijds een onderzoek naar de belangen van reizigersorganisaties. Tijdens de test in Rotterdam bleek dat veel van de beoogde voordelen van de OV-chipkaart niet werden waargemaakt, en dat er nog een flink aantal problemen waren. Maakte dat uit voor de landelijke uitrol, en afschaffing van die mooie strippenkaart? Daar heb ik niets van gezien, er zat (politieke) druk op.

In de proef waar het nu om gaat, lijken Translink en de vervoerders en KPN en Vodafone, uit te vinden hoe "OV-chip mobiel" geïmplementeerd kan worden, als verbetering op het huidige systeem. De use-case voor het gebruik van de smartphone i.p.v. chipkaart om mee in-en-uit te checken blijft impliciet. Ik gok dat het met gebruiksgemak te maken heeft: niet een apart pasje bij je hebben, niet hoeven opladen, direct op je scherm feedback? Translink geeft in haar communicatie eigenlijk drie redenen aan waarom het systeem niet werkte.

1. Het bleek complex om met negen partijen samen te werken.

2. Niet alle Androids zijn gelijk; het is lastig op de verschillende smaken smartphones, het volledige systeem werkend te krijgen. Apple Pay is weer zo verschillend dat het daar helemaal niet werkt.

3. Het instellen is zo lastig dat eindgebruikers het niet zonder hulp kunnen. En gebruiksvriendelijkheid zou nou juist een doel moeten zijn.

Alle drie vrij bekende redenen. Elke architect weet (hopelijk) dat systemen exponentieel moeilijker worden met de groei van het aantal betrokken partijen. Dat is overigens ook waarom vergelijking van onze OV-chipkaart met andere landen moeilijk te maken is. Niet alleen de OV-chip-techniek is lastig; mobiele betalingssystemen zoals Google Pay, zijn ook notoir ingewikkeld en divers. Interessant in dat kader is de presentatie van Simon Eumes over de verschillende technieken en processen voor contactloos betalen op het Chaos Communication Congress.

En dat de gebruikerservaring een cruciale factor is, mag bij iedereen doorgedrongen zijn. Zeker als je zo'n grote gebruikersgroep hebt. Zeker als jouw app en hun toestel niet compatible zijn, word jìj daar op aan gekeken.

Innovatieve techbedrijven kennen de beperking van de tekentafel en weten dat je niet alles kan voorspellen. Omdat het product vaak 'instant' bij de gebruiker komt, kunnen ze innoveren door direct te testen op een groep gebruikers. Slaat het aan? Dan rollen ze het uit naar meer gebruikersgroepen. De kritiek dat er 'maar' 8000 mensen meededen aan "ov-chip mobiel" lijkt me dan de slechtste kritiek - de uitrol is terecht gestopt toen de resultaten tegenvielen.

De 'eerst uitrollen, dan fixen' mentaliteit is overigens niet in alle producten even toepasbaar; Tesla krijgt begrijpelijke kritiek want een auto wil je vanaf de winkel veilig hebben en niet na de eerste gebruikerservaringen. Net zo zeer moeten publieke organisaties oppassen; je kan alleen testen als het mag falen en de deelnemers een alternatief hebben. Belangrijkst is dat je als bestuurder, het lef hebt om te gaan proberen en tegen je kiezers of aandeelhouders zegt dat je niet weet of het een succes wordt. De meeste "proeven" die ik in de publieke sector heb gezien, mogen niet falen. Soms is de uitkomst al vastgelegd in politiek: 'dit is de oplossing'. Of, in planning en budget: 'we gaan uit van volledige uitrol een maand na de pilot', 'we hebben geen alternatief bedacht'. Vaak is er al een vrij volledig product gemaakt en is de scope van de proef slechts: 'we kijken nu hòe de uitrol naar alle overheden plaats moet vinden'. Als je ruimte wil voor testen, test dan op tijd zodat je nog aanpassingen kan doen. Dàt is, in een notendop Agile architectuur.

Ja, er is een hoop geld geïnvesteerd in deze proef; 1.8 miljoen semi-publiek geld door Translink en vast een flink bedrag door KPN en Vodafone. Maar als realistische architect weet je dat heel lang overleggen en nadenken over de toekomst niet altijd genoeg is om onzekerheden weg te nemen, maar wel een flinke investering kan zijn. Om het klein en persoonlijk te maken: ik zet (architectuur-)wiki’s op voor klanten, waarbij we een kennismodel probéren vast te stellen waar de hele organisatie mee kan werken. Dan hak ik wel eens de knoop door: “met nog meer overleggen komen we niet veel verder, laten we gewoon beginnen met een eerste versie”. Welbewust zo flexibel mogelijk en we zien wel hoeveel er aangepast moet worden.

Dus, waar je ook in de organisatie zit: slim zijn is toegeven dat je geen glazen bol hebt, ook al lijkt IT zo maakbaar.

Interessant? Deel het!
Illustratie stel je vraag
Meer weten over deze blog?

Neem contact op met ons, we vertellen er graag meer over!

© ArchiXL  |  KvK 05084421