Podcast

Dobrý den, moje jméno je Jirka Vicherek a vítám vás u dalšího dílu Datatalk podcastu. Mými dnešními vzácnými hosty jsou Honza Divko a David Lacina, cloud data architekti z České spořitelny. Ahoj kluci.
Ahoj, čau.

Dneska si s kluky povíme, jak Česká spořitelna přešla datově do cloudu. Co to znamenalo, jak to vypadá dnes, jaké byly trade-offy a hlavně lessons learned. A kluci to měli celé na starost.

Než se dostaneme k období 2021 až 2025, kdy se toho událo hodně a kdy můžete hodnotit, co vám dělá radost, povídejte, prosím, jaká byla vaše cesta – jak jste se dostali do spořitelny, k datům, k IT. Začněme tebou, Davide.

Jo, já jsem vystudoval VŠE, informatiku a statistiku. Během školy jsem pracoval na brigádě na first level podpoře v jedné rakouské firmě, kde jsme sbírali různé počítače na opravy. Jezdil jsem i na instalace různých zařízení. Po škole jsem pokračoval v logistické firmě, kde jsem se stal jakýmsi velkým Excel guru, protože tam se hodně práce dělalo v Excelu. Většinou jsme si stáhli nějaká data z databáze a pak jsme je kombinovali přes funkci SVYHLEDAT. Asi se z tebe musí stát Excel guru, aby člověk zvládl logistiku v Excelu.

No, přesně tak. Měli tam předdefinované dotazy, které jsme si stáhli, a pak jsme je kombinovali dohromady, abychom získali potřebné informace. My jsme pracovali přímo s databází, takže to bylo docela zábavné. Ale později jsem z toho hodně těžil, protože jsem si v Excelu rychle dokázal udělat spoustu věcí, když bylo potřeba nějaké ad-hoc analýzy.

Dobře, díky. Pak jsem pokračoval v Adastře, kde jsem byl čtyři roky. Tam jsem se poprvé dostal ke spořitelně, protože jsem byl přes Adastru „prodaný“ do spořitelny, kde jsem dělal datového i business analytika nad datovým skladem, hlavně na regulaci. Byl jsem také součástí velkého projektu ve Vídni, kde se předělávalo celé rozhraní pro zasílání dat do Vídně pro regulační účely. V roce 2019 jsem pak přešel do interního týmu spořitelny, když se banka agilizovala a vznikala Future Bank. Tam jsem jako datový specialista měl na starosti korporátní klienty. A tam jsem potkal Honzu, protože Honza přišel asi půl roku po mně.

Co jsou to vlastně korporátní klienti?

Korporátní klienti jsou velké firmy, například ČEZ nebo jiné velké společnosti s miliardovými obraty, ale patří sem i menší firmy – SMEčka, a dneska také small business, což jsou i malí živnostníci. Korporáty tedy pokrývají segment od živnostníků až po velké firmy, tedy takovou B2B větev.

Přesně tak, jde o B2B segment, všechno, co má právní formu právnické osoby, dneska spadá pod korporáty.

V rámci korporátního segmentu jsme pak začali rozjíždět datový self-service, o kterém se ještě budeme bavit. V roce 2023 jsem pak přešel do týmu cloudových datových platforem a dnes se s Honzou zase propojujeme.

Jistě, zde je opravený text s lepší gramatikou, interpunkcí a plynulostí:

Spolupracovali jsme a pracovali jsme na kebule a adopci Snowflake'u ve spořitelně. Takže ve spořitelně jsi od jakého roku? Od roku 2019, vlastně teď už šestým rokem jako zaměstnanec a předtím jsem tam byl čtyři roky jako externista. Jasně, takže tam držíš know-how, víš, co znamená tahle tabulka? Jo, určitě si držím v tomhle ohledu know-how, ale spořitelna má i tu výhodu, že člověk může dělat pořád něco jiného. Já jsem začal jako datový specialista, pak jsem byl chapter leader, vedl jsem lidi a jejich vzdělávání, následně jsem se stal architektem, kde jsem řešil, jak budeme budovat jednotlivé use case, třeba větší migrace a jak připravit datové základy. Pak jsem přešel zpět k té kebuli, kde se začalo řešit i to, jak adoptovat nové služby, bezpečnost a tak dál, takže práce byla zase jiná. Dá se říct, že každý dva roky jsem dělal trochu jinou práci, ale nemusel jsem se učit úplné základy – věděl jsem, kde jsou informace o klientovi, kde jsou data o účtu, takže jsem mohl předat hodnotu díky svým znalostem.

Co tvoje cesta, Honzo? Já jsem vystudoval aplikovanou informatiku, ale během studií jsem pracoval jako obchodně technický zástupce pro menší firmu, která pochází ze Švýcarska. Zabýváme se technologiemi a vážnými technikami na zpracování nebo svařování termoplastických materiálů, takže úplně mimo IT. Jedná se například o střešní fólie, hydroizolace tunelů, svařování bazénů a tak dále. Tam jsem si doplnil soft skills, které tě škola v našem systému úplně nenaučí.

Potom jsem začal pracovat na malé klinice jako IT specialista, kde jsem se poprvé prakticky dostal do kontaktu s databázemi. Dělali jsme tam SMS, SQL a první reporty v SSIS. Byl jsem tam zhruba rok a půl až dva roky. Následně jsem potkal bývalé spolužáky z vysoké školy a oni mi řekli, že spořitelna prochází velkou agilní transformací a stane se moderní firmou. To byl okamžik, kdy jsem nastoupil do spořitelny.

Měl jsem skvělý start, začal jsem pracovat na incentívním reportingu pro retail. Retail zahrnuje celou naši pobočkovou síť, call centra a další útvary. Incentívní reporting je velmi zajímavý reporting, který vypočítává variabilní složku mzdy za prodeje a další motivační složky v síti. Je to citlivé téma, protože když to nesedí, sleduje to mnoho lidí – tisíce v distribuční síti, kteří to přesně zkontrolují. Tohle mě hodně naučilo.

Postupně jsem inklinoval k architektonickým a strategickým aktivitám. Řešení tehdy bylo postavené na Enterprise Guide a s tím jsme hodně bojovali. Podařilo se nám ale zahájit projekt, kdy jsme celé toto řešení dekomisionovali do Oraclu. V těchto aktivitách jsem pokračoval, dekomisionovali jsme Cognos jako reportingovou platformu a to mě postupně přivedlo až k práci v cloudu.

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

Opravený text:

Dovým technologiím jsme začali věnovat pozornost někdy v roce 2021, a to celkově jako cloudové technologické cestě, pokud jde o data. Ve Spořce jsem nastoupil vlastně ve stejný rok. Přesněji jsem tam nastoupil v roce 2019, kde jsme se s Davidem potkali v jednom společném týmu, který byl obchodně orientovaný, sice pod centrálním útvarem Data Tribe, ale zaměřený na business linie. David se věnoval korporátní části, kterou zmiňoval, a já jsem dělal detailněji tu druhou oblast.

Ve Spořitelně jsme měli koncept flow to work, což znamenalo, že datový specialista seděl přímo u businessu alespoň tři dny v týdnu, takže business měl datového specialistu přímo k dispozici „hands on“, mohl k nám dávat ad hoc požadavky a potom jsme se dva dny v týdnu scházeli v kanceláři a řešili věci tak, aby to dávalo smysl pro celou banku. Takže jsme spolupracovali, já jsem poslouchal problémy ohledně incentívního reportingu – i v korporátu se incentivní reporting řešil – a vlastně jsme si navzájem radili, ukazovali zkušenosti a předávali znalosti. Když někdo věděl, kde co najít, druhý se mohl zeptat. Měli jsme za sebou celkem asi deset lidí, kteří se mezi sebou radili a pomáhali si.

Jak už to Honza nastínil, pojďme se podívat, jak vypadala Spořka, hlavně z datového, architektonického a technologického pohledu v roce 2019, kdy jsme nastupovali. Jak jsem už zmínil, rok 2021 byl velkým zlomem v transformaci. Když si to rozdělíme na „před“ a „po“ — předtím, jak jsi zmiňoval Oracle…

Ano, jak jsem říkal, rok 2019 byl transformační dobou. V bance se začalo agilně řídit, přeskládaly se útvary, změnily se pracovní postupy. Tech stack byl primárně Oracle – především pro centralizované týmy, kdy jsme měli centrální datový sklad, centrální oddělení pro regulatorní reporting a analytický datový sklad. Pro obchodní části, alespoň primárně pro retailovou větev, se používal SAS Enterprise Guide, existovaly ještě některé reporty v SAS Visual Analytics a velkou roli zde tehdy hrál Kognos.

Korporátní část měla tu výhodu, že neměla tak velké objemy dat, díky čemuž se to budovalo rovnou na Oracle. Začali jsme také experimentovat s Tableu, protože někdy mezi lety 2018 a 2019 do Spořitelny přibyl Tableau jako reportingový nástroj pro centrálu. Nové reporty, které byly určené pouze pro centrálu, jsme začali dělat právě v Tableau. Tableau se začalo v té době ve Spořitelně etablovat, protože Kognos byl složitější a často těžkopádný – především pokud někdo potřeboval rychle během jednoho dne naklikat report pro tým, který by ukázal například, jestli se nějaký produkt prodává nebo ne. Tableau tedy začalo pomalu expandovat v celé Spořitelně. Takový byl tehdejší technologický stack.

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

To byl ten stack a možná docela dobrý — ten stack je vlastně od Davida.

K tomu tablu, protože v té době, když jsme přivedli Tablu jako spořitelnu, tak jsme v rámci agilizace začali s kolegyní Větou Suborovou datovou akademii. Datová akademie byla platforma pro vzdělávání lidí, protože jsme přinášeli spoustu nového softwaru a současně v rámci agilizace přišlo i mnoho nových lidí. Byla to platforma, kde jsme vzdělávali lidi ve směru SQL, vytváření reportů a řešení na Oracle.

Jak David zmiňoval, například výstavbu korporátního datamartu. Pokud jde o datovou decentralizaci, započali jsme ji právě na Oracleu v týmu Data Tribe, ale tehdy tam bylo asi jen pět byznysových týmů — korporát, retail a tak dále. Tým se trochu větvil a už jsme mohli vyrábět řešení v Oracleu, která nebyla stavěna úplně od nuly, ale využívala předpřipravené platformní věci od platformního týmu.

Teď jsem zmínil, že jsme se více věnovali interním týmům než dodavatelům. Začali jsme rozjíždět self-service, například v korporátním týmu. Připravili jsme jenom korporátní datamart, kde měli data jednoduše dostupná a nemuseli řešit, že ve warehouse musí spojovat 15 tabulek. Prostě dostali jednu velkou tabulku, která obsahovala základní informace podle jejich požadavků.

Měli jsme k tomu i školení, kde jsme učili lidi, kteří neuměli úplně SQL, jak s SQL pracovat a využívat korporátní datamart ke zjištění základních věcí — kolik mají klientů, kdo je obsluhuje, jaké mají účty a podobně.

Datová akademie nám také pomáhala, protože učila lidi, jak si v Tablu udělat report. Lidé tak byli schopní jít od základního SQL až po tvorbu jednoduchého reportu. Díky tomu z týmu odpadly jednoduché ad-hoc požadavky, které dřív dodávali za 14 dní, ale uživatelé je potřebovali druhý den. Nechtěli čekat 14 dní, protože se potřebovali jen rychle podívat na nějaká data.

