Sdílet prostřednictvím


Plánování implementace Power BI: Plánování řešení BI

Poznámka:

Tento článek je součástí řady článků o plánování implementace Power BI. Tato série se zaměřuje především na prostředí Power BI v Rámci Microsoft Fabric. Úvod do série najdete v tématu Plánování implementace Power BI.

Tento článek vám pomůže naplánovat řešení, která podporují strategii business intelligence (BI). Primárně se zaměřuje na:

  • Ředitelé bi a analýzy a manažeři: Rozhodovací pracovníci, kteří zodpovídají za dohled nad programem BI a strategicky důležitými řešeními BI.
  • Týmy CENTER OF Excellence (COE), IT a BI: Týmy, které navrhují a nasazují podniková řešení BI pro svou organizaci.
  • Odborníci na danou problematiku a vlastníci obsahu a tvůrci obsahu: Týmy a jednotlivci, kteří se zabývají analýzou v oddělení a navrhují a nasazují řešení pro samoobslužné , oddělení BI nebo scénáře používání týmových BI .

Strategie BI je plán implementace, používání a správy dat a analýz. Strategii BI definujete tak, že začnete se strategickým plánováním BI. Strategické plánování vám pomůže identifikovat oblasti a cíle zaměření BI. Pokud chcete určit cestu k dosažení cílů BI, popíšete konkrétní klíčové výsledky pomocí taktického plánování. K těmto klíčovým výsledkům pak dosáhnete tím, že plánujete a nasadíte řešení BI.

Poznámka:

V rámci cílů a klíčových výsledků (OKR) jsou cíle jasné a základní popisy toho, čeho chcete dosáhnout. Naproti tomu klíčové výsledky jsou specifické a dosažitelné výsledky k měření průběhu směrem k jednomu z vašich cílů.

Iniciativy nebo řešení jsou dále procesy nebo nástroje vytvořené tak, aby vám pomohly dosáhnout jednoho nebo více klíčových výsledků. Řešení řeší konkrétní potřeby dat pro uživatele. Řešení může mít mnoho forem, jako je datový kanál, datové jezero nebo sémantický model nebo sestavu Power BI.

Další informace o okrs najdete v tématu Seznámení s okrs (Microsoft Viva Goals).

Existuje mnoho přístupů k plánování a implementaci řešení BI. Tento článek popisuje jeden přístup, který můžete provést při plánování a implementaci řešení BI, která podporují vaši strategii BI.

Následující diagram vysoké úrovně znázorňuje, jak provádět plánování řešení BI.

Diagram znázorňuje přehled strategického, taktického a řešení plánování business intelligence. Plánování řešení je zvýrazněné. Podrobnosti o plánování řešení jsou popsány v následující tabulce.

Při plánování řešení BI provedete následující kroky.

Step Popis
1 Sestavte projektový tým, který shromažďuje požadavky a definuje návrh řešení.
2 Plánování nasazení řešení provedením počátečního nastavení nástrojů a procesů
3 Proveďte testování konceptu řešení (POC) a ověřte předpoklady týkající se návrhu.
4 Vytváření a ověřování obsahu pomocí iterativních vývojových a ověřovacích cyklů
5 Nasazení, podpora a monitorování řešení po jeho vydání do produkčního prostředí

Poznámka:

Plánování řešení BI se vztahuje jak na samoobslužné projekty BI , tak na podnikové projekty BI .

Další informace najdete v řadě migrace Power BI. I když se řada zabývá migrací, klíčové akce a aspekty jsou relevantní pro plánování řešení.

Krok 1: Shromáždění požadavků

Plánování řešení zahájíte tím, že nejprve shromáždíte požadavky a definujete návrh řešení.

Poznámka: Strategické a taktické plánování vede pracovní tým, který vede iniciativu. Naproti tomu plánování řešení vede projektový tým, který se skládá z vlastníků obsahu a tvůrců.

Diagram znázorňuje krok 1 v řadě pěti kroků pro iterativní poskytování hodnoty z plánování řešení BI. Krok 1 se týká shromažďování požadavků.

Shromažďování správných požadavků je nezbytné k dosažení úspěšného nasazení a přijetí řešení. Účinným způsobem, jak shromáždit požadavky, je identifikovat a zapojit správné zúčastněné strany, společně definovat problém, který se má vyřešit, a použít tento sdílený přehled problému k vytvoření návrhu řešení.

Tady jsou některé výhody použití přístupu pro spolupráci ke shromažďování požadavků.

  • Uživatelský vstup vytváří užitečnější návrhy: Zapojením uživatelů do diskuzí zaměřených na shromažďování požadavků můžete efektivněji zaznamenávat potřeby obchodních dat. Uživatelé mohou například ukázat tvůrcům obsahu, jak používají existující řešení, a poskytnout zpětnou vazbu o vnímané efektivitě těchto řešení.
  • Vyhněte se předpokladům a zmírnit žádosti o změnu: Diskuze s uživateli často odhalí drobné odlišnosti, výjimky a skryté složitosti. Tyto přehledy snižují pravděpodobnost požadavků v pozdní fázi, což může být nákladné pro řešení.
  • Onboarding uživatelů zvyšuje přijetí řešení: Zapojením uživatelů do návrhu a raného vývoje jim poskytnete příležitost ovlivnit konečný výsledek. Zapojení může také uživatelům poskytnout představu o duševním vlastnictví a odpovědnosti za řešení. Vysoce zapojení uživatelé budou s větší pravděpodobností doporučit řešení a vést svou komunitu praxe při jeho efektivním používání.
  • Návrhy nastavují očekávání pro zúčastněné strany a firemní uživatele: Vytvářením napodobení nebo ilustrací návrhu řešení můžete jasně ukázat zúčastněné strany, co bude řešení poskytovat. Pomáhá také vytvořením vzájemného porozumění očekávanému výsledku projektu. Tento proces se také označuje jako návrhové myšlení a může být efektivním způsobem, jak přistupovat ke složitým problémům a porozumět jim.

