Podcast

Ahoj všem, moje jméno je Barbara Hinerová a vítám vás u dalšího dílu DataTalku. Dneska tu mám Matyáše Apustu, Head of BI z Fúdory. Ahoj, Matyáši.
Ahoj, Báro.

Dneska samozřejmě projdeme Matyášovu zajímavou cestu datovým světem a zaměříme se hlavně na to, co dělá firmy doopravdy data-driven, a nějaké Matyášovo doporučení také určitě uslyšíte. Tak Matyáši, než se dostaneme k těmto zajímavým tématům, jak ses dostal k datům?

Moje cesta k datům asi začala někdy v roce 2009, kdy mi bylo 18 let a říkal jsem si, co teda vlastně chci dělat po Gimpelu. Jedna z věcí, co jsem věděl, že nechci dělat, bylo IT, protože jsem si říkal, že na IT už jsem starý.

No jasně, v osmnácti jsi za zenitem.

Přesně tak. Okolo mě byli lidi, co programovali od patnácti, a já jsem to už v životě nedoženu. Takže jsem přemýšlel, co mě vlastně baví, co umím a co by mě mohlo uživit, a vybral jsem si matematiku. Konkrétně na VŠE měli zajímavý obor, který se jmenoval Matematické metody v ekonomii, a postupně se tam objevovaly další předměty jako operační výzkum, ekonometrie, datová analýza a pořád se to sice jmenovalo jinak, ale pořád to byla aplikovaná matematika a statistika na řešení každodenních problémů.

Jasně, takže to zahrnovalo cvičení v Excelu, MATLABu a podobných nástrojích.

Přesně tak. Vyzkoušeli jsme si spoustu jazyků, které jsem pak v životě nepoužil, jako třeba Lingo nebo MPS, nebo právě MATLAB. Teď už tam snad učí Rko a Python, takže se někam posunuli, což jim docela závidím.

Pak jsem přemýšlel, kde můžu tyhle znalosti využít, a vyšlo mi, že nejvíc a nejlíp se matematika uplatní právě v IT, v datové analytice a optimalizaci. Tak jsem tam zkusil najít první práci s daty, což znamenalo, že jsem měl jeden Excel, do kterého jsem zadal úplně všechno, protože to byl tehdy nejlepší způsob, jak jsem uměl pracovat s daty. To byly informace o brigádnících, nějakých spoluprojektech, fotky a tak dále — veškerá data, co jsme měli, jsem se snažil sbírat do jednoho Excelu, a pak jsem se divil, že to běží hrozně pomalu.

No jo, klasika.

Dobře, takže to byla zkušenost z ČSOB, tedy práce s vahybáním Excelu do systému pro brigádníky. A dál tě to vedlo kam?

Po škole jsem nastoupil do ANG, kde jsem začal dělat práci nazvanou Data Miner — tehdy frčel data mining, to byl takový buzzword v roce 2015. V podstatě jsme dělali reporting, což znamenalo, že jsme spouštěli SQL query z databáze a výsledky copy-pastovali do PowerPointových prezentací.

Ale co bylo zajímavé, bylo to, že když nám to zabíralo dost času, protože to není nejrychlejší způsob tvorby reportingu, tak jsme při tom koukali do dat a snažili se najít důvody, proč se věci vyvíjejí tak, jak se vyvíjejí. Proč třeba naše kampaně fungují nebo nefungují, které produkty fungují a které ne. A k tomu jsem vždycky dodával nějaké vysvětlení a povídání.

Co je…

Měli rádi ten report, protože vlastně každý týden čekali, až jim přijde ten PowerPoint. Takže to bylo aktualizované každý týden, jo? Tady ten PowerPointový report. Přesně tak, to byl náš reporting tam. No, tak jsi tedy nedělal nic jiného než copy-paste, ne? Já jsem to měl docela vychytané. Zjistil jsem, že v PowerPointu jsou ty grafy nějak vzájemně provázané, takže jsem si to vylil do jednoho grafu, který měl na pozadí nějaký Excel, a když jsem pak otevřel ty ostatní grafy ve správném pořadí, tak se mi to načetlo přes nějaké nahrávání přímo mezi těma Excelama na pozadí. Ale taky to není úplně best practice. No, aspoň že nějaká automatizační linka tam byla nastavená. Jasně, takže máme ENG a reporting v PowerPointu. Potom tedy tvoje cesta vedla už do konzultačky, viď? Přesně tak, pak jsem nastoupil do Revolt BI, tehdy nově vzniklé konzultačky, kde jsem začal jako data scientist. A to je jaký rok, ještě mi řekni? To je rok 2018. Jasně. A když děláš data scientistu v konzultačce, hlavně v nově vzniklé, tak děláš úplně všechno. Takže to byl data engineering – člověk se musí k datům dostat, poskládat si je, pak trošku data science, kdy vytvoříš zajímavý model a něco z toho vyčteš, pak je potřeba to odprezentovat, takže nějaká datová vizualizace v Tableu nebo v Power BI, pak to často musíš probrat s klientem, takže jsi vlastně konzultant i trochu salesák, navíc začínáš vést svůj tým, takže i trochu HR, takže prostě děláš úplně všechno. Ale na to jsi byl zvyklý z těch podržtaškových pozic předtím, ne? Přesně tak, to byla dobrá příprava. Jasně. Byla to pro tebe velká změna dělat najednou reporting v Tableu, v Power BI místo těch vychytaných PowerPointů? No, bylo to super. Musím říct, že to byla velice příjemná změna, protože jsem objevil Kebulu, která mi tehdy umožnila pracovat s daty velice přívětivým a snadným způsobem. Takže v tom to bylo fajn. Zároveň samozřejmě spousta věcí byla náročných v tom, že člověk neměl, na koho se zeptat. Prostě řešil problémy, jak nejlíp uměl, ale když nás tam na začátku bylo pět, tak to bylo limitované. Tady je rybník a plav. Přesně tak. No a možná je to jednodušší než dostat se k pokročilejším technologiím, když to opravdu vykopáváš tím rejčem a děláš to tou komplikovanější cestou, a potom když ti někdo nabídne nějaký rozumný datastek, tak se v tom možná lépe orientuješ, nebo taky ne, ale prostě není to až tak složité se do toho dostat. Hlavně když člověk vystřídá víc nástrojů a přístupů, uvědomí si, jak to může fungovat trochu jinak, a zjistí, že nástroje nejsou vyloženě dobré nebo špatné, ale každý se hodí na něco jiného a je dobré používat správný nástroj na správný problém, protože jinak se člověk strašně nadře. No jasně. Co tam pr…

Opravený text:

