Analyseplan maken: een praktisch format vóór je begint (2026)

Een analyseplan voorkomt dat je halverwege van vraag, definitie of bron wisselt zonder dat iemand het merkt. Leg het plan vast vóór je data combineert of een dashboard bouwt.

Stappenplan: tien vaste onderdelen

1. Doel en beslissing: wat moet de lezer hiermee kunnen doen?
2. Vraag: welke populatie, periode en vergelijking horen erbij?
3. Gebruiker: wie leest en wie handelt?
4. Bronnen: eigenaar, exportdatum en bekende beperkingen.
5. Definities: KPI's, statussen, eenheden en sleutels.
6. Methode: berekening, filter en uitsplitsing.
7. Privacy: minimale velden en toegangsrollen, volgens de uitleg van de Autoriteit Persoonsgegevens over verantwoordingsplicht, privacy by design en dataminimalisatie.
8. Kwaliteitschecks: wat blokkeert een conclusie?
9. Uitkomst: tabel, grafiek of besluitnotitie.
10. Eigenaar: wie bevestigt inhoud en onderhoud?

Maak je KPI's expliciet met KPI-definities, controleer bronnen met de datakwaliteitschecks en lees eerst wat data-analyse is.

Controleerbaar voorbeeld

Vraag: "Welke regio heeft in mei de meeste onafgeronde serviceverzoeken?" Bron: ticketsysteemexport van 1 juni. Definitie onafgerond: status open of wachtend, niet gesloten. Controle: steekproef van vijf records met de bron. Eigenaar: servicemanager. Dit plan laat zien wat het antwoord wel en niet zegt.

Werk het plan uit zonder alvast een uitkomst te kiezen

Een analyseplan is geen projectadministratie achteraf. Het is een afspraak die voorkomt dat een team tijdens het werk ongemerkt de vraag, de populatie of de betekenis van een kolom verandert. Begin daarom met één beslismoment. Schrijf bijvoorbeeld niet: “we willen klantdata analyseren”, maar: “de servicemanager besluit op maandag of er capaciteit naar regio Noord gaat; daarvoor vergelijkt zij afgesloten verzoeken van de vorige vier volledige weken.” Daarmee zijn lezer, moment en periode zichtbaar.

Maak vervolgens een klein definitieschema. Per KPI leg je vast wat meetelt, wat juist niet meetelt, welke datum leidend is, in welke eenheid je rapporteert en wie twijfel oplost. Geef ook aan wat een record is. Bij tickets kan dat een aanvraag zijn, maar bij omzet kan het een factuurregel, factuur of betaling zijn. Dat onderscheid bepaalt of je mag optellen. Als een bron niet kan aantonen welke betekenis geldt, is dat geen detail maar een blokkade voor een stevige conclusie.

Een format dat je direct kunt invullen

Gebruik onderstaande velden als een compacte start. Vul alleen zakelijke of synthetische voorbeelden in. Zet geen namen van klanten, e-mailadressen, vrije tekst uit tickets of andere persoonsgegevens in een gedeeld plan wanneer die niet nodig zijn.

1. Besluit: welke keuze volgt mogelijk uit dit antwoord?
2. Hoofdvraag: welke groep, periode en vergelijking onderzoek je?
3. Succescriterium: wanneer is het antwoord bruikbaar genoeg om te handelen?
4. Populatie en uitsluitingen: welke records horen er wel en niet bij?
5. Bronregister: systeem, eigenaar, extractiedatum, tabellen en bekende vertraging.
6. Definities: formule, datumveld, statusregel, eenheid en afronding per KPI.
7. Bewerking: welke reproduceerbare stap verandert welke kolom en waarom?
8. Controles: aantallen, totalen, steekproef en afwijkingsgrens.
9. Risico en privacy: minimaal noodzakelijke velden, rollen en bewaartermijn.
10. Oplevering en beheer: vorm, eigenaar, versie en moment van hercontrole.

