Plánování implementace Power BI: Plánování a návrh obsahu

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 a navrhnout obsah v rámci správy životního cyklu obsahu. Primárně se zaměřuje na:

• Centrum excelence (COE) a týmy BI: Týmy zodpovědné za dohled nad Power BI v organizaci. Mezi tyto týmy patří rozhodovací pracovníci, kteří se rozhodnou, jak spravovat životní cyklus obsahu Power BI.
• tvůrci obsahu a vlastníci obsahu: Uživatelé, kteří vytvářejí obsah, který chtějí publikovat na portálu Fabric, aby ho mohli sdílet s ostatními. Tito jednotlivci zodpovídají za správu životního cyklu obsahu Power BI, který vytvářejí.

Správa životního cyklu se skládá z procesů a postupů, které používáte k řízení obsahu od jeho vytvoření až po jeho konečné vyřazení. Jak je popsáno v prvním článku této série, správa životního cyklu obsahu Power BI je důležitá k zajištění spolehlivého a konzistentního doručování obsahu podnikovým uživatelům.

První fází životního cyklu obsahu je plánování a návrh obsahu. Životní cyklus obsahu obvykle zahájíte plánováním řešení BI. Shromáždíte požadavky, abyste pochopili a definovali problém, který má řešení řešit, a dostali se k návrhu řešení. Během této fáze plánování a návrhu provedete klíčová rozhodnutí při přípravě na pozdější fáze.

Následující obrázek znázorňuje životní cyklus obsahu Power BI a zvýrazňuje fázi jedna, kde plánujete a navrhujete obsah.

Poznámka:

Přehled správy životního cyklu obsahu najdete v prvním článku v této sérii.

Návod

Tento článek se zaměřuje na klíčové aspekty a rozhodnutí týkající se plánování a návrhu obsahu v souvislosti se správou životního cyklu.

• Další informace o efektivním plánování a návrhu řešení Fabric nebo Power BI doporučujeme přečíst si článek o plánování řešení .
• Další informace o tom, jak efektivně naplánovat migraci Power BI, doporučujeme přečíst si řadu migrací Power BI .

Při shromažďování požadavků byste měli jasně popsat aspekty týkající se obsahu, které ovlivňují váš přístup k řízení životního cyklu. Tyto aspekty byste měli zdokumentovat jako součást plánování a návrhu řešení.

Následující části tohoto článku popisují klíčové aspekty a aspekty řešení, které motivují váš přístup ke správě životního cyklu při plánování a návrhu obsahu.

Identifikace a popis obsahu

Při návrhu řešení byste měli popsat, co je obsah, kdo ho vytvoří, kdo ho bude podporovat a jak důležitý je tento obsah pro organizaci. Tyto faktory byste měli řešit během nebo po dokončení shromažďování požadavků v rámci návrhu řešení.

Poznámka:

Stejně jako vaše požadavky se odpovědi na tyto otázky můžou při vývoji řešení nebo později v jeho životním cyklu změnit. Jakmile na tyto otázky odpovíte, připravte se na jejich pravidelné opakované vyhodnocení při provádění změn obsahu nebo při škálování v počtu uživatelů, které slouží.

Odpovězte na následující otázky týkající se obsahu, které vám pomůžou při rozhodování o pozdějším řízení životního cyklu.

Jaký je formát obsahu?

Typ, rozsah a složitost obsahu motivuje klíčová rozhodnutí o tom, jak ho budete spravovat. Jedna sestava pro omezenou cílovou skupinu například vyžaduje jiný přístup správy životního cyklu v porovnání s sémantickým modelem, který bude používat celá organizace a několik různých podřízených úloh.

Odpovězte na otázky podobné následujícímu, které vám pomůžou určit typ obsahu, který vytvoříte.

• Jaké typy položek očekáváte, že se vytvoří a kolik z nich? Budete například vytvářet datové položky, jako jsou datové toky nebo sémantické modely, sestavy, jako jsou zprávy nebo řídicí panely, nebo kombinaci obojího?
• Jak se obsah doručuje příjemcům obsahu? Budou například uživatelé používat datové položky k vytvoření vlastního obsahu, budou zobrazovat pouze centralizované sestavy nebo kombinaci obojího?
• Jak složitý je obsah? Jedná se například o malý prototyp nebo velký sémantický model, který zahrnuje více obchodních procesů?
• Očekáváte, že se rozsah, rozsah a složitost obsahu v průběhu času zvětšují? Bude například obsah zahrnovat další oblasti nebo obchodní oblasti v budoucnu?
• Jak dlouho očekáváte, že firma bude tento obsah potřebovat? Bude například tento obsah podporovat klíčovou iniciativu firmy, která má omezenou časovou osu?

Návod

Zvažte vytvoření diagramu architektury, který popisuje formát obsahu. Můžete zahrnout různé zdroje dat, typy položek a příjemce obsahu a vztahy mezi těmito diskrétními komponentami. Diagram architektury vám může pomoct stručně znázornit obsah a jeho složitost a pomůže vám naplánovat správu životního cyklu. Tyto diagramy můžete pomocí ikon Fabric a ikon Azure vytvářet v externím softwaru. Alternativně můžete použít diagramy Azure, které se dodává s ikonami a nástroji kreslení k vytváření těchto diagramů.

Příklad takových diagramů najdete v diagramech scénářů použití implementace Power BI.

Kdo bude obsah vytvářet a podporovat?

Tvůrci obsahu mají různé potřeby, dovednosti a pracovní postupy. Tyto faktory ovlivní úspěch různých přístupů správy životního cyklu. Větší a centrální týmy, které spolupracují, často vyžadují sofistikovanější správu životního cyklu obsahu než menší týmy samoobslužných tvůrců.

Odpovězte na otázky podobné následujícímu, které vám pomůžou určit, kdo bude obsah vytvářet nebo podporovat.

