Delfíni na vlnách: To nejdůležitější o Power BI governance

Dodržovat pravidla se vyplatí aneb jak zajistit to, aby se ze self-service nestal jeden velký zmatek? Zjistíte v dalším podcastu delfíni na vlnách!

00:00:01 Jakub Holubec:  

Dobrý den, dámy a pánové, vítám vás u dalšího dílu našeho podcastu ze světa dat a datové analytiky. Já jsem Jakub Holubec ze společnosti dolphin consulting a mým dnešním hostem je opět Petr Kolář – náš expert na Power BI. 

Téma, které jsme si pro dnešek vybrali, je governance v Power BI prostředí. A začneme pěkně zostra. Můj dojem je, že firmy často vnímají Power BI jako self-service platformu pro analytické a reportovací potřeby. Představují si, že uživatelům dají nástroj a řeknou: „Tady to máte, vytvářejte si vlastní reporty, dělejte si, co chcete,“ a celá firma bude šťastná a informačně saturována. 

Na druhé straně se tady ale bavíme o nějaké governance. Co si pod tím pojmem představuješ a proč by měla v této oblasti existovat? 

00:01:10 Petr Kolář: 

Aby self-service efektivně fungoval, musí být správně nastavena jak platforma, tak pravidla používání. Governance je základním prvkem pro zajištění pořádku. 

00:01:23 Jakub Holubec: 

A governance jako taková znamená co konkrétně? 

00:01:29 Petr Kolář: 

Například otázka, zda si každý uživatel může bez jakýchkoli pravidel vytvářet vlastní workspace v Power BI prostředí. Pokud toto povolíme, vznikne chaos, ve kterém se nikdo nevyzná, což bude složité i pro správu a podporu. 

00:01:52 Petr Kolář: 

Uživatelé mohou dosáhnout limitů dat nebo transformací, což může přetížit sdílenou nebo prémiovou kapacitu. Pokud mnoho uživatelů pracuje v rámci jedné prémiové licence, mohou ji rychle přetížit. 

00:02:25 Jakub Holubec: 

Takže zavedení governance znamená stanovit pravidla, postupy a seznámit s nimi uživatele, je to tak? 

00:02:45 Petr Kolář: 

Ano, v první řadě je potřeba rozmyslet, jak bude platforma používána. Z toho vyplývá nastavení tenantu a spousty dalších věcí, které se neustále rozšiřují, zejména s implementací nových funkcí, například do Microsoft Fabricu. 

Zajímavé je například nastavení, kdo může vytvářet workspace, certifikované datové modely, nebo publikovat reporty na nezabezpečený web. Také je potřeba rozhodnout, zda povolíme externí nástroje jako Excel nebo AI nástroje. 

00:03:51 Jakub Holubec: 

Takže je tam technická část platformní a procesní část, která se týká toho, co bude lidem umožněno a co ne? 

00:04:10 Petr Kolář: 

Přesně tak. Technická část zahrnuje nastavení tenantu a souvisejících nástrojů, například od Microsoftu nebo třetích stran, které jsou schváleny Microsoftem. Nastavení datových zdrojů může být komplexní, zvláště pokud firma používá různé databáze. Pak je tu procesní část – nastavit pravidla, která zajišťují, že vše funguje hladce. Důležité je nastavit pravidla pro sdílení reportů, například pomocí security groups, což je pro administraci jednodušší než přidávat uživatele individuálně do každého reportu nebo datasetu. 

Takže uživatelé najdou ten svůj střípek, ale jakmile workspace a reporty začnou narůstat do velkého množství, může se v tom administrátor začít ztrácet. Může být složité dohledat, co k čemu patří, a zjistit, koho oslovit, když něco nefunguje. Když tyto věci neuděláme a nenastavíme pravidla, jaký bude reálný dopad? K čemu to povede? 

00:06:07 Jakub Holubec: 

Jo, jo. 

00:06:07 Petr Kolář: 