Pokud chcete zapojit uživatele a shromáždit požadavky, můžete použít různé přístupy. Můžete například shromáždit požadavky s obchodním návrhem a technickým návrhem (podrobně popsáno v dalších částech tohoto článku).

Obchodní návrh je přístup ke shromažďování obchodních požadavků. Zaměřuje se na zapojení podnikových uživatelů do relací obchodního návrhu, aby mohli řešení společně navrhovat. Výstupem obchodního návrhu je napodobení řešení a popisná dokumentace k návrhu.

Technický návrh je přístup k překladu obchodních požadavků na technické požadavky a k řešení předpokladů návrhu. Technický návrh se zaměřuje na ověřování obchodního návrhu a definování technického přístupu k použití. K ověření návrhu se tvůrci obsahu obvykle zabývají technickými odborníky v zaměřených diskusích, které se označují jako relace technického návrhu, pokud je to potřeba.

Důležité

Shromažďování nesprávných požadavků je běžným důvodem, proč implementace selžou. Týmy často shromažďují nesprávné požadavky, protože se zabývají nesprávnými zúčastněnými stranami, jako jsou pracovníci s rozhodovací pravomocí, kteří poskytují žádosti o řešení, která mají být sestavena shora dolů.

Zapojení podnikových uživatelů pomocí přístupů založených na spolupráci, jako je firemní návrh, vám může pomoct shromáždit lepší požadavky. Lepší požadavky často vedou k efektivnějšímu vývoji a robustnějším řešením.

Poznámka:

Pro některé týmy je přijetí procesu shromažďování strukturovaných požadavků velkou změnou. Ujistěte se, že tuto změnu spravujete a že nenaruší plánování řešení. Doporučujeme najít způsoby, jak tyto přístupy přizpůsobit tak, aby odpovídaly způsobu, jakým váš tým funguje.

Příprava na plánování řešení

Nejprve byste se měli připravit na plánování řešení s ohledem na faktory popsané v následujících částech.

  • Určete, kdo bude provádět plánování řešení: V rámci taktického plánování BI vytvořil pracovní tým upřednostňovaný backlog řešení. Při plánování řešení zodpovídá projektový tým za návrh, vývoj a nasazení jednoho nebo více řešení z backlogu. Pro každé řešení v backlogu byste měli sestavit projektový tým, který bude zodpovědný za řešení. Kromě plánování řešení BI by měl projektový tým:
    • Definujte časové osy a milníky pro plánování řešení.
    • Identifikujte a zapojte správné zúčastněné strany pro shromažďování požadavků.
    • Nastavte centralizované umístění pro komunikaci, dokumentaci a plánování.
    • Zapojte účastníky, aby shromáždili požadavky.
    • Komunikujte a koordinujte se zúčastněnými stranami a obchodními uživateli.
    • Orchestrace iterativních vývojových a testovacích cyklů s firemními uživateli
    • Zdokumentujte řešení.
    • Připojte uživatele k řešení definováním a přijetím plánu školení.
    • Poskytněte podporu řešení po nasazení.
    • Vyřešte přiměřené žádosti uživatelů o změnu nebo aktualizaci řešení po nasazení.
    • V případě potřeby proveďte předání řešení po nasazení.
  • Centralizovaná komunikace a dokumentace: Je důležité, aby projektový tým centralizuje komunikaci a dokumentaci pro plánování řešení BI. Projektový tým by měl například centralizovat požadavky, komunikaci účastníků, časové osy a dodávky. Zvažte uložení veškeré dokumentace na centralizovaný portál.
  • Shromažďování požadavků na plánování: Projektový tým by měl začít plánováním relací obchodního návrhu za účelem shromáždění obchodních požadavků. Tyto relace mají podobu interaktivních schůzek a mohou sledovat podobný formát jako semináře o strategickém plánování.

Tip

Zvažte identifikaci a zapojení týmů podpory zodpovědných za řešení v rané fázi procesu shromažďování požadavků. K efektivní podpoře řešení budou týmy podpory potřebovat komplexní porozumění řešení, jeho účelu a uživatelům. To je zvlášť důležité, když se projektový tým skládá jenom z externích konzultantů.

Shromáždění obchodních požadavků

Pro návrh správného řešení je důležité shromáždit správné obchodní požadavky. Aby bylo možné shromáždit správné požadavky a definovat efektivní návrh řešení, může projektový tým společně s firemními uživateli provádět relace obchodního návrhu.

Účelem obchodních relací návrhu je:

  • Potvrďte počáteční obor řešení.
  • Definujte a porozumíte problému, který by řešení mělo řešit.
  • Identifikujte správné klíčové zúčastněné strany pro řešení.
  • Shromážděte správné obchodní požadavky.
  • Připravte návrh řešení, který splňuje obchodní požadavky.
  • Příprava podpůrné dokumentace k návrhu

Následující diagram znázorňuje, jak shromáždit obchodní požadavky a definovat návrh řešení pomocí přístupu k návrhu firmy.

Diagram znázorňuje proces obchodního návrhu, který se týká shromažďování obchodních požadavků a definování řešení. Každý krok v procesu je popsaný v následující tabulce.

Diagram znázorňuje následující kroky.