• Kolik různých jednotlivců očekáváte, že tento obsah vytvoří? Bude více tvůrců obsahu spolupracovat nebo je za vytváření obsahu zodpovědný jeden jednotlivec?
• Jsou tvůrci obsahu obeznámeni se správou životního cyklu a souvisejícími koncepty, jako je správa verzí? Rozumí tvůrci obsahu výhodám správy životního cyklu?
• Budou tvůrci obsahu, kteří vyvíjejí řešení, stejní jednotlivci, kteří ho po nasazení podporují?
• Mají tvůrci obsahu nebo jejich týmy stávající postupy správy životního cyklu pro podporu stávajících řešení?
• Používají tvůrci obsahu aktuálně nástroje pro správu životního cyklu, jako je Azure DevOps?

Důležité

Ujistěte se, že jasně zdokumentujete, kdo je zodpovědný za vytváření obsahu a kdo ho bude podporovat po nasazení do produkčního prostředí. Zapojte všechny tyto jednotlivce do plánování správy životního cyklu obsahu.

Jaký je význam obsahu?

V závislosti na tom, jak důležitý je obsah pro firmu, budete dělat různá rozhodnutí o tom, jak ho spravovat. Důležité obchodní informace vyžadují robustnější přístupy ke správě životního cyklu obsahu, které chrání kvalitu a snižují možné přerušení.

Odpovězte na otázky podobné následujícímu, které vám pomůžou určit, jestli je obsah kritický.

• Jak důležitý je tento obsah pro firmu? Jak urgentní je žádost o jeho vývoj?
• Budou z informací poskytovaných tímto obsahem učiněna důležitá obchodní rozhodnutí nebo akce?
• Jak široce očekáváte distribuci tohoto obsahu (od celé organizace do omezeného místního týmu)?
• Budou vedoucí pracovníci nebo jiní pracovníci s rozhodovací pravomocí spoléhat na tento obsah pro svou práci?
• Jaký je dopad tohoto obsahu? Pokud například obsah náhle není dostupný, jaké obchodní dopady by nastaly, například ztráty výnosů nebo přerušení obchodních procesů?

Pokud jste dostatečně identifikovali a popsali obsah, který vytvoříte, měli byste dále rozhodnout, jak by tvůrci obsahu měli spolupracovat.

Určení způsobu využívání obsahu uživateli

V Power BI existuje mnoho různých způsobů, jak můžou uživatelé využívat obsah, včetně sémantických modelů a sestav. V závislosti na tom, jak budou lidé přistupovat k tomuto obsahu a jak ho budou používat, budete muset učinit různá rozhodnutí o jejím návrhu a způsobu jeho vývoje. Některá z těchto rozhodnutí mohou výrazně změnit způsob vytváření obsahu a kolik času a úsilí to trvá. Obvykle platí, že čím více různých způsobů budou uživatelé používat vaše modely a sestavy, tím více aspektů si pamatujete a čím vyšší jsou výsledné náklady na vývoj.

Použití a opětovné použití sémantických modelů

Sémantické modely jsou v Power BI a Fabric diskutovatelně nejdůležitějšími typy položek, protože je uživatelé můžou využívat pomocí mnoha různých podřízených přístupů a položek. Pokud budete distribuovat jenom sestavy, budete dělat velmi odlišná rozhodnutí o návrhu, jako když uživatelé připojí různé položky k modelu, aby mohli provádět vlastní analýzy nebo dosahovat vlastních cílů.

Sdílený sémantický model můžete znovu použít pomocí následujících typů podřízených položek:

• Power BI

  • Zprávy
  • Stránkované sestavy
  • Přehledy výkonnostních metrik
  • Excel (analýza v kontingenčních tabulkách Aplikace Excel)
  • Sémantické modely (složené modely)

• Microsoft Fabric

  • Aktivátor (dříve Reflex)
  • Dovednosti umělé inteligence
  • Copilot
  • Zkoumání
  • Sady metrik
  • Poznámkové bloky (prostřednictvím Semantic Link a semantic-link-labs knihoven)

Následující části poskytují přehled důležitých aspektů při použití sémantických modelů s některými z těchto položek.

[! POZNÁMKA] Mnohé z těchto možností jsou dostupné pouze v případě, že povolíte příslušná nastavení tenanta. Ujistěte se, že se seznámíte s nastavením tenanta, abyste věděli, jaké metody spotřeby jsou v pracovním prostoru možné, kde publikujete sémantický model. Pokud jsou tyto možnosti omezené na konkrétní skupiny zabezpečení, ujistěte se, že do těchto skupin zabezpečení patří (nebo mají patřit) vaši uživatelé, nebo ne.

Zprávy

Uživatelé mohou pracovat se sémantickými modely pomocí sestav několika různými způsoby.

• Zobrazení sestav Standardní scénář, ve kterém uživatel zobrazuje data v sestavě, kterou distribuujete nebo sdílíte s nimi.
• Připojení k sémantickému modelu a vytvoření nové zprávy S oprávněními k sestavení můžou uživatelé vytvořit novou sestavu v Power BI Desktopu nebo ve službě Power BI. Tato zpráva má živé připojení ke sdílenému sémantickému modelu. Uživatelé mohou také převést živě propojenou sestavu na nový kompozitní sémantický model, který se dotazuje originálu pomocí DirectQuery.
• Vytvoření analýzy z existujícího zobrazení sestavy S oprávněními k sestavení můžou uživatelé také vybrat podporovaný vizuál a vytvořit průzkum svých dat. Tím se vytvoří nová položka průzkumu, která uživateli umožní přidat pole nebo změnit formátování. Uživatelé můžou uložit a sdílet výsledné zkoumání, pokud splňují požadovaná kritéria pro licencování, členství v pracovním prostoru a oprávnění k položce.
• Přizpůsobení vizuálů sestavy, ve kterých můžou uživatelé měnit pole a formátování.Přizpůsobení vizuálů funguje podobně jako při průzkumu, ale vyžaduje jenom oprávnění ke čtení a nevytvoří novou položku. Vizualizace se personalizují také na základě jakýchkoli perspektiv, které uživatel aplikuje na stránku sestavy, což omezuje dostupná pole, která může uživatel vidět a používat.

