Planlegging av Power BI-implementering: PLANLEGGING av BI-løsning

Merk

Denne artikkelen er en del av planleggingsserien for power BI-implementering av artikler. Denne serien fokuserer hovedsakelig på Power BI-opplevelsen i Microsoft Fabric. Hvis du vil ha en innføring i serien, kan du se Planlegging av Power BI-implementering.

Denne artikkelen hjelper deg med å planlegge løsninger som støtter strategien for forretningsintelligens (BI). Det er primært rettet mot:

• BI- og analysedirektører eller -ledere: Beslutningstakere som er ansvarlige for å overvåke BI-programmet og strategisk viktige BI-løsninger.
• Center of Excellence (COE), IT- og BI-team: Teamene som utformer og distribuerer enterprise BI-løsninger for organisasjonen.
• Emneeksperter (SMEer) og innholdseiere og opprettere: Teamene og enkeltpersoner som kjemper for analyser i en avdeling og utformer og distribuerer løsninger for selvbetjente, avdelingelle BI- eller team BI-bruksscenarioer .

En BI-strategi er en plan for å implementere, bruke og administrere data og analyse. Du definerer BI-strategien ved å starte med strategisk planlegging av BI. Strategisk planlegging hjelper deg med å identifisere bi-fokusområdene og -målene dine. Hvis du vil finne veien til fremdriften mot BI-målene dine, beskriver du bestemte nøkkelresultater ved hjelp av taktisk planlegging. Deretter oppnår du fremdrift mot disse viktige resultatene ved å planlegge og distribuere BI-løsninger.

Merk

I rammeverket for mål og viktige resultater (OKRs) er målene tydelige beskrivelser på høyt nivå av hva du ønsker å oppnå. Derimot er viktige resultater spesifikke, oppnåelige resultater for å måle fremdriften mot ett av målene dine.

Videre er initiativer eller løsninger prosesser eller verktøy som er bygd for å hjelpe deg med å oppnå ett eller flere viktige resultater. Løsninger tar for seg bestemte databehov for brukere. En løsning kan ta mange skjemaer, for eksempel et datasamlebånd, et data lakehouse eller en Semantisk Power BI-modell eller -rapport.

Hvis du vil ha mer informasjon om OKRs, kan du se Bli kjent med OKRs (Microsoft Viva-mål).

Det finnes mange fremgangsmåter for å planlegge og implementere BI-løsninger. Denne artikkelen beskriver én tilnærming du kan ta for å planlegge og implementere BI-løsninger som støtter BI-strategien din.

Diagrammet nedenfor viser hvordan du gjennomfører planlegging av BI-løsninger.

Du gjør følgende for å gjennomføre planlegging av BI-løsninger.

Trinn	Beskrivelse
1	Sett sammen et prosjektteam som samler inn krav og definerer utformingen av løsningen.
2	Planlegg for løsningsdistribusjon ved å utføre første oppsett av verktøy og prosesser.
3	Utfør en løsningsbevis for konsept (POC) for å validere antagelser om utformingen.
4	Opprett og valider innhold ved hjelp av iterative utviklings- og valideringssykluser.
5	Distribuer, støtte og overvåk løsningen etter at den er utgitt i produksjonsmiljøet.

Merk

BI-løsningsplanlegging gjelder både selvbetjent BI- og enterprise BI-prosjekter .

Hvis du vil ha mer informasjon, kan du se Power BI-overføringsserien . Selv om serien er opptatt av overføring, er de viktigste handlingene og vurderingene relevante for løsningsplanlegging.

Trinn 1: Samle krav

Du starter løsningsplanleggingen ved først å samle inn krav og definere løsningsutformingen.

Merk: Strategisk og taktisk planlegging ledes av et arbeidsgruppe, som leder initiativet. Løsningsplanlegging ledes derimot av et prosjektteam, som består av innholdseiere og opprettere.

Innsamling av de riktige kravene er avgjørende for å oppnå vellykket løsningsdistribusjon og innføring. En effektiv måte å samle inn krav på er å identifisere og involvere de riktige interessentene, samarbeide definere problemet som skal løses, og bruke den delte forståelsen av problemet til å opprette en løsningsutforming.

Her er noen fordeler ved å bruke en samarbeidstilnærming for å samle inn krav.

• Brukerinndata gir mer nyttige utforminger: Ved å engasjere brukere i fokuserte diskusjoner for å samle inn krav, kan du mer effektivt fange opp forretningsdatabehov. Brukere kan for eksempel demonstrere for innholdsopprettere hvordan de bruker eksisterende løsninger og gi tilbakemelding om den oppfattede effektiviteten til disse løsningene.
• Unngå antakelser og reduser endringsforespørsler: Diskusjoner med brukere viser ofte nyanser, unntak og skjulte kompleksiteter. Denne innsikten reduserer sannsynligheten for forespørsler i sen fase, noe som kan være kostbart å håndtere.
• Onboarding-brukere øker løsningsinnføringen: Ved å involvere brukere i utforming og tidlig utvikling, gir du dem en mulighet til å påvirke det endelige resultatet. Engasjement kan også gi brukerne en følelse av intellektuell eierskap og ansvarlighet for løsningen. Svært involverte brukere vil være mer sannsynlig å godkjenne løsningen og lede sitt fellesskap av praksis i å bruke den effektivt.
• Design setter forventninger for interessenter og forretningsbrukere: Ved å produsere mock-ups eller illustrasjoner av løsningsutformingen, kan du tydelig vise interessenter hva løsningen vil levere. Det hjelper også ved å opprette en gjensidig forståelse av det forventede prosjektresultatet. Denne prosessen kalles også designtenkning , og det kan være en effektiv måte å nærme seg og forstå komplekse problemer på.

