Plánovanie implementácie služby Power BI: plánovanie riešení BI

Poznámka

Tento článok je súčasťou série článkov k plánovaniu implementácie služby Power BI. Táto séria sa zameriava predovšetkým na prostredie služby Power BI v rámci služby Microsoft Fabric. Úvod do série nájdete v téme Plánovanie implementácie služby Power BI.

Tento článok vám pomôže plánovať riešenia na podporu vašej stratégie Analytických nástrojov (BI). Zameriava sa predovšetkým na:

• Riaditelia alebo manažéri analýzy BI: osoby zodpovedné za dohľad nad programom BI a strategicky dôležité riešenia BI.
• Centrum excelentnosti (CE), IT a tímy BI: Tímy, ktoré navrhujú a nasadzujú podnikové riešenia BI pre svoju organizáciu.
• Odborníci na danú problematiku (MSP) a vlastníci a tvorcovia obsahu: Tímy a jednotlivci, ktorí presadzujú analýzu v oddelení a navrhujú a nasadzujú riešenia pre scenáre použitia samoobslužných služieb, analytických nástrojov jednotlivých oddelení alebo tímu BI .

Stratégia BI je plán implementácie, používania a spravovania údajov a analýz. Svoju stratégiu BI definujete tým, že začnete so strategickým plánovaním BI. Strategické plánovanie vám pomôže identifikovať oblasti a ciele v oblasti zamerania BI. Ak chcete určiť cestu k pokroku smerom k cieľom BI, môžete opísať konkrétne kľúčové výsledky pomocou taktického plánovania. Týmto kľúčovým výsledkom potom dosiahnete pokrok plánovaním a nasadením riešení BI.

Poznámka

V rámci cieľov a kľúčových výsledkov (OKR) sú ciele jasné a vysoko výkonné popisy toho, čo chcete dosiahnuť. Naopak, kľúčové výsledky sú špecifické a dosiahnuteľné výsledky na meranie pokroku smerom k jednému z vašich cieľov.

Iniciatívy alebo riešenia ďalej predstavujú procesy alebo nástroje, ktoré vám pomôžu dosiahnuť jeden alebo viac kľúčových výsledkov. Riešenia riešia konkrétne potreby údajov pre používateľov. Riešenie môže mať mnoho foriem, ako je napríklad kanál údajov, dátový lakehouse alebo sémantický model či zostava Power BI.

Ďalšie informácie o tlačidlách OKR nájdete v téme Spoznajte položky OKR (Microsoft Viva Goals).

Existuje mnoho prístupov k plánovanie a implementácii riešení BI. Tento článok popisuje jeden prístup, ktorý môžete využiť pri plánovaní a implementácii riešení BI na podporu vašej stratégie BI.

Nasledujúci diagram vysokej úrovne znázorňuje, ako vykonávať plánovanie riešenia BI.

Ak chcete vykonávať plánovanie riešení BI, vykonajte nasledujúce kroky.

Krok	Popis
1	Zostavte projektový tím, ktorý zhromažďuje požiadavky a definuje návrh riešenia.
2	Plánovanie nasadenia riešenia vykonaním počiatočného nastavenia nástrojov a procesov.
3	Vykonajte testovanie konceptu (POC) na overenie predpokladov týkajúcich sa návrhu.
4	Vytvárať a overovať obsah pomocou iteračných cyklov vývoja a overenia.
5	Nasadenie, podpora a monitorovanie riešenia po jeho vydaní do produkčného prostredia.

Poznámka

Plánovanie riešení BI sa vzťahuje na samoobslužné projekty BI aj podnikové projekty BI.

Ďalšie informácie nájdete v sérii o migrácii do služby Power BI. Hoci sa séria týka migrácie, kľúčové akcie a dôležité informácie sú relevantné pre plánovanie riešení.

Krok č. 1: Zhromažďovanie požiadaviek

Plánovanie riešenia začínate najskôr zhromažďovaním požiadaviek a definovaním návrhu riešenia.

Poznámka: Strategické a taktické plánovanie vedie pracovný tím, ktorý vedie iniciatívu. Naopak plánovanie riešení vedie projektový tím, ktorý sa skladá z vlastníkov obsahu a tvorcov.

Zhromažďovanie správnych požiadaviek je dôležité na dosiahnutie úspešného nasadenia a prijatia riešení. Účinným spôsobom zhromažďovania požiadaviek je identifikovať a zapojiť správne zainteresované strany, spolupracovať definovať problém, ktorý sa má vyriešiť, a využiť toto spoločné chápanie problému na vytvorenie návrhu riešenia.

Tu sú niektoré výhody z používania prístupu spolupráce na zhromažďovanie požiadaviek.

• Vstup používateľa prináša užitočnejšie návrhy: Zapojením používateľov do zameraných diskusií o zhromažďovaní požiadaviek môžete efektívnejšie zaznamenávať potreby obchodných údajov. Používatelia môžu napríklad tvorcom obsahu preukázať, ako používajú existujúce riešenia a poskytnúť spätnú väzbu o vnímanej účinnosti týchto riešení.
• Vyhnite sa predpokladom a zmierňujte žiadosti o zmeny: Diskusie s používateľmi často odhaľujú nuansy, výnimky a skryté komplikácie. Tieto prehľady znižujú pravdepodobnosť požiadaviek v neskorom štádiu, ktoré môžu byť nákladné na riešenie.
• Prijatie používateľov zvyšuje prijatie riešení: Tým, že zahrniete používateľov do návrhu a raného vývoja, poskytnete im možnosť ovplyvniť konečný výsledok. Zapojenie môže tiež poskytnúť používateľom pocit duševného vlastníctva a zodpovednosti za riešenie. Vysoko zapojení používatelia budú s väčšou pravdepodobnosťou podporovať riešenie a viesť svoju komunitu praxe pri jeho účinnom používaní.
• Návrhy nastavujú očakávania pre účastníkov projektu a podnikových používateľov: Vytvorením makety alebo ilustrácie návrhu riešenia môžete jasne ukázať zúčastneným stranám, čo riešenie prinesie. Pomáha to tiež vytvorením vzájomného porozumenia očakávanému výsledku projektu. Tento proces je tiež známy ako koncepcia návrhu a môže predstavovať účinný spôsob, ako pristupovať k zložitým problémom a pochopiť ich.

