Podcast

Dobrý den, moje jméno je Jirka Vešerek a vítám vás u dalšího dílu Data Talku. Mým dnešním hostem je Vašek Kouklík ze společnosti Saska. Ahoj, Vašku.
Ahoj.

Vašek v Sasku působí jako team lead pro data analytics a v dnešním díle Data Talku si budeme povídat o tom, jak se v Sasku zaváděl BI reporting, co znamená pro Sasku regulatorní reporting, i jak teď vlastně zavádějí self-service BI. Vašku, děkuji, že jsi přišel.

Než se dostaneme do Sasky, pojďme si představit tebe a jak ses vlastně dostal k datům, k technologiím a nakonec k Sasku.

Jo, díky za pozvání. Já jsem vlastně začínal se SAPem, což mě upřímně úplně nebavilo, byla to pro mě dokonce černá krabička, protože jsem úplně nevěděl, co se uvnitř děje. Pak se mi podařilo dostat do reportingu, do Outu, kde už jsem pracoval s databázemi a s daty, a to mě naplňovalo daleko víc. Tam jsem se toho poměrně hodně naučil, když jsem přicházel, tak v podstatě jsem uměl napsat akorát „Select hvězdička from TerraData“ a od tohoto jednoduchého skriptu jsem se posunul poměrně dál a pak logická volba, další krok, bylo využít ty nabité znalosti v Sasku.

A co jsi studoval?
Studoval jsem v Praze na Vysoké škole ekonomické se zaměřením na informatiku a statistiku, takže k datům jsem měl blízko už na škole. Tam jsem měl i předměty typu datový sklad, business intelligence už v té době a to mě poměrně hodně bavilo, takže jsem byl rád, že jsem se k reportingu malou oklikou přes SAP vrátil.

A ty jsi byl v Outu skoro pět let, co jsi tam vlastně měl na starosti? Jaké bylo tvoje oddělení a už tehdy jsi řešil BI reporting jako BI reporting?
V té době se tomu úplně neříkalo BI reporting, ale dělali jsme reporting pro business. Reportingových oddělení v Outu bylo více, poměrně hodně se s námi i v organizační struktuře hýbalo, takže nakonec, když jsem tam byl, tak jsme skončili pod IT, pod technologií.

Čím tě přilákala Saska?
Dala mi příležitost vybudovat reporting v podstatě na zelené louce, takže jsem mohl zužitkovat nabité znalosti a dělat si to trochu po svém.

A to je který rok, kdy se staví reporting Sasky na zelené louce?
To bylo v roce 2017. Potřeba ze strany Sasky vlastně vznikla i rozvojem online sázení. Do té doby primárně hrála velkou roli land-based sázení, takže v tomto roce dat opravdu hodně přibylo.

Takže v roce 2017 Češi začali sázet online a do Sasky přichází Vašek. Ty jsi přišel na pozici nějakého datového analytika?
Ano, v té době se to jmenovalo BI specialista. Tým byl poměrně malý, když jsem přicházel, tak nás bylo tři, takže se to nazývalo BI specialista a byla to práce všeho druhu nad datovým skladem a daty.

No a ještě říkáš „na zelené louce“, ale na druhou stranu je to Saska, tak předpokládám, že i v roce 2017 co se týká technologií, IT i reportingu tam něco bylo. Můžeš se vrátit zpátky do svého prvního roku, jaký byl tehdy status quo?
Nešlo o úplnou zelenou louku, už tam existoval datový sklad, který se v té době outsourcoval, také tam existovaly datové OLAP kostky, které jsou a stále jsou uživateli hodně oblíbené. Automatizovaný reporting ve smyslu aktuálně používaného Power BI jsme tam teprve budovali.

Říkáš, že uživatelé mají OLAP kostky rádi. Jak se v průběhu let mění tvůj názor a pohled na OLAP kostky a jejich použití?
Snažíme se je postupně nahradit reporty v Power BI. Nevýhoda OLAP kostek nebo Excelových dat je v tom, že je k nim přesunuta odpovědnost bez kontrolovatelnosti, jak jsou vlastně data používána, zatímco u reportů máme nad tím větší kontrolu.

Takže kdybys dnes stavěl reporting na zelené louce, byla by součástí toho OLAP kostka?
Nebyla by.

Pro posluchače, co se moc s daty nesetkávají, já mám trošku nedůvěru v OLAP kostky, protože se s tím setkávám od ostatních. Je zajímavé, že právě uživatelé je mají rádi, že tam je nějaká setrvačnost v jejich používání.

Ano, to je přesně tak.

