Een dashboard begint niet met data

Delta Trading B.V. heeft de afgelopen jaren flink geïnvesteerd in data.

Finance heeft dashboards. Sales heeft dashboards. Operations heeft dashboards. Het management heeft een overzicht met de belangrijkste KPI’s en verschillende medewerkers hebben daarnaast rapportages laten bouwen voor hun eigen informatiebehoefte.

Op het eerste gezicht klinkt dat als een organisatie die haar informatievoorziening goed op orde heeft.

Tot iemand tijdens een overleg vraagt hoeveel omzet er deze maand is gerealiseerd.

Sales opent een dashboard. Finance opent een ander dashboard. De bedragen verschillen.

Niet enorm. Maar genoeg om de discussie te laten verschuiven van de ontwikkeling van de omzet naar de vraag: welk cijfer klopt eigenlijk?

En dat is niet het enige probleem. Sommige dashboards worden nauwelijks nog geopend. Andere bevatten inmiddels zoveel KPI’s, filters en grafieken dat gebruikers vooral moeten zoeken naar het cijfer waarvoor het dashboard ooit is gebouwd. Voor bepaalde vragen bestaan meerdere dashboards die ongeveer hetzelfde proberen te laten zien.

Ondertussen staat er alweer een nieuw verzoek bij BI. Sales wil een dashboard met omzet, marge, orderintake, gemiddelde orderwaarde, omzet per klant, omzet per verkoper en omzet per productgroep.

De vraag lijkt eenvoudig: kunnen we dit bouwen?

Maar dat is waarschijnlijk niet de vraag waarmee je moet beginnen. De betere vraag is: waarom hebben we dit nodig?

Het dashboard is niet het startpunt

Een dashboardverzoek begint vaak met een lijst van wat iemand wil zien. Omzet per verkoper. Brutowinst erbij. Filteren op productgroep. En als we toch bezig zijn ook de openstaande offertes.

Geen van die verzoeken hoeft onlogisch te zijn. Maar een lijst met gewenste cijfers is nog geen goede informatiebehoefte.

Stel dat de oorspronkelijke vraag van Sales bij Delta Trading eigenlijk deze is: we willen gedurende de maand eerder zien waarom onze orderintake achterblijft ten opzichte van vorig jaar.

Dat is een compleet andere manier van beginnen. Misschien is omzet per productgroep relevant om die vraag te beantwoorden. Misschien is omzet per verkoper relevant. Misschien heb je beide helemaal niet nodig.

Als je direct begint te bouwen, sla je het belangrijkste gesprek over: welk probleem proberen we eigenlijk op te lossen?

Een half uur goed doorvragen aan het begin kan tientallen uren bouwen en aanpassen aan het einde voorkomen.

Mensen weten niet altijd wat ze nodig hebben

Dat klinkt misschien vreemd. De medewerker die dagelijks met een proces werkt, weet toch zelf het beste welke informatie hij nodig heeft?

De business moet inderdaad eigenaar zijn van de informatiebehoefte. Maar dat betekent niet dat de eerste oplossing die iemand voorstelt ook meteen de juiste is.

Mensen denken snel vanuit wat op dat moment handig lijkt. Een verkoper vraagt om omzet per klant. Vervolgens bedenkt iemand dat brutomarge ook interessant is. Een manager wil kunnen filteren op productgroep. Daarna komt omzet per land erbij. Een week later blijkt een vergelijking met vorig jaar handig. En een maand later wil iemand ook de openstaande offertes zien.

Iedere toevoeging afzonderlijk is te verdedigen. Maar na twintig of dertig wijzigingen kan een dashboard iets heel anders zijn geworden dan waarvoor het oorspronkelijk werd gebouwd.

Dan is niet alleen ontwikkeltijd verloren gegaan. Het oorspronkelijke doel is ook vertroebeld.

Daarom moet BI niet alleen vragen wat iemand wil zien, maar vooral waarom iemand dit wil weten.

Interessant is niet hetzelfde als relevant

Hierdoor lopen veel dashboards langzaam vol. Het dashboard begint met vijf KPI’s. Bij het eerste gebruik ontstaat wens nummer zes. Daarna komt nummer zeven. En acht. Een jaar later staan er 25 KPI’s op het scherm.

Niet omdat iemand ooit heeft vastgesteld dat er 25 indicatoren nodig zijn om één vraag goed te beantwoorden. Maar omdat iedere toevoeging afzonderlijk nuttig leek.

