Podcast

Dobrý den, jsem Šimon Porhajský a rád bych vás dnes přivítal u dalšího dílu podcastu Data Talk. Mým dnešním vzácným hostem je František Pavlíček, datový analytik a product owner z CleverMaps.
Ahoj.
Ahoj, vítám všechny a děkuji za pozvání.

Františku, jsi první geoinformatik, kterého znám. Řekni mi, co tě zaujalo na geoinformatice, proč sis vybral právě toto studium a v čem se liší od běžných dat?

Ke geoinformatice jsem se dostal přes mapy. Na střední škole jsem hodně přemýšlel, kam jít, až do posledního ročníku jsem nevěděl, váhal jsem, ale geografie mě bavila a nechtěl jsem učit, takže takto vzniklo to, že jsem se nakonec přihlásil na geoinformatiku. Myslím, že jsem udělal dobře, pořád mě to baví a dodnes vlastně nevím, co bych dělal jiného, kdyby to nevyšlo.

Pojďme se podívat na konkrétní věci. Mně to přijde jako divnost, tobě jako samozřejmost. Jsem původem bioinformatik, takže vůbec nevím, co je to GIS. Jak se geodata liší od obyčejných dat?

No, až tak moc ne, ale mají prostorovou složku, tedy souřadnice. Tyto souřadnice jsou často trochu skryté, protože často se říkalo, že 80 % dat má nějakou prostorovou složku, i když dnes už se to trochu zpochybňuje. Přesto mnoho věcí, které jsou dnes reprezentovány daty, třeba i v našem oboru – například prodeje – se vždy uskuteční na nějakém místě. Klient někde bydlí, někam jede, produkt někam putuje. Prostorovou složku tak lze najít téměř všude. A právě s tím v GISu pracujeme – snažíme se najít souvislosti a ideálně z toho získat informace, které uživatele zajímají.

Prostorová složka má i síťový charakter, nejde jen o bod A, ale o trasu z bodu A do bodu B. Třeba pokud je něco vedle elektrárny, může mít horší dostupnost pekařství?

Přesně tak, to jsou ty souvislosti, kdy bereme různé prvky vedle sebe. Nekoukáme na ně jako na řádky v tabulce, ale v mapě, zkoumáme vzdálenosti a potenciální závislosti.

Zemědělství je prý jedno z míst, kde se geoinformatika začínala.

Ano, po škole nebo už během ní jsem začal spolupracovat se zemědělskou firmou, kde se dá dat užít hodně. Tehdy vůbec neměli databázi pozemků ani půdních bloků – což jsou zjednodušeně řečeno pole, na kterých hospodaří. Měli starou mapovou prohlížečku, kde se mohli koukat, kde hospodaří, ale nebyla spolehlivá.
Můj úkol byl to dát dohromady a vytvořit datovou bázi, kde by se dalo sledovat, které pozemky podnik vlastní a kde hospodaří. Pak jsme pracovali i s historickým vývojem, tedy s prostorovou i časovou složkou – aby bylo možné sledovat, jak se podnikání vyvíjelo v čase.

[Text zde pokračuje, pokud si budete přát, rád opravím dále.]

Opravený text:

Rma postupně nakupuje nebo zase o ty pozemky přichází. No a po škole jsem tam vlastně nastoupil potom na fulltime, kde už jsem dostal tu aplikaci plně pod svou správu a začali jsme potom dělat další věci, jako dálkový průzkum země. Začali jsme vlastně vzorkovat půdu, ať už sondama, nebo potom jsme létali s dronem a snímkovali pole a připravovali data pro precizní zemědělství, pro traktory, které hnojí na poli. Takže využití bylo široké, mně se líbilo hlavně to, že jsem neseděl jenom u počítače 40 hodin týdně, ale třeba jeden, dva dny v týdnu jsem fakt byl venku – ať už právě to vzorkování, vytyčování, různé měření, nebo lítání s dronem, to všechno bylo fajn.

A to je všechno součástí té precizní zemědělství?
Jo, v podstatě to je precizní zemědělství – jednodušeně něco, co pomáhá zemědělcům optimalizovat náklady. Když to uvedu na jednoduchém příkladu, tak třeba 30hektarové pole je relativně velké, a dřív traktor prostě jezdil a všude pohnojil stejně, to, co se tehdy považovalo za optimální. Ale díky družicovým snímkům a sondážím se ukázalo, že pole není homogenní a že někde není třeba vůbec hnojit. Díky technologiím, jako je GPS a navádění, se dnes dají data nachystat do traktorů, které hnojí jen tam, kde je to potřeba, a tam, kde ne, jedou vlastně naprázdno. Je to zjednodušeně řečeno, ale precizní zemědělství je zhruba o optimalizaci nákladů, ochraně přírody a lepším hospodaření s půdou.

Jasně, taková precizní medicína pro půdu.
V podstatě ano.

A jak ses z tohohle prostředí dostal ke Clever Maps?
Lehkou okružní cestou. Já jsem ze zemědělství utekl, protože jsem tam byl vlastně sám a cítil jsem, že bych se rád učil od někoho zkušenějšího, seniornějšího. Nebylo to o tom, že by mě ta práce nebavila, ale spíš jsem se chtěl posunout dál a využít i znalosti někoho jiného než jen Stack Overflow. Takže jsem hledal pozici, kde by se mi to mohlo podařit. Více mě bavilo vývoj mapových aplikací, tak jsem se hlásil do Clever Maps na pozici frontend vývojáře. Nevyšlo to, protože oni hledali nejseniornějšího člověka nebo náhradu nejseniornějšího člověka ve firmě, což jsem tehdy nebyl.

To bylo kdy?
To bylo asi ve třetím kvartálu 2020, tedy během covidu. Myslel jsem, že to nevyjde, ale asi o měsíc později se mi ozvali s nabídkou do datového týmu, jestli nechci zkusit pracovat s daty místo vývoje. Nějaké zkušenosti jsem s daty měl, tak jsem si řekl, proč ne – byl jsem po škole a hledal práci, tak jsem to zkusil a uvidím…

