Podcast

Dobrý den, moje jméno je Jirka Vešerek.

Dobrý den všem, moje jméno je Hinek Wellner. Vítáme vás u dalšího dílu DataTalku. Je to tak, dneska naše pozvání přijel Ondra Hubálek ze všem asi známé firmy Rohlik.cz.

Ahoj, Ondro.

Ahoj, díky za pozvání. My jsme, Ondro, hrozně rádi, že tě tady máme. Samozřejmě Rohlik patří nejen na českém trhu mezi takové etalony data-driven přístupu a dneska si právě budeme povídat o tom, jak se vlastně v Rohlíku pracuje s daty.

První bychom byli ale hrozně rádi, kdybys ty představil sebe, co tě do Rohlíku dostalo, dovedlo a co jsi zažil před Rohlíkem.

OK, tak já jsem vlastně první setkání s daty měl možná ještě na střední škole. Bylo to zajímavé, protože jsme tehdy měli nějaký předmět o Microsoft Excelu a já jsem vůbec nechápal, o co jde. Řešily se tam databáze SQL a já jsem vůbec nevěděl, o co jde. Takže za mě vlastně kamarádova sestra dělala nějakou seminární práci, abych ten předmět vůbec dodělal, protože naše paní profesorka nebyla úplně silná v předávání těchto znalostí.

Takže jsem tehdy vůbec nějakým způsobem potkal data, databáze, ale vlastně jsem ani nevěděl, že bych s těmi daty mohl něco dělat profesionálně. Do dat mě tedy dostala kamarádova sestra ke spolužákovi?

No vlastně ani ne, protože za mě dělala tu seminární práci ona, já vůbec nechápal, o co jde. A v podstatě až když jsem se rozhodoval, kam půjdu na vysokou školu, vybral jsem si VŠE, obor statistika a ekonometrii. Tam jsem se k tomu nějakým způsobem víc přičichnul a už mi to začalo dávat větší smysl.

A jaká byla tvoje první datová štace?

Byla to společnost Fincentrum, která už dnes neexistuje, přejmenovala se na Swiss Life Select, je to něco jako partner z finančního poradenství. Já jsem tam tehdy byl na pozici, která se jmenovala obchodní analytik – v podstatě to, čemu se dnes říká datový analytik. Znamenalo to nějakou práci s daty, vytahování reportů a tak dále. Tehdy jsme začínali v Excelu, všechno se dělalo v Excelu a mně to po čase přišlo dost zvláštní, tak jsem řekl, pojďme se podívat, jestli by to nešlo do nějaké databáze.

Šel jsem tehdy s mým šéfem na SQL kurz na VŠE, který jsem asi ani nemusel absolvovat, stačilo by si něco najít online. Pak jsme se domluvili s někým z IT, aby nám dal přístup do databáze, a začali jsme reporty dělat přímo nad databází. V tu chvíli jsem začal chápat, že SQL a tyhle věci mě baví, docela mi to šlo, a zároveň že bez toho dělat analytiku moc nejde.

A co to bylo za rok a jaká to byla databáze?

To bylo v roce 2013 až 2014 a firma fungovala na Microsoft SQL Serveru, takže tam jsem začínal. Posléze k tomu přibyla Keboola a tam jsem se potkal s Redshiftem, Snowflakem a v průběhu další kariéry jsem si k těm databázím přičuchnul víc a víc.

Co tě lákalo před Rohlíkem?

Rozhodoval jsem se, kam půjdu dál, a chtěl jsem zkusit e-commerce obecně, protože jsem tušil, že tam budou dobrá data a hodně práce s daty. Rozhodoval jsem se mezi Rohlíkem a ještě jednou nejmenovanou e-commerce firmou a nakonec pro Rohlík rozhodlo to, že mi tam lidi přišli sympatičtější. Nebyla to tedy nějaká datově orientovaná volba, prostě mi tam lidi sedli.

Já jsem už tehdy byl zákazník Rohlíku a líbilo se mi, co dělají – člověk nemusí chodit na nákup, což je super. Takže jsem se rozhodl, že to zkusím, vzali mě a jsem tam dodnes.

Během své kariéry v Rohlíku jsi ale prošel několika pozicemi, cesta nebyla úplně lineární, že jsi zatím všechno viděl – co všechno jsi viděl?

Když jsem začínal, v týmu nás bylo asi čtyři nebo pět lidí. Tým byl relativně malý. Přitom jsem přišel s nějakou zkušeností s machine learningem z O2, ale reálně jsem dělal skoro všechno – data engineering, machine learning, klasický reporting, BI.

Jak se firma rozrůstala, což hodně nakopnul COVID a zahraniční expanze, tým se zvětšoval. V určitý chvíli přišlo rozhodnutí, že budeme mít dedikovaný machine learningový tým s třemi, čtyřmi, pěti lidmi. Já jsem tehdy byl jeden ze dvou lidí, kteří se machine learningu věnovali, tak jsem se stal team leaderem.

Až do letošního roku jsem tým vedl, potom jsem se rozhodl přesunout na pozici lead engineera.

Proč jsi se rozhodl?

Těch důvodů bylo víc. Jedním bylo, že mi úplně nevyhovovalo, jak to bylo nastavené pro mě jako team leadera, jak funguje Rohlík, což je agilní způsob řízení. Ten agilní model Rohlíku mu velmi pomáhá a dává smysl, ale mně osobně nevyhovovalo mít své lidi dedikované v týmech s vlastními product ownery, kteří se o ně starají, zatímco já je nemohu efektivně řídit.

Také jsem většinu času – asi 80 % – trávil jako data inženýr, což pro mě dávalo smysl. S pozicí team leadera přišla prestiž a peníze, ale také potřeba řešit HR záležitosti, které mě upřímně nebavily. Připadalo mi to neefektivní a zabralo to čas, takže jsem si řekl, že bude lepší se toho zbavit a věnovat se čistě technickým věcem.

