Podcast

Dobrý den, jmenuji se Jirka Vicherek.

Ahoj, tady Karel Šmáněk, vítáme vás u dalšího dílu podcastu Datadolok.

Naším dnešním vzácným hostem je Michal Buzek, který vede BI oddělení ve skupině Heureka Group.

Ahoj, Michale.

Ahoj, kluci.

Michal je z mého pohledu významná osobnost české datové scény. Určitě jste se s ním setkali na nějaké datové konferenci nebo v některém odbornějším podcastu.

Téma, které bychom dnes s Michalem chtěli probrat, je BI oddělení, jeho role, budování a ideální místo v rámci struktury firmy.

Než se do toho pustíme, jak ses vlastně k tomuto tématu dostal? Jaká je tvoje datová cesta? Než ses stal pánem všech dat v Heureka Group?

Já jsem začal po vysoké škole v roce 2007 pracovat v Seznamu a působil jsem tam skoro deset let. Z toho posledních sedm let jsem měl za úkol vybudovat analytické oddělení. Poté jsem strávil krátkou epizodu v Moneta Money Bank na celý rok. Protože mnoho lidí ze Seznamu odešlo do Heureky, znal jsem se s Tomášem Bravermanem trochu a na jedné akci jsme se potkali a bavili o datech. Když jsem v Monetě nebyl spokojený, dostalo se to k Tomášovi, sedli jsme si, diskutovali o datové budoucnosti, strategii a vizi Heureka Group a domluvili jsme se, tak jsem do Heureky přišel.

Proč řeším, kde by to oddělení mělo být a jak by mělo fungovat v rámci firmy? Je to velké téma, protože jsem si za ty roky prošel spoustou různých zařazení. Myslím, že to, jak to fungovalo na konci v Seznamu a jak to nyní funguje v Heurece, je to nejsprávnější. Mimochodem jsem četl skvělou knihu Chief Data Officer Playbook, kde popisují velmi podobné příběhy a vysvětlují, jak by to mělo správně fungovat a kde by měl být zařazen BIA nebo BIA leader v organizaci firmy.

Takže toto je pro mě nyní velké téma a myslím, že se o něm tak moc nemluví v různých datových podcastech. Ty se spíš zaměřují na technologie, kdo má lepší modely a služby, lepší ETL a další softwarové věci, ale o tom, jak ovlivňovat byznys, být zařazen ve firmě a jak rozvíjet analytiky, se tolik nemluví.

Michale, možná dříve než se dostaneme k tomu, jak jsi říkal, že rád pracuješ pod nejvyšším byznysovým vedením, z kolika lidí se vlastně skládá tvůj tým, jaké tam máš role a zda máte nějakou hierarchii?

Teď ne, mám dvacet lidí. Z nich čtrnáct je datových analytiků. Máme v Čechách dva týmy datových analytiků. Dále mám dva lokální analytiky v Maďarsku a na Slovensku, protože tam máme své kanceláře. Koupili jsme v těchto zemích cenové srovnávače.

Působíme v devíti zemích a je složité dělat analytiku z Prahy, protože pražští nebo čeští analytici neznají specifika jednotlivých trhů. Proto jsme se asi před třemi lety rozhodli do každé země přijmout jednoho analytika.

Historicky v těch zemích používají trochu jiné databáze či struktury databází těch srovnávačů, které jsme odkoupili. Je proto lepší, když lidé znají místní trh a lokální data.

Dále máme dva webové analytiky a tým čtyř lidí, včetně teamlídera, který se stará o nástroj price monitoringu, tedy o monitoring cen a spokojenost klientů s tímto datovým nástrojem.

Celkem tedy máme dvacet lidí, včetně cenových srovnávačů, webových analytiků a BI analytiků.

Je to takový datový customer success tým, který zajišťuje spokojenost a fungování price monitoringového nástroje, který jsme do Heureky získali po akvizici firmy Datavaps. Ta vyvíjí nástroj price monitoringu a také nástroj pro automatizaci biddingu na cenových srovnávačích.

Když se vrátíme k druhé straně mince – ty jsi tedy manažer celého týmu. Jaká je tvoje preference, být zařazený pod IT, byznysem nebo pod generálním ředitelem? Kde vidíš největší přínos?

Můj příběh je takový, že v Seznamu jsme začínali v obchodním oddělení, byli první dva analytici. V roce 2008–2009 se zakládalo analytické oddělení, nebo Pavel Zima…

A pak tam byl ještě analytik na marketingu. Když přemýšleli, kdo by to mohl sestavit a dát dohromady, nabídli to mně a já jsem byl moc rád, takže jsem to přijal.

První roky jsme byli pod obchodním oddělením. Postupem času nám ale přibývalo dalších agend, protože i obchodníci potřebují znát čísla z webové analytiky či chování uživatelů a chtějí mít argumenty na schůzky s klienty.

Začalo se práce více zaměřovat na marketingový výzkum, uživatelské výzkumy a podobně, které hodně pomáhaly produktovému oddělení. Proto jsme převzali i marketingovou analytiku a výzkum trhu.

Pak přišel Michal Vodák, můj současný kolega v Heurece. Přišel do Seznamu, byl také velmi datově orientovaný, a tak jsme se přesunuli do marketingu, který spolupracoval s více odděleními.

Po Michalově odchodu asi po třech letech analytické oddělení spadlo pod CEO, nejdříve pod Michala Fajkse, později pod Pavla Zimu. Myslím, že to bylo nejlepší rozhodnutí.

Když je analytické oddělení uprostřed firmy, těsně u CEO, vysílá to silný signál, že data mají pro vedení firmy velký význam.

Nejde jen o byznysové či salesové analýzy, ale pracujeme s daty ze všech možných koutů firmy, dáváme je dohromady, kontext je nesmírně důležitý.

Není vhodné se dívat jen na marketingová, salesová nebo produktová data, ale kombinovat je a přinášet produktovým lidem pohled na salesová data a naopak.

Tato provázanost byla v Seznamu za poslední tři roky skvělá.

