BI-platform concept — gedestilleerde samenvatting

Het concept, de ontwerpbeslissingen en de open keuzes achter het onderliggende BI-/analyseplatform (de “batterij” onder Storybooks & Insights). Bedoeld om een sessie snel te oriënteren op de architectuur-redenering.

Bron: gesprek met Claude (chat), gedestilleerd 2026-06-27. Het volledige woordelijke transcript hoort hier nog onder te komen (Deel 2 — nog toe te voegen, was afgekapt). Verhouding tot de rest: dit is de WHAT-laag. De verkoop-/verhaal-laag staat in visie-commercieel-positionering.md en why-en-storybrand-bronmateriaal.md.

Het concept in één alinea

Een lichtgewicht BI-/analyseplatform dat rechtstreeks op het data warehouse zit (geen zwaar vooraf gebouwd semantisch model). Een AI-assistent helpt de gebruiker data te exploreren, SQL te schrijven en visuals te bouwen. Het platform bouwt zelf bewust weinig: de kern is de visualisatielaag + de vastlegging (welke SQL, welke visual, welke parameters, welke bron). Definities en een semantisch model ontstaan bottom-up / organisch uit feitelijk gebruik, niet top-down vooraf door IT. De positionering is storytelling & focus voor finance/controlling, niet “self-service BI voor iedereen”.

Kernfilosofie

De AI is sterk in genereren (vragen, SQL, visuals, voorstellen). De mens is nodig voor het ankeren (klopt dit? is dit af? was dit de bedoeling?). Het hele platform is: vrije generatie, verankerd door menselijk oordeel op de paar plekken waar het telt.

Terugkerende vraag per gedaante: heeft de gebruiker tegenover mij het anker zelf in huis, of moet de assistent het meebrengen?

Belangrijkste ontwerpbeslissingen

Hard vs. zacht. Hard = datamodel/domeinlogica/validatie. Zacht = de AI-assistent die de afstand overbrugt tussen ruw bouwblok en de specifieke gebruikersvraag. De dure, brosse UI-laag (wizards, tooltips, schermvarianten) verschuift naar de assistent → klein, stabiel UI-oppervlak, andere kostencurve.
De assistent gaat door dezelfde poort als de gebruiker. AI-acties mogen validatie/constraints niet via een achterdeur omzeilen.
Onderscheid uitleg geven (laag risico) van invullen/muteren (hoog risico). Voor het tweede: expliciet bevestigingsmoment (GUI als verificatiepunt).
Uitleg is eigenschap van het blok, niet van de assistent. Eén bron van waarheid die gedrag én uitleg voedt.
Vastgelegde SQL is de bron van waarheid, niet de natuurlijke-taalvraag. Bevroren SQL + visual + parameters + bron → reproduceerbaar, draait zónder AI.
Gebroken moet zichtbaar breken. Bij schemawijziging: duidelijke fout i.p.v. stilletjes verkeerde cijfers.
Semantisch model: bottom-up i.p.v. top-down. Definities ontstaan per vraagstuk; de AI herkent, legt vast en controleert tegen bestaande definities. Het model wordt opgevangen, niet gebouwd.
Controlerende skill moet écht bijten. Bij een nieuwe definitie: AI checkt op betekenis (niet string) of er al iets vergelijkbaars bestaat, en confronteert. Governance door confrontatie op moment van ontstaan.
Leg bij elke definitie herkomst + context + status vast (persoonlijk / gedeeld) → natuurlijke promotie lokaal → gedeeld.
Hardening-routine (periodiek, niet in productie/niet meteen). Business gaat door (snelheid); warehouse convergeert periodiek (consistentie). Review checkt twee assen: consistentie én validiteit (klopt hij, gegeven de grain?). Verankerde definities stromen terug.
Geen keiharde blokkade. Die vereist dat de “juiste” definitie al bestaat én bekend is — de top-down aanname die je ontvlucht. Zachte frictie nu + periodieke verzoening.
Data-eigenaar verplaatst van moment-van-ontstaan naar de periodieke review. Overgebleven knop = de cadans.

Wat van Kimball/stermodel overleeft

Niet nabouwen: het fysieke stermodel (performance-argument is dood door columnar/MPP).
Wél serieus nemen:
- Grain (= wat betekent één rij). De stille moordenaar: een fan-out verdubbelt bedragen, ziet er plausibel uit, breekt niet luid.
- Conformed dimensions (= gedeelde definities) = het definitieregister in oudere kleren.

Het controle-mechanisme (de echte differentiator)

Drie visuals als eersteklas, vastgelegde burgers van het systeem:

Hoofdvisual — wat wil ik zien. (Wat elke BI-tool levert.)
Rondrekening — klopt het met zichzelf (interne fout: join-explosie, dubbeltelling). Volledig binnen eigen data.
Tie-out naar bronsysteem — klopt het met de werkelijkheid (externe fout). Heeft een extern ankergetal nodig (bv. ERP-screenshot, maandafsluiting).

Cruciaal:

De gevaarlijkste fan-out (plausibel maar fout) wordt door een tie-out genadeloos opgevangen → je hebt geen stermodel nodig voor grain-bescherming, je hebt een aansluiting nodig.
AI-zelfcontrole = nuttige eerste zeef, maar mag de tie-out niet vervangen: de AI toetst tegen zijn eigen (mogelijk foute) begrip; de tie-out toetst tegen externe waarheid.
Het ankergetal mag niet uit dezelfde bron met dezelfde fout komen.

Twee menselijke rollen

Intentie — wat wil ik analyseren.
Attestatie — “ik heb gezien dat het aansluit en sta ervoor in.” Een handtekening, geen analyse. Nooit aan de AI. Vastleggen: wie heeft wanneer welke aansluiting bevestigd.

Iteratie vs. zoeken

Het proces is geen iteratie (convergeren naar bekend doel) maar zoeken (het doel beweegt; pas door een resultaat te zien weet je wat je had moeten willen). De assistent is geen uitvoerder maar gesprekspartner in het ontdekken van de vraag. Schaduwkant: zoeken heeft geen natuurlijk eindpunt → de assistent heeft een kompas/tegenkracht nodig (“je zocht X — sluit dit daarop aan?”).

Verhouding tot Power BI / Microsoft (de strategische weddenschap)

Microsoft wedt: AI (Copilot) bovenop een vooraf gebouwd, governed semantisch model. Copilot consumeert het model, mag het niet bouwen. Richting: Power BI als governed AI-laag binnen Fabric.
“Prep data for AI” = letterlijk het top-down model: eerst IT, dan business.
Jouw weddenschap is tegengesteld: AI bouwt het model on-the-fly, business itereert vrij, mens borgt achteraf. Microsoft kan die oever architectonisch niet bereiken zonder DAX/het model op te geven.
Maar: modelkwaliteit-vooraf dempt ambiguïteit, niet de klasse “plausibel maar fout”. Microsoft’s “verified answers” (handmatig gecureerde Q&A) is een stille toegeving — een primitieve versie van jouw verificatie. Jouw rondrekening/tie-out = de schaalbare vorm.

Organisch model destilleren (vliegwiel)

Uit bv. 40 analyses kun je een semantisch model destilleren — bottom-up.
Levert niet een schoon model maar de tegenstrijdigheden → concentreert het oordeel in de hardening-review.
Beperking: bevat alleen wat mensen gevráágd hebben → blinde vlek voor de vraag die niemand bedacht.
Vliegwiel: artefacten → gedestilleerd model → scherpere assistent → betere artefacten. Versterkt wat je het voert, inclusief fouten. De poort (artefact gaat pas het model in ná rondrekening + attestatie) bepaalt of het convergeert naar waarheid of garbage.

Go-to-market / positionering

Niet “self-service BI voor de business” (kerkhof; mist het anker).
Beachhead: finance / controlling / BI-consultant — wie het anker (aansluitingsreflex) al heeft maar het gereedschap niet.
Positioneer op verifieerbaarheid-als-bewijs (“elk cijfer komt met zijn bewijs”), niet op feature-pariteit met Power BI.
Verkoop tegen de pijn, niet de droom: “nooit meer handmatig aansluiten, vast voor de audit” i.p.v. “vrij bouwen op je data”.
Scheiding zuiver houden: controllerlaag (wig, finance-specifiek) vs. exploratie-/destillatiemotor (visie, domein-neutraal).
Sterkere verfijning: vraag een branche-kennende adviseur “welke 15–20 analyses zou jij maken om dit bedrijf te begrijpen?” → KPI-framework. Wig = storytelling + focus; verteller = de controller, niet de bouwer. Verkoop statusverhoging (“je wordt belangrijker”), niet efficiëntie. Verifieerbaarheid ligt eronder: een verhaal dat niet klopt is een leugen met een grafiek.

Open keuzes

Per-visual SQL vs. dunne tussenlaag met gedeelde metrics. Advies: reserveer de plek in de vastlegging.
Assistent = interpretatielaag of ook generatielaag.
Wie beslist bij definitiebotsing → eigenaar verplaatst naar periodieke review; resterende knop = cadans.
Ankergetal-herkomst voor de tie-out (onafhankelijke bron).
Consultancy vs. product → begin consultancy-achtig, maar voed vanaf dag één de productbibliotheek/branche-templates.
Aan wie verkoop je het verhaal — de controller die het wil máken, of de bestuurder die het wil ontvángen?