När jag kommer in i en kunds Power BI-miljö finns det tre saker jag nästan alltid tittar på direkt.
- Har de stängt av Auto date/time?
- Är deras semantiska modeller utformade kring tydliga analytiska syften?
- Har de någon form av versionshantering?
Varför just dessa tre? För att de tidigt ger mig en fingervisning om tre olika områden av mognad:
- Förstår de Power BI som verktyg?
- Förstår de dimensionell modellering?
- Ser de Power BI-utveckling som mjukvaruutveckling?
Självklart är det här inga definitiva mått på någons erfarenhet. Det finns alltid undantag. Men de är förvånansvärt användbara indikatorer på hur en miljö har utformats, utvecklats och underhållits. Låt oss titta på varför de spelar roll. Och om ni vill att vi bedömer er miljö kan ni ladda ner vårt Health Check-formulär för mer information.
Dolda Auto date/time-tabeller
Auto date/time är en av de inställningar i Power BI Desktop som lätt går obemärkt förbi. När den är påslagen, vilket den är som standard, skapar Power BI automatiskt dolda datumtabeller för varje lämplig datumkolumn i Import-modeller. Varje tabell får en egen beräknad datumkolumn och extra kolumner för vanliga datumattribut. Och normalt ser ni inte de här tabellerna när ni tittar på er modell.
Beroende på era data kan ni få flera extra tabeller utan att ens märka det. Varför spelar det roll? För att tabellerna tar minne, gör modellen större och kan ge extra bearbetningstid vid uppdatering. Och kanske viktigare: de är inte nödvändigtvis den bästa grunden för konsekvent time intelligence i hela er analyslösning.
För de flesta produktionsmodeller rekommenderar jag i stället en riktig datumdimension. En som ni själva styr och kan återanvända för alla era faktatabeller. Auto date/time är inte fel i sig, men det är en inställning ni bör förstå och använda medvetet.
Monstermodeller
Det här är förmodligen det område jag känner starkast för. Och det är något jag ser förvånansvärt ofta.
En semantisk modell börjar med försäljningsrapportering. Sedan behöver någon lagersaldon. Sedan inköp. Sedan ekonomi. Och i stället för att fundera på om behoven hör ihop läggs fler tabeller, relationer och measures till. Till slut har ni en enorm modell som försöker besvara varje fråga verksamheten någonsin kan ställa.
Men bara för att ni kan lägga allt i en semantisk modell betyder det inte att ni borde.
Att ha flera faktatabeller är inte fel i sig. En väldesignad modell kan absolut innehålla flera faktatabeller, även med olika granularitet. Det viktiga är att modellen har ett tydligt definierat analytiskt syfte och att varje faktatabell har en konsekvent granularitet. När de principerna förbises blir det snabbt komplicerat. Relationerna blir svårare att förstå. DAX-measures blir allt mer komplexa. Utvecklare bygger nödlösningar, och användarna börjar ifrågasätta siffrorna.
En stor modell är inte nödvändigtvis en dålig modell. Men komplexitet ska vara avsiktlig, inte resultatet av att man hela tiden lägger till mer utan att se över designen.
Om ni står inför en monstermodell, börja med att identifiera vilka analytiska områden den behöver stödja. Ni kanske hittar möjligheter att separera ansvarsområden, återanvända dimensioner och skapa modeller som är lättare att förstå och underhålla.
Målet är inte att skapa så många semantiska modeller som möjligt. Det är att skapa rätt modeller.
Utveckling med versionshantering
Det tredje jag tittar efter är versionshantering. Oavsett om ni har en utvecklare eller ett helt team. Vad händer om någon gör en ändring som förstör något som fungerade i går? Kan ni se vad som ändrades? Kan ni gå tillbaka? Och kan flera utvecklare samarbeta utan att riskera varandras arbete?
Om er strategi för versionshantering är en mapp full av PBIX-filer med namn som Final, Final_v2 och Final_ReallyFinal kan det vara dags att tänka om.
Med Power BI Projects (PBIP), textbaserade modell- och rapportdefinitioner och Git-integration har vi mycket bättre möjligheter att hantera Power BI-utveckling. Men verktygen i sig är inte det viktigaste.
Det handlar om att ha en medveten process för att hantera ändringar, skydda det som fungerar och gå vidare med trygghet. Power BI-utveckling är mjukvaruutveckling. Den förtjänar samma omsorg om kvalitet och underhållbarhet.
Tre kontroller. Tre perspektiv.
De här tre kontrollerna berättar inte allt om kvaliteten i en Power BI-miljö. Men tillsammans ger de en användbar utgångspunkt.
De säger något om hur väl organisationen förstår verktyget, principerna för dimensionell modellering och de arbetssätt som krävs för att underhålla analyslösningar över tid.
Och i slutändan påverkar alla tre verksamheten. Prestanda, tillförlitlighet, underhållbarhet och det förtroende användarna har för sina rapporter.
Att bygga en rapport som fungerar i dag är en sak. Att bygga en analyslösning som fortsätter att skapa värde när verksamheten utvecklas är något helt annat.
Hur står sig er Power BI-miljö?
Om ni är osäkra på hur er miljö står sig i de här grunderna, eller om ni redan upplever prestandaproblem, komplicerade modeller eller svårigheter att hantera utvecklingen, hjälper vi gärna till.
Vår Analytics Health Check ger en oberoende bedömning av er analysmiljö och hjälper er att identifiera risker, förbättringsmöjligheter och var ni bör lägga er kraft.
För att veta vad som går att förbättra är ofta det första steget mot att få ut mer av det ni redan har byggt.
Nyfikna på er miljö? Kontakta oss eller börja med vår Analytics Health Check.