Když jsem přecházel do Heureky, s Tomášem jsem již řešil, že bych byl součástí vedení přímo pod ním a převáděli jsme tam ty zkušenosti ze Seznamu.

Navíc Tomáš je velkým heavy userem dat, sleduje všechny nástroje a čísla, což práci značně usnadňuje oproti Seznamu, kde nebylo vedení tolik datově orientované jako v Heurece.

Co se týká organizačních konfliktů – často bývá BI součástí IT oddělení, které si tuto oblast nárokuje, zatímco moderně, jak jsi sám říkal, je BI spíše pod generálním ředitelem.

Máte mezi IT a BI nějaké rozpory, nebo spolu dobře spolupracujete? Jak to funguje?

Musím říct, že CTO Lukáš Putna, který také dříve pracoval v Seznamu, mi na začátku hodně pomohl.

Je to dobře popsáno také v knize Chief Data Officer Playbook, kde je uvedeno, že CIO nebo CTO často spravují data, protože vývojáři vytvářejí databáze a produkty, které data generují.

Technický člověk se ale často nezajímá o byznys, necítí ho a nespolupracuje s marketingem na jejich potřebách.

Byl jsem rád, že Lukáš mi pomohl nastartovat Kebolu, náš BI nástroj. Museli jsme ujistit administrátory, sysadminy a vývojáře, že data nejsou nebezpečná, nástroj má certifikace a je bezpečný, takže se ho nemusí bát.

To je velmi důležité, mít podporu CTO.

Zorganizovali jsme osvětu ve firmě o přínosech BI oddělení.

Vývojáři jsou nakonec rádi, protože dříve museli programovat reporty na požádání různých oddělení, což nebyla prioritní práce.

Nyní jim BI analytici umožňují více se soustředit na produkt samotný.

S Lukášem jsme od začátku na stejné notě a on mi velmi pomohl.

Proto si myslím, že nejlépe je, když je BI uprostřed firmy, blízko vedení, protože se tak dostává ke všem oddělením a lépe chápe jejich potřeby.

Vývojáři často o marketingu a sales nemluví.

Co se týče fungování oddělení, pracujete spíše na projektové bázi, kde máte rozpočet na každý projekt, nebo berete BI spíše jako produkt, který kontinuálně rozvíjíte?

V Heurece fungujeme podle OKR frameworku. Nevím, kolik lidí toto zná, zejména datově orientovaní lidé nebo ti z digitálního světa, ale zjednodušeně máme na každý rok dopředu stanovený rozpočet a tři hlavní cíle, které chceme jako firma dosáhnout.

Jednotlivé týmy by měly tyto roční cíle rozdělit na kvartální a pracovat na nich.

Ve firmě je spousta týmů, kterým může pomáhat nejen produkt a vývoj, ale i sales, marketing či content.

Každé oddělení si musí nastavit kvartální cíle tak, aby podporovalo roční strategii firmy.

My často jsme součástí jednotlivých kvartálních projektů.

Podle našeho OKR mástra Jirky Langra jsme facilitátory („enabler“) týmů, protože týmy často potřebují data či analýzy, aby mohly dál postupovat.

Před začátkem každého kvartálu se s těmito týmy bavíme, jak jim můžeme pomoci, nebo naopak oni za námi přicházejí s požadavky – třeba chtějí zlepšit nějaké metriky, sledovat nové indikátory nebo dělat nové analýzy.

To je jedna věc.

Druhá je, že jsme v BI oddělení nastaveni i s vlastními rozvojovými cíli, například zlepšit něco v Kebole či udělat pořádek v nějakých datech.

Celkově jsme hodně zapojeni do cílů jednotlivých týmů a celé firmy a zároveň rozvíjíme naši vlastní denní datovou agendu.

Máte tedy rozpočet, a jakou část přidělíte na interní rozvoj a technologický dluh, to je na vás?

Přesně tak, máme svůj oddělový rozpočet na nástroje, licence, rozvoj lidí a podobně.

Na rok vím, kolik můžu utratit.

Většina nákladů je vázaná na licence jako Google Analytics 360, Kebolu nebo vizualizační nástroje.

Záleží jen na tom, jak moc chceme s daty růst a kolik budeme platit za Kebolu či jiné nástroje.

To jsi zmínil, jak prioritizujete práci.

Co pro tebe znamená každodenní náplň práce?

Myslím, že nejdůležitější věc, kterou by měl umět každý head of BI, BI director nebo chief data officer, je navazování vztahů s lidmi ve firmě, tzv. „relationship building“.

To znamená, že by BI člověk měl dobře rozumět všem druhům byznysu – marketingu, salesu, produktu – aby se mohl s lidmi bavit o jejich každodenních problémech a společně s týmem hledat řešení.

Když firma začíná s BI, často nejde o to dělat revoluce, ale postupně pomáhat a udržovat směr.

BI přináší nové postupy, procesy a nástroje, které zlepšují, zrychlují a zefektivňují práci lidí.

V další fázi se mohou přidat nové modely, statistiky či pokročilé datové přístupy, pokud je firma na to připravená.

Můj denní chleba je chodit na schůzky, bavit se s lidmi o problémech napříč odděleními, podílet se se s managementem na dlouhodobých strategiích.

Strategie je často spojená s daty a analýzami.

Naposledy jsme vytvářeli pětiletou strategii pro devět zemí, což bylo hodně dat ke zpracování a analýze.

Jsem tedy u strategických debat, ale také u těch operativních na denní úrovni, protože mým cílem není dělat revoluci, ale postupně firmě pomáhat daty napříč všemi odděleními.

Podporovat lepší a rychlejší rozhodování a získávat důležité informace.

Mohu uvést příklad.

Naše contentové oddělení spravuje katalog s 25 miliardami produktů.

Potřebují vědět, na které produkty lidé nyní chodí a kde mohou být obsahové problémy.

My jim to umíme říct: například, že uživatelé často chodí do určitých kategorií, ale u konkrétního produktu je problém, třeba špatně funguje strojově učený algoritmus kvůli nesprávnému párování nabídek.

