Strategimøde om Business Central

Kapitel 1:
Byg dit ERP-projekt med moduler og skabeloner

Af: Anders Lindskov, Projektleder

Du kan sagtens kombinere standardløsninger, skabeloner og skræddersyet udvikling i ét projekt. Det gør dit ERP-projekt modulært og agilt, og det er nemmere at realisere en gevinst på kort sigt. Projektleder Anders Lindskov forklarer, hvordan du skal gribe det an.

Nu vil Anders Lindskov fortælle, hvorfor alle virksomheder i dag vil opdele deres ERP-projekter i små, kortvarige bidder. Anders Lindskov har årtiers erfaring inden for projektledelse og forandringsledelse, og han har en klar holdning til, hvordan man får succes med et ERP-projekt i dag. Og nu giver vi ordet videre til Anders. Hvad er det, vi skal tale om nu?

Vi skal tale om, hvordan man får et succesfuldt IT-projekt. Man kan sige, at det første handler om at vælge det rigtige projekt, men det kommer jeg ikke til at tale om i dag. Så vi arbejder under forudsætningen, at vi har valgt det rigtige projekt.

Så er der tre ting, der skal gå op i en højere enhed. Det er det, vi kalder projekttrekanten, når man er projektleder. Det handler om, hvad det er, vi skal lave, altså indholdet af projektet. Så er det tidsplanen, altså hvor lang tid det tager at levere. Og så er det ressourcer, både de penge, man skal betale til en eventuel IT-leverandør, men også den tid, medarbejderne selv skal bruge.

Når kunder kommer til os i dag, er der især ét parameter, de gerne vil have succes med, og det er tid. Som de fleste kender fra deres liv og arbejdsliv, går tingene hurtigt, og det gælder også i IT-verdenen. Her går det måske endda hurtigere end andre steder. Det betyder, at når kunder ringer til os en mandag, synes de, det ville være fantastisk at kunne komme i gang allerede torsdag. At få et projekt hurtigt i gang er en tendens, vi ser nu.

For 10 år siden blev man ofte mødt af en lang kravsspecifikation fra en kunde, som havde skrevet alt ned i et Excel-ark, typisk udarbejdet i samarbejde med et eksternt konsulenthus. Vi fik måske et Excel-ark med 400 krav, som vi skulle svare på. De havde brugt lang tid på at udarbejde det, og vi skulle bruge tid på at svare.

I dag kommer kunderne med en meget klar idé om, hvad de vil have. Ikke bare behovene, men konkrete ønsker til systemer og apps, de har læst om på nettet. De møder os med helt andre forventninger og en anden viden om løsningerne. Og de vil have det hurtigt. Det er en ny situation for os som konsulenter, og det betyder, at vi skal tænke anderledes i, hvordan vi leverer projekter.

Gør det projektet succesfuldt i sig selv?

For mange kunder er det en succes, at det går hurtigt.

I sig selv?

I sig selv. Fordi jo længere tid et projekt tager, jo mere kan nå at ske undervejs. Vi ved ikke, om en autokrat pludselig beslutter at invadere et naboland, så energipriserne tredobles. Eller om IT-direktøren siger op, og en ny direktør foretrækker SAP frem for Business Central, som ellers var forudsætningen. Eller om virksomheden bliver opkøbt af en anden virksomhed, som ændrer retningen.

Jo længere tid et projekt tager, jo mere kan ske, både i projektet og i omgivelserne, som kan afspore det. Det vigtige er at få leveret noget og derefter stoppe op for at vurdere, hvad det næste skal være. Jo længere tid jeg bruger, jo større risiko er der for at blive ramt af forandringer. Derfor bliver tid i sig selv enormt kritisk, og vi som leverandører skal kunne spille med på meget optimistiske tidsscenarier.

Er opskriften på succes i dag små korte sprint med korte mellemrum?

Vi vil i hvert fald sige, at jo bedre man er til at skære sit projekt op i små bidder, jo større sandsynlighed er der for succes. Jeg kan prøve at illustrere, hvad der sker, når et projekt vokser, og kompleksiteten øges.

Forestil dig et meget simpelt projekt med kun én leverance. Der er kun det, jeg skal forholde mig til. Tilføjer jeg en ekstra leverance, er der nu to leverancer, men også en relation mellem de to. Jeg skal altså forholde mig til tre ting. Udvider jeg til tre leverancer, har jeg pludselig tre relationer, som jeg skal tage højde for. Nu er der seks ting at styre. Med fem leverancer stiger antallet af relationer til ti.

Man skal ikke være stærk i matematik for at se, at kurven vokser voldsomt. Jo flere leverancer, jo mere komplekst bliver projektet. Med 100 leverancer er der cirka 5.000 relationer. Det er en model, men den illustrerer pointen: jo flere tandhjul, der skal passe sammen, jo mere komplekst bliver det.

Hvis jeg ændrer én lille ting, ændrer alt muligt andet sig også. Har jeg mange ting i spil på én gang, bliver det svært at komme i mål, fordi jeg hele tiden skal korrigere på mange parametre.

Derfor kan man med et simpelt projekt på fem leverancer vælge at tage dem én ad gangen. Så er der kun én ting at fokusere på, og fordelen er, at min go-live sandsynligvis bliver meget hurtigere. Hvis det oprindelige projekt var planlagt til et år, og jeg deler det op i fem dele, kan jeg levere den første del efter to-tre måneder.

Når jeg har leveret den del, begynder jeg at høste gevinster. Vi har lært hinanden bedre at kende i projektet, og vi har fået erfaring med løsningen. Næste gang vi planlægger, går det hurtigere, og måske leverer vi den næste del efter to måneder. Bryder man projektet op i bidder med kort tidshorisont, kan man få mere succes.

Og hvis vi så tænker på din projektledertrekant, så betyder opdelingen i små bidder, at scope på hver bid er overskueligt, økonomien er lettere at styre og måske kendt på forhånd. Risikoen er mindre, og projektet kan gennemføres hurtigere. Så tager man det bid for bid?

Ja, og det kan være en udfordring at finde de rigtige bidder. Men vi har øvet os i at tænke sådan. Det er ikke første gang, vi laver et ERP-system eller en BI-løsning. Vi har erfaret, at de fleste kunder vil have nogenlunde det samme.

Derfor kan vi lave pakker, som vi har gjort. Vi kan pakke projekter, ligesom når man køber en Lego tankstation. Den har vi forberedt, og vi kan levere den hurtigt. Hvis man vil have en brandstation, kan man få den i næste runde.

Det betyder, at vi kan levere hurtigt. Kunden skal dog acceptere, at pakken er, som den er. Hvis man har købt tankstationen med to benzinstandere, kan man ikke få fire fra start. Vi leverer de to, og senere kan vi bygge to ekstra. På den måde bevarer vi effektiviteten, fordi vi ikke ændrer i pakken undervejs.

