Samla in krav för att migrera till Power BI

Den här artikeln beskriver steg 1, som handlar om att samla in och prioritera krav vid migrering till Power BI.

Kommentar

En fullständig förklaring av bilden ovan finns i Översikt över Power BI-migrering.

Betoningen i steg 1 ligger på informationsinsamling och planering för en enskild lösning som ska migreras till Power BI.

Utdata från steg 1 innehåller detaljerade krav som har prioriterats. Ytterligare aktiviteter i steg 2 och 3 måste dock slutföras för att fullt ut beräkna insatsnivån.

Viktigt!

Steg 1–5 representerar aktiviteter relaterade till en specifik lösning. Det finns beslut och aktiviteter på organisations-/klientorganisationsnivå som påverkar processen på lösningsnivå. Några av dessa planeringsaktiviteter på högre nivå beskrivs i artikeln Översikt över Power BI-migrering. När det är lämpligt bör du skjuta upp beslut på organisationsnivå för effektivitet och konsekvens.

Översikten över implementering av infrastrukturresurser beskriver dessa typer av strategiska och taktiska överväganden. Det har en betoning på organisationsimplementering.

Dricks

De flesta av de ämnen som beskrivs i den här artikeln gäller även för ett standardprojekt för Power BI-implementering.

Kompileringskrav

Inventeringen av befintliga BI-objekt, som kompilerats i stegen före migreringen, blir indata för kraven för den nya lösningen som ska skapas i Power BI. Insamlingskrav handlar om att förstå det aktuella tillståndet, samt vilka objekt som användarna vill ändra eller omstrukturera när rapporter görs om i Power BI. Detaljerade krav är användbara för planering av lösningsdistribution i steg 2, när du skapar ett konceptbevis i steg 3 och när du skapar den produktionsklara lösningen i steg 4.

Samla in rapportkrav

Kompilera detaljerad, lätt att referera till, information om rapporter, till exempel:

• Syfte, målgrupp och förväntad åtgärd: Identifiera syftet och affärsprocessen som gäller 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: Överväg att sitta med rapportkonsumenterna i den befintliga rapporten för att förstå exakt vad de gör med den. Du kan lära dig att vissa element i rapporten kan elimineras eller förbättras i den nya Power BI-versionen. Den här processen innebär ytterligare tidsinvesteringar, men den är värdefull för kritiska rapporter eller rapporter som används ofta.
• Ägare och ämnesexpert: Identifiera rapportägaren och eventuella ämnesexperter som är associerade med rapporten eller datadomänen. De kan bli ägare till den nya Power BI-rapporten framöver. Inkludera eventuella specifika krav för ändringshantering (som vanligtvis skiljer sig mellan IT-hanterade och företagshanterade lösningar) samt godkännanden och signeringar som krävs när ändringar görs i framtiden. Mer information finns i denna artikel.
• Innehållsleveransmetod: Förtydliga konsumenternas förväntningar på innehållsleverans. Det kan vara interaktiv körning på begäran, inbäddad i ett anpassat program eller leverans enligt ett schema med hjälp av en e-postprenumeration. Det kan också finnas krav för att utlösa aviseringsmeddelanden.
• Interaktivitetsbehov: Fastställa interaktivitetskrav som måste ha och vara bra att ha , till exempel filter, åtgärder för ökad detaljnivå eller åtgärder för visning av detaljerad information.
• Datakällor: Se till att alla datakällor som krävs av rapporten identifieras och att datasvarstidsbehoven (datas färskhet) förstås. Identifiera krav för historiska data, trender och ögonblicksbilder av data för varje rapport så att de kan anpassas till datakraven. Dokumentation om datakällor kan också vara användbar senare när du utför dataverifiering av en ny rapport med dess källdata.
• Säkerhetskrav: Förtydliga säkerhetskrav (till exempel tillåtna användare, tillåtna redigerare och eventuella säkerhetsbehov på radnivå), inklusive eventuella undantag från normal organisationssäkerhet. Dokumentera eventuella behov av datakänslighet, datasekretess eller regel-/efterlevnad.
• Beräkningar, KPI:er och affärsregler: Identifiera och dokumentera alla beräkningar, KPI:er och affärsregler som för närvarande definieras i den befintliga rapporten så att de kan anpassas till datakraven.
• Användbarhet, layout och kosmetiska krav: Identifiera specifika användbarhets-, layout- och kosmetiska behov relaterade till datavisualiseringar, grupperings- och sorteringskrav samt villkorsstyrd synlighet. Ta med eventuella specifika överväganden som rör leverans av mobila enheter.
• Utskrifts- och exportbehov: Avgör om det finns några krav som är specifika för export eller utskriftsklar layout. Dessa behov påverkar vilken typ av rapport som passar bäst (till exempel en Power BI, Excel eller sidnumrerad rapport). Tänk på att rapportkonsumenter tenderar att lägga stor vikt vid hur de alltid har gjort saker, så var inte rädd för att utmana deras sätt att tänka. Var noga med att tala om förbättringar snarare än förändring.
• Risker eller problem: Avgör om det finns andra tekniska eller funktionella krav för rapporter, samt eventuella risker eller problem med den information som presenteras i dem.
• Öppna problem och kvarvarande uppgifter: Identifiera framtida underhåll, kända problem eller uppskjutna begäranden att lägga till i kvarvarande uppgifter just nu.

