Hoe voorkom je maatwerk per afdeling bij toepassing van het Gemeentelijk Gegevensmodel?

Ed Kisman · 14 okt 2026

Maatwerk per afdeling binnen het Gemeentelijk Gegevensmodel voorkom je door een gemeentebreed gegevensbeleid vast te stellen dat afdelingen verplicht het GGM als vertrekpunt te gebruiken, met een centraal gegevensbeheerteam dat afwijkingen beoordeelt en goedkeurt. Dit vraagt zowel om technische afspraken over de databasearchitectuur als om bestuurlijk draagvlak. De vragen hieronder helpen je stap voor stap om grip te houden op gestandaardiseerd gegevensbeheer binnen je gemeente.

Waarom ontstaat er toch maatwerk per afdeling binnen het GGM?

Maatwerk per afdeling ontstaat binnen het Gemeentelijk Gegevensmodel omdat elke afdeling haar eigen applicaties, processen en prioriteiten heeft, en het GGM niet altijd kant-en-klaar aansluit op die specifieke behoeften. Afdelingen gaan dan zelf aanvullen of afwijken, zonder dit centraal af te stemmen.

Het GGM dekt een breed palet aan gemeentelijke domeinen: van het Sociaal Domein met Wmo, Jeugd, Inkomen en Schuldhulpverlening tot Openbare Ruimte, Bouwen en Wonen, en interne organisatieonderdelen zoals HR en Financiën. Juist die breedte maakt het model waardevol, maar ook complex. Afdelingen als Leerplicht of Erfgoed werken met domeinspecifieke applicaties die hun eigen gegevensstructuren meebrengen. Als er geen centraal aanspreekpunt is dat de vertaalslag maakt tussen het GGM en die applicaties, lossen medewerkers het pragmatisch op: ze bouwen hun eigen oplossing.

Een andere veelvoorkomende oorzaak is het ontbreken van bewustzijn over bestaande standaarden. Het GGM is gebaseerd op landelijke informatiestandaarden zoals RSGB, RGBZ, iWmo, iJw en het Suwi Gegevensregister. Als medewerkers niet weten dat deze standaarden al in het model zijn verwerkt, zien ze het GGM al snel als een abstracte verplichting in plaats van een praktische basis.

Wat zijn de gevolgen van gefragmenteerd gegevensbeheer voor een gemeente?

Gefragmenteerd gegevensbeheer leidt tot inconsistente gegevens, hogere beheerkosten en beperkte mogelijkheden voor gemeentebrede rapportage en beleidssturing. Wanneer elke afdeling haar eigen gegevensstructuur hanteert, wordt betrouwbare informatie-uitwisseling tussen domeinen structureel moeilijker.

Concreet betekent dit dat een burger in het ene systeem anders geregistreerd staat dan in het andere, wat fouten in dienstverlening veroorzaakt. Koppelingen tussen systemen worden maatwerk in plaats van standaard, wat de kosten van databasebeheer aanzienlijk verhoogt. Elke nieuwe applicatie vraagt dan om een op maat gemaakte interface in plaats van een herbruikbare aansluiting.

Daarnaast raken gegevensmigraties en upgrades ingewikkelder. Als een afdeling afwijkt van het GGM, moet bij elke systeemwissel opnieuw worden uitgezocht hoe de gegevens zich verhouden tot de gemeentebrede structuur. Dit vertraagt projecten en vergroot de kans op dataverlies of -corruptie tijdens migraties.

Hoe stel je een gemeentebreed gegevensbeleid in voor het GGM?

Een gemeentebreed gegevensbeleid voor het GGM stel je in door het model formeel vast te stellen als de gemeentelijke gegevensstandaard, een gegevensbeheerteam aan te wijzen en afwijkingsprocedures te definiëren. Zonder bestuurlijke verankering blijft het GGM een advies in plaats van een norm.

Praktisch gezien werk je toe naar de volgende bouwstenen:

Formeel besluit: Laat het college of de gemeentesecretaris het GGM vaststellen als verplicht vertrekpunt voor alle nieuwe gegevensvraagstukken.
Gegevenssteward per domein: Wijs per beleidsdomein een verantwoordelijke aan die de GGM-conformiteit bewaakt en als aanspreekpunt fungeert voor afdelingen.
Afwijkingsprocedure: Maak inzichtelijk wanneer en hoe een afdeling mag afwijken, zodat uitzonderingen gecontroleerd verlopen en gedocumenteerd worden.
Bewustwordingsprogramma: Zorg dat medewerkers begrijpen welke landelijke standaarden al in het GGM zijn verwerkt, zodat het model als hulpmiddel wordt gezien en niet als belemmering.

Een gegevensbeleid werkt alleen als het aansluit bij de bestaande werkwijze van afdelingen. Betrek domeinexperts vroeg in het proces, net zoals bij de totstandkoming van het GGM zelf is gedaan via interviews met vakinhoudelijke specialisten.

Welke rol speelt de databasearchitectuur bij het voorkomen van maatwerk?

De databasearchitectuur is de technische ruggengraat die bepaalt of het GGM in de praktijk houdbaar is. Een goed ontworpen architectuur maakt het eenvoudiger om het GGM te volgen dan om ervan af te wijken, waardoor afdelingsspecifiek maatwerk minder aantrekkelijk wordt.