Tito lidé mají každý den přístup k těmto datům a mohou opravit největší problémy, které automatizované technologie nezvládly zachytit.

Všechny tyto požadavky jsou spojené s OKR?

Má to příznivý dopad na zisk firmy, nebo děláte i analýzy pro zlepšení uživatelského zážitku?

Děláme to i pro zlepšení uživatelského zážitku.

Spolupracujeme s produktovým oddělením, zejména na A/B testování.

A/B testy samozřejmě souvisí s UX, ale zároveň sledujeme hlavní KPIs – zda test zlepšil příjmy, chování uživatelů či jiné metriky.

Mohu tedy říct, že podporujeme produkt a UX oddělení v jejich úsilí o zlepšení uživatelského zážitku.

Zároveň ale hodně analýz a dat je spojeno s plněním klíčových ukazatelů výkonnosti – KPIs.

Peněženka je samozřejmě na prvním místě a důležitá, ale v produktu jsou silní zástupci uživatelské přívětivosti, takže všechno je potřeba vyvážit.

Jak jsi říkal, že se snažíš budovat vztahy napříč korporací – mám zkušenost z jiných korporací, že to bylo občas těžké.

Když se snažíš budovat něco nového nebo něco, co lidé neznají a necítí se v tom komfortně, musíš od nich tahat nápady.

Snažíš se jim vysvětlovat, co by mohli dělat, dělat osvětu, aby získali zpětnou vazbu a věděli, že jim můžeš pomoci.

Stává se ti to? Máte tlak od lidí na nové nápady?

Zda se musí strany snažit hodně pomáhat? Vlastně z celé historie B.I.K. ze začátku samozřejmě vždycky byly nějaké úkoly pro tu analitičku, která tam byla jediná vlastně v Hevrek, takže když jsem nastupoval, měla toho víc, než byla schopná zvládnout.

Nicméně, když jsem nastoupil, sešel jsem se se všemi team leadery, nechal si provést onboarding, jak funguje například contentové oddělení, co dělají v marketingu a tak, abych to trochu nasál a pochopil. Vždycky jsem se nazkoušel bavit třeba i s Kastiákem naším o tom, jaké jsou jejich problémy, například řešení podvodných recenzí, co jim zabírá nejvíc času, co je těžké odhalit, kde mají skutečné potíže.

Pak jsme se zavřeli u nás v oddělení a řekli si, že tyto problémy jsou, ale toto můžeme řešit tak, že jim propůjčíme tři tabulky v databázi, zobrazíme jim dashboard a oni tak místo hledání podvodné recenze pěti kliknutími v administraci teď vidí vše na dashboardu, který je každý den aktualizovaný. Mohou to jednoduše jen promazávat a nemají s tím tolik práce.

Abych se vůbec dostal do firmy, musel jsem se těmito lidmi bavit, to jsou ty schůzky a potkávání se s nimi. My máme například každý čtrnáct dní schůzku s marketingovým oddělením, jednou schůzku s produktovým oddělením, bavíme se a já se jich neptám, jaké analýzy pro ně můžeme udělat, ale co plánují, co budou nasazovat, jaké mají problémy, co si myslí, že bychom jim mohli pomoct. Neříkám jim, jestli by chtěli tato data nebo tamta.

Bavíme se o tom, co oni řeší, jaké mají problémy, jaké mají potřeby, a snažíme se jim datově nějak pomoci a přesněji cílit. Myslím si, že po tomto kolečku začaly úkoly přibývat. Teď máme v backlogu v Asaně, našem tiketovacím nástroji, úkoly na 40–50 lidí, které bychom potřebovali zpracovat, ale vždy je to o prioritizaci.

Víš, jaké jsou cíle firmy, takže víš, že některé věci mohou počkat kvůli jiným důležitějším. Jak mi říká Tomáš, pro analytiky je vždy více úkolů, než jsou schopni zvládnout, a tvým úkolem jako manažera je to správně prioritizovat. To je hezké.

A co je vlastně vaše role? Dodavatelská, že to dodáte a doděláte, nebo máte tam power usery, kterým připravujete platformu nebo data, a oni s nimi už pracují sami? Vlastně to záleží na oddělení. Například v marketingovém oddělení jsou lidi, anebo v Yieldovém oddělení, kteří se snaží vytěžovat bannerový prostor, mají lidi, kteří s daty pracují, znají Google Analytics a Google Ads. Tito lidé musí datům rozumět, aby dobře řídili výkon Hevrek v Google světě, v reklamním prostředí.

Tam už tedy jsou uživatelé dat dál. Naopak například obchodní oddělení nebo contentové oddělení potřebují data připravit snadno dostupná, aby nad nimi nemuseli přemýšlet, stačí jim ukázat důležité věci, kterým se mají věnovat. Takže tam data více připravujeme.

A navrhuješ jim sám následné procesy? Co s tím reportem dělat? Nebo už designuješ report podle toho, jestli se bude otevírat jednou měsíčně na poradě, anebo každý den jako dashboard? Měli jsme workshop s contentovým i customer success oddělením před začátkem fiskálního roku. Prohlédli jsme si roční cíle firmy. Jedním z těch konkrétních cílů je traffic acquisition – získávání nové návštěvnosti.

Přemýšleli jsme, jak contentové oddělení může pomoct zvýšit traffic, větší návštěvnost. Zjistili jsme, že některé záležitosti jsou propojené s marketingovým oddělením, protože pokud chceš být vidět v Google Ads, v produktových inzerátech na Google, musíš splňovat určité požadavky, například mít vhodnou velikost nebo kvalitu obrázku, vyplněný EAN kód, GTIN.

To jsou všechno věci, které contentové oddělení má na starosti, ale ani si neuvědomují, že ovlivňují kampaně na Google. Já jsem si to totiž dokázal spojit. Pozvali jsme marketingové lidi, bavili jsme se o typech reportů a věcech, které mohou content správně opravit, aby marketing měl daleko větší možnosti zobrazování v produktových inzerátech na Google.

