In het atollenrijk Digitalië zijn alle eilanden door indrukwekkende hogesnelheidsinfrastructuur verbonden. Maar die is alleen toegankelijk voor een onbelemmerd op de automatische piloot rondflitsende happy flew¹.

Alle pogingen om ook de unhappy flaw² toe te laten liepen spaak: te moeilijk, te duur. Want deze gevallen zonder vaste bestemming negeerden zorgvuldig vastgestelde gewichts- en hoogtebeperkingen, bewogen zich tegen de rijrichting in en eisten afritten op onmogelijke plaatsen.

En daarom bevaart de unhappy flaw tot op heden de mistige zeeën van Digitalië in een haveloos roeibootje.

Werkende ketens voor iedereen​

De Nederlandse digitale overheid kan geen Digitalië zijn.

Ze moet werken voor de overweldigende meerderheid van de gevallen waarin alles gesmeerd verloopt. En óók voor de kleine minderheid van gevallen waarin iets misgaat.

Dat laatste is uitdagend, zo is de afgelopen jaren meermaals gebleken. Zeker als meerdere partijen samenwerken.

Dan ontstaat spraakverwarring. Wat glashelder is voor de één, kan voor een ander immers koeterwaals lijken.

Worden fouten uitvergroot. Want hoe repareer je een gebrek in andermans voorziening?

Blijken we onvolledig geïnformeerd. Omdat we gewijzigde gegevens zonder kennis van de aanleiding voor die verandering niet altijd goed begrijpen.

En ontstaat onzekerheid. Wie durft nog de consequenties van een handeling te garanderen als het einde van een keten van mogelijke gevolgen in nevelen is gehuld?

Tijdens de Dag van de toekomstige ketens willen we samen met jullie, aan de hand van casuïstiek en met speciale aandacht voor de rol van capabele registers, verkennen wat er nodig is voor digitale ketens die niet alleen de happy flew bedienen.

Binnenkort volgt meer informatie over aanmelding voor, en inhoud van deze dag.

De digitalisering van de overheid lijkt op het eerste gezicht een simpele moderniseringsslag: van papier naar pixels, van loketten naar websites. Maar onder deze ogenschijnlijk eenvoudige transitie gaat een fundamentele transformatie schuil die de manier waarop de overheid functioneert drastisch heeft veranderd. In deze blog verkennen we hoe de overstap van fysieke naar digitale processen niet alleen onze interactie met de overheid heeft veranderd, maar ook heeft geleid tot onvoorziene uitdagingen in de uitvoering van overheidstaken.

Van papier naar pixels​

De uitvoering van overheidstaken is diep geworteld in een papieren traditie. Dit is meer dan alleen een kwestie van documentatie - het heeft de hele architectuur van overheidsprocessen gevormd. Denk aan de fysieke dossiers in archiefkasten, formulieren die met de post werden verzonden, en handtekeningen die met pen op papier werden gezet. Deze papieren werkelijkheid creëerde natuurlijke grenzen: documenten konden maar op één plek tegelijk zijn, moesten fysiek worden overgedragen, en het aantal mensen dat tegelijk toegang had tot informatie was beperkt door praktische beperkingen.

Met de komst van digitale technologie is deze realiteit fundamenteel veranderd. Wat ooit bestond als stapels papier in archiefkasten, bestaat nu als datastromen in serverparken. Deze transformatie biedt ongekende mogelijkheden: documenten kunnen instant worden gedeeld, duizenden aanvragen kunnen parallel worden verwerkt, en informatie is overal en altijd toegankelijk. Maar deze digitalisering is vaak als een deken over bestaande processen heen gelegd, zonder de onderliggende werkwijze grondig te herzien.

De schaalvergroting die hieruit voortvloeit is monumentaal. Waar een ambtenaar vroeger tientallen dossiers per dag kon verwerken, handelen geautomatiseerde systemen nu duizenden gevallen per uur af. Deze exponentiële schaalvergroting heeft echter een keerzijde: als er fouten in het systeem zitten, vermenigvuldigen deze zich ook op dezelfde schaal. Een verkeerd geprogrammeerde regel kan in korte tijd duizenden burgers raken.

