Vanliga frågor om
data, AI och beslutstöd

Det beror nästan alltid på att samma begrepp definieras olika i olika system. Ekonomisystemet räknar en sak, affärssystemet en annan, och Excel-filen däremellan en tredje. Konsekvensen är att möten ägnas åt att stämma av siffror i stället för att fatta beslut. Den dolda kostnaden är svår att räkna på, men en organisation med tio ledningspersoner som lägger en halv dag i månaden på att jaga avvikelser i rapporter — det är tid som aldrig kommer tillbaka. Vi börjar alltid med att enas om definitionerna, inte med att välja verktyg.

Mer data löser sällan problemet om ingen litar på den. Det vanligaste hindret är inte volym utan tillit: om controllern och verksamhetschefen ser olika siffror för samma nyckeltal väljer båda att lita på sin egen version. Grunden för ett fungerande beslutsstöd är gemensamma definitioner och en dataplattform som tillämpar dem konsekvent — så att hela organisationen utgår från samma bild.

Det beror på om er verksamhet är standardiserad nog för att passa ett standardsystem. Ett färdigt BI-verktyg som Power BI eller Qlik är bra för visualisering och rapportering — men det ersätter inte ett genomtänkt datalager. Att köpa ett BI-verktyg utan att ha ordning på datakällan är som att köpa en bra skärm till en dator som inte vet vilka filer den har. De flesta organisationer behöver båda: en solid dataplattform i grunden och ett BI-verktyg ovanpå.

Räkna på frigjord tid, inte på potentiell uppside. Konkreta räkneexempel: en controller som lägger en dag i veckan på manuell rapportering — det är 50 dagar per år. En inköpschef som inte ser avvikelser i leverantörspriser förrän kvartalsrapporten är klar — det är ett kvartal för sent. Däremot är löften om AI-driven intäktsökning svårare att belägga innan plattformen finns. Bygg business case på det mätbara, låt uppside vara bonus.

Vanligaste orsaken: rapporten svarar på frågor ingen längre ställer, eller kräver tolkning för att vara användbar. En månadsrapport med 40 diagram är inte ett beslutsunderlag — det är ett datauttag. Börja med att fråga ledningen vilka tre beslut de faktiskt vill kunna fatta snabbare. Bygg sedan bakåt därifrån. Det är ett samtal som sällan äger rum, och det är nästan alltid mer värdefullt än att lägga till fler visualiseringar.

En välbyggd dataplattform med tydlig arkitektur och dokumenterade definitioner håller länge — vi förvaltar lösningar vi byggde för 10–20 år sedan, och kärnan är fortfarande intakt. Det som åldras är tekniklagret: verktyg, API:er, integrationer. Byggs plattformen däremot på ett enskilt verktyg utan genomtänkt arkitektur riskerar ni att behöva börja om när det verktyget förändras. Investera i strukturen, inte i en specifik produktversion.

De bästa vi sett börjar inte med teknik. De börjar med en fråga de faktiskt vill ha svar på — "Varför minskar marginalen på produkt X?" eller "Vilka kunder är på väg att churna?" — och bygger sedan bakåt till vilken data som krävs. Tekniken blir ett medel, inte ett mål. Det tar längre tid att komma igång, men lösningen används sedan av hela organisationen i stället för att stanna hos IT-avdelningen.

Microsoft Fabric är en samlad dataplattform som ersätter flera separata Azure-tjänster: Azure Synapse, Azure Data Factory, Power BI och delar av Azure Data Lake. Allt i en gemensam yta med ett licensmodell. Om ni redan använder delar av det här ekosystemet är Fabric ofta ett naturligt nästa steg. Om ni börjar från noll är det Microsofts rekommenderade väg framåt. Behöver ni det? Beror på skala, ambitionsnivå och budget — men det är svårt att motivera att börja med de äldre tjänsterna separat när Fabric finns.

Power BI är visualiseringsverktyget — det som slutanvändaren ser. Azure Synapse var Microsofts svar på ett samlat analyslager, men är nu i praktiken inbakat i Fabric. Fabric är nästa generation och samlar allt ovan under ett tak. Byter man? Inte i ett svep. De flesta migrerar stegvis — behåller Power BI-rapporterna och byter ut datalagret bakom. Vi har hjälpt SL med exakt den typen av modernisering.