Jistě, tady je opravený text:

Víme, co to udělá. A tam teda, když ještě zůstaneme u tebe před tím, než se přesuneme ke Clever Maps, stal ses product ownerem. Jak jsi řekl, jak ta cesta změnila? Jak se ti to líbí?

No, cesta… já jsem s tím upřímně nepočítal, neplánoval jsem to, ale obecně ten vývoj byl takový přirozený v tom, že z těch dat jsme se vlastně postupně, aspoň někteří členové našeho professional services týmu, posouvali víc ke konzultantské práci. Vlastně se víc rozpadla ta role, řekněme, data analytika na víc částí – více konzultanta a data inženýra. A já jsem vlastně díky tomu, že asi někdo ve firmě vyhodnotil, že umím mluvit a bavit se s klienty, byl nominován na tuhle roli konzultanta. Mně to upřímně nevadilo úplně, takže jsem se posunul tam.

No a vlastně teď v posledním čtvrt roce, nebo možná půl roce, když jsme začali pracovat na dalším produktu, kterého jsem byl součástí, a v podstatě jsem tam nejdřív měl zodpovědnost za tu datovou část, tak to potom vykrystalizovalo tak, že jsem převzal vedení celého produktu.

Takže teď vedeš lidi, frontenťáky, datajáky?

Teď v podstatě vedu hlavně frontend a dataře a postupně samozřejmě už vidíme, jak to celé roste – ten produkt – že se tam určitě bude muset zapojit i část back-endu a samozřejmě jsou tam i markeťáci a další lidi.

To jsou dvě kultury, co se tak často nepotkají. Jaké jsou hlavní jablka sváru mezi frontenťáky a datajáky, jestli jsi to tak vypozoroval? Neříkám, že tvůj tým má jablka sváru, samozřejmě.

Jo, ale určitě tam jsou. Typicky se to teď nejlíp dá ukázat na tom, že jsme s produktem začali v našem datovém professional services týmu, kde jsme vlastně hledali nástroj, kterým data budeme prezentovat, a vybírali jsme mezi Evidence a Hexem. Evidence je dá se říct přístup zaměřený na BI jazyk, Hex je více založený na Jupyter notebookcích a Pythonu.

Nakonec jsme víceméně vybrali Evidence, ale ne po nějaké zdlouhavé analýze, spíš proto, že se nám v tu chvíli na produktu pracovalo líp a šlo nám to rychleji. Takže jsme to začali dělat v Evidence. Pak ten produkt převzal frontendový tým a z jejich strany se ozvaly hlasy typu „proč tady tohle, když v tom se vůbec nic nedá psát a je to otravný“. A tam určitě svár vznikl. Jde vidět, že dataři přistupují k tomu jinak. Pro nás bylo důležité co nejrychleji dostat ven výsledek analýz a výpočtů, takže když jsme našli produkt, který to umožňoval, moc jsme neřešili, jak dobře se to píše nebo co všechno v tom jde udělat. Naopak frontendáci jsou hodně zaměření na to, aby se jim v tom dobře psalo a aby to bylo modulární.

Jasně, pro nás je frontend vlastně zcela oddělitelný od toho, co děláme, a akorát ho používáme jako produkt.

Je to tak, no. A pro nás dlouho tou prezentační vrstvou byla hlavně mapa. A teď v podstatě…

Pokud chceš, mohu text ještě trochu více upravit tak, aby byl formálnější nebo více mluvený, stačí říct.

Tady je opravený text:

Na začátku v tom produktu téměř žádná mapa nebyla, teď už tam teda je, ale šlo hlavně o prezentaci dat v nějakých grafech. No a jak říkám, my jsme prostě chtěli co nejrychleji ta data odprezentovat nějakým relativně srozumitelným způsobem a vlastně v tomhle nám to šlo jednoduše, přišlo nám to easy, tak jsme to zvolili. A pak jsme si teda poslechli, že možná to nebylo úplně nejlepší rozhodnutí.

Pojďme se teda bavit přímo o Clever Maps. Co dělají, čím je to těžké? Clever Maps vlastně postihují část geoinformatiky, která se nazývá location intelligence. Mně se na tohle, co dělá Clever Maps a co vlastně dělám v práci, vždycky ptají rodiče, babičky a tak, a odpověď jsem pořád úplně nevycizeloval.

Jaká je ta odpověď pro babičky? Pro babičky je to, že radíme firmám, kde mají být, kde mají otevírat své podniky — ať už je to pobočka, nebo teďka říkám babičce takovou tu krabici, kde si zatím nevyzvedáváš balíčky, ale ostatní ano, tak to babička celkem chápe. Říkám jí, že radíme firmám, jestli ji postavit tady před tím domem, nebo o 200 metrů dál před jiným domem.

A čím bys to zkomplikoval pro naše posluchače? No, je to vlastně široký pojem, protože to není jenom o tom poradit. My se pak samozřejmě začneme s těmi firmami bavit i o nějaké strategii a o tom, čeho chtějí dosáhnout, kolik poboček chtějí mít, jestli chtějí být blíž u konkurence, nebo dál. To se třeba dobře ukazuje na fastfoodech, kde se často snaží být vedle sebe a nepotřebují být tam, kde konkurence není, protože zákazník tam stejně přijde a vybere si svého oblíbeného. Všichni chtějí být na nejvíce frekventovaných místech a moc neřeší, jestli jsou daleko nebo blízko.

Takže těch věcí, o kterých se dá bavit, a těch závislostí, které se dají hledat, je hodně.

