Samla in krav för att migrera till Power BI

I den här artikeln beskrivs steg 1, som handlar om att samla in och prioritera kraven vid en migrering till Power BI.

Tyngdpunkten för steg 1 ligger på att samla in information och planera för en enskild lösning som ska migreras till Power BI.

Resultatet från steg 1 innehåller detaljerade krav i prioritetsordning. Ytterligare aktiviteter i steg 2 och 3 måste slutföras för att helt kunna uppskatta nivån på ansträngningen.

Sammanställa krav

Inventeringen av befintliga BI-artefakter, som sammanställs i stegen före migreringen, blir indata för kraven för den nya lösningen som ska skapas i Power BI. Att samla in krav handlar om att förstå det aktuella läget, samt vilka punkter som användare skulle vilja ändra eller omstrukturera när rapporter återskapas i Power BI. Detaljerade krav är användbara för distributionsplanering för lösningen i steg 2, under skapandet av ett konceptbevis i steg 3 och när du skapar den produktionsklara lösningen i steg 4.

Samla in rapportkrav

Sammanställ grundlig och lättfattlig information om rapporter, till exempel:

• Syfte, målgrupp och förväntad åtgärd: Identifiera syftet och affärsprocessen för varje rapport, samt målgrupp, analytiskt arbetsflöde och förväntad åtgärd som ska vidtas av rapportkonsumenter.
• Hur konsumenterna använder rapporten: Det kan vara en bra idé att sätta sig ner med konsumenter av den befintliga rapporten och ta reda på exakt vad de gör med den. Du kanske får veta att vissa delar av rapporten kan strykas eller förbättras i den nya Power BI-versionen. Den här processen omfattar ytterligare tidsinvesteringar, men det är värdefullt för kritiska rapporter eller rapporter som används ofta.
• Ägare och ämnesexpert: Identifiera rapportägaren och eventuella ämnesexperter som är kopplade till rapporten eller datadomänen. De kan bli ägare till den nya Power BI-rapporten framöver. Ta med eventuella specifika krav för ändringshantering (som normalt skiljer sig mellan IT-hanterade och verksamhetshanterade lösningar) samt godkännanden och signeringar som krävs när ändringar görs i framtiden.
• Metod för innehållsleverans: Klargör rapportkonsumenternas förväntningar på innehållsleverans. Det kan vara på begäran, interaktiv körning, inbäddat i ett anpassat program eller enligt ett schema med hjälp av en e-postprenumeration. Det kan också finnas krav på att utlösa aviseringsmeddelanden.
• Interaktivitetsbehov: Fastställ krav på interaktivitet som måste ha och är bra att ha, till exempel filter, åtgärder för att öka detaljgranskning eller detaljgranskningsåtgärder.
• Datakällor: Se till att alla datakällor som krävs av rapporten identifieras och att behoven av datasvarstid (dataaktualitet) har förståtts. Identifiera krav på historiska data, trendande och ögonblicksbilder av data för varje rapport så att de kan samordnas med datakraven. Datakällans dokumentation kan också vara användbar senare när du utför datavalidering för en ny rapport med dess källdata.
• Säkerhetskrav: Klargör säkerhetskraven (till exempel tillåtna tittare, tillåtna redigerare och eventuella säkerhetsbehov på radnivå), inklusive eventuella undantag från normal organisationssäkerhet. Dokumentera eventuella behov av datakänslighetsnivåer, datasekretess eller regelefterlevnad.
• Beräkningar, KPI:er och affärsregler: Identifiera och dokumentera alla beräkningar, KPI:er och affärsregler som för närvarande är definierade i den befintliga rapporten så att de kan samordnas med datakraven.
• Användbarhet, layout och kosmetiska krav: Identifiera särskilda krav på användbarhet, layout och utseende som rör datavisualiseringar, gruppering och sorteringskrav och villkorlig synlighet. Ta med eventuella specifika överväganden som rör leverans till mobila enheter.
• Utskrifts- och exportbehov: Ta reda på om det finns några särskilda krav i fråga om utskrifter, exporter eller pixelperfekta layouter. De här behoven påverkar vilken typ av rapport som passar bäst (till exempel en Power BI- eller Excel-rapport eller en sidnumrerad rapport). Tänk på att rapportkonsumenter tenderar att lägga stor vikt vid hur de alltid har gjort, så dra dig inte för att utmana deras sätt att tänka. Kom ihåg att prata om förbättringar i stället för förändringar.
• Risker eller problem: Ta reda på om det finns andra tekniska eller funktionella krav för rapporter, samt eventuella risker eller problem avseende den information som presenteras i dem.
• Öppna ärenden och eftersläpning: Identifiera eventuellt framtida underhåll, kända problem eller uppskjutna begäranden som ska sättas på väntelista för tillfället.

Samla in datakrav

Sammanställ detaljerad information om data, till exempel:

• Befintliga frågor: Identifiera om det finns befintliga rapportfrågor eller lagrade procedurer som kan användas av en DirectQuery-modell eller en sammansatt modell eller som kan konverteras till en importmodell.
• Olika typer av datakällor: Sammanställ vilka typer av datakällor som behövs, inklusive centraliserade datakällor (till exempel ett informationslager för företag) och datakällor som inte är standard (till exempel flata filer eller Excel-filer som utökar företagsdatakällor för rapporteringssyften). Det är också viktigt att ta reda på var datakällor finns för datagateway-anslutningar.
• Datastruktur och rengöringsbehov: Bestäm datastrukturen för varje nödvändig datakälla och i vilken utsträckning datarengöring krävs.
• Dataintegrering: Utvärdera hur dataintegreringen ska hanteras när det finns flera datakällor och hur relationer kan definieras mellan varje modelltabell. Identifiera de enskilda dataelement som behövs för att förenkla modellen och minska storleken.
• Godtagbar datasvarstid: Fastställ behoven av datasvarstider för varje datakälla. Det påverkar beslut om vilket datalagringsläge som ska användas. Frekvensen för datauppdateringar för importmodellstabeller är viktig att känna till.
• Datavolym och skalbarhet: Utvärdera förväntningar på datavolymer, vilket kommer att påverka beslut om stormodellsstöd och utformning av DirectQuery-modeller eller sammansatta modeller. Överväganden om behov av historiska data är också nödvändiga att känna till. För större datauppsättningar är det också nödvändigt att fastställa inkrementell datauppdatering.
• Mått, KPI:er och affärsregler: Utvärdera behovet av mått, KPI: er och affärsregler. De påverkar beslut om var logiken ska tillämpas: i datamängden eller i dataintegreringsprocessen.
• Huvuddata och datakatalog: Fundera över om det finns några problem med huvuddata som behöver åtgärdas. Kontrollera om integreringen med en företagsdatakatalog är lämplig för att förbättra identifieringsmöjligheterna, komma åt definitioner eller skapa konsekvent terminologi som godkänts av organisationen.
• Säkerhet och datasekretess: Ta reda på om det finns några särskilda överväganden angående säkerhet och datasekretess för datamängder, inklusive krav på säkerhet på radnivå.
• Öppna ärenden och eftersläpning: Lägg till eventuella kända problem, kända defekter i datakvaliteten, framtida underhåll eller uppskjutna begäranden på väntelista för tillfället.

Identifiera förbättringsmöjligheter

I de flesta situationer görs vissa ändringar och förbättringar. Det är ovanligt med en direkt ett-till-ett-migrering utan någon omstrukturering eller förbättring. Tre typer av förbättringar kan vara:

• Konsolidering av rapporter: Liknande rapporter kan konsolideras med hjälp av tekniker som filter, bokmärken eller anpassning. Att ha färre men mer flexibla rapporter kan avsevärt förbättra upplevelsen för rapportkonsumenter. Överväg att optimera datamängder för Frågor och svar (frågor på naturligt språk) för att ge rapportkonsumenter ännu större flexibilitet, så att de kan skapa egna visualiseringar.
• Effektivitetsförbättringar: Under kravinsamlingen kan förbättringar ofta identifieras. När till exempel analytiker sammanställer siffror manuellt eller när ett arbetsflöde kan effektiviseras. Power Query kan spela upp en viktig roll för att ersätta manuella aktiviteter som utförs för närvarande. Om affärsanalytikerna upptäcker att de regelbundet utför samma aktiviteter för att rensa och förbereda data, kan repeterbara dataförberedelsesteg i Power Query ge avsevärda tidsbesparingar och minska fel.
• Centralisering av datamodell: En auktoritativ och certifierad datamängd fungerar som ryggraden för hanterad självbetjänings-BI. I det här fallet hanteras data en gång, och analytikerna har sedan flexibiliteten att använda och utöka dessa data så att de uppfyller deras rapporterings- och analysbehov.

Prioritera och utvärdera komplexitet

I det här läget är den första inventeringen tillgänglig och kan innehålla specifika krav. När du prioriterar den första uppsättningen BI-artefakter som är klara för migrering bör rapporter och data betraktas som både kollektivt och oberoende av varandra.

Identifiera rapporter med hög prioritet, vilket kan omfatta rapporter som:

• har betydande värde för verksamheten.
• körs ofta.
• krävs av ledningen eller chefer.
• innebär en rimlig komplexitetsnivå (för att förbättra chanserna att lyckas under den första migreringen).

Identifiera data med hög prioritet, vilket kan omfatta data som:

• innehåller kritiska dataelement.
• är vanliga organisationsdata som används i många scenarier.
• kan användas för att skapa en delad datamängd för återanvändning av rapporter och flera olika rapportförfattare.
• innebär en rimlig komplexitetsnivå (för att förbättra chanserna att lyckas under den första migreringen).

Nästa steg

I nästa artikel i den här serien om Power BI-migrering lär du dig mer om steg 2 som handlar om att planera migreringen för en enskild Power BI-lösning.

Andra användbara resurser är:

• Microsoft BI-omvandling
• Planera ett white paper för en företagsdistribution för Power BI
• Har du några frågor? Fråga Power BI Community
• Har du förslag? Bidra till att förbättra Power BI

Våra erfarna Power BI-partners finns där och kan hjälpa din organisation att lyckas med migreringsprocessen. Om du vill kontakta en Power BI-partner går du till partnerportalen för Power BI.