Troligen ja, om ni har mer än ett par datakällor. Power BI kan koppla direkt mot källsystem, men det skapar problem på sikt: rapporten för försäljning frågar affärssystemet, rapporten för ekonomi frågar ekonomisystemet, och ingen vet vad som händer när de inte stämmer. Ett datalager samlar och harmoniserar datan en gång — Power BI blir då ett renodlat visualiseringsverktyg som utgår från en gemensam, granskad källa.

Det är ett av de viktigaste argumenten för ett ordentligt mellanlagret. Om Power BI-rapporterna är direktkopplade mot källsystemet måste ni uppdatera varje rapport när systemet byts. Med ett datalager i mitten bryter ni den kopplingen: byt ut källsystemet, uppdatera integrationen mot datalagret, och rapporterna märker ingenting. Vi byggde det här mönstret för Plantagen när de konsoliderade data från butiker i tre länder med olika system.

En semantisk modell är det lager som översätter teknisk databasstruktur till ett språk verksamheten förstår. I stället för att slutanvändaren ser tabellnamnet "fct_order_line_v2" ser de "Orderrader". Måtten är fördefinierade och beräknade konsekvent — "omsättning" betyder samma sak i alla rapporter som bygger på modellen. Det är det som möjliggör self-service BI på riktigt: användaren bygger egna rapporter utan att behöva förstå databasstrukturen bakom.

Ett traditionellt datalager lagrar strukturerad data i ett väldefinierat schema — snabbt att fråga mot, men stelt. En datasjö lagrar allt i råformat — flexibelt, men lätt att drunkna i om ingen håller ordning. Ett lakehouse försöker kombinera båda: lagra rådata som i en sjö, med en strukturerad yta för analys ovanpå. Microsoft Fabric är i praktiken ett lakehouse-system. Vilket som passar er beror på hur strukturerad er data är och hur tekniskt mogen er organisation är att hantera rådata.

AI förstärker det den riktas mot. Riktar ni den mot data ni förstår och litar på, får ni rätt svar snabbare. Riktar ni den mot data ingen riktigt äger, får ni fel svar snabbare — och litar på dem ändå. I praktiken innebär det att ni behöver: konsistenta definitioner, dokumenterat ursprung (varifrån kommer siffran?), rimlig täckning (saknas data för 30% av kunderna är modellen blind på dem) och någon form av kvalitetsvalidering som körs kontinuerligt.

Realtid är värt kostnaden när glappet mellan att något händer och att någon agerar på det faktiskt kostar pengar. I en produktion där en maskin ligger nere är det uppenbart. I en detaljhandel där ni vill flytta om lager baserat på försäljningstakt under dagen — troligen också. Men för månadsrapportering till ledningsgruppen, strategisk planering eller leverantörsutvärdering är realtid onödig komplexitet. Frågan är inte vad som är tekniskt möjligt — det är vad er organisation faktiskt hinner agera på.

Ofta en kombination. En BICC (Business Intelligence Competence Center) fungerar bra som intern koordinator och ägare av definitioner och governance — men kräver att ni kan bemanna den med rätt kompetens, vilket är svårt på en regional arbetsmarknad. Konsulter är bra för initialt bygge, komplexa migrationer och spetskompetens ni inte har råd att ha på heltid. Vi har hjälpt Kriminalvården att bygga upp exakt den strukturen: strategi, pm3-baserad förvaltningsorganisation och teknisk plattform i ett sammanhängande uppdrag.

Minimum är: gemensamma definitioner på era viktigaste nyckeltal, dokumenterade på ett ställe alla kan hitta, med tydligt ägarskap för varje definition. Allt annat — datakatalog, lineage, kvalitetsregler, automatiserad validering — byggs på det fundamentet. Börjar ni med verktygen innan ni har definitionerna är det lätt att bygga något tekniskt imponerande som ingen litar på.

Verksamheten bör äga definitionerna och kvalitetskraven — de vet vad "en aktiv kund" eller "en försenad order" ska betyda. IT äger infrastrukturen och ser till att datan faktiskt flödar och lagras rätt. Problemet uppstår när IT äger hela frågan och verksamheten inte är delaktig: då byggs tekniskt korrekta lösningar som ingen i verksamheten litar på. Det omvända fungerar inte heller — verksamheten utan teknisk förankring tappar konsistens och underhållbarhet. Det kräver ett samarbete, och det är ett organisatoriskt arbete lika mycket som ett tekniskt.