Hvis man kan leve med det, kan man komme hurtigt ud over stepperne. Er man skarp på, hvad man vil have i første omgang, og hvad man kan vente med, får man et projekt, som er markant billigere, end hvis alt skulle forberedes og leveres på én gang.

I din erfaring, er det den eneste ulempe ved at tage projektet i bidder?

Jeg har svært ved at finde en reel ulempe, hvis man kan leve med at være inde i kassen. Det er klart, at vi ikke har kasser til alt, så i nogle situationer findes der ikke en pakke. Så er vi nødt til at gribe det anderledes an. Men jo mere af projektet man kan bruge kasser og færdigpakkede løsninger til, jo billigere bliver det, og jo nemmere bliver det at styre.

Hvem har så ansvaret for de enkelte dele? For i den gammeldags model, hvor man laver en kravsspecifikation, og leverandøren svarer på den, så tager leverandøren ansvaret for alle punkterne i svaret. Hvem har ansvaret her?

Her vipper ansvaret i højere grad over på kunden. Vi har en kasse, og vi kan forklare, hvad der er i den. Men om kassen passer til kundens behov, er det kunden, der skal tage stilling til.

Kunden skal altså selv se, at der er to benzinstandere i kassen.

Og vi hjælper med at kigge ned i kassen. Men vi sætter os ikke dybt ind i hele kundens verden, gennemgår alle forretningsprocesser og vurderer på den baggrund, om kassen passer. Vi vender det om og siger: vi har hørt og forstået så meget af din forretning i grove træk, at vi tror, den her kasse er den rigtige. Prøv at se, om det holder.

Hvis den tese holder, og kunden vurderer, at den gør det, så kan vi komme langt på kort tid. Hvis kassen ikke kan bruges, må man tilbage til den gamle model med at skrive alle krav ned og lade leverandøren tjekke dem igennem. Men det er den nye model med færdigpakkede løsninger, der vinder frem.

Er der ikke tilfælde, hvor den traditionelle model faktisk er den bedste?

Jo, nogle gange er den nødvendig. Hvis kunden har et meget specifikt behov, kan det give mening at lave noget tilpasset. Eksempelvis hvis kunden producerer elektronik i Vietnam, hvor de kan lave det billigere end i Danmark. Så er det afgørende at være hurtig og præcis i bestillingen af komponenter, fordi det tager tid at skaffe dem fra Fjernøsten.

For sådan en kunde kan det være vigtigt at bygge en særlig planlægningsmekanik ind i løsningen. Men når det handler om lager, produktion, finans eller salg, er der ofte ingen forskel fra andre virksomheder. Så koncentrerer vi os om det område, der er forretningskritisk, og laver noget tilpasset der.

Jeg har en arkitekt, der siger: vi skal behandle det komplicerede som kompliceret, og det simple som simpelt. I dette tilfælde er indkøb og planlægning kompliceret, resten er simpelt i den forstand, at det ligner, hvad vi gør i andre virksomheder. På den måde kan vi kombinere standardløsninger med kundetilpasninger.

Så som projektleder ville du lægge op til et projekt med standardbokse, men også med et særligt område, hvor virksomheden får udviklet noget unikt.

Præcis. Og tankegangen med at dele ting i bidder handler ikke kun om teknikken, men også om forandringen i virksomheden. Vi har et eksempel fra et advokatfirma.

Deres brancheløsning har et tidsregistreringssystem, men kunden har valgt ikke at bruge det, fordi de allerede har et velfungerende system. Advokaterne arbejder i det, og IT-afdelingen ved, at hvis de skifter system, rammer det alle advokater. Det ønsker de ikke, for advokaterne vil ikke forstyrres i deres arbejde.

Ved at holde tidsregistreringen udenfor projektet kan de minimere kompleksiteten. Det bliver en mindre teknisk løsning, men de undgår også at ramme en brugergruppe, der ikke har lyst eller tid til at deltage i projektet. Så kan tidsregistreringen tages med senere, hvis der viser sig at være en god business case.

At tænke i bidder gælder altså både teknikken og konteksten, fordi intet projekt er isoleret teknik. Det øger chancen for succes, fordi man kan komme hurtigere i mål.

Tak til Anders, og tak fordi du læste med. Nu har du forhåbentlig fået inspiration til, hvordan du kan sammensætte dit næste ERP-projekt som et skabelonbaseret projekt.

Kapitel 2:
I dag vælger du en App i stedet for at udvikle

Af: Lene Graa Jennum, Head of Innovation

Du kan vælge mellem tusinder af Apps i Microsofts app-butik. Hør hvordan du bruger Apps i stedet for at udvikle i Business Central, og hvordan du vælger de rette Apps i det store udvalg.

Apps er i dag blevet en del af alle Business Central-projekter, og nu kommer Head of Innovation, Lene Graa Jennum, og giver os indsigt i, hvordan apps egentlig fungerer, hvordan apps kan kombineres med specialudvikling, og hvordan du vælger de rette apps til din løsning.

Jeg skal fortælle lidt om apps, det vil sige Business Central-apps og alt det, som I hører jeres Business Central-konsulent eller forretningskonsulent tale om. Det kan være extensions, det kan være PTE’er, on-prem og alle de her flotte ord, som vi nu prøver at tegne op og forklare, hvad egentlig er.

Hvis vi starter med at se Business Central som en telefon. Man kan sige, at dem, der lavede smartphones, sendte nogle telefoner på markedet, som i virkeligheden ikke kunne meget mere end at ringe. De kunne tage imod sms’er og beskeder, og så lod de egentlig markedet være frit og sagde, at nu skal der bygges en masse apps, og det er jo virkelig det, der har gjort dem gode. Man kan sige, Apple er lykkedes godt, Google er lykkedes, Microsoft prøvede at lave en telefon.

Det er lidt det samme med Business Central. De har lavet denne her platform, som hedder Business Central, hvor man kan tilføje apps på sit ERP-system og få det til at fungere bedre. Og det er ikke fordi, man ikke kan leve uden apps, men faktisk, når vi kigger ind i Business Central, så er den også bygget op af apps fra Microsoft, som man kan afinstallere. Hvis vi kigger på noget som Shopify-integrationen, så er det faktisk bare en app.

Der er noget bankafstemning, det er bare en app. Så pointen er, at Microsofts egne apps følger med som standard. Hvis du siger, at der er noget, du mangler, så går du på AppSource, som er det sted, hvor man kan downloade ting. Man kan gå ind via internettet og få adgang til hele Microsofts palette. Det kan være rigtig svært, for man skal vælge Dynamics oppe i hjørnet, huske at vælge Business Central, og hvis man i stedet kommer til at vælge Sales, så ender man i et CRM-system i stedet. Så kan du stå med en app, der ser spændende ud, men som slet ikke er til det produkt, du leder efter.