Položka Popis
Položka 1. Projektový tým zahájí obchodní návrh potvrzením rozsahu řešení, který byl poprvé zdokumentován v taktickém plánování. Měly by objasnit obchodní oblasti, systémy a data, které řešení bude zahrnovat.
Položka 2. Projektový tým identifikuje klíčové účastníky z komunity uživatelů, kteří budou zapojeni do obchodních relací návrhu. Klíčovými zúčastněnými stranami jsou uživatelé s dostatečnými znalostmi a důvěryhodností, aby představovaly předměty řešení.
Položka 3. Projektový tým plánuje relace obchodního návrhu. Plánování zahrnuje informování zúčastněných stran, uspořádání schůzek, přípravu dodávek a zapojení podnikových uživatelů.
Položka 4. Projektový tým shromažďuje a zkoumá existující řešení, která podnikoví uživatelé aktuálně používají k řešení stávajících potřeb obchodních dat. K urychlení tohoto procesu může projektový tým použít relevantní výzkum ze strategického plánování BI, který byl zdokumentovaný v komunikačním centru.
Položka 5. Projektový tým provozuje relace obchodního návrhu se zúčastněnými stranami. Tyto relace jsou malé interaktivní schůzky, kde tým projektu provede účastníky, aby porozuměl potřebám a požadavkům obchodních dat.
Položka 6. Projektový tým uzavře obchodní návrh tím, že předloží návrh řešení zúčastněným stranám a dalším uživatelům za účelem zpětné vazby a schválení. Obchodní návrh je úspěšný, když účastníci souhlasí s tím, že jim návrh pomůže dosáhnout svých obchodních cílů.

Obchodní návrh končí následujícími dodávkami.

  • Návrhy řešení: Napodobení, prototypy nebo diagramy drátového modelu znázorňují návrh řešení. Tyto dokumenty překládají požadavky na konkrétní podrobný plán návrhu.
  • Seznam obchodních metrik: Kvantitativní pole očekávaná v řešení, včetně obchodních definic a očekávaných agregací Pokud je to možné, seřadí je podle důležitosti pro uživatele.
  • Seznamobchodníchch Pokud je to možné, zahrňte hierarchie a pořadí atributů podle důležitosti pro uživatele.
  • Doplňková dokumentace: Popis klíčových požadavků na funkčnost nebo dodržování předpisů Tato dokumentace by měla být co nejpřesnější, ale co nejpřesnější.

Dodávky obchodního návrhu se používají v technickém návrhu a ověřují je.

Tip

Diagramy modelů řešení, prototypů nebo diagramů drátových modelů můžou jasně porozumět očekávanému výsledku, a to jak pro vývojáře, tak pro koncové uživatele. Vytváření efektivních napodobení nevyžaduje umělecké dovednosti ani talent. K ilustraci návrhu můžete použít jednoduché nástroje, jako je Microsoft Whiteboard, PowerPoint nebo dokonce jen pero a papír.

Shromáždění technických požadavků

Po dokončení obchodního návrhu projektový tým ověří své výsledky pomocí technického návrhu. Technický návrh je přístup podobný obchodnímu návrhu. I když se návrh firmy zaměřuje na potřeby obchodních dat, technický návrh se zaměřuje na technické aspekty řešení. Klíčovým výsledkem technického návrhu je plán řešení, který popisuje konečný návrh řešení a informované odhady úsilí o jeho implementaci.

Poznámka:

Na rozdíl od obchodního návrhu je technický návrh z velké části nezávislým zkoumáním zdrojových dat a systémů, které provádějí tvůrci obsahu a vlastníci.

Účelem technického návrhu je:

  • Ověřte výsledky obchodního návrhu.
  • Řeší technické předpoklady v aktuálním návrhu.
  • Identifikujte relevantní zdroje dat v oboru a definujte výpočty polí a mapování zdrojů polí pro každý zdroj dat.
  • Přeložte obchodní požadavky na technické požadavky.
  • Vytváří odhad úsilí potřebného pro implementaci.

Projektový tým se zabývá technickými nebo funkčními účastníky v omezených a zaměřených relacích technického návrhu. Tyto relace jsou interaktivní schůzky s funkčními účastníky, které shromáždí technické požadavky. Zúčastněné strany zodpovídají za konkrétní funkční oblasti potřebné k tomu, aby řešení efektivně fungovalo.

Příklady zúčastněných stran v technickém návrhu mohou být:

  • Bezpečnostní a síťové týmy: Zodpovídá za zajištění zabezpečení a dodržování předpisů dat.
  • Funkční týmy a správci dat: Zodpovídá za kurátorování zdrojových dat.
  • Architekti: Vlastníci konkrétních platforem, nástrojů nebo technologií.

Projektový tým se zabývá zúčastněnými stranami v relacích technického návrhu, aby řešil technické aspekty řešení. Mezi technické aspekty patří:

  • Připojení ke zdroji dat: Podrobnosti o tom, jak se připojit ke zdrojům dat a jak je integrovat.
  • Sítě a brány dat: Podrobnosti o privátních sítích nebo místních zdrojích dat.
  • Mapování zdroje polí: Mapování dat obchodních metrik a atributů na pole zdroje dat.
  • Logika výpočtů: Překlad obchodních definic do technických výpočtů.
  • Technické funkce: Funkce nebo funkce potřebné k podpoře obchodních požadavků.

Tip

Projektový tým, který provedl návrh firmy, by měl také provádět technický návrh. Z praktických důvodů však mohou technické návrhy vést různé osoby. V tomto případě začněte technický návrh tím, že zkontrolujete výsledky obchodního návrhu.

V ideálním případě by jednotlivci, kteří vedou technický návrh, měli důkladně porozumět výsledkům a podnikovým uživatelům.

Následující diagram znázorňuje, jak pomocí technického návrhu přeložit obchodní požadavky na technické požadavky.

Diagram znázorňuje proces technického návrhu, který se týká ověřování a finalizace výsledků obchodního návrhu a překlad obchodních požadavků na technické požadavky. Každý krok v procesu je popsaný v následující tabulce.

Diagram znázorňuje následující kroky.