Takové věci jsme společně řešili. Před tímto rokem jsme si s každým oddělením udělali rozhovor, podívali jsme se na tři roční cíle a bavili jsme se o tom, jak mohou přispět a jak my jim můžeme pomoct vylepšit některé věci, aby k dosažení těch cílů oddělení přispěla.

To znamenalo, že jsem organizoval dva workshopy pro oddělení. Hodně se to týkalo dat a byznysu a to je má role.

Co se týče škálovatelnosti, protože každé oddělení, když je ještě relativně malé – a vnímám, že ještě jste relativně malé oddělení, i když ne zanedbatelné – tak má problém, když se více projektů rozjede najednou. Jak to řešíte? Řešíte jeden, dva projekty najednou, nebo každý analytik má svůj vlastní?

Máme systém plánování práce v Asaně, kam může kdokoliv zadat úkol nebo ticket. Každý týden máme poradu – team leadři se svými lidmi – a plánují si práci na další týden, aby věděli, kolik toho zvládnou odbavit. V tomto plánu víme, pokud je nějaký důležitý projekt, a samozřejmě v této fázi můžeme prioritizovat, aby se nestalo, že slíbíme 50 věcí a zvládneme jich pouze 12. Každý týden tedy diskutujeme o práci, projekty jsou rozděleny do menších úkolů, které se odhadují metrikou typu tříček SML (small, medium, large), takže víme, kolik práce má každý analytik na příští týden a zda něco potřebuje k dokončení.

Takto práci řídíme.

Nedávno se nám například stal projekt marketplace na Heurece, který měl za cíl rozjet a více podpořit marketplaceový business, nejen z PPT tlačící lidi do e-shopu, ale chtěli jsme víc akvizicí e-shopů do marketplaceu. Přitom byly jiné projekty, které někdo potřeboval.

OKR nám však výrazně pomáhají, protože víme, že marketplace je jeden z hlavních cílů firmy na daný rok. Takže můžeme říci, omlouváme se, toto neuděláme, protože se budeme soustředit na marketplace projekt.

Takhle práci řídíme. Nevím, zda to vysvětluji srozumitelně, ale myslím, že ano.

Jak jste to řídili před zavedením OKR? Jaký byl jiný systém? Toto zní velmi logicky a pěkně, ale jistě to má i nějaké nevýhody a ne každá firma si takové řízení může dovolit. Musí mít dobře fixované organizace, strukturu, role.

Mně osobně hodně pomáhá, že víme, co je pro firmu důležité. Potkal jsem spoustu firem, například pro jednu velkou značku jsem dělal e-commerce audit jako vedlejší projekt. Tam jsem přesně viděl, že oni nemají vyjasněné priority a je těžké říct, komu dát data za jakým účelem.

Tam třeba salesák potřebuje pomoct s jedním úkolem a šéf marketingu s jiným, a věci se hromadí. Pak je to na BI manažerovi, aby vycítil, koho pomoci více a kdo má větší přidanou hodnotu pro firmu. Manažer musí lidem vysvětlit, vzít je dohromady a přimět k pochopení, že jeden úkol může chvíli počkat, pokud nemá pořádnou hodnotu.

Je to tedy spíše o rozhledu a rozhodování head of BI, který prioritizuje. S tím frameworkem v naší firmě si myslím, že to není růžové, že to vždy funguje, stále přicházejí urgence od salesů nebo jiných oddělení, kteří chtějí data „na včerejšek“, například kvůli velkému klientovi.

Snažíme se tedy balancovat.

A co role toho, že jsi přímo pod CEO? Dostával jsi někdy příkazy, například v případě hádek kolem tebe, pro koho máš pracovat? Stanovili ti, co musíš dělat, i když jsi nesouhlasil?

Nikdy se mi to nestalo. Možná mám štěstí, ale v Hevrece je vedení na stejné vlně. Když například řeknu šéfovi produktů, že musím udělat něco pro sales, vždy se domluvíme. Samozřejmě někdy proběhne i hádka, ale většinou převládá hodnota – buď finanční nebo jiná přidaná – a ostatní ustoupí, případně něco odložíme.

Mnoho takových situací řešíme, diskutujeme o prioritách, ale nikdy se nestalo, že by management opustil zasedání s neshodou. Máme pravidlo, že pokud se něco dohodneme, všichni za tím stojí a dále to nepodkopávají nebo nepodporují negativně mimo zasedání.

Nevím, zda to všechny firmy mají takto, ale je to i zásluha Tomáše Sijiho, že dal dohromady lidi, kterým jde o to, aby se dobře spolupracovalo.

Na toto navazuje role OKR – framework je tak dobrý, jak dobře ho firma využívá. Diskuze o cílech firmy a prioritách, tři hlavní priority, velmi pomáhají firmě fungovat jednotně, řešit spory mezi odděleními a táhnout za jeden provaz.

Ve Hrvéce jsou OKR určité už mnoho let v produktu a ve vývoji, ale do celé firmy se zaváděly zhruba před rokem a půl. Samozřejmě to nebylo prvoplánově dokonalé. Byly tam spory o to, co je business usual a co jsou zlepšení, což není růžové, ale je to proces.

Pamatuji si, že před čtyřmi lety jsme měli devět cílových objektivů na celý rok. Měli jsme skoro všechno.

Postupně jsme dospěli k tomu, že je potřeba mít jen tři zásadní cíle, aby se zaměření firmy nerozptylovalo a nevznikaly hádky o prioritách.

S tímto přístupem je komunikace do firmy jednodušší, všichni ví, co je důležité, jsou sladěni a již se nevyskytuje tolik problémů s prioritizací.

Ale nikdy to nebylo růžové. Ze začátku byla větší potíž hlavně u non-R&D oddělení, která se musela učit, jak plánovat OKR a rozlišovat zlepšení v HR nebo v zákaznickém servisu. Tito pracovníci často jen plnili úkoly od partnerů a nepřemýšleli o zlepšení procesů.

Postupem času se ale tento přístup mění. Někteří lidé odešli, protože s tím nebyli smíření, ale to je život.