De Europese AVG noemt doelbinding en dataminimalisatie als beginselen: bepaal dus eerst waarom een veld nodig is en verwerk niet “voor het geval dat” meer velden. Lees de primaire tekst van artikel 5 AVG op EUR-Lex naast de praktische uitleg van de Autoriteit Persoonsgegevens over verantwoordingsplicht. Dit artikel geeft geen juridisch advies; leg een risicovolle of nieuwe verwerking voor aan je privacyverantwoordelijke.

Synthetisch voorbeeld: vertraging per regio

Stel dat een fictief serviceteam wil weten waar de doorlooptijd oploopt. Het plan zegt: “Vergelijk afgesloten verzoeken in april en mei, per regio. Doorlooptijd is kalenderdagen tussen ontvangst en de eerste status gesloten. Verzoeken zonder sluitdatum tellen niet mee in de gemiddelde doorlooptijd, maar wel apart als open voorraad.” De bron is een maandelijkse export met een interne recordcode. De eigenaar levert een lijst met bekende testrecords die buiten de populatie vallen.

Voor de controle telt het team eerst het aantal unieke recordcodes. Daarna vergelijkt het drie bekende fictieve verzoeken met de bron en controleert het of april en mei hetzelfde datumveld gebruiken. De acceptatiegrens kan bijvoorbeeld zijn: geen ontbrekende recordcode, geen onverwachte negatieve doorlooptijd en maximaal twee procent records zonder regio. Overschrijdt een bron die grens, dan komt er een datakwaliteitssignaal in plaats van een ranglijst. Daarna kan de lezer met de tien datakwaliteitschecks vaststellen of een herstelstap nodig is.

De conclusie luidt in dit voorbeeld niet “Noord presteert slecht”. Een voorzichtige formulering is: “In mei is de gemeten gemiddelde doorlooptijd in Noord hoger; de registratie bevat nog 1,4% records zonder regio en verklaart de oorzaak niet.” Dat maakt ruimte voor verificatie met proceskennis of een korte kwalitatieve check. Voor de keuze tussen tellen en context verzamelen helpt kwalitatief versus kwantitatief onderzoek.

Validatie, onzekerheid en herstel

Plan een controle vóór de eerste berekening, na iedere ingrijpende bewerking en vlak voor publicatie. Noteer per controle wie heeft gekeken, wanneer en wat het resultaat was. Een controle is sterker wanneer een ander de stappen met hetzelfde bronbestand kan herhalen. De Power Query-richtlijnen van Microsoft adviseren onder meer vroeg profileren en kleine, controleerbare stappen. Dat principe geldt ook als je geen Power Query gebruikt.

Komt een definitieconflict boven water, probeer dan niet snel één getal te redden. Zet de oplevering op pauze, bewaar de vorige versie, beschrijf de afwijking en vraag de definitie-eigenaar om een keuze. Herbereken daarna vanaf de bron, niet vanaf een gekopieerde grafiek. Vermeld in de oplevering welke periode of groep onzeker blijft. Een dashboard kan een vervolgactie ondersteunen, maar vervangt geen inhoudelijke goedkeuring.

Veelgemaakte fouten

• Een tool als methode opschrijven. “We gebruiken een dashboard” zegt niets over de vraag of controle.
• Een doel en KPI door elkaar halen. “Sneller helpen” is een doel; “mediane doorlooptijd per week” is een mogelijke indicator.
• Filters niet vastleggen. Een lezer kan dan dezelfde KPI met een andere groep berekenen.
• Testrecords in de uitkomst laten staan. Markeer en sluit ze met een herleidbare regel uit.
• Alleen het eindbestand bewaren. Bewaar ook bronversie, definitielijst en wijzigingslog.

Lees wat data-analyse is voor de basis en vertaal het goedgekeurde plan daarna naar een afgebakende dashboardbriefing met acceptatiecriteria.

Officiële bronnen

• Autoriteit Persoonsgegevens: verantwoordingsplicht
• EUR-Lex: AVG
• Microsoft Learn: Power Query-richtlijnen