Du kan ta forskjellige tilnærminger for å engasjere brukere og samle inn krav. Du kan for eksempel samle inn krav med forretningsutforming og teknisk utforming (beskrevet i detalj i senere deler av denne artikkelen).

Forretningsutforming er en fremgangsmåte for å samle forretningskrav. Den fokuserer på å engasjere forretningsbrukere i forretningsutformingsøkter for å utforme løsningen sammen. Utdataene fra en forretningsutforming består av løsningsmock-ups og beskrivende utformingsdokumentasjon.

Teknisk utforming er en tilnærming til å oversette forretningskrav til tekniske krav, og for å håndtere utformingsforutsetninger. En teknisk utforming fokuserer på å validere forretningsutformingen og definere en teknisk tilnærming til bruk. For å validere utformingen kan innholdsopprettere vanligvis kommunisere med tekniske eksperter i fokuserte diskusjoner kalt tekniske utformingsøkter, der det er nødvendig.

Viktig

Innsamling av feil krav er en vanlig årsak til at implementeringer mislykkes. Ofte samler team inn feil krav fordi de engasjerte seg med feil interessenter, for eksempel beslutningstakere som leverer forespørsler ovenfra og ned om løsninger som skal bygges.

Å engasjere forretningsbrukere ved hjelp av samarbeidsmetoder som en forretningsutforming kan hjelpe deg med å samle inn bedre krav. Bedre krav fører ofte til mer effektiv utvikling og mer robuste løsninger.

Merk

For noen team er det en stor endring å ta i bruk en strukturert kravinnsamlingsprosess. Kontroller at du administrerer denne endringen, og at den ikke forstyrrer løsningsplanleggingen. Vi anbefaler at du finner måter å tilpasse disse tilnærmingene slik at de passer med måten teamet fungerer på.

Klargjøre for løsningsplanlegging

Du bør først forberede deg på løsningsplanlegging ved å vurdere faktorene som er beskrevet i avsnittene nedenfor.

• Identifiser hvem som skal gjennomføre løsningsplanlegging: Som en del av den taktiske bi-planleggingen opprettet arbeidsgruppen en prioritert mengde løsninger. I løsningsplanleggingen er et prosjektteam ansvarlig for utforming, utvikling og distribusjon av én eller flere løsninger fra etterslepet. For hver løsning i etterslepet bør du sette sammen et prosjektteam som vil være ansvarlig for løsningen. I tillegg til å kjøre planlegging av BI-løsninger, bør prosjektgruppen:
  • Definer tidslinjer og milepæler for løsningsplanlegging.
  • Identifiser og involver de riktige interessentene for kravinnsamling.
  • Konfigurer en sentralisert plassering for kommunikasjon, dokumentasjon og planlegging.
  • Engasjer interessenter for å samle inn krav.
  • Kommunisere og koordinere med interessenter og forretningsbrukere.
  • Orkestrer iterative utviklings- og testsykluser med forretningsbrukere.
  • Dokumenter løsningen.
  • Onboard brukere til løsningen ved å definere og vedta en opplæringsplan.
  • Gi støtte for løsninger etter distribusjon.
  • Adresser rimelige brukerforespørsler om å endre eller oppdatere løsningen etter distribusjon.
  • Utfør løsningsoversetter distribusjon om nødvendig.
• Sentraliser kommunikasjon og dokumentasjon: Det er viktig at prosjektteamet sentraliserer kommunikasjon og dokumentasjon for planlegging av BI-løsninger. Prosjektgruppen bør for eksempel sentralisere krav, interessentkommunikasjon, tidslinjer og leveranser. Vurder å lagre all dokumentasjon i en sentralisert portal.
• Plankravinnsamling: Prosjektteamet bør begynne med å planlegge forretningsutformingsøktene for å samle forretningskrav. Disse øktene tar form av interaktive møter, og de kan følge et lignende format som de strategiske planleggingsverkstedene.

Tips

Vurder å identifisere og involvere støtteteamene som er ansvarlige for løsningen tidlig i kravinnsamlingsprosessen. For effektiv støtte av løsningen trenger støtteteamene en omfattende forståelse av løsningen, formålet og brukerne. Det er spesielt viktig når prosjektteamet bare består av eksterne konsulenter.

Samle forretningskrav

Innsamling av de riktige forretningskravene er avgjørende for å utforme den riktige løsningen. Hvis du vil samle de riktige kravene og definere en effektiv løsningsutforming, kan prosjektteamet gjennomføre forretningsutformingsøkter sammen med forretningsbrukerne.

Formålet med forretningsutformingsøktene er å:

• Bekreft det opprinnelige løsningsomfanget.
• Definer og forstå problemet løsningen skal løse.
• Identifiser de riktige nøkkelinteressentene for løsningen.
• Samle inn de riktige forretningskravene.
• Klargjør en løsningsutforming som oppfyller forretningskravene.
• Klargjør støtteutformingsdokumentasjon.

Diagrammet nedenfor viser hvordan du samler forretningskrav og definerer løsningsutformingen ved hjelp av en forretningsutformingstilnærming.

Diagrammet viser følgende trinn.