O tobě bylo, nebo takhle—v Revoltu jsi byl docela dlouho, kolik let?
Bylo to nějakých pět let.
Tak co ti to všechno dalo? Co jsi se tam všechno naučil?
Dalo mi to docela velký rozhled v tom datovém světě, co všechno vlastně firmy řeší za problémy. My jsme tam pracovali pro firmy, jako je třeba Sportissimo, kde jsem dodával nějaký prediktivní model, co budou prodávat na prodejnách, nebo třeba pro Stockboschkov jsme zase sestavovali nějaký datamart v Kebule. A byly to hodně zajímavé problémy, které jsme řešili, a člověk je řeší tak nejlíp, jak umí, takže se tam člověk prostě naučí – když má nějaký problém, potřebuje ho vyřešit a nemá moc času přemýšlet nad tím, jestli ta cesta, kterou si vybral, je ta úplně nejlepší, prostě to dělá tak nejlíp, jak umí. Cílem je, aby byl klient spokojený.
No jasně, takže široký rozhled zkrátka nad tím, co se s daty dá řešit a jak k tomu dojít, jestli tomu správně rozumím.
A potom tady už vlastně ta tvoje aktuální role přišla po Revoltu. Jak ses k tomu dostal, co tě vedlo vlastně přejít z toho konzultačního byznysu přímo do interního týmu?
Jo, tak jedna z věcí, co jsem dělal v Revoltu jako data scientist, bylo zjištění, že dělat data scientistu v konzultační firmě je poměrně náročné, protože abyste byli dobrý data scientist, musíte dokázat vydolovat nějaké zajímavé hluboké vhledy, nějaké insighty, a to prostě nejde, když přeskakujete z projektu na projekt a když musíte stíhat pozornost. Takže jsem pak zjistil, že se mi nejvíc líbí dlouhodobé projekty, kde pracuju delší dobu s těmi samými lidmi a s podobnými daty.
Máš šanci pochopit i ten byznys, jak funguje.
Přesně tak. A tak jsem si řekl, že po pěti letech přišel čas prostě z konzultačky odejít. Dal jsem si volno a pak jsem na podzim vstoupil do Fudory.
Jasně, to je super. Jak vlastně vypadá ta tvoje pozice? Co tam teda začal dělat a na co tě najmuli?
Moje pozice je Head of BI. Vedu asi čtyřčlenný tým a jeden z prvních úkolů, co jsem dostal, bylo: máme tady velice hezké a použitelný řešení BI, ale chceme to celé rozbít a postavit znovu. Protože nás čekala migrace reportingu – v první řadě se jednalo o migraci přímo toho vizualizačního nástroje, kde dřív používali GoodData a potřebovali to dostat do Tableau. A druhá věc pak byla migrace nějakého backendu, protože tam měli ETL postavený v Kebule a potřebovali to dostat do BigQuery v Google Stacku.
A proč se tahle migrace plánovala? Proč se to vůbec stalo?
To trošku souvisí s tím, jak Fudora funguje. Fudora je součástí celosvětové firmy Delivery Hero, která působí asi ve 70 zemích. A já nechci úplně řešit, jestli GoodData je lepší nebo horší nástroj než Tableau, ale každopádně, když máte 10 zemí a z toho 9 používá jeden nástroj a jedna jiný, tak je to…

Jestli chceš, můžu opravit i pokračování.

Opravený text:

Problém. A oni se snažili tenhle problém vyřešit. V čem jsem jim tam dokázal pomoct bylo to, že oni se dokázali velice dobře poradit ve svém stávajícím řešení, ale neměli moc chuť nebo se trochu báli celé to překopat. A tam se mi vlastně hodil někdo z konzultačky, kdo byl poměrně zvyklý stavět věci na zelené louce, prostě překopávat a vrtat se v nich. A tak si mě na to najeli.

No tak dobrý. Tak nám pověz, jak to probíhá, nebo už jste tu migraci dokončili? Kde tedy teďka jste?

Teď dokončuju tu druhou část. Ta první část, vlastně migrace reportingu, proběhla během prvních tří měsíců letošního roku. Takže skončila někdy v dubnu. A to se povedlo, reporting teď běží v Tabulu, plus se to doplnilo Lukrem, takže Lukr a Lukr Studio, což jsou vlastně datavizualizační nástroje od Google. A myslím, že to proběhlo velice dobře. Samozřejmě byly tam nějaké porodní bolesti, ale překvapivě malé.

Prozradíš nám nějaké zásadní porodní bolesti nebo něco, co tam neproběhlo úplně podle očekávání, řekněme, na co si dát pozor, když někdo něco takového dělá?

Tak jedna z věcí, co byla problém, bylo, že ty nástroje fungují trochu jinak. V GoodDatě jsme se hodně snažili mít hezký, vyhezkanej datový model, který byl napříč všemi reporty stejný. A Tablo vlastně vede člověka spíš k tomu, že co dashboard, to nějaký individuální datamart z důvodu výkonu nebo i jiných důvodů. Naše první snaha všechno stavět na tom jednom datovém modelu se ukázala jako problematická, protože to bylo pomalé. Takže jsme pak řešili, že nějaký každodenní report, který uživatel má používat několikrát denně, nabíhal příliš dlouho a to bylo potřeba vyřešit jinak.

Jasně, takže performance jste vyřešili tak, že jste ty reporty skládali jinak. Můžeš nám prozradit, jaké jsou nejdůležitější reporty nebo hlavní problémy, které se pomocí nich řeší?

Jsme firma, která odbavuje milion objednávek měsíčně. To znamená, že je tu velký důraz na logistiku, aby se objednávka ve chvíli, kdy si ji zákazník zadá, dostala včas k němu. Jeden z hlavních uživatelů těch dat je logistika, která sleduje aktuální stav i forecast dopředu a kontroluje, jestli všude stíháme, jestli někde nehrozí nedostatek kurýrů, jestli není nějaký výkyv v poptávce nebo např. jestli není ucpaná nějaká důležitá silnice, což by znamenalo, že logistika přestává stíhat. To je taková operativní věc, která se řeší každou hodinu a probíhá v podstatě v reálném čase.

Pak je tu reporting na denní úrovni, kdy se sleduje, jak se minulý den vyvíjely objednávky z pohledu třeba salesu nebo marketingu, jak probíhají marketingové kampaně a tak dále. A pak jsou tu strategičtější věci, které se sledují dlouhodobě.

Jasně, tady je opravený text:

Třeba na týdenní nebo měsíční bázi. Celkové tržby a podobně? Přesně tak, ale třeba i hiringový proces. Teď je třeba prosinec, potřebujeme nabrat hodně kurýrů, abychom zvládli tu největší špičku. Sledovali jsme několik týdnů a měsíců náš hiring funnel, jak nám dobře fungují jednotlivé kanály, které používáme, abychom dostali kurýry a měli jich pak dost, až přijde ta největší píka poptávce.

U té logistiky jsi zmínil také predikce, že predikujete, kdy může nastat nějaký problém. Můžeš o tom říct víc?

Třeba jít víc do hloubky u tohohle a jak přesně se vám daří predikovat výkyvy objednávek, případně do toho zapojovat další věci, jak jsi říkal, například ucpané silnice, počasí a podobné faktory?

Hodně z těchto věcí neděláme přímo my. To je zase jedna z výhod toho, že Delivery Hero, což je matka Foodory, je opravdu velká firma, a právě ty machine learningové modely se nevytváří přímo tady v Čechách. Nicméně do toho pak dohlíží lidé tady na logistice, kteří to obohatí o lokální know-how. Takže to je jedna z věcí, zároveň je to kombinace strojového učení, lidského insightu a know-how těch lidí, kteří data spravují, sledují a upravují. Třeba úplně jinak zohledníme státní svátky než jiné země, takže i poptávka vypadá odlišně. Velký vliv má tedy místní tým.

Jak funguje spolupráce mezi vámi a zahraničními pobočkami Delivery Hero? Kdo co dělá, učíte se od sebe, kdo je v čem lepší?