Iedere extra KPI concurreert om aandacht met de informatie waarvoor het dashboard oorspronkelijk is gemaakt. Meer informatie kan daardoor juist leiden tot minder inzicht.

Hoe simpeler het dashboard kan blijven zonder zijn doel te verliezen, hoe beter. Niet omdat minimalisme mooier is. Maar omdat focus functioneel is.

Datakwaliteit is geen absoluut percentage

Daarmee komen we bij een ander veelgehoord uitgangspunt: een dashboard moet 100% kloppen. Dat klinkt logisch. Maar ook hier ontbreekt een vraag: waarvoor gebruiken we het dashboard?

Stel dat Finance bij Delta Trading een dashboard gebruikt om de volledigheid van de omzetregistratie te controleren. In werkelijkheid zijn er 1.000 transacties. Het dashboard toont er 980. Dan is 98% betrouwbaarheid niet bijna goed genoeg. Het dashboard faalt gewoon in zijn functie.

Maar neem nu Sales. Sales gebruikt een dashboard om gedurende de maand te volgen hoe de orderintake zich ontwikkelt ten opzichte van dezelfde periode vorig jaar. Door een technisch probleem worden enkele orders tijdelijk verkeerd toegewezen. De algemene trend blijft correct zichtbaar.

Dan kan diezelfde 98% voor deze specifieke toepassing mogelijk prima bruikbaar zijn. Dezelfde datakwaliteit. Een compleet andere conclusie.

Dat betekent niet dat slechte data ineens acceptabel is. Het betekent dat je moet begrijpen hoeveel nauwkeurigheid nodig is om een bepaalde beslissing verantwoord te kunnen nemen. Voor een financiële volledigheidscontrole kan de laatste 2% essentieel zijn. Voor een commerciële trendanalyse misschien niet.

Garbage in, garbage out

Dat maakt betrouwbaarheid niet minder belangrijk. Integendeel.

Een dashboard kan er perfect uitzien, automatisch verversen en binnen een seconde laden. Als de onderliggende data niet betrouwbaar genoeg is voor het doel waarvoor het wordt gebruikt, heb je vooral een efficiënte manier gebouwd om verkeerde informatie te verspreiden.

Garbage in, garbage out.

En zodra gebruikers een paar keer ontdekken dat een cijfer niet klopt, ontstaat een tweede probleem. Vertrouwen verdwijnt.

Sales opent het dashboard, maar controleert het getal voor de zekerheid nog even in Excel. Finance exporteert de gegevens en maakt een eigen aansluiting. Operations houdt daarnaast een handmatige lijst bij.

Technisch gezien heeft de organisatie één centrale informatievoorziening. In de praktijk controleert iedereen hem opnieuw. Dan heb je niet alleen een dataprobleem. Je hebt een vertrouwensprobleem.

Realtime is geen kwaliteitskenmerk

Ook het woord realtime heeft een bijzondere aantrekkingskracht. “Kunnen we dit realtime maken?” klinkt bijna automatisch als een verbetering.

Maar ook daar hoort dezelfde vraag achter: waarom?

Stel dat Delta Trading een operationeel dashboard gebruikt om orders te signaleren die vastlopen en dezelfde dag nog moeten worden vrijgegeven. Dan kan zeer actuele informatie noodzakelijk zijn.

Maar stel dat een manager iedere vrijdagmiddag naar een trend kijkt en op basis daarvan acties voor de volgende week bepaalt. Wat is dan de waarde van data die iedere minuut wordt bijgewerkt? Waarschijnlijk beperkt.

Terwijl realtime verwerking wel extra eisen kan stellen aan databronnen, koppelingen, foutafhandeling en beheer.

De vraag is dus niet hoe actueel we het kunnen maken, maar hoe actueel deze informatie moet zijn om de vraag goed te beantwoorden.

Niet alles wat je visualiseert is een dashboard

Hier ontstaat regelmatig begripsverwarring. Een maandelijkse managementrapportage wordt niet ineens een dashboard omdat de cijfers in Power BI, Zoho Analytics of een andere BI-oplossing staan.

Een managementrapportage heeft een andere functie. Daar wil je bijvoorbeeld antwoord op krijgen: hoe hebben omzet en marge zich ontwikkeld? Waarom wijken kosten af van budget? Welke gebeurtenissen hebben het resultaat beïnvloed? Welke risico’s zijn ontstaan? En welke acties volgen daaruit?

Daar horen analyse, interpretatie en context bij.

