Podcast

Dobrý den, moje jméno je Jirka Vecherek.
Ahoj všem, moje jméno je Barbara Hinerová.
Vítáme vás u nového dílu Data Talk podcastu.
Naším dnešním hostem je Petr Žáček, director of product management v Atakamu.
Ahoj, Petře.
Ahoj všem, ahoj všem posluchačům.

Náš dnešní díl se bude zabývat data managementem. Budeme se hlavně dívat na Atakamu, odkud Petr přišel, a jak se vlastně změnil trh, jak se změnily priority klientů, jak se změnila celá tato doména a z něčeho, co mně osobně kdysi dávno přišlo jako nutné zlo a něco škaredého, se stává ústřední věcí celé datové transformace. Tak na to se podíváme.

Ale než se k tomu dostaneme, Petře, pověz nám, jak ses k tomu všemu dostal.

Tak jo, tak já načrtnu svůj životní příběh v Atakamě. Do Atakamy jsem se dostal naprostou náhodou – nevěnoval jsem se programování ani datům. Když jsem byl ještě na škole a zkoušel jsem dodělávat nějaký titul, rozhodl jsem se, že bych měl začít hledat nějaké dobré zaměstnání. Rozhodl jsem se jít směrem technologického konzultanta, protože mi to dávalo smysl.

Ovšem s trochou štěstí jsem se na Job Fairu potkal u stánku Atakamy s některými našimi kolegy, kteří už tady s námi nejsou, ale možná jste o nich slyšeli v podcastu nebo na nějakých eventech. Nadchlo mě, jak působili a co říkali o tom, co dělají. V tu chvíli jsem tomu moc nerozuměl, ale šel jsem na pohovor a nechal jsem se najmout jako tester, i když jsem původně myslel, že budu dělat něco trochu jiného. Oni vlastně moc nevěděli, co se mnou, protože jsem přijel z úplně jiného světa – nic jsem nevěděl o databázích, datech ani o ničem souvisejícím.

Pamatuju si, jak mi můj buddymist na první nebo druhý den řekl: „Tady máš databázi, udělej na něco testy, a pak ji po sobě uklid.“ Byl jsem z toho naprosto vyděšený, protože jsem se bál, že něco rozbiju – ani jsem nevěděl, co znamená „databáze“. Za tu dobu jsem ale ušel nějakou cestu.

Nás tady ještě bude zajímat, odkud jsi přišel, co je ten jiný svět, který tě sem přitáhl, a taky chceme samozřejmě pojmenovat ty kolegy.

Přesně, teď to zní jako religionsistika. Ne, ne, ne. Studoval jsem matematiku, jsem matfyzák a věnoval jsem se matematickému modelování, což je obor mezi matematikou a fyzikou, který mi přišel hrozně zajímavý. Je to něco jako práce s reálnými aplikacemi. Nicméně jsem došel k nějakému svému limitu, kdy mi to přišlo pořád zajímavé, ale neviděl jsem to jako něco, čemu bych se chtěl dál věnovat. Nebyl jsem si úplně jistý, čemu se chci věnovat, tak jsem zkusil ještě jednou matematiku v jiném oboru a uvažoval o doktorském studiu.

Během té doby pro mě ale nejužitečnější bylo zkoušet učit studenty, předávat jim informace, srovnávat si v hlavě složité abstraktní věci a pomáhat jim najít v tom smysl, výhody a užitek.

Opravený text:

Myslím, že to byla zkušenost, která mi pomohla přizpůsobit se některým věcem v Atakamě. Říkal jsem si, že to už asi není ten směr, kterým chci jít, ale že chci dělat něco smysluplnějšího. V začátcích Atakamy jsem to bral tak, že si tam jdu něco vyzkoušet a uvidím, kam půjdu dál. Nakonec jsem u firmy zůstal. Chtěl jsem být konzultant, ale najali mě jako testera, což bylo v pořádku. Zpětně to dává smysl a jsem za to hrozně vděčný, že mě vůbec přijali.

Ještě jsi ale neřekl, kdo tě najímal na job fairu. Ne, nechceme slyšet konkrétní jména. Tenkrát mě najímal Roman Kučera, který byl před pár lety na Data Days a vedl náš AI program. Na stánku byla i Kateřina Leš, která pak přešla do Litu Tušima. Teď si nepamatuji přesně, kde všude je, ale působí na různých místech. Zdravíme Kateřinu do Embedy! Jo, vůbec se nedivím, že jsem se nechal přesvědčit Romanem a Kateřinou na job fairu. Zněli velmi přesvědčivě v tom, že je to dobrá práce s fajn lidmi, a měli pravdu. Když jsem nastupoval, bylo nás asi 60 nebo 70.

Život v té firmě byl samozřejmě jiný než teď a byla to pro mě skvělá příležitost se zorientovat v tomhle světě, něco se naučit a dostat příležitosti. Zpětně vidím jako velkou výhodu začínat tam, kde si může člověk vyzkoušet různé role a vědět, co lidé v té firmě dělají a čemu se věnují. Postupně jsem se dostal k tomu, co jsem původně chtěl – dělat konzultanta, i když jsem tehdy ještě přesně nevěděl, co to obnáší. Pro nás to znamenalo dělat konzultanta při různých projektech data managementu pro klienty a používat naše nástroje, což bylo v pořádku. Člověk sice nepracoval tolik s jinými věcmi, ale občas si na něco sáhnul. Převážně jsme používali naše nástroje k dodávání hodnoty klientům.

Já nejsem typický projektový člověk, jak jsem během kariéry zjistil, ne vždycky jsem správně dokázal dotáhnout věci do konce, takže jsem se víc profiloval jako pre-sale konzultant. Jezdil jsem za klienty ještě před tím, než měli naše nástroje, abych jim ukázal, co nabízíme, vysvětlil, proč je to pro ně užitečné, a třeba ad hoc ukázal něco na jejich datech. Tam se mi skvěle naučila improvizace před publikem, když máte před sebou technické téma a někdo mu rozumí nebo nerozumí, a musíte mu to vysvětlit a pomoci mu to pochopit. To mě posunulo na mé cestě tam, kde jsem teď, protože překládání technických a abstraktních věcí tak, aby jim někdo porozuměl, dělám celý život.

Určitě. Jak dlouho ti vlastně trvala ta cesta od testera k vysněné roli konzultanta?

Tady je opravený a upravený text:

Bylo to rychlejší, než bych asi čekal, protože uplynul asi rok a půl, než jsem začal věnovat nějakým projektům a zapojovat se do konzultantských aktivit. Nicméně, jak říkám, ten čas strávený jako tester, ale i v dalších rolích a při různých výpomocích mi pomohl pochopit ten nástroj. Takže přesun do role konzultanta byl vlastně přirozený, protože jsem se musel začít učit komunikovat s klienty a chápat jejich problémy, ale nástroj jsem dobře znal. Věděl jsem přesně, jak funguje a jak ho používat, což mi pomohlo přizpůsobit se změně.

Konzultanta jsem pak dělal šest, možná sedm let, přesně už to nespočítám, ale určitě šest. Jak jsem již zmínil, občas jsem pracoval na projektech, vedl tréninky a pomáhal zákazníkům nastartovat jejich projekty a začít produkt používat, ale více jsem se soustředil na pre-sale. Hodně jsem komunikoval s klienty a potenciálními zákazníky po celém světě, vysvětloval jsem, jak jim můžeme pomoci, ukazoval přínosy a samozřejmě vedl je k výsledkům.

Dnes tu sedíš jako director of product management, což mě fascinuje a potvrzuje, že vyzkoušet různé role je důležité a najít tu, která člověku sedí nejvíc. Jak jsi se tedy z konzultanta a pre-sale dostal zase na pozici produktového manažera? Jak se přesunout zpátky dovnitř?

Je to vlastně jednoduché. Z konzultanta se PM stane tak, že si myslíš, že současní PM-ové dělají svou práci špatně a že to zvládneš lépe. A to byl můj případ – byl jsem spíš někdo, kdo neumí dotahovat projekty. Samozřejmě jsem se pak naučil to dělat lépe, ale nebylo to moje hlavní preference. Je důležité také říct nahlas, že práce produktového manažera je odlišná od projektové práce a že přepnutí mindsetu z projektového na produktový není vždy jednoduché a ne každý ho zvládne. To je v pořádku, každý funguje jinak.

Mně osobně tento přístup vyhovuje víc, protože je to dlouhodobé úsilí, aby produkt dával smysl, je potřeba myslet do budoucna a neřešit jen taktická zadání a termíny. Jde o to vlastnit produkt a snažit se, aby všechny součásti – marketing, způsob používání produktem uživateli, tréninky, materiály a podobné věci – pomáhaly výrobku uspět. Práce je v tomhle ohledu hodně zajímavá.

Ještě zpátky k té roli konzultanta – právě pre-sale a časté cestování může být náročné a může člověka přimět uvažovat o změně. S mojí znalostí platformy jsem si říkal, že bych chtěl pomoci jinak a dokázal bych produkt posunout dál. Zpětně vidím, že ne všechny mé představy byly ideální, byly naivní, ale povedlo se mi přizpůsobit změně, pochopit, co se ode mě očekává, a najít si v tom své místo.

