Podcast

Dobrý den, moje jméno je Jirka Vycherek a vítám vás u dalšího dílu Datatolku. Dnes jsme tu hned dva moderátoři. Spolu se mnou bude dnes moderovat Karel Šimánek. Ahoj, Karle.

Ahoj, Jirko.

S Karlem společně organizujeme meetup Datamesh a protože je na rozdíl ode mě opravdový a sám datový profesionál, doufám, že do našeho podcastu přinese ještě větší technologický insight a společně budeme pokládat zvídavější a erudovanější otázky našim hostům.

Uvidíme, Jirko. Uvidíme.

A uvidíme to právě na dnešním hostovi, který je velmi erudovaný, a my jsme velmi zvědaví, co nám dneska bude vyprávět. Z společnosti Workday k nám přišel Hinek Valner.

Ahoj, Hinku.

Ahoj, Jirko.

Ahoj, Karle.

Jen bych chtěl dodat, že s tou erudicí ještě uvidíme.

To uvidíme, ale ta příprava vypadala velmi dobře.

Hinku, prosím tě, dokážeš nám představit, pro ty, kdo Workday třeba ještě neznají, co vlastně Workday dělá, případně jak vznikl, kdo za ním stojí a jak jsi se tam třeba dostal?

Určitě, mohu to minimálně zkusit. Workday je velká americká IT společnost. Já jadrám toho businessu, což je systém pro správu zaměstnaneckých dat. Typicky ten use case je takový, že jsi větší společnost, řekněme 20 tisíc lidí a více, a potřebuješ někde spravovat zaměstnanecká data, řešit výplatní pásky, dovolené, organizaci práce, organizační strom a podobné věci.

Workday kromě toho nabízí ještě finanční služby a nějaké operativní řešení, ale já jadrám toho businessu je správa zaměstnaneckých dat. Když se pak zaměřím na to, co děláme v Praze, protože jsem právě popsal Workday obecně, tak v Praze vyvíjíme produkt s názvem Workday People Analytics. Ten je součástí nabídky Workday a je to analytická aplikace, která našim klientům dodává insighty právě z těch zaměstnaneckých dat.

A co konkrétně dělám v Praze já? Vedu analytické oddělení v rámci tohoto produktu a starám se o to, abychom dodávali zajímavý obsah.

Jasně. Jak se to tedy může představit? Já znám třeba PeopleSoft ještě z Komerční banky. Dokážeš vysvětlit, jestli je to nějaká aplikace, kterou si někdo stáhne, jestli je provozovaná na desktopu, nebo jestli je to cloudová SaaS aplikace, případně co to vlastně je?

Jo, to je docela vtipná historka. Jestli znáš PeopleSoft, tak Workday v podstatě vznikl, když PeopleSoft začal být skupován Oraclem, a zakladatelé PeopleSoftu řekli, že to nechtějí. Tak odešli a založili Workday jako konkurenci Oraclu v HR řešeních. Workday je kompletně v cloudu a neprovozuje žádná on-premise řešení. Takže všichni klienti mají jednu verzi, která běží v cloudu. Workday samozřejmě používá své vlastní privátní i veřejné servery, kde aplikace běží.

A jak klienti s tím pracují? Prostě otevřou webovou stránku, přihlásí se a mohou dělat, co potřebují.

No a jak se Workday dostal do Prahy a ty do Workday?

Já začnu tím, jak se Workday dostal do Prahy. Ta cesta začala před čtyřmi a půl lety, kdy Workday koupil český startup Stories BI, ve kterém jsme vymýšleli nástroje na automatizaci datové analytiky, ve zkratce. A jak jsem se dostal do Workday já? Skrz to, že jsem pracoval v tom startupu, a do toho startupu jsem se dostal přes Vojtu Ročka, se kterým jsem začal pracovat v Rockabye na pozici BI analytika. Když Vojta odešel a začal vymýšlet Stories, přivedl mě tam a od té doby spolupracujeme.

No a před čtyřmi a půl lety koupil Workday Stories jako produkt a tebe také akvizírovali. Co se vlastně ze Stories stalo?

Dá se říct, že ze Stories aktuálně vznikl Workday People Analytics. To, co děláme, je v podstatě duchovní nástupce nebo přirozené pokračování toho, co jsme dělali ve Stories.

Celá dynamika spojení spočívá v tom, že ve Stories jsme měli nástroj, který vezme klientská data a hledá v nich nějaké zajímavé insighty. Workday řešil problém, že má systém, kde uchovává zaměstnanecká data, ale nemá řešení, které by klientům automaticky dávalo insighty z těchto dat.

A v tu chvíli nás potkali, respektive potkali Filipa, který byl jedním ze spoluzakladatelů a šéfem Stories, na konferenci v Americe. My jsme přišli s řešením, které lze aplikovat na jakýkoliv druh dat. Workday řekl, že to je super, má spoustu dat, a chtěl by naše řešení aplikovat a vytvořit z toho společný produkt. Takže jsme se dohodli na akvizici.

A v podstatě to, co děláme tady v Praze, je ta aplikace, tedy použití algoritmů, které jsme vyvinuli ve Stories, na data v Workday. Lze si tedy představit, že Stories je teď plugin pro Workday v oblasti People Analytics.