Dnes už po dvou až třech letech vidím velký přínos OKR pro firmu.

Ale nechci tvrdit, že když někdo teď OKR zavede, vše bude hned dokonalé jako u nás. I my jsme tímto údolím prošli.

Doporučuji znát priority firmy, nemít jich nekonečně mnoho, ale raději menší počet – to je obecně platné.

Je to strmá cesta, ale firma z toho časem profituje.

Co se týče růstu týmu: Ty to trochu zametl pod koberec, když jsi říkal, že musíte prioritizovat, řídit to, ale když vidíš enormní nárůst požadavků, že se firma opravdu stává data driven, jaký je plán růstu týmu? Budete nabírat?

Udělali jsme asi největší nábor v poslední době s cílem, aby oddělení BIA nedělalo jen interní analýzy, ale i analýzy pro naše partnery, což jsou e-shopy nebo značky.

Předpokládali jsme, že to bude hodně práce, hodně požadavků, a to se potvrdilo. Požadavky přicházely od celého oddělení, nebo od customer success, kteří jednají s klienty.

Obzvlášť v těžkých časech, když přijde krize, tak e-shopy a značky chtějí víc informací a více řeší efektivitu a možnosti, jak pracovat lépe.

Zhruba v listopadu jsme oddělili tým na dvě části – Internal Analytics a Client Analytics. Ty druhé již nejsou data inženýři, ale hledáme lidi, kteří umí data číst, najít v nich příběh a mají dobrý byznysový cit pro klienta, s nímž analytik komunikuje.

Tito lidé jsou na trhu vzácní. Hodně je datových inženýrů, kteří propojí data, aby vše fungovalo a byl automatizovaný výstup, ale najít někoho, kdo má zároveň data inženýrské dovednosti, umí data dobře číst a zároveň dát klientovi hodnotu a bavit se s ním jako partner – to je náročné.

Snažíme se tedy nabírat i juniornější lidi, kteří nemají technologické zázemí, ale mají třeba historický background ze salesu, bizdevu nebo jsou sociologové, takže na data myslí jinak než jen databázově.

Což s sebou přináší tlak na jejich upskilling a rozvoj v týmu.

Jak to řešíme? Zavádíme kompetenční model, inspirovaný naším vývojem a CTO Lukášem Putnou, kterého už jsem zmiňoval.

Je to trochu jiný CTO – byl vývojář a technolog, ale hodně dbá i na soft skills a rozvoj lidí. Sám je velký learner, snaží se stále učit a rozvíjet, už možná víc v měkkých oblastech, manažerských dovednostech.

… (text dále pokračoval, ale zadaný obsah končí zde).

Něco ovlivňuje celou tu firmu. A oni ve vývoji rozdělili takový projekt nebo koncept, my jsme to nazvali jako životní cesta vývojáře nebo jako kompetenční model těch vývojářů. A vlastně jsme to teď převzali u nás v oddělení, kde máme čtyři role: datový analytik, webový analytik, pricing analytik a data quality specialista, což je ten technický customer success tým price monitoringového nástroje.

Pro každou z těchto rolí jsme vydefinovali pro juniora, mediora a seniora nějaké kompetence, které by ten člověk měl mít. Toto nám teď strašně pomáhá v tom říct si, kde ten člověk právě je. Jsou tam jak softové věci, například business doména nebo chápání byznysu, tak i hard skillové věci.

Nyní chci, aby během dvou týdnů všichni team lídři sesbírali informace, že ten člověk se cítí být na této dovednostní úrovni – například na juniorním levelu, ale v určité dovednosti třeba na mediorním. Budeme mít tím pádem jasnou představu, kde ten člověk aktuálně je. Když ví, že je na mediorní pozici a chce být senior, případně by chtěl do budoucna něco přidat nebo se rozvíjet, přesně ví, kam se má posunout, protože má nějaký guideline.

Ten kompetenční model jsem nedával dohromady já, ale tvořil jsem ho s těmi lidmi – hlavně s těmi seniornějšími, kteří jsou v jednotlivých rolích, nebo s team lídry, takže vznikl přímo od nich. Teď je důležité vzít tento kompetenční model, uvést ho do praxe, napojit ho na reálné úkoly, které lidé řeší, a doporučit například, když někdo řekne „hele, já neumím moc BigQuery“, a vidíme, že máme v Asaně spoustu úkolů na BigQuery. Pak team lídr řekne „jsem junior, nebo to vůbec neumím“, tak junior se musí naučit tyhle základní věci, a proto mu budu dávat úkoly, kde tyto juniorní dovednosti využije. Poté může postupně pokračovat dál.

Přesně víš, když máme nějaké nástroje, které používáme, nebo technologie, co má junior, medior a senior umět. To se teď snažíme u nás rozjet. Strašně tomu věřím; myslím si, že rozvoj lidí je důležitý, protože lidé odcházejí z firmy kvůli dvěma důvodům: buď mají špatného šéfa, nebo se v té firmě neposouvají a neučí se nové věci. To první věřím, že máme v pořádku, a na tom druhém teď pracujeme, protože chceme, aby se lidé posouvali a měli pocit, že v té práci v Heuréce má smysl.

Jak ověřujete, zda se něco naučili? Máte certifikace, názor seniornějších kolegů nebo nějaké objektivní měřítko? Když je někdo junior, má vždycky buddyho nebo svého teamleadera, takže často se to pozná tak, že při týdenním plánování úkolů víš, že jako senior ti by určitý úkol zabral jeden den, ale ten člověk dostane tři dny, a pokud to ani za tři dny nezvládne, víš, že se to nenaučil, nebo že s ním má problém.

Můžeš mu poté nabídnout školení, další podporu nebo to řešit společně, protože třeba něco nechápe, nebo mu něco nejde. Tímto způsobem týdně plánováním úkolů odhalíš, jestli se ty věci, které se měl naučit, skutečně naučil nebo ne. Protože mu dáváš úkoly, které by měl podle svých slov umět.

