De fleste virksomheder har det samme problem: data bor i forskellige systemer. Med Microsoft Fabric kan du samle dine data og bruge AI til at gøre dem tilgængelige for hele organisationen.
Sælgerne er i CRM. Økonomi er i Business Central. Der bliver brugt mere tid på at samle tal end på at handle på dem. Ingen har det samlede billede.
Microsoft Fabric samler data fra alle kildesystemer i én fælles platform, så hele organisationen arbejder ud fra det samme datagrundlag.
Når dataplatformen er på plads, kan AI og Copilot gøre data tilgængelige for langt flere end dem, der bruger Power BI i dag. En sælger, en indkøber eller en økonomichef kan nu spørge til rapporterne i naturligt sprog og få svar.
Jonas Kjeldsen og Andreas Feldstedt har holdt to live webinarer om netop det.
I det første ser vi på, hvordan du samler ERP- og CRM-data i Fabric og får ét samlet overblik over pipeline, omsætning og kapacitet. I det andet ser vi på, hvordan du gør din semantiske model klar til AI, så Copilot faktisk giver pålidelige svar i stedet for at gætte.
Du kan se optagelserne fra de to webinarer herunder.
Webinar 1: Få overblik på tværs af Business Central og CRM
Webinar 2: Gør din Power BI-model klar til Copilot og AI
Saml data og gør dem AI-klar med Microsoft Fabric
I mange virksomheder bor data i forskellige systemer. Med Microsoft Fabric kan du samle data og bruge AI og Copilot i BI-rapporterne.
Copilot i Power BI er nu tilgængelig for alle med Microsoft Fabric
Tidligere krævede Copilot til Power BI en dyr Fabric-kapacitet, men nu er det blevet tilgængeligt på alle niveauer.
Business Intelligence indlejret i Business Central
I dag kan du indlejre Power BI-rapporter direkte i Business Central, og det giver en meget nemmere adgang til indsigt for ERP-brugerne,
Hvordan kobler du bedst Power BI på din Business Central?
Hør hvilke muligheder du har, når du vil have Business Intelligence ved at integrere Power BI med din Business Central
Få et samlet overblik med Microsoft Fabric: ERP- og CRM-data i én platform
Microsoft Fabric blev lanceret i 2023 som Microsofts store satsning på en samlet data- og analyseplatform. De første år var produktet for umodent til seriøs brug, men det billede har ændret sig. Fabric er nu et stabilt og velfungerende produkt med god sikkerhed, versionsstyring og et voksende antal connectors. For virksomheder, der i dag kæmper med spredte data på tværs af ERP, CRM og andre systemer, er det værd at kigge nærmere på, hvad platformen kan gøre.
Denne artikel gennemgår de forretningsmæssige gevinster ved at samle data i Fabric, viser konkrete eksempler med ERP- og CRM-data, og giver et overblik over, hvad det kræver at komme i gang.
Forskellige systemer, forskellige sandheder
De fleste virksomheder kender problemet: sælgerne sidder i CRM-systemet, økonomifolkene sidder i ERP-systemet, og begge systemer registrerer mange af de samme ting (kunder, omsætning, aktiviteter), men på hver deres måde. Resultatet er forskellige Excel-ark på forskellige afdelinger, der siger forskellige ting.
Fabric er bygget til at løse det problem. Ved at trække data fra kildesystemerne ind i én fælles datamodel kan man definere, hvad “en kunde” er, hvordan churn beregnes, og hvad et kundesegment indeholder, uanset om dataen oprindeligt kommer fra Business Central, Dynamics 365 Sales eller et tredje system. Når de definitioner er på plads, kan hele organisationen rapportere på det samme grundlag.
Det handler om at opnå én version af sandheden i stedet for at have halvdelen af billedet i hvert system.
Salgspipeline der kan valideres mod realiseret omsætning
Et konkret eksempel er salgspipeline. Salgsmuligheder og pipeline-data lever typisk i CRM-systemet. Når salget er landet, og der bliver leveret og faktureret, sker det i ERP-systemet. Hvis de to verdener aldrig mødes, er det svært at validere pipelinen.
Med Fabric kan man forbinde hele kæden: fra et lead i CRM, til en salgsmulighed, til en ordre i ERP, til leverance, faktura og betaling. Det gør det muligt at evaluere, hvor gode virksomhedens forecasts er. Hvor mange af de salgsmuligheder, sælgerne vurderer til 70%, bliver reelt til omsætning? Forskydes pipelinen bare løbende, uden at nogen måler konverteringsraten?
Man kan også spore, hvor meget omsætning en given lead-kilde eller markedsføringskanal genererer over tid. Det kræver, at dataen er forbundet hele vejen fra marketing-event til betaling.
Kombineret forecast med omsætning, pipeline og kapacitet
Abakion bruger selv Fabric til intern rapportering, og et af de mest nyttige dashboards kombinerer tre datakilder: realiseret omsætning fra økonomisystemet, vægtet pipeline fra CRM og allerede bookede timer (kapacitet), der er solgt men endnu ikke leveret. Tilsammen giver de tre tal et samlet forecast for kvartalet, som kan holdes op mod budgettet.
I et konkret eksempel fra Q2 lå den realiserede omsætning på 4 mio. kr., pipelinen på 1,7 mio. kr. og kapaciteten oven i det, hvilket gav en samlet forventet omsætning på 11,4 mio. kr. for kvartalet. Dashboardet kan brydes ned på business units, så man kan se, hvor der eventuelt ligger under budget. Og jo længere frem i tid man kigger, desto større del af omsætningen udgøres af pipeline frem for bekræftede bookinger. Det ændrer risikoprofilen, og det er synligt i rapporten.
Den slags overblik kan en ledelse bruge uge for uge til at vurdere, om der skal justeres.
Indkøb og MRP-planlægning med CRM-data
Et tredje eksempel handler om indkøb. En indkøber sidder typisk i ERP-systemet og har ingen synlighed i, hvad der sker i CRM. Hvis der er store salgsmuligheder på vej ind, er det værdifuldt for indkøberen at vide det, så materialer kan bestilles i tide.
Med Fabric kan man give indkøbsfunktionen adgang til vægtede salgsmuligheder fra CRM, så de kan internalisere dem i MRP-planlægningen. Et alternativ er at skrive de vægtede salgsmuligheder direkte fra CRM over i ERP som salgsforecasts, men Fabric giver den samme indsigt uden at kræve integrationer direkte mellem de to systemer.
Power BI-rapporter der bor, hvor brugerne er
En vigtig pointe er, at Power BI-rapporter baseret på Fabric-data ikke behøver at leve i en Power BI-portal. For nogle brugere er det en barriere at skifte system for at se deres data. Rapporter kan embeddes i Business Central, i Dynamics 365 CRM, i Teams og i SharePoint.
Et eksempel: en sælger sidder på en account i CRM og kan se et 360-graders omsætningsdashboard med data fra ERP, direkte på kunden, uden at forlade CRM. Rapporten filtrerer automatisk på den valgte kunde. Det kræver, at der er et alignet stamdata-setup på tværs af systemerne, men når det er på plads, er det en stor gevinst for brugsfrekvensen.
En vigtig detalje er, at dataen i de embeddede rapporter kommer fra Fabric og ikke direkte fra kildesystemerne. Det betyder, at kildesystemerne ikke belastes af rapporteringsforespørgsler.
Sådan ser Fabric-arkitekturen ud
Rent teknisk trækker Fabric data fra kildesystemer ind i OneLake, som er platformens centrale datalager. OneLake gemmer data i et standardiseret, åbent format (Delta/Parquet), som alle værktøjer i Fabric kan arbejde med.
Herefter transformeres og renses de rå data. De mappes på tværs af systemer, datakvaliteten valideres, og der bygges en semantisk model (den samme motortype, der ligger under Power BI), hvor forretningslogikken defineres: beregninger, dimensioner, relationer. Den semantiske model er et kurateret lag, der altid er opdateret, og som er grundlaget for al rapportering.
Ovenpå den semantiske model bygges Power BI-rapporter, Excel-analyser, AI/Copilot-integrationer og eventuelle data science-modeller. Hele arkitekturen skalerer horisontalt, så man ikke løber tør for beregningskapacitet, selv med store datamængder.
Connectors: hvad er dækket, og hvor er der huller
Fabric har gode standardconnectors til de fleste Microsoft-produkter. Dynamics 365 Sales, Dataverse og Finance & Operations fungerer fint ud af boksen. Det samme gælder en række systemer inden for regnskab, marketing, e-commerce og projektværktøjer som Jira og Tempo. Tekniske kilder som SQL Server, Oracle, Snowflake og REST API’er er også understøttet.
Undtagelsen er Business Central. Standard-connectoren til BC er en OData-connector, der forespørger på tabellers API’er. Den har tre problemer: BC har typisk ikke de API’er, man har brug for, så de skal bygges først. Connectoren læser altid fuld load (hele tabellen, hver gang). Og hvis man har mange selskaber, skal connectoren mappes til hvert selskab for hver tabel, hvilket hurtigt bliver uoverskueligt.
Der er to alternativer. Det ene er BC2ADLS, som Microsoft oprindeligt udviklede, og som i dag er discontinued og kører som open source. Den er push-baseret og sender data ud af Business Central. Det andet er Abakions egen datareplikator, som er pull-baseret: dataplatformen beder om de ændringer, der er sket siden sidst, på tværs af alle selskaber. Forskellen mellem de to tilgange har praktiske konsekvenser, som er værd at undersøge nærmere, hvis man har BC som kildesystem.
Hvad er der sket i Fabric siden lanceringen
Fabric var ret buggy ved lanceringen i 2023, og der manglede vigtige funktioner. Siden er der sket en del:
Data Activator gør det muligt at sætte logiske tests op i en brugergrænseflade, så forretningen kan få notifikationer ved specifikke datahændelser. Det kan være en KPI, der krydser en grænseværdi, eller en kunde, der mangler en branchekode i et kildesystem. Notifikationerne kan målrettes den ansvarlige person.
Git-integration og CI/CD er kommet på plads. Det var ikke med fra start, men det er en forudsætning for løbende udvikling af en dataplatform, og det fungerer nu.
OneLake Security giver adgangskontrol ned til tabel-, række- og kolonneniveau, og rettighederne nedarves, uanset hvor data bliver brugt i Fabric. Microsoft Purview-integration til GDPR-scanning og compliance er også understøttet.
Helt nyt (maj 2026) er Microsoft Fabric Plan, som giver en brugergrænseflade til at oprette og vedligeholde budgetter direkte i Fabric, baseret på data i semantiske modeller. Det løser et klassisk problem i BI, hvor budgetter typisk har levet i Excel og er blevet importeret manuelt.
Licensering og økonomi
Fabric licenseres som kapacitet. Man køber en F-størrelse (F2, F4, F8, F16 osv.), der bestemmer, hvor mange beregningsressourcer man har til rådighed. Den mindste kapacitet, F2, koster ca. 1.800 kr. om måneden. De størrelser, man typisk ser ved seriøse installationer, er F8 eller F16. Ved en treårig binding giver Microsoft 41% rabat.
Kapaciteten kan sammenlignes med et taletidskort: der er en vis mængde ressource over tid, og forbruget varierer med belastningen. På de dage, hvor mange brugere tilgår de samme rapporter, kan kapaciteten blive presset. Man kan til enhver tid skalere op, og man kan pausere kapaciteten, når den ikke bruges, for at spare omkostninger.
Det vigtige er, at indgangsprisen er lav (under 2.000 kr. om måneden), og at platformen kan vokse med virksomheden uden at skifte teknologi.
Hvad tager tid i et Fabric-projekt
Fabric-projekter kan variere enormt i størrelse. De steder, der typisk tager tid, er: komplicerede forretningsbehov, der kræver grundig afklaring, før man kan modellere noget. Dårlig datakvalitet i kildesystemerne, som i værste fald gør det umuligt at bygge noget meningsfuldt ovenpå, og som kan kræve egne oprydningsprojekter. Og manglende standardintegrationer, som betyder, at der skal bygges custom-integrationer, typisk i Python.
En god forberedelse er at have klarhed over, hvilke forretningsprocesser man vil løfte med data, og at kende sine data godt nok til at vide, hvor skoen trykker. Abakion har udgivet guiden “Din rolle som BI-ansvarlig”, der gennemgår, hvordan man kortlægger og prioriterer de forretningsprocesser, der skal ind i en dataplatform, og hvordan man sammensætter et projekt.
Kom i gang med det, der giver mest værdi
Fabric er klar til seriøs brug. Det er ikke længere et produkt, man leger med. Det er en platform, man kan bygge sin datainfrastruktur på, hvis man er investeret i Microsofts økosystem. Indgangsprisen er lav, skaleringsmulighederne er gode, og værktøjerne til sikkerhed, versionsstyring og datakvalitet er modnet.
Det vigtigste første skridt er ikke teknisk. Det er at identificere de forretningsprocesser, hvor samlet data vil gøre den største forskel, om det er pipelinevalidering, forecast, indkøbsplanlægning eller noget helt fjerde. Start der, og byg videre.
Gør din Power BI-model klar til Copilot og AI i Microsoft Fabric
Når en virksomhed har samlet sine data fra ERP, CRM og andre kildesystemer i Microsoft Fabric, åbner der sig en ny mulighed: at lade AI arbejde med de data. Fabric har i dag to AI-funktioner, der gør det muligt at stille spørgsmål til sine data i naturligt sprog. Den ene er Copilot i Power BI, som de fleste vil møde først. Den anden er Fabric Data Agents, som er mere avanceret og fleksibel.
Begge dele kræver, at fundamentet er på plads: en velfungerende dataplatform med gode semantiske modeller. AI kan ikke kompensere for dårlig datakvalitet eller mangelfuld forretningslogik. Men når modellerne er i orden, kan AI gøre data tilgængelig for langt flere mennesker i organisationen end dem, der i dag bruger Power BI.
Copilot og Fabric Data Agents: to forskellige værktøjer
Copilot i Power BI er et discoverability-værktøj. Brugeren skriver et spørgsmål i naturligt sprog, og Copilot finder svaret i den semantiske model. Det kan være en sælger, der spørger til pipeline og omsætning, en økonomimedarbejder, der vil have en opsummering af kvartalets tal, eller en lagermedarbejder, der vil vide, hvor de største udfordringer er. Brugeren behøver ikke vide, hvad et measure hedder, eller hvilken tabel dataen ligger i.
Fabric Data Agents er mere avancerede og tiltænkt som områdespecifikke agenter. En Data Agent kan fx være en projektlederhjælper eller en salgsagent, der kigger på bestemte data. Den kan tilgås i Teams, i Copilot Studio eller via API og kan dermed integreres i andre løsninger. Data Agents kan også kigge på tværs af flere datakilder, men de er beregnet til et afgrænset emneområde.
For de fleste virksomheder er Copilot i Power BI det naturlige første skridt. Det er mindre komplekst at sætte op og giver hurtig værdi for slutbrugere.
Data bliver tilgængeligt for flere end BI-brugere
BI har historisk bevæget sig fra faste rapporter (send en mail, få et udtræk) til self-service, hvor forretningsbrugere selv bygger visualiseringer og analyser oven på en semantisk model. AI tilføjer et nyt lag: nu kan også brugere, der ikke kender Power BI, DAX eller datamodellen, stille spørgsmål og få svar.
Det er særligt værdifuldt i situationer, hvor data går på tværs af systemer. En person, der er uddannet i CRM-systemet, har ofte brug for data fra ERP, men kender ikke nødvendigvis ERP-strukturen. Med Copilot kan vedkommende bare spørge. Al sikkerhed følger med: Copilot respekterer den row-level security og object-level security, der er sat op i Power BI. En HR-medarbejder ser kun de data, vedkommende har adgang til, også når AI leverer svaret.
Tre scopes: rapport, app og globalt
Copilot i Power BI kan bruges i tre forskellige scopes, og valget påvirker svarenes kvalitet.
På rapportniveau ser Copilot kun den side, brugeren har åben. Det giver de mest præcise svar, fordi konteksten er snæver. På app-niveau kan Copilot se alle sider og rapporter i en app og kan kigge på tværs af semantiske modeller, men den baserer altid sit svar på én model ad gangen. Hvis der er flere, kan den enten antage, hvilken model der er relevant, eller spørge brugeren. På globalt niveau kan Copilot tilgå alt, hvad brugeren har adgang til. Det er nyttigt, hvis man slet ikke ved, hvor en bestemt rapport ligger, men svarene bliver typisk mindre præcise.
Tommelfingerreglen er: jo snævrere scope, jo bedre svar. Brug rapportniveau, når det er muligt, og globalt scope kun som opslagsværktøj.
Tre typer svar og deres pålidelighed
Når Copilot svarer, kan svaret komme i tre former med forskellig pålidelighed.
Det bedste svar refererer direkte til eksisterende visualiseringer i rapporten og kan highlighte, hvor tallet kommer fra. Her kan brugeren verificere svaret med det samme. Det næstbedste svar er baseret på filtreringer eller udtræk af data, der ikke er direkte synlige i rapporten, men som bygger på den semantiske models measures. De er typisk korrekte, hvis modellen er korrekt opsat. Det tredje og mest risikable svar er, når Copilot skriver ad hoc DAX for at beregne noget, der ikke findes som et eksisterende measure. Her kan forretningslogikken afvige fra det, organisationen har defineret, og svaret kræver ekstra validering.
Best case er, at Copilot leder brugeren hen til det kuraterede, godkendte indhold i rapporten. Det bør være målet for langt de fleste scenarier.
Garbage in, gospel out: AI forstærker datakvalitetsproblemer
Et velkendt princip i BI er “garbage in, garbage out”. Med AI bliver problemet større, fordi AI svarer med stor selvtillid. Det kan være svært for en bruger at gennemskue, om et svar er korrekt eller bygger på forkerte antagelser, når det præsenteres i et velformuleret, selvsikkert sprog.
To konkrete eksempler fra praksis illustrerer det.
I det første eksempel blev Copilot spurgt om omsætningen i sidste kvartal. Svaret så fornuftigt ud, men var forkert. Årsagen var, at den semantiske model indeholdt et measure kaldet “Revenue Old”, som var et forældet measure markeret med “Old”, fordi det ikke længere skulle bruges. Copilot tolkede “Old” som “historisk” og brugte det til at besvare spørgsmålet.
I det andet eksempel blev Copilot bedt om at liste de ti største kunder. Listen så fin ud, men var forkert. Copilot havde baseret svaret på individuelle kundeenheder (solo), mens virksomheden altid rapporterer på bill-to-kunder, altså faktureringsgrupper med moderselskab. Den skelnen stod ikke beskrevet i modellen, og Copilot lavede derfor en forkert antagelse.
Begge fejl skyldes mangler i den semantiske model, ikke i AI’en selv. Copilot brugte de data, den havde adgang til, men manglede konteksten til at fortolke dem korrekt.
Sådan forbereder du din semantiske model til AI
Power BI Desktop har fået en “Prep Data for AI”-funktion, der samler de vigtigste forberedelser. Her er de konkrete værktøjer.
Beskrivelser på tabeller, kolonner og measures giver AI kontekst til at forstå, hvad de indeholder. Navne alene er ikke altid tilstrækkelige. “Revenue Old” er et godt eksempel: uden en beskrivelse kan AI ikke vide, at det er et forældet measure. Alle measures og tabeller bør have en kort, præcis beskrivelse af deres forretningsbetydning.
Synonymer og forretningssprog skal skrives eksplicit ind i modellen. Hvis organisationen bruger forkortelser eller branchespecifikke termer, kan AI ikke gennemskue dem, medmindre de er registreret. Det gælder også begreber, der har en specifik intern betydning, som “kunde” i eksemplet ovenfor.
Schema-simplificering gør det muligt at begrænse, hvad AI kan se i modellen. Kolonner, der allerede er skjult for brugere, er som udgangspunkt også skjult for AI, men man kan afgrænse yderligere. Hvis en semantisk model kun skal bruges af AI til at besvare lagerspørgsmål, kan man fjerne data om budgetter og salg fra AI’s synsfelt. Det reducerer risikoen for fejltolkninger.
Verified Answers er foruddefinerede spørgsmål knyttet til specifikke visualiseringer. Når en bruger stiller et spørgsmål, der matcher, leder Copilot direkte hen til den relevante visualisering i stedet for at beregne svaret selv. Det giver de mest pålidelige svar. En anbefaling er 3-5 verified answers per visualisering, men man bør ikke overdrive det. Hvis alle visualiseringer har foruddefinerede svar, mister man den fleksibilitet, der gør AI værdifuld, og ender med noget, der minder mere om et statisk menukort.
En overordnet modelbeskrivelse i markdown-format kan skrives på modelniveau. Den giver AI en forståelse af, hvad modellen handler om, og hjælper den med at vurdere, om modellen overhovedet er relevant for et givet spørgsmål.
Et vigtigt trick: bed AI om ikke at antage
En instruktion, der har vist sig at have stor effekt, er at skrive i modellens beskrivelse, at agenten ikke skal lave antagelser, men i stedet spørge brugeren, når den er i tvivl. Det betyder, at brugeren typisk skal lidt mere frem og tilbage med Copilot for at nå svaret, men til gengæld undgår man situationer, hvor AI laver en forkert antagelse og præsenterer resultatet som et faktum.
Sikkerhed følger med
Copilot og Fabric Data Agents respekterer den eksisterende sikkerhedsmodel i Power BI. Row-level security, sensitivity labels og object-level security gælder også, når AI leverer svar. Men det kræver, at sikkerhed er sat op. Hvis man ikke ønsker, at brugere ser sensitive data (fx fraværsdata), er det ikke nok at fjerne det fra en rapport via et filter. AI kan stadig finde det, hvis row-level security ikke er konfigureret.
Licensering: Copilot bruger Fabric-kapaciteten
Copilot i Power BI kræver ikke en separat licens. Den bruger den Fabric-kapacitet (F2, F4, F8 osv.), som organisationen allerede har. Det er consumption-baseret: hver forespørgsel bruger en del af kapaciteten, men det er typisk ikke en stor del. Hvis forbruget alligevel vokser, kan man begrænse, hvilke brugere der har adgang til Copilot.
Power BI Pro er fortsat nødvendig for at se og bruge Power BI-rapporter, men Pro-licensen alene giver ikke adgang til Copilot. Der skal en Fabric-licens til, og den er ikke per bruger.
Start småt, iterér, og acceptér at AI vil svare forkert
AI på data er ikke et produkt, man ruller ud og så er færdig. Det er en iterativ proces. Copilot vil give forkerte svar, særligt i starten. Det vigtige er at have en kultur, hvor brugere melder tilbage, når de får et mærkeligt svar, så modellen kan forbedres løbende.
En god praksis er at vedligeholde 10-30 testspørgsmål, man kender svaret på. Hver gang der er lavet ændringer i den semantiske model, stilles de samme spørgsmål for at verificere, at svarene stadig er korrekte.
Den investering, en virksomhed har lavet i at bygge en god dataplatform og gode semantiske modeller, er den investering, der betaler sig, når AI kommer ovenpå. Men AI kan ikke løse det, der ikke allerede er på plads i fundamentet.