Položka Popis
Položka 1. Projektový tým zahájí technický návrh definováním rozsahu zdroje dat na základě výsledků obchodního návrhu. Obor zdroje dat deklaruje, která data jsou potřebná k sestavení řešení. Aby bylo možné identifikovat správné zdroje dat, projektový tým se poraďte s obchodními a funkčními msp.
Položka 2. Projektový tým identifikuje technické nebo funkční zúčastněné strany, které budou později zahrnovat do relací technického návrhu.
Položka 3. Projektový tým plánuje omezené a zaměřené relace s funkčními účastníky, které řeší technické aspekty řešení. Plánování zahrnuje informování zúčastněných stran, uspořádání schůzek a přípravu dodávek.
Položka 4. Projektový tým zkoumá technické požadavky. Výzkum zahrnuje definování výpočtů polí a mapování zdrojů dat a také řešení předpokladů obchodního návrhu pomocí technické analýzy a dokumentace.
Položka 5. V případě potřeby projektový tým zahrnuje zúčastněné strany v relacích technického návrhu. Relace se zaměřují na konkrétní technický aspekt řešení, jako jsou připojení zabezpečení nebo zdroje dat. V těchto relacích projektový tým shromažďuje kvalitativní zpětnou vazbu od zúčastněných stran a msp.
Položka 6. Projektový tým připraví svá zjištění pomocí plánu řešení, který prezentuje zúčastněným stranám a osobám s rozhodovací pravomocí. Plán je iterace a rozšíření výsledků obchodního návrhu, které zahrnují konečný návrh, odhady a další dodávky.
Položka 7. Technický návrh by měl končit konečnou schůzkou se zúčastněnými stranami a pracovníky s rozhodovací pravomocí, aby se rozhodli, jestli pokračovat nebo ne. Tato schůzka poskytuje konečnou příležitost k vyhodnocení plánování řešení před tím, než se prostředky zavázaly k vývoji řešení.

Poznámka:

Technický návrh může odhalit neočekávanou složitost, která by mohla znepřístupnit plánování řešení vzhledem k aktuální dostupnosti prostředků nebo připravenosti organizace. V takovém případě by se řešení mělo znovu vyhodnotit v následujícím taktickém plánování. V závislosti na naléhavosti potřeb obchodních dat může rozhodovací pracovník, jako je sponzor vedení, pokračovat v testování konceptu nebo pouze jednou částí plánovaného řešení.

Technický návrh končí plánem řešení, který se skládá z následujících dodávek.

  • Nástroje a technologie: Seznam příslušných technických nástrojů potřebných k implementaci řešení. Seznam obvykle obsahuje relevantní nové možnosti licence (jako je kapacita infrastruktury nebo Premium na uživatele), funkce a nástroje.
  • Definovaný seznam obchodních metrik: Výpočty a mapování zdrojů polí obchodních metrik pro všechny zdroje dat v oboru K vytvoření této dodávky používá projektový tým seznam obchodních metrik vytvořených v návrhu firmy.
  • Definovaný seznam obchodních atributů: Mapování zdrojů polí obchodních atributů pro všechny zdroje dat v oboru K vytvoření této dodávky používá projektový tým seznam obchodních atributů vytvořených v návrhu firmy.
  • Revidované návrhy: Revize návrhu řešení na základě změn obchodního návrhu nebo neplatných předpokladů. Revidované návrhy jsou aktualizované verze napodobených, prototypů nebo diagramů drátových modelů vytvořených v návrhu firmy. Pokud nejsou potřeba žádné revize, sdělte, že technický návrh ověří obchodní návrh.
  • Odhad úsilí: Odhad prostředků potřebných k vývoji, podpoře a údržbě řešení Odhad informuje konečné rozhodnutí o tom, zda pokračovat v implementaci řešení, nebo ne.

Důležité

Ujistěte se, že projektový tým informuje zúčastněné strany o jakýchkoli změnách nebo neočekávaných zjištěních z technického návrhu. Tyto relace technického návrhu by stále měly zahrnovat relevantní firemní uživatele. Ujistěte se ale, že účastníci nejsou zbytečně vystaveni složitým technickým informacím.

Tip

Vzhledem k tomu, že obchodní cíle se neustále vyvíjejí, očekává se, že se požadavky změní. Nepředpokládáme, že jsou pevné požadavky na projekty BI. Pokud máte potíže s měnícími se požadavky, může to značit, že proces shromažďování požadavků není efektivní nebo že pracovní postupy vývoje dostatečně nezabírají běžnou zpětnou vazbu.

Kontrolní seznam – Při shromažďování požadavků, klíčových rozhodnutí a akcí patří:

  • Ujasněte si, kdo vlastní plánování řešení: Pro každé řešení zajistěte, aby byly pro projektový tým jasné role a zodpovědnosti.
  • Objasnění rozsahu řešení: Rozsah řešení by již měl být zdokumentován jako součást taktického plánování BI. Než začnete s plánováním řešení, možná budete muset věnovat více času a úsilí, abyste si tento rozsah objasnili.
  • Identifikace a informování zúčastněných stran: Identifikace zúčastněných stran pro obchodní návrhy a technické návrhy Informujte je předem o projektu a vysvětlete rozsah, cíle, požadované investice do času a dodávky z obchodního návrhu.
  • Plánování a vedení obchodních relací návrhu: Moderujte relace obchodního návrhu tak, aby se vyvolaly informace od zúčastněných stran a podnikových uživatelů. Požádejte uživatele, aby ukázali, jak používají existující řešení.
  • Dokumentovat obchodní metriky a atributy: Pomocí existujících řešení a vstupu od zúčastněných stran vytvořte seznam obchodních metrik a atributů. V technických návrzích namapujte pole na zdroj dat a popište logiku výpočtu pro kvantitativní pole.
  • Návrh řešení: Vytvořte iterativní napodobení na základě vstupu účastníka, který vizuálně odráží očekávaný výsledek řešení. Ujistěte se, že napodobení přesně reprezentují a řeší obchodní požadavky. Komunikujte firemním uživatelům, že během technického návrhu musí být i nadále ověřeny (a případně revidovány).
  • Vytvořte plán řešení: Zdrojová data zdrojů a relevantní technické aspekty, které zajistí, aby obchodní návrh byl dosažitelný. V případě potřeby popište klíčová rizika a hrozby návrhu a jakékoli alternativní přístupy. V případě potřeby připravte revizi návrhu řešení a proberte ji se zúčastněnými stranami.
  • Vytváření odhadů úsilí: V rámci konečného plánu řešení odhadněte úsilí o sestavení a podporu řešení. Tyto odhady ospravedlněte informacemi shromážděnými během obchodních relací návrhu a technického návrhu.
  • Rozhodněte se, jestli chcete pokračovat v plánu: Chcete-li dokončit proces shromažďování požadavků, předvádění konečného plánu zúčastněným stranám a osobám s rozhodovací pravomocí. Účelem této schůzky je určit, jestli pokračovat ve vývoji řešení.