Centraal staat de keuze voor een gedeeld dataplatform of een integratielaag die GGM-conforme gegevensuitwisseling faciliteert. Wanneer afdelingen hun gegevens ophalen uit en terugschrijven naar een centrale, gestandaardiseerde omgeving, verdwijnt de prikkel om lokale schaduwdatabases bij te houden. Gegevensgovernance en beveiliging zijn daarbij onlosmakelijk verbonden: een centrale architectuur maakt het ook makkelijker om toegangsrechten en audittrails op orde te houden.

Voor gemeenten die werken met meerdere databaseplatforms, zoals Oracle, Microsoft SQL Server of PostgreSQL, is het belangrijk dat de architectuurkeuzes per platform aansluiten op de GGM-structuur. Denk aan naamgevingsconventies voor tabellen en velden, het gebruik van gemeenschappelijke sleutels zoals het BSN of de BAG-adresidentificatie, en gestandaardiseerde koppelvlakken op basis van landelijke standaarden als GML en NEN3610 voor geo-informatie.

Een gedegen database-adviestraject helpt gemeenten om de architectuur zo in te richten dat het GGM niet als extra laag bovenop bestaande systemen wordt geplakt, maar als fundament waarop applicaties worden aangesloten.

Wanneer is afwijking van het GGM wél gerechtvaardigd?

Afwijking van het Gemeentelijk Gegevensmodel is gerechtvaardigd wanneer domeinspecifieke wet- of regelgeving, een landelijke standaard of een unieke gemeentelijke situatie niet adequaat binnen het bestaande model past. De sleutel is dat de afwijking bewust, gedocumenteerd en tijdelijk van aard is.

Het GGM is van origine ontwikkeld op basis van de Delftse situatie en is generiek genoeg voor hergebruik, maar niet elke gemeente is identiek. Legitieme redenen voor een afwijking zijn onder andere:

Nieuwe wetgeving zoals de Omgevingswet, waarbij standaarden als STOP/TPOD en CIMOW nog in ontwikkeling zijn en het GGM nog niet volledig is bijgewerkt.
Domeinspecifieke informatiemodellen die nog niet volledig in het GGM zijn opgenomen, zoals onderdelen van IMBOR voor beheer van de openbare ruimte.
Tijdelijke situaties tijdens migraties, waarbij een tussenoplossing nodig is om continuïteit te waarborgen.
Lokale beleidsspecifieke gegevens die nergens anders in de gemeentelijke informatiehuishouding thuishoren.

Afwijken mag, maar het moet altijd via de vastgestelde afwijkingsprocedure verlopen. Zo blijft het GGM als gemeentebreed referentiemodel intact en worden uitzonderingen beheersbaar gehouden.

Hoe bewaak je GGM-conformiteit op de lange termijn?

GGM-conformiteit op de lange termijn bewaak je door periodieke audits in te plannen, wijzigingen in het gegevensmodel te koppelen aan een formeel beheerproces en afwijkingen actief te monitoren. Zonder structurele bewaking sluipt maatwerk er geleidelijk in, ook bij gemeenten met goede intenties.

Concrete maatregelen die werken in de praktijk:

Periodieke gegevensaudits: Controleer minimaal jaarlijks of de feitelijke databasestructuren nog overeenkomen met het GGM, en documenteer afwijkingen.
Wijzigingsbeheer: Koppel elke aanpassing aan een applicatie of database aan een toets op GGM-conformiteit, vergelijkbaar met een architectuurreview.
Versiebeheer van het GGM: Houd bij welke versie van het GGM in gebruik is en zorg dat updates van het model gecontroleerd worden doorgevoerd in de gemeentelijke systemen.
Monitoring en alertering: Gebruik databasemonitoringtools om structurele afwijkingen vroegtijdig te signaleren, zodat je niet achteraf voor verrassingen komt te staan.

Langetermijnbewaking vraagt ook om een levend document: het GGM moet meegroeien met nieuwe wetgeving, nieuwe standaarden en veranderende gemeentelijke behoeften. Moderne dataplatforms voor de overheid kunnen daarbij helpen door gegevensstromen inzichtelijk te maken en afwijkingen automatisch te signaleren.

Hoe DBA helpt bij GGM-conform databasebeheer

Als gemeente wil je je richten op dienstverlening, niet op de technische complexiteit van je databaseomgeving. Wij ondersteunen gemeenten bij het inrichten, beheren en bewaken van GGM-conforme databaseomgevingen, zodat gestandaardiseerd gegevensbeheer geen papieren ambitie blijft maar dagelijkse werkelijkheid wordt.

Wat wij voor je kunnen betekenen:

Databasearchitectuuradvies: We helpen je een technische infrastructuur te ontwerpen die het GGM als fundament gebruikt, passend bij Oracle, SQL Server of PostgreSQL.
Proactief databasebeheer: Via dagelijkse monitoring, back-upcontroles en periodiek onderhoud zorgen we dat afwijkingen vroeg worden gesignaleerd.
Migratiebegeleiding: Bij overgangen naar nieuwe systemen bewaken we GGM-conformiteit gedurende het hele migratietraject.
Advies en consultancy: Onze senior database administrators kennen de gemeentelijke informatiehuishouding en denken mee over gegevensbeleid en afwijkingsprocedures.
24/7 ondersteuning: Op afstand of op locatie, zodat problemen worden opgelost voordat ze de dienstverlening raken.

Wil je weten hoe we jouw gemeente kunnen helpen om grip te houden op het Gemeentelijk Gegevensmodel? Neem contact met ons op voor een vrijblijvend gesprek.