Jaa

Vaatimusten kerääminen Siirtymiseksi Power BI:hin

  • Artikkeli

Tässä artikkelissa kuvataan vaihe 1, joka koskee vaatimusten keräämistä ja priorisointia siirryttäessä Power BI:hin.

Kaaviossa näkyvät Power BI:hin siirtymisen vaiheet. Tässä artikkelissa korostetaan vaihetta 1.

Muistiinpano

Edellä olevan kuvan täydellinen kuvaus on kohdassa Power BI:hin siirtymisen yleiskatsaus.

Vaiheessa 1 painotus on tietojen keräämisessä ja suunnittelussa yksittäistä ratkaisua varten, joka siirretään Power BI:hin.

Tulos vaiheesta 1 sisältää yksityiskohtaisia vaatimuksia, jotka on asetettu tärkeysjärjestykseen. Vaiheiden 2 ja 3 lisätoiminnot on kuitenkin suoritettava, jotta ponnistuksen taso voidaan arvioida täysin.

Tärkeä

Vaiheet 1–5 edustavat yhteen tiettyyn ratkaisuun liittyviä toimintoja. Organisaatio-/vuokraajatasolla tehdyt päätökset ja toiminnot vaikuttavat prosessiin ratkaisutasolla. Joitakin näistä ylemmän tason suunnittelutoiminnoista käsitellään Power BI:hin siirtymisen yleiskatsaus -artikkelissa. Siirry tarvittaessa organisaatiotason päätöksiin tehokkuuden ja yhdenmukaisuuden vuoksi.

Fabric-käyttöönottosuunnitelma kuvaa tällaisia strategisia ja taktisia näkökohtia. Siinä painotetaan organisaation käyttöönottoa.

Vihje

Useimmat tässä artikkelissa käsitellyt aiheet koskevat myös vakiomuotoista Power BI -toteutusprojektia.

Kääntämisvaatimukset

Siirtymistä edeltävissä vaiheissa käännetystä olemassa olevien BI-kohteiden varastosta tulee uuden, Power BI:ssä luotavan ratkaisun vaatimusten syöte. Vaatimusten keräämisessä on kyse nykyisen tilan ymmärtämisestä sekä siitä, mitä kohteita käyttäjät haluavat muuttaa tai muodostaa uudelleen, kun raportteja suunnitellaan uudelleen Power BI:ssä. Tarkat vaatimukset ovat hyödyllisiä vaiheen 2 ratkaisun käyttöönoton suunnittelussa, soveltuvuusselvityksen luonnin aikana vaiheessa 3 ja luotaessa tuotantovalmista ratkaisua vaiheessa 4.

Raporttivaatimusten kerääminen