Tyto různé scénáře vytvářejí řadu aspektů, které je potřeba vzít v úvahu pro sémantické modely, například:

• Která oprávnění uživatelům udělíte a jak tato oprávnění budete spravovat. Doporučujeme, aby uživatelé před získáním oprávnění k sestavení dokončili školení.
• Zda přidáte perspektivy do svého modelu, nebo ne. Perspektivy můžete přidávat jenom pomocí zobrazení TMDL v Power BI Desktopu nebo pomocí jiných nástrojů třetích stran. Doporučujeme přidat perspektivy, když uživatelé budou používat přizpůsobené vizuály nebo složené modely.
• Která pole v modelu byste měli skrýt a zda potřebujete povolit vlastnost IsPrivate TOM tabulek, aby se předešlo jejich zobrazení jako návrhů u nich nebo jejich podřízených objektů. Vlastnost Private TOM lze nastavit pouze pomocí externích nástrojů v souboru metadat modelu (například .bim nebo .tmdl) nebo vzdáleného modelu publikovaného ve službě Power BI.
• Jak dokumentujete model a co by tato dokumentace měla zahrnovat. Doporučujeme vytvořit dokumentaci přizpůsobenou konkrétním případům použití a zahrnout relevantní a užitečné informace, a ne exportovat metadata modelu, jako jsou výrazy míry DAX, které nejsou obecně užitečné pro koncové uživatele.
• Jak doporučíte uživatelům, aby si zvolili jeden přístup za jiný.

[! UPOZORNĚNÍ] Jakmile udělíte oprávnění ke čtení nebo sestavení sémantickému modelu, můžou se uživatelé dotazovat na libovolnou tabulku nebo sloupec v modelu pomocí přístupů popsaných v této části. To platí i v případě, že tabulku, míru nebo sloupec v sestavě nezpřístupňujete. Zajistěte, abyste citlivá data vždy chránili pomocí zabezpečení dat nebo je vyloučili z modelu. Tímto způsobem se můžete vyhnout neúmyslnému zveřejnění citlivých informací nesprávným lidem.

Excel (analýza v kontingenčních tabulkách Aplikace Excel)

Pokud mají uživatelé oprávnění k sestavení modelu, můžou se také připojit k sémantickému modelu z Excelu a dotazovat se na něj pomocí jazyka MDX z kontingenční tabulky Excelu. To může být užitečné, když uživatelé raději pracují v Excelu, aby prozkoumali nebo analyzovali data sami.

Když uživatelé budou k dotazování sémantického modelu používat analýzu v Excelu, budete možná muset zvážit následující věci:

• Některé funkce, jako jsou parametry pole nebo měření řetězců dynamického formátu , fungují jenom v Power BI, a ne v Excelu. Pokud chcete dosáhnout podobného výsledku, musíte použít jiné přístupy.
• Funkce Analyzovat v aplikaci Excel vyžaduje, aby byla povolena vlastnost sloupce IsAvailableinMDX . Pokud uživatelé nebudou používat Excel, může zakázání této vlastnosti vést k menším a výkonnějším modelům.
• Uživatelé nemůžou zobrazit skryté sloupce nebo míry v sémantickém modelu, jako by mohli z Power BI Desktopu (kliknutím pravým tlačítkem myši na podokno dat a výběrem možnosti Zobrazit skryté).
• Uživatelé nemůžou v Excelu vytvářet vlastní míry ani vizuální výpočty , jako by mohli při použití živého připojení z Power BI Desktopu. Mohou ale odkazovat na pole kontingenční tabulky v jiných buňkách a listech Aplikace Excel pro vlastní výpočty.
• Uživatelé analýzy v Excelu často vyžadují další školení o tom, jak ho používat. To platí zejména v případě, že očekávají prostředí podobné exportu nebo vyjadřují záměr ukládat offline kopie dat. Zvažte školení uživatelů, například:
  • Jak aktualizovat data
  • Před přidáním polí do kontingenční tabulky vyfiltrujte data.
  • Vyhněte se velkým a podrobným dotazům bez filtrů.
  • Power BI Desktop bude výkonnější než Analyze in Excel, protože Analyze in Excel dotazuje model pomocí jazyka MDX, ale Power BI Desktop používá k dotazování modelu jazyk DAX.
  • Jak se vyhnout vytváření rizik správy nebo zabezpečení a přitom stále využívat Excel způsobem, který upřednostňují.

Kopilot a AI dovednosti

Pokud mají uživatelé oprávnění ke čtení modelu, můžou pomocí funkce Copilot zkoumat data a pokládat dotazy k nim pomocí přirozeného jazyka. Alternativně mohou také klást otázky o jejich datech ve funkci umělé inteligence, ale na rozdíl od Copilotu musíte tuto položku nejprve vytvořit a sdílet s nimi.

Když uživatelé chtějí pracovat s sémantickým modelem pomocí přirozeného jazyka, mají značné důsledky pro návrh a implementaci modelu:

• Lingvistické schéma: Do modelu budete muset přidat synonyma a relace, aby příslušná anglická slova a termíny byly přidružené ke správným objektům modelu.
• Konvence pojmenování: Budete muset používat anglické, AI přátelské konvence pojmenování. To znamená, že byste se měli vyhnout duplicitním nebo příliš podobným názvům polí, zkratkám, symbolům a zkratkám, i když jsou ve vaší organizaci standardní.
• Vlastnosti: Budete muset nastavit vlastnosti, jako jsou popisy sloupců nebo měr, kategorie dat a další, aby nástroje AI mohly tato pole lépe rozpoznat a používat.
• Skrytí polí: Budete muset skrýt pole, která nechcete zveřejnit pro Copilot nebo použít v odpovědích.

Musíte také věnovat další úsilí školení uživatelům:

• Jaké dovednosti copilotu nebo umělé inteligence můžou a nemůžou dělat.
• Kdy použít Copilot nebo AI dovednosti k prozkoumání dat oproti jinému (než AI) přístupu.
• Jak psát efektivní výzvy
• Jak ověřit výstupy
• Řešení potíží s neočekávanými výstupy