V podstatě ano, samozřejmě za touto odpovědí je několik vrstev, protože ze Stories jsme přinesli jádro startupu, tedy sadu analytických algoritmů. Ale People Analytics nejsou jen algoritmy, je to také frontend, který výsledky algoritmů prezentuje srozumitelnou formou pro business uživatele. Dále je tam backend, který data někde stahuje, orchestruje, zajišťuje datové pipeline, a všechny věci, které jsou potřeba k dodání kompletního produktu.

To jsme tedy dělali ve Stories. Když to přenesu do Workday use case, máme tam „zafixovaná“ data, což znamená zaměstnanecká data jednotlivých zákazníků. Máme více než jeden use case. Standardně tyto věci řeší HR analytická oddělení nebo HR business partneři, což jsou naše hlavní persony. Ti pomocí datových insightů pomáhají business leaderům, general managerům nebo line of business leaderům zjistit, co se děje s jejich zaměstnanci.

Klasicky nejžhavější téma je, kde lidé odcházejí a proč. Co s tím mohu dělat? Jak se daří náboru? Jaké kanály jsou rychlé nebo pomalé? Dokážeme najít kvalitní lidi? Jak moc new hires odcházejí za určitou dobu? Velké téma je také diverzita nebo dovednosti zaměstnanců. Jsou naši zaměstnanci dostatečně kompetentní, co se týče skillů, ve srovnání s nějakými benchmarky?

Tohle je tedy náš use case. Děláme to tak, že vezmeme zadání, data od Workday a snažíme se pomocí různých postupů analyzovat, zpracovat data. Můžeme do detailu vysvětlit a rozebrat případnou story, jak business uživatel vstoupí do našeho nástroje a uvidí například: „Aha, největší problém je, že nám odcházejí lidé. Co mám řešit v rámci celé firmy? Zdá se, že Java vývojáři v New Yorku odcházejí, protože nedostávají dostatečné platové ohodnocení v porovnání s trhem. Třeba je to kvůli manažerovi, nebo odcházejí hlavně ženy.“ Takže se snažíme najít tu „jahodku“ přes insighty z HR dat.

Hinku, tvoje role je senior manager analytics a něco podobného. Můžeš prosím popsat svoji roli, kolik máš lidí ve svém týmu, jak váš pražský tým funguje, jestli máš pod sebou všechny lidi, nebo jsou tam ještě další týmy vedle sebe, jak se doplňujete a podobně?

Určitě. Moje role je senior manager analytics a něco podobného. Ale teď vážně, to, co děláme v pražském Workday, je vývoj téhle aplikace.

Tu aplikaci vyvíjíme end-to-end tady v Praze, což znamená, že k tomu potřebujeme business analytiky, data scientisty, ML inženýry, kteří píší jednotlivé algoritmy, vývojáře, kteří mají pod kontrolou datový tok, stejně jako front-end a back-end vývojáře, DevOps, testery, produktové manažery, UX designéry a další. Prakticky máme všechno, co k tomu potřebujeme.

Konkrétně moje role je vést analytické oddělení, které zahrnuje business analytiku, data science a produktovou analytiku v rámci našeho produktu. V Praze nás je celkem 80 a moje organizace z toho tvoří necelých 30 lidí.

Jaké je složení tvého týmu? Jaký je poměr mezi inženýry, analytiky a hardcore data scientisty?

V mé části organizace máme tři týmy. Zhruba třetina jsou tzv. data scientisté, ML inženýři a Python inženýři, tedy lidé, kteří pracují na jádru, na enginu, který zpracovává data pro produkt. Zbytek jsou business analytici, které já nazývám technickými projektovými manažery a zároveň business developery. Jsou to lidé, kteří dělají propojení mezi produktovým manažerem a byznysem.

Jejich úkolem je specifikovat business zadání do datového jazyka. Například pokud chceme dělat analýzu dovedností zaměstnanců, co to znamená? Co mají vývojáři vyvinout? Jaká data budou potřebovat? Bude třeba nějaká transformace? Jak bude definována metrika? Co by dělal HR analytik, kdyby to dělal na koleni a nepoužíval náš nástroj?

Dále máme frontend a backend vývojáře. Většina z nich sedí v jiné části organizace, ale s nimi také spolupracujeme, pokud potřebujeme pomoc.

A jak si představit tu vaši „chytrou“ analytiku? Je to spíš víc modulů nebo jeden model? Můžeš to technologicky trochu popsat, aniž bys vyzradil know-how?

Určitě. Je to spíš řetězení modelů. Myslím, že dobrý příklad je představit si datového analytika nebo business analytika, jak by řešil postupně jednotlivé kroky, kdyby dostal zadání.

Například jako první krok si analytik řekne: „Zjisti mi, kde nám lidé odcházejí, kde máme největší problém s odchodem.“ Nejprve se shromáždí data, potom definuje metriky, připraví pohledy, které budou zajímavé. Ať už se to týká lokalit, profilů zaměstnanců, manažerů nebo nákladových středisek, prostě si vytvoří hrací pole, na kterém bude pracovat.

Pak začne hledat trendy, anomálie, případně jiné zajímavosti. Například by mohl dělat trendovou analýzu jednotlivých segmentů a vyhodnotit výsledky. Poté musí prioritizovat, co je zajímavé a co ne. A tím může být poměrně velký počet trendů, například 250 nebo i tisíc, protože pokud jdeme dostatečně do detailu, objeví se hodně statisticky zajímavých trendů, ale otázka je, které jsou relevantní obchodně.