Takže jsme v roce 2017, Saska má datový sklad a ještě outsourcovaný, to je zajímavé, a jdete dělat BI reporting. Co to znamená v takové organizaci? Jak se to rozdělilo? Bylo to příkazem shora, nebo se to zrodilo ze zdola, protože online sázení začalo fungovat? Co bylo iniciátorem té změny?
Obrovskou výhodou bylo, že Saska už měla v rámci svého serveru licenci Reporting Services zdarma, takže nebylo potřeba chodit za byznysem žádat o peníze, stačilo to nainstalovat a začít používat.

Prosím tě, pro ty mladší z nás – co je to Reporting Services?
Reporting Services byly předchůdcem Power BI, potažmo report serveru. Uměly page-novat reporty, což bych přirovnal k Excelu, dobře zvládaly tabulky, filtry, práci s parametry apod. Už tehdy uměly tzv. mobilní reporty – předchůdce dnešních vizualizací v Power BI. Vizuálně to na tu dobu vypadalo hodně pěkně, ale tvorba reportů byla komplikovaná, protože data musela být velmi dobře připravená. Už to nebylo jako v Power BI, kde lze používat DAX a tvořit kalkulace dle potřeby.

Tehdy to umělo základní sumy a průměry, takže data musela být pečlivě připravená a report vyžadoval velké množství datasetů. Dnes pro Power BI stačí jeden velký dataset, kde si mohu metriky dopočítávat.

Takže jste nemuseli žádat o rozpočet navíc, což je obrovská výhoda. Byl nějaký tlak na to s reporty pracovat? Čím jste začali? Vzali jste nějaký use case či oddělení, nebo jste šli stylem one size fits all? Jak to probíhalo? Představuji si, že Saska má stovky zaměstnanců.

Už v té době existovala sada neautomatizovaných reportů – nějaké skripty běžely nad datovým skladem, exportovaly se do Excelu, z toho se dělaly prezentace a ty se každé pondělí dopoledne posílaly celou firmou. Takže začáteční baterie use caseů a reportů byla velká. Samozřejmě, jak jsem říkal, že nás bylo tři, nemohli jsme všechno hned předělat, ale postupně jsme šli podle jednotlivých oddělení a představovali jsme jim, jak funguje automatizovaný reporting, co od nás mohou očekávat a co jsme schopni nabídnout.

Kdy z Reporting Services vzniklo Power BI?
Poměrně záhy, asi po půl roce fungování Reporting Services, kdy jsme tvořili mobilní reporty a page-native reporty, jsme přešli na Power BI. To otevřelo širokou škálu možností, jak data zpracovávat efektivněji a vizuálně lépe.

Bylo to úplně bezbolestné, protože Reporting Services byly technologickým předchůdcem Power BI? Předpokládal bych snadnou migraci či upgrade.

Vlastně nešlo o přímou migraci. Mobilní a page-native reporty zůstaly zachovány a přidala se nová kategorie Power BI. S Power BI jsem předtím neměl zkušenosti, tak jsem se to musel učit, ale není to raketová věda a zvládne to pár kurzů.

Problém přišel nedávno, když jsme přešli na novější verzi report serveru, která přestala podporovat první mobilní reporty. Ztratili jsme tím asi deset reportů a museli je rychle předělat do Power BI. To nás zaskočilo. Musím říct, že jsem to i trochu oplakal, protože můj první report, který sloužil pět let, jsme tímto ztratili, ale technologie se vyvíjejí a teď je to dobré.

Mělo něco společného více než jen verze? Například nějaká konkrétní funkce nebo princip, který se teď už nepodporuje?

Podklad pod reporty zůstal stejný, bylo to čistě o tom, že přestali podporovat danou technologii, tedy vizualizace.

Jak dlouho vám trvalo to přenastavení? BI reporting je věc, která nikdy není hotová, vždy je co vylepšovat, ale jaký jsi vnímal pomyslný konec první etapy zavádění BI reportingu a Power BI v Sasku, kdy jste si řekli, že už se to povedlo a můžete řešit složitější věci?

Za mě je to kontinuální proces, který nikdy nekončí. Přicházejí nové technologie, jako Microsoft Fabric, takže budeme pokračovat i v budoucnu. Nicméně jsem hlavně rád, jak se nám to na začátku povedlo nastavit. Po prvotních nedokonalostech jsme to tak vyladili, že reporting, jak jsme ho tehdy nastavili, funguje do dnes. Můžeme se tak věnovat dalším důležitým projektům z hlediska byznysu Sasky.

Chápu, že práce nekončí nikdy, ale kdy se vám podařilo nahradit původní infrastrukturu, na kterou byli lidé zvyklí – například týdenní cyklus v mailu s PDF pro všechny? Byl tam milník, kdy jste to zastavili, protože už to lidé měli v Power BI a předchozí pohled byl zastaralý?

