Genomföra konceptbevis för migrering till Power BI

Den här artikeln beskriver steg 3, som handlar om att genomföra ett konceptbevis (POC) för att minimera risker och åtgärda okända så tidigt som möjligt när du migrerar till Power BI.

Kommentar

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

Fokus för steg 3 är att åtgärda okända och minimera risker så tidigt som möjligt. En teknisk POC är användbar för att validera antaganden. Det kan göras iterativt tillsammans med planering av lösningsdistribution (beskrivs i steg 2).

Utdata från den här fasen är en Power BI-lösning som är smal i omfånget, hanterar de inledande öppna frågorna och är redo för ytterligare arbete i steg 4 för att göra den produktionsklar.

Viktigt!

Vi har inte för avsikt att POC ska vara disponibelt arbete. I stället förväntar vi oss att det blir en tidig iteration av den produktionsklara lösningen. I din organisation kan du referera till den här aktiviteten som en prototyp, pilot, modell, snabbstart eller minimalt livskraftig produkt (MVP). Att genomföra en POC är inte alltid nödvändigt och det kan till och med ske informellt.

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. När din organisation blir mer erfaren med Power BI minskar behovet av att genomföra POC:er. Men på grund av den snabba lanseringstakten med Power BI och den kontinuerliga introduktionen av nya funktioner kan du regelbundet utföra tekniska POC:er i utbildningssyfte.

Ange POC-mål och omfång

När du utför en POC fokuserar du på följande mål:

• Kontrollera dina antaganden om hur en funktion fungerar.
• Lär dig mer om skillnader i hur Power BI fungerar jämfört med den äldre BI-plattformen.
• Verifiera inledande förståelse av vissa krav med ämnesexperter.
• Skapa en liten semantisk modell (tidigare känd som en datamängd) med verkliga data för att förstå och identifiera eventuella problem med datastrukturen, relationer, datatyper eller datavärden.
• Experimentera med och verifiera DAX-syntaxuttryck som används av modellberäkningar.
• Testa datakällans anslutning med hjälp av en gateway (om den ska vara en gatewaykälla).
• Testa datauppdatering med hjälp av en gateway (om det ska vara en gatewaykälla).
• Verifiera säkerhetskonfigurationer, inklusive säkerhet på radnivå när det är tillämpligt.
• Experimentera med layout och kosmetiska beslut.
• Kontrollera att alla funktioner i Power BI-tjänst fungerar som förväntat.

POC-omfånget är beroende av vad det okända är eller vilka mål som måste valideras med kollegor. För att minska komplexiteten bör du hålla en POC så smal som möjligt när det gäller omfång.

Oftast med en migrering är kraven välkända eftersom det finns en befintlig lösning att börja från. Beroende på omfattningen av de förbättringar som ska göras eller befintliga Power BI-kunskaper ger en POC dock fortfarande ett betydande värde. Dessutom kan snabba prototyper med konsumentfeedback vara lämpliga för att snabbt klargöra kraven – särskilt om förbättringar görs.

Viktigt!

Även om en POC endast innehåller en delmängd data, eller endast innehåller begränsade visuella objekt, är det ofta viktigt att ta den från början till slut. Det vill: från utveckling i Power BI Desktop till distribution till en utvecklingsarbetsyta i Power BI-tjänst. Det är det enda sättet att fullt ut uppnå POC-målen. Det gäller särskilt när Power BI-tjänst måste leverera viktiga funktioner som du inte har använt tidigare, till exempel en DirectQuery-semantisk modell som använder enkel inloggning. Under POC fokuserar du på aspekter som du är osäker på eller behöver verifiera med andra.

Hantera skillnader i Power BI

Power BI kan användas som ett modellbaserat verktyg eller som ett rapportbaserat verktyg. En modellbaserad lösning omfattar utveckling av en datamodell, medan en rapportbaserad lösning ansluter till en redan distribuerad datamodell.

På grund av dess extrema flexibilitet finns det vissa aspekter av Power BI som kan skilja sig i grunden från den äldre BI-plattform som du migrerar från.

Överväg att designa om dataarkitekturen

Om du migrerar från en äldre BI-plattform som har ett eget semantiskt lager är skapandet av en importsemantisk modell sannolikt ett bra alternativ. Power BI fungerar bäst med en star-schematabelldesign . Om det äldre semantiska lagret inte är ett star-schema är det därför möjligt att viss omdesign kan krävas för att dra full nytta av Power BI. Att försöka definiera ett semantiskt lager som följer designprinciper för star-schema (inklusive relationer, vanliga mått och vänlig organisationsterminologi) fungerar som en utmärkt utgångspunkt för rapportförfattare med självbetjäning.

Om du migrerar från en äldre BI-plattform där rapporter refererar till relationsdatakällor med hjälp av SQL-frågor eller lagrade procedurer, och om du planerar att använda Power BI i DirectQuery-läge, kanske du kan uppnå nära en en-till-en-migrering av datamodellen.

Varning

Om du ser skapandet av många Power BI Desktop-filer som består av en enda importerad tabell är det vanligtvis en indikator på att designen inte är optimal. Om du märker den här situationen kan du undersöka om användningen av delade semantiska modeller som skapas med hjälp av en star-schemadesign kan uppnå ett bättre resultat.

Bestämma hur instrumentpanelskonverteringar ska hanteras

I BI-branschen är en instrumentpanel en samling visuella objekt som visar viktiga mått på en enda sida. I Power BI representerar dock en instrumentpanel en specifik visualiseringsfunktion som bara kan skapas i Power BI-tjänst. När du migrerar en instrumentpanel från en äldre BI-plattform har du två alternativ:

1. Den äldre instrumentpanelen kan återskapas som en Power BI-rapport. De flesta rapporter skapas med Power BI Desktop. Sidnumrerade rapporter och Excel-rapporter är också alternativa alternativ.
2. Den äldre instrumentpanelen kan återskapas som en Power BI-instrumentpanel. Instrumentpaneler är en visualiseringsfunktion i Power BI-tjänst. Visuella instrumentpaneler skapas ofta genom att fästa visuella objekt från en eller flera rapporter, Q&A eller Snabbinsikter.

Dricks

Eftersom instrumentpaneler är en Power BI-innehållstyp bör du avstå från att använda ordet instrumentpanel i rapporten eller instrumentpanelens namn.

Fokusera på helheten när du återskapar visuella objekt

Varje BI-verktyg har sina styrkor och fokusområden. Därför kanske de exakta visuella rapportobjekt som du var beroende av i en äldre BI-plattform kanske inte har någon nära motsvarighet i Power BI.

När du återskapar visuella rapportobjekt fokuserar du mer på de övergripande affärsfrågor som tas upp i rapporten. Det tar bort trycket att replikera designen för varje visuellt objekt på exakt samma sätt. Även om innehållskonsumenter uppskattar konsekvens när de använder migrerade rapporter är det viktigt att inte fastna i tidskrävande debatter om små detaljer.

Relaterat innehåll

I nästa artikel i den här Power BI-migreringsserien får du lära dig mer om steg 4, som handlar om att skapa och validera innehåll när du migrerar till Power BI.

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.