A podle čeho se učí? Každá firma má své zaběhlé standardy, protože jednu technologii lze dělat různými způsoby. Samozřejmě existují nějaké market standardy, ale máte například knowledge base, kde člověk, když chce začít s Pythonem, si projde první, druhou, čtvrtou a desátou kapitolu, a měl by být na očekávané úrovni vyhovující firmě.

Toto nám ale moc nefungovalo. Například jsme lidem platili datové kampy nebo kurzy na platformách jako Coursera a podobně, ale přišel člověk a dříve jsme měli rozvojové cíle na půl roku, třeba „posunout se v Pythonu“, a bylo obtížné složitě hodnotit, zda se posunul nebo ne. Teď se snažíme, aby to byly reálné věci z každodenní práce analytika, a když je Python součástí kompetenčního modelu, tým lídři vyhodnocují dovednosti mediorních či seniorních lidí například tak, že onboardují nováčky a věnují se jim, pomáhají jim.

Například jeden náš team leader natočil video, v němž onboardoval nováčka na BigQuery, a to video používáme jako materiál, který si kdokoliv ve firmě může pustit, když se chce posunout v BigQuery. Začínáme vytvářet vlastní školicí materiály, píšeme dokumentace, best practices, ukázky nejlépe optimalizovaných SQL dotazů, kde jsou použity určité funkce. Když nováček naráží na neznámou funkci v SQL, může se zeptat nebo si vyhledat dokumentaci například ke Snowflake.

Cesta obecných kurzů nám moc nefungovala; snažíme se edukaci řešit vlastními zdroji uvnitř firmy tak, aby byla spojena s konkrétními praktickými úkoly.

Zmínil jste několik technologií – Kebula, Snowflake, BigQuery, Python a podobně. Daří se vám najít na trhu lidi už na úrovni mediora nebo seniora, nebo se vám osvědčilo nabírat spíše juniornější lidi a vychovávat je? BigQuery je dost specifický; dříve bylo úzce spojeno s prémiovou verzí Google Analytics, kdy jsi měl dotazy v BigQuery, ale už se to mění, už to nemusí být jen o GA datech.

Nedávno jsme nabrali dva skvělé datové analytiky – jeden přišel z pojišťovny, druhý z Airbanky. Tam s BigQuery sice nepřicházeli do styku, ale protože byli medióři, rozuměli databázím a SQL, rychle se do BigQuery dostali. Není to žádná raketová věda, má trochu jinou syntaxi nebo jinak strukturované tabulky než například MySQL, ale tyto věci se dají relativně snadno naučit.

Všechno, co je okolo SQL, je jednodušší než naučit lidi Python.

Jaký je váš datový stack? Máme core nástroje, jako je Kebula, která běží nad Snowflake. Když někoho přijímáme, musí umět SQL a vždy dostane SQL test. Pracujeme hodně s daty z Google Analytics a Google Ads, což jsou googlářské nástroje, jejichž data jsou na BigQuery. Některá data si přehazujeme do Snowflake a Kebuly, ale některé transformace řešíme přímo v BigQuery.

Na vizualizaci používáme Google Data Studio, což je pro business lidi podle nás dostačující, ale pro analytiky už ne vždy, takže řešíme, jaký vizualizační nástroj do budoucna použít.

Máte preferovaný nástroj? Například Looker Pro?

Máme nabídku od Google na Looker Pro pro naši firmu. Pracujeme s Data Studiem (teď známým jako Looker Studio) a využíváme ho k distribuci dat například klientům, ale má to mnoho nevýhod, protože jde o free verzi. Looker je velice drahý a vhodný spíše pro větší firmy.

Například Vojta z Muse, který pracuje v datameshi, říkal, že Looker používá také Product Board a Muse, což jsou úspěšné startupy, ale cena Lookeru je opravdu vysoká.

Google nyní přišel s Looker Pro, který oproti free verzi Data Studia nabízí zákaznickou podporu, ale my potřebujeme semantický layer. Například jedeme ve fiskálních rocích, potřebujeme kalkulované metriky, ideálně sdílené napříč projekty, což Data Studio Pro zatím neumí.

Data Studio umí výborně data spravovat, ale je slabší ve vizualizaci a v možnostech tvorby dashboardů. To chceme nyní vyřešit. Rádi bychom nástroj, který má jak semantický model nebo layer, tak i exceluje ve vizualizaci.

Používáte Power BI?

Ano, Power BI používáme. Pracujeme také s GoodData, občas používáme Tableau, například jeho free verzi, a Data Studio je hodně v oblibě mezi marketingem nebo ve vývoji oddělení. Používáme ho například i pro klienty, ale například O2 nemají Google účty, takže buď by si museli založit vlastní Google účet, což není možné, nebo jim pošleme odkaz, který může unikat. To se nám nelíbí.

Proto jsme šli do spolupráce s externí firmou Datalook, která s Kebulou také rozvíjí statistiky pro klienty jako Shoplet, a domluvili jsme se, že oni zajistí administraci klientů a obsah bude v Power BI, protože s tím mají zkušenosti.

Power BI však má nevýhodu, že desktopová aplikace je dostupná pouze pro Windows, naše firma však je založená na Apple zařízeních (Mac), takže vždy potřebujeme mít jeden až tři notebooky Windows, když někdo potřebuje připravit report. Tohle mi stále není jasné, proč Microsoft nevytvořil klienta Power BI i pro Mac.

Jak udržujete všechny ty nástroje v chodu, když jich používáte pět od různých dodavatelů?

To je pro nás také velké téma. Snažíme se mít nejdůležitější reporting v GoodData, protože do něj koukají investoři nebo management, ale nevadí mi, když ostatní oddělení používají například Data Studio. Důležité je, aby data pomáhala lidem ve firmě dělat lepší a rychlejší práci.

Hlavní nástroj v BI je Kebula. Řešíme nyní přechod na multiprojektovou architekturu, protože když jsme před pěti lety začínali v Čechách v Heuréce, nebylo žádné Data Governance, kdo kam má přístup, co Kebula může mít a podobně.

