Better Decisions
For Better Life

Business Intelligence voor managers: Need-to-know #2 Brondata

-

business intelligence

“Al is je BI-omgeving nog zo goed.... garbage-in betekent garbage-out”.

Deze tiendelige blogreeks is onderdeel van de themareeks ‘Management & BI’. De blogreeks is bedoeld voor managers die wat meer willen weten over Business Intelligence, maar dan in begrijpelijke taal zonder alle technische termen en hypes. De blogs vormen een samenvatting van de inhoud van het 100 pagina’s lange eBook  ‘De 10 Need-to-Know’s, een introductie van Business Intelligence voor managers’.

Dit is de tweede blog in de reeks waarin we de in’s en out’s van brondata bespreken en het onttrekken van die data uit de primaire bedrijfsapplicaties van jouw organisatie.

Voor een BI-omgeving is de kwaliteit van de geleverde managementinformatie van het grootste belang. Wat hebben jouw managers aan mooie dashboards en rapporten als de cijfers die erop staan niet kloppen of misschien niet kloppen, zodat er onzekerheid gaat ontstaan? Gelukkig bestaan er in een BI-omgeving allerlei methoden en tools om cijfers te kunnen controleren en om te kunnen herleiden hoe een bepaald cijfer is ontstaan. Een goed gecontroleerd productieproces in de BI-omgeving is niet voldoende, omdat fouten in de brondata de belangrijkste bron van fouten in de managementinformatie vormen.

Al is je BI-omgeving nog zo goed.... ‘garbage-in’ betekent ‘garbage-out’.

Wat is brondata?

Binnen je organisatie wordt gebruik gemaakt van operationele systemen (de primaire bedrijfsapplicaties), waarmee medewerkers de feitelijke gang van zaken vastleggen. Denk aan het invoeren van orders door de binnendienst, het opvoeren van nieuwe producten of prijswijzigingen door productmanagers, het registreren van adreswijzigingen van klanten door de servicedesk, voorraadwijzigingen door distributiemedewerkers, een salariswijziging door P&O, nieuwe facturen door de afdeling financiën, enzovoort. In deze ‘bronsystemen’ zit waardevolle data (‘brondata’), die weergeeft wat er daadwerkelijk in je bedrijf is gebeurd en wanneer. Dit zijn dus ‘feiten’, of beter gezegd: bedrijfsfeiten. Deze bedrijfsfei­ten moeten we verzamelen om er managementinformatie mee te kunnen maken. En in principe geldt: des te meer data wordt verzameld, des te meer informatie kan ervan worden gemaakt.

Brondata ophalen (extractie)

De data moet uit de operationele pro­ductiesystemen worden gekopieerd. Dat heet bron-ontsluiting of data-extractie. In de meeste geval­len wordt brondata niet constant, maar periodiek uit de bronsystemen gehaald (maandelijks, wekelijks of dagelijks). Je kunt er wel voor kiezen om elke dataverandering in een bronsysteem direct of achteraf ‘drup­pelend’ (dripfeed) door te laten geven, maar vaak is dit in het begin niet nodig, te complex of te duur.

Als basisregel adviseer ik om de meest elementaire data/feiten op te halen voor in het data warehouse. Anders kom je er op termijn achter dat je initieel onvoldoende ‘granu­lariteit’ in de verzamelde feiten hebt voorzien. Je hebt bijvoorbeeld orders verzameld in plaats van orderregels. Zo gauw een manager bijvoorbeeld job-costing of winstgevendheid per klant wil vaststellen dan moet omzet aan kosten worden gekoppeld. Omdat die gegevens veelal pas op het meest elementaire feitenniveau (orderregel) bij elkaar komen, is er vaak sprake van te weinig granulariteit in het data warehouse. Als je daar pas achter ­komt na een aantal jaren, dan loop je niet alleen het risico van de kosten voor het bij­bouwen van een extra data ontsluiting, maar ook van de kans dat de historische gegevens misschien niet meer in de produc­tiesystemen aanwezig zijn.

