Het belang van een Data Dictionary

De eerste vermelding van Data Quality-software is op zijn minst 20 jaar geleden. Over een periode van 20 jaar is er veel veranderd in de markt voor datakwaliteit. Waar datakwaliteit begon als een op zichzelf staande oplossing, veranderde het langzaam in een commodity, en is nu veelal een onderdeel binnen andere applicaties. Er zijn nog maar een paar op zichzelf staande datakwaliteit oplossingen. Hoe komt het dan dat na 20 jaar datakwaliteit de meeste organisaties nog steeds problemen hebben met hun gegevenskwaliteit?

Mogelijk nog verbazingwekkender is dat het min of meer dezelfde soorten problemen zijn als 20 jaar geleden. Het is nogal ongemakkelijk om je te beseffen dat er in die 20 jaar niet veel veranderd lijkt te zijn. We zouden zelfs kunnen concluderen dat wanneer we in de afgelopen 20 jaar er niet in geslaagd zijn de kwaliteit van de gegevens met behulp van tooling te verbeteren, de kans groot is dat wanneer we in de komende 20 jaar hetzelfde blijven doen, de resultaten evenmin overweldigend zullen zijn.

Laten we eens een stap terug doen. Waarom hebben we eigenlijk problemen met de kwaliteit van onze gegevens? In de literatuur en verschillende onderzoeken zijn de meest genoemde redenen voor problemen met datakwaliteit:

Gegevensinvoer door werknemers
Datamigratie projecten
Batch feeds
Gemengde verwachtingen van gebruikers

1. Gegevensinvoer door werknemers

Gegevensinvoer wordt steevast genoemd als belangrijkste reden van een slechte gegevenskwaliteit. Bij het invoeren van een nieuwe klant in bijvoorbeeld SAP komt veel meer kijken dan alleen het invoeren van naam- en adresgegevens. Er is een immense hoeveelheid informatie die benodigd is voor het opvoeren van een nieuwe klant. Vaak moet die informatie aangeleverd worden door verschillende afdelingen en is afhankelijk van bijvoorbeeld het type klant die wordt ingevoerd. Is de nieuwe klant de entiteit waaraan de producten worden verkocht? Of is het slechts een locatie waar de goederen naartoe worden verzonden? Zijn er speciale kortingen van toepassing op dit type klant? Is dit in het verleden al een klant geweest? Zo ja, moet deze dan opnieuw worden aangemaakt of slechts worden geactiveerd?

Het gebruik en de betekenis van de verschillende klantgroepen en bankgegevens zijn vaak complex en de afhankelijkheden met andere informatie niet altijd even duidelijk. Deze onduidelijkheid wordt groter indien nieuwe klanten maar af en toe ingevoerd worden en dit met enige niet regelmaat gebeurd. Met moet dan eigenlijk elke keer opnieuw beginnen met het begrijpen van de klant gegevens. Soms zie je op een afdeling de kennis over hoe (klant)gegevens correct ingevoerd dienen te worden langzaam afnemen. Een nieuwe medewerker moet misschien nog opgeleid worden, en begrijpt de context nog niet die bepaald hoe en wanneer bepaalde informatie moet worden ingevoerd.

2. Data migratie

Over het algemeen worden datamigratie trajecten opgeleverd door externe consultants. Deze consultants zijn bekend met datamigratie projecten en de bijbehorende tooling. Ze kennen de uitdagingen die typisch zijn voor datamigratie projecten en hebben hier al vaker mee te maken gehad. In een ideale wereld zijn deze adviseurs ook nog bekend met de bron-applicatie, van waaruit de gegevens worden gemigreerd, én met de doel-applicatie waarnaar de gegevens worden gemigreerd. Ze kunnen zelfs nog bekend zijn met de industrie waarbinnen uw organisatie opereert.

Deze externe consultants zijn echter niet bekend met de manier waarop de gegevens in uw organisatie in het verleden opgevoerd zijn, en hoe ze worden gebruikt. Regels en uitzonderingen op die regels zijn bekend bij gebruikers die wellicht niet worden geraadpleegd door het migratieteam. De meeste van deze regels en uitzonderingen worden gevonden door het analyseren van fouten tijdens de migratie. Dankzij meerdere iteraties, langdurige analyses en aannames lukt het uiteindelijk toch nog om de data te laden in de doelapplicatie. Om er op een later tijdstip achter te komen dat de aannames niet klopte en een deel van de data niet bruikbaar is.

Hoewel de consultants mogelijk het technische gegevensmodel kennen, is het niet mogelijk alle bedrijfsdefinities en regels te kennen die van toepassing zijn op de data.

3. Batch-feeds

Een Batch-feed is een exercitie waar grotere hoeveelheden gegevens in één keer worden ingevoerd. Bij batch-feeds treedt een combinatie op van de problemen die bij handmatige gegevensinvoer spelen en bij gegevensmigratie. Over het algemeen zijn er twee manieren waarop batch-gewijze invoer plaats vindt:

Gebruikers die gegevens handmatig in een bepaald formaat voorbereiden, en vervolgens een mechanisme gebruiken om al deze gegevens in één keer in de toepassing te laden.
Een op maat ontwikkelde interface tussen twee applicaties via welke voortdurend gegevens van de ene applicatie naar de andere verstuurd worden op de achtergrond, zonder dat gebruikers dit merken.

Er zijn een paar problemen die hier mogelijk voor moeilijkheden kunnen zorgen:

Het voorbereiden van de gegevens voor gebeurt vaak met Microsoft Excel. In de loop van de tijd ben ik Excel steeds vaker als bron van datakwaliteit problemen gaan zien, en niet als de oplossing;
Controles op de invoer die veelal plaatsvinden wanneer gegevens handmatig worden ingevoerd, worden mogelijk niet toegepast tijdens een batch-gewijze invoer. Denk hierbij aan invoerhulp van bijvoorbeeld straat aan de hand van postcode en huisnummer.
Er is extra inspanning nodig om ervoor te zorgen dat de batchinterface en/of de interface tussen beide toepassingen up-to-date blijft met wijzigingen in de toepassing.

De technische medewerker die verantwoordelijk is voor de batchinterface is zich mogelijk niet bewust dat de zakelijke betekenis van de gegevens in de loop van de tijd is veranderd. Mogelijk is er een nieuw klantsegment toegevoegd dat nog niet wordt ondersteund door de batchinterface. Er is dan een risico dat dat klantsegment verdwijnt tijdens de overdracht van informatie, of vervangen wordt door het default klantsegment.

4. Gemengde verwachtingen

Gemengde verwachtingen komen zowel bij het invoeren van gegevens als bij het gebruik van gegevens voor.

Tijdens het invoeren van gegevens kunnen verschillende mensen de gevraagde informatie anders interpreteren. Een voorbeeld hiervan zou de CRM-toepassing kunnen zijn, waar er een veld heeft genaamd “ETA” is bij de invoer van een opportunity. Sommige medewerkers zijn misschien niet bekend met de afkorting ETA, en zullen het veld leeg laten. Anderen herkennen mogelijk dat ETA staat voor “Estimated Time of Arrival”. In de context van een opportunity, zou dat dan de geschatte tijd betekenen dat de deal wordt gesloten, of de geschatte tijd dat de prospect zijn / haar artikelen nodig heeft? De betekenis van beiden zijn heel verschillend, maar ze zijn allebei te vertalen naar een datum.

Het mag duidelijk zijn dat wanneer iedereen informatie invoert overeenkomstig met de betekenis die zij eraan toekennen, het gebruik van die gegevens in een later stadium erg moeilijk kan zijn. Wat betekent het bijvoorbeeld als er géén datum wordt vermeld? Betekent dit dat:

Er geen ETA is?
Het niet duidelijk is wat er ingevoerd dient te worden?
De medewerker niet over de benodigde informatie beschikt en dus het veld heeft overgeslagen?

De enige constante: verandering

De enige constante in het bedrijfsleven is verandering. Wat het ene jaar nog correct en nodig is om gegevens in te voeren, zal hoogstwaarschijnlijk het volgend jaar anders zijn. De informatie die we nodig hebben voor onze dagelijkse werkzaamheden verandert en daarom verandert de behoefte aan de informatie die we opslaan. Verschillende klanttypen kunnen ontstaan in een poging de markt beter te bedienen. Na verloop van tijd kan dat nieuwe klanttype blijven, (enigszins) veranderen of volledig worden verwijderd.

Bij de beslissing over dit type klant is het natuurlijk belangrijk om te weten of het nog steeds moet worden gebruikt of niet. Een discussie rond de type klant en de argumenten die leiden tot een wijziging of verwijdering zijn net zo belangrijk, zo niet nog belangrijker dan de uiteindelijke beslissing.

Conclusie

Datakwaliteit tooling kan goed gebruikt worden voor het in kaart brengen van de problematiek rond datakwaliteit in uw organisatie. Voor een oplossing van deze problematiek moet echter niet naar tooling gekeken worden. Het is van belang dat de betekenis van gegevens, toegestane waardes en uitzonderingen éénduidig en toegankelijk vastleggen worden. Wat je nu vaak ziet is dat elk project het wiel opnieuw uitvindt, en het stuk data documenteert wat op dat moment van belang is om het project af te ronden. Deze documentatie verdwijnt na het project, of wordt onder het mom van “Agile” helemaal niet vastgelegd. Een gemiste kans. Goede documentatie is de basis voor goede data.

Tentive Solutions biedt organisaties ondersteuning bij het oplossen van hun Data Management vraagstukken. Meer weten? Neem gerust contact op met ons Data Management Team via 076-5658080 of info@tentive.nl

Rudi van Lent, Master Data & Data Quality Specialist