Já to naopak vítám. Myslím, že každý má hledat své štěstí. To, co je pro někoho zázrakem, může být pro jiného prokletím. Jsem rád, že tu mluvíme otevřeně, že ne všechno je růžové a ne každý graf dělá růstovou křivku.

Jsem hlavně rád, že oficiálně zazní, že cesta na manažerskou pozici není jedinou cestou růstu ve firmě. V IT světě už je běžné, že existují specializované seniorní pozice a růst lze i v jedné doméně.

Nevím, jestli je to tak běžné v datech obecně, ale v Rohlíku je tým relativně velký a pokud někdo něčemu rozumí a je přínosný, může být užitečnější, když řeší technické věci, než když tráví čas na mítincích a řeší vedení týmu.

Myslím, že pokud firmě přijde normální to pochopit, což si u Rohlíku myslím, že ano, není to žádný problém. A pokud to někomu vyhovuje, proč ne.

Je to fakt super. Pamatuji si rčení, že když povýšíš nejlepšího vývojáře na manažera, ztratíš nejlepšího vývojáře a dostaneš podprůměrného manažera. To je takové klišé.

Co je ale určitě skvělé, je to, že jsi poznal data v Rohlíku z několika rolí a z pohledu času. A právě o tom si dnes chceme povídat.

Když mluvíme o datech v Rohlíku a o data-driven přístupu, co je podle tebe určující, proč Rohlík tak šlape do dat? Proč si myslíš, že je to tak zajímavá firma? Jak to nějak kategorizovat?

Myslím, že hlavní roli hraje Tomáš Čupr jako CEO, který data-driven přístup zažil už ve Slevomatu nebo Dáme jídlo. Když rozjížděl Rohlík, věděl, že chce měřit věci, reportovat a mít data pod kontrolou.

Ten data-driven přístup jde prostě z Tomáše a dobře se promítá do celé firmy. To je hlavní důvod, proč Rohlík tak funguje – nejen v datech, ale i v dalších oblastech.

Když si představíme Rohlík z pohledu dat, jaké domény řešíte a co máte na starosti?

Myslím, že není přehnané tvrdit, že většina posluchačů zná Rohlík a mnoho z nich jsou uživatelé. Co to ale znamená pro tebe, člověka zodpovědného za data? Jaké úkoly vlastně řešíš?

Obecně je to tak, že Rohlík je ve skutečnosti asi pět nebo šest firem dohromady, protože se snaží řešit co nejvíce věcí interně. To znamená, že celý proces, jak ho vidí zákazník – od nákupu na webu nebo v aplikaci, přes přípravu objednávky ve skladu, až po doručení kurýrem – probíhá uvnitř firmy.

Všechny tyto procesy musí být podpořeny daty, tedy my musíme tato data zpracovávat a použít k podpoře businessu, aby mohl fungovat a lépe se rozvíjet.

Jak vypadá tým, kde sedíte a jak si rozdělíte domény?

Tým je centralizovaný a Rohlík funguje ve pěti zemích. Do nedávna jsme měli dedikované analytiky v každé zemi, kteří podporovali lokální business. Dnes už jsou všichni centralizovaní a podporují lokální týmy spíše na bázi ad hoc.

V týmu je nás asi 25–30 lidí, rozdělení do tří skupin: machine learning team, který se věnuje strojovému učení a AI; data engineering team, který se stará o backend a přípravu dat; a největší skupina jsou analytici, klasické BI analytiky, kteří se věnují reportingu a insightům.

Analytici jsou ještě rozděleni na dvě menší skupiny: jedna podporuje země v denním businessu a druhá se věnuje více interním projektům.

Zkušenosti jednotlivých zemí se různě liší. Česká republika jako nejstarší trh má hodně zkušeností a ví, jak věci dělat. Mezinárodní pobočky – Rumunsko, Německo, Rakousko – fungují kratší dobu a jsou na jiné úrovni zralosti, většinou řeší jiné otázky než český trh.

Jste součástí IT oddělení, nebo jak jste organizačně začleněni v Rohlíku?

Data-driven firmy obvykle mají data velmi centrálně.

Ještě nedávno jsme byli přímo pod Tomášem Čuprem, teď jsme organizačně pod IT. Šéf IT Ondra Klamp je zároveň naším interim BI manažerem, protože momentálně nemáme dedikovaného manažera BI.

Organizačně jsme tedy přímo pod Ondrou Klampem a tým je seniorní, takže nemáme jednoho dedikovaného lídra BI. Leadership je rozdělen mezi tým.

Šéf IT spíš tlačí projekty a pomáhá nám dosáhnout toho, co plánujeme. My nejsme projektoví manažeři, potřebujeme někoho, kdo nás tlačí, aby se věci dodaly. Víme, co dělat, ale potřebujeme podporu v realizaci.

Ondro, co máte teď konkrétně na stole za projekty? Na čem jsi dnes pracoval, než jsi přišel na natáčení, z pohledu data engineeringu, machine learningu, reportingu?

Poslední věcí, na které jsem dnes pracoval, je část supply chainu, kde my jako data tým a machine learningový tým dodáváme forecasty a odhady poptávky po produktech.

Rohlík má na skladech zhruba 20 000 produktů a potřebujeme pro každý z nich nějaký odhad, kolik si zákazníci koupí. To je důležité proto, abychom věděli, kolik objednat, aby byl produkt dostupný na webu a mohl si ho zákazník objednat.

To je zásadní úloha, protože na jedné straně chceme mít zboží skladem, aby zákazník neodcházel s prázdnou, na druhé straně nechceme objednávat moc, aby se zboží nezkazilo a nebylo třeba ho vyhazovat.

To je velká výzva.

To mi připadá hodně složité. Já si to úplně laicky představuji – jídlo si objednávám docela často, takže dat tam asi bude hodně. Navíc je potřeba počítat s tím, že se zboží kazí, takže je potřeba optimalizovat na obě věci.

