Proof of concept uitvoeren om te migreren naar Power BI

  • Artikel

In dit artikel wordt fase 3 beschreven, dat betrekking heeft op het uitvoeren van een proof-of-concept (POC) om risico's te beperken en onbekende gegevens zo snel mogelijk te verhelpen bij het migreren naar Power BI.

Diagram shows the stages of a Power BI migration. Stage 3 is emphasized for this article.

Notitie

Zie het overzicht van power BI-migratie voor een volledige uitleg van de bovenstaande afbeelding.

De focus van fase 3 is om onbekende gegevens aan te pakken en risico's zo vroeg mogelijk te beperken. Een technische POC is handig voor het valideren van veronderstellingen. Het kan iteratief worden uitgevoerd naast de planning van de implementatie van de oplossing (beschreven in fase 2).

De uitvoer van deze fase is een Power BI-oplossing die beperkt is in het bereik, de eerste openstaande vragen beantwoordt en klaar is voor extra werk in fase 4 om deze gereed te maken voor productie.

Belangrijk

We zijn niet van plan om de POC wegwerpwerk te laten zijn. In plaats daarvan verwachten we dat het een vroege iteratie is van de oplossing die gereed is voor productie. In uw organisatie kunt u deze activiteit raadplegen als een prototype, pilot, mockup, quickstart of minimaal levensvatbaar product (MVP). Het uitvoeren van een POC is niet altijd nodig en het kan zelfs informeel gebeuren.

Tip

De meeste onderwerpen die in dit artikel worden besproken, zijn ook van toepassing op een standaard Power BI-implementatieproject. Naarmate uw organisatie meer ervaring ervaart met Power BI, neemt de noodzaak om POC's uit te voeren af. Vanwege het snelle releaseritme met Power BI en de voortdurende introductie van nieuwe functies kunt u echter regelmatig technische POC's uitvoeren voor leerdoeleinden.

POC-doelstellingen en -bereik instellen

Richt u bij het uitvoeren van een POC op de volgende doelen:

  • Controleer uw veronderstellingen over hoe een functie werkt.
  • Informeer uzelf over verschillen in de manier waarop Power BI werkt vergeleken met het verouderde BI-platform.
  • Valideer initiële kennis van bepaalde vereisten met deskundigen.
  • Maak een klein semantisch model (voorheen een gegevensset genoemd) met echte gegevens om eventuele problemen met de gegevensstructuur, relaties, gegevenstypen of gegevenswaarden te begrijpen en te detecteren.
  • Experimenteer en valideer DAX-syntaxisexpressies die worden gebruikt door modelberekeningen.
  • Test de connectiviteit van de gegevensbron met behulp van een gateway (als dit een gatewaybron is).
  • Test het vernieuwen van gegevens met behulp van een gateway (als dit een gatewaybron is).
  • Controleer de beveiligingsconfiguraties, inclusief beveiliging op rijniveau, indien van toepassing.
  • Experimenteer met lay-out- en cosmetische beslissingen.
  • Controleer of alle functionaliteit in de Power BI-service werkt zoals verwacht.

Het POC-bereik is afhankelijk van wat de onbekenden zijn of welke doelen moeten worden gevalideerd met collega's. Om de complexiteit te verminderen, houdt u een POC zo smal mogelijk in termen van bereik.

Bij een migratie zijn de vereisten meestal bekend omdat er een bestaande oplossing is om van te beginnen. Afhankelijk van de mate van verbeteringen die moeten worden aangebracht of bestaande Power BI-vaardigheden, biedt een POC echter nog steeds een aanzienlijke waarde. Bovendien kunnen snelle prototypen met feedback van consumenten geschikt zijn om snel vereisten te verduidelijken, met name als er verbeteringen worden aangebracht.

Belangrijk

Zelfs als een POC slechts een subset met gegevens bevat of alleen beperkte visuals bevat, is het vaak belangrijk om deze van begin tot eind te nemen. Dat wil gezegd: van ontwikkeling in Power BI Desktop tot implementatie naar een ontwikkelwerkruimte in de Power BI-service. Het is de enige manier om de POC-doelstellingen volledig te bereiken. Dit geldt met name wanneer de Power BI-service essentiële functionaliteit moet leveren die u nog niet eerder hebt gebruikt, zoals een DirectQuery-semantisch model dat gebruikmaakt van eenmalige aanmelding. Richt tijdens de POC uw inspanningen op aspecten die u niet zeker weet of die u met anderen wilt verifiëren.

