Planering av Power BI-implementering: BI-lösningsplanering

Kommentar

Den här artikeln är en del av planeringsserien för Power BI-implementering. Den här serien fokuserar främst på Power BI-upplevelsen i Microsoft Fabric. En introduktion till serien finns i Implementeringsplanering för Power BI.

Den här artikeln hjälper dig att planera lösningar som stöder din BI-strategi (Business Intelligence). Det är främst inriktat på:

• BI- och analyschefer: Beslutsfattare som ansvarar för att övervaka BI-programmet och strategiskt viktiga BI-lösningar.
• Center of Excellence (COE), IT- och BI-team: De team som utformar och distribuerar företags-BI-lösningar för sin organisation.
• Ämnesexperter (SMF) och innehållsägare och skapare: De team och individer som kämpar för analys på en avdelning och utformar och distribuerar lösningar för självbetjäning, avdelnings-BI eller team BI-användningsscenarier .

En BI-strategi är en plan för att implementera, använda och hantera data och analys. Du definierar din BI-strategi genom att börja med STRATEGISK BI-planering. Strategisk planering hjälper dig att identifiera dina BI-fokusområden och -mål. För att fastställa vägen mot dina BI-mål beskriver du specifika viktiga resultat med hjälp av taktisk planering. Du kan sedan uppnå framsteg mot dessa viktiga resultat genom att planera och distribuera BI-lösningar.

Kommentar

I ramverket för mål och viktiga resultat (OKR) är målen tydliga, övergripande beskrivningar av vad du vill uppnå. Däremot är viktiga resultat specifika, uppnåeliga resultat för att mäta framsteg mot ett av dina mål.

Dessutom är initiativ eller lösningar processer eller verktyg som skapats för att hjälpa dig att uppnå ett eller flera viktiga resultat. Lösningar hanterar specifika databehov för användare. En lösning kan ha många former, till exempel en datapipeline, ett datasjöhus eller en Power BI-semantisk modell eller rapport.

Mer information om OKR finns i Lär känna OKR (Microsoft Viva Goals).

Det finns många metoder för att planera och implementera BI-lösningar. Den här artikeln beskriver en metod som du kan använda för att planera och implementera BI-lösningar som stöder din BI-strategi.

Följande diagram på hög nivå visar hur du utför BI-lösningsplanering.

Du vidtar följande steg för att genomföra BI-lösningsplanering.

Steg	Beskrivning
1	Sätt ihop ett projektteam som samlar in krav och definierar lösningens utformning.
2	Planera för lösningsdistribution genom att utföra den inledande installationen av verktyg och processer.
3	Genomför ett konceptbevis (POC) för att validera antaganden om designen.
4	Skapa och verifiera innehåll med hjälp av iterativa utvecklings- och valideringscykler.
5	Distribuera, stödja och övervaka lösningen när den har släppts till produktionsmiljön.

Kommentar

BI-lösningsplanering gäller både BI-projekt med självbetjäning och BI-företagsprojekt .

Mer information finns i Power BI-migreringsserien. Även om serien handlar om migrering är de viktigaste åtgärderna och övervägandena relevanta för lösningsplaneringen.

Steg 1: Samla in krav

Du påbörjar lösningsplaneringen genom att först samla in krav och definiera lösningsdesignen.

Obs! Strategisk och taktisk planering leds av ett arbetsteam som leder initiativet. Lösningsplaneringen leds däremot av ett projektteam som består av innehållsägare och skapare.

Att samla in rätt krav är viktigt för att uppnå en lyckad distribution och implementering av lösningen. Ett effektivt sätt att samla in krav är att identifiera och involvera rätt intressenter, gemensamt definiera det problem som ska lösas och använda den delade förståelsen av problemet för att skapa en lösningsdesign.

Här är några fördelar med att använda en samarbetsmetod för att samla in krav.

• Användarindata ger mer användbara design: Genom att engagera användare i fokuserade diskussioner för att samla in krav kan du mer effektivt samla in affärsdatabehov. Användare kan till exempel visa innehållsskapare hur de använder befintliga lösningar och ge feedback om den upplevda effektiviteten hos dessa lösningar.
• Undvik antaganden och minimera ändringsbegäranden: Diskussioner med användare visar ofta nyanser, undantag och dolda komplexiteter. Dessa insikter minskar sannolikheten för sena begäranden, vilket kan vara kostsamt att hantera.
• Registrering av användare ökar lösningens införande: Genom att involvera användare i design och tidig utveckling ger du dem möjlighet att påverka slutresultatet. Engagemang kan också ge användarna en känsla av intellektuellt ägande och ansvar för lösningen. Mycket involverade användare kommer att vara mer benägna att stödja lösningen och leda sin community av praxis i att använda den effektivt.
• Design ställer in förväntningar för intressenter och företagsanvändare: Genom att skapa modeller eller illustrationer av lösningsdesignen kan du tydligt visa intressenterna vad lösningen kommer att leverera. Det hjälper också genom att skapa en ömsesidig förståelse för det förväntade projektresultatet. Den här processen kallas även designtänkande och kan vara ett effektivt sätt att hantera och förstå komplexa problem.