Myslím, že je to jedna z velkých výhod — těch týmů je víc a řeší někdy podobné problémy, takže když má někdo problém, má se na koho obrátit. To je velká přidaná hodnota u takové firmy oproti třeba konzultační firmě. Co se týče konkrétního srovnání: v Budapešti mají menší tým, který je ale hodně silný v data science a pokročilém modelování. My jsme pak spíš silní v reportingu, řešení, která jsme tady postavili za poslední rok, jsou už od nás přejímána i ostatními pobočkami. V Turecku je pak velký tým lidí zaměřený na data engineering, pracují například v DBT, Airflow a řeší technickou část datové práce.

Setkal ses někde v zahraničí s něčím neobvyklým nebo zajímavým z hlediska dat?

Jo, vtipná historka je, že lidi ze Singapuru byli překvapení, že u nás není sto procent objednávek rozváženo na kole. V Singapuru je totiž auto luxus a všichni kurýři tam jezdí jenom na kolech, případně na motorkách. To, že by někdo vozil jídlo autem, je tam naprosto nepředstavitelné.

Pokud chceš, můžu text upravit ještě víc, nebo přepsat do formálnější podoby.

Opravený text:

Jídlo autem je pro ně nepředstavitelné, u nás to je pořád velká část těch dodávek.
A je to, nebo asi tahle čísla se taky budou měnit podle sezonnosti, že jo? Teďka už na kole asi někdo moc nejezdí, v listopadu už je docela zima.
Jako je jich míň, ale pořád jsou lidi, co si rádi i v tomhle počasí jedou na kole.
No tak dobře pro ně.
A možná další faktor té zahraniční spolupráce je, že ono to pak zase vyřeší otázku duplicit, protože se ty samé činnosti dělají víckrát, a to je něco, co je teď velké téma. Takže se vlastně hledá, jak to poskládat tak, aby týmy využívaly zdroje optimálně, byly opravdu efektivní. A to je vlastně náš plán na nejbližší měsíce – zjistit, v čem je přesně pražská nika, co je to, v čem jsme silní, a kde můžeme pomáhat ostatním skupinám.
Jasně, takže se může stát, že v Praze budete mít centrum reportingu, zatímco v Maďarsku si stále budou dělat data science, machine learning a tak dále. A zkrátka si budete tyto úkoly mezi sebou předávat podle toho, co vám dodají zahraniční týmy.
Přesně tak, určitě tam bude nějaká spolupráce, proto většina specializací těch jednotlivých center vzniká.
To je zajímavé, můžeš tedy říct, jak vypadá ten tým v Čechách?
Tak tým v Čechách, tady nás teď pět. Jsem tam já, je tam jeden seniorní kolega, který má na starosti hlavně správu datamartů, tedy přípravu dat v SQL a tak dále.
Pak jsou tam dvě kolegyně, každá se specializuje na nějaký nástroj – jedna z nich na Tableau, druhá na Looker. A pak je tam kolega, který má na starosti customer experience, což je také součást BI týmu.
Obsluhujete tedy těmi reporty českou pobočku, nebo už se děje i to, že třeba máte školení pro zahraniční pobočky a říkáte: „Hele, vytvořili jsme nový report, který řeší predikci zpoždění objednávek, pojďte ho taky používat, tady si ho můžete nasadit.“
Jo, většina našich řešení byla původně vyvíjena lokálně a ta, která se osvědčila jako použitelná, slouží pak jako inspirace pro další země. Ať už tedy vznikne něco podobného samostatně, nebo dostaneme přímo úkol: „Tohle je super, udělejte stejné řešení pro ostatní země.“
Jasně, jak teda vypadá ten tech stack? Bavili jsme se tady o migraci, takže tam je BigQuery, Looker, Tableau. Zmínil jsi ještě dbt, Airflow a podobně, můžeš to popsat víc do detailů, co všechno tam používáte?
Tak v reportingu je pořád Tableau, to znamená, že většina lidí kouká do Tableau, kde jsou hlavní reporty – jak pro management, tak i pro jednotlivá konkrétní oddělení. Na druhém místě je Looker, resp. teď nový Looker Studio, kde díky úzké spolupráci s Googlem testujeme tento nástroj a musím říct, že je to zajímavá zkušenost být u prvotních verzí tohoto reportingového nástroje. Samozřejmě…

(Poznámka: Text končí nedokončený, pokud chcete, mohu pomoci i s pokračováním.)

Jasně, tady je upravený a trochu přehlednější text:

Ejmě to má nevýhody, prostě není k tomu taková dokumentace, není k tomu taková komunita, ale zase je zajímavé, že třeba tím, že to vlastně neumí tolik funkcí jako Tableau, tak je to jednodušší na práci a člověk se v tom uživatele tolik nezahltí. Takže to někdo preferuje a má třeba podle mě lepší práci s datovým modelem než v Tableu. V tom je to trochu střihlé na ty good data, na která jsou lidé zvyklí pořád.

Máš to rozdělení podle use case? To znamená, co děláte v Tableu a co v Looker Studiu, je tam nějaký rozdíl? Třeba logistice to dáváme do Tableu, protože jsou na to zvyklí a protože ty projekty jsou složitější. Je tam nějaký takový rozdělovník?

Asi bych řekl, že hlavní rozdělovník je ten, že pokud je to pro vyšší management, tak je to v Tableu, protože reporty jsou hezké, líbí se jim to, je to pro ně důležité – barvičky atd. Looker Studio se zase používá pro hodně takové near real-time dashboardy. Looker se doporučuje také jako nástroj tam, kde jsou lidi víc datově pokročilí. Máme třeba oddělení quick commerce, které řeší, že přes Foodoru můžete objednat nejen jídlo z restaurace, ale i ze supermarketu nebo z našeho dark storu.

To je tým hodně datově pokročilý, takže pro ně dává Looker větší smysl, protože je to self-service reporting. Někteří zase chtějí pouze vidět report, který jim každý den svítí, kde nějaké metriky jsou červené, jiné zelené, a podle toho vědí, co mají dělat, bez potřeby na něco klikat.

Dobře, takže se zasekneme u těch reportovacích nástrojů. Co se týče dál v datastacku, co tam najdeme? Stále tam je Keboola, která se hodí na nějaké zpracování dílčích use case. Používáme i Clever Maps, což používají naši sales, protože geodata jsou pro nás důležitá třeba pro otevírání nových restaurací nebo příležitostí po celé republice. Spolupráce s Clever Maps je dlouhodobá a jsme velice spokojení, což nás těší.

Matyáši, ty vždycky říkáš, že Foodora je podle tebe opravdu data-driven firma, že je to příjemná změna, protože jsi viděl hodně firem, jak fungují, i když si myslí, že jsou data-driven, ale ve skutečnosti nejsou. Jaké jsou podle tebe hlavní body, díky kterým můžeš s klidným svědomím říct, že Foodora je opravdu data-driven firma?

Když to vezmu zhora, tak management hodně kouká do dat a každý board meeting probíhá tak, že se ukáže report, probírají se metriky a lidé říkají: „Toto svítí červeně, protože… a děláme s tím tohle.“ Obecně je tam fakt snaha, aby každé rozhodnutí bylo nějakým způsobem podloženo daty. Samozřejmě pak na jiných meetingách se řeší strategické věci…

Pokud chceš, můžu text ještě více zkrátit, nebo rozčlenit do otázek a odpovědí. Stačí říct.

Jistě, tady je opravený text:

Je metriky na té měsíční bázi nebo operativně ty každodenní, ale základem každého rozhodování jsou nějaká data, takže to je jedna z věcí. Druhá věc je, že ta data mají pak nějaký vliv na hodnocení lidí, ať už přímo finanční nebo v rámci výkonu (performance). A to vlastně pak slouží i k nějaké dobré interní kontrole, protože ve chvíli, kdy na nějakém čísle záleží, například jaký dostaneš bonus, tak si hodně hlídáš, aby to číslo svítilo správně. A když tam občas dojde k nějakým datovým výpadkům nebo nějakým nejasnostem, máme velmi rychlou zpětnou vazbu, že je potřeba něco opravit a upřesnit.

Máme spoustu automatických i polootomatických procesů, které se odvíjejí od dat. Když jsem tady například mluvil o logistice, tak ve chvíli, kdy se ukazuje, že máme nějaké problémy s dodávkami, spustí se procesy, které tyto problémy začnou nějakým způsobem řešit. Jednou z možností je, že pokud máme moc objednávek a nestíháme je odbavovat, může se doprava trochu zdražit. Druhá věc je, že se pak může stát, že začneme snižovat některé dodací zóny.

Jo, jasně. Omezíte to trošku, aby to nebylo zase tak šílené.

A to zdražení dopravy je kvůli tomu, aby lidé tolik neobjednávali?

Řekl bych, že je to takový klasický princip nabídky a poptávky. Ve chvíli, kdy nestíháme odbavit všechny, kteří by chtěli, což je samozřejmě primární snaha, ale když už to nejde, musíme to nějak prioritizovat. Jedním ze způsobů, jak to prioritizovat, je to trochu zdražit. Najednou za to lidé musí dát o pár korun navíc a to pomáhá rozlišit priority, tedy které objednávky jsou opravdu významné.

Říkal jsi i něco o omezování zón – takže když je hodně objednávek a někde to nestíháte, tak se restaurace některým lidem už v určité vzdálenosti nezobrazují?

Přesně tak. Standardně můžeš objednat z restaurací v určité vzdálenosti, ale když se ukáže, že naše logistika má problém stihnout doručit všechny objednávky, začneme nabízet restaurace, které jsou blíže. Máme tak větší jistotu, že se najde kurýr, který ti to dokáže přivézt a že budeš spokojený, než aby ti někdo vozil jídlo přes celou Prahu.

Jasně, to je pizza.

Přesně tak. Kurýrům to nezávidím, protože když sám jezdím po Praze autem, jsem z toho docela vystresovaný a myslím, že tohle dělat je čistý masochismus. Zkoušel jsem tu roli krátce před čtrnácti týdny a bylo to docela zábavné. Připomínalo mi to doby, kdy jsem hrál nějaké RPG, třeba World of Warcraft – člověk dostane úkol, něco mu tam naskočí, někam jede, něco vyzvedne, něco doručí. U toho si i docela odpočine, a hlavně na konci dodáš jídlo někomu, kdo měl hlad, a ten člověk je vždycky velmi vděčný, spokojený a rád – takže to je tak.

Pokud chceš, mohu text ještě upravit do formálnější nebo naopak neformálnější podoby.

Opravený text:

To je vlastně hezká část té práce, když na konci je spokojený zákazník, který si právě vyřešil svůj problém. A proč to bylo? Protože jste měli málo kurýrů, tak jste třeba udělali akci: „Hele, pojďme všichni rozvážet jídlo,“ nebo jsi si chtěl zkusit nějakou roli, kterou normálně neděláš. Nebo ne všechny, ale zkrátka nějakou roli, pro kterou děláš to, co děláš? Byla to akce vyloženě pro management, aby si vyzkoušeli i jiné aspekty a aby tomu trochu rozuměli. Já se na to samozřejmě dívám z datového pohledu, protože všechna data, která máme, pocházejí nějakým způsobem z aplikací. Kurýři mají taky svoji aplikaci a ve chvíli, kdy přijmeš objednávku nebo předáš objednávku, tak vznikají datové touchpointy. Bylo zajímavé to vidět z pohledu datového zdroje, když jsem zvyklý koukat na velká čísla, procenta a grafy. Ty jsi chtěl být taky tím číslem, které do toho spadá. A ještě něco jiného jsi v rámci Foodory zkoušel? Třeba uklízet kuchyňku nebo tak?

Čeká nás teďka ještě šichta ve skladech. Máme tam „dark story“, což by mělo přijít teď někdy v prosinci. Takže balit objednávky?

Přesně tak, přesně tak. Vyzkoušet si, jak to funguje přímo na skladu, protože z toho taky máme samozřejmě spoustu dat.

No jasně. A zase je tam i ta práce, kdy si můžeš ověřit, jak ta data vznikají.

To je krásné, že máte takovéhle výlety z vašich pozic. A jak dlouho jsi to dělal? Třeba aspoň týden?

Ne, ne, byla to hodinka a půl, něco takového.

No tak to nic moc, mohl jsi vydržet déle!

Byli se mnou spokojení, prý ať se vrátím, tak uvidíme, když přestanu obírat data, tak třeba začnu zase vozit.

No to je skvělé, třeba Matyáše potkáte ve dveřích, až vám bude předávat pizzu nebo něco takového a vyřeší vám problém.

Nicméně zpátky k těm problémům, které řešíš častěji, nebo každý den, řekněme. Bavili jsme se o tom, proč si myslíš, že je Foodora data-driven. Trochu jsme odběhli k práci kurýra, tak se k tomu ještě vraťme.

Říkal jsi, že management používá data a v logistice je to hodně o tom vědět, když se děje nějaká odchylka od normálu. Jsou tam ještě další oddělení, která bys rád zmínil?

Jo, například sales. Co vlastně znamená sales ve Foodora? Znamená to, že naši accounti objíždějí různé restaurace nebo větší řetězce typu McDonald's, a nějakým způsobem s nimi diskutují o spolupráci, ať už nové, nebo stávající. Mají k tomu hodně datových podkladů, které aktivně využívají. Takže jsou schopní ukázat majiteli restaurace, který často není datově zdatný – to je hospodský –, že tady jsi nás zapnul, teď ti rostou objednávky takhle, tady jsi nedávno vstoupil do kampaně a díky tomu máš o tolik peněz víc. Takže s námi… (pokračování textu)

Tady je opravený text:

Spolupracuj dál, protože to je super, jo. A to jsou vlastně věci, kde opravdu jsou ty nejvíc používané reporty, protože těch účtů je hodně a to jsou reporty, na které se lidi koukají několikrát denně. Taky je potřeba, aby to bylo rychlé, protože člověk má třeba tendenci mít osm schůzek, oběhat několik restaurací a prostě potřebuje vidět jasná, velice přehledná čísla. To nejsou žádné hluboké analytické insighty, to prostě…

Tady je graf – takhle máš objednávky a ta čára jde nahoru, takže chceš mít radost. No jasně. A potom tady je i akvizice nových restaurací, že jo? O tom něco vím, jak to funguje ve Fooduře. Nechceš o tom taky něco říct? Jo, tak tam zase koukáme, kde by stálo za to získat nové partnery, kde nám třeba chybějí nějaké zimní restaurace, nebo ve kterých městech zatím nejsme, nebo v těch městech jsme, ale chybí nám tam zajímavá asijská restaurace nebo něco podobného.

