Eén definitie van omzet voor elk rapport en elke agent

In de directievergadering liggen drie omzetcijfers voor dezelfde maand op tafel. Sales nam er een mee uit het CRM: deals die als gewonnen zijn gemarkeerd. Finance nam er een mee uit het grootboek: verstuurde facturen, min creditnota’s. Operations nam er een mee uit het magazijnsysteem: verzonden orders. Elk cijfer klopt volgens de eigen definitie, en de eerste twintig minuten van de vergadering gaan op aan uitzoeken waarom ze verschillen.

Nu wordt een agent gevraagd hoe de omzet zich verhoudt tot het plan. Welke definitie gebruikt hij? In de praktijk die van de tabel die hij het eerst tegenkomt, en de volgende keer misschien een andere.

De oorzaak is dat de definities van bedrijfskengetallen in de rapportagelaag leven: in de formules van elk dashboard, in elke spreadsheet, in de query’s van elke analist. Elke afnemer bouwt ze opnieuw, en de implementaties lopen met elke correctie verder uit elkaar. Agents maken dit erger, niet omdat ze slordig zijn, maar omdat het er meer zijn, ze de data rechtstreeks bevragen en ze sneller antwoorden produceren dan iemand de definitie achter elk antwoord kan controleren.

Het beproefde antwoord heeft in business intelligence een naam: een semantische laag. Dat is een gedeelde laag die bedrijfskengetallen en dimensies één keer definieert, bovenop de ruwe data, zodat elke tool „omzet” bij naam opvraagt in plaats van het opnieuw te berekenen. OLAP-kubussen deden decennia geleden al een variant hiervan. Het idee is nu belangrijker, omdat de afnemers ook software omvatten die haar eigen query’s schrijft.

Waar definities uit elkaar lopen

Formules gekopieerd naar rapporten. Eén kopie krijgt een correctie, de andere niet, en de cijfers gaan uiteen zonder dat iemand daartoe besloot.

Eén woord, meerdere betekenissen. Geboekte, gefactureerde en verantwoorde omzet zijn allemaal legitiem, en allemaal verschillend. Ze allemaal „omzet” noemen garandeert een discussie.

Stille filters. Intercompany-verkopen op de ene plek uitgesloten en op de andere niet. Creditnota’s hier verrekend en daar niet. Een testklant die niemand uit één van de databronnen heeft verwijderd.

Tijd. Orderdatum, factuurdatum of leverdatum: dezelfde transactie valt in verschillende maanden, afhankelijk van welke datum een rapport gebruikt.

Valuta en afronding. Welke wisselkoers, van welke dag, en waar afgerond.

Agents die zelf kiezen. Een taalmodel dat query’s schrijft op ruwe tabellen, kiest bij elke vraag een plausibele definitie. Plausibel is niet hetzelfde als afgesproken, en het is niet gegarandeerd twee keer hetzelfde.

Eén keer definiëren, aan de bron

Geef elke variant een naam. Geboekte omzet, gefactureerde omzet en verantwoorde omzet worden elk een apart, benoemd kengetal met een eigenaar en een geschreven definitie. Het doel is niet één definitie van omzet voor het hele bedrijf, maar precies één definitie achter elke naam.

Definieer kengetallen op het bedrijfsmodel, niet op tabellen. Gefactureerde omzet wordt gedefinieerd op facturen en creditnota’s als objecten in de ontologie van het bedrijf, met hun statussen en relaties, niet op kolomnamen die veranderen zodra een bronsysteem wordt geüpgraded.

Laat alles de laag bevragen. Dashboards, spreadsheets, exports en agents vragen het kengetal allemaal bij naam op. Vooral agents mogen een bedrijfskengetal niet uit ruwe tabellen samenstellen; ze vragen erom, en het antwoord komt met de definitie erbij.

Versioneer de definities, met ingangsdata. Als een definitie verandert, zijn de cijfers van vorig jaar nog steeds te reproduceren zoals ze toen zijn gerapporteerd, en is de wijziging zichtbaar als wijziging.

Toon de definitie bij het getal. Elk antwoord vermeldt welk kengetal, welke filters, welke periode en met welke peildatum. Een getal zonder die gegevens is een gerucht met decimalen.

In het ontwerp van Hurukan worden kengetallen gedefinieerd op de objecten van de laag Ontologie en gelezen uit één datamodel in de laag Data, zodat een rapport en een agent die dezelfde vraag stellen hetzelfde antwoord krijgen, om dezelfde reden. Budgetbeheersing in de module Financiën (plan, verplicht, werkelijk en prognose) is gebouwd op precies zulke benoemde maatstaven. Dit is in ontwikkeling.

Een test die u vandaag kunt doen

Vraag drie mensen naar het omzetcijfer van vorige maand en hoe ze eraan zijn gekomen: iemand van finance, iemand van sales en degene die het directiepakket voorbereidt. Noteer de drie getallen en de drie methodes.

Als uw bedrijf al een AI-assistent heeft die op de data is aangesloten, stel hem dan dezelfde vraag twee keer, in twee afzonderlijke sessies, en noteer wat hij zegt en hoe.

Komt u over die vijf antwoorden op meer dan één getal uit, en kunt u voor elk verschil de reden niet noemen, dan hebt u eerst een gedeelde definitie nodig en pas daarna een nieuw rapport. Het bredere pleidooi om analytics te laten beginnen bij vragen in plaats van bij dashboards staat in het dashboard dat niemand opent.