Meestal is het zo als je toch een bronsysteem moet ontsluiten, dat je het dan gelijk min of meer compleet doet. Met andere woorden: haal dan gelijk alle feiten op die het bronsysteem beheert.

Operational Data Store of Data Lake?

Normaal gesproken kopieer je brongegevens uit een bronsysteem naar de BI-omgeving. Daar sla je de gegevens op in een ‘Operational Data Store (ODS)’. Dit is een tijdelijke opslag, waarin de brondata wacht op verwerking in het data warehouse. Zo’n Operational Data Store kom je tegenwoordig vaak tegen als ‘Data Lake’ (of ‘Data Integratie Hub’) als de verzamelde data niet alleen voor de BI-omgeving word gebruikt, maar voor hergebruik door de hele organisatie. In een dergelijk ‘data lake’ wordt vaak ongestructureerde data opgeslagen.

Fouten in de brondata

Voordat je de brondata kan ver­werken moet het vaak nog worden schoongemaakt (‘cleansing’). Foutjes die syntactisch van aard zijn (gege­vens die niet voldoen aan een vooraf afgesproken formaat), kun je nog voordat de data het ODS in gaat, herstellen. Ook kun je data in een standaard syntax brengen, zoals bijvoorbeeld bij gegevens rond datum, geslacht, afstand, gewicht of temperatuur. Als er niet automatisch een duide­lijke correctie mogelijk is, dan wordt de datalevering afgekeurd en moet de beheerder van het bronsysteem worden benaderd om een set met ver­beterde gegevens aan te leveren.

Fouten in de brondata die inhoudelijk van aard zijn (semantisch), kunnen niet goed worden hersteld door de BI-omgeving. Denk bij­voorbeeld aan een aangeleverde order waarbij een niet-bestaande klant staat aangegeven. In dat geval zie je pas bij de integratie van brongegevens dat de relatie tussen de order en de klant niet kan worden gelegd. Soms kun je zelfs helemaal niet constateren dat een gegeven fout is, zoals bijvoorbeeld bij een order met een verkeerd bedrag.

Tijdens de ontwikkeling van een data-ontsluiting, maar ook tijdens de daadwerkelijke periodieke dataleveringen daaropvolgend, kan een ‘data profiling’ tool erg behulpzaam zijn om syntactische en semantische fouten vroegtijdig op te sporen.

Service Level Agreement

Als niet herstelbare fouten in de brondata geconstateerd worden, moet je contact opnemen met de partij die verantwoordelijk is voor de levering. Dat is meestal een gesprek tussen een functio­neel- of applicatiebeheerder van het bronsysteem. Fouten in brondata treden bijna onvermijdelijk met enige regelmaat op in elke BI-omgeving. Het is dan ook verstandig om een Service Level Agreement (‘SLA’) met de bron­data-leveranciers op te stellen, zodat incidenten, changes, aanspreekpun­ten en escalatie goed zijn geborgd in procedures.

Navolgbare data

Uitgebreidere BI-omgevingen bevatten allerlei tools om de data door het verwerkingsproces te volgen (tracking & tracing op basis van meta-data). Deze methoden dragen sterk bij aan het vertrouwen van de managers in de BI-om­geving en de daarbinnen gemaakte managementinformatie. En dat ver­trouwen is van cruciaal belang voor de business case van de BI-omgeving.

Het volgende blog uit de reeks gaat specifiek over data-integratie: ‘Business Intelligence voor Managers, Need-to-know #3: Data-integratie is het kernprobleem’. Een verdere uitleg over brondata en de ontsluiting ervan vind je in het gratis eBook ‘de 10 Need-to-Know’s rond BI voor de manager’. Als je op de hoogte wilt blijven wanneer de volgende blog in deze reeks verschijnt, dan kun je je hier abonneren op het thema ‘Management & BI’.

Ebook Business Intelligence 'De 10 Need to Knows rond BI'