Vare	Beskrivelse
	Prosjektteamet starter forretningsutformingen ved å bekrefte løsningsomfanget som først ble dokumentert i taktisk planlegging. De bør klargjøre forretningsområder, systemer og data som løsningen vil omfatte.
	Prosjektgruppen identifiserer viktige interessenter fra brukerfellesskapet som vil være involvert i forretningsutformingsøktene. Sentrale interessenter er brukere med tilstrekkelig kunnskap og troverdighet til å representere emneområdene i løsningen.
	Prosjektteamet planlegger forretningsutformingsøkter. Planlegging innebærer å informere interessenter, organisere møter, forberede leveranser og engasjere seg med forretningsbrukere.
	Prosjektgruppen samler inn og undersøker eksisterende løsninger som forretningsbrukere for øyeblikket bruker til å håndtere eksisterende forretningsdatabehov. For å få fart på denne prosessen kan prosjektteamet bruke relevant forskning fra strategisk planlegging for BI, som er dokumentert i kommunikasjonshuben.
	Prosjektteamet kjører forretningsutformingsøkter med interessenter. Disse øktene er små, interaktive møter, der prosjektteamet veileder interessenter til å forstå behov og krav til forretningsdata.
	Prosjektteamet avslutter forretningsutformingen ved å presentere et utkast til løsningsutforming til interessenter og andre brukere for tilbakemelding og godkjenning. Forretningsutformingen lykkes når interessentene er enige om at utformingen vil hjelpe dem med å nå sine forretningsmål.

Forretningsutformingen avsluttes med følgende leveranser.

• Utkast til løsningsutforminger: Mock-ups, prototyper eller trådrammediagrammer illustrerer løsningsutformingen. Disse dokumentene oversetter kravene til en konkret utformingsplan.
• Liste over forretningsmetrikk: Kvantitative felt som forventes i løsningen, inkludert forretningsdefinisjoner og forventede aggregasjoner. Hvis det er mulig, rangerer du dem etter viktighet for brukerne.
• Liste over forretningsattributter: Relevante attributter og datastrukturer som forventes i løsningen, inkludert forretningsdefinisjoner og attributtnavn. Hvis det er mulig, må du inkludere hierarkier og rangere attributtene etter viktighet for brukerne.
• Tilleggsdokumentasjon: Beskrivelser av viktige funksjonelle krav eller samsvarskrav. Denne dokumentasjonen bør være så nøyaktig som nødvendig, men likevel så konsis som mulig.

Leveransene for forretningsutforming brukes i og valideres av den tekniske utformingen.

Tips

Løsnings-mock-ups, prototyper eller trådrammediagrammer kan skape en klar forståelse av det forventede resultatet, både for utviklere og sluttbrukere. Å skape effektive mock-ups krever ikke kunstneriske ferdigheter eller talenter. Du kan bruke enkle verktøy som Microsoft Whiteboard, PowerPoint eller bare en penn og et papir for å illustrere utformingen.

Samle tekniske krav

Når du har fullført forretningsutformingen, validerer prosjektteamet resultatene ved hjelp av en teknisk utforming. Den tekniske utformingen er en tilnærming som ligner på forretningsutformingen. Mens forretningsutformingen fokuserer på forretningsdatabehov, fokuserer den tekniske utformingen på de tekniske aspektene ved en løsning. Et viktig resultat av den tekniske utformingen er løsningsplanen, som beskriver den endelige løsningsutformingen og informerte estimater av arbeidet med å implementere den.

Merk

I motsetning til forretningsutformingen er den tekniske utformingen i stor grad en uavhengig undersøkelse av kildedata og systemer utført av innholdsopprettere og eiere.

Formålet med en teknisk utforming er å:

• Valider resultatene av forretningsutformingen.
• Adresser tekniske forutsetninger i gjeldende utforming.
• Identifiser de relevante datakildene i omfang, og definer feltberegninger og feltkildetilordninger for hver datakilde.
• Oversett forretningskravene til tekniske krav.
• Produsere beregninger av innsatsen som kreves for implementeringen.

Prosjektteamet engasjerer tekniske eller funksjonelle interessenter i begrensede, fokuserte tekniske utformingsøkter. Disse øktene er interaktive møter med de funksjonelle interessentene for å samle tekniske krav. Interessenter er ansvarlige for bestemte funksjonelle områder som kreves for at løsningen skal fungere effektivt.

Eksempler på interessenter i en teknisk utforming kan være:

• Sikkerhets- og nettverksteam: Ansvarlig for å sikre sikkerhet og overholdelse av dataene.
• Funksjonelle team og dataforvaltere: Ansvarlig for å kuratere kildedataene.
• Arkitekter: Eiere av bestemte plattformer, verktøy eller teknologi.

Prosjektteamet engasjerer interessenter i tekniske utformingsøkter for å håndtere tekniske aspekter ved løsningen. Tekniske aspekter kan omfatte:

• Datakildetilkoblinger: Detaljer om hvordan du kobler til og integrerer datakilder.
• Nettverk og datagatewayer: Detaljer om private nettverk eller lokale datakilder.
• Feltkildetilordning: Datatilordninger av forretningsmetrikk og attributter til datakildefelt.
• Beregningslogikk: En oversettelse av forretningsdefinisjoner til tekniske beregninger.
• Tekniske funksjoner: Funksjoner eller funksjonalitet som kreves for å støtte forretningskrav.

Tips

Prosjektteamet som utførte forretningsutformingen, bør også utføre den tekniske utformingen. Av praktiske årsaker kan imidlertid forskjellige personer lede den tekniske utformingen. I dette tilfellet begynner du den tekniske utformingen ved å se gjennom resultatene av forretningsutformingen.

Ideelt sett bør personene som leder den tekniske utformingen ha en grundig forståelse av resultatene og forretningsbrukerne.

Diagrammet nedenfor viser hvordan du oversetter forretningskrav til tekniske krav ved hjelp av en teknisk utforming.

Diagrammet viser følgende trinn.

