Del via

Samle inn krav for å overføre til Power BI

  • Artikkel

Denne artikkelen beskriver trinn 1, som er opptatt av å samle inn og prioritere krav ved overføring til Power BI.

Diagrammet viser fasene i en Power BI-overføring. Trinn 1 fremheves for denne artikkelen.

Merk

Hvis du vil ha en fullstendig forklaring av grafikken ovenfor, kan du se Oversikt over Overføring av Power BI.

Uthevingen av trinn 1 er informasjonsinnsamling og planlegging for en individuell løsning som overføres til Power BI.

Utdataene fra trinn 1 inneholder detaljerte krav som er prioritert. Tilleggsaktiviteter i fase 2 og 3 må imidlertid fullføres for å beregne innsatsnivået fullt ut.

Viktig

Fase 1–5 representerer aktiviteter relatert til én bestemt løsning. Det finnes beslutninger og aktiviteter på organisasjons-/leiernivå som påvirker prosessen på løsningsnivå. Noen av disse planleggingsaktivitetene på høyere nivå diskuteres i oversiktsartikkelen for Power BI-overføring. Når det er aktuelt, må du utsette avgjørelsene på organisasjonsnivå for effektivitet og konsekvens.

Stoffadopsjonsveikartet beskriver denne typen strategiske og taktiske hensyn. Det legges vekt på organisatorisk innføring.

Tips

De fleste emnene som beskrives i denne artikkelen, gjelder også for et standard Power BI-implementeringsprosjekt.

Kompiler krav

Beholdningen av eksisterende BI-elementer, kompilert i trinnene før overføringen, blir inndataene for kravene til den nye løsningen som skal opprettes i Power BI. Innsamling av krav handler om å forstå gjeldende tilstand, samt hvilke elementer brukerne ønsker endret eller refaktorert når rapporter er endret på nytt i Power BI. Detaljerte krav vil være nyttige for planlegging av løsningsdistribusjon i trinn 2, under oppretting av konseptbevis i trinn 3, og når du oppretter den produksjonsklare løsningen i trinn 4.

Samle inn rapportkrav

Kompiler grundig, enkel å referere til, informasjon om rapporter, for eksempel:

  • formål, målgruppe og forventet handling: Identifiser formålet og forretningsprosessen som gjelder for hver rapport, i tillegg til målgruppen, den analytiske arbeidsflyten og forventede tiltak som skal utføres av rapportforbrukere.
  • Hvordan forbrukere bruker rapporten: Vurder å sitte sammen med rapportforbrukerne i den eksisterende rapporten for å forstå nøyaktig hva de gjør med den. Du kan lære at enkelte elementer i rapporten kan elimineres eller forbedres i den nye Power BI-versjonen. Denne prosessen innebærer ekstra tidsinvesteringer, men det er verdifullt for kritiske rapporter eller rapporter som brukes ofte.
  • eier og fagekspert: Identifiser rapporteieren og eventuelle fageksperter som er knyttet til rapporten eller datadomenet. De kan bli eiere av den nye Power BI-rapporten fremover. Inkluder eventuelle spesifikke krav til endringsbehandling (som vanligvis varierer mellom IT-administrerte og forretningsadministrerte løsninger) samt godkjenninger og avlogginger, som vil være nødvendige når endringer gjøres i fremtiden. Hvis du vil ha mer informasjon, kan du se denne artikkelen.
  • innholdsleveringsmetode: Klargjør forbrukernes forventninger til innholdslevering. Det kan være behovsbetinget, interaktiv kjøring, innebygd i et egendefinert program eller levering etter en tidsplan ved hjelp av et e-postabonnement. Det kan også være krav til å utløse varslingsvarsler.
  • Interaktivitetsbehov: Bestem må ha og behov for interaktivitet, for eksempel filtre, neddrillingshandlinger eller ekstraheringshandlinger.
  • datakilder: Sørg for at alle datakilder som kreves av rapporten, oppdages, og at dataventetidsbehov (datafriskhet) forstås. Identifiser historiske krav for data, trending og øyeblikksbilde av data for hver rapport, slik at de kan justeres etter datakravene. Datakildedokumentasjon kan også være nyttig senere når du utfører datavalidering av en ny rapport med kildedataene.
  • Sikkerhetskrav: Avklar sikkerhetskrav (for eksempel tillatte brukere, tillatte redigeringsprogrammer og eventuelle sikkerhetsbehov på radnivå), inkludert eventuelle unntak fra normal organisasjonssikkerhet. Dokumenter datafølsomhetsnivå, personvern eller forskriftsmessige/samsvarsbehov.
  • Beregninger, KPI-er og forretningsregler: Identifiser og dokumenter alle beregninger, KPI-er og forretningsregler som for øyeblikket er definert i den eksisterende rapporten, slik at de kan justeres etter datakravene.
  • Brukervennlighet, oppsett og kosmetiske krav: Identifiser spesifikk brukervennlighet, oppsett og kosmetiske behov knyttet til datavisualiseringer, grupperings- og sorteringskrav og betinget synlighet. Inkluder bestemte hensyn knyttet til levering av mobilenheter.
  • Utskrifts- og eksportbehov: Finn ut om det finnes noen krav som er spesifikke for eksport eller utskriftsklar oppsett. Disse behovene vil påvirke hvilken type rapport som passer best (for eksempel en Power BI-, Excel- eller paginert rapport). Vær oppmerksom på at rapportforbrukere har en tendens til å legge stor vekt på hvordan de alltid har gjort ting, så ikke vær redd for å utfordre deres måte å tenke på. Pass på å snakke i form av forbedringer i stedet for å endre.
  • Risikoer eller bekymringer: Bestem om det finnes andre tekniske eller funksjonelle krav for rapporter, samt eventuelle risikoer eller bekymringer angående informasjonen som presenteres i dem.
  • Åpne problemer og backlog elementer: Identifiser eventuelle fremtidige vedlikehold, kjente problemer eller utsatte forespørsler om å legge til i etterslepet på dette tidspunktet.