Gå ind i Business Central, se hvad der er tilgængeligt, og find nogle apps. Hvis vi for eksempel søger på Masterdata, så er der rigtig mange, der har apps. Abakion selv har nogle, men mange andre har også. Søger du på Masterdata, kan du få 20 apps frem. For det første er Masterdata et ord, der ikke er beskyttet, så du ved ikke, hvad du får. Du er nødt til at læse beskrivelserne af alle de forskellige apps for at finde ud af, om deres forståelse af Masterdata matcher din egen.

Når du har skåret markedet lidt ned, står du måske med 10 apps. Så kan du begynde at kigge på ratings. Hvem har fået mange ratings? Hvis der kun ligger én rating, der er fem stjerner, siger det ikke så meget. Hvis der er mange ratings, kan du bedre stole på dem. Har en app få ratings, må du selv dykke ned og vurdere kvaliteten.

Det, du kan gøre, er at spørge din konsulent: kender du nogen, der kan det her, eller hvad har I gjort andre steder? De oplever nemlig de her ting i praksis. Derudover kan du google og søge på tingene. Mange apps har trials, så du kan downloade en trial og prøve den i dit eget miljø, med dine egne data, for at se, om den virker.

Men du kan ikke bare downloade alt. På AppSource kan der stå “Contact Me,” og det betyder, at du skal kontakte udbyderen for at få lov at downloade appen. Hvis de sidder i Australien, kan der gå noget tid, og så kan du have mistet interessen. Dem, hvor der står “Download,” kan du hente med det samme. Nogle har trials, nogle kræver betaling, og nogle er gratis. Det er meget forskelligt, og det skal du være opmærksom på.

Hvordan er betalingsmodellen? I Abakion kører vi per bruger per måned eller per år, afhængigt af, hvordan aftalen er strikket sammen. Nogle steder er der rabataftaler, andre steder en flad pris. Nogle apps, som f.eks. Continia, tager betaling ud fra forbrug. Jo flere dokumenter, desto dyrere. Andre, som Timelog, har en model, hvor du betaler gennem deres eget produkt, og appen til Business Central er gratis. Markedet er frit, og betalingsaftaler ligger typisk uden for AppSource.

Forestil dig telefonen, så er du allerede i det mindset, der hedder apps-verden, som er Business Central-appsene.

Når du hører noget om global-app og PTE-app, kan du i Business Central under “Extension Management” se forskellen. Nogle står som global, andre som PTE. Er du i en sandbox, kan der også stå “dev,” som betyder udvikling. De forsvinder, når der opdateres, og kan kun være i sandboxmiljøer.

I produktionsmiljøet findes kun global og PTE. Global betyder, at du kan opdatere uden at kontakte nogen. PTE betyder, at du skal kontakte en udvikler for at få næste opdatering. Men globale apps bliver ikke bare tvunget ud. Du skal selv vælge at opdatere ved små opdateringer. Ved store opdateringer (når versionsnummeret skifter hovedtal, fx fra 23.x til 24.x) ruller Microsoft automatisk alle apps op på nyeste version.

Der er kommet nye muligheder for at styre, hvornår opdateringer installeres: automatisk, udsat eller manuelt. Hovedpointen er, at globale apps opdateres uden, at du behøver kontakte nogen.

En PTE-app er bygget til dig og dækker dine behov 100 procent. Ofte kombineres en global app med en PTE-app, så den sidste tilpasning passer til virksomheden.

Spørgsmålet er, om PTE-apps er billigere end globale apps. På kort sigt kan de være det, men Microsoft ændrer løbende deres kode. Hvis din PTE-app bruger kode, der udgår, skal du selv betale for tilpasningen. Ansvaret for vedligehold ligger på dig, hvor det for globale apps ligger hos udbyderen. På længere sigt kan det derfor blive dyrere.

Du mister også fordelen ved at være en del af et fællesskab af kunder, der alle får glæde af forbedringer og fejlrettelser. Det betyder ikke, at man ikke skal vælge PTE, men man skal vide, hvilket valg man træffer.

Så har vi noget, der hedder “extensions.” At extende betyder at udvide noget, der allerede findes, frem for at bygge nyt fra bunden. For eksempel i kundetabellen kan man tilføje nye felter. Brugeren oplever det som en naturlig del af systemet. Man kan også koble sig på events, så bestemte ting sker, når systemet kører en handling, f.eks. ved bogføring. På den måde kan man udvide funktionaliteten uden at ændre kernen.

Hvis man bygger helt fra bunden, som en ny salgsordre, skal man selv bygge alt: hoved, linjer, bogføring, flytning osv. Det er ting, der følger gratis med standarden. Derfor bør man altid overveje, om behovet ikke kan løses i standard.

Til sidst er der cloud. De fleste forbinder cloud med noget, der ligger i skyen, og det er efterhånden almindeligt kendt. On-prem betyder, at løsningen ligger på egne servere. I Abakion arbejder vi ikke længere med servere, for det kræver ekstra ressourcer at holde dem kørende. Med cloudløsningen er man altid på nyeste version, og opdateringer sker automatisk.

On-prem-markedet findes stadig, men flere ting understøttes ikke længere dér. For eksempel kommer Shopify-integrationen og dele af Power BI og Power Platform aldrig til on-prem. Dels fordi Microsoft vil have kunderne på SaaS, men også fordi det teknisk er svært at få on-prem til at spille sammen med eksterne tjenester.

Det er nemmere, når alle er på samme infrastruktur, og det er også lettere at give fx revisor adgang. På on-prem kræver det langt flere trin. Derfor vil flere ting i fremtiden ikke blive understøttet på on-prem. Skal man bruge nye teknologier, bør man kigge mod SaaS.

Man kan sagtens flyttes fra on-prem til SaaS, og Microsoft er interesseret i det. Derfor bør du overveje, hvorfor du stadig er på on-prem, og om du ikke burde videre til SaaS.

Det var, hvad jeg havde at fortælle om alle de ord, som I sikkert hører jeres Business Central-konsulent bruge. Jeg håber, I er blevet lidt klogere på, hvad vi mener med SaaS, PTE, Extensions og alle de her begreber.

Tak til Lene. Nu ved vi en masse om apps til Business Central. Vil du vide mere, kan du besøge abakion.dk/apps, hvor du både kan lære mere og se hele udvalget af apps til Business Central.

Kapitel 3:
Sådan bruger du Power Platform til nye tiltag

Af: Nicolai Schjørmann, Teamleder Power Platform