Vare	Beskrivelse
	Prosjektteamet starter den tekniske utformingen ved å definere datakildeomfanget basert på resultatene av forretningsutformingen. Datakildeomfanget erklærer hvilke data som kreves for å bygge løsningen. Hvis du vil identifisere de riktige datakildene, kontakter prosjektteamet bedrifts- og funksjons-SMN-ene.
	Prosjektteamet identifiserer tekniske eller funksjonelle interessenter som skal involveres senere i de tekniske utformingsøktene.
	Prosjektteamet planlegger begrensede, fokuserte økter med funksjonelle interessenter for å håndtere tekniske aspekter ved løsningen. Planlegging innebærer å informere interessenter, organisere møter og forberede leveranser.
	Prosjektteamet undersøker tekniske krav. Oppslag omfatter definering av feltberegninger og datakildetilordninger, og tar også for seg forutsetningene for forretningsutforming med teknisk analyse og dokumentasjon.
	Prosjektteamet involverer om nødvendig interessenter i tekniske utformingsøkter. Økter fokuserer på et bestemt, teknisk aspekt av løsningen, for eksempel sikkerhets- eller datakildetilkoblinger. I disse øktene samler prosjektteamet kvalitative tilbakemeldinger fra interessenter og SMEer.
	Prosjektteamet forbereder sine funn ved hjelp av en løsningsplan, som de presenterer for interessenter og beslutningstakere. Planen er en gjentakelse og utvidelse av resultatene for forretningsutforming som inkluderer endelig utforming, beregninger og andre leveranser.
	Den tekniske utformingen bør avsluttes med et endelig møte med interessenter og beslutningstakere for å avgjøre om de skal fortsette eller ikke. Dette møtet gir en endelig mulighet til å evaluere løsningsplanleggingen før ressurser forpliktes til å utvikle løsningen.

Merk

Den tekniske utformingen kan vise uventet kompleksitet som kan gjøre løsningsplanleggingen umulig gitt gjeldende ressurstilgjengelighet eller organisasjonsberedskap. I dette tilfellet bør løsningen revurderes i den påfølgende taktiske planleggingsperioden. Avhengig av hvor viktig forretningsdata trenger, kan det hende at en beslutningstaker, som den utøvende sponsoren, fortsatt ønsker å fortsette med et konseptbevis, eller bare én del av den planlagte løsningen.

Den tekniske utformingen avsluttes med en løsningsplan, som består av følgende leveranser.

• Verktøy og teknologier: Liste over relevante tekniske instrumenter som trengs for å implementere løsningen. Listen inneholder vanligvis relevante nye lisensalternativer (for eksempel Stoffkapasitet eller Premium per bruker), funksjoner og verktøy.
• Definert liste over forretningsmetrikk: Beregninger og feltkildetilordninger av forretningsmetrikk for alle datakildene i omfang. Hvis du vil produsere denne leveransen, bruker prosjektteamet listen over forretningsmetrikk som er opprettet i forretningsutformingen.
• Definert liste over forretningsattributter: Feltkildetilordninger av forretningsattributtene for alle datakildene i omfanget. Hvis du vil produsere denne leveransen, bruker prosjektteamet listen over forretningsattributter som er opprettet i forretningsutformingen.
• Reviderte utforminger: Revisjoner av løsningsutformingen basert på endringer i eller ugyldige antagelser om forretningsutformingen. Reviderte design er oppdaterte versjoner av mock-ups, prototyper eller trådrammediagrammer produsert i forretningsdesignet. Hvis ingen revisjoner er nødvendige, må du informere om at den tekniske utformingen validerer forretningsutformingen.
• Beregning av innsats: Beregning av ressursene som trengs for å utvikle, støtte og vedlikeholde løsningen. Estimatet informerer den endelige beslutningen om å fortsette med å implementere løsningen, eller ikke.

Viktig

Sørg for at prosjektteamet varsler interessenter om eventuelle endringer eller uventede funn fra den tekniske utformingen. Disse tekniske utformingsøktene bør fortsatt involvere relevante forretningsbrukere. Sørg imidlertid for at interessenter ikke blir unødvendig utsatt for kompleks teknisk informasjon.

Tips

Fordi forretningsmål alltid utvikler seg, forventes det at kravene vil endres. Ikke anta at kravene for BI-prosjekter er løst. Hvis du sliter med å endre krav, kan det være en indikasjon på at kravinnsamlingsprosessen ikke er effektiv, eller at utviklingsarbeidsflytene ikke inneholder regelmessig tilbakemelding tilstrekkelig.

Sjekkliste – Ved innsamling av krav omfatter viktige beslutninger og handlinger:

• Klargjør hvem som eier løsningsplanlegging: For hver løsning må du sørge for at roller og ansvar er tydelige for prosjektgruppen.
• Klargjør løsningsomfanget: Løsningsomfanget skal allerede dokumenteres som en del av bi taktisk planlegging. Du må kanskje bruke mer tid og krefter på å klargjøre omfanget før du starter løsningsplanleggingen.
• Identifiser og informer interessenter: Identifiser interessenter for forretningsdesign og tekniske utforminger. Informer dem på forhånd om prosjektet og forklar omfanget, målene, nødvendige tidsinvesteringer og leveranser fra forretningsutformingen.
• Planlegge og gjennomføre forretningsutformingsøkter: Moderer forretningsutformingsøktene for å få frem informasjon fra interessenter og forretningsbrukere. Be om at brukerne demonstrerer hvordan de bruker eksisterende løsninger.
• Dokumenter forretningsmetrikk og -attributter: Ved hjelp av eksisterende løsninger og inndata fra interessenter kan du opprette en liste over forretningsmetrikk og attributter. I de tekniske utformingene tilordner du feltene til datakilden og beskriver beregningslogikken for kvantitative felt.
• Utkast til løsningsutforming: Opprett iterative mock-ups basert på interessentinndata som visuelt gjenspeiler det forventede løsningsresultatet. Sørg for at mock-ups nøyaktig representerer og adresserer forretningskravene. Kommuniser til forretningsbrukere om at mock-ups fortsatt må valideres (og muligens revideres) under den tekniske utformingen.
• Opprett løsningsplanen: Oppslagskildedata og relevante tekniske hensyn for å sikre at forretningsutformingen er oppnåelig. Der det er relevant, kan du beskrive viktige risikoer og trusler mot utformingen og eventuelle alternative tilnærminger. Om nødvendig klargjør du en revisjon av løsningsutformingen og diskuterer den med interessentene.
• Opprett innsatsestimater: Som en del av den endelige løsningsplanen estimerer du innsatsen for å bygge og støtte løsningen. Juster disse estimatene med informasjonen som samles inn under forretningsutformingen og tekniske utformingsøkter.
• Bestem om du vil fortsette med planen: Hvis du vil avslutte kravinnsamlingsprosessen, presenterer du den endelige planen for interessenter og beslutningstakere. Formålet med dette møtet er å avgjøre om det skal fortsette med løsningsutvikling.