K tomu používáme třeba cover maps, kde se díváme na to, odkud máme hodně sessions, ale vlastně tam nemáme tolik objednávek. Takže je to způsob, jak zjistit, kde bychom potřebovali mít víc restaurací, větší nabídku a tak dále. Pak další věc, kterou hodně monitorujeme, jsou takzvané soft faktory, jako je zákaznická spokojenost. Řešíme C-SAT, řešíme NPS – běžné metriky, kde lidé nějakým způsobem číselně vyjadřují, jak jsou s námi spokojení. A protože máme poměrně hodně touchpointů, jsme schopni na základě toho udělat nějakou statistiku a říct si: „Jo, tohle jsou věci, na kterých se potřebujeme zapracovat.“ A naopak třeba některé věci, které jsme považovali za problém, se v praxi ukázaly, že takové nejsou, takže nejsou prioritou.

Pro textovou analytiku těch odpovědí už teď používáme i nějaký EIK, necháme to projet třeba Gemini, který z toho vytáhne jednoduché shrnutí. „Toto jsou teď problémy, kterými byste se měli zabývat.“ To je dneska už taková běžná věc, ale samozřejmě super, že o tom mluvíš. Ještě něco dalšího?

Dobře, prošli jsme jednotlivá oddělení, kdo všechno data používá, proč a jak, máme AI, takže jsme data-driven, ale jsou tam ještě nějaké další faktory, třeba způsob práce s daty, jak to třeba podporuje management, aby se takové věci děly?

Myslím, že jednou z věcí, co nám v tom pomáhá, je to, že ta data vůbec máme. V Fooduře, když to hodně zjednoduším, máme tři aplikace. Jednu aplikaci má zákazník, který si vybere, že má hlad a chce si objednat. Druhou aplikaci má restaurace, která dostane objednávku a má ji nějak vyřídit. A třetí aplikaci má kurýr, který dostane objednávku a má ji doručit. A tohle by šlo samozřejmě vyřešit mnoha způsoby, ale ten způsob, jaký jsme zvolili – kdy si dáte jídlo přes Fooduru – je prostě hodně datově orientovaný, protože sbírá…

Pokud chceš, mohu ti pomoci dál s opravou nebo doplněním textu.

Tady je opravený text:

Ty endpointy z těch jednotlivých zařízení, tím pádem máš k dispozici data, která si můžeš dlouhou dobu uchovávat a nějakým způsobem je vyhodnocovat. Tím, že máme v aplikacích, cokoliv se stane, vidíme to a sbíráme data. Myslím, že je to něco, co je ve firmě už hodně dlouho. Když to před 12 lety zakládal Tomáš Čupr, o kterém vím, že je hodně datový, tak určitě ta kultura a procesy, že lidem ukazujeme data, jdou částečně i za ním, jak to tehdy nastavil. Pak samozřejmě je tam mraky práce, kterou udělali od té doby. A možná je to i rychlostí, jak ten byznys funguje, že opravdu potřebuješ být efektivní, aby byli všichni spokojení. Jakmile ti nějaký článek vypadne, tak to celé nefunguje. Takže to je možná další faktor, proč…

Jo, přesně tak. Nedávno jsme se bavili s nějakou pojišťovnou, která nám hrdě říkala, že dělají digitalizaci a díky tomu třeba zrychlili response time jejich podpory z týdne na dny. Já si tak říkám, představit si, že náš klient má problém, protože má hlad, a my mu odpovíme za týdny nebo dny, my máme response time v řádu minut. To samozřejmě nejde jinak, než být digitální.

No jasně. A hlavně je to jiný byznys, nebo spíš je to jiný starý byznys – 12 let je sice dost, ale pořád není tak starý jako některé jiné firmy, které tu jsou dlouho. A někdy ta transformace bolí víc, než to prostě udělat od začátku s daty.

Přesně tak. A máš nějaká ponaučení za tu dobu, co jsi ve Foodoře? Vím, že jsem se na to už ptal, ale teď, když se na to podíváme znovu po té diskuzi o dalších věcech, které tam řešíte, je něco, co jsi se naučil, nebo naopak něco, co úplně nevyšlo, a přineslo to nějaká ponaučení?

Jedna z věcí byla, že my jako každý datový tým byli hodně orientovaní na řešení. Řešili jsme, jestli něco bude v Tablu, nebo v GoodData, nebo v Lookeru a tak dále. Ale výsledku je uživatelům dost jedno, v jakém nástroji to je. Člověk má nějaký problém a chce ho vyřešit. Manažer chce vidět, jak se daří celé firmě a kde jsou problémy. Šéf sales oddělení chce vidět, kteří salesáci performují dobře a kteří hůř. A jestli na to bude koukat v Lookeru nebo v Tablu, mu je v podstatě jedno.

Výsledku mu stačí, že má nástroj, kde to uvidí, ideálně tak, aby se mu nástroj neměnil pod rukama každou chvíli. Pokud mu to měníme kvůli migraci, potřebujeme ho proškolit a ukázat mu: „Vidíš, tady jsou pořád ty samé čísla, co jsi viděl předtím, jen v jiném nástroji.“ Pak třeba můžeme report upravit a zlepšit, ale základ je postupná změna, aby člověk nebyl hned zahlcen, protože ne všichni uživatelé jsou tak datově zkušení, že bychom…

Jasně, tady je opravený text s lepší srozumitelností a jazykovou úpravou:

Jsou datoví specialisté na své pozici, ale nejsou to takzvaní „dataři“, kteří by dokázali nejen řešit úplně nový problém v úplně novém dashboardu, v úplně novém nástroji. To je prostě zmatek. Tím, že ta změna byla maximálně postupná, to bylo hodně plynulé a zvládli jsme to za plného provozu – v tom nebyl žádný freeze, že by lidi měsíc neviděli žádné dodávky, to by ani nešlo. No jasně, to by opravdu nešlo.

Ale to nás vede k tomu, že se musí začínat od business case, tedy od řešení, které to má přinést, a ne úplně se ujet na finální technologii nebo něco podobného. Jo, myslím si, že hlavním úkolem datového oddělení není pouze používat datové nástroje, ale řešit datové problémy lidí ve firmě. A občas se může stát, že člověk upadne do pasti svého oblíbeného způsobu řešení a snaží se ho aplikovat za každou cenu, pak se ale odchýlí od původního problému.

Takže sice může vytvořit skvělý prediktivní model, ale uživatel pořád neví, co má dělat, protože nevidí každý den v grafu, co jsou ty věci, které má řešit. Je potřeba vylézt ze své skořápky a neujíždět tolik na technologiích, které jsou samozřejmě skvělé, vymazlené, ale zapomínáme na uživatelskou zkušenost reálného člověka, který se do toho pak dívá.

Přesně tak, je důležité být pořád v kontaktu s finálním uživatelem, zeptat se ho: “Řeší to, co jsme dodali, tvůj problém? Ano nebo ne? Je potřeba něco dalšího dodat?” A mít přehled o tom, co se ve firmě obecně děje, jaké jsou priority, a ne být zahlcený jen svojí jednou věcí, kterou řešíš.

Takže být konzultantem navždy – ať už přímo v interním týmu firmy, nebo v konzultační agentuře. Nemyslím si, že je rozdíl mezi konzultačkou a firmou. V konzultačce jsem se třeba setkal s názorem, že datař má být jen „písařem“, takže nepotřebuje širší rozhled. S tímto názorem nesouhlasím, protože si myslím, že to výsledku není jedno.

