Därför tar ert Power BI-projekt dubbelt så lång tid — problemet sitter inte i Fabric

Ett större bolag vi pratat med räknade med att få sin nya Power BI-rapportering på plats på tre månader. Ett år senare är två av fem rapporter produktionssatta. Konsultfakturan är uppe i sex gånger den ursprungliga budgeten. Och ingen på ekonomi öppnar styrelsepacken utan att först ringa en controller för att dubbelkolla.

Det här är inte en ovanlig berättelse. Varje gång ett bolag investerar tungt i Microsoft Fabric, Power BI eller ett nytt datalager och sedan fastnar sju månader in — är det nästan aldrig BI-verktyget som är problemet.

Rapporteringen är en spegel, inte ett filter

När man sätter Power BI ovanpå affärssystemet händer en sak: allt som varit rörigt i ERP:et blir plötsligt synligt för fler. Kontoplanen med 1 200 rader där 300 aldrig används. Projektkoderna som tre divisioner använder på olika sätt. Kundkategoriseringen som blivit ad hoc efter fem år av specialfall. Inköpen som ibland bokas på leverantörskontot och ibland på projektet, beroende på vem som bokförde.

I redovisningen spelar det liten roll — avstämningarna görs ändå, manuellt, varje månadsskifte. I rapporteringen faller allt ut som brus. Varje graf blir en diskussion om vad det egentligen är vi mäter.

Fabric, semantiska lager och andra räddningsplankor

Microsoft Fabric, semantic models, DAX-mått, dbt-transformationer — allt är utmärkta verktyg. Men de används ofta för att kompensera för strukturproblem i källsystemet. Ett mått som "nettoomsättning exklusive koncerninterna mellanhavanden, justerad för valutaeffekt och periodiserad rabatt" kan absolut räknas fram i ett semantiskt lager. Problemet är att den regeln ändras — och när den gör det måste uppdateringen göras i BI-lagret i stället för att datan kommer rätt ur affärssystemet från början.

Resultatet blir ett BI-lager som i praktiken är en andra kontoplan. Dubbel underhållsbörda. Två källor till sanningen. Och ett beroende av två eller tre personer som förstår båda.

Vad bra data från affärssystemet faktiskt kräver

Ett modernt affärssystem levererar data som går att rapportera på utan tolkningsinstans i mellanledet. Konkret betyder det fyra saker:

• Dimensioner som är konsekventa över hela bolaget — ett projekt är ett projekt, inte en kostnadsställe-proxy på finans och en fritextsträng på inköp.
• En kontoplan som följer en tydlig logik och inte mer än nödvändigt. Detaljering hanteras via dimensioner, inte via 300 extra konton.
• Entydig koppling mellan transaktion och underlag. En leverantörsfaktura har en ägare, en kostnadsbärare och en projektkod — inte tre valbara tolkningar.
• En API-modell som lämnar ut data med stabila identifierare och stabil semantik över tid. Ändras ett fält i användargränssnittet ska integrationen inte gå sönder.

Det här är inte BI-arbete. Det är ERP-arbete. Och när det är på plats blir Fabric- eller Power BI-projektet det det ska vara: visualisering.

Det återkommande mönstret

Vi har sett samma sekvens upprepas hos flera bolag:

• Fas 1: Affärssystemet upplevs som trögt att rapportera ur. Controller-teamet bygger Excel-lösningar med manuella extrakt.
• Fas 2: Excel blir ohållbart. Ett BI-initiativ startas, ofta med en extern implementationspartner.
• Fas 3: BI-konsulterna börjar bygga mått och transformationer ovanpå källdata som inte är normaliserad. Projektet drar ut på tiden eftersom varje ny rapport kräver att regler för vad datan "egentligen betyder" definieras om.
• Fas 4: Efter två år finns en Power BI-lösning som fungerar — men är omöjlig att förändra utan dyra konsulttimmar. Varje förändring i affärsmodellen innebär en förändring i BI-lagret.

Den verkliga kostnaden syns inte i projektbudgeten. Den syns i att ingen i ekonomi litar på rapporterna fullt ut, och i att det tar veckor att ta fram siffror som borde ta timmar.

När det är rätt att faktiskt bygga ett datalager

Missförstå inte — Fabric, datalager och Power BI är rätt svar på många problem. När ni har flera källsystem som ska konsolideras, när datavolymerna är så stora att ERP:et inte ska serva BI-frågor direkt, när ni behöver avancerad statistik eller ML — då behövs ett separat analyslager.

Men om det enda källsystemet är ett affärssystem och problemet är "det är svårt att rapportera", då är investeringen oftast fel riktad. Lös ERP-datamodellen först. Använd sedan BI som visualisering ovanpå.

Det är precis den här typen av missriktade investeringar som är en av anledningarna till att Northscale startade. Affärssystemsvärlden har inte förändrats på 30 år — men allt runtomkring har det, inklusive kraven på hur data ska kunna plockas ut och användas. Vi är en ny aktör som bygger om affärssystemet så att datan faktiskt går att använda rätt ur källan — och slipper bolag från att betala konsulttimmar för att kompensera för struktur som borde varit rätt från början. Ett bra BI-projekt börjar med en ordentlig kontoplan och en tydlig dimensionsmodell, inte med ett licensavtal för Fabric.