Over mij

Ik ben Richard Steijn en datawarehousing/BI specialist. Bij vele organisaties in diverse branches heb ik een kijkje in de keuken mogen nemen. Verscheidene technologieën hebben mijn pad gekruist. Data en alle vraagstukken daaromheen vormen een rode draad in mijn werkzame leven. In deze blog schrijf ik over de dingen die mij zoal bezighouden.

door Richard Steijn

Archief voor 'Datakwaliteit'

Grip op datakwaliteit

 Laat ik beginnen met het schetsen van een scenario dat menigeen bekend zal voorkomen. Een jonge organisatie, is ter ondersteuning van haar bedrijfsprocessen ooit begonnen met het bouwen van een eigen operationeel systeem. Dit systeem is samen met de organisatie meegegroeid. Wat ooit klein en overzichtelijk begon, is in de loop der tijd uitgegroeid tot een groot en complex systeem tjokvol met kennis die vitaal is voor het functioneren van de organisatie. In de loop der tijd hebben er verscheidene ontwikkelaars aan gewerkt. Deze zijn gekomen en gegaan met in hun hoofd belangrijke kennis over hoe het systeem werkt en hoe het met data omspringt. Er is nooit veel gedaan aan kennisborging. De focus heeft altijd vooral gelegen op het snel inspelen op nieuwe ontwikkelingen en het zo goed mogelijk bedienen van klanten. Zo nu en dan was daarvoor een snelle praktische (lees quick en dirty) oplossing nodig. Het systeem is keer op keer verder uitgebreid om aan de veranderende eisen van de business te kunnen voldoen. Gevolg is dat inmiddels niemand meer het overzicht heeft van hoe het systeem in elkaar zit. Dit maakt het maken van aanpassingen steeds lastiger.

Ook is het niet al te best gesteld met de datakwaliteit. Dit alles komt pijnlijk duidelijk naar voren nu men managementinformatie wil gaan onttrekken aan de data in het systeem. Hoe kan dit ontstaan? Een verklaring zou kunnen zijn dat in het begin toen de organisatie nog klein en overzichtelijk was er nog geen behoefte was aan een dichtgetimmerd systeem dat data integriteit  afdwong. Data ging toen nog niet door vele handen zoals nu en er was overzicht. Het was belangrijker dat het systeem flexibel en open was zodat snel kon worden ingespeeld op de behoeften van de klant.

Inmiddels is de organisatie gegroeid en komt men erachter hoe afhankelijk men eigenlijk is geworden van dit systeem. Jarenlange ervaringen met klanten en de markt liggen er op een of andere manier in vastgelegd. De organisatie beseft dat er iets moet gebeuren. Maar wat? Hieronder volgen enkele tips die helpen grip te krijgen op deze situatie.

Tip: Weet wat je hebt

Allereerst moeten we weten wat we hebben. Het aanleggen van een data dictionary is een goede eerste stap. Ga op tabel en veldniveau beschrijven wat de functie ervan is. Deze informatie zal her en der uit de organisatie bij elkaar moeten worden geschraapt en op een centrale plek, de data dictionary worden vastgelegd.

Tip: Stel definities op

Kijk naar de business en identificeer de concepten (entiteiten) waar het om draait. Beschrijf vervolgens exact hoe deze concepten mappen met data in het systeem. Voorbeeld: Een actief abonnement bestaat uit een record in de tabel tbl_abonnement waarvan het veld einddatum leeg is. Dit record is via het veld relatie_id gekoppeld aan een record in de tabel tbl_relatie dat weer aan een record uit de tabel tbl_adres gekoppeld is via het veld relatie_id. Doe dit voor alle concepten.

Tip: Maak zaken telbaar.