Du kan använda olika metoder för att engagera användare och samla in krav. Du kan till exempel samla in krav med affärsdesign och teknisk design (beskrivs i detalj i senare avsnitt i den här artikeln).

Affärsdesign är en metod för att samla in affärskrav. Den fokuserar på att engagera företagsanvändare i affärsdesignsessioner för att gemensamt utforma lösningen. Utdata från en affärsdesign består av lösningsmodeller och beskrivande designdokumentation.

Teknisk design är en metod för att översätta affärskrav till tekniska krav och för att hantera designantaganden. En teknisk design fokuserar på att validera affärsdesignen och definiera en teknisk metod att använda. För att verifiera designen interagerar innehållsskapare vanligtvis med tekniska experter i fokuserade diskussioner som kallas tekniska designsessioner, där det behövs.

Viktigt!

Att samla in fel krav är en vanlig orsak till att implementeringarna misslyckas. Ofta samlar teamen in fel krav eftersom de samarbetar med fel intressenter, till exempel beslutsfattare som tillhandahåller begäranden uppifrån och ned för att lösningar ska skapas.

Att engagera företagsanvändare genom att använda samarbetsmetoder som en affärsdesign kan hjälpa dig att samla in bättre krav. Bättre krav leder ofta till effektivare utveckling och mer robusta lösningar.

Kommentar

För vissa team är det en stor förändring att anta en strukturerad kravinsamlingsprocess. Se till att du hanterar den här ändringen och att den inte stör lösningsplaneringen. Vi rekommenderar att du hittar sätt att anpassa dessa metoder så att de passar ditt team.

Förbereda för lösningsplanering

Du bör först förbereda dig för lösningsplanering genom att ta hänsyn till de faktorer som beskrivs i följande avsnitt.

• Identifiera vem som ska genomföra lösningsplanering: Som en del av den taktiska planeringen för BI skapade arbetsteamet en prioriterad kvarvarande lösning. I lösningsplaneringen ansvarar ett projektteam för att utforma, utveckla och distribuera en eller flera lösningar från kvarvarande uppgifter. För varje lösning i kvarvarande uppgifter bör du sätta ihop ett projektteam som ansvarar för lösningen. Förutom att köra BI-lösningsplanering bör projektteamet:
  • Definiera tidslinjer och milstolpar för lösningsplanering.
  • Identifiera och involvera rätt intressenter för kravinsamling.
  • Konfigurera en central plats för kommunikation, dokumentation och planering.
  • Kontakta intressenter för att samla in krav.
  • Kommunicera och samordna med intressenter och företagsanvändare.
  • Samordna iterativa utvecklings- och testcykler med företagsanvändare.
  • Dokumentera lösningen.
  • Registrera användare i lösningen genom att definiera och anta en träningsplan.
  • Ge stöd för lösningen efter distributionen.
  • Hantera rimliga användarbegäranden om att ändra eller uppdatera lösningen efter distributionen.
  • Utför överlämning av lösningen efter distributionen, om det behövs.
• Centralisera kommunikation och dokumentation: Det är viktigt att projektteamet centraliserar kommunikation och dokumentation för BI-lösningsplanering. Projektteamet bör till exempel centralisera krav, kommunikation mellan intressenter, tidslinjer och slutprodukt. Överväg att lagra all dokumentation i en centraliserad portal.
• Insamling av plankrav: Projektteamet bör börja med att planera affärsdesignsessionerna för att samla in affärskrav. Dessa sessioner är i form av interaktiva möten, och de kan följa ett liknande format som de strategiska planeringsworkshoparna.

Dricks

Överväg att identifiera och involvera de supportteam som ansvarar för lösningen tidigt i kravinsamlingsprocessen. För att effektivt stödja lösningen behöver supportteamen en omfattande förståelse för lösningen, dess syfte och användarna. Det är särskilt viktigt när projektteamet endast består av externa konsulter.

Samla in affärskrav

Att samla in rätt affärskrav är viktigt för att utforma rätt lösning. För att samla in rätt krav och definiera en effektiv lösningsdesign kan projektteamet genomföra affärsdesignsessioner tillsammans med företagsanvändare.

Syftet med affärsdesignsessionerna är att:

• Bekräfta det inledande lösningsomfånget.
• Definiera och förstå problemet som lösningen bör åtgärda.
• Identifiera rätt viktiga intressenter för lösningen.
• Samla in rätt affärskrav.
• Förbered en lösningsdesign som uppfyller affärskraven.
• Förbered dokumentation om stöddesign.

Följande diagram visar hur du samlar in affärskrav och definierar lösningsdesignen med hjälp av en affärsdesignmetod.

Diagrammet visar följande steg.