Odhaduji, že základní sadu reportů jsme měli automatizovanou asi po roce. Uživatelé, kteří měli historicky přístup do datového skladu, nadále tam spouštějí vlastní skripty a tvoří ad hoc analýzy. Není úplně naší úlohou dělat každou ad hoc analýzu v BI. Naše role je pak pomáhat tuto ad hoc analýzu automatizovat, vylepšit a zdokonalit report.

Během toho prvního roku jste museli udělat i hodně technologické práce, stavět trubky atd. Byly nějaké technické obtíže, lessons learned, na co dát pozor pro posluchače, kteří teď zavádějí Power BI reporting?

Kromě technologického nastavení reportingu byl zlomový bod, když jsem ráno přišel do práce a nemusel jsem se bát, kolik reportů není aktualizovaných. Zavedli jsme tzv. auto-refresh, kdy se report, který nebyl úspěšně aktualizován, automaticky znovu snaží aktualizovat. Po několika neúspěšných pokusech přijde alert analytikovi, aby se na to podíval.

Další komplikací bylo, že datový sklad nemusel být vždy spočítán v osm hodin ráno, tak jsme přidali další vlny refreshů, například v deset hodin. Nebylo to ideální, protože jsme pak refresovali i reporty, které už byly úspěšné, ale podařilo se nám refresh navázat na dokončení jednotlivých částí datového skladu.

Když jsou data v datovém skladu připravena, refresh reportů se spouští postupně podle priority. Když dojde k problémům, funguje auto-refresh, který to zkouší znovu.

Kde tuto logiku držíte? Nad datovým skladem, nějakým ETL či pipeline, přímo v Power BI?

Logika běží v jobech nebo triggerech přímo v datovém skladu a joby spouští refresh na report serveru. Je to tedy propojené mezi datovým skladem a report serverem.

Já rád, že po roce jsi si mohl přispat ráno bez stresu z nereportovaných dat a žádných starostí. Co bylo dál? Nyní se dostáváme k regulatornímu reportingu, což byla významná záležitost, že?

Přesně tak, do této fáze mi přišel „šrapnel“ v podobě regulatorního reportingu.

Možná lehce odkážu na díl s Martinem Košinou, který je Vaškovým nadřízeným a kde se rovněž o regulatorním reportingu a jeho významu pro Sasku mluvilo. Co to ale znamenalo z tvého pohledu, z pozice někoho, kdo zavádí BI? Mluvíme o roce 2019 a nové legislativě.

Ta nová legislativa vám dala nové povinnosti jako herní firmě, že?

Ano, naše prvotní představa byla, že vytvoříme jen další report, kam budou chodit lidé z ministerstva se podívat na data. Nicméně to nebylo tak jednoduché, protože požadavky a reportní vyhlášky byly velmi komplexní. Největší problém pro nás byl, že data chtěli třikrát denně, takže jsme nemohli využít současnou strukturu datového skladu a museli jsme vytvořit paralelní nový datový sklad primárně pro regulatorní účely.

Takže jste začali budovat nový datový sklad. To nezní tak hrozně, až na to, že se jedná o paralelní stack, tedy vše se dělá dvakrát. Co bylo ještě složitého?

Data, která regulatorní orgány vyžadují, jsou rozeseta po různých systémech („all over the place“), a je třeba je konsolidovat. Navíc šlo o granularity nebo detailnost dat, která byla mnohem větší, než co jsme dosud měli v datovém skladu.

Můžeš popsat, jaká kritéria a detaily se musely řešit? Aby si posluchači mohli představit složitost.

Například v kurzových sázkách bylo třeba reportovat změny kurzů. Tyto kurzy se mohou měnit každou sekundu, což je obrovské množství dat. Nebo u loterií, kdy do té doby byla základní jednotkou tiket, který mohl mít pět až deset sloupců. Pro regulátory jsme museli jít do detailu a říct, který konkrétní sloupec byl výherní, kdy uživatel výhru vyzvedl, kdy na ni vznikl nárok. Shrnout všechny tyto informace bylo potřeba, aby vznikla jedna transakce, kterou jsme pak posílali na ministerstvo.

Na druhou stranu, pokud jde pouze o granularitu dat, mám pocit, že to je zároveň inovační. Když jdeš do většího detailu tiketů a máš data třikrát denně místo jednou, mohl z toho být i benefit pro Sasku jako takovou. Je to tak, nebo ne?

Za mě určitě ano. I když to na první pohled nemusí být zřejmé, tato změna byla motivací a inspirací pro další rozvoj.