Nu we definities hebben opgesteld van de belangrijkste concepten kunnen we als volgende stap de regels opstellen over welke dataitems wel en welke niet samen mogen gaan. Deze regels (ik noem ze ook wel declaratieve business rules) stellen we op in termen van de eerder genoemde conceptdefinities.  Vertaal deze regels naar concrete controle query’s die tellen hoe vaak (en welke) er verboden data combinaties in de database voorkomen. We hebben nu een manier om ‘vervuiling’ te meten.  Wellicht hebben we nu ook een aanknopingspunt op basis waarvan kan worden berekend hoeveel omzet er gemoeid is met deze vervuiling. Dit kan dan weer gebruikt worden voor het onderbouwen van een business case voor het verbeteren van de datakwaliteit.

Vervolgens moeten er stappen worden genomen om de datakwaliteit te verbeteren. Enkele tips:

Tip: Start een verbetercyclus

Een “big bang” aanpak waarin alle datakwaliteitsissues ineens worden opgelost is doorgaans geen haalbare optie. Dit is zeker het geval als het systeem nog volop in gebruik is. Het is dan beter kleine stapjes vooruit te maken. Start daarom een cyclus waarin de eerder genoemde controlequery’s bijvoorbeeld maandelijks worden uitgevoerd om zo doorlopend zicht op de stand van zaken te houden. Bedenk daarnaast verbeteracties die er op gericht zijn het bestaande aantal foute dataitems omlaag te brengen. Deze verbeteracties kunnen eveneens periodiek worden uitgevoerd worden.  Als de tijd verstrijkt, is het heel goed mogelijk dat we door voortschrijdend inzicht onze set controlequery’s of verbeteracties nog verder kunnen uitbreiden. Verwerk deze ook in de verbetercyclus.

 Tip: Maak de organisatie bewust

Door het resultaat van de verbetercyclus te delen met de organisatie, kan gewerkt worden hogere mate van kwaliteitsbewustzijn onder de medewerkers. Betrek medewerkers uit verschillende plekken in de organisatie bij het verbeterproject. Maak bij zoveel mogelijk medewerkers inzichtelijk dat de ondernomen acties ook daadwerkelijk hun vruchten afwerpen. Maak bijvoorbeeld een datakwaliteitsmonitor die door iedereen te bekijken is.

Om te voorkomen dat we blijven dweilen met de kraan open, moeten er maatregelen genomen worden om te voorkomen dat hetzelfde probleem in de toekomst weer ontstaat. Enkele tips:

Tip: Ruim op

Velden die in onbruik zijn geraakt moeten worden verwijderd uit het systeem. Weersta de neiging om ‘voor de zekerheid’ oude datastructuren te behouden want ‘wie weet wat er dan omvalt’.

Tip: Los zaken structureel op

Idealen zijn prachtig maar als we naar de werkelijkheid kijken is het soms nodig snel te schakelen. Bijvoorbeeld om een nieuw product eerder dan de concurrent in de markt te zetten. Soms beweegt de markt sneller dan een ontwikkelteam kan bijhouden. In dit soort gevallen wordt vaak gekozen voor een quick en dirty oplossing. Mocht dit nodig zijn, neem dan nadien altijd de tijd om deze snelle oplossing om te zetten in een degelijke structurele oplossing.

Tip: Bewaak business rules geautomatiseerd.

Vervuiling ontstaat vaak doordat data integriteit en declaratieve business rules niet centraal of zelfs in het geheel niet worden afgedwongen. Moderne relationele database systemen bieden uitstekende mogelijkheden om dit te faciliteren in de vorm van referential en uniqueness constraints en triggers. Door hier optimaal gebruik van te maken zijn veel problemen te voorkomen. Deze manier van datakwaliteit afdwingen kan ook in stapjes worden uitgebreid. Dit kan gelijk opgaan met de eerder genoemde verbetercyclus. Telkens wanneer uit de periodieke controles blijkt dat een business rule geen enkele schending meer oplevert, kan op databaseniveau het geautomatiseerd afdwingen van deze regel in werking worden gesteld. De corresponderende controlequery kan vanaf dat moment worden verwijderd uit de verbetercyclus. Het komt voor, bij complexe triggers, dat dit een te zware wissel trekt op de transactiesnelheid van het systeem. In dat geval moet een andere oplossing gezocht worden. Bijvoorbeeld door achteraf te blijven controleren zoals we al deden of door wijzigingen aan te brengen in de invoerschermen.