A možná je dobré zmínit ještě něco dalšího, o čem si budeme víc povídat příště.

Takže tak nějak… My jsme během posledních dvou…

(Pokračování nebylo dodáno.)

Jasně, tady je opravený a upravený text pro lepší srozumitelnost a plynulost:

Letos jsme procházeli nějakou transformací, máme nového CEO, nový leadership tým, a vlastně to, že já jsem prošel změnou leadershipu zároveň s mojí změnou role, mi vlastně pomohlo se na všechno přizpůsobit, protože všechno se nastavovalo znovu. Přesně tak, takže to pro mě bylo asi mnohem přirozenější. Teď, když zůstávám v té roli, ve které jsem, není to tak, že bych vzpomínal na nějaké minulé časy, jak to bylo kdysi jinak. Prostě je to teď pro mě realita a je asi mnohem jednodušší v ní fungovat.

Mně to přijde skvělé, že jsi začínal jako tester, že znáš tu platformu opravdu do hloubky, fakt umíš ty nástroje používat. Potom jsi přešel na stranu konzultantů, takže dostáváš ten náhled z druhé strany. A co je vlastně PM (projektový manažer) jiného než to, že propojuje tyhle dva pohledy, kde se mohou potkat, a hledá směr, kterým by to obojí mohlo jít a potkat se. Takže zpětně mi to dává smysl. Myslím si ale, že jsi dost unikátní v tom, že jsi měl tu příležitost vyzkoušet si opravdu diametrálně odlišné role.

Určitě, určitě. Člověk si musí uvědomovat, že v celé té cestě měl i štěstí. To je vždycky potřeba. Já možná ještě navážu na to, že jako tester jsem znal tu platformu, ale samozřejmě byla v té době úplně jiná, jednodušší. Dnes už neznám zdaleka všechno, což pro mě trošku není komfortní – rád bych to znal. Ale samozřejmě jsme už prošli nějakou cestou, takže už to není ten relativně, nechci říct jednoduchý, ale přímo jednoduchý nástroj, jako když jsem začínal. Teď je to docela komplexní platforma.

A na to se můžeme podívat zblízka. Myslím, že málo kdo z našich posluchačů nikdy neslyšel o značce Atakama. Většina asi ví, že je to firma s českými kořeny. Tak možná takhle letem světem company.

Když jsi nastupoval, říkáš, že vás bylo 60–70 a byl to vlastně malý nástroj. Byl to tedy relativně malý tool, ale velmi flexibilní, užitečný, konfigurovatelný. A to bych tady mohl trošku rozvést.

Když jsem nastoupil do Atakamy, existovalo už nějaké jádro nástroje, které prošlo spoustou změn. Tenkrát jsme měli Data Quality Center, dnes byste to pojmenovali trochu jinak. Šlo o to, že jsme měli nějaký engine a vlastně Eclipse tool na konfigurace. Pracovali jsme s krabičkami na plátně – pospojovali jsme je dohromady. Občas to fungovalo jako nějaká ETL-ka, ale soustředili jsme se opravdu na datovou kvalitu, na práci s daty – transformace, čištění, enrichment, doplňování, validování atd.

A to všechno vzniklo proto, že Atakama vznikla jako spin-off nebo dcérská společnost Adastry, která vytvářela různé datové sklady (warehouses). Při jejich tvorbě narazili na problém, že tabulky, které měli k dispozici, nestačily, aby data připravili správně. Tak vznikla první verze Atakama engine, která se potom ukázala jako validní pro trh...

Chceš ještě opravit nebo upravit další část?

Tady je opravený a stylisticky upravený text:

To bylo něco, co by se dalo prodávat dál, takže se z toho stal pořádný nástroj. Ve chvíli, kdy jsem nastoupil, už existovalo toto jádro, ale měli jsme i několik webových aplikací. Existoval jeden nástroj na dashboardy, jedna webová aplikace na řešení různých problémů, takzvaný issue tracker. Měli jsme také nějaký engine pro naše MDM, tedy Master Data Management. Myslím, že když jsem nastoupil, frontend ještě nebyl hotový, ale už se na něm pracovalo. Měli jsme i referenční data management jako samostatnou webovou aplikaci. Byla to taková platforma, která sdílela spoustu technických elementů, ten engine byl prakticky stejný v každé aplikaci. Pokud jsme chtěli používat všechny aplikace najednou, šlo to, nicméně integrace nebyla úplně jednoduchá.

Tyto nástroje jsme mohli považovat za samostatné (standalone). Pro někoho, kdo přišel zvenčí, bylo ale naprosto zásadní pochopit právě ten korový produkt – jak fungují různé datové toky, jak fungují naše plátna, jak se všechno konfiguruje, jak je to modulárně propojené, co to umí. Z toho se potom drajovala logika do webových aplikací pro koncové uživatele. Měli jsme s tím poměrně velký úspěch i na mezinárodní scéně, ale bylo jasné, že se potřebujeme posunout dál.

Přišli jsme tedy s první iterací tzv. Atakamy One, což byl první nový uživatelský interface. Byl navrhovaný s představou, že bude mnohem víc automatizovaný, uživatelsky přívětivý a přístupný i pro business uživatele. Navíc by měl využívat i umělou inteligenci a vše by mělo být modernější a lepší. Tento produkt jsme zavedli a kolem něj začali vytvářet základní use case – šlo o něco jako datový katalog, ne úplně datovou kvalitu. V podstatě šlo o základní datový katalog, i když jsme tehdy ještě přesně nevěděli, co datový katalog doopravdy znamená. Měli jsme ale určité povědomí z našich zkušeností s konkurencí a klienty, kteří s tím pracovali, jen jsme neznali všechny důsledky.

Tak jsme udělali první verzi jako samostatnou webovou aplikaci vedle naší platformy. Postupně jsme zjistili, že tudy je cesta – katalog, business glossary s pojmy a klasifikací dat dávají smysl datovým use caseům. Cítili jsme ale, že to můžeme udělat lépe. A proto jsme vytvořili současný nový produkt, který interně nazýváme Atakama Gen 2 nebo One Gen 2. Máme ale různé označení, takže každá věc má často i tři jména, ale externě se snažíme být konzistentnější. Naše Gen 2 je platforma, která nabízí jednotný interface pro use casey týkající se datové kvality, katalogu, business glossary a také datové lineage. Všechno je skutečně propojené a funguje jako jeden celek.

Pokud chceš, můžu ti pomoci i s dalšími úpravami nebo zkrácením textu.

Zde je opravený text:

Není to nástroj složený z několika propojených platforem, je to jeden nástroj, který má různé servisy a zajímavou architekturu, ale je to skutečně jedna věc. A to mělo velký úspěch u spousty klientů – ten koncept měl úspěch, i když samozřejmě ne vždycky se nám podařilo všechno udělat úplně správně. Pořád jsme měli vedle toho i další naše nástroje, například MDM a DM pro skutečné řízení dat, tedy pro ukládání, historizaci a úpravy dat.

V posledních několika letech pracujeme na další konsolidaci té platformy do jednoho celku. Já se například věnuji tomu, aby reference data management byl již součástí platformy, ne jako separátní rozhraní či nástroj, který pouze něco sdílí, ale skutečně jako integrovaná součást platformy. Ta má také mnoho přesahů do dalších use case, které tam řešíme.

Ted nevím, jestli možná skáču moc dopředu k jednotlivým use caseům, možná bych měl zpomalit a představit, co všechno vlastně nabízíme, protože nevím, jestli všichni posluchači rozumí tomu, co Atacama nabízí a co dělá. Je toho opravdu hodně. Možná jako základ – je to jedna platforma, kde si musíte koupit jádro a pak dokupujete potřebné modely? Ano, současná verze funguje tak, že můžete používat referenční data i bez hlavní části platformy.

Ale kam se chceme dostat, je větší přepnutí do SaaS-like režimu, kde platforma běží neustále online a uživatelé budou schopni používat jen to, co potřebují. Přitom však zůstane možnost využít i další funkce platformy – kompletní vypnutí některých částí nedává smysl, spíše chceme podporovat flexibilní využití – některé funkce více, jiné méně.

My silně věříme v platformní přístup. Možná udělám krok zpět, a to souvisí i s tím, co dělají naši zákazníci a konkurenti. Ve výsledku máte dvě možnosti: buď mít platformu, která řeší vše, co klient potřebuje, nebo se specializovat na konkrétní use case či schopnost a pak řešit integrace a synergii s jinými nástroji, aby všechno fungovalo dohromady.

My jsme zvolili platformní přístup, někteří naši konkurenti zase specializaci v určitém odvětví. Subjektivně si myslím, že platforma je budoucnost, a že ti konkurenti na tom trošku doplatí, i když vidíme, že i oni nyní vyvíjejí platformy. Takže právě začíná „závod“ ve vývoji platforem.