Jasně, a takhle to trošku zní, že jste jen geokonzultanti, ale máte i produkty, že? Jo, vlastně máme platformu analytickou, kde klientům buď chystáme projekty my, nebo si je mohou připravit sami. Mohou si od nás vzít jen data, nebo pokud už mají geodata u sebe ve firmě, tak si mohou vzít jen platformu a postavit si na ní svůj produkt a analýzu dělat sami.

Není to tedy tak, že bychom my rozhodovali o tom, že ten doručovací box nebo ta pobočka má být tady a ne tam, ale spíš o tom, že klientům dodáme podklady a dáme jim je v nějaké ucelené formě, ve které si mohou sami klikat a dělat si rozhodnutí.

Jaký jsou typičtí klienti? Nejčastěji retail, tedy někdo, kdo má pobočky. Tam už úplně nerozlišuji – jsou to banky, pojišťovny, ale mohou to být i menší maloobchody typu pekárna, řeznictví, kavárna, něco takového, co najdeme v městě. Teď se hodně rozmohly i doručovací boxy.

Pokud bys chtěl, mohu pomoci i s další úpravou stylu nebo formátování.

Jasně, tady je opravený text s plynulejším a spisovnějším vyjadřováním:

Takže to není jako typická pobočka, ale je to také něco, co se odehrává v prostoru, takže s tím si dokážeme docela dobře poradit. Ještě než se zeptám na další otázky ohledně klientů, chci se zeptat na tu analytickou platformu. Jak to vypadá, na čem je založená, jaký je stack? Jo, ten stack…

Je založený hlavně na Postgresu. Frontend dříve byl psaný v Angularu, teď se překlápí do Reactu. Pro mě jako geoinformatika je vždy klíčová mapa, nebo vlastně to je to, na co se koukám jako první. Mapa běží na Leafletu a v rámci migrace do Reactu přecházíme i na MapLibre, což je novější knihovna, postavená na vektorových dlaždicích místo na rastrových. To bych řekl, že jsou asi ty hlavní věci, které bych zmínil. Na pozadí tedy běží hlavně ten Postgres.

Když jsem datový analytik v Quaver Maps, potřebuji znát SQL? Jo, bez toho se asi člověk neobejde.

A ovládáte hlavně SQL, nebo používáte i další metody? My jako dataři píšeme hlavně SQL a Python. Děláme to tak, že klientům připravujeme data do platformy, která je pak vlastně interaktivní, tedy „klikací“. I když se teď bavíme o tom, že některé konkurenční platformy umožňují klientům přímo psát SQL dotazy nad daty, v praxi klient spíš kliká v platformě. Například se dá zeptat, kolik poboček konkurence je v desetiminutové docházkové vzdálenosti od nějakého bodu. Pokud klient položí takový dotaz, využíváme Mapbox k určení této spádové oblasti a potom se dotaz konvertuje do SQL, konkrétně prostorový dotaz do Postgres databáze, a výsledky se vrátí klientovi.

Takže Mapbox si mám představit jako nějaký metriku? Ne, Mapbox je firma, je to vlastně teď asi lídr v oblasti mapování. Zakladatel Leafletu – což byla a pořád je velmi populární mapová knihovna – tam teď už nějakou dobu pracuje. Mapbox nabízí širokou škálu technologií, od vektorových dlaždic, přes routingové služby, geokódování, až po výpočet isochron. Mají třeba třicet různých API, na která se dá připojit, nechci je tu všechny vyjmenovávat, ale…

Lze tam udělat třeba isochronu? Jo, isochrona je v podstatě linie, která ukazuje, jak daleko nebo kam se člověk dostane třeba za 10 minut. Když kliknete na nějaký bod a zvolíte například desetiminutovou docházkovou vzdálenost, vykreslí se linka, která ohraničuje oblast, kam se dostanete za těch 10 minut.

Dobře, a ještě se zeptám: ten Postgres, který používáte, má nějaké geo-rozšíření? Jo, klíčová extenze je PostGIS, což je částečně důvod, proč mnoho geoinformatiků stále používá právě Postgres.

Pokud chceš, můžu text ještě více upravit nebo zkrátit.

Tady je opravený a plynulejší text:

U nás se pracuje s PostGIS, protože je to asi nejsilnější prostorová extenze. Myslím si také, že je i nejstarší a že lidi jsou na ni hodně zvyklí. Na větší výpočty, které často na této platformě potřebujeme, je Postgres pořád nejlepší řešení. Znamená to, že SQL, které píšete, je hodně jiné než to, co by znal například někdo, kdo pracuje s jednodušším SQL? Ten rohlík se opravuje i s PostGISem, ale… upřímně nevím, protože jsem nikdy nepsal čistě datové SQL, většinou jsem pracoval s prostorovými věcmi. Určitě jsou tam nějaké prostorové funkce navíc. Když například joinujeme dvě tabulky, často nepoužíváme join na základě společného sloupce nebo cizího klíče, ale právě prostorový join – například „vrátí mi body, které leží v Moravskoslezském kraji“. To je asi to nejčastější, co je jiné – tabulky propojujeme pomocí prostorových závislostí místo klasických klíčů.

Jasně. Pojďme se tedy vrátit k těm klientům, pro které vlastně tento složitý geografický systém píšete. Často jsou to klienti, kteří řeší konkrétní problémy, například s umístěním pobočkové sítě nebo podobně.