Příklad, který často používám: když zjistím, že odcházejí vývojáři v New Yorku – konkrétně jazykoví vývojáři Java – a zároveň jsou v New Yorku jen Java vývojáři a nikdo jiný, tak vlastně říkám stejnou věc dvakrát různými způsoby. Takže analytik by si to měl zkontrolovat, seskupit výsledky do klastrů a doplnit textový popis. Následně může provést i jako nějakou root cause analýzu.

Engine se v podstatě snaží tyto kroky částečně vykonávat za analytika. Nejprve prozkoumává prostor, generuje množství různých segmentů a kombinuje je.

Řešíme tam i optimalizační problémy, protože když si představíte prostor s padesáti různými charakteristikami (feature), a začneme řešit jejich kombinace, např. trendy na lokacích, profilech a manažerech najednou, počet kombinací rychle exploduje. Proto určitou optimalizaci potřebujeme.

Dále řešíme detekci anomálií pomocí statistických metod. Snažíme se odhadnout, zda je daná časová řada anomální, například jestli je míra odchodovosti v Londýně neobvykle vysoká v porovnání s ostatními pobočkami, s historií nebo benchmarkem.

Když máme tento prioritizovaný seznam insightů, pořád jich může být moc. Naším cílem je z toho velkého množství dat dostat na počátečních pět insightů. V našich use casech pracujeme s desítkami tisíc, někdy až sto tisíci prioritami. Proto další zpracování zahrnuje seskupování do klastrů podle podobnosti, vybíráme reprezentanty a doplňujeme vysvětlení.

Ukážeme třeba, že odcházejí inženýři v New Yorku, ale proč? Jaké další faktory to ovlivňují? Může jít o další datové zdroje, například dotazníky se zaměstnaneckým sentimentem. Vše se snažíme podat ve stručné podobě těm, kdo rozhodují, aby bylo jasné, co řešit.

Zmínil jsi velmi důležitou věc, a to jsou data, která krmí modely. Můžeš prosím popsat, jaký je rozdíl mezi tím, když jste dříve vyvíjeli modely pro Škodovku nebo Kiwi, a jak to funguje teď v HR oblasti?

Určitě. Je to dobrá otázka z několika aspektů. Všechny projekty u nás byly v podstatě datově agnostické, takže nebylo důležité, jaká data přicházejí. Projekty definoval konfigurační soubor.

Všechny projekty měly jedno společné – vždy jsme měli nějakou monetární hodnotu, kterou bylo možné použít jako metriku. Takže bylo jedno, jestli to byla data z logistiky, e-commerce nebo bankovnictví. Vždy šlo jednoduše ohodnotit problém v korunách nebo dolarech.

Odpověď byla vždy ano, a byla k dispozici jasná rovnice. To velmi usnadňovalo práci a určovalo, kterou story preferovat – jestli je důležitější zpoždění dodávek u konkrétního dílu nebo něco jiného.

Když jsme nastoupili do Workday, bylo to úplně jiné. A ani jsme nečekali, jak moc se to změní. Jako bývalí startupoví lidé jsme si mysleli, že to bude jednoduché – jen nakrmit data a hotovo. Ale co nás překvapilo, a myslím, že to řešíme dodnes, je to, že na těch zaměstnaneckých datech je to velmi těžké, protože…

[Text zde končí nedokončeně]

Jirka, Karle, doufám, že přepis odpovídá všem požadavkům na zachování obsahu, gramatiky, diakritiky a členění do odstavců. Pokud budete chtít pokračování přepisu nebo jiné úpravy, dejte vědět.

Jsou data o lidech. Pokud ta data nejsou o lidech a o penězích, je to velmi snadné, protože peníze nemají emoce, nikdo se nehádá o to, že 10 dolarů je důležitějších než jeden dolar. Ale přesto, když se bavíme o analytice a lidech, i když některé věci lze vyčíslit, spousta jich vyčíslit nelze. Konkrétně například, když řešíme analýzu diverzity nebo podobných oblastí, není úplně jasná monetární metrika nebo monetární spojení mezi diverzitou managementu a tím, kolik firma může díky tomu reálně ušetřit.

Toto tam nemáme, a občas máme výzvu, jak nastavit algoritmy, které dělají nějaká rozhodnutí, když toto směrnitko chybí. Samozřejmě zde vstupuje i téma biasu, protože všichni HR analytici nebo HR business partneři, což jsou naši klienti a primární uživatelé této aplikace, se ptají, jaké máme explicitní biasy. Teoreticky by se dalo říci, že náš engine nedělá rozhodnutí typu, že tyto lidi je třeba vyhodit nebo najmout, vždy to dělá člověk, ale naše analýzy mohou pomoci dát nějaké návrhy nebo doporučení. Proto je téma biasu důležité. Máme některé explicitní biasy, například tím, že provádíme top-down analýzu, což znamená, že preferujeme větší populaci před menší. Kromě toho vznikají implicitní biasy, které pramení ze statistiky.

To znamená, že pokud jsou některé populace nebo segmenty v organizaci nedostatečně reprezentovány, statistika nemusí být jistá a často to vyhodnotí jako nejisté či nesignifikantní pouze proto, že není k dispozici dostatečný vzorek. Toto je tedy také reflexe reálné situace.