Artikel	Beskrivning
	Projektteamet påbörjar affärsdesignen genom att bekräfta lösningsomfånget som först dokumenterades i taktisk planering. De bör klargöra de affärsområden, system och data som lösningen kommer att omfatta.
	Projektteamet identifierar viktiga intressenter från användarcommunityn som kommer att delta i affärsdesignsessionerna. Viktiga intressenter är användare med tillräcklig kunskap och trovärdighet för att representera ämnesområdena i lösningen.
	Projektteamet planerar affärsdesignsessioner. Planering innebär att informera intressenter, organisera möten, förbereda slutprodukt och interagera med företagsanvändare.
	Projektteamet samlar in och undersöker befintliga lösningar som företagsanvändare för närvarande använder för att hantera befintliga affärsdatabehov. För att påskynda den här processen kan projektteamet använda relevant forskning från BI:s strategiska planering, som har dokumenterats i kommunikationshubben.
	Projektteamet driver affärsdesignsessioner med intressenter. Dessa sessioner är små, interaktiva möten, där projektteamet vägleder intressenter för att förstå affärsdatabehov och krav.
	Projektteamet avslutar affärsdesignen genom att presentera ett utkast till lösningsdesign för intressenter och andra användare för feedback och godkännande. Affärsdesignen lyckas när intressenterna är överens om att designen hjälper dem att uppnå sina affärsmål.

Affärsdesignen avslutas med följande slutprodukt.

• Utkast till lösningsdesign: Modeller, prototyper eller trådramsdiagram illustrerar lösningsdesignen. Dessa dokument översätter kraven till en konkret designritning.
• Lista över affärsmått: Kvantitativa fält som förväntas i lösningen, inklusive affärsdefinitioner och förväntade aggregeringar. Om möjligt rangordnar du dem efter prioritet för användarna.
• Lista över affärsattribut: Relevanta attribut och datastrukturer som förväntas i lösningen, inklusive affärsdefinitioner och attributnamn. Inkludera om möjligt hierarkier och rangordna attributen efter användarnas betydelse.
• Kompletterande dokumentation: Beskrivningar av viktiga funktions- eller efterlevnadskrav. Den här dokumentationen bör vara så exakt som möjligt, men ändå så kortfattad som möjligt.

Affärsdesignens slutprodukt används i och verifieras av den tekniska designen.

Dricks

Lösningsmodeller, prototyper eller trådramsdiagram kan skapa en tydlig förståelse för det förväntade resultatet, både för utvecklare och slutanvändare. Att skapa effektiva modeller kräver inte konstnärlig skicklighet eller talang. Du kan använda enkla verktyg som Microsoft Whiteboard, PowerPoint eller till och med bara en penna och ett papper för att illustrera designen.

Samla in tekniska krav

När du har slutfört affärsdesignen validerar projektteamet resultatet med hjälp av en teknisk design. Den tekniska designen är en metod som liknar affärsdesignen. Affärsdesignen fokuserar på affärsdatabehov, men den tekniska designen fokuserar på de tekniska aspekterna av en lösning. Ett viktigt resultat av den tekniska designen är lösningsplanen, som beskriver den slutliga lösningsdesignen och informerade uppskattningar av arbetet med att implementera den.

Kommentar

Till skillnad från affärsdesignen är den tekniska designen till stor del en oberoende undersökning av källdata och system som utförs av innehållsskapare och ägare.

Syftet med en teknisk design är att:

• Verifiera resultatet av affärsdesignen.
• Hantera tekniska antaganden i den aktuella designen.
• Identifiera relevanta datakällor i omfånget och definiera fältberäkningar och fältkällmappningar för varje datakälla.
• Översätt affärskraven till tekniska krav.
• Ta fram uppskattningar av den ansträngning som krävs för implementeringen.

Projektteamet engagerar tekniska eller funktionella intressenter i begränsade, fokuserade tekniska designsessioner. Dessa sessioner är interaktiva möten med funktionella intressenter för att samla in tekniska krav. Intressenter ansvarar för specifika funktionella områden som krävs för att lösningen ska fungera effektivt.

Exempel på intressenter i en teknisk design kan vara:

• Säkerhets- och nätverksteam: Ansvarar för att säkerställa säkerhet och efterlevnad av data.
• Funktionella team och dataförvaltare: Ansvarar för att kurera källdata.
• Arkitekter: Ägare av specifika plattformar, verktyg eller teknik.

Projektteamet engagerar intressenter i tekniska designsessioner för att hantera tekniska aspekter av lösningen. Tekniska aspekter kan vara:

• Datakällans anslutningar: Information om hur du ansluter till och integrerar datakällor.
• Nätverk och datagatewayer: Information om privata nätverk eller lokala datakällor.
• Mappning av fältkälla: Datamappningar av affärsmått och attribut till datakällfält.
• Beräkningslogik: En översättning av affärsdefinitioner till tekniska beräkningar.
• Tekniska funktioner: Funktioner som behövs för att stödja affärskrav.

Dricks

Projektteamet som utförde affärsdesignen bör också genomföra den tekniska designen. Av praktiska skäl kan dock olika personer leda den tekniska designen. I det här fallet börjar du den tekniska designen genom att granska resultatet av affärsdesignen.

Helst bör de personer som leder den tekniska designen ha en grundlig förståelse för resultaten och företagsanvändare.

Följande diagram visar hur du översätter affärskrav till tekniska krav med hjälp av en teknisk design.

Diagrammet visar följande steg.