Krok 2: Plánování nasazení

Jakmile projektový tým dokončí shromažďování požadavků, vytvoření plánu řešení a přijetí schválení, aby mohli pokračovat, je připravený naplánovat nasazení řešení.

Diagram znázorňuje krok 2 v řadě pěti kroků pro iterativní poskytování hodnoty z plánování řešení BI. Krok 2 se týká plánování nasazení.

Úlohy plánování nasazení se liší v závislosti na řešení, pracovním postupu vývoje a procesu nasazení. Plán nasazení obvykle souvisí s mnoha aktivitami zahrnujícími plánování a nastavení nástrojů a procesů pro řešení.

Plánování řešení klíčových oblastí

Projektový tým by měl plánovat klíčové oblasti nasazení řešení. Plánování by obvykle mělo řešit následující oblasti.

  • Dodržovánípředpisůch Přiřaďte každou z těchto akcí konkrétním lidem a jasně definujte časový rámec doručení.
  • Zabezpečení: Rozhodněte se, jak se budou spravovat různé vrstvy přístupu k řešení, a všechny požadavky na pravidlo zabezpečení dat. Zkontrolujte, jestli bude zabezpečení řešení více nebo méně přísné než standardní obsah v tenantovi.
  • Brány dat: Vyhodnoťte, jestli řešení potřebuje bránu dat pro připojení ke zdrojům dat. Určete, jestli jsou potřebná konkrétní nastavení brány nebo clustery s vysokou dostupností . Naplánujte, kdo bude moct spravovat připojení brány prostřednictvím rolí zabezpečení brány a jak monitorovat brány. Další informace najdete v tématu Zřízení přístupu k bráně.
  • Pracovní prostory: Rozhodněte se, jak nastavit a používat pracovní prostory. Určete, jestli řešení vyžaduje nástroje pro správu životního cyklu, jako je integrace Gitu a kanály nasazení, a jestli vyžaduje pokročilé protokolování pomocí Azure Log Analytics.
  • Podpora: Nastavte, kdo zodpovídá za podporu a údržbu řešení po produkčním nasazení. Pokud se jednotlivci odpovědní za podporu liší od projektového týmu, zapojte je do vývoje. Zajistěte, aby každý, kdo bude řešení podporovat, rozuměl návrhu řešení, měl by problém řešit, kdo by ho měl používat a jak.
  • Školení uživatelů: Předvídejte úsilí potřebné k trénování komunity uživatelů, aby mohli řešení efektivně používat. Zvažte, jestli jsou potřeba nějaké konkrétní akce správy změn.
  • Zásady správného řízení: Identifikujte potenciální rizika zásad správného řízení pro dané řešení. Předpovídejte úsilí potřebné k tomu, aby uživatelé mohli efektivně používat řešení a zároveň zmírněte rizika zásad správného řízení (například pomocí popisků citlivosti a zásad).

Provedení počátečního nastavení

Projektový tým by měl provést počáteční nastavení pro zahájení vývoje. Mezi počáteční aktivity nastavení patří:

  • Počáteční nástroje a procesy: Proveďte první nastavení pro všechny nové nástroje a procesy potřebné pro vývoj, testování a nasazení.
  • Identity a přihlašovací údaje: Vytvořte skupiny zabezpečení a instanční objekty, které se použijí pro přístup k nástrojům a systémům. Efektivně a bezpečně uložte přihlašovací údaje.
  • Brány dat: Nasaďte brány dat pro místní zdroje dat (brány v podnikovém režimu) nebo zdroje dat v privátní síti (virtuální síť nebo virtuální síť, brány).
  • Pracovní prostory a úložiště: Vytváření a nastavení pracovních prostorů a vzdálených úložišť pro publikování a ukládání obsahu.

Poznámka:

Plánování nasazení se liší v závislosti na řešení a preferovaném pracovním postupu. Tento článek popisuje pouze základní plánování a použitelné položky.

Další informace o plánování nasazení najdete v tématu Plánování nasazení pro migraci do Power BI.

Kontrolní seznam – Při plánování nasazení řešení patří klíčová rozhodnutí a akce:

  • Plánování klíčových oblastí: Naplánujte řešení procesů a nástrojů, které potřebujete k úspěšnému vývoji a nasazení řešení. Vyřešte obě technické oblasti (jako jsou brány dat nebo pracovní prostory) a také přijetí (jako je školení uživatelů a zásady správného řízení).
  • Provedení počátečního nastavení: Vytvořte nástroje, procesy a funkce, které potřebujete k vývoji a nasazení řešení. Zdokumentujte nastavení a pomozte ostatním, kteří budou muset v budoucnu provést první nastavení.
  • Test připojení ke zdroji dat: Ověřte, že jsou zavedeny příslušné komponenty a procesy pro připojení ke správným datům, aby bylo zahájeno testování konceptu.