Traditionelt ville du udvikle i ERP-løsningen, hvis du har nye styringsbehov. Men i dag stiller Microsoft stærke værktøjer til rådighed til at styre processer og skabe nye applikationer. Du skal møde Power Platform og opleve mulighederne for at udbygge din ERP-løsning.

Nu kommer Nicolai Schjørmann og fortæller, hvorfor vi ikke længere skal udvikle alt direkte i Business Central, men i stedet udnytte Microsofts nye værktøjskasse, der hedder Power Platform. Nicolai Schjørmann har mange års erfaring med Dynamics 365-platformen, og i dag er han afdelingschef for Power Platform og hjælper virksomheder med at bygge Business Central på en meget smartere måde. Lad os høre, hvad Nicolai har af gode råd.

Jeg skal fortælle om Power Platformen, og særligt Power Platformen i relation til Business Central og ERP-systemer.

Og jeg er blevet spurgt nogle gange: hvorfor skal sådan en Power Platform-nørd som dig snakke om ERP-systemer? Og det har jeg faktisk også altid tænkt, at det skal jeg ikke nødvendigvis, eller det skal Power Platform-nørder ikke nødvendigvis. Fordi jeg har altid haft den tanke, at når man arbejder med Power Platform, så er det meget kreativ frihed, og det er at løse en specifik proces, automatisere et eller andet, bygge en eller anden brugergrænseflade, som kan hjælpe dig med at gøre noget, som foregår mange forskellige steder, ofte ude i field sales, field service og alt muligt andet.

Mine tanker omkring ERP og Business Central har tidligere været, at det er meget styret af regler og lov, bogføringslov, skatteregler og alt muligt andet, som gør, at det er det samme hver gang. Det har altid været min tilgang til det som CRM- og Power Platform-konsulent.

Men efter at have brugt en del tid sammen med Lene Graa Jennum, har jeg fundet ud af, at det måske ikke er helt sandheden, fordi der er masser af steder, hvor virksomheder, der har Business Central og ERP-løsninger, kan have brug for en ny brugergrænseflade til medarbejdere, som ikke skal bruge hele Business Central.

Eller de kan have brug for at automatisere en expense management-løsning eller automatisere en indlæsning af point of sales-tal eller hvad det nu måtte være. Og det er nogle af de ting, jeg har eksempler med på i dag. Men inden vi dykker ned i eksempler og den slags, kunne jeg godt tænke mig at sætte fem ord på:

Hvad er Power Platformen?
Det er fx Power BI. Det fortæller Jonas en masse om senere. Så er det Power Apps. Det vender vi tilbage til. Power Automate. Det vender vi også tilbage til. Så er det noget, der hedder Copilot Studio. Kort fortalt er det en måde at bygge sine egne copilots eller AI-agenter.

Grunden til, at jeg siger AI på den måde, er, at det er et emne, vi har på agendaen senere. Og der kan vi diskutere: hvad er AI, hvad er machine learning, hvad er rapportering, hvad er alt muligt. AI er et hot ord lige nu, så det kan blive brugt om mange ting, som jeg måske mener ikke er AI. Men det er et værktøj til at bygge forskellige copilots, lad os bruge det ord.

Så er der Power Pages, som er en måde at bygge hjemmesider, hvor folk uden for organisationen kan tilgå data inde i organisationen. Det kan være self-service og kundeservice-løsninger. Det kan være adgang til at se: hvornår kommer min tekniker? Hvornår kan jeg hente min bil på værksted? Eller hvad det nu måtte være.

Og så er der data connectors, som er forbindelser til forskellige online services. Jeg tror, vi ligger på 1100+ i dag. Der er bare én ud af de her 1100. Så hvis man har brug for at forbinde og hente data eller aflevere data mellem systemer i ens systemlandskab, så er det her, man virkelig får en gave af platformen, fordi man i næsten alle tilfælde med større systemer kan fange dem via de her forbindelser.

Så er der AI Builder, som jeg historisk ikke har snakket meget om. Hvis nogen af jer har set mig i videoer om Power Platform, så har I helt sikkert ikke hørt mig snakke om det. Men nu er vi i den AI-tid, så det skal vi selvfølgelig snakke lidt om. Og på vores AI-indlæg senere har jeg også en lille demo af, hvad man kan lave med det. Og så er der Dataverse og PowerFX, som jeg har snakket om tidligere, og som jeg ikke vil tale så meget om i dag.

Og særligt Power Apps og Power Automate vil jeg gerne beskrive: hvad skal det bruges til, og hvad er det. Specielt Power Apps har jeg lært gennem interne dialoger og samtaler med kunder og partnere, at vi skal være skarpe på ordet apps. For der er også apps i Business Central, som Lene ved meget om og fortæller om, når hun er på agendaen.

De apps i Business Central kan være små bidder af kode, man downloader og lægger ind i sin Business Central, som giver dig nye felter, automatiserer en lille ting eller udfylder felter. Men de kan også være store løsninger, som man kan downloade til scannere og ændringer i brugergrænseflader. Og det er ikke det, jeg snakker om. Jeg snakker om Power Apps, som altid er en brugergrænseflade på toppen af en database.

De eksempler, jeg har med i dag, handler om, hvordan vi kan bygge en ny brugergrænseflade oven på Business Central, hvis man har brug for det, fordi man kun skal arbejde med en lille del af Business Central, og man ikke går rundt med en pc på lageret, eller man ikke sidder inde i Business Central, når man skal logge, hvor lang tid man bruger på en sag i eksempelvis Abakion Legal. Det er nogle af de ting, jeg har eksempler med på.

Power Automate er et værktøj, som nogle næsten vil kalde et integrationsværktøj. Men hvis man skal tale om integrationsværktøjer, så skal man kigge på Logic Apps, som også er et Microsoft Azure-produkt. Power Automate er til at automatisere processer. De mest brugte løsninger, vi har set, handler meget om berigelse af data. For eksempel har vi lige lavet en løsning, hvor hvis man har et POS-apparat i en bar eller restaurant, så sender vi hver aften, når stedet er lukket, en anmodning afsted til POS-leverandøren. Vi får så alle salgstallene tilbage og opretter dem som linjer i Business Central, uden at man skal sidde og taste eller downloade et Excel-ark og importere det, eller hvad man ellers måtte have gjort tidligere. Det har jeg også eksempler med.

Så lad os starte med at kigge lidt på Power Apps. Den første app, jeg gerne vil vise screenshots af og sætte lidt ord på, er den app, vi har, der hedder Abakion Legal, som er til advokatbranchen. Her har vi noget, der hedder timers, hvor advokater kan logge, hvor lang tid de bruger på forskellige sager.

