In het kort
Een dashboard laten maken begint niet met grafieken, maar met de beslissingen die je ermee wilt nemen. Leg voor elk getal vast welke vraag het beantwoordt, hoe het precies wordt berekend, uit welke bron het komt, hoe vaak het ververst en wie in actie komt bij een afwijking. Kies daarna pas tussen een standaard BI-tool op je bestaande systemen of een dashboard als onderdeel van maatwerksoftware.
Wat is een dashboard en wanneer laat je er een maken?
Een dashboard is één overzichtsscherm met de cijfers die je regelmatig nodig hebt om je werk te sturen. Microsoft beschrijft een Power BI-dashboard bijvoorbeeld als één pagina die alleen de hoogtepunten toont; voor de details klik je door naar onderliggende rapporten. Die gedachte is ook buiten Power BI bruikbaar. Een dashboard is geen plek om alles te laten zien wat je kunt meten, maar een selectie van wat je vaak moet weten.
Een dashboard laten maken is zinvol wanneer dezelfde vragen steeds terugkomen en het antwoord nu handwerk kost. Denk aan iemand die elke maandag cijfers uit drie systemen in een rekenblad plakt, een planner die belt om te horen hoeveel werk er openstaat, of een directie die pas na de maand ziet dat offertes zijn blijven liggen. Komt een vraag eens per jaar voorbij, dan is een los rapport vaak genoeg.
Bij Softora zien we een dashboard als onderdeel van een werkproces. Het helpt pas als iemand weet wat hij moet doen wanneer een getal verandert. Daarom staat in dit artikel niet de keuze van grafieken centraal, maar de voorbereiding die bepaalt of het dashboard straks gebruikt wordt.
Welke beslissing moet het dashboard ondersteunen?
Schrijf eerst op wie het dashboard gebruikt en welke beslissing die persoon ermee neemt. Een verkoopleider wil weten welke offertes deze week opvolging nodig hebben. Een planner wil zien welke opdrachten volgende week nog geen monteur hebben. Een eigenaar wil per maand zien of omzet en marge op koers liggen. Dat zijn drie verschillende dashboards, ook al kunnen ze uit dezelfde gegevens komen.
Het GOV.UK Service Manual adviseert om metingen af te leiden van het doel van een dienst en ze context te geven: met een uitgangssituatie, ontwikkeling over tijd en waar nodig een opsplitsing naar groepen. Dat is uitleg uit de Britse overheidspraktijk, maar de les geldt ook voor een MKB-bedrijf. Een los getal zegt weinig. Twaalf open offertes is veel of weinig, afhankelijk van wat normaal is en hoe oud ze zijn.
Beperk de eerste versie tot de getallen die een concrete actie uitlokken. Een handige toets is de vraag: wat doen we anders als dit getal stijgt of daalt? Kan niemand daar een antwoord op geven, dan hoort het getal waarschijnlijk in een rapport voor later, niet bovenaan het dashboard.
Sjabloon: de KPI-kaart voor elk getal
Leg ieder getal vast op een eigen kaart voordat iemand gaat bouwen. Een praktische kaart heeft zes velden. Vraag: welke vraag beantwoordt dit getal? Definitie: wat telt precies mee, inclusief datums en statussen? Telt niet mee: welke gevallen sluit je bewust uit? Bron en verversing: uit welk systeem komt het en hoe actueel moet het zijn? Eigenaar: wie bewaakt de definitie en spreekt anderen aan? Actie bij afwijking: wat gebeurt er boven of onder welke grens?
Neem als fictief voorbeeld een installatiebedrijf dat offertes laat liggen. De vraag is welke offertes deze week moeten worden nagebeld. De definitie: verzonden offertes die nog openstaan en ouder zijn dan 14 dagen. Vervallen, gewonnen of verloren offertes tellen niet mee. De bron is de offertemodule, die elke ochtend om 07:00 wordt ververst. Eigenaar is de verkoopleider. Staan er meer dan vijf offertes op de lijst, dan plant het team een belronde.
De kaart dwingt keuzes af die anders pas tijdens de bouw opduiken. Moet het getal elke minuut kloppen of is één keer per dag genoeg? Gaat het om het aantal offertes of om het totale bedrag? Valt een offerte die is aangepast en opnieuw verstuurd terug naar dag nul? Zulke vragen beantwoord je liever in een gesprek van een uur dan in drie bouwrondes.
Rekenvoorbeeld: één getal, twee uitkomsten
Waarom is die definitie zo belangrijk? Stel dat het installatiebedrijf 40 open offertes heeft. Volgens definitie A telt een offerte als te laat wanneer hij langer dan 14 dagen geleden is verstuurd. Dat geldt voor 9 offertes: 9 van 40 is 22,5 procent. Volgens definitie B telt een offerte pas als te laat wanneer er 14 dagen geen contact is geweest. Drie van die negen offertes zijn vorige week nog nagebeld, dus blijven er 6 over: 15 procent.
Beide definities zijn verdedigbaar, maar ze sturen ander gedrag. Definitie A laat zien hoe lang klanten over een beslissing doen. Definitie B laat zien waar het eigen team opvolging vergeet. Wie het dashboard gebruikt om nabellen te plannen, heeft meer aan B. Wie wil weten of offertes te groot of te onduidelijk zijn, kijkt eerder naar A. Zet je de keuze niet op papier, dan bouwt een leverancier een van beide en ontdekt het team pas na weken dat het getal iets anders meet dan gedacht.
Voor definitie B moet de software ook weten wanneer er contact was. Wordt een belletje nu niet vastgelegd, dan bestaat dat gegeven niet en kan geen enkel dashboard het tonen. Zo laat een rekenvoorbeeld meteen zien welke gegevens je proces eerst moet gaan bijhouden.
Waar komen de cijfers vandaan en hoe actueel moeten ze zijn?
Maak een lijst van alle systemen waar de cijfers nu staan: CRM, boekhouding, planning, urenregistratie, webformulieren of losse rekenbladen. Noteer per systeem of je de gegevens kunt exporteren of via een API-koppeling kunt ophalen, wie de beheerder is en welke velden je nodig hebt. Dat bepaalt een groot deel van het werk. Een dashboard dat één nette bron leest, is eenvoudiger dan een dashboard dat vijf systemen met verschillende klantnummers moet samenvoegen.
Spreek daarna per getal af hoe actueel het moet zijn. Eén keer per nacht ophalen is voor een maandoverzicht prima. Voor een werkvoorraad die de hele dag verandert, wil je sneller bijwerken, bijvoorbeeld met een webhook die het dashboard een seintje geeft zodra een status verandert. Sneller is niet automatisch beter: elke extra koppeling moet ook worden bewaakt als die een keer stilvalt.
Controleer tot slot of de brongegevens betrouwbaar zijn. Dubbele klanten, lege statussen en offertes zonder eigenaar verdwijnen niet in een dashboard; ze worden juist zichtbaarder. Soms is het verstandig eerst aan de CRM-datakwaliteit te werken en het dashboard daarna te bouwen. Laat het dashboard in elk geval tonen wanneer de gegevens voor het laatst zijn ververst, zodat niemand op verouderde cijfers stuurt.
Standaard BI-tool of dashboard in maatwerksoftware?
Er zijn grofweg drie routes. Als het dashboard alleen cijfers hoeft te tonen en de bronnen al betrouwbaar te koppelen zijn, is een standaard BI-tool zoals Power BI of Looker Studio vaak een logische keuze. Je betaalt dan vooral voor het inrichten van koppelingen, berekeningen en schermen, en je gebruikt functies die al bestaan.
Zijn de bronnen nog niet goed te koppelen, of staan belangrijke gegevens in losse rekenbladen, dan helpt een mooier scherm weinig. Begin dan met het op orde brengen van de gegevens en de koppelingen. Dat kan betekenen dat een proces eerst in één systeem wordt vastgelegd, of dat een koppeling de gegevens dagelijks samenbrengt in één tabel.
Moet het dashboard ook werk laten vastleggen of starten, dan past een dashboard als onderdeel van maatwerksoftware vaak beter. Denk aan een overzicht waarin een verkoper direct een offerte als nagebeld markeert, of een planningsscherm waarin je een opdracht meteen aan een monteur toewijst. Dan is het dashboard geen los rapport meer, maar het startscherm van een werkproces.
Wie mag wat zien en is het voor iedereen leesbaar?
Een dashboard bundelt gevoelige informatie: omzet per klant, marges of de prestaties van individuele medewerkers. Leg daarom per rol vast welke cijfers iemand mag zien. OWASP adviseert om toegangsrechten bij elk verzoek aan de serverkant te controleren, en niet alleen een knop of tegel te verbergen. Voor een dashboard betekent dat: een monteur die de marges niet mag zien, kan ze ook niet via een export of een rechtstreekse link opvragen.
Let ook op leesbaarheid. Veel dashboards gebruiken alleen rood en groen om goed en slecht te tonen. De toegankelijkheidsrichtlijn WCAG vraagt dat kleur niet het enige middel is om informatie over te brengen. Zet dus ook een tekst, pijl of getal bij een waarschuwing. Dat helpt kleurenblinde collega’s, maar ook iedereen die het dashboard op een telefoon in de zon bekijkt.
Test het dashboard vóór gebruik met een paar bekende situaties. Tel voor één week handmatig na hoeveel offertes volgens de afgesproken definitie te laat zijn en vergelijk dat met het scherm. Controleer ook wat een medewerker zonder rechten ziet. Het stappenplan voor een acceptatietest van software helpt die controles vooraf op te schrijven.
Wat bepaalt de kosten en wat neem je mee naar een leverancier?
De kosten hangen minder af van het aantal grafieken dan van het werk eronder: hoeveel bronnen er gekoppeld worden, hoe schoon die gegevens zijn, hoeveel berekeningen en rollen er nodig zijn en of het dashboard ook handelingen moet ondersteunen. Daarnaast is er doorlopend beheer: koppelingen veranderen, definities worden aangepast en nieuwe vragen komen erbij. Voor een breder beeld van een softwareproject kun je de uitleg over de kosten van bedrijfssoftware laten maken lezen.
Neem naar een eerste gesprek mee: de gebruikers en hun beslissingen, een ingevulde KPI-kaart voor de drie belangrijkste getallen, een lijst van bronnen met beheerders, de gewenste actualiteit en de rollen met hun rechten. Moet het dashboard ook werk ondersteunen, beschrijf die handelingen dan zoals in een functioneel ontwerp. Met dat pakket kan een leverancier gericht inschatten wat er nodig is.
Wil je een dashboard op maat laten maken dat aansluit op je CRM, planning of offerteproces, dan kijkt Softora bij bedrijfssoftware op maat eerst naar die KPI-kaarten en bronnen. Zo wordt vooraf duidelijk welke route past: een standaard BI-tool, eerst een koppeling, of een overzicht als onderdeel van je eigen systeem.
Over deze uitleg
Dit artikel is door Softora met hulp van AI opgesteld en gecontroleerd aan de genoemde openbare bronnen. Het installatiebedrijf, de offertes, de aantallen en de afspraken op de KPI-kaart zijn fictief en dienen alleen als uitleg. De illustraties zijn eigen vectorbeelden voor dit artikel, met hulp van code gemaakt; het zijn geen schermopnamen of klantresultaten. Power BI en Looker Studio worden genoemd als voorbeelden van bestaande tools, zonder voorkeur of samenwerking.