Když jsme později koupili další země, nebo naši investoři koupili další srovnávače, vytvořili jsme projekty pro Adriatic Region, Maďarsko, Bulharsko, Rumunsko, a data se do nich přenášela, ale finálně jsme chtěli mít všechno na jednom místě, tak se data přelévala do Heuréckého hlavního projektu v Kebule.

Z toho jsme usoudili, že je to neudržitelné. Rok jsme o tom diskutovali a pomáhala nám externí firma Bystry, datová agentura či konzultační společnost, která má zkušenosti například s Economií a Dovou. Pomohla nám pochopit, jak to lépe uchopit a Kebula nám také poskytla workshop, jak to dělat lépe.

Nyní přichází čas na rozdělení, přepsání a optimalizaci dat. Mohli bychom to udělat rychle za vysoké náklady – například dva miliony Kč – na najmutí agentů či konzultantů, kteří by to rychle provedli. Jelikož rozpočet tak vysoký není, šli jsme druhou cestou: vymysleli jsme koncept s externistou a Bystrytem, jak data rozdělit, lépe spravovat, aby to bylo flexibilní a udržitelnější.

Postupně nyní vývojáři refaktorují kód, aby byl lepší a novější – myslím, že to má docela dobrou paralelu.

Jaké jsou vaše drace zjištěné lessons learned, obecné nebo specifické pro Kebulu, které by mohly zajímat i ostatní?

Nápad Kebuly byl mít data ze všech možných koutů firmy, abychom je mohli propojovat a díky tomu přinášet byznysu daleko lepší přehled o situaci. Pracujete nejen se SAS daty, ale i s produktovými, abyste mohli říct „v procesu to funguje dobře, ale v produktu méně“ a tak dále.

Takže my jsme nabrali miliardu datových zdrojů na jedno místo a teď tam máme desítky extraktorů, což znamená různé aplikace, které ti sem každou noc zasejí data. Pokud něco spadne, je složitější najít bug, protože data jsou provázána.

Nyní jdeme cestou rozdělení dat do domén, stažení vrstvy extrakce, aby bylo jasné, co a v jaké fázi selhalo. Například první zóna je landing, kde děláš kopii dat z původních zdrojů, a teprve poté stavíš hodnotu.

Víme, že vstupní data v další fázi ovlivňují reporting nebo distribuci dat, a když selže extrakce, víme, kde opravovat. Momentálně máme složité špagety SQL kódu a transformací, které je těžké rozklíčovat.

Chceme tedy data rozdělit do jasných škatulek, mít přehledný data lineage a lepší správu souvislostí.

Je to velký projekt, o kterém už rok diskutujeme, a teď začínáme s jeho realizací.

Jedna věc je implementace, druhá dokumentace a governance – to také řešíte?

Dokumentace je problém, nevíme, jestli…, ale myslím, že s tím bojuje hodně firem…

Databáze, které vývojáři v oddělení výzkumu a vývoje vytvářejí, jsou často nedostatečně nebo špatně zdokumentované. Jednou z prvních věcí, kterou doporučuji každému analytickému oddělení, které vzniká, je začít si vytvářet vlastní dokumentaci zdrojů dat. Například můžeš mít sloupeček s ID, ale nevíš, co přesně znamená identifikátor číslo dva, tři nebo čtyři, takže se musíš obrátit na vývojáře a zeptat se.

Je to důležité. My používáme Confluence, stejně jako vývojáři, kde máme vlastní prostor a projekt, ve kterých si děláme vlastní dokumentaci. Ta je rozdělena podle obchodních domén a databází. Dokumentace je pro mě zásadní, protože mám s tímto problémem zkušenost a často, když se bavím s různými analytiky, narážím na to, že dokumentace chybí a analytici ji také často nechtějí vytvářet, ale je to opravdu důležité.

Když totiž oddělení roste a už nejste jen dva, kteří vědí, co znamená konkrétní ID, potřebujete znalosti jednoduše předávat. Dokumentace je klíčem ke všemu. Nyní třeba v týmu s multiprojektovou architekturou chceme připravit data pro marketingové oddělení, které má ambici psát si vlastní SQL dotazy a dělat vlastní analýzy. Chceme tedy vytvořit vrstvu dat speciálně pro marketing, kde budou ty důležité informace už pohromadě, a pak si s nimi mohou pracovat, jak chtějí.

Co se týče udržitelnosti dokumentace, když ji děláš manuálně, což v Confluence evidentně děláte, může se stát, že jednou přestane být aktuální nebo její údržba zabere až 80 % času vývoje. Máte tohle promyšlené? Jak to plánujete řešit?

Musím přiznat, že zatím ne. Rád o tom budu diskutovat, nebo když natočíte další díl, určitě si to poslechnu. My to prostě děláme v Confluence.

Náš vývoj právě přechází z monolitických MySQL databází na Google Cloud Platformu a při těchto změnách aktualizujeme dokumentaci. Udržování dokumentace je však zodpovědností lidí. Naštěstí máme týmového lídra, který na to dbá a všichni víme, že je to důležité, ale lidé ji nechtějí psát. Nemáme na to zatím žádný recept, máme pouze statickou dokumentaci v Confluence.

Jaké argumenty používáš, aby ses přesvědčil o nutnosti dokumentace?

Je to podobné jako u mé snahy vysvětlit dětem, že si mají čistit zuby – není to jednoduché. Když ale v týmu řekneš: „Rosteme, znalosti je třeba předávat dál a nechceme nováčkům pořád vysvětlovat to samé“, pak chápou smysl dokumentace. Díky ní ušetříš čas s onboardováním nových kolegů, protože místo toho, aby jsi každému zvlášť vysvětloval, kde najít data, mu dáš dokumentaci s popisem tabulek a vztahů.

Díky tomu mohou nováčci pracovat rychleji a ty ušetříš spoustu času s mentoringem a vysvětlováním. Lidé to chápou, když jim to takhle vysvětlíš. Nestává se nám, že by někdo dokumentaci odmítal.