Podíváme se na use case, který jsi zmínil – co přesně jste se rozhodli řešit. Zkusím to shrnout, protože je to opravdu hodně. Naším jádrem je datová kvalita. Zajišťujeme, aby data, která klient používá, byla co nejlepší kvality. Ať už jde o data discovery, pochopení struktury dat, monitoring…

Pokud bys chtěl, mohu pokračovat nebo upravit text ještě víc podle dalších částí.

Opravený text:

g pomocí nějakých pravidel datové kvality, až po různé vylepšování těch dat, například automatické čištění, obohacování a podobně. A vlastně poskytování těch dat potom k dalšímu použití. Nemáme ambici být analytický nástroj, nemáme ambici být ten koncový nástroj, který někdo používá třeba pro řízení zákazníků. Naší ambicí je být platformou, částí infrastruktury, která zaručí,

že data jsou v pořádku a že je mohou všichni ostatní používat. A to je teď hodně skloňovaný pojem v souvislosti s AI. Čím víc firmy začnou používat AI, tím víc jim dochází, že potřebují kvalitní data. My se ještě snažíme dotáhnout to na další úroveň – nemluvíme jen o datové kvalitě, ale o tzv. data trustu. Prostě nejde jen o to, že data jsou kvalitní, ale že jim skutečně věříte, že je dokážete používat, že důvěřujete celému procesu. To znamená, že víte, kdo data vlastní, kdo se o ně stará a kdo je za ně zodpovědný. Víte, odkud data pochází – což jsou například naše schopnosti lineage – a víte, že jste schopni s daty opravdu pracovat, upravovat je a připravovat je, ať už jde o referenční data, nebo v rámci master data managementu vytvořit například kompletní identitu klienta, a potom data poskytnout do datového skladu, CRM nebo jiných systémů, kde jsou tato data využívána, aby zákazník věděl, že data jsou v pořádku.

Takže se vlastně staráme o to, aby klienti v každém okamžiku věděli, že je o jejich data dobře postaráno, ale nejsme ti, kdo se o ně starají přímo. Děláme nástroj, který umožňuje jejich týmům tohle dělat. To hodně souvisí s tím, kdo si nás vlastně pořizuje a do jaké míry firma potřebuje dosáhnout určité úrovně, aby měla z naší platformy užitek. Možná to souvisí i s tím, že spousta posluchačů o nás slyšela, ale nikdy nás neviděla ani nepoužila. A může to být i proto, že nás prostě nepotřebují. Bohužel to tak být může.

Vždycky rád říkám, že data management můžete zvládnout i s tužkou a papírem. V zásadě nic proti tomu, ale takové řešení přestane škálovat po určité době. A i některé jednoduché nástroje přestanou škálovat. Představte si, že existují firmy, které provedou akvizici a získají tři nové databáze, kde jsou tisíce tabulek a vůbec netuší, co v nich je. To může být velký problém, protože mohou dostat pokutu – zvlášť pokud jsou v nějakém regulovaném sektoru a orgány jim řeknou: „Nestaráte se o data správně, tak tady máte pokutu.“ To je vážný problém, který musí řešit.

Takže hledají nástroje, které jim pomohou to vyřešit. Ale zároveň nástroj sám o sobě není řešením. Musí si uvědomit, že to musí řešit, musí mít tým lidí nebo někoho, kdo bude mít motivaci to zvládnout. Nemohou jenom koupit nástroj a čekat, že se problém magicky vyřeší sám. Naše zkušenost je, že často klienti vědí, že potřebují... (pokračování podle potřeby).

Opravený text:

Užívali Data Quality tool, ale vlastně nevěděli, k čemu, nevěděli, co s tím. A pokud my jsme jim to nedokázali vysvětlit a opravdu jim dát nějaký konzulting, připravit je na to, co je čeká a pomoci jim nastavit ty procesy, a oni třeba ani nechtěli, třeba si chtěli udělat sami, tak se mohlo stát, že selhali. Protože prostě nevěděli ten užitek v celém tom nástroji a v té šílené platformě. Ale zároveň samozřejmě klienti, kteří vědí, co chtějí, nebo vědí, proč je to důležité, a vědí, kam směřují, a třeba i staví nové týmy, upravují organizační strukturu, aby se přizpůsobili těm novým pořádkům, tak pro ně ta platforma je úžasná, protože mohou těm týmům dát do ruky něco, s čím se mohou starat o ta data, mohou je vlastnit, mohou zaručovat, že jsou v pořádku, a nemusí běhat mezi pěti různými nástroji a pěti různými rozhraními, aby tohle zařídili.

No, v tom, co říkáš, já se zase vrátím k tomu mému úvodu, cítím ten, nebo slyším ten shift data managementu jako takový. Určitě. Že deset let zpátky ten use case byl: ať nedostaneme pokutu. Jakoby, že data management, data governance je nutné zlo v regulovaných odvětvích prostě, ale je to daň, je to prostě security. Je to jako pojištění vlastně. Nutné zlo. A mám pocit, že teď, hodně zrychlené AI vlnou, ale že v těch posledních pěti letech se to úplně otáčí. Čím víc přichází byznys k datům a čím víc self-service BI už není trend, bullshit buzzword, ale stává se realitou – s tím, jak se data zpřístupňují – tak najednou jde vidět, jaký je v tom přínos a koho kam pouštět. Data management je jako enabler, jako empowerment. Není to nutné zlo.

Je to přesně tak. Já bych řekl, že pokuty a regulace jsou pořád samozřejmě obrovské téma, zvlášť pro nás, kdo se hodně orientujeme na banky, pojišťovny a firmy tohoto typu, ale máme samozřejmě i klienty z různých jiných odvětví. Ale tady ty regulace prostě vždycky budou hrát roli. Ale je to přesně tak, že když jdou regulace, tak v zásadě může být nějaký IT tým, který bude třeba pod CFO, kteří řeší, aby se nedostaly pokuty, nějak tam řeší ty kontroly.

V nějakém smyslu je tam pro ty IT lidi na obtíž a vlastně jim to jenom komplikuje práci. A postupně lidi chtěli mít tu moc, chtěli dostat přístup k byznysu, chtěli, aby ti lidi, kteří potom potřebují ta data proto, aby mohli oslovit nějakého zákazníka, byli si vědomi toho, že ta data nějak existují, že je třeba se o ně starat, aby tam právě vznikl nějaký ownership nad těmi daty. Ale nebylo to samozřejmě bezbolestné, protože to byla velká změna pro právě ty lidi na konci.

Hezké příklady jsou právě z pojišťoven, zvlášť třeba v UK, kde je ten trh přece jen trochu specifický, a většina těch smluv se prostě odehrává na papíře s nějakými velmi custom podmínkami a tak dále. A pak ten člověk přijde tam někde, po očku hodí tam tu smlouvu, jakože „já jsem vám tady teď vydělal peníze“, a jde pryč, a je mu vlastně jedno, co s těmi daty stane, protože jeho práce skončila. A teď jak přesvědčit takového člověka, že by se měl starat o ta data? Je to těžké... (text zde končí).

Opravený text:

Je to těžké, může to nějak pomoci pochopit, že jeho chyby mohou způsobit problémy, ze kterých pak on nebude mít přínos. Je to jako napojit na jeho peníze nebo něco podobného. Ale je to prostě těžké, je těžké najít tu správnou linii. Myslím si, že podle mé zkušenosti bylo prvním krokem, jak se dostat k byznysu, to, že lidé začali chápat, že někde ztrácejí peníze, že data způsobují, že dělají něco navíc nebo špatně. Můj oblíbený příklad je od jednoho klienta, kde jsme jim pomáhali nasadit naše nástroje a integrovat je s jejich novým CRM při nové transformaci. Reálně to byla firma, která vyráběla sportovní náčiní a posílala ho klientům ve státech v krabicích spolu s papírovými katalogy. Když se podívali na stav jejich adres, zjistili, že posílají spoustu katalogů na neexistující adresy, nebo je duplikují, nebo něco takového. Reálně museli vytisknout katalogy v objemu asi 2-3 cm tlustém svazku a na tom ztráceli spoustu peněz. Takže to byla první věc, díky které viděli smysl starat se o data, protože jim to ubíralo peníze a snižovalo revenue. Druhý krok je uvědomit si, kde jsou příležitosti. To je potom víc spojeno s managementem master dat, kdy identifikujeme klienta, víme, kdo je, jaké používá nástroje.

Pokud chcete, vysvětlím, co je master data management. Určitě. Master data management je podle mě královská disciplína – těžko se to kvantifikuje. Je to příprava master dat, což jsou kmenová data pro byznys. Typicky jsou to zákazníci, produkty, ale může to být cokoliv, co se na faktuře objeví – něco, co pomáhá identifikovat, kdo zaplatí a za co. Samozřejmě, když si představíte třeba banku, ta má spoustu oddělení, které spolu nemusí úplně komunikovat. Když si založíte účet, hypotéku nebo kreditní kartu odděleně, můžete se v systémech duplikovat. Pro banku je důležité vědět, kdo jste, uvědomit si, že už máte u nich produkty. Také kvůli regulacím musí banka rozpoznat klienta a v případě potřeby vědět, kam nahlédnout nebo co upravit, aby nedošlo ke komplikacím s úřady.