Med forbehold for detaljer, som Abakion Legal selv kan uddybe, er det min forståelse, at det er formålet. Det, vi er blevet spurgt om, er, om vi kan lave en brugergrænseflade, så man kan ligge det ind i Teams. For advokater arbejder ofte uden for Business Central, når de håndterer sager med dokumenter i Teams og SharePoint eller i Outlook. Derfor har vi bygget en ny brugergrænseflade. Den viser alle sager, man arbejder på. Man vælger en sag, starter en timer, og når man skifter sag, stopper den automatisk den forrige timer og starter en ny. På den måde har man hele tiden overblik over, hvor lang tid man bruger på de forskellige sager.

Det vigtige her er, at vi ikke har bygget en motor nede i Business Central til det. Det har Abakion Legal haft længe. Men de erfarede, at ikke alle brugte det, fordi det var besværligt at logge i Business Central. Derfor blev vi bedt om at bygge en enkel brugergrænseflade, så medarbejderne, der ikke fakturerer eller laver faktureringsgrundlag i Business Central, bare kan logge deres tid, så økonomiafdelingen har data. Det er det, vi har bygget sammen med Abakion Legal.

Et andet eksempel er Mobile Flows, som er en gruppe af løsninger til warehouse-processer, fx statusoptælling, modtagelse eller levering af pakker. Det har vi bygget for længe siden, og det har fungeret godt. Vi har dog været udfordret af Business Centrals mobile brugergrænseflade.

Åbner man Business Central i en browser på en scanner eller mobil, får man et responsivt design, men i praksis fungerer det ikke. Fx skal man trykke i et felt, før man kan scanne en stregkode, og når man skal scanne en ny, skal man trykke igen. Det er sådan, interfacet fungerer på mobilen, og det kan vi ikke ændre. Microsoft prioriterer, hvad de vil ændre, så vi har i stedet bygget en ny brugergrænseflade.

Det virker på en iPad, eller en Datalogic-scanner eller en mobil fra Apple, Samsung eller Motorola. Vi bygger dem responsive efter device. Fordelen er, at vi har kontrol. Når man scanner en stregkode, sender vi data til Business Central, og så navigerer interfacet tilbage til den rette side og sætter cursoren i feltet, så brugeren bare kan scanne den næste. Det eliminerer fejlsituationer, hvor man skal bakke fem trin tilbage.

Et konkret eksempel: lydene ved scanning i Business Central er ens, uanset om stregkoden er kendt eller ukendt. Scanner man 10.000 koder om året, er det svært at vide, hvornår der er fejl. I vores løsning kan vi selv styre lydene: et “ding” ved succes og en anden lyd ved fejl. Vi kan altså kontrollere lyd, billeder og funktionalitet. Pointen er, at vi ikke bruger det til at bygge nye logikker eller store kodekomponenter i bunden af Business Central. Det gør vi i Business Central selv. Power Apps bruger vi til at udstille og validere data, måske med små aggregeringer, men ikke tunge kodeopgaver.

Et eksempel på en automatisering i Power Automate er expenses fra et eksternt system. Når de afleverer expenses, så uploader de linjer i CSV-filer til en FTP-server. Vi har bygget en automatisering, som hver dag efter deadline henter filerne ind i Business Central. Vi trækker filerne ned og får data ind i Business Central uden manuel indtastning eller import, og man kan bogføre finanskladderne uden manuel indsats.

Et andet eksempel er salgstal fra Point of Sales. Den leverandør har data liggende i deres service, som man kan hente via API. Man kalder en URL og beder om data, og så får man kontonumre, beløb, kredit og debit tilbage. Det strukturerer vi og lægger ind i Business Central, fx i finans- eller kassekladder. Det kan lade sig gøre, fordi vi har adgang til alle tabeller i Business Central med Power Platform.

Nogen vil sige: det kan jeg også bygge i kode. Men der er to hovedpointer, hvorfor man bør overveje denne vej. For det første er kompetencekravet lavere. Man skal forstå teknikken, men man behøver ikke være hardcore .NET- eller C#-udvikler. Det frigiver udviklerne til de tunge kodeopgaver i Business Central i stedet for at sidde med den her type automatisering.

For det andet er der de 1100+ dataconnectors, inkl. Teams, Outlook og standard mail. Det betyder, at hvis noget fejler, kan vi sende besked præcis, hvor vi vil. Hvis en servicemedarbejder får en mail om fejlede flows, så kan vedkommende rette dem straks. Det kunne lige så godt være sendt til en Teams-kanal, en Teams-chat, en logtabel i Business Central eller et Google Sheet. Vi kan aflevere data, hvor vi vil. Det gør man ikke bare ved at skrive fem linjers kode. Det er en kæmpe gevinst.

Nu har jeg fortalt eksempler med to Power Apps og to Power Automate-processer. Og det er blot fire ud af mange løsninger, vi har bygget. Som jeg sagde i starten, giver Power Platform kreativ frihed til at finde på.

Tak fordi du læste med. Jeg håber, det har givet inspiration og gode idéer. Hvis du vil have mere inspiration til, hvordan du kan udnytte Power Platform, kan du besøge abakion.dk/power-platform, hvor du finder mange videoer med konkrete eksempler på, hvad Power Platform kan bruges til.

Kapitel 4:
Integrationer er en udfordring, der bliver mindre

Af: Lene Graa Jennum, Head of Innovation

Integrationer er et vigtigt emne, når man indfører et ERP-system. I dag er integrationer nemmere end for blot få år siden, fordi der findes et udvalg af integrations-apps og nye muligheder for at udveksle data med Microsoft Power Automate. Vi skal fx høre hvordan man connecter til fragtfirmaer.

Nu skal vi tale om integration, som altid er et stort emne i et Business Central-projekt. Men det er også et emne, hvor der er sket en stor udvikling i de senere år. Og nu skal vi høre Head of Innovation, Lene Graa Jennum, fortælle, hvordan man bedst håndterer integrationer i et ERP-projekt i dag.

Vi skal tale om integrationer i Business Central-kontekst, men også integrationer helt generelt. Når man kigger tilbage i tiden, så talte man lidt om integrationer, men det vi kan se nu, er, at man næsten ikke kan køre et projekt uden integration. Det er blevet hverdag at skulle få systemer til at tale sammen.

Folk har faktisk ret godt styr på, at man skal flytte data fra det ene system til det andet, og det er en kæmpe udvikling. I gamle dage byggede man det hele inde i sin platform. Alt blev bygget i ét system, hvor integrationen boede inde i Business Central, NAV, SAP eller et andet ERP-system.

Man byggede alting derinde. Systemet eksekverede, hentede data, lagde filer eller gjorde noget andet. Dengang var det typisk fil-flytning. Man lavede en flad fil, lagde den et sted, og så hentede et andet system filen og læste den ind.

Det kaldtes asynkron integration. Asynkron betyder, at data ikke bliver flyttet med det samme, men over tid, og det var helt fint. Det var acceptabelt, at man kun hentede ordrer ind om morgenen, én gang i timen eller bogførte på bestemte tidspunkter.

