Ambitionen är bättre beslut.
Resultatet blir fler rapporter.

För CFO:er, controllerchefer och FP&A-ansvariga börjar många BI-initiativ med samma mening: vi behöver bättre beslutsunderlag.

Arton månader senare finns rapporterna på plats. De är snyggare än de gamla, uppdateras automatiskt och bygger på bättre datakvalitet än tidigare.

Och budgeten görs fortfarande i Excel.

Det är sällan ett tekniskt misslyckande. Ofta är det ett gap mellan vad som beställdes och vad som faktiskt behövdes. Gapet uppstår tidigt, ofta redan i kravarbetet, men blir synligt först när lösningen ska användas skarpt.

För en ekonomifunktion är det mer än en irritation. Problemet är sällan att organisationen saknar rapporter. Problemet är att rapporterna inte sitter ihop med den process där beslut, ansvar och justeringar faktiskt sker. Det är skillnaden mellan en rapportmiljö och en planeringsprocess.

Ambitionen ligger på steg fyra

Business caset formuleras nästan alltid i termer av beslut: snabbare prognoser, tidigare varningssignaler, mindre manuellt arbete och en gemensam bild av läget. Det är en ambition som hör hemma på steg tre och fyra i mognadstrappan.

Rapportering och analys svarar på vad som hände och varför. Planering och uppföljning svarar på vad vi ska göra och om vi gjorde det. BI-plattformar är byggda för de två första stegen. Det är där de är riktigt bra.

Projektet levererar därför ofta exakt det plattformen är byggd för. Beställaren trodde bara att hen köpte mer än så.

Det är därför många BI-projekt i praktiken blir FP&A-frågor. Så snart organisationen vill påverka framtiden, inte bara förstå historiken, räcker inte rapporteringen ensam.

Vad som faktiskt finns på plats efter ett år

Mönstret återkommer i många organisationer:

• Rapporterna används dagligen av controllers, sällan av linjechefer.
• Budgetprocessen ser ut som den gjorde för fem år sedan: mallar ut, mallar in, konsolidering i kalkylark.
• Prognosen görs kvartalsvis, eftersom den kostar för mycket arbete för att göras oftare.
• Ingen kan svara på vem som ändrade en siffra i planen, eller varför.
• Det finns två sanningar: den i BI-lösningen och den i kalkylarket som ledningen faktiskt tittar på.

Ingen av punkterna hamnar i projektets slutrapport. Projektet levererade det som stod i kravspecifikationen. Just därför är problemet svårt att se i tid.

Fyra orsaker till gapet

1. Projektet mäts på leverans, inte på användning

Styrgruppen följer antal rapporter, datakällor och testfall. Ingen mäter hur många beslut som faktiskt fattas i lösningen. Ett projekt kan därför bli godkänt och samtidigt sakna effekt.

2. Plattformen är byggd för att läsa, verksamheten behöver skriva

Power BI har ingen inbyggd funktion för att skriva tillbaka data. En chef kan se avvikelsen men inte lägga in sin justerade prognos. Så fort någon behöver mata in en siffra lämnar processen plattformen. Den kommer sällan tillbaka.

3. Omfattningen sätts av data som finns, inte av beslut som ska fattas

Kravarbetet börjar ofta i källsystemen: vilka tabeller finns, vad går att hämta och vad är kvalitetssäkrat? Det är en rimlig teknisk ingång, men den bygger lösningen bakifrån. Besluten som ska stödjas kommer aldrig riktigt upp på bordet.

4. Ägarskapet stannar kvar i IT

Efter driftstart förvaltas lösningen av dem som byggde den. Verksamheten beställer ändringar i stället för att göra dem själv. Varje ny dimension och varje ny kostnadsställestruktur blir ett ärende. Efter ett halvår har verksamheten hittat en snabbare väg, och den vägen heter Excel. Mönstret återkommer i många implementationer: se även sju vanliga misstag i FP&A-implementationer.

Vad gapet kostar

Kostnaden syns sällan som en post i budgeten. Den syns i tempot.

• Prognoscykeln blir för dyr för att köras ofta, vilket gör att avvikelser upptäcks sent.
• Två parallella sanningar tvingar fram avstämningsmöten som inte tillför något.
• Tilliten till lösningen sjunker, och med den viljan att investera vidare.
• Den som drev business caset får försvara en investering som inte gav det som utlovades.

Den sista punkten är den som väger tyngst i praktiken, även om den aldrig skrivs ned.

Den verkliga kostnaden är alltså inte rapporterna som byggdes. Den är beslutstakten som aldrig förbättrades.

Fem frågor att ställa innan ni startar

Frågorna nedan tar ungefär en timme att gå igenom i en beslutsgrupp. De ändrar ofta projektets omfattning innan det kostar något att ändra den.

1. Vilka fem beslut ska lösningen faktiskt förbättra?

Formulera dem som beslut, inte som rapporter. ”Ska vi ta in mer lager inför hösten?” är ett beslut. ”Lagerrapport per artikelgrupp” är en leverans. Svaret avgör om lösningen styrs av affärsfrågor eller av rapportönskemål.