Laadi raporteista perusteellisia ja helposti viitattavat tiedot, kuten seuraavat:

  • Tarkoitus, kohderyhmä ja odotettu toiminto: Selvitä kunkin raportin tarkoitus ja liiketoimintaprosessi sekä kohderyhmä, analyyttinen työnkulku ja odotetut toimet, joita raportin kuluttajat voivat tehdä.
  • Miten kuluttajat käyttävät raporttia: Harkitse istuvasi aiemmin luodun raportin kuluttajien kanssa ymmärtääksesi tarkalleen, mitä he tekevät raportilla. Saatat oppia, että jotkin raportin elementit voidaan poistaa tai niitä voidaan parantaa uudessa Power BI -versiossa. Tämä prosessi vie enemmän aikaa, mutta se on arvokas kriittisille raporteille tai raporteille, joita käytetään usein.
  • Omistaja ja aihealueen asiantuntija: Selvitä raportin omistaja ja raporttiin tai tietotoimialueeseen liittyvät aihealueen asiantuntijat. Heistä voi tulevaisuudessa tulla uuden Power BI -raportin omistajia. Sisällytä tietyt muutosten hallinnan vaatimukset (jotka yleensä eroavat IT-hallittujen ja yrityksen hallitsemien ratkaisujen välillä) sekä hyväksynnät ja kuittaukset, jotka vaaditaan, kun muutoksia tehdään jatkossa. Lisätietoja on tässä artikkelissa.
  • Sisällön toimitusmenetelmä: Selvitä raportin kuluttajan odotukset sisällön toimittamisesta. Kyseessä voi olla pyydettäessä suoritettava, vuorovaikutteinen suoritus mukautettuun sovellukseen upotettuna tai toimitus aikataulussa sähköpostitilausta käyttämällä. Ilmoitusten käynnistämiseen voi myös liittyä vaatimuksia.
  • Vuorovaikutteisuustarpeet: Selvitä pakollinen ja hyödyllinen vuorovaikutteisuusvaatimukset, kuten suodattimet, porautumistoiminnot tai porautumistoiminnot.
  • Tietolähteet: Varmista, että kaikki raportin edellyttämät tietolähteet löydetään ja että tietoviiveen tarpeet (tietojen tuoreus) ymmärretään. Tunnista kunkin raportin historialliset tiedot, trendit ja tietojen tilannevedoksen vaatimukset, jotta ne voidaan kohdistaa tietovaatimusten kanssa. Tietolähdedokumentaatiosta voi olla hyötyä myös myöhemmin uuden raportin tietojen kelpoisuuden tarkistamista suoritettaessa sen lähdetieduksilla.
  • Suojausvaatimukset: Selvitä suojausvaatimukset (kuten sallitut katselijat, sallitut muokkaajat ja rivitason suojaustarpeet), mukaan lukien poikkeukset organisaation normaaliin suojaukseen. Dokumentoi mahdollinen tietojen luottamuksellisuustaso, tietosuoja tai sääntely-/yhteensopivuustarpeet.
  • Laskutoimitukset, suorituskykyilmaisimet ja liiketoimintasäännöt: Tunnista ja dokumentoi kaikki laskutoimitukset, suorituskykyilmaisimet ja liiketoimintasäännöt, jotka on tällä hetkellä määritetty raportissa, jotta ne voidaan kohdistaa tietovaatimusten kanssa.
  • Käytettävyys-, asettelu- ja kosmeettiset vaatimukset: Tunnista tietojen visualisointien, ryhmittelyn ja lajittelun vaatimuksiin ja ehdolliseen näkyvyyteen liittyvät erityiset käytettävyys-, asettelu- ja kosmeettiset tarpeet. Sisällytä mobiililaitteiden toimitukseen liittyvät lisänäkökohdat.
  • Tulostus- ja vientitarpeet: Selvitä, onko vienti- vai tulostusvalmiiseen asetteluun liittyviä vaatimuksia. Nämä tarpeet vaikuttavat siihen, mikä raporttityyppi on sopivin (kuten Power BI, Excel tai sivutettu raportti). Huomaa, että raportin kuluttajat yleensä tekevät asioita samalla tavalla kuin aina ennenkin, joten älä pelkää kyseenalaistaa heidän ajattelutapaansa. Muista puhua parannuksista muutosten sijaan.
  • Riskit tai huolenaiheet: Selvitä, onko raporteille muita teknisiä tai toiminnallisia vaatimuksia, sekä mahdolliset riskit tai huolenaiheet, jotka koskevat niissä esitettyjä tietoja.
  • Avoimet ongelmat ja keskeneräiset kohdat: Tunnista mahdolliset tulevat ylläpitotoiveet, tunnetut ongelmat tai lykätyt pyynnöt, jotka lisätään keskeneräisiä töiden kesken.

Vihje

Harkitse luokitteluvaatimusten, kuten pakollinen tai hyvä, käyttämistä. Kuluttajat kysyvät usein kaikkea, mitä he ehkä tarvitsevat etukäteen, koska he uskovat, että tämä on heidän ainoa mahdollisuutensa tehdä pyyntöjä. Lisäksi käsitellessäsi prioriteetteja useissa iteraatioissa, aseta keskeneräiset asiat sidosryhmien saataville. Se auttaa viestinnässä, päätöksenteossa ja odottavien sitoumusten seurannassa.

