BRM is helemaal geen oplossing in mijn optiek. Robuuste relationele databases zijn dat echter wel. Ik stoor mij al geruime tijd aan de term 'opschonen' als het data in een database betreft. Volgens de theorieen waarop relationele databases (relationele logica) zijn gebaseerd is een correct datamodel een garantie voor consistente gegevens. Ik heb nogal wat databases van dichtbij gezien en over het algemeen waren de datamodellen niet sluitend, en dus was er ook sprake van opschoonacties.

Hoe lossen wij dit probleem op? De overheid huurt enkele goed opgeleide en ervaren database-deskundigen in (en dus niet mensen van Cap Gemini o.i.d. die onlangs nog een cursus hebben gehad) en deze mensen ontwerpen nieuwe datamodellen en conversie scripts om de huidige database te importeren in de correcte database. Als deze zaken klaar zijn wordt de huidige database op slot gezet en worden nieuwe gegevens slechts ingevoerd in de nieuwe database. Vanaf dit moment kan de beschikbare data ingelezen worden in de nieuwe database en vallen de corrupte records al snel door de mand.

Wat koppeling van databases betreft, stel ik voor dat de verschillende overheidsinstellingen gebruik maken van een grote database waarin alle gegevens staan. Als primary key wordt voor een persoon het SoFi-nummer gebruikt en niets anders. Of iemand dan in de ene database Janssen en in de andere Jansen heet, is dan niet meer relevant. De conversie scripts pakken gewoon een van beiden en als het niet klopt kan de persoon in kwestie later altijd nog naar een callcenter (zie vorige column) bellen en vragen of dit aangepast kan worden.

Als je de reactie van Justs leest, zijn er twee opties:
a) Justs snapt het allemaal wel maar is een cynicus pur sang of
b) Justs weet niet waarover hij spreekt.

Ik zou in beide gevallen niet moeten reageren, maar in geval iemand wel zijn raad opvolgt, doe ik het toch. Zekerheid boven alles. Een goed relationeel bestand is inderdaad de garantie voor consistentie - maar ook de garantie voor consistentie in fouten. Het is echter ondenkbaar dat alle overheden en overheidsinstellingen van een grote relationele database gebruik gaan maken. Dream on - zou ik zeggen! De grootste fout die de meeste IT’ers maken, is dat zij verwachten dat de gebruikers van een systeem de database vullen met waarden, zoals die in het conceptuele model zijn voorzien. Dream on - zou ik wederom zeggen.

Het beste bewijs dat Justs een cynicus is, is dat hij zijn naam opzettelijk fout heeft ingegeven. Hiermee toont hij feilloos aan dat de ontwerper van deze site er geen rekening mee heeft gehouden dat er ook fouten dan wel niet-namen in de rubriek ‘uw naam’ kunnen worden ingevoerd. Erg subtiel Justus. Chapeau!

Norbert Mergen, Human Inference
www.humaninference.nl

PS Human Inference heeft software die in staat is namen te valideren.

Net als klanten van (commerciële) bedrijven niet als nummer wensen te worden behandeld, zo moet de overheid ook de burger niet als nummer behandelen. Als de overheid de kloof met de burger wil dichten, zal zij zich klantvriendelijk moeten opstellen.

In feite spelen binnen de overheid meerdere aspecten een rol:
1) er is geen commerciële drive
2) de politieke opportuniteit en daarmee gepaard gaande actualiteit
3) mensen maken nu eenmaal fouten en ook ambtenaren zijn mensen

Om met de laatste te beginnen: het is een illusie te veronderstellen dat ambtenaren foutloos werken. Nu reeds kennen we een scala aan namen die zijn ontstaan in het papieren tijdperk: er bestaan zowaar 32 schrijfwijzen voor de naam die klinkt als Mathijssen. Dit soort vergissingen zijn weliswaar door o.a. het GBA-netwerk te verminderen – aan de andere kant heeft een fout verstrekkende gevolgen.

Bij de overheid is geen commerciële drive, zoals in het bedrijfsleven. Door klantgericht te handelen, komen er geen klanten (burgers) bij – door niet-klantgericht te handelen verhuizen burgers ook niet. Ze mopperen en keren zich hoogstens van de overheid af. Want welke burger reageert als hij of zij ziet dat er een fout in de bevolkingsadministratie staat? Hoogstens als het tot direct nadeel leidt. En om ervoor te zorgen dat een fout in de bevolkingsadministratie wordt aangepast, vergt nogal wat doorzettingsvermogen. Een database is een afbeelding van de werkelijkheid. De Gemeentelijke Basisadministratie moet dat ook zijn.