2. Var finns Excel kvar dagen efter driftstart?

Svaret på frågan visar projektets verkliga omfattning. Om budget, prognos och simulering ligger utanför scopet kan det vara helt rimligt, så länge alla vet om det. Det viktiga är att se om Excel är ett medvetet komplement eller ett tecken på att lösningen inte täcker den faktiska processen.

3. Vem i verksamheten äger lösningen efteråt?

IT ska förvalta plattformen. Verksamheten ska äga modellen. Om ingen namngiven person i verksamheten kan ändra en hierarki på egen hand kommer lösningen att åldras snabbt. Svaret avgör om modellen blir ett levande styrverktyg eller ett tekniskt förvaltningsobjekt.

4. Ska någon kunna mata in en siffra, eller bara läsa?

Det här är den fråga som oftast hoppas över, och den som får störst konsekvenser. Inmatning ställer helt andra krav på behörighet, versionshantering och spårbarhet än ren rapportering. Svaret avgör om projektet är ett BI-projekt, ett planeringsprojekt eller båda.

5. Hur ser vi att plan och utfall glider isär, och hur snabbt?

En lösning som visar utfall men inte planen bredvid kan bara berätta vad som hände. Den kan inte varna. Svaret avgör om lösningen stödjer uppföljning i efterhand eller styrning medan det fortfarande går att agera.

Var gränsen faktiskt går att flytta

Om någon behöver kunna mata in en siffra räcker det inte med fler rapporter. Då behövs stöd för planering, spårbarhet, ansvar och versionshantering. I praktiken finns tre vägar: ett separat planeringssystem, en egenbyggd lösning med Power Apps och databas, eller ett tillägg som lägger inmatning direkt i Power BI. Fördelar och nackdelar med alternativen finns i jämförelsen av FP&A-verktyg.

Den tredje vägen har blivit mer intressant eftersom den låter organisationen behålla datamodellen den redan byggt. Aimplan är ett exempel på den typen av lösning, men inte det enda sättet att lösa problemet. Lösningen körs som visuals inne i Power BI och Fabric. Planeringsdatan lagras i organisationens egen Azure SQL eller Fabric-databas och skrivs tillbaka i samma rapporter där utfallet visas.

I praktiken kan fler funktionsområden då flytta in i BI-lösningen i stället för att leva vid sidan av den:

• Ekonomi: budget, prognos, kostnadsställen, personal, investeringar och strukturerad finansiell rapportering.
• Verksamhet: sälj- och verksamhetsplanering, efterfrågan, inköp, lager och kapacitet.
• Försäljning: intäktsbudget, distrikt, kvoter och ersättning kopplat till CRM-data.
• Projekt: projektbudget, resurser, lönsamhet och prognos per uppdrag.

Till det kommer sådant som en ren rapportlösning aldrig behöver hantera: prognosversioner som går att jämföra sida vid sida, kommentarer på enskilda celler, godkännandeflöden, radnivåsäkerhet via Entra ID och en logg över vem som ändrade vad och när. Det gör inte ett svagt arbetssätt bra, men det gör ett fungerande arbetssätt möjligt att styra och följa upp.

Tre invändningar värda att ta på allvar

Inmatning utan styrning blir snabbt sämre än Excel. Om alla får skriva överallt har ni bytt ut ett spårlöst kalkylark mot en spårlös databas. Bestäm behörigheter, versioner och godkännanden innan första siffran matas in, inte efteråt.

Ett tillägg är ett beroende. Fråga leverantören var planeringsdatan lagras, vem som äger den och hur ni får ut den om ni byter verktyg. Svaret ska gå att få skriftligt. I det här fallet ligger datan i er egen databasmiljö, vilket är en väsentlig skillnad mot ett fristående planeringssystem. Men frågan ska ändå ställas.

Verktyg löser inte process. Om budgetprocessen tar fyra månader för att den innehåller tre förhandlingsrundor blir den inte kortare av att flytta in i Power BI. Den blir mer spårbar. Det är värt något, men det är inte samma sak. Det finns dessutom lägen där svaret bör bli nej: de är samlade i när Aimplan inte är rätt val.

Var fattas besluten när projektet är klart?

De organisationer som får ut det de betalade för skiljer sig sällan i teknikval. De skiljer sig i att någon tidigt ställde en obekväm fråga: när det här är klart, var kommer besluten faktiskt att fattas?

Om svaret fortfarande är Excel finns två hederliga alternativ: bygg för det och acceptera att lösningen är ett rapportverktyg, eller bygg bort det och ta höjd för vad det kräver.

Det som inte fungerar är att hoppas att det löser sig under vägen.

Läs vidare

• När Aimplan inte är rätt val – fem situationer då något annat passar bättre
• Bästa FP&A-verktygen 2026 – sex verktyg jämförda
• Sju vanliga misstag i FP&A-implementationer
• Forecasting in Power BI – grunderna för den som börjar från början