Také například lidem, kteří odcházejí z oddělení za novými výzvami, říkám: „Před odchodem ještě prosím rozpracuj dokumentaci“. Nechci po nich víc práce, ale chtěl bych, aby po nich zůstalo něco pro firmu a že neposilují dluh v podobě nezaznamenaných znalostí. Lidé to většinou ochotně udělají, aby měli čisté svědomí.

Jak řešíte projektové řízení menších úkolů? Řeší to celý týmový lídr, nebo máte nějakou administrativní podporu? Často se totiž při agilním přístupu definují kritéria ukončení úkolů, někdy je dokumentace součástí těchto kritérií. Zajišťujete to nějak?

Ano, to je dobrý příklad. Máme projekty, třeba jako vyhodnocování „Shop roku“ nebo „Produkt roku“. Data streamy nám umožňují určit, který produkt je v dané kategorii nejlepší. Když přijde nová metoda výpočtu nebo jiný projekt, týmový lídr s člověkem, který na tom pracuje, rozdělí projekt na menší úkoly.

Platí u nás pravidlo, že úkoly, které by měly trvat déle než tři dny, je potřeba rozdělit na menší části, aby bylo lépe vidět, zda se postupuje, nebo někdo někde zůstává „viset“. Tímto způsobem je práce lépe kontrolovatelná.

Při nové práci je jedním z úkolů sepsání dokumentace, protože víme, že danou věc předtím nikdo neřešil.

Toto zatím funguje dobře.

Jaké máte vize do blízké budoucnosti, v následujících měsících?

Máme dva hlavní směry. Interně chceme udělat lepší Kebulu a lépe organizovat data používaná v BI. To je dlouhodobý projekt, který jsme již zahájili.

Druhá věc se týká našeho klientského analytického týmu, tedy analytiků, kteří se věnují požadavkům klientů – značek, e-shopů nebo agentur. V době obtížnější ekonomické situace firmy hledají data čím dál více. Na schůzky se často chtějí připojit i analytici, protože obchodníci a pracovníci zákaznické podpory nejsou tak zkušení v byznysu klientů. Analytici se před schůzkou připraví, nastudují trendy na trhu a mohou s klientem diskutovat detailněji.

U velkých e-shopů, jako jsou Datart, Lidl nebo Alza, chceme mít s klienty pravidelný kontakt – denní, měsíční až kvartální – co se týče dat. Máme analytika, který s klientem komunikuje, rozebírá trh a jeho vývoj.

To vnímáme jako velkou přidanou hodnotu Heuréky. Nechceme být jen prodejci, ale partnerem v jejich byznysu. Klienti to oceňují. Můžeme jim dát vhled, co se na trhu osvědčuje. Například řekneme: „V prodávaných televizích je silná značka Samsung, ale existuje tu nový hráč s televizemi ve střední cenové kategorii, které zatím u vás nejsou v nabídce.“ Taková data jim pomáhají lépe se orientovat.

Jak řešíte téma datových produktů a zda vidíš, že se firmy v této oblasti posouvají? Často slyším, že technologické firmy staví datové produkty nebo testují model data-as-a-service, ale po mnoha letech není vidět výraznější rozvoj.

Je to zajímavé, mnoho firem by to mohlo dělat, ale nedělají to. Při nastartování našich datových produktů a reportů jsem čekal větší zájem ze strany e-shopů a značek, ale na prodej dat je potřeba šikovný člověk, který dobře rozumí jejich prodeji, což není jednoduché najít.

Naštěstí se nám podařilo najmout dva lidi z agentury GFK, která provozuje výzkum trhu a údaje o prodejích v elektrosegmentech, což nás velice urychlilo.

Je pravda, že většina firem data neprodává, ale my cítili hodnotu od začátku. I když to první dva roky nešlo, věřili jsme tomu. V posledních dvou letech to začalo výrazně růst a znám, že třeba Rohlík nabízí značkám prodejní data o jejich a konkurenčních produktech, Mews má data o hotelovém trhu.

Kivy zase chtěl nabízet data aerolinkám a letištím, ale kvůli covidu to nevyšlo a docházelo k personálním změnám. Nevím, zda firmy v těchto oblastech mají uvnitř dost lidí, kteří věří datovým produktům, nebo zda to prostě ještě neobjevili jako nový zlatý důl a zdroj příjmů.

Můj názor je, že firmy, které mají data o trhu nebo zákaznících, by měly začít přemýšlet o prodeji těchto dat. Neříkám, že jde o velmi zásadní příjmy, ale je to další menší příjmový proud a především obrovský benefit z hlediska budování vztahů se zákazníky.

Klienti tak firmu vnímají jinak – nejste jen ti, co chtějí data „vzít“, ale zároveň jim něco hodnotného vracíte. Byl bych rád, kdyby více firem začalo data sdílet a vytvářelo protihodnotu pro své zákazníky.

Držíme palce tobě i dalším, kdo se vydají vaší cestou – ať už znamená posílit své postavení ve firmě, ideálně pod generálním ředitelem, nebo začít prodávat data.

Děkujeme, že jsi dnes přišel a podělil se s námi o své zkušenosti.

Děkuji za pozvání. Mějte se.

Děkujeme, že jste si poslechli Datatalk až sem. Jak se vám tato epizoda líbila? Co bychom mohli vylepšit? Koho bychom měli pozvat příště? Napište nám, prosím, svůj názor, ať už na příštím Datameš Meetupu, nebo hned teď na e-mail jirka@datablog.cz.

Pokud se vám epizoda líbila, doporučte ji dál, klikněte na „like“, udělte hvězdičku, odebírejte náš kanál, aby dashboardy svítily zeleně, grafy rostly a všichni stakeholderi schvalovali rozpočty.

Ještě jednou děkuji. Poděkování patří také mým kolegům Nikovi a Iris, stejně jako členům našeho partnerského klubu – Bighubu, DeepNote, Atakamě a Mantě.

Pokud máte návrhy, tipy na hosty, témata, pořádáte vlastní akce nebo chcete komunitu podpořit jinak, neváhejte mě kontaktovat.

Díky a nechť vás provází data!