Ak chcete zapojiť používateľov a zhromažďovať požiadavky, môžete využiť rôzne prístupy. Môžete napríklad zhromaždiť požiadavky s obchodným dizajnom a technickým návrhom (podrobne popísané v ďalších častiach tohto článku).

Podnikový návrh je prístupom na zhromažďovanie obchodných požiadaviek. Zameriava sa na zapojenie podnikových používateľov do stretnutí o návrhu podniku s cieľom spolupráce navrhnúť riešenie. Výstupom podnikového návrhu je maketa riešenia a popisná dokumentácia k návrhu.

Technická koncepcia predstavuje prístup premietnuť obchodné požiadavky do technických požiadaviek a riešiť predpoklady týkajúce sa návrhu. Technický návrh sa zameriava na overenie podnikového návrhu a definovanie technického prístupu na používanie. Na overenie návrhu sa tvorcovia obsahu zvyčajne v prípade potreby zapájajú s technickými expertmi do cielených diskusií, ktoré sa nazývajú technické relácie návrhu.

Dôležité

Zhromažďovanie nesprávnych požiadaviek je bežným dôvodom zlyhania implementácií. Tímy často zhromažďujú nesprávne požiadavky, pretože sa zapájajú do nesprávnych účastníkov projektu, ako sú napríklad osoby s rozhodovacími právomocami, ktoré poskytujú žiadosti zhora nadol o riešenia, ktoré sa majú zostaviť.

Zapojenie podnikových používateľov pomocou prístupov spolupráce, ako je napríklad podnikový návrh, vám môže pomôcť zhromažďovať lepšie požiadavky. Lepšie požiadavky často vedú k efektívnejšiemu vývoju a robustnejším riešeniam.

Poznámka

Pre niektoré tímy je prijatie procesu zhromažďovania štruktúrovaných požiadaviek veľkou zmenou. Uistite sa, že túto zmenu spravujete a aby nenarušla plánovanie riešení. Odporúčame vám, aby ste našli spôsoby prispôsobenia týchto prístupov tak, aby vyhovovali spôsobu fungovania vášho tímu.

Príprava na plánovanie riešení

Najprv by ste sa mali pripraviť na plánovanie riešenia posúdením faktorov popísaných v nasledujúcich častiach.

• Identifikujte, kto bude vykonávať plánovanie riešení: V rámci taktického plánovania BI vytvoril pracovný tím prioritné nevybavené riešenia. Pri plánovaní riešení je projektový tím zodpovedný za navrhovanie, vývoj a nasadzovanie jedného alebo viacerých riešení z nevybavených. Pre každé riešenie v nevybavených by ste mali zostaviť projektový tím, ktorý bude zodpovedný za riešenie. Okrem spustenia plánovania riešenia BI by mal projektový tím:
  • Definovanie časových osí a medzníkov na plánovanie riešenia.
  • Identifikujte a zahrnujte správne zainteresované strany na zhromažďovanie požiadaviek.
  • Nastavte centralizované umiestnenie na komunikáciu, dokumentáciu a plánovanie.
  • Zapojenie zainteresovaných strán na zhromažďovanie požiadaviek.
  • Komunikáciu a koordinovanie so zainteresovanými stranami a podnikovými používateľmi.
  • Koordinovať iteračné vývojové a testovacie cykly s podnikovými používateľmi.
  • Zdokumentovať riešenie.
  • Pridajte používateľov k riešeniu definovaním a uzákonením plánu školení.
  • Poskytovať podporu riešení po nasadení.
  • Riešte primerané požiadavky používateľov na zmenu alebo aktualizáciu riešenia po nasadení.
  • Vykonajte odovzdanie riešenia po nasadení, ak je to potrebné.
• Centralizácia komunikácie a dokumentácie: Je dôležité, aby projektový tím centralizoval komunikáciu a dokumentáciu pre plánovanie riešení BI. Projektový tím by mal napríklad centralizovať požiadavky, komunikáciu zainteresovaných strán, časové osi a doručenia. Zvážte uloženie celej dokumentácie na centralizovanom portáli.
• Zhromažďovanie požiadaviek na plán: Projektový tím by mal začať plánovaním relácií obchodného návrhu a získať tak obchodné požiadavky. Tieto relácie majú formu interaktívnych stretnutí a môžu postupovať v podobnom formáte ako workshopy strategického plánovania.

Tip

Zvážte identifikáciu a zapojenie tímov podpory zodpovedných za riešenie v počiatočnom štádiu procesu zhromažďovania požiadaviek. Na efektívnu podporu tohto riešenia budú tímy podpory potrebovať komplexné pochopenie riešenia, jeho účelu a používateľov. Je to obzvlášť dôležité vtedy, keď projektový tím pozostáva len z externých konzultantov.

Zhromažďovanie obchodných požiadaviek

Zhromažďovanie správnych obchodných požiadaviek je dôležité na vytvorenie správneho riešenia. Tím projektu môže spolu s podnikovými používateľmi zhromaždiť správne požiadavky a definovať efektívny návrh riešenia.

Cieľom relácií návrhu podniku je:

• Potvrdenie počiatočného rozsahu riešenia.
• Definujte a porozumejte problému, ktorý by malo riešenie riešiť.
• Identifikujte správne kľúčové zainteresované strany v rámci riešenia.
• Získajte správne obchodné požiadavky.
• Pripravte návrh riešenia, ktorý spĺňa obchodné požiadavky.
• Pripravte podpornú dokumentáciu k návrhu.

Nasledujúci diagram znázorňuje, ako zhromaždiť obchodné požiadavky a definovať návrh riešenia pomocou prístupu k obchodnému návrhu.

Diagram znázorňuje nasledujúce kroky.