Ano, přesně. Výzvou je hlavně fresh zboží, které se kazí rychle, a proto je potřeba s ním pracovat „just in time“, aby bylo čerstvé, ale zároveň dostupné. To je ta složitá část.

U trvanlivých produktů je situace jednodušší, tam můžeme objednávat větší skladové zásoby.

Text je nyní přepsán do spisovné češtiny, s opravou gramatiky, diakritiky a rozdělením do odstavců, zároveň byl zachován kompletní obsah a význam původního textu.

Nemusíme řešit úplně každý detail, například zda jsme náhodou neobjednali o deset procent více, protože jednoduše víme, že nám to vydrží, a příště to už neobjednáme znovu. To, co je ale čerstvé – to znamená ovoce, zelenina, maso, pečivo – to je samozřejmě trochu problém, protože přesně odhadnout, kolik si zákazníci objednají, je obtížné.

Současně nechceme, aby zákazníci měli zboží nedostupné. Naším ideálem je, aby zákazník po příchodu na web nebo do aplikace viděl vždy skutečnou dostupnost výrobku, který chce objednat. K tomu máme velmi dobrý a přesný reporting, díky kterému víme, kolik procent času jsme dostupní a kolik procent času jsme nedostupní. Snažíme se tedy dostupnost maximalizovat a zároveň minimalizovat „shrink“, tj. množství vyhozeného zboží. To je samozřejmě problém, protože odhadnout, kolik lidí si zítra objedná například koblihu, je velmi těžké – může to být 300, může to být 350. Pokud řekneme 325, ale skutečnost je 350, pak 25 lidí si objednat nemůže, anebo pokud vyrobíme 350 a objedná si jen 300, musí se zbývajících 50 koblih vyhodit. Tento problém je komplikovaný, ale myslím, že se nám ho daří poměrně dobře manažovat. Samozřejmě zde je velký prostor pro procesní zlepšování a co nejvíce snižování plýtvání. Predikce poptávky je jedna ze základních věcí, která má na celou problematiku velký vliv a neustále ji zdokonalujeme a přizpůsobujeme.

Co se týče skladu a logistiky, vnímám Rohlík jako velkého inovátora právě v oblasti nasazování vlastních technologií. Měli jste vlastní datové zdroje, obrovské investice, které tradiční hráči často nechtějí podstoupit. Myslel jsem si, že sklad a picking jsou dnes již spíše komoditizované a technicky vyřešené. Je tedy skutečně největší přidanou hodnotou právě předpověď poptávky? Nebo jak bys uspořádal priority jednotlivých domén? Nebo se to v čase mění podle aktuálních problémů?

Z pohledu našeho zaměření se určitě průběžně mění, protože například v Česku máme jeden automatizovaný sklad, který má velmi dobrou efektivitu a dá se říci, že je do určité míry vyřešený. Díky automatizaci tam není třeba tolik zasahovat. Určitý prostor pro zlepšení existuje, ale otázkou je, kolik investice a práce by to přineslo reálné hodnoty.

Na druhé straně tam máme sklady, které jsou stále spíše řízeny lidmi, kde lidé vykonávají picking a balení. Tam je pořád prostor pro zlepšování procesů. Mnoho lidí možná kritizovalo Rohlík za to, že posíláte mnoho tašek – například relativně běžný nákup dorazil v deseti taškách, i když by mohl být zabalen v pěti. To byl skutečně problém, kterým jsme se zabývali. Na jedné straně řešíme počet tašek, na druhé straně, jak rychle a efektivně dokážeme to zboží zabalit. Protože je to neustálý prostor pro inovace a zlepšování procesů, aby to dávalo smysl.

Ondro, takže to nebyli vy, kdo problém „tašek“ vlastně vytvořil tím, že jste zavedli velmi rychlý picking? Předpokládám, že sbalit zboží do deseti tašek je levnější a rychlejší než balení všech produktů do jedné tašky. Pak jste problém znovu řešili? Přemýšlím správně?

Ano, efektivita v skladu je klíčová – kolik položek zvládne jeden pracovník vypikovat za hodinu, to je zásadní i z hlediska ziskovosti. Snažíme se efektivitu neustále zvyšovat, ale pak se objevují sekundární negativní dopady, jako právě ta velká spotřeba tašek.

Takže se dá říct, že jsme si ten problém možná sami vytvořili, ale zároveň v naší firmě máme mindset neustále posouvat věci k lepšímu pro zákazníky. Tedy ano, problém jsme vytvořili, a pak jsme ho zase chtěli řešit.

Mluvili jsme tedy o predikci poptávky, pak jsme zmínili sklad a picking. Vy máte i další domény. Co třeba řešíte na webu, v produktu nebo v dalších oblastech? Jaké další projekty tam najdeme?

Co by posluchači mohli znát, je téma pricingu – nastavování cen. I zde máme poměrně silné datové zázemí. Například během inflace, kdy to bylo velmi aktuální, jsme se zabývali i tématem „shrinku“ – jak zabránit tomu, abychom vyhazovali čerstvé zboží. Na Rohlíku je oblíbená sekce „zachraň jídlo“, která se možná už přejmenovala, ale v podstatě jde o místo, kde si zákazník může koupit zboží, které má krátkou dobu do uplynutí minimální trvanlivosti, přesto je stále nezávadné. Potřebujeme se těch položek zbavit, abychom předešli vyhazování.

Jednou z prvních úloh, kterou jsme řešili i v reálném čase, bylo tedy nastavení ceny takového zboží, aby se dokázalo prodat. Máme například deset chlebů na skladě, které musíme prodat do večera. Jakou cenu tedy nastavíme, abychom těch deset chlebů prodali, ale aby nebyla sleva příliš vysoká? Abychom maximalizovali zisk, respektive minimalizovali ztrátu, protože často při slevách zisková marže klesá pod nulu?

Toto řešíme algoritmicky pomocí machine learningu, který běží na AVS (Amazon Vertex Service). Máme tam modely, které počítají vhodnou cenu a endpoint, který náš backend volá a posílá data o produktu, skladových zásobách apod., a dostává zpět návrh ceny, kterou pak zobrazujeme zákazníkům na webu.