[! TIP] Další, podrobné tipy a důležité informace o optimalizaci modelů, aby dobře fungovaly s Copilotem, najdete v následujících článcích:

• Optimalizace pro autory sestav a uživatele modelu
• Aktualizace datového modelu tak, aby dobře fungoval s copilotem pro Power BI
• Psaní dotazů DAX pomocí Copilotu

Technologie Copilot a další generující AI mají důležitá omezení a důležité informace, kterým byste měli rozumět také ve fázi plánování a návrhu obsahu:

• Je to ne deterministické, což znamená, že stejný vstup ve stejném kontextu může vytvořit jiný výstup.
• Můžete získat nízké kvality nebo nepřesné výstupy, například když nástroj halucinuje nebo přepočítá důležitost určitých faktů. Copilot může být také nesprávný nebo nepřesný tím, že vynechá podstatné informace.
• Nástroje jsou omezené jejich trénovacími daty, takže dotazy týkající se více nových informací jsou méně pravděpodobné, že budou produkovat užitečné výstupy.

[! UPOZORNĚNÍ] Měli byste zmírnit rizika těchto omezení a aspektů. Technologie Copilot, dovednosti AI, velké jazykové modely a generativní AI jsou nově se rozvíjející technologie, takže byste je neměli používat pro autonomní, vysoce rizikové ani důležité obchodní procesy a rozhodovací činnost. Další informace najdete také v doprovodných materiálech zabezpečení pro velké jazykové modely.

Stránkované sestavy

Můžete napsat dotaz DAX pro sémantický model, který vytvoří stránkovanou sestavu s výsledkem dotazu. To je relevantní, pokud uživatelé vyžadují stránkované sestavy a vy máte v úmyslu použít sémantický model jako zdroj dat.

Při plánování vytváření stránkovaných sestav v sémantickém modelu možná budete muset zvážit následující body:

• Jak budete psát a udržovat dotazy DAX, například pomocí zobrazení dotazu DAX v Power BI Desktopu nebo jiných nástrojů třetích stran.
• Ať už potřebujete rozhodovat o návrhu, aby byla zajištěna výkonnost sémantického modelu při dotazování, například materializací určitých dat ve sloupci nebo v tabulce modelu.
• Ať už stránkované sestavy vložíte do interaktivních sestav Power BI, nebo ne pomocí vizuálu stránkované sestavy.
• Jak zajistíte, že mezi stránkovanými sestavami a jinými sestavami není redundance?
• V jakém formátu byste měli distribuovat stránkované sestavy a zda potřebujete popisky citlivosti nebo ochranu před únikem dat, aby se tyto výstupy nestaly rizikem pro správu nebo bezpečnost.

Ostatní

Existují také další způsoby, jak využívat sémantické modely. Tady je několik příkladů:

• Aktivátor (dříve Reflex): Sémantický model můžete použít k automatizaci upozornění na data a aktivaci podřízených toků, jako jsou ty, které vytvoříte pomocí Power Automate.
• Sady metrik: Můžete vytvořit sadu metrik, která zahrnuje míry a doporučené rozměry z více sémantických modelů na jednom místě. Sady metrik můžou uživatelům zlepšit zjišťování dat.
• Zkoumání: Kromě vytváření průzkumů ze sestav a výstupů Copilot mohou uživatelé také vytvářet průzkumy z sémantického modelu.

Distribuce a sdílení sestav

V závislosti na tom, jak budete sestavy Power BI distribuovat a sdílet , provedete různé volby návrhu. Například přechod mezi sestavami je funkce, která umožňuje uživatelům navigovat mezi sestavami ve stejném pracovním prostoru nebo aplikaci. Podrobnou analýzu napříč sestavami ale nemůžete použít, pokud vložíte sestavu nebo ji veřejně sdílíte pomocí funkce Publikovat na webu.

Další položky

V závislosti na tom, jak budou lidé používat váš obsah a podkladová data, budete možná muset přejít na jiné typy objektů v Power BI nebo Fabric. Pokud například uživatelé chtějí přidat vlastní data a výpočty, mohou používat složené modely se svým sémantickým modelem. Alternativně můžete pro ně vytvořit další centralizované datové položky, které budou využívat v nových modelech, jako je tok dat.

Jakmile určíte, jak budou uživatelé využívat obsah, který vytvoříte, měli byste dále rozhodnout, jak by tvůrci obsahu měli během vývoje spolupracovat.

Rozhodnutí o tom, jak by tvůrci obsahu měli spolupracovat

S rostoucím rozsahem a složitostí řešení může být nutné, aby ve spolupráci spolupracovalo více tvůrců obsahu a vlastníků. Při vytváření složitých řešení doporučujeme používat efektivní nástroje, které pomáhají strukturovat, spravovat a podporovat spolupráci. Při vytváření obsahu Power BI, například pomocí Microsoft Teams, Azure DevOps nebo GitHubu, můžete spolupracovat mnoha způsoby.

Návod

I když tvůrci obsahu pracují nezávisle, můžou i nadále těžit z plánování a strukturování práce pomocí nástrojů, jako jsou Microsoft Teams, Azure DevOps nebo GitHub. To je zvlášť důležité, když plánujete nasadit obsah, například pomocí aktualizace OneDrivu z knihovny dokumentů Microsoft Teams nebo integrace Gitu z úložiště Azure DevOps nebo GitHubu.

Microsoft Teams

V případě menších nebo jednodušších projektů můžou tvůrci obsahu spolupracovat pomocí Microsoft Teams.

Pomocí Microsoft Teams tvůrci obsahu strukturují komunikaci, plánování a práci v týmech a kanálech. Microsoft Teams je často dobrou volbou pro jednodušší scénáře spolupráce. Decentralizované týmy, které vytvářejí obsah pro omezenou cílovou skupinu, můžou například používat knihovny dokumentů k ukládání souborů a správy verzí. Mohou také využívat další integrované nástroje a služby.