Een dashboard heeft een andere rol. Het maakt actuele informatie beschikbaar over een vraag die je gedurende een periode wilt kunnen volgen.

Die grens is niet in iedere situatie absoluut. Maar het onderscheid helpt wel om te voorkomen dat ieder rapport met een grafiek ineens een dashboard wordt genoemd.

De business bepaalt de vraag. Niet iedereen bouwt de oplossing

Terug naar Delta Trading. Sales heeft een eigen omzetdashboard. Finance ook. Operations heeft omzet daarnaast opgenomen in een operationele rapportage. Tijdens het managementoverleg blijken de bedragen opnieuw af te wijken.

Sales kijkt naar orderdatum. Finance gebruikt factuurdatum. Operations kijkt naar de datum waarop de order operationeel is verwerkt. Alle drie kunnen intern logisch zijn. Maar iedereen denkt dat hij over omzet praat.

Daarmee ontstaat een risico van ongecontroleerde self-service BI. De oplossing is niet dat de business geen dashboards meer mag aanvragen. Integendeel. De business moet eigenaar blijven van de informatievraag.

Een Sales Manager weet veel beter dan BI welke commerciële informatie nodig is om zijn team aan te sturen. Maar er moet wel centrale regie zijn over de manier waarop die behoefte wordt vertaald naar een dashboard.

Een centrale BI-functie kan vóór ontwikkeling vragen: bestaat deze informatie al? Overlapt de vraag met een bestaand dashboard? Welke databron gebruiken we? Welke definitie is leidend? Hoe betrouwbaar moet de informatie zijn? Hoe actueel moet ze zijn? En is een nieuw dashboard werkelijk de beste oplossing?

Dat is geen centrale afdeling die voor iedereen bepaalt wat ze mogen weten. Het is governance.

Vijf dashboards voor dezelfde vraag

Die regie wordt steeds belangrijker wanneer een organisatie groeit. Stel dat Delta Trading inmiddels 100 dashboards heeft.

De eerste reflex kan zijn om te kijken welke technisch verouderd zijn, welke sneller moeten of welke datasets kunnen worden gemoderniseerd. Maar ik zou ergens anders beginnen.

Bij ieder dashboard dezelfde twee vragen: waarom bestaat dit en welke behoefte lost het op?

De kans is groot dat daar overlap zichtbaar wordt. Misschien blijken vijf dashboards ongeveer dezelfde commerciële informatiebehoefte te bedienen. Niet omdat Delta vijf verschillende vragen heeft. Maar omdat dezelfde vraag op vijf momenten door vijf verschillende mensen opnieuw is vertaald naar een oplossing.

Dat betekent dubbel ontwikkelwerk, meerdere definities, meer onderhoud, meer kans op afwijkende cijfers en uiteindelijk gebruikers die niet meer weten welk dashboard leidend is.

Dashboardwildgroei ontstaat dus niet noodzakelijk omdat een bedrijf te veel informatie nodig heeft. Het kan ook ontstaan doordat dezelfde informatiebehoefte steeds opnieuw wordt opgelost.

Dat mechanisme lijkt op wat breder in organisaties gebeurt wanneer professionalisering langzaam verandert in extra lagen en dubbel werk.

Wat kost dashboardwildgroei?

Maak het concreet. Stel dat Delta Trading in een jaar tien nieuwe dashboards laat bouwen.

Voor dit rekenvoorbeeld gaan we ervan uit dat inventarisatie, ontwikkeling, testen en de eerste aanpassingen gemiddeld 40 uur per dashboard kosten. Dat is geen algemene benchmark. Het is simpelweg de aanname voor deze Delta Trading-case.

Een jaar later wordt het gebruik geëvalueerd. Drie dashboards worden nauwelijks nog geopend of blijken grotendeels dezelfde informatie te tonen als een ander dashboard.

Het interessante getal is niet die 120 uur op zichzelf. Misschien kon vooraf ook helemaal niet worden voorzien dat alle drie dashboards hun waarde zouden verliezen.

Maar als een deel daarvan voorkomen had kunnen worden door vóór ontwikkeling scherper naar de informatiebehoefte te kijken, zit daar directe capaciteit. Het is dezelfde reden waarom je bij procesverbetering eerst wilt weten waar de tijd en het geld werkelijk verdwijnen.

Een dashboard dat niemand gebruikt

Er is nog een signaal dat serieus genomen moet worden: gebruik.

Stel dat BI weken aan een dashboard heeft gewerkt. De data klopt. De vormgeving is goed. Alle gevraagde filters zitten erin. Na de lancering blijkt vrijwel niemand het te openen.

