Power BI-implementatieplanning: BI-oplossingsplanning

Notitie

Dit artikel maakt deel uit van de reeks artikelen over de implementatieplanning van Power BI. Deze reeks richt zich voornamelijk op de Power BI-ervaring in Microsoft Fabric. Zie de planning van de Power BI-implementatie voor een inleiding tot de reeks.

Dit artikel helpt u bij het plannen van oplossingen die ondersteuning bieden voor uw BI-strategie (Business Intelligence). Het is voornamelijk gericht op:

• BI- en analytics-directeuren of -managers: besluitvormers die verantwoordelijk zijn voor het toezicht op het BI-programma en strategisch belangrijke BI-oplossingen.
• Center of Excellence (COE), IT- en BI-teams: de teams die zakelijke BI-oplossingen voor hun organisatie ontwerpen en implementeren.
• Deskundigen (KMO's) en makers van inhoud: de teams en personen die analyses in een afdeling ondersteunen en oplossingen ontwerpen en implementeren voor selfservice-, afdelings-BI- of team BI-gebruiksscenario's .

Een BI-strategie is een plan voor het implementeren, gebruiken en beheren van gegevens en analyses. U definieert uw BI-strategie door te beginnen met de strategische BI-planning. Strategische planning helpt u bij het identificeren van uw BI-focusgebieden en -doelstellingen. Als u het pad naar de voortgang van uw BI-doelstellingen wilt bepalen, beschrijft u specifieke belangrijke resultaten met behulp van tactische planning. Vervolgens bereikt u de voortgang van deze belangrijke resultaten door BI-oplossingen te plannen en te implementeren.

Notitie

In het framework voor doelstellingen en belangrijkste resultaten (OKR's) zijn duidelijke , algemene beschrijvingen van wat u wilt bereiken. Belangrijke resultaten zijn daarentegen specifieke, haalbare resultaten om de voortgang van een van uw doelstellingen te meten.

Daarnaast zijn initiatieven of oplossingen processen of hulpprogramma's die zijn gebouwd om u te helpen een of meer belangrijke resultaten te bereiken. Oplossingen hebben betrekking op specifieke gegevensbehoeften voor gebruikers. Een oplossing kan veel vormen aannemen, zoals een gegevenspijplijn, een data lakehouse of een semantisch Power BI-model of -rapport.

Zie Okr's voor meer informatie over OKR's (Microsoft Viva Goals) voor meer informatie over OKR's.

Er zijn veel benaderingen voor het plannen en implementeren van BI-oplossingen. In dit artikel wordt een benadering beschreven die u kunt gebruiken om BI-oplossingen te plannen en implementeren die ondersteuning bieden voor uw BI-strategie.

In het volgende diagram op hoog niveau ziet u hoe u BI-oplossingsplanning uitvoert.

U voert de volgende stappen uit om BI-oplossingsplanning uit te voeren.

Stap	Beschrijving
1	Stel een projectteam samen dat vereisten verzamelt en definieert het ontwerp van de oplossing.
2	Plan de implementatie van oplossingen door de eerste installatie van hulpprogramma's en processen uit te voeren.
3	Voer een proof of concept (POC) van een oplossing uit om veronderstellingen over het ontwerp te valideren.
4	Inhoud maken en valideren met behulp van iteratieve ontwikkelings- en validatiecycli.
5	Implementeer, ondersteuning en bewaak de oplossing nadat deze is vrijgegeven in de productieomgeving.

Notitie

Bi-oplossingsplanning is van toepassing op zowel selfservice-BI - als enterprise BI-projecten .

Zie de Power BI-migratiereeks voor meer informatie. Hoewel de reeks betrekking heeft op migratie, zijn de belangrijkste acties en overwegingen relevant voor de planning van oplossingen.

Stap 1: Vereisten verzamelen

U begint met het plannen van de oplossing door eerst vereisten te verzamelen en het oplossingsontwerp te definiëren.

Opmerking: Strategische en tactische planning wordt geleid door een werkteam, dat het initiatief leidt. Oplossingsplanning wordt daarentegen geleid door een projectteam, dat bestaat uit inhoudseigenaren en makers.

Het verzamelen van de juiste vereisten is essentieel voor een succesvolle implementatie en acceptatie van oplossingen. Een effectieve manier om vereisten te verzamelen is het identificeren en betrekken van de juiste belanghebbenden, gezamenlijk het probleem definiëren dat moet worden opgelost en die gedeelde kennis van het probleem gebruiken om een oplossingsontwerp te maken.

Hier volgen enkele voordelen van het gebruik van een samenwerkingsbenadering om vereisten te verzamelen.

• Gebruikersinvoer produceert nuttigere ontwerpen: Door gebruikers te betrekken bij gerichte discussies om vereisten te verzamelen, kunt u efficiënter zakelijke gegevensbehoeften vastleggen. Gebruikers kunnen bijvoorbeeld aan makers van inhoud laten zien hoe ze bestaande oplossingen gebruiken en feedback geven over de waargenomen effectiviteit van deze oplossingen.
• Vermijd veronderstellingen en beperk wijzigingsaanvragen: discussies met gebruikers onthullen vaak nuances, uitzonderingen en verborgen complexiteiten. Deze inzichten verminderen de kans op aanvragen die te laat zijn, wat kostbaar kan zijn om aan te pakken.
• Onboarding van gebruikers verhoogt de acceptatie van oplossingen: Door gebruikers te betrekken bij het ontwerpen en vroeg ontwikkelen, biedt u hen de mogelijkheid om het uiteindelijke resultaat te beïnvloeden. Betrokkenheid kan gebruikers ook een gevoel geven van intellectueel eigendom en verantwoordelijkheid voor de oplossing. Zeer betrokken gebruikers zullen de oplossing waarschijnlijker goedkeuren en hun praktijkgemeenschap effectief gebruiken.
• Ontwerpen stellen verwachtingen vast voor belanghebbenden en zakelijke gebruikers: Door mock-ups of illustraties van het oplossingsontwerp te produceren, kunt u duidelijk belanghebbenden laten zien wat de oplossing zal leveren. Het helpt ook door een wederzijds begrip te creëren van het verwachte projectresultaat. Dit proces wordt ook wel ontwerpdenken genoemd en het kan een effectieve manier zijn om complexe problemen te benaderen en te begrijpen.

U kunt verschillende benaderingen gebruiken om gebruikers te benaderen en vereisten te verzamelen. U kunt bijvoorbeeld vereisten verzamelen met bedrijfsontwerp en technisch ontwerp (beschreven in latere secties van dit artikel).

Bedrijfsontwerp is een benadering om zakelijke vereisten te verzamelen. Het richt zich op het betrekken van zakelijke gebruikers in zakelijke ontwerpsessies om de oplossing gezamenlijk te ontwerpen. De uitvoer van een bedrijfsontwerp bestaat uit mock-ups van oplossingen en beschrijvende ontwerpdocumentatie.

Technisch ontwerp is een benadering voor het vertalen van bedrijfsvereisten naar technische vereisten en het aanpakken van ontwerpveronderstellingen. Een technisch ontwerp is gericht op het valideren van het bedrijfsontwerp en het definiëren van een technische benadering die moet worden gebruikt. Om het ontwerp te valideren, nemen makers van inhoud doorgaans contact op met technische experts in gerichte discussies, ook wel technische ontwerpsessies genoemd, indien nodig.

Belangrijk

Het verzamelen van de verkeerde vereisten is een veelvoorkomende reden waarom implementaties mislukken. Vaak verzamelen teams de verkeerde vereisten omdat ze betrokken zijn bij de verkeerde belanghebbenden, zoals besluitvormers die top-downaanvragen bieden voor het bouwen van oplossingen.

Het betrekken van zakelijke gebruikers met behulp van samenwerkingsmethoden zoals een bedrijfsontwerp kan u helpen betere vereisten te verzamelen. Betere vereisten leiden vaak tot efficiëntere ontwikkeling en robuustere oplossingen.

Notitie

Voor sommige teams is het verzamelen van gestructureerde vereisten een grote verandering. Zorg ervoor dat u deze wijziging beheert en dat de planning van de oplossing niet wordt onderbroken. We raden u aan om manieren te vinden om deze benaderingen aan te passen aan de manier waarop uw team werkt.

Voorbereiden op oplossingsplanning

Bereid u eerst voor op de planning van de oplossing door rekening te houden met de factoren die in de volgende secties worden beschreven.

• Bepaal wie oplossingsplanning gaat uitvoeren: als onderdeel van de tactische BI-planning heeft het team een prioriteitsachterstand van oplossingen gemaakt. Bij het plannen van oplossingen is een projectteam verantwoordelijk voor het ontwerpen, ontwikkelen en implementeren van een of meer oplossingen uit de achterstand. Voor elke oplossing in de achterstand moet u een projectteam samenstellen dat verantwoordelijk is voor de oplossing. Naast het uitvoeren van BI-oplossingsplanning moet het projectteam:
  • Definieer tijdlijnen en mijlpalen voor het plannen van oplossingen.
  • Identificeer en betrek de juiste belanghebbenden voor het verzamelen van vereisten.
  • Stel een centrale locatie in voor communicatie, documentatie en planning.
  • Betrek belanghebbenden om vereisten te verzamelen.
  • Communiceren en coördineren met belanghebbenden en zakelijke gebruikers.
  • Iteratieve ontwikkelings- en testcycli organiseren met zakelijke gebruikers.
  • Documenteer de oplossing.
  • Onboarding van gebruikers naar de oplossing door een trainingsplan te definiëren en uit te voeren.
  • Bied ondersteuning voor de oplossing na de implementatie.
  • Verwerk redelijke gebruikersaanvragen om de oplossing na de implementatie te wijzigen of bij te werken.
  • Voer indien nodig een oplossing over na de implementatie.
• Communicatie en documentatie centraliseren: het is belangrijk dat het projectteam communicatie en documentatie centraliseert voor het plannen van BI-oplossingen. Het projectteam moet bijvoorbeeld vereisten, communicatie van belanghebbenden, tijdlijnen en producten centraliseren. Overweeg alle documentatie op te slaan in een gecentraliseerde portal.
• Planningsvereisten verzamelen: het projectteam moet beginnen met het plannen van de bedrijfsontwerpsessies om zakelijke vereisten te verzamelen. Deze sessies hebben de vorm van interactieve vergaderingen en ze kunnen een vergelijkbare indeling volgen als de strategische planningsworkshops.

Tip

Overweeg om de ondersteuningsteams die verantwoordelijk zijn voor de oplossing vroeg in het proces voor het verzamelen van vereisten te identificeren en erbij te betrekken. Om de oplossing effectief te ondersteunen, hebben de ondersteuningsteams een uitgebreid begrip nodig van de oplossing, het doel ervan en de gebruikers. Dat is vooral belangrijk wanneer het projectteam alleen bestaat uit externe consultants.

Zakelijke vereisten verzamelen

Het verzamelen van de juiste zakelijke vereisten is essentieel voor het ontwerpen van de juiste oplossing. Om de juiste vereisten te verzamelen en een effectief oplossingsontwerp te definiëren, kan het projectteam zakelijke ontwerpsessies uitvoeren samen met de zakelijke gebruikers.

Het doel van de bedrijfsontwerpsessies is het volgende:

• Bevestig het oorspronkelijke oplossingsbereik.
• Definieer en begrijp het probleem dat de oplossing moet oplossen.
• Identificeer de juiste belangrijke belanghebbenden voor de oplossing.
• Verzamel de juiste zakelijke vereisten.
• Bereid een oplossingsontwerp voor dat voldoet aan de bedrijfsvereisten.
• Ondersteunende ontwerpdocumentatie voorbereiden.

In het volgende diagram ziet u hoe u zakelijke vereisten verzamelt en het oplossingsontwerp definieert met behulp van een bedrijfsontwerpbenadering.

In het diagram ziet u de volgende stappen.

Artikel	Beschrijving
	Het projectteam begint het bedrijfsontwerp door het oplossingsbereik te bevestigen dat voor het eerst is gedocumenteerd in tactische planning. Ze moeten de bedrijfsgebieden, systemen en gegevens verduidelijken die de oplossing zal omvatten.
	Het projectteam identificeert belangrijke belanghebbenden van de gebruikerscommunity die betrokken zullen zijn bij de bedrijfsontwerpsessies. Belangrijke belanghebbenden zijn gebruikers met voldoende kennis en geloofwaardigheid om de onderwerpen van de oplossing te vertegenwoordigen.
	Het projectteam plant zakelijke ontwerpsessies. Planning omvat het informeren van belanghebbenden, het organiseren van vergaderingen, het voorbereiden van producten en het betrekken van zakelijke gebruikers.
	Het projectteam verzamelt en onderzoekt bestaande oplossingen die zakelijke gebruikers momenteel gebruiken om te voldoen aan bestaande zakelijke gegevensbehoeften. Om dit proces te versnellen, kan het projectteam relevant onderzoek van DE STRATEGISCHE PLANNING van BI gebruiken, dat is gedocumenteerd in de communicatiehub.
	Het projectteam voert zakelijke ontwerpsessies uit met belanghebbenden. Deze sessies zijn kleine, interactieve vergaderingen, waarbij het projectteam belanghebbenden begeleidt om inzicht te krijgen in de behoeften en vereisten van bedrijfsgegevens.
	Het projectteam sluit het bedrijfsontwerp af door een conceptoplossingsontwerp te presenteren aan belanghebbenden en andere gebruikers voor feedback en goedkeuring. Het bedrijfsontwerp is succesvol wanneer de belanghebbenden het erover eens zijn dat het ontwerp hen zal helpen hun bedrijfsdoelstellingen te bereiken.

Het bedrijfsontwerp eindigt met de volgende producten.

• Ontwerpontwerpen voor oplossingen: Mock-ups, prototypen of draadmodeldiagrammen illustreren het ontwerp van de oplossing. Deze documenten vertalen de vereisten naar een concrete ontwerpblauwdruk.
• Lijst met metrische zakelijke gegevens: kwantitatieve velden die in de oplossing worden verwacht, inclusief bedrijfsdefinities en verwachte aggregaties. Rangschik ze indien mogelijk op belang voor de gebruikers.
• Lijst met bedrijfskenmerken: relevante kenmerken en gegevensstructuren die in de oplossing worden verwacht, inclusief bedrijfsdefinities en kenmerknamen. Neem indien mogelijk hiërarchieën op en rangschik de kenmerken op belang voor de gebruikers.
• Aanvullende documentatie: Beschrijvingen van belangrijke functionele of nalevingsvereisten. Deze documentatie moet zo nauwkeurig mogelijk zijn, maar zo beknopt mogelijk.

De producten voor bedrijfsontwerp worden gebruikt in en gevalideerd door het technische ontwerp.

Tip

Met mock-ups van oplossingen, prototypen of draadmodeldiagrammen kunt u een duidelijk beeld krijgen van het verwachte resultaat, zowel voor ontwikkelaars als voor eindgebruikers. Voor het maken van effectieve mock-ups is geen artistieke vaardigheid of talent vereist. U kunt eenvoudige hulpmiddelen zoals Microsoft Whiteboard, PowerPoint of zelfs een pen en papier gebruiken om het ontwerp te illustreren.

Technische vereisten verzamelen

Nadat het bedrijfsontwerp is voltooid, valideert het projectteam de resultaten met behulp van een technisch ontwerp. Het technische ontwerp is een benadering die vergelijkbaar is met het bedrijfsontwerp. Hoewel het bedrijfsontwerp zich richt op zakelijke gegevensbehoeften, richt het technische ontwerp zich op de technische aspecten van een oplossing. Een belangrijk resultaat van het technische ontwerp is het oplossingsplan, waarin het uiteindelijke oplossingsontwerp en de geïnformeerde schattingen worden beschreven van de inspanningen om het te implementeren.

Notitie

In tegenstelling tot het bedrijfsontwerp is het technische ontwerp grotendeels een onafhankelijk onderzoek naar brongegevens en -systemen die worden uitgevoerd door makers en eigenaren van inhoud.

Het doel van een technisch ontwerp is het volgende:

• Valideer de resultaten van het bedrijfsontwerp.
• Technische veronderstellingen in het huidige ontwerp aanpakken.
• Identificeer de relevante gegevensbronnen in het bereik en definieer de veldberekeningen en veldbrontoewijzingen voor elke gegevensbron.
• Vertaal de bedrijfsvereisten naar technische vereisten.
• Hiermee worden schattingen gemaakt van de inspanning die nodig is voor de implementatie.

Het projectteam neemt technische of functionele belanghebbenden in beperkte, gerichte technische ontwerpsessies in contact. Deze sessies zijn interactieve vergaderingen met de functionele belanghebbenden om technische vereisten te verzamelen. Belanghebbenden zijn verantwoordelijk voor specifieke functionele gebieden die nodig zijn om de oplossing effectief te laten werken.

Voorbeelden van belanghebbenden in een technisch ontwerp kunnen zijn:

• Beveiligings- en netwerkteams: verantwoordelijk voor de beveiliging en naleving van de gegevens.
• Functionele teams en gegevensstewards: Verantwoordelijk voor het cureren van de brongegevens.
• Architecten: Eigenaren van specifieke platforms, hulpprogramma's of technologie.

Het projectteam betrek belanghebbenden in technische ontwerpsessies om technische aspecten van de oplossing aan te pakken. Technische aspecten kunnen het volgende omvatten:

• Gegevensbronverbindingen: details over het maken van verbinding met en integreren van gegevensbronnen.
• Netwerken en gegevensgateways: details over privénetwerken of on-premises gegevensbronnen.
• Veldbrontoewijzing: Gegevenstoewijzingen van metrische gegevens en kenmerken van zakelijke gegevens voor gegevensbronvelden.
• Berekeningslogica: Een vertaling van bedrijfsdefinities naar technische berekeningen.
• Technische functies: functies of functionaliteit die nodig zijn om bedrijfsvereisten te ondersteunen.

Tip

Het projectteam dat het bedrijfsontwerp heeft uitgevoerd, moet ook het technische ontwerp uitvoeren. Om praktische redenen kunnen verschillende personen echter het technische ontwerp leiden. Begin in dit geval met het technische ontwerp door de resultaten van het bedrijfsontwerp te bekijken.

In het ideale geval moeten de personen die het technische ontwerp leiden, een grondig begrip hebben van de resultaten en de zakelijke gebruikers.

In het volgende diagram ziet u hoe u zakelijke vereisten vertaalt in technische vereisten met behulp van een technisch ontwerp.

In het diagram ziet u de volgende stappen.

Artikel	Beschrijving
	Het projectteam begint het technische ontwerp door het gegevensbronbereik te definiëren op basis van de resultaten van het bedrijfsontwerp. Het bereik van de gegevensbron declareert welke gegevens nodig zijn om de oplossing te bouwen. Om de juiste gegevensbronnen te identificeren, raadpleegt het projectteam de zakelijke en functionele KMO's.
	Het projectteam identificeert technische of functionele belanghebbenden die later in de technische ontwerpsessies betrokken moeten zijn.
	Het projectteam plant beperkte, gerichte sessies met functionele belanghebbenden om technische aspecten van de oplossing aan te pakken. Planning omvat het informeren van belanghebbenden, het organiseren van vergaderingen en het voorbereiden van producten.
	Het projectteam onderzoekt technische vereisten. Onderzoek omvat het definiëren van veldberekeningen en gegevensbrontoewijzingen, en het aanpakken van de veronderstellingen voor bedrijfsontwerp met technische analyse en documentatie.
	Indien nodig omvat het projectteam belanghebbenden in technische ontwerpsessies. Sessies richten zich op een specifiek, technisch aspect van de oplossing, zoals beveiligings- of gegevensbronverbindingen. In deze sessies verzamelt het projectteam kwalitatieve feedback van belanghebbenden en kmo's.
	Het projectteam bereidt hun bevindingen voor met behulp van een oplossingsplan, dat ze aan belanghebbenden en besluitvormers presenteren. Het plan is een iteratie en uitbreiding van de bedrijfsontwerpresultaten die het uiteindelijke ontwerp, de schattingen en andere producten omvatten.
	Het technische ontwerp moet eindigen met een laatste vergadering met belanghebbenden en besluitvormers om te beslissen of ze al dan niet moeten doorgaan. Deze vergadering biedt een laatste mogelijkheid om de planning van de oplossing te evalueren voordat resources zich inzetten voor het ontwikkelen van de oplossing.

Notitie

Het technische ontwerp kan onverwachte complexiteit onthullen waardoor de planning van de oplossing onfeilbaar kan worden gezien de huidige beschikbaarheid van resources of de gereedheid van de organisatie. In dit geval moet de oplossing opnieuw worden geëvalueerd in de volgende tactische planningsperiode. Afhankelijk van de urgentie van de behoeften van de zakelijke gegevens, wil een besluitvormer, zoals de executive sponsor, misschien nog steeds doorgaan met een proof-of-concept of slechts één deel van de geplande oplossing.

Het technische ontwerp eindigt met een oplossingsplan, dat bestaat uit de volgende producten.

• Hulpprogramma's en technologieën: Lijst van de relevante technische instrumenten die nodig zijn om de oplossing te implementeren. De lijst bevat doorgaans relevante nieuwe licentieopties (zoals Infrastructuurcapaciteit of Premium per gebruiker), functies en hulpprogramma's.
• Gedefinieerde lijst met metrische gegevens van het bedrijf: berekeningen en veldbrontoewijzingen van de metrische gegevens van het bedrijf voor alle gegevensbronnen binnen het bereik. Om dit product te produceren, gebruikt het projectteam de lijst met metrische zakelijke gegevens die zijn gemaakt in het bedrijfsontwerp.
• Gedefinieerde lijst met zakelijke kenmerken: veldbrontoewijzingen van de bedrijfskenmerken voor alle binnenbereikgegevensbronnen. Om dit product te produceren, gebruikt het projectteam de lijst met zakelijke kenmerken die zijn gemaakt in het bedrijfsontwerp.
• Herziene ontwerpen: Revisies van het oplossingsontwerp op basis van wijzigingen in, of ongeldige veronderstellingen over, het bedrijfsontwerp. Herziene ontwerpen zijn bijgewerkte versies van de mock-ups, prototypen of draadmodeldiagrammen die in het bedrijfsontwerp worden geproduceerd. Als er geen revisies nodig zijn, geeft u aan dat het technische ontwerp het bedrijfsontwerp valideert.
• Schatting van de inspanning: schat de resources die nodig zijn om de oplossing te ontwikkelen, te ondersteunen en te onderhouden. De schatting informeert de definitieve beslissing over de vraag of de oplossing al dan niet moet worden geïmplementeerd.

Belangrijk

Zorg ervoor dat het projectteam belanghebbenden op de hoogte stelt van wijzigingen of onverwachte ontdekkingen van het technische ontwerp. Deze technische ontwerpsessies moeten nog steeds relevante zakelijke gebruikers omvatten. Zorg er echter voor dat belanghebbenden niet onnodig worden blootgesteld aan complexe technische informatie.

Tip

Omdat bedrijfsdoelstellingen zich altijd ontwikkelen, wordt verwacht dat de vereisten veranderen. Stel niet dat de vereisten voor BI-projecten zijn opgelost. Als u moeite hebt met veranderende vereisten, kan het een indicatie zijn dat uw proces voor het verzamelen van vereisten niet effectief is of dat uw ontwikkelwerkstromen niet voldoende regelmatig feedback bevatten.

Controlelijst : bij het verzamelen van vereisten zijn belangrijke beslissingen en acties:

• Verduidelijken wie eigenaar is van de planning van de oplossing: zorg ervoor dat voor elke oplossing rollen en verantwoordelijkheden duidelijk zijn voor het projectteam.
• Het oplossingsbereik verduidelijken: het oplossingsbereik moet al worden gedocumenteerd als onderdeel van de tactische PLANNING van BI. Mogelijk moet u extra tijd en moeite besteden om het bereik te verduidelijken voordat u begint met het plannen van de oplossing.
• Belanghebbenden identificeren en informeren: belanghebbenden identificeren voor bedrijfsontwerpen en technische ontwerpen. Informeer ze van tevoren over het project en leg het bereik, de doelstellingen, de vereiste tijdsinvesteringen en producten uit het bedrijfsontwerp uit.
• Bedrijfsontwerpsessies plannen en uitvoeren: beheer de bedrijfsontwerpsessies om informatie van belanghebbenden en zakelijke gebruikers op te halen. Vraag of gebruikers laten zien hoe ze bestaande oplossingen gebruiken.
• Documenteer metrische gegevens en kenmerken van het bedrijf: Door bestaande oplossingen en invoer van belanghebbenden te gebruiken, maakt u een lijst met metrische gegevens en kenmerken van het bedrijf. Wijs in de technische ontwerpen de velden toe aan de gegevensbron en beschrijf de berekeningslogica voor kwantitatieve velden.
• Concept van het oplossingsontwerp: iteratieve mock-ups maken op basis van invoer van belanghebbenden die het verwachte oplossingsresultaat visueel weerspiegelen. Zorg ervoor dat mock-ups de bedrijfsvereisten nauwkeurig vertegenwoordigen en aanpakken. Communiceer met zakelijke gebruikers dat de mock-ups nog steeds moeten worden gevalideerd (en eventueel herzien) tijdens het technische ontwerp.
• Maak het oplossingsplan: Brongegevens en relevante technische overwegingen onderzoeken om ervoor te zorgen dat het bedrijfsontwerp haalbaar is. Beschrijf indien relevant belangrijke risico's en bedreigingen voor het ontwerp en eventuele alternatieve benaderingen. Bereid zo nodig een revisie van het oplossingsontwerp voor en bespreek het met de belanghebbenden.
• Schattingen voor inspanning maken: als onderdeel van het uiteindelijke oplossingsplan schat u de inspanningen om de oplossing te bouwen en te ondersteunen. Rechtvaardig deze schattingen met de informatie die is verzameld tijdens de bedrijfsontwerp- en technische ontwerpsessies.
• Bepaal of u wilt doorgaan met het plan: Om het proces voor het verzamelen van vereisten af te ronden, dient u het uiteindelijke plan aan belanghebbenden en besluitvormers te presenteren. Het doel van deze vergadering is om te bepalen of u wilt doorgaan met het ontwikkelen van oplossingen.

Stap 2: Implementatie plannen

Wanneer het projectteam klaar is met het verzamelen van vereisten, het maken van het oplossingsplan en het ontvangen van goedkeuring om door te gaan, is het klaar om de implementatie van de oplossing te plannen.

Implementatieplanningstaken verschillen, afhankelijk van de oplossing, uw ontwikkelwerkstroom en uw implementatieproces. Een implementatieplan heeft doorgaans betrekking op veel activiteiten met betrekking tot het plannen en instellen van hulpprogramma's en processen voor de oplossing.

Plannen om belangrijke gebieden aan te pakken

Het projectteam moet plannen voor de belangrijkste gebieden van de implementatie van oplossingen. Normaal gesproken moet de planning betrekking hebben op de volgende gebieden.

• Naleving: Zorg ervoor dat alle nalevingscriteria die zijn geïdentificeerd in het verzamelen van vereisten, worden aangepakt door specifieke acties. Wijs elk van deze acties toe aan specifieke personen en definieer duidelijk de levertijd.
• Beveiliging: Bepaal hoe verschillende lagen van oplossingstoegang worden beheerd en welke vereisten voor gegevensbeveiligingsregels er zijn. Controleer of de beveiliging van de oplossing meer of minder strikt is dan standaardinhoud in de tenant.
• Gegevensgateways: evalueer of de oplossing een gegevensgateway nodig heeft om verbinding te maken met gegevensbronnen. Bepaal of specifieke gatewayinstellingen of clusters met hoge beschikbaarheid nodig zijn. Plan wie gatewayverbindingen kan beheren via de gatewaybeveiligingsrollen en hoe u de gateways kunt bewaken. Zie Gatewaytoegang inrichten voor meer informatie.
• Werkruimten: Bepaal hoe u werkruimten instelt en gebruikt. Bepaal of de oplossing hulpprogramma's voor levenscyclusbeheer vereist, zoals Git-integratie - en implementatiepijplijnen, en of hiervoor geavanceerde logboekregistratie met Azure Log Analytics is vereist.
• Ondersteuning: Bepaal wie verantwoordelijk is voor het ondersteunen en onderhouden van de oplossing na de productie-implementatie. Als de personen die verantwoordelijk zijn voor ondersteuning anders zijn dan het projectteam, moeten deze personen in ontwikkeling zijn. Zorg ervoor dat degene die de oplossing ondersteunt het ontwerp van de oplossing begrijpt, welk probleem het moet oplossen, wie deze moet gebruiken en hoe.
• Gebruikerstraining: Verwacht de inspanningen die nodig zijn om de gebruikerscommunity te trainen, zodat ze de oplossing effectief kunnen gebruiken. Overweeg of er specifieke acties voor wijzigingsbeheer nodig zijn.
• Governance: identificeer mogelijke governancerisico's voor de oplossing. Houd rekening met de inspanningen die nodig zijn om gebruikers in staat te stellen de oplossing effectief te gebruiken, terwijl u eventuele governancerisico's beperkt (bijvoorbeeld door vertrouwelijkheidslabels en beleid te gebruiken).

Voer de eerste installatie uit

Het projectteam moet de eerste installatie uitvoeren om de ontwikkeling te starten. Initiële installatieactiviteiten kunnen het volgende omvatten:

• Initiële hulpprogramma's en processen: Voer de eerste installatie uit voor nieuwe hulpprogramma's en processen die nodig zijn voor ontwikkeling, testen en implementatie.
• Identiteiten en referenties: Maak beveiligingsgroepen en service-principals die worden gebruikt voor toegang tot hulpprogramma's en systemen. Sla de referenties effectief en veilig op.
• Gegevensgateways: Gegevensgateways implementeren voor on-premises gegevensbronnen (gateways in bedrijfsmodus) of gegevensbronnen in een particulier netwerk (virtueel netwerk of VNet, gateways).
• Werkruimten en opslagplaatsen: werkruimten en externe opslagplaatsen maken en instellen voor het publiceren en opslaan van inhoud.

Notitie

De implementatieplanning verschilt, afhankelijk van de oplossing en de werkstroom van uw voorkeur. In dit artikel worden alleen de plannings- en actie-items op hoog niveau beschreven.

Zie Implementatie plannen om te migreren naar Power BI voor meer informatie over de implementatieplanning.

Controlelijst : bij het plannen van de implementatie van oplossingen zijn belangrijke beslissingen en acties:

• Plan voor belangrijke gebieden: plan om de processen en hulpprogramma's aan te pakken die u nodig hebt om uw oplossing te ontwikkelen en te implementeren. Los zowel technische gebieden (zoals gegevensgateways of werkruimten) als acceptatie (zoals gebruikerstraining en governance) op.
• Voer de eerste installatie uit: stel de hulpprogramma's, processen en functies in die u nodig hebt om de oplossing te ontwikkelen en te implementeren. Documenteer de installatie om anderen te helpen die in de toekomst een eerste keer moeten instellen.
• Test gegevensbronverbindingen: Controleer of de juiste onderdelen en processen zijn ingesteld om verbinding te maken met de juiste gegevens om het concept te starten.

Stap 3: Een bewijs van concept uitvoeren

Het projectteam voert een oplossingstest van concept (POC) uit om uitstekende veronderstellingen te valideren en om vroege voordelen voor zakelijke gebruikers te demonstreren. Een POC is een eerste ontwerp-implementatie die beperkt is in het bereik en de volwassenheid. Een goed uitgevoerde POC is met name belangrijk voor grote of complexe oplossingen, omdat deze complexiteiten (of uitzonderingen) kan identificeren en aanpakken die niet zijn gedetecteerd in het technische ontwerp.

We raden u aan rekening te houden met de volgende overwegingen bij het voorbereiden van een POC.

• Doelstellingen en bereik: beschrijf het doel van de poC van de oplossing en de functionele gebieden die worden aangepakt. Het projectteam kan bijvoorbeeld besluiten om de POC te beperken tot één functioneel gebied of een specifieke set vereisten of functies.
• Brongegevens: bepaal welke gegevens worden gebruikt in de POC. Afhankelijk van de oplossing kan het projectteam besluiten om verschillende typen gegevens te gebruiken, zoals:
  • Productiegegevens (echte)
  • Voorbeeldgegevens
  • Gegenereerde synthetische gegevens die lijken op werkelijke gegevensvolumes en complexiteit waargenomen in productieomgevingen
• Demonstratie: Beschrijf hoe en wanneer het projectteam de POC aan belanghebbenden en gebruikers zal demonstreren. Demonstraties kunnen worden gegeven tijdens regelmatige updates of wanneer de POC voldoet aan specifieke functionele criteria.
• Omgeving: Beschrijf waar het projectteam de POC gaat bouwen. Een goede aanpak is het gebruik van een afzonderlijke sandbox-omgeving voor de POC en deze implementeren in een ontwikkelomgeving wanneer deze gereed is. Een sandbox-omgeving heeft flexibeler beleid en vloeiende inhoud en is gericht op het produceren van snelle resultaten. Een ontwikkelomgeving volgt daarentegen meer gestructureerde processen die samenwerking mogelijk maken en richt zich op het voltooien van specifieke taken.
• Succescriteria: definieer de drempelwaarde voor wanneer de POC succesvol is en moet overstappen op de volgende iteratie en formele ontwikkeling invoeren. Voordat de POC wordt gestart, moet het projectteam duidelijke criteria identificeren voor wanneer de POC succesvol is. Door deze criteria vooraf in te stellen, bepaalt het projectteam wanneer de POC-ontwikkeling eindigt en wanneer iteratieve ontwikkelings- en validatiecycli beginnen. Afhankelijk van de doelstellingen van de POC kan het projectteam verschillende succescriteria instellen, zoals:
  • Goedkeuring van de POC door belanghebbenden
  • Validatie van functies of functionaliteit
  • Gunstige beoordeling van de POC door peers na een vaste ontwikkeltijd
• Fout: zorg ervoor dat het projectteam fouten van de POC kan identificeren. Het identificeren van fouten die vroeg optreden, helpt bij het onderzoeken van de hoofdoorzaken. Het kan ook helpen om verdere investeringen in een oplossing te voorkomen die niet werkt zoals verwacht wanneer deze wordt geïmplementeerd in productie.

Let op

Wanneer het projectteam de POC uitvoert, moeten ze alert blijven op veronderstellingen en beperkingen. Het projectteam kan bijvoorbeeld de prestaties en gegevenskwaliteit van de oplossing niet eenvoudig testen met behulp van een kleine set gegevens. Zorg er bovendien voor dat het bereik en het doel van de POC duidelijk zijn voor de zakelijke gebruikers. Zorg ervoor dat de POC een eerste iteratie is en wees erop dat het geen productieoplossing is.

Notitie

Zie Proof of Concept voor meer informatie om te migreren naar Power BI.

Controlelijst : bij het maken van een POC zijn belangrijke beslissingen en acties:

• Definieer de doelstellingen: zorg ervoor dat de doelstellingen van de POC duidelijk zijn voor alle personen die betrokken zijn.
• Definieer het bereik van de POC: Zorg ervoor dat het maken van de POC niet te veel ontwikkelinspanningen kost, terwijl u nog steeds waarde levert en het oplossingsontwerp demonstreert.
• Bepaal welke gegevens er worden gebruikt: bepaal welke brongegevens u gebruikt om de POC te maken, uw beslissing te rechtvaardigen en de mogelijke risico's en beperkingen in kaart te brengen.
• Bepaal wanneer en hoe de POC moet worden gedemonstreerd: plan om de voortgang weer te geven door de POC aan besluitvormers en zakelijke gebruikers te presenteren.
• Verduidelijken wanneer de POC eindigt: Zorg ervoor dat het projectteam een duidelijke conclusie voor de POC besluit en beschrijf hoe het wordt gepromoveerd tot formele ontwikkelingscycli.

Stap 4: Inhoud maken en valideren

Wanneer de POC is geslaagd, verschuift het projectteam van de POC naar het maken en valideren van inhoud. Het projectteam kan de BI-oplossing ontwikkelen met iteratieve ontwikkelings- en validatiecycli. Deze cycli bestaan uit iteratieve releases, waarbij het projectteam inhoud maakt in een ontwikkelomgeving en deze naar een testomgeving publiceert. Tijdens de ontwikkeling onboardt het projectteam de gebruikerscommunity geleidelijk aan in een testproces naar vroege (bèta) versies van de oplossing in de testomgeving.

Tip

Iteratieve levering moedigt vroege validatie en feedback aan die wijzigingsaanvragen kunnen beperken, de acceptatie van oplossingen kunnen bevorderen en voordelen kunnen realiseren vóór de productierelease.

Iteratieve ontwikkelings- en validatiecycli gaan door totdat het projectteam tot een vooraf gedefinieerde conclusie komt. Normaal gesproken eindigt de ontwikkeling wanneer er geen functies meer zijn om te implementeren of feedback van gebruikers om aan te pakken. Wanneer de ontwikkelings- en validatiecycli eindigen, implementeert het projectteam de inhoud in een productieomgeving met de definitieve productierelease.

In het volgende diagram ziet u hoe het projectteam BI-oplossingen iteratief kan leveren met ontwikkelings- en validatiecycli.

In het diagram ziet u de volgende stappen.

Artikel	Beschrijving
	Het projectteam communiceert elke release naar de gebruikerscommunity, waarin wijzigingen en nieuwe functies worden beschreven. In het ideale voorbeeld bevat communicatie een demonstratie van oplossingen en Q&A, zodat gebruikers begrijpen wat er nieuw is in de release en ze kunnen mondelinge feedback geven.
	Tijdens de validatie geven gebruikers feedback via een centraal hulpmiddel of formulier. Het projectteam moet regelmatig feedback bekijken om problemen op te lossen, aanvragen te accepteren of af te wijzen en toekomstige ontwikkelingsfasen te informeren.
	Het projectteam bewaakt het gebruik van de oplossing om te bevestigen dat gebruikers deze testen. Als er geen gebruik is, moet het projectteam contact opnemen met de gebruikerscommunity om de redenen te begrijpen waarom. Laag gebruik kan erop wijzen dat het projectteam verdere activerings- en wijzigingsbeheeracties moet uitvoeren.
	Het projectteam reageert onmiddellijk op feedback van gebruikers. Als het projectteam te lang duurt om feedback te verwerken, verliezen gebruikers mogelijk snel de motivatie om het te verstrekken.
	Het projectteam neemt geaccepteerde feedback op in de oplossingsplanning. Indien nodig beoordelen ze de planningsprioriteiten om taken te verduidelijken en delegeren voordat de volgende ontwikkelingsfase begint.
	Het projectteam gaat verder met de ontwikkeling van de oplossing voor de volgende release.
	Het projectteam doorloopt alle stappen totdat ze een vooraf gedefinieerde conclusie bereiken en de oplossing is klaar voor productie-implementatie.

In de volgende secties worden belangrijke overwegingen beschreven voor het gebruik van iteratieve ontwikkelings- en validatiecycli om BI-oplossingen te leveren.

Inhoud maken

Het projectteam ontwikkelt de oplossing door de normale ontwikkelwerkstroom te volgen. Ze moeten echter rekening houden met de volgende punten bij het maken van inhoud.

• Werk tijdens elke ontwikkelingscyclus documentatie bij om de oplossing te beschrijven.
• Sluit elke ontwikkelingscyclus af met een aankondiging aan de gebruikerscommunity. Aankondigingen moeten worden geplaatst in de gecentraliseerde portal en ze moeten korte beschrijvingen geven van wijzigingen en nieuwe functies in elke release.
• Overweeg bij elke release sessies te organiseren om wijzigingen en nieuwe functies voor de gebruikerscommunity te demonstreren en om mondelinge vragen te beantwoorden.
• Definiëren wanneer iteratieve ontwikkelings- en validatiecycli worden afgesloten. Zorg ervoor dat er een duidelijk proces is voor het implementeren van de oplossing in de productieomgeving, inclusief een overgang naar ondersteunings- en acceptatieactiviteiten.

Inhoud valideren

Elke iteratieve ontwikkelingscyclus moet worden afgesloten met inhoudsvalidatie. Voor BI-oplossingen zijn er meestal twee soorten validatie.

• Validatie van ontwikkelaars: oplossingstests worden uitgevoerd door makers en peers van inhoud. Het doel van ontwikkelaarsvalidatie is om alle kritieke en zichtbare problemen te identificeren en op te lossen voordat de oplossing beschikbaar wordt gesteld aan zakelijke gebruikers. Problemen kunnen betrekking hebben op gegevens correctheid, functionaliteit of de gebruikerservaring. In het ideale instantie wordt inhoud gevalideerd door een maker van inhoud die deze niet heeft ontwikkeld.
• Gebruikersvalidatie: Oplossingstests worden uitgevoerd door de gebruikerscommunity. Het doel van gebruikersvalidatie is om feedback te geven voor latere iteraties en om problemen te identificeren die niet zijn gevonden door ontwikkelaars. Formele gebruikersvalidatieperioden worden meestal gebruikersacceptatietests (UAT) genoemd.

Belangrijk

Zorg ervoor dat problemen met de kwaliteit van gegevens tijdens de validatie van ontwikkelaars (vóór UAT) worden opgelost. Deze problemen kunnen snel vertrouwen in de oplossing veroorzaken en kunnen de acceptatie op lange termijn schaden.

Tip

Overweeg bij het uitvoeren van gebruikersvalidatie af en toe korte oproepen met belangrijke gebruikers. Bekijk ze wanneer ze de oplossing gebruiken. Maak notities over wat ze moeilijk te gebruiken vinden of welke onderdelen van de oplossing niet werken zoals verwacht. Deze aanpak kan een effectieve manier zijn om feedback te verzamelen.

Houd rekening met de volgende overwegingen wanneer het projectteam inhoud valideert.

• Feedback van gebruikers aanmoedigen: vraag gebruikers bij elke release feedback te geven en laat zien hoe ze dit effectief kunnen doen. Overweeg regelmatig voorbeelden van feedback en aanvragen te delen die hebben geleid tot recente wijzigingen en nieuwe functies. Door voorbeelden te delen, demonstreert u dat feedback wordt bevestigd en gewaardeerd.
• Grotere aanvragen isoleren: voor sommige feedbackitems is meer moeite nodig om aan te pakken. Zorg ervoor dat het projectteam deze items kan identificeren en bespreek of ze worden geïmplementeerd of niet. Overweeg grotere aanvragen te documenteren om later tactische planningssessies te bespreken.
• Begin activiteiten voor wijzigingsbeheer: gebruikers trainen hoe ze de oplossing kunnen gebruiken. Zorg ervoor dat u extra moeite besteedt aan nieuwe processen, nieuwe gegevens en verschillende manieren van werken. Investeren in veranderingsbeheer heeft een positief rendement op de acceptatie van oplossingen op lange termijn.

Wanneer de oplossing een vooraf gedefinieerd niveau van volledigheid en volwassenheid bereikt, is het projectteam klaar om deze in productie te implementeren. Na de implementatie gaat het projectteam over van iteratieve levering naar ondersteuning en bewaking van de productieoplossing.

Notitie

Ontwikkeling en testen verschillen, afhankelijk van de oplossing en de werkstroom van uw voorkeur.

In dit artikel worden alleen plannings- en actie-items op hoog niveau beschreven. Zie Inhoud maken voor migratie naar Power BI voor meer informatie over iteratieve ontwikkelings- en testcycli.

Controlelijst : bij het maken en valideren van inhoud zijn belangrijke beslissingen en acties:

• Gebruik een iteratief proces om taken te plannen en toe te wijzen: taken plannen en toewijzen voor elke release van de oplossing. Zorg ervoor dat het proces voor het plannen en toewijzen van taken flexibel is en gebruikersfeedback bevat.
• Beheer van de levenscyclus van inhoud instellen: hulpprogramma's en processen gebruiken om de implementatie en wijzigingsbeheer van oplossingen te stroomlijnen en automatiseren.
• Maak een hulpprogramma voor het centraliseren van feedback: Automatiseer het verzamelen van feedback met behulp van een oplossing die eenvoudig is voor u en uw gebruikers. Maak een eenvoudig formulier om ervoor te zorgen dat feedback beknopt en uitvoerbaar is.
• Plan een vergadering om feedback te bekijken: Vergaderen om elk nieuw of openstaand feedbackitem kort te bekijken. Bepaal of u de feedback implementeert of niet, wie verantwoordelijk is voor de implementatie en welke acties u moet ondernemen om het feedbackitem te sluiten.
• Bepaal wanneer iteratieve levering eindigt: Beschrijf de voorwaarden voor wanneer de iteratieve leveringscycli worden afgesloten en wanneer u inhoud vrijgeeft aan de productieomgeving.

Stap 5: Implementeren, ondersteunen en bewaken

Wanneer het projectteam klaar is, wordt de gevalideerde oplossing geïmplementeerd in de productieomgeving. Het projectteam moet belangrijke acceptatie- en ondersteuningsacties uitvoeren om ervoor te zorgen dat de implementatie is geslaagd.

Om een geslaagde implementatie te garanderen, voert u de volgende ondersteunings- en acceptatietaken uit.

• De definitieve release communiceren: de executive sponsor, een manager of een andere persoon met voldoende autoriteit en geloofwaardigheid moet de release aankondigen voor de gebruikerscommunity. Communicatie moet duidelijk, beknopt zijn en koppelingen naar de relevante oplossingen en ondersteuningskanalen bevatten.
• Training uitvoeren voor gebruikers van inhoud: Training moet beschikbaar zijn voor inhoudsconsumenten gedurende de eerste weken na de release naar productie. Training moet zich richten op het verduidelijken van het bereik van de oplossing, het beantwoorden van gebruikersvragen en het uitleggen hoe de oplossing moet worden gebruikt.
• Feedback en aanvragen afhandelen: Overweeg gebruikers een kanaal te bieden om feedback en aanvragen naar het projectteam te verzenden. Zorg ervoor dat redelijke feedback en aanvragen worden besproken en, indien van toepassing, geïmplementeerd tijdens de ondersteuningsperiode na de implementatie. Reageren op feedback en aanvragen na de productierelease is belangrijk. Het geeft een flexibele oplossing aan die reageert op veranderende bedrijfsbehoeften.
• Plan verbinding te maken met de gebruikerscommunity: Zelfs nadat de ondersteuningsperiode na de implementatie is beëindigd, moet u ervoor zorgen dat eigenaren van oplossingen regelmatig voldoen aan de gebruikerscommunity. Deze vergaderingen zijn waardevolle bronnen van feedback voor het herzien van uw BI-strategie. Ze helpen ook bij het ondersteunen van de acceptatie van oplossingen door gebruikers in te schakelen.
• Overdrachtsacties: Leden van het projectteam zijn mogelijk niet verantwoordelijk voor het onderhouden van de oplossing. In dit geval moet het team bepalen wie verantwoordelijk is en een handover uitvoeren. De overdracht moet kort na de release naar productie plaatsvinden en moet zowel de oplossing als de gebruikerscommunity aanpakken.

Let op

Het niet uitvoeren van een effectieve overdracht kan leiden tot voorkombare problemen met de ondersteuning en acceptatie van oplossingen tijdens de levenscyclus.

Na de implementatie moet het projectteam van plan zijn om door te gaan naar de volgende oplossing in de achterstall van de oplossing met prioriteit. Zorg ervoor dat u nieuwe feedback en aanvragen verzamelt en indien nodig wijzigingen aanbrengt in tactische planning, inclusief de achterstand van de oplossing.

Controlelijst : bij het overwegen van de implementatie van oplossingen zijn belangrijke beslissingen en acties:

• Maak een communicatieplan: Plan hoe u de release, training en andere ondersteunings- of acceptatieacties van de oplossing communiceert. Zorg ervoor dat eventuele storingen of problemen worden gecommuniceerd en onmiddellijk worden opgelost in de ondersteuningsperiode na de implementatie.
• Volg dit met een trainingsplan: Gebruikers trainen om de oplossing te gebruiken. Zorg ervoor dat de training zowel live- als opgenomen trainingssessies bevat gedurende enkele weken na de release.
• Handoveractiviteiten uitvoeren: Bereid indien nodig een handover van het ontwikkelingsteam voor aan het ondersteuningsteam.
• Houd kantooruren voor de oplossing: Na de ondersteuningsperiode na de implementatie kunt u normale kantoorurensessies houden om vragen te beantwoorden en feedback van gebruikers te verzamelen.
• Stel een proces voor continue verbetering in: Plan een maandelijkse controle van de oplossing om mogelijke wijzigingen of verbeteringen in de loop van de tijd te controleren. Centraliseer gebruikersfeedback en controleer regelmatig feedback tussen controles.

Gerelateerde inhoud

Zie de planning van de Power BI-implementatie voor meer overwegingen, acties, besluitvormingscriteria en aanbevelingen om u te helpen bij beslissingen over de implementatie van Power BI.