Planlægning af Power BI-implementering: PLANLÆGNING af BI-løsning

Bemærk

Denne artikel er en del af power BI-implementeringsplanlægningsserierne. I denne serie fokuseres der primært på Power BI-oplevelsen i Microsoft Fabric. Du kan få en introduktion til serien under Planlægning af implementering af Power BI.

Denne artikel hjælper dig med at planlægge løsninger, der understøtter din BI-strategi (Business Intelligence). Det er primært rettet mod:

• BI- og analysedirektører eller -ledere: Beslutningstagere, der er ansvarlige for at lede BI-programmet og strategisk vigtige BI-løsninger.
• COE (Center of Excellence), IT og BI-teams: De teams, der designer og udruller VIRKSOMHEDS-BI-løsninger til deres organisation.
• Emneeksperter (SMV'er) og indholdsejere og -oprettere: De teams og enkeltpersoner, der er forkæmper for analyser i en afdeling og designer og udruller løsninger til selvbetjeningsscenarier, afdelings-BI eller team BI-forbrugsscenarier .

En BI-strategi er en plan for implementering, brug og administration af data og analyser. Du definerer din BI-strategi ved at starte med strategisk planlægning af BI. Strategisk planlægning hjælper dig med at identificere dine BI-fokusområder og -målsætninger. Hvis du vil bestemme vejen til fremskridt i forhold til dine BI-målsætninger, skal du beskrive specifikke vigtige resultater ved hjælp af taktisk planlægning. Du opnår derefter fremskridt i forhold til disse vigtige resultater ved at planlægge og udrulle BI-løsninger.

Bemærk

I rammerammen for målsætninger og vigtige resultater (OKR'er) er målene klare beskrivelser på højt niveau af, hvad du vil opnå. I modsætning hertil er vigtige resultater specifikke og opnåelige resultater for at måle status i forhold til et af dine mål.

Derudover er initiativer eller løsninger processer eller værktøjer, der er udviklet til at hjælpe dig med at opnå et eller flere vigtige resultater. Løsninger løser specifikke databehov for brugerne. En løsning kan tage mange former, f.eks. en datapipeline, et data lakehouse eller en semantisk Power BI-model eller -rapport.

Du kan få mere at vide om OKR'er under Lær OKRs (Microsoft Viva Goals) at kende.

Der er mange metoder til at planlægge og implementere BI-løsninger. I denne artikel beskrives én fremgangsmåde, som du kan bruge til at planlægge og implementere BI-løsninger, der understøtter din BI-strategi.

Følgende diagram på højt niveau viser, hvordan du udfører BI-løsningsplanlægning.

Du skal udføre følgende trin for at udføre PLANLÆGNING af BI-løsning.

Trin	Beskrivelse
1	Saml et projektteam, der indsamler krav og definerer løsningens design.
2	Planlæg installation af løsninger ved at udføre den indledende konfiguration af værktøjer og processer.
3	Udfør en blåstempling af løsningen for at validere antagelser om designet.
4	Opret og valider indhold ved hjælp af iterative udviklings- og valideringscyklusser.
5	Udrul, understøt og overvåg løsningen, når den er udgivet i produktionsmiljøet.

Bemærk

BI-løsningsplanlægning gælder for både selvbetjenings-BI - og enterprise BI-projekter .

Du kan få flere oplysninger i migreringsserien til Power BI. Mens serien omhandler migrering, er de vigtigste handlinger og overvejelser relevante for løsningsplanlægningen.

Trin 1: Indsaml krav

Du påbegynder løsningsplanlægningen ved først at indsamle krav og definere løsningsdesignet.

Bemærk! Strategisk og taktisk planlægning ledes af et arbejdsteam, som leder initiativet. I modsætning hertil ledes løsningsplanlægningen af et projektteam, der består af indholdsejere og oprettere.

Indsamling af de rette krav er afgørende for at opnå en vellykket udrulning og implementering af løsninger. En effektiv måde at indsamle krav på er ved at identificere og involvere de rette interessenter, i fællesskab definere det problem, der skal løses, og bruge den delte forståelse af problemet til at oprette et løsningsdesign.

Her er nogle fordele ved at bruge en samarbejdsbaseret tilgang til indsamling af krav.

• Brugerinput giver mere nyttige design: Ved at engagere brugerne i fokuserede diskussioner for at indsamle krav kan du mere effektivt registrere forretningsdatabehov. Brugerne kan f.eks. vise indholdsoprettere, hvordan de bruger eksisterende løsninger, og give feedback om den opfattede effektivitet af disse løsninger.
• Undgå antagelser, og reducer ændringsanmodninger: Diskussioner med brugere afslører ofte nuancer, undtagelser og skjulte kompleksiteter. Disse indsigter reducerer sandsynligheden for anmodninger i den sene fase, hvilket kan være dyrt at håndtere.
• Onboarding af brugere øger implementering af løsninger: Ved at involvere brugere i design og tidlig udvikling giver du dem mulighed for at påvirke det endelige resultat. Inddragelse kan også give brugerne en følelse af intellektuelt ejerskab og ansvarlighed for løsningen. Meget involverede brugere vil være mere tilbøjelige til at anbefale løsningen og lede deres community af praksis i at bruge den effektivt.
• Design sætter forventninger til interessenter og erhvervsbrugere: Ved at producere modeller eller illustrationer af løsningsdesignet kan du tydeligt vise interessenterne, hvad løsningen vil levere. Det hjælper også ved at skabe en gensidig forståelse af det forventede projektresultat. Denne proces kaldes også design tænkning, og det kan være en effektiv måde at gribe ind og forstå komplekse problemer.

Du kan bruge forskellige metoder til at engagere brugerne og indsamle krav. Du kan f.eks. indsamle krav med forretningsdesign og teknisk design (beskrevet detaljeret i senere afsnit i denne artikel).

Forretningsdesign er en metode til at indsamle forretningsmæssige krav. Den fokuserer på at engagere forretningsbrugere i forretningsdesignsessioner for at designe løsningen i fællesskab. Resultatet af et forretningsdesign består af løsningsmodeller og beskrivende designdokumentation.

Teknisk design er en tilgang til at oversætte forretningsmæssige krav til tekniske krav og til at håndtere designantagelser. Et teknisk design fokuserer på at validere forretningsdesignet og definere en teknisk tilgang til brug. For at validere designet interagerer indholdsforfattere typisk med tekniske eksperter i fokuserede diskussioner kaldet tekniske designsessioner, hvor det er nødvendigt.

Vigtigt

Indsamling af de forkerte krav er en almindelig årsag til, at implementeringer mislykkes. Teams indsamler ofte de forkerte krav, fordi de har engageret sig i de forkerte interessenter, f.eks. beslutningstagere, der leverer top-down-anmodninger om løsninger, der skal bygges.

Hvis du engagerer virksomhedsbrugere ved hjælp af samarbejdstilgange som f.eks. et forretningsdesign, kan det hjælpe dig med at indsamle bedre krav. Bedre krav fører ofte til mere effektiv udvikling og mere robuste løsninger.

Bemærk

For nogle teams er det en stor ændring at indføre en proces til indsamling af strukturerede krav. Sørg for, at du administrerer denne ændring, og at den ikke forstyrrer løsningsplanlægningen. Vi anbefaler, at du finder måder, hvorpå du kan tilpasse disse tilgange, så de passer til den måde, dit team fungerer på.

Forbered løsningsplanlægning

Du skal først forberede dig på løsningsplanlægning ved at overveje de faktorer, der er beskrevet i følgende afsnit.

• Identificer, hvem der skal udføre løsningsplanlægning: Som en del af den taktiske PLANLÆGNING i BI oprettede arbejdsteamet en prioriteret efterslæb af løsninger. I forbindelse med løsningsplanlægning er et projektteam ansvarlig for at designe, udvikle og udrulle en eller flere løsninger fra efterslæbet. For hver løsning i efterslæbet skal du samle et projektteam, der er ansvarlig for løsningen. Ud over at køre BI-løsningsplanlægning skal projektteamet:
  • Definer tidslinjer og milepæle for løsningsplanlægning.
  • Identificer og involver de rette interessenter i forbindelse med indsamling af krav.
  • Konfigurer en central placering til kommunikation, dokumentation og planlægning.
  • Engager interessenter for at indsamle krav.
  • Kommuniker og koordinat med interessenter og erhvervsbrugere.
  • Orkestrer iterative udviklings- og testcyklusser med virksomhedsbrugere.
  • Dokumentér løsningen.
  • Onboarde brugere til løsningen ved at definere og vedtage en oplæringsplan.
  • Angiv understøttelse af løsning efter installation.
  • Adresser rimelige brugeranmodninger om at ændre eller opdatere løsningen efter udrulningen.
  • Udfør om nødvendigt løsningsoverlevering efter udrulning.
• Centraliser kommunikation og dokumentation: Det er vigtigt, at projektteamet centraliserer kommunikation og dokumentation til BI-løsningsplanlægning. Projektteamet skal f.eks. centralisere krav, kommunikation mellem interessenter, tidslinjer og leverancer. Overvej at gemme al dokumentation på en centraliseret portal.
• Indsamling af plankrav: Projektteamet skal begynde med at planlægge forretningsdesignsessionerne for at indsamle forretningskrav. Disse sessioner har form af interaktive møder, og de kan følge samme format som de strategiske planlægningsworkshops.

Tip

Overvej at identificere og involvere de supportteams, der er ansvarlige for løsningen, tidligt i indsamlingsprocessen for krav. For effektivt at understøtte løsningen skal supportteamene have en omfattende forståelse af løsningen, dens formål og brugerne. Det er især vigtigt, når projektteamet kun består af eksterne konsulenter.

Indsaml forretningskrav

Indsamling af de rette forretningskrav er afgørende for at designe den rigtige løsning. For at indsamle de rette krav og definere et effektivt løsningsdesign kan projektteamet gennemføre forretningsdesignsessioner sammen med virksomhedsbrugerne.

Formålet med forretningsdesignsessionerne er at:

• Bekræft det indledende løsningsområde.
• Definer og forstå det problem, som løsningen skal løse.
• Identificer de rette nøgleaktører til løsningen.
• Indsaml de rette forretningsmæssige krav.
• Forbered et løsningsdesign, der opfylder virksomhedens krav.
• Forbered dokumentation til understøttende design.

Følgende diagram viser, hvordan du indsamler forretningskrav og definerer løsningsdesignet ved hjælp af en tilgang til forretningsdesign.

Diagrammet viser følgende trin.

Punkt	Beskrivelse
	Projektteamet starter forretningsdesignet med at bekræfte det løsningsområde, der først blev dokumenteret i taktisk planlægning. De bør tydeliggøre de forretningsområder, systemer og data, som løsningen omfatter.
	Projektteamet identificerer vigtige interessenter fra brugergruppen, som vil blive involveret i forretningsdesignsessionerne. De vigtigste interessenter er brugere med tilstrækkelig viden og troværdighed til at repræsentere løsningens emneområder.
	Projektteamet planlægger forretningsdesignsessioner. Planlægning omfatter information til interessenter, organisering af møder, forberedelse af leverancer og engagement med virksomhedsbrugere.
	Projektteamet indsamler og undersøger eksisterende løsninger, som erhvervsbrugere i øjeblikket bruger til at imødekomme eksisterende behov for forretningsdata. For at fremskynde denne proces kan projektteamet bruge relevant forskning fra strategisk planlægning i BI, som er dokumenteret i kommunikationshubben.
	Projektteamet kører forretningsdesignsessioner med interessenter. Disse sessioner er små, interaktive møder, hvor projektteamet guider interessenter til at forstå behov og krav til forretningsdata.
	Projektteamet afslutter forretningsdesignet ved at præsentere et udkast til løsningsdesign for interessenter og andre brugere til feedback og godkendelse. Forretningsdesignet lykkes, når interessenterne er enige om, at designet vil hjælpe dem med at nå deres forretningsmæssige målsætninger.

Forretningsdesignet afsluttes med følgende leverancer.

• Udkast til løsningsdesign: Modeller, prototyper eller trådrammediagrammer illustrerer løsningsdesignet. Disse dokumenter oversætter kravene til en konkret designplan.
• Liste over forretningsmålepunkter: Forventede kvantitative felter i løsningen, herunder forretningsdefinitioner og forventede sammenlægninger. Hvis det er muligt, skal du rangordne dem efter vigtighed for brugerne.
• Liste over forretningsattributter: Relevante attributter og datastrukturer, der forventes i løsningen, herunder forretningsdefinitioner og attributnavne. Hvis det er muligt, skal du inkludere hierarkier og rangordne attributterne efter vigtighed for brugerne.
• Supplerende dokumentation: Beskrivelser af vigtige funktionelle krav eller overholdelseskrav. Denne dokumentation skal være så præcis som nødvendigt, men så præcis som muligt.

Forretningsdesignleverancerne bruges i og valideres af det tekniske design.

Tip

Løsningsmodeller, prototyper eller trådrammediagrammer kan skabe en klar forståelse af det forventede resultat for både udviklere og slutbrugere. Oprettelse af effektive mock-ups kræver ikke kunstneriske færdigheder eller talent. Du kan bruge enkle værktøjer som Microsoft Whiteboard, PowerPoint eller blot en pen og papir til at illustrere designet.

Indsaml tekniske krav

Når projektteamet har fuldført forretningsdesignet, validerer det sine resultater ved hjælp af et teknisk design. Det tekniske design er en tilgang, der ligner forretningsdesignet. Mens forretningsdesignet fokuserer på forretningsdatabehov, fokuserer det tekniske design på de tekniske aspekter af en løsning. Et vigtigt resultat af det tekniske design er løsningsplanen, som beskriver det endelige løsningsdesign og informerede estimater af indsatsen for at implementere den.

Bemærk

I modsætning til forretningsdesignet er det tekniske design stort set en uafhængig undersøgelse af kildedata og -systemer, der udføres af indholdsoprettere og -ejere.

Formålet med et teknisk design er at:

• Valider resultaterne af forretningsdesignet.
• Håndter tekniske antagelser i det aktuelle design.
• Identificer de relevante datakilder i området, og definer feltberegninger og feltkildetilknytninger for hver datakilde.
• Oversæt forretningskravene til tekniske krav.
• Fremstil estimeringer af den indsats, der kræves til implementeringen.

Projektteamet engagerer tekniske eller funktionelle interessenter i begrænsede, fokuserede tekniske designsessioner. Disse sessioner er interaktive møder med de funktionelle interessenter for at indsamle tekniske krav. Interessenterne er ansvarlige for specifikke funktionelle områder, der kræves for at løsningen kan fungere effektivt.

Eksempler på interessenter i et teknisk design kan være:

• Sikkerheds- og netværksteams: Ansvarlige for at sikre sikkerheden og overholdelse af dataene.
• Funktionelle teams og dataansvarlige: Ansvarlig for at organisere kildedataene.
• Arkitekter: Ejere af bestemte platforme, værktøjer eller teknologi.

Projektteamet engagerer interessenter i tekniske designsessioner for at håndtere tekniske aspekter af løsningen. Tekniske aspekter kan omfatte:

• Datakildeforbindelser: Oplysninger om, hvordan du opretter forbindelse til og integrerer datakilder.
• Netværk og datagateways: Oplysninger om private netværk eller datakilder i det lokale miljø.
• Tilknytning af feltkilde: Datatilknytninger af forretningsmålepunkter og -attributter til datakildefelter.
• Beregningslogik: En oversættelse af forretningsdefinitioner til tekniske beregninger.
• Tekniske funktioner: Funktioner eller funktionalitet, der er nødvendige for at understøtte forretningsmæssige krav.

Tip

Projektteamet, der gennemførte forretningsdesignet, bør også udføre det tekniske design. Men af praktiske årsager kan forskellige personer lede det tekniske design. I dette tilfælde skal du starte det tekniske design ved at gennemgå resultaterne af forretningsdesignet.

Ideelt set bør de personer, der leder det tekniske design, have en grundig forståelse af resultaterne og erhvervsbrugerne.

I følgende diagram kan du se, hvordan du oversætter forretningskrav til tekniske krav ved hjælp af et teknisk design.

Diagrammet viser følgende trin.

Punkt	Beskrivelse
	Projektteamet begynder det tekniske design ved at definere datakildens omfang baseret på resultaterne af forretningsdesignet. Datakildeområdet deklarerer, hvilke data der kræves for at bygge løsningen. For at identificere de rette datakilder rådfører projektteamet sig med de forretningsrelaterede og funktionelle SMV'er.
	Projektteamet identificerer tekniske eller funktionelle interessenter, der skal involveres senere i de tekniske designsessioner.
	Projektteamet planlægger begrænsede, fokuserede sessioner med funktionelle interessenter for at håndtere tekniske aspekter af løsningen. Planlægning omfatter information af interessenter, organisering af møder og forberedelse af leverancer.
	Projektteamet forsker i tekniske krav. Forskning omfatter definition af feltberegninger og tilknytninger af datakilder samt håndtering af antagelser om forretningsdesign med teknisk analyse og dokumentation.
	Om nødvendigt inddrager projektteamet interessenter i tekniske designsessioner. Sessioner fokuserer på et bestemt teknisk aspekt af løsningen, f.eks. sikkerheds- eller datakildeforbindelser. I disse sessioner indsamler projektteamet kvalitativ feedback fra interessenter og SMV'er.
	Projektteamet udarbejder deres resultater ved hjælp af en løsningsplan, som de præsenterer for interessenter og beslutningstagere. Planen er en gentagelse og udvidelse af de forretningsdesignresultater, der omfatter det endelige design, estimater og andre leverancer.
	Det tekniske design bør afsluttes med et endeligt møde med interessenter og beslutningstagere for at beslutte, om de vil fortsætte eller ej. Dette møde giver en endelig mulighed for at evaluere løsningsplanlægningen, før ressourcer er forpligtet til at udvikle løsningen.

Bemærk

Det tekniske design kan afsløre uventet kompleksitet, der kan gøre det umuligt at planlægge løsningen på grund af den aktuelle ressourcetilgængelighed eller organisationens parathed. I dette tilfælde bør løsningen revurderes i den efterfølgende taktiske planlægningsperiode. Afhængigt af hvor presserende virksomhedens databehov er, kan en beslutningstager, ligesom den ledende sponsor, stadig gerne fortsætte med et blåstempling eller kun en del af den planlagte løsning.

Det tekniske design afsluttes med en løsningsplan, som består af følgende leverancer.

• Værktøjer og teknologier: Liste over de relevante tekniske instrumenter, der er nødvendige for at implementere løsningen. Listen indeholder typisk relevante nye licensmuligheder (f.eks. Fabric-kapacitet eller Premium pr. bruger), funktioner og værktøjer.
• Defineret liste over forretningsmålepunkter: Beregninger og tilknytninger af feltkilden for forretningsmetrik for alle datakilder i området. For at producere denne leverance bruger projektteamet listen over forretningsmålepunkter, der er oprettet i forretningsdesignet.
• Defineret liste over forretningsattributter: Feltkildetilknytninger for forretningsattributterne for alle datakilder i området. For at producere denne leverance bruger projektteamet listen over forretningsattributter, der er oprettet i forretningsdesignet.
• Reviderede design: Ændringer af løsningsdesignet baseret på ændringer af eller ugyldige antagelser om forretningsdesignet. Reviderede design er opdaterede versioner af modeller, prototyper eller trådrammediagrammer, der er produceret i forretningsdesignet. Hvis der ikke er behov for ændringer, skal du kommunikere, at det tekniske design validerer forretningsdesignet.
• Anslået indsats: Estimat over de ressourcer, der er nødvendige for at udvikle, understøtte og vedligeholde løsningen. Estimatet informerer den endelige beslutning om, hvorvidt løsningen skal gennemføres eller ej.

Vigtigt

Sørg for, at projektteamet underretter interessenterne om eventuelle ændringer eller uventede opdagelser fra det tekniske design. Disse tekniske designsessioner bør stadig omfatte relevante erhvervsbrugere. Sørg dog for, at interessenter ikke udsættes for unødigt komplekse tekniske oplysninger.

Tip

Da forretningsmålene uvægerligt udvikler sig, forventes det, at kravene ændres. Antag ikke, at kravene til BI-projekter er faste. Hvis du kæmper med at ændre krav, kan det være en indikation af, at indsamlingsprocessen for dine krav ikke er effektiv, eller at dine udviklingsarbejdsprocesser ikke i tilstrækkelig grad inkorporerer regelmæssig feedback.

Tjekliste – Når du indsamler krav, omfatter vigtige beslutninger og handlinger:

• Tydeliggør, hvem der ejer løsningsplanlægning: For hver løsning skal du sikre, at roller og ansvar er klare for projektteamet.
• Tydeliggør løsningsomfanget: Løsningsomfanget bør allerede dokumenteres som en del af BI's taktiske planlægning. Du skal muligvis bruge ekstra tid og kræfter på at tydeliggøre omfanget, før du starter løsningsplanlægningen.
• Identificer og informér interessenter: Identificer interessenter i forbindelse med forretningsdesign og tekniske design. Informer dem på forhånd om projektet, og forklar omfanget, målene, den påkrævede tidsinvestering og leverancerne fra forretningsdesignet.
• Planlæg og udfør forretningsdesignsessioner: Moderér forretningsdesignsessionerne for at indhente oplysninger fra interessenter og forretningsbrugere. Anmod brugerne om at demonstrere, hvordan de bruger eksisterende løsninger.
• Dokumentér forretningsmålepunkter og -attributter: Opret en liste over forretningsmålepunkter og -attributter ved hjælp af eksisterende løsninger og input fra interessenter. I de tekniske design skal du knytte felterne til datakilden og beskrive beregningslogikken for kvantitative felter.
• Udkast til løsningsdesignet: Opret iterative modeller baseret på input fra interessenter, der visuelt afspejler det forventede løsningsresultat. Sørg for, at mock-ups repræsenterer og imødekommer forretningskravene korrekt. Kommuniker til erhvervsbrugere, at modellerne stadig skal valideres (og muligvis revideres) under det tekniske design.
• Opret løsningsplanen: Forskningskildedata og relevante tekniske overvejelser for at sikre, at forretningsdesignet er opnåeligt. Hvis det er relevant, skal du beskrive vigtige risici og trusler mod designet og eventuelle alternative tilgange. Hvis det er nødvendigt, skal du forberede en revision af løsningsdesignet og drøfte det med interessenterne.
• Opret indsatsestimater: Som en del af den endelige løsningsplan skal du estimere indsatsen for at bygge og understøtte løsningen. Juster disse estimater med de oplysninger, der indsamles under forretningsdesign- og tekniske designsessioner.
• Beslut, om planen skal fortsætte: Hvis du vil afslutte indsamlingsprocessen for krav, skal du præsentere den endelige plan for interessenter og beslutningstagere. Formålet med dette møde er at afgøre, om der skal fortsættes med løsningsudvikling.

Trin 2: Planlæg udrulning

Når projektteamet er færdig med at indsamle krav, oprette løsningsplanen og modtage godkendelse for at fortsætte, er den klar til at planlægge udrulning af løsningen.

Udrulningsplanlægningsopgaver varierer afhængigt af løsningen, din udviklingsarbejdsproces og din udrulningsproces. En udrulningsplan vedrører typisk mange aktiviteter, der involverer planlægning og konfiguration af værktøjer og processer til løsningen.

Planlæg at håndtere nøgleområder

Projektteamet skal planlægge vigtige områder for udrulning af løsninger. Planlægning skal typisk tage fat på følgende områder.

• Overholdelse: Sørg for, at alle de kriterier for overholdelse, der er identificeret i indsamlingen af krav, håndteres ved specifikke handlinger. Tildel hver af disse handlinger til bestemte personer, og definer klart tidsrammen for levering.
• Sikkerhed: Beslut, hvordan forskellige lag af løsningsadgang skal administreres, og eventuelle krav til datasikkerhedsregel . Gennemse, om løsningssikkerheden er mere eller mindre streng end standardindholdet i lejeren.
• Datagateways: Evaluer, om løsningen skal bruge en datagateway for at oprette forbindelse til datakilder. Find ud af, om specifikke gatewayindstillinger eller klynger med høj tilgængelighed er nødvendige. Planlæg, hvem der kan administrere gatewayforbindelser via sikkerhedsrollerne for gatewayen, og hvordan du overvåger gateways. Du kan få flere oplysninger under Klargør gatewayadgang.
• Arbejdsområder: Beslut, hvordan du konfigurerer og bruger arbejdsområder. Find ud af, om løsningen kræver værktøjer til administration af livscyklus, f.eks . Git-integration og udrulningspipelines, og om den kræver avanceret logføring med Azure Log Analytics.
• Support: Fastlæg, hvem der er ansvarlig for at understøtte og vedligeholde løsningen efter udrulningen af produktionen. Hvis de personer, der er ansvarlige for support, er anderledes end projektteamet, skal disse personer involveres i udvikling. Sørg for, at den, der understøtter løsningen, forstår løsningsdesignet, det problem, den skal håndtere, hvem der skal bruge den, og hvordan.
• Brugeruddannelse: Forvent den nødvendige indsats for at oplære brugersamfundet, så de effektivt kan bruge løsningen. Overvej, om der er behov for specifikke handlinger til administration af ændringer.
• Styring: Identificer eventuelle potentielle styringsrisici for løsningen. Forudsig den indsats, der er nødvendig for at give brugerne mulighed for effektivt at bruge løsningen, samtidig med at du afhjælper enhver risiko for styringen (f.eks. ved hjælp af følsomhedsmærkater og politikker).

Udfør indledende konfiguration

Projektteamet skal udføre den indledende opsætning for at påbegynde udviklingen. Indledende konfiguration af aktiviteter kan omfatte:

• Indledende værktøjer og processer: Udfør førstegangskonfiguration for alle nye værktøjer og processer, der er nødvendige for udvikling, test og installation.
• Identiteter og legitimationsoplysninger: Opret sikkerhedsgrupper og tjenesteprincipaler, der skal bruges til at få adgang til værktøjer og systemer. Gem legitimationsoplysningerne effektivt og sikkert.
• Datagateways:Udrul datagateways til datakilder i det lokale miljø (gateways i virksomhedstilstand) eller datakilder på et privat netværk (virtuelt netværk eller VNet, gateways).
• Arbejdsområder og lagre: Opret og konfigurer arbejdsområder og fjernlagre til udgivelse og lagring af indhold.

Bemærk

Planlægning af udrulning varierer afhængigt af løsningen og din foretrukne arbejdsproces. I denne artikel beskrives kun elementer, der kan planlægges på højt niveau, og elementer, der kan handles på.

Du kan få flere oplysninger om planlægning af udrulning under Planlæg udrulning for at migrere til Power BI.

Tjekliste – Når du planlægger udrulning af løsninger, omfatter vigtige beslutninger og handlinger:

• Planlæg for vigtige områder: Planlæg at håndtere de processer og værktøjer, du skal bruge for at udvikle og udrulle din løsning. Adresser både tekniske områder (f.eks. datagateways eller arbejdsområder) og indføring (f.eks. brugertræning og styring).
• Udfør den indledende konfiguration: Opret de værktøjer, processer og funktioner, du skal bruge for at udvikle og udrulle løsningen. Dokumentér opsætningen for at hjælpe andre, der skal foretage en førstegangsopsætning i fremtiden.
• Test datakildeforbindelser: Valider, at de relevante komponenter og processer er på plads for at oprette forbindelse til de rigtige data for at starte blåstemplingen.

Trin 3: Udfør en blåstempling

Projektteamet udfører en blåstempling af løsninger for at validere udestående antagelser og for at demonstrere tidlige fordele for erhvervsbrugere. En blåstempling er en indledende designimplementering, der er begrænset i omfang og modenhed. En veldrevet blåstempling er især vigtig for store eller komplekse løsninger, da den kan identificere og håndtere kompleksiteter (eller undtagelser), der ikke blev registreret i det tekniske design.

Vi anbefaler, at du tager højde for følgende overvejelser, når du forbereder en blåstempling.

• Mål og omfang: Beskriv formålet med løsnings-POC og de funktionelle områder, den skal håndtere. Projektteamet kan f.eks. beslutte at begrænse blåstemplingen til et enkelt funktionsområde eller et bestemt sæt krav eller funktioner.
• Kildedata: Identificer, hvilke data der skal bruges i blåstemplingen. Afhængigt af løsningen kan projektteamet beslutte at bruge forskellige typer data, f.eks.:
  • Produktionsdata (reelle)
  • Eksempeldata
  • Genererede syntetiske data, der ligner faktiske datamængder og kompleksitet, der er observeret i produktionsmiljøer
• Demonstration: Beskriv, hvordan og hvornår projektteamet demonstrerer blåstemplingen over for interessenter og brugere. Demonstrationer kan gives under regelmæssige opdateringer, eller når blåstemplingen opfylder specifikke funktionelle kriterier.
• Miljø: Beskriv, hvor projektteamet skal bygge blåstemplingen. En god tilgang er at bruge et specifikt sandkassemiljø til blåstemplingen og udrulle det i et udviklingsmiljø, når det er klar. Et sandkassemiljø har mere fleksible politikker og flydende indhold, og det fokuserer på at skabe hurtige resultater. I modsætning hertil følger et udviklingsmiljø mere strukturerede processer, der muliggør samarbejde, og det fokuserer på at udføre bestemte opgaver.
• Succeskriterier: Definer tærsklen for, hvornår blåstemplingen lykkes, og gå videre til næste gentagelse, og angiv formel udvikling. Før projektgruppen starter blåstemplingen, skal det identificere klare kriterier for, hvornår blåstemplingen lykkes. Ved at angive disse kriterier på forhånd definerer projektteamet, hvornår poc-udviklingen slutter, og hvornår iterative udviklings- og valideringscyklusser begynder. Afhængigt af målene for blåstemplingen kan projektteamet angive forskellige succeskriterier, f.eks.:
  • Interessenternes godkendelse af blåstemplingen
  • Validering af funktioner eller funktionalitet
  • Positiv gennemgang af blåstemplingen foretaget af peers efter en fast udviklingstid
• Fejl: Sørg for, at projektteamet kan identificere fejl i blåstemplingen. Identificering af fejl tidligt hjælper med at undersøge rodårsager. Det kan også hjælpe med at undgå yderligere investeringer i en løsning, der ikke fungerer som forventet, når den udrulles til produktion.

Advarsel

Når projektteamet udfører blåstemplingen, skal de være opmærksomme på antagelser og begrænsninger. Projektteamet kan f.eks. ikke nemt teste løsningens ydeevne og datakvalitet ved hjælp af et lille datasæt. Sørg desuden for, at omfanget af og formålet med blåstemplingen er klart for virksomhedsbrugerne. Sørg for at kommunikere, at blåstemplingen er en første gentagelse, og understrege, at det ikke er en produktionsløsning.

Bemærk

Du kan få flere oplysninger under Udfør blåstempling ved migrering til Power BI.

Tjekliste – Når du opretter en blåstempling, omfatter vigtige beslutninger og handlinger:

• Definer målene: Sørg for, at målene for blåstemplingen er tydelige for alle de personer, der er involveret.
• Definer omfanget af blåstemplingen: Sørg for, at oprettelsen af blåstemplingen ikke tager for meget udvikling, samtidig med at du leverer værdi og demonstrerer løsningsdesignet.
• Beslut, hvilke data der skal bruges: Identificer, hvilke kildedata du vil bruge til at oprette blåstemplingen, begrunde din beslutning og skitsere de potentielle risici og begrænsninger.
• Beslut, hvornår og hvordan du vil demonstrere blåstemplingen: Planlæg at vise status ved at præsentere blåstemplingen for beslutningstagere og erhvervsbrugere.
• Tydeliggør, hvornår blåstemplingen slutter: Sørg for, at projektteamet beslutter sig for en klar konklusion for blåstemplingen, og beskriv, hvordan den vil blive forfremmet til formelle udviklingscyklusser.

Trin 4: Opret og valider indhold

Når blåstemplingen lykkes, skifter projektteamet fra blåstemplingen til oprettelse og validering af indhold. Projektteamet kan udvikle BI-løsningen med iterative udviklings- og valideringscyklusser. Disse cyklusser består af iterative udgivelser, hvor projektteamet opretter indhold i et udviklingsmiljø og udgiver det til et testmiljø. Under udviklingen onboarder projektteamet gradvist brugergruppen i en pilotproces til tidlige (beta) versioner af løsningen i testmiljøet.

Tip

Iterativ levering opfordrer til tidlig validering og feedback, der kan afhjælpe ændringsanmodninger, fremme løsningsindføring og realisere fordele før produktionsudgivelsen.

Iterative udviklings- og valideringscyklusser fortsætter, indtil projektteamet ankommer til en foruddefineret konklusion. Udvikling afsluttes typisk, når der ikke er flere funktioner, der skal implementeres, eller brugerfeedback, der skal håndteres. Når udviklings- og valideringscyklusserne er afsluttet, udruller projektteamet indholdet til et produktionsmiljø med den endelige produktionsudgivelse.

Følgende diagram viser, hvordan projektteamet iterativt kan levere BI-løsninger med udviklings- og valideringscyklusser.

Diagrammet viser følgende trin.

Punkt	Beskrivelse
	Projektteamet kommunikerer hver udgivelse til brugergruppen og beskriver ændringer og nye funktioner. Ideelt set omfatter kommunikation en løsningsdemonstration og Q&A, så brugerne forstår, hvad der er nyt i udgivelsen, og de kan give verbal feedback.
	Under valideringen giver brugerne feedback via et centralt værktøj eller en central formular. Projektteamet bør regelmæssigt gennemse feedback for at løse problemer, acceptere eller afvise anmodninger og informere om kommende udviklingsfaser.
	Projektteamet overvåger brugen af løsningen for at bekræfte, at brugerne tester den. Hvis der ikke er noget forbrug, skal projektteamet interagere med brugergruppen for at forstå årsagerne til det. Lavt forbrug kan indikere, at projektteamet skal udføre yderligere aktiverings- og ændringsadministrationshandlinger.
	Projektteamet reagerer straks på brugerfeedback. Hvis det tager for lang tid for projektteamet at håndtere feedback, kan brugerne hurtigt miste motivationen til at levere den.
	Projektteamet inkorporerer accepteret feedback i løsningsplanlægningen. Om nødvendigt gennemgår de planlægningsprioriteterne for at tydeliggøre og delegere opgaver, før den næste udviklingsfase begynder.
	Projektteamet fortsætter udviklingen af løsningen til den næste version.
	Projektteamet gentager alle trin, indtil de når en foruddefineret konklusion, og løsningen er klar til udrulning i produktion.

I følgende afsnit beskrives de vigtigste overvejelser i forbindelse med brug af iterative udviklings- og valideringscyklusser til at levere BI-løsninger.

Opret indhold

Projektteamet udvikler løsningen ved at følge deres normale udviklingsarbejdsproces. De bør dog overveje følgende punkter, når de opretter indhold.

• Under hver udviklingscyklus skal du opdatere dokumentationen for at beskrive løsningen.
• Afslut hver udviklingscyklus med en meddelelse til bruger community'et. Meddelelser skal sendes til den centraliserede portal, og de skal indeholde korte beskrivelser af ændringer og nye funktioner i hver version.
• Med hver version kan du overveje at organisere sessioner for at demonstrere ændringer og nye funktioner i bruger community'et og for at besvare eventuelle verbale spørgsmål.
• Definer, hvornår iterative udviklings- og valideringscyklusser afsluttes. Sørg for, at der er en klar proces til udrulning af løsningen i produktionsmiljøet, herunder en overgang til support- og indføringsaktiviteter.

Valider indhold

Hver iterative udviklingscyklus skal afsluttes med indholdsvalidering. For BI-løsninger er der typisk to typer validering.

• Udviklervalidering: Test af løsninger udføres af indholdsoprettere og peers. Formålet med udviklervalidering er at identificere og løse alle kritiske og synlige problemer, før løsningen gøres tilgængelig for erhvervsbrugere. Problemer kan relaterer til data korrekthed, funktionalitet eller brugeroplevelsen. Ideelt set valideres indhold af en indholdsopretter, der ikke har udviklet det.
• Brugervalidering: Løsningstest udføres af bruger-community'et. Formålet med brugervalidering er at give feedback til senere gentagelser og at identificere problemer, der ikke blev fundet af udviklere. Formelle brugervalideringsperioder kaldes typisk test af brugeraccept (UAT).

Vigtigt

Sørg for, at eventuelle problemer med datakvaliteten håndteres under udviklervalidering (før UAT). Disse problemer kan hurtigt udhule tilliden til løsningen, og de kan skade den langsigtede indførelse.

Tip

Når du udfører brugervalidering, skal du overveje lejlighedsvise, korte opkald med nøglebrugere. Hold øje med dem, når de bruger løsningen. Tag noter om, hvad de har svært ved at bruge, eller hvilke dele af løsningen der ikke fungerer som forventet. Denne fremgangsmåde kan være en effektiv måde at indsamle feedback på.

Faktor i følgende overvejelser, når projektteamet validerer indhold.

• Opmuntr brugerfeedback: Med hver udgivelse skal du anmode brugerne om at give feedback og demonstrere, hvordan de kan gøre det effektivt. Overvej regelmæssigt at dele eksempler på feedback og anmodninger, der har ført til de seneste ændringer og nye funktioner. Ved at dele eksempler demonstrerer du, at feedback anerkendes og værdsættes.
• Isoler større anmodninger: Nogle feedbackelementer kræver en større indsats for at løse. Sørg for, at projektteamet kan identificere disse elementer og diskutere, om de skal implementeres eller ej. Overvej at dokumentere større anmodninger for at diskutere i senere taktiske planlægningssessioner .
• Start aktiviteter til administration af ændringer: Oplær brugerne, hvordan de bruger løsningen. Sørg for at bruge ekstra kræfter på nye processer, nye data og forskellige måder at arbejde på. Investering i forandringsstyring har et positivt afkast på langsigtet løsningsindføring.

Når løsningen når et foruddefineret niveau af fuldstændighed og modenhed, er projektteamet klar til at udrulle den til produktion. Efter udrulningen skifter projektteamet fra iterativ levering til understøttelse og overvågning af produktionsløsningen.

Bemærk

Udvikling og test varierer afhængigt af løsningen og din foretrukne arbejdsproces.

I denne artikel beskrives kun elementer, der kan planlægges på højt niveau, og elementer, der kan handles på. Du kan finde flere oplysninger om iterative udviklings- og testcyklusser under Opret indhold, der skal migreres til Power BI.

Tjekliste – Når du opretter og validerer indhold, omfatter vigtige beslutninger og handlinger:

• Brug en iterativ proces til at planlægge og tildele opgaver: Planlæg og tildel opgaver for hver version af løsningen. Sørg for, at processen til planlægning og tildeling af opgaver er fleksibel og inkorporerer brugerfeedback.
• Konfigurer administration af indholdslivscyklus: Brug værktøjer og processer til at strømline og automatisere udrulning af løsninger og administration af ændringer.
• Opret et værktøj til centralisering af feedback: Automatiser indsamling af feedback ved hjælp af en løsning, der er enkel for dig og dine brugere. Opret en enkel formular for at sikre, at feedback er præcis, men handlingsvenlig.
• Planlæg et møde for at gennemse feedback: Mødes for kort at gennemgå hvert nyt eller udestående feedbackelement. Beslut, om du vil implementere feedbacken eller ej, hvem der er ansvarlig for implementeringen, og hvilke handlinger der skal udføres for at lukke feedbackelementet.
• Beslut, hvornår iterativ levering afsluttes: Beskriv betingelserne for, hvornår iterative leveringscyklusser afsluttes, og hvornår du frigiver indhold til produktionsmiljøet.

Trin 5: Udrul, understøt og overvåg

Når du er klar, udruller projektteamet den validerede løsning i produktionsmiljøet. Projektteamet skal udføre vigtige implementerings- og supporthandlinger for at sikre, at udrulningen lykkes.

Hvis du vil sikre en vellykket udrulning, skal du udføre følgende support- og indføringsopgaver.

• Kommuniker den endelige udgivelse: Den ledende sponsor, en leder eller en anden person med tilstrækkelig autoritet og troværdighed bør annoncere udgivelsen til bruger-community'et. Kommunikationen skal være klar, præcis og indeholde links til de relevante løsninger og støttekanaler.
• Udfør oplæring af indholdsforbrugere: Oplæring skal være tilgængelig for indholdsforbrugere i løbet af de første uger efter udgivelsen til produktion. Oplæringen skal fokusere på at tydeliggøre løsningsomfanget, besvare brugerspørgsmål og forklare, hvordan du bruger løsningen.
• Adresser feedback og anmodninger: Overvej at give brugerne en kanal til at sende feedback og anmodninger til projektteamet. Sørg for, at rimelig feedback og anmodninger drøftes og, når det er relevant, implementeres i supportperioden efter udrulningen. Det er vigtigt at reagere på feedback og anmodninger efter produktionsudgivelsen. Det angiver en fleksibel løsning, der reagerer på ændrede forretningsbehov.
• Planlæg at oprette forbindelse til bruger community'et: Selv efter supportperioden efter udrulningen skal du sørge for, at løsningsejerne jævnligt mødes med bruger community'et. Disse møder er værdifulde kilder til feedback til revision af din BI-strategi. De hjælper også med at understøtte implementering af løsninger ved at aktivere brugere.
• Overleveringshandlinger: Medlemmer af projektteamet er muligvis ikke ansvarlige for at vedligeholde løsningen. I dette tilfælde skal teamet identificere, hvem der er ansvarlig, og udføre en overdragelse. Overdragelsen skal ske kort tid efter udgivelsen til produktion, og den skal adressere både løsningen og brugersamfundet.

Advarsel

Hvis der ikke gennemføres en effektiv overdragelse, kan det føre til undgåelige problemer med løsningssupport og -implementering i løbet af dens livscyklus.

Efter udrulningen skal projektteamet planlægge at gå videre til den næste løsning i den prioriterede løsningslog. Sørg for, at du indsamler ny feedback og nye anmodninger og foretager ændringer af taktisk planlægning – herunder løsningsefterslæbet – hvis det er nødvendigt.

Tjekliste – når du overvejer udrulning af løsninger, omfatter vigtige beslutninger og handlinger:

• Opret en kommunikationsplan: Planlæg, hvordan du kommunikerer udgivelses-, oplærings- og andre løsningssupport- eller implementeringshandlinger. Sørg for, at eventuelle afbrydelser eller problemer kommunikeres og straks håndteres i supportperioden efter udrulningen.
• Følg med i en oplæringsplan: Oplær brugerne i at bruge løsningen. Sørg for, at træningen omfatter både live- og optagede træningssessioner i flere uger efter udgivelsen.
• Udfør overdragelsesaktiviteter: Forbered om nødvendigt en overdragelse fra udviklingsteamet til supportteamet.
• Udfør kontortid for løsninger: Efter supportperioden efter udrulningen kan du overveje at holde almindelige sessioner i kontortid for at besvare spørgsmål og indsamle feedback fra brugere.
• Konfigurer en løbende forbedringsproces: Planlæg en månedlig overvågning af løsningen for at gennemse potentielle ændringer eller forbedringer over tid. Centraliser brugerfeedback, og gennemse feedback med jævne mellemrum mellem overvågninger.

Relateret indhold

Du kan finde flere overvejelser, handlinger, beslutningskriterier og anbefalinger, der kan hjælpe dig med power BI-implementeringsbeslutninger, i Planlægning af Implementering i Power BI.