Začali jsme se snažit touto self-service cestou přesouvat tuto schopnost přímo do týmů, aby tým sám rozhodl, kdo bude dělat reporty, protože čísla potřebovali pro řízení.

To byl nějaký začátek self-service, který jsme se snažili zavést v bance. Dalšími kroky, jako byla kvalifikace a příchod k Bulletu, se nám to dařilo víc a víc, protože nevýhodou Oracle bylo složité nasazování. Lidé nebyli schopni si sami vyvíjet tabulky, potřebovali nás. Mohli vytvořit nějaký prototyp, napsat selekt do Tably, Tablu to spočítalo, ale složitější věci pořád řešil náš centrální tým. Už ale odpadaly…

Pokud si přeješ, mohu pokračovat v opravě zbytku textu nebo něco upravit podrobněji.

Jasně, tady je opravený text:

A aspoň tyhle ad-hoc úkoly, které si dokázali udělat rychleji, efektivněji, a většinou už hned na začátku měli správná čísla, protože věděli, jak jejich data mají vypadat a jak má být všechno správně. Jo, je důležité zmínit i příčinu, proč se vůbec šlo cestou decentralizovaného přístupu, protože centrální útvary – ať už to byly původní útvary datového skladu – začaly dříve či později představovat bottleneck. Jak data v organizaci nabývají na důležitosti, přibývá víc a víc softwaru, sbírá se více dat z interního i externího světa, a požadavků od byznysu je čím dál více.

To znamená, že nejdřív se stal bottleneckem datový sklad. Pak v rámci Data Tribe vznikly ty datové týmy, které odbavovaly byznys. Ale po dvou, třech letech jsme ani my nebyli schopní odbavovat požadavky, které na nás přicházely. Jediná cesta, která mi dává smysl, je decentralizace v podobě self-service, kdy si týmy pro ad-hoc analýzy mohou obsluhovat sami, zatímco doménové huby dělají složitější věci – data preparation, připravují datamáry a tak dále. Ale i to se s časem ukázalo jako nedostatečné – nechci říct, že to nevyhovovalo, ale prostě to nestíhalo.

V roce 2022 došlo k decentralizaci týmů – pět týmů se přesunulo přímo k byznysovým lidem, lídrům, kteří mají dnes možnost týmy rozšiřovat, zmenšovat, přeskládávat a obsluhovat je více samostatně. Právě tam nám přestal stíhat Oracle, protože jsme na něm nebyli schopní dělat self-service multiprojektovou architekturu. V té době přišla myšlenka na použití Buli. Myslím si, že se SASem a Oraclem se self-service dělá podstatně hůře, protože jsou to produkty, které vznikly ve starém světě, kde se self-service moc nepočítalo, oproti novým nástrojům, jako je Tableau, které na to jsou stavěné.

Jak moc tedy šlo dělat self-service? Kolik je to o technologickém stacku a kolik o lidech a adopci?

My třeba na Oracle máme krásně udělaný framework, na kterém pracují kluci z ADS od nás. Není až tak složitý, ale myslím, že pro byznysové uživatele je stále hodně komplikovaný. Máme tam spoustu věcí – oni nám dodávají vlastně jen byznysovou transformaci, my ji obalíme do balíku, který se pak nasazuje přes pipeline. Ale i tady jsou ty kroky, například GitHub, a to už je pro běžné uživatele složité. A bylo to složité i pro datové specialisty, kteří byli dobří v tom udělat selekty, uměli komunikovat s byznysem, zjistit, jak mají být data správně uspořádána, ale měli problém to nasazovat, nebo je ten celý proces nebavil. Na jednoduché reporty to bylo prostě overkill.

Pokud chceš, můžu ještě text dále upravit, zestručnit nebo přeformulovat.

Zde je opravený a stylisticky upravený text:

Nepotřebuje se to dávat na testovací prostředí, nepotřebuje to pak nějak nasazovat na produkci, psát adminům ani řešit verze, protože jde o jednoduchý report pro jeden, dva týmy, který potřebují vytvořit rychle a ideálně sami – tak, aby ten člověk byl schopen udělat to od začátku až do konce sám. Není tam žádný proces, kdy by například někdo nejprve vytvořil selekci, pak ji dal vývojáři, který to nasadí až za 14 dní, protože takhle to nemůže fungovat v rychle se vyvíjejícím prostředí.

Tento způsob by měl platit například pro incentívní reporting, kde se pracuje s penězi a musí být vše přesné, tam si člověk nemůže jen tak nasazovat reporty na produkci. Když je to ale report pro tým, který má deset produktů a chce sledovat jejich prodeje, tak pokud se tam udělá chyba, tým ji snadno pozná — třeba když místo tisíců budou miliony, a report se pak musí opravit.

David krásně ukázal problém SASu, který už není úplně multiprojektová platforma, neuměl verzování do Gitu a používal verzování pomocí souborů na disku, všichni pak pracovali přímo s produkčními verzemi. To vedlo k velké chybovosti kvůli ručním nasazováním, kdy si někdo něco přepsal.

Framework, o kterém mluvil David, je postavený na model-driven přístupu. To znamená, že jsme vývojáře i další lidi, kteří na tom pracovali, začali nutit víc přemýšlet o výsledné struktuře a využití různých vzorů, které byly předpřipravené. Pro některé by to mohl být zbytečný overkill, ale datoví specialisté to zvládli.

Právě tak se tehdy, za dob Martina Garnischa, začala hledat platforma, která by toto nabízela – v té době to byla prakticky jediná taková služba, a to právě Keboola. Další výhodou Kebooly bylo, že umožňovala jednoduchý datový ingest. My totiž měli data lake, kam se data nejdříve ukládala, pak jsme je vytahovali do Oracle. Když data v data lake byla v JSON formátu, nebylo snadné to v Oracle rozparsovat a dále s tím pracovat. Keboola umožňovala napojit se téměř na cokoliv, stáhnout data a hned nad nimi pracovat.

Nemuselo to probíhat tak, že nejprve jeden tým něco udělá, druhý tým něco zpracuje a třetí pak může s daty pracovat. Stačilo zadat credential a cestu, vše šlo hladce přes Keboolu.

V roce 2021 jsme tedy nasadili Keboolu a začali ji používat. Co to znamenalo? Nejenom vypnutí Oracle a zapnutí Kebooly, ale doplnění existujícího sekventního procesu. Aby to neznělo úplně růžově, narazili jsme i na spoustu překážek, například získání cloudové služby pro data, ale to už je jiná historie.

Pokud chcete, mohu text ještě více rozčlenit nebo upravit dle potřeby.

Zde je opravený text:

Když jsme chtěli ukládat citlivá data do prostředí banky, tedy do regulovaného prostředí, nebylo to úplně jednoduché. Měli jsme tak trochu smůlu, nebo je to možná zkušenost, kterou bych rád předal posluchačům. Začali jsme s Kebulou na backendu Microsoft Synapse. Standardně je platforma primárně vyvíjená nad Snowflakem, ale v RFPčkách a assessmentech nám to z hlediska ceny a dalších parametrů vyšlo lépe na papíře právě se Synapse.

Naše lekce je ale ta, že to vypadalo lépe jen na papíře, a když jsme po čase začali migrovat ze Synapse, realita se ukázala být mnohem lepší, než jsme původně předpokládali v těch assessmentech.

Když jsme začínali s Kebulou na Synapse, měli jsme zhruba 40–50 uživatelů a asi 20 projektů. Projekty v Kebule jsou izolované prostory určené například pro jeden vývojový tým nebo jedno datové řešení, aby byly oddělené od ostatních. Přesto jsme měli spoustu problémů s výkonem, zamykáním objektů, konkurencí uživatelů a paralelismem. Přitom Synapse je prezentovaný jako platforma pro cloud, která by měla tyto problémy zvládat, ale v praxi tomu tak nebylo.

Měli jsme i poměrně vytížený DevOps tým, který se musel denně starat o to, aby vůbec veškeré pipeline doběhly. Trápili jsme se s tím asi dva roky a David tohle období dobře zažil.

Synapse byl náročný i z pohledu self-service, protože uživatelé museli psát různé příkazy, kterým mnohdy vůbec nerozuměli. Při vytváření tabulek museli zadávat příkazy s distribucemi a dalšími parametry, o jejichž významu neměli tušení. Říkali jsme jim, že to tam musí být, jinak by to správně nefungovalo. Často docházelo k zamykání tabulek, museli se psát dotazy přes view, aby se tomu zabránilo.

Další problém byl v tom, že většina lidí u nás praktikovala Foreklu a Microsoft SQL měl jiný dialekt. Uživatele to dost frustrovalo – místo toho, aby se věnovali byznysové části, tedy tomu, jak získat správně data, půl dne řešili, jak správně napsat příkaz. V té době ještě nebyl ChatGPT, museli hledat informace po internetu nebo na Stack Overflow. Pro ně to bylo složité a přechod na něco nového, zvlášť cloudového, musel být jednoduchý, což tady nebylo.

Zejména pro ty, co se SQL úplně nekamarádili, byli spíše začátečníci, nebo zvládali Foreklu, ale SQL v Kebule nefungovalo stejně. Věděli, co chtějí udělat, ale nevěděli, proč jim to nešlo. Typicky při zavádění něčeho nového a cloudového panovaly velké obavy, nebylo tolik nadšenců ani průkopníků, kteří by byli nadšení a šli tomu naproti. Místo toho se všichni snažili hledat drobné důvody, proč by to nemělo fungovat a proč bychom to dělat neměli.

Pokud si přejete, mohu text ještě více upravit nebo zestručnit.

Takže vlastně zhruba ty dva roky ta adopce nějak lítala nahoru a dolů, ale nezažívala vůbec žádný velký boom. Jak jsem zmiňoval, je to zhruba 20 projektů a 40–50 lidí. A na vaší straně to tedy konečně bylo rozvázání rukou a „wow, prima, máme konečně platformu a můžeme na ní pracovat“? Nebo to vlastně taky dřelo?

Úplně jsem to tak nevnímal, protože jak jsme tady mluvili předtím o tom frameworku a o tom model-driven přístupu právě na tom Oreklu, ten byl stále používán ve větším měřítku těmi businessovými týmy, které to uměly. Takže vlastně tato Keboola se Synapsekou nepřevážila, byl to spíš doplněk k tomu stávajícímu stacku a dělaly se tam jen ty use-casy, které neměly jinou alternativu. David zmiňoval natahování nějakých nových datových zdrojů, začali jsme číst nějaká data pro business z různých veřejných rejstříků a podobně. To jsme v tom starém světě pohodlně neměli. Takže tam to dávalo smysl, ale žádný velký enablement nebo rollout do banky se vlastně nekonal.

To bylo přesně v období, kdy došlo k decentralizaci všech týmů do businessových linií. Zároveň vzniknul Cloud Data Platform Team, jehož jsem byl součástí od úplného začátku, a tam jsme začali uvažovat o tom, jestli bychom ten backend neměli vyměnit a zmigrovat právě na Snowflake – na platformu, na které je původní Keboola velmi silná a etablovaná. To bylo někdy začátkem roku 2023, kdy jsme o tom začali uvažovat a rozjeli všechny potřebné kroky.