To je jednoduché. Reálný dopad může být například problémy s výkonem. Pokud uživatelé z různých oddělení budou mít přístup k reportům a nebude existovat žádná struktura v pojmenování nebo vytváření workspace, tak pro ně to může být chaos. Budou přehlceni daty a někteří si sice mohou některé reporty nebo aplikace přidat do oblíbených, což pomůže, ale propojení mezi datasety a složitější funkce, jako je drill through nebo cross-reporting, může být obtížné. Proto je dobré nastavit nějaká pravidla. 

Navíc je důležité, aby reporty vypadaly podobně, měly nějakou „štábní kulturu“, používaly stejný šablonový styl, barvy, a aby na stránkách byly cílové ukazatele. Pokud nejsou nastavena pravidla, je to složité. 

A další věcí, o které jsme ještě nemluvili, je, jak budou reporty nebo dashboardy sdíleny s koncovými uživateli. Budou jmenováni konkrétní uživatelé, nebo to budeme řešit pomocí security groups, například prostřednictvím e-mailových adres? To je pro administraci jednodušší, protože je jednodušší přidat konkrétní uživatele do security group než ke každému datasetu nebo reportu zvlášť. 

Použití security groups také zjednodušuje přidávání nových uživatelů, což šetří čas a zvyšuje přehlednost. 

00:07:49 Jakub Holubec: 

Když to bereme tak, že Power BI bude self-service platforma a my dáme nějaká doporučení nebo pravidla, jak jsi říkal – třeba jaké mají být naming convention a podobně – mělo by se to vztahovat na všechno, co uživatel udělá? Nebo jsou tam různé úrovně? Například když někdo publikuje report, musí to splňovat nějaká pravidla, ale pokud to dělá jen pro malou skupinu lidí v rámci jednoho oddělení, nemusí? Řeší se tohle v rámci governance, nebo je to striktní a kdykoliv uživatel něco udělá, musí to splňovat daná pravidla? 

00:08:22 Petr Kolář: 

Jasně, jednotlivé týmy mají svůj vlastní self-service, takže úplný a čistý self-service, kde si každý dělá úplně všechno sám, reálně snad v žádné firmě není nasazen. Byly takové průzkumy, že minimálně základní přípravu dat dělají odborníci, kteří těm datům rozumí. Mají pod palcem data governance a připravují data pro uživatele. Ideálně je dobré připravit i workspace a technikálie na pozadí, protože pro uživatele to může být obtěžující a v podstatě je to nezajímá. 

Navíc workspace může být něco, co potřebují vytvořit jednou za dva roky. Takže učit se, co všechno je třeba nastavit a jak to spolu souvisí, je složité. Lepší je, když to dělá nějaký support tým nebo oddělení podpory, nebo se to vytvoří automaticky. 

Za mě je docela dobrá praxe, že když někdo chce mít větší projekt v Power BI, je to procesně vyřešeno například formuláři nebo checklisty. Uživatel si zažádá o projekt v Power BI, definuje, kdo o něj žádá, kdo bude gestorem projektu, kdo bude vlastníkem dat, kdo bude schvalovat přístup a citlivost dat, a také přibližně určí, jak velká data budou, kolik bude výstupů atd. Taková jednoduchá evidence může být schválena třeba automatickým procesem nebo někdo to zkontroluje a dá souhlas. Následně může být pomocí Power Automate automaticky vytvořen workspace, příslušné AD skupiny, deployment pipeline, a případně další prostředí. Dalším krokem pak může být výzva k definování datových zdrojů. Jedna věc je vědět, co chceme, a druhá mít k tomu technické podmínky – například mít konektor. 

Pokud je to on-premises zdroj, ten musí být definován na gateway, což určitě nebude dělat nějaký manager self-service. 

00:10:32 Jakub Holubec: 

To je tedy součástí té governance, která říká, že pokud si uživatelé budou chtít založit nový workspace, měli by postupovat podle tohoto popsaného procesu? 