De eerste reactie is vaak: we hebben een adoptieprobleem. Misschien moeten gebruikers worden getraind. Misschien moet het dashboard gebruiksvriendelijker. Misschien moet management mensen stimuleren het vaker te gebruiken.

Dat kan terecht zijn. Maar er is nog een andere mogelijkheid. Misschien had het dashboard nooit gebouwd moeten worden.

Als de informatiebehoefte vooraf niet scherp genoeg is onderzocht, kan een technisch perfect dashboard nog steeds antwoord geven op een vraag die nauwelijks iemand heeft. Dat is geen adoptieprobleem. Dat is een probleem dat vóór de ontwikkeling al bestond.

Dashboards hebben geen permanent bestaansrecht

Ook een dashboard dat vandaag veel waarde toevoegt, hoeft dat over drie jaar niet meer te doen. Bedrijven veranderen. Processen veranderen. Systemen veranderen. Mensen wisselen van functie. Nieuwe informatiebehoeften ontstaan. Oude verdwijnen.

Toch blijven dashboards vaak bestaan. Ze zijn ooit gebouwd, dus worden ze onderhouden. Daarmee ontstaat langzaam een digitaal archief van historische informatievragen.

Dat kost beheer en maakt het voor gebruikers steeds moeilijker om te bepalen welk dashboard ze moeten hebben. Daarom hoort bij volwassen BI ook iets wat misschien minder aantrekkelijk klinkt dan nieuwe dashboards bouwen: verwijderen.

Periodiek moet bij bestaande dashboards opnieuw dezelfde vraag worden gesteld waarmee het ooit begon: welke behoefte lost dit vandaag nog op?

Is daar geen duidelijk antwoord meer op? Wordt het nauwelijks gebruikt? Bestaat inmiddels een ander dashboard dat hetzelfde beter doet? Dan kan verwijderen een betere beslissing zijn dan aanpassen.

De ontwikkeltijd die er ooit in is gestoken, hoort daarbij geen argument te zijn.

De Dashboard Start Check

Hoe voorkom je bij Delta Trading dat ieder informatieverzoek automatisch een nieuw dashboard wordt? Niet met een zwaar aanvraagproces. Begin met een korte check voordat BI gaat bouwen.

De beste dashboardvraag komt vóór het dashboard

Veel organisaties beginnen hun datavraagstuk bij technologie. Welke BI-tool gebruiken we? Welke databronnen kunnen we koppelen? Welke KPI’s kunnen we tonen? Kunnen we alles realtime maken?

Maar technologie wordt pas interessant als duidelijk is welke informatie iemand nodig heeft en waarom. Een dashboard is geen doel. Het is een antwoord op een bedrijfsbehoefte.

Soms vraagt die behoefte om vijf KPI’s die vrijwel realtime beschikbaar zijn. Soms om één trend die iedere nacht wordt bijgewerkt. Soms moet de data volledig aansluiten op de financiële administratie. En soms is iets minder precisie voldoende om een ontwikkeling vroeg genoeg te herkennen.

Er bestaat daarom geen universeel perfect dashboard. Er bestaat alleen een dashboard dat wel of niet geschikt is voor de vraag waarvoor het is gemaakt.

Voor Delta Trading betekent dat dat het volgende dashboardverzoek misschien niet meer begint met: “Kunnen jullie deze acht KPI’s toevoegen?” Maar met: “We willen gedurende de maand eerder begrijpen waarom onze orderintake achterblijft.”

Dat lijkt een klein verschil. Voor BI is het een wereld van verschil. Want vanaf dat moment bouw je niet meer simpelweg wat iemand vraagt. Je probeert eerst te begrijpen waarom diegene het vraagt.

En precies daar begint een goed dashboard. Niet bij de data. Bij de vraag.

Bronnen en methodiek

Delta Trading B.V. is fictief. De situaties, aantallen dashboards en ontwikkeluren in dit artikel zijn illustratief en bedoeld om de afweging rond dashboardontwikkeling concreet te maken.

De genoemde 40 ontwikkeluren per dashboard zijn nadrukkelijk geen benchmark. De werkelijke ontwikkeltijd kan sterk verschillen afhankelijk van databronnen, datakwaliteit, complexiteit, integraties en gewenste functionaliteit.

Het uitgangspunt van dit artikel is organisatorisch: een informatiebehoefte hoort de aanleiding te zijn voor een dashboard, niet de beschikbaarheid van data of technologie.