Master data management vede k vytvoření procesu pro správu těchto master dat. Často souvisí s deduplikací, slučováním dat a samozřejmě i s kvalitou dat. Musíte mít kvalitní kontakty, adresy a informace o dokumentech, které klienti mají, abyste s daty mohli efektivně pracovat.

Tady je opravená verze textu:

A pokud máme tyhle informace, můžeme je právě použít i na propojování informací o tom, co ten klient dělá. Jakékoliv programy na zvyšování spokojenosti zákazníků (customer satisfaction programs) budou na tom závislé. Potřebujeme vědět, co si klient koupil, a co mu nabídnout, abychom mu nenabídli třikrát ten samý produkt, ale naopak něco, co ještě nemá a co dává smysl vzhledem k tomu, co o něm víme. A to jsou právě ty příležitosti například pro nějaký cross-sell a tak dále, kdy lidé vidí, že když mají data v pořádku, mohou z toho vlastně generovat další příjmy, mohou vydělat víc peněz. Z nákladu se tak stává příležitost. Přesně tak, třeba z call centra. Vždycky se určitě prodává lépe a můžeš vydělat víc peněz, než kolik dostaneš pokutu. Je to tak, určitě. Zároveň je těžší to opravdu vysvětlit a najít tam tu příležitost, pokud si zákazník sám ještě není vědomý těch možností, ale na tom taky intenzivně pracujeme.

Máme samostatnou business value funkci, kde máme kolegy, kteří tyto věci diskutují s klienty a radí jim, jakým směrem by se měli ubírat, kde budou mít největší benefity, s čím začít a tak dále. No a teď máme AI, kde si všichni uvědomujeme, že pokud využíváme AI, potřebujeme mít dobrá data, protože jinak to nebude fungovat. Zároveň jsi už zmiňoval AI, že jste ji začali implementovat i u vás. Kdy bylo to první rozhodnutí, nebo kdy jste vůbec začali o AI uvažovat?

My jsme s AI začali pracovat už, já nevím, asi před osmi lety, kdy náš tehdejší CEO, Michal Klaus, byl velmi přesvědčený o tom, že budoucnost je v AI, že musíme mít nějakou AI funkcionalitu a musíme něčím ukázat hodnotu AI v našich nástrojích. Tehdy to byly spíš strojově učené modely – dělali jsme klasifikace dat, doporučovací systémy. Když jsme například klasifikovali nějaký dataset podle slov, jako jsou jména, telefonní čísla, nemuseli jsme mít deterministická pravidla, abychom zjistili, že v jiném datasetu je něco podobného. Skrze klasifikaci jsme pak nabízeli návrhy. Začali jsme tedy docela brzy a vyvíjeli různé funkce, které jsme zapojovali do platformy na různých místech. A samozřejmě už dva roky (jakmile začal velký boom generativní AI) jsme založili dedikovaný tým, který se dívá na to, jak nám AI může pomoci, co bychom mohli dělat a jaká by měla být naše budoucnost v této oblasti. To se rozvinulo v několik funkcionalit, včetně AI agenta, kterého brzy spustíme do světa. Už to není novinka, agenti jsou teď všude a hodně se o nich mluví, ale pravda je taková, že už před rokem a půl jsme…

Pokud chceš, mohu pomoci upravit i pokračování.

Tím jsem chtěl říct, že takhle nějak by to mělo fungovat – měli bychom mít takového buddyho, vlastně skoro jako juniorního kolegu, který nám bude pomáhat. AI tedy není od toho, aby na jeden klik udělala nějakou šílenou magii, které nikdo nerozumí, ale je tu především proto, aby pomáhala s repetitivními úkoly, automatizovala je, a zároveň aby byla pořád zabudovaná v týmu jako nástroj tak, že to, co AI vytvoří, vypadá stejně, jako kdyby to udělal kolega, a já tak mohl pochopit, co udělala, případně to upravit, změnit a s tím pracovat.

To je samozřejmě velké téma pro nás a snažíme se, aby všude, kde něco děláme, pokud tam AI hned není, mysleli na to, že ji jednou bude třeba agent konfigurovat nebo nějak nastavovat. Abychom pak dokázali pospojovat různé úkoly napříč platformou a udělali to co nejjednodušší. Můžeme se na to podívat konkrétně možná později, teď bych se ještě rád zaměřil na to, co jsi dobře zmínil – cílovou skupinu, tedy klienty, zejména z oblasti financí, pojištění, velké a globální firmy.

Co se týče rolí, které to používají – mluvil jsi jako ředitel produktu, takže to musí být hodně složité. Původně to byl spíš technický nástroj, který používala Adastra, hlavně techničtější konzultanti. Přechod je ale mnohem víc k byznysu. Jak to tedy vypadá teď, když řešíte uživatele? Je tam kombinace – máte dvě různé skupiny: první, kteří chodí do pokročilé konfigurace a píší kód, a druhé, kteří jen klikají v dashboardech? Kdo to tedy vlastně konzumuje?

To je skvělá otázka. Posunuli jsme se co nejvíce směrem k byznysuživatelům, ale zároveň jsme začali řešit, jak pomoci roli data inženýra. Ten má někde nějakou pipeline, něco dělá v Pythonu a potřebuje ověřit, že data jsou v pořádku, nebo mít nějakou kvalitní bránu (quality gate), která data pošle dál. Vydali jsme proto iniciální verzi našeho Python SDK a plánujeme větší verzi. Pointa je, že máte platformu, ve které nastavujete spoustu věcí, ale pak můžete v pipeline používat SDK, které využívá ty funkcionality definované v platformě.

Ne všechno je zatím hotové, ale dá se to představit tak, že když bude byznys mít požadavek na pravidlo kvality dat pro konkrétní doménu – například, jak by měla vypadat telefonní čísla –, data inženýr už nebude muset hledat, jak to má vypadat, ale jednoduše si zavolá do implementace daného pravidla pomocí SDK. Využívá tak funkce nastavené byznysem v platformě, ví, že pravidla pocházejí z důvěryhodného zdroje, a nebude řešit interní logiku.

Chceme se tímto směrem postupně rozvíjet a rozkročit do světa, kde bude... (pokračování podle kontextu)

Tady je opravená verze textu:

Mým úkolem je podporovat ty lidi, kteří se starají o data, o vnitřnosti různých pipeline na infrastrukturách, ale zároveň i ten byznys – tedy lidi, kteří vlastní data, rozumí jim, potřebují s nimi pracovat a vždy budou naší cílovou skupinou. Kdo to doopravdy je, jsme měli vždycky jako legendu o datovém stewardovi. Každý mluvil o datovém stewardovi, ale nikdo nevěděl, kdo to přesně je, a myslím si, že v určitém smyslu pořád úplně přesně nevíme, kdo to vlastně je. Obecně víme, kdo to je v různých typech firem a různých organizací.

Teď nechci dělat velký skok, ale zmíním, že s tím vším souvisí tendence implementovat koncepty jako data mesh a pracovat s datovými produkty. Trend je takový, že nechceme mít jeden centrální datový tým – případně ho klidně mít můžeme, ale jenom pro poskytování guidance – a pak v každém týmu, který data používá nebo produkuje, by měl být datový expert. Ideálně by každý člověk měl být nějakým datově orientovaným specialistou, ale minimálně by měla v týmu být kompetence a expertíza v datech.

V takovém případě může naši platformu skutečně používat kdokoliv z těchto týmů. Například centrální tým vytvoří soubor pravidel, která by si měly jednotlivé týmy aplikovat. Daný tým si může ověřit kvalitu svých dat tím, že se podívá na existující pravidla, může je použít, ale případně si může vytvořit vlastní pravidla přímo v webovém rozhraní. To tedy může udělat business analytik nebo jiná role, která není vyloženě technická, případně se na to může zeptat AI agenta, který mu pomůže.

Pokud chtějí pak poskytnout svoje výsledky někam dál, mohou jako součást reportu připojit evaluaci svého datového setu a tu pak sdílet v rámci platformy s dalšími týmy. Když pak někdo bude shánět data, může si v našem katalogu zjistit, například: „Tady jsou data o marketingové kampani, mají takovouhle kvalitu, vlastní to tento tým.“ Následně buď bude existovat nějaký proces, jak se k nim dostat, nebo může rovnou v aplikaci napsat žádost o přístup, čímž pomůžeme týmům se navzájem spojit.

Kdo to doopravdy je vevnitř, velmi záleží na tom, jak daleko je daná organizace ve své datové cestě. Máme klienty, kde je dedikovaný tým několika datových stewardů, kteří vyřizují frontu různých úkolů. Máme klienty, kde se o data starají dva až tři techničtí nebo zkušení lidé, kteří zároveň rozumějí byznysu a připravují data pro celou organizaci. Pak máme klienty, kde je hromada týmů rozesetých přes rozsáhlou globální korporaci, které musíme postupně onboardovat – nikdy nezačneme tím, že si pořídí velkou platformu a ihned ji použijí všichni, ale začneme v jednom týmu a postupně se rozšiřujeme. Záleží tedy hodně na tom, kde organizace začíná, a podle toho je potřeba přizpůsobit přístup.