Krok 3: Provedení testování konceptu

Projektový tým provádí testování konceptu řešení (POC) k ověření nevyřízených předpokladů a k předvedení počátečních výhod pro firemní uživatele. POC je počáteční implementace návrhu, která je omezená v rozsahu a vyspělosti. Dobře fungující POC je obzvláště důležitý pro rozsáhlá nebo složitá řešení, protože dokáže identifikovat a řešit složitosti (nebo výjimky), které nebyly zjištěny v technickém návrhu.

Diagram znázorňuje krok 3 v řadě pěti kroků pro iterativní poskytování hodnot z plánování řešení BI. Krok 3 se týká testování konceptu.

Při přípravě POC doporučujeme zvážit následující aspekty.

  • Cíle a rozsah: Popis účelu řešení POC a funkčních oblastí, které bude řešit. Projektový tým se například může rozhodnout omezit POC na jednu funkční oblast nebo konkrétní sadu požadavků nebo funkcí.
  • Zdrojová data: Určete, jaká data se použijí v POC. V závislosti na řešení se projektový tým může rozhodnout použít různé typy dat, například:
    • Produkční (reálná) data
    • Vzorová data
    • Vygenerovaná syntetická data, která se podobají skutečným objemům dat a složitosti pozorovaným v produkčních prostředích
  • Ukázka: Popište, jak a kdy projektový tým předvede POC zúčastněným stranám a uživatelům. Ukázky mohou být poskytnuty během pravidelných aktualizací nebo když POC splňuje konkrétní funkční kritéria.
  • Prostředí: Popište, kde projektový tým sestaví POC. Dobrým přístupem je použít pro POC jedinečné prostředí sandboxu a nasadit ho do vývojového prostředí, až bude připravené. Prostředí sandboxu má flexibilnější zásady a plynulý obsah a zaměřuje se na vytváření rychlých výsledků. Naproti tomu vývojové prostředí se řídí strukturovanějšími procesy, které umožňují spolupráci, a zaměřuje se na dokončení konkrétních úloh.
  • Kritéria úspěchu: Definujte prahovou hodnotu pro úspěšné provedení konceptu a měli byste přejít na další iteraci a vstoupit do formálního vývoje. Před zahájením poc by měl projektový tým identifikovat jasná kritéria pro úspěšné provedení konceptu. Nastavením těchtokritériích V závislosti na cílech POC může projektový tým nastavit různá kritéria úspěchu, například:
    • Schválení POC zúčastněnými stranami
    • Ověření funkcí nebo funkcí
    • Příznivá kontrola POC podle partnerských vztahů po pevném čase vývoje
  • Selhání: Ujistěte se, že projektový tým dokáže identifikovat selhání poc. Identifikace selhání v rané fázi pomůže prozkoumat původní příčiny. Může také pomoct vyhnout se dalším investicím do řešení, které nebude fungovat podle očekávání při nasazení do produkčního prostředí.

Upozornění

Když projektový tým provede poC, měl by zůstat upozorňující na předpoklady a omezení. Projektový tým například nemůže snadno testovat výkon řešení a kvalitu dat pomocí malé sady dat. Kromě toho se ujistěte, že rozsah a účel POC je pro firemní uživatele jasný. Nezapomeňte sdělit, že POC je první iterace a zdůrazňuje, že se nejedná o produkční řešení.

Poznámka:

Další informace najdete v tématu Testování konceptu migrace do Power BI.

Kontrolní seznam – Při vytváření POC patří klíčová rozhodnutí a akce:

  • Definujte cíle: Zajistěte, aby cíle POC byly jasné všem lidem, kteří se účastní.
  • Definujte rozsah POC: Ujistěte se, že vytvoření POC nebude trvat příliš mnoho úsilí o vývoj, ale stále poskytuje hodnotu a demonstruje návrh řešení.
  • Rozhodněte se, jaká data se použijí: Určete zdrojová data, která použijete k vytvoření poc, a odůvodněte své rozhodnutí a vystihovejte potenciální rizika a omezení.
  • Rozhodněte se, kdy a jak předvést POC: Plán ukázat pokrok tím, že předvedete POC rozhodovacím pravomocím a podnikovým uživatelům.
  • Vysvětlit, kdy poc skončí: Ujistěte se, že projektový tým rozhodne o jasném závěru poC, a popište, jak bude povýšen na formální vývojové cykly.

Krok 4: Vytvoření a ověření obsahu

Poc je úspěšné, projektový tým se přesune z POC na vytváření a ověřování obsahu. Projektový tým může vyvíjet řešení BI s iterativními vývojovými a ověřovacími cykly. Tyto cykly se skládají z iterativních verzí, kde projektový tým vytvoří obsah ve vývojovém prostředí a uvolní ho do testovacího prostředí. Během vývoje projektový tým postupně nasadí komunitu uživatelů v pilotním procesu na počáteční (beta) verze řešení v testovacím prostředí.

Diagram znázorňuje krok 4 v řadě pěti kroků pro iterativní poskytování hodnoty z plánování řešení BI. Krok 4 se týká vytváření a ověřování obsahu.

Tip

Iterativní doručování podporuje včasné ověření a zpětnou vazbu, které můžou zmírnit žádosti o změny, podporovat přijetí řešení a realizovat výhody před produkční verzí.

Iterativní vývojové a ověřovací cykly budou pokračovat, dokud tým projektu nedorazí na předdefinovaný závěr. Vývoj obvykle dospěl k závěru, že neexistují žádné další funkce pro implementaci zpětné vazby uživatelů nebo jejich zpětnou vazbu. Po dokončení cyklů vývoje a ověřování nasadí projektový tým obsah do produkčního prostředí s finální produkční verzí.