Tip: Geef iedere gebruiker precies voldoende rechten

Een systeem waarin iedereen alle data naar hartelust kan wijzigen leidt bijna automatisch tot datavervuiling. Bekijk wie wat moet kunnen in het systeem om zijn rol in de organisatie naar behoren te kunnen vervullen. Als het systeem dit ondersteunt, ken dan iedere gebruiker precies die rechten toe die strikt noodzakelijk zijn. Als het systeem geen deugdelijk autorisatiemechanisme heeft, ligt hier de schone taak voor het ontwikkelteam om dit alsnog mogelijk te maken.

Tip: Vermijd hard coded keuzelijsten

In de meeste gebruikersschermen zijn ze wel te vinden: keuzelijsten die de gebruiker helpen met het invoeren van een valide waarde in een veld. De gebruiker kiest dan uit een lijst met veelzeggende omschrijvingen maar in werkelijkheid voert hij een code in. Reuze handig maar zorg er wel voor dat de items die in deze keuzelijsten getoond worden niet hard coded in de sourcecode voor gebruikersschermen staan. Deze waarden kunnen beter uit de database worden gehaald. Behalve dat dit voordelen met zich mee brengt met betrekking tot de onderhoudbaarheid wordt ook de kennis over welke beschrijving bij welke code hoort geborgd. Bovendien wordt het zo mogelijk door middel van een referential key te bewaken dat er enkel valide codes worden ingevoerd in de transactietabellen.

Tip: Kies het juiste datatype

Definieer het type van ieder database veld zo streng mogelijk. Dus als een veld een datum moet gaan bevatten, geef het dan een datumtype in plaats van bijvoorbeeld een teksttype, als het een geheel getal moet bevatten, geef het dan een numeriek datatype zonder decimalen.

Tot slot

Over het algemeen is het opschonen van een vervuilde database geen simpele opgave. Hiervoor is in de eerste plaats een lange adem nodig. Het opstellen van een data dictionary en business rules zijn een belangrijke eerste stap. De vervolgstap kan zijn dat het bestaande systeem verbeterd wordt. Het kan natuurlijk zijn dat het huidige systeem zodanig slecht in elkaar zit dat er wordt overwogen om over te stappen naar een nieuw systeem. De opgedane kennis over hoe de data werkelijk in elkaar steekt en hoe hij hoort in elkaar te steken zal in dat geval belangrijke input zijn voor een migratietraject naar dat nieuwe systeem.  Aan datamigratietrajecten heb ik al eens eerder een post gewijd. Kijk hier voor meer.

 

 

De kwaliteit van het hoger onderwijs staat de laatste tijd flink ter discussie. Kwaliteitszorg en het daarmee samenhangende accreditatieproces zijn dan ook hot items binnen hogescholen en universiteiten. In dit artikel, gepubliceerd in het blad Onderwijsinnovatie beschrijf ik hoe het slim toepassen van BI de kwaliteitszorg in het hoger onderwijs ten goede komt.

 

Een datawarehouse bouwen op drijfzand

Het uniek kunnen identificeren van entiteiten is van groot belang voor een datawarehouse. Binnen transactiesystemen die de bron vormen voor een datawarehouse wordt dit doorgaans netjes geregeld door een unieke index te definiëren op de velden die een entiteit identificeren. Op deze manier kan worden afgedwongen dat op ieder moment in de tijd het betreffende veld of combinatie van velden de unieke sleutel vormen van een entiteit binnen het betreffende systeem. Wanneer we vervolgens data uit het betreffende transactiesysteem willen inlezen in een datawarehouse, kunnen we op basis van deze unieke sleutel bepalen bij welke entiteit een bepaald data item hoort.