Men billedet har ændret sig. I dag forventer man ofte, at alt skal køre i realtid. Og mange gange er det dyrt, hvis alt skal køre i realtid. Derfor bør man overveje, om det virkelig er nødvendigt, eller om det er fint at vente til om aftenen.

For eksempel: hvad er der kørt igennem kasseapparaterne i løbet af dagen? Skal hver enkelt bogføring sendes tilbage til systemet i samme sekund, kunden køber noget? Ofte er det helt i orden at vente til natten og køre hele puljen der.

Når man henter data ud i realtid, lægger man nemlig et pres på systemet. Det vil være ærgerligt, hvis systemet ikke kan håndtere salg i butikken, fordi det samtidig er optaget af at sende data. Flytning af data i realtid skal give værdi for nogen.

Hvis indkøberne alligevel først arbejder om aftenen eller næste dag, så er der ingen idé i at flytte data i realtid. Derfor skal man altid tænke over performance og ressourceforbrug.

Et eksempel er Pleo. Det er et system til håndtering af medarbejderudgifter. Det giver ingen mening at flytte data fra Pleo til Business Central i realtid. Det kan sagtens vente, måske én gang om måneden eller hver fjortende dag.

Der findes en Business Central-app til Pleo, men pointen er, at realtid ikke er nødvendigt.

Så opstår spørgsmålet: skal vi bygge PTE-apps? PTE-apps er apps, man selv bygger til sin platform. De bor kun dér og udgives ikke på AppSource.

Som nævnt i Pleo-eksemplet: ofte forventer kunder, at integrationen allerede findes. Når jeg spørger, om de har tjekket, om systemet kan integrere med Business Central, svarer de næsten altid: “Det kan det vel. Det kan alt jo.” Men det kræver jo, at nogen har bygget det.

En PTE-app kan give mening, hvis det er et unikt system, I har brug for. Men i mange tilfælde vil flere virksomheder have samme behov, og så giver det bedre mening at lave en generel integration, også fordi det styrker systemets konkurrenceevne. Hvis Pleo fx ikke havde en app, ville de stå svagere i markedet.

Et eksempel fra praksis: en kunde ville hver morgen sende salgstal til sin leverandør. At bygge det hele inde i Business Central ville have kostet mange timer. At trække data ud er ikke svært, men at sende det videre er mere komplekst i Business Central.

Derfor lavede en Business Central-konsulent et udtræk, og en Power Platform-konsulent byggede løsningen til at sende mails. På den måde sparede man tid, fordi hver konsulent arbejdede med det, de var bedst til.

Her støder vi på en række begreber. Et API er et interface, et sæt regler for, hvordan systemer taler sammen. Business Central har et API, Shopify har et API, Blue Water har et API. API’et udstiller data og metoder, fx at oprette, læse eller rette en kunde.

Men et API gør ingenting i sig selv. Det er passivt. Det stiller bare data til rådighed. Derfor skal man have et lag imellem, som kaster data frem og tilbage, fx Power Platform eller Logic Apps.

Man kan også arbejde med abonnementer. Et eksempel: når du lukker en kasse i et kasseapparat, sker der en event. Hvis du abonnerer på den event, får du besked og kan hente data. Men abonnementer udløber, så du skal huske at forny dem, ellers stopper de.

Derfor skal man altid have et mellem-lag. Det kan også håndtere fejl. I Business Central ser vi ofte, at der kun bygges et happy flow, altså når alt går godt. Men når noget fejler, er der ingen, der får besked. Det er farligt, for fejl sker altid.

Derfor er det bedre at bruge produkter, som håndterer både successcenarier og fejl. Ellers kan en enkelt fejl betyde, at ordrer slet ikke bliver indlæst.

Et andet begreb er Client Secret. Det er en form for brugeroplysninger, i praksis brugernavn og adgangskode, som genereres gennem en app-registrering i Microsoft Entra (tidligere Azure). Det er sådan, systemer autentificerer sig.

Når det gælder licenser: integration gennem app-registrering er gratis. Her registrerer man appen, ligesom hvis det var en bruger, og tildeler den rettigheder. Men man skal ikke genbruge den samme registrering til mange systemer, det åbner en ladeport. Opret hellere flere små registreringer med snævre rettigheder.

Microsoft har også lavet standardintegrationer. Et eksempel er Shopify. Microsoft købte en eksisterende connector fra en partner, videreudviklede den og gør den nu gratis. Den håndterer bl.a. returvarer. Det er en kæmpe styrkelse for Shopify, fordi kunder nu gratis kan integrere med Business Central.

Et andet eksempel er Power BI. Microsoft har lavet en integration, så man kan lægge små kuber på Business Central og se rapporter direkte i platformen.

Bankintegration er også kommet som standard. Den første bankkonto er gratis at integrere, flere kan tilkøbes.

Der er også integration til Dataverse og CRM. Udfordringen ligger i kunderejsen. Hvornår må data flyttes, og hvem må rette hvad? Det er komplekst, men grundlæggende findes der en standardintegration.

Hos Abakion har vi længe haft integrationsprodukter, som byggede på filindlæsning. Nu bevæger vi os mod et mellemlag i Power Platformen, så brugere lettere kan sætte integrationer op uden at skulle have konsulenter med hver gang.

Vi har fx Shipping Manager til fragtbreve og Warehouse Manager til pluk og lagerintegration. Begge løsninger bygger på API’er, men med ekstra funktioner, som Microsofts standard ikke dækker, fx at bogføre udefra.

Shipping Manager gør det muligt at sende ordrer direkte til speditører som GLS eller Shipmondo via connectors. Det fungerer som Lego-klodser, hvor man bygger præcis de integrationer, man har brug for.

Pointen er, at integrationer er uundgåelige i ERP-projekter. En eller anden integration vil altid være der, og det er blevet helt naturligt.

Tak til Lene Graa Jennum for gennemgangen. Hvis du vil se, hvilke integrationer eller connectors der findes, så besøg Microsoft AppSource. Og hvis du ikke kan finde det, du søger, kan Lene hjælpe med at pege i den rigtige retning.

Kapitel 5:
Nu kan du koble Business Central til Power BI

Af: Jonas Kjeldsen, Business Intelligence-ekspert

Man har længe kunnet visualisere ERP-data i Microsoft Power BI. Men du vil sikkert gerne samle dine ERP-data med andre datakilder – sådan at du har et rigtigt Business Intelligence-system med Power BI. Nu findes der standard-app til at udstille data fra Business Central og til at overføre data til BI. Det skal vi høre om.