Následující diagram znázorňuje, jak může projektový tým iterativním způsobem dodávat řešení BI s vývojovými a ověřovacími cykly.

Diagram znázorňuje proces vývojového a ověřovacího cyklu, který se týká iterativního sestavování a testování řešení. Každý krok v procesu je popsaný v následující tabulce.

Diagram znázorňuje následující kroky.

Položka Popis
Položka 1. Projektový tým komunikuje s každou verzí komunitou uživatelů a popisuje změny a nové funkce. V ideálním případě komunikace zahrnuje ukázku řešení a Q&A, aby uživatelé pochopili, co je nového ve vydané verzi, a můžou poskytnout slovní zpětnou vazbu.
Položka 2. Během ověřování uživatelé poskytují zpětnou vazbu prostřednictvím centrálního nástroje nebo formuláře. Projektový tým by měl pravidelně kontrolovat zpětnou vazbu a řešit problémy, přijímat nebo odmítat žádosti a informovat nadcházející fáze vývoje.
Položka 3. Projektový tým monitoruje využití řešení, aby ověřil, že ho uživatelé testují. Pokud se žádné využití nepoužívá, tým projektu by se měl spojit s komunitou uživatelů, aby porozuměl důvodům, proč. Nízké využití může znamenat, že projektový tým musí provést další akce povolení a správy změn.
Položka 4. Projektový tým okamžitě odpoví na zpětnou vazbu uživatelů. Pokud projektový tým trvá příliš dlouhou dobu, než vyřeší zpětnou vazbu, můžou uživatelé rychle přijít o motivaci k poskytnutí.
Položka 5. Projektový tým zahrne do plánování řešení přijatou zpětnou vazbu. V případě potřeby kontrolují priority plánování, aby objasnili a delegovali úkoly před zahájením další fáze vývoje.
Položka 6. Projektový tým pokračuje ve vývoji řešení pro příští verzi.
Položka 7. Projektový tým iteruje všemi kroky, dokud nedosáhne předdefinovaného závěru a řešení je připravené pro produkční nasazení.

Následující části popisují klíčové aspekty použití iterativních vývojových a ověřovacích cyklů k poskytování řešení BI.

Vytvoření obsahu

Projektový tým vyvíjí řešení podle svého normálního vývojového pracovního postupu. Při vytváření obsahu by ale měli zvážit následující body.

  • Během každého vývojového cyklu aktualizujte dokumentaci, která popisuje řešení.
  • Ukončete každý vývojový cyklus oznámením komunity uživatelů. Oznámení by se měla publikovat na centralizovaném portálu a v každé verzi by měla obsahovat stručný popis změn a nových funkcí.
  • S každou verzí zvažte uspořádání relací, abyste ukázali změny a nové funkce komunity uživatelů a odpověděli na jakékoli slovní otázky.
  • Definujte, kdy budou ukončeny iterativní vývojové a ověřovací cykly. Ujistěte se, že existuje jasný proces nasazení řešení do produkčního prostředí, včetně přechodu na aktivity podpory a přijetí.

Ověření obsahu

Každý iterativní vývojový cyklus by měl být uzavřen s ověřováním obsahu. U řešení BI existují obvykle dva druhy ověřování.

  • Ověření vývojáře: Testování řešení provádí tvůrci obsahu a partnerské vztahy. Účelem ověření vývojáře je identifikovat a vyřešit všechny kritické a viditelné problémy před zpřístupněním řešení podnikovým uživatelům. Problémy se můžou týkat správnosti, funkčnosti nebo uživatelského prostředí dat. V ideálním případě je obsah ověřený tvůrcem obsahu, který ho nevytvořil.
  • Ověření uživatele: Testování řešení provádí komunita uživatelů. Účelem ověření uživatele je poskytnout zpětnou vazbu pro pozdější iterace a identifikovat problémy, které vývojáři nenašli. Formální ověřovací období uživatelů se obvykle označují jako uživatelské akceptační testování (UAT).

Důležité

Ujistěte se, že se všechny problémy s kvalitou dat řeší při ověřování vývojáře (před UAT). Tyto problémy mohou rychle erode důvěru v řešení a mohou poškodit dlouhodobé přijetí.

Tip

Při provádění ověřování uživatelů zvažte občasné krátké hovory s klíčovými uživateli. Sledujte je, když řešení používají. Vezměte si poznámky o tom, co se obtížně používají nebo jaké části řešení nefungují podle očekávání. Tento přístup může být efektivní způsob, jak shromáždit zpětnou vazbu.

Při ověřování obsahu projektový tým zvažte následující aspekty.

  • Povzbuďte zpětnou vazbu uživatelů: Při každé verzi požádejte uživatele o zpětnou vazbu a předveďte, jak to mohou efektivně udělat. Zvažte pravidelné sdílení příkladů zpětné vazby a požadavků, které vedly k nedávným změnám a novým funkcím. Sdílením příkladů demonstrujete, že zpětná vazba je potvrzená a hodnotná.
  • Izolace větších požadavků: Některé položky zpětné vazby vyžadují větší úsilí k vyřešení. Ujistěte se, že projektový tým může tyto položky identifikovat, a prodiskutovat, jestli budou implementovány, nebo ne. Zvažte zdokumentování větších požadavků, které je potřeba probrat v pozdějších taktických plánovacích relacích.
  • Zahájení aktivit správy změn: Natrénujte uživatele, jak řešení používat. Nezapomeňte věnovat větší úsilí novým procesům, novým datům a různým způsobům práce. Investice do správy změn má pozitivní návratnost dlouhodobého přijetí řešení.