In deze post wil ik wat dieper ingaan op het concept unieke sleutel. De ene sleutel is de andere niet. Sleutels hebben aspecten die soms over het hoofd worden gezien maar die van wezenlijk belang zijn voor het kunnen ‘volgen’ van een entiteit binnen een bepaald bronsysteem door de tijd heen.

Eeuwig versus Tijdelijk

Vaak wordt er vanuit gegaan dat een unieke sleutel binnen een bronsysteem voor altijd gekoppeld blijft aan een en dezelfde entiteit. Dit is echter een aanname die door de werkelijkheid kan worden ingehaald. In systemen waar gebruikers de mogelijkheid hebben om unieke sleutels te wijzigen, kan het al dan niet bedoeld, gebeuren dat de sleutel die voorheen aan entiteit A was gekoppeld nu verbonden is met entiteit B. Zelfs de veelgebruikte technische sleutel (ook wel surrogaatsleutel genoemd) is wat dat betreft niet veilig. Het kan namelijk voorkomen dat een bestaand transactiesysteem wordt overgezet naar een andere database, waarbij de technische sleutels opnieuw gegenereerd en aan entiteiten gekoppeld worden. In een dergelijk geval is het heel waarschijnlijk dat de technische sleutels gerecycled worden. Kort gezegd: Er zijn unieke sleutels die Eeuwig zijn en er zijn unieke sleutels die Tijdelijk zijn. Wat betreft tijdelijke sleutels is het nog nuttig om te weten of ze alleen Gecontroleerd, of ook Ongecontroleerd, kunnen wijzigen. Van een sleutel die gecontroleerd wijzigt, krijgen we bij ieder geval van wijziging een signaal. Naar aanleiding van dit signaal kunnen we maatregelen nemen zodat we de betreffende entiteit in het bronsysteem kunnen blijven volgen in het datawarehouse. Bij sleutels die ongecontroleerd kunnen wijzigen, kan dat niet en hebben we te maken met een zekere foutkans. Bij een transactiesysteem dat we middels een Changed Data Capture mechanisme volgen, wijzigen tijdelijke sleutels altijd gecontroleerd. Een ander voorbeeld van een gecontroleerd wijzigende tijdelijke sleutel is een surrogaatsleutel binnen een transactiesysteem waarvan we op de hoogte gehouden worden, als er bijvoorbeeld een datamigratie plaatsvindt.

Universeel versus Optioneel

In de loop der tijd kan er voor een bepaald entiteittype een nieuwe unieke sleutel ontstaan. Bijvoorbeeld binnen het basisonderwijs is het sinds een aantal jaren verplicht om in correspondentie over een leerling met overheidsinstanties het centraal uitgegeven onderwijsnummer te gebruiken. Leerlingvolgsystemen zijn dientengevolge uitgebreid met een extra uniek veld ‘Onderwijsnummer’. Voor reeds uitgestroomde leerlingen was echter geen onderwijsnummer beschikbaar. Daarom is in veel systemen het veld ‘Onderwijsnummer’ naast uniek (voor zover ingevuld) ook Optioneel: het mag de waarde NULL bevatten. Omgekeerd kunnen reeds bestaande sleutels in onbruik raken en zo Optioneel worden. De tegenhanger van het kenmerk Optioneel noem ik Universeel.

Sterk versus Zwak

Tot slot kan het voorkomen dat een veld of een combinatie van velden logischer wijze gebruikt kan worden als sleutel maar dat binnen het bronsysteem geen uniciteit wordt afgedwongen. Dit type sleutel noem ik Zwak vanwege de verhoogde foutkans. Dit is een type sleutel dat bij voorkeur vermeden moet worden als identificatiemiddel maar helaas zijn we hier soms, bij gebrek aan beter, op aangewezen. Wanneer we zwakke sleutels gebruiken voor identificatie, doen we er goed aan de mogelijkheid in te bouwen om op zo simpel mogelijke wijze de gevolgen van een achteraf fout gebleken identificatie terug te draaien. Het alternatief is: accepteren dat er een zekere foutmarge is. De tegenhanger van het kenmerk Zwak noem ik Sterk: uniciteit wordt afgedwongen in het bronsysteem.