Když přijdeš za někým a řekneš: „Hele, ten program, co jsi napsal loni, nám ušetřil půl milionu korun,“ to zajímá každého. Nebo když to není business, tak třeba: „Tento tvůj program teď lépe predikuje rakovinu.“ Vždy je potřeba vědět, proč to vlastně dělám, abych si uvědomoval celkový důvod a svůj malý přínos k tomu, jak přispívám k velkému cíli.

Mně přijde, že někdy datař a programátor nejsou úplně totéž – i když to není stejná věc. Programátor, když vyvíjí software, chce také řešit nějaký problém, ale často jen plní díry, píše kód, mění barvu tlačítek a tak. To samozřejmě přeháním, nechci to dehonestovat, ale i to je realita.

Pokud chceš, mohu ti pomoci i s další částí nebo s úpravou textu do oficiálního stylu.

Jistě, zde je upravený a opravený text:

V dnešní době já sama, stejně jako naši dataři, kladu velký důraz na to, aby rozuměli tomu problému a aby dělali věci, které skutečně dávají smysl, a neujížděli si zbytečně na nějakých datových věcech. Samozřejmě, ať už data tam jsou, ale musí mít smysl pro zákazníka. Přijde mi, že na dataře je dnes daleko větší tlak, aby tomu rozuměli, ale potom máme vývojové týmy, které stále fungují tak, že mají nějaké dílčí úkoly, třeba tikety v nástrojích jako Asana nebo Jira, které odpracují a pak jdou domů.

Pokud pak problém není přímo na konkrétním člověku v týmu, padá to víc na manažera, který dostává otázky typu „Proč to zase musíme upravovat?“ A když odpoví, že neví, že si to někdo vymyslel, třeba management, tak logicky motivace lidí je jiná, než když řekneme: „Hele, vím, že je to další změna, ale ta změna se děje proto, že má velký dopad na to, jak se ve firmě cítí a jak se jim pracuje.“ To pak má výrazný dopad i na kvalitu řešení – tedy jestli dané řešení skutečně pomůže vyřešit původní problém, nebo ne.

Tím se dostáváme možná k doporučením z tvého pohledu, jak to vidíš ty, a jak můžeme posluchačům, kteří řeší podobný problém a snaží se budovat opravdovou data-driven kulturu, pomoci. Máš pro ně nějaké rady, jak podporovat propojení dat s byznysem a jak skutečně řešit ty problémy, které firma má, případně jaké jsou potřeby uživatelů finálních reportů nebo jiných datových produktů?

Myslím si, že začátek je definice problému nebo priorit – co jsou ty klíčové věci, které firma řeší, nebo co je ta věc, kterou chceme řešit a vyřešit. A teprve potom je otázka, jak k tomu mohou přispět data nebo datový tým. Já jsem si mnohokrát vyzkoušel špatný nástroj na řešení problému, ale nakonec to bylo jedno, protože ten problém jsem vyřešil. Například PowerPoint. V době, kdy jsem pracoval v konzultacích, byla jedna zábavná situace u klienta, kde jsme neměli přímá oprávnění zasahovat do SAPu, ale mohli jsme měnit hesla uživatelům, takže jsme se přihlašovali pod jejich účtem. Byla to jejich best practice. Přežili jsme to, ale dnes bych to rozhodně jako best practice nedoporučil.

Nakonec jde o to, že člověk vyřeší problém, ne vždy má k dispozici ten „správný“ nástroj. Ten správný nástroj často nepoužíváme kvůli uživateli, klientovi nebo šéfovi, ale kvůli sobě, abychom s ním dobře pracovali. Proto je důležité uvědomit si, jaké problémy jsou kolem nás.

Máte-li zájem, mohu pokračovat v opravě i dalších částí textu.

Tady je opravená verze textu:

Ty lidi chtějí vidět hezké grafy, a já jim ty hezké grafy můžu dělat v Excelu nebo v PowerPointu, ale bude mě to stát strašné množství práce. Proto řeknu někomu, že by se nám hodilo mít tablo, protože pak ty samé grafy, které po mně chceš, udělám jednou za týden a uděláme dva denně. Takže to zvládneme a bude se to i aktualizovat, třeba každých pět minut a tak dále. Je tedy potřeba rozlišovat tyhle dvě věci – je tu nějaký problém, který mám vyřešit, a na druhou stranu používám k tomu ten správný nástroj.

Člověk, který buduje datový tým, se musí uvědomit, co se po nás jako datovém oddělení vlastně chce. Jaké jsou očekávání a co máme řešit? A druhá otázka je, jestli jsme schopni to zvládnout s tím, co momentálně máme k dispozici. Odpověď může být ano, zvládáme to, nebo ne, nezvládáme to. Když to nezvládáme, buď nám chybí nějaké know-how, které potřebujeme doplnit. Například ve Fudoře v týmu chybělo know-how na tablo – nikdo ho neznal a nemohli jsme měnit veškeré prototypy z tablu, tak jsme to vyřešili tím, že jsme přibrali expertku na tablo. Nebo si někoho najmeme interně, nebo si necháme poradit od konzultanta.

Tak jsme se domluvili s nějakou konzultantkou – náhodou z Revolt BI, kde jsem předtím pracoval – aby nám udělala školení na tablo, protože jsem věděl, že kouči tam jsou dobří.

Máš nějaký speciální návod, jak zjistit, že problém, který jdeš řešit, je opravdu ten správný? Protože existuje spousta problémů, ale ne vždy jsou to ty správné, které by se měly řešit právě teď.

Typicky je důležité zjistit, kdo má ten problém – jestli to je finální uživatel reportu, třeba salesák, nebo jeho manažer – a trochu to podle toho rozlišit. Řešení, které pomůže salesákovi denně se rozhodnout, co má dělat a jaké priority nastavit, je úplně jiné než řešení, které chce manažer, aby viděl, jestli jeho tým obecně performuje, a případně kdo je lepší a kdo horší. Myslím, že je dobré si ověřit, že řešíš ten správný problém toho správného člověka, ideálně to všechno propojit.

Často se ve větších týmech stává, že vznikne situace, kterou je potřeba řešit, vznikne zadání, to zadání pak někdo upraví, a potom ho manažer předá finálnímu uživateli bez kontextu. To je velké riziko, že člověk stráví hodiny, dny nebo týdny řešením něčeho, co ve finále vůbec nevyřeší správný problém.

Pokud chceš, můžu ještě text trochu upravit, aby byl více formální nebo naopak více neformální. Dej vědět!

Jasně, tady je opravený text s lepší strukturou a interpunkcí:

Je ten problém, když je ten řetězec mezi těma dvěma takhle dlouhý. Ale zase vytváří jiný problém. Přesně tak. Jde o to propojit toho člověka, jehož problém se snažíme vyřešit, s tím člověkem, který bude řešení dělat. Ne vždycky to jde, ale minimálně by o sobě měli vědět a nějakým způsobem tam fungovat zpětnou vazbu. Místo toho, abychom půl roku tvořili něco a pak to najednou dodali, je lepší vytvářet řešení iterativně. Diskutovat: „Hej, jdeme správným směrem?“ A je jedno, jestli je to velký projekt v konzultační firmě, nebo malý reportík pro kolegu ve firmě. Vždy se mi vyplácí agilní přístup – vytvořit něco, ověřit si, jestli to řeší ten problém, anebo jestli jdeme špatnou cestou, a případně zkusit jiný směr.