Napadá mě například Generali, která měla případ, kdy se spojovala s Českou pojišťovnou a potřebovala sfúzovat dvě sítě poboček. Tehdy měli, myslím, přes 800 poboček a snažili se snížit počet na přibližně 500. Jejich cílem bylo sfúzovat sítě tak, aby nedošlo ke ztrátě pokrytí obyvatel a zároveň aby snížili počet poboček o 30–35 %, jak vycházelo z analýzy. Počítali jsme tedy analýzu, které pobočky ideálně zavřít, aby pokrytí zůstalo zachováno. Pracovalo se přitom například s desetiminutovou až patnáctiminutovou docházkovou vzdáleností. Oni také pracují s dojezdovými vzdálenostmi autem. Hledali jsme tedy, které pobočky zavřít tak, aby se pokrytí nesnížilo. Šlo o jednorázovou analýzu, kdy jsme vraceli výsledky kolem 300 poboček. Nyní mají u nás nasazený i pohled, kde si mohou označit pobočky, které chtějí potenciálně zavřít, a systém jim on the fly počítá, jak se mění pokrytí. Hned vidí, že když zavřou těchto deset poboček, přichází o půl procenta pokrytí obyvatel České republiky, ale zároveň zjistí, že lidé v dotčených oblastech budou mít nejbližší pobočku místo pěti minut autem za patnáct minut. To pro ně znamená, že jsou s tím schopni pracovat a rozhodnout se pro zavření.

Jak velký musí být klient, aby pro něj byly CleverMaps zajímavé? Jak moc sofistikovaní musí být datoví inženýři, aby rozuměli tomu, co jim říkáme? Skvělá otázka. Nejčastěji pracujeme s velkými firmami, ale není to stoprocentně nutné. Teoreticky v té firmě nemusí ani být datový inženýr…

Pokud chcete, mohu text doplnit nebo upravit dál, dejte vědět.

Jasné, tady je opravený text:

On má jasné zadání, takže my tu zakázku jsme schopni u nás odbavit a dát jim rozhodovací podklady. A to je i naším cílem. My nechceme nikdy rozhodovat za firmy, spíš jim chceme dát nástroje, aby mohly rozhodnutí udělat zodpovědně samy. Pravdou je, že odbavujeme hlavně větší klienty s většími sítěmi, ale už teď vymýšlíme i nástroj, který bude přístupnější menším firmám. Z mého pohledu tam není potřeba téměř žádná znalost a i bez ní jsme schopni klientovi vrátit zajímavé podklady k rozhodnutí, na jejichž základě může rozhodnout.

O jaký produkt jde? Produkt se jmenuje MarketSpot, vyvíjíme ho ve spolupráci s T-Mobilem a Mastercardem. Mastercard a T-Mobile vstupují jako datoví partneři, my v našem relativně malém týmu provádíme implementaci a navíc dodáváme naše prostorová data, respektive data, která zpracováváme. Jsou to hlavně body zájmu, kde lze například zjistit, kde leží konkurence. Dále máme zastávky hromadné dopravy s frekvencí dopravy na nich, silniční dopravu, počet rezidentů a kde lidé bydlí a jak se to vyvíjí v čase.

T-Mobile přispívá mobilitními daty, která zobrazují, jak se lidé během dne pohybují, jak se mění provoz, kde a kolik lidí je, kolik lidí odjíždí ze sídlištních oblastí během dne a tak dále. Mastercard dodává data o transakčním chování lidí – můžeme vidět, kde lidé platí, za co, kolik a jak často. Jsou tam souhrny plateb za určité období. Takže je to vlastně taková „krev“, jak proudí tepny ekonomiky.

Obvykle právě to firmy zajímá – vyčíslit potenciál na určitém místě, a ideálně i v určitém časovém horizontu. Například bar zajímá jiný čas než pekárnu. To je cíl, ke kterému směřujeme a co se snažíme firmám nabídnout, aby si na základě dat mohly vyhodnotit, které místo je pro jejich byznys lepší.

Jaké firmy máte na mysli? Jsou to firmy, které už mají tři lokace a rozhodují se o čtvrté, nebo je to i pro někoho, kdo se právě teď rozhoduje, kde by…

Ano, obojí je možné. V MarketSpotu máme dva use cases. První je, když máš dva nebo tři body, mezi kterými se chceš rozhodnout, který je lepší. Typicky jsme to už řešili s mnoha klienty, kteří přišli a měli možnost otevřít obchod na jednom místě nebo třeba o 500 metrů dál. Na místě o 500 metrů dál byl nájem třeba o 20 % nižší, ale zdálo se jim, že potenciál tam je menší, a chtěli po nás vyčíslit potenciál, aby se mohli správně rozhodnout, jestli jít do jednoho či druhého místa.

Zde je opravený text:

Takže to je ten první use case, který řešíme a který si zatím myslím, že bude ten hlavní, ale možná se pletu, to se ještě uvidí. Ten druhý use case je přesně to, co jsi říkal – že bys byl malý podnikatel, který si chce otevřít třeba pekárnu. A vlastně jediné, co víš v tu chvíli, je, že chceš otevřít pekárnu a pravděpodobně budeš vědět přibližně, kde – třeba v Praze, Olomouci nebo v nějakém jiném městě. A tady ten use case funguje tak, že si vybereš, co chceš otevřít, a my ti potom poradíme, na jaké parametry by ses měl dívat. To znamená, když budeš chtít otevírat pekárnu, řekneme ti například, že by bylo dobré, aby tam dopoledne bylo hodně lidí a aby nejbližší pekárna byla aspoň 300 metrů daleko, nebo něco podobného. Ty pak můžeš buď souhlasit s parametry, které jsme ti nabídli, nebo si zvolit například počet transakcí, které se na daném místě uskutečňují, aby to dávalo smysl.

Pak ti v analýze vrátíme jednak mapu s jednotlivými jevy a jejich rozmístěním – například kde jsou místa, která jsou aspoň 300 metrů vzdálená od jiné pekárny. Dále ti představíme syntézu všech parametrů, které sis vybral, a řekneme ti, kde vychází nejlepší místo na otevření pekárny v souhrnu těchto parametrů. Takže ta „blbuvzdornost“ pro geoignoranty, jako jsem já, spočívá v tom, že to přepočítáme na peníze nebo ukážeme na mapě, kde se vydělávají nejvíce. V podstatě vyčíslíme potenciál daného místa.