Artikel	Beskrivning
	Projektteamet börjar den tekniska designen genom att definiera datakällans omfång baserat på resultatet av affärsdesignen. Datakällans omfång deklarerar vilka data som krävs för att skapa lösningen. För att identifiera rätt datakällor samråder projektteamet med de företag och funktionella små och medelstora företag.
	Projektteamet identifierar tekniska eller funktionella intressenter som ska involveras senare i de tekniska designsessionerna.
	Projektteamet planerar begränsade, fokuserade sessioner med funktionella intressenter för att hantera tekniska aspekter av lösningen. Planering innebär att informera intressenter, organisera möten och förbereda slutprodukt.
	Projektteamet undersöker tekniska krav. Forskningen omfattar att definiera fältberäkningar och datakällsmappningar, samt att hantera antaganden om affärsdesign med teknisk analys och dokumentation.
	Vid behov involverar projektteamet intressenter i tekniska designsessioner. Sessioner fokuserar på en specifik, teknisk aspekt av lösningen, till exempel säkerhets- eller datakällans anslutningar. Under dessa sessioner samlar projektteamet in kvalitativ feedback från intressenter och små och medelstora företag.
	Projektteamet förbereder sina resultat med hjälp av en lösningsplan som de presenterar för intressenter och beslutsfattare. Planen är en iteration och förlängning av affärsdesignresultaten som innehåller den slutliga designen, uppskattningarna och andra slutprodukt.
	Den tekniska utformningen bör avslutas med ett slutligt möte med intressenter och beslutsfattare för att avgöra om de ska fortsätta eller inte. Det här mötet ger en sista möjlighet att utvärdera lösningsplaneringen innan resurser har åtagit sig att utveckla lösningen.

Kommentar

Den tekniska designen kan avslöja oväntad komplexitet som kan göra lösningsplaneringen ogenomförbar med tanke på den aktuella resurstillgängligheten eller organisationens beredskap. I det här fallet bör lösningen omvärderas under den efterföljande taktiska planeringsperioden. Beroende på hur brådskande affärsdatabehoven är kanske en beslutsfattare, som den verkställande sponsorn, fortfarande vill fortsätta med ett konceptbevis, eller bara en del av den planerade lösningen.

Den tekniska designen avslutas med en lösningsplan som består av följande slutprodukt.

• Verktyg och tekniker: Lista över relevanta tekniska instrument som behövs för att genomföra lösningen. Listan innehåller vanligtvis relevanta nya licensalternativ (t.ex. infrastrukturkapacitet eller Premium per användare), funktioner och verktyg.
• Definierad lista över affärsmått: Beräkningar och fältkällsmappningar av affärsmåtten för alla datakällor inom omfånget. För att producera den här slutprodukten använder projektteamet listan över affärsmått som skapats i affärsdesignen.
• Definierad lista över affärsattribut: Mappningar med fältkälla för affärsattributen för alla datakällor inom omfånget. För att skapa den här slutprodukten använder projektteamet listan över affärsattribut som skapats i affärsdesignen.
• Ändrade design: Revideringar av lösningsdesignen baserat på ändringar i eller ogiltiga antaganden om affärsdesignen. Reviderade mönster är uppdaterade versioner av modeller, prototyper eller trådramsdiagram som skapats i affärsdesignen. Om inga revisioner krävs meddelar du att den tekniska designen validerar affärsdesignen.
• Uppskattning av insats: Uppskattning av de resurser som behövs för att utveckla, stödja och underhålla lösningen. Uppskattningen informerar det slutliga beslutet om huruvida lösningen ska genomföras eller inte.

Viktigt!

Se till att projektteamet meddelar intressenter om eventuella ändringar eller oväntade upptäckter från den tekniska designen. Dessa tekniska designsessioner bör fortfarande omfatta relevanta företagsanvändare. Se dock till att intressenterna inte exponeras i onödan för komplex teknisk information.

Dricks

Eftersom affärsmålen alltid utvecklas förväntas kraven ändras. Anta inte att kraven för BI-projekt är fasta. Om du kämpar med ändrade krav kan det vara en indikation på att din kravinsamlingsprocess inte är effektiv eller att dina utvecklingsarbetsflöden inte tillräckligt innehåller regelbunden feedback.

Checklista – Vid insamling av krav omfattar viktiga beslut och åtgärder:

• Förtydliga vem som äger lösningsplaneringen: Se till att roller och ansvarsområden är tydliga för projektteamet för varje lösning.
• Förtydliga lösningsomfånget: Lösningsomfånget bör redan dokumenteras som en del av BI:s taktiska planering. Du kan behöva ägna mer tid och arbete åt att förtydliga omfånget innan du börjar planera lösningen.
• Identifiera och informera intressenter: Identifiera intressenter för affärsdesign och teknisk design. Informera dem i förväg om projektet och förklara omfattningen, målen, nödvändiga tidsinvesteringar och slutprodukt från affärsdesignen.
• Planera och genomföra affärsdesignsessioner: Moderera affärsdesignsessionerna för att få fram information från intressenter och företagsanvändare. Be användarna visa hur de använder befintliga lösningar.
• Dokumentera affärsmått och attribut: Genom att använda befintliga lösningar och indata från intressenter skapar du en lista med affärsmått och attribut. I de tekniska designerna mappar du fälten till datakällan och beskriver beräkningslogik för kvantitativa fält.
• Utforma lösningen: Skapa iterativa modeller baserat på intressenternas indata som visuellt återspeglar det förväntade lösningsresultatet. Se till att modeller korrekt representerar och uppfyller affärskraven. Meddela företagsanvändare att modeller fortfarande måste valideras (och eventuellt revideras) under den tekniska utformningen.
• Skapa lösningsplanen: Undersöka källdata och relevanta tekniska överväganden för att säkerställa att affärsdesignen kan uppnås. I förekommande fall ska du beskriva viktiga risker och hot mot designen och eventuella alternativa metoder. Förbered vid behov en översyn av lösningsdesignen och diskutera den med intressenterna.
• Skapa uppskattningar av arbete: Som en del av den slutliga lösningsplanen beräknar du arbetet med att skapa och stödja lösningen. Motivera dessa uppskattningar med den information som samlats in under affärsdesign och tekniska designsessioner.
• Bestäm om planen ska fortsätta: Presentera den slutliga planen för intressenter och beslutsfattare för att slutföra kravinsamlingsprocessen. Syftet med det här mötet är att avgöra om lösningsutvecklingen ska fortsätta.