00:10:45 Petr Kolář:
V podstatě ano. Řeší se, jaký typ projektu ten uživatel vytváří nebo požaduje. Pokud je to self-service, tak se vytvoří jednoduchá evidence objektů, aby bylo jasné, pro koho je report, jaký je jeho smysl, co je na něm zobrazeno a za jakým účelem. Také se uvede, jak report číst, jestli tam jsou nějaké nápovědy a jestli je report technicky dokonalý – například jestli používá tooltips, drillthrough, analýzu, time intelligence atd. 

Toto může být na koncovém vývojáři reportu, nebo někdo může report vytvořit na základě požadavku byznysového člověka. V rámci každého oddělení může být někdo, kdo umí vytvářet reporty, a pár lidí ho úkoluje – to je jedna cesta. Druhá cesta je mít systematický reporting, kde je potřeba, aby tam byla pravda, aby to prověřili editoři, a aby specialisté na IT nebo BI dělali performance testing a maintenance reportu. V tomto případě musí být pravidla striktnější, také z důvodu dokumentace, kde může být požadována SDLC dokumentace. 

00:12:07 Jakub Holubec:
Teď mě zajímá technický detail. Jak je ta governance reálně zpracována? Je to nějaký wordový dokument, nebo je to na SharePointu nebo nějaké interní platformě? Jaký je fyzický formát? 

00:12:24 Petr Kolář:
Fyzická forma může být dokument, ale to nemusí být ideální pro koncového uživatele nebo lidi, kteří něco dohledávají. Většinou, co vídáme u zákazníků, nebo co doporučujeme, je používat SharePointové stránky nebo nějaké knowledge base, kde jsou věci popsané a strukturované. Například některé informace jsou určeny pro IT specialisty, kteří nastavují prostředí a vědí, jak dělat správně performance a na co si dát pozor.
Jsou tam pravidla, best practices a jejich kontrola, třeba i automatizovaná. Dále jsou stránky s doporučeními a tipy pro vývojáře reportů. Bohužel se někdy opomíjejí tipy pro uživatele, kteří se na reporty pouze dívají. Pokud tito lidé neprojdou alespoň půlhodinovým školením, aby věděli, co přesně dělá každá z deseti ikonek, které mají k dispozici, mohou být frustrovaní a nevyužívají reporting tak efektivně, jak by mohli. 

00:13:31 Jakub Holubec: 

Číst si nějaký wordový dokument nebo se dívat na SharePoint už není tak úplně cool. Dneska jsou hodně populární chatboti. Viděls někdy využití chatbota? Přijde mi, že by to bylo přirozenější. Místo dohledávání dokumentů bych se prostě zeptal chatbota: „Jak si mám založit workspace?“ Viděls to někdy realizovaný? 

00:13:53 Petr Kolář: 

Ano, viděli jsme chatboty a pomáhali jsme je tvořit u dvou zákazníků. Bylo to většinou na otázky týkající se procesů na pozadí. Například někdo zjistí, že existuje Power BI, ale neví, kde začít. Chatbot může jednoduše vysvětlit, co Power BI je, a odkázat uživatele na stránky, kde jsou podrobné informace, nebo na formulář, který vyplní a díky kterému se mu automaticky vytvoří workspace, aby mohl začít vytvářet reporty. Případně může chatbot odkázat uživatele na podporu, která projekt vezme pod svá křídla a pomůže mu s jeho realizací. 

00:14:48 Jakub Holubec: 

Když mluvíme o datech a datové analytice, měli bychom se také bavit o bezpečnosti. Je zabezpečení součástí governance? A co všechno governance v rámci zabezpečení řeší? Už jsi zmínil skupiny versus jednotlivé uživatele, ale je tam ještě něco dalšího? 

00:15:09 Petr Kolář: 