Jak často se toto přepočítává? Je to nějaký časový průběh – například když máme 200 jogurtů, které propadají za pět dní, nasadí se malá sleva, a když je jich už jen 50 s expirací za dva dny, sleva se zvýší?

Detail algoritmu bohužel nemůžu zveřejnit, protože by mohl být zneužit, ale obecně se začíná s určitou slevou a pak se postupně upravuje podle aktuálního odbytu.

Je model vlastní výroby, nebo se jedná o nějaké krabičkové řešení, které jste jen připojili do AVS?

Model jsme psali sami, není generický – nemyslím si, že by fungoval v jiné firmě. Je tedy na míru šitý přímo pro Rohlík a dané use case. Běží jako docker image na AVSu, jednoduchý, stabilní a už více než půl roku pilně vylepšovaný na základě zkušeností.

Můžete obecněji ještě říci, jak u vás probíhá validace a rollout ML modelů? Představuji si, že byste dělali A/B testování na části zákazníků, abyste ověřili efektivitu řešení, zatímco by business běžel dál. Jak to funguje u vás?

To záleží na úloze. Některé věci, například pricing, se A/B testovat příliš nedají, takže rovnou nasazujeme na všechny zákazníky a pokud vznikne nějaký problém, musíme ho rychle řešit. V minulosti jsme měli několik problémů, například chybějící záznamy v databázi, což vedlo k nastavení 80% slevy na všechny produkty, prodané za 5 Kč. Zajímavé bylo, že se to dlouho nevšimlo, což nám ukázalo potřebu lepšího monitoringu.

Od té doby tedy rozvinuli monitoring a nasazovací procesy, abychom byli schopni podobné chyby rychle odhalit a případně vypnout model.

U jiných oblastí, například supply chainu, začínáme s určitým segmentem produktového portfolia a po otestování nasazujeme dále. A personalizace zobrazení na webu probíhá obvykle prostřednictvím A/B testů, které jasně ukazují, zda nové řešení funguje lépe či hůře.

Když se bavíme o machine learningu v Rohlik.cz, ale zároveň i o data engineeringu, kdo u vás zodpovídá za udržování chodu systémů? Kdo má na starost, aby nic nepadalo a fungovalo to?

Obvykle je hlavní zodpovědný datový vědec nebo machine learning inženýr, tedy ten, kdo model vytváří, ten by měl mít správu pod kontrolou. Já, jakožto člen data engineering týmu a někdejší člen ML týmu, vím o řešeních hodně, a v případě problémů mohu pomoci.

Obecně to u nás stojí na individuální zodpovědnosti každého člena týmu, který si end-to-end projekt vyvíjí, nasazuje a udržuje. Klíčový je monitoring, který dříve nebyl ideální, a proto se někdy stávaly chyby.

Dnes při nasazování nových modelů klademe důraz na sledování jejich provozu a schopnost rychlého zásahu – vypnutí modelu, pokud by došlo k problémům.

Většina našich řešení však není kritická pro chod firmy – když nějaký endpoint dočasně vypneme, firma funguje dál a zákazníci si mohou objednat bez omezení. To nám dává určitou volnost.

Co by se stalo, kdybychom vypnuli model pro „zachraň jídlo“? Co by se pak zobrazovalo na webu?

Náš web by zákazníkům ukázal téměř totéž, možná s trochu odlišnými cenami v sekci „zachraň jídlo“. Zákazník by s vysokou pravděpodobností rozdíl ani nepostřehl, my bychom změny viděli v datech o prodejích.

Máme tam také „fallback“ varianty, pokud by model přestal fungovat, což je jednoduchá obchodní logika založená například na pravidlech „if-else“, která se historicky používala a stále je k dispozici jako poslední záložní řešení.

A co je tedy ta jedna věc, kterou vypnout nejde?

Máme plánování logistiky, konkrétně optimalizaci trasy kurýra. Jak roste firma a počet skladů, úloha plánování se částečně zjednodušuje, protože více objednávek znamená větší výběr zákazníků, které lze lépe uspořádat.

Hlavním omezením v tomto algoritmu je kapacita auta, protože většina lidí zná, že auto není nafukovací – má pevné omezené místo. Proto dimenzujeme, kolik objednávek lze do auta naložit, aby bylo možné v rozumném čase všechny zákazníky navštívit.

Je pro nás důležité dobře naplánovat kapacitu auta a máme systém, který již v momentě vytvoření nákupu odhaduje, kolik tašek bude potřeba. Víme, že auto pojme například maximálně 20 tašek a podle toho se plánuje objížděcí trasa.

Snažíme se, aby v autě bylo maximálně těch 20 tašek, i kdyby bylo 30 nákupů, protože přetížení vede k poškození zboží a zhoršuje kvalitu služby. Naopak chceme kapacitu auta maximálně využít, protože v tom je velký potenciál úspor.

Když jsme toto řešení zavedli poprvé, zvedli jsme kapacitu auta a…

Auta, respektive nějaké průměrné rozvezení nákupů na jedno auto, se zlepšila asi o 20 %, což je v logistice relativně hodně. Tam se totiž při zlepšování často počítá doslova po procentech, takže udělat 20 % zlepšení zní opravdu dobře.

Zároveň však toto řešení, pokud přestane fungovat, nebo funguje špatně, může způsobit nepříjemnosti. Nám se stalo asi dvakrát, že jsme najednou posílali špatná čísla o kapacitě auta, a tím pádem jsme začali tvořit mnohem menší trasy.

Což znamená, že místo aby auto odvezlo 15 objednávek, vezlo jich v průměru třeba jen 10, což je opět extrémně velký rozdíl. Takže jsme měli chybu v datech, kdy endpoint vracel špatná čísla, a díky tomu jsme měli zhruba den a půl sníženou kapacitu.