Pokud chcete, mohu text ještě více zkrátit nebo upravit do formálnější či neformálnější podoby.

Zde je opravený text:

Někdo si víceméně naklikává jako byznisové pojmy do glosáře, aby potom věděl, co tam má a jak podle toho dělat další reporty. A je to obrovská výzva i pro nás, protože identifikovat uživatele není vůbec triviální. Spousta lidí, kteří k nám přijdou třeba z jiných firem – ať už PMové, designéři nebo kdokoliv jiný – se vždycky rozčílí, kde máme ty persony a tak dále. My je samozřejmě máme, ale není to tak přímočaré, jak jsme například zvyklí. Musíme někdy říct, že je to určitý předpoklad, se kterým pracujeme, a že případně těch rolí může být víc, kteří pracují se stejnou částí aplikace. Takže pracujete spíš s procesem, který to řeší, než s personami samotnými.

Určitě ale s personami pracujeme. Já osobně se rozhodně více soustředím na ten proces, ale persony máme vydefinované, máme lidi, kteří jsou „to starý“, a persony jsou součástí různých našich aktivit, nových implementací a tak dále. To ne, že bychom je neměli. Já k tomu ale často přistupuji s jistou skepsí, když se moc zaměřujeme pouze na persony, protože mám pocit, že nám něco uniká. Někdy je lepší podívat se na věc z větší perspektivy a rozmyslet si, co je vlastně celý proces a jestli ty persony nejsou úplně zbytečné, jestli to nemá vypadat jinak, a jestli to není spíš něco, co bychom měli říci zákazníkovi. Ale už je to asi složité, kde je ta hranice mezi technickým dodavatelem a konzultantem, který zákazníkovi říká, co má dělat.

Ty máš v tomto prostoru dlouholeté zkušenosti, byl jsi u klientů a firem, které to vyřešily skvěle, na jedničku, ale i u těch, které měly zdroje, lidi a nejlepší nástroje, a přesto na tom pohořely...

Pokud by nás poslouchal někdo, kdo má na starosti transformaci zahrnující změnu data managementu a zavedení ownershipu, co by měly být věci, na které by si měl dát pozor? Jak jsi říkal, je dobré rolovat postupně, ne?

Určitě, to platí u všech našich implementací. Vždycky doporučujeme nedělat Big Bang, protože to téměř nikdy nefunguje z mnoha důvodů. Proto je důležité jít krok za krokem. Pak obecná rada – když už to začnete zavádět, mějte jasný use case, na který se zaměřujete. Use case nemusí být složitý, ale je důležité, aby interně bylo jasné, proč to děláte.

A co může být takový use case?

To může být cokoliv. Důležité je, aby například věděli, proč to teď dělají. Třeba reporty v Tableau nebo jiném nástroji konzistentně ukazují špatná data. Tím pádem náš cíl na tento projekt – ať už na půlrok nebo rok – bude zlepšit kvalitu těchto reportů, například nějakou klíčovou metriku. Jakmile je cíl jasný, můžete začít přemýšlet: proč jsou reporty špatné? Protože se někde kazí data. Vím, kde se kazí? Ne? V takovém případě musím nastavit proces, který mi do...

Pokud chceš, mohu pokračovat v opravě a doplnění zbytku textu, stačí říct.

Tady je opravená verze textu:

Káže udělat nějakou data discovery, nebo nějakou identifikaci, kde ta data jsou, případně analýzu lineage a pochopení toho, jak data tečou skrz. Našel jsem ta data, vidím ten proces, a zjistím, že je něco špatně. Ke komu jdu, koho půjdu seřvat, že to je špatně? Nevím, musím to nějak zjistit, musím to najít a ideálně použiju nějaký nástroj, abych na jednom místě dokázal tyto věci přiřazovat, organizovat a abych to dokázal najít jinak, než že budu psát e-maily na všechny strany, kdo vlastní tuhle tabulku. A tohle samozřejmě úzce souvisí s ownershipem, kde si myslím, že obrovská součást zavedení ownershipu je zavedení schopnosti – a teď nevím, jak to říct správně česky, a i anglicky to zní hrozně – aby lidi měli možnost něco udělat s tím, za co jsou zodpovědní.

Když jsem ten termín „empower the users“ slyšel poprvé od klienta, tak jsem se tomu smál, že je to jen korporátní buzzword, že to vlastně nic neznamená. Ale je na tom dost pravdy, protože empowerment ve smyslu toho, že máte byznysové uživatele schopné něco udělat s těmi daty bez nutnosti další pomoci, je klíčový. Bez toho je velmi těžké vybudovat skutečný ownership, protože proč by lidé dělali něco s tím, co nemohou ovlivnit?

Tedy tady jdou ty věci ruku v ruce a já bych doporučoval právě zamyslet se nad tím, jakou roli ti lidé hrají – jestli skutečný owner je opravdu owner, nebo jestli jde jen o papírovou osobu, která je nějak zodpovědná, ale s tím nic neudělá. Nebo zda ten člověk, případně tým, který ta data vlastní, má nástroje a prostředky na to, aby s tím skutečně něco udělal v případě nějakého problému.

Tohle samozřejmě není jednoduché říct obecně, protože záleží na tom, co zákazník dělá, jakou má infrastrukturu a jaké legacy nástroje musí používat. Protože každá taková transformace se často zasekne na jednom on-premises systému, kterému nikdo nerozumí, těžko se mění, a přitom je klíčový pro všechny procesy kolem.

Proto podle mě neexistuje univerzální rada. Je to prostě o tom, přistupovat k tomu rigorózně a budovat to tak, aby se lidé v organizaci starali o data, aby věděli, že se mají o data starat, aby to bylo součástí jejich práce a ne jen další zodpovědnost navíc, a aby z toho měli i nějaký benefit.

Když například existuje nějaký report, který dává špatné výsledky, tak já můžu mít jasný benefit v tom, že ho vylepším a pak půjdu dál. Další úkol může být třeba identifikovat zákazníky, kteří si od nás koupí nový produkt, který plánujeme launchovat příští rok. Mám proto vůbec potřebné informace? Je to samozřejmě na bedrech analytika, ale pokud ani nevím, že jsou data špatná, nebo nevím, ze kterého systému je získat, tak se zase můžu začít ptát, jestli mám vše správně propojené, jestli pipeline fungují, jestli data jsou ve správném stavu atd.

Pokud chceš, mohu to ještě více upravit, zpřehlednit nebo zestručnit.

Jasně, tady je opravený text s úpravami pro lepší čitelnost a gramatiku:

Kvalitě. A když nejsou, tak s tím můžu něco dělat, ale zároveň to budu monitorovat a budu mít třeba tu naši platformu, která mi pomůže podívat se na to každý týden, každý měsíc, prostě třeba půl roku, a říct si: OK, kde jsme, čeho jsme dosáhli, jak jsme se posunuli, kde máme problémy, na co se musíme zaměřit a tak dále. Ale řekl bych, že nejtěžší věcí je skutečně ukázat ty benefity. Protože když tomu někdo nerozumí nebo to vidí poprvé, tak benefit datové kvality nemusí být zřejmý – můžete mít krásně vypadající reporty i bez ní. A to, že jsou špatné, si nemusíte vůbec všimnout. Jen proto, že někomu vylepším report, nutně neznamená, že pochopí, proč má věnovat několik hodin zkoumání rolu a nastavení toho, jak evolvovat data. Takže je tam hodně evangelizace, vysvětlování a identifikace business value.

Někdy zákazníci na to nejsou připraveni, a to si myslím, že je v pořádku, i když jim třeba nějak naznačíme možnosti my. Zkušenost je totiž taková, že když zákazník vidí, že s ním jednáme férově a nesnažíme se jen prodat platformu, tak se na nás až budou připraveni vrátí. V tomhle se snažíme být hodně otevření a transparentní.

Můžeme se teď pobavit o tom ownershipu a co to vlastně znamená v praxi. Rád bych navázal na pojem data product, který jsem už zmínil při našich rozhovorech. O datových produktech se hodně mluví, spousta firem se je snaží implementovat, často právě v kontextu data meshy. Já osobně bych o data meshy nemluvil jako o primárně technologickém konceptu, spíše je to organizační záležitost. Data products jsou zajímavé tím, že nepřinášejí něco zásadně nového. Ve svém důsledku se stále bavíme o tom, že data musí někdo vlastnit, musí vědět, k čemu slouží, a musí je poskytovat ostatním, kteří je mohou používat. Tento koncept jsme zabalili do formy datového produktu. Mně se taky líbí původní označení „data as a product“, které podle mě krásně vystihuje podstatu věci. Jde o to, že stejně jako když chci dostat produkt na pulty obchodů, zabalit ho do krabice a zajistit, aby se dostal ke klientům správně zorganizovaný, tak u dat chci mít nad nimi kontrolu, data „vyrobit“, poskytnout je spolu s informacemi, které chci, aby ostatní znali – třeba vysvětlit, k čemu data slouží. A pak případně nastavit i „kontrakty“, které se mohou v konkrétních implementacích objevit – třeba napojit je na datovou kvalitu nebo klasifikaci dat.

