Bij de overheid zien we het regelmatig gebeuren: een enthousiaste groep professionals bedenkt een innovatieve website of app voor een maatschappelijk probleem. Binnen korte tijd ligt er een werkend prototype op tafel. Het ziet er veelbelovend uit. De potentie is groot: iedereen zou dit kunnen gebruiken! Bestuurders zijn enthousiast: Kan dit niet volgende week al uitgerold worden? Iedereen zit hierop te wachten! Dit zou net zo standaard moeten worden als DigiD!
Maar dan gebeurt het. Een jaar later is de dienst nog steeds niet live. Twee jaar daarna ook niet. Wat ging er mis?
De oorzaak ligt zelden in de techniek. Technologie opent deuren en biedt nieuwe mogelijkheden om maatschappelijke vraagstukken aan te pakken. Maar de weg van een eerste prototype naar een robuuste en betrouwbare publieke dienst is lang, complex en wordt vaak zwaar onderschat. En hoewel de knelpunten zelden technisch van aard zijn, wordt het probleem toch vaak technisch benaderd: doorlopend sleutelen aan het ontwerp, terwijl de echte opgaven elders liggen. Op basis van ervaringen in verschillende overheidsprojecten, zie ik steeds dezelfde vijf blinde vlekken terugkeren die het succes van een veelbelovend initiatief in de weg staan.
1. Ondersteuning: wie neemt de telefoon op?
De eerste vraag die ik tegenwoordig stel bij de start van een nieuw project is: Wie neemt de telefoon op als een burger hier niet uitkomt?
Te vaak blijft het antwoord daarop vaag of ontbreekt het volledig. En dat is zorgwekkend. Want wanneer een product eenmaal breder wordt uitgerold dan de eerste groep ‘friends & family’-testers, zal er onvermijdelijk een stroom vragen en problemen ontstaan. De overheid is groot, met talloze loketten. Welke daarvan worden gebeld? En wat gaan die zeggen? Er is echt een groot verschil tussen 200 gebruikers en 18 miljoen, sommigen van wie er ook niet voor hebben gekozen om dit te gaan gebruiken.
Ondersteuning moet structureel worden geregeld: heldere FAQ’s, duidelijke contactpunten, en ondersteuning via bibliotheken of wijkteams. Daarbij moeten we beseffen: burgers hebben geen keuze. De overheid is een monopolist op haar eigen diensten. Uitsluiten is geen optie. Dat betekent ook dat digitale inclusie geen nice-to-have is, maar een kernverantwoordelijkheid. Een overheidsdienst moet zo zijn ingericht dat zoveel mogelijk mensen ermee uit de voeten kunnen – ongeacht hun digitale vaardigheden, taalniveau of beperking. En waar dat niet lukt, moeten er volwaardige alternatieven zijn. Veel prototypes ondersteunen alleen de ‘happy flow’: de gebruiker logt in, krijgt de juiste informatie en alles werkt. Maar wat als er iets misgaat? Wat als gegevens ontbreken, of iemand onterecht geen toegang heeft? Is er wel nagedacht over al deze “unhappy flows” of “sad flows”? Zijn er duidelijke foutmeldingen waardoor de gebruiker weet wat hij moet doen? Bestaat er een procedure om fouten te melden en te corrigeren? Wordt duidelijk gemaakt bij wie een burger terecht kan met klachten of een hulpvraag?
2. Wetgeving: mag dit eigenlijk wel?
De tweede vraag die ik stel is: Wie is verantwoordelijk voor de gegevensverwerking in dit systeem? Sommige projecten combineren op één plek gegevens uit meerdere ketens. Technisch gezien kan dat vaak prima – maar juridisch? Is de verantwoordelijke organisatie bevoegd om als ‘verwerker’ of ‘verwerkingsverantwoordelijke’ op te treden voor al die gegevens? En wat zijn de rechten van de burger ten aanzien van die informatie? Is het slechts een weergave ter informatie, of kan de burger er formele aanspraken aan ontlenen? In sommige gevallen is het zelfs nodig om bij te houden wat exact getoond is aan een burger, om bijvoorbeeld aan te kunnen tonen dat iemand geïnformeerd is geweest. En als gegevens niet kloppen, geldt dan het ‘no wrong door’-principe? Met andere woorden: draagt het systeem zorg voor de correctie, ook als de fout bij een andere partij ligt?
3. Leveranciers: wie gaat het technisch beheer doen?
De derde vraag is: waar komt de ontwikkelcapaciteit vandaan? De overheid heeft niet grote hoeveelheden ontwikkelaars die zitten te duimendraaien totdat er een leuke nieuwe ontwikkeling is waar ze mee aan de slag kunnen. In de geest van de Wet Markt & Overheid moet de overheid zich aan bepaalde gedragsregels moet houden wanneer zij economische activiteiten verricht die ook door private partijen kunnen worden uitgevoerd. Ontwikkelaars die aan overheids-ICT werken, zijn vaak in dienst van bedrijven die worden ingehuurd door de overheid of worden als ZZP’er ingehuurd. Daarom moet als we een prototype willen toevoegen aan de overheidsdienstverlening ook nagedacht moeten worden over hoe we dat gaan beheren, welke marktpartijen daarbij nodig zijn en hoe we die – vaak met een aanbesteding – gaan inhuren. Want burgers moeten kunnen blijven vertrouwen op een voorziening, ook als de oorspronkelijke ontwikkelaar weer in een nieuw spannend project is gedoken.
Het is cruciaal om bij de start al na te denken over wie het beheer en de doorontwikkeling gaan doen. Is dat de huidige leverancier? Wordt er aanbesteed? Wat betekent dat voor kennisborging, overdracht en continuïteit?
4. Beheer: wie gaat dit product of deze dienst doorontwikkelen?
De vierde vraag is: welke overheidsorganisatie gaat dit beheren? Goede ideeën ontstaan vaak vanuit de uitvoering en blijken dan patronen te bevatten die breder bruikbaar zijn. Er ontstaat dan vaak een idee voor een generiek systeem dat dan bij voorkeur door een andere organisatie wordt onderhouden. Er is vaak nog een lange weg tussen een werkend prototype en een productiewaardig product met een complete beheerorganisatie. Een beheerorganisatie is meer dan een beheerder die kijkt of de server nog aanstaat en af en toe een beveilingspatch doorvoert. Naast technisch beheer zal ook functioneel beheer gevoerd moeten worden: issues management en oplossen, gebruikersvragen beantwoorden, de doorontwikkeling van het product vormgeven, etc. Maar het is veel maar dan dat: er kunnen Kamervragen over komen, er kan de vraag komen om nieuwe organisaties aan te sluiten, er kan Europese wetgeving komen. De communicatie over het product zal moeten worden ingericht en iemand zal moeten waken over de koers en doorontwikkeling van het product. Kortom: denk niet alleen na over technisch beheer, maar over het beheer en doorontwikkeling van de complete product en dienstverlening.
5. Financiering: MVP ≠ klaar
Een werkend prototype is geen eindpunt – het is pas het begin. De klassieke Pareto-regel geldt ook hier: op het moment dat het MVP er is, heb je vaak nog maar 20% van het werk verricht dat nodig is om tot een stabiele live-dienst te komen. De kosten voor beheer, ondersteuning, doorontwikkeling en communicatie zijn substantieel en worden vaak onderschat. In veel gevallen lopen de beheerkosten in de eerste vier jaar op tot hetzelfde niveau als de oorspronkelijke ontwikkelkosten. Zonder structurele financiering is succes onmogelijk. Maar wie gaat het betalen?
Conclusie: een werkend product is het begin, niet het eindpunt
Natuurlijk zijn er ook technische uitdagingen bij de stap van prototype naar productie. Maar die zijn zelden het struikelblok. De werkelijke opgaven liggen in juridische, organisatorische, communicatieve en financiële hoek. En die vereisen een integrale aanpak, vanaf het allereerste begin. Wil je als overheid of publieke organisatie écht impact maken met digitale dienstverlening? Dan moet je al bij de eerste brainstorm nadenken over de ondersteuning, de juridische kaders, beheer en financiering. Alleen dan wordt een briljant idee ook écht een duurzame publieke dienst.
Meer weten over hoe je digitale dienstverlening wél succesvol van prototype naar productie brengt? Ik help graag!
