Planlægningsdata i Power BI: plan mod faktisk på tværs af systemer

Af /

Planlægningsdata i Power BI er kun værd noget, når planen kan lægges oven på det faktiske med samme vare, samme ressource og samme uge. Planerne ligger sjældent ét sted. Nogle står i Business Central, nogle i et regneark på SharePoint og nogle i et planlægningssystem. Her gennemgår vi, hvordan de samles i én semantisk model uden en dataplatform.

Resumé og konklusion

  • Hver plankilde får sin egen kæde. Business Central, Excel-filer og planlægningssystemet hentes hver for sig i Base og Enriched og samles først i Curated.
  • Kornet skal afgøres før koden. En plan pr. uge kan ikke sammenlignes med salg pr. dag, før I har besluttet, om det faktiske samles op, eller planen fordeles ud.
  • Power BI gemmer ikke gamle planer. En opdatering overskriver. Versioner og snapshots skal gemmes i kilden, fx som navngivne prognoser eller én fil pr. version.
  • Forecast-præcision kræver en fastfrosset version. Sammenlign det faktiske med planen, som den så ud fx en måned før, ellers måler I en plan, der er rettet til undervejs.
  • MAPE kan snyde på små varer. Én vare med lav afsætning kan trække gennemsnittet op. Vis WAPE ved siden af.

Hvor planlægningsdata kommer fra

I en typisk SMV med Business Central findes planer tre steder. Hver kilde har sin styrke og sit problem.

Business Central

Business Central har flere slags planer. Finansbudgetter på finanskonti, varebudgetter for salg og køb, projektplanlægningslinjer og efterspørgselsprognoser. Prognoserne oprettes på siden Demand Forecasts, kan have flere navne og vises pr. dag, uge, måned, kvartal, år eller regnskabsperiode. Kun én prognose bruges i planlægningen ad gangen, ifølge Microsofts beskrivelse af efterspørgselsprognoser. At en prognose har et navn, er vigtigt, fordi navnet kan bruges som version.

Excel og SharePoint

Salgsbudgetter pr. sælger, kapacitetsplaner pr. hold og kampagneplaner lever ofte i Excel. Det er fint, hvis filerne har samme opbygning. SharePoint-mappe-connectoren i Power Query henter alle filer i en mappe og kombinerer dem, men Microsoft skriver, at alle filer i mappen og undermapperne skal have samme skema. Én fil med en ekstra kolonne stopper opdateringen.

Planlægningssystemet

Et planlægningssystem til produktion, bemanding eller ruter eksporterer typisk planen som en fil, en databasevisning eller et API. Planen er detaljeret, ofte pr. dag og ressource, men nøglerne er systemets egne. En maskine hedder noget andet end arbejdscentret i Business Central, og en medarbejder har et andet nummer. Oversættelsen af nøgler er det største stykke arbejde.

Planlægningsdata i Power BI lagt i lagene

Den semantiske model i oneBC365 har fire lag i Power Query: Base, Enriched, Curated og Model. Det er samme struktur, som en dataplatform bygger med bronze, silver og gold, og den er beskrevet i semantisk lag i Power BI. Plandata følger samme regel som alle andre kilder: én kæde pr. kilde, fælles dimensioner i Curated.

  • Base. Én forespørgsel pr. kilde med erklærede kolonner. For Excel er det den kombinerede mappe, for planlægningssystemet visningen eller API’et. Ingen omdøbning.
  • Enriched. Kolonnerne bringes på samme form: Version, Periodestart, Korn (dag, uge eller måned), Vare, Ressource, Antal og Beløb. Datoer får CalendarDateID. Kildens nøgler slås op i en oversættelsestabel.
  • Curated. Kilderne lægges sammen i én plantabel med en kolonne for kilde. Her får hver række surrogatnøgler til de fælles dimensioner: vare, ressource eller medarbejder, kunde og dato. Rækker uden match lander på unknown member -1, så de kan tælles.
  • Model. En faktatabel Plan med relationer til de samme dimensioner som Sales Document og Item Ledger Entry. Så virker ét udsnit på både plan og faktisk.

