Datagrundlaget: dimensioner og datamodel bag enhver analyse

Datagrundlaget: dimensioner og datamodel bag enhver analyse

Resumé og konklusion

  • To rapporter med to omsætningstal er ikke et rapporteringsproblem. Det er et definitionsproblem, og det er den billigste test, der findes, af et datagrundlag for analyse.
  • Dimensioner og datamodel er de to øverste af fire lag. Definitioner, stamdata, struktur og model. Man kan ikke springe et lag over, og fejl i lag 1 kan ikke rettes i lag 4.
  • Dimensioner er det vigtigste analysevalg i Business Central. De to globale dimensioner virker overalt, og at lave dem om bagefter er en stor øvelse. Vælg dem ud fra, hvordan I vil analysere, ikke hvordan I bogfører.
  • Bogføringsgrupperne afgør, hvad du overhovedet kan analysere på. Har alle varer den samme produktbogføringsgruppe, kan ingen finansrapport vise dækningsbidrag pr. forretningsområde. Det kan Power BI ikke reparere bagefter.
  • AI redder ikke et dårligt datagrundlag. Den gør bare de forkerte svar hurtigere. Microsofts krav til Copilot er i praksis en tjekliste for det samme grundlag.

To rapporter, samme måned, to forskellige tal

På ledelsesmødet i juli lå der to tal for juni. Salgsrapporten sagde 5.240.000 kr., ledelsesrapporten fra økonomi sagde 5.418.000 kr. Forskellen er 178.000 kr.: 121.000 kr. i fragt og gebyrer, som salg ikke regner med, og 57.000 kr. i koncerninternt salg, som økonomi ikke trækker fra. Begge tal er korrekte. Alligevel gik tyve minutter med at finde ud af, hvilket der gjaldt, i stedet for med at tale om, hvorfor juni var svag.

Det er ikke et rapporteringsproblem. Det er et definitionsproblem, og det er det tydeligste symptom på et datagrundlag, der aldrig er blevet skrevet ned. Domæneanalyserne — finansiel analyse, salgsanalyse, indkøbsanalyse og lageranalyse — virker kun, hvis grundlaget under dem er på plads.

De fire lag under dimensioner og datamodel

Lag 1 er definitionerne. Hvad betyder omsætning, dækningsbidrag, aktiv kunde og leveret til tiden hos jer? Det skal skrives ned, ikke diskuteres. Er en kunde aktiv efter et køb inden for 12 måneder eller 24? Tæller en delleverance som leveret til tiden? Ejeren er økonomichefen. Uden lag 1 får man scenen fra ledelsesmødet.

Lag 2 er stamdata. Kunder, varer og leverandører uden dubletter, med konsistente enheder og udfyldte felter. Står “Nordisk Byg A/S” oprettet tre gange med 1,4, 0,9 og 0,5 mio. kr. i køb, findes koncernens 2,8 mio. kr. ikke nogen steder. Kunden falder ud af top 10, og rabatforhandlingen bliver ført på et forkert grundlag.

Lag 3 er strukturen. Dimensioner, kontokategorier og bogføringsgrupper i Business Central: den opsætning, der bestemmer, hvad man overhovedet kan gruppere på. Er der ingen dimension på salgskanal, findes svaret på “hvilken kanal vokser hurtigst” ikke. Det er ikke en rapport, der mangler. Det er data, der aldrig blev registreret. Ejeren er BC-superbrugeren.

Lag 4 er modellen. Stjerneskemaet i Power BI med faktatabeller, dimensionstabeller, klare navne og beskrivelser. Ejeren er den BI-ansvarlige eller partneren.

Pointen er rækkefølgen. Grundlaget bygges nedefra, og fejl i lag 1 kan ikke rettes i lag 4. Et forkert defineret dækningsbidrag bliver ikke rigtigt af at komme i Power BI. Det bliver bare hurtigere forkert og set af flere. Grafikken herunder viser de fire lag med ejer og konsekvens for hvert af dem.

De fire lag i datagrundlaget med dimensioner og datamodel
De fire lag i datagrundlaget

Dimensioner: det vigtigste analysevalg i Business Central

Dimensioner er Business Centrals indbyggede måde at analysere på tværs af afdeling, projekt, område og salgskanal uden at oprette nye konti for hver kombination (dimensioner hos usedynamics). To af dem er globale. De kan bruges overalt, også som filter direkte på kontoplanen og i finansrapporter. Derudover kan man have genvejsdimensioner, som ligger på bilagslinjerne og er hurtige at bogføre på (bogføring med dimensioner).

Advarslen er den vigtigste sætning i artiklen: at ændre de globale dimensioner bagefter er en stor øvelse, fordi alle bogførte poster skal opdateres. Vælg dem rigtigt fra start, og vælg dem ud fra, hvordan I vil analysere, ikke hvordan I bogfører.