Když začneme tyto pojmy spojovat, můžeme dojít k situaci, kdy nějaký tým připravuje data o zákaznících, kontaktech a podobně...

Pokud chceš, můžu opravit a doplnit i zbytek textu. Stačí říct!

Tady je opravená verze textu:

Nějaké informace o tom, například jaké produkty používají. A už součástí datového produktu může být i informace o tom, jaký důvod opravňuje někoho se k těmto datům dostat, například z hlediska GDPR. Takže některé oddělení, pokud by chtělo data použít, tak k nim reálně nebudou moci mít přístup. Právě ten nástroj (tooling) může toto zajistit, protože pokud správně odklasifikujeme data a nastavíme různé access control (přístupová práva), tak se k nim lidé jednoduše nedostanou.

Ano, pak se můžeme bavit o tom, že někdo stáhne Excel a pošle ho dál, ale to je něco, co nástroje už nevyřeší. Je to však věc, která může firmě pomoci demokratizovat data – dostat je k lidem a zároveň se nebát, že je použije někdo, kdo nemá oprávnění.

To může být například právě nějaký konkrétní důvod k používání těch dat. Na to můžeme navázat datovou kvalitu – říct například, že data vždy obsahují kvalitní e-maily, a pokud v některých nebudou, můžeme automaticky zrušit transakci. Ten, kdo bude data přijímat, bude vědět, že je tam nějaký problém. Pokud je proces automatizovaný, pipeline se zastaví a systém oznámí: „Toto data nemohu přijmout, protože podle datového produktu nejsou správná a kontrakt je porušený.“

Může také fungovat to, že příjemce si sám ověřuje, zda je kontrakt správný, ale já bych argumentoval, že správný způsob je, aby ten, kdo datový produkt vytváří, poskytoval všechny potřebné informace a aby to bylo nastavené tak, aby je nemohl falšovat. Samozřejmě se může stát, že v komplikované organizaci někdo bude předstírat, že má lepší data než ostatní, ale pokud vše probíhá v jednom nástroji, se stejnými metodami a nastaveními, kde existuje i centrální tým zaručující správnost pravidel, minimalizuje se tento problém.

Je to mnohem jednodušší než v případě, že každý používá své vlastní nástroje, protože pak dostanete dataset v nějakém formátu s nějakým reportem, aniž byste věděli, kdo ho vytvořil, kdo zaručuje jeho správnost, v jakém nástroji to vzniklo, a nemůžete tomu úplně věřit.

Právě datové produkty a jejich vlastnictví (ownership) a vše kolem toho zaručují to, čemu říkáme „data trust“ (důvěra v data). Skutečná důvěra znamená, že víte, že všechno je v pořádku, znáte odpovědnou osobu a máte všechny informace, které potřebujete, abyste data správně využili.

Samozřejmě tohle může jít i za hranice datasetů. Data produkt může být téměř cokoli – třeba i machine learning model. My se ale teď soustředíme hlavně na data, protože pro nás jsou data nejdůležitější. Doporučujeme, aby konkrétní data měla své vlastníky a schopnost být spravována v nástroji …

Pokud chcete, mohu text ještě více upravit či zestručnit.

Zde je opravený text:

I v našem případě třeba si najít data, udělat ty reporty,
udělat nějaký cleansing, prostě to aplikovat
a poskytovat to dál.

Skvělé, já se vrátím ke dvěma věcem.
První je ten ownership.

Takže ok, před chvílí jsi říkal,
že je hrozně důležité,
aby ten data owner měl moc, pravomoc,
schopnost ta data ovládat,
něco s nimi opravdu udělat.

A to je pro mě vlastně příklad,
když si to představím, vidím dva extrémy.
Vidím organizaci, kde vyplňují obchodní zástupci,
jako obvolaní lidi,
a nějaké CSV do Excelu,
a potom to nahrávají někam.
Tím pádem je owner těch dat ten, kdo to píše do Excelu,
a je to čistý byznysák.

A k němu můžeš říct:
"Hele, tady máš chybu,
zapsal ses špatně."

Na druhé straně, u velkých organizací,
si myslím, že byznysák už to neopraví,
a že to bude čistě datové nebo IT oddělení,
někde úplně jinde.
A že oprava bude spíš na data inženýrech.

Takže mi, prosím, uprav tenhle obrázek,
protože vlastně nevím, co si pod tím představit.
Kdo má být data owner?

Já myslím, že je to super příklad,
protože když byznysáci vyplňují věci do Excelu,
tak samozřejmě kvalita dat tam nebude ověřena úplně dobře,
ale ultimátně ten, kdo data poskytuje dál,
je vlastně ten, kdo data vlastní v tomhle smyslu.

Stejně jako když představíme nějaké schvalování změn v datech,
ultimátně ten, kdo vlastní ten systém,
který vezme data z formuláře a posílá je dál,
ten potřebuje zajistit, že data jsou v pořádku už na vstupu,
to je samozřejmě ideální stav.

Nebo potřebuje vědět, v čem jsou problémy,
aby je mohl opravit.

Ideálně je data owner někdo,
kdo je zodpovědný za přesun těch dat z formuláře
do systému, ale samozřejmě může být i někdo dál v organizaci,
kdo pak řeší spíš reaktivní změny a opravy dat.

No, tak...

Skvělé, teď jsi mi to vysvětlil, to jsem moc rád.
A ještě mě napadla jedna otázka.

Mluvil jsi o tom, že někde je centrální oddělení,
které má odpovědnost za data management a za celou tuto problematiku,
tak kde vlastně sedí?

Sedí v datové organizaci jako BI a data?
Sedí v IT, protože se to týká všech systémů,
a je to víc data engineering?
Je to víc pod COO, pod digitální transformací?
Jaké jsou tvé zkušenosti?

Existuje nějaká best practice nebo lesson learned?

Z toho, co vidíme u našich zákazníků,
tak je to právě role CDO,
která vznikla před mnoha lety.
Někdy jsou tyto role na hraně s bezpečností,
a poslední dva roky vznikly role jako CDAIO –
Chief Data and AI Officer –
které tyto oblasti spojují.

Naši zákazníci, s kterými pracujeme nejvíc a kteří využívají naše nástroje,
skutečně mají část organizace CDO,
mají datové týmy a zodpovědnost za data
jak z pohledu byznysu, tak i z pohledu IT.

Pokud byste chtěli, upravím ještě dál pro stylistickou konzistenci nebo formálnost.

Tady je upravený a stylisticky zlepšený text:

Leda v jedné části IT, vlastně v jedné funkci, kde typicky žijí centrální týmy. Pokud existují, často bývají součástí tzv. center of excellence, tedy týmů, které nejsou nutně zodpovědné za správu samotných systémů, ale spíše poskytují guidelines, pravidla a udržují vše v chodu. Jsou to lidé, na které se může kdokoliv obrátit s dotazem, problémem nebo žádostí o pomoc. Takové týmy vždy existovaly a budou existovat i nadále.

Většinou dnes tyto týmy fungují v rámci CD (Chief Data) organizace a firmy se zároveň snaží, aby v jednotlivých odděleních existovaly samostatné datové týmy, které prioritizují svá data. Ideálně se to potom přes různé nástroje propojí a CDO má i analytickou funkci, která zajišťuje, že analytika funguje správně. Každý specifický tým může mít své vlastní menší oddělení bez problémů, ale je důležité vědět, odkud data pocházejí, aby jim bylo možné důvěřovat – o tom jsme už mluvili. Tohle rozhodně vidíme nejvíc.

Pamatuju si, že za posledních pár let měl prakticky každý náš klient CDO nebo někoho v podobné roli. Aktuálně vidím trend v dotažení federalizace tohoto řešení – tedy jako vedení na centrální úrovni a zároveň nezávislé týmy na úrovni oddělení. Postupně se dostávají k mindsetu, který se blíží principům data mesh, možná pod jiným názvem, ale jde o to, že kompetence se rozkládají do jednotlivých týmů, které mají své vlastní kompetence nad svými daty, a CDO tým pak aggrekuje a koordinuje celé řešení.

Je to vlastně podobné tomu, co známe ze software engineeringu a DevOps – někdo drží know-how, stará se o to, aby všichni mohli pracovat rychle a samostatně. Je to krásná paralela.

Když jsme takhle shrnuli data management a jeho trendy, a proč je to důležité pro inženýry i infra lidi, zajímá mě, kde v tom všem jsou business uživatelé. Proč je výzvou vytvořit Atacamu (platformu) pro obě skupiny? A kde podle tebe data management v tom steku vlastně je? Vidím tady trend platformizace datových nástrojů – místo jednotlivých specializovaných nástrojů dnes vznikají integrované platformy, které sjednocují různé funkce. V minulosti byly různé nástroje např. od Databricks, Microsoftu nebo jiných partnerů komplementární a fungovaly v symbióze, ale dnes jsou často v konkurenčním boji.