Kerää tietovaatimuksia

Käännä yksityiskohtaisia tietoja, jotka koskevat esimerkiksi:

  • Aiemmin luodut kyselyt: Selvitä, onko olemassa olevia raporttikyselyitä tai tallennettuja toimintosarjoja, joita DirectQuery-malli tai yhdistelmämalli voi käyttää tai jotka voidaan muuntaa tuontimalliksi.
  • Tietolähdetyypit: Käännä tarvittavat tietolähdetyypit, kuten keskitetyt tietolähteet (kuten yritystietovarasto) sekä muut kuin standardit tietolähteet (kuten tietuetiedostot tai Excel-tiedostot, jotka voivat laajentaa yritystietolähteitä raportointia varten). Tietolähteiden sijainnin selvittäminen tietoyhdyskäytävän liitettävyyttä varten on myös tärkeää.
  • Tietorakenne ja siistimistarpeet: Selvitä kunkin tarvittavan tietolähteen tietorakenne ja se, missä määrin tietojen siistimisen toiminnot ovat välttämättömiä.
  • Tietojen integrointi: Arvioi, miten tietojen integrointia käsitellään, kun tietolähteitä on useita, ja miten suhteita voidaan määrittää kunkin mallitaulukon välillä. Tunnista tietyt tietoelementit, joita tarvitaan mallin yksinkertaistamiseen ja koon pienentämiseen.
  • Hyväksyttävä tietojen viive: Selvitä tietojen viiveen tarpeet kullekin tietolähteelle. Se vaikuttaa käytettävää tietojen tallennustilaa koskeviin päätöksiin. Tuontimallitaulukoiden tietojen päivitystaajuus on myös tärkeä tietää.
  • Tietojen määrä ja skaalattavuus: Arvioi tietojen määrän odotuksia, jotka vaikuttavat suurten mallien tukea sekä DirectQuery- tai yhdistelmämallien suunnittelua koskeviin päätöksiin. Historiallisten tietojen tarpeisiin liittyvät näkökohdat on myös tärkeä tietää. Suurempien semanttisten mallien kohdalla myös lisäävän tietojen päivittämisen määrittäminen on myös tarpeen.
  • Mittarit, suorituskykyilmaisimet ja liiketoimintasäännöt: Arvioi tarpeet mittareille, suorituskykyilmaisimia ja liiketoimintasäännöille. Ne vaikuttavat päätöksiin siitä, missä logiikkaa käytetään: semanttisessa mallissa vai tietojen integroinnissa.
  • Ydintiedot ja tietohakemisto: Mieti, onko ydintietoihin liittyviä ongelmia, jotka edellyttävät huomiota. Selvitä, onko yritystietohakemiston sisällyttäminen tarkoituksenmukaista, jotta voidaan parantaa löydettävyyttä, käyttää määritelmiä tai tuottaa organisaation hyväksymiä yhdenmukaisia termejä.
  • Suojaus ja tietosuoja: Selvitä, onko semanttisille malleille mitään erityisiä suojaus- tai tietosuojanäkökohtia, mukaan lukien rivitason suojausvaatimukset .
  • Avoimet ongelmat ja keskeneräiset työt: Lisää tunnetut ongelmat, tunnetut tietojen laatuun liittyvät viat, tulevat ylläpitotyöt tai lykätyt pyynnöt, jotka lisätään keskeneräisiin työruuhkaan.

Tärkeä

Tietojen uudelleenkäytettävyys voidaan saavuttaa jaettavilla semanttisissa malleissa, jotka voidaan vaihtoehtoisesti sertifioida luotettavuuden ilmaisemiseksi ja löydettävyyden parantamiseksi. Tietojen valmistelun uudelleenkäytettävyys voidaan saavuttaa tietovoiden avulla, mikä vähentää toistuvaa logiikkaa useissa semanttisissa malleissa. Tietovuot voivat myös vähentää lähdejärjestelmien kuormitusta huomattavasti, koska tiedot noudetaan harvemmin – useat semanttiset mallit voivat sitten tuoda tietoja tietovuosta.