Situace v HR je spíše „softová“ než „hardová“, tedy spíš jde o to, jak s daty zacházet a jak je správně prezentovat, než o to, že by data nebyla k dispozici nebo nebylo možné s nimi pracovat. Pokud tomu rozumím správně, je tomu tak? Ano, řekl bych, že sociálně náš přístup k datům je takovýto. My víceméně k datům přístup máme, protože když si klient nainstaluje naši aplikaci, souhlasí s tím, že oddělení DataSense, které vyvíjí tuto aplikaci, bude mít přístup k těmto datům.

Naši data scientisti tak mohou pracovat s reálnými daty, která jsou velmi citlivá, protože jsou to data o zaměstnancích konkrétních firem. Máme samozřejmě náležité zabezpečení, existuje retention policy, což znamená, že data jsou periodicky mazána a nemohou opustit server, kde jsou uložena. Není možné si data stáhnout lokálně a pracovat s nimi mimo tento systém. Přístup k datům tedy máme, ale myslím, že větší otázkou je, jak data prezentovat.

Je to kombinace toho, že jde o HR data a že naši uživatelé jsou z HR. Jeden z vtipných problémů, který jsme řešili, byl, že jsme měli mnoho metrik, kterými jsme se snažili prioritizovat například otázky diverzity. Tyto metriky často nejsou celá čísla, což znamená, že se může stát, že v organizaci například chybí čtyři a půl ženy.

Pro nás data scientisty je to běžný výsledek metriky, ale například v první verzi aplikace jsme tyto metriky ukazovali našim uživatelům a všem pohlavím. Ve všech ostatních případech, které jsme testovali, nikomu nevadilo, když například bylo deset a půl milionu dolarů, všichni byli rádi, že vidí číslo jako pomocnou metriku. Zde ale standardní reakce byla, že jsme se zbláznili a že ověřují validitu těchto dat.

Takže řešíme otázku, jak tyto hodnoty vysvětlit HR manažerům. Má model nějakou zpětnou vazbu nebo mají uživatelé možnost kliknout, že určitá data už nechtějí vidět, protože jsou nerelevantní, nebo by chtěli zobrazovat jinou kategorii oblastí?

Řekl bych, že ano i ne. Rozhodně nemáme zpětnou vazbu v takové klasické formě, jako má například Spotify, kde uživatelé dávají like nebo dislike písničkám a systém na základě toho generuje playlisty. Máme jistá doporučovací řešení, která jen individualizují již vygenerované výsledky, tedy klasický machine learning při generování výsledků neprobíhá.

Uživatelé mohou dát thumbs up, thumbs down, skrýt některé výsledky nebo si je uložit na později, ale těchto impulsů zatím máme velmi málo, aby se algoritmus mohl učit. Tyto reakce využíváme spíše pro ad hoc analýzy a korelace kvality výsledků s tím, kolik času u nich lidé stráví. Na rozdíl od Spotify, kde je stovky milionů uživatelů, máme těchto dat méně.

Kolik přibližně máte zákazníků? Napadlo mě, zda přenášíte znalosti z jednoho klienta anonymizovaně na jiného, třeba že byste doporučovali praxe, které konkurence používá. Nebo k tomu vůbec nedochází?

Aktuálně máme 600 klientů, kde klient je v našem pojetí firma. Většina klientů však nechce, aby jejich data byla použita k lepším rozhodnutím pro ostatní klienty – toto je ve smlouvách zakotveno. Takže to můžeme dělat jen do určité míry, primárně pro vlastní potřebu, například metaanalýzy nad daty, která máme k dispozici, nebo A/B testování.

Nedochází tedy k tomu, že by firmy podobného typu (např. střední telekomunikační firmy) vylepšovaly rozhodovací algoritmus pro ostatní podobné firmy.

Co se týče benchmarků, ty neděláme sami z dat, která klienti poskytují, protože větší část našich klientů by to nechtěla. Používáme však produkt Workday, který tyto benchmarky nabízí – klienti vyměňují agregovaná statistická data na úrovni regionu nebo větších skupin a díky tomu dostávají benchmarky od ostatních Workday klientů.

Dovolím si ještě jednu otázku. Z přednášek a prezentací je zřejmé, že vaše práce byla velmi specifická. Abychom byli skutečně agnostičtí, byla potřeba velká integrační práce pro každého zákazníka. Můžeš popsat, jak se liší škálovatelnost řešení u Workday?

Určitě. Skvělý komentář. Ve Stories byla práce spíše namáhavá, protože přizpůsobení algoritmu konkrétnímu use case často vyžadovalo několik týdnů mé práce. Znamenalo to namapovat data, což by za normálních okolností dělal business analytik, vytvořit ETL (extract, transform, load) proces, tedy dostat data ze zdrojové databáze do podoby, kterou algoritmus zvládne zpracovat.

K tomu jsme vytvářeli společný konfigurační soubor, který obsahuje instrukce pro engine, například že se bude analyzovat logistika, že metrikou je věrnost dodávek nebo dochvilnost vůči dodavatelům. Důležité bylo vymezit, které metriky se v analýze použijí a jaké statistiky jsou autorizované.

Ve Workday jsme však museli přijít s řešením, které se dá snadno škálovat a zvládne obsloužit více než sto klientů zároveň. Naše řešení proto dodává jednotnou datovou pipeline všem klientům, stejný jednotný konfigurační soubor, přičemž liší se jen obsah dat. Pro klienta, který si koupí PIP Analytics, a má nastavený Workday, přijde implementátor nebo externí firma a společně se posadí k našemu instalačnímu vizionáři, který funguje jako dotazník pro data.