Samozřejmě, že výsledný úspěch byznysu nezávisí jen na lokalitě, ale i například na tom, jaký chléb pekárna peče a další faktory. Nicméně pokud bude pekárna otevřená na místě, kde není žádný provoz a lidé tam nechodí a neutrácí, je malá pravděpodobnost, že se bude dařit. Naším cílem je tedy pomoct lidem rozhodnout se správně, aby si byznys otevřeli tam, kde to má skutečný smysl.

Je to taky otázka investice – když otevíráš větší pobočku, investice často dosahují milionů, někdy i desítek milionů korun. Proto podle mě dává velký smysl ověřit si, jestli je to místo opravdu to správné, ještě než se do toho pustíš. To určitě.

Proč to dosud nešlo, nebo čím se tento produkt liší od toho, co Clever Maps dělal dosud? Je to hodně jiné v tom, že dříve jsme měli problémy malým podnikatelům jednoduše odpovědět. Často přišli, chtěli vyhodnotit dva či tři body, ale my pro ně neměli jednoduché řešení, protože naše vyhodnocení vycházelo ze složitých dat a ta data jsou poměrně drahá – zejména mobilitní data od T-Mobilu, kde náklady mohou dosahovat statisíců až milionů korun, v závislosti na rozsahu a požadavcích uživatele. A samozřejmě nedává smysl, když si chtějí porovnat…

Pokud chceš, mohu pomoci dokončit text.

Opravený text:

O dvě místa a utratit za data milion nebo milion a půl, to je prostě nesmysl. My jsme toho už viděli hodně, ale vlastně v tu chvíli jsme pro ty klienty neměli žádné řešení. I proto vlastně našimi klienty byly hlavně firmy s většími sítěmi, například Generali nebo Alza, kdy taková rozhodnutí, kam dát pobočku nebo doručovací box, dělají fakt na denní bázi desetkrát, padesátkrát. Tam už potom dává smysl se dívat na tu platformu, nakoupit si ta data a v podstatě je kontinuálně používat. Pokud ale mám nějaký jednorázový problém, který chci vyřešit, například chci otevřít pekařství, tak tohle jsme úplně odbavit neuměli. To se teď, doufám, mění.

Liší se ten produkt i technologicky? Liší. Liší se v tom, že jsme potřebovali reagovat na ty poptávky daleko rychleji. Je to tak, že jakmile uživatel poptávku odešle, my ji začínáme zpracovávat téměř ihned. Nedávalo ani smysl nasazovat tak velký a výkonný stroj, jako běží na pozadí analytické platformy, na něco takového. Naopak potřebujeme reagovat okamžitě po odeslání poptávky, proto tam navíc používáme orchestrátor, který celý proces řídí. Používáme také novější technologie jako DuckDB a DBT, abychom byli schopni zpracovávat celé datové workflow i po částech, pokud je to potřeba.

Produkt se hodně liší i v prezentační vrstvě; na konci máme relativně jednoduchý report, není potřeba žádný složitý frontendový nástroj na vykreslování. Ve frontendu jsme nakonec použili Evidence, což je relativně nový BI nástroj, který teď více méně zkoušíme a zatím to vypadá, že bude fungovat dobře.

DuckDB používáte tak, že běží na jednom místě, nebo ho distribuujete?
Zatím běží na jednom konkrétním místě. V DuckDB běží ale jen část, zbytek stále běží na Postgresu — měl jsem to zmínit dřív. Je to proto, že prostorové operace jsou v Postgresu zatím nejefektivnější. S DuckDB jsme se setkali s tím, že tam stále nejsou prostorové indexy a nedají se tam prostorové výpočty efektivně počítat, což se, myslím, v budoucnu určitě změní, ale momentálně to tak není. Z těchto důvodů kvůli rychlosti výpočtů běží hlavní část stále na Postgresu. Na DuckDB máme aktualizace dat, které nejsou časově náročné, a můžeme je provádět mimo odbavování klientů.

Zajímavé. Takže ty aktualizace v DuckDB…
Ano, chápu to tak, že do DuckDB se špatně zapisuje, zato se z něj skvěle čte. Aktualizace tam tedy nejsou ideální, ale to, že jednou denně například T-Mobile dodá nová mobilitní data ve formě DuckDB, je zrovna náš případ?
Právěže ne tak často a díky tomu se nám data v DuckDB líp spravují a píšou než v Postgresu nebo klasickém SQL.

Pokud chcete nějaké konkrétní části ještě upravit stylisticky nebo jazykově více, dejte vědět.

Zde je opravený text s lepší strukturou, interpunkcí a stylistikou:

Ale a plus je tam i to fajn spojení s DBT, že vlastně ta integrace je fakt příjemná. Nejvíc tam ale narážíme na absenci těch prostorových indexů. Ten výpočet… My chceme toho klienta v úhozovkách odbavit co nejrychleji, a tam nejdeme tolik po technologii, nebo po tom, jak nám to je pohodlné, ale spíš prostě jdeme po tom, co je rychlejší.

A zmínil jsi ještě orchestrátor? Jo, orchestrátorem je Prefect. Já se přiznám, že to řeší víc data inženýři. Jak jsem mluvil na začátku o tom, že jsem se ze světa trochu vzdálil, tak to vybírali čistě oni, takže by byli víc poučení o tom, proč. Já jsem rád, že to funguje, a nekoukám na to.

V pohodě, chápu, že tvůj stack je teď hlavně Jira. Je to tak, no.

Takže ten hlavní průlom je v tom, že je to rychlejší a byznysově přístupnější menším novým zákazníkům? Jo, víceméně ano. Hodně pracujeme i s tím, že se snažíme data prezentovat srozumitelnější a jednodušší formou. Obecně třeba z dat Mastercardu přístup nemáme ke všem jednotlivým transakcím, je to vlastně agregované na dny a rozdělené do kategorií jako potraviny, specializované prodejny, jídlo atd. Takže tam je nějaká anonimizace a my jednotlivé transakce nevidíme, stejně jako u T-Mobile nevidíme jednotlivé záznamy.