Jedna z otázek je, zda chceme mít data a celý reporting on-premise, nebo v cloudu. To je často řešené téma. Většina zákazníků končí v cloudu, ale někdy jsou rozumné důvody pro setrvání on-premise, například u zákazníků, kteří mají vybudovaný reporting a databáze on-premise a používali Reporting Services. Také někdy regulátoři nebo zákonné důvody vyžadují, aby určitá data zůstala on-premise. 

Pokud se bavíme o reportingu v cloudu, ten má zabezpečení na stejné úrovni jako celý Office 365, včetně certifikací a standardů jako ISO 27001. Jakmile firmy získají více informací a reference, většinou obavy ztratí. Poté řešíme objektovou a row-level security. Objektová security se nejjednodušeji nastavuje pomocí AD skupin a workspace, a může být ještě vylepšena pomocí aplikací, kde každý uživatel vidí jinou verzi reportu. 

Row-level security se definuje tak, že různí lidé vidí různé záznamy na základě svých přístupových práv – třeba výsledky pro jejich region nebo tým. Tyto dvě vrstvy zabezpečení se mohou kombinovat. Součástí zabezpečení je také možnost, či nemožnost publikovat do nezabezpečeného webu, což typicky zakazujeme, ale v některých případech to dává smysl. 

00:17:20 Jakub Holubec:
Takže způsoby, jak bezpečnost řídit, jsou tedy popsány v té dokumentaci, že? Pokud by si uživatel vytvořil sadu reportů, mohl by se chatbot zeptat: „Jak je mám zabezpečit a publikovat?“ a chatbot by mu poskytl pravidla, která by měl dodržet, aby to mohl správně publikovat. Chápu to správně? 

00:17:42 Petr Kolář:
Ano, přesně tak. Ideálně by ten chatbot měl vědět i roli uživatele. Pokud jsem například IT administrátor Office 365, budu potřebovat jiné informace, než když jsem vývojář reportu a zajímám se o row-level security. Chatbot by to měl umět odhalit nebo se na to doptat. Všechny tyto informace by měly být v dokumentaci, protože bezpečnost často nastavují lidé z jiného týmu než ti, kteří se pohybují kolem BI a Power BI. Je tedy dobré, aby vše bylo jasně popsáno, včetně odkazů na oficiální Microsoft dokumentaci. 

00:18:38 Jakub Holubec:
Další věc, co mě zajímá, je, že u klientů často vidím, že reporty vznikají, ale je málo pozornosti věnováno tomu, jak je následně udržovat a měnit. A pak se stává, že reporty zanikají. Když třeba děláme migraci z jednoho reportovacího systému do jiného, často začínáme s 1500 reporty a nakonec zůstane třeba jenom pár. Řeší governance i celý životní cyklus reportů, včetně změn a jejich ukončování? 

00:19:19 Petr Kolář:
Určitě je důležité, aby byl životní cyklus pod kontrolou. Doporučujeme přístup podle norem ISO, který se používá v mnoha odvětvích, včetně finančního a průmyslu. Tento přístup má čtyři kroky: plánovat, udělat, zkontrolovat a naplánovat údržbu. 

00:19:45 Jakub Holubec:
Chápu, jak je řešen vznik reportu, a co se týče změn, předpokládám, že tam jde o proces vývoje, testování a nasazení do produkce. Je tento cyklus řešen v rámci governance? 

00:20:03 Petr Kolář:
Ano, tento cyklus je součástí governance. Změny reportů by měly mít jasně definovaný proces. Mělo by být jasné, kdo má právo požádat o změnu, kdo ji schvaluje, a zda jde o malou nebo velkou změnu. Může jít o malý hotfix nebo o větší změnu, která vyžaduje více práce či úpravy IT infrastruktury. Vše by mělo být naplánováno, provedeno, zkontrolováno a nasazeno do produkce. 

00:20:42 Jakub Holubec: 

A jak se řeší zánik reportů? Je to nějakým způsobem pokryté? Protože, jak jsem zmínil, reportů neustále přibývá a když se nějaký přestane používat, zůstává tam. To pak může být problém pro lidi, kteří ho najdou, aniž by věděli, že už se nepoužívá. 