Klient pak musí ukázat, kde má data o zaměstnancích, například kde je pole pro pohlaví, co konkrétně znamená a podobně. Dále pak dodá organizační strukturu nebo i další pole, která jsou nezbytná. Pokud se některé povinné informace nezadají, například pohlaví, analýza není možná.

Data, která se zde zmiňují, jsou tedy přímo ve Workday, nikoliv externí. Je to proces mapování dat z klientova Workday do požadované datové struktury. Každý zákazník má totiž určitá vlastní přizpůsobení (customizaci). Proto musíme vytvořit odpovídající ETL proces pomocí vizionáře.

Customizace nejsou úplně minimální, ale nejsou ani 100%. Někteří klienti mají polia ve výchozím nastavení, jiní je mají úplně jinak pojmenovaná či strukturovaná. Každý klient operuje jinak, například organizační struktura, cost centra a podobně. Nechtějí mít analytický nástroj, který by nesouhlasil s interním reportingem, což musí být konzistentní.

Stává se, že nemají některá povinná data? Upřímně se nám ještě nestalo, že by chyběl třeba gender field, což je pro nás povinné pole. Často chybí nepovinná data, například hodnocení výkonu zaměstnance (performance). To je důležité pro analýzu, zda odcházejí vysoce výkonnostní zaměstnanci (high performers). Některé firmy toto nepoužívají, takže pak máme pole označená jako nepovinná. Pokud chybí povinná data, nedodáme analýzu, protože by neměla smysl.

Firmy taková data ani nemají smysl uchovávat mimo Workday – všichni zaměstnanečtí záznamy jsou ve Workday, neexistuje externí systém, kde by se vedla třeba personalistika či výkon.

Některé firmy používají Workday jako nástroj pro nábor (hiring), jiné nikoliv – proto pokud nějaký klient hiring v Workday nepoužívá, má obsah bez těchto dat. My nyní pracujeme na podpoře externích hiringových řešení, například Fairparty, kde bychom uměli tato data propojit na úrovni polí.

Nepovinná pole jsou tak dodatečné informace pro zpřesnění modelu, ale nejsou nezbytná pro fungování.

Jak se liší obsah datové sady, pokud některá pole jsou dostupná a pokud ne? Například pole sentimentu nebo spokojenosti zaměstnance – pokud firma využívá systém pro zpracování dotazníků, můžeme využívat tyto informace k analýze důvodů odchodů – zda byli zaměstnanci nespokojení s manažerem, platy či vybavením. Pokud tomu tak není, daná data zobrazena nebudou.

Snažíte se motivovat firmy, aby tato data používaly? Když parametr může být významný, máte nějaká data, o kolik lepší by se model stal, kdyby je klient poskytl?

Žádnou statistiku nemáme. Komunikujeme především s implementátory během nasazení, kde vysvětlujeme, jaký význam mají jednotlivá pole a jak mohou hodnotu přidat. Například když mají pole zachycující sentiment zaměstnanců, učíme je, že toto pole pomáhá v lepším objasnění důvodů odchodů či spokojenosti.

Pokud máte další otázky, rád je zodpovím.

Bavili jsme se o tom, že dříve jste ty modely tvořili více na míru konkrétnímu zákazníkovi, zatímco teď říkáš, že je to naopak – teď je to skvělé, protože máme relativně unifikovaný model a relativně unifikovaného zákazníka. Jak je to s přesností? Je teď lepší, nebo horší?

Upřímně si myslím, že je teď lepší, ale potenciálně to může být i horší. Samozřejmě, kdybychom vzali celé naše analytické oddělení, všechny datové vědce a posadili je přímo do firmy, aby vytvořili model na míru dané firmě, určitě by byli schopni jít dál, než my kombinací generického řešení plus nějaké konfigurace nebo vstupů od klienta. Oni totiž znají kontext, znají i další potenciální příznaky, které my třeba neznáme – například že proběhla akvizice, nebo že byla zrušena nějaká pobočka. My to zjistíme s určitým zpožděním, ale ne dopředu. Oni znají všechny cykly v HR světě a byznysových procesech, které jsou docela signifikantní a mohou mít značné zpoždění.

Standardní úvaha je, že když firma rychle roste nebo najme třeba dvacet lidí do desetilčlenného týmu, není jasné, co to znamená pro odchod těch lidí za půl roku. Pokud manažer nezvládne ten nápor, může se stát, že se celý tým rozpadne. To všechno člověk, který sedí přímo ve firmě, ví nebo má kontext, a je schopen model dotunit dál než my.

Jak s tím my bojujeme? Snažíme se být chytřejší, pokud jde o dynamiku řešení. Standardní dimenzí, na které to řešíme, je velikost firmy. Máme klienty od firem s deseti tisíci zaměstnanci až po firmy se sto padesáti tisíci lidmi. Je jasné, že počet signifikantních insightů nebo statistiky nejsou vytvořeny pouze pro jednu populaci. Například u firmy s deseti tisíci lidmi, když začneme rozčleňovat data podle jednotlivých poboček, pracovních profilů, struktur nebo organizačních úrovní, může nastat problém s malým počtem zásahů. Tam musíme něco změnit.