Et dårligt valg i en handelsvirksomhed med 60 mio. kr. i omsætning: global dimension 1 er Afdeling med 10 Adm, 20 Salg og 30 Lager, og global dimension 2 er Bogføringsformål. Begge er kopieret fra den gamle kontoplan. Opsætningen kan besvare ét spørgsmål: hvad koster hver afdeling. Den kan ikke besvare, om man tjener penge på servicedelen, hvilken salgskanal der vokser, eller hvad dækningsbidraget er pr. forretningsområde.

Et godt valg i samme virksomhed: global dimension 1 er Forretningsområde med Handel, Service og Projekt, global dimension 2 er Salgskanal med Webshop, Direkte salg og Forhandler. Afdeling, projekt og sælger flyttes ned som genvejsdimensioner. Nu kan alle fire spørgsmål besvares, og afdelingsspørgsmålet kan stadig besvares. Det er forskellen på et datagrundlag for analyse og et datagrundlag for bogføring. Grafikken herunder stiller de to opsætninger op ved siden af hinanden.

Dimensionsvalget i Business Central som del af dimensioner og datamodel
Dimensionsvalget i Business Central

Kontoplanen og kontokategorierne

Analyse kræver, at kontoplanen har en struktur og ikke bare en nummerrække. Kontotyper, totalintervaller og indrykning gør, at rapporterne summerer af sig selv (kontoplanen hos usedynamics). En kontoplan uden totalintervaller tvinger enhver analyse ud i et regneark, hvor nogen adderer i hånden.

Og så det råd, der er billigst i hele serien: byg finansrapporterne på kontokategorier (G/L Account Categories) i stedet for på hårdkodede kontonumre (arbejd med finansrapporter). Hver gang nogen opretter en ny konto, er en nummerbaseret rapport forkert, indtil et menneske opdager det. En kategoribaseret rapport tager den nye konto med af sig selv. Det er lag 3 i praksis, og det er den enkeltbeslutning, der sparer mest vedligehold senere.

Bogføringsgrupper: den usynlige analysestruktur

Bogføringsgrupperne er den del af grundlaget, ingen taler om, fordi de føles som en teknikalitet. Virksomhedsbogføringsgrupper bestemmer, hvem en postering vedrører: indland, EU, eksport, koncern. Produktbogføringsgrupper bestemmer, hvad den vedrører: handelsvarer, servicetimer, fragt. Kombinationen afgør, hvilken konto beløbet lander på (bogføringsgrupper, koncept og flow).

Konsekvensen for analysen er direkte. Har alle varer den samme produktbogføringsgruppe, ender handelsvarer og servicetimer på den samme omsætningskonto (produktbogføringsgrupper). Så kan ingen finansrapport vise dækningsbidrag pr. forretningsområde, uanset hvor dygtig den BI-ansvarlige er. Bruger alle kunder den samme virksomhedsbogføringsgruppe, kan eksportsalg ikke skilles fra indlandssalg i finansen (virksomhedsbogføringsgrupper).

Tommelfingerreglen: hver gang ledelsen spørger “hvor stor en del af omsætningen kommer fra”, afhænger svaret af bogføringsgrupperne. Det er en halv dags oprydning i opsætningen og en umulig opgave i Power BI. Vil I teste, hvor langt strukturen rækker, kan I gøre det uden BI-projekt overhovedet — analysetilstand i Business Central viser med det samme, hvilke akser I faktisk kan skære tallene på.

Modellen i Power BI: stjerneskema, sprog og teknik

Lag 4 er stjerneskemaet. Faktatabellerne med posteringerne ligger i midten, og dimensionstabellerne for kunde, vare, sælger, dato og dimensionsværdi ligger omkring. Én vej fra hver dimensionstabel ind til fakta. Det er den form, dimensioner og datamodel skal have i Power BI: den gør filtrering og tidsintelligens hurtig. Grafikken herunder viser skemaet med faktatabellen Salgsposter i midten.

Stjerneskemaet der binder dimensioner og datamodel sammen i Power BI
Stjerneskemaet i datamodellen

Sproget i modellen er lige så vigtigt som formen. Klare navne uden forkortelser, beskrivelser på tabeller, kolonner og mål, og de felter, ingen skal bruge, skjules. Det er præcis de krav, Microsoft stiller, for at Copilot kan svare rigtigt (Copilot og semantiske modeller). Tag et felt fra Business Central: “Amount (LCY)” siger intet til hverken en ny medarbejder eller en AI. “Omsætning i DKK” siger det hele. Det er tyve sekunders arbejde pr. felt.