Steg 2: Planera för distribution

När projektteamet har slutfört insamlingen av krav, skapat lösningsplanen och fått godkännande för att fortsätta är den redo att planera för lösningsdistribution.

Planeringsuppgifterna för distributionen varierar beroende på lösningen, ditt utvecklingsarbetsflöde och distributionsprocessen. En distributionsplan avser vanligtvis många aktiviteter som omfattar planering och installation av verktyg och processer för lösningen.

Planera för att hantera viktiga områden

Projektteamet bör planera för viktiga områden för lösningsdistribution. Normalt bör planeringen ta itu med följande områden.

• Efterlevnad: Se till att alla efterlevnadskriterier som identifieras i kravinsamlingen hanteras av specifika åtgärder. Tilldela var och en av dessa åtgärder till specifika personer och definiera tydligt leveranstidsramen.
• Säkerhet: Bestäm hur olika lager av lösningsåtkomst ska hanteras och eventuella krav på datasäkerhetsregler . Granska om lösningssäkerheten är mer eller mindre strikt än standardinnehållet i klientorganisationen.
• Datagatewayer: Utvärdera om lösningen behöver en datagateway för att ansluta till datakällor. Avgör om specifika gatewayinställningar eller kluster med hög tillgänglighet är nödvändiga. Planera vem som ska kunna hantera gatewayanslutningar via gatewaysäkerhetsrollerna och hur du övervakar gatewayerna. Mer information finns i Etablera gatewayåtkomst.
• Arbetsytor: Bestäm hur du konfigurerar och använder arbetsytor. Ta reda på om lösningen kräver livscykelhanteringsverktyg som Git-integrering och distributionspipelines och om den kräver avancerad loggning med Azure Log Analytics.
• Support: Fastställa vem som ansvarar för att stödja och underhålla lösningen efter produktionsdistributionen. Om de personer som ansvarar för support skiljer sig från projektteamet bör du involvera dessa personer i utvecklingen. Se till att den som stöder lösningen förstår lösningsdesignen, det problem som den bör åtgärda, vem som ska använda den och hur.
• Användarutbildning: Förutse de ansträngningar som krävs för att träna användarcommunityn så att de effektivt kan använda lösningen. Överväg om några specifika åtgärder för ändringshantering är nödvändiga.
• Styrning: Identifiera eventuella styrningsrisker för lösningen. Förutse den ansträngning som krävs för att göra det möjligt för användare att effektivt använda lösningen, samtidigt som du minskar eventuella styrningsrisker (till exempel genom att använda känslighetsetiketter och principer).

Genomför den inledande installationen

Projektteamet bör utföra den inledande konfigurationen för att påbörja utvecklingen. Inledande konfigurationsaktiviteter kan vara:

• Initiala verktyg och processer: Utför första konfigurationen för alla nya verktyg och processer som behövs för utveckling, testning och distribution.
• Identiteter och autentiseringsuppgifter: Skapa säkerhetsgrupper och tjänsthuvudnamn som ska användas för att komma åt verktyg och system. Lagra autentiseringsuppgifterna på ett effektivt och säkert sätt.
• Datagatewayer:Distribuera datagatewayer för lokala datakällor (företagslägesgatewayer) eller datakällor i ett privat nätverk (virtuellt nätverk eller VNet, gatewayer).
• Arbetsytor och lagringsplatser: Skapa och konfigurera arbetsytor och fjärranslutna lagringsplatser för publicering och lagring av innehåll.

Kommentar

Distributionsplaneringen varierar beroende på lösningen och ditt önskade arbetsflöde. Den här artikeln beskriver endast övergripande planering och åtgärdsbara objekt.

Mer information om distributionsplanering finns i Planera distribution för migrering till Power BI.

Checklista – När du planerar distribution av lösningar är viktiga beslut och åtgärder:

• Planera för viktiga områden: Planera för att hantera de processer och verktyg som du behöver för att utveckla och distribuera din lösning. Hantera både tekniska områden (till exempel datagatewayer eller arbetsytor) och även implementering (till exempel användarutbildning och styrning).
• Utför den inledande installationen: Upprätta de verktyg, processer och funktioner som du behöver för att utveckla och distribuera lösningen. Dokumentera konfigurationen för att hjälpa andra som behöver göra en första konfiguration i framtiden.
• Testa datakällans anslutningar: Kontrollera att lämpliga komponenter och processer finns på plats för att ansluta till rätt data för att starta konceptbeviset.