(texte končí zde)

Regulatorní reporting nemá pro firmu žádný byznysový přínos, negeneruje vyšší tržby a tak dále. Co se týče, jak jsem mluvil o kurzových sázkách a o těch live kurzech, tak to byly třeba první real-time data, která jsme začali zpracovávat. Takže zase jsme se vůbec posunuli k real-time datům do cloudu, což předtím jsme také úplně neřešili.

Kdybychom přišli s regulatorním reportingem o rok později, tak byste asi šli o rok později také do real-time? Možná bych řekl, že ano, protože těch use case v té době moc nebylo a tady to byl právě jeden z prvních, který nás tam doslova dokopal. A teď vlastně ten real-time data, to je už standard. Dá se říct, že vyhláška, která nás donutila nasadit regulatorní reporting, od té doby funguje, ale práce zatím je hodně, protože všechna data už nám tam tečou v reálném čase.

Zpočátku to byly nějaké batchové zpracování třikrát denně. Super, gratuluji. Co to pro vás znamenalo? Mám pocit, nebo historicky to bylo tak, že batchové a real-time zpracování jsou odlišné infrastruktury, znamenalo to úplně jiný přístup k práci s těmi daty. Co platilo pro jedno, neplatilo pro druhé a museli jste tam…

Bylo to skoro černobílé. Mám pocit, že s technologickým pokrokem existuje škála od velmi pomalého datového skladu, kdy čekáte na data, přes zpracování, které je někdy real-time, pro které real-time use case vlastně nemáte a nepotřebujete, takže jestli dostanu data za 20 sekund nebo za dvě minuty, je mi to vcelku jedno, po reálné zpracování, kdy to probíhá v řádu vteřin. Tady jste měli jasně zadaný refresh třikrát denně. Máš za to pocit, že už je technologicky jedno, jestli reporting pracuje s třemi refreshi denně, nebo dává smysl realizovat to v reálném čase, protože práce navíc už nebude tak velká? Nebo to je spíše otázka postupného zlepšování – začali jste s třemi refreshi, někdo řekl, že není problém dělat to šestkrát denně, pak dvanáctkrát denně a nyní třeba každou minutu?

Přímě doufám, že v tomto regulatorním use case se to otočí spíše opačně, tedy z třikrát denně na jednou denně. Nicméně právě to real-time jsme zaváděli s výhledem, že ministerstvu by nemuselo stačit třikrát denně a mohli by chtít například každou hodinu. Proto jsme začali budovat řešení na real-time datech.

Samozřejmě datové transformace jsou poměrně složité, protože struktura toho, jak nám data poskytuje dodavatel a jak je požaduje ministerstvo, je značně odlišná. Proto zpracování v plném real-time je náročné a reálně tato real-time data měníme na batchová a třikrát denně zpracováváme tato batchová data.

Rozumím. Ještě jsi zmínil dodavatele, o kterých mluvil i Martin. Když říkáš dodavatele, myslíš tím dodavatele od SaaSka vlastně?

Ano, SaaSka funguje jako systémový integrátor, kde máme dodavatele na kurzové sázky, loterie, losy, hráčské účty atd., takže jde o poměrně široké spektrum dodavatelů. V tomto ohledu je regulatorní reporting specifický tím, že v době jeho zavádění jsme nebyli schopni svěřit všechno jednomu dodavateli. Samozřejmě máme s dodavateli smlouvy, že musí být regulatorně compliant, nicméně datové balíčky či sady, které posíláme ministerstvu, jsou složené z dat různých dodavatelů. Proto jsme zodpovědnost za tvorbu těchto datových balíčků museli nést my, museli jsme je skládat u nás.

To chápu, v situaci, kdy se jedná o takto rizikovou, stěžejní a kritickou oblast, je přirozené mít věci pod co největší kontrolou. Co to znamenalo technologicky? Bylo potřeba to politicky „oběhat“, požádat dodavatele o změnu API, a museli sáhnout do vlastních API i produktů, aby vám to mohli poskytnout? Na druhou stranu je regulatorní reporting, takže to nebylo jenom na vás. Předpokládám, že se jednalo o upgrade a evoluci, kterou museli i dodavatelé podstoupit, ne?

Přesně tak, SaaSka je specifická tím, že kompletnost produktů je obrovská – pokrývá kurzové sázky, loterie, sázení, až po například Polosy. Troufám si říct, že v takovémto rozsahu to žádný jiný provozovatel neposkytuje. Proto hlavním problémem byla komplexnost a množství dodavatelů. Jednání s nimi byla složitá a hrál tam i časový tlak při spuštění. V té době nás bylo třeba pět lidí, takže část řešení regulatorního reportingu jsme outsourcovali. To s sebou opět přineslo své problémy.