Jak to vidíš ty? Potřebujeme specializovaný nástroj na data management? Nebo když mám kvalitní dbt, dokumentaci a glosáře ve svém Power BI, část věcí si vlastně pokryju?

Myslím, že to souvisí se škálou požadavků a tím, co chceme vyřešit na platformě. Firma, která má jednu databázi, jedno Power BI a dbtcko, je v pohodě…

Pokud chceš, můžu upravit i zbytek, až budeš mít pokračování.

Opravený text:

Odě nás nepotřebuje. Nějak se s tím poradí. Jakmile mají několik instancí dbtčka, když je používají různé týmy a pak tam mají ještě nějakou informatiku a také Power BI někde, protože mají historické důvody, a něco běží na Google Cloudu a něco na Azure, protože dřív koupili nějakou firmu, začíná to být komplikovanější. A právě tam vidíme naši příležitost – být nástrojem, který je agnostický vůči zdrojům a technologiím. Možná proto dává smysl i cílení na byznys, protože byznys se vlastně nezajímá o technologie pod tím, ale o data, jejich stav, co s nimi dělat, kolik to stojí a jak ušetřit peníze.

Důvod, proč byznys do toho chce vidět a potřebuje to, je ten, že mezi byznysem a IT často dochází k nepochopení. Když má byznys své důvody pro něco, co dělá, a IT třeba nechápe, proč to je potřeba, vznikají problémy. Byznys chce mít ty věci víc pod kontrolou. Datová kvalita je například primárně byznysový požadavek – data musí být v určitém stavu. Přeložit to do IT tak, aby to správně udělali a přineslo to požadované výsledky, může dělat mnoho problémů. Proto byznys hledá nástroje, které mu pomohou intuivně, jednoduše a co nejvíce automatizovaně získávat tyto informace, s nimi pracovat a také lépe chápat, jak data tečou, odkud přicházejí a k čemu se používají.

Jak už jsem říkal, snažíme se být agnostičtí vůči systémům i cloud providerům. To znamená, že i když někdo bude all-in na Azure, naše nabídka bude stále relevantní. Je ale možné, že si z nástrojů, které Azure a Microsoft poskytují, poskládá řešení, které mu bude vyhovovat a nebude nutné integrovat nic dalšího. Máme i konkurenty, kteří zvolili spíše single-purpose nástroje orientované na konkrétní cloud providery, aby měli co nejlepší integraci s jejich nástroji. Například někdo může hledat MDM řešení na Azure a existují minimálně dva konkurenti, kteří se zaměřují právě na tento přístup a nabízejí ideální řešení pro Microsoftí MDM.

My si ale myslíme – a také to vidíme – že firmy nutně rostou a začínají používat stále více nástrojů i cloudů. Něco může být řízené technologií, něco třeba náklady, ale spousta věcí také obavou o business continuity. Když jste hodně velká firma, nechcete mít všechno někde jen v jednom konkrétním cloudu. Před rokem se například stalo, že někdo omylem vymazal kompletně průběžné prostředí na cloudu a měl tam všechno all-in...

Pokud chcete, mohu text ještě více upravit či uspořádat.

Zde je opravená verze vašeho textu s úpravami pro lepší srozumitelnost a gramatiku:

To, co nemají nikde jinde, tak už to nevyřeší. Takže vidíme, že firmy používají různé technologie a my chceme být tou technologií nebo platformou, která je trochu nad tím, ale v nějakém smyslu hlavně mezi zdroji dat a aplikacemi, které je potom dál používají. Pro nás je ideální stav, že nenahrazujeme databázi, ale jsme schopni říct, co se děje s daty, když někdo importuje do datalake, jak se pak data přesouvají dál a dodat informace o jejich stavu, než je začne používat třeba nějaký BI nástroj.

Pokud je potřeba, můžeme se do toho i vložit – opravovat, fixovat, deduplikovat, slučovat data v určitých datových doménách a tak dále. Případně můžeme přidat vrstvu referenčních dat nebo mít jedno místo, kde budou všechny různé kódy – ISO kódy, hierarchie a podobně – a distribuovat je na všechny strany. Od začátku, kdy identifikujeme, co máme za data a děláme první pipelines, až po konec – tedy do nějakého BI nástroje.

To, že tam jsou různé další nástroje, nám nevadí, někdy je to dokonce dobře, protože nemusíme řešit spoustu dalších věcí. Například ETL jsme nikdy nechtěli dělat sami a neměli jsme na to ambice, i když jsme měli různé funkcionality kolem toho. Naším cílem je být schopni pracovat s těmi lepšími nástroji. Možná to zní trochu protichůdně vůči tomu, co jsem říkal dřív – že když máte platformu, nemusíte řešit spoustu dalších nástrojů. Ale to je spíš z pohledu konzumenta, uživatele, který platformu používá a potřebuje informace, a je více na straně byznysu. Tam je problém, když je hodně rozhraní a nejasných závislostí mezi nástroji.

Když je někdo techničtější, nevadí mu používat nástroj, který je fit for purpose, protože je nejlepší na daný účel. A to je v pořádku. My už jen chceme vědět, jak vytáhnout informace z těchto nástrojů – jak získat lineage, datovou kvalitu ze Snowflakeu a podobně. Nevadí nám, že tyto věci poskytují sami. Důležité je, že my jsme schopni na jednom místě to poskytnout koncovým uživatelům.

Někdy je to složitější, protože technologií je hodně, ale tím, že se nesnažíme být nutně nějakou „krabičkou“, která zapadne do prostředí a musí komunikovat na všech stranách, ale spíš jsme takovým „přehozem“ přes prostředí, který nám pomáhá pochopit, co se kde děje, kde jsou problémy a jak upravit různé technologie pod tím, aby nám pomohly dosáhnout našich cílů. To je spíš abstraktnější a někdy hůře uchopitelné.

A k vaší otázce ohledně Gartneru a kategorií:

Jsme na kvadrantu Data Quality, kde patříme mezi lídry. Datová management kategorie jako taková není. Na Data Analytics něco... tady to říkám špatně, kvad... (text končí, není pokračování)

Pokud chcete, mohu pomoci i s dokončením poslední části textu nebo s jeho další úpravou.

Opravený text:

My jsme se dřív snažili dostat i do metadata management kvadrantu, který pak ale přestali dělat, a teď nevím, jestli se zase vrátil. Tam to bylo tak trochu na hraně, a dlouhodobě jsme byli v master data management kvadrantu, který Gartner zveřejňoval a asi ho letos zase začne používat, protože Gartner hodně pracuje s takzvaným hype cyklem a sleduje, jak ty věci vypadají. Zajímavé u MDM je, že to Gartner posunul až do fáze plateau of productivity, což znamená, že je to nástroj, který už lidé mohou běžně používat – což je skoro funkční. Možná z toho důvodu se to střídá v těch kvadrantech, ale myslím si, že teď, zejména v souvislosti s AI, vidí, že ty věci jsou důležité a je třeba posunout marketing někam dál.

Jinak se to samozřejmě točí kolem datové kvality a analytiky. I když jsme analytická firma, máme tam nějaké funkcionality, které pomáhají v analytických use casech. Mění se to, ale ne tak rychle, jak jsem osobně očekával. Nicméně určitě ty věci postupují, zejména GenAI a obecně velké téma umělé inteligence dnes už nemůže být jen o AI, ale musí zahrnovat generativní AI jako standard. To ale neznamená, že všichni vědí, co s tím, nebo že mají funkce, které jim skutečně pomůžou.

Marketing se tedy ještě hledá, v čem je generativní AI nejvíce užitečná. My máme svoji představu, ale nevidím, že by někdo udělal revoluční krok, který by všechno změnil. Spíš se to točí kolem generování a konfigurace těch věcí, které jsou nudné a nikdo je nechce klikat, dále kolem generování nějakých insightů a podobně. Hodně je to zabalené v přirozeném jazyce, což je v určitém smyslu obrovský game changer, ale nemění to zásadně procesy, které zůstávají hodně podobné.

Máme nějaké nápady, jak některé věci vylepšit, ale vzhledem k tomu, co jsem řekl, je jasné, že velké firmy jsou vůči změnám dost rezistentní. I když chtějí používat nejnovější technologie a trendy, stačí jim, když je budou mít třeba za dva roky, protože než se tam vůbec dostanou, nějakou dobu to potrvá. Neříkám, že je to naše strategie, spíš je to realita – hype existuje i na této úrovni.

Souvisí to i s další výzvou, kterou máme – že nástroje diskutujeme například právě s Gartnerem, abychom byli viditelní, a pak je prodáváme klientovi, ale zpravidla to není ten člověk, který nástroj skutečně používá. S ním tedy mluvíme jinak než s uživatelem, který ne vždy má ve finále ve věci prodeje opravdu slovo.