Deze digitale transformatie heeft ook het karakter van overheidsorganisaties fundamenteel veranderd. De imposante overheidsgebouwen die ooit symbool stonden voor bureaucratische macht en afstand, vervagen nu in een netwerk van servers en clouds. Paradoxaal genoeg wordt de overheid hierdoor tegelijkertijd ongrijpbaarder én toegankelijker. Via websites en apps staat ze 24/7 tot onze beschikking, maar de menselijke factor - die ambtenaar achter het loket die nog kon meedenken en maatwerk kon leveren - verdwijnt steeds meer naar de achtergrond.

Procesketens​

Deze fundamentele verschuiving van papier naar digitaal heeft misschien wel de grootste impact op ketens van processen binnen en tussen organisaties. In het papieren tijdperk was de fysieke route van een dossier glashelder: je kon letterlijk volgen hoe een map van bureau naar bureau ging, van afdeling naar afdeling, vaak vergezeld van een routeformulier met handtekeningen en datumstempels. Deze fysieke beperkingen zorgden voor een natuurlijk ritme en creëerden vanzelf momenten van controle en reflectie.

In de digitale wereld zijn deze ketens ogenschijnlijk efficiënter geworden. Een document kan instantaan worden gedeeld met alle betrokken partijen, wijzigingen worden realtime gesynchroniseerd, en processtromen kunnen parallel lopen in plaats van sequentieel. Maar deze ogenschijnlijke efficiëntie verhult fundamentele problemen. Waar eerder een fysieke map niet 'kwijt' kon raken - hij was altijd ergens - kunnen digitale dossiers verdwijnen in de krochten van verschillende systemen die niet met elkaar praten. De verantwoordelijkheid voor een proces vervaagt als tien afdelingen tegelijk toegang hebben tot dezelfde informatie.

Nog complexer wordt het wanneer verschillende organisaties in deze ketens moeten samenwerken. Waar vroeger een papieren dossier van de ene naar de andere organisatie ging, met duidelijke overdrachtsprotocollen, zien we nu een web van digitale verbindingen ontstaan. Gemeentes, uitvoeringsorganisaties, ministeries - allemaal hebben ze hun eigen systemen, die vaak met kunst- en vliegwerk aan elkaar geknoopt worden. Het resultaat is een digitale lappendeken waar informatie regelmatig tussen de naden door glipt.

De toekomst van deze procesketens roept fundamentele vragen op. Moeten we vasthouden aan de oude, lineaire procesmodellen die we hebben geërfd uit het papieren tijdperk? Of vraagt de digitale realiteit om een complete herziening van hoe we processen organiseren? Kunnen we bijvoorbeeld toe naar een model waarin processen meer organisch verlopen, gestuurd door de behoefte van het moment in plaats van vooraf vastgelegde routes?

En misschien wel de meest cruciale vraag: hoe waarborgen we in deze nieuwe realiteit belangrijke waarden als transparantie, controleerbaarheid en menselijk maatwerk? Want hoewel digitalisering enorme mogelijkheden biedt voor efficiëntie en toegankelijkheid, mogen we niet vergeten dat achter elk proces uiteindelijk mensen zitten - zowel als uitvoerder als als burger.

De uitdaging voor de komende jaren zal zijn om een nieuwe balans te vinden. Een balans tussen de mogelijkheden van digitale technologie en de menselijke maat. Tussen efficiëntie en zorgvuldigheid. Tussen gestandaardiseerde processen en ruimte voor maatwerk. Want uiteindelijk draait overheidshandelen niet om papier of pixels, maar om het effectief dienen van de samenleving.

Goed, dat gaan we niet in één dag oplossen. Maar laten we beginnen met het gesprek over onze procesketens, welke issues daarin nu prominent spelen en hoe we stappen kunnen maken in het oplossen daarin. Tijdens de Dag van de toekomstige ketens willen we samen met jullie, aan de hand van casuïstiek en met speciale aandacht voor de rol van capabele registers, verkennen wat er nodig is om stappen te kunnen maken. Binnenkort volgt er meer informatie over de inhoud van deze dag. Zet 'm vast in je agenda: 3 april 2025!