Kolik jste na to měli času?

Začali jsme asi rok dopředu, ale ještě jsme třeba nevěděli, že to bude povinné, takže hlavní práce probíhala asi půl roku. Nicméně dostat data v požadované struktuře od dodavatelů byl náročný úkol. Na samotnou realizaci pak bylo času velmi málo vzhledem ke komplexnosti.

Další výhodou regulatorního reportingu bylo, že šlo o úplně první data governance, protože datové balíčky, které jsme odesílali ministerstvu, procházely jejich základními validacemi. Občas se stalo, že nám vrátili chybu, a my jsme museli řešit datovou kvalitu. Pro mě to je jeden z důvodů, proč samotné data governance vzniklo jako projekt v rámci celého BI.

Nyní udělám reklamní vsuvku na tvoji kolegyni Zdeňku Teplou, se kterou jsme natáčeli díl právě o data governance, kde můžeme jít větší do detailu.

Líbí se mi to v tom smyslu, že „obstacle is the way“ – tedy překážka je cesta. Asi jste moc neřešili, že máte novou povinnost, a musíte vybudovat nový datový stack na základě pravidel někoho, kdo ten byznys nikdy nedělal. Samotné to nepřineslo byznysovou hodnotu, ale byl to jakýsi impulz ke změně.

Ty jsi říkal, že to bylo vlastně základem data governance a kontroly kvality dat, která jste posílali. Jak si to mám představit? Byla tam nějaká „checklistika“? Nebo si sahali třeba do finančních přiznání? Jak fungoval kontrolní mechanismus na straně ministerstva? Jak jste dostávali zpětnou vazbu? Posílali jste třeba CSV nebo něco podobného?

Bylo tam vícero typů kontrol. V rámci těch CSVček, které tvoří datový balíček, kontrolovali i vazby mezi jednotlivými CSV, například cizí klíče, a také obsah souborů. Například muselo být vždy vyplněné pole sázek a podobné údaje. Šlo tedy o jakési „data health checky“.

A co vás ta zkušenost naučila? Jak to máte dnes? Kopírujete ty validace na vlastní straně? Přijali jste je?

Takhle. Také jsme je chtěli nasadit na naši straně, ale odezva těch kontrol na straně ministerstva je aspoň stejně rychlá, někdy jen o trochu pomalejší, než jsme schopni udělat vlastní kontroly. Proto jsme se více zaměřili na to, zavést kontroly, které ministerstvo sama neprovádí. Například porovnáváme objem sázek proti účetnímu systému, tedy SAPu, a na jejich základě děláme rekonsiliace. Ministerstvo pak samozřejmě také kontroluje výstupy z regulatorního reportingu, daňová přiznání a podobně.

Podíváme-li se na zpětnovazební smyčku, co tě tato zpětná vazba naučila? Přijde mi zajímavé, že dostáváte zpětnou vazbu z vnějšího pohledu na vlastní data. Naučilo tě to něco, například nepřemýšlet složitě?

První pocit není díky moc, ale je to spíše tak, že musíme jít za dodavatelem, řešit s ním, proč chyba vznikla. Někdy jde o jednorázovou chybu, kterou jen pošlu znovu. Jindy je příčina hlubší a vyžaduje delší vývoj na straně dodavatele.

Vzhledem k tomu, že jsme systémový integrátor, často musíme jít o úroveň níže, přímo k některému dodavateli či do jejich API a tam to řešit. Samozřejmě, protože logika datových transformací je poměrně složitá, může se stát, že nějaký datový záznam „propadne“ a vyhodí chybu.

Rozumím. Takže regulatorní reporting byl základem data governance. Proč je pro tebe data governance důležité téma? Jak to vnímáš z pohledu BI týmu?

Mám pocit, že data governance bylo dlouho řešeno podobně jako dokumentace ve softwarovém inženýrství – něco, co se odloží na „až budu mít čas“. Naopak se stavělo rychle, bez kudrlinek. Zdá se mi, že se to hodně změnilo. Když se hned na začátku udělá kvalitně a promyšleně, ušetří to práci později.

Jak jsi data governance vnímal dříve a jak dnes? Co to pro tebe znamená?

Jsem rád, že se toho ujala Zdeňka, jak už jsem zmínil v pohovoru. Vidím v tom přínos hlavně pro uživatele reportů a dat obecně. Například co se týče rekonsiliací – už se nestává, že by měsíčně přicházel někdo ze SAPu a oznamoval rozdíl a my pak museli dohledávat data měsíc zpětně. Nyní máme informaci hned druhý den, což umožňuje rychlé řešení a snižuje dopad do přepočítávání datového skladu.