Grafikken herunder viser de tre kæder og de fire kolonner, der skal være ens, før kilderne kan lægges sammen.

Planlægningsdata i Power BI fra Business Central, Excel og planlægningssystem samlet i én plantabel i Curated-laget
Tre plankilder, tre kæder, én plantabel med version, korn og fælles nøgler.

Tidsopløsning: plan og faktisk på samme korn

Salg og vareforbrug i Business Central er pr. dag. Planer er ofte pr. uge eller måned. Der er to måder at bringe dem sammen på.

Den første er at samle det faktiske op. Planrækken får periodens første dag som dato, og målene sammenligner kun på uge eller måned. Det er enkelt og ærligt over for planen, men en rapport pr. dag viser hele ugens plan på mandag. Løs det med et mål, der returnerer blankt, når udsnittet er finere end planens korn.

Den anden er at fordele planen ud på dage, fx ligeligt på arbejdsdage. Det giver pæne kurver, men tallene pr. dag er opfundne. Brug det kun, hvor en daglig kurve er nødvendig, fx til at følge en måned undervejs.

Blandede korn er det egentlige problem. Planlægningssystemet planlægger de næste fire uger pr. dag og resten pr. måned. Så skal Korn-kolonnen følge med hver række, og målene skal respektere den. Beslut det i Enriched og skriv det ned.

Planversioner og snapshots

En import-model i Power BI indeholder det, kilden indeholdt ved seneste opdatering. Retter planlæggeren tallene for oktober, er den gamle plan væk fra modellen. Power BI er ikke et arkiv, og det skal det heller ikke være. Selv incremental refresh er et filter, der dropper rækker uden for vinduet, ikke en historik.

Versioner gemmes derfor i kilden. I Business Central kan det være en navngiven prognose eller et varebudget pr. måned, fx “FC 2026-09”. I SharePoint kan det være én fil pr. version i en mappe, der aldrig overskrives. Fra planlægningssystemet kan det være en månedlig eksport med dato i filnavnet. Enriched-laget udleder Version og Versionsdato, og Curated markerer, hvilken version der er den aktuelle.

Kapacitet mod ordrebog og forecast-præcision

Når plan og faktisk deler dimensioner, kan to ledelsesspørgsmål besvares. Det første er kapacitet mod ordrebog. Kapaciteten pr. ressource og uge kommer fra planlægningssystemet, og belastningen kommer fra de åbne ordrer i Business Central omregnet til timer. Er uge 43 booket til 112 % på ét arbejdscenter, er det et spørgsmål om leveringsdato, ikke om planlægning. Sammenhængen med leveringsgrad er beskrevet i leveringsgrad og flaskehalse i driften.

Det andet er forecast-præcision. Det mest brugte mål er MAPE, gennemsnittet af den procentvise fejl pr. vare. Det har en svaghed, som grafikken herunder viser med fem tænkte varer. En vare med en prognose på 40 og et salg på 10 har en fejl på 300 %, og den trækker MAPE op på 70,3 %. WAPE, den samlede absolutte fejl divideret med det samlede salg, giver 13,5 % for de samme tal.

Forecast-præcision med MAPE og WAPE på fem varer, beregnet på planlægningsdata og faktisk salg
Samme fem varer, to mål. Én lille vare flytter MAPE fra 12,9 % til 70,3 %.

Vis begge. MAPE fortæller, hvor skævt den typiske vare rammes. WAPE fortæller, hvor meget af omsætningen der blev planlagt forkert. Mål på den version, der var gældende en måned før perioden, så planen ikke er rettet til efter det faktiske. Metoder til selve prognosen står i salgsforecasting med AI.