Naopak u velkých firem je neustále hodně lidí, což umožňuje jiné fungování modelu. Ještě možná, abych to doplnil, když jsi se ptal na procento přesnosti – to je další výzva, kterou řešíme, protože na naši úlohu lze nahlížet jako na klasifikaci. My říkáme, který problém je pro firmu zajímavý a který ne. Výstupem našeho modelu může být například, že odchází Java vývojáři, anebo že odcházejí marketingoví experti ze San Francisca. My potřebujeme zjistit, jestli jsou zajímavější právě ti Java vývojáři, marketingoví experti, obojí, nebo nic.

Abychom to mohli rigorózně ohodnotit, potřebovali bychom validační dataset, kde by lidé z firmy označovali problémy za zajímavé, či nezajímavé – podobně, jako kdyby to dělala nějaká novoranká AI zcela na začátku, aby byla schopná klasifikovat. Ten validační dataset ale nemáme. My vlastně problémy „gettujeme“ a úspěšnost měříme až pomocí implicitních vyhodnocení, například praximetrik.

To znamená, že GM z firmy nám asi nepoví, jestli je problém zajímavý byznysově, ale zjistíme, jestli dotyčný tráví na tomto problému čas, nebo ho ignoruje. Nebo jaký vliv má změna nastavení algoritmu, jestli například zaměstnanci obecně tráví víc času v aplikaci. To tedy snažíme měřit tímto způsobem – implicitně kompenzujeme nedostatek explicitního validačního datasetu.

Technicky vzato, používáte jeden model pro všechny zákazníky, nebo má každý zákazník vlastní model simulující jeho specifický „heartbeat“ a touhy?

To je možná spíše technikálie. My používáme jeden generický model, který se ale pak upraví například podle velikosti firmy. Není tak, že bychom měli zcela odlišné sady modelů nebo vstupů. Vstupy jsou stále stejné, ale měníme některé statistiky a parametry modelu dle konkrétních okolností.

Čili poskytujete nějaké insighty týkající se firmy, které by měly zpřesnit výkon modelu. Kde jsou limity a kde tyto insighty končí?

Samozřejmě limity jsou v datech samotných. Pokud v nich není podchycený nějaký sezónní cyklus nebo jiný fenomén, který probíhá ve firmě, a není v datech zaznamenaný, pak máme problém, protože to z modelu nevytáhneme. Zkrátka, co není v datech, to model nevidí.

Tady mě napadlo, když máte novou implementaci Workday u nového klienta, jste zřejmě trochu znevýhodnění, je to tak?

Ano. V podstatě máme historii, jak tomu říkáme, „treasure“, která říká, že pokud klient teprve nedávno nasadil Workday nebo migroval z jiného řešení, naše aplikace pro něj několik měsíců není použitelná. Dodáváme obsah do aplikace a víme, že bychom jinak jenom generovali šum, takže jsme v tom upřímní.

Další zajímavou výzvou, kterou řešíme, je přímo na konci procesu – využitelnost insightu a způsob, jakým byznysoví uživatelé s insighty pracují. Tam je několik dimenzí. Obecně tedy získáš insight, že ti odchází třeba Java vývojáři z určitého týmu – co s tím uděláš?

Aby se s tím dalo něco dělat, musíš tomu věřit, rozumět tomu řešení a přesně vědět, co to znamená. Současně musíš pochopit, co jsme ti nezobrazili, například všechny ostatní profily v New Yorku, ostatní lokace a všechny miliony dalších datových řádků, které na začátku ignorujeme.

To jehle otázka, která je docela zásadní – záleží, s kým člověk mluví. Když mluvíme s HR analytiky, typicky po nás chtějí Excel – třeba přehnaně řečeno – chtějí mít 100% informaci, i za cenu, že tam je spousta šumu a oni si signál musejí najít sami. To přijmou a budou to schopni řešit.

Naopak HR business partneři by reálně chtěli dostat zprávu třeba na Slack s jasným zadáním: udělej tohle. A chtějí mít nějaké potvrzení od HR analytika, že je to pravda a mají to skutečně udělat. Protože pokud dostanou něco od neznámého systému bez možnosti ověření, budou k tomu skeptičtí.

Jak toto řešíte?

Mohu popsat, jak to přistupujeme, i když si nejsem jistý, zda toto máme zcela vyřešené – jedná se o otevřený problém, na kterém hodně pracujeme převážně dialogem a iteracemi s klienty.

Na začátku jsme například v řešení ukazovali procentuální hodnocení nebo impact faktory jednotlivých atributů. Takže když jsme zjistili, že odchází Java vývojáři v New Yorku, zobrazilo se, že míra odchodu se zvýšila o deset procentních bodů, z toho 25 % problému řeší konkrétní manažer, dalších 35 % tvoří určité oddělení z New Yorku. Naopak seniorita některých Java vývojářů může tento problém částečně vyvažovat s mínus 35 %.

To je podobné jako pokles prodeje ponožek, kde černé ponožky jdou dolů, ale modré nahoru. Takže tam je opačný faktor. Pro nás je to mentální cesta, která dává smysl.

Pro uživatele není jasné, co znamená zmíněných 35 % s 10 body, nebo proč se to nesčítá na sto procent – protože například neukazujeme detailní rozklad okolo, abychom nezvyšovali šum a zobrazovali jen top dva faktory.