Det är ett av de vanligaste och svåraste problemen vi möter. Tekniken kan inte lösa det — det kräver ett beslut: vem har mandat att bestämma vad "marginal" eller "omsättning" ska innebära i er organisation? Ofta finns ingen tydlig ägare, vilket innebär att alla har rätt i sin kontext och ingen har fel — men ingen kan jämföra. Processen är att samla relevanta parter, synliggöra konflikten och dokumentera en överenskommen definition. Det tar ett möte. Det som tar tid är att bestämma vem som ska kalla till det mötet.

Det praktiska minimum: kartlägg var personuppgifter finns i datakällan, se till att åtkomst till persondata är rollbaserad och loggas, och bygg en process för att hantera begäran om radering. Det sistnämnda är ofta svårast i en dataplattform — historiska snapshots kan innehålla data som ska raderas. Azure Purview och Fabric har inbyggda verktyg för klassificering och lineage som hjälper, men processen och ägarskapet måste ni bestämma internt.

Förvaltning handlar om att svara på tre frågor löpande: vem ansvarar för att plattformen fungerar, vem beslutar om vad som ska byggas härnäst, och hur finansieras det? En vanlig modell är pm3-inspirerad: en förvaltningsledare som äger helheten, ett råd med representanter från de verksamheter som nyttjar plattformen, och en teknisk resurskärna (internt eller externt). Vi hjälpte Kriminalvården att sätta upp exakt det — och tre år senare drivs det utan oss.

Vanligaste orsaken: man köper verktyget innan man har ordning på data och definitioner. Slutanvändare som kan bygga egna rapporter är en styrka — men om de kan dra slutsatser från data ingen granskat multipliceras felen i stället för att elimineras. Self-service fungerar när det finns en pålitlig, väldefinierad datamodell att bygga på, tydliga rättigheter för vem som får göra vad, och utbildning som faktiskt anpassats till hur ni jobbar — inte en generisk Power BI-kurs.

Det kräver att rapporten som ersätter Excel-filen faktiskt är enklare att använda — inte bara tekniskt bättre. Det vanligaste misstaget är att bygga en Power BI-rapport som är lika svår att tolka som Excel-filen den ersätter, fast med fler klick. Börja med vilka beslut rapporten ska stödja, inte med vilka siffror den ska visa. Sedan: identifiera var data kommer ifrån och bygg ett lager som hämtar den automatiskt. Sista steget är att stänga Excel-filen — inte steg ett.

Den vanligaste tidsslukaren är insamlingen, inte analysen. Om budgetarbetet börjar med att samla in Excel-filer från ett tiotal enheter, konsolidera dem manuellt och sedan börja räkna — är det processen som behöver åtgärdas, inte kalkylarket. Verktyg som automatiserar insamling och konsolidering (det finns dedikerade system för detta, och Microsoft Fabric kan fylla delar av rollen) kortar processen med dagar. Men det kräver att ni enas om strukturen och definitionerna innan ni väljer verktyg.

Det beror på hur de är byggda. Fem varningssignaler på att er Power BI-lösning behöver ses över: olika rapporter ger olika svar på samma fråga, ingen vet vilken datamodell som gäller, rapporten uppdateras inte när källan ändras, åtkomsten är inte kontrollerad, eller ingen annan än den som byggde den förstår hur den fungerar. Känner ni igen något av det — hör av er, så tittar vi på det.

En rapport är ett statiskt eller periodiskt dokument som visar vad som hänt — typiskt månadsrapporten till styrelsen, årsredovisningsunderlaget, den konsoliderade P&L:en. Ett dashboard är ett levande, interaktivt verktyg för löpande uppföljning — försäljning per dag, lagerstatus, beläggning. Båda fyller en funktion. Misstaget är att bygga ett dashboard när man behöver en rapport, eller att skicka en rapport när man behöver ett dashboard. Vilken ni behöver avgörs av vad mottagaren ska göra med informationen.

Det är ett vanligare problem än de flesta vill erkänna. Första steget är en genomgång: finns dokumentation, är datakopplingarna beskrivna, förstår någon internt hur modellen är byggd? Saknas det — och det gör det ofta — är det värt att lägga tid på en ordentlig granskning och dokumentation innan ni bygger vidare. Annars riskerar ni att bygga på en okänd grund. Vi tar den typen av granskningar, och vi är vana vid att ta över lösningar vi inte själva har byggt.

