Is Common Ground een (zoveelste) ICT-hoofdpijndossier of is het écht een wendbaar vernieuwingstraject?
In de iBestuur nieuwsbrief van 7 mei was een artikel? gewijd aan Common Ground, aangeduid als “het meest intensieve digitale initiatief ooit binnen de gemeentelijke overheid. Voor de overgang van een gesloten landschap met silo-gebaseerde automatisering naar een open structuur waarin data gescheiden zijn van processen, is ongeveer tien jaar uitgetrokken.”
Het idee achter Common Ground klinkt als conceptueel oké: scheiden van know (inhoud) en flow (proces) is een beproefd concept in service georiënteerde architecturen (sprak de jurist ;-)). Een blik op de Pleio-site van Common Ground geeft echter de indruk dat het accent nogal ligt op het realiseren van apps of van diensten in een app: voor huwelijksaangifte, geboorteaangifte, doorgeven verhuizing, melden vakantieverhuur (in Amsterdam, status: on hold (!)) etc. Daarmee lijkt de aanpak meer gericht op de front end dan op het fundamenteel herinrichten van de gegevenshuishouding van gemeenten en van het ontwikkelen van generieke, regelgebaseerde services voor beslisondersteuning en dienstverlening.
Ook het onderdeel van de Pleio-site voor beleidsmakers en bestuurders oogt een beetje teleurstellend: wel een paar masterclasses over wat Common Ground is, maar geen werkmethoden of gereedschap voor het mee-ontwikkelen van wat nodig is om tot modulaire, wendbare toepassingen voor gemeentelijke dienstverlening te komen, gebaseerd op efficiënt en gelegitimeerd (her)gebruik van gegevens.
Wat in het stuk op iBestuur kritisch wordt bejegend, is de vrijblijvende aanpak van Common Ground. Iedere gemeente kan zelf bepalen of zij meedoet, aangesloten wordt op vervangingscycli voor oude systemen of op invoering van nieuwe wetgeving. De gemeentesecretaris van Zoetermeer ziet daarin een risico: “Er zijn te veel gemeentebestuurders en managers die zichzelf – en de door hen gekozen oplossing – zo uniek vinden dat ze wars zijn van elke vorm van inperking van lokale autonomie. Dat wordt dan belangrijker dan efficiency en informatiebeveiliging.”
Dat klinkt herkenbaar (ook bij de Rijksoverheid komt dit soort ‘uniciteitsdenken’ voor), maar misschien komt dat ook omdat Common Ground – alle pogingen om dat te voorkomen ten spijt – nogal een ICT-ding is. Het gaat uiteindelijk toch weer om het opruimen van complexiteit en achterstallig onderhoud in het systeemlandschap, om het wegwerken van legacy, of zoals het tegenwoordig ook wel heet: technische schuld.
Echte verandering en verbetering moet naar mijn idee beginnen met een andere vraag, op welke bestuurslaag dan ook. En die vraag is: “Wil je dat je transparant bent als bestuursorgaan en dat je je te allen tijde kunt verantwoorden over de manier waarop je wetgeving toepast op burgers en bedrijven? In termen van de brief, die minister Hoekstra op 11 januari van dit jaar aan de Tweede kamer stuurde over de Belastingdienst: wil je benaderbaar, behulpzaam en begrijpelijk zijn?
Zo ja, dan moet je je werkprocessen en systemen zo inrichten dat ze rechtmatig, uitlegbaar en wendbaar zijn. Dat is een kwestie van goed beheren van de kennis die nodig is om processen en systemen te laten draaien.
Die kennis begint bij analyse van wetgeving en uitvoeringsbeleid. Gelukkig hebben we in Nederland veel generieke wetgeving die dat mogelijk maakt. Zoals het artikel over Common Ground al zegt: vuil ophalen is hetzelfde in Tynaarlo als in Amsterdam, bijstand en een kapvergunning verlenen ook, net als belasting heffen en innen. De wetgever heeft wat dat betreft de voorwas voor de standaardisering die een servicegeoriënteerde architectuur ondersteunt, goed gedaan met bijvoorbeeld de Algemene wet bestuursrecht.
Die wettelijke regels kunnen worden vertaald in wetsgebaseerde (bedrijfs)regels en gegevensspecificaties, met behulp van een domain specific language (DSL). Zo’n DSL is niet iets technisch, het kan ‘gewone’ natuurlijke taal zijn die door alle betrokkenen bij het proces gelezen en begrepen kan worden. Dat maakt dat juristen, beleidsmakers en ICT-ontwikkelaars het met elkaar eens kunnen worden over de inhoud van de beslisregels, en vooral, de overeenstemming met de wetgeving waar die regels (daar focus ik nu even op) op gebaseerd zijn. Wel kent zo’n taal specifieke patronen en strikte afspraken over hoe zaken geforumuleerd worden, wat maakt dat die taal ook voor een machine te begrijpen is.
Bij het opstellen van de regels formuleren de betrokkenen direct ook samen testgevallen, fictieve maar reële situaties waarop de regels worden toegepast. Daarmee kunnen de regels al in een vroege fase getest worden, om te kijken of ze de verwachte uitkomsten geven. Zo dat niet het geval is, kan gemakkelijk teruggekeerd worden naar de gezamenlijke tekentafel om aanpassingen door te voeren.
De laatste stap is een geautomatiseerde vertaling naar softwarecode zodat de regels executeerbaar worden in een rule engine, in geval ze worden ingezet voor het geautomatiseerd nemen van besluiten. Maar het is ook mogelijk om de regels naar bijvoorbeeld HTML om te zetten, voor het inrichten van een webpagina met een reken- of regelhulp.
De kennisbasis die zo wordt gecreëerd voor digitale uitvoering is dus implementatieonafhankelijk: je kunt kiezen voor services die stukjes proces automatisch afhandelen en het resultaat doorgeven aan een (nog ‘oud’) systeem. Of die gegevens ophalen uit een bron. Of die een aanvraagmodule via een webportaal ondersteunen, of een app. Voor het implementeren van nieuwe wetgeving bouw je idealiter direct zo’n state of the art kennismodel, beheerbaar voor de toekomst. Zo kan een stapsgewijze en modulaire werkwijze worden gerealiseerd die grootse en meeslepende ICT-trajecten (ofwel potentiële hoofdpijndossiers) voorkomt. Maar mooier nog is dat je in het hele traject de link tussen de wettelijke regels en de uiteindelijke softwarecode vastlegt en bewaart. Dat maakt dat ook geautomatiseerde besluitvorming transparant en te verantwoorden wordt. En dat de impact van wetswijzigingen op de uitvoering eenvoudiger bepaald kan worden.
Er zijn wel een paar randvoorwaarden te vervullen, maar die kosten eigenlijk geen tijd en geld. In de eerste plaats moeten mensen echt multidisciplinair werken: jurist, beleidsmaker, uitvoerder en ICT-ontwikkelaars samen aan tafel, liefst vanaf het moment van beleidsontwikkeling tot aan oplevering van de service. In de tweede plaats is commitment van bestuurders van belang om die samenwerking ook echt te realiseren, want daarvoor moeten soms wat schotten tussen beleid, wetgeving en uitvoering worden geslecht.
Is dit toekomstmuziek? Nee hoor, verschillende grote uitvoerders bij de Rijksoverheid hebben deze noten al op hun zang; sommige zijn nog bij de ouverture, andere komen al in de richting van de grande finale. Misschien heb ik niet helemaal goed geluisterd en klinkt deze melodie ook onder Common Ground. Als dat zo is, dan zou dit best hoger van de toren geblazen mogen worden. Het is de basis voor de rechtmatige, uitlegbare en wendbare wetsuitvoering die de (digitale) overheid nodig heeft!
Mariette Lokin is juridisch adviseur bij het DG Belastingdienst
Goed artikel, Mariette. Raak.
Het enige is dat een informatielandschap aan de kant waar om informatie gevraagd wordt niet alleen begint bij Wet en Regelgeving. Er is veel meer dan alleen de keuzes die daarin ver werkt zijn.
Maar verder heb je gelijk. Ben benieuwd of je reacties krijgt.
Hm, ik ben een beetje in de war over dit artikel. Het begint met de suggestie dat bij de Common Ground teveel vanuit de front end wordt ontwikkeld. In het vervolg beschrijf je dat het ontwikkelen van de informatievoorziening moet starten bij de analyse van wetgeving, het uitvoeringsbeleid en het multidisciplinair herontwerpen van werkprocessen. Deze twee lijken mij helemaal niet strijdig met elkaar. Sterker nog: ze versterken elkaar.
Het is wat in veel Common Ground projecten plaatsvindt: Samen met klanten en gebruikers ontwikkelen van nuttige en werkende toepassingen die innovatie bij gemeenten stimuleren. De gegevenshuishouding en services die hierbij ontstaan zijn bouwstenen voor nieuwe ontwikkelingen.
Neem een aantal projecten als voorbeeld: De Adreswijziging (verhuizen), Huwelijksplanner en de Begrafenisplanner maken alle drie gebruik van dezelfde componenten voor dienstverlening en procesafhandeling. Denk hierbij aan PDC (product & dienstencatalogus), Verzoekencomponent, Agendacomponent, etc. Daarnaast worden ook de ZGW api’s toegepast. Deze componenten zijn allen onderdeel van de service laag en richten daarmee de gegevenslaag in vanuit het gebruik, die daarmee ook direct toepasbaar is.
Natuurlijk is het risico dat een al te pragmatische aanpak juist leidt tot een versnippering. Voor nu is het nodig om de trein in beweging te zetten; laten zien dat het werkt. Binnen Common Ground blijft het belangrijk dat we toewerken naar goed bruikbare standaarden waarmee alle gemeenten gaan werken. Wat dat betreft: wetgeving en beleid zijn ook overheidsstandaarden. Het is belangrijk om deze goed toepasbaar te maken. Open source gaat niet alleen over techniek; Open source kennis over de werking van de overheid is volgens mij minstens net zo belangrijk.
Om die reden vindt ik je uitleg hoe we wetgeving kunnen vertalen naar product-, indienings- en toekenningsvoorwaarden wel heel erg interessant. We hebben goede voorbeelden nodig. Ik ben wel geïnteresseerd om hier meer over te horen.
Beste Mariette,
Het idee om de beslisregels uit de software te halen is inspirerend. Inderdaad zijn veel processen te abstraheren in generieke stappen, die – zoals dat bij de Belastingdienst werd bedacht – gelden voor alle soorten toeslagen. De regels die je toegepast in de module voor een bepaalde processtap, kun je zien als de configuratie van die module voor een specifieke regeling. Hier is de configuratie voor de huurtoeslag en met deze regels configureren we dezelfde module voor de kinderopvangtoeslag. De beslisregels zien als een nieuw soort data, de geïnterpreteerde en geëxpliciteerde versie van de wetgeving, maakt een organisatie zonder meer wendbaarder. Bij wijzigingen in een regeling hoef je minder aan te passen en je kunt die aanpassingen doen op één punt. Helder.
Wat ik wat moeilijker te volgen vind is waarom dit het kernidee zou zijn, dat automatische netwerkbesluiten transparant maakt en rechtmatig. De veronderstelling is onder meer dat de indeling in processtappen (de flow, zoals je dat noemt) geen invloed heeft op de transparantie en rechtmatigheid. Eén van de opvallende dingen in de kinderopvangtoeslagaffaire vond ik dat er een processtap was, waarbij de toegang tot de aanvraag überhaupt werd gecheckt tegen een lijst met signalen. Ook waren er “events” (ic. een tijdsverloop) die een proces in gang konden zetten van automatische invordering, nadat die juist was stopgezet door menselijk ingrijpen. Of neem het parallelle proces überhaupt waarbij signalen werden verzameld op statistisch niveau – en waarbij het dus niet gaat om de toepassing van regels op individuele data – dat tot uitkomsten leidt die invloed hebben op de algemene processtappen interface en verrijking. Wat ik maar wil zeggen is: als we alleen kijken naar de flow van het specifieke proces en de regels die daarin worden toegepast, kijken we met oogkleppen.
En er ligt een andere veronderstelling aan ten grondslag. En dat is dat transparantie en rechtmatigheid alleen slaan op het algoritme, op de toepassing van de regels. Een fundamentele verandering die automatische netwerkbeslissingen veroorzaken in de informatie-architectuur van de overheid als geheel is nu juist dat een individuele organisatie niet meer de eigenaar is van zowel data als algoritme (van zowel de feiten als het besluit). Het algoritme, daarover heeft de Belastingdienst als individuele organisatie controle. Maar de data komt van andere organisaties. De feiten zijn daar in een andere juridische context omgezet in data. Die andere organisaties, de “eigenaar” van de data, kunnen niet inschatten hoe die data worden toegepast en wat de consequenties zijn. De eigenaar van het besluit, kan de feiten niet beoordelen waarop het besluit is gebaseerd. (ik heb er met anderen een nog niet gepubliceerd paper over geschreven als je wilt) Beiden worden zo blind voor elke vorm van context.
Dit alles natuurlijk nog los van het feit dat automatische netwerkbesluiten sowieso het deel van de wet- en regelgeving dat vraagt om oordeelsvorming niet kunnen toepassen. De belangenafweging – formeel onderdeel van het besluitvormingsproces – verplaatst zich naar de bezwaarfase, die daarmee een andere rol krijgt.
Nu wil ik niets afdoen aan het idee, dat is inspirerend. Zelfs wanneer overheidssoftware vrije of open source software zou zijn maakt het de regels die zijn toegepast wat breder toegankelijk. Het zou ook een vorm van (publiek) toezicht makkelijker maken. Ik weet dat het idee meer omvat dan in dit artikel staat, zoals ook directe verwijzingen naar zowel welke data is gebruikt als op welke wetgeving een beslisregel is gebaseerd. Dit idee maakt daarom een deel van de verantwoording makkelijker en efficiënter voor individuele organisaties. En dit idee helpt uitvoeringsorganisaties ontsnappen aan het gebrek aan wendbaarheid dat zij nu ondervinden. Dat is allemaal goed en relevant. Maar wat ik niet zie is waarom dit het kernidee zou zijn, dat automatische netwerkbesluiten transparant maakt en rechtmatig.
Zie eventueel ook het [position paper](http://www.kafkabrigade.nl/nieuws/tijdelijke-commissie-uitvoeringsorganisaties#idZwzWPcRpeandiY7_IX6CDg) dat Stichting Kafkabrigade schreef op verzoek van de parlementaire commissie uitvoering.
Hartelijke groet,
Arjan Widlak.
N.b. De mail-functie van deze website werkt niet (altijd), dus mail me even als je reageert.
Beste Mariette,
Je artikel gaat over een onderwerp dat mij al heel lang interesseert. Het werken met beslisregels of ook wel Rule Based Systems genoemd. In de 80-er jaren van de vorige eeuw was men daar al mee bezig en werden het 4GL-porgammertalen genoemd. Het gebruik ervan is echter altijd weer naar de achtergrond geschoven, vooral omdat bij veel uitzonderingen op de regels de systemen erg complex en dan vaak ook traag werden.
Momenteel kennen we No-code development, programmeertalen waarbij je niet hoeft te programmeren. Prima gereedschappen wanneer je niet te veel bijzondere dingen wilt en het niet te fancy hoeft te worden. Het is dus technisch gezien vrij lastig om dit zo goed uit te werken dat het overal past. Een one-size-fits-all stuk gereedschap.
Daarnaast is wetgeving vaak erg complex, vooral door alle uitzonderingen die er vaak (later) in aangebracht worden. Zie het toeslagenstelsel, in de hoofdprocessen niet heel lastig, maar door allerhande uitzonderingen om iedere bevolkingsgroep tegemoet te komen een ingewikkeld stelsel geworden.
Momenteel wordt het getracht bij de nieuwe Omgevingswet om daar met toepasbare regels te werken. Ook een mooi en transparant systeem, wat goed werkt bij dakkapellen, het kappen van bomen en het aanvragen van een uitrit. Wanneer het over echt ingewikkelde dingen als een chemische fabriek of een ziekenhuis gaat vermoed ik dat het dan, zeker de eerste 5 jaren, niet gaat werken. Misschien dat er de komende jaren nog progressie op dit terrein geboekt gaat worden en misschien moeten we dit soort complexe zaken dan maar niet in een systeem met deze regels willen stoppen.