Položka	Popis
	Projektový tím začína projektovaním firmy potvrdením rozsahu riešenia, ktoré bolo najprv zdokumentované v taktickom plánovaní. Mali by objasniť obchodné oblasti, systémy a údaje, ktoré riešenie zahrnuje.
	Projektový tím identifikuje kľúčové zainteresované strany z komunity používateľov, ktoré sa budú zúčastňovať na reláciách obchodných návrhov. Kľúčovými zainteresovanými stranami sú používatelia s dostatočnými znalosťami a dôveryhodnosťou, ktoré predstavujú oblasti riešenia.
	Projektový tím plánuje relácie obchodného návrhu. Plánovanie zahŕňa informovanie zainteresovaných strán, organizovanie stretnutí, prípravu dodávok a zapojenie sa s podnikovými používateľmi.
	Projektový tím zhromažďuje a skúma existujúce riešenia, ktoré podnikoví používatelia v súčasnosti používajú na riešenie existujúcich potrieb obchodných údajov. Na urýchlenie tohto procesu môže projektový tím využiť príslušný výskum zo strategického plánovania bi, ktorý bol zdokumentovaný v komunikačnom centre.
	Projektový tím vedie stretnutia o podnikových návrhoch so zainteresovanými stranami. Tieto relácie sú malé, interaktívne schôdze, kde projektový tím sprevádza účastníkov projektu v oblasti pochopenia potrieb a požiadaviek podnikových údajov.
	Projektový tím uzatvára obchodný návrh tak, že predloží návrh riešenia zúčastneným stranám a iným používateľom na spätnú väzbu a schválenie. Návrh podniku je úspešný, keď sa účastníci projektu dohodnú, že návrh im pomôže dosiahnuť svoje obchodné ciele.

Obchodný návrh sa končí nasledujúcimivodmi.

• Návrhy konceptov riešení: Mock-up, prototypy alebo wireframe diagramy ilustrujú návrh riešenia. Tieto dokumenty premietnu požiadavky na plán konkrétneho návrhu.
• Zoznam obchodných metrík: Kvantitatívne polia očakávané v riešení vrátane definícií podniku a očakávaných agregácií. Ak je to možné, zoraďte ich podľa dôležitosti pre používateľov.
• Zoznam podnikových atribútov: Relevantné atribúty a štruktúry údajov očakávané v riešení vrátane definícií podniku a názvov atribútov. Ak je to možné, zahrňte hierarchie a zoraďujte atribúty podľa dôležitosti pre používateľov.
• Doplnková dokumentácia: Popis kľúčových požiadaviek na funkčné alebo dodržiavanie súladu. Táto dokumentácia by mala byť čo najpresnejšia, no zároveň najvýstižnejšia.

Doručenia podnikového návrhu sú použité v technickom návrhu a overené ich.

Tip

Maketové diagramy riešenia, prototypy alebo diagramy drôtu dokážu jasne porozumieť očakávanému výsledku, a to tak pre vývojárov, ako aj pre koncových používateľov. Vytváranie efektívnych maketácií nevyžaduje umeleckú zručnosť ani talent. Na ilustráciu návrhu môžete použiť jednoduché nástroje, ako napríklad Microsoft Whiteboard, PowerPoint, alebo dokonca pero a papier.

Zhromažďovanie technických požiadaviek

Po dokončení obchodného návrhu projektový tím overí svoje výsledky pomocou technického návrhu. Ide o podobný prístup ako pri obchodnom návrhu. Hoci sa návrh podniku zameriava na potreby obchodných údajov, technický návrh sa zameriava na technické aspekty riešenia. Kľúčovým výsledkom technického návrhu je plán riešenia, ktorý opisuje konečný návrh riešenia a informované odhady úsilia v rámci jeho implementácie.

Poznámka

Na rozdiel od podnikového návrhu je technický návrh z veľkej časti nezávislým vyšetrovaním zdrojových údajov a systémov, ktoré vykonali tvorcovia a vlastníci obsahu.

Cieľom technického návrhu je:

• Overte výsledky podnikového návrhu.
• Riešiť technické predpoklady v aktuálnom návrhu.
• Identifikujte relevantné zdroje údajov v rozsahu a definujte výpočty polí a mapovania zdrojov polí pre jednotlivé zdroje údajov.
• Preložiť obchodné požiadavky do technických požiadaviek.
• Vyprodukovať odhady úsilia potrebného na implementáciu.

Projektový tím zapája technické alebo funkčné zainteresované strany do obmedzených, zameraných stretnutí o technickom návrhu. Tieto relácie sú interaktívnymi stretnutiami s funkčnými účastníkmi projektu na zhromažďovanie technických požiadaviek. Účastníci projektu sú zodpovední za konkrétne funkčné oblasti potrebné na efektívne fungovanie riešenia.

Príkladmi zainteresovaných strán v technickom návrhu by mohli byť:

• Tímy zabezpečenia a siete: Zodpovedné za zabezpečenie a dodržiavanie údajov.
• Funkčné tímy a správcovia údajov: zodpovední za vytvorenie zdrojových údajov.
• Architekti: vlastníci konkrétnych platforiem, nástrojov alebo technológií.

Projektový tím zapája účastníkov projektu do stretnutí o technickom návrhu s cieľom riešiť technické aspekty riešenia. Technické aspekty môžu zahŕňať:

• Pripojenia zdrojov údajov: Podrobnosti o tom, ako sa pripojiť k zdrojom údajov a ako ich integrovať.
• Siete a brány údajov: Podrobnosti o súkromných sieťach alebo lokálnych zdrojoch údajov.
• Priradenie zdroja poľa: Priradenia údajov obchodných metrík a atribútov k poliam zdroja údajov.
• Logika výpočtu: Preklad definícií podniku na technické výpočty.
• Technické funkcie: funkcie potrebné na podporu obchodných požiadaviek.

Tip

Projektový tím, ktorý vykonal obchodný návrh, by mal tiež vykonávať technický návrh. Z praktických dôvodov však môžu viesť k technickému návrhu rôzni jednotlivci. V tomto prípade začnite s technickým návrhom preskúmaním výsledkov obchodného návrhu.

V ideálnom prípade by jednotlivci, ktorí sú vedúcimi v technickom návrhu, mali dôkladne rozumieť výsledkom a podnikovým používateľom.

Nasledujúci diagram znázorňuje, ako premietnuť obchodné požiadavky do technických požiadaviek pomocou technického návrhu.

Diagram znázorňuje nasledujúce kroky.