Als de digitale keten hapert: hoe ontwerpen we systemen die mensen écht helpen?​

Stel je voor: je doet aangifte van het overlijden van een familielid, maar wordt per ongeluk zelf als overleden geregistreerd. Je AOW stopt en je bankrekening wordt geblokkeerd. Of je auto wordt gestolen, maar niemand meldt het als die een dag later is teruggevonden. Het lijkt alsof jij die auto weer hebt. Dus je krijgt een oproep voor de APK, maar je hebt de auto niet. De boetes stapelen zich daarna snel op. Klinkt onwaarschijnlijk? Toch overkwam dit Fred en Saskia. Hun verhalen laten zien wat er misgaat als systemen zwaarder wegen dan de werkelijkheid. Hoe dat anders kan én moet, was het onderwerp van de Dag van de Toekomstige Ketens op donderdag 3 april in Utrecht, georganiseerd door DigiLab.

"Je zou denken: als je het uitlegt, is het snel opgelost. Maar zo werkt het systeem niet", legt inleider Arjan Widlak uit. Als directeur van de Stichting Kafkabrigade kent hij meer voorbeelden van situaties waarin burgers vastlopen en moeilijkheden ondervinden bij het corrigeren van fouten in ketens van informatiesystemen. "Het gaat om veel meer mensen dan je denkt, het zijn al snel honderdduizenden burgers. Zij moeten vaak van loket naar loket om fouten te herstellen. Dat legt een zware last bij deze mensen die juist hulp nodig hebben. Kortom: als er iets misgaat, is de schade groot en raakt het de burger diep."

Overzicht nodig

Het delen van informatie in ketens maakt de overheid efficiënter. Maar dat is niet zonder risico. Al in 2011 waarschuwde de Wetenschappelijke Raad voor het Regeringsbeleid (WRR) dat de informatiehuishouding binnen de overheid niet goed was ingericht op samenwerking tussen organisaties. Volgens de WRR kunnen fouten makkelijk ontstaan als niemand het overzicht of de verantwoordelijkheid heeft.

Steeds meer gegevens delen

Ook anno 2025 valt de uitwisseling van gegevens in ketens te verbeteren. "We zijn veel meer gegevens gaan uitwisselen", weet Arjan. "Maar er zijn nog steeds vragen over verantwoordelijkheden, het corrigeren van fouten en het overzicht. Wat kunnen we nu doen om het delen van gegevens in de ketens van morgen te verbeteren? Hoe voorkomen we dat een klein foutje in het systeem een heel leven ontwricht?"

Uit de zaal

De discussie met de zaal leverde herkenbare knelpunten op:

• Er is geen pauzeknop in het systeem – processen blijven doorgaan, ook als iets misgaat.
• Medewerkers volgen de procedures, maar hebben weinig ruimte om maatwerk te leveren.
• Burgers kunnen registraties niet makkelijk inzien en betwisten – het systeem heeft altijd gelijk.
• Het ontbreekt aan één duidelijk loket waar mensen terecht kunnen voor hulp, klachten of feedback op de keten.
• De bewijslast ligt bij de burger, terwijl het probleem vaak bij de overheid zit en data onzichtbaar zijn voor de burger.

Systemen zijn ontworpen voor alles wat goed gaat (happy flows). We zouden meer rekening moeten houden met uitzonderingen en foutsituaties (crappy flows): Crappy by Design.

Arjan Widlak sloot hoopvol af. "Ik zie de laatste jaren dat de overheid menselijker aan het worden is. Bijeenkomsten als deze helpen daarbij."

Van inzicht naar actie

Na de pauze gingen de deelnemers in twee werksessies aan de slag. Centraal stond de vraag wat we nú al kunnen doen om ketens foutbestendiger te maken. Dus: zonder (ingrijpende) aanpassingen in wet- en regelgeving en technologie die alleen nog op de tekentafel bestaat. Er waren twee invalshoeken.

1. Organisatorisch

