Dashboards: datamodel en ontwerpkeuzes (deel 2/4)

16 september 2021

Artikel geschreven door Nieck de Groot en Wouter van Gils

In het eerste artikel van dit vierluik zijn we ingegaan op wanneer een dashboard dé oplossing is voor jouw informatiebehoefte. Als het goed is weet je nu waar een dashboard aan moet voldoen om te zorgen dat je de juiste inzichten uit de data haalt zodat je betere beslissingen kunt nemen.

De volgende stap is het vertalen van jouw informatiebehoefte naar concrete KPI’s en bepalen welke data nodig is om de voortgang op deze KPI’s te meten. In het vorige artikel verwezen we naar een voorbeeld van een manager die 20% omzetgroei ten opzichte van het vorige jaar wil realiseren. De KPI is hier 20% omzetgroei, de dimensie waartegen je dit wilt afzetten is tijd. In het dashboard wil je de drivers voor deze KPI kunnen monitoren, bijvoorbeeld in de vorm van het aantal nieuwe klanten en hun gemiddelde orderwaarde. En dit is maar één voorbeeld.

Zorg ervoor dat je input van alle belangrijke stakeholders hebt voordat je aan het datamodel begint. Onze tip: start met een schets van je eindproduct. Wat ons betreft een stap die wordt onderschat en veel impact heeft op het eindresultaat. Welke informatie ga je tonen, waar precies, met welke visualisaties? Een schets helpt je om te bepalen welke eisen je stelt aan het ontwerp van je datamodel. Welke informatie heb ik precies nodig om deze schets te realiseren en hoe kan ik zien of de KPI positief of negatief is?

Waarom is een datamodel belangrijk voor de ontwikkeling van een dashboard?

De opbouw van een datamodel start met het matchen van de informatiebehoefte naar beschikbare kolommen in je brondata. Dit vergt vaak flink wat werk, de meeste brondata is niet meteen geschikt om gebruikt te worden in een rapportage. Het uitdenken van een datamodel dwingt je om na te denken over logische relaties tussen entiteiten en unieke sleutels. Met dit ontwerp ben je later in staat om een kwaliteitscontrole te doen. De voorwaarden waar een gedegen datamodel wat ons betreft aan moet voldoen zijn als volgt:

1. Het datamodel moet alle data bevatten die nodig is om de KPI’s te berekenen en te kunnen afzetten tegen de gewenste dimensies, vooral niet méér (zwaarder qua performance) en uiteraard niet minder (onvoldoende inzicht in de data om besluiten te kunnen nemen). Onze ervaring is dat de integratie van targets ook niet zonder slag of stoot gaat. Deze gegevens zijn vaak niet aanwezig in een datawarehouse of niet op alle niveaus beschikbaar. Neem deze dus op in je datamodel en bespreek met je opdrachtgever wie verantwoordelijk is voor de levering van gegevens
2. Het detailniveau moet aansluiten bij de initiële vraag:
   1. Willen stakeholders maandelijks, wekelijks of zelfs dagelijks kunnen monitoren? En tot hoe ver terug in de tijd?
   2. Welke diepte van inzicht is nodig om de organisatie bij te kunnen sturen? Is dat op winkelniveau, (sub)productgroep / merk en welke klantgroepen moeten gemonitord worden? Let hierbij ook op het volume van de data dat snel kan toenemen bij een hoog detailniveau, lange historie of uitbreiding van het aantal bronsystemen.
3. De robuustheid van het model bepaalt de performance, de kosten en het gebruiksgemak en daarmee adoptie binnen de organisatie. Vaak kiest men voor een STER-model, een multi-dimensionele modelleringstechniek waarbij er één of meerdere feitentabellen zijn met daaromheen de dimensie-tabellen die efficiënt de informatie over de feiten opslaan. Deze vorm is populair omdat er veel data op een snelle manier opgevraagd kan worden in de dashboards die erop gebaseerd zijn.

Als je deze criteria hanteert en afweegt tegen de vraag/informatiebehoefte, krijgt de data vanzelf de vereiste vorm voor maximale flexibiliteit voor het creëren van inzichten vs. optimalisatie voor performance. Het uitdenken van het datamodel krijgt echter over het algemeen te weinig aandacht. Drie veel voorkomende redenen hiervoor zijn:

1. Tijd: je hebt de inzichten nú (lees: gisteren) nodig en vaak is er weinig tijd of onvoldoende expertise aanwezig om gestructureerd aan BI/Reporting te werken.
2. Te magere Minimum Viable Products (MVP): het dashboard begint als een idee op basis van een aantal losse bestanden en naarmate de eerste inzichten goed ontvangen worden bouwt men hierop verder zonder eerst de data goed in te richten voor grootschalig gebruik.
3. Veel dashboarding software kan direct data onttrekken aan front-end applicaties zonder tussenkomst van een DWH. Je kunt vaak een volledig datamodel uit de bron importeren, waardoor je niet gedwongen wordt na te denken over een datamodel dat past bij jouw vraagstuk. Visualiseren van een enkelvoudige bron is nog wel te doen, integratie van meerdere bronnen binnen je visualisatietool is niet aan te raden. Zo is er geen standaardisatie tussen de bronnen, haal je vaak veel te veel data binnen en ben je afhankelijk van wijzigingen in het datamodel van de bron.

Onvoldoende aandacht besteden aan het datamodel en de verversingstermijn van gegevens kan later in het proces niet alleen een grote impact op de performance of adoptie van je dashboard hebben (niemand gebruikt een traag of gedateerd dashboard), maar ook op de totale tijdsinvestering. Een inefficiënt dashboard vergt veel tijd in onderhoud en leidt geregeld tot aanpassing van het datamodel en het dashboard. Kortom, te laat starten met een datamodel leidt onherroepelijk tot extra werk.

Wie schrijft die blijft

De opbouw van de KPI’s en dimensies en (meta-)data die daarmee gemoeid is, moeten goed gedocumenteerd en bijgehouden worden. Zowel eindgebruikers als beheerders waarderen het als de oorsprong van de data en de berekeningen gedocumenteerd zijn. Wijzigingen worden vaak in een andere hoek van de organisatie gedaan (bijvoorbeeld product development) en het is belangrijk dat er procesafspraken gemaakt worden over het aankondigen, interpreteren en implementeren van deze wijzigingen door de data-keten heen (van bronsysteem, naar BI-team, naar eindgebruikers). Documenteren kan natuurlijk in PowerPoint, Word of Excel maar ook tools als Confluence en Microsoft Data Catalog zijn hier erg voor geschikt.

Met de punten van dit artikel in het achterhoofd is de kans groot dat je komt tot een solide datamodel als basis voor de visualisaties in je dashboards. Het datamodel bevat namelijk alle data die nodig is om aan de vraag te voldoen, is geaggregeerd op het gewenste detailniveau en transparant opgebouwd wat het overzichtelijk houdt voor alle stakeholders. Daarnaast is er op gelet dat de impact op de systemen en daarmee gepaarde kosten, zo laag mogelijk gehouden wordt.

Stay tuned!

In het volgende artikel van deze reeks gaan we in op de datavisualisatie en het gebruiksgemak van een dashboard. Mocht je meer willen weten over specifieke onderwerpen van dit artikel of de meer technische kant van het data modelleringsproces, laat dan een bericht achter of neem contact met ons op.

Lees deel 3 over visualisatie en bruikbaarheid >

Wil je op de hoogte blijven van onze volgende artikelen over dit onderwerp? Volg ons via LinkedIn of schrijf je in voor onze nieuwsbrief.

Blijft op de hoogte >