Du kender måske situationen. Der er brugt tid og penge på Power BI. Dashboardet ser godt ud. Farverne passer. Layoutet er professionelt. Og så siger salgschefen: “De tal stemmer ikke med mine.”
Pludselig handler mødet ikke om strategi, men om hvem der har ret. Økonomi har én version af dækningsbidraget, salg har en anden – og driftschefen sidder med et Excel-ark han selv har lavet, fordi han ikke stoler på nogen af delene. Det dashboard, der skulle skabe klarhed, har skabt en diskussion. Igen.
Min påstand er, at problemet næsten aldrig er dashboardet. Det er det, der ligger under det. Og det, der ligger under det, er noget så kedeligt som stamdata.
Stamdata er ikke en administrativ opgave
De fleste virksomheder behandler stamdata som noget nogen skal “vedligeholde.” Kunder, varer, leverandører, kontoplan, dimensioner. Det er de stabile forretningsobjekter, som alt andet bygger ovenpå. Og netop fordi de er stabile, tænker de fleste ikke særligt meget over dem. De er der bare.
Problemet er, at når de ikke er korrekte, påvirker det alt. Hver eneste rapport, hvert dashboard, hver automatisering arver de fejl, der ligger i stamdata. Melville, Kraemer og Gurbaxani har vist det i deres forskning om IT-værdi: teknologi skaber aldrig værdi alene. Værdien kommer fra kombinationen af teknologien og de organisatoriske ressourcer, der gør den brugbar (Melville et al., 2004). Datafelter er tekniske strukturer. Datakvalitet er et organisatorisk resultat.
Det er en vigtig pointe, fordi den flytter ansvaret. Stamdata er ikke noget IT-afdelingen klarer. Det er noget organisationen klarer.
Schryen peger på noget tilsvarende, når han viser, at sammenhængen mellem IT-investeringer og forretningsværdi er svær at bevise kausalt (Schryen, 2013). Der er forsinkede effekter, måleproblemer og organisatoriske mellemled overalt. I praksis betyder det, at en virksomhed ikke kan konkludere at Business Central mangler værdi, hvis det egentlige problem er svag datapraksis, ingen dimensionsdisciplin og uklare regler for hvem der må ændre hvad.
(Og nej, at købe en Power BI-licens løser det ikke.)
Når salg og økonomi ikke er enige om hvad en “kunde” er
Chan og Reich har forsket i alignment, altså sammenhængen mellem IT-systemer og forretningsbehov (Chan & Reich, 2007). Deres pointe er, at systemers værdi afhænger af, at strukturen i data og den måde data bruges på faktisk afspejler de beslutninger, virksomheden skal træffe. Det lyder abstrakt. Det er det ikke.
Lad mig tage et tænkt eksempel. Hvis salg definerer en “kunde” som den kontakt, der bestiller, men økonomi definerer en “kunde” som den juridiske enhed, der betaler, og drift definerer en “kunde” som den adresse, der modtager varen, så har du tre afdelinger der taler forbi hinanden. Ikke fordi de er uenige. Men fordi de arbejder med forskellige definitioner af det samme begreb. Den slags informationsgnidninger kan hverken Power BI eller Power Apps fjerne. De kan kun gøre dem mere synlige.
Janssen og kolleger viser, at troværdig datadrevet beslutningsstøtte kræver governance omkring data, processer og ansvar (Janssen et al., 2020). Deres forskning handler om AI, men argumentet rammer lige præcist her: jo mere en virksomhed arbejder med dashboards, automatisering og (i fremtiden) AI, desto vigtigere bliver det, at nogen ejer dataene, at der er kvalitetssikring, at ændringer er kontrollerede. Det er ikke sexet. Men det er forudsætningen for alt det, der er.
Kane og kolleger kobler digital modenhed til ledelse, kultur og evnen til at bruge teknologi på tværs af organisationen (Kane et al., 2017). Overført til Business Central betyder det, at modenhed ikke handler om at have ERP og Power BI installeret. Det handler om at kunne vedligeholde datagrundlaget, tolke indsigter og omsætte dem til handling. En umoden organisation bruger ERP som bogføringsmaskine. En moden organisation bruger det som styringsfundament.
Forskellen mellem de to er sjældent teknisk. Den er organisatorisk.
Business Central er et backbone, ikke et dashboard
Sebastian og kolleger viser, at digital transformation i etablerede virksomheder kræver to ting: et stabilt operationelt backbone og et lag af digitale services ovenpå (Sebastian et al., 2017). Ross, Weill og Robertson argumenterer tilsvarende for, at enterprise architecture skaber et fundament for at drive forretningen (Ross et al., 2006).
Business Central passer ind i den rolle. Det er det sted, hvor transaktioner, regler og forretningsobjekter standardiseres. Power BI og Power Platform er så det forstærkende lag, der gør det muligt at analysere, visualisere, automatisere og udvide processerne. Men kun hvis backbone er robust nok til at bære det.
Microsoft beskriver selv Business Central som en løsning, der forbinder salg, service, økonomi og drift, og platformen kan integreres med Power BI, Power Apps og Power Automate (Microsoft, 2025a; Microsoft, 2025b). I praksis gør det Business Central til et centralt system of record, mens Power Platform fungerer som et lag for indsigt og udvidelser. Men forkerte dimensioner, dublerede kunder eller uens varenummerlogik bliver ikke mindre problematiske af at blive vist i flotte dashboards. De bliver bare mere synlige og mere skalerede.
Power BI giver mulighed for at kombinere og visualisere BC-data, og Business Central har i dag analysefunktioner direkte på listesider, så brugeren kan gruppere, pivotere og undersøge data uden at forlade ERP-klienten (Microsoft, 2024; Microsoft, 2025c). Det betyder, at indsigt ikke kun opstår i eksterne BI-værktøjer, men i den daglige arbejdsproces. Og det gør det endnu vigtigere, at de data, folk kigger på, faktisk er til at stole på.
Det samme gælder Edit in Excel og Power Automate. At redigere lister i Excel og publicere ændringer tilbage til Business Central kan være en kæmpe produktivitetsgevinst, men kun når datamodellen er disciplineret og rettighedsstyringen er bevidst. Ellers risikerer du at flytte manuelle fejl fra enkeltregistreringer til batchopdateringer i stor skala. Power Automate kan forbinde Business Central med Outlook, Teams, Dataverse og SharePoint, men workflows gør kun værdi hurtigere, hvis data allerede er gode nok til at blive videresendt uden manuelle kontroller (Microsoft, 2025d; Microsoft, 2025e).
Singh, Baird og Mathiassen kalder det ambidextrous governance: evnen til at styre stabil drift og løbende fornyelse samtidig (Singh et al., 2020). Business Central kræver netop den dobbelthed. Stamdata, bogføring og centrale processer skal være robuste og standardiserede. Rapportering, apps og automatisering må gerne udvikles mere eksperimenterende. Den balance kan ikke løses ved enten fuld centralisering eller fuld selvbetjening. Den kræver en bevidst arbejdsdeling mellem ejerskab, standarder og frihed til at bygge nyt.
STI-modellen: Fra stamdata til indsigt
På den baggrund har jeg udviklet det, jeg kalder STI-modellen (Stamdata Til Indsigt) som et praktisk værktøj til analyse og implementering.
Modellen bygger på fire kædede niveauer. Først kommer stamdatafundamentet, hvor virksomheden vurderer kvaliteten i sine kerneobjekter: kunder, varer, leverandører, kontoplan, dimensioner. Dernæst kommer proces- og registreringsdisciplin, hvor fokus flyttes til, hvordan data skabes, ændres og kontrolleres i den daglige drift. Tredje niveau er indsigtslaget, hvor Business Central-analyse, Power BI, Excel og Dataverse bruges til at omsætte data til forståelige signaler. Fjerde niveau er handling og skalering, hvor indsigterne omsættes til beslutninger, workflows, apps og automatisering.
Figur 1. STI-modellen: Fra stamdata til beslutnings- og automatiseringsværdi
1. Stamdatafundament
Kunder, varer, leverandører, kontoplan, dimensioner
2. Proces- og registreringsdisciplin
Korrekte felter, standardiseret brug, ansvarsplacering
3. Indsigtslag
Power BI, BC-analyse, Excel, Dataverse
4. Handling og skalering
Beslutninger, workflows, Power Automate, Power Apps
Tværgående styringslag
Dataejerskab • governance • alignment • digital modenhed • prioritering • datakvalitetsmålinger
Modellen skal ikke forstås sådan, at niveau fire først bliver relevant til sidst. Pointen er diagnostisk: hvis virksomheden oplever svage dashboards eller misvisende KPI’er, skal analysen ofte gå baglæns i kæden og spørge, om problemet i virkeligheden ligger i objekter, ejerskab eller registreringspraksis.
STI-modellen egner sig derfor både til foranalyse, implementeringsdesign og gevinstopfølgning. Tabellen herunder viser, hvordan modellen kan bruges diagnostisk: hvad er de typiske svagheder, hvad er konsekvenserne, og hvad kan ledelsen gøre?
Figur 2: STI-diagnosen
| Dimension | Typiske svagheder | Konsekvens i praksis | Ledelsesgreb | Primære værktøjer |
|---|---|---|---|---|
| Stamdatafundament | Dubletter, manglende felter, svag dimensionsstruktur, lokal logik i stedet for fælles standard | Ustabile rapporter, tvivl om KPI’er, fejl i finansielle og operationelle analyser | Definér dataejere, datastandarder og regler for oprettelse/ændring | BC master data, opsætning, godkendelser |
| Registreringsdisciplin | Uens registreringspraksis, omgåelse af processer, batchrettelser uden kontrol | Fejl forplantes til analyse, forecasts og workflows | Skab procesejerskab, træning og minimumskrav til registrering | Business Central, Edit in Excel, controller |
| Indsigtslag | Rapporter uden fælles definitioner, KPI’er uden kontekst, for mange lokale udtræk | Mistro til rapportering, lokale sandheder og sen beslutningstagning | Etabler fælles semantik, KPI-katalog og review-rytmer | Power BI, analyse i lister, Excel |
| Handling og skalering | Automatisering oven på svage data, apps uden governance, uklar prioritering | Hurtigere spredning af fejl og lav adoption | Styr portefølje, test flows og mål gevinster | Power Automate, Power Apps, Dataverse |
Start med datagrundlaget, ikke med dashboardet
Det vigtigste implementeringsprincip er det mindst populære: start med dataobjekter, ikke med dashboards. Kunde-, vare-, leverandør- og dimensionsdata skal være tilstrækkeligt standardiserede, før ledelsen beder om mere avanceret indsigt. Og der skal være et tydeligt skel mellem dataejerskab og rapportudvikling. Den, der bygger rapporten, kan ikke alene bære ansvaret for datakvaliteten.
Nielsen og Persson har vist, at værdi i IS-projekter bliver stærkere, når business cases knyttes til faktisk værdiskabelse og ikke kun til projektleverancer (Nielsen & Persson, 2017). Overført til Business Central betyder det, at Power BI-rapporter og automatiseringer bør prioriteres efter beslutningsværdi, ikke efter ønskelister om flere dashboards. (Og der er altid ønskelister.)
Ross, Weill og Robertson samt Sebastian og kolleger peger på, at stabilitet og digital fornyelse ikke er modsætninger, men komplementer. Et stærkt Business Central-setup er ikke et bureaukratisk benspænd for Power Platform. Det er forudsætningen for, at Power Platform kan bruges sikkert og med høj troværdighed (Ross et al., 2006; Sebastian et al., 2017).
Og så er der modenhedsspørgsmålet. Hvis virksomheden ikke har faste definitioner, reviewrytmer og ansvarslinjer for data, er den næste Power App sandsynligvis mindre vigtig end det næste datakatalog.
Business Central skaber ikke i sig selv indsigt. Systemet skaber et udgangspunkt, som først bliver strategisk værdifuldt, når virksomheden arbejder disciplineret med stamdata, ejerskab, governance og oversættelsen fra data til beslutning. Power BI og Power Platform er ikke genveje rundt om dataproblemer. De er forstærkere. Når datagrundlaget er stærkt, forstærkes værdien. Når datagrundlaget er svagt, forstærkes støjen.
Korrekt stamdata er ikke en baggrundsopgave. Det er den stille infrastruktur, som afgør, om virksomheden får klar indsigt eller bare mere elegant forvirring.