Položka	Popis
	Projektový tím začína technickým návrhom definovaním rozsahu zdroja údajov na základe výsledkov obchodného návrhu. Rozsah zdroja údajov deklaruje, ktoré údaje sú potrebné na vytvorenie riešenia. Ak chcete identifikovať správne zdroje údajov, projektový tím sa poradí s podnikateľskými a funkčnými MSP.
	Projektový tím identifikuje technické alebo funkčné zainteresované strany, aby sa mohli neskôr zapojiť do stretnutí o technickom návrhu.
	Projektový tím plánuje obmedzené, cielené stretnutia s funkčnými zainteresovanými stranami s cieľom riešiť technické aspekty riešenia. Plánovanie zahŕňa informovanie zainteresovaných strán, organizovanie stretnutí a prípravu dodávok.
	Projektový tím skúma technické požiadavky. Výskum zahŕňa definovanie výpočtov polí a mapovania zdrojov údajov a tiež riešenie predpokladov návrhu podniku s technickou analýzou a dokumentáciou.
	Ak je to potrebné, projektový tím zahrňuje účastníkov projektu do stretnutí o technickom návrhu. Relácie sa zameriavajú na konkrétny technický aspekt riešenia, ako sú napríklad pripojenia zabezpečenia alebo zdroja údajov. Projektový tím v týchto reláciách zhromažďuje kvalitatívnu spätnú väzbu od zainteresovaných strán a MSP.
	Projektový tím pripravuje svoje zistenia s použitím plánu riešenia, ktorý predložia zainteresovaným stranám a subjektom s rozhodovacími právomocami. Tento plán predstavuje iteráciu a rozšírenie výsledkov obchodného návrhu, ktoré zahŕňajú konečný návrh, odhady a ďalšie výstupy.
	Technická koncepcia by sa mala ukončiť definitívnym stretnutím so zainteresovanými stranami a subjektmi, ktoré prijímajú rozhodnutia o tom, či budú pokračovať. Toto stretnutie poskytuje konečnú príležitosť na vyhodnotenie plánovania riešenia predtým, ako sú zdroje odhodlané na vývoj riešenia.

Poznámka

Technický návrh môže odhaliť neočakávanú zložitosť, pre ktorú by mohlo byť plánovanie riešenia nefunkčné vzhľadom na aktuálnu dostupnosť zdrojov alebo pripravenosť organizácie. V tomto prípade by sa toto riešenie malo opätovne vyhodnotiť v nasledujúcom taktickom plánovaní. V závislosti od naliehavosti potrieb obchodných údajov môže rozhodovací orgán, ako je výkonný sponzor, stále chcieť pokračovať v doklade koncepcie alebo len v jednej časti plánovaného riešenia.

Technická dokumentácia je záverom plánu riešenia, ktorý sa skladá z nasledujúcich plnení.

• Nástroje a technológie: Zoznam príslušných technických nástrojov potrebných na implementáciu riešenia. Zoznam zvyčajne obsahuje relevantné nové možnosti licencie (napríklad kapacita služby Fabric alebo Premium na používateľa), funkcie a nástroje.
• Definovaný zoznam obchodných metrík: Výpočty a priradenia zdrojov polí obchodných metrík pre všetky zdroje údajov v rozsahu. Na vytvorenie tohto poskytovania projektový tím použije zoznam obchodných metrík vytvorených v obchodnom návrhu.
• Definovaný zoznam podnikových atribútov: Priradenia zdroja poľa obchodných atribútov pre všetky zdroje údajov v rozsahu. Na vytvorenie tohto doručenia projektový tím použije zoznam podnikových atribútov vytvorených v obchodnom návrhu.
• Revidované návrhy: revízie návrhu riešenia na základe zmien v podnikovom návrhu alebo neplatných predpokladov týkajúcich sa návrhu podniku. Revidované návrhy sú aktualizované verzie makety, prototypov alebo diagramov drôtených prvkov vytvorených v podnikovom návrhu. Ak nie sú potrebné žiadne revízie, komunikujte, že technický návrh overí podnikový návrh.
• Odhad úsilia: Odhad zdrojov potrebných na vývoj, podporu a údržbu riešenia. Odhad informuje konečné rozhodnutie o tom, či pokračovať vo implementácii riešenia alebo nie.

Dôležité

Uistite sa, že projektový tím informuje účastníkov projektu o všetkých zmenách alebo neočakávaných zisteniach v technickom návrhu. Tieto relácie technického návrhu by mali stále zahŕňať príslušných podnikových používateľov. Zabezpečte však, aby účastníci projektu neboli zbytočne vystavení zložitým technickým informáciám.

Tip

Keďže obchodné ciele sa vždy vyvíjajú, očakáva sa, že požiadavky sa zmenia. Nepredpokladajte, že požiadavky na projekty BI sú pevne stanovené. Ak zápasíte s meniacimi sa požiadavkami, môže to naznačovať, že váš proces zhromažďovania požiadaviek nie je efektívny alebo že vaše pracovné postupy vývoja dostatočne nezahrňujú pravidelnú spätnú väzbu.

Kontrolný zoznam – pri zhromažďovaní požiadaviek, ku kľúčovým rozhodnutiam a akciám patria:

• Objasnite, kto vlastní plánovanie riešení: Pri každom riešení zabezpečte, aby boli roly a povinnosti pre projektový tím jasné.
• Objasnite rozsah riešenia: Rozsah riešenia by už mal byť zdokumentovaný ako súčasť taktického plánovania BI. Možno budete musieť vynaložiť ďalší čas a úsilie, aby ste objasnili rozsah ešte predtým, ako začnete plánovať riešenia.
• Identifikácia a informovať účastníkov projektu: Identifikácia účastníkov projektu v oblasti obchodných návrhov a technických návrhov. Vopred ich informujte o projekte a vysvetlite rozsah, ciele, požadované časové investície a výnosy z obchodného návrhu.
• Plánovanie a vykonávanie stretnutí o návrhu podniku: Moderovanie relácií obchodného návrhu s cieľom vyvolať informácie od zainteresovaných strán a podnikových používateľov. Požiadajte používateľov, aby im ukázali, ako používajú existujúce riešenia.
• Dokumentácia obchodných metrík a atribútov: Pomocou existujúcich riešení a vstupov od zainteresovaných strán vytvorte zoznam podnikových metrík a atribútov. V technických návrhoch priraďte polia k zdroju údajov a popíšte logiku výpočtu pre kvantitatívne polia.
• Návrh riešenia: Vytvorte iteračné mock-up na základe vstupu zainteresovaných strán, ktoré vizuálne odrážajú očakávaný výsledok riešenia. Uistite sa, že makety presne predstavujú a riešia obchodné požiadavky. Komunikujte podnikovým používateľom, že makety musia byť ešte overené (a prípadne revidované) počas technického návrhu.
• Vytvorenie plánu riešenia: Údaje zo zdroja výskumu a príslušné technické aspekty na zabezpečenie dosiahnuteľnosti podnikového návrhu. V prípade potreby opíšte kľúčové riziká a hrozby návrhu a všetky alternatívne prístupy. V prípade potreby pripravte revíziu návrhu riešenia a prediskutujte ho so zainteresovanými stranami.
• Vytvorenie odhadov úsilia: V rámci konečného plánu riešenia odhadnite úsilie na vytvorenie a podporu riešenia. Odôvodnite tieto odhady informáciami zhromaždenými počas stretnutí o obchodnom návrhu a technickom návrhu.
• Rozhodnite sa, či budete pokračovať v pláne: Ak chcete uzavrieť proces zhromažďovania požiadaviek, predložiť konečný plán zúčastneným stranám a tvorcom rozhodnutí. Cieľom tejto schôdze je určiť, či treba pokračovať vo vývoji riešení.

Krok č. 2: Plánovanie nasadenia

Keď projektový tím dokončí požiadavky na zhromažďovanie, vytvorí plán riešenia a získa schválenie, aby pokračoval, je pripravený na plánovanie nasadenia riešenia.

Úlohy plánovania nasadenia sa líšia v závislosti od riešenia, pracovného postupu vývoja a procesu nasadenia. Plán nasadenia sa zvyčajne týka mnohých aktivít zahŕňajúcich plánovanie a nastavenie nástrojov a procesov pre riešenie.

Plánovanie riešenia kľúčových oblastí

Projektový tím by mal plánovať kľúčové oblasti nasadenia riešení. Plánovanie by sa zvyčajne malo zaoberať nasledujúcimi oblasťami.

• Súlad: Zabezpečte, aby sa všetky kritériá dodržiavania súladu identifikované v zhromažďovaní požiadaviek vyriešili konkrétnymi akciami. Priraďte každú z týchto akcií konkrétnym ľuďom a jasne definujte časový rámec doručenia.
• Zabezpečenie: rozhodnite sa, ako sa budú spravovať rôzne vrstvy prístupu k riešeniu, a všetky požiadavky na zabezpečenie údajov. Skontrolujte, či bude zabezpečenie riešenia v nájomníkovi prísnejšie alebo menej prísne ako štandardný obsah.
• Brány údajov: Vyhodnotiť, či riešenie potrebuje bránu údajov na pripojenie k zdrojom údajov. Určte, či sú potrebné konkrétne nastavenia brány alebo klastre s vysokou dostupnosťou. Naplánujte, kto bude môcť spravovať pripojenia brány prostredníctvom rolí zabezpečenia brány a ako monitorovať brány. Ďalšie informácie nájdete v téme Zriadiť prístup k bráne.
• Pracovné priestory: Rozhodnite sa , ako nastaviť a používať pracovné priestory. Určite, či riešenie vyžaduje nástroje na správu životného cyklu, ako sú napríklad kanály integrácie a nasadenia systému Git, a či vyžaduje rozšírené zapisovanie do denníka pomocou služby Azure Log Analytics.
• Podpora: Zriadte zodpovedných používateľov za podporu a údržbu riešenia po nasadení produkcie. Ak sú jednotlivci zodpovední za podporu odlišní od projektového tímu, zapojiť týchto jednotlivcov do vývoja. Zabezpečte, aby ten, kto bude podporovať riešenie, rozumeje návrhu riešenia, problému, ktorému by sa malo riešiť, kto by ho mal používať a ako.
• Školenie používateľov: Očakávajte potrebné úsilie na trénovanie komunity používateľov, aby mohli efektívne používať riešenie. Zvážte, či sú potrebné nejaké konkrétne akcie spravovania zmien.
• Riadenie: Identifikujte potenciálne riziká riadenia pre riešenie. Predvídajte úsilie potrebné na to, aby používatelia mohli efektívne používať riešenie, a zároveň zmiernite akékoľvek riziko riadenia (napríklad pomocou označení citlivosti a politík).

Vykonať počiatočné nastavenie

Projektový tím by mal vykonať počiatočné nastavenie až do začatia vývoja. Počiatočné nastavenie aktivít môže zahŕňať:

• Počiatočné nástroje a procesy: Vykonajte prvé nastavenie všetkých nových nástrojov a procesov potrebných na vývoj, testovanie a nasadenie.
• Identity a poverenia: vytvorte skupiny zabezpečenia a objekty služby, ktoré sa použijú na prístup k nástrojom a systémom. Prihlasovacie údaje môžete efektívne a bezpečne ukladať.
• Brány údajov:Nasadenie brán údajov pre lokálne zdroje údajov (brány v podnikovom režime) alebo pre zdroje údajov v súkromnej sieti (virtuálna sieť alebo VNet, brány).
• Pracovné priestory a odkladacie priestory: Vytvárajte a nastavujte pracovné priestory a vzdialené odkladacie priestory na publikovanie a ukladanie obsahu.

Poznámka

Plánovanie nasadenia sa líši v závislosti od riešenia a preferovaného pracovného postupu. Tento článok sa týka len položiek plánovania a akcií, ktoré možno plánovať na vysokej úrovni.

Ďalšie informácie o plánovaní nasadenia nájdete v téme Plánovanie nasadenia na migráciu do služby Power BI.

Kontrolný zoznam – pri plánovaní nasadenia riešenia, ku kľúčovým rozhodnutiam a akciám patria:

• Plánovanie pre kľúčové oblasti: Plánujte riešenie procesov a nástrojov, ktoré potrebujete na úspešné vytvorenie a nasadenie riešenia. Zamerať sa na technické oblasti (ako sú napríklad brány údajov alebo pracovné priestory) a tiež osvojovať si (ako napríklad školenie používateľov a riadenie).
• Vykonať počiatočné nastavenie: vytvorte nástroje, procesy a funkcie, ktoré potrebujete na vývoj a nasadenie riešenia. Zdokumentovanie nastavenia tak, aby pomohlo ostatným, ktorí budú musieť v budúcnosti vykonať prvé nastavenie.
• Testovanie pripojení k zdrojom údajov: Overte, či sú na mieste vhodné komponenty a procesy na pripojenie k správnym údajom na začatie testovania konceptu.