00:20:59 Petr Kolář: 

Automatizace v Power BI funguje tak, že pokud se nikdo na report nepodívá dva měsíce, aktualizace se vypnou samy. To z jedné strany šetří infrastrukturu, ale na druhé straně může dojít k situaci, kdy se někdo na report podívá a neuvědomí si, že nahoře na obrazovce je napsáno, kdy byl naposledy aktualizován. Může se stát, že bude pracovat se zastaralými daty. Jakmile se však někdo na report podívá, automaticky se spustí obnovení. Pokud byl ale report vypnutý delší dobu, může dojít k problémům, protože příslušné tabulky na pozadí už nemusí být dostupné, což znemožní obnovu dat. 

V Power BI sledujeme tyto reporty a zároveň kontrolujeme i nevyužívané datové artefakty. Uživatelé často smažou report, ale zapomenou odstranit dataset nebo sémantický model. A jak jsem zmínil na začátku, když firmy implementují self-service BI, uživatelé začnou vytvářet obrovské množství reportů, ale často se zanedbává dokumentace, což je pro mnohé takové sprosté slovo. 

00:22:28 Jakub Holubec: 

Předpokládám, že dokumentace je pořád něco, co by mělo vznikat i v rámci self-service BI a že se to řeší v rámci governance. Je to tak? 

00:22:40 Petr Kolář: 

Určitě je důležité najít vhodnou míru dokumentace, aby to nebylo likvidační pro platformu a pro self-service BI. Pokud jde o nějaký malý report s omezenou skupinou uživatelů, není nutné dokumentaci přehánět. Doporučujeme však při práci s Power Query Editor psát komentáře k jednotlivým transformacím. To pomáhá nejen tvůrci reportu, ale i ostatním vývojářům, protože za pár měsíců už nemusí být jasné, proč se tyto transformace dělaly. 

Stejně tak u vzorců v DAXu je dobré komentovat alespoň ty méně obvyklé nebo nelogické části. Dokumentační nástroje, jako je Documenter, mohou snadno vytáhnout metadata včetně těchto komentářů, což může sloužit jako základ dokumentace reportu. 

Co jsem zatím nezmínil, je popis samotné reportní stránky – proč tam určité prvky jsou a jak by měly být využívány. U důležitých reportů často vytváříme stránku s nápovědou nebo zobrazujeme poslední aktualizace. Může to být pracné, ale velmi užitečné pro uživatele, kteří se do reportu dívají jen občas, nebo pro ty, kteří nejsou obeznámeni s jeho fungováním. 

Tato pravidla jsou klíčová pro zajištění, že reporty zůstanou přehledné a snadno použitelné, a to i pro méně zkušené nebo nepravidelné uživatele. 

00:25:01 Jakub Holubec:
Můžou se ta pravidla dodržovat, ale důležité je, jak zajistit jejich skutečné dodržování. Typicky u dokumentace, která se na začátku vytvoří, ale během změn v budoucnu se do ní už nikdy nezasahuje, a tak se stává zastaralou. Jak se tedy řeší tento proces? 

00:25:27 Petr Kolář:
Ten, kdo se stará o změny dokumentace, musí být vhodně motivován nebo k tomu přímo přinucen. Například pokud vytváří reporty a nedodržuje pravidla, nebude mu povolena prémiová kapacita, což může být dostatečnou motivací. Dalším způsobem je zavedení interních procesních pravidel, které vyžadují určitou míru dokumentace u reportů na vyšší úrovni. Samozřejmě existují také procesy pro aktualizaci dokumentace, ale u jednodušších self-service reportů se to může rozjet a není to tak striktní. 

00:26:20 Jakub Holubec:
Takže governance popisuje nejen ta pravidla a způsob kontroly, ale i kdo za co odpovídá, tedy nějaké role. Kdo publikuje, kdo kontroluje atd.? 