Jakmile řešení dosáhne předdefinované úrovně úplnosti a vyspělosti, je projektový tým připravený ho nasadit do produkčního prostředí. Po nasazení projektový tým přejde z iterativního doručování na podporu a monitorování produkčního řešení.

Poznámka:

Vývoj a testování se liší v závislosti na řešení a preferovaném pracovním postupu.

Tento článek popisuje pouze základní plánování a použitelné položky. Další informace o iterativních cyklech vývoje a testování najdete v tématu Vytvoření obsahu pro migraci do Power BI.

Kontrolní seznam – Při vytváření a ověřování obsahu patří klíčová rozhodnutí a akce:

  • K plánování a přiřazování úkolů použijte iterativní proces: Naplánujte a přiřaďte úkoly pro každou verzi řešení. Ujistěte se, že proces plánování a přiřazování úkolů je flexibilní a zahrnuje zpětnou vazbu uživatelů.
  • Nastavení správy životního cyklu obsahu: Použití nástrojů a procesů ke zjednodušení a automatizaci nasazení řešení a správy změn
  • Vytvořte nástroj pro centralizovanou zpětnou vazbu: Automatizujte shromažďování názorů pomocí řešení, které je pro vás i vaše uživatele jednoduché. Vytvořte jednoduchý formulář, který zajistí, aby byla zpětná vazba ještě stručná.
  • Naplánujte schůzku, abyste mohli zkontrolovat zpětnou vazbu: Schůzka vám umožní krátce zkontrolovat každou novou nebo nevyřešenou položku zpětné vazby. Rozhodněte se, jestli budete implementovat zpětnou vazbu, kdo bude zodpovědný za implementaci a jaké akce se mají provést při zavření položky zpětné vazby.
  • Rozhodněte se, kdy iterativní doručení skončí: Popište podmínky, kdy budou ukončeny cykly iterativního doručování, a kdy uvolníte obsah do produkčního prostředí.

Krok 5: Nasazení, podpora a monitorování

Jakmile je projektový tým připravený, nasadí ověřené řešení do produkčního prostředí. Projektový tým by měl provést klíčové akce přijetí a podpory, aby se zajistilo, že nasazení bude úspěšné.

Diagram znázorňuje krok 5 v řadě pěti kroků pro iterativní poskytování hodnoty z plánování řešení BI. Krok 5 se týká nasazení, podpory a monitorování.

Abyste zajistili úspěšné nasazení, proveďte následující úlohy podpory a přijetí.

  • Sdělte konečné vydání: Vedoucí sponzor, manažer nebo jiná osoba s dostatečnou autoritou a důvěryhodností by měla oznámit vydání komunitě uživatelů. Komunikace by měla být jasná, stručná a měla by obsahovat odkazy na příslušná řešení a kanály podpory.
  • Trénování pro uživatele obsahu: Školení by mělo být dostupné pro uživatele obsahu během prvních týdnů po vydání do produkčního prostředí. Školení by se mělo zaměřit na objasnění rozsahu řešení, zodpovězení uživatelských otázek a vysvětlení způsobu použití řešení.
  • Vyřešte zpětnou vazbu a žádosti: Zvažte možnost poskytnout uživatelům kanál k odeslání zpětné vazby a žádostí týmu projektu. Zajistěte, aby byly probírané přiměřené zpětné vazby a žádosti a případně implementovány během období podpory po nasazení. Reakce na zpětnou vazbu a žádosti po vydání produkční verze je důležitá. Označuje agilní řešení, které reaguje na měnící se obchodní potřeby.
  • Naplánujte spojení s komunitou uživatelů: I po skončení období podpory po nasazení se ujistěte, že se vlastníci řešení pravidelně setkávají s komunitou uživatelů. Tyto schůzky jsou cennými zdroji zpětné vazby pro revizi strategie BI. Pomáhají také podporovat přijetí řešení povolením uživatelů.
  • Předání akcí: Členové projektového týmu nemusí být zodpovědní za údržbu řešení. V takovém případě by měl tým identifikovat, kdo je zodpovědný, a provést předání. Předání by mělo proběhnout brzy po vydání do produkčního prostředí a mělo by řešit řešení i komunitu uživatelů.

Upozornění

Neúspěšné provedení efektivního předání může vést k problémům s podporou řešení a přechodem během životního cyklu.

Po nasazení by měl projektový tým pokračovat k dalšímu řešení v backlogu řešení s prioritou. V případě potřeby se ujistěte, že shromažďujete všechny nové názory a žádosti a v případě potřeby provedete revize taktického plánování, včetně backlogu řešení.

Kontrolní seznam – Při zvažování nasazení řešení patří klíčová rozhodnutí a akce:

  • Vytvoření komunikačního plánu: Plánování komunikace s vydáním, školením a dalšími akcemi podpory nebo přijetí řešení Ujistěte se, že se všechny výpadky nebo problémy komunikují a okamžitě řeší v období podpory po nasazení.
  • Postupujte podle plánu školení: Vytrénujte uživatele, aby řešení používali. Ujistěte se, že trénování zahrnuje živé i zaznamenané trénovací relace po dobu několika týdnů po vydání.
  • Provádění aktivit předání: V případě potřeby připravte předání od vývojového týmu týmu podpory.
  • Vedení pracovní doby řešení: Po uplynutí doby podpory po nasazení zvažte pravidelné relace pracovní doby a odpovězte na otázky a shromážděte zpětnou vazbu od uživatelů.
  • Nastavení procesu průběžného zlepšování: Naplánujte měsíční audit řešení a zkontrolujte potenciální změny nebo vylepšení v průběhu času. Centralizace zpětné vazby uživatelů a pravidelná kontrola zpětné vazby mezi audity

Další aspekty, akce, rozhodovací kritéria a doporučení, které vám pomůžou při rozhodování o implementaci Power BI, najdete v tématu Plánování implementace Power BI.