Krok č. 3: Vykonanie testovania konceptu

Projektový tím vykonáva testovanie konceptu (POC) riešenia na overenie nevyriešeného predpokladu a na preukázanie počiatočných výhod pre podnikových používateľov. Koncept je počiatočná implementácia návrhu, ktorá je obmedzená rozsahom a splatnosťou. Dobre fungujúci testovanie konceptu je dôležité najmä pre veľké alebo komplexné riešenia, pretože dokáže identifikovať a riešiť komplikácie (alebo výnimky), ktoré neboli zistené v technickom návrhu.

Pri príprave testovania konceptu odporúčame zvážiť nasledujúce aspekty.

• Ciele a rozsah: Popíšte účel testovania konceptu riešenia a funkčné oblasti, ktoré bude riešiť. Projektový tím sa môže napríklad rozhodnúť obmedziť koncept na jednu funkčnú oblasť alebo konkrétnu množinu požiadaviek či funkcií.
• Zdrojové údaje: Identifikujte, ktoré údaje sa použijú v testovania konceptu. V závislosti od riešenia sa projektový tím môže rozhodnúť používať rôzne typy údajov, napríklad:
  • Produkčné (skutočné) údaje
  • Vzorové údaje
  • Generované syntetické údaje, ktoré sa podobajú na skutočné objemy údajov a zložitosť pozorovanú v produkčnom prostredí
• Ukážka: Popíšte, ako a kedy tím projektu predvedie testovania konceptu akcionárom a používateľom. Ukážky by sa mohli poskytnúť počas pravidelných aktualizácií alebo vtedy, keď testovania konceptu splní konkrétne funkčné kritériá.
• Prostredie: popíšte, kde bude tím projektu zostavovať testovania konceptu. Vhodným prístupom je použitie odlišného testovacieho prostredia ( sandbox ) pre testovania konceptu a jeho nasadenie do vývojového prostredia, keď bude pripravené. Testovacie prostredie (sandbox) obsahuje flexibilnejšie politiky a tekuté obsahy a je zamerané na vytváranie rýchlych výsledkov. Naopak vývojové prostredie sleduje štruktúrovanejšie procesy, ktoré umožňujú spoluprácu, a zameriava sa na plnenie konkrétnych úloh.
• Kritériá úspešnosti: Definujte prahovú hodnotu pre to, kedy je koncept úspešný, a mali by prejsť na ďalšiu iteráciu a zadať formálny vývoj. Pred začatím testovania konceptu by mal projektový tím identifikovať jasné kritériá pre úspešné spustenie testovania konceptu. Vopred nastavením týchto kritérií projektový tím definuje, kedy sa skončí vývoj testovania konceptu a kedy sa začnú iteračné cykly vývoja a overenia. V závislosti od cieľov testovania konceptu môže projektový tím nastaviť rôzne kritériá úspechu, ako napríklad:
  • Schválenie testovania konceptu zainteresovanými stranami
  • Overenie funkcií alebo funkcií
  • Priaznivé preskúmanie POC rovesníkmi po pevnom čase vývoja
• Zlyhanie: Skontrolujte, či tím projektu dokáže identifikovať zlyhanie testovania konceptu. Identifikácia zlyhania na začiatku pomôže preskúmať hlavné príčiny. Môže tiež pomôcť vyhnúť sa ďalším investíciám do riešenia, ktoré nebude fungovať podľa očakávania pri jeho nasadení do produkcie.

Výstraha

Keď projektový tím vykoná testovania konceptu, mal by zostať v upozornení na predpoklady a obmedzenia. Projektový tím napríklad nemôže jednoducho otestovať výkon a kvalitu údajov pomocou malej množiny údajov. Okrem toho sa uistite, že rozsah a účel testovania konceptu sú pre podnikových používateľov jasné. Nezabudnite oznámiť, že koncept je prvou iteráciou, a zdôrazniť, že to nie je produkčné riešenie.

Poznámka

Ďalšie informácie nájdete v téme Vykonanie testovania konceptu na migráciu do služby Power BI.

Kontrolný zoznam – pri vytváraní testovania konceptu sú tu kľúčové rozhodnutia a akcie:

• Definujte ciele: Uistite sa, že ciele testovania konceptu sú jasné pre všetkých zúčastnených ľudí.
• Definovanie rozsahu testovania konceptu: Uistite sa, že vytvorenie testovania konceptu nevyberie príliš veľa úsilia pri vývoji a zároveň poskytuje hodnotu a demonštruje návrh riešenia.
• Rozhodnite sa, ktoré údaje sa použijú: Identifikujte, ktoré zdrojové údaje použijete na vykonanie testovania konceptu, odôvodnite svoje rozhodnutie a zvýšte potenciálne riziká a obmedzenia.
• Rozhodnite sa, kedy a ako predviesť koncept: Plán na zobrazenie pokroku zobrazením testovania konceptu tvorcom rozhodnutí a podnikovým používateľom.
• Objasnite, kedy sa skončí testovania konceptu: Uistite sa, že projektový tím rozhodne o jasnom závere pre testovania konceptu a popíšte, ako sa bude propagovať na formálne vývojové cykly.

Krok č. 4: Vytvorenie a overenie obsahu

Po úspešnom dokončení testovania konceptu sa projektový tím presunie z testovania konceptu na vytváranie a overovanie obsahu. Projektový tím môže vyvíjať riešenie BI s iteračnými cyklami vývoja a overenia. Tieto cykly pozostávajú z opakovaných vydaní, v ktorých projektový tím vytvorí obsah vo vývojovom prostredí a uvoľní ho do testovacieho prostredia. Počas vývoja projektový tím postupne pridáva komunitu používateľov do pilotného procesu s cieľom skorej (beta) verzie riešenia v testovacom prostredí.

Tip