Trinn 2: Planlegge distribusjon

Når prosjektgruppen er ferdig med å samle krav, opprette løsningsplanen og motta godkjenning for å fortsette, er den klar til å planlegge for løsningsdistribusjon.

Distribusjonsplanleggingsoppgaver varierer avhengig av løsningen, utviklingsarbeidsflyten og distribusjonsprosessen. En distribusjonsplan gjelder vanligvis mange aktiviteter som involverer planlegging og oppsett av verktøy og prosesser for løsningen.

Planlegge å adressere viktige områder

Prosjektgruppen bør planlegge for viktige områder for løsningsdistribusjon. Vanligvis bør planleggingen ta for seg følgende områder.

• Samsvar: Sørg for at alle samsvarskriteriene som er identifisert i kravinnsamling, blir behandlet av bestemte handlinger. Tilordne hver av disse handlingene til bestemte personer, og definer leveringstidsrammen tydelig.
• Sikkerhet: Bestem hvordan ulike lag med løsningstilgang skal administreres, og eventuelle krav til datasikkerhetsregler . Se gjennom om løsningssikkerheten vil være mer eller mindre streng enn standardinnholdet i leieren.
• Datagatewayer: Vurder om løsningen trenger en datagateway for å koble til datakilder. Avgjør om bestemte gatewayinnstillinger eller klynger med høy tilgjengelighet er nødvendige. Planlegg hvem som skal kunne administrere gateway-tilkoblinger via gatewayens sikkerhetsroller, og hvordan du overvåker gatewayene. Hvis du vil ha mer informasjon, kan du se Klargjør gateway-tilgang.
• Arbeidsområder: Bestem hvordan du konfigurerer og bruker arbeidsområder. Finn ut om løsningen krever administrasjonsverktøy for livssyklus, for eksempel Git-integrasjon og distribusjonssamlebånd, og om den krever avansert logging med Azure Log Analytics.
• Støtte: Etablere hvem som er ansvarlig for å støtte og vedlikeholde løsningen etter produksjonsdistribusjon. Hvis personene som er ansvarlige for støtte, er annerledes enn prosjektgruppen, kan du involvere disse personene under utvikling. Sørg for at den som støtter løsningen forstår løsningsutformingen, problemet den skal løse, hvem som skal bruke den, og hvordan.
• Brukeropplæring: Forutse innsatsen som trengs for å lære opp brukerfelleskapet slik at de effektivt kan bruke løsningen. Vurder om bestemte handlinger for endringsbehandling er nødvendige.
• Styring: Identifiser eventuelle styringsrisikoer for løsningen. Forutse innsatsen som kreves for å gjøre det mulig for brukere å effektivt bruke løsningen, samtidig som de reduserer enhver styringsrisiko (for eksempel ved hjelp av følsomhetsetiketter og policyer).

Utføre første installasjon

Prosjektgruppen bør utføre innledende oppsett for å starte utviklingen. Første oppsettsaktiviteter kan omfatte:

• Innledende verktøy og prosesser: Utfør førstegangsoppsett for eventuelle nye verktøy og prosesser som trengs for utvikling, testing og distribusjon.
• Identiteter og legitimasjon: Opprett sikkerhetsgrupper og tjenestekontohavere som skal brukes til å få tilgang til verktøy og systemer. Lagre legitimasjonen effektivt og sikkert.
• Datagatewayer:Distribuer datagatewayer for lokale datakilder (gatewayer for bedriftsmodus) eller datakilder på et privat nettverk (virtuelt nettverk eller VNet, gatewayer).
• Arbeidsområder og repositorier: Opprett og konfigurer arbeidsområder og eksterne repositorier for publisering og lagring av innhold.

Merk

Distribusjonsplanlegging varierer avhengig av løsningen og den foretrukne arbeidsflyten. Denne artikkelen beskriver bare om planlegging på høyt nivå og handlingsbare elementer.

Hvis du vil ha mer informasjon om distribusjonsplanlegging, kan du se Planlegge distribusjon for å overføre til Power BI.

Sjekkliste – Når du planlegger løsningsdistribusjon, omfatter viktige beslutninger og handlinger:

• Planlegg for viktige områder: Planlegg for å håndtere prosessene og verktøyene du trenger for å utvikle og distribuere løsningen. Adresser både tekniske områder (for eksempel datagatewayer eller arbeidsområder) og innføring (for eksempel brukeropplæring og styring).
• Utføre første installasjon: Opprett verktøyene, prosessene og funksjonene du trenger for å utvikle og distribuere løsningen. Dokumenter konfigurasjonen for å hjelpe andre som må utføre et førstegangsoppsett i fremtiden.
• Test datakildetilkoblinger: Kontroller at de riktige komponentene og prosessene er på plass for å koble til de riktige dataene for å starte konseptbeviset.