Dricks

Överväg rangordningskrav genom att klassificera dem som måste ha eller trevligt att ha. Ofta frågar konsumenterna efter allt de kan behöva i förväg eftersom de tror att det är deras enda chans att göra förfrågningar. När du hanterar prioriteringar i flera iterationer gör du också kvarvarande uppgifter tillgängliga för intressenter. Det hjälper till med kommunikation, beslutsfattande och spårning av väntande åtaganden.

Samla in datakrav

Kompilera 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 kan konverteras till en importmodell.
• Typer av datakällor: Kompilera de typer av datakällor som är nödvändiga, inklusive centraliserade datakällor (till exempel ett företags informationslager) samt icke-standarddatakällor (till exempel flata filer eller Excel-filer som utökar företagets datakällor i rapporteringssyfte). Det är också viktigt att hitta var datakällor finns för datagatewayanslutningar .
• Datastruktur och rensningsbehov: Fastställa datastrukturen för varje nödvändig datakälla och i vilken utsträckning datarensningsaktiviteter är nödvändiga.
• Dataintegrering: Utvärdera hur dataintegrering ska hanteras när det finns flera datakällor och hur relationer kan definieras mellan varje modelltabell. Identifiera specifika dataelement som behövs för att förenkla modellen och minska dess storlek.
• Acceptabel datasvarstid: Fastställa datafördröjningens behov för varje datakälla. Det påverkar beslut om vilket datalagringsläge som ska användas. Datauppdateringsfrekvens för importmodelltabeller är också viktigt att känna till.
• Datavolym och skalbarhet: Utvärdera datavolymförväntningar, vilket tar hänsyn till beslut om stöd för stora modeller och utformning av DirectQuery- eller sammansatta modeller. Överväganden som rör historiska databehov är också viktiga att känna till. För större semantiska modeller (tidigare kallade datauppsättningar) är det också nödvändigt att fastställa inkrementell datauppdatering .
• Mått, KPI:er och affärsregler: Utvärdera behov av mått, KPI:er och affärsregler. De påverkar beslut om var logiken ska tillämpas: i den semantiska modellen eller i dataintegreringsprocessen.
• Huvuddata och datakatalog: Överväg om det finns huvuddataproblem som kräver uppmärksamhet. Kontrollera om integrering med en företagsdatakatalog är lämplig för att förbättra identifieringen, komma åt definitioner eller skapa konsekvent terminologi som godkänts av organisationen.
• Säkerhet och datasekretess: Avgör om det finns några specifika säkerhets- eller datasekretessöverväganden för semantiska modeller, inklusive säkerhetskrav på radnivå.
• Öppna problem och kvarvarande uppgifter: Lägg till kända problem, kända datakvalitetsfel, framtida underhåll eller uppskjutna begäranden till kvarvarande uppgifter just nu.