Steg 3: Genomföra ett konceptbevis

Projektteamet genomför ett konceptbevis (POC) för att validera utestående antaganden och för att visa tidiga fördelar för företagsanvändare. En POC är en inledande designimplementering som är begränsad i omfattning och mognad. En välkörd POC är särskilt viktig för stora eller komplexa lösningar eftersom den kan identifiera och hantera komplexiteter (eller undantag) som inte identifierades i den tekniska designen.

Vi rekommenderar att du överväger följande när du förbereder en POC.

• Mål och omfattning: Beskriv syftet med lösnings-POC och de funktionella områden som den ska hantera. Projektteamet kan till exempel besluta att begränsa POC till ett enda funktionellt område, eller en specifik uppsättning krav eller funktioner.
• Källdata: Identifiera vilka data som ska användas i POC. Beroende på lösningen kan projektteamet välja att använda olika typer av data, till exempel:
  • Produktionsdata (verkliga)
  • Exempeldata
  • Genererade syntetiska data som liknar faktiska datavolymer och komplexitet som observerats i produktionsmiljöer
• Demonstration: Beskriv hur och när projektteamet ska demonstrera POC för intressenter och användare. Demonstrationer kan ges under regelbundna uppdateringar, eller när POC uppfyller specifika funktionella kriterier.
• Miljö: Beskriv var projektteamet ska skapa poc. En bra metod är att använda en distinkt sandbox-miljö för POC och distribuera den till en utvecklingsmiljö när den är klar. En sandbox-miljö har mer flexibla principer och flytande innehåll och fokuserar på att skapa snabba resultat. En utvecklingsmiljö följer däremot mer strukturerade processer som möjliggör samarbete och fokuserar på att slutföra specifika uppgifter.
• Framgångsvillkor: Definiera tröskelvärdet för när POC lyckas och bör gå vidare till nästa iteration och gå in i formell utveckling. Innan du startar POC bör projektteamet identifiera tydliga kriterier för när POC lyckas. Genom att ange dessa kriterier i förväg definierar projektteamet när POC-utvecklingen slutar och när iterativa utvecklings- och valideringscykler börjar. Beroende på POC:s mål kan projektteamet ange olika framgångskriterier, till exempel:
  • Intressenternas godkännande av POC
  • Validering av funktioner eller funktioner
  • Gynnsam granskning av POC av peer-datorer efter en fast utvecklingstid
• Fel: Se till att projektteamet kan identifiera poc-fel. Att identifiera fel tidigt hjälper till att undersöka rotorsaker. Det kan också bidra till att undvika ytterligare investeringar i en lösning som inte fungerar som förväntat när den distribueras till produktion.

Varning

När projektteamet genomför POC bör de vara aviseringar om antaganden och begränsningar. Projektteamet kan till exempel inte enkelt testa lösningens prestanda och datakvalitet med hjälp av en liten uppsättning data. Se dessutom till att POC:s omfång och syfte är tydligt för företagsanvändare. Se till att kommunicera att POC är en första iteration och betona att det inte är en produktionslösning.

Kommentar

Mer information finns i Genomföra konceptbevis för migrering till Power BI.

Checklista – När du skapar en POC är viktiga beslut och åtgärder:

• Definiera målen: Se till att POC:s mål är tydliga för alla personer som är inblandade.
• Definiera omfånget för POC: Se till att det inte tar för mycket utveckling att skapa POC, samtidigt som du levererar värde och visar lösningsdesignen.
• Bestäm vilka data som ska användas: Identifiera vilka källdata du ska använda för att göra POC, motivera ditt beslut och beskriva potentiella risker och begränsningar.
• Bestäm när och hur du ska demonstrera POC: Planera för att visa framsteg genom att presentera POC för beslutsfattare och företagsanvändare.
• Förtydliga när POC slutar: Se till att projektteamet beslutar om en tydlig slutsats för POC och beskriver hur den kommer att befordras till formella utvecklingscykler.

Steg 4: Skapa och verifiera innehåll

När POC lyckas flyttas projektteamet från POC till att skapa och verifiera innehåll. Projektteamet kan utveckla BI-lösningen med iterativa utvecklings- och valideringscykler. Dessa cykler består av iterativa versioner, där projektteamet skapar innehåll i en utvecklingsmiljö och släpper det till en testmiljö. Under utvecklingen registrerar projektteamet gradvis användarcommunityn i en pilotprocess till tidiga (betaversioner) av lösningen i testmiljön.

Dricks

Iterativ leverans uppmuntrar tidig validering och feedback som kan minimera ändringsbegäranden, främja lösningsimplementering och dra nytta av fördelarna före produktionsversionen.

Iterativa utvecklings- och valideringscykler fortsätter tills projektteamet kommer fram till en fördefinierad slutsats. Normalt avslutas utvecklingen när det inte finns några fler funktioner att implementera eller använda feedback om. När utvecklings- och valideringscyklerna avslutas distribuerar projektteamet innehållet till en produktionsmiljö med den slutliga produktionsversionen.