Trinn 3: Gjennomføre et konseptbevis

Prosjektteamet gjennomfører et løsningsbevis for konsept (POC) for å validere utestående forutsetninger og for å demonstrere tidlige fordeler for forretningsbrukere. En poc er en innledende utformingsimplementering som er begrenset i omfang og forfallsdato. En veldrevet poc er spesielt viktig for store eller komplekse løsninger fordi den kan identifisere og håndtere kompleksiteter (eller unntak) som ikke ble oppdaget i den tekniske utformingen.

Vi anbefaler at du tar hensyn til følgende når du forbereder en poc.

• Mål og omfang: Beskriv formålet med løsnings-POC og de funksjonelle områdene den skal håndtere. Prosjektgruppen kan for eksempel bestemme seg for å begrense poc til ett enkelt funksjonsområde, eller et bestemt sett med krav eller funksjoner.
• Kildedata: Identifiser hvilke data som skal brukes i poc. Avhengig av løsningen kan prosjektgruppen bestemme seg for å bruke ulike typer data, for eksempel:
  • Produksjonsdata (ekte)
  • Eksempeldata
  • Genererte syntetiske data som ligner faktiske datavolumer og kompleksitet observert i produksjonsmiljøer
• Demonstrasjon: Beskriv hvordan og når prosjektteamet demonstrerer poc for interessenter og brukere. Demonstrasjoner kan gis under regelmessige oppdateringer, eller når poc oppfyller bestemte funksjonelle kriterier.
• Miljø: Beskriv hvor prosjektgruppen skal bygge poc. En god tilnærming er å bruke et distinkt sandkassemiljø for poc, og distribuere det til et utviklingsmiljø når det er klart. Et sandkassemiljø har mer fleksible policyer og flytende innhold, og fokuserer på å produsere raske resultater. Et utviklingsmiljø følger derimot mer strukturerte prosesser som muliggjør samarbeid, og fokuserer på å fullføre bestemte oppgaver.
• Suksesskriterier: Definer terskelen for når poc er vellykket, og bør flytte til neste gjentakelse og angi formell utvikling. Før du starter prosjektavdelingen, bør prosjektgruppen identifisere klare kriterier for når poc er vellykket. Ved å angi disse kriteriene på forhånd definerer prosjektgruppen når poc-utviklingen avsluttes, og når iterative utviklings- og valideringssykluser begynner. Avhengig av målene for prosjektgruppen kan prosjektgruppen angi ulike suksesskriterier, for eksempel:
  • Godkjenning av poc av interessenter
  • Validering av funksjoner eller funksjonalitet
  • Gunstig gjennomgang av POC av jevnaldrende etter en fast utviklingstid
• Feil: Kontroller at prosjektgruppen kan identifisere feil i poc. Identifisering av feil tidlig vil bidra til å undersøke grunnårsaker. Det kan også bidra til å unngå ytterligere investeringer i en løsning som ikke fungerer som forventet når den distribueres til produksjon.

Forsiktig!

Når prosjektgruppen utfører poc-en, bør de være oppmerksomme på antakelser og begrensninger. Prosjektteamet kan for eksempel ikke enkelt teste løsningsytelse og datakvalitet ved hjelp av et lite sett med data. Sørg i tillegg for at omfanget og formålet med poc er tydelig for forretningsbrukerne. Pass på at poc er en første gjentakelse, og understreke at det ikke er en produksjonsløsning.

Merk

Hvis du vil ha mer informasjon, kan du se Utføre konseptbevis for å overføre til Power BI.

Sjekkliste – Når du oppretter en poc, omfatter viktige beslutninger og handlinger:

• Definer målene: Sørg for at målene for poc er klare for alle personer som er involvert.
• Definer omfanget av poc: Sørg for at oppretting av poc ikke vil ta for mye utviklingsinnsats, samtidig som du leverer verdi og demonstrerer løsningsutformingen.
• Bestem hvilke data som skal brukes: Identifiser hvilke kildedata du vil bruke til å foreta poc, rettferdiggjøre beslutningen din og skissere potensielle risikoer og begrensninger.
• Bestem når og hvordan du demonstrerer poc: Planlegg å vise fremdrift ved å presentere poc til beslutningstakere og forretningsbrukere.
• Avklar når poc slutter: Sørg for at prosjektteamet bestemmer seg for en klar konklusjon for poc, og beskriv hvordan det vil bli forfremmet til formelle utviklingssykluser.

Trinn 4: Opprette og validere innhold

Når poc er vellykket, skifter prosjektgruppen fra poc til å opprette og validere innhold. Prosjektgruppen kan utvikle BI-løsningen med iterative utviklings- og valideringssykluser. Disse syklusene består av iterative utgivelser, der prosjektteamet oppretter innhold i et utviklingsmiljø og utgir det til et testmiljø. Under utvikling går prosjektteamet gradvis om bord i brukerfellesskapet i en pilotprosess til tidlige (beta)-versjoner av løsningen i testmiljøet.

Tips

Iterativ levering oppfordrer til tidlig validering og tilbakemelding som kan redusere endringsforespørsler, fremme løsningsinnføring og realisere fordeler før produksjonsutgivelsen.

Iterative utviklings- og valideringssykluser fortsetter til prosjektteamet kommer frem til en forhåndsdefinert konklusjon. Utviklingen avsluttes vanligvis når det ikke er flere funksjoner å implementere eller gi tilbakemeldinger til brukeren om å ta tak i. Når utviklings- og valideringssyklusene avsluttes, distribuerer prosjektteamet innholdet til et produksjonsmiljø med den endelige produksjonsutgivelsen.

Diagrammet nedenfor viser hvordan prosjektteamet kan iterativt levere BI-løsninger med utviklings- og valideringssykluser.