Iteračné doručovanie podporuje včasné overenie a spätnú väzbu, ktoré môžu zmierniť žiadosti o zmeny, podporovať prijatie riešení a realizovať výhody pred vydaním produkcie.

Iteračný vývojový a overovací cyklus pokračujú, kým projektový tím nedospeje k preddefinovanému záveru. Zvyčajne k vývoju dochádza k záveru, že neexistujú žiadne ďalšie funkcie na implementáciu alebo pripomienky používateľov, ktoré by bolo možné riešiť. Po skončení cyklov vývoja a overenia nasadí projektový tím obsah do produkčného prostredia s vydaním konečnej produkcie.

Nasledujúci diagram znázorňuje, ako môže projektový tím opakovane poskytovať riešenia BI s vývojovými a overovacími cyklymi.

Diagram znázorňuje nasledujúce kroky.

Položka	Popis
	Projektový tím komunikuje s komunitou používateľov každé vydanie, pričom popisuje zmeny a nové funkcie. V ideálnom prípade komunikácia obsahuje ukážku riešenia a funkciu Q&A, aby používatelia pochopili, čo je vo vydaní nové, a mohli poskytovať slovnú spätnú väzbu.
	Počas overovania používatelia poskytujú pripomienky prostredníctvom centrálneho nástroja alebo formulára. Projektový tím by mal pravidelne kontrolovať pripomienky s cieľom riešiť problémy, prijímať alebo zamietať žiadosti a informovať nadchádzajúce vývojové fázy.
	Projektový tím monitoruje použitie riešenia s cieľom potvrdiť, že používatelia ho testujú. Ak ju nepoužívate, projektový tím by sa mal spojiť s komunitou používateľov, aby porozumeli dôvodom, prečo. Nízke využitie môže naznačovať, že projektový tím musí vykonať ďalšie kroky povolenia a zmeny riadenia.
	Projektový tím okamžite reaguje na pripomienky používateľov. Ak tímu projektu trvá príliš dlho riešiť spätnú väzbu, používatelia môžu rýchlo stratiť motiváciu na jej poskytovanie.
	Projektový tím zahŕňa prijaté pripomienky do plánovania riešenia. V prípade potreby preskúmajú priority plánovania na objasnenie a delegovanie úloh pred začatím ďalšej fázy vývoja.
	Projektový tím pokračuje vo vývoji riešenia pre ďalšie vydanie.
	Projektový tím opakuje všetky kroky, kým nedospeje k preddefinovanému záveru a riešenie bude pripravené na nasadenie produkcie.

Nasledujúce časti popisujú kľúčové dôležité informácie týkajúce sa používania iteračných cyklov vývoja a overenia na poskytovanie riešení BI.

Vytvorenie obsahu

Projektový tím vyvíja riešenie podľa bežného pracovného postupu vývoja. Pri vytváraní obsahu by však mali vziať do úvahy nasledujúce body.

• Počas každého vývojového cyklu aktualizujte dokumentáciu s popisom riešenia.
• Ukonkujte každý vývojový cyklus oznámením pre komunitu používateľov. Oznámenia by mali byť uverejňované na centralizovanom portáli a mali by v každom vydaní poskytovať stručné popisy zmien a nových funkcií.
• V rámci každého vydania zvážte usporiadanie relácií na predvedenie zmien a nových funkcií pre komunitu používateľov a zodpovedanie akýchkoľvek slovných otázok.
• Definovať, kedy bude iteračný vývoj a validačné cykly uzatvárať. Uistite sa, že existuje jasný proces nasadenia riešenia do produkčného prostredia vrátane prechodu na podporu a aktivity adopcie.

Overenie obsahu

Každý iteračný vývojový cyklus by mal byť ukončený overením obsahu. V prípade riešení BI zvyčajne existujú dva druhy overenia.

• Overenie vývojármi: Testovanie riešení vykonávajú tvorcovia obsahu aj kolegovia. Cieľom overenia vývojára je identifikovať a vyriešiť všetky kritické a viditeľné problémy ešte predtým, ako sa riešenie sprístupní podnikovým používateľom. Problémy sa môžu týkať správnosti údajov, funkčnosti alebo používateľského prostredia. V ideálnom prípade obsah overí tvorca obsahu, ktorý ho nevyvinul.
• Overenie používateľa: Testovanie riešenia vykonáva komunita používateľov. Účelom overenia používateľa je poskytnúť pripomienky na neskoršie iterácie a identifikovať problémy, ktoré sa nenašli vývojármi. Obdobia formálneho overenia používateľa sa zvyčajne označujú ako testovanie prijatia používateľmi (UAT).

Dôležité

Skontrolujte, či sa počas overovania vývojárom (pred UAT) vyriešili všetky problémy s kvalitou údajov. Tieto problémy môžu rýchlo narušiť dôveru v riešenie a môžu poškodiť dlhodobé prijatie.

Tip

Pri vykonávaní overovania používateľa zvážte občasné a krátke volania s kľúčovými používateľmi. Pri používaní riešenia si ich pozrite. Poznamenajte si, čo sa pre ne zložito používa alebo ktoré časti riešenia nefungujú podľa očakávaní. Tento prístup môže predstavovať účinný spôsob zhromažďovania pripomienok.

Faktor s nasledujúcimi úvahami, kedy tím projektu overí obsah.

• Stimulujte pripomienky používateľov: Pri každom vydaní môžete požiadať používateľov o spätnú väzbu a ukázať, ako efektívne tak dokážu. Zvážte pravidelné zdieľanie príkladov pripomienok a požiadaviek, ktoré viedli k najnovším zmenám a novým funkciám. Zdieľaním príkladov preukazujete, že spätná väzba je uznaná a ocenená.
• Izolovanie väčších požiadaviek: Niektoré položky pripomienok si vyžadujú viac úsilia na riešenie. Uistite sa, že projektový tím dokáže tieto položky identifikovať a diskutovať o tom, či budú vykonané, alebo nie. Zvážte dokumentáciu väčších požiadaviek, aby ste mohli diskutovať v neskorších reláciách taktického plánovania .
• Začať meniť aktivity správy: Trénovať používateľov, ako používať riešenie. Nezabudnite vynaložiť maximálne úsilie na nové procesy, nové údaje a rôzne spôsoby práce. Investovanie do riadenia zmien má pozitívnu návratnosť dlhodobých riešení.