Een taxonomie van sleutels

Alle sleutels zijn te karakteriseren met een combinatie van bovenstaande kenmerken. In de onderstaande tabel zijn alle mogelijke combinaties weergegeven. Iedere combinatie in de tabel staat dus voor een type sleutel. Per type sleutel is aangegeven of deze een 100% betrouwbare (+) mogelijkheid biedt om een entiteit in een bepaald bronsysteem door de tijd heen te volgen in het datawarehouse of niet (-).

Let wel dat ook de classificatie van een sleutel een momentopname is. Door omstandigheden kunnen hierin wijzigingen optreden. Een sleutel die bijvoorbeeld op een bepaald moment Universeel is, kan in de loop der tijd in onbruik raken en worden vervangen door een andere sleutel. Vanaf dat moment is hij Optioneel.

Ieder datawarehouse dat gevoed wordt met data die op discrete momenten in de tijd (dus niet continue) aan een bronsysteem wordt onttrokken, loopt het gevaar, het spoor van bepaalde entiteiten kwijt te raken als er niet 100% veilige sleutels in het spel zijn. In wezen is het datawarehouse dan gebouwd op drijfzand. Mijn inschatting is dat dit vaker wel dan niet aan hand is. Ga maar na: de meeste bronsystemen leven in het hier en nu. Ze houden vaak geen rekening met wijzigingen van unieke sleutels door de tijd heen. Enige relativering is hier wel op zijn plaats. Unieke sleutels die op de werkvloer een rol spelen (de niet-technische sleutels dus), hebben doorgaans niet de neiging om om de haverklap van waarde te veranderen. Dit zou op de werkvloer namelijk resulteren in een voortdurende zoektocht naar de juiste informatie binnen een bronsysteem. Het dagelijks werk zou hierdoor sterk belemmerd worden. Aan de andere kant geldt ook hier de wet van Murphy: ’Anything that can go wrong will go wrong’.

Daarom is het goed je te realiseren waar dit probleem kan optreden. Nog beter is het om dit probleem op een of andere manier te kwantificeren. Het is onmogelijk om de situaties te identificeren waar dit optreedt, immers dan zou het probleem niet bestaan. Wat we wel kunnen doen is bijvoorbeeld iedere keer dat het datawarehouse wordt geladen, tellen hoeveel sleutelwaarden er in het verleden wel in het bronsysteem stonden  maar nu niet meer. Een andere interessante meting is, daar waar een entiteit met meerdere sleutels identificeerbaar is, te tellen hoe vaak een bepaalde sleutelwaarde door de tijd heen is gecombineerd met verschillende waarden van de alternatieve sleutel. Zo zijn er nog meer metingen te verzinnen (Suggesties zijn zeer welkom!). Een oplossing is dit niet maar het geeft wel enigszins grip op de situatie en helpt ons om iets te zeggen over foutmarge.

 

Managementinformatie: Wat is waar? (II)

In deze post ga ik dieper in op het produceren van managementinformatie in een business intelligence (BI) omgeving, er vanuit gaand dat we alle benodigde broninformatie reeds bij elkaar hebben gezocht. Deze eerste stap heb ik reeds eerder beschreven.