Zpátky k datovému inženýrství. Nyní jsme se dívali na některé úlohy a projekty týmu strojového učení. Když bych se podíval na tvé úlohy a projekty, co máte nyní na roadmapě?

My teď řešíme asi nejzásadnější věc – migraci jednoho našeho reportovacího nástroje. Pro reporting používáme Tableau, což je běžný reportingový nástroj, kde běžným uživatelům z marketingu či komerčního oddělení ukazujeme data většinou z předchozího dne či dnů.

Pak máme druhou část, která úzce souvisí se skladem a logistikou. Potřebujeme totiž i v reálném čase reportovat dění ve skladu a logistice. Proto používáme jeden nástroj, který nám v tuto chvíli ale už nevyhovuje, hlavně kvůli špatné údržbě. Nejsme schopni například hromadně provádět úpravy, protože nástroj nemá žádnou API, přes kterou by se s ním dalo pěkně pracovat.

Takže se snažíme přesunout do jiného nástroje, a to je Metabase. Budeme tam migrovat report pro sklad a logistiku, ideálně tak, aby uživatelé nepoznali rozdíl v tom, co jim nabízíme v reportech. Pro nás by to mělo být mnohem jednodušší na údržbu, správu, a zároveň to potenciálně otevře nové možnosti práce s reporty.

Jak složitá je pro vás tato migrace? Je to v podstatě pouze o tom, že máme data vyřešená a jen je přehodíme jinam, nebo musíte něco řešit, například změnu datových modelů či sběru dat?

Na začátku jsme si mysleli, že to bude relativně jednoduché – vezmeme SQL dotazy, co máme, a jen je přehodíme. Postupem času jsme ale zjistili, že tak snadné to nebude. Jsou tam specifika, která jak reportingový nástroj, tak sklad vyžadují.

Čeká nás hodně komunikace s lidmi z logistiky a skladu, abychom s nimi dobře odladili, jak budou reporty vypadat, co jim budeme měnit, aby to nevadilo, ale možná budeme chtít, aby něco technicky upravili. Na skladu je spousta televizí, na kterých promítají různé reporty. My tedy musíme zajistit, aby televize začaly promítat nové reporty, a zajistit správný chod celé věci s minimálním dopadem na uživatele.

Takže vy v datovém inženýrství řešíte i posílání dat do těch televizí?

To ne zcela. To ještě budeme upřesňovat, jak to přesně funguje. Možná tam i nalezneme prostor pro zlepšení nebo objevíme jiný způsob, jak to dělat. Naskočili jsme do migrace a teď postupně objevujeme, co všechno to obnáší. Budeme tedy pořizovat potřebné věci, ale věřím, že to nebude problém.

Ondro, zmínil jsi Metabase, ale co další technologie, které používáte, například na strojové učení nebo ETL? Můžeš nám to trochu přiblížit?

Náš kód běží převážně přes Kebulu, kterou prochází téměř všechna data. Připravuji data jak pro strojové učení, tak pro klasický reporting nebo další aplikace.

Co se týká strojového učení, natáhneme data do Kebuly, tam je provedena příprava, a pak data posíláme do AVSka, kde na nich stavíme modely.

U reportingu připravím datové zdroje v Kebule, které pak posílám do Tableau – našeho primárního reportovacího nástroje. Analytici v něm staví reporty.

Obvykle vytváříme obecné datové zdroje použitelné na více místech, aby analytici mohli z nich vytvářet spoustu různých reportů užitečných pro byznys.

Zmínil jsi AVS a Tableau, ale v IT komunitě hodně proběhla migrace Rohlíku na Google Cloud. Jste tedy součástí jednoho IT, nedochází tam k nějakému tření při snaze o konsolidaci? Nebo jsou tyto technologie nezávislé a plní samostatné úkoly?

V tuto chvíli jsou nezávislé. Rozhodli jsme se pro AVS pro strojové učení ještě rok před tím, než se celé IT rozhodlo přejít na Google Cloud, takže to proběhlo zcela samostatně. Pro nás to zatím nečiní žádné potíže.

Máme endpointy a modely v AVSku, které backend využívá, takže když backend potřebuje data, může si je z AVSka vzít. Občas se diskutuje, zda bychom neměli využít Google Cloud naplno i my, ale aktuálně toto není nijak zásadní téma.

Google Cloud nabízí různé služby, např. jsme zkoušeli Looker, ale zatím to nedává smysl z různých důvodů. Možná to za rok znovu otevřeme, pokud uvidíme, že je to vhodné.

A co BigQuery?

Před přechodem na Google Cloud jsme používali Google Analytics a s ním i BigQuery, se kterým pracujeme dál. Technologie BigQuery neopustíme minimálně pro Google Analytics, protože dává smysl.

Jsme BigQuery využíváme i pro jiné aplikace. Vznikl požadavek na jednoduchou aplikaci, pro kterou jsme nechtěli stavět backend a frontend v našich systémech.

Použili jsme Google Sheets, které jsou jednoduché na vytvoření layoutu aplikace a funkčnosti. Pod ním byla data v BigQuery, Google Sheets je čerpají a my potom pomocí nějaké vrstvy zobrazujeme metriky.

Šlo o jednoduchý MVP, který analytik zvládl vytvořit relativně rychle a byl schopný postavit nějaký finální produkt – aplikaci pro komerční oddělení.

Tato aplikace ještě půjde přetvořit do normální aplikace s backendem a front-endem, ale Google Sheets se ukázal jako skvělý rychlý nástroj.

U dat jsme měli někdy problém s objemem, tak jsme to napojili na BigQuery, což je nativní technologie, takže propojení bylo hotovo během pěti minut.

Myslím, že jsme prošli IT část, data engineering, machine learning, ale co práce datových analytiků?

Na začátku jsme zmínili, že Rohlík je velmi „data-driven“ firma. Co to znamená pro datového analytika pracovat v takovém prostředí?

Příkladně nemohu srovnávat Fincentrum a Rohlík, protože rozsah i dynamika je úplně jiná. Když jsem na Rohlíku začínal, řešil jsem strojové učení, ale protože nás bylo málo, dělal jsem i BI a reporting.