Projekt data governance byl také enablerem dalšího projektu – self-service BI.

Dobře, ještě se zeptám – co pro tebe jako původně specialistu a nyní team leada data analytics znamenalo, když přišla Zdeňka a začala řešit data governance? Co jsi musel změnit v každodenní práci? Bylo to jen o tom, že jsi lépe dokumentoval, nebo to byla větší změna?

Bylo to i pomocné při rozšiřování týmu. Když přijde někdo nový, tak už existující data jsou někde zdokumentovaná. Já tu pracuji dlouho, data mám pod kůží, takže nemusím denně koukat do datového katalogu, abych zjistil význam polí. K reportingu již z pozice team leada nemám tolik přímý vztah, ale pro nováčky je dokumentace velmi užitečná, například při dopadových analýzách. Obsáhnout celou šíři dat v datovém skladu pro jednoho člověka je nadlidský úkol.

Byla to také určitá úleva?

Ano, data governance dává odpovědnost za data co nejblíže tam, kde data vznikají, a k těm, kdo chápou jejich kontext. Často tak odpadá situace, kdy někteří obchodní uživatelé házejí chybu na jiné a naopak. Místo toho se výměna mění na konstruktivní opravy dat.

Je to také jakýsi marketplace – „shit in, shit out“ – který nelze plně kontrolovat, na rozdíl od tradičního BI světa, kde bylo možné upozornit na chybný repozitář a opravit jej.

Není to tak, že se můžeš soustředit více na svou práci a nemusíš držet v hlavě všechny sloupce všech reportů?

Ano, samozřejmě. I když se ještě objevují dotazy od kolegů, co každý sloupec znamená, zapojení obchodních uživatelů přináší výhodu, že data už neříkají: „To jsou vaše data, máte tam chybu“, ale spíše: „Máme tam chybu, pojďme ji opravit.“ To vládnutí nám pomáhá a snižuje tlak na BI tým.

To mi hezky navazuje na závěrečné téma, protože v BI týmu poslední dobou řešíte hlavně buzzword self-service BI. Co pro tebe self-service znamená? Kdy jste tomu projektu začali tak říkat a jak jste k tomu přistoupili?

V podstatě se spojily dva projekty dohromady. Jak jsme se bavili, reporting i regulatorní reporting přináší i určitou technologickou zátěž, která souvisí s přechodem do cloudu, například do Power BI service.

Ještě tě zastavím u minulosti – několikrát jsi zmínil, že jste byli napřed tři, pak pět lidí ve firmě, jak to vypadá nyní? Kolik vás je v BI oddělení, celkem?

V celém BI je nás asi 16, z toho je 7 BI analytiků.

Super, důležité je, že nemáte problém často si kolegové volají externí firmy na pomoc a dodavatele. Je to zajímavý přístup, jak zrychlit vývoj a rozvíjet interní organizaci – ti, co ovládají danou kategorii, to naučí ostatní. Nejste tedy jenom vy sami.

Kolik má SaaSka přibližně lidí?

Nyní už přes 500, SaaSka tedy vyrostla nejenom BI.

Takže 7 analytiků, 16 lidí v BI na půl tisícovou organizaci, super. Myslím si, že nastává moment, kdy si BI uvědomí, že nestíhá, protože příležitostí a use caseů stále přibývá a tým nemá kapacitu růst lineárně s nimi. V takovém okamžiku chce tým přehodit část technologické inovace a práce na byznysu na koncové uživatele. Jak vám se to dařilo? Jaké byly první kroky?

Historicky mají jiná oddělení často své šikovné analytiky, kteří ovládají technologie, například SQL, a jsou schopni tvořit ad hoc reporty. My jim chceme poskytnout další nástroj, jak s daty pracovat, jak je vizualizovat a sdílet s kolegy, aby nebylo třeba posílat data e-mailem. Jde o jakousi demokratizaci dat, aby data nebyla v rukou pouze BI, ale i dostupná všem, kdo je potřebují.

Rozumím. Co to znamenalo na technické úrovni? Pořád jste na datovém skladu, který je on-premise?

Ano, základní core data máme stále v datovém skladu. Power BI service nám připadala jako vhodná platforma…

Něco mírnějšího než ten report server, teď už je možnost nějaké administrace, řízení přístupu, schvalování těch datových sad, takže tam chceme už kalů těch governance nástrojů.

