Din rolle som BI-ansvarlig
Del 3: Teknik
Som almindelig bruger kan man sagtens tænke, at Power BI vel ”bare” skal kobles sammen med Business Central, og så kan vi bruge ERP-data i Power BI.
Det er en helt forståelig tanke, og Microsoft får det også til at lyde nemt i deres reklamemateriale, men det er desværre ikke helt så simpelt i praksis.
Data kommer ikke ud af Business Central i et format, som er særlig godt til rapportering.
Der skal foretages en transformation, for at vi kan anvende data, sådan som vi gerne vil i Power BI.
Og dette afsnit giver dig overblik over, hvilke værktøjer vi skal have i spil, for at du har et velfungerende Business Intelligence-system til dine ERP-data.
Du er blevet kaldt ind på CFO’en kontor. Budskabet er klart, og ordene falder nogenlunde således:
“Jeg er med på, at du gerne vil begynde med en masse research, men der er efterhånden gået lang tid, så jeg tænker, at vi skal have noget sat i gang nu.”
CFO’en har set en smart pakkeløsning med Power BI, som man kan komme i gang med på en eftermiddag, og det giver nogle flotte dashboards. “Kan vi ikke bare begynde der?” lyder spørgsmålet.
Efter mødet støder du på den it-ansvarlige, som har den stik modsatte holdning. Forelskelsen i det store Microsoft Fabric data warehouse skinner tydeligt igennem, og du tør slet ikke nævne den pakkeløsning, du lige har fået besked på at begynde med.
CFO vil have en delebil, og den it-ansvarlige vil have en racerbil. Men det gode spørgsmål er: Hvad er det rette valg?
En pakkeløsning kan være en udmærket begyndelse, men hvad sker der, hvis nogen senere får behov for at få data opdateret jævnligt, og har 40 mio. poster i et andet system, som også skal inkluderes som datakilde?
At begynde stort eller småt. Begge dele kan være det rette valg, hvis det matcher virksomhedens aktuelle behov, og kan udvides til fremtidige behov.
Den tager vi lige igen for at være sikker:
Matcher i dag. Forberedt til fremtiden. Det er det rette valg.
Derfor er det vigtigt, at du har været gennem del 1 og del 2 i denne guide, før vi nu tager hul på teknikken.
Overblik over den tekniske løsning
Her i teknik-afsnittet tager vi udgangspunkt i Microsoft Power BI som værktøj til visualisering, og ERP-systemet Microsoft Dynamics 365 Business Central som kildesystem.
Som nævnt kan du vælge at begynde med en enkel pakkeløsning, men du kan også vælge et rigtigt Data Warehouse med Microsoft Fabric. Det gennemgår vi alt sammen om lidt.
Og bare fordi vi nu fokuserer på Business Central som datakilde, så forhindrer det dig ikke i at tilføje mange flere kildesystemer, eller at begynde et helt andet sted, men BI-rapporter med ERP-data er en klassiker, så det er der, vi begynder.
Tegningen giver dig et overblik over den tekniske løsning, og lad os først gennemgå den fra venstre til højre, og så går vi i detaljer bagefter.
Grundlaget for alt er kildesystemet, som i dette tilfælde er Business Central, men som ellers kan være en hel række af kildesystemer.
Den første opgave er at skabe adgang til data. Business Central er født med teknologi, der kan udstille data til dette formål. Det kalder man et API. Men Business Centrals API er ret begrænset, og ofte er man nødt til at finde en løsning til at udstille og skabe adgang til flere data.
Så skal vi have en service, som replikerer data over i en anden database, som Power BI kan anvende. Databasen for et BI-værktøj er anderledes end databasen for en ERP-løsning, og derfor er det nødvendigt at kopiere data over i et Data Warehouse.
BI-værktøjet kan teknisk set ikke køre direkte på ERP-databasen, og det ville også være et performancemæssigt mareridt.
Den database, som data bliver replikeret til, kalder man et Data Warehouse. De fås i mange størrelser og kompleksiteter.
Den mest simple er bygget ind i maven på Power BI, og den er så enkel, at en BI-konsulent næppe ville kalde det for et rigtigt Data Warehouse – og i den større ende finder man egentlige Data Warehouses med staging-lag og mange muligheder af frihedsgrader for behandling af data.
Vi tillader os i denne sammenhæng at bruge udtrykket ”Data Warehouse” som en fællesbetegnelse for de databaser, som kan fungere som grundlag for Business Intelligence.
I et Data Warehouse foregår en transformation af data, til dels for at gøre data brugbare for visualiseringsværktøjet Power BI, men også for at sammenkøre data, udregne nøgletal, og skabe de muligheder for at gruppere, afgrænse og sortere, som man ønsker, og meget mere.
Det sidste skridt er visualisering af data. Her kommer Power BI på banen, hvor brugeren har rapporter og dashboards til rådighed, som viser de data, der er forberedt i Data Warehouse.
Det er de elementer og processer, der skal være styr på for at bruge Power BI til at analysere data fra Business Central (og andre kildesystemer). Det kan som sagt løses både simpelt og avanceret, og det afhænger helt af dit ambitionsniveau, hvilken løsning du bør vælge.
Nu gennemgår vi mulighederne, fra simpel til avanceret, og vi lægger især vægt på de emner, som er afgørende for, hvor avanceret en løsning, du skal vælge.
Målet er at klæde dig på til at træffe det valg, som matcher dine behov, og at du på forhånd har indblik i, hvor meget du kan vokse i den løsning, du har valgt.
Den simple løsning
Den simple løsning er, at Power BI får lov til at stikke snablen direkte ned i Business Centrals data. Det foregår via en teknologi, der hedder OData.
Adgangen til data kan du løse ved at installere en app i Business Central, og så skal du sikkert have en smule konsulenthjælp til at koble Power BI sammen med Business Central. Men derfra er opgaven ikke særlig teknisk.
Power BI vil placere data i sit eget dataformat inde i Power BI-servicen, og der er ikke noget rigtigt Data Warehouse, men der er en slags dataplatform indbygget i Power BI, hvor man kan transformere sine data til en vis grad.
Den simple løsning består således af 2 elementer: Adgang til data + Power BI rapporter, og de to elementer gennemgår vi nu.
Det scenarie forudsætter, at man kan anvende Business Centrals datastruktur uden større transformationer.
Med den simple løsning har vi begrænsede muligheder for at modulere data, men simple transformationer af data kan sagtens lade sig gøre direkte i Power BI. Beregninger af nøgletal vil altid foregå i Power BI, uanset om der er et eksternt Data Warehouse eller ej.
Adgang til data
Adgang til data i Business Central foregår enten via Microsofts standard-API, eller ved at du installerer en app fra Microsoft AppSource med et bedre API, eller at du hyrer en udvikler til at skabe et nyt API. Det er de 3 muligheder, du kan vælge mellem.
Det er en begrænset mængde data, Microsofts standard-API’er giver adgang til. Man løber nemt ind i, at man ikke har adgang til alle de kolonner i centrale Business Central tabeller, som man har behov for.
Så har man behov for en løsning til at udstille de nødvendige data.
I den situation kan man vælge at abonnere på en app, der hedder Data Access, som vi i Abakion har udgivet på Microsoft Marketplace, eller en tilsvarende app fra en af vores kolleger i branchen.
Besøg Microsoft Marketplace
Med en app fra Microsoft AppSource får du en standardløsning, som er klar til brug, og giver adgang til et udvalg af tabellerne i Business Central. Den koster et abonnement, men det er til gengæld leverandøren, som er ansvarlig for vedligeholdelse.
Når der sker ændringer i Business Central, så er leverandøren forpligtet til at opdatere app’en, så den uafbrudt virker efter hensigten.
En app er en “managed service”, som du kan vælge, hvis du vil tage en af de tekniske udfordringer ud af ligningen.
Du kan naturligvis hyre en udvikler til at lave de samme API’er, som du får med en app, men du skal være opmærksom på, at det er lidt af en specialkompetence. Det er langt fra alle Business Central-udviklere, som har erfaring med at skabe API’er.
Og så er der naturligvis de åbenlyse forskelle, at du selv skal betale for udviklingsprojektet samt de løbende ændringer, som nye versioner af Business Central kræver, men at du slipper for at betale abonnement.
Vi har i Abakion valgt app-vejen, fordi vi ikke vil opfinde den dybe tallerken hver gang, men det er naturligvis et spørgsmål om, hvad man foretrækker.
Standardpakke
Når du med ”den simple løsning” har adgang til Business Central-data, så mangler du kun at etablere de rapporter i Power BI, som du gerne vil have.
Microsoft kalder det low-code. Indlæringskurven er ikke særlig stejl, og det kræver ikke udvikler-kompetencer at arbejde med ERP-data i Power BI. Det kræver i højere grad indsigt i datastrukturen i de ERP-data, du vil arbejde med.
Du kan vælge at anvende en færdigbygget rapportpakke i Power BI, i stedet for at bygge dine egne dashboards og rapporter i Power BI. Så er det plug’n’play. Det er bare at tegne et abonnement.
En standardpakke er ikke blot en nem måde at komme i gang på. Den datamodel, som følger med en standardpakke, er også et rigtig godt grundlag for, at du kan bygge dine egne nye rapporter i Power BI.
Datamodellen i en standardpakke indeholder som regel flere muligheder, end der er udnyttet i de rapporter, som pakken indeholder. Det betyder, at du (eller en konsulent) nemmere kan bygge videre på rapporterne, eller oprette nye rapporter – uden at skulle etablere en ny datamodel.
I en standardpakke er det egentlig mere datamodellen, som er “produktet” du skal betale for, end de rapporter der er inkluderet i pakken. Det er rapporterne, du visuelt oplever som “produktet”, men det er ikke svært at bygge rapporter i Power BI, når du har styr på designprincipperne, du lige har læst om. Det er datamodellen, arbejdet er lagt i.
Når du overvejer en standardpakke af rapporter til Power BI, så kig under motorhjelmen og spørg om datamodellens omfang.
Se eksempel på en standardpakke til Finans på abakion.dk/finans og prøv selv løsningen online.
Emner der øger kompleksiteten
Nu har vi den simple løsning på plads. Og nu skal vi tale om en række emner, som potentielt øger kompleksiteten, og som kan skabe et behov for et ”rigtigt” Data Warehouse, et data-replikeringsværktøj og transformation af data for at gøre alt klar til visning i Power BI.
Nu taler vi først om alle de vigtige emner, og så beskriver vi bagefter ”den avancerede løsning” med et Data Warehouse.
Datamængder
Hvis du fx har 100.000 finansposter og gerne vil have data opdateret i Power BI en gang om dagen, så er den simple løsning perfekt. Det er ikke et kompliceret scenarie, og du kan næsten klare tingene på egen hånd.
Men det er en forudsætning for ”den simple løsning”, at datamængderne ikke bliver for store. Du kan ikke bede Power BI om at trække mange millioner finansposter direkte fra Business Central.
Man kan ikke sige entydigt, hvor grænsen for datamængden går, men jo flere poster, des større risiko er der for, at Power BI får datamængderne galt i halsen.
Power BIs interne datalagring er slet ikke et Data Warehouse, men det fungerer i praksis godt, og det har mange funktioner, men det er bygget til mindre datamængder, og der er en begrænsning i kapacitet.
Microsoft har sat en licensmæssig grænse for hvor meget data, der kan håndteres direkte i Power BI, og den grænse øges, hvis man køber et større abonnement, så det er ikke en teknisk grænse men en licensmæssig.
Men når vi taler om den simple løsning med direkte forbindelse til Business Central, så er det ikke den licensmæssige grænse, der er problemet. Grænsen er i skrivende stund 10gb, og med den simple løsning vil du opleve kapacitetsproblemer allerede under 1gb.
Men det er ikke nødvendigvis et problem, fordi mange af de brugsscenarier, vi vil anvende den simple løsning til, er langt under 1gb i størrelse.
Opdateringsfrekvens
Og hvis du har behov for hyppige dataopdateringer, så øger det også den samlede mængde af data, som skal flyttes.
Mange vælger én daglig opdatering, måske om natten så opdateringen ikke forstyrrer brugerne. Men det kan også være, at en ugentlig eller månedlig opdatering er nok til det konkrete behov. Alt det virker fint i den simple løsning.
Det er vigtigt at vide, at når Power BI opdaterer data, så sletter den alle de gamle data, som den har gemt i sit interne format, og så henter den en frisk kopi af det komplette datasæt fra Business Central.
Det tager lang tid at eksekvere. Og det er en af årsagerne til, at denne løsning er sårbar over for store datamængder.
Power BI risikerer at ramme en time-out, fordi den simple løsning er designet til mindre datamængder. Hvis et af systemerne slår en lille bøvs undervejs, så fejler den samlede opdatering, og så er der ikke friske data den dag.
I den almindelige Power BI, som hedder Power BI Pro, der kan man planlægge op til 8 opdateringer af data i døgnet, som man kan placere som man vil.
Nogle opdaterer data en gang i timen i løbet af 8 timers åbningstid, mens andre fordeler opdateringer over døgnet. Det fungerer fint med den simple løsning, så længe datamængderne ikke er for store til at Power BI kan nå at ekspedere det.
Med Power BI Premium kan man planlægge mange flere opdateringer, 48 i døgnet i skrivende stund. Så kan du opdatere data hver halve time døgnet rundt. Men det er stadig hele datasættet, der skal opdateres hver gang, så det skal ikke tage særlig mange minutter at udføre en opdatering – for det er ikke hensigtsmæssigt, at data-replikeringen kører hele tiden uden pauser.
Hvis du ønsker at få data opdateret hyppigt, fx en gang hver time eller hvert 15. minut, så skal Power BI nå at hente det komplette datasæt, inden den skal gentage hele manøvren igen om 15 minutter. Det er svært at få til at fungere godt i praksis, og det bliver for stor en opgave i den simple løsning.
Nu lyder det måske som om, at den simple løsning er problematisk, men det er slet ikke tilfældet. Den er god til rigtig mange formål. Du skal bare vide, at hvis du øger kompleksiteten eller datamængden, så rammer du på et tidspunkt loftet.
Transformation af data
Når du har behov for at transformere de data, som skal vises i Power BI, så står du i grænselandet mellem den simple løsning og den avancerede med et Data Warehouse.
Transformation af data handler om at foretage en behandling af data, uden for kildesystemet. Power BI kan sagtens håndtere nogen grad af transformation af data, men i komplekse scenarier er det en fordel at anvende et Data Warehouse.
Transformation kan fx være logik, som udleder en konklusion af de data, som er til rådighed, og beriger data med konklusionen.
Lad os tage et eksempel: Række 1 har en værdi på 53, og række 2 har en værdi på 87. Hvis logikken foreskriver, at over 60 klassificeres som ”høj”, og under 60 som ”lav”, så vil data blive beriget med, at række 1 er ”lav”, og række 2 er ”høj”. Den klassificering kan så anvendes i en Power BI-rapport, men klassificeringen ligger ikke i kildesystemet.
Det er et eksempel på data-transformation, og dette eksempel kan faktisk sagtens klares i den simple løsning, men der kunne også være tale om datavask, samkøring af data fra flere kilder, omformattering af data, beregning af nøgletal og meget mere.
Findes data overhovedet?
Du kan løbe ind i den udfordring, at din datakilde slet ikke understøtter den rapportering eller analyse, som du ønsker. Det kan være fordi data ligger i Excel eller i et ustruktureret format, eller at de ønskede data slet ikke findes i kildesystemet.
Hvis du fx vil analysere tendenser inden for langtidssygdom og korttidssygdom i Business Intelligence, men i dit tidregistreringssystem bliver sygdom ikke kategoriseret på en brugbar måde – så vil du være nødt til at ændre registreringspraksis, for at du har data til at udføre analysen.
Hvis du gerne vil analysere ‘perfect order fulfillment’, dvs. hvor stor en procentdel af kundeordrerne der er leveret perfekt med rette antal på rette tid, så mangler du måske også data i kildesystemet. Der er registreret en realiseret leveringsdato på ordren, men måske mangler du at registrere den oprindeligt aftalte leveringsdato. Og det er netop denne, der skal indgå i beregningen. Ordren indeholder måske også en erstatningsvare, men den vare, som kunden oprindeligt bestilte, er blevet slettet fra ordren. Det kræver både en ændring i registreringspraksis, men også en systemændring i kildesystemet, hvis du skal have data til din analyse i Business Intelligence.
På denne måde kan du opleve, at din Business Intelligence-strategi ikke kun handler om opsætning af Power BI, men at den også griber ind i din registreringspraksis, dine forretningsprocesser, og i kildesystemer som fx dit ERP-system.
Det er grunden til, at vi anbefaler, at du lægger en BI-strategi og kortlægger en projektportefølje, inden ERP-projektet eller andre store projekter om forretningssystemer begynder.
Historik
Historik er et spændende emne, for det afhænger af, om kildesystemet er opbygget med eller uden historik på det område, som du ønsker at analysere. Nogle gange er historikken indbygget i datakilden, og andre gange er det ikke.
Et eksempel kunne være tidsregistrering. Alle historiske tidsregistreringer ligger i kildesystemet, så hvis du ønsker at analysere en tendensudvikling af antal registrerede timer, så er den nødvendige historik tilgængelig i datakilden.
Men i samme eksempel kunne det være en udfordring, hvis du vil analysere udviklingen per afdeling. Medarbejderens tilhørsforhold til en afdeling er typisk registreret på medarbejderen og ikke på den enkelte tidsregistrering, så hvis en medarbejder skifter afdeling, så vil alle historiske tidsregistreringer også skifte afdeling, og det er jo ikke korrekt. I dette tilfælde er historikken ikke indbygget i datakilden.
Et andet eksempel kan være, at salgsledelsen vil gerne analysere udviklingen over tid i den vægtede pipeline i salgsafdelingen. En CRM-løsning kan sagtens vise den aktuelle vægtede pipeline, men der er typisk ikke nogen registrering af, hvad den vægtede pipeline var i går, og i forgårs osv. I dette tilfælde er der ingen historiske data.
Historik kan stille krav til systemændringer i kildesystemerne, og til ændrede registrerings-processer i din organisation.
Den bedste løsning er at indbygge historikken i kildesystemet, for det er der, data hører hjemme. Man kan også lægge et dagligt snapshot af data i et Data Warehouse, for på den måde at skabe historik, men det er en metode med nogle forbehold og forudsætninger, som vi gerne vil gå i detaljer med en anden gang, hvis du har lyst til at lægge øre til det.
Men lige nu skal du blot vide, at hvis du ønsker at analysere historik, så har du afgjort behov for et Data Warehouse, og du bør kortlægge dine rapporteringsbehov så tidligt i processen, at du kan nå at øve indflydelse på kildesystemet og registreringsprocesserne.
Mange datakilder
De fleste virksomheder har mange IT-systemer, og hvis man ønsker at rapportere på tværs af systemerne, så skal Business Intelligence-systemet være klar til at håndtere flere datakilder.
Ud over ERP, så har du måske IT-systemer til HR, salg (CRM), kundeservice, tidsregistrering, lagerstyring, kørende teknikere, osv.
Det kan fx være, at du gerne vil have en rapport, der sammenligner sidste års omsætning med dette års realiserede omsætning, igangværende arbejde, et salgsforecast og den aktuelle vægtede pipeline fra salgsafdelingen. Det kræver en samling af data fra ERP og CRM.
Den simple løsning med OData kan principielt godt anvendes, når der er flere datakilder. Men de rapporter og analyser, som du formentlig gerne vil have på tværs af datakilderne – de har sikkert en kompleksitet som gør et Data Warehouse relevant.
I eksemplet med data fra CRM og Business Central kan vi udtrække data fra Business Central med Data Replicator eller Data Factory, og i CRM-løsningen har Microsoft faktisk indbygget et tilsvarende værktøj, så det dataudtræk er relativt nemt at opsætte. Og de to datakilder skal samles i et Data Warehouse og transformeres til det datagrundlag, vi gerne vil have i rapporten i Power BI.
Hvis der ikke eksisterer et connector-værktøj til et bestemt kildesystem, så skal vi udvikle forbindelsen til kildesystemets API, så vi får de ønskede data overført til Data Warehouse i den rette frekvens. Det er en udvikleropgave, og det kan både være en stor eller en lille opgave, afhængigt af hvor godt dit kildesystem er forberedt til at udstille data.
Det er i et Data Warehouse, at vi samler data fra forskellige kilder og transformerer data. Når Power BI bagefter anvender Data Warehouse som kildesystem, så har Power BI ingen idé om, hvor mange kildesystemer der oprindeligt lå til grund for datasættet.
Sikkerhed
Sikkerhed er et vigtigt emne med mange aspekter.
Den interne sikkerhed, som er indbygget i kildesystemerne, skal naturligvis afspejles i Business Intelligence-rapporterne. Der kan være data, som kun må tilgås af bestemte medarbejdergrupper.
Et scenario kunne være, at medarbejderne kun må se deres egne tidsregistreringer, mellemlederne må se deres medarbejderes, HR-afdelingen må se alles, og ledelsen må se aggregerede tal.
På den måde har de fleste datasæt begrænsninger på, hvem der må se hvad.
Og så er der databeskyttelse, så man overholder GDPR. Det er vigtigt at have med i overvejelserne, men lige hvad angår ERP-data fra Business Central, så er der sjældent behov for at anvende personhenførbare data i rapportering. Og i så fald bør de data slet ikke gemmes i et Data Warehouse.
Vi anbefaler, at du får en GDPR-kyndig rådgiver til at vurdere din Business Intelligence, for det emne er din Business Central-konsulent og din Business Intelligence-konsulent som regel ikke juridisk ekspert i.
Inkrementelle opdateringer
Når datamængden i BI bliver større, eller når behovet for opdateringsfrekvens stiger, så er det værd at overveje ”inkrementelle” opdateringer af data.
”Inkrementel” betyder bare ”trinvis”, og inkrementelle opdateringer handler om, at data-replikeringen fra et kildesystem som Business Central til Data Warehouse kun behandler de data, som er ændret siden sidst. Det er ikke hele datasættet, der skal overføres hver gang – men kun “delta”, dvs. ændringerne.
Der er mange grunde til, at det er smart. Det belaster kildesystemet mindre, og det belaster BI-systemet mindre, og det forbedrer performance af begge dele. Og når replikeringen tager kortere tid, så kan opdateringerne planlægges med kortere mellemrum.
Og så er det færre data, der skal overføres, og hvis man anvender teknologi, der afregnes efter datamængder, som fx Microsofts Data Factory, så er der en ret stor prisforskel. Hvis man har store datamængder, så er det en markant prisforskel. Det er faktisk en af grundende til, at vi i Abakion har bygget værktøjet Data Replicator. Transaktionsafgifterne med Data Factory er alt for dyre i store projekter.
De fleste bliver overraskede over, hvor omfattende det reelt er at flytte data fra et kildesystem til et Data Warehouse.
Især hvis man skal opsætte nye integrationer til kildesystemers API’er, men også selv om det alt sammen er Microsoft-systemer. Det lyder enkelt at replikere data, men det er reelt omfattende.
Det er ikke særlig svært at koble Power BI sammen med Business Central, men hvis du har 5 regnskaber i Business Central, og du beder Power BI om at replikere alle data i Business Central en gang i timen, så går det hele i knæ. Inkrementel opdatering er et vigtigt emne, når opdateringsfrekvensen skal være høj.
Konsolidering af regnskaber
Mange virksomheder har flere regnskaber i Business Central, og når man gerne vil have Business Intelligence på tværs af alle regnskaber, så taler vi om konsoliderings-regnskaber og om eliminering.
For den udenforstående kan man sige, at konsolidering handler om, at man lægger flere selskabers data sammen til ét. Man samler alle aktiver, forpligtelser og andre finansielle poster. Så kan man i Business Intelligence se rapporteringen, som den ville se ud, hvis alle selskaberne var ét selskab.
Dette er slet ikke nogen svær opgave i Power BI – hvis blot udfordringen er løst i Business Central. Men det er den ikke altid, og derfor nævner vi emnet her.
Hvis selskaberne ikke har samme datastruktur, så er det ikke simpelt at lægge data sammen. Hvis kontoplanerne er helt forskellige, så skal de ‘mappes’ til hinanden, så data bliver sammenlignelige.
Hvis der er tilgodehavender og forpligtelser mellem selskaberne, så skal de elimineres. Det samme gælder intercompany-transaktioner, dvs hvis selskaberne har handlet med hinanden. At fjerne den slags data kalder man ‘eliminering’.
Nogle håndterer det via en Intercompany-app i Business Central, og dermed kan man sige, at elimineringen bliver forberedt i Business Central. Så kan du i Power BI vælge at se en rapport med data fra alle regnskaber, og så filtrere intercompany-posteringer fra. Men der er mange måder at løse det på, og der er mange niveauer af kompleksitet i behov.
Flere regnskaber kan i sig selv sagtens håndteres med den simple løsning, men den samlede vurdering af dine behov gør sikkert et Data Warehouse til en god idé.
Og så skal vi lige nævne, at kompleksiteten naturligvis bliver højere, hvis du har flere Business Central-konti, der skal konsolideres. Det kalder vi ‘tenants’ i IT-sprog. Det kan være, at du har 3 selskaber i én Business Central-konto, og et fjerde selskab i en separat Business Central-konto af sikkerhedsmæssige årsager.
Det er i Business Intelligence-forstand separate kildesystemer, selv om de begge to er Business Central.
Data warehouse
Nu skal vi tale om Data Warehouse og replikering af data.
Når ambitionerne er for store til den simple løsning, så har du behov for en mellemstation mellem Business Central og Power BI, hvor data kan samles og transformeres. Den mellemstation kalder vi et Data Warehouse.
Med et Data Warehouse løser vi mange af de begrænsninger, som vi har talt om: opdateringsfrekvens, datamængder, antal selskaber, driftsikkerhed, transformationsmuligheder osv.
De værktøjer, som vi anvender til at replikere data fra Business Central over i et Data Warehouse kan meget mere, end når vi i den simple løsning kobler Power BI direkte til Business Central med OData. Vi kan nøjes med at overføre ændringer siden sidst og opsætte en historik af ændringer, som giver mulighed for at analysere ændringer og tendenser i Power BI.
Som koncept indeholder et Data Warehouse meget mere end blot et replika af dine Business Central-data, og et Data Warehouse kan have mange forskellige former.
Men for nemheds skyld bruger vi bare udtrykket Data Warehouse som en fællesbetegnelse for den database, der fungerer som mellemtrin mellem kildesystemerne og Power BI, hvor vi også har mulighed for at transformere data til de visualiseringer, vi gerne vil lave i Power BI.
Replikering af data
Til at replikere data fra Business Central over i et Data Warehouse anvender mange værktøjet Data Factory, som er en Microsoft Azure cloud service. Data Factory kan hive data ud af Business Central og en masse andre kildesystemer og skrive ind i staging-laget i Data Warehouse. Typisk har et Data Warehouse en to- eller tre-lags logik, hvilket afhænger af kompleksiteten af dine behov.
Data Factory er et godt værktøj, det er peg-og-klik, og det fungerer godt, men i nogle tilfælde bliver det ret dyrt at anvende. Jo flere Business Central-regnskaber – og jo højere frekvens data skal opdateres med – des højere bliver prisen.
Hvis du har 15 tabeller i 1 regnskab med opdatering 1 gang i døgnet, så har Data Factory en fornuftig pris. Men hvis du har 20 regnskaber med opdatering hvert kvarter, så stikker prisen på at bruge Data Factory helt af.
Mange virksomheder oplever, at Data Factory er billigt i begyndelsen, men bliver ret dyrt når ambitionsniveauet senere stiger.
Når det bliver dyrt, så anvender vi i Abakion i stedet Data Replicator, som er vores eget standardværktøj, som er langt billigere, når datamængderne stiger.
Data Replicator anvender en Microsoft Azure-funktion til at forespørge data i Business Central. En Azure-funktion er “atomet” i Azure, som er den billigste funktion, og samtidig forsimpler Data Replicator overførslen allerede i forespørgslen, fordi den kan udnytte, at den er bygget specifikt til at trække data ud af Business Central.
Hvis der skal overføres 50 tabeller, og der er 20 regnskaber, så er det 1000 reelle tabeller, der skal forespørges og overføres, og det konsoliderer Data Replicator allerede i forespørgslen, så overførslen bliver simplere, og data er bedre transformeret til Business Intelligence-behov.
Det er en afvejning, hvad der bedst kan betale sig. Hvis man specialbygger overførslen i Data Factory, så koster hver kørsel noget mere, og hvis man bruger Data Replicator, så er det i stedet på abonnement.
Du vokser ikke ud af Power BI
Power BI er præsentationsværktøjet, og det er afhængigt af, at data er klargjort tidligere i fødekæden.
Derfor er al transformation af data færdiggjort i Data Warehouse, og i Power BI konfigurerer man, hvilke relationer der er mellem data, og man opretter ‘measures’, som er nøgletal, der beregnes.
Nu er du godt oppe i størrelse og kompleksitet, fordi vi har gennemgået alle de emner, som øger kompleksiteten i din Business Intelligence-løsning. Du har en masse datakilder, og du har et Data Warehouse, som transformerer data og gør alt klar til Power BI.
Når du anvender et Data Warehouse, dvs Microsoft Fabric eller en SQL Server, så er det et langt mindre problem at indlæse hele datasættet i Power BI i hver opdatering. Forbindelsen mellem Power BI og databasen performer markant bedre end med den simple løsning med OData, så ofte er det slet ikke noget problem at indlæse hele datasættet i Power BI hver gang, når du har Microsoft Fabric eller en SQL Server på banen.
Men hvis der fx ligger 100 millioner rækker af data i Data Warehouse, så vil det alligevel være ret omfattende at indlæse alle 100 millioner rækker i hver eneste opdatering.
Det performer bedre, hvis der kun overføres ændringer i data. Og den mulighed får du med en Data Warehouse-løsning. Det giver mulighed for at håndtere ret store datamængder, at vi kun overfører ændringer til Power BI.
Det er en løsning med stor kapacitet, og det betyder, at det i dag er svært at vokse ud af en Power BI-løsning, uanset hvor meget du hæver ambitionsniveauet.
Abakion er eksperter i Microsofts forretningsløsninger til ERP, CRM og BI til danske virksomheder. Vi leverer både enkle løsninger, der er klar til brug hos mindre virksomheder, og skræddersyede løsninger til større virksomheder.
Ring til os på 70 23 23 16
eller skriv til abakion@abakion.com
Vi giver gerne et godt råd, uanset om du vil handle hos os eller en anden Microsoft-partner.