Visualisering og analyse af ERP-data er blevet en fast del af næsten alle ERP-projekter i dag. Det er blevet meget nemmere at koble Business Intelligence-løsningen Power BI sammen med Business Central. Det kommer Jonas Kjeldsen til at fortælle om nu.

Jonas Kjeldsen er ekspert i Business Intelligence og især i kombination med Business Central. Og han vil nu hjælpe dig med at vælge den rette Business Intelligence-løsning til dine ERP-data. Jonas, hvad skal vi tale om nu?

Vi skal tale om Business Intelligence med data fra Business Central. Det har vi en masse erfaring med, og det vil jeg gerne dele lidt af.

Så først vil jeg fortælle lidt om, hvad man egentlig kan med Business Intelligence helt kort, og så noget om, hvad vores kunder mest bruger det til. Og så vil jeg komme med nogle gode råd i forhold til, hvad man gør, når man skal i gang, hvis man står for et ERP-projekt. Ud fra et forretningsmæssigt perspektiv og også lidt ud fra nogle tekniske briller, som begge dele er relevante for et projekt.

Hvad er det egentlig, vi bruger BI til? Hvad vil vi med BI? Der er mange virksomheder, der allerede bruger BI. Og det, vi typisk gerne vil, er at skabe indsigter gennem de data, vi har i virksomheden, som vi ikke havde i forvejen. Så analyse på data og understøttelse af de strategiske beslutninger, man har i en organisation.

Det kan være på topledelsesniveau, hvor man for eksempel skal overveje, om vi i dette forretningsområde skal investere mere, eller om der er en del af organisationen, vi skal trimme ind, fordi det går mindre godt.

Det kan også være i dagligdagen hos den enkelte medarbejder. Det kan være, hvordan sælgeren er opmærksom på, at han skal nå sine mål. Eller det kan være en projektleder, der skal følge op på et projekt. Eller måske en afdelingsleder, der skal se, hvordan det går på tværs af hele projektporteføljen i afdelingen.

Når vi vores mål, når vi de deadlines, vi har, og så videre. Så det kan være på mange niveauer. Grundlæggende set er det for at blive mere effektiv i virksomheden og træffe beslutninger på et mere oplyst grundlag.

I høj grad handler det også om at fjerne manuelle opgaver. Det bruger man også BI til. Og når man spørger mange virksomheder, svarer de, at BI er noget af det, man kan implementere for at få en ret stor effekt på bundlinjen.

Det er et af de IT-projekter, som oftest vurderes til at give rigtig meget på bundlinjen. Og det er klart, at hvis man lykkes med, at alle medarbejdere i en virksomhed har mere faktuel viden at basere beslutninger på, så vil det være rigtig meget værd for en forretning.

Og så er det langt nemmere at analysere data på en BI-platform, end det er at gøre i forskellige forretningssystemer. Man kan godt hive data ud af et ERP-system og åbne det og kigge ned i data, men det er meget sværere at lave analyse, end det er i et dedikeret analyseværktøj som BI. Og når vi derudover gerne vil kombinere ERP-data med data fra andre kilder, er vi nødt til at have et system til det.
Det er netop det, et BI-system kan.

Nu er du jo i et hus, der har rigtig meget med Business Central at gøre. Er det de fleste, der bruger Business Central, der også bruger BI, eller er det kun få?

Der er efterhånden flere og flere, der bruger BI sammen med deres Business Central. Og vi forsøger rigtig meget, når vi går i gang med ERP-projekter, at forklare kunderne, hvilken værdi der er i at få tænkt BI med fra start. Det er også et af mine hovedbudskaber i dag: Når man tænker ERP, skal man også tænke BI med.
Og det er der heldigvis flere og flere, der gør. Vi begynder også mere og mere at lægge nogle af vores BI-løsninger med som free trials på ERP-projekter, så kunderne nemt kan få en idé af, hvad man kan på egne data.

Hvorfor skal man tænke BI med fra starten?

Det er fordi, når man implementerer et ERP-system, har man en gylden mulighed. Det er virkelig en chance for at få de rigtige ting på plads. Business Intelligence, visse analyser og nøgletal kræver nogle ret specifikke ting af det underliggende forretningssystem.

Det kunne være, at man havde et måltal for, hvor god man var til at levere til sine kunder, men forretningssystemet ikke gemmer leveringsdatoen. Det kunne være et eksempel. Så er det vigtigt, at vi sørger for, at de ting, vi skal bruge til BI, er indtænkt i vores forretningsprocesser i ERP-systemet, for det er kun muligt at lave BI på de data, vi har.

Man kan også gøre det på bagkant, men så er det meget mere besværligt. Det er langt bedre, når man har gang i alle de mennesker, der ved rigtig meget om ERP, at få kravene stillet korrekt til projektet, så BI har de rigtige forudsætninger, når projektet går i gang.

Så det helt overordnede spørgsmål: Er det svært eller nemt at lægge BI oven på et ERP-system?

Det afhænger af, hvem man spørger. Hvis man spørger Microsoft for eksempel, vil de sige, at de har en connector til deres BI-værktøj Power BI, der kan bruges til at trække data ud af Business Central. Det lyder supernemt. Og det er det faktisk også i en vis grad. Hvis Business Central ikke indeholder alt for store datamængder, ikke skal opdateres for tit og har et afgrænset forretningsområde, så kan det være helt fint at bruge Power BI direkte imod ERP-systemet.

Hvis man spørger andre virksomheder, vil nogle svare, at de har postet en masse penge i et BI-projekt, og det kom aldrig til at kunne det, de gerne ville. Den oplevelse findes også. Det er fordi, man ikke kan nøjes med den standardløsning, Microsoft leverer, men i stedet må bruge traditionel datavarehus-teknologi, som giver frit spil i forhold til, hvad man kan, men som også stiller større krav til projektet. Der stilles krav til at identificere de rigtige behov for BI, inden man starter, og så videre. Det gør det sværere at køre sådan et projekt.

Men hvis forudsætningerne er på plads, er der mange virksomheder, der får god værdi ud af at benytte datavarehus-teknologi i stedet for direkte Power BI mod Business Central. Så ja, omfanget af BI-projekter kan variere rigtig meget. Det afhænger af virksomhedens behov og ambitioner. Det skal man holde sig for øje.

Og det bringer mig til de forretningsmæssige gode råd. Hvis vi skal opstille et par simple forudsætninger for succes med et BI-projekt mod Business Central, eller andre ERP-systemer og kilder, er det vigtigt at definere klare formål for, hvad man vil. Historisk er BI-projekter noget, man kan bruge mange penge og meget tid på, hvis man ikke er skarp på det. Det kan hurtigt blive projekter, der trækker ud.

Hvis man bare går i gang med at kode løs, ender man ofte med, at nogle forretningsbrugere modtager BI-løsningen og finder ud af, at det slet ikke er det, de havde brug for. Et andet vigtigt succeskriterium er derfor at inddrage de mennesker, der skal bruge BI, fra start i processen.