Tips

Vurder rangeringskrav ved å klassifisere dem som må ha eller hyggelig å ha. Ofte ber forbrukerne om alt de muligens trenger på forhånd fordi de tror det er deres eneste sjanse til å gjøre forespørsler. Når du adresserer prioriteringer i flere gjentakelser, gjør du også etterslepet tilgjengelig for interessenter. Det hjelper med kommunikasjon, beslutningstaking og sporing av ventende forpliktelser.

Samle inn datakrav

Kompiler detaljert informasjon som gjelder data, for eksempel:

  • Eksisterende spørringer: Identifiser om det finnes eksisterende rapportspørringer eller lagrede prosedyrer som kan brukes av en DirectQuery-modell eller en sammensatt modell, eller kan konverteres til en importmodell.
  • typer datakilder: Kompiler hvilke typer datakilder som er nødvendige, inkludert sentraliserte datakilder (for eksempel et virksomhetsdatalager) samt ikke-standard datakilder (for eksempel flate filer eller Excel-filer som utvider virksomhetsdatakilder for rapporteringsformål). Det er også viktig å finne ut hvor datakilder befinner seg, for datagatewaytilkobling .
  • datastruktur og rensingsbehov: Bestem datastrukturen for hver nødvendig datakilde, og i hvilken grad datarensing aktiviteter er nødvendige.
  • Dataintegrering: Vurder hvordan dataintegrering skal håndteres når det finnes flere datakilder, og hvordan relasjoner kan defineres mellom hver modelltabell. Identifiser bestemte dataelementer som er nødvendige for å forenkle modellen og redusere størrelsen.
  • Akseptabelfor dataventetid: Bestem behovene for dataventetid for hver datakilde. Det vil påvirke beslutninger om hvilken datalagringsmodus som skal brukes. Dataoppdateringsfrekvens for importmodelltabeller er også viktig å vite.
  • datavolum og skalerbarhet: Evaluer forventninger til datavolum, som vil ta hensyn til beslutninger om stor modellstøtte og utforming av DirectQuery eller sammensatte modeller. Hensyn knyttet til historiske databehov er viktig å vite også. For større semantiske modeller vil det også være nødvendig å fastslå trinnvis dataoppdatering .
  • mål, KPI-er og forretningsregler: Vurder behov for mål, KPI-er og forretningsregler. De vil påvirke beslutninger om hvor logikken skal brukes: i den semantiske modellen eller dataintegreringsprosessen.
  • hoveddata og datakatalog: Vurder om det er hoveddataproblemer som krever oppmerksomhet. Avgjør om integrering med en virksomhetsdatakatalog passer for å forbedre synlighet, få tilgang til definisjoner eller produsere konsekvent terminologi som er godkjent av organisasjonen.
  • Sikkerhet og personvern: Bestem om det er noen spesifikke sikkerhets- eller personvernhensyn for semantiske modeller, inkludert sikkerhet på radnivå krav.
  • Åpne problemer og tilbakeloggingselementer: Legg til kjente problemer, kjente datakvalitetsdefekter, fremtidig vedlikehold eller utsatte forespørsler til etterslepet på dette tidspunktet.