Följande diagram visar hur projektteamet iterativt kan leverera BI-lösningar med utvecklings- och valideringscykler.

Diagrammet visar följande steg.

Artikel	Beskrivning
	Projektteamet kommunicerar varje version till användarcommunityn och beskriver ändringar och nya funktioner. I bästa fall innehåller kommunikationen en lösningsdemonstration och Q&A, så att användarna förstår vad som är nytt i versionen och de kan ge verbal feedback.
	Under valideringen ger användarna feedback via ett centralt verktyg eller formulär. Projektteamet bör regelbundet granska feedbacken för att åtgärda problem, acceptera eller avvisa begäranden och informera kommande utvecklingsfaser.
	Projektteamet övervakar användningen av lösningen för att bekräfta att användarna testar den. Om det inte finns någon användning bör projektteamet samarbeta med användarcommunityn för att förstå varför. Låg användning kan tyda på att projektteamet måste vidta ytterligare åtgärder för aktivering och ändringshantering.
	Projektteamet svarar snabbt på användarfeedback. Om projektteamet tar för lång tid på sig att ta itu med feedback kan användarna snabbt förlora motivationen att tillhandahålla den.
	Projektteamet införlivar god feedback i lösningsplaneringen. Vid behov granskar de planeringsprioriteringarna för att klargöra och delegera uppgifter innan nästa utvecklingsfas börjar.
	Projektteamet fortsätter att utveckla lösningen för nästa version.
	Projektteamet itererar genom alla steg tills de når en fördefinierad slutsats och lösningen är redo för produktionsdistribution.

I följande avsnitt beskrivs viktiga överväganden för att använda iterativa utvecklings- och valideringscykler för att leverera BI-lösningar.

Skapa innehåll

Projektteamet utvecklar lösningen genom att följa sitt normala arbetsflöde för utveckling. De bör dock överväga följande punkter när de skapar innehåll.

• Under varje utvecklingscykel uppdaterar du dokumentationen för att beskriva lösningen.
• Avsluta varje utvecklingscykel med ett meddelande till användarcommunityn. Meddelanden bör publiceras på den centraliserade portalen och de bör ge korta beskrivningar av ändringar och nya funktioner i varje version.
• Med varje version bör du överväga att organisera sessioner för att demonstrera ändringar och nya funktioner i användarcommunityn och besvara eventuella verbala frågor.
• Definiera när iterativa utvecklings- och valideringscykler ska avslutas. Se till att det finns en tydlig process för att distribuera lösningen till produktionsmiljön, inklusive en övergång till support- och implementeringsaktiviteter.

Verifiera innehåll

Varje iterativ utvecklingscykel bör avslutas med innehållsverifiering. För BI-lösningar finns det vanligtvis två typer av validering.

• Utvecklarvalidering: Lösningstestning utförs av innehållsskapare och peer-datorer. Syftet med utvecklarvalidering är att identifiera och lösa alla kritiska och synliga problem innan lösningen görs tillgänglig för företagsanvändare. Problem kan gäller datakorrigering, funktioner eller användarupplevelsen. Helst verifieras innehållet av en innehållsskapare som inte utvecklade det.
• Användarverifiering: Lösningstestning utförs av användarcommunityn. Syftet med användarverifiering är att ge feedback för senare iterationer och identifiera problem som inte hittades av utvecklare. Formella användarvalideringsperioder kallas vanligtvis användargodkännandetestning (UAT).

Viktigt!

Se till att eventuella problem med datakvaliteten åtgärdas under utvecklarvalidering (före UAT). Dessa problem kan snabbt urholka förtroendet för lösningen, och de kan skada det långsiktiga införandet.

Dricks

När du utför användarverifiering bör du överväga tillfälliga, korta anrop med nyckelanvändare. Observera dem när de använder lösningen. Anteckna vad de har svårt att använda eller vilka delar av lösningen som inte fungerar som förväntat. Den här metoden kan vara ett effektivt sätt att samla in feedback.

Ta hänsyn till följande när projektteamet validerar innehåll.

• Uppmuntra användarfeedback: Med varje version begär du att användarna ger feedback och visar hur de effektivt kan göra det. Överväg att regelbundet dela exempel på feedback och förfrågningar som har lett till de senaste ändringarna och nya funktioner. Genom att dela exempel visar du att feedback bekräftas och värderas.
• Isolera större begäranden: Vissa feedbackobjekt kräver mer arbete för att åtgärda. Se till att projektteamet kan identifiera dessa objekt och diskutera om de ska implementeras eller inte. Överväg att dokumentera större begäranden att diskutera i senare taktiska planeringssessioner .
• Påbörja ändringshanteringsaktiviteter: Träna användare att använda lösningen. Se till att lägga extra arbete på nya processer, nya data och olika sätt att arbeta. Att investera i förändringshantering har en positiv avkastning på långsiktig lösningsimplementering.

När lösningen når en fördefinierad nivå av fullständighet och mognad är projektteamet redo att distribuera den till produktion. Efter distributionen övergår projektteamet från iterativ leverans till att stödja och övervaka produktionslösningen.