Teknikken bagved har tre faste regler (byg Power BI-rapporter på BC-data). Kun OData V4 understøttes. Brug en read-only replica, så analysen ikke belaster produktionsmiljøet. Og sæt ODataMaxPageSize op — den kan gå til 20.000 rækker, hvilket flytter en opdatering fra timer til minutter. Start i øvrigt ikke fra en tom fil: Power BI-apperne til Business Central blev open-sourcede 1. oktober 2025 og fik samtidig drill-back og dynamiske dimensionsnavne, så de kan bruges som udgangspunkt for jeres egen model.

Skal modellen ligge i Power BI alene, eller skal den have en data platform under sig? Det spørgsmål hører til det samme lag, og vi har taget det for sig i gennemgangen af, hvornår Power BI er nok. Driften af den færdige model — opdateringer, adgange og ejerskab — er behandlet i Power BI i en SMV uden IT-afdeling.

Et godt datagrundlag er også AI-grundlaget

Microsoft har lagt to funktioner ind i Power BI, der hedder “prep data for AI” og AI instructions. De lader dig beskrive tabeller og felter i klart sprog, skrive regler for, hvordan modellen skal forstås, og gemme verificerede svar på de spørgsmål, der stilles ofte (prep data for AI og AI instructions).

Læs det igen. Det er lag 1 skrevet ned, bare i et format en maskine kan læse. En AI instruction om, at omsætning altid opgøres uden fragt og uden koncerninternt salg, er nøjagtig den definition, ledelsesmødet manglede — nu håndhævet automatisk, hver gang nogen spørger.

Derfor holder den vigtigste sætning om AI: AI redder ikke et dårligt datagrundlag. Den gør bare de forkerte svar hurtigere, mere selvsikre og lettere at sende videre. En sprogmodel kan ikke gætte, om jeres omsætning er med eller uden fragt. Er lag 1 til lag 3 ikke på plads, er gevinsten ved AI ikke nul, den er negativ, fordi fejlene nu kommer med en velformuleret forklaring. Artiklen om Copilot i Power BI og Fabric data agents går i dybden med det, og forudsætningen der er præcis de dimensioner og datamodel, denne artikel handler om.

Sådan understøtter oneBC365 dimensioner og datamodel

oneBC365 er færdige Power BI-rapporter oven på Business Central-data, og det, produktet reelt leverer, er lag 4 i jeres grundlag. Modellen er bygget som stjerneskema med danske feltnavne og beskrivelser, målene er defineret ét sted, finansrapporterne bygger på kontokategorier frem for kontonumre, og jeres dimensioner følger med under deres egne navne i stedet for som Dimension 1 og Dimension 2. Den samme model kan trækkes direkte ind i regnearket, hvis I foretrækker det — se Analysér i Excel.

Det, oneBC365 ikke kan, er at opfinde lag 1 til lag 3 for jer. Definitionerne skal I skrive, stamdata skal I rydde op i, og dimensionsvalget er jeres. Til gengæld gør en færdig model det synligt med det samme, hvor grundlaget mangler: står der fem varegrupper i systemet, men hele omsætningen ligger i én, ser I det på den første side, I åbner, i stedet for om et halvt år.

Sådan kommer du i gang

  1. Skriv definitionerne ned på én side. Ti til femten begreber: omsætning, dækningsbidrag, aktiv kunde, leveret til tiden. Ved hvert begreb en ejer og det felt eller den kontokategori i Business Central, tallet kommer fra. Det tager en formiddag og er hele lag 1.
  2. Test jeres dimensioner mod virkeligheden. Skriv de fem spørgsmål ned, ledelsen oftest stiller. Kan de to globale dimensioner besvare dem? Kan de ikke, så tag ændringen nu — den bliver kun dyrere for hver måned, der bogføres.
  3. Kør en oprydning i stamdata. Dubletkontrol på kunder, leverandører og varer, spærring af de inaktive og en ansvarlig for, hvem der må oprette nye. Uden det er ethvert grundlag utroværdigt på top 10-lister.
  4. Byg modellen som stjerneskema med læsbare navne. Beskrivelser på tabeller, kolonner og mål, tekniske felter skjult, og start fra de open-sourcede Power BI-apps i stedet for fra en tom fil. Så er lag 4 klar til både mennesker og Copilot.

Hele serien: fra rapportering til analyse

Serien er tolv artikler i fire blokke — fundament, domæner, praksis og AI. Hver artikel kan læses alene; læst i rækkefølge er de en plan for et år.

  1. Fra rapportering til analyse: de fire trin
  2. Analyse-landkortet
  3. Analysemetodernes værktøjskasse
  4. Finansiel analyse
  5. Salgsanalyse
  6. Indkøbsanalyse
  7. Lageranalyse
  8. Datagrundlaget — du læser den nu
  9. Analysens årshjul
  10. Analyse uden BI-projekt
  11. AI i analysen (1): Copilot i Business Central
  12. AI i analysen (2): Copilot i Power BI og Fabric

Vil du se, hvordan analyserne ser ud på jeres egne tal? Book en demo af oneBC365.

Scroll to Top