Firma je velmi rozsáhlá, což analytikům dává příležitost pracovat na mnoha různých doménách.

Měl jsem kolegu, který původně byl čistě analytik komerčního oddělení – zabýval se maržemi, tržbami a podobně – a pak si řekl, že chce dělat logistiku.

Během jednoho až dvou měsíců se přetransformoval na analytika logistiky, takže dobře rozuměl logice, reportoval a přitom stále měl obchodní background, což bylo super, protože pokrýval více oblastí firmy bez problémů.

Analytici jsou rozděleni do dvou částí – jedna podporuje lokální týmy, kde Rohlík působí (Česko, Německo, Maďarsko, Rakousko, Rumunsko), a druhá část pracuje v agilních týmech a podporuje je datově.

Pro ty agilní týmy analytici dělají reporting, vyhodnocování AB testů a podobně. Výstup analytika přitom nemusí být jen report, ale i jakýsi mini datový produkt.

Například Rohlík má něco jako mailbox – malou ikonku vpravo nahoře, kde přichází zprávy. Některé jsou generované BI týmem a jeden analytik psal obsah těch zpráv. Integrovali jsme to do backendu a zprávy se posílají zákazníkům.

Takže analytik nevytváří jen report, ale relativně hezké řešení, které zákazník vidí přímo na webu.

Stejně tak u vyhledávání, které bylo před pár lety problematické. Měli jsme dedikovaný tým, který se snažil vyhledávání zlepšit.

Analytici zde pomáhali s daty – reportovali, ale také přispívali ke zlepšování produktu, například statistikou, které produkty se nejvíc nakupují na konkrétní vyhledávané výrazy.

Analytik zpracoval data, která se posílala zpět do backendu a byly následně využívány ve vyhledávání.

Jak do práce datových analytiků proniká důraz na data, který Rohlík má? Tomáš přinesl z předchozích firem datovou kulturu a potřebu stavět na datech.

Z pohledu byznysu má téměř každý člověk ve firmě sadu reportů, na které denně kouká a sleduje klíčová čísla.

Lidé opravdu bedlivě sledují čísla a pokud je něco odlišné od očekávání, řeší, zda je chyba v datech, nebo zda se změnil některý firemní proces.

To klade velký důraz na přesnost, konzistenci a rychlost dat.

Lidé vstávají už v šest ráno a první, na co se dívají, jsou čísla. Potřebují je mít k dispozici včas, protože od sedmi či osmi mají schůzky a potřebují znát data z předchozího dne, aby mohli hodnotit například účinnost změn procesů.

Proto je pro nás datové inženýrství zásadní, aby všechna tato data měla k dispozici včas a v kvalitě.

Jak často se vám stává, že stojíte v pět ráno, abyste něco opravili do šesté?

Pět ráno? To ještě nespím. Tento měsíc se to stalo asi jen jednou a myslím, že to byla moje chyba. V minulosti jsme měli období, kdy se to stávalo víc, třeba během jednoho týdne i pětkrát až šestkrát, kdy jsme opravdu museli vstávat v noci a řešit problémy.

Obvykle to ale nebyla jen chyba jednoho týmu. Často šlo o kombinaci lidské chyby, IT problému, nebo chyby na straně Kebuly.

Když se to sešlo třikrát za sebou, bylo těžké to byznysu vysvětlit – že to zase spravíme, ale pak se to stalo znova.

To se dělo a nyní se nám podařilo stabilizovat Kebulu, která před časem občas padávala častěji, než bychom chtěli.

Nyní když tu chybu udělám, tak je moje chyba, ale obecně už je to celkově relativně v pořádku.

Přijde mi hezké, že datový analytik často není jen někdo, kdo dělá reporty, které končí jako PowerPoint prezentace a nic se nestane, ale je důležitou a klíčovou součástí firmy.

Vnímáš, že je to zároveň větší zodpovědnost, protože na procesu a datech závisí mnohem více lidí?

Myslím, že pro většinu lidí v týmu je to pozitivní. Kdyby to tak nebylo a dělali jen čistý reporting, který nikoho nezajímá, bylo by to nudné.

Lidé, kteří v týmu jsou, to berou tak, že jejich práce má smysl a reálný dopad. Není to jen produkce reportů pro reporty.

No a když se podíváš na své předchozí zkušenosti a srovnáš je…

S tím Rohlíkem – co tě tam nejvíc překvapilo? Všichni máme nějakou představu o Rohlíku jako data-driven lídrovi. S čím ses ty vlastně musel smířit? Co bylo hodně jinak, než jsi si předpokládal?

Určitě mě překvapilo to, co jsem už zmiňoval. To znamená, že lidé na ta data skutečně koukají denně, někteří možná i každou hodinu, a neustále sledují, co se děje. Takže to je něco, co je podle mě velmi specifické. Také to, že lidé mají ta čísla v hlavě, že přesně vidí, jaká by tam měla být čísla. A když tam nejsou, upozorní na to.

Když říkáš „lidé“, myslíš tím všechny zaměstnance – členy boardu, manažery, skladníky?

Myslím vlastně skoro všechny lidi, kteří ve firmě jsou, protože samozřejmě management je jasný, ale i lidé, kteří nejsou na manažerských pozicích, mají co sledovat. I naši analytici chtějí sledovat čísla, protože víme, že nějakým způsobem popisují kvalitu naší práce.

A když to vezmu opravdu jednoduše, tak i juniorní pracovník z komerčního oddělení má svá čísla a pokyny a přesně ví, co má sledovat. Sleduje to a řeší, pokud je něco jinak, nebo pokud je třeba jiný pohled. Takže i juniorní člověk, u kterého by se to možná nečekalo, to nějakým způsobem řeší.