Als ik het heb over managementinformatie dan denk ik aan beknopte overzichten met gemiddelden en kengetallen op dashboards en dergelijke. Kortom informatie waarop een organisatie gestuurd kan worden. In data warehouse land wordt in dit verband vaak gesproken over de “single version of the truth”. Vaak wordt dit uitgelegd als: Organisatiebreed moet er consensus zijn over de definitie van alle begrippen (kengetallen, categorieën, ..) binnen de managementinformatie. Dit is makkelijker gezegd dan gedaan. Zeker als we te maken hebben met een grote schare aan eindgebruikers afkomstig uit verschillende delen van de organisatie, zal er een hoop overleg nodig zijn om deze heilige graal te vinden. En zoals een goede heilige graal betaamd, blijft hij waarschijnlijk onvindbaar.

Laten we het probleem eens illustreren aan de hand van een voorbeeld waarin het begrip Medewerker een rol speelt.

Een universiteit heeft een financiële afdeling. Op deze afdeling heerst de overtuiging dat iedereen die op de loonlijst staat, een Medewerker is. Mensen die niet op de loonlijst staan, zijn geen Medewerker.

Faculteit A ziet dit anders. Zij beschouwt alle niet-studenten die daadwerkelijk werk verrichten voor de faculteit als Medewerkers. Immers, deze mensen schrijven uren, worden ingepland en leggen beslag op bepaalde ruimtes en hulpmiddelen. Zo komt het voor dat onderzoekers afkomstig van andere onderzoeksinstituten werkzaam zijn binnen de faculteit.   Verder zijn er soms gastdocenten die een college verzorgen. Deze mensen staan niet op de loonlijst maar verrichten wel degelijk werkzaamheden.

Faculteit B hanteert een iets andere definitie. Zij beschouwd in aanvulling op de definitie van Faculteit A ook studenten met een student-assistentschap als Medewerker.

We hebben hier drie verschillende definities van het begrip Medewerker binnen een organisatie. Net als in mijn vorige blogpost rijst ook hier weer de vraag: Wat is waar?

Het antwoord is simpel: Alle drie zijn natuurlijk waar. Het hangt er maar vanaf welk gezichtspunt je kiest. Als je wilt uitrekenen wat de student/docent ratio is op een bepaald moment, moet je eerst weten welke vraag je hiermee wilt beantwoorden. Wil je de gemiddelde loonkosten in beeld brengen die gemoeid zijn met het opleiden van een student, dan kun je uit de voeten met de definitie van het begrip Medewerker van de financiële afdeling. Ben je geïnteresseerd in het gemiddeld aantal uren inspanning dat het opleiden van een student kost, dan is de definitie van faculteit A of B wellicht nuttiger.

De faculteiten zullen mogelijk niet snel bereid zijn de definitie van het begrip Medewerker over te nemen van de financiële afdeling en vice versa. Alle drie de definities hebben echter bestaansrecht. Immers zowel de werkprocessen op de financiële afdeling als de werkprocessen op de faculteiten functioneren (hopelijk) naar behoren. Je zou kunnen zeggen dat ieder organisatieonderdeel/bedrijfsproces in principe zijn eigen definitie kan hebben van een bepaald begrip en een BI omgeving moet al deze definities faciliteren. Dit hoeft helemaal geen probleem te zijn zolang het voor de eindgebruiker van managementinformatie maar steeds duidelijk is welke definitie gehanteerd wordt.

Een bijzonder geval vormt die managementinformatie die organisatiebreed en dus afdeling overstijgend is. Dit is typisch het gezichtspunt van het hoger management. Om er hier zeker van te zijn dat we geen appels met peren gaan vergelijken is afstemming nodig met de verschillende organisatieonderdelen waarover we management informatie willen produceren.

Stel, voortbouwend op het bovengenoemde voorbeeld, dat het College van Bestuur van iedere faculteit een beeld wil hebben van de gemiddelde kosten die worden gespendeerd aan het opleiden van een student per collegejaar. Hiervoor moeten onder anderen de volgende vragen beantwoorden:

  1. In hoeverre kunnen gewerkte uren van Medewerkers worden toegeschreven aan een bepaalde faculteit? Er zijn namelijk Medewerkers met meerdere deeltijdaanstellingen.
  2. Welke kosten kunnen gekoppeld worden aan gewerkte uren van Medewerkers? Denk aan loonkosten en allerhande geldstromen.
  3. Voor welk deel moeten we kosten voor het opleiden van een student toeschrijven aan een bepaalde faculteit? Denk hier aan studenten die cursussen volgen bij verschillende faculteiten.

Op zich zijn dit stuk voor stuk lastige vragen die ik hier niet ga proberen te beantwoorden. Waar het om gaat is de definitie van het begrip Medewerker in dit verband.  Het is duidelijk dat we met de definitie van het begrip Medewerker van de financiële afdeling hier niet uit de voeten kunnen. We kiezen hier de definitie van Faculteit B (dus ook student-assistenten worden als Medewerker beschouwd).

Vervolgens is het zaak dat dit wordt afgestemd met alle faculteiten. De faculteiten hoeven de definitie van de begrippen die het College van Bestuur hanteert in principe niet over te nemen. Het gaat er hier alleen om dat we voor alle faculteiten inzicht krijgen in de ons ter beschikking staande brondata met betrekking tot Medewerkers. Hiervoor is input van de faculteiten nodig. Het zo verworven inzicht stelt ons technisch in staat om hieruit de management informatie zodanig te construeren dat deze voldoet aan de definities die het College van Bestuur hanteert. De faculteiten kunnen met de brondata op hun managementniveau nog altijd hun eigen ding mee doen, natuurlijk wel met het besef dat er op een hoger gelegen niveau op een (iets) andere manier naar gekeken wordt.

Ik realiseer mij dat deze zienswijze niet door iedereen wordt aangehangen. In mijn optiek moet een BI omgeving gewoon aansluiten bij de bestaande werkprocessen. De BI omgeving moet nooit dicteren hoe de betrokken organisatieonderdelen moeten werken of communiceren. Er moet ruimte zijn voor verschillende zienswijzen. Hooguit kan de BI omgeving doordat zij inzicht geeft in de verschillen in interpretatie van bepaalde begrippen de aanzet zijn voor een “verbeterproces” om de definitie van begrippen meer op een lijn te krijgen door de organisatie heen.

Ik ben dan ook een tegenstander van het nastreven van een organisatiebrede “single version of the truth” want: “The truth is in the eye of the beholder.”

 

In iedere organisatie van enige omvang speelt het uitwisselen van informatie een belangrijke rol.  Het komt dan ook geregeld voor dat er van bepaalde informatie verschillende versies circuleren. Stel je voor: Een hogeschool slaat van alle ingeschreven studenten informatie op in een centraal inschrijfsysteem. Daarnaast gebruikt iedere faculteit haar eigen op zichzelf staande studievolgsysteem (voor de niet ingewijden: een systeem waarin studieresultaten worden bijgehouden).  Ook hierin is informatie over studenten opgeslagen die oorspronkelijk bij instroom is overgenomen van het centrale inschrijfsysteem. Zowel in het inschrijfsysteem, als in het studievolgsysteem kunnen vanaf dat moment onafhankelijk van elkaar wijzigingen worden aangebracht op de studentgegevens. Het is dientengevolge heel goed mogelijk dat in beide systemen tegenstrijdige informatie rondom een bepaalde student is opgeslagen. Dit voorbeeld is slechts het topje van de ijsberg. Soortgelijke problemen doen zich voor bij medewerkers die zowel in het HRM systeem, het financiële systeem en soms ook in het studievolgsysteem (docenten) staan opgeslagen. En nog een (uit eigen ervaring): Als studenten die ingeschreven staan bij faculteit A een cursus volgen bij faculteit B dan wordt de betreffende cursus in het studievolgsysteem van beide faculteiten overgenomen. Kortom:  Er zijn legio voorbeelden.

En dan rijst nu de vraag: Wat is waar? Je zou kunnen zeggen dat dit op zich geen interessante vraag is. De student kan immers netjes zijn studie doorlopen en daar is het ons toch allemaal om te doen. Dit is op zich waar. Het punt is alleen dat wanneer we managementinformatie willen gaan afleiden, we voor een dilemma staan. Deze managementinformatie is geen doel op zich maar speelt een belangrijke rol in de kwaliteitscyclus (en uiteindelijk ook in het accreditatieproces). Als de juiste mensen op het juiste moment kunnen beschikken over de juiste managementinformatie, kan er beter gestuurd worden.  Misschien doorloopt de student zijn studie dan wel wat sneller, of sluit zijn kennis beter aan op de arbeidsmarkt, om maar eens wat te noemen.

Hoe voorkomen we dat er onduidelijkheid bestaat over welke informatie we moeten gebruiken voor het afleiden van managementinformatie?

Een antwoord hierop is Master Data Management (MDM). Het komt er dan op neer dat van alle niet transactionele informatie er een centrale administratie wordt aangewezen die als leidend beschouwd wordt binnen alle werkprocessen in de organisatie. Het decentraal wijzigen van gegevens die onder het MDM regime vallen is dan dus vloeken in de kerk. Dit betekent uiteraard wel dat alle werkprocessen en geautomatiseerde systemen hierop geënt moeten zijn. Dit is geen sinecure. Teruggrijpend naar de bovenstaande voorbeelden moet er dan MDM worden toegepast op de entiteiten Student, Medewerker en Cursus. Als er gekozen is voor een data warehouse als middel voor het verkrijgen van managementinformatie is het laden ervan door MDM een stuk eenvoudiger geworden. Transactionele data uit de verschillende bronsystemen kan dan relatief eenvoudig aan de entiteiten gekoppeld worden die onder MDM vallen.

Veel organisaties “kiezen” noodgedwongen voor een alternatief voor MDM. Namelijk door voor het verzamelen van brondata voor managementinformatie te kiezen voor een bronsysteem dat als leidend gezien moet worden. Deze leidende data wordt dan eventueel nog aangevuld met data uit niet leidende bronnen. Dit levert in de praktijk bijna per definitie problemen op met betrekking tot het aan elkaar koppelen van data uit verschillende bronsystemen. Het kan in dat geval haast niet anders dan dat de trukendoos open moet om toch maar zoveel mogelijk data wel te kunnen koppelen. Tijdens dit koppelproces zal naar alle waarschijnlijkheid bepaalde data afkomstig uit niet leidende systemen, genegeerd worden. In het beste geval zijn alle betrokkenen (van eigenaren van de bronsystemen tot aan eindgebruikers van de managementinformatie) het eens over de gekozen aanpak. Maar uiteindelijk zullen slechts weinigen kunnen overzien wat de gevolgen zijn van de toegepaste trucs voor de kwaliteit van de managementinformatie die hieruit voortkomt. Waarschijnlijk zijn dit alleen die personen die verantwoordelijk zijn voor de technische realisatie ervan. De verantwoordelijkheid voor datakwaliteit wordt op deze manier bij de verkeerde personen gelegd. Hoe dan ook: deze praktijk komt zeer veel voor.

Bij het ontbreken van MDM pleit ik ervoor om in ieder geval alle brondata ‘as is’ te bewaren met een tijdsstempel. Namelijk het is best mogelijk dat we bijvoorbeeld door voortschrijdend inzicht bedenken dat het koppelen van data uit verschillende bronnen toch anders moet verlopen. Als we data historisch hebben bewaard, kunnen we met terugwerkende kracht deze nieuwe manier van koppelen alsnog gaan uitvoeren. Een data warehouse ingericht volgens principes als Data Vault  en Anchor Modelling is hier heel geschikt voor.

We zijn nu op de helft. Als we eenmaal zover zijn dat de we brondata bij elkaar hebben gezocht, moet er nog managementinformatie van gemaakt worden.  In de volgende blogpost ga ik hier wat dieper op in.