Wie ooit heeft meegewerkt aan een koppeling tussen twee overheidsregistraties, kent het moment waarop de eerste testbestanden worden uitgewisseld. De technische verbinding staat, de interfaces zijn gedocumenteerd, de acceptatiecriteria zijn vastgelegd in een document dat door te veel mensen is geparafeerd. En dan blijkt dat een substantieel deel van de uitgewisselde gegevens niet aansluit op wat de ontvangende partij verwacht: velden die leeg zijn terwijl ze verplicht zijn, datumnotaties die afwijken van de afgesproken standaard, of — het meest verraderlijke geval — waarden die technisch correct zijn maar semantisch iets anders betekenen dan de ontvangende partij veronderstelt. Dit is geen uitzondering. Dit is de regel. En wie dat niet van tevoren inkalculeert in zijn planning, zal halverwege het traject met een ongemakkelijke boodschap naar de stuurgroep moeten.
De definitie van gegevenskwaliteit is zelf al een probleem
In de literatuur rondom informatiemanagement worden doorgaans zes tot tien dimensies van gegevenskwaliteit onderscheiden: volledigheid, juistheid, tijdigheid, consistentie, uniciteit, geldigheid, en enkele varianten daarop afhankelijk van het raamwerk dat men hanteert. Het probleem is dat deze dimensies op zichzelf niet operationeel zijn zolang men ze niet heeft vertaald naar de specifieke context van een registratie. Wat volledigheid betekent voor een basisregistratie personen verschilt wezenlijk van wat het betekent voor een sectorale registratie in het sociaal domein. In het eerste geval is er een wettelijke grondslag die bepaalt welke attributen moeten worden bijgehouden; in het tweede geval is de scope vaak minder scherp omlijnd en afhankelijk van beleidsinterpretaties die in de loop der jaren zijn gewijzigd.
Dit gebrek aan operationele definitie heeft directe gevolgen voor ketenintegratie. Wanneer twee organisaties een gegevensuitwisseling afspreken, hanteren zij elk hun eigen impliciete kwaliteitsnormen. Die normen zijn zelden expliciet gedocumenteerd, en nog minder zelden gevalideerd aan de hand van de feitelijke gegevenshuishouding. Het gevolg is dat men pas bij de eerste daadwerkelijke uitwisseling ontdekt dat de normen niet overeenkomen. Tegen die tijd zijn de contracten getekend, de opleverdata gecommuniceerd aan de politiek verantwoordelijken, en is de ruimte voor technische correctie aanzienlijk beperkt.
Een bruikbare aanpak is het opstellen van een zogenaamd gegevenswoordenboek vóórdat de technische architectuur wordt vastgelegd. In zo’n woordenboek worden niet alleen de namen en typen van gegevenselementen vastgelegd, maar ook de bedrijfsregels die bepalen wanneer een waarde als geldig wordt beschouwd, de herkomst van het gegeven, de frequentie van bijwerking, en de verantwoordelijkheid voor kwaliteitsbewaking. Dit klinkt als een bureaucratische exercitie, maar wie dit overslaat, betaalt de prijs later in de keten — en die prijs is altijd hoger dan de investering in het woordenboek.
De spanning tussen bronregistratie en afnemer: wie is verantwoordelijk voor kwaliteit?
In het stelsel van basisregistraties is de verantwoordelijkheid voor gegevenskwaliteit in principe belegd bij de bronhouder. Dit is een heldere juridische constructie: de gemeente die een adreswijziging verwerkt, is verantwoordelijk voor de juistheid van dat gegeven in de basisregistratie. Afnemers van die registratie mogen — en in veel gevallen: moeten — de gegevens als authentiek beschouwen en zijn niet verplicht ze zelfstandig te verifiëren. Dit principe van authenticiteit is een van de pijlers van het stelsel en heeft als doel de administratieve lasten voor burgers en organisaties te verminderen.
In de praktijk werkt dit principe echter alleen goed als aan een aantal voorwaarden is voldaan. De bronhouder moet beschikken over adequate processen voor gegevensinwinning en -controle. De terugmeldingsfaciliteit — het mechanisme waarmee afnemers twijfels over de juistheid van gegevens kunnen signaleren aan de bronhouder — moet functioneel zijn en daadwerkelijk worden gebruikt. En de bronhouder moet de capaciteit en de bereidheid hebben om terugmeldingen tijdig te verwerken. Aan geen van deze voorwaarden is structureel en uniform voldaan in het Nederlandse stelsel, hetgeen niet als kritiek op individuele organisaties moet worden gelezen, maar als een constatering over de systemische uitdagingen van gedistribueerd gegevensbeheer op nationale schaal.
De spanning die hieruit voortvloeit, is bijzonder zichtbaar in ketens waarbij meerdere registraties worden gecombineerd. Stel dat een uitvoeringsorganisatie een beschikking moet afgeven op basis van gegevens uit drie verschillende basisregistraties. Als de gegevens in die registraties onderling inconsistent zijn — wat kan voorkomen als gevolg van verwerkingstijden, definitieverschillen of fouten in de bronregistratie — dan staat de uitvoeringsorganisatie voor een keuze: de beschikking uitstellen in afwachting van reconciliatie, of een beslissing nemen op basis van onzekere informatie. Beide opties hebben juridische en operationele consequenties. Dit is geen theoretisch scenario; het is een dagelijkse realiteit in het uitvoeringslandschap.
Een gedeeltelijke oplossing ligt in het ontwerpen van expliciete kwaliteitssluitingen in de keten: momenten waarop de kwaliteit van gegevens wordt getoetst voordat ze worden doorgegeven aan de volgende schakel. Dit vereist echter dat men vooraf overeenstemming bereikt over de kwaliteitscriteria — wat ons terugbrengt bij de noodzaak van het gegevenswoordenboek — én dat men bereid is de keten te vertragen wanneer gegevens de toets niet doorstaan. Die bereidheid is in de politieke praktijk moeilijk te realiseren, omdat vertraging zichtbaar is en gegevensrisico’s dat doorgaans niet zijn totdat ze zich manifesteren als een incident.
Gegevenskwaliteit in aanbestedingen: een ondergewaardeerd contractueel risico
Wanneer overheidsorganisaties IT-systemen aanbesteden die een rol spelen in gegevensverwerking, wordt gegevenskwaliteit zelden als zelfstandig criterium opgenomen in de aanbestedingsdocumenten. Men specificeert functionaliteit, beschikbaarheid, verwerkingscapaciteit en beveiligingsniveaus — terecht, want dit zijn essentiële eisen — maar de kwaliteit van de gegevens die het systeem verwerkt, beheert of produceert, wordt doorgaans niet geoperationaliseerd als contractuele verplichting. Dit is een lacune die pas zichtbaar wordt nadat het systeem in productie is.
De reden voor deze lacune is begrijpelijk: gegevenskwaliteit is moeilijk te specificeren zonder diepgaande kennis van de gegevenshuishouding van de aanbestedende organisatie, en die kennis is lang niet altijd aanwezig bij de opstellers van het aanbestedingsdocument. Bovendien is gegevenskwaliteit een gedeelde verantwoordelijkheid: een leverancier kan niet garanderen dat de gegevens die worden ingevoerd in zijn systeem kwalitatief hoogwaardig zijn als de invoerprocessen buiten zijn controle liggen. Dit maakt het opstellen van afdwingbare kwaliteitseisen juridisch complex.
Toch zijn er mogelijkheden om gegevenskwaliteit beter te borgen in aanbestedingen. Men kan eisen stellen aan de validatiemechanismen die het systeem biedt: welke bedrijfsregels worden afgedwongen bij invoer, hoe worden afwijkingen gesignaleerd, welke rapportagemogelijkheden zijn er over de kwaliteitstoestand van de gegevens? Men kan ook eisen dat de leverancier een gegevenskwaliteitsplan opstelt als onderdeel van de implementatie, inclusief een nulmeting en een beschrijving van de maatregelen die worden getroffen om de kwaliteit te verbeteren. Dit zijn eisen die technisch haalbaar zijn en die de aandacht voor gegevenskwaliteit institutionaliseren in het project.
Daarnaast verdient het aanbeveling om in de aanbestedingsfase een gegevensprofiel op te stellen van de te verwerken gegevens: een beschrijving van de omvang, de diversiteit, de historische kwaliteitsproblemen en de verwachte mutatiesnelheid. Dit profiel stelt potentiële leveranciers in staat om realistisch te offreren en voorkomt dat gegevenskwaliteitsproblemen worden ontdekt tijdens de implementatie, wanneer de contractuele verhoudingen al zijn vastgelegd.
Het bredere punt is dit: gegevenskwaliteit is geen technisch detail dat na de contractsluiting kan worden geregeld. Het is een architectureel vraagstuk dat bepalend is voor de werking van de keten als geheel. Organisaties die dit inzicht laat in het traject ontwikkelen — of pas nadat een incident heeft plaatsgevonden — betalen een prijs die zich niet alleen uitdrukt in herstelkosten, maar ook in verminderd vertrouwen van burgers in de betrouwbaarheid van overheidsgegevens. En dat vertrouwen, eenmaal beschadigd, laat zich niet herstellen met een patchrelease.
Wie verantwoordelijkheid draagt voor gegevensgedreven dienstverlening — of dat nu als opdrachtgever, architect of programmamanager is — doet er goed aan gegevenskwaliteit niet te behandelen als een afgeleide van technische implementatie, maar als een zelfstandig besturingsvraagstuk dat om expliciete keuzes vraagt, om duidelijke verantwoordelijkheden, en om de institutionele moed om een keten te vertragen wanneer de kwaliteit van de gegevens daartoe aanleiding geeft.
Leave a Reply