Další věcí, která vyplývá, je rychlost, která prostupuje celým Rohlíkem. Nejen daty, ale i tím, jak je firma schopná velmi rychle otočit směr, pokud je potřeba. Samozřejmě krásnou ukázkou byl covid, kdy se všechno najednou úplně rozjelo a bylo potřeba rychle reagovat. Bylo to velmi hezké vidět v té době, jak Rohlík fungoval, jak spousta lidí věděla, co mají dělat, a velmi rychle zareagovali.

Pokud si dobře pamatuji, tak i Tomáš Čupr někde naklikával náš e-shop Opteta, který jsme tam rychle spouštěli, protože na to měl čas, zatímco ostatní lidé řešili něco jiného, takže to bylo fakt super.

Pamatuji si, že z hlediska našeho BI oddělení bylo taky hodně vstupů – například jsme zaváděli spoustu Slackových upozornění, abychom řešili velmi specifické věci, které vznikly během covidu. To byla doba, kdy jsme měli vyprodáno pět dní dopředu a sklad na to nebyl úplně připravený, což byla výjimečná situace. Ale lidé to skvěle zvládali a my jako BI jsme dělali datovou podporu a pomáhali, co to šlo.

Velmi hezký případ byl, když jsme měli Bistro Rohlík, vyráběli jsme jídla z restaurací skrz Rohlík a rozváželi je naši kurýři. Vždycky jsme k tomu potřebovali reporting. Pamatuji si, jak mi tehdy šéf BI, Petr Hulka, v 16 hodin posílal přístupy do databáze s daty o tom, co jsme rozvezli, přičemž žádný reporting jsme zatím neměli.

Kolem 18. nebo 19. hodiny jsme měli reporty v Tableau a druhý den ráno mohl jít management na meeting s přesnými daty o tom, co se odehrálo v našem novém Rohlíku. Tím se ukazuje rychlost nejen ze strany byznysu, ale i z naší strany, kdy díky například Kebulu jsme schopni velmi rychle dodávat některé věci a nebyl to žádný problém.

Neschytává to potom vás? Tedy, rychlost znamená naklikat to v shop.tetu, což je první rychlé řešení, které se ověří. Na druhou stranu předpokládám, že je to trochu „bastl“ a když na takovém rychle vytvořeném produktu chceš stavět další produkty a procesy, musíš to refaktorovat a přemýšlet o tom. Nejsou pak potom problémy třeba za tři měsíce u Data Engineeringu?

To už většinou funguje a teď je potřeba co nejrychleji chyby opravit. Samozřejmě to známe všichni – třeba někdo přijde s požadavkem na jeden sloupeček a my řekneme, že to budeme muset celé přehodnotit. To se nám samozřejmě někdy stane. Především ten případ z covidu byl hodně specifický.

Jinak obecný princip naší firmy je snažit se dělat věci co nejjednodušší, tedy moc nekomplikovat život. Všichni vidí, jak složitý je proces zrušení objednávky. Pokud budou procesy co nejjednodušší, i data pro nás budou jednodušší a jakýkoliv refaktoring nebo změna budou snazší.

Sám jsem to zkusil například v O2, kde mi data přišla zbytečně komplikovaná ve srovnání s tím, co z nich bylo možné vytáhnout. V Rohlíku něco podobného prakticky neexistuje a myslím si, že většinu věcí by seniorní lidé dnes dokázali za den upravit a zprovoznit v případě zásadní změny.

Samozřejmě nás to někdy tvrdí k tomu, že musíme něco předělávat, ale byznys to potřebuje a my bychom ho neměli brzdit, naopak mu musíme pomáhat. Člověk se proto musí trochu „zakousnout“ a udělat to.

Změnil ses nějak osobně v tom, jaký je princip Rohlíku – dynamiku, rychlost reagování, data-driven kulturu, nefixování na složité věci či neustálé vylepšování a předělávání věcí? Předpokládám, že tohle není pro každého a člověk musí mít speciální nastavení, aby ho to v tomto prostředí bavilo nebo dlouhodobě zvládal.

Určitě si myslím, že téměř každý, kdo je v Rohlíku, musel na svůj přístup trochu změnit způsob uvažování o fungování a práci. Sám jsem to zažil – říkal jsem, že něco nelze udělat, a Tomáš Čupr trval na tom, že to půjde. A zpětně, kdybych se mohl vrátit o dva roky zpátky, řekl bych mu, že to nějak vymyslíme, i když jsem to tehdy ještě takhle nevnímal.

Obecně je kultura nastavena tak, že se snažíme problémy řešit, ne vyhledávat. To znamená, že když vznikne situace, kterou je potřeba vyřešit, ideální je říct si: „Podívejme se, jak to půjde, ne jak to nepůjde.“ Samozřejmě víme, jaké překážky jsou, ale na to se nesoustředíme.

Říkáme si, jaké jsou řešení. Spousta těch řešení je možná nehezkých, ale když to srovnám s jinými firmami, uvědomujeme si, že možná by u nich neprošla. My to ale potřebujeme udělat a většinou to funguje.

Často se stane, že něco spadne nebo se něco rozbije, ale díky rychlosti to okamžitě spravíme. V nejhorším to vypneme, pokud nefunguje. To je mindset celé firmy, jak musí fungovat.

Myslím si, že je to také specifické dané tímto odvětvím. Marže nejsou extrémní a otočit firmu do zisku, aby dlouhodobě prosperovala, je velmi obtížné. Podle mě je téměř jediná cesta právě přes rychlá, i když ne úplně hezká, ale funkční řešení.

To bylo moc hezké, Ondro. Jaké problémy tedy teď čekáte? Co je na stole, co vás nemine?

Teď je samozřejmě obrovský boom AI, přestože já osobně tomu slovu příliš nefandím. Asi nebudeme rozebírat, jestli současné nástroje jako GPT skutečně jsou AI nebo ne. Každopádně to u nás rezonuje.

Nedávno jsme měli interní hackathon, kde jsme měli asi šest až osm týmů, které zkoušely využít například GPT nebo jiné nástroje a vymyslet, jak v naší firmě AI či machine learning ještě posunout dál.