Verschillen in Power BI afhandelen

Power BI kan worden gebruikt als een hulpprogramma op basis van een model of als een hulpprogramma op basis van rapporten. Een modeloplossing omvat het ontwikkelen van een gegevensmodel, terwijl een oplossing op basis van rapporten verbinding maakt met een al geïmplementeerd gegevensmodel.

Vanwege de extreme flexibiliteit zijn er enkele aspecten van Power BI die mogelijk fundamenteel verschillen van het verouderde BI-platform van waaruit u migreert.

Overweeg om de gegevensarchitectuur opnieuw te ontwerpen

Als u migreert van een verouderd BI-platform met een eigen semantische laag, is het maken van een semantisch importmodel waarschijnlijk een goede optie. Power BI werkt het beste met een ontwerp van een stervormige schematabel . Als de verouderde semantische laag dus geen stervormig schema is, is het mogelijk dat een nieuw ontwerp nodig is om volledig te profiteren van Power BI. Het definiëren van een semantische laag die zich houdt aan ontwerpprincipes voor stervormige schema's (inclusief relaties, veelgebruikte metingen en beschrijvende organisatieterminologie) fungeert als een uitstekend uitgangspunt voor selfservicerapportauteurs.

Als u migreert van een verouderd BI-platform waarin rapporten verwijzen naar relationele gegevensbronnen met behulp van SQL-query's of opgeslagen procedures en als u van plan bent Power BI te gebruiken in de DirectQuery-modus, kunt u mogelijk dicht bij een een-op-een-migratie van het gegevensmodel komen.

Let op

Als u ziet dat veel Power BI Desktop-bestanden bestaan uit één geïmporteerde tabel, is het meestal een indicator dat het ontwerp niet optimaal is. Als u deze situatie ziet, onderzoekt u of het gebruik van gedeelde semantische modellen die zijn gemaakt met behulp van een stervormig schemaontwerp een beter resultaat kan opleveren.

Bepalen hoe dashboardconversies moeten worden verwerkt

In de BI-branche is een dashboard een verzameling visuals die belangrijke metrische gegevens op één pagina weergeeft. In Power BI vertegenwoordigt een dashboard echter een specifieke visualisatiefunctie die alleen kan worden gemaakt in de Power BI-service. Wanneer u een dashboard migreert vanaf een verouderd BI-platform, hebt u twee opties:

  1. Het verouderde dashboard kan opnieuw worden gemaakt als een Power BI-rapport. De meeste rapporten worden gemaakt met Power BI Desktop. Gepagineerde rapporten en Excel-rapporten zijn ook alternatieve opties.
  2. Het verouderde dashboard kan opnieuw worden gemaakt als een Power BI-dashboard. Dashboards zijn een visualisatiefunctie van de Power BI-service. Dashboardvisuals worden vaak gemaakt door visuals vast te maken uit een of meer rapporten, Q&A of Snelle inzichten.

Tip

Omdat dashboards een Power BI-inhoudstype zijn, moet u zich onthouden van het woorddashboard in de naam van het rapport of dashboard.

Focus op het grote geheel bij het opnieuw maken van visuals

Elk BI-hulpprogramma heeft zijn sterke punten en focusgebieden. Daarom hebben de exacte rapportvisuals waarvoor u afhankelijk was in een verouderd BI-platform mogelijk geen nauw equivalent in Power BI.

Wanneer u rapportvisuals opnieuw maakt, richt u zich meer op de zakelijke vragen van het grote geheel die door het rapport worden aangepakt. Hiermee wordt de druk verwijderd om het ontwerp van elke visual precies op dezelfde manier te repliceren. Hoewel gebruikers van inhoud consistentie waarderen bij het gebruik van gemigreerde rapporten, is het belangrijk om niet in de tijdrovende debatten te komen over kleine details.

Gerelateerde inhoud

In het volgende artikel in deze Power BI-migratiereeks leert u meer over fase 4, dat betrekking heeft op het maken en valideren van inhoud bij het migreren naar Power BI.

Andere nuttige bronnen zijn onder meer:

Ervaren Power BI-partners zijn beschikbaar om uw organisatie te helpen slagen met het migratieproces. Als u een Power BI-partner wilt betrekken, gaat u naar de Power BI-partnerportal.