De vraag die je stelt voor je een dashboard bouwt

De meeste dashboards beginnen met dezelfde vraag: welke cijfers wil je zien?

Het is een logische vraag. Ze is vriendelijk, ze is concreet, en iedereen kan ze beantwoorden. Daarom is ze ook zo gevaarlijk. Het antwoord is altijd een lijst, en een lijst is geen ontwerp. Zo kom je bij vijftig KPI's op het verlanglijstje en uiteindelijk bij het dashboard dat niemand opent.

De vraag die wel werkt, is een andere. En het gesprek eromheen is het belangrijkste halfuur van elk project.

De verkeerde vraag

"Welke cijfers wil je zien?" nodigt uit tot opsommen. De gesprekspartner denkt aan wat hij vandaag in Excel heeft, aan wat hij ooit in een ander bedrijf zag, en aan wat professioneel klinkt. Omzet, marge, EBITDA, klanttevredenheid, voorraadrotatie.

Niets daarvan is fout. Maar niets daarvan zegt wat hij ermee gaat doen. En zonder dat weet je niet hoe je het moet tonen, met wat je het moet vergelijken, hoe vaak het moet verversen, of het überhaupt op een scherm hoort.

Omzet als cijfer is geen antwoord. Omzet tegenover vorig jaar per week, omdat je elke maandag beslist of je extra personeel inplant voor het weekend, dat is een antwoord. Het is hetzelfde cijfer, maar een totaal andere pagina.

De juiste vraag

De vraag die ik stel, is deze: welke beslissing neem je hiermee, en wanneer?

Die vraag dwingt drie dingen af.

• Een beslissing. Als er geen beslissing aan hangt, is het context. Mag, maar hoort niet vooraan.
• Een moment. Beslis je dagelijks, wekelijks, maandelijks? Dat bepaalt hoe vaak het rapport moet verversen en hoe het eruit moet zien. Een dagelijkse beslissing verdraagt geen trage pagina.
• Een persoon. Wie neemt die beslissing? Dat is de eigenaar van de pagina.

Soms is het antwoord: "Eigenlijk beslis ik daar niets mee, ik wil het gewoon weten." Dat is een eerlijk antwoord, en een nuttig. Het zegt dat dit cijfer niet bovenaan hoort.

Hoe het gesprek eruitziet

Ik begin niet met cijfers. Ik begin met de week van de persoon tegenover mij.

Wat doe je op maandagochtend? Welke beslissingen neem je die week? Welke daarvan neem je op gevoel, omdat de cijfers niet op tijd zijn of te veel werk vragen? Waar heb je achteraf spijt van gehad omdat je iets te laat zag?

Uit die antwoorden komen de beslissingen. Pas daarna vraag ik welke informatie daarbij zou helpen. En dan komen de cijfers vanzelf, maar met hun context erbij: met wat ze vergeleken moeten worden, hoe gedetailleerd, en hoe snel.

Een voorbeeld uit de retail, waar ik zelf vijfentwintig jaar gestaan heb. Een zaakvoerder zegt dat hij de omzet per winkel wil zien. Vraag je door naar de beslissing, dan blijkt dat hij elke week beslist hoeveel uren hij per winkel inplant. Dan is omzet per winkel niet genoeg. Hij heeft omzet per uur nodig, per winkel, per dag van de week, met de passage erbij. Dat is een ander dashboard dan "omzet per winkel".

Vijf vragen die altijd terugkomen

Na de beslissing volgen een paar vragen die de meeste ontwerpkeuzes vastleggen. Ik stel ze bijna altijd.

1. Waarmee vergelijk je het? Een cijfer alleen zegt niets. Tegenover vorig jaar, tegenover budget, tegenover een andere vestiging, tegenover een drempel? Elk antwoord geeft een andere grafiek. En let op: je ERP bewaart geen budget, dus als het budget is, moet dat ergens vandaan komen.

2. Wat is normaal? Als het cijfer tien procent lager staat, is dat dan alarm of ruis? Het antwoord bepaalt of je een signaal nodig hebt en waar de drempel ligt.

3. Wat doe je als het afwijkt? Bel je iemand, bestel je iets, pas je iets aan? Als het antwoord "dan zoek ik uit waarom" is, dan moet de pagina dat uitzoeken makkelijk maken. Dan heb je een doorklik naar detail nodig.

4. Wie kijkt er nog naar? Als de verkoopploeg dezelfde cijfers ziet, moet de pagina ook voor hen leesbaar zijn. En moeten ze alles zien? Dat is een vraag voor wie mag wat zien.

