Een bekende zin in de IT is: Garbage in, garbage out (gigo). Oftewel als de invoer rommel is, zal de uitkomst ook rommel zijn. Het bij de bron aanpakken van dit probleem lijkt met de huidige technieken vrij eenvoudig. Zorg er gewoon voor dat je geen fouten kunt invoeren of koop de data bij een data leverancier. De praktijk is echter niet zo simpel.
In ’10 datadingen’ worden een aantal praktische problemen aangestipt die inzicht geven en tot nadenken aanzetten.
10 is slechts een selectie en je kan er uren over praten als je wilt. Als voorbeeld gebruik ik klanten en artikelen. Maar u mag hier ook denken aan andere data, zoals verkoop -en inkooporders, leveranciers, systeeminstellingen etc.
Herkent u zich in de punten, dan doet u er goed aan om na te denken over te een oplossing rondom data onderhoud. Zeker als u op dit moment bezig bent om te starten met een BI of ERP implementatie traject. Beide kunnen erg slecht tegen slechte data.
De invoer van gegevens moet snel, snel
Laten we beginnen met de invoerkant van gegevens. In veel bedrijven begint de invoer van een klant, op het moment dat deze klant bekend wordt als potentiële klant. Om dit proces niet ingewikkeld te maken en de offerte vaak snel de deur uit moet, wordt er snel een klant aangemaakt met de noodzakelijke gegevens. Het is dan niet handig dat het systeem allerlei meldingen gaat geven, als er een paar velden niet ingevuld worden. Het systeem mag daarin geen bottleneck worden. In de ideale wereld worden andere velden op een later moment alsnog ingevuld. In de praktijk worden vaak alleen de gegevens ingevuld, die nodig zijn om het proces tot aan de betaling te laten slagen.
Naast velden die het proces ondersteunen, zijn er ook velden die interessant zijn voor analyse en rapporten. Als die velden niet juist zijn gevuld, kunt u het mooiste dashboard programma ter wereld aanschaffen, maar houdt u last van incomplete gegevens. Een dashboard programma lost dit probleem (al beweren sommige leveranciers van wel) niet op. In het slechtste geval wordt er door de dashboard ontwerper omheen gewerkt, door allerlei uitzonderingen te programmeren, om geen last te hebben van dit probleem. U heeft vanaf dat moment niet alleen een onderhoudsachterstand in het bronsysteem, maar binnen afzienbare tijd ook in uw dashboard of rapport omgeving.
Systeem ondersteunt geen validatie
Met systeem bedoel ik o.a. een ERP of CRM-systeem (Microsoft CRM, NAV, AX, 365, SAP, eigen pakketten etc.) maar kan ook een database zijn in Access. Alles wat redelijkerwijs uit te lezen is. Veel systemen bieden functies om data al bij invoer te valideren. Door middel van verplichte velden, keuzelijsten of maskering (max 10 cijfers, postcode) worden invoermogelijkheden al beperkt. Je zou dus zeggen dat het inrichten hiervan het probleem zou oplossen. Maar hier wordt logischerwijs niet voor gekozen. Het valideren tijdens de invoer, beperkt je als business namelijk ook enorm. De wendbaarheid wordt minder, omdat je per sé moet houden aan deze regels. In snelle organisaties is dit niet wenselijk. Je wilt niet te afhankelijk zijn van je software (lees: leverancier) bij het invoeren van je data. Bovendien zijn de validatieregels vaak niet toegankelijk en makkelijk aan te passen door bijvoorbeeld een key-user.
Wijzigingen worden niet vastgelegd
Een goed systeem legt belangrijke gegevens historisch vast. Een factuur bijvoorbeeld, moet reproduceerbaar zijn, met exact dezelfde gegevens als op het moment van factureren. De meeste moderne systemen voldoen aan deze eis, maar oudere systemen doen dit niet altijd. U kunt zich voorstellen dat als een bestaande klant verhuist, dit adres op een gegeven moment ook in uw systeem aangepast wordt. Als u een oude factuur opvraagt bij deze klant, moet natuurlijk ook het oude adres getoond worden. Dit geldt voor alle data op de factuur, dus ook hiervoor.
Een veel gekozen manier om dit op te lossen is bij een wijziging, de klant nogmaals aanmaken. Uiteraard met negatieve gevolgen voor rapporten en dergelijke, want daar komt de klant voortaan twee maal voor. In moderne systemen worden deze gegevens gelukkig ook bij het moment van factureren opgeslagen. Houdt er dus wel rekening mee, dat als de wijziging van een klant wordt doorgevoerd, maar er geen factuur ontstaat het vaak lastig is de historie alsnog op te vragen. In een ideale wereld wilt u iedere wijziging op een dataset vastleggen. Zowel voor audits als analyses en voorspellingen kan dit waardevolle informatie zijn.
Systeem is al zeer lang in gebruik
Systemen die al een lange tijd meegaan, zijn gevuld met veel data. Data die nog steeds relevant is voor analyse, maar minder voor de ondersteuning van de dagelijkse bedrijfsprocessen. Denk bijvoorbeeld aan artikelen. Artikelen veranderen en verdwijnen in de loop van de tijd. Artikelen met een transactie in het verleden kunnen niet volledig verwijderd worden uiteraard, maar mogen ook niet meer verkocht worden. U zult ze dus op de één of andere manier moeten deactiveren. Als u dus regelmatig artikelen op rapporten ziet terugkomen die eigenlijk niet verkocht meer mogen worden, dan is dit een gebied waar vervuiling oplossen een eerste stap zou moeten zijn.
Zelfde geldt natuurlijk voor klanten. Is de klant nog actief? Bestaat het bedrijf nog wel? Is het wellicht qua naam veranderd?
Nieuwe velden zijn niet gevuld bij bestaande klanten
Verandering is standaard en systemen worden regelmatig uitgebreid met nieuwe velden. Deze nieuwe velden worden uiteraard netjes ingevuld voor nieuwe klanten, maar hoe ga je om met bestaande klanten? Voor de ondersteuning van het proces hoeft het vaak niet gevuld te worden, maar dat zie je wel terug op je rapporten en analyses.
Controle op de invoer is niet geregeld
Dashboard en rapporten zijn mooi, maar lastig te lezen door ‘garbage in, garbage out’
Interfaces lopen stroef
Betekenis van data is onduidelijk