Tento problém se snažíme řešit iteracemi s klienty a různými návrhy redesignu. Myslím, že spíše než o analytiku jde o storytelling a informační design. Pracujeme úzce s UX oddělením od začátku vývoje, máme designové skupiny s klienty, kde jim ukazujeme různé návrhy.

V současné chvíli vypadá naše řešení tak, že už například procenta nejsou přímo znázorněna, ale jsou schována za tooltipem. Když vidíš label „high“, můžeš si u něj najít vysvětlení. Už jen toto malé ergonomické vylepšení výrazně snižuje kognitivní zátěž byznysových uživatelů, kteří by jinak museli procházet deset čísel najednou.

Přijde mi fascinující, že pokračujete ve filozofii automatizace business intelligence. Vzhledem k tvému výzkumu, který někdy zasahuje až do matematiky, filozofie a produktového managementu, jak se ti posouvá pohled na business intelligence? Zdá se, že řešíte mnohem hlubší analytické otázky než kdekoliv jinde. Jinde se často bavíme spíš o aplikacích. Posunulo se to někam? Například ve smyslu, že prezentace a poslední krok je nyní mnohem důležitější, než jsi si myslel před pěti lety?

Určitě ano. Asi nejsem schopen ohodnotit obecný vývoj v oboru augmented analytics. Když jsme s tím začínali ve Strajcích, vlastně teprve vznikalo celé odvětví. Gartner či Blistek nás pojmenovali a existuje spousta historických zajímavostí kolem toho.

V kontextu naší firmy máme občas problém, kdy jsme při prodeji toho produktu byli až moc napřed, jeli jsme několik kroků před uživatele. Neříkám to jako kritiku, že jsme „pozadu“, ale nabízeli jsme řešení na problém, který klient často ani neviděl nebo jej nevnímal jako problém.

Možná jsme nezvládli dostatečně vysvětlit, proč je to problém. Sám na sobě vidím, že člověk potřebuje několikrát pochopit, proč je například automatizace dobrá. Může si říct „Udělám to ještě ručně, abych měl jistotu“.

Je to jako navigace v Google Maps – když jsem s nimi začínal, tak jsem raději navigoval na známá místa, nebo si po zadání nového cíle vždycky raději zkontroloval mapu, zda nejdu správným směrem. To je validace, kterou člověk potřebuje – až potom začne aplikaci důvěřovat.

V našem kontextu to funguje tak, že nabízíme například možnost podívat se do zdrojových dat. Každý insight obsahuje odkaz na data, která jsme využili. Je tam replikace daného datasetu a analytik si to může ověřit.

Jak pomáháte zákazníkům s onboardováním? Oni si kliknou náš plug-in, integrační partner pomůže s instalací, ale přetrvává určitá nedůvěra zákazníků, například HRD, kteří nejsou zvyklí takto pracovat analyticky. Máte business analytiky, integrační partnery, kteří s nimi spolupracují?

Snažíme se pomoci, i když nejsme stoprocentní. V aplikaci máme například walkthrough – průvodce, který uživatele provede první zapnutím, popíše jednotlivé části a vysvětlí význam. Pro klienty pořádáme office hours a máme komunitu našich zákazníků. Každé dva až tři měsíce se konají setkání, kde představujeme nové funkce, připomínáme stávající možnosti a klienti mezi sebou navzájem vystupují.

Z našich 600 klientů chodí zhruba 250 až 300, takže komunita je živá a je fajn to sledovat. Nicméně věřím, že bychom mohli fungovat lépe. Například by bylo velmi přínosné, kdybychom mohli poslat jednoho z našich business analytiků na týden či dva přímo do firmy během implementace. To by pomohlo klientům pochopit, jak s produktem pracovat rychleji a efektivněji.

Co se týče HR, je to často oddělení, které je datově spíše agnostické, zpracovává své tabulky, ale nemusí řešit data komplexně. Jaká je tvoje zkušenost s mírou jejich analytické zralosti?

Míra zralosti se hodně liší. V průměru jsou HR oddělení méně vyspělé než třeba finanční oddělení, které analytiku začalo řešit dříve a má k ní větší potřebu. Většina HR týmů má méně času a zkušeností s analyzováním dat.

Na druhou stranu existují firmy, které mají velmi vyspělé HR analytické týmy – i deset lidí – a tito lidé chtějí s námi často diskutovat o modelech, metodách, heterokonalitě a podobně. Tam vidíš, že umí a chápu tyto koncepty, ale často se to míjí s hlavním konkrétním případem užití klienta.

Nicméně většina firem je ráda, že jim nabídneme řešení, které jim alespoň částečně automatizuje část práce. Kromě generovaných insightů, které jsou nevyzpytatelné a dynamické (protože člověk nikdy přesně neví, co dostane), také poskytujeme základní reportingové pohledy.

Ke všem insightům máme KPI a grafy nebo vizualizace, aby člověk, který není ještě tak daleko, dokázal navázat – získal nějaký základní přehled a porozumění.

Potřebuje vůbec zjistit, jaká je atraktivita celé firmy, aby tam našel i toto.

Toto je klasický korporátní scénář. Když někomu přijdete a tam už je hodně angažovaný tým, který je zvyklý si to dělat sám, stává se, že řeknou: „My to nechceme, my si to radši uděláme sami,“ nebo si radši vezmou vaše řešení. To se stává také.