5. Wat betekent het woord precies? Omzet met of zonder btw, met of zonder retours, op factuurdatum of leverdatum? Dit is de vraag waar het meest tijd in gaat, en het meest tijd mee gewonnen wordt. Zie als drie mensen drie antwoorden geven.

De vraag die je niet mag vergeten

Er is nog één vraag, en die wordt het vaakst overgeslagen: welke vraag kan je vandaag niet beantwoorden?

Alle vorige vragen gaan over wat er al is. Deze gaat over wat ontbreekt. En daar zit vaak de grootste waarde.

Een zaakvoerder die niet weet waarom zijn omzet daalde, omdat hij geen passage meet. Een aannemer die niet weet hoeveel tijd er tussen offerte en start zit, omdat niemand dat bijhoudt. Een dienstverlener die niet weet welke klant hem geld kost, omdat de uren niet per klant geregistreerd worden.

Die antwoorden komen niet uit het ERP. Soms moeten ze eerst gebouwd worden. Maar als je de vraag niet stelt, komt het antwoord nooit op tafel.

Wat je vermijdt

Een paar dingen gaan bijna altijd mis als je deze stap overslaat.

Iedereen tegelijk interviewen. In een groep praat de luidste, en de rest knikt. Spreek met de beslissers apart, en breng de antwoorden daarna samen. Wie iedereen tegelijk vraagt, krijgt een compromis.

Het gesprek houden met wie het rapport niet gebruikt. Soms wordt een dashboard besteld door een directeur voor een afdeling. Dan moet je ook met de afdeling praten. De directeur weet wat hij wil zien, maar niet altijd wat zijn mensen nodig hebben om het te laten gebeuren.

Oplossingen laten voorstellen. "Ik wil een taartgrafiek met de omzet per kanaal." Neem dat mee als wens, maar vraag wat ermee beslist wordt. Het beste antwoord op die beslissing is zelden een taartgrafiek.

Te snel beginnen bouwen. De verleiding is groot. De data is er, de tools zijn er, en een eerste grafiek staat er in een uur. Maar een uur bouwen aan de verkeerde vraag kost later een dag afbreken.

Waarom dan toch snel een prototype

Dat klinkt als een tegenspraak met hoe wij werken, want wij bouwen snel een prototype. Maar het prototype komt na dit gesprek, niet ervoor.

Het gesprek levert de beslissingen en de definities. Het prototype toont of we het goed begrepen hebben. Mensen weten vaak pas wat ze nodig hebben als ze iets zien, en daarom werkt eerst bouwen beter dan een lang lastenboek. Maar een prototype zonder dit gesprek toont alleen dat je grafieken kan maken.

In de praktijk is het een halfuur tot een uur per beslisser. Daarna bouwen we. Een week later zitten we opnieuw samen met het prototype, en dan is de vraag eenvoudiger: welke beslissing heb je hiermee genomen, en wat miste je daarbij?

Een eenvoudig sjabloon

Voor wie het zelf wil doen: dit is het blad dat ik per pagina invul voor we beginnen.

• Beslissing: wat wordt er beslist met deze pagina?
• Eigenaar: wie beslist?
• Ritme: dagelijks, wekelijks, maandelijks?
• Hoofdcijfer: welk cijfer vertelt of het goed of slecht gaat?
• Vergelijking: waarmee wordt het vergeleken?
• Normaal: wat is een gewone schommeling, wat is alarm?
• Actie: wat gebeurt er als het afwijkt?
• Definities: wat betekent elk woord precies?
• Ontbrekend: welke vraag kunnen we vandaag niet beantwoorden?

Kan je dat blad niet invullen, dan is de pagina nog niet klaar om gebouwd te worden. Dat is geen falen. Het is precies wat het gesprek moest opleveren.

Wat je kan automatiseren

Het gesprek zelf niet. Wel alles erna. De definities die je vastlegt, kan je als beschrijving in het datamodel zetten, zodat ze zichtbaar zijn bij elk cijfer in plaats van in een los document. De drempels uit "wat is normaal" worden automatische signalen. En het gebruik van elke pagina kan je meten, zodat je na een maand ziet of de beslissing waarvoor ze gebouwd werd, er ook mee genomen wordt.

De stelling

Vraag nooit welke cijfers iemand wil zien. Vraag welke beslissing hij neemt, wanneer, en waarmee hij vergelijkt. Het dashboard volgt daaruit, en wat niet volgt uit een beslissing, hoort niet vooraan.