Tak tam vůbec to self-service přijde. To už jste si ale museli jít pro peníze, ne? To už jste neměli licence v PEK-u. A to je zajímavý moment. Tam byl taky takový break trošku. Proč chcete chodit do cloudu? Budete potřebovat licence Power BI service. Máte tady on-premise vlastně zadarmo. Proč tam chodit? Samozřejmě v tom servisu jsou aktualizace každý měsíc, kdežto na report servu jednou za rok. Ale asi až doteď tam nebyly nějaké zásadní technologické vychytávky, které by nás nutili do toho cloudu přejít. Samozřejmě teď s Microsoft Fabrics to vypadá, že se to změní. Ale zase je to dar shůry.

Celá Saskia přišla na O365 licence, myslím E5 nebo jak se to jmenuje. A tam už právě součástí je licence například na Power BI service. Takže to byl zase takový dáreček, který nám umožnil to daleko rychleji rolovat, než bychom museli v rámci projektu žádat o nějaké peníze na licence a tak dále.

Jak to teď vypadá teda se self-service? Když bychom se podívali, tak máte to postavené zase na nekončící práci, rozumím, ale v jakém je to stavu teď a v jakých krocích jste to stavěli?

Tak samozřejmě z hlediska našich kapacit jsme se rozhodli nějakým pilotem s jedním oddělením vytvořit pro ně první datovou sadu, na které se budeme oba dva učit – jak my z hlediska administrace, tak oni samotní pracovat s nástroji, publikovat reporty a tak dále.

Podle čeho jste vybírali to první oddělení?

Tak základní předpoklad byl, že v tom oddělení už je nějaký datový analytik, třeba umí SQL, jsou tam ochotní se doučit nástrojům typu Power BI, je tam zodpovědný za business reporting, takže on vytvářel tu datovou sadu, jelikož nejlépe zná data z digitálního marketingu. Takže tam se to takhle zkombinovalo, vlastně ta znalost dat s inovativním přístupem Power BI service.

Takže jste začali oddělením, říkal jsi, digitálního marketingu. A i proto, že tam bylo spoustu cloudových dat, že už jejich infrastruktura byla online de facto.

Ano, tam byla také velká využitelnost těch cloudových dat, takže tam dává smysl zůstat v cloudu.

Takže to byl váš pilot, co vás pilot naučil? Co vám řekl „ano“, co bylo „ne“? Nebo to bylo přesně tak, jak jste čekali, že je to jenom o tom, si to protrpět, vysvětlit a overcommunicovat?

Bylo tam pár takových momentů, ještě některé věci nejsou úplně uzavřené. V podstatě jsme si definovali tři základní typy uživatelů. První jsou běžní uživatelé, kteří maximálně změní barvu v grafu nebo vymění koláčový graf za sloupcový.

Druhá skupina, na kterou jsme se zaměřili v pilotu, dostala dataset, který spravujeme, máme ho také ošetřený v Data Governance, aby s ním mohli dobře pracovat. Takže už nad tímto vytvořeným datasetem dokázali generovat vlastní reporty a publikovat je.

Tam nás překvapil velký zájem těch uživatelů, kterým jsme poskytli hotové datasety, posunout se do třetí skupiny, což je nejpokročilejší skupina analytiků, kteří si budou schopni datasety tvořit sami, propojovat data a tak dále.

Takže nás trochu překvapil vysoký zájem o přechod do této skupiny.

Co nás ještě překvapilo bylo, že jsme očekávali, že každý, kdo dostane datovou sadu, vytvoří dva, tři reporty a bude je chtít sdílet kolegům. To se úplně nestalo. Lidé si začali ty reporty tvořit třeba pro sebe, do své osobní složky. Netouží tolik výstupy sdílet a někdy tu datovou sadu nepoužívají ani pro pravidelný reporting.

Dělají tam nějaké ad hoc dotazy, které jsou pro mě náhradou datových kostek, protože ty jsou také dobré právě pro ad hoc dotazy. Takže mají přístup k datům, podívají se do ní jednorázově, ani nepotřebují report nějak publikovat.

Naším cílem rozhodně není vytvořit 2000 reportů, když mají stejný pohled, nebo jen jiné barvy.

Teď říkáš 200 reportů, to je počet reportů, které spravujete, nebo které vznikají? Nějaké pravidelné automatizované reporty, kolik jich máte?

Na tom on-premise se blížíme k číslu 200. A počet lidí, kteří využívají Power BI, nebo aktivních uživatelů BI?

Myslím, že je jich tak do 30. Takže polovina? Polovina části organizace? Gratuluji.

Ještě k té třetí skupině – chápu tu „noobskou“, která mění si barvy a co není v UI Power BI na hlavní obrazovce, to neřeší. A ta druhá – to už jste vyčistili, dali jim datová hraní, která jsou hezky popsaná, takže jste jim vytvořili hrací hřiště.