Keď riešenie dosiahne preddefinovanú úroveň úplnosti a splatnosti, projektový tím je pripravený ho nasadiť do produkcie. Po nasadení projektový tím prejde z iteračného doručovania na podporu a monitorovanie produkčného riešenia.

Poznámka

Vývoj a testovanie sa líšia v závislosti od riešenia a preferovaného pracovného postupu.

Tento článok popisuje iba položky plánovania a činností na vysokej úrovni. Ďalšie informácie o iteračných vývojových a testovacích cykloch nájdete v téme Vytvorenie obsahu na migráciu do služby Power BI.

Kontrolný zoznam – pri vytváraní a overovaní obsahu zahŕňajú kľúčové rozhodnutia a akcie:

• Iteračný proces použite na plánovanie a priradenie úloh: Plánovanie a priradenie úloh pre každé vydanie riešenia. Uistite sa, že proces naplánovania a priradenia úloh je flexibilný a zahŕňa pripomienky používateľov.
• Nastavenie spravovania životného cyklu obsahu: Pomocou nástrojov a procesov môžete zjednodušiť a automatizovať nasadenie a správu zmien riešení.
• Vytvorte nástroj na centralizovanie pripomienok: Automatizujte kolekciu pripomienok pomocou riešenia, ktoré je jednoduché pre vás a vašich používateľov. Vytvorte jednoduchý formulár, aby ste zaistili, že pripomienky budú výstižné a zároveň použiteľné.
• Naplánovanie schôdze na kontrolu spätnej väzby: Zoznámte sa, aby ste si nakrátko prečítali každú novú alebo vynikajúcu položku s pripomienkami. Rozhodnite sa, či budete implementovať pripomienky alebo nie, kto bude zodpovedný za implementáciu a aké akcie treba vykonať na uzavretie položky pripomienky.
• Rozhodnite sa pri uzatváraní iteratívneho doručovania: Popíšte podmienky, kedy sa budú uzatvárať iteračné cykly doručenia a kedy budete vydávať obsah do produkčného prostredia.

Krok č. 5: Nasadenie, podpora a monitorovanie

Keď bude projektový tím pripravený, nasadí overené riešenie do produkčného prostredia. Projektový tím by mal vykonať kľúčové kroky prijatia a podpory, aby sa zabezpečilo, že nasadenie bude úspešné.

Na zabezpečenie úspešného nasadenia vykonáte nasledujúce úlohy podpory a prijatia.

• Oznámenie konečného vydania: Výkonný sponzor, manažér alebo iná osoba s dostatočnou autoritou a dôveryhodnosťou by mal oznámiť vydanie komunite používateľov. Komunikácia by mala byť jasná, stručná a obsahovať prepojenia na príslušné riešenia a kanály podpory.
• Školenie pre spotrebiteľov obsahu: Školenie by malo byť k dispozícii pre spotrebiteľov obsahu počas prvých týždňov po vydaní do produkcie. Školenia by sa mali zamerať na objasnenie rozsahu riešenia, zodpovedanie otázok používateľov a vysvetlenie, ako používať riešenie.
• Riešenie pripomienok a žiadostí: Zvážte poskytnutie kanála používateľom na odoslanie pripomienok a žiadostí projektového tímu. Uistite sa, že sa rozoberá primeraná spätná väzba a žiadosti, a ak je to vhodné, realizujú sa počas obdobia podpory po nasadení. V prípade pripomienok a požiadaviek po vydaní produkcie je dôležité konať na základe pripomienok a požiadaviek. Označuje agilné riešenie, ktoré reaguje na meniace sa obchodné potreby.
• Plán pripojenia ku komunite používateľov: Aj po skončení obdobia podpory po nasadení sa vlastníci riešení pravidelne stretávajú s komunitou používateľov. Tieto stretnutia sú cennými zdrojmi pripomienok k revízii stratégie BI. Okrem toho pomáhajú podporovať prijatie riešení povolením pre používateľov.
• Akcie pri odovzdaní: Členovia projektového tímu nemusia byť zodpovední za udržiavanie riešenia. V tomto prípade by tím mal určiť, kto je zodpovedný a vykonať odovzdanie. K odovzdaniu by malo dôjsť krátko po vydaní do produkcie a malo by sa riešiť tak riešenie, ako aj komunita používateľov.

Výstraha

Zlyhanie účinného odovzdania môže viesť k problémom, ktorým sa dá predísť pri podpore a osvojení riešenia počas jeho životného cyklu.

Po nasadení by mal projektový tím naplánovať, aby pokračoval v ďalšom riešení v nevybavených prioritných riešeniach. Ubezpečte sa, že zhromažďujete všetky nové pripomienky a požiadavky a v prípade potreby vykonáte revízie taktického plánovania vrátane nevybavených riešení.

Kontrolný zoznam – pri zvažovaní nasadenia riešenia sú kľúčové rozhodnutia a akcie:

• Vytvorenie komunikačného plánu: Naplánujte si, ako oznámiť vydanie, školenia a iné akcie podpory alebo prijatia riešenia. Uistite sa, že v období podpory po nasadení boli všetky výpadky alebo problémy oznámené a okamžite riešené.
• Postupujte podľa plánu školení: Trénujte používateľov, aby mohli používať riešenie. Uistite sa, že súčasťou školenia sú živé aj nahraté školenia niekoľko týždňov po vydaní.
• Vykonávanie činností pri odovzdaní: V prípade potreby pripravte odovzdanie od vývojového tímu tímu technickej podpory.
• Vykonávanie úradných hodín riešenia: Po období podpory po nasadení zvážte organizovanie pravidelných relácií v úradných hodinách, aby ste mohli odpovedať na otázky a zhromažďovať pripomienky od používateľov.
• Nastavte proces priebežného zlepšovania: Naplánujte si mesačný audit riešenia na kontrolu možných zmien alebo vylepšení v priebehu času. Centralizujte pripomienky používateľov a pravidelne skúmajte pripomienky medzi auditmi.

Súvisiaci obsah

Ďalšie informácie, akcie, kritériá rozhodovania a odporúčania, ktoré vám pomôžu pri rozhodnutiach o implementácii služby Power BI, nájdete v téme Plánovanie implementácie služby Power BI.