K tomu bych jen přidal, že problém Kebooly v té době byl, že se nedostala mezi businessáky, stále byla mezi lidmi z DataTribu, což nebyl ten cíl. Cílem bylo to dostat mezi businessáky, aby si businessák – například customer journey expert, který umí programovat – mohl vytvořit svou vlastní datovou pipeline a zpracovat si část, která ho zajímá, a nebyl závislý na jiných lidech, kteří mu to musí udělat v Oreklu. To se se Synapsekou nedařilo, protože byla pro ty lidi zbytečně složitá.

Jak jsem říkal, zhruba začátek roku 2023. Až v polovině roku 2023 jsme začali adoptovat tuto platformu, což zase obnášelo spoustu papírování, compliance, risk, IT security a podobně. Snowflake je totiž oproti Synapse software jako služba (SaaS) v public cloudu, kdežto Synapse byla jako platforma provozovaná v našem Azure. Proto bylo potřeba spoustu příprav, papírování a zajištění, jak tu platformu naintegrovat do banky a jak všechno zabezpečit s ohledem na to, že ji používáme v business critical prostředí s nejvyšší úrovní zabezpečení.

Někdy před létem 2023 jsme společně s Keboolou připravovali migrační projekt, jak převést těch zhruba 20–25 projektů, které už tam byly, na nový backend, aby to mělo na uživatele co nejmenší dopad. Zároveň jsme i v Synapse dělali repliku velké části našich RecLio dat…

Zde je opravený a stylisticky upravený text:

A Warehouse, aby tam ty týmy měly to jádro – klienty, účty a další faktové informace, aby tam vůbec mohly nějaké reporty dělat. Takže tohle jsme všechno začali připravovat a převádět. S Davidem jsme na tom spolupracovali, protože on byl ještě v té korporátní linii. Byl to takový kámoš, můj buddy, abychom společně navrhli migraci, připravili ji, zkusili to s někým odladit a pak jsme ji vlastně rozjeli na všechny týmy a migraci prováděli. Myslím, že to trvalo dva, tři měsíce a pak jsme byli s migrací hotoví.

Samozřejmě nešlo všechno úplně hladce, migraci jsme několikrát přehrávali, protože se objevovaly problémy, které se dříve nestaly. Jedním z problémů byly rozdíly v datových typech mezi databázemi. Převoditelnost například floatů, které jsou dost vázané na konkrétní verzi a hardware procesoru, je docela problémová. Proto jsme ten převod floatů opakovali asi dvakrát, třikrát, než to správně fungovalo s desetinou čárkou. Takže bacha na floaty!

Co bych ještě změnil? Pro mě je Kebula taková abstrakce, mezivrstva, „operační systém“, jak rád říká Pavel. Co všechno je třeba přepsat, pokud mám stále Kebulu a stejné use case, ale měním jen podvozek ze Synapse na Snowflake? Hodně věcí. Protože to bylo psáno pro Synapse. Migrace probíhala tak, že kluci z Kebuly všechny transformace zduplikovali do verze pro Snowflake, takže jsme v jednu chvíli měli obě platformy – Synapse a Snowflake. Projekt se pak musel v určitou chvíli přepnout na nový backend, zatímco stará verze na Synapse stále fungovala, dokud se nerozhodlo o jejím vypnutí.

Když se projekt přepnul, lidi museli kontrolovat jednotlivé SELECTy. Většinou to probíhalo tak, že si vybrali flow, kde měli konkrétní SELECTy, spustili ho a sledovali, co se děje. V té době už naštěstí byl ChatGPT, bylo to krátce poté, co ho vydali, takže hodně pomohl. Lidé se mohli ptát a banka byla rychlá, takže jsme měli ChatGPT dostupný přímo v rámci banky. Díky tomu si lidé mohli radit, jak přepisovat SQL.

Největší problémy byly s různými složitějšími procedurami. Pamatuju si třeba, že tam byla procedura pro dynamické tvoření pivot tabulek. To přepisoval Honza asi den a půl, než to dal dohromady. Dneska Snowflake tuto funkci umí přímo v rámci jedné funkce, dříve však ne. Nejvíce problémů byly právě s procedurami, protože se jazyk výrazně lišil. U ostatních věcí většinou ChatGPT pomohl, takže když vezmu všechny korporátní projekty dohromady, trvalo nám asi 14 dní, než jsme mohli říct, že nám už to funguje.

Pokud chcete, můžu pak text ještě více zformálnit nebo naopak přizpůsobit určitému stylu.

Zkopírovali jsme Signapsku do Snowflake, abychom ji pak už zapli jen na Snowflake. Nemyslím si, že to bylo úplně bolestné. Samozřejmě to stálo nějaký čas, business se do toho musel zapojit, ale přínosy, které to přineslo, byly tak velké, že všichni byli rádi, že se Signapsky ve výsledku zbavili.

Ptal jsi se, co přesně se muselo stát. Kebula je operační systém nebo nějaký framework, nadstavba nad backendem. David zmínil transformace, což bylo vlastně to hlavní – veškeré extrakty ze zdrojových systémů zůstaly neměnné. Protože jsme nějakou dobu fungovali duálně, každý projekt byl dvakrát a měl nové ID. Projekty si mezi sebou sdílely data, takže se všechno muselo překonfigurovat, přezdílet, a nejvíc práce byla asi na transformacích, aby šly znovu spustit v snowflakovém dialektu. Pak všechny konfigurace kolem, než se týmy přepojily na nové projekty.

Toto všechno jsme zveřejňovali v různých tabulkách. Velký dík patří týmům, které na tom pracovaly a které nám v tom asistovaly. Musely do toho vložit svůj efort, a postupovali jsme od jednodušších věcí k těm složitějším. Kluci udělali migrační plán, protože bylo potřeba týmy koordinovat. Nejprve bylo potřeba migrovat DVHčko, protože všichni využívají data z DVHčka, a bez dat z DVHčka nikdo nic neudělá.

Takže kluci zmigrovali DVHčko a řekli, že týmy, které braly jen data z DVHčka, mohly začít s migrací. Potom se domluvili s dalšími odběrateli, kteří také museli přepnout. Bylo tedy potřeba správně koordinovat přepnutí všech týmů. Naštěstí v té době nebylo v kebule tolik lidí a tolik sdílení, takže se to dalo dobře řídit.

Kluci měsíc předem dělali rozhovory, ptali se, co kdo používá za datové typy a podobně, protože samozřejmě vše zkoušeli na testech a věděli, jaké problémy mohou nastat. Zvládli i věci jako flowty a další záležitosti, aby vše fungovalo. Když přišla migrace k týmům, už se technické problémy téměř nevyskytovaly, možná jen nějaké orchestrální – protože jsme ještě používali naši orchestrální platformu Rockify. Kebula sama o sobě v tomto směru nestačí, když je potřeba navázat na okolní svět.

Řešili jsme například ještě problémy s tokeny, ale nebyly to žádné velké záležitosti. Při samotné migraci jsme na nic zásadního nenarazili, protože to bylo velmi dobře otestované. Harmonogram také dával smysl – někdy v červenci a přes prázdniny, nejpozději v září nebo říjnu, už bylo vše na Snowflake v kebule.

Ještě máš otázku na architekturu nebo smysl?

Tady je opravený text:

Bylo to složité, nebo to bylo jen o přepsání transformací a projektů? Nebo jsou tam nějaké věci, které Snowflake prostě počítá a dělá úplně jinak, a tím pádem jste museli celou transformaci nebo projekt zahodit, protože celá logika Snowflakeu je odlišná? Nebo naopak, budeme o tom mluvit, jak vám to vlastně uvolnilo ruce a podobně.

Moje otázka je, jestli to bylo jenom o rychlejším computingu, a tím, že to bylo rychlejší, nebo jestli jsou tam i nějaké další výhody Snowflakeu?

Bylo to primárně o rychlejším computingu, díky čemuž za námi primárně šly transformace. Určitě, kdyby se přehazovaly transformace v Kebule, tak za tím byl mnohem větší effort, aby to přehodili. Ale protože Kebula na Snowflakeu standardně nabízí své služby zákazníkům, předpokládám, že tohle bylo vyřešené. Nejvíc jsme řešili přesouvání projektů mezi projekty, a kluci z Kebuly připravili spoustu utilit, které nám to usnadnily.

Ale tady přichází ten moment, jak jsem zmínil u assessmentů a RFP, které na papíře vypadaly dobře. Když jsme po třech měsících migraci dokončili a začali jsme využívat pouze computing Snowflakeu, udělali jsme porovnání nákladů mezi Synapse a Snowflake. Snowflake nás najednou vyšel na třetinové náklady. Na papíře to ale tak nevypadalo. Díky PSUGO modelu, výkonu, sdílení clusterů mezi uživateli a odlišné architektuře a platformě Snowflakeu došlo k výraznému snížení nákladů.

To pro nás byl trochu pozitivní šok, protože jsme náklady výrazně snížili. Kdyby to bylo naopak, asi bychom měli co vysvětlovat.

A to je naše lesson learned – opravdu si dát pozor, aby dobře vyšly assessmenty a různé RFP analýzy, které byly často dělány pouze teoreticky nebo na malých POC. Všechno ale záleží na tom, kolik firma je schopná do projektu investovat effortu, kolik informací dokážeme u komplexních institucí získat a vložit do studie. Myslím, že firmy nikdy nejsou schopny poskytnout všech 100 %, a proto se to nikdy na papíře neukáže tak, jako v realitě.

Když jsem porovnával Snowflake, zjistil jsem, že většina transformací běží mnohem rychleji, neblokují se zámky, nechodí každý týden žádné zprávy, že Synapse byla dvě hodiny zamrzlá, a pipeline běží přesně podle plánů. Kluci pak byli překvapení, jak málo to „žere“ kreditů – nakoupili plno kreditů a pořád zbyvaly rollovery, protože výpočetní náklady na Snowflake byly zhruba třetinové oproti Synapse.

To bylo naprosto úžasné a ještě to zvýšilo spokojenost lidí. Snowflake pomohl Kebule rozjet se a etablovat v bance.

Myslím, že i kluci tomu udělali docela dobrou reklamu – že to bude všechno jednodušší, lepší, takže týmy na to slyšely a když si to vyzkoušely, poznaly, že to opravdu tak je. My jsme využili tu platformu, ty datové akademie a právě ty týmy, co tam naskočily. Do toho týmu přišel i David Kimo, který nám pomohl řešit platformu, a využili jsme vlastně našich kontaktů. David dělal korporát a retail, pak jsme měli kolegy, kteří znali controlling, Ryska a podobně, takže jsme využili takových kontaktů a dokázali jsme enablovat tu platformu až do dnešní velikosti, kdy jsme ji roztlačili skrz celou banku.

Zlikvidovali jsme vlastně takové to „šedé IT“, kde vznikalo spousta sil, počítačů s nálepkou „Prosím, nevypínat, kritická služba“, Excelů, VBAček, nějakých Microsoft Accessů a dalších custom řešení. Ta instituce je strašně velká, je to jako desítky firem ve velké firmě. Díky tomu jsme všechny dostali na jednu platformu, kde máme viditelnost, vidíme perfektně náklady a lidé mezi sebou můžou velice snadno sdílet data. Předtím v tom distribuovaném „šedém“ světě všichni řešili stejné problémy: jak tam nahrát Excel, jak tam nahrát data z Oracle, jak tam nahrát data odsud či odjinud. Najednou všichni začali přicházet na to, že chtějí být na té platformě, kde jsou i ostatní útvary – protože když tam budu, získám od nich nějaká data a jim zase můžu poskytovat nějaká data.

Vlastně se stalo něco jako komunitní enablement – postupně jsme nabírali další a další lidi, ti nabírali další a další, a všichni chtěli fungovat v tom ekosystému. Byla to sněhová koule s datovými zdroji. My jsme v Kebule vlastně nedělali moc žádnou reklamu po bance, lidé chodili sami s tím, že slyšeli: „Mohli byste mi pomoci, já to tady dělám někde v Excelu, každý měsíc to mám ručně, Kebula by to měla umět udělat.“ My jsme jim ukázali, jak by to měla udělat, oni to v Kebule udělali a zase to doporučovali dál. Najednou to začalo organicky růst samo, zvlášť když jsme přešli na Snowflake – už to bylo fakt jednoduché a hands-on.

Samozřejmě Kebula stále dodělávala nové a nové funkcionality, takže se to lidem stále víc a víc přibližovalo. A často nás při tom i poslouchali – když jsme říkali, že nás něco trápí, přišel další klient s podobným problémem a rádi nám funkčnost dodělali, čímž ji zase přiblížili ostatním uživatelům. Takže to bylo pomalu, ale jistě – Kebula rostla do současné velikosti. O to se staral náš platformní tým. Neznělo to tak, že jsme udělali migraci a založili si ruce, ale soustředili jsme se s Davidem a týmem především na enablement nových týmů. Když někdo přišel, že potřebuje něco řešit, pomáhali jsme s iniciálním návrhem řešení.

Opravený text:

Mohlo to takto vypadat. Získávali jsme od nich nové požadavky, protože Kebula nabízí přes 300 různých komponent, extractorů, writerů, ale my v bance to nemůžeme takhle všechno pustit. To znamená, že každá komponenta musí projít interním procesem, schválením IT security a dalších oddělení, kde se řeší, za jakých podmínek se mohu napojit, jak bude vypadat autentizace, jak budeme sítě oddělovat a podobně. Takže jsme vytvořili průvodce, který jsme jako platformní tým postupně rozšiřovali.

Zároveň jsme začali s Kebulou a naší datovou akademií pořádat různé čtvrtletní nebo půlroční meetupy, kde jsme představovali novinky, které je možné ve spořitelně používat, a také vzdělávací programy. Kebula přinesla do naší spolupráce i jejich akademii, kde bylo možné absolvovat školení. To vše vedlo postupně k adopci a ke kýženému efektu, kdy jsme zjistili, že více než polovina lidí, kteří dnes pracují s Kebulou, nejsou IT specialisté v liniích, ale jsou to skutečně business uživatelé, kteří zautomatizovali ruční procesy pomocí platformy. Myslím, že to bylo velmi pozitivní. David bude mít určitě nějaká aktuální čísla, jak jsme na tom.

My jsme vlastně začali budovat komunitu kolem Kebuly. Dnes je nás v týmové skupině přes 300 nebo 400 lidí. Aktivně to sleduje podle mého názoru minimálně 100 lidí, protože naše příspěvky mají kolem 25–30 lajků, což ukazuje, že lidé informace čtou. V těchto skupinách sdílíme novinky, ale také řešíme problémy. Zjistili jsme, že pro základní věci je potřeba psát návody, a to ne jen textové návody typu „klidně sem, klidně tam“, ale s obrázky. Člověk tak může kliknout na konkrétní use case a je jasně vysvětleno, co má dělat.

To hodně pomohlo, protože když člověk pošle jen wiki s návodem, často už uživatelé nereagují nebo zapomenou, že návody existují. Proto jsme s návody strávili hodně času, ale ukázalo se, že jsou velmi důležité. Pro základní komponenty platí, že jakmile se člověk ozve potřetí nebo čtvrtý, že neví, jak něco nastavit, vyplatí se strávit půl dne nebo tři čtvrtě dne vytvořením dobře zpracovaného návodu. Pak už stačí jen odpovídat odkazem na návod a čas se tím vrátí. Lidé jsou spokojení, protože mnoho z nich ani nevyhledává pomoc, stačí, že si podle návodu poradí sami.

Nevím přesně, kolik lidí návod použilo, ale podle měření návštěvnosti na Wiki si ho prohlédlo už 700–800 unikátních uživatelů, což ukazuje, že lidé návody opravdu čtou a používají je.

Proto si myslím, že pro jakoukoli adopci je potřeba připravovat návody specifické pro spořitelnu, kde jasně uvedeme, co tady vyplňovat nemají, co nepoužíváme, nebo co je například v naší bezpečnostní politice blokováno či omezeno.

Zde je opravený a upravený text s lepší plynulostí a srozumitelností:

Vyplňuji tam různé věci, dávám tam třeba nějaké tipy a triky, jak někdy něco upravit, nebo jak se někdy vlastně něco dělá přes konfigurační JSON – kam to mají vložit, aby to fungovalo tak, jak potřebují. Díky tomu pak i složité věci zvládnou, protože oni potřebují jednu konkrétní věc, tak tam mají jasný příklad, co to udělá, a jednoduše to tam vloží.

Takže spousta těchto věcí je pokrytá návody, což si myslím, že hodně pomohlo k adopci. Lidi totiž přicházeli, chtěli zakládat nové projekty a pracovali v té Kebule hlavně proto, že to není mrtvý projekt, na kterém se nic neděje.

No, to zní jako velký úspěch, když to srovnáme s dobou, kdy jste mluvili o Kebule a Synapse. Tehdy bylo maximum zhruba 25–30 projektů a podobný počet lidí zapojených. Když jste pak otevřeli Kebulu a Snowflake, říkáte o tom samé hezké věci, ale jak se to projevilo v číslech?

Jo, v roce 2025 jsme se dostali na zhruba 100 aktivních projektů. Aktivní projekt je takový, který mě ve daném měsíci provede alespoň jeden success job, přičemž většinou jich je samozřejmě mnohem více. Máme kolem 230 aktivních uživatelů, kteří se tam alespoň jednou do měsíce přihlásí. Dále máme přibližně 60 až 70 týmů v rámci banky, sdílíme zhruba 250 bucketů neboli schémat.

Takže teď jsme Kebulu za poslední dva roky viděli ve velkém růstu. Nyní už ale přemýšlíme o určité konsolidaci, protože i když je to kavernované prostředí (rozčleněné na různé části), je to zcela self-service, takže uživatelé tam mohou dělat spoustu věcí. Ne všechno však má 100% přidanou hodnotu.

Proto teď začínáme řešit konsolidaci a správu governance, aby se tam zase nevyrábělo úplně všechno, protože samozřejmě běží v cloudu, což něco stojí, vytáčí se kredity. Potřebujeme to lépe řídit a dostat do fáze, kdy udržujeme systém, ale už nepotřebujeme nabírat mnoho dalších use caseů. Myslím, že už jsme pokryli celou banku a teď je potřeba spíš řídit, aby se dělaly ty správné věci, aby se nepřidávaly zbytečnosti, a aby staré věci, když už nefungují, byly vypínány – aby tam nikdo nenechal běžet zbytečné flow atd.

Souhlasím s Davidem. My jsme tak říkajíc saturaci platformou pro celou banku udělali, další stovky týmů už nevytvoříme, ale přineslo to nové aspekty řízení a governance. To je hodně téma kolem Kolibry a její adopce, kterou táhne Pavlína Vajgarová – možná je to teaser na některé z dalších dílů.

Zároveň je tu i nákladová složka, kterou zmínil David. Velký benefit cloudu a důvod, proč firmy přecházejí do cloudu, je transparentnost nákladů – jsme schopni přesně vyčíslit, kolik který projekt stojí a kolik výkonu který člověk skutečně využívá. To je teď velké téma i u nás v bance, protože dneska celý náklad leží na platformním útvaru nebo centrálním oddělení…

Pokud chcete, mohu upravit i další část textu.

Jsem v IT, ale to je samozřejmě dlouhodobě neudržitelné a my právě potřebujeme ten náklad začít rozřezávat na jednotlivé linie a začít jim to přeúčtovávat. Takže teď jsme spíš v novém období optimalizace, nejenom nákladové, ale také začínáme hodnotit, jakou to má pro nás byznysovou hodnotu. Tady vidím, kolik mě celý ten projekt stojí, můžu ho nějak byznysově popsat, co to vlastně pro banku dělá, a každý product owner nebo byznys si potom může dát na misku vah, jestli to pro nás je kladný případ užití nebo záporný, a jestli to má skutečnou přidanou hodnotu. Takže tohle je teď velké téma, které opravdu řešíme s financemi, s controllingem atd., jak to nějak interně dělat, aniž by to bylo moc byrokratické.

Když jsme takto nasaturovali banku self-servisem, přišlo téma, co dál s core datovým skladem a s analytickým skladem. Máme tam i datalake, o kterém jsme tu trošičku mluvili. To je cloudová technologie postavená na Hadoopu, vlastně data platforma. Nedává smysl neustále pouze replikovat data z Oracle. Proto jsme zavedli nástroj Oracle Golden Gate, abychom replikaci nedělali pomocí Kebuly, kde každý extraktor se musel nějak konfigurovat, a my máme tisíce tabulek. Vzali jsme tedy CDC od Golden Gate a ta nám replikovala celý core datový sklad a analytický sklad do Snowflakeu. Konec roku 2024 jsme ten Golden Gate spustili a to také přineslo období, kdy jsme začali uvažovat, jak tyto centrální komponenty nebo ten starý, více než 20 let vyvíjený datový sklad posunout do cloudu.

Tam jsme začali o Snowflakeu uvažovat jako o samostatné větvi. Pracovně tomu říkáme Direct Snowflake, protože Kebula jako nadstavba je hodně byznysově orientovaná, má servisní charakter a přináší velkou hodnotu, ale pro takto obrovský sklad, kde běží denně desítky tisíc dotazů, je potřeba spoustu věcí generovat automaticky, mít to hodně metadatově řízené, model-driven, něco jako codebase. Zjistili jsme, že Kebula na to není úplně vhodná a že tuto větev chceme držet čistě v Direct Snowflakeu.

Začali jsme dělat různé assessmenty se zahraničními firmami, bavit se o přínosech, když datový sklad přesuneme do cloudu, o možných přístupech, zda uděláme lift and shift, zda budeme stavět úplně nový řešení, nebo to nějak zkonvertujeme. Momentálně jsme v této fázi a postupně některá řešení na Snowflakeu začínáme stavět. Máme tam tým z domény Insurance, který postavil celý nový datový produkt, včetně nových integrací s našimi dceřinými společnostmi a partnery. Staví to celé úplně od začátku v cloudu. Jsou za to zodpovědní David Pacholka a jeho tým, protože každá taková věc „from the scratch“ vyžaduje určité odhodlání a výdrž směrem k platformě.

Opravený text:

Ormě, protože ne všechno nám fungovalo na první dobrou, ale to si myslím, že je na spoře docela skvělý – že tam máme spoustu partiáků, kteří jsou ochotní a nadšení do nějakého rizika a prototypování těchto věcí, a to nám hodně pomáhá. A když se zeptám obecně, kdy můžu vypínat starou platformu? Je nějaká možnost, že vypnete Oracle? V horizontu pěti let? Asi to nebude jedna ku jedné, asi tam nějaké procesy vždycky poběží, asi zůstane on-prem, protože nedává smysl to úplně vypínat, ne? Nedává smysl, abyste byli stoprocentně cloudová firma, že? Ty cíle máme poměrně vysoké a banka se tam žene s celým aplikačním portfoliem. Ta nás vlastně táhne i tím aplikačním portfoliem. My dneska nakupujeme spoustu softwaru jako SaaSové služby, které integrujeme do on-premu, a někdy za dva roky už myslím, že budeme mít více než 50 % portfolia v cloudu, takže pro nás pak přestává dávat smysl tahat analytiku zpátky do on-premu, jo? To by se nám vůbec nevyplatilo. Máme ambice s datovým skladem tam odejít celým. Důležité je říct, že ten Oracle nemáme v bance jenom pro datový sklad a analytické účely. Funguje tam jako backend různých core systémů a tak dále. Tam 100 % zůstane v následujících letech. Tam to není téma. Ale u analytiky tu ambici máme. Z těch assessmentů, co jsme dělali, jsme měli nějaký – nebo máme připravený – zhruba čtyřletý plán a teď se bavíme o tom, kdy a jak to udělat. Snažíme se nějak obhájit finance a ještě zvažujeme i další platformy.

A když se ještě zeptám, promiň, za jak dlouho jste vypnuli Synapse? Už jste ho mohli zahodit, protože backend to tahalo? Vlastně po migraci na Snowflake jsme to udělali hned na závěr. Nechali jsme ho tam asi měsíc kvůli nějakým backupům. Pak, protože Microsoft má ty předplatné, tak jsme to oficiálně finančně vypnuli někdy v únoru tohoto roku, protože jsme měli ještě dva roky předplacené, takže tam bylo něco doplaceno, ale reálně se to přestalo používat někdy v říjnu nebo listopadu, kdy poslední tým vybral data, protože ten tým už dál nepoužíval Synapse a chtěl si je dělat jinde. To byl asi poslední tým, který si vybral data, pak už to bylo skutečně vypnuto a jezdily tam jen předplatné, která se musela platit.

Ještě bych dodal k analytice, že díky Oracle Golden Gate, když se nám podařilo zmigrovat celý warehouse do cloudu, tak podle mě už většina analytiků – možná 80–90 % – používá Snowflake, protože je rychlejší na analytiku. Warehouse a vše ostatní furt běží tam, ale analytici už hrozně často chodí přímo do Snowflakeu a píšou si tam své dotazy. Vidíme to třeba i v Tableau v reportingu, kde reporting, který byl původně nad on-premem, teď přesunul většinu práce do cloudu.

Opravený text:

Když si lidi přepínají na ty tabulky ve Snowflakeu, protože jim ten reporting dobíhá rychleji, tak vlastně už část banky postupně přesouváme. Teď je třeba vymyslet, jak přesunout i vývoj a celý ten core někam do cloudu, protože tam bude všechno průhlednější a člověk bude moct mnohem víc optimalizovat. Load v Erausu je jasný – většina probíhá někdy v noci nebo ráno, tam to běží naplno, a pak zase odpoledne to železo nemá využití. Když to budeme mít v cloudu, můžeme si ráno vzít víc výkonu a odpoledne ho už neplatit, takže to určitě dává smysl. Jo, napadá mě spousta historie…

Jako z pozadí, jo? Je mnoho kolegů, kteří za námi vlastně byli tady v rámci týmu a říkali: „Hele, my ty selekty a analytiku píšeme do Snowflakeu, připravím si tam SQL, a když to potřebuji nasadit do pipeline, vezmu to SQL a deploynu do Oracle.“ Protože, jak jsme zmiňovali, dialekt mezi Oracle a Snowflakem je téměř totožný, takže onboarding lidí je výrazně jednodušší. Z mého pohledu vlastně vše, o čem se tady bavíme, do 50 % stojí na lidech, takže nám to trošičku hrálo do karet, že adopce je snadná. Lidi samozřejmě díky tomu, že Snowflake je OLAP databáze, ne transakční jako Oracle, dostávají mnohem rychleji výsledky u velkých dotazů, které procházejí například transakcemi nebo eventy – opravdu vzhledem k velikosti tabulek je to pohodlnější práce.

Ještě, když jsi zmiňoval, že dnes máte Snowflake buď jako stand-alone, nebo direct Snowflake, jak bys to doporučil? Jaký je rozdíl mezi používat Snowflake jako backend Kebuly, tedy databázovou část Kebuly, versus používat Snowflake napřímo? Proč se ptám je, že u spousty jiných věcí jsem viděl Kebulu a Snowflake jako velmi komplementární produkty. Jak se všechno platformizuje, decoupluje, centralizuje, mám pocit, že nové funkce Kebuly zasahují do Snowflakeu a naopak nové funkce Snowflakeu zasahují do nabídky Kebuly. Je to tak?

Je to tak, vidíme to na trhu, na všech platformách. Všichni se nějakým způsobem kanibalizují nebo opisují od sebe, jak se říká. Každopádně Snowflake je hodně zaměřený na datové sklady a inženýrství dat. V poslední době přibylo spoustu self-service capability, spoustu funkcí kolem AI a podobně. David to možná okomentuje – děláme i nějaké porovnání a feasibility analýzy. Kde ještě Kebulu použít, kde není vhodná. Stále si myslíme, že v mnoha projektech pro nás Kebula má přidanou hodnotu, protože žádná z těch velkých platforem – ať už Snowflake, Fabric nebo další – nenabízí tolik ergonomie self-service, která umožňuje práci lidem mimo IT, tedy přímo v businessu.

Jasně, tady je opravená verze textu s úpravou gramatiky, interpunkce a stylistiky, aby byl text plynulejší a srozumitelnější:

O více lidí ještě nemají. Jestli tam ty platformy budou driftovat, podle mě uvidíme v následujících dvou letech, možná i rychleji, protože ten trh je teď velmi dynamický a s nástupem AI a podobně mám pocit, že to ještě více akceleruje. A můžete si tam doplnit, co chcete. Přidal bych k tomu srovnání: když vezmeme lidi podle pracovního profilu i v bance, tak například vývojář, který byl zvyklý bušit nějaké SQL do Oracle, tvořit balíky a podobně, tak podle toho, co jsme zjistili, ze Kebuly úplně nadšený nebyl. Je tam totiž hodně „klikaček“, mnoho věcí Kebula dělá za člověka a má samozřejmě i nějakou režii. Vzhledem k tomu, jak je postavená, si například v transformaci vyrábí workspace, jsou tam příkazy, které když člověk dělá přímo na databázi, vůbec nemusí spouštět.

Když tedy člověk chce budovat velké, komplexní řešení typu Data Warehouse, nějaké velké analytické úložiště a podobně, mám za to, že raději vybere přímý přístup přes Snowflake, na kterém si to udělá sám. Uděláme tedy ten Direct Snowflake, ale zároveň to máme zjednodušené díky připraveným patternům. Máme model-driven přístup, kdy člověk připraví businessovou transformaci, vloží ji – dneska to máme v Power Designeru, ale chceme to do budoucna přenést jinam – nakliká si, že chce SCDčko nebo Merge, a systém mu to automaticky obalí, protože SCD a Merge jsou pořád stejné, není potřeba to pořád psát do kola. Je lepší mít to řízené jednou pořád stejně. Když chci úpravu, děláme to všem díky řízení metadat. Pak to nasadí normálně na Snowflake a jede to.

Takže tam máme takový lehký self-service, i když je to složitější self-service – je tam GitHub, člověk musí umět pull requesty a podobné věci, ale vývojářům to samozřejmě mnohem víc vyhovuje, těm, kteří jsou přímo vývojáři a jsou zvyklí třeba pracovat s Oracle. Na druhou stranu, datoví specialisté, kteří umí výborně SQL, ale tenhle vývoj jim přijde jako totální overhead, protože nemůžou dávat přidanou hodnotu a nemají použitelné případy, kde by bylo potřeba zajistit testování a produkční automatizaci – to není „víčko“, není to produkční automatizace.

Direct Snowflake máme řešený plně – v integraci s různými testovacími prostředími, vývojovým procesem, s klasickým CI/CD pipeline a tak dále. Je to vlastně plnohodnotný software engineering lifecycle vývoje.

Naopak Kebula platforma se primárně používá jen nad produkcí, development se rozděluje v rámci projektu do různých větví nebo workspace, ale je to spíše BI než engineering. I automatizace v Kebula Flow je jednoduchá – klikáte krabičky, vybíráte komponenty, co tam máte, a můžete si ji přímo v tom flow definovat. Pro Direct Snowflake máme mimo to vlastní interní aplikaci, kterou jsme vyvinuli velmi zjevně…

Pokud byste chtěl, mohu pokračovat s opravou i další části textu, jen mi dejte vědět.

Tady je opravený text s upravenou gramatikou, interpunkcí a formálnější strukturou, přičemž zachovávám původní význam a styl:

Je to jednodušší, ale furt to nemá tak výrazný výraz jako třeba Kebula, takže pro vývojáře je to v pohodě. Někdy však ještě musí upravit metadata, dát nějaké příkazy do databáze nebo spustit procedury. Na druhou stranu pro nějakého byznysáka, který potřebuje rychle výsledky, je Kebula úplně ideální. Podle mě, když člověk najde správnou rovnováhu, kdy se už daný use case vyplatí dávat mimo Kebulu – protože například už tam může být nějaká režie, kterou by člověk zbytečně platil – tak se vyplatí využít třeba Snowflake. Myslím si tedy, že obě platformy mají své uplatnění.

No a jak vypadá váš stack? Předpokládám, že v něm není jen Kebula a Snowflake, že tam máte ještě nějaké starší systémy. Když se na to podíváme, jak velkou část celého datového světa máte podchycenou jen Kebulou a Snowflakem, co tam máte dalšího? Mě zaujalo, že pořád používáte Tableau – když jste zmiňovali, jak se vlastně dostalo do spořky, tak klobouk dolů, že v rámci vašeho Microsoft-Kebula-Snowflake stacku stále běží Tableau. To je zajímavé.

Promiň, já bych řekl, že Kebula a Snowflake pokrývá zhruba 50 % workloadu svého stacku. Primárně jsme jako banka založená na Oracle, navíc máme ještě v některých liniích MS SQL Server, tedy on-premisovou část. Takže bych odhadoval, že využití je dnes asi zhruba 50:50. Samozřejmě pokud vezmeme tvorbu dat, tam vládne Oracle, protože celý data warehouse je na Oracle a všechno vychází z něj. Ale z pohledu uživatelů, tedy analytiků, už převažuje cloudový svět, protože Snowflake má rychlejší reakční dobu na dotazy a podobně.

Dále máme ještě Databricks platformu, kterou jsme využívali hlavně pro personalizaci, marketing cloud, přípravu kampaní, ML a datovou vědu. Nyní jsme po nějaké reorganizaci opět interní společný tým a teď rozšiřujeme assessmenty s ohledem na migraci datového skladu. Budeme přecházet na Snowflake, nebo na Databricks, nebo na jejich kombinaci. Snažíme se na to najít odpovědi, protože určitě si všichni všimli, že firmy v digitálním prostoru se často předhánějí a dávají do stejné roviny, že obě platformy dělají to samé. Naše detaily však ukazují, že to vůbec není pravda.

Každá firma vychází z trochu jiného přístupu. Snowflake je orientován na datový engineering a relační databáze, kdežto Databricks má základ v Hadoop stacku a Spark technologii. Ty platformy pak doplňují své funkce, a to mě vrací zpátky k těm RFPčkům a assesmentům. Mám možná trochu obavu, že i přes naši zkušenost nejsme vždy schopní všechny informace stoprocentně zpracovat tak, aby na papíře výsledek odpovídal realitě. To možná uvidíme příště, jak to dopadne.

Na úrovni cloudového hyperscaleru jste…

Pokud chcete, mohu pokračovat s přepracováním další části textu. Rád pomohu.

Jasně, tady je opravený a plynulejší text:

V Azure? My jsme na úrovni Azure, máme pár služeb v AVS, kde to většinou používáme primárně jako gateway pro některé aplikace. Jak jsem zmínil, nakupujeme hodně software jako službu a paradoxně spousta tohoto software běží právě na AVS. Začínáme se jako skupina, nebo banka, bavit o high resiliency a multicloudovosti vzhledem k současné geopolitické situaci. Momentálně to není hlavní téma, ale myslím si, že v nejbližších letech to pro nás bude velké téma.

A teď takový slon v místnosti – Fabrik, když už mluvíme o Azure. Možná se rychle vrátím k Tablu, abychom dodělali ten stack Tablu, což pak Fabrik nějak naváže. Měli jsme v bance Cognos, pak přišlo Tableau někdy v letech 2018–2019 a kolem 2022–2023 jsme se rozhodli, že všechno nakonec poběží v Tablu, takže jsme opustili Cognos. Samozřejmě teď narážíme na různé věci a RFPčka a všechno ukazuje, že to jde, ale incentívní reporting, kam chodí tisíce lidí denně, je někdy náročný.

Na začátku to bylo velmi “dýchavičné”, teď se to zlepšilo, ale stále řešíme, co dál. Tableau máme teď on-premise, řešíme cloudovou variantu, nebo co s tím. A co myslíš tím “dýchavičný”? Myslíš, že to nestíhalo počítat? No, vlastně se točilo kolečko, kdy člověk na pobočce zapnul report a čekal třeba pět minut, než se načetl. To ale nikdo z pobočky nechce — chtějí okamžitě vidět, jak jsou na tom s prodejem a jestli budou mít nárok na odměnu.

To samozřejmě není ideální, protože lidí na pobočce je hodně a potřebují data hned. Reporty byly velmi detailně vymazlené, ale ukázalo se nám, a to se špatně simuluje, že velká konkurence uživatelů najednou, třeba mezi 7:30 a 8:00, kdy naráz otevře stejný report 600–800 lidí, vytváří problém. Tableau provádí bezpečnostní kontroly, aby každý bankéř viděl svůj vlastní pohled, takže to opravdu působilo problémy s výkonem.

Cognos v tomto ohledu fungoval lépe a nyní nám to otevírá možnosti, začínáme se bavit i na úrovni celého holdingu, jestli zůstat u Tableau nebo přejít na Power BI, protože některé země v holdingu používají Power BI a některé Tableau. V tom se nám začíná otevírat zelená i kolem Fabriku, protože jak asi posluchači vědí, Power BI se stalo součástí rodiny Fabrik. Když chcete rozšířit Power BI, tady je Fabrik.

Měl jsem hypotézu, že se to stane až příští rok, ono se to ale stalo už tohoto léta, takže to určitě budeme pozorovat. Jsem velmi zvědavý, co se na trhu v následujících dvou letech bude dít. Myslím, že Microsoft pravděpodobně začne v rámci Azure stacku víc prosazovat svůj…

Pokud chceš, mohu pokračovat nebo ještě více upravit.

Tady je opravená verze textu, kde jsem se snažil zachovat původní obsah a styl, ale upravil jsem gramatiku, interpunkci a stylistiku pro lepší čitelnost:

Cooling, svoji datovou platformu, a jsem vlastně zvědavý, jak to bude fungovat v tom třídním boji Snowflake, Databricks, Fabrik — na to jsem osobně zvědavý a netroufám si teď úplně předjímat. Tak jak říkáš, že jsi zvědavý, co se bude dít další dva roky, díky. Asi nejvýznamnější složkou, která do toho vstupuje, je AI, konkrétně Gen AI — a dneska to požralo všechno, to je slon v místnosti, velké téma. Tak mě zajímá, na té první straně, Davide, co Self Service adopce? Říkal jsi, že vám to už vlastně četlo GPT a hodně vám to pomohlo, dál ten trend roste, a učíte v datové akademii ještě SQL, to je moje první otázka. A potom na tebe, Honzo, jak to vidíš v těch platformách, v use casech – jak velká část vaší práce je vlastně Gen AI?

Davide: Určitě GPT a vlastně všechny podobné AI platformy pomohly uživatelům při vývoji, protože teď už nemusí hledat něco na Google nebo Stack Overflow, kde často byla jedna nesmyslná a dvě pravdivé odpovědi. Teď si mohou povídat s jedním chatbotem, který jim poradí. Takže i to SQL už tolik lidí nevyžaduje naučit se nazpaměť, protože jsou schopni s chatem GPT SQL dát tak nějak dohromady. V rámci Kebuly jsme taky adoptovali AI. Je ale potřeba říct, že protože jsme v regulovaném prostředí, adopce AI věcí nejsou vždycky jednoduché. V Kebule jsme řešili dvě AI funkce: vysvětlování chyb, kde člověku chatbot poradí, kde má pravděpodobně chybu, a druhá věc je psaní dokumentace — chatbot se podívá na metadata těch transformací a vypíše, co transformace dělá z pohledu metadat, třeba že bere data odněkud, ukládá do tabulky, v SELECTu bere ty a ty atributy. Tyto věci jsme úspěšně adoptovali v Kebule, ale bylo to právě na začátku AI. V bance nám trvalo i půl roku, než se to protáhlo.

Je potřeba, když člověk pracuje v regulované organizaci, všechny věci s AI dobře vysvětlit a společnými silami dotáhnout, aby to dávávalo smysl, aby nebyl proces schvalování use case na půl roku, ale zároveň aby se dodržovaly evropské normy a směrnice — aby nebyl průšvih, nikdo neotevřel data tam, kam nemá.

My v Kebule také dost benefitujeme z toho, že backend je na Snowflake — Honzovi se s týmem povedlo adoptovat Snowflake Cortex, máme tam LM functions, které člověk může používat v SQL. Tyto funkce mohou využívat i lidé v Kebule, protože kdyby je SQL funkce, mohou si je zavolat i v Kebule. Díky tomu můžeme využívat AI, kterou nabízí Snowflake, a udělala se jedna adopce, nemuseli jsme to adoptovat zvlášť na Kebule, což je velká výhoda toho, jak si platformy navzájem…

Pokud chceš, mohu upravit ještě další části textu nebo zkrátit, aby byl styl uhlazenější a profesionálnější.

Tady je opravený text s přehlednější formou a opravami gramatiky a stylistiky:

Když se lezou do zelí, tak vlastně teď jsme z toho profitovali, protože jsme nemuseli dávat dohromady adopci třeba komponenty Gen.ai, kterou má Kebula, protože máme nabídku z Snowflakeu. Díky tomu, že jsme s nimi strávili dost času, ta funkce by byla dost podobná té, kterou nám už nyní nabízí Snowflake. Proto je potřeba se i takhle dívat, co jednotlivé platformy nabízejí, a nemuset adoptovat všechno, protože se to pak překrývá a úsilí, které do toho vkládáme, je zbytečné i z pohledu nákladovosti pro banku.

To je zajímavé. Takže já jdu do Snowflakeu, tam si generuju kód, který potom skládám v Kebule, nebo to mám…

Přesně tak. Ve Snowflakeu si připravíš a odladíš transformaci, pak ji dáš do Kebuly, do transformace, a uživatel technický v Kebule má právo zavolat třeba tu LLM funkci. Můžeš tak využívat klasifikaci nebo něco podobného, co je vybudované ve Snowflakeu. Udělali jsme si jednu adopci nad Snowflakeem a funguje nám to.

Pro uživatele to tedy funguje ve dvou platformách, ale vlastně stále jako jedna.

Super, takže to nejde jen o generování SQL, ale přímo o functions a automatizaci v rámci pipeline.

Ano, přesně tak. V rámci datových platforem používáme copilota, který umí třeba na základě promptu generovat i nějaký příkaz. Banka začala velmi brzo s ChatGPT. Byli jsme mezi šesti sty firmami Microsoftu po celém světě, které adoptovaly GitHub Copilota a Office 365 Copilota, takže to byla velká výhoda pro širší použití.

Mně to přijde úplně skvělé. Kdybyste se mě před patnácti lety zeptali, která banka je nejhorší a nejzastřešnější, řekl bych Česká spořitelna. Mám ale dojem, že za posledních deset let se to totálně otočilo. Česká spořitelna je tady už 200 let na trhu, a dnes do toho šlapete šíleně tvrdě.

Souhlasím s tím. Když jsem byl dítě, měl jsem tam spořicí účet, pak jsem přešel k nějaké modernější bance, která byla více digitální, ale pak jsem se rád vrátil do spořitelny. Naší dlouhodobou strategií je být opravdu fintechovou firmou, velmi moderní, máme skutečně moderní technologický stack a jdeme naplno za nejnovějšími trendy. Myslím, že i IT brand na Venexu se změnil a obecně brand spořitelny se hodně proměnil. Dneska je to opravdu moderní fintechová společnost západního kalibru.

Byl jsem na konferencích ve Spojených státech a myslím si, že se vůbec nemáme za co stydět, držíme krok s aktuálními trendy a nezaostáváme.

Promiň, skočil jsem ti do řeči ohledně AI, ale je super, že jste mezi šesti sty firmami, které v tomto šlapou.

Díky tomu kolegové z AI oddělení připravili, jak zmiňoval David, interního chatbota na k…

Pokud chceš, mohu vám ještě text více zjednodušit či upravit do formální nebo neformální podoby.

Tady je opravený text:

Bylo zde Chat GPT, který mohou využívat všichni zaměstnanci ve spořitelně, včetně lidí z poboček a podobně. My jsme ale vlastně přišli se Snowflakem s žádostí o novou adopci, protože se jedná o SaaSovou službu. Tuto žádost posuzovala naše AI pracovní skupina, kde jsou i právníci, zástupci GDPR, Compliance, a posuzuje se DORA, Evropský AI Act a podobně. Nakonec jsme adoptovali platformu, která nakupuje různé modely a hostuje je u sebe v bezpečnostním perimetru.

To bylo trochu něco jiného, než jsme byli zvyklí u AI používat, takže tento proces trval zhruba šest měsíců a byl velmi náročný. Díky tomu jsme ale Snowflake Cortex adoptovali jako platformní službu a dneska může prakticky jakýkoliv business tuto AI využívat. David zmiňoval například LM functions — nejčastější současné use cases jsou analýzy nad různými recenzemi, ať už jsou od našich externích nebo interních zákazníků, včetně manažerských 360° hodnocení.

Takže to tam velmi dobře funguje. Ty týmy pak tato řešení často zapouzdřují do Kebuli, kde mají zbytek pipelineů. Aktuálně řešíme další funkčnosti, například chatboty a knowledge boty nad těmito daty. V tuto chvíli jsme spíše v POC (proof of concept) fázi a zároveň vyhodnocujeme rizikovost těchto systémů, protože příslušné oddělení pečlivě rizika posuzuje.

Jako banka nemůžeme okamžitě vytvořit AI systém, který automaticky ovlivní klienty na základě výstupu, protože to je považováno za rizikový systém. Primárně proto nyní směřujeme k uvolnění využití AI v oblasti analytiky. Když jste analytik, nechcete ztrácet týden i déle tvorbou reportu v Tableau, ale chcete se jednoduše zeptat na nějaké insighty. Můžete mít například dlouhodobé křivky a trendy, ale chcete vědět třeba, proč dnes došlo k propadu nebo kolik jste včera prodali produktů. Věříme, že právě tam je budoucnost AI u datových platforem — přímo tam, kde leží data, nechceme, aby bylo AI umísťováno na externí systémy, kam je třeba data nejdříve integrovat.

Tento přístup má ovšem jeden velmi důležitý aspekt, který si teprve začínáme plně uvědomovat a který se snažíme do organizace zavést. Zmínili jsme zde datovou governance, např. pomocí Kebuly. Pro AI je klíčové, aby byl dobře popsán náš byznysový kontext, data samotná, jejich ontologie a vzájemné vazby. Pokud to neuděláme dostatečně, AI z toho nevykouzlí žádná užitečná „moudra“.

Myslím, že tohle bude možná naše nová éra. Doslova jsme saturaci datových platforem dosáhli na svůj limit. Nyní se budeme více zaměřovat na správu dat, byznysové popisy a semantiku, aby AI mohla správně fungovat a přinášet užitek. Tímto způsobem se také bude řešit i problém, že i jednoduchý report na začátku může být pro byznysové uživatele neúplný nebo matoucí.

Pokud chceš, mohu text ještě více upravit pro lepší strukturu či jazykovou úroveň.

Tady je opravený text s úpravou gramatiky, interpunkce a stylistiky pro lepší srozumitelnost:

Jeden detail za druhým, detaily se v reportu pomalu množí, až se to tam úplně zaplevelí. Zpočátku je tam pořádek, ale pak ten člověk chce vidět report jednou, a když zjistí, že je v pořádku, už do něj moc nenahlíží. Přitom se tam pořád přidávají další detaily, a po dvou letech je report jako přídící deska letadla – člověk se v něm vůbec nevyzná. Kdybychom byli schopní zachovat jen ty hlavní trendy a klíčové informace a měli k tomu chatbot, který by dokázal s uživatelem interagovat – například vysvětlit, proč něco spadlo, nebo dodat detail týkající se obchodů – mohli bychom reporting držet dlouhodobě konzistentní. K tomu by byl chatbot, který by rozuměl údajům v čase a měl dostatečnou jistotu, že nebude odpovídat nesmysly. To je důležité, aby se byznys neřídil chybnými daty a nečinil opatření na základě halucinací.

Takže co pro vás znamená governance? Nebo Kolibrat? Zní to hezky – jasně, potřebujeme více metadat, co nejlépe popsanou semantickou vrstvu a dostat ji do systému. Protože jazykové modely s námi nechodí do kuchyně, nevědí, kdo je kdo, a nevědí, že v daném oddělení se marže počítá jinak. To jsou obecné věci, ale co konkrétně to znamená a v čem to je pro vás těžké?

Dám příklad s marží – problematické je, že organizace je velká a má různá oddělení – risk, finance, retail, korporát a další. Už třeba pojem marže nebo úroková míra může na různých odděleních znamenat něco jiného a definice se liší. Myslím, že problém spočívá v tom, že dnes nemáme dostatečně popsaná business data. Regulativní data máme popsána dobře, jsou na ně směrnice a je to tu zavedené dlouho, tam to musí být jasné. Ale u byznysových dat to tak nebylo.

My přinášíme nástroj, který to umožní – Pavlík to umožní – ale nejtěžší bude všechno dostatečně popsat. Když mluvíme s týmy a business uživateli, zjistili jsme, že je velice těžké vysvětlit, co jejich data vlastně znamenají. Často mají nějakou metriku, ale nevědí přesně, co do ní vstupuje za aspekty. To bude teď asi nejtěžší část. Technologicky je propojení business metadat s technickými daty a vytvoření chatbota relativně jednoduché – to uděláme rychle. Ten popis dat je ale tvrdý oříšek.

Už jsme se podělili o nějaký proof of value pro tým Pavlíny, říká se tomu „datový butik“. Byl to vlastně Excel, kde byly vypsané atributy s českými popisy, co znamenají, u složitějších byly i kalkulace ve Skvělku. Fungovalo to tak, že když se tým fakt sešel s byznysáky, probírali spolu, co ta data znamenají, jak to počítají, jak si představují, co je pro ně klient, a tak dále.

Pokud chceš, mohu text ještě dále upravit nebo zestručnit podle potřeby.

Zde je opravená verze textu:

Takhle. Všechno se to pak zapsalo do Excelu, což nebylo úplně nejlepší řešení, ale pro nějaký Proof of Concept to stačilo. Takže v bance reálně máme nějaký postup, který se ověřil pro konkrétní use case, a teď musíme vymyslet, jak to přetavit do Kolibry – do nástroje, kde to bude dostupné všem, kde se s tím bude lépe pracovat a lépe se budou dělat provázky. Když například klikne člověk na klienta, měl by tam vidět třeba deset podpojmů různých klientů – například korporátní klient, retailový klient a podobně. A to je potřeba tam zapracovat, na tom právě pracuje tým Pavlíny Vajgarové.

My se snažíme jako cloudová nebo datová platforma podpořit to, že obecně popisování – jak dokumentace – nikdo moc dělat nechce. Snažíme se proto podpořit důležitost toho, aby všichni pochopili, že když do toho teď investujeme úsilí a budeme se skutečně věnovat popisu dat, můžeme pak těžit z AI. Už jsme si ukázali některé možnosti v rámci knowledgebotů nad daty.

Pokud data nejsou popsaná, nezískáme z nich žádnou hodnotu. Když chceme být rychlejší a dělat méně reportů, nechceme, aby to byly kokpity jako od Boeingu, tak musíme opravdu věnovat čas a investovat do popisu dat, abychom z toho začali profitovat. Věřím a trochu doufám, že právě propojení s AI pomůže více naplnit i oblast governance, aby celý ekosystém zapadl sám do sebe. AI, data, governance – celý ten trojúhelník nám umožní získat benefit.

Kolibra má tu výhodu, že už Pavlína dokázala do ní natáhnout všechna metadata, takže uživatelé nemusí opisovat sloupečky z tabulek, jak tomu bylo dřív, ale mohou tam radši dopisovat obsah. A když přijdou s potřebou nějakého AI use case, máme v tu chvíli páku, aby se nad tím zamysleli, sedli si ke Kolibře a už mají nástroj, není to jen nějaký Excel, ale systém, kde jasně vidí, jak mají data vyplnit. Ze systému pak jsme schopni data vzít a začít je používat pro AI use case – například vytvořit yamly a podobné formáty, které potřebuje Snowflake, a dodat mu detailní informace.

Když mluvíme o AI use casech, kde je vidíte? Zatím to vypadá spíš jako nástroj osobní produktivity, pilotní projekt. Honza mluvil o NLP – zpracování sentimentu, prostě odemklo to NLP a najednou máme out-of-the-box jeden z nejlepších NLP modelů, velmi levný. To je jeden příklad. Kde dál vidíte potenciál? Trochu jsem měl dojem, že mluvíte o chatbotech, že to není to pravé zlato. Kde tedy vidíte to skutečné zlato do budoucna?

Zatím ne, ale myslím, že důležitý mezikrok budou datově orientovaní knowledgeboti. Platformy, které v bance používáme, stále více tímto směrem směřují. Jakmile se nám povede naplnit byznysová metadata, budeme schopni vytvářet tyhle knowledge boty…

Pokud chcete, mohu pomoci text ještě víc zestručnit nebo upravit styl.

Zde je opravený text s vylepšenou gramatikou a plynulostí:

Knowledge boty mi dávají insajty na data, nemusím kvůli tomu dělat reporty. Ale myslím si, že to nebude hned v nějakém krátkodobém horizontu. Ta dlouhodobá strategie – alespoň jak vnímám trh – podle mě směřuje víc k nějakým agentním AI. Já jako manažer nebo byznysák se podívám na KPI report, zjistím nějaký propad, pak si s chatbotem pokecám o tom, co se stalo a proč tam ten propad je. On mi třeba odpoví, že jsme včera prodali málo daného produktu, nebo že centrální banka na trhu změnila úrokovou sazbu. Pak můžu rovnou dát chatbotu nějaké prompty s akcemi, co se mají stát, nebo on mi ty akce navrhne. Může spustit další nástroje – například rozběhne marketingovou kampaň, pošle maily, informuje manažery, pošle informace třeba do cenotvorby produktů a tak dále.

Takový stav zatím nemáme, myslím, že bude velmi těžké to prosadit v rámci regulatorního prostředí, aby z AI insights rovnou startovaly různé pipeline. Ale myslím si, že se tam časem dostaneme, i když to bude dlouhý proces.

Co se týče self-service přístupu, zatím nejsme na úrovni, kdy by si člověk psal s platformou, jako je Keboola, která to už dnes částečně umí (a tenhle koncept kluci teď připravují) – člověk by napsal „udělej mi pipeline, chci vidět nějaké prodeje“ a platforma by začala připravovat i SQL. Teoreticky by to šlo více otevřít i laickým uživatelům. Otázka ale je, kdy narazíme na problém, že uživatelé, kteří datům úplně nerozumí, napíší dotazy, které nedávají smysl. Jak to dopadne, pokud napíšou něco špatně, a systém jim to neodmítne, protože chtějí dělat věci, které se vlastně dělat nedají – například sčítat a dělit věci, které se sčítat a dělit nemají. Může to ale pomoct těm, kteří se v datech nějak orientují, ale nechtějí se učit SQL nebo jiný jazyk, protože příprava v těchto jazycích jim přijde zbytečně náročná.

Tyto věci bychom rádi využili, i když uvidíme, co vše budeme schopni adoptovat v bance, aby to nebylo v rozporu s regulacemi, a aby to bylo pro uživatele skutečně použitelné. Někdy totiž narazíme na to, že podle regulí nejsme schopni udělat daný use case.

Ještě doplním, že si nemyslím, že SQL nějak zanikne. Pamatuji si ze své kariéry hype kolem Hadoopových technologií, kdy se říkalo, že se vše bude dělat ve Sparku a SQL už se nebude používat procedurálně. O několik let později ale tyto technologie spíš zanikají a SQL tady stále je. I knowledge boty nebo funkcionály jako CortexAnaly, Database Genie a další na pozadí překládají přirozený jazyk do SQL, které skutečně pak vrací výsledky. Takže myslím, že SQL bude i nadále mít svou zástupnou roli, možná i větší.

Pokud chcete, mohu také text zestručnit nebo upravit styl pro konkrétní použití.

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

Analytici to opravdu nebudou psát, ta analytika opravdu přejde jen do přirozeného jazyka. Ale stále si myslím, že budeme ještě mile překvapeni, že SQL zůstane skvělé – tady to ještě klidně 10–20 let vydrží, a vůbec bych se tomu nedivil. Ten jazyk je totiž tak jednoduchý a kolem databázového světa mi přijde jako stavební kámen, kolem kterého se pořád všechno točí. Takže na to jsem sám zvědavý, ale fandím SQL, myslím, že s námi tady ještě dlouho bude.

Já si taky myslím, že SQL hned tak nezmizí, že tady s námi ještě nějakou dobu bude, stejně jako Excel, i když těch „zabijáků“ bylo dost. Chtěl bych vám poděkovat, že jste takhle sdíleli radosti i obtíže přechodu do cloudu. Klobouk dolů za to, co děláte ve spořitelně – jdete příkladem, protože právě vy byste mohli být jedni z posledních, kdo to přijmou, a přitom jste jedni z prvních, kdo technologie aktivně adoptují a měníte se v technologickou firmu.

Co byste za vás označili za hlavní „lessons learned“? Co byste poradili těm, kdo do roku 2021 ještě nebyli v cloudu, nebo těm, kdo se na to teprve připravují? Jaké zkušenosti jsou univerzální, které si chcete z tohoto období zapamatovat?

Možná začnu tím self-service, které je takovou podnoží před přechodem. Pro mě bylo určitě důležité, aby platforma, na kterou se nasazuji self-service, byla co nejjednodušší. Ukázalo se nám to třeba na projektu Significa, kde nebyla úplně jednoduchá – byly tam příkazy, které lidé nevěděli, proč tam jsou.

Další důležitá věc je postupně pracovat na změně mindsetu lidí. Když někoho učíte něco nového, je ideální dát mu k dispozici návody, vytvořit komunitu, pravidelně ho informovat o novinkách, být těsně s ním v kontaktu, pomáhat mu s konkrétními use case – ne jen říct: tady máte platformu, dělejte si to. Je lepší ukázat první příklad, první transformaci a podobně.

Při migraci je pak klíčové všechno naplánovat, promyslet a dobře vykomunikovat, aby všichni věděli, co se bude dít, jaký bude postup a co je čeká.

A nakonec, vzdělávání – u nás hodně pomohla datová akademie, kde se lidé mohli naučit pracovat s Tableam, Qubelem, Oraclem a poznat data ve warehouse. Mít jednu osobu, která tuto akademii táhne, je v tak velké organizaci opravdu potřeba. Tohle všechno velmi pomohlo k tomu, že self-service dnes funguje, jak funguje.

Děkuji ti, Honzo. Já souhlasím se vším, co řekl David, a pokusím se doplnit. Když se snažím řešit víc strategické věci, tak v rámci assessmentů a různých RFP je důležité myslet na to, že nikdy nemohu pokrýt všechno stoprocentně. Vždycky riskuji, že…

Pokud chceš, můžu pokračovat s opravou i zbytku textu, který nebyl zcela dokončený.

Opravený text:

Olí jako svědomí, ale možná to, co bych doporučil, je neotáčet to kolem té technologie. Neotáčet cloudovou cestu tak, že zlevním někde náklad. Takhle se to managementu vlastně nedá prodat. Je potřeba se na to dívat víc z pohledu organizace. Kde nám to přinese přínos? Kde nám to zrychlí byznys? Jakou to pro nás bude mít propozici? A opravdu se nedívat jenom na tu technologii. Ta technologie je jen třetina nebo jeden dílek skládačky, ale je potřeba se podívat na celou organizaci. Kolik tam mám lidí, kteří pracují s daty? Jaký mají skillset? Jaký dnes používají tooling? A to hodně ovlivní výběr i výsledné technologie. Ta technologie je ve finále jenom nějaký vehikl, který tě veze celou cestou.

To znamená, že dnes bys dělal RFPčka jinak? Nebo dnes děláš RFPčka jinak? No, třeba když děláme i ty assessmenty, nebo nás čeká nějaké RFP v rámci reportingových nástrojů, tak se opravdu snažíme víc dívat na organizaci, na procesy a na byznysovou hodnotu. Nejenom na technologii, ale brát ji opravdu jen jako jeden kousek. Všimni si, že v tomhle jsme se jako posunuli.

Takže tohle bych určitě vypíchl. Pak bych se hodně zaměřil na práci s komunitou a opravdu tam získat fanoušky, nadšence, protože se to potom začne v organizaci velice šířit – vzdělávání, co už tady zaznělo. A nějaký tip a trik? Já myslím, že je samozřejmost nakoupit interní stakeholdry a tak. Funguje ti datový smídaně – když je tam jídlo, tak lidi přijdou, pochválí je, dávají jim beže nebo diplomy nebo…

Jsou tam nějaké „dirty tricks“ rychlé? My jsme dělali třeba pro Kebulu meetupy, kde Kebula vždycky přinesla nějaký merch, ale je to i o tom, že ten člověk přijde do platformy. Já mu neříkám, že je to nejlepší platforma na světě, chci něco udělat a říkám: „Tady tohle uděláš úplně jednoduše, ale má to zase jiné výhody.“ Připomíná mi to, že když je člověk k lidem upřímný, tak oni pak řeknou: „Jo, tohle tady nejde, ale jde tady tohle.“ Není to takové, že děláme reklamu, že je to nejlepší na světě a nic lepšího člověk nemůže potkat. Říkáme i bolístky nebo na ně upozorníme, když se lidi onboardují, a myslím, že pak to pomohlo.

Plus pomohlo to, že jsme využili naše známosti, které jsme nabyli před tím, že jsme dělali datové specialisty. S těmi lidmi jsme pracovali a pomalinku jsme vyrostli, takže pořád je plno lidí, se kterými spolupracujeme a které známe, třeba jsme s nimi byli v týmech. Takže na začátku vytipovat a motivovat každého jednoho… Vytipovat, motivovat. Nejen školení, ale dáváme lidem k dispozici různé certifikace, zveme je v rámci Datové akademie třeba na různé konference, pořádáme knowledge sharingy s různými firmami v rámci našich setkání a to všechno drží komunitu v životě a pomáhá adopci.

Co bych určitě vypíchl, je prostě neb- (text zde končí).

Opravený text:

Podívej se na ty cesty, jo. Já teď vnímám na tom českém trhu, že opravdu spořka je lídrem, co se týče cloudifikace, jak aplikačního portfolia, tak toho datového. Ale důležité je, aby si firmy uvědomily, že každý krok je nějaký krok, jo. Prostě vydat se na to, jo. Bavili jsme se tady o AI a o spoustu dalších věcech. To bez těch cloudových center není možné, jo.

Mám občas pocit, že v tom je trošičku takový despekt, ale spousta firem má dneska privátní datové centrum, které někde outsourcuje u nějaké firmy. Teď to už je vlastně cloud, jo. Cloud není místo, cloud je princip obsluhy a toho, jak přistupuju vlastně k těm věcem. A ve finále v těch public cloudech, o kterých jsme se tady bavili, je mnohem vyšší zabezpečení, než má nejmodernější datové centrum v Čechách, jo.

Takže možná jen takové poznámky, jaké firmy nebo která země vlastně šla nejrychleji do cloudu v posledních letech. Víte, kdo to byl? Byly to ukrajinské banky. Protože právě ten cloud přinesl vysokou bezpečnost a možnost vysoké resiliencie, geolokační zálohy a vlastně se v tom cloudu posouvat. Dává to smysl.

No, takže tohle jenom vypichuju – opravdu se toho nebát a opravdu do toho rozhodnutí jít, podpořit to vzděláváním nějakým silným lídrem, kdo bude hlavou toho vzdělávání, najít prostě nač se vydat na tu cloudifikační cestu a nebát se těch změn, jo. Mně přijde, že občas trošku ta naše česká kotlina trpí tím, že nejsme naučení jít do změny, jo, nebo bojíme se chyb, jo. Pro nás je chyba nepřítel, ale možná bychom tu chybu měli brát trochu jinak – jako kámoše, a když se spálíme, tak to opravíme a něco se naučíme. To bych asi doporučil posluchačům.

Najít určitě takové ty early adoptery, kteří pomůžou vyladit problémy, než to člověk rozjede po celé bance a ví, že ten základ určitě funguje.

No, co je vaše mise na příštích 12 měsíců? Protože z toho, co tady povídáte, tak hodně věcí už jste odmakali, že ne jen řešíte, ale na rozdíl od jiných firem to není první a poslední a 90 % rozpočtu a všechno, tak mi přijde, že k tomu přistupujete smysluplně a odspodu – od dat a metadat – aby to bylo takzvaně AI ready data. Co je pro vás teď ta mise?

Tak za mě z technologického pohledu je to určitě dotáhnout ještě ty assessmenty, kam finálně půjdeme s tím datovým skladem, a jestli se do toho pustíme už letos, nebo jestli to ještě na nějakou dobu zaparkujeme. Teď to musíme taky podpořit nějakým business casem a tak dále.

A co se týče třeba AI obecně a toho self-service, tak já tam vidím jako důležitost právě začít dělat to rozdělování nákladů. Nejenom ukazovat to týmům od začátku, ale opravdu to přesunout do jejich linií, a tak, jak jsme dělali enablement datových věcí, tak víc začít dělat enablement AI věcí na datech. A tam ten náklad je opravdu velice důležitý, tam si musím zvážit, jestli ten business case vyjde pozitivně, nebo ne.

Jistě, tady je opravený text:

O AI, co si budeme povídat, na to není úplně levný. A je vlastně zajímavé, že spousta firem nebo u některých use case se vrací k tomu standardnímu machine learningu, protože ten nás dnes vyjde levněji. Takže tohle si myslím, že bude takový nový skillset, který si budeme muset osvojit a dostat mezi lidi.

Můj teď velký cíl je připravit něco, čemu říkám Activity Centrum Viva Nula, právě pro přehled, aby lidé věděli, kolik je stojí jejich projekt, kolik mají nejdražší transformace a podobně, pro budoucnost.

Transformaci toho, že to budeme schopni přeučovat dál, tak aby lidé už teď měli průhledné využívání a nákladovost svých projektů. A pak takový sen, který nevím, jestli se povede, kdy vlastně Kebula má MCP server, člověk už by mohl začít trochu přesněji ten self-service dělat, takže půjde psát s Kebulou. To bych rád začal nějakou adopci a nějak to dostal do banky, protože si myslím, že to zase může hodně posunout to, jak rychle lidé v Kebule budou schopni pracovat, a může to otevřít další možnosti lidem, kteří tam dneska nepracují, ale mohli by, a zvýšilo by to jejich efektivitu.

Skvělé, tak končíme MCP serverem, to je hezky future-facing agenda. Děkuju moc, Honzo, Davide, držím palce, věřím, že se tady nevidíme naposled a až budete mít gen AI use case více, nebo už budete mít assessment nového warehouseu, nebo jakoukoliv další novinku, tak klobouk dolů před vaší prací ve Sportce a těším se na další setkání.

Jirko, díky za pozvání, bylo to příjemné a doufám, že si to posluchači užijí.

Já moc děkuji za pozvání, výborná zkušenost pro mě, díky.

Děkujeme, že jste doposlouchali až sem. A díky taky našim partnerům a členům Data Talk klubu. Těmi jsou: Index, Saska, Bystreet, Colors of Data, Revolt BI, GoodData, Kebula, Emark, Carl Data Company, Datamind, 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 zaregistrovat k odběru našeho týdenního newsletteru na datatalk.cz.

Nechť vás provází data.

Pokud chcete, mohu text ještě více upravit do formálnější podoby nebo naopak do hovorovější.