Zkrátka je ideální zkracovat to zadávací kolečko, aby tam neprobíhala nějaká tichá pošta. A zároveň si uvědomit, že ten člověk často přesně neví, co chce. On ví, co ho štve a možná ho napadlo nějaké řešení, ale neví přesně, jestli chce report, tabulku, nebo něco jiného. On může třeba říct: „Nevím, do jaké restaurace mám dneska jet.“ A my mu můžeme dát seznam restaurací, nebo je tisíc způsobů, jak to udělat. Je potřeba vybrat ten, který dává smysl pro obě strany. Nebát se tomu, že i když třeba řekl, že chce toto, z toho kontextu, co k tomu získáme, mu může více pomoci něco jiného. Ukázat mu to a říct: „Hele, mám pocit, že by tě vlastně víc uspokojilo toto řešení.“ A on pak může říct: „Máš pravdu, díky, to je super.“ Ale k tomu musíš s tím člověkem mluvit a znát trochu kontext toho, co dělá. Propojovat domény, protože bez toho kontextu vytvoříš jen těžko perfektní řešení. To je ponaučení pro všechny.

Teď jsme mluvili hodně z vrchu, jak celý proces zaštitit, že je potřeba iterovat a zkracovat zadávací kolečko. Máš nějaké tipy pro lidi v datovém týmu? Pro ty dataře, kteří to vyrábí – ne pro manažery, ale pro dataře?

Myslím, že pro dataře jsou dvě hlavní rady. První je najít si to svoje. Něco jako svůj ikigai – tedy něco, v čem jsou dobří, co je baví, co je uživí a co v tom vidí smysl. Ať si najdou tu svoji oblast, ve které budou dobří, budou se v ní rádi zlepšovat a budou ochotní například o dvě hodiny déle zůstat v práci, nebo si o víkendu pustit podcast, protože je téma zajímá. Najít si to téma, které je baví a není pro ně otrava. A je jedno, jestli jde o psaní kódu, tvorbu vizualizací, nebo cokoliv jiného.

Pokud chceš, můžu pokračovat a dokončit poslední část věty. Stačí říct.

Zde je opravený text:

Je důležité být ochotný se pořád zlepšovat, protože přichází doba, kdy bude stále lehčí a lehčí být v něčem průměrný. AI totiž dokáže nahradit průměrného dataře nebo průměrného analytika mnohem snáz než někoho, kdo je opravdu pokročilý. Proto je důležité dostat se do hloubky něčeho, věnovat se tomu dlouhodobě a zajímat se o to. Jak říkám, není to o tom, že by to někomu mělo být otrava – zlepšování by mělo být přirozenou součástí.

Takže jedna rada je: jděte do něčeho do hloubky. Ideálně vedle někoho zkušenějšího, hlavně na začátku, od koho se můžete učit. Protože ten přístup „hodit někoho do vody a nauč se plavat“ asi není ten nejefektivnější a mně se nikdy neosvědčil. Vždycky je lepší mít někoho, kdo vám například doporučí určitý přístup, ale zároveň tam mít i tu zdravou výzvu/challenge – tedy když už jsem na nějaké úrovni, dokážu pochybovat o tom, co mě ten člověk naučil, a říct si, že jiné řešení může být lepší. Ale k tomu je potřeba čas, musíte si projít několika problémy a zkušenostmi, než vás napadne, že to jde dělat i jinak.

Samozřejmě, minimálně je rychlejší, když máte někoho, kdo vám poradí, než když se tím trápíte sami.

Souhlasím s tebou i v tom, že datař by měl mít nějakou specializaci, ve které je opravdu dobrý. Co se týče T-shaped datařů, kteří mají přehled a ví, co a jak kde funguje, tak pro ně, například u vás v týmu, nemusí být tak velké uplatnění.

Ale to byla vlastně ta druhá rada, kterou jsem chtěl říct: vedle toho, čemu se zaměřujete do hloubky, je důležité mít i přehled o tom, co se děje okolo. I když vás třeba technická část úplně nezajímá, bylo by dobré tušit, co je ETL, jak data vlastně do databáze přicházejí, nebo jak funguje váš business model a co vede k tomu, že firma vydělává peníze. Nemusíte tomu rozumět do detailu, ale je dobré mít u sebe lidi, kteří vám o tom něco řeknou a mít alespoň základní přehled. Díky tomu pak můžete například zastoupit kolegu, který běžně řeší danou věc a teď není přítomen.

Občas mu kouknout pod ruce, sledovat, jak řeší problémy – třeba já jsem expert na Tableau a někdo jiný na Looker – tak se na to dívám, protože se mi to může hodit. Tím si pořád rozšiřuju obzory, co všechno je možné. Může se stát, že to neudělám úplně nejlíp, ale alespoň si udržuji know-how – vím o tom, že se to dělá, že jsou to problémy, které někdo musí řešit, a kdyby to spadlo na mě, alespoň přibližně vím, kde začít, koho se zeptat a kde získávat informace.

A myslím si, že právě kombinace hluboké specializace a širšího přehledu tvoří dobrého dataře. Mít svoji jistotu a oblast, ve které excelujeme, ale zároveň být schopný orientovat se i v dalších oblastech.

Pokud chceš, mohu ti text také víc odlehčit, upravit na formálnější styl nebo naopak na neformální. Stačí říct!

Zde je opravený text:

Potřebuji něco rychle vyřešit a není čas týden hledat nové řešení nebo se něco učit, takže dokážu svoje každodenní úkoly odbavit dobře a jsem si tím jistý.

Stále si udržuji přehled o tom, co se děje kolem mě, a snažím se nebýt jenom ve své vlastní ulitě, nemít tunelové vidění, ale prostě vědět, co se kolem děje. Svět se rychle mění a je dobré tušit, co se kolem nás děje, protože to může velmi brzo ovlivnit i mou „ulitku“ a můj tunel. Třeba zjistím, že si najdu jiný tunel nebo jiný nástroj, který je lepší na řešení problémů, se kterými se běžně setkávám.

Když mluvíme o tunelu, a kdyby si teď někdo chtěl vybrat svůj „tunílek“, do kterého se pustí a který ho nejvíc vystihuje, co je za tu dobu, co se točí okolo dat, nějaká specializace nebo oblast, která se často opakuje a která chybí nebo je nejvíc oceňovaná? Myslím, že je dobré si uvědomit celý ten tunel od dat – neříkám úplný nejtunel, ale tunel začíná u dat, která vznikají a tečou do databáze. Odtud se třeba v datamartu sestaví nějaký BI s grafy, které někdo sleduje, aby dělal rozhodnutí nebo složitější analýzy. Okolo toho může být nějaké machine learningové řešení nebo umělá inteligence.

Je tedy dobré jít po cestě, co se s daty děje. Uvědomovat si celou cestu, jednotlivé touchpointy. Když si třeba vyberu jednu oblast, třeba placení nebo machine learning, tak si mám jít na obě strany tunelu – tedy jak získat ta data, jak z datového warehouse sestavit svůj datamart pro model, a na druhé straně, jak z machine learningového řešení vyvodit dílčí byznysové závěry, které opravdu pomohou, aby řešení mělo účinek. Protože může být model hezký a přesný, ale když nikdo neví, co dělá, není to moc užitečné.

Tedy je důležité si uvědomit celý ten data funnel, kde je moje místo v něm a jaké jsou koncové body na obou stranách. Tím člověk může lépe řešit své problémy, když zná „konektory“ na další problémy.