Det handler både om at sikre, at projektet indeholder det rigtige, og om at få business intelligence ud at leve i organisationen. Det skal ikke bare være et topledelsesværktøj, hvor en rapportansvarlig hver måned trækker en rapport og sender den til ledelsen. Det er ikke det, vi vil med BI. Vi vil mere.

I moderne virksomheder træffes beslutninger på alle niveauer. Hvis vi vil have værdi ud af BI, skal vi inddrage hele organisationen eller alle, hvor vi kan se et formål. Hvis vi giver medarbejdere adgang til data, der er relevante for dem, forbedrer vi deres beslutningstagen og gør dem mere produktive. Måske giver vi i sidste ende også transparens i virksomheden over, hvordan tingene fungerer. Det kan også være et plus.

Og du har helt praktisk et værktøj til at kortlægge, hvem i organisationen der har hvilket behov?

Ja, det er rigtigt. Man starter med at finde ud af, hvad man vil med BI, ved at inddrage de mennesker, jeg taler om. Og så handler det om at fastlægge, hvilke målgrupper der har behov for hvilke forretningsprocesser, og på hvilke forretningsområder. Man definerer, hvilke nøgletal de forskellige målgrupper har brug for, og skitserer nogle rapporter, de kan få.

I den proces skal man selvfølgelig undersøge, om der allerede findes en standardrapportpakke. Er der nogen, der allerede har lavet det som et produkt, man kan købe, så man ikke behøver at lave et helt IT-projekt? Ofte er det ikke tilfældet, og så skal man ind og identificere de nødvendige data.

Derfor skal vi indtænke BI i vores ERP, så dataene, vi har brug for, også er tilgængelige.

Man kan bruge en matrix, hvor målgrupper står på den ene akse og forretningsområder på den anden, og så kan man plotte processer ind. Et eksempel kan være direktion, økonomistab, salgsledelse, med områder som økonomistyring, salgsstyring, HR og lagerstyring. Så kan man plotte formål ind, som for eksempel finansforecast eller opfølgning på udestående betalinger. BI kan bruges til rigtig meget.

Det, vi ofte anbefaler, er at prioritere. For alt behøver ikke laves fra start. En god BI-platform skal understøtte, at tingene kan tages i et fornuftigt tempo, så ikke alle områder behøver at være implementeret dag ét. Denne metode er også beskrevet i vores Business Intelligence-strategiguide, hvor man kan læse mere om processen.

Og igen: At tænke BI ind fra start i ERP betyder ikke nødvendigvis, at BI-projektet skal laves samtidig med ERP-projektet. Det vigtigste er, at scoping af BI, altså analysen af behov sammen med de rette mennesker, bliver foretaget, inden eller i forbindelse med ERP-projektet. Selve BI-projektet kan godt vente, til ERP-projektet er afsluttet.

Man behøver ikke starte det hele på én gang. Tag gerne ét område ad gangen. Det vigtige er, at man har en teknisk platform, der understøtter skalering. Vi skal kunne tage det trinvis. Platformen skal være målrettet de formål, vi har defineret, men også kunne vokse med forretningen. Sådan er det med BI: Hvis BI står stille, står forretningen stille. BI skal udvikle sig med forretningen, og platformen skal understøtte det.

Det leder mig til at tale om, hvad en BI-platform skal kunne. Først skal ERP-systemet udstille data, så vi kan rapportere på dem. Derefter kommer data fra forretningssystemet. De er operationelle data. De kan være okay, men de er ikke ideelle til rapportering. Vi er nødt til at lave efterbehandling og klargøring, før vi kan bygge rapporter.

Måske vil vi også sammenstille med data fra andre systemer, for eksempel CRM eller HR. Platformen skal understøtte det. Og til sidst skal den udstille data til slutbrugerne med rapporter og visualiseringer til de målgrupper, vi har defineret. Det er dér, vi normalt bruger Power BI. Man kan i princippet også bruge andre værktøjer.

Når vi taler platform, kan vi godt lide at beskrive to modeller.

Den fulde model: Data kopieres eller replikeres ud af ERP-systemet og over i et datavarehus. Business Central udstiller data via API’er, og data replikeres i et datavarehus, hvor de transformeres efter behov. Derefter læses de ind i Power BI, hvor rapporteringen sker. Datavarehuset ligger typisk i en SQL-server, men kan også være andre teknologier som data lake. Det minder om det klassiske datavarehus-princip og fungerer stadig fint i dag.

Den anden model er den simple model. Her udstilles data fra Business Central direkte i Power BI. Transformation og visualisering sker i Power BI. Det kræver mindre infrastruktur, men man kan ikke det samme, som i den fulde model.

Jeg har lavet en liste over forskelle. Den simple model tager typisk data fra ét kildesystem. Hvis man kun har Business Central, kan den bruges. Den fulde model tillader data fra mange systemer.

Den simple model tillader ikke mange regnskaber i Business Central. Hvis man har mange, skal man bruge den fulde model, som i princippet understøtter ubegrænset antal regnskaber.

I forhold til datamængder er den simple model begrænset. Den fulde model kan håndtere ubegrænset mængder. Det hænger sammen med, at den simple model skal lave full load hver gang, mens den fulde kan lave delta load og kun hente ændringer. Dermed kan den håndtere langt større datamængder og højere opdateringsfrekvens, for eksempel hvert kvarter. Den simple model er begrænset til lavere frekvens, måske daglig.

Den fulde model er mere skalerbar og fleksibel. Man kan tilføje ressourcer og udvikle frit. Den simple er ikke så skalerbar og har begrænsede tilpasningsmuligheder.

Og hvis man gerne vil have en fuld vejledning i, hvordan man vælger mellem de to modeller, så har vi hele vejledningen.

Vi har lavet en omfattende strategiguide, der beskriver mange af disse områder, både forretningsmæssigt og teknisk. Den vil jeg anbefale at kigge i.

Hvis man skulle tage ét godt råd med herfra, ud over at læse guiden, så er det at tænke BI ind i begyndelsen af ERP-projektet. Ja, lige præcis. Det er ofte dér, vi ser, at det går galt: Man udnytter ikke muligheden for at samtænke processer på tværs af ERP og BI.

Og man ser det som et teknisk projekt, hvor man laver det, og når det er færdigt, giver man brugerne et kursus. Men de mennesker, der skal bruge det – målgrupperne – skal være med fra start til at definere, hvad vi gerne vil med BI-platformen.

Tak til Jonas for at fortælle, hvordan man i dag kobler Business Central sammen med Microsoft Power BI. Og hvis du gerne vil se udvalget af standardløsninger til Power BI, kan du besøge abakion.dk/power-bi.