Mě zajímá ta třetí, když už si dávám dataset i k sobě a jsem na úrovni opravdového BI analytika, mají ti lidé přístup k datovému skladu? Typicky, jak jsi mluvil na začátku, měl jsem pocit, že warehouse je úzké místo.

Samozřejmě s přístupem souvisí i zodpovědnost, takže neumožníme pouštět do datového skladu šílené reporty, aby vůbec nedošlo k zahlcení jeho výpočetních kapacit. Takže tvorba datových sad třetí skupiny souvisí s určitými pravidly ohledně data governance. Datasety, které budou vytvářet, musí být dobře popsané, aby nevznikalo, že třeba Pepův report ukazuje tržby s jiným číslem než Pavelův report.

Pro nás je důležité, aby každý report ukazoval stejná čísla.

A to bylo řešeno na úrovni data governance, nebo na úrovni ODS, případně přístupových práv k warehouse?

Aby čísla seděla, to primárně považuji za úkol data governance. Data sady, které vznikají, musí být dobře popsané. Biznisové pojmy, které již existují v technické recenzi, jsou implementovány i v nových datových sadách. Standardizace musí být.

Super. Dostávám se k poslednímu tématu – jak do toho celého zapadá cloud a on-premise? Co vám teď běží v cloudu, co on-premise, jaký máte plán a jak vidíš výhody a nevýhody obou forem řízení a provozu?

Z historického pohledu stále core data máme on-premise v datovém skladu. Nicméně nová data nebo data, u kterých méně hlídáme kvalitu, z mého pohledu není nutné házet do datového skladu.

V cloudu jsou široké možnosti z hlediska škálovatelnosti a také z hlediska stavby reportů na cloudových datech. Určitě si pohráváme s konceptem data lake a podobně.

To zní, jako by vám data governance v těchto stínech řešila spoustu věcí.

Má spoustu aspektů, které jinak musí člověk řešit v rámci organizace pořád dokola, potvrzovat, dohadovat se, dělat data contracts a podobně, takže ano, data governance je v tomhle obrovský pomocník.

Co mě ještě těší na tomhle celém projektu self-service je to, že to není tak, že by přišel generální ředitel a řekl: „Hele, udělejte nám self-service,“ ale je to iniciativa, která vznikla u nás v rámci BI.

Za mě je Saskia skvělé prostředí, kde je prostor pro vlastní projekty.

Takže jste si to vykopali sami?

Vykopali jsme si to sami. Za mě nejtěžší je najít na to kapacitu a prioritu, protože jsou tu i regulatorní projekty a podobně. Ale konečně po těch několika letech od spuštění on-premise reportingu se to teď daří.

Obrovskou radost mám z toho, že uživatelé si toho váží, rádi se zapojují a jsou nadšení. Mám radost, když uděláme report a uživatel přijde a vidíte, že je spokojený a report používá. To je moc hezká zpětná vazba.

Gratuluji, to je příjemné zadostiučinění. Touto cestou vyzývám naše posluchače, aby se nebáli posílat zpětnou vazbu.

Co vás čeká dál? V jakém je to stavu? Jaké jsou další milníky a překážky na vaší cestě? Co tě čeká příští rok?

V rámci self-service nás čeká rollout do dalších oddělení, plus školení nových pokročilých uživatelů ve stávajících odděleních, kteří už se self-service pracují.

Obecně je novodobý trend v cloudových technologiích a data lakech, takže chceme zkoumat, jak stavět reporty přes cloudové technologie.

Microsoft Fabrics je obrovská novinka, kterou chceme prozkoumat – co nám umožní, v čem pomůže.

Například se mi líbí myšlenka automatických refreshů – když mám data v data lakehouse, nemusím je ručně řídit či kontrolovat, ale když přibudou data v data lakehouse, tak se automaticky zobrazí v reportu.

Na to jsem zvědavý, jak bude fungovat.

Děkuji, že jsi sdílel vaši cestu a zkušenosti. Ať se daří, ať jsou uživatelé spokojení a reporty přinášejí byznysovou hodnotu. Děkuji moc, Vašku.

Super, díky za pozvání.

To je všechno. Díky, že jste doposlouchali až sem. Děkujeme také našim partnerům: Big Hub, Recombii, Intex, Nanoenergies, Lifesport, SASCE, Bystrýtům, Colors of Data, Revolt BI a Gudatě.

Jestli vás zajímá víc z české datové scény a globálních datových technologií, zanechte nám svůj e-mail na datatalk.cz nebo se přijďte podívat na některý z našich meetupů na datamesh.cz.

Ať vás provází data!