Viktig

Data gjenbrukbarhet kan oppnås med delte semantiske modeller, som eventuelt kan sertifiseres for å indikere troverdighet og forbedre synligheten. Gjenbruk av dataforberedelse kan oppnås med dataflyter for å redusere gjentakende logikk i flere semantiske modeller. Dataflyter kan også redusere belastningen betydelig på kildesystemer fordi dataene hentes sjeldnere – flere semantiske modeller kan deretter importere data fra dataflyten.

Identifiser forbedringsmuligheter

I de fleste situasjoner oppstår noen endringer og forbedringer. Det er sjelden at en direkte en-til-en-overføring oppstår uten refaktorering eller forbedring. Tre typer forbedringer du kan vurdere inkluderer:

  • Konsolidering av rapporter: Lignende rapporter kan konsolideres ved hjelp av teknikker som filtre, bokmerker eller tilpassing. Å ha færre rapporter, som er mer fleksible, kan forbedre opplevelsen for rapportforbrukere betydelig. Vurder å optimalisere semantiske modeller for spørsmål og svar (naturlig språkspørring) for å gi enda større fleksibilitet til å rapportere forbrukere, slik at de kan opprette sine egne visualiseringer.
  • effektivitetsforbedringer: Under kravinnsamling kan forbedringer ofte identifiseres. Når analytikere for eksempel kompilerer tall manuelt eller når en arbeidsflyt kan strømlinjeformes. Power Query kan spille en stor rolle i å erstatte manuelle aktiviteter som utføres for øyeblikket. Hvis forretningsanalytikere utfører de samme aktivitetene for å rense og klargjøre data regelmessig, kan repeterbare forberedelsestrinn for Power Query-data gi betydelige tidsbesparelser og redusere feil.
  • Sentralisering av datamodell: En autoritativ og sertifisert semantisk modell fungerer som ryggrad for administrert selvbetjent BI. I dette tilfellet administreres dataene én gang, og analytikere har fleksibilitet til å bruke og utvide disse dataene for å møte deres rapporterings- og analysebehov.

Merk

Hvis du vil ha mer informasjon om sentralisering av datamodeller, kan du lese om disiplin i kjernen og fleksibiliteten på kanten.

Prioriter og vurder kompleksitet

På dette tidspunktet er den opprinnelige beholdningen tilgjengelig og kan inneholde spesifikke krav. Når du prioriterer det første settet med BI-elementer som er klare for overføring, bør rapporter og data vurderes kollektivt og uavhengig av hverandre.

Identifiser rapporter med høy prioritet, som kan omfatte rapporter som:

  • Hent betydelig verdi til virksomheten.
  • Utføres ofte.
  • Kreves av toppledelsen eller lederne.
  • Involver et rimelig kompleksitetsnivå (for å forbedre sjansene for suksess under de første overførings gjentakelsene).

Identifiser data med høy prioritet, som kan omfatte data som:

  • Inneholder kritiske dataelementer.
  • Er vanlige organisasjonsdata som betjener mange brukstilfeller.
  • Kan brukes til å opprette en delt semantisk modell for gjenbruk av rapporter og mange rapportopprettere.
  • Innebærer et rimelig kompleksitetsnivå (for å forbedre sjansene for suksess når du er i de første overførings gjentakelsene).

Relatert innhold

I den neste artikkelen i denne Power BI-overføringsserien kan du lære om trinn 2, som er opptatt av å planlegge overføringen for én enkelt Power BI-løsning.

Andre nyttige ressurser omfatter følgende:

Erfarne Power BI-partnere er tilgjengelige for å hjelpe organisasjonen med å lykkes med overføringsprosessen. Hvis du vil finne en Power BI-partner, kan du gå til Microsoft Power BI-partnerportalen.