Co se týče AI a jejího využití, ovlivňuje nějakým způsobem vaši každodenní práci v datovém týmu? Myslím, že existují problémy, kde AI hodně pomáhá, a jiné, které bychom rádi, aby AI vyřešila, ale zatím nedokáže.

Tam, kde nám AI pomáhá, jsou běžné činnosti – například nechat si vygenerovat kus kódu, což AI umí už velmi dobře, nebo vytáhnout nějaké textové insighty z odpovědí respondentů a podobně. Tam to jde velmi dobře…

Pokud chceš, mohu ti ještě s textem dále pomoci, například s dalším jeho dokončením nebo stylistikou.

Tady je opravený text s lepší srozumitelností a jasností, přičemž jsem zachoval co nejvíce původní význam a myšlenky:

Třeba v oblasti BI se občas objeví požadavek, například: „Chtěli bychom nástroj, který by se provrtal všemi dashboardy, co máme, a řekl nám, které jsou deset nejdůležitějších věcí, které je potřeba řešit.“ Myslím, že využití AI tady pořád nějakým způsobem máme a ještě nějakou dobu mít budeme. Není lepší mít data používaná pro reporty v nějakém datovém modelu, ze kterého se potom bude jednodušší čerpat, než používat logiku, podle které jsou data poskládaná v Tableau?

Na jednu stranu to fungovat může, ale na druhou stranu si myslím, že je důležité uvědomit si, kde je lepší nechat přemýšlet lidi a kde stroje. Pořád si myslím, že i ve firmách, které jsou hodně data-driven, je větší přidaná hodnota v tom, když lidé dostanou správná data, na kterých mohou přemýšlet, než ve snaze úplně je nahradit a svěřit strojům úkoly, v nichž je člověk pořád lepší.

Jo, to chápu. Měla jsem spíš na mysli to, že by lidem mohl AI nástroj ušetřit čas tím, že nemusí procházet třeba pět různých reportů, ale rovnou uvidí nějaké shrnutí – například: „Tady jsou nejdůležitější změny, zaměřte se na tohle.“

Určitě, tohle je jedna z věcí, kterou jsme se snažili řešit i na začátku migrace, kdy jsme dělali revizi současných řešení. Zkoumali jsme, zda stále používáme nástroje, které byly navržené dříve, protože spousta z nich byla postupem času nahrazena lepšími, nebo už řeší problémy jinak. Například některé metriky, které byly dřív důležité, už nejsou tak relevantní. Je proto dobré průběžně dělat sanity check – tedy kontrolu, jestli nástroje stále pomáhají řešit naše problémy, nebo jestli už plní svůj účel nedostatečně a uživatelé jsou z nich zmatení a raději by něco přehlednějšího a jednoduššího.

Je to tedy nekonečný proces, který je třeba dělat neustále, protože s každým novým řešením vzniká určitá změna ve světě uživatelů – přidáváme něco nového. A uživatelé mají pořád omezený čas – třeba 8 hodin denně, který mohou věnovat práci. Je proto důležité myslet na to, že i když něco vytvoříme, občas je dobré něco odebrat nebo přemýšlet, kde uživatel vezme čas to vše zpracovat, a nesnažit se ho každou chvíli zahlcovat dalšími informacemi.

To je asi hezký přístup. Máte teď nějaké konkrétní věci nebo projekty, do kterých plánujete v blízké budoucnosti nasadit více AI řešení?

Určitě, jedna z věcí, které nás čeká, je harmonizace, která povede k tomu, aby si každý te…

Pokud chcete, mohu vám pomoci také s pokračováním a doladěním konce textu.

Tady je opravený text:

Náš tým se zaměřil na určitou oblast, což znamená, že budete i tým, který bude řešit logistiku, tým, který bude řešit marketing, a tak dále. To pak vede k tomu, že když se tým specializuje, rychleji odladí základy, rychleji dokáže dělat základní analytická řešení a pak je schopný zvládat i pokročilou analytiku. Protože vlastně náš cíl není používat AI, ale řešit problémy lidí. Když k nám přijde nějaký problém, tak některý vyřešíme jednoduchou funkcí v Excelu, některý problém vyřešíme lineární regresí nebo grafem a na některé problémy už potřebujeme pomalu vlastní neuronovou síť nebo něco takového. Ale je potřeba si uvědomit, v jaké fázi problému se nacházíme a jaký problém řešíme, než si prostě řekneme, že za každou cenu teď použijeme AI, protože to dělají všichni a myslíme si, že to bude cool.

No jasně. A je tady něco, na co se ve Foodoře opravdu těšíte příští rok, nebo jaké hlavní výzvy vás čekají?

Jak jsem říkal, jedna z věcí, co teď probíhá, je specializace jednotlivých týmů. To znamená, že i náš tým si najde oblast, na kterou budeme experty a z níž se budou učit i ostatní země. Některé oblasti se už teď rýsují, ve kterých jsme fakt dobří. A to si myslím, že je něco, za co celý tým zaslouží velkou pochvalu a rád bych je tady pochválil. Dokázali jsme během jednoho roku vybudovat řešení, která jinde nestihli za dlouhá léta. A samozřejmě k tomu přispěly i datové základy, které už byly předtím, ale hlavně to je proto, že na tom fakt spousta lidí makala. Díky tomu, co teď děláme, je úroveň taková, že se tím inspirují i lidé v Singapuru, Kuala Lumpur nebo Istanbulu, kteří si říkají: „Hele, v Praze to dělají nejlíp.“

To je super, to musí být pro tým skvělá motivace, když opravdu přijedou lidi ze Singapuru nebo z Kuala a koukají na naše reporty.

Těšíme se na to!

No tak super. A je tady ještě něco, co bys rád řekl našim posluchačům?

Jo, svět dat se hodně mění. Nikdo moc neví, co přinesou nové AI nástroje, jak moc nahradí nebo nenahradí běžné analytiky. Ale myslím si, že naše super vlastnost je to, že to není poprvé, co se objevují nové věci. Vždycky jsme zvyklí učit se něco nového. Je dobré si tohle udržet – zvědavost a zároveň si ověřit, že jsem v prostředí, které mi to umožňuje. Že jsem v prostředí, které mě posouvá, mám kolem sebe lidi, kteří mě rozvíjejí, nebo které já rozvíjím. To si myslím, že je hlavní věc, kterou by si lidé měli udržet nejen v nejbližších letech, ale i během dekád, protože náš svět se bude měnit.

Pokud chceš, můžu text ještě více upravit nebo zestručnit.

Opravený text:

Je potřeba, abychom se, pokud se k těm změnám chceme přizpůsobit, cítili příjemně. Nemá smysl pracovat způsobem, který mě štve. Nejlepší je mít takové pracovní prostředí, kde se pracuje fajn a jsou kolem mě lidé, kteří mě posouvají dál způsoby, které mi vyhovují a jsou příjemné. Jasně, máme to dělat, protože chceme.

Jsem ráda, že jsi něco takového ve Foodoře našel, a držím palce s vašimi dalšími plány, ať ukážete všem, že Praha je ta hlavní reportovací velmoc. Děkuji moc za rozhovor.

Také děkuji. Děkujeme, že jste doposlouchali až sem, a díky také našim partnerům – členům Data Talk klubu. Jsou jimi: Inpex, Saska, Bistreet, Colors of Data, Revolt BI, Good Data, Keboola, Emark, Carl, Data Company, Data Mind, Notino a Flo.

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.