Návod

Doporučujeme používat Microsoft Teams k usnadnění efektivní správy životního cyklu obsahu ve scénářích samoobslužných služeb s decentralizovaným doručováním obsahu.

Ke spolupráci a komunikaci v Microsoft Teams používáte podpůrné služby v průběhu životního cyklu obsahu Power BI.

• Planner: Vlastníci obsahu můžou Pomocí Planneru vytvářet plány, které používají ke sledování úkolů a určení rozsahu práce na obsahu. Úkoly můžou popisovat problémy, chyby nebo funkce v řešení a odpovídající zúčastněné strany.
• SharePoint: Tvůrci obsahu můžou ukládat a spravovat soubory v knihovně dokumentů Microsoft Teams nebo připojeném webu pro každý kanál. Soubory obsahu uložené v SharePointu můžou používat správu verzí ke sledování a správě změn obsahu. Další informace o sledování a správě změn pomocí SharePointu najdete v tématu Fáze 2: Vývoj obsahu a správa změn.
• Schválení: Tvůrci a vlastníci obsahu můžou po kontrole nastavit a používat pracovní postupy ke schválení změn nebo vydaných verzí obsahu.
• Fabric a Power BI: Tvůrci a vlastníci obsahu mají přístup k portálu Fabric v rámci Microsoft Teams. Odtud můžou spravovat nebo diskutovat o obsahu a přidávat užitečné zprávy na záložky v kanálech Teams.
• Další integrace: Tvůrci obsahu můžou využívat jiné služby Microsoftu nebo třetích stran, které se integrují s Microsoft Teams, aby co nejlépe vyhovovaly jejich preferovanému pracovnímu postupu a potřebám.

Doporučujeme definovat strukturovaný proces, jak by tvůrci obsahu měli používat Microsoft Teams ke spolupráci. Ujistěte se, že určíte:

• Jak spravovat přístup k týmům a kanálům
• Kdo zodpovídá za správu týmů a kanálů.
• Jak je práce vymezená a uspořádaná do různých týmů, kanálů a plánů.
• Jak by tvůrci obsahu měli používat knihovnu dokumentů k uspořádání souborů a sledování a správě změn. Jak například uspořádat knihovnu dokumentů a jestli by tvůrci obsahu měli soubory rezervovat a uvolňovat.
• Jestli tvůrci obsahu mají k automatickému publikování souborů Power BI Desktopu (.pbix) použít OneDrive Refresh .
• Jak se řeší konflikty synchronizace souborů.
• Kdy archivovat a odebírat soubory z knihovny dokumentů, které už nejsou relevantní.

Azure DevOps nebo GitHub Enterprise

Tvůrci a vlastníci obsahu můžou také komunikovat a spolupracovat v centrálním, uspořádaném centru pomocí Azure DevOps nebo GitHub Enterprise.

Poznámka:

Azure DevOps je sada služeb, které se integrují s Power BI a Fabric, aby vám pomohly plánovat a řídit správu životního cyklu obsahu. Při použití Azure DevOps tímto způsobem obvykle využíváte následující služby:

• Azure Repos: Umožňuje vytvářet a používat vzdálené úložiště Git, což je vzdálené umístění úložiště, které používáte ke sledování a správě změn obsahu.
• azure Pipelines: Umožňuje vytvářet a používat sadu automatizovaných úloh ke zpracování, testování a nasazování obsahu ze vzdáleného úložiště do pracovního prostoru.
• azure Test Plans: Umožňuje navrhovat testy k ověření řešení a automatizaci řízení kvality společně se službou Azure Pipelines.
• Azure Boards: Umožňuje používat panely ke sledování úkolů a plánů jako pracovních položek a odkazování na pracovní položky z jiných služeb Azure DevOps.
• Azure Wiki: Umožňuje sdílet informace se svým týmem, abyste porozuměli obsahu a přispěli k nim.

Tvůrci obsahu používají Azure DevOps nebo GitHub Enterprise ke strukturování komunikace, plánování a práce pomocí projektů. Tvůrci obsahu navíc můžou orchestrovat správu životního cyklu obsahu z Azure DevOps provedením správy zdrojového kódu, ověřením a nasazením. Správa zdrojového kódu je proces správy podrobnějších změn kódu obsahu a metadat.

Azure DevOps je často dobrou volbou pro pokročilejší scénáře spolupráce, protože existují podpůrné služby a možnosti orchestrace vytváření a nasazení obsahu.

Návod

Doporučujeme použít Azure DevOps k podpoře efektivní správy životního cyklu obsahu v podnikových scénářích s centralizovaným doručováním obsahu. Spolupráce pomocí Azure DevOps nebo podobných nástrojů se upřednostňuje ve větších nebo složitějších scénářích před spolupráci pomocí Microsoft Teams nebo SharePointu. Je to proto, že existuje více nástrojů a možností, které usnadňují robustnější spolupráci a automatizaci.

Doporučujeme definovat strukturovaný proces, jak by tvůrci obsahu měli používat Azure DevOps ke spolupráci. Ujistěte se, že určíte:

• Jak je práce vymezena a jak se vytvářejí, pojmenovávají a používají větve obsahu.
• Jak autoři seskupují změny, potvrzují je a popisují pomocí zpráv o potvrzení.
• Kdo zodpovídá za kontrolu a schvalování změn pomocí pull requestů
• Jak se řeší konflikty při slučování pull requestů a kdo je řeší.
• Jak by se změny provedené v různých větvích měly sloučit do jedné větve.
• Jak se obsah testuje a kdo provádí testování před nasazením obsahu.
• Jak a kdy se změny nasazují do vývojových, testovacích a produkčních pracovních prostorů.
• Jak a kdy lze vrátit zpět nasazené změny nebo verze řešení.

GitHub

Tvůrci a vlastníci obsahu můžou také komunikovat a spolupracovat pomocí GitHubu (jenom cloudové verze) a GitHubu Enterprise. Podobně jako Azure DevOps poskytuje GitHub platformu se službami, které můžete použít k orchestraci a správě aspektů prostředí Power BI nebo Fabric.