Ideálně jo, ale někdy se stane, že si uživatelé pořídí tuhle verzi, jsou z toho nešťastní, a my si musíme dát extra záležet, abychom je neztratili, aby to rádi používali a aby to pro ně dávalo smysl. Musíme vlastně řešit všechny tyto aspekty najednou. Někdy tak musíme hodně přemýšlet do budoucna kvůli Gartneru a hned druhý den skočit do taktického řešení pro uživatele, protože právě teď potřebují něco vyřešit. Ale na tom je to samozřejmě zajímavé a je fajn, že jsme v tom všichni víceméně na podobné úrovni s našimi konkurenty. Není to tak, že bychom my zaostávali, ani náhodou, zároveň nikdo to úplně nevyřešil – všechny tyhle problémy jsou součástí živého odvětví.

No a jak dávat dohromady tyhle dvě reality? Realitu prodeje a Gartnera, kterým se hýbe celý trh, globální ekonomiku a datový stack na jedné straně, a zároveň klienta, který pořád třeba ani nezašel do cloudu a polovinu věcí má v Excelu. Je to boj. Existuje nějaká PM poučka? Popravdě si nejsem úplně jistý, jestli nějaká úplně jasná PM poučka existuje. Myslím si, že ta největší je snažit se co nejvíc rozumět danému oboru. Já se vlastně ani úplně nepovažuji za PMa v prvním slova smyslu, spíš za někoho, kdo má rád data management a hledá, jak může být užitečný v této oblasti, a product management je pro mě nástroj, jak toho dosáhnout.

Co vidím kolem sebe, bych nejvíc doporučoval, aby lidé pochopili obor, doménu, aby dokázali nejenom brát podněty od Gartnera nebo od klientů, ale aby měli vlastní názor, viděli, kam by věci mohly směřovat a měli nějaký vlastní pohled.

To neznamená nutně jít s vlastním názorem hlava nehlava, ale je důležité mít vlastní názor, který dává smysl. Samozřejmě to nesmí být něco zcela abstraktního nebo mimo realitu, ale pokud to dává smysl a je to třeba nejlepší praxe, kterou si člověk může obhájit a prodat klientům, tak to zvyšuje jejich důvěru. Oni hledají radu, hledají vedení, a vědí, že to, co říká Gartner, je pohled na dva roky dopředu. Zajímá je to, ale praktická implementace bude vždy záviset na tom, co mají teď a co právě potřebují od dodavatele.

Takže je důležité rozumět klientům, rozumět tomu, co chtějí a zároveň vědět, že ne vždy je to, co chtějí, to, co opravdu potřebují, a směřovat je správným směrem. Ale obecně nesmíme nikoho nechat pozadu nebo říct: „Teď děláme něco, protože to Gartner řekl, a vás už dál nepodporujeme.“ Je třeba si uvědomit, že existuje škála uživatelů a my musíme mít platformu, nástroj, který dokáže žít s těmi, kdo to právě začínají používat, a zároveň přesvědčit další, aby s námi šli do budoucna.

Opravený text:

právným směrem. Je to prostě balancování, je to zajímavé a nedokážete si říct úplně ultimátní poučku, protože každý den přijde nějaká nová výzva. Dobře, takže kromě balancování mezi budoucností a současností, co plánujete v následujícím roce třeba? Na co se můžeme těšit, že přijde od Atacami nového, nebo co si přečteme v Gartneru? Doufám, že jenom to nejlepší, ale konkrétně my se chystáme na vydání zmodernizované verze naší platformy. Hodně jsme pracovali na úpravě celé architektury, jak to všechno funguje, aby to bylo trošku víc future proof a abychom právě dokázali využít ten platformní potenciál. Budeme vydávat novou verzi našeho referenčního managementu jako řešení na číselníky, který je součástí té platformy, a vlastně z nějakého, řekněme, nástroje, který používal eklipsový interface na konfiguraci a měl nějakou dělnou webaplikaci, tak najednou máme krásnou, responsivní, velmi intuitivní aplikaci, kde můžeme všechno udělat na jednom místě na základě našich oprávnění atd., což bude velká změna pro některé naše klienty a hlavně pozitivní. A i třeba jsme trochu přemýšleli o některých principech, jak se ta data dřív zpracovávala a vlastně to validujeme se spoustou klientů. No a budeme dál pracovat na AI agentech, samozřejmě, máme našeho jednoho agenta, z těch nechceme mít víc, ale samozřejmě teď v kontextu poslední doby řešíme, jak co nejlíp začít dělat nějaké ty MCP, jak se jim říká, ty interface, abychom se dokázali zapojit do dalších agentů, a samozřejmě musíme si rozmyslet dobře, kde je ta role toho našeho agenta, protože on umí nějaké specifické věci u nás, takže bychom rádi, aby se používal dál. Uvidíme, jakým směrem se bude posouvat taková ta představa, že vlastně už všechno budou dělat agenti. Myslím si, že obzvlášť v našem průmyslu pořád budeme klást velký důraz na uživatele, že ultimátní uživatelé budou rozhodovat o věcech a agenti jim budou poskytovat informace, zjednodušovat věci, automatizovat, vysvětlovat, co dělají, a budou si možná povídat s nějakými aplikacemi napříč, ale pořád tam bude potřeba dělat ty konkrétní úkoly. Dál pokračujeme s platformou, aby tam byly funkcionality, které nám to zabalí všechno do sebe, aby to dávalo smysl. Takže my budeme teď pracovat na nějaké upravené verzi naší data observability, což je vždycky trochu problém správně vysvětlit, že to je takový správný pojem, ale data observability si můžete představit jako observability nad technickými věcmi, třeba jako grafy o tom, jak vypadají systémy, jak se chovají a tak dále. Data observability vlastně říká, jak třeba běží ty pipeline, jestli se nám někde změnily datové modely, nebo někde chybí atribut, nebo prostě něco stalo, nějaká anomálie. A není to nutně jen ta datová kvalita, která spíš evoluuje data vůči nějakým pravidlům, ale je to mnohem víc tak jako real-time monitoring toho, co se děje, takže to jde hodně blízko právě k data inženýrům a k tomu, co oni budou potřebovat. No a zároveň...

(Pokud chcete, mohu pokračovat s opravou a dokončením zbývající části textu.)

Jistě, tady je opravený a stylisticky upravený text:

Jedním z velkých trendů, který se teď objevuje, jsou vlastně nestrukturovaná data. My jsme si na ně dřív moc nesáhli, a to podle mě z rozumných důvodů – dřív to nedávalo moc smysl. Ale s rozvojem například Genei a dalších modelů, které už teď existují...

Zákazníci začínají budovat svoje řešení a přemýšlejí, jak vzít všechny ty dokumenty ze SharePointu nebo odkudkoliv jinud, jak je někam nahrát a něco z nich získat. My tedy musíme – nebo alespoň máme – plány, které zatím úplně nebudu prozrazovat, jak se zapojit tak, abychom využili náš data trust i pro nestrukturovaná data.

Hodně to souvisí s tématem AI governance, tedy správou umělé inteligence, a s přípravou dat skutečně pro AI. Zároveň jde o porozumění tomu, jestli jsou ta data vhodná, fit for purpose, jestli jsou dostatečně kvalitní a jestli výsledky, které vytvářejí velké jazykové modely (LLM), nejsou zkreslené právě kvůli nekvalitním či nedostatečným datům.

Toto bude tedy nové odvětví, kam určitě půjdeme. Největší otázkou v rámci AI governance je, jak rychle do ní chceme vstoupit. Zcela jistě totiž na začátku bude nějaký chaos, lidé budou zjišťovat, k čemu to vlastně je, jaká je hodnota a jak k tomu správně přistupovat. My pravděpodobně nejdříve vyřešíme naši platformu Obzor a další související věci a s AI governance se zapojíme skrze platformu, která bude mít vše víceméně na místě a my to jen spojíme dohromady.

Takže rozhodně máme plány, kam to chceme rozvíjet, a myslím, že na příštích 12 měsíců to je tak akorát. Jsou to dost ambiciózní cíle, ale uvidíme, co všechno nakonec odebereme nebo upravíme. Je ale důležité stále koukat dopředu a plánovat, proto ty plány neustále máme. Nemáme pocit, že bychom měli hotovo nebo že něco stagnuje. Stále sledujeme, co bude dál.

No a vzhledem k plánu na příštích 12 měsíců to tak tedy vypadá. Jsem vděčný, že jste si udělali čas a přišli k nám do Data Talku, abyste představili Atacamu, co vlastně děláte a jak o tom přemýšlíte, a poradili, jak přistupovat k data managementu. Už to dávno není nějaký můz nebo nutné zlo.

Děkuju moc, že jsi tady s námi byl, Petře.

Tak jo, moc děkuju za pozvání.

Děkujeme, že jste doposlouchali až sem. A díky patří také našim partnerům a členům Data Talk klubu, kterými jsou Impex, Saska, Bystreet, Colors of Data, Revolt BI, GoodData, Keboola, Emark, Carl Data Company, Data Mind, Notino a Flow.

A pokud chcete zůstat v obraze, co se týče české datové scény a globálních datových technologií, nezapomeňte se zaregistrovat k odběru našeho týdenního newsletteru na datatalk.cz.

Nechť vás provází data.

Pokud chcete, mohu text ještě upravit podle konkrétního tónu nebo formálnosti.