De eerste groep richtte zich op veranderingen op organisatieniveau en besprak de mogelijkheden van een dienstverleningsafsprakenkader: een set afspraken om te voorkomen dat burgers vastlopen in regels of tussen verschillende instanties.

Zo'n kader moet duidelijke maatregelen bevatten die ketenpartners helpen het overzicht te houden. Ook moet het mogelijk zijn om twijfel te delen en fouten te herstellen.

Een van de suggesties was om een inlichtingenplicht in te voeren voor de overheid om burgers actief te informeren over zaken die hun leven kunnen beïnvloeden, zoals een wijziging in hun adresgegevens. Ook is betere samenwerking tussen organisaties nodig. Klantreizen en processen mogen niet stoppen bij de grenzen van een organisatie. En binnen een keten zou één partij verantwoordelijk moeten zijn voor:

• het bewaken van de juistheid van gegevens;
• het bewaken van de kwaliteit van dienstverlening;
• het zorgvuldig verwerken van signalen van burgers.

2. Technisch

In de tweede groep lag de nadruk op technische mogelijkheden die er vandaag de dag zijn om betere systemen te ontwerpen en te bouwen. De deelnemers aan deze sessie vergeleken samen met het projectteam 'Uit Betrouwbare Bron' verschillende patronen voor het vastleggen van historie. Ze onderzochten hoe administratieve handelingen, zoals de aangifte van een geboorte, leiden tot administratieve gevolgen: de toekenning van een BSN, vaststelling van de nationaliteit en inschrijving op een adres. Op basis van deze gevolgen is het mogelijk om de historie te reconstrueren. Tot slot lichtte het projectteam 'Uit Betrouwbare Bron' toe welke plannen er zijn om het ontwerpen en ontwikkelen van betrouwbare registers in de toekomst eenvoudiger te maken.

De vraagstukken liggen op tafel. Nu is het tijd om samen te bouwen aan oplossingen. De toekomst van gegevensuitwisseling begint met mensen die anders willen en durven denken. Sluit je aan bij de community van DigiLab en werk mee aan de ketens van morgen.

De handouts van de presentaties die op deze dag gegeven zijn zijn te vinden op:

• Dag van de toekomstige Ketens - introductie
• Casus auto gestolen
• Wat als ik vandaag een register moet bouwen

Op de dag van de toekomstige registraties is door Uit betrouwbare bron een presentatie verzorgd.

Op deze dag, georganiseerd door team Digilab, is verkend hoe we voor de toekomst registers kunnen bouwen die voldoen aan publieke waarden, die wendbaar zijn en een traceerbare vertaling van wet naar uitvoering borgen.

Sprekers op deze dag waren:

• Arjan Widlak, hij nam ons mee in de historie van de bureaucratie en waar het in de digitalisering soms misgaat. Hij illustreerde hoe burgers klem komen te zitten door gegevensdeling.
• Mariette Lokin, als pleitbezorger van een Weberiaanse bureaucratie in de goede zin des woords, gaf zij inzicht in de methode Wendbare Wetsanalyse en de voordelen van juridisch-technische samenwerking, geïnspireerd door DevOps: "LegOps".
• Wicher Minnaard deelde zijn ervaringen in Timor-Leste, waar hij met een klein team een nieuwe overheidsregistratie opzette. Hij benadrukte het belang van het kunnen terugkijken en rekenen in registraties.
• Jeanot Bijpost besprak hoe we de werkelijkheid in toekomstige registraties het beste kunnen benaderen, met aandacht voor het opdelen van claims en het meenemen van context bij registratiehandelingen.

De handouts van de bijdrage door Jeanot Bijpost zijn hier te bekijken

1. Ontwerpen en ontwikkelen. Het ontwerpen, toepassen en beproeven van kenmerken van een capabel register in het prototype.
2. Documenteren. Het zodanig beschrijven van concepten, capability's en functionaliteit dat die in (andere) applicaties kunnen worden toegepast. Deze beschrijvingen zouden na afloop van het project ook kunnen dienen als basis voor handreikingen of standaarden.
3. Toetsen en uitdragen. Het uitdragen van onze resultaten en het toetsen van bevindingen bij betrokkenen en belanghebbenden.