Hlavním rozdílem mezi Azure DevOps a GitHubem je, že zatímco Azure DevOps poskytuje sadu nástrojů pro správu životního cyklu vývoje softwaru, GitHub se zaměřuje hlavně na hostování úložišť Git, správy zdrojového kódu a spolupráce na kódu. GitHub používáte hlavně při plánování nasazení obsahu pomocí integrace Gitu. Kromě toho můžete pomocí GitHubu synchronizovat obsah z veřejného opensourcového úložiště do pracovního prostoru.

Pokud chcete používat integraci Gitu s GitHubem, musíte povolit nastavení tenanta správce Uživatelé mohou synchronizovat položky pracovního prostoru s úložišti GitHub.

Poznámka:

Microsoft Teams můžete také používat společně s Azure DevOps nebo GitHubem, protože existují různé způsoby integrace těchto služeb. Můžete například zobrazit a spravovat Azure Boards a monitorovat události v Azure Pipelines z Microsoft Teams.

Obsah můžete také plánovat a spolupracovat pomocí jiných nástrojů, které tu nejsou uvedené. Nejdůležitější je, že používáte nástroje a služby, které vám usnadňují spolupráci a které nejlépe vyhovují potřebám vašeho týmu a způsobu práce.

Až se rozhodnete, jestli a jak by tvůrci obsahu měli spolupracovat, měli byste se dále rozhodnout, kam soubory uložíte. Mnoho z těchto souborů se uloží tam, kde se rozhodnete spolupracovat.

Rozhodněte se, kam se mají ukládat soubory.

Při vytváření obsahu obvykle vytváříte různé typy souborů. Je důležité se rozhodnout, kam se mají tyto soubory ukládat, abyste je mohli efektivně spravovat.

Návod

Ukládejte soubory, ke kterým mají přístup více členů týmu a kde je možné snadno sledovat změny (označované jako správa verzí). Tento přístup zajišťuje, že odchod člena týmu nebo ztráta souboru nezpůsobí přerušení.

Mezi typy souborů, které budete muset často ukládat, patří:

• Soubory obsahu: Soubory, které obsahují data obsahu nebo metadata. Soubory obsahu s daty, jako jsou .pbix a soubory Power BI Projectu (.pbip), obsahují citlivé informace. Soubory obsahu můžete ukládat do zabezpečeného umístění přístupného jenom těm, kteří k nim potřebují přístup. Měli byste také ukládat soubory obsahu do umístění, které podporuje správu verzí, jako je knihovna dokumentů v Microsoft Teams nebo úložiště Git v Azure DevOps. Mezi příklady souborů obsahu patří:
  • Soubory z aplikace Power BI Desktop (.pbix)
  • Soubory Projectu Power BI (.pbip)
  • Soubory stránkované sestavy Power BI (.rdl)
  • Soubory metadat modelu (.bim nebo .tmdl)
  • Soubory metadat toku dat (.json)
• Soubory zdroje dat: Soubory, které jsou spotřebovány datovými položkami, jako jsou sémantické modely nebo toky dat. Obsah je přímo závislý na souborech zdroje dat, takže je důležité pečlivě zvážit, kde jsou uložené, protože jejich odebrání způsobí selhání aktualizace dat. Kromě toho mohou tyto soubory obsahovat citlivé informace. Proto ukládejte soubory zdroje dat do zabezpečeného, spolehlivého a důvěryhodného prostředí, které má omezený přístup jinými jednotlivci. Mezi příklady souborů zdroje dat může patřit:
  • Strukturované zdroje dat, jako jsou excelové sešity, soubory Parquet nebo CSV.
  • Částečně strukturované zdroje dat, jako jsou soubory JSON nebo XML.
  • Nestrukturované zdroje dat, jako jsou obrázky, které importujete do sestav.
• Podpůrné soubory: Soubory, které podporují vytváření nebo správu obsahu, ale nejsou pro jeho fungování potřeba. Podpůrné soubory by měly být uložené v umístění, které podporuje správu verzí a kde k nim mají přístup další nástroje a tvůrci obsahu. Mezi příklady podpůrných souborů patří:
  • Soubory motivu Power BI (.json).
  • Soubory obrázků (.png, .jpgnebo .gif) v sestavách Power BI.
  • Soubory pravidel analyzátoru osvědčených postupů (.json).
  • Soubory zdrojového kódu pro obsah a dotazy
  • Soubory vlastní vizualizace (.pbiviz).
• Šablony a dokumentace: Soubory, které pomáhají při vytváření samoobslužného obsahu nebo popisu existujícího obsahu. Šablony a dokumentace by měly být snadno přístupné lidem, kteří je potřebují používat. Mezi příklady šablon a dokumentace patří:
  • Soubory šablony Power BI (.pbit).
  • Šablony vizualizací a ukázkové reporty
  • Návrhy řešení a dokumentace
  • Plánování a plány řešení
  • Požadavky uživatelů a problémy s řešením

Upozornění

Některé soubory obsahu, jako jsou soubory .pbix a .pbip, můžou obsahovat citlivá data importovaná ze zdrojů dat. Soubory metadat mohou také obsahovat citlivé informace nebo v některých případech datové body. Příkladem je metadata sestavy a šablony .pbit, které můžou v určitých případech obsahovat hodnoty sloupců. Ujistěte se, že podniknete nezbytná opatření k uložení těchto souborů do zabezpečených umístění a že procvičíte efektivní ochranu před únikem informací.

Máte různé možnosti pro ukládání souborů. Ujistěte se, že jste vybrali vhodné umístění v závislosti na typu souboru, jeho obsahu a způsobu jeho použití.

SharePoint Online nebo OneDrive

Běžným řešením pro ukládání souborů je použití sharepointových webů. SharePoint je široce přístupný pro většinu uživatelů a je vysoce integrovaný s Power BI i dalšími aplikacemi Microsoft 365, jako je Microsoft Teams. Kromě toho má integrovanou správu verzí, což usnadňuje ukládání většiny typů souborů. Správa verzí umožňuje zobrazit a spravovat různé uložené verze souboru.