Myslím si, že se nám to stávalo především ve Stredis, když jsme se snažili provozovat (něco), než se to stává zde. Nevím přesně proč, ale myslím si, že ve Stredis to bylo tím, že naše kontakty byly často analytici, kteří jsou samozřejmě tam trochu v dilemě, což je trochu nešťastné, protože to je jenom nástroj, který jim něco automatizuje. Je to prostě nějaká bedlička, která jim něco vyhodí. Konečně došlo i na datové a technologické lidi, kteří se bojí technologií, že je nahradí.

Ještě jenom od datového podcastu – na to se těším. Zpátky k tomuto tématu. Tam je taková rezistence, že je to nějaká firma, která má nahradit mou práci, což není pravda. My neděláme toto. S tím jsme měli velký problém, teď už ne tak velký. Myslím si, že je to způsobeno také tím, že sales force je velmi silná, a zároveň jsme jedním z dalších produktů, který všichni klienti, co jdou, jsou víceméně hrozně spokojení, protože má vysoký satisfaction rate. Takže samozřejmě salesáci ví, s kým se bavit.

Náš primární uživatel je obchodní člověk: HR business partner, nebo třeba generální manažer, viceprezident něčeho, nejsou to analytici.

Tak jo, ukončíme ta business témata. Možná na chviličku – jaký používáte technologický stack?

Asi zklamu všechny, kdo očekávají nějaký bombastický technologický stack, ale pro nás je to v podstatě základní Python se streamem. Engine je Python kód, ve kterém ty věci píšou. Píšou to přímo do produkce, takže já používám Python jenom na prototyp, ale potom lidi komitují přímo do produkce.

Používáme React, který je napsaný na frontendu, Java a Kotlin na backend, orkestraci, instalační nástroj. A vše končí v nějakém Docker image, který se buildí a posílá každý týden klientům.

Super, děkujeme. Naše poslední otázka: Co tě teď čeká? Jaká je další hora, kterou zdoláváš tady v pražském Workday? Na co se těšíš?

Hodně se těším na další use case. Bylo velmi zábavné ve Stredis hrát si na hraně mezi generickým nástrojem a jeho aplikací na konkrétní různé use case.

Poslední čtyři roky jsme prakticky řešili pouze HR data, protože to je většina businessu Workday. A tím, že jsme začali dělat HR use case, máme najednou přístup k více než osmi tisícům klientům Workday, kteří mají nasazený Workday na HR data. To dává smysl.

Ale Workday není jenom HR data. Snaží se také hodně expandovat do finančního prostoru, což je strategie firmy pro další růst. Pro nás to znamená trochu se přiblížit těmto finančním use case.

Máme rozjeté několik POC, například aplikaci našich algoritmů na účetnictví, jak urychlit proces závěrky, nebo trochu zautomatizovat hraní s Excelem. Je to úplně nová doména, stejná technologie.

Je to další důkaz naší práce, že technologie je natolik obecná, že dokáže obsáhnout i úplně jiné use case, a že by zvládla i český účetní systém. Věřím, že ano.

A možná poslední otázka na závěr: Kovářova kobyla chodí bosa? Používáte Workday sami na sebe, nebo People Analytics?

Ano, kovářova kobyla chodí ve Workday potkách, nebo pod kováhy (pozn. metafora).

Workday vždy ve všem, co dělá, vede všechny produkty nejprve na sobě. Takže People Analytics jsme začali vyvíjet na datech Workday, stejně jako další POC. Účetnictví máme na datech Workday a tam to začíná ladit.

A co vám Workday říká ohledně náboru na pražské pobočce?

Workday nám říká, že máme ještě nabírat. Máme teď otevřenou pozici Data Scientist, takže pokud někoho baví nebo by chtěl pracovat na tom, o čem jsme se právě bavili, je to vhodná příležitost.

Nabíráme také backend vývojáře. Když člověk zadá „Workday Prague careers“, rozhodně mu to vyskočí. Nebojte se nám napsat nebo si s námi popovídat.

Držíme palce.

Mockrát děkujeme za podrobný rozhovor a vysvětlení toho, co Workday v Praze úžasného dělá.

Děkuji za poslech, taky díky.

Moc děkuji za pozvání, za příležitost a děkuji všem posluchačům, případným zájemcům. Děkuji, že jste doposlouchali Data Talk až sem.

Jak se vám tato epizoda líbila? Co byste na našem podcastu zlepšili? Koho pozvat příště? Dejte mi prosím vědět, co si myslíte.

Můžete mi to říct osobně na příštím Data Mesh Meetupu, nebo hned teď na mail jirka-datatalk.cz.

A pokud se vám tato epizoda líbila, doporučte ji dále, klikněte na srdíčka, na hvězdičky, dejte subscribe, aby nám svítily dashboardy zeleně, křivky vytvářely „hokejku“ a všichni stakeholderové schvalovali extra rozpočty.

Ještě jednou vám děkuji. Poděkování patří také mým kolegům, Nikovi a Iris, stejně jako členům našeho partnerského klubu: Big Hubu, Deep Note, Atakamě a Manitě.

Pokud máte návrhy, tipy na hosty, témata, pořádáte vlastní akce nebo byste chtěli datovou komunitu podpořit jinak, určitě mi dejte vědět.

Děkuji. Nechť vás provází data.