Viktigt!

Dataåteranvändning kan uppnås med delade semantiska modeller, som kan certifieras för att indikera tillförlitlighet och förbättra identifieringen. Återanvändning av dataförberedelser kan uppnås med dataflöden för att minska repetitiv logik i flera semantiska modeller. Dataflöden kan också avsevärt minska belastningen på källsystem eftersom data hämtas mindre ofta – flera semantiska modeller kan sedan importera data från dataflödet.

Identifiera förbättringsmöjligheter

I de flesta situationer sker vissa ändringar och förbättringar. Det är ovanligt att en direkt en-till-en-migrering sker utan någon refaktorisering eller förbättring. Tre typer av förbättringar som du kan överväga är:

• Konsolidering av rapporter: Liknande rapporter kan konsolideras med hjälp av tekniker som filter, bokmärken eller anpassning. Att ha färre rapporter, som var och en är mer flexibla, kan avsevärt förbättra upplevelsen för rapportkonsumenter. Överväg att optimera semantiska modeller för Q&A (frågor på naturligt språk) för att ge ännu större flexibilitet för rapportkonsumenter, så att de kan skapa egna visualiseringar.
• Effektivitetsförbättringar: Vid insamling av krav kan förbättringar ofta identifieras. Till exempel när analytiker kompilerar siffror manuellt eller när ett arbetsflöde kan effektiviseras. Power Query kan spela en stor roll när det gäller att ersätta manuella aktiviteter som för närvarande utförs. Om affärsanalytiker regelbundet utför samma aktiviteter för att rensa och förbereda data kan upprepningsbara Steg för förberedelse av Power Query-data ge betydande tidsbesparingar och minska fel.
• Centralisering av datamodell: En auktoritativ och certifierad semantisk modell fungerar som stamnät för hanterad bi med självbetjäning. I det här fallet hanteras data en gång och analytiker har flexibilitet att använda och utöka dessa data för att uppfylla deras rapporterings- och analysbehov.

Kommentar

Mer information om centralisering av datamodeller finns i avsnittet om disciplin i grunden och flexibilitet på gränsen.

Prioritera och utvärdera komplexitet

Nu är den inledande inventeringen tillgänglig och kan innehålla specifika krav. När du prioriterar den första uppsättningen BI-objekt som är redo för migrering bör rapporter och data betraktas kollektivt och oberoende av varandra.

Identifiera rapporter med hög prioritet, som kan innehålla rapporter som:

• Ge företaget ett betydande värde.
• Körs ofta.
• Krävs av ledande befattningshavare.
• Involvera en rimlig komplexitetsnivå (för att förbättra chanserna att lyckas under de inledande iterationerna för migrering).

Identifiera data med hög prioritet, som kan innehålla data som:

• Innehåller viktiga dataelement.
• Är vanliga organisationsdata som hanterar många användningsfall.
• Kan användas för att skapa en delad semantisk modell för återanvändning av rapporter och många rapportskapare.
• Innebär en rimlig nivå av komplexitet (för att förbättra chanserna att lyckas när den första migreringen iterationer).

Relaterat innehåll

I nästa artikel i den här Power BI-migreringsserien får du lära dig mer om steg 2, som handlar om att planera migreringen för en enda Power BI-lösning.

Andra användbara resurser är:

• Microsofts BI-transformering
• Planering av Power BI-implementering
• Frågor? Prova att fråga Power BI Community
• Förslag? Bidra med idéer för att förbättra Power BI

Erfarna Power BI-partner är tillgängliga för att hjälpa din organisation att lyckas med migreringsprocessen. Om du vill engagera en Power BI-partner går du till Power BI-partnerportalen.