Det handlar nästan alltid om att dashboarden svarar på fel frågor, kräver för mycket tolkning, eller sitter i ett system chefen inte öppnar dagligen. Tre saker som hjälper: bygg för ett specifikt beslut, inte för allmän information — "ska vi skjuta på kampanjen?" är ett bättre designmål än "försäljningsöversikt". Distribuera insikter aktivt via Teams eller mail i stället för att kräva att folk navigerar till ett verktyg. Och involera cheferna i vad de vill se, inte i vad ni kan visa.

Rapportering visar vad som hänt. AI kan visa vad som troligtvis kommer hända — eller varför något hände, om träningsdata och modell är rätt byggd. Det praktiska: en rapport visar att försäljningen sjönk förra månaden. En prediktiv modell kan flagga vilka kunder som sannolikt minskar sina köp de kommande 90 dagarna. Skillnaden i affärsnytta är stor, men förutsättningarna är andra: AI kräver historisk data av tillräcklig kvalitet och volym, ett definierat problem att lösa, och en organisation som kan agera på signalerna.

I praktiken: det låter dig ställa frågor om din data i naturligt språk och får ett diagram eller en summering som svar. Det fungerar bra för enkla frågor mot välstrukturerad data. Det fungerar sämre när modellen bakom är komplex, när definitioner är otydliga, eller när frågan kräver att Copilot förstår er affärsterminologi. Det är ett bra komplement för vana Power BI-användare — men det ersätter inte en genomtänkt datamodell och löser inte problemet om data inte är pålitlig från början.

En AI-agent som ska agera autonomt i en process — t.ex. flagga avvikelser, skicka notiser eller initiera ett flöde — kräver tre saker: pålitlig data att fatta beslut på, tydliga regler för vad som är en avvikelse (och vem som definierar dem), och en process för vad som händer när agenten har fel. Det sistnämnda glöms ofta bort. En agent som ibland har fel utan att det finns en människa som granskar är inte ett AI-system — det är ett slumpsystem. Börja smalt, med ett avgränsat problem, och utöka när ni förstår beteendet.

Det korta svaret: via ett datalager i mitten. ERP:et är inte byggt för att exponera data på ett sätt som AI-modeller trivs med — det är byggt för transaktioner. Vägen är: extrahera data från ERP:et till ett datalager (i Fabric, Azure eller motsvarande), transformera och kvalitetssäkra den, bygg sedan prediktiva modeller ovanpå det lagret. Det gör att AI-modellerna inte är hårt kopplade till ERP:ets struktur och att ni kan byta eller uppgradera ERP utan att riva AI-lagret.

Machine learning tränas på er egen historiska data för att förutsäga eller klassificera — "kommer den här ordern att försenas?", "vilka kunder har hög churnrisk?". Generativ AI (GPT, Copilot och liknande) är förtränade på enorma textkorpusar och kan svara på frågor, sammanfatta och skriva. I ett beslutsstödsammanhang är machine learning ofta mer relevant: det ger specifika, kalibrerade svar om er verksamhet. Generativ AI är däremot användbar för att göra data mer tillgänglig — naturliga språkfrågor mot ett dashboard, automatiserade kommentarer i en rapport.

Microsoft Fabric och Azure Machine Learning har AutoML-funktioner som bygger och utvärderar modeller utan att ni skriver en rad kod. Det räcker långt för standardproblem som churnprediktion, efterfrågeprognoser och avvikelsedetektering. Förutsättningen är fortfarande att ni har tillräckligt med historisk data och att den är konsistent. En data scientist behövs när problemet är ovanligt komplext, när AutoML inte räcker, eller när ni vill förstå varför modellen fattar de beslut den fattar — inte bara vad den förutsäger.

Ni utvärderar den mot historisk data som modellen inte sett under träningen — det kallas ett testset. En modell som förutsäger rätt i 85% av fallen låter bra, men det beror helt på problemet. Om 90% av alla ordrar är i tid är en modell som alltid svarar "i tid" 90% korrekt och totalt oanvändbar. Rätt mått beror på vad ni vill optimera. Utöver noggrannhet är det viktigt att förstå i vilka fall modellen är osäker — och se till att en människa granskar de fallen.

AI Foundry är Microsofts plattform för att bygga, driftsätta och övervaka AI-applikationer och agenter i Azure. Det är relevant när ni vill bygga egna AI-lösningar som integrerar med er data och era system — inte bara använda färdiga Copilot-funktioner. Behöver ni det? Om ni vill ha generativa AI-funktioner anpassade till er verksamhet (t.ex. en intern assistent som svarar på frågor om er produktkatalog eller era kundavtal) är Foundry rätt väg. För standard BI och prediktion räcker Fabric och Azure ML.