Kommentar

Utveckling och testning varierar beroende på lösning och önskat arbetsflöde.

I den här artikeln beskrivs endast planering på hög nivå och åtgärdsbara objekt. Mer information om iterativa utvecklings- och testcykler finns i Skapa innehåll för migrering till Power BI.

Checklista – När du skapar och validerar innehåll omfattar viktiga beslut och åtgärder:

• Använd en iterativ process för att planera och tilldela uppgifter: Planera och tilldela uppgifter för varje version av lösningen. Se till att processen för att planera och tilldela uppgifter är flexibel och innehåller användarfeedback.
• Konfigurera innehållslivscykelhantering: Använd verktyg och processer för att effektivisera och automatisera lösningsdistribution och ändringshantering.
• Skapa ett verktyg för att centralisera feedback: Automatisera feedbackinsamlingen med hjälp av en lösning som är enkel för dig och dina användare. Skapa ett enkelt formulär för att säkerställa att feedbacken är kortfattad men ändå kan användas.
• Schemalägg ett möte för att granska feedback: Träffas för att kort granska varje nytt eller enastående feedbackobjekt. Bestäm om du ska implementera feedbacken eller inte, vem som ska ansvara för implementeringen och vilka åtgärder som ska vidtas för att stänga feedbackobjektet.
• Bestäm när iterativ leverans avslutas: Beskriv villkoren för när de iterativa leveranscyklerna ska slutföras och när du ska släppa innehåll till produktionsmiljön.

Steg 5: Distribuera, stödja och övervaka

När det är klart distribuerar projektteamet den verifierade lösningen till produktionsmiljön. Projektteamet bör vidta viktiga implementerings- och supportåtgärder för att säkerställa att distributionen lyckas.

För att säkerställa en lyckad distribution utför du följande support- och implementeringsuppgifter.

• Kommunicera den slutliga versionen: Den verkställande sponsorn, en chef eller en annan person med tillräcklig auktoritet och trovärdighet bör tillkännage lanseringen till användarcommunityn. Kommunikationen bör vara tydlig, koncis och innehålla länkar till relevanta lösningar och supportkanaler.
• Genomföra utbildning för innehållskonsumenter: Utbildning bör vara tillgänglig för innehållskonsumenter under de första veckorna efter lanseringen till produktion. Utbildningen bör fokusera på att förtydliga lösningsomfånget, besvara användarfrågor och förklara hur du använder lösningen.
• Hantera feedback och begäranden: Överväg att ge användarna en kanal för att skicka feedback och förfrågningar till projektteamet. Se till att rimlig feedback och förfrågningar diskuteras och, när det är lämpligt, implementeras under supportperioden efter distributionen. Det är viktigt att du agerar på feedback och begäranden efter produktionsversionen. Det anger en flexibel lösning som svarar på föränderliga affärsbehov.
• Planera för att ansluta till användarcommunityn: Även efter att supportperioden efter distributionen är slut ser du till att lösningsägare regelbundet träffar användarcommunityn. Dessa möten är värdefulla källor till feedback för att se över din BI-strategi. Dessutom hjälper de till att stödja lösningsimplementering genom att aktivera användare.
• Överlämningsåtgärder: Medlemmar i projektteamet kanske inte ansvarar för att underhålla lösningen. I det här fallet bör teamet identifiera vem som är ansvarig och utföra en överlämning. Överlämningen bör ske strax efter lanseringen till produktion, och den bör hantera både lösningen och användarcommunityn.

Varning

Om du inte utför en effektiv överlämning kan det leda till problem som kan förebyggas med lösningsstöd och implementering under livscykeln.

Efter distributionen bör projektteamet planera att gå vidare till nästa lösning i den prioriterade kvarvarande lösningen. Se till att du samlar in ny feedback och förfrågningar och gör ändringar i den taktiska planeringen , inklusive kvarvarande uppgifter om lösningen, om det behövs.

Checklista – När du överväger lösningsdistribution är viktiga beslut och åtgärder:

• Skapa en kommunikationsplan: Planera hur du kommunicerar lanserings-, utbildnings- och andra lösningsstöd- eller implementeringsåtgärder. Se till att eventuella avbrott eller problem kommuniceras och åtgärdas snabbt under supportperioden efter distributionen.
• Följ igenom med en träningsplan: Träna användare att använda lösningen. Se till att träningen innehåller både live- och inspelade träningspass i flera veckor efter lanseringen.
• Utför överlämningsaktiviteter: Förbered vid behov en överlämning från utvecklingsteamet till supportteamet.
• Utför kontorstid för lösningen: Efter supportperioden efter distributionen bör du överväga att hålla regelbundna kontorstidssessioner för att besvara frågor och samla in feedback från användare.
• Konfigurera en kontinuerlig förbättringsprocess: Schemalägg en månatlig granskning av lösningen för att granska potentiella ändringar eller förbättringar över tid. Centralisera användarfeedback och granska feedback regelbundet mellan granskningar.

Relaterat innehåll

Mer information, åtgärder, beslutskriterier och rekommendationer som hjälper dig med beslut om Power BI-implementering finns i Planering för Power BI-implementering.