Byly to týmy z IT a datových oddělení?

Ano, primárně složené z vývojářů a datových specialistů. Byl tam i produktový tým a třeba Tom Ondřej. Akademické kolegiální setkání probíhalo on-site, někteří byli i přes noc, a pizza taky nechyběla.

Tak to mě moc těší. My jsme si tedy řekli: „Máme GPT, máme další věci, které můžeme vyzkoušet, pojďme vytvořit nějaká rychlá MVP (minimum viable products), řešení, která nám ukáží, kam AI v firmě využívat.“

Měli jsme zajímavé věci, například chat GPT, konverzační nástroje, ale i velmi technické, řekl bych ne „sexy“ záležitosti, jako je zlepšování forecastů. Pro zákazníky to asi není moc zajímavé, pro mnohé je to nuda, ale nám to pomohlo vylepšit či vymyslet nové způsoby forecastingu.

Dále tam byly případy využití rozpoznávání obrázků – relativně dobře vyřešená technologie, kterou máme v plánu využít ve skladu na zlepšení kvality a celkového procesu.

Také tam byly věci spojené s obohacováním dat. Jeden tým využíval chat GPT právě k obohacení našich dat, například popisu produktů.

To je oblast, ve které nejsme úplně silní – nemáme ke všem produktům kvalitní metadata. Pomocí chat GPT jde velmi dobře a automatizovaně tato data vylepšit.

Tým vytvořil jednoduché vylepšení do našich interních systémů, kdy na základě stávajících dat o produktu dostaneme určitý enhancement, tedy zlepšení dat, například různé tagy, filtry či lepší popisy.

Například informace, zda produkt obsahuje lepek, nebo patří do určité kategorie.

Přesně tak. Máme data, která nás zajímají, ale často jsou jen v textu, a chtěli bychom je vytáhnout do přehledné podoby. Máme v Česku asi 20 000 různých produktů, celkově v různých zemích zhruba 80 000, a chceme co nejvíce jednotně získat informace o každém produktu.

Například, zda je vhodný pro určitou skupinu zákazníků, na grilování, nebo na specifický druh vaření apod.

Takové věci může řešit i člověk, ale procházet 20 000 produktů by trvalo dlouho a udělat to jednotně je poměrně náročný úkol.

Pokud využijete například API OpenAI, dostanete výsledky velmi rychle a s těmito daty pak můžete dále pracovat.

Další úzké případy se týkaly přímo zákazníků a toho, jak by mohli využívat pokrok, který přinesly chat GPT a další modely. Například zákazník se zeptá: „Jaký recept si mám uvařit v sobotu, mám doma toto a toto?“ A ideálně mu chceme říct: „Uvař si toto a toto, tady máš seznam produktů a kup si je u nás.“

Recepty a horoskopy jsou asi už vyřešené věci, což mě osobně baví.

Co tě osobně kromě migrace na Metabase čeká? Jaké jsou tvé hlavní výzvy?

Musím si zvyknout na nové prostředí Roclia. Jde především o technické zlepšení našeho data engineeringu, protože nás jsou tři. Z hlediska trhu je to poměrně malý počet analytiků vzhledem k velikosti firmy.

V jiných firmách je poměr mezi data engineerem a analytiky úplně jiný.

Na druhou stranu v těch firmách často analytici nedělají end-to-end aplikace, což u nás ano.

Určitě nás čekají úkoly v oblasti automatizace – jak si usnadnit některé úkony, abychom dokázali v práci udělat víc.

Jde také o oblast machine learningu – nikdy jsme neměli machine learning ops specialistu.

Takže to je další oblast, kde může data engineering pomoci.

Chystáme se i nabírat nové kolegy – hledáme jak analytika čistě pro BI, tak i specialisty na machine learning, protože tam pořád je spousta práce.

Máme spoustu zajímavých případů, o které se musíme postarat.

Vidíme, že nám to pomáhá a s příchodem chat GPT a dalších nástrojů to chceme ve firmě prosazovat ještě víc.

Preferujeme, aby co nejvíce lidí z vývojářského týmu chápalo, co machine learning je, jak funguje, jaké jsou jeho výhody a omezení, a bylo schopno ho zapojovat do produkčních systémů.

Současně ale potřebujeme odborné machine learning inženýry, protože například pro forecasting zatím neexistuje mnoho dobrých řešení, která by šla jen tak koupit na trhu a aby fungovala.

Pro tyto věci je podle nás lepší práci dělat interně. Není to tak „sexy“, vyžaduje to znalost statistiky a dalších oblastí, takže potřebujeme lidi, kteří to zvládnou.

Technické úkoly jako chat GPT pak často delegujeme na vývojáře a backendisty, kteří to integrují do produkce, ale těžší machine learning zůstane v rukou specializovaných lidí.

Držíme vám palce při hledání nových lidí. Možná někoho z vašich budoucích kolegů poslouchá právě náš posluchač.

Těšíme se na další setkání a slyšení. Díky moc, Ondro, že jsi přišel a nechal nás nakouknout pod pokličku.

Chtěl jsem udělat špatný vtip, že jsi nás nechal nahlédnout do pekárny.

Přesně tak, místo rohlíku jsme se podívali na skutečné těsto, ze kterého je upečený.

Ondro, opravdu děkujeme za návštěvu.

Mám pocit, že kdybychom tady byli ještě dvě hodiny, pořád by bylo o čem mluvit. Věřím, že se nevidíme naposled a že ani tento díl s Rohlíkem, ani tento díl s tebou není poslední.

Děkujeme moc.

Děkujeme, Ondro.

Taky díky za pozvání, mějte se.

To je všechno.

Děkujeme, že jste doposlouchali další díl Datatolku.

Díky patří také našim partnerům: Bighub, Vypnoutu, Manta, Natín a mě, GeneBeam, Seznam.cz a Muse.

Pokud vás zajímají další informace ze světa datových technologií a československé datové scény, navštivte naše stránky datatolk.cz.

Nechť vás provází data!