Human Inference houdt zich sinds 1986 bezig met de kwaliteit van relatiegegevens. Bijna alle grote bedrijven en andere organisaties gebruiken software van Human Inference. Ook de Rijksoverheid, o.a. IBG, Belastingdienst, Centrale Justiële Documentatie en Ministerie van Justitie (Vreemdelingenketen). Als je er goed over nadenkt, is het ten hemel schreiend dat een bedrijf als bijvoorbeeld Spaarbeleg er veel aan gelegen is om de gegevens van haar (potentiële) klanten correct te verwerken en dat bij alle gemeentelijke overheden de minste of geringste tikfout als waarheid in de basisadministratie c.q. bevolkingsadministratie wordt opgeslagen. Ooit heb ik gesproken met een leverancier van software voor gemeenten. Hij zei: “Waarom zou een gemeente meer geld uitgeven om de kwaliteit te verbeteren? Ze winnen er niets voor terug.” Dat was een jaar of acht geleden. Nu voert het begrip CRM de boventoon bij het bedrijfsleven. Inderdaad, tijd voor BRM!

Norbert Mergen, Human Inference, Arnhem (www.humaninference.nl)

Ik ben het volstrekt niet eens met de stelling dat een goed relationeel bestand, naast een garantie voor consistente data ook een garantie voor consistentie in fouten. Natuurlijk kunnen de meeste IT'ers geen relationele databases in elkaar zetten, maar er zijn er genoeg die dit wel kunnen. Om terug te komen op de stelling dat een goed relationeel bestand garant staat voor consistentie in fouten, kan ik alleen maar zeggen, dat als een database niet waterdicht is er geen foute data in terecht kan komen. De IT'ers waar meneer Mergen over spreekt kunnen blijkbaar geen database-implementatie maken als zij niet in staat zijn het conceptuele model waarin de regels nog wel kloppen niet om kunnen zetten in een relationeel implementatiemodel.
Natuurlijk zal een database niet controleren of de schrijfwijze van de achternaam De Broeckenaere met 'ae' of met 'aa' geschreven wordt. Dit is mijns inziens ook niet relevant, want ik voerde aan dat als primaire sleutel het SoFi-nummer van de burger gebruikt kan worden. Dit is immers een uniek nummer. Bovendien bevat een goede database slechts een keer de naam van een persoon.

Het opstellen van een datamodel en bijbehorende constraints (regels waaraan de relaties en de records moeten voldoen) is een van de weinige zaken op gebied van software-ontwikkeling, die zeer goed in samenwerking met de opdrachtgever gedaan kunnen worden. Bij het ontwerp van een database zijn de regels namelijk strikt. Tabellen hebben relaties met elkaar en in de tabellen kunnen slechts bepaalde soorten gegevens opgeslagen worden. Bij het ontwerp van een database is in eerste instantie sprake van een conceptueel model, maar meneer Mergen zou veel betere reclame maken voor zijn bedrijf als hij ook nog weet te melden dat naast een conceptueel model ook een relationeel en een implementatiemodel gemaakt dient te worden. Het implementatiemodel kan vrijwel in een keer omgezet worden in een werkende database, waarin elke foutiefe invoer in deze kern van het systeem wordt afgevangen (de database garandeert de consistentie van de gegevens). Een veel gemaakte fout is om integriteitsregels slecths in de abovenliggende pplicaties in te bouwen. Dit levert weliswaar gebruiksvriendelijkere foutmeldingen op, maar kan tot gevolg hebben dat de data in de database niet meer consistent is. (Waanzin als XML in de database en het gebruik van Enterprise Java Beans dragen tot dit laatste bij bij).

Aangezien een database de kern is van menig applicatie, dienen hier op het laagste niveau zo veel mogelijk business rules (in de vorm van constraints en triggers) geimplementeerd te worden. De overheid doet er goed aan om een algemeen datamodel (niet per se een enkele fysieke database zoals ik wellicht eerder suggereerde) voor persoonsgegevens op te stellen. Dit datamodel kan gemakkelijk binnen een week geimplementeerd worden en hiervoor zijn geen dure Enterprise Solution Integration Deployments nodig (de overheid moet overigens maar eens luisteren naar Groen Links en al die dure software niet meer kopen, maar gewoon degelijke goedkope spullen gebruiken).

Natuurlijk moet de overheid klanten niet als nummer behandelen, maar in een database dient dit wel te gebeuren. Overheden doen er wellicht goed aan om 'klanten' (ja, zij noemen ons klanten) duidelijk te maken hoe hun gegevens zijn opgeslagen en wat hun primaire sleutels zijn. Zo kunnen de burgers wellicht een steentje bijdragen aan de controle van de consistentie als de overheid weer eens een steekje laat vallen.
Als de overheid die blauwe enveloppen nou eens een keer achterwege laat en in plaats daarvan de uitdraaien stuurt van een paar database-queries.....