Diagrammet viser følgende trinn.

Vare	Beskrivelse
	Prosjektgruppen kommuniserer hver utgivelse til brukerfelleskapet, som beskriver endringer og nye funksjoner. Ideelt sett inkluderer kommunikasjon en løsningsdemonstrasjon og spørsmål og svar, slik at brukerne forstår hva som er nytt i utgivelsen, og de kan gi muntlig tilbakemelding.
	Under valideringen gir brukerne tilbakemelding via et sentralt verktøy eller skjema. Prosjektgruppen bør jevnlig se gjennom tilbakemeldinger for å løse problemer, godta eller avvise forespørsler og informere kommende utviklingsfaser.
	Prosjektteamet overvåker bruken av løsningen for å bekrefte at brukerne tester den. Hvis det ikke finnes noen bruk, bør prosjektteamet kommunisere med brukerfellesskapet for å forstå årsakene til hvorfor. Lav bruk kan indikere at prosjektgruppen må aktivere og endre administrasjonshandlinger ytterligere.
	Prosjektgruppen svarer umiddelbart på tilbakemeldinger fra brukerne. Hvis prosjektteamet bruker for lang tid på å adressere tilbakemeldinger, kan det hende at brukerne raskt mister motivasjonen til å gi den.
	Prosjektgruppen inkorporerer godtatt tilbakemelding i løsningsplanleggingen. Om nødvendig gjennomgår de planleggingsprioriteringer for å klargjøre og delegere aktiviteter før neste utviklingsfase begynner.
	Prosjektteamet fortsetter utviklingen av løsningen for neste utgivelse.
	Prosjektteamet går gjennom alle trinnene til de når en forhåndsdefinert konklusjon, og løsningen er klar for produksjonsdistribusjon.

De følgende avsnittene beskriver viktige hensyn for bruk av iterative utviklings- og valideringssykluser for å levere BI-løsninger.

Opprett innhold

Prosjektgruppen utvikler løsningen ved å følge den normale utviklingsarbeidsflyten. De bør imidlertid vurdere følgende punkter når du oppretter innhold.

• I løpet av hver utviklingssyklus oppdaterer du dokumentasjonen for å beskrive løsningen.
• Avslutt hver utviklingssyklus med en kunngjøring til brukerfellesskapet. Kunngjøringer bør legges ut i den sentraliserte portalen, og de bør gi korte beskrivelser av endringer og nye funksjoner i hver utgivelse.
• Med hver utgivelse bør du vurdere å organisere økter for å demonstrere endringer og nye funksjoner i brukerfelleskapet, og for å svare på eventuelle muntlige spørsmål.
• Definer når iterative utviklings- og valideringssykluser vil konkludere. Sørg for at det er en klar prosess for å distribuere løsningen til produksjonsmiljøet, inkludert en overgang til støtte- og innføringsaktiviteter.

Valider innhold

Hver iterative utviklingssyklus bør avsluttes med innholdsvalidering. For BI-løsninger finnes det vanligvis to typer validering.

• Utviklervalidering: Løsningstesting utføres av innholdsopprettere og kolleger. Formålet med validering av utviklere er å identifisere og løse alle kritiske og synlige problemer før løsningen gjøres tilgjengelig for forretningsbrukere. Problemer kan gjelde for datakorrigering, funksjonalitet eller brukeropplevelsen. Ideelt sett valideres innhold av en innholdsoppretter som ikke utviklet det.
• Brukervalidering: Løsningstesting utføres av brukerfelleskapet. Formålet med brukervalidering er å gi tilbakemelding for senere gjentakelser og identifisere problemer som ikke ble funnet av utviklere. Formelle brukervalideringsperioder kalles vanligvis brukergodkjenningstesting (UAT).

Viktig

Sørg for at eventuelle problemer med datakvalitet løses under utviklervalidering (før UAT). Disse problemene kan raskt erodere tillit til løsningen, og de kan skade langsiktig adopsjon.

Tips

Når du utfører brukervalidering, bør du vurdere sporadiske, korte anrop med viktige brukere. Vær oppmerksom på dem når de bruker løsningen. Ta notater om hva de synes er vanskelig å bruke, eller hvilke deler av løsningen som ikke fungerer som forventet. Denne fremgangsmåten kan være en effektiv måte å samle inn tilbakemeldinger på.

Faktor i følgende vurderinger når prosjektgruppen validerer innhold.

• Oppmuntre til tilbakemeldinger fra brukere: Be brukerne om tilbakemelding og demonstrere hvordan de effektivt kan gjøre det. Vurder regelmessig å dele eksempler på tilbakemeldinger og forespørsler som har ført til nylige endringer og nye funksjoner. Ved å dele eksempler demonstrerer du at tilbakemelding er anerkjent og verdsatt.
• Isolere større forespørsler: Noen tilbakemeldingselementer krever mer innsats for å løse. Sørg for at prosjektgruppen kan identifisere disse elementene og diskutere om de skal implementeres eller ikke. Vurder å dokumentere større forespørsler å diskutere i senere taktiske planleggingsøkter .
• Start aktiviteter for endringsadministrasjon: Lær brukerne hvordan de bruker løsningen. Pass på å bruke ekstra innsats på nye prosesser, nye data og ulike måter å arbeide på. Investering i endringsstyring har en positiv avkastning på langsiktig løsningsinnføring.

Når løsningen når et forhåndsdefinert nivå av fullstendighet og forfallsdato, er prosjektgruppen klar til å distribuere den til produksjon. Etter distribusjonen går prosjektteamet over fra iterativ levering til støtte og overvåking av produksjonsløsningen.

Merk

Utvikling og testing varierer avhengig av løsningen og den foretrukne arbeidsflyten.