Ale pořád z těch dat lze vytáhnout spoustu informací a my jsme vždycky měli touhu si s nimi hrát a vymýšlet, co klientovi ještě dodat. Na druhé straně jsme často naráželi na to, že klient chtěl jednodušší řešení. Například do analytické platformy jsme mu vlastně nabídli…

Tady máme pět různých pohledů na to, jak se s daty dá pracovat, na co všechno se může koukat a nad tím vším rozhodovat. Teď trochu zkoušíme přístup, kdy hodně toho rozhodujeme za klienta a hodně zjednodušujeme. Sami si uvědomujeme, že prezentujeme jen velmi malou část dat, a rádi bychom se do nich ponořili hlouběji a vymysleli další možnosti, ale chceme to přístupné hlavně menším podnikatelům – někomu, kdo si třeba chce otevřít pekárnu nebo kadeřnictví a chce se rozhodovat na základě dat, které mu dávají smysl, ale nemá kapacitu řešit složité analýzy a hrabat se v datech od A do Z.

V tuhle chvíli přicházíme k otázkám ohledně jazykových modelů. Chtěl jsem se zeptat – plánujete do budoucna nějakou integraci jazykového modelu, který by mohl být klientem skrze nějaké specifikace OpenAI? Na rozdíl od lidí jazykové modely nemají představu o tom, jak jde krev tepnami velkoměsta, a právě pro budoucí agenty by to mohlo být zajímavé. Máte to nějak v plánu?

Zatím ne, nicméně už se o tom ve firmě bavíme, takže si myslím, že to zatím nemáme v roadmapě, ale úplně to nevylučujeme.

Pokud chceš, můžu text ještě více zpřehlednit nebo upravit podle konkrétního zaměření.

Tady je opravený text:

Vůbec. Myslím si, že to může být cesta, kterou se vydáme. A teď ten hlavní fokus samozřejmě byl na to obsloužit ty klienty. Jasně, tohle by bylo spíš, když bych byl nějaký edgy klient, co zadá novému modelu OpenAI: „Přijď mi na to, jako třeba otevřít si pekárnu." Ale samozřejmě to je sci-fi, nebo ne úplně sci-fi? Já si nemyslím, že to je úplně sci-fi, a my vlastně i v té analytické platformě teď implementujeme chatbot, který v podstatě něco podobného by teoreticky mohl dělat, byť on bude zatím asi trochu jednodušší. Ale myslím si, že tohle je ten směr, kterým se to bude vydávat.

A klidně se vlastně může stát, že v podstatě to, co my dnes odbavujeme tím, že klient přijde, vyplní nějakou poptávku a my mu vracíme nějaký výstup, tak se časem může překlopit do něčeho takového, že tu poptávku fakt vyplní stylem: „Řekni mi, kde bych měl otevřít pekárnu“ a my mu prostě takhle budeme vracet výsledek.

Takže ta interpretace výsledků a přijetí objednávky je to, kam teďka upínáte svoji relevanci?
Jo, tam si myslím, že je asi největší prostor teď, protože i když jsme testovali první verzi MarketSpotu s nějakými klienty, pořád nám opakovali, že je to hrozně složité, že se v tom vůbec nevyznají. Říkali nám: „Řekněte nám,“ v podstatě klienti po nás často chtějí, „řekněte nám, jestli je to místo dobré nebo špatné.“ A my krčíme rameny a říkáme si: „No jo, ale z jakého pohledu dobré nebo špatné? To se nedá tak jednoduše říct.“

Ale to je vlastně krátce to, co klienti chtějí, a ty LLM modely na tohle můžou fungovat docela dobře. My teď jsme ve fázi testování právě interpretace těch výsledků, že bychom kromě toho nebo v rámci toho reportu, který předáváme, nabídli i takovou interpretaci, kde klient nemusel projít celý report, ale nahoře by si přečetl: „Hele, tohle místo je dobré, protože… a potenciální rizika jsou XY.“

A to je nakonec i to, k čemu jsme se v tom reportu dostali, že nahoře je jedno číslo – 6,5 z 10, a to je vlastně to, co po nás všichni chtěli – nějaké hodnocení. Ale pořád, abych se dozvěděl, v čem je to místo dobré a v čem je špatné, musím scrollovat a konzumovat obsah.

Potenciál – a už z toho testování jasně vyplývá, že to půjde udělat – proto s tím počítáme, že tam bude taková interpretace. Takže teoreticky pak tomu klientovi vedle hodnocení 6,5 napíšeme: „Hele, tady je vysoký počet rezidentů, dobrá mobilita přes den, ale skoro nikdo tu nic nekupuje, takže pozor na to, musíš to udělat atraktivní, aby si tam někdo něco koupil.“ Myslím si, že tímto směrem to směřuje.

Paráda. MarketSpot je tedy velmi nový produkt, chápu to správně?
Jo, MarketSpot je momentálně, kdy natáčíme, v podstatě takový starý produkt, ale my jsme sami trochu napnutí, co to všechno způsobí a jaké klienty bude schopné přilákat.

Pokud chcete, můžu text ještě upravit víc do formálního stylu nebo dodat interpunkci podle potřeby.

Tady je opravený text s úpravami pro lepší srozumitelnost, gramatiku a formátování:

To je nové, je to pro nás, a myslím si, i hezké vystoupení. Nechci říct, že úplně z komfortní zóny, ale vlastně jsme dlouho chtěli klienty obsluhovat právě těmi analýzami a složitějšími věcmi, chtěli jsme, aby si v tom klikali a hledali informace sami. A teď si myslím, že trochu ustupujeme od tohoto modelu a spíš jdeme naproti klientům a snažíme se jim dodat — to je světlo, místo dobrý nebo špatný v uvozovkách.

Super. Já se teda chci ještě zeptat, tohle je ten produkt, který začal být v rukou Produkt Ownerů. Jak se to vyvíjelo?

No, vyvíjelo se to tak, že jsem byl na začátku zodpovědný jen za tu datovou část a spolupracoval jsem s kolegy, abychom správně dělali výpočet. K tomu jsme si založili takový supershelmostroj, který jsme pak nazvali Matilda, takže jsme pracovali spolu na tom, aby Matilda dělala to, co jsme po ní chtěli.

Proč Matilda?

To vymyslel kolega, já nevím přesně, Matilda byla nějaká bojová loď nebo tank, nevím přesně, jestli z druhé světové války nebo kdy, ale kolega to přetavil ve stylu, že je to taková datová šelma a datový stroj. Když jsme hledali nějaký název pro náš vznešený stroj, dali jsme mu tedy název Matilda.

Matilda je zajímavá v tom, že kromě lokality, kterou uživatel hodnotí, vždycky řešíme i srovnání s konkurencí, kterou si uživatel vybere. Takže i když uživatel zadá poptávku na jedno nebo dvě místa, hodnotíme i dvě stě, tři sta dalších, které splňují podobné požadavky, abychom měli benchmark a mohli říct, jestli je tato lokalita z pohledu konkurence dobrá nebo špatná.

Co se týče odpovědi na otázku, jestli je lokalita dobrá nebo špatná, dlouho jsme to hledali. Často, když klienti přišli a chtěli hodnocení, vraceli jsme jim údaje jako „je zde pět tisíc rezidentů, ve špičce až osm tisíc lidí, platí tolik a tolik,“ ale oni se nás vždycky ptali: „Je to hodně nebo málo? Je to dobré nebo špatné?“ My jsme na to krčili rameny a říkali, že nevíme, protože nevíme, s čím to porovnávat.

A teď už to víme. Díky Matildě, která nehodnotí jen jeden bod, ale desítky dalších, máme s čím porovnávat a z porovnání vycházejí docela zajímavé věci.

A jak se pro tebe osobně vyvíjela role v tomhle procesu?

Trochu jsem utekl od otázky. Ne, ne, to je v pořádku, chtěl jsem se ptát dál na vývoj Matildy, to je super.

Vlastně nevím přesně, jak to popsat, ale mám pocit, že vývoj by mohl jít i rychleji a měl jsem pocit, že datová část je…

Pokud chceš, mohu text ještě rozdělit na odstavce, přepsat do formálnější nebo neformálnější podoby, případně doplnit další opravné návrhy.

Opravený text:

A předně oproti té vývojové části. Takže my jsme pak, abychom to trošku posunuli, zorganizovali ve firmě takový datový hackathon, abychom ukázali: Hele, my vlastně už tady počítáme docela zajímavé věci, ale pořád to neumíme úplně dobře prezentovat. To zvedlo takovou vlnu nadšení, která vydržela nějakou dobu. Pak, z mého pohledu, to alespoň opět upadlo do pomalejšího vývoje, kdy mi přišlo, že jsme už připravení, že už to máme všechno spočítané, tak to pojďme klientům nějak předat. Nakonec ten drive, který jsem měl, převážil a vykrystalizovalo to tak, že jsem pak začal celý ten produkt vést.

Bylo to hodně o tom, že jak produkt rostl, náš product owner, který měl na starosti i analytickou platformu, toho začínal mít hodně. Vlastně z něčeho, co bylo původně zamýšleno jako takový „side business“, se stal plnohodnotný produkt, který opravdu potřeboval řízení, a to se prostě nedalo stíhat. Takže jsme řešili, jak mu ulehčit práci. V té chvíli jsem už fakt cítil, že jsme kousek od cíle a chtěl jsem to dotáhnout. I když jsem nikdy neplánoval být product ownerem, řekl jsem si, že to zkusím a půjdeme to dokončit. Takže jsem product ownerem z entuziasmu a taky trošku z frustrace. Jo, vlastně spíš z entuziasmu, frustrace nebyla tak velká. Ten entuziasmus mi podle mě stále vydržel, protože mě to pořád baví, dává mi to smysl a chci klientům to řešení nabízet a vymýšlet.

Ale neříkám, že budu product ownerem do smrti. Už jsem zkusil vývoj, trochu dat, teď trochu produktů, a pravděpodobně skončím zase někde jinde. Mívám problém v tom, že mě baví všechno. Já to „ne“. A potřeboval bych, aby den měl 36 hodin, což zatím není možné.

Považuješ tohle pořád za součást geoinformatiky, když jsme se bavili o tom, co všechno to je?

Jo, určitě ano. Pořád je to něco v prostoru, kde vlastně radíme uživatelům nebo klientům, kde se co děje. Já geoinformatiku tak vnímám, a vlastně i Esri jako největší geoinformatickou firmu. Nevím, jestli to pořád mají, ale kdysi dávno měli heslo „The Science of Where“ – tedy „věda o tom, kde“. Myslím, že to heslo úplně sedí. Někteří si možná říkají: Hele, mapy už máme, všechno je hotové, víme, kde co je. Ale právě tam je to o tom, že my sice máme mapu a víme, kde co je, ale pořád můžeme pracovat s daty, která v sobě mají prostorovou složku, ačkoliv třeba s ní dosud nepracujeme. Na základě té prostorové složky můžeme činit rozhodnutí, se kterými těm klientům pomáháme.

Řekl bys, že Matilda je i geoinformaticky inovativní?

No, z pohledu technologie nebo z pohledu toho, co počítá? To je na tobě.

Na mě?

Z pohledu technologie si myslím, že zase až tak moc ne. My pořád používáme ten „starý“…

Tady je opravená verze textu:

Postgres, na kterém se prostě ty prostorové analýzy dělaly v uvozovkách odjakživa, nebo alespoň co si pamatuju, a dělají se tam dodnes. Z pohledu toho, co počítá, si myslím, že je zajímavé, jak jsem říkal, že vlastně hodnotíme těch bodů daleko víc než jenom ten jeden, ale uživatel toho na frontendu tak úplně nevidí. A ten výpočet je vlastně třeba něco nového i pro nás a věc, kterou po nás klienti dlouho chtěli. Vymysleli jsme totiž na pozadí docela fajn věc, která nám vlastně rozděluje republiku. Motivace byla taková, že když jsme říkali klientům, že je srovnáme s konkurencí, oni říkali: „Jo, ale když uvažuji o tom, kde otevřít pobočku banky, chci se srovnávat jen s ostatními relevantními pobočkami bank, ne těmi, které jsou někde úplně na druhé straně republiky.“ To dávalo smysl, takže jsme přemýšleli, jak k tomu přistoupit, a vymysleli jsme dělení republiky do něčeho, čemu se říká hexagonový grid, tedy šestiúhelníková mřížka. Tu mimochodem zavedla a vymyslela firma Uber, která kromě aut dělá docela dobrá IT řešení.

Tento grid jsme rozdělili jednak podle velikosti měst, přičemž se ukázalo, že Praha je fakt jako stát ve státě a pokud si někdo chce otevřít byznys v Praze, nedává smysl ho srovnávat například s byznysem v Brně. Máme tedy přibližně pět velikostních kategorií měst podle počtu obyvatel v Česku, a samozřejmě v Německu nebo jinde by ty kategorie byly jiné, ale princip zůstává stejný. Dále máme dělení na komerční, komerčně rezidenční, rezidenční a ostatní plochy, což pro nás byla docela výzva, protože bylo nutné věrohodně rozdělit město tak, abychom spolehlivě dokázali říct, že tohle je komerční plocha, tamto rezidenční a jinde komerčně rezidenční. Navíc se to mění na základě velikosti města – například to, co je v Olomouci komerční plochou, se v Praze stále vnímá spíš jako komerčně rezidenční, protože tam je stále hodně rezidenční zástavby.

S tímto jsme si dlouho lámali hlavu, ale nakonec jsme přišli na podle mě velmi dobré řešení, které nám to spolehlivě odlišuje. Využíváme k tomu dataset bodů zájmu a rezidenční údaje, které rozpočítáváme až na úroveň jednotlivých domů a bytů, takže to jde velmi detailně.

Jak jste to vyřešili vy? Co je správně a co špatně? Validujete to podle něčeho? Validace je sice hodně subjektivní, ale opírá se o místa, která známe, kde víme, že je tam jen byznys a nikdo tam nebydlí. Chceme, aby se ta místa logicky označila jako komerční. Například v Holešovicích máme kanceláře na Dělnické, kde je teď byznys hodně, ale stále tam všude bydlí lidi.

Zde je opravený text s úpravami pro lepší srozumitelnost, interpunkci a styl:

Lidi, takže takovou oblast jsme chtěli označit jako komerčně rezidenční, a pak jsou logicky ty čistě rezidenční, kde toho businessu je fakt málo. Takže validujeme v podstatě pohledem na mapu, tomu říkáme vizuální analýza, tedy vizuálně analyzujeme, jestli se nám daří nebo ne. No a těch iterací bylo fakt hodně, protože podmínek, které musí jednotlivé oblasti splnit, aby byly zařazeny do nějaké kategorie, je hrozně moc. Je to dlouhý seznam věcí, které tam musí být, a věcí, které tam nesmí být, aby oblast spadla do jedné nebo druhé kategorie. Takže jsme nad tím seděli fakt docela dlouho a výsledkem podle mě je fajn.

Ve výsledku, když já chci novou pekárnu a chci ji mít úspěšnou, tak mě srovnáte jenom s pekárnami, které jsou ve srovnatelně velkých městech, ve srovnatelně obývaných lokalitách. Řekněme, že pokud víš, kde tu pekárnu zhruba chceš mít, a máš nějakou nabídku na nájem na určité ulici, tak my se podíváme, kde ten bod, který jsi označil, leží — jestli v komerční nebo v komerčně rezidenční oblasti. Pak vezmeme ostatní pekárny, které leží v podobně velkém městě a na podobně typologicky profilovaném místě, a s tímto bodem tě pak srovnáme a řekneme ti: „Hele, to místo, které jsi vybral, je fakt dobré,“ nebo „potenciálně je to dost špatné místo.“

Co bys vzkázal na rozloučenou posluchačům DataTalku?

No, asi to, ať se nebojí zamyslet nad svými daty i z pohledu prostoru, z pohledu toho, kde se jejich byznys odehrává. Třeba v těch datech mohou odhalit něco, co by jim pomohlo dělat byznys lépe, efektivněji a být blíž svým klientům. Celé je to samozřejmě o tom, nabízet dobrou službu, alespoň pro nás. Každý způsob, kterým se můžeme k tomu přiblížit a pomoci z pohledu prostoru, jsme otevření řešit a snažíme se to dělat.

A marketspot.cz?

A marketspot.cz už také běží, takže se tam určitě můžete podívat, jestli je to ten způsob, jak vám můžeme pomoct. My pevně věříme, že to tak bude.

Tak jo, děkuji, Františku, za třetí pozvání.

Děkuju také, moc jsem si to užil, bylo to fajn a těším se zase někdy.

Naslyšenou.

Naslyšenou.

Děkujeme, že jste doposlouchali až sem. A díky taky našim partnerům, členům DataTalk klubu, kterými jsou Intex, Saska, Bistreet, Colors of Data, Revolt BI, Good Data, Keboola, Emark, Carl Data Company, Data Mind, Notino a Flow.

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

Nechť vás provází data.

Pokud si přejete ještě něco upravit, dejte vědět!