Tunnista parannusmahdollisuudet

Useimmissa tilanteissa tapahtuu joitakin muutoksia ja parannuksia. On harvinaista, että suora yksi yhteen -siirto tapahtuu ilman minkäänlaista uudelleenmuodostamista tai parannusta. Huomionarvoista on kolme seuraavaa parannustyyppiä:

  • Raporttien konsolidointi: Samankaltaisia raportteja voidaan konsolidoida käyttämällä erilaisia tekniikoita, kuten suodattimia, kirjanmerkkejä tai mukauttamista. Pienempi määrä raportteja, jotka ovat kuitenkin joustavampia, voi parantaa merkittävästi raportin kuluttajien käyttökokemusta. Harkitse semanttisten mallien optimointia Q&A:lle (luonnollisella kielellä kirjoitettu kysely), jotta voit tarjota entistä enemmän joustavuutta raportin kuluttajille, jotta he voivat luoda omia visualisointejaan.
  • Tehokkuuden parannukset: Vaatimusten keräämisen aikana voidaan usein tunnistaa parannuksia. Esimerkiksi silloin, kun analyytikot kääntävät lukuja manuaalisesti tai kun työnkulkua voidaan virtaviivaistaa. Power Querylla voi olla suuri rooli tällä hetkellä suoritettavien manuaalisten toimintojen korvaamisessa. Jos yritysanalyytikot joutuvat suorittamaan samoja toimia tietojen siistimistä ja valmistelua varten säännöllisesti, toistettavissa olevat Power Queryn tietojen valmistelun vaiheet voivat säästää aikaa merkittävästi ja vähentää virheitä.
  • Tietomallin keskittäminen: Virallinen ja sertifioitu semanttinen malli toimii hallitun, omatoimisen BI:n runkona. Tässä tapauksessa tietoja hallitaan kerran, ja analyytikot voivat joustavasti käyttää ja laajentaa näitä tietoja raportointi- ja analyysitarpeidensa mukaan.

Muistiinpano

Lisätietoja tietomallien keskimisestä on oppaissa kurinalaisuudesta ytimessä ja joustavuudesta reunalla.

Priorisoi ja arvioi monimutkaisuutta

Tässä vaiheessa alkuvarasto on käytettävissä, ja se voi sisältää erityisvaatimuksia. Kun priorisoit siirtoa varten valmista BI-tietoyksiköiden ensimmäistä joukkoa, raportteja ja tietoja tulee tarkastella yhdessä sekä toisistaan riippumatta.

Tunnista suuren prioriteetin raportit, kuten raportit,

  • jotka tuovat merkittävää arvoa liiketoiminnalle.
  • jotka suoritetaan usein.
  • joita ylin johto edellyttää
  • joiden monimutkaisuustaso on kohtuullinen (onnistumismahdollisuuksien parantamiseksi ensimmäisten siirron iteraatioiden aikana).

Tunnista suuren prioriteetin tiedot, kuten tiedot,

  • Sisältää kriittisiä tietoelementtejä.
  • jotka ovat yleisiä, moniin käyttötapauksiin sopivia organisaatiotietoja.
  • Voidaan käyttää jaetun semanttisen mallin luomiseen raporttien ja monien raportin luojien uudelleenkäyttöä varten.
  • joiden monimutkaisuustaso on kohtuullinen (onnistumismahdollisuuksien parantamiseksi ensimmäisten siirron iteraatioiden aikana).

Liittyvä sisältö

Tämän Power BI -siirtymää sisältävän sarjan seuraavassa artikkelissa tutustutaan vaiheeseen 2, joka koskee yksittäisen Power BI -ratkaisun siirron suunnittelua.

Seuraavat resurssit ovat myös hyödyllisiä:

Kokeneet Power BI -kumppanit voivat auttaa organisaatiotasi onnistumaan siirtymisprosessissa. Jos haluat ryhtyä yhteistyöhön Power BI -kumppanin kanssa, siirry Power BI -kumppaniportaaliin.