Denne artikkelen beskriver bare planlegging på høyt nivå og handlingsbare elementer. Hvis du vil ha mer informasjon om iterative utviklings- og testsykluser, kan du se Opprette innhold som skal overføres til Power BI.

Sjekkliste – Når du oppretter og validerer innhold, omfatter viktige beslutninger og handlinger:

• Bruk en iterativ prosess til å planlegge og tilordne oppgaver: Planlegge og tilordne oppgaver for hver utgivelse av løsningen. Sørg for at prosessen for å planlegge og tilordne oppgaver er fleksibel og inkorporerer tilbakemeldinger fra brukere.
• Konfigurer behandling av innholdslivssyklus: Bruk verktøy og prosesser til å effektivisere og automatisere løsningsdistribusjon og endringsbehandling.
• Opprett et verktøy for å sentralisere tilbakemelding: Automatiser tilbakemeldingssamling ved hjelp av en løsning som er enkel for deg og brukerne. Opprett et enkelt skjema for å sikre at tilbakemeldingen er konsis, men handlingsbar.
• Planlegg et møte for å se gjennom tilbakemeldinger: Møt for å se gjennom hvert nye eller utestående tilbakemeldingselement kort. Bestem om du vil implementere tilbakemeldingen eller ikke, hvem som skal være ansvarlig for implementeringen, og hvilke tiltak som skal utføres for å lukke tilbakemeldingselementet.
• Bestem når iterativ levering konkluderer: Beskriv betingelsene for når de iterative leveringssyklusene avsluttes, og når du vil frigi innhold til produksjonsmiljøet.

Trinn 5: Distribuere, støtte og overvåke

Når du er klar, distribuerer prosjektteamet den validerte løsningen til produksjonsmiljøet. Prosjektgruppen bør utføre viktige innførings- og støttehandlinger for å sikre at distribusjonen er vellykket.

For å sikre en vellykket distribusjon utfører du følgende støtte- og innføringsoppgaver.

• Kommuniser den endelige utgivelsen: Den overordnede sponsoren, en leder eller en annen person med tilstrekkelig myndighet og troverdighet bør kunngjøre utgivelsen til brukerfelleskapet. Kommunikasjonen bør være tydelig, konsis og inkludere koblinger til relevante løsninger og støttekanaler.
• Gjennomføre opplæring for innholdsforbrukere: Opplæring skal være tilgjengelig for innholdsforbrukere i løpet av de første ukene etter utgivelsen til produksjon. Opplæring bør fokusere på å klargjøre løsningsomfanget, svare på brukerspørsmål og forklare hvordan du bruker løsningen.
• Adresser tilbakemeldinger og forespørsler: Vurder å gi brukerne en kanal for å sende inn tilbakemeldinger og forespørsler til prosjektteamet. Sørg for at rimelige tilbakemeldinger og forespørsler diskuteres og, når det er aktuelt, implementert i løpet av støtteperioden etter distribusjon. Det er viktig å handle på tilbakemeldinger og forespørsler etter produksjonsutgivelsen. Det indikerer en smidig løsning som reagerer på endrede forretningsbehov.
• Planlegg å koble til brukerfelleskapet: Selv etter at støtteperioden etter distribusjon er over, må du sørge for at løsningseiere regelmessig møter brukerfelleskapet. Disse møtene er verdifulle tilbakemeldingskilder for å revidere BI-strategien din. De bidrar også til å støtte løsningsinnføring ved å aktivere brukere.
• Overleveringshandlinger: Medlemmer av prosjektgruppen er kanskje ikke ansvarlige for å vedlikeholde løsningen. I dette tilfellet bør teamet identifisere hvem som er ansvarlig og utføre en overlevering. Overleveringen skal skje kort tid etter utgivelsen til produksjon, og den bør ta for seg både løsningen og brukerfellesskapet.

Forsiktig!

Unnlatelse av å gjennomføre en effektiv overlevering kan føre til forebyggelige problemer med løsningsstøtte og innføring i løpet av livssyklusen.

Etter distribusjonen bør prosjektgruppen planlegge å gå videre til neste løsning i den prioriterte løsningsreserven. Sørg for at du samler inn nye tilbakemeldinger og forespørsler og foretar revisjoner av taktisk planlegging – inkludert løsningsreserven – om nødvendig.

Sjekkliste – Når du vurderer løsningsdistribusjon, omfatter viktige beslutninger og handlinger:

• Opprett en kommunikasjonsplan: Planlegg hvordan du kommuniserer utgivelses-, opplærings- og andre løsningsstøtte- eller innføringshandlinger. Sørg for at eventuelle avbrudd eller problemer blir kommunisert og umiddelbart adressert i støtteperioden etter distribusjon.
• Følg med på en opplæringsplan: Lær opp brukere til å bruke løsningen. Sørg for at opplæringen inkluderer både direktesendte og innspilte treningsøkter i flere uker etter utgivelsen.
• Utfør overleveringsaktiviteter: Om nødvendig klargjør du en overlevering fra utviklingsteamet til støtteteamet.
• Gjennomføre kontortid for løsninger: Etter støtteperioden etter distribusjonen bør du vurdere å holde regelmessige kontortidsøkter for å svare på spørsmål og samle inn tilbakemeldinger fra brukere.
• Konfigurer en kontinuerlig forbedringsprosess: Planlegg en månedlig revisjon av løsningen for å se gjennom potensielle endringer eller forbedringer over tid. Sentraliser tilbakemeldinger fra brukere og se gjennom tilbakemeldinger regelmessig mellom revisjoner.

Relatert innhold

Hvis du vil ha mer informasjon, handlinger, beslutningskriterier og anbefalinger for å hjelpe deg med implementeringsbeslutninger for Power BI, kan du se planlegging av Power BI-implementering.