00:26:26 Petr Kolář:
Přesně tak. A zase je důležité vzít v úvahu velikost dané firmy nebo oddělení. U menších týmů může být role jednodušší, třeba jen pár lidí vytvářejících reporty, ale u větších organizací se musí definovat role jako Power BI tenant administrátor, který na začátku nastaví vše správně a pak se zapojuje jen v případě, že něco nefunguje. U větších firem s prémiovou kapacitou je také potřeba role kapacitního manažera, který sleduje, jak jsou reporty a dataset využívány. 

Co se týče samotného vývoje reportu, je dobré oddělit role zadavatele, vývojáře, testera a případně někoho, kdo provádí nasazení (deployment). Například ten, kdo vyvíjí, by si neměl sám testovat svůj kód, protože by mohl přehlédnout důležité detaily. Ve větších firmách se také mohou vytvářet komunity uživatelů Power BI, kteří si navzájem radí, což šetří čas a kapacity podpory. 

00:28:32 Petr Kolář:
A k tomu všemu je důležité mít také vzdělávací systém, který uživatele pravidelně školí na nové funkce a postupy. 

00:28:38 Jakub Holubec: 

A to všechno, co jsme tady popsali jako governance, je tedy někde sepsané na jednom místě? Ať už je to chatbot, SharePoint nebo dokument, kde jsou všechny tyto věci shrnuté – vzdělávání, komunita, role, procesy, zabezpečení a podobně? 

00:28:58 Petr Kolář: 

Může to být na jednom místě, nebo rozdělené na více míst. Máme technickou governance, která je více zaměřená na technické detaily, a pak máme část, která by měla být přístupnější a srozumitelnější pro koncové uživatele nebo vývojáře. Ty technické aspekty je tolik nezajímají, nebo je nemohou ovlivnit ze své pozice. Když to shrneme dohromady, můžeme to nazvat specifikací prostředí nebo platformy, jejíž součástí je i technická governance. Bez ní to nejde – někdo musí ten tenant správně nastavit, umožnit přístup uživatelům a podobně, a následně se řeší samotné využívání platformy. 

00:29:44 Jakub Holubec: 

Jen tak pro zajímavost, protože jsi tu governance nastavoval v několika firmách, kdybychom všechna ta pravidla sepsali do Wordu, kolik stránek by zhruba měl takový dokument? Já vím, že to nejde přesně říct, ale zhruba? 

00:29:56 Petr Kolář: 

Záleží na rozsahu platformy a úrovni detailů, ale takový dokument by mohl mít klidně desítky stránek. Na jedné straně máme jednodušší pravidla, která se týkají uživatelů a procesů, a na druhé straně technická pravidla a postupy, která mohou být rozsáhlejší. 

 

00:30:00 Petr Kolář: 

Je to o tom, kolik detailů se tam napíše. Když se třeba bavíme o detailech ohledně softwaru, které se dají používat… Spousta lidí si představí jen Power BI Desktop a Power BI Service, ale existuje spousta externích nástrojů, které je dobré alespoň zmínit. Pokud se to vezme v úvahu, můžeme se bavit třeba o dvouset stránkách dokumentace. Ale když je to vhodně rozděleno na sekce a je tam dobrá navigace, pak se člověk velmi rychle dostane k tomu, co ho konkrétně zajímá. Třeba v Microsoft E-learningu nebo v nějakých vzdělávacích programech, které se vytváří uvnitř firem a jsou specifické pro danou společnost, protože vyplývají z jejích dat, kultury a procesů. Může to být opravdu rozsáhlá záležitost. 

00:30:32 Jakub Holubec: 

Tohle téma je opravdu zajímavé. Měli bychom se o tom bavit další půlhodinu, ale myslím, že je na čase skončit. Děkuji moc. 

Mohlo by vás zajímat

Číst další

Chcete nás kontaktovat?

Drop files here or
Max. file size: 100 MB.
    This site is registered on wpml.org as a development site. Switch to a production site key to remove this banner.