Sådan sætter du det op i Power BI

  1. Lav en oversættelsestabel for nøgler. Én tabel, der oversætter planlægningssystemets maskiner og medarbejdere til arbejdscentre, ressourcer og medarbejdere i Business Central. Hold den i SharePoint, så driften kan vedligeholde den.
  2. Byg én Base-forespørgsel pr. kilde. Til Excel bruges SharePoint-mappe-connectoren på en mappe pr. plantype. Til Business Central bruges en API-side for de planer, der ikke allerede er i modellen.
  3. Normalisér i Enriched. Tilføj Version, Versionsdato, Korn og CalendarDateID, og oversæt nøglerne. Sæt privatlivsniveauerne til Organizational, så Formula.Firewall ikke stopper sammenlægningen.
  4. Læg sammen i Curated. Én plantabel med kilde, version og surrogatnøgler. Tæl rækker på -1 pr. kilde og vis tallet i en rapport om datakvalitet.
  5. Skriv målene med beskrivelser. Plan, Afvigelse, MAPE og WAPE med én sætning om version og korn hver. Det er dem, Copilot læser.

Hvad planlægningsdata i Power BI ikke løser

Power BI planlægger ikke. Modellen viser planen og afvigelsen, men planen skal stadig laves i Business Central, i planlægningssystemet eller i Excel. Skal brugerne kunne rette planen direkte fra rapporten, er det writeback i Power BI, og det er et andet emne.

Mængderne vokser hurtigt. 5.000 varer pr. dag i 365 dage med 12 versioner er knap 22 mio. rækker. På Power BI Pro er grænsen for en semantisk model 1 GB, og en opdatering skal være færdig inden for to timer. Hold planer pr. dag til de nærmeste måneder og ældre versioner pr. uge eller måned.

Og realtid findes ikke. Pro giver op til otte planlagte opdateringer om dagen. Skal planlæggeren se konsekvensen af en ændring med det samme, hører det hjemme i planlægningssystemet. Kræver volumen eller versionshistorik mere, er det tid til at flytte lagene til Dataflows Gen2 eller en Fabric Lakehouse, som Power BI eller dataplatform gennemgår.

Sådan understøtter oneBC365 det

oneBC365 har allerede en del planer fra Business Central i modellen: finansbudgetter med mål for budget og afvigelse, varebudgetter i Item Budget Entry med flere budgetnavne, købsbudgetter, projektplanlægningslinjer i Job Planning og en rapportside for kapacitet på arbejdscentre og maskincentre. Efterspørgselsprognoser og planer fra andre systemer er ikke blandt standardmodellens tabeller, men oneBC365 kan integrere dem som en udvidelse af modellen, aftalt og estimeret pr. kilde (se services). De lægges ind som nye kæder med de samme delte funktioner til surrogatnøgler og unknown members, som modellens Curated-lag bruger i dag.

Det er seriens pointe. Dataplatform-leverandørerne bygger samme lagdeling med lakehouse, pipelines og Fabric-kapacitet. I oneBC365 sker det i Power BI’s semantiske lag på Pro-licenser. Løsningen ligger som PBIP i Git med kommenteret M-kode, I ejer koden, og jeres BC-partner kan udvide den. Kommer I dertil, hvor versionshistorikken bliver for stor, kan lagene flyttes, mens rapporterne bliver stående.

Sådan kommer du i gang

  1. Lav en liste over jeres planer. Plantype, kilde, korn, ejer og hvor ofte den ændres. Fem til ti linjer er typisk.
  2. Vælg én plan og ét faktisk tal. Fx salgsprognose pr. vare og måned mod faktureret antal. Byg den ene kæde færdig, før den næste startes.
  3. Begynd at gemme versioner nu. Én fil eller ét prognosenavn pr. måned. Historikken kan ikke skabes bagefter.
  4. Beslut, hvordan I måler præcision. MAPE og WAPE, hvilken version og hvilket korn. Skriv det i én sætning, før målene bygges.

Relaterede artikler

Vil I se, hvordan budget mod faktisk ser ud på jeres egne tal fra Business Central? Book en demo, så viser vi det live på 30 minutter.

Scroll to Top