Het lijkt erop dat De Broekenaare in zijn betoog de aansluiting met de realiteit mist. Op zijn verhaal over databases is weinig aan te merken, anders dan dat dit zuiver vanuit de technologie is beredeneerd. Waar Pieterse het over heeft, is dat in systemen al dan niet opzettelijk fouten worden ingegeven en dat eerst maar eens moet worden toegegeven dat databases niet schoon zijn, voordat men het probleem kan oplossen. Dat een probleem van een andere orde.

Een uniek nummer als primaire sleutel gebruiken is al jaren gangbaar; bij overheid en in het bedrijfsleven. Maar het bedrijfsleven weet (a) dat mensen meestal niet hun unieke nummer bij de hand hebben en (b) dat door vergissingen en fouten klanten meer dan eens worden ingevoerd.

Deze feiten gelden 1:1 voor de overheid. En zoals ik al aangaf, ook bij de overheid worden fouten gemaakt: bij een uniek SoFi-nummer worden de gegevens van een persoon verminkt vastgelegd. Maar het kan ook zijn dat een SoFi-nummer niet bij de juiste persoon is gebruikt. Soms moedwillig (witwerken); soms abusievelijk. Het is genoegzaam bekend dat er SoFi-nummers meer dan eens zijn toegekend, of door (externe) bronnen, de nummers en personen zijn verwisseld. Hoe goed het conceptuele model dan ook mag zijn, en hoe goed dat dan ook is geïmplementeerd in een rdbms en hoe diep de controles en validaties daar dan ook mogen zijn ingebouwd (stored procedures, etc.), de werkelijkheid is weerbarstiger. Er moet rekening gehouden worden met menselijk feilen.

Het probleem, heer De Broekenaare is dus niet de techniek. En in zekere zin ben ik het dan ook niet met uw betoog oneens. Sterker nog: sommige meningen over nieuwerwetse zaken deel ik van harte. Maar uw betoog is rigide en enigszins naïef.

Wat mij betreft: discussie gesloten. Tenzij de heer Pieterse of een ander nieuw inzicht heeft..

Norbert Mergen, Human Inference, Arnhem

Als een database al dan niet opzettelijk ingegeven data bevat en dus niet 'schoon' is, primary keys in database voor andere doeleinden dan waarborging der relationele integriteit misbruikt kunnen worden, er nog steeds vergissingen gemaakt kunnen worden bij de invoer en de techniek hier geen rol in de oplossing mag spelen en er dus maar weer met de huidige kapotte databases verder gewerkt moet worden, dan moet zal BRM vast wel een goede oplossing zijn.
Succes hiermee.

Volgens mij is XML de oplossing van deze problematiek.

10% van de nederlanders verhuist jaarlijks(CBS). Als dit niet tijdig wordt doorgegeven dan loopt de administratie bijvoorbeeld al achter. De uitdaging is dan ook om de administratie actueel te houden maar ook juist en volledig en dat tegen een gunstige prijs/kwaliteit verhouding. 100% correcte administraties zijn een utopie.. Maar hoe ver moet je gaan?.

Hoe bepaal je de kwaliteit van de huidige gegevens en de businesscase om er wat aan te doen?

De norm die de overheid stelt aan haar bestanden is hoog. Het rechtsgelijkheidsbeginsel, moderne dienstverlening vormen daar o.a. de basis voor. De overheid investeert hier ook nadrukkelijk in. Op het internet zijn diverse publicaties te vinden over de diverse basisregistraties die worden opgezet (denk aan het basis bedrijvenregister).

Ook in de moderne onderneming speelt het gegevenskwaliteitsvraagstuk. Inmiddels zijn een aantal onderzoeksresultaten bekend: 55% van de CRM implementaties en 70% van de DWH implementaties falen door de slechte gegevenskwaliteit(Gartner e.a.) In het verleden werd de kwaliteit van de gegevens met name aangepakt tijdens een nieuwe systeemimplementatie. Nu zie je overal structureel aandacht ontstaan voor de kwaliteit van de gegevens.

De aanpak om de kwaliteit van de gegevens vereist wel een samengesteld pakket van maatregelen. Zo kan men denken aan maatregelen on de gegens te schonen en maatregelen om te voorkomen dat vervuiling gaat optreden. Maar vaak begint het met een meting van de huidige kwaliteit en een goede businesscase zelfs voor een moderne overheid.

Ortwin Verreck
www.arvix.nl
"ARVIX is gespecialiseerd in gegevenskwaliteitsoplossingen"