Při ukládání souborů na SharePointu zvažte následující body.

• Organizace: Zajistěte, abyste zachovali konzistentní a logickou strukturu, aby bylo snadné najít konkrétní soubory. Používejte dobré zásady vytváření názvů, uspořádejte soubory ve složkách a archivní soubory, které už nejsou relevantní pro probíhající projekty.
• Aktualizace OneDrivu: Publikovaný sémantický model nebo sestavu můžete propojit se souborem .pbix uloženým na SharePointu nebo OneDrivu pro firmy (označovaném také jako OneDrive pro práci nebo školu). Díky tomuto přístupu už nemusíte publikovat sémantický model, aby se změny projevily. Místo toho se změny zobrazí po automatické aktualizaci OneDrivu, ke které dochází každou hodinu. I když je tento přístup pohodlný, mějte na paměti, že tento přístup přináší určité překážky a výzvy. Když se něco stane, nedá se to snadno vrátit zpět.
• Sestavy ve verzi Preview: V SharePointu je možné zobrazit sestavy Power BI bez nutnosti instalovat Power BI Desktop nebo stáhnout soubor .pbix místně. Když sestavy otevřete tímto způsobem, zobrazí se v prohlížeči. Tato funkce může být praktickou alternativou k zobrazení sestav z portálu Fabric. Ve výchozím nastavení je povolená v nastavení tenanta Fabric.

Návod

Při spolupráci pomocí Microsoft Teams zvažte ukládání souborů do knihovny dokumentů kanálu. Tento přístup pomáhá centralizovat soubory a usnadnit spolupráci.

Zvažte uložení následujících typů souborů v SharePointu.

• Šablony a dokumentace: Ukládání šablon a dokumentace na SharePointu, pokud nemáte existující řešení úložiště. SharePoint je ideální pro tyto soubory, protože můžete udělit přístup ostatním a spravovat soubory bez složitého nastavení nebo procesů.
• Podpůrné soubory: Ukládání podpůrných souborů na SharePointu, pokud nemáte existující řešení úložiště. Některé pomocné soubory, jako například soubory s motivem Power BI .json pro sestavy, mohou být lépe uložené v systému správy verzí, který umožňuje prohlížení a správu zaznamenaných změn.
• Soubory obsahu: Obsah můžete ukládat do SharePointu, pokud není pro firmu důležitý nebo pokud nemáte přístup ke vzdálenému úložišti, jako je Azure Repos.
• Zdroje dat: Zdroje dat se ukládají v SharePointu jenom v případech, kdy jsou malé a složité. Buďte disciplinovaní při použití SharePointu k ukládání datových souborů. Zvažte další možnosti, jako OneLake.

Upozornění

Nepoužívejte SharePoint jako alternativu k správné architektuře dat. I když ukládání souborů zdrojů dat na SharePointu může být vhodné v některých omezených scénářích, tento přístup se neškáluje, když máte větší, složitější zdroje dat nebo když potřebujete nižší latenci dat.

Výstraha

Nepoužívejte osobní systémy souborů ani osobní účty OneDrivu k ukládání souborů. Pokud vlastník opustí organizaci, tyto soubory už nebudou k dispozici.

OneLake

Pokud máte kapacitu Fabric, může být OneLake dobrou volbou ke ukládání souborů zdroje dat. Soubory můžete nahrát nebo synchronizovat do OneLake pomocí Průzkumníka souborů OneLake, kde je můžete transformovat na tabulky pro použití v podřízených úlohách, jako je Power BI. U větších nebo pravidelně aktualizovaných zdrojů dat můžete soubory načíst do OneLake automaticky pomocí služby Fabric Data Factory nebo jiných aplikací, které používají rozhraní API Azure Data Lake Storage (ADLS) Gen2 nebo sadu Azure Storage Python SDK.

Upozornění

Akce, jako je nahrávání nebo stahování souborů z OneLake , využívají jednotky kapacity Fabric. Měli byste monitorovat metriky kapacity a podniknout kroky, abyste se vyhnuli přetížení kapacity způsobené zbytečným přesunem velkých souborů.

Kromě toho jsou soubory, ke kterým uživatelé přistupují v Průzkumníku souborů OneLake, ohroženy náhodnými změnami nebo ztrátou. Doporučujeme, abyste se vyhnuli používání Průzkumníka souborů OneLake pro důležitá obchodní řešení.

Výstraha

Průzkumník souborů OneLake má několik důležitých omezení a aspektů. OneLake například nepodporuje správu verzí pro soubory, jako je SharePoint nebo OneDrive. Při rozhodování o ukládání souborů vezměte v úvahu tyto aspekty a omezení.

Návod

Při ukládání dat ve OneLake zvažte povolení provozní kontinuity a zotavení po havárii (BCDR) ke zmírnění rizika ztráty dat. S povoleným BCDR se vaše data duplikují a ukládají ve dvou různých geografických oblastech podle párování standardních oblastí Azure.

Vzdálené úložiště

Tvůrci obsahu mohou v pravidelných intervalech během vývoje ukládat a nahrávat svou práci ze svého místního počítače do vzdáleného úložiště, jako je úložiště Git v Azure Repos nebo GitHub. Vzdálené úložiště obsahuje nejnovější verzi obsahu nebo podpůrných souborů a je přístupné celému vývojovému týmu. Vzdálené úložiště obvykle usnadňuje pokročilejší přístupy ke správě životního cyklu než používání Teams, SharePointu nebo OneDrivu. Je to proto, že pomocí vzdáleného úložiště můžou tvůrci obsahu využívat sofistikovanější možnosti spolupráce na souborech nebo sledování a správu změn souborů. Tvůrci obsahu můžou například pracovat ve své vlastní větvi vzdáleného úložiště, aby mohli provádět změny, a požádat o sloučení těchto změn do hlavní větve, až bude připravená.

Zvažte uložení následujících typů souborů do vzdáleného úložiště.

• Šablony a dokumentace: Ukládání šablon a dokumentace ve vzdáleném úložišti při správě projektu pomocí souvisejících služeb, jako je Azure DevOps.
• Podpůrné soubory: Ukládání podpůrných souborů ve vzdáleném úložišti, pokud je k dispozici pro snadné sledování a správu změn.
• Soubory obsahu: Ukládání obsahu ve vzdáleném úložišti, pokud je pro firmu důležité, nebo máte v úmyslu spolupracovat s ostatními vývojáři na stejném obsahu. Vzdálené úložiště je ideální pro sledování změn obsahu a usnadnění spolupráce.

Návod

Při použití vzdáleného úložiště důrazně doporučujeme ukládat sestavy Power BI a sémantické modely jako soubory power BI Desktopu (.pbip) místo souborů .pbix. Je to proto, že uložené změny nelze identifikovat v souboru .pbix.

Zvažte také použití rozšířeného formátu sestav Power BI (PBIR) pro sestavy. Formát PBIR zajišťuje, aby metadata sestavy byla čitelnější, což usnadňuje sledování a správu změn ve správě zdrojového kódu. Sestavy, které používají tento formát, mohou být navíc snadněji spravovány programovými nástroji, jako jsou sémantic-link-labs, knihovnou Pythonu od Microsoftu, kterou můžete použít v poznámkových blocích Fabric.

Žádné soubory: Obsah vytvořený na portálu Fabric

Tvůrci obsahu můžou vytvářet obsah přímo na portálu Fabric. V tomto scénáři obvykle nefungují přímo se soubory obsahu. Obsah na portálu Fabric byste obvykle měli vytvářet jenom v případě, že se typy položek nedají vytvářet jinde (například toky dat, řídicí panely nebo přehledy výkonnostních metrik). Sestavy a sémantické modely můžete vytvářet také na portálu Fabric, pokud nemáte přístup k počítači s Windows, a proto nemůžete Power BI Desktop používat. Další informace najdete v tématu Uživatelské nástroje a zařízení.

Upozornění

Jako soubor nejde stáhnout nějaký obsah vytvořený na portálu Fabric. Například sestavy vytvořené na portálu Fabric nelze stáhnout ve formátu .pbix.

Při vytváření obsahu na portálu Fabric byste měli k zálohování definic obsahu použít rozhraní API Fabric nebo integraci Git. Při zálohování definic obsahu zmírníte přerušení, pokud se tento obsah omylem odstraní nebo neúmyslně změní. Pokud se obsah omylem odstraní nebo změní, můžete ho nahradit pomocí zálohy.

Kontrolní seznam – Při plánování a navrhování obsahu zahrnují klíčová rozhodnutí a kroky:

• Plánování řešení: Shromážděte obchodní požadavky a technické požadavky , abyste dostatečně porozuměli problému, který bude váš obsah řešit, a navrhněte, jak bude tento obsah problém řešit.
• Určete, kdo bude vytvářet obsah: V závislosti na pracovním postupu, dovednostech a potřebách jednotlivých tvůrců obsahu můžou být potřeba různé přístupy ke správě životního cyklu.
• Určete, jestli musí spolupracovat více tvůrců obsahu: Zajistěte, aby spolupracovníci obsahu používali typy souborů, které podporují správu verzí, jako jsou soubory .pbip.
• Rozhodněte se, jak budou tvůrci obsahu spolupracovat: Rozhodněte se, jak sofistikovaná spolupráce bude. Kromě toho se rozhodněte, jak tuto spolupráci usnadníte, například pomocí Microsoft Teams, Azure DevOps nebo GitHubu.
• Rozhodněte formát obsahu: Rozhodněte se, jestli se sémantické modely a sestavy Power BI budou skládat ze souborů .pbix nebo .pbip (nebo jiných formátů, jako jsou .bim nebo .tmdl pro modely), a jestli sestavy budou používat formát PBIR, nebo ne.
• Určete, jak bude obsah spotřebován: Vyhodnoťte, jak budou uživatelé pracovat s daty. Rozhodněte se, které typy položek potřebujete vytvořit pro podporu spotřeby a jestli uživatelé vyžadují oprávnění jen ke čtení, nebo také vytvářejí oprávnění k podkladovým sémantickým modelům nebo jiným datovým položkám. Pokud uživatelé vyžadují oprávnění k sestavení, určete včas, jak budou využívat sémantické modely a jak je budete efektivně trénovat.
• Nastavení nástrojů pro spolupráci: Ujistěte se, že pro řešení nebo projekt provedete nezbytné první nastavení. Rozhodněte se, jak budete spravovat spolupráci pomocí těchto nástrojů.
• Ukládání souborů zdroje dat na SharePointu nebo OneLake: Ukládání malých jednoduchých souborů zdroje dat na SharePointu Jinak místo toho použijte OneLake nebo ADLSGen2 (pokud jsou k dispozici).
• Ukládání obsahu a podpůrných souborů v SharePointu, Microsoft Teams nebo úložišti Git: Pro jednodušší menší projekty používejte SharePoint pro většinu souborů, pokud je uspořádaná a vy si procvičíte dobrou správu přístupu. V případě větších prostředí nebo v případě potřeby paralelní spolupráce zvažte použití úložiště Git v GitHubu nebo Azure DevOps, které poskytuje podrobný přehled o změnách obsahu.
• Ukládání šablon a dokumentace v Microsoft Teams nebo SharePointu: Tyto šablony a dokumentace jsou určené pro komunitu uživatelů. Zajistěte, aby šablony a dokumentace byly pro ostatní snadno dostupné, používané a srozumitelné.
• Plánování vývoje a nasazení: K závěru této první fáze proveďte specifické plánování pro řešení klíčových oblastí a provedení počátečního nastavení. Vytvořte například nástroje a otestujte připojení ke zdroji dat.

Související obsah

V dalším článku v této sérii se dozvíte, jak vyvíjet obsah a spravovat změny v rámci správy životního cyklu obsahu.