Het stelsel en zijn staart
Redactioneel
MIJNGIN
Ad van der Meer
Het stelsel van basisregistraties is een prachtig grand design.
Alles éénmalig en gestandaardiseerd opslaan, meervoudig
gebruik alom, verplichte terugmeldingen voor afwijkingen -
mooi, mooi, mooi. Effciencyvoordeel en winstpakkers vliegen
je om de oren, een overheid zonder basisregistraties lijkt haast
niet meer mogelijk. Laat ik vooropstellen dat ik een voorstander
ben van het stelsel zoals dat is bedacht. Dat de implementatie
geld kost, daar is iedereen zich wel van bewust. In de dagelijkse
uitvoeringspraktijk levert het stelsel echter niet alleen winst: daar
zitten nieuwe kosten. Een stelsel vereist nieuwe beheertaken en
brengt nieuwe beheerissues met zich mee, die boven het beheer
van de individuele registraties uitstijgen.
Een simpel voorbeeld om dit te illustreren. De gemeente Amster
dam kent twee woonplaatsen: Amsterdam en Amsterdam-
Zuidoost. De gemeentelijke politiek heeft in 2012 vastgesteld dat
dit er één moet worden. Het zou simpel moeten zijn: ergens een
woonplaatscode wijzigen en voila, het hele stelsel is aangeslo
ten. Maar helaas. Het model van de BAG zit zó in elkaar dat het
aanvankelijk leek dat we alle 40.000 verblijfsobjecten in Zuidoost
zouden moeten wijzigen. Voorts bleek dat het niet mogelijk is
om een woonplaats simpelweg toe te voegen aan een andere
woonplaats. In zo'n geval moeten beide woonplaatsen worden
opgeheven en één nieuwe worden gevormd. Het probleem
dijde dus uit naar 480.000 verblijfsobjecten in heel Amsterdam.
Door de koppeling BAG-GBA zou de GBA voor 800.000 inwoners
een gewijzigde adresaanduiding moeten toepassen. En de
koppeling naar de landelijke voorziening van de GBA zou op zijn
beurt weer tot miljoenen mutaties naar afnemers van die voor
ziening leiden.'Leve het stelsel! Maar dit resultaat was uiteraard
niet gewenst.'
Inmiddels hebben we een workaround gevonden, maar het
probleem is daarmee nog niet principieel opgelost. Het blijkt
namelijk erg lastig om de precieze impact te bepalen van een
mutatie in één van de basisregistraties op de andere. Datamodel
len, netwerkprotocollen, codetabellen, berichtenformaten - alles
kan invloed hebben op hoe een mutatie binnen de hele informa- Ad van der Meer
tieketen uitpakt.
Dat leidt tot grote onzekerheid bij de operationeel-technische
medewerkers. Die zijn allemaal erg goed en erg slim, maar vooral
voor hun eigen gedeelte. Zij gaan hulpeloos kijken als je ze
vraagt om de impact van een wijziging op de totale informatie
keten. Hier zijn dus specialistische functionarissen nodig die de
hele ketens binnen het stelsel scherp op hun netvlies hebben, de
koppelvlakken uit en te na kennen, en goed op de hoogte zijn
van de (eigen)aardigheden van netwerken, uitwisselformats en
wat dies meer zij.
En ook nog dit. Je houdt basisregistraties bij ten behoeve van
(interne) afnemers. Die gaan hun bedrijfsprocessen inrichten op
de basisregistraties. In een toenemend aantal gevallen gaat dit
betekenen dat een mutatie in een basisregistratie bij een afne
mer automatisch een bedrijfsproces start. Zo zal een uitschrij
ving van bewoners uit de GBA bij de Sociale Dienst automatisch
leiden tot een mutatiebehandelingsverzoek aan de backoffice:
immers, dit kan een wijziging in de uitkeringsrelatie betekenen.
Bij het beheren van basisregistraties moetje dus erg oppassen
bij het doorvoeren van wijzigingen. Je moet niet alleen goed op
de hoogte zijn van je interne ketens, maar ook van de bedrijfs
processen van je afnemers. Dat houdt in dat je (deels) achter de
voordeur meekijkt. Dit betekent datje bij het implementeren
van een basisregistratie nauwkeurig moet analyseren wat dat bij
interne afnemers van die gegevens betekent, en datje bij elke
wijziging van een registratie moet onderzoeken óf en zo ja wat
dat dan kan betekenen. Dat zijn doorgaans tijdrovende vraag
stukken.
De moraal van dit verhaal? Het grote voordeel van het stelsel is
dat alles met alles is gekoppeld. Dat is tegelijkertijd ook het grote
nadeel: alles in het stelsel heeft invloed op elkaar, in die zin bijt
het stelsel zichzelf in de staart. Je moet dus zorgen voor grondige
kennis van de informatieketens tot en met de afnemers. En onder
schat de hoeveelheid werk niet en beleg die taken structureel in
de organisatie! Je afnemers zullen je dankbaar zijn.
Via MIJNGIN wordt de GIN-ledendatabase up-to-date gehouden. We zijn er met z'n allen in geslaagd om van onze leden betere gegevens
in deze database te plaatsen. Op basis van de nu beschikbare informatie starten we in maart een lezerspanel. De bevindingen en ideeën uit
deze groep zullen we onder deze rubriek opnemen en publiceren.
Meer informatie over MIJNGIN en hoe daar gegevens aan te vullen en te verbeteren vind je op www.geo-info.nl.
Geo-lnfo 2013-2 3
Geo Info 02-13.indd 3
18-02-13 09:34