Deze activiteiten worden parallel aan elkaar uitgevoerd. Tegelijkertijd zorgen onderlinge afhankelijkheden ervoor dat we op verschillende momenten in verschillende mate aandacht aan bovengenoemde activiteiten zullen besteden.

Om te kunnen documenteren moeten we immers eerst begrijpen wat we van IT-systemen realistisch kunnen verwachten. Dat betekent dat we een eindje onderweg moeten zijn met ontwerpen en ontwikkelen. Toetsen en uitdragen is dan weer makkelijker als het materiaal wat onze bevindingen onderschrijft begrijpelijk en toegankelijk beschreven is. Wat betekent dat we een aardig deel van onze bevindingen hebben gedocumenteerd.

De verwachte aandachtsverdeling over de verschillende activiteiten voor de projectperiode is hieronder geïllustreerd.

Werkwijze​

De doelen van het project 'Uit betrouwbare bron' zijn ambitieus, terwijl motivatie, aanleiding en behoefte reden zijn om de blik ver vooruit te richten. Aan dit vernieuwende karakter kleven drie belangrijke risico's:

1. Wat we conceptueel willen, blijkt technisch niet haalbaar;
2. Wat we technisch kunnen, blijkt binnen een realistisch domein niet toepasbaar, en
3. Wat binnen een realistisch domein toepasbaar is, blijkt voor gebruikers niet werkbaar te zijn.

Fasering​

Optreden van deze risico's kunnen we alleen uitsluiten door helemaal niet te innoveren. Dat is wat ons betreft geen optie. We kiezen in plaats daarvan voor een 'fail as early as possible'-aanpak die de schade beperkt als één van deze risico's bewaarheid wordt. Bij deze werkwijze doorlopen we een vijftal fases (Figuur 1):

1. Vaststellen ontwerpfunctionaliteit. We bepalen op hoofdlijnen welke capability's en functionaliteit het register moet kunnen invullen.
2. Toets op technische haalbaarheid. De gewenste ontwerpfunctionaliteit wordt in een prototype gerealiseerd. Het ontwikkelproces helpt ons de concepten waarmee we werken beter te begrijpen. Deze fase eindigt wanneer duidelijk is of we de gewenste ontwerpfunctionaliteit daadwerkelijk kunnen implementeren. Zo nee, dan passen de we de ontwerpfunctionaliteit aan. Zo ja, dan gaan we door naar de volgende fase.
3. Toets op realistische toepasbaarheid. We toetsen aan de hand van modellen uit één of beide Proof of concept-domeinen (WOZ en Wegennetwerkregistratie) of het prototyperegister met concrete domeinhandelingen en -data overweg kan. Dit proces geeft ons inzicht in hoe het register zich gedraagt als daarin realistische datasets worden verwerkt. Deze fase eindigt wanneer duidelijk is dat het register realistische data volledig, betrouwbaar en performant kan verwerken. Lukt dit niet, dan passen de we ontwerpfunctionaliteit aan. Lukt dat wel, dan gaan we door naar de volgende fase.
4. Toets op praktische werkbaarheid. We toetsen met domeinprogrammeurs uit verschillende doelgroepen of het prototyperegister voor hen configureerbaar - dus in te richten voor gebruik in een specifiek domein – is. Dit vertelt ons of de functionaliteit van het register voldoende begrepen wordt om niet-ingewijden in staat te stellen daarmee praktisch aan de slag te gaan. Blijkt dit niet zo te zijn, dan passen we ontwerpfunctionaliteit aan. Blijkt dit wel zo te zijn, dan gaan we door naar de volgende fase.
5. Documenteren en uitdragen. Als de functionaliteit van het ontwikkelde register voldoet aan de eisen van technische haalbaarheid, realistische toepasbaarheid en praktische werkbaarheid, documenteren we de capability's, functionaliteit en API-specificaties gedetailleerd. Eveneens documenteren we tijdens het ontwikkelproces gestelde vragen, genomen besluiten en 'geleerde lessen'. Die kunnen immers waardevol zijn voor partijen die zelf een 'capabel' register willen (laten) ontwikkelen.