Denken Over Data

Mijn naam is Richard Steijn en ik ben dol op data dingen. In deze blog deel ik mijn ideeën, ervaringen, hersenspinsels en wat al niet meer over dit onderwerp.

Bezoek ook eens de website van Vaiper, mijn bedrijf.

Categorie: Datakwaliteit

  • Datamigratie?: Bezint eer ge begint

    Datamigratie?: Bezint eer ge begint

    U denkt misschien: Waarschuwt hij nou voor datamigraties? Nou nee, dat is niet de bedoeling. Ik wou de lezer er slechts op wijzen dat, wanneer een systeemmigratie, met bijbehorende data, op stapel staat, dit een goed moment is om starten met het leggen van een stevige basis voor toekomstig databeheer. Aangezien iedere organisatie hier vroeg of laat wel mee te maken krijgt, bijvoorbeeld vanwege de gang naar de cloud, leek het mij goed om eens wat zaken op op een rijtje te zetten.

    Want waarom zou u simpelweg bestaande data overzetten, inclusief fouten, inconsistenties en verouderde structuren? Een datamigratie biedt het momentum om de datafundamenten van uw organisatie nog eens kritisch na te lopen en te verbeteren. Alle data uit het oude systeem moet immers toch onder de loep worden genomen.

    Enterprise Data Model

    Maak bijvoorbeeld, om te beginnen eens een start met Enterprise Data Model (EDM). Een EDM helpt u in een (of twee) oogopslag(en) inzicht te krijgen over welke entiteiten (klanten, producten, facturen, medewerkers, …) er informatie in omloop is binnen uw organisatie. Bovendien zijn hier de definities van alle entiteiten en hun attributen vastgelegd. Gebruik hier wel een degelijk CASE-tool voor zoals Powerdesigner of DataArchitect zodat u wordt geholpen met het bewaken van de integriteit van het datamodel. Bovendien heeft u dan een mooie basis van waaruit allerhande code generereerd kan worden ten behoeve van het creeeren van tabellen, ETL scripts en (delen van) applicaties die iets doen met de data die in het EDM is gemodelleerd.

    Een goed bijgehouden en compleet EDM betaalt zichzelf op termijn terug, omdat het veel dingen makkelijker maakt. Zo laat het duidelijk zien welke gegevens (entiteiten) in welke systemen worden gebruikt en hoe ze herkend kunnen worden (de zogenaamde business keys). Dit helpt bij het samenvoegen van data, bijvoorbeeld in een datawarehouse. Bijvoorbeeld: Stel, we hebben een Klant als entiteit die in zowel een CRM-systeem als een factureringssysteem voorkomt onder de naam Customer. In het CRM systeem wordt het veld Customernumber gebruikt als unieke identificator van een Klant. In het factureringssysteem wordt o.a. het veld CustomerId hiervoor gebruikt. In het EDM is vastgelegd dat de velden Customernumber in het CRM-systeem en CustomerId in het factureersysteem mappen met het het attribuut Klantnummer van entiteit Klant, dat is aangemerkt als business key. Hieruit volgt dat de velden CustomerId en CustomerNumber gebruikt kunnen worden om klantinfo uit beide bronsystemen te koppelen.

    Bij organisaties die kampen met zogenaamde datasilo’s kan een EDM helpen de overlap en verschillen tussen deze datasilo’s zowel qua structuur als definities in beeld te brengen hetgeen communicatie tussen de gebruikers van de silo’s vereenvoudigd.

    Master Data Management

    In samenhang met bovenstaande is dit ook een mooie aanleiding om Master Data Management (MDM) op te zetten. Dit komt erop neer dat er een centrale plek wordt gecreëerd waar alle kerngegevens (klanten, producten, leveranciers, medewerkers, …) beheerd worden. Informatie die dus in MDM beheerd worden, worden alleen gewijzigd in het MDM systeem en nergens anders. De overige informatiesystemen in de organisatie verwijzen er slechts naar. Hiermee wordt voorkomen dat er binnen de organisatie inconsistente kerngegevens rondgaan.

    Grote schoonmaak

    Verder zou ik de over te zetten data onderwerpen aan een kwalitteitsonderzoek. Identificeer dubbelingen en tegenstrijdigheden in de data. Spoor foutieve data op. Standaardiseer naamgevingen, formaten en structuren. Zorg voor eenduidige datadefinities en coderingen en breng ze zonodig onder in het EDM en MDM. Corrigeer datakwaliteitsissues zoveel mogelijk alvorens de data door te zetten naar zijn nieuwe habitat.

    Data Governance

    En nu u toch bezig bent met uw datalandschap: Spreek meteen even af wie welke afdeling in de organisatie eindverantwoordelijk is voor welke data. Definieer en implementeer datakwaliteitsregelsen zorg voor duidelijke richtlijnen over data-opslag, beveiliging en toegang. Oftewel: Data Governance.

    Tot slot

    Daarom zeg ik: Bezint eer ge begint als u aan een datamigratie begint en neem uw kans waar om uw databeheer en datakwaliteit in de toekomst op een hoger niveau te brengen.

  • Hogere datakwaliteit door het zelfreinigend effect

    Hogere datakwaliteit door het zelfreinigend effect

    We leven in een tijd waarin data enorm belangrijk is. Organisaties buitelen over elkaar heen met de wens om datagedreven te werken. Deze data gebruiken we om de prachtigste dashboards te voeden en om allerlei analyses uit te voeren die tot nieuwe inzichten leiden. Een wet die echter nog altijd geldt, is: Garbage in = Garbage out. We kunnen nog zulke mooie rapporten en analyses maken en er nog zoveel machine learning op loslaten: als de brondata van slechte kwaliteit is, zal het informatieproduct dat je ervan maakt van dezelfde kwaliteit zijn.

    Bij mijn klanten loop ik geregeld tegen data van matige kwaliteit aan. Wat ik vaak waarneem, is dat BI-ontwikkelaars proberen “er toch nog iets van te maken”. In bepaalde eenvoudige gevallen is hier best wat voor te zeggen. Denk bijvoorbeeld aan een veld “Geslacht” dat de waarden M, m, man, V, v en vrouw kan bevatten. Het is duidelijk dat M en m staan voor “Man” en V en v voor “Vrouw”. Een simpele fix zou dan kunnen zijn: M, m en man vertalen naar “Man” en V, v en vrouw vertalen naar “Vrouw”.

    Echter, wanneer een fix minder voor de hand ligt en meer interpretatie en creativiteit eist van de BI-ontwikkelaar, heb ik mijn bedenkingen. Stel dat men een klantenbestand bijhoudt welk type klant het betreft. Het veld Klantcategorie bevat de waarden Premium, Standaard en Budget. Helaas wordt bij het invoeren van nieuwe klanten dit veld regelmatig niet ingevuld. Om, ter wille van een managementdashboard, toch zoveel mogelijk klanten aan een van de drie categorieën toe te wijzen, besluit de BI-ontwikkelaar om dit veld bij ontbrekende waarden in te vullen op basis van de omzet die de klant gemiddeld per jaar genereert.

    Het gevolg van deze benadering is dat in het dashboard iedere klant netjes aan een categorie wordt toegewezen. In het beste geval heeft de ontwikkelaar deze fix met de belanghebbenden besproken, gedocumenteerd en benoemd in het betreffende dashboard. In het slechtste geval verzint de ontwikkelaar op eigen houtje een fix en documenteert het niet. Verder wordt nu de indruk gewekt dat het datakwaliteitsprobleem niet bestaat of verder geen actie behoeft. Hierdoor blijft het werkelijke probleem in de brondata bestaan en zal alleen maar groeien naarmate de tijd verstrijkt. Dit bezwaar geldt overigens ook voor de simpele fix in het eerste voorbeeld.

    Zelfreiniging

    In het volgende gedachtenexperiment gaan we omwille van het verbeteren van de datakwaliteit gebruik gaan maken van het zelfreinigend effect. Dit houdt in dat eindgebruikers van de BI-oplossing zoveel mogelijk “niet gefixte” data te zien krijgen. Het idee is dan dat er mechanismen worden gecreëerd die er voor zorgen dat degenen die de “foute” data hebben ingevoerd, dit zelf corrigeren. Hiervoor moeten feedbackloops gecreëerd worden waarin zowel de eigenaar van de brondata als de gebruikers van hierop gebaseerde informatieproducten zijn opgenomen. Het basisidee is dat datakwaliteitsproblemen juist expliciet duidelijk worden gemaakt aan de eindgebruikers van de BI-oplossing.

    Een zo groot mogelijk draagvlak

    Om het zelfreinigend effect optimaal te laten werken, moet hier vanaf de start van het gebruik van de BI-omgeving aan worden gewerkt. Goodwill van alle medewerkers die de bronsystemen vullen en hun leidinggevenden is noodzakelijk. Hoe krijgen we dit voor elkaar? Dat is een uitdaging. Wat kan helpen, is deze personen in een vroeg stadium bij het project te betrekken. Ze moeten zelf het nut van Business Intelligence inzien, zowel voor de organisatie als voor henzelf.

    Geef iets terug

    Wat volgens mij ook goed zal werken, is om zoveel mogelijk mensen in alle lagen van de organisatie “iets terug te geven” uit het datawarehouse. Op een lager organisatieniveau kan dit in de vorm van handige overzichten en lijsten die niet direct beschikbaar zijn in de systemen waarmee ze dagelijks werken. Op hogere organisatieniveaus kan dit bijvoorbeeld door overzichten op een hoger aggregatieniveau of via een of meer KPI’s in een dashboard. Dit zal het draagvlak vergroten.

    Op deze manier maken we van zoveel mogelijk mensen aan de invoerkant van de bronsystemen tevens eindgebruikers van de BI-omgeving. Op de kwaliteit van de informatie die ze hieruit halen, kunnen ze nu zelf invloed uitoefenen. Men wordt zich op deze manier bewust van de gevolgen van fouten in de invoer. We hopen dan dat men de werkwijze in de toekomst gaat aanpassen om zo fouten te voorkomen.

    Aangeven wat er fout is

    Hoewel we “foute” data niet wegfilteren of corrigeren, geven we wel aan wat er fout aan is. Hiervoor moeten in kaart gebracht hebben welke business rules er gelden m.b.t. het betreffende data item (Voorbeeld: Iedere klant moet ingedeeld worden in een Klantcategorie). Vervolgens kunnen we per business rule gaan vastleggen hoevaak deze geschonden is en waar dit precies het geval is. Dit zou dagelijks in een organisatiebreed datakwaliteitsrapport getoond kunnen worden.

    De bron van de data

    Bij ieder data item, dus ook de als “fout” aangemerkte, wordt opgeslagen wat de herkomst is. Dit kan op verschillende niveaus gedaan worden. Je kunt vastleggen van welk bronsysteem, welke afdeling, eigenaar of misschien zelfs welke medewerker het afkomstig is. Zo is het duidelijk wie er actie dient te ondernemen.

    Voorkom toekomstige fouten

    Probeer in de bronsystemen zaken zo te regelen dat problemen in de toekomst worden voorkomen. Dit kan bijvoorbeeld door al aan invoerkant bepaalde data integriteitseisen af te dwingen.

    Stel een datakwaliteitsbewaker aan

    Maak iemand verantwoordelijk voor het bewaken van de datakwaliteit, en geef deze persoon mandaat om waar nodig actie te ondernemen. Deze persoon kan bijvoorbeeld dataeigenaars aanspreken op datakwaliteitsproblemen en verbeteracties in de bronsystemen initiëren.

    Enkele overwegingen bij deze benadering

    Een speciale categorie binnen het palet aan “foute” data is data die niet ingelezen is in het datawarehouse, doordat er bijvoorbeeld cruciale business keys ontbreken of incompleet zijn. De bedoelde betekenis van dit soort informatie is moeilijk te achterhalen. Dit is typisch data die door specialisten aangepakt moet worden. Het zelfreinigend effect gaat hier dus niet werken.

    Het blijft een uitdaging voor het data BI-team om alle business rules boven water te krijgen. Waarschijnlijk is de lijst aanvankelijk niet compleet en zal deze gaandeweg gaan groeien. Pas als een business rule onderkend is en er een controle mechanisme voor gebouwd is, zal dit resulteren in zichtbare datakwaliteitsproblemen aan de kant van de eindgebruikers van de BI-omgeving.

    Het benoemen van de herkomst van foute data kan ook resulteren in weerstand bij de betrokkenen. Het kan worden opgevat als een soort schandpaal. Toegang tot deze informatie moet zeer beperkt en weloverwogen gegeven moet worden aan de juiste personen. Hoe specifiek je moet zijn in het aanwijzen van de bron, is ook een aandachtspunt.

    En u?

    Hoe gaat uw organisatie om met datakwaliteit?

  • Datakwaliteit en Managementinformatie: De Noodzaak van een Gouden Standaard

    Datakwaliteit en Managementinformatie: De Noodzaak van een Gouden Standaard

    In iedere organisatie van enige omvang speelt het uitwisselen van informatie tussen de verschillende organisatieonderdelen een belangrijke rol. Het komt dan ook geregeld voor dat er van bepaalde gegevens verschillende versies circuleren. Stel je voor: een bedrijf slaat alle personeelsgegevens op in een centraal HRM-systeem. Daarnaast gebruikt elke afdeling een eigen, op zichzelf staand systeem voor specifieke operationele processen, zoals projectmanagement, klantrelaties of salarisadministratie. Ook hierin worden personeelsgegevens opgeslagen die oorspronkelijk zijn overgenomen uit het centrale HRM-systeem. Vanaf dat moment kunnen in zowel het HRM-systeem als in de afdelingsspecifieke systemen onafhankelijk van elkaar wijzigingen worden aangebracht. Dit kan ertoe leiden dat er in verschillende systemen tegenstrijdige informatie over een medewerker is opgeslagen. Dit voorbeeld is slechts het topje van de ijsberg. Soortgelijke problemen doen zich bijvoorbeeld voor bij klantgegevens die in CRM-systemen, facturatiesystemen en helpdesksystemen worden beheerd. Ook hier kan dit leiden tot inconsistenties. En wat te denken van productinformatie die zowel in in de productcatalogus, het warehouse management systeem en het ecommerce systeem staat?

    Gegeven deze verschillende registraties van hetzelfde ding, rijst nu de vraag: Wat is waar? Zolang de dagelijkse bedrijfsprocessen maar soepel lijken te verlopen, lijkt deze vraag niet zo belangrijk. Echter wanneer we van onze operationele data managementinformatie willen afleiden zullen we deze vraag moeten gaan stellen. Dit is de beruchte zoektocht naar de zogenaamde “Single version of the truth”. De heilige graal.

    Managementinformatie is natuurlijk geen doel op zich. Het is slechts een middel dat kan bijdragen aan het nemen van betere strategische beslissingen, het nog efficienter maken van de bedrijfsvoering, verbeterde klanttevredenheid, etc. Hoe voorkomen we dat er onduidelijkheid bestaat over welke data we moeten gebruiken voor het genereren 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 Medewerker, Klant en Product. Als er gekozen is voor een datawarehouse 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.

    Bij het ontbreken van MDM “kiezen” veel organisaties noodgedwongen voor een alternatief. Namelijk door voor het verzamelen van brondata voor managementinformatie te kiezen voor een bronsysteem dat als leidend gezien moet worden. Deze leidende data (in deze context wordt nog wel eens gesproken van het “Golden Record”) wordt dan eventueel nog aangevuld met data uit niet leidende bronnen. Dit levert in de praktijk allerlei uitdagingen op met betrekking tot dataintegratie oftewel het aan elkaar koppelen van data uit verschillende bronsystemen. Vaak moet dan dat de trukendoos open om toch maar zoveel mogelijk data wel te kunnen koppelen. Tijdens dit dataintegratieproces 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 en is deze aanpak goed gedocumenteerd. In veel gevallen echter, 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.

    Als we eenmaal zover zijn dat de we brondata bij elkaar hebben gezocht, moet er nog managementinformatie van gemaakt worden.  In een volgend artikel ga ik hier wat dieper op in.

  • Accreditatie in het onderwijs en de PDCA Cyclus

    Accreditatie in het onderwijs en de PDCA Cyclus

    Accreditatie is in hoger onderwijsland een heet hangijzer. O.a. de bekostiging en het imago van de instelling of opleiding hangen hier van af dus eens in de zes jaar is het weer tijd om de bloemetjes buiten te zetten. Het accreditatieproces wordt veelal ervaren als een grote inspanning. Begin dit jaar is door de NVAO het nieuwe accreditatiestelsel voor instellingen in het hoger onderwijs geïntroduceerd. De focus dit nieuwe stelsel is verschoven van kwaliteitsborging naar kwaliteitsverbetering. Daarnaast zou het de administratieve last voor onderwijsinstellingen wat moeten verlichten, met name door de introductie van een instellingstoets kwaliteitszorg. Een onderwijsorganisatie die op deze toets een positieve beoordeling behaalt, komt in een ander (lichter) accreditatie regime terecht voor haar opleidingen, waarvoor dus minder informatie aangeleverd hoeft te worden. Voor meer info zie kijk hier.

    Instellingen en opleidingen moeten voor accreditatie twee typen informatie aanleveren. Enerzijds moet tekstuele informatie worden geleverd zoals diverse beleidsstukken rondom kwaliteitszorg, een kritische zelfreflectie en niet kwantificeerbare bewijzen van deugdelijkheid van de onderwijskwaliteit. Anderzijds zal ook de nodige getalsmatige onderbouwing geleverd moeten worden om de effectiviteit van de kwaliteitszorg aan te tonen. Zeker nu focus nadrukkelijker op kwaliteitsverbetering komt te liggen zal een opleiding des te meer moeten kunnen aantonen hoe zij deze kwaliteitsverbetering dan wel denkt te kunnen meten en vervolgens hierop te acteren.

    Een accreditatie kost meer tijd en moeite naarmate kwaliteitszorg een slechter geïntegreerd onderdeel van het werkproces is. Als kwaliteitszorg door de gehele organisatie structureel aangepakt zou zijn, zou het opleveren van de juiste informatie voor de auditcommissie niet zo’n grote last zijn. Beleidsplannen kunnen dan zo van de plank getrokken worden en de getallen die bewijzen dat deze plannen werken kunnen vlot berekend worden. Namelijk de data die een organisatie gebruikt om kengetallen te berekenen die de effectiviteit van haar kwaliteitszorg inzichtelijk maken voor de auditcommissie zou dezelfde moeten zijn als waarop de organisatie de haar processen stuurt. Als dit niet het geval is, dan zou men zich moeten realiseren dat er kennelijk iets mis is met het ‘Check’ deel in de PDCA cyclus die het hart van het stelsel van kwaliteitszorg vormt. Dien ten gevolge kan aan het ‘Act’ deel ervan ook geen goede invulling gegeven worden, wat weer tot de conclusie leidt dat men kwaliteitszorg niet op orde heeft.

    Bovengenoemd scenario treedt typisch op als men de accreditatie als een zesjaarlijkse verplichte exercitie ziet waarin men even door een hoepeltje moet springen en na het bereiken van een positief oordeel weer rustig achterover kan leunen.

    Om de (verbetering van) kwaliteit van een onderwijsproces te kunnen meten zal op regelmatige basis aan zowel aan de input als aan de output kant gemeten moeten worden. Informatie aan de output kant kan worden vergeleken met een norm om zo te bepalen of men op koers ligt. Hierbij dient te worden opgemerkt dat veel processen op zich weer op te delen zijn in deelprocessen. Op alle niveaus kan gemeten en vergeleken worden.

    Op het niveau van opleiding kun je wat betreft input bijvoorbeeld denken aan het vastleggen van informatie rondom instroom van studenten zoals: de gevolgde opleidingsvorm, nationaliteit, leeftijd, vooropleiding, geslacht etc. Wat betreft output kun je denken aan informatie rondom uitstroom zoals: uitstroom met/zonder diploma, moment van uitvallen, doorstroom naar betaalde baan of vervolgopleiding, tevredenheid over de opleiding etc.

    Op cursusniveau kun je aan de inputkant denken aan het vastleggen van informatie rondom bestede FTE’s per werkvorm (hoorcollege, werkcollege, stage etc.), bepaalde karakteristieken van docenten zoals: specialisme, type aanstelling, nationaliteit en studenten gebonden aspecten zoals: hoofdopleiding, nationaliteit, major of minor cursus, cursus wel niet verplicht etc. Aan de outputkant valt in dit verband te denken aan het werkelijke aantal contacturen tussen student en docent, het werkelijk aantal besteedde uren door student en docent, studenttevredenheid over: cursusmateriaal, deskundigheid van de docent, didactische vaardigheden van de docent, bereikbaarheid van de docent, studielast etc.

    Met name de informatie aan de outputkant van processen is doorgaans lastig of zelfs onmogelijk op een later tijdstip (bij een accreditatie) te bepalen. Het is daarom zaak om te meten en vast te leggen zo snel dit mogelijk is. Deze regel moet ‘ingebakken’ zijn in ieder proces in de organisatie. Maar dat alleen is niet genoeg. Als het meten van de kwaliteit per geval (bijvoorbeeld per cursus) weer op een andere wijze gebeurt en wordt vastgelegd, resulteert dit alsnog in heel veel werk als je dit soort informatie wilt bundelen in een overzicht of kengetal. Daarom is het nodig dat er een algemeen geldende werkwijze van evaluatie wordt gehanteerd, over de verschillende processen heen. De verzamelde data kan dan weer op een centrale plek worden bewaard, en bijvoorbeeld via een data warehouse worden ontsloten voor de organisatie. Deze werkwijze moet organisatiebreed gedragen worden en helder zijn vastgelegd. Dit is dan meteen een mooi document om aan de auditcommissie te overhandigen. Dit kan mijns inziens alleen maar werken als iedereen in de organisatie het belang hiervan inziet en de managementinformatie die hierdoor beschikbaar komt ook kan gebruiken om de eigen processen bij te sturen op het moment dat het nodig is en niet alleen en niet alleen voor de accreditatie. Het accreditatieproces is op deze manier het logische verlengde van de hele kwaliteitszorgcyclus.