Podcast

Zde je opravený text s drobnými úpravami pro lepší čtivost a gramatickou správnost:

Dobrý den, moje jméno je Jirka Vichrek a vítám vás u dalšího dílu podcastu Datatalk. Mými dnešními vzácnými hosty je dvojice BI specialistů ze společnosti eMark – Martin Hažer, seniorní BI specialista. Ahoj Martine.
Ahoj.
A Jirka Noheil, což je BI specialista a zároveň školitel. Ahoj Jirko.
Ahoj.

Naším dnešním tématem, které si projdeme s Martinem a Jirkou, je implementace BI v menších firmách nebo ve firmách, které s BI nemají moc zkušeností, často pracují hlavně v Excelu a staví velký BI systém na zelené louce. Budeme se zaměřovat hlavně na zkušenosti kluků s nástrojem Qlik, který mnozí z vás dobře znají, ale předpokládám, že budete stejně jako já překvapeni, jak univerzální je a jaké velké možnosti nabízí.

Než se pustíme do našeho tématu, představte prosím eMark. My jsme tady měli vašeho kolegu, šéfa Rada, ale to je už nějaký čas, tak co je eMark?

eMark vznikl na Slovensku kolem roku 2000 a za těch 25 let si tam vybudoval poměrně silnou pozici. V posledních 15 letech působíme i na českém trhu, kde máme kanceláře v Pardubicích a Praze. Naším hlavním zájmem je tedy Československo, ale působíme mezinárodně, především v rámci širší skupiny eMark, vlastně na všech obydlených kontinentech.

Klientům poskytujeme datová řešení – ať už se jedná o pomoc s digitální transformací, datovou analytiku na míru nebo třeba školení. Abych náš tým trochu zařadil v rámci technologického stacku, největší část naší činnosti je Business Intelligence. Dlouho jsme byli synonymní s Qlikem, ale v současné době se snažíme arzenál rozšiřovat, můžu zmínit například Power BI, integrační nástroje Talend, cloudové tooly, Snowflake a podobně.

Říkám to trochu honosně, aby bylo jasné, že my jsme s Martinem oba téměř výhradně klikaři a implementační zkušenosti a projekty, o kterých se dnes budeme bavit, jsou právě z Qlik Sense. V tuto chvíli máme asi 70 vývojářů a naše největší klienty – například OnlyCrate, Leasing, PPL, Orange, Foxconn, Asset – o mnohých z nich jste určitě slyšeli.

A máte teda spoustu i těch menších klientů, nebo takových, co teprve začínají s BI?
Ano, v rámci konzultací se často dostáváme i k klientům, kteří mají prvotní zkušenost, tedy staví si BI na zelené louce. My jim tím pádem pomáháme zašít celý proces – od úvodních konzultací až po kompletní adopci BI.

Super. Teď už víme, co dělá eMark, tak jaký je váš příběh? Jak jste se do eMarku dostali? Martin, ty jsi služebně starší, tak ti dám přednost.

Já jsem absolvent Fakulty elektrotechniky a informatiky v Pardubicích, kterou jsem absolvoval v roce 2015. Už v rámci diplomové práce jsem chtěl směřovat svou kariéru – přišla mi nabídka, že bych mohl diplomovou práci tvořit pro jednu menší pardubickou firmu, která se zabývá BI. Kývl jsem na to a díky tomu jsem získal i první zaměstnání. Takže v podstatě hned po škole jsem nastoupil.

Pokud potřebujete pokračovat nebo text dále upravit, dejte vědět.

Opravený text:

Voják, dejme tomu programátor. Co byl tvůj stack? Můj stack bylo všechno možné, dalo by se říct, protože my jsme v tu dobu dělali jeden větší projekt pro Skypicker, což je současné Kiwi.com, známý přeprodávač letenek. A tam jsme stahovali data z různých bankovních bran. Takže tam to bylo hodně různorodé – od .NETu, přes PHP. A pracovali jsme s jednou technologií, která mi hodně přirostla k srdci, což dříve byl Clover ETL, teď je to Clover DX. Rád bych se k práci s tímto nástrojem někde vrátil.

Zatím nebyla příležitost, ale je to v podstatě technologie, na kterou rád vzpomínám. Což v podstatě byl i ten můj problém, že mě zpočátku klik tolik neoslovil. Možná to bylo tím, nebo jak já říkám, že to bylo tím, že jsem se nedokázal přepnout z programátorského myšlení do analytického. Ale to se časem změnilo a ten klik jsem si taky oblíbil. Takže to byl takový můj přechod z programátora ke výstupovému analytikovi.

A s klikem ses setkal poprvé v tehdejším Skypickeru? Tam používali klik?
Ano, přesně tak. Respektive my jsme ho tam implementovali s tou pardubickou firmou. Zajímavé.

No, co se dělo pak?
Pak se objevil eMark, takže jsem začal pracovat pro eMark. Tam už jsem přes 7 let, takže jak už říkal Jirka, jsem BI specialista, plus mám takový přesah do našeho COG týmu – Customer Operation Group – která se stará o instalace, péči a různé administrátorské věci. Takže do toho mám taky přehled.

Takže něco vývojářského jsi opustil?
Určitě ne. Teď mám vývojářské práce spíš víc než těch COG věcí, ale furt máme pravidelné COG meetingy, kde konzultujeme a řešíme problémy. Když někdo potřebuje něco zkonzultovat a já vím, že v tom jsem silný, tak se ozve a pomáháme si takhle.

Co tě přitáhlo do eMarku, Jirko?
Moje cesta k datům byla o něco méně přímočará. Přišel jsem z humanitních věd a místo dostudování na postě jsem prchnul dělat reporty do korporátu, všude samej Excel. A jak to bývá, člověk chce zjednodušit práci, začne experimentovat se zakázaným ovocem – psaním v code a care? (poznámka: pokud „care“ není překlep, lze doplnit) Najednou je to málo, potřebuju víc, silnější nástroje. Po takovéhle šikmé ploše jsem se sunul a přistál v eMarku vlastně bez formálního IT vzdělání. Když to trochu přeženu, kolegové si při psaní kódu pomáhají výrokovou logikou a já literární analýzou. Poslední tři roky působím v eMarku jako BI specialista a školitel. Na projektech často spolupracuju s Martinem, na kterého se můžu opřít hlavně co se týče programátorských zkušeností a tvrdší data science.

A tvůj stack je tím pádem klik a programátorsky jsi si osvojil nějaký jazyk?
Mám drobný přesah do PowerShellu a Pythonu, kde si tím pomáháme. Klik je dost schopný jako orchestrátor, může si načítat i externí aplikace, takže právě nějaké drobné úpravy v těchto jazycích.

Pokud bys chtěl, mohu ještě text upravit do plynulejší podoby nebo lépe přizpůsobit konkrétnímu účelu. Stačí říct.

Tady je opravený text s úpravami, které zlepšují srozumitelnost a gramatickou správnost, přičemž zachovávají původní kontext:

Sám napíšeš, můžou rozšířit ten nástroj tím způsobem, kdy je potřeba zhruba dočistit ta data, udělat konverzi, kterou ten nástroj neumí, a podobně. A jak se z tebe stal vrchní školitel a někdo, kdo takhle pomáhá s adopcí? Vrchní školitel asi úplně ne. Tam mě vlastně pomohlo, že jsme slovenská firma a nemáme tolik lidí s češtinou, kteří by chtěli mluvit. Na tom jsem si vystavil svoji školitelskou kariéru. A je to taková srdečná záležitost – školení a přednášení, ať už přímo pro klienty, nebo v současné době spolupracuji s Mark Slusenburskou univerzitou, kde zajišťujeme praktičtější části jejich Business Intelligence trainingu. Super.

Já bych možná Jirku doplnil, že má i výborný přednes, protože prováděl na českých hradech a zámcích. Jo, takže byl průvodce po českých hradech a zámcích a teď provádí takříkajíc „klikem“. Chápu.

No, tak teď, když známe vaši story, pojďme se podívat na příběhy těch klientů, kteří jsou téměř nepolíbení v BI, kteří žijí ve světě Excelů. My jsme se tady bavili, že je rozdělujete do čtyř fází, do určité maturity spolupráce s vámi. Já bych možná začal tím – co je tím impulzem? Kdy to začne? Kdy firma zjistí, že jí Excel nestačí?

Tak určitě jsou tam nějaké vlastní pokusy, kdy se firma snaží – slyšela to někde, ví, že BI je dobrý, nebo že je to další krok v konkurenceschopnosti, tak si sami zkoušejí něco implementovat. Ale poměrně často nás překvapuje, že za tím stojí jeden člověk. Ať už někdo získal zkušenosti z BI jinde a pak to dobro dál předává.

Nebo to je někdo, třeba šéf oddělení, který se rozhodl, že si to vezme sám na triko a dotáhne to. Setkáváme se s oběma přístupy: někdo, kdo se naučil BI někde jinde, spolupracoval s námi v jedné firmě, přechází i k nám, zjistí, že tam nic ještě není, a dotáhne tam tyto věci. Nebo někdo takový, řekněme zodpovědný nebo odvážný, kdo si to celý vezme na triko a dotáhne firmu přes tu síťovou čáru implementace.

Takže stačí jeden odvážný, aby to rozjel. Líbilo se mi, jak říkáš, BI je dobro – to si dokážu představit jako náš merch – a BI je dobro, takže stačí jeden. Máte nějaký příklad toho, že opravdu jeden člověk to utáhne?

Určitě bych mohl jmenovat, a je to i nedávná minulost, jako příklad uvedu Super ZOO, což asi každý zná. V podstatě to byla společnost, kde byl Klik zaveden, ale celý vývoj si dělali sami. Pak se v controllingu společnosti změnilo vedení a novému vedení se nelíbilo, kam se to ubírá. Nedařilo se jim to dobře kontrolovat, takže bouchli do stolu a řekli: „Pojďme to probrat s odborníky.“ Ozvali se nám.

My jsme přišli do prostředí, kde nebyla dobře sdílená znalost, nebylo tam žádné ETL, takže uživatelé si aplikace mezi sebou nezdíleli, a s tím bylo potřeba něco udělat. Takže tam jsme byli my a v podstatě jsme tam zavedli prvotní ETL v Kliku. Vlastně jsme vytvořili aplikace tak, aby nebyly určeny jen pro jednoho…

Pokud chcete, mohu opravit i zbytek textu, případně ho dále zkrátit a zpřehlednit.

Opravený text:

Člověk, ale aby se data dala sdílet napříč celou tou společností. Takže na začátku si to každý dělal po svém ve své části a vůbec nad tím nepřemýšlel. A zrovna v té SuperZoo byl jeden driver, který dokázal vzít své oddělení, prodat svoji vizi, poslat nás tam a dostat firmu k překotnému rozvoji BI. Za rok až rok a půl jsme se dostali z nuly nebo z nějakých prvotních pokusů až k plné implementaci včetně plánování. Takže to je krásný use case toho, jak jeden člověk může tímto způsobem posunout věci dál.

Někdy je impulzem i externí faktor, asi všichni známe ten známý vtip: kdo uvedl vaši digitální transformaci – CEO, CTO nebo COVID-19? I s tím jsme se setkali, že digitální transformace byla vyvolaná externím tlakem, ale ve většině případů, se kterými se setkáváme, je to právě buď člověk, který přišel odjinud, kde BI fungovalo dál, nebo ten zodpovědný člověk, který se rozhodne, že takhle to bude vypadat.

My, když přijdeme do takových firem, zkoumáme, jakým směrem se data sdílí, jestli tam existuje nějaká struktura Data Warehouse. Pokud ne, není to problém, my ji postavíme. Jedna z velkých výhod našeho kliku je, že obsahuje ETL a vlastně si kvazi Data Warehouse uděláme rovnou my. Není potřeba další externí nástroje, což se mnohem lépe prodává byznysu, protože je třeba jen jedna věc a budeme schopni vystavět celou strukturu.

Když tam jsou nějaké vlastní pokusy, díváme se, jakým způsobem ty aplikace fungují – jestli jde o jednorázové řešení nebo ne. ETL neboli Extract, Transform, Load architektura je něco, bez čeho se v dlouhodobém horizontu neobejdeš. Když máš report na jedno použití, může vypadat dobře, ale při bližším pohledu se to rozpadne.

Jestli můžu vypůjčit příklad Zimmermana: jeho zubní protéza, veselý železný čář vyrobený ze sádry. Má vysokou glance value, ale když ji chceš znovu použít, narážíš na limity řešení, respektive na sádrovou pěnu. Naší snahou je tedy přesvědčit stakeholdery, že je potřeba nějak strukturovat data, vystavět alespoň elementární data warehouse a s ním pak pracovat. Ušetří to hodně práce v dlouhodobém horizontu.

Martine, potkáváš u těch zákazníků nějaká jiná řešení, že už mají data warehouse nebo BI? Ve většině případů narazíme na Excel. Excel vládne světu. A jaká je úroveň sofistikovanosti těch Excelů? Někdy se podíváme, co vše na Excelu vlastně běží. Občas narazíme na OLAP kostky v kombinaci s Excelem, což je takový primární pokus o BI. Co si říkáš, když narazíš na Excel s OLAP kostkou? Ono to v podstatě hodně brzdí vývoj BI platformy, řekl bych, že to není správný směr.

Takže OLAP kostky už jsou přežité. Když přijdete do firmy a vidíte, že mají aplikace a další věci, konzultujete to a vidíte, že jsou na začátku, ale je tam šampion, který to chce tlačit, co je další fáze? Jak začít přechod od Excelové struktury někam do modernějšího světa? Je potřeba si ujasnit…

Opravený text:

Musíme si ujasnit ty požadavky, které bude mít šampion. Jestli se jedná o nějaký jeho konkrétní report, kde je stakeholder, který chce přesunout třeba nějaký sales report v kontrolingu, případně s výhledem do potenciálního plánování, nebo jestli chce celkově začít školit lidi v BI myšlení a postupně přecházet dál a dál, rozšiřovat implementaci do dalších oddělení.

Dále musíme vyřešit hardware, jestli bude řešení v cloudu nebo on-premise. Často bývá jednodušší přesvědčit někoho, aby si nainstaloval aplikaci lokálně na své vlastní zařízení, které má pod kontrolou, než řešit cloudové řešení, které může lidi vyděsit tím, že podpora není přímo lokální a může dojít třeba k půldenní odstávce kvůli problémům s autentizačními servery nebo podobně.

Proto se stále často řeší, kde bude systém nainstalovaný, jak bude fungovat, jak se bude přizpůsobovat infrastruktuře firmy zvenčí i zevnitř, a jak bude interagovat s jejich technologickým stackem. To znamená, zda mají nějakou databázi, účetní systém, který má otevřené servery, zda existuje API rozhraní, přes které si můžeme načítat data, a podobně.

A co Excel? Samozřejmě Excel připojujeme, ale ideálně se snažíme dostat přímo k primárním zdrojům dat, odkud uživatelé exportují data do Excelu – třeba ze SAPu, účetnictví apod. Chceme jít na ty primární zdroje, protože je důležitá ETL vrstva – extrakce dat přímo z těchto zdrojů, následné uložení dat tak, aby bylo snadné je rozšiřovat bez nutnosti opakovat práci, transformace a čištění dat podle jejich kritérií nebo pomocí doplňkových tabulek, které mají, a nakonec nahrání do koncové aplikace.

Nejde nám o replikování Excelů, ale o přístup k primárním zdrojovým datům, tedy k takzvané „nutné vrstvě“ dat.

Jaké jsou typické první projekty, které pro ně děláte? Máte nějaký preferovaný typ projektu, nebo to záleží na šampionovi? Jsou první projekty a implementace různorodé napříč segmenty a use cases, nebo je zřejmá jasná preference, například reporting nebo sales, protože finanční data jsou většinou v pořádku?

Většinou to závisí na diskuzi se šampionem, ale rozhodně to konzultujeme, vyslechneme si zadání a dohodneme se, co by mohlo být optimální pro daný případ použití, tedy pro POC (proof of concept).

Co se často objevuje? Sales reporting nebo finanční reporting jsou typické projekty, často v kombinaci s pozicí, o kterou se snažíme. Často také dostáváme atypická zadání, protože se snažíme implementovat v BI nástroji i writeback funkce – tedy rozšířit funkcionalitu tak, aby uživatel mohl zadávat data zpět do systému. Tím vznikají POC například na kompletní HR systémy nebo třeba tiketovací systémy, což je už trochu vyšší dívčí, ale stává se, že to klientovi ukazujeme jako první věc.

Plánování, HR systém nebo neb… (text končí nedokončený)

Opravený text:

O vůbec řízení nějakého procesu prostřednictvím klikání a zadávání zpětných dat v BI nástroji. Takže ho vlastně vedete hodně brzo do aplikace místo reportingu. Chápu to správně? Je to občas náš positioning, taková naše noha ve dveřích, že se prostřednictvím těchto přidaných hodnot writebacku dostaneme k nim, abychom implementovali, a pak to začneme rozšiřovat o ty běžné use case, to znamená finanční reporting, credit control a podobně. Jak jsou velké ty první projekty? A zase asi hrozně záleží, ale máte nějaký sweet spot, když byste měli radit jiným konzultantům nebo lidem, co jsou in-house — jaký je rozsah, který se dá uřídit, jaká je vaše zkušenost, jak nastavit ten první projekt? Když tomu hodně věříme, tak ještě…

Takový „seeing is believing“ stage, to znamená vyvineme něco na omezených datech klienta úplně bez jakýchkoliv řešení financí a to pak demonstrujeme. Ale realistické je, že se snažíme spíš dohodnout na něčem, co bude vypadat slušně za pět, šest, sedm mendejů, abychom se dostali někam, kam potřebujeme. Za tyto vyšší jednotky mendejů jsme schopni postavit i rudimentární plánování, prototyp nebo něco podobného. A na základě nějakých steering meetingů s klientem, kde to vidí a může si to upřesňovat, pak přejdeme rovnou třeba na agilní vývoj, kdy se bude dodělávat a doplňovat funkcionalita do toho POC řešení, které jsme demonstrovali.

Mohl bych určitě zmínit jedno POC, týkající se závozů odběratelů, kde jsme zpětně vyhodnocovali zavážení odběratelů dodávkami. Využili jsme rozšíření Click Geonalytics, což je rozšíření kliku o geolokální analýzu, a vyhodnocovali jsme ty závozy oproti nejkratší a nejrychlejší cestě. Co to znamená, jak si to mám představit? Že jsme měli realitu — tedy dodávky, které jely po určité trase a měly na trase několik zastávek — a zpětně jsme vyhodnocovali, zda ta cesta, kterou jely, byla optimální, ať už z pohledu ujetých kilometrů (tedy nejkratší), nebo z pohledu časového (tedy nejrychlejší trasy). Takže to bylo spíše plánování „pozadu“? Spíš takové zpětné vyhodnocení, ze kterého pak jsme diskutovali, že na základě toho by mohl vzniknout i systém odměňování dopravců, kteří jezdí efektivně.

Za nás mohu zmínit ještě jednu zajímavou věc, na níž se podílel český tým — vyhodnocování testových otázek pro nejmenovanou příspěvkovou organizaci Ministerstvo školství. Klik jsme použili jako orchestrátor, tedy spojili jsme více aplikací v kliku, protože se jednalo o stále BI záležitost, tak klik byl hlavní aplikací, která všechno řídila. Klik spouštěl Python skripty, které volaly OCR, vyhodnocovali jsme rozkouskované části testových otázek, využívali jsme více OCR systémů, aby nám vracely výsledky, a mohli jsme přímo při návratu hodnotit validitu odpovědí. Pak jsme to poskládali dohromady v BI nástroji na frontend a prostřednictvím writebacku jsme umožnili hromadné opravování, například u otázky, která měla…

Pokud chceš, můžu text dál doladit nebo upravit podle konkrétního stylu či požadavků.

Opravený text:

10 000 studentů odpovědělo stejně, a mohl si 10 000 otázek vyhodnotit jedním kliknutím tady na počet hvězdiček nebo počet bodů, který byl udělený. To zní jako dost velký POC, to asi nebylo následnou Mendeju. Já myslím, že jsme se snažili na sedu, ten frontend podle toho vypadal. A ten bych asi nikde neprezentoval, ale co se týče technologického pozadí, to bylo tak zajímavé, že jsme na tom rádi dělali v podstatě zadarmo. Super, no tak máme hotový POC, jak vás tak poslouchám, tak to je velká škála řešení, tak si to neděláte moc jednoduché na týhle business logice. POC se povedlo, tak co se děje dál? Potom to škálujete oddělení po oddělení, nebo už máte tu důvěru a jdete za boardem a jdete měnit všechno najednou? Jaká je vaše zkušenost, vaše strategie u menších firem, které s BI zatím nemají zkušenosti? Firma získává zkušenosti v rámci jednoho oddělení a začínají se objevovat lidi z dalších oddělení, kteří by chtěli něco podobného. Snad se to prodává dál – buď šampionovi, nebo nám – a postupně se to rozšiřuje. Z čistě jedné firmy na matku, nebo nějaký, jak říkám, přesun na více oddělení, víc nástrojů, specifičtější projekty. A v téhle chvíli nastávají i takové výzvy, které jsou vysoce jisté v tom, jak se to rozšiřuje. To znamená, musíme si pořádně dořešit datový stack, data warehouse, jestli budeme nadále v Qliku, který na naprostou většinu dostačuje, anebo budeme spolupracovat s něčím jiným – třeba když jsme v cloudu, tak bychom šli do Snowflake a podobně. Jestli je potřeba transformace datového základu, nějaké řízení a správa procesů, section access – to znamená, kdo bude mít kam přístup a podobně. To je taková kritická doba, kdy sice…

Najednou začne masivní enablement pro všechny, že všichni chtějí BI aplikace, ale pro nás teď přichází období růstu, práce na tom, aby se to všechno stabilizovalo a při tom rozvoji to nepřerostlo v chaos. Martine, za tebe, ty jsi blíž tomu kódu, tak kdy už ti nestačí ten kvazi Data Warehouse v Qliku a kdy potřebuješ skutečný Data Warehouse? Mně přijde, že tedy OK, máme nějaké řešení v Qliku, který umí všechno, a pak máme super pokročilý Snowflake, tak mi to přijde zajímavé – že tohle je váš tooling. Tak kdy ti nestačí Qlik?

Tak já myslím, že jedna strana mince je velikost nebo objem dat, a druhá strana mince je to, jestli Qlik používáme on-premise nebo v cloudu. Pokud používáme on-premise, tak tam je hodně na nás, kde si vlastně architekturu stavíme sami. Pokud jsme v cloudu, tak už určitě dává velký smysl použít například Snowflake jako data warehouse.

A jak moc si rozumí Snowflake s Qlikem? Qlik se Snowflakem? Velmi. Vím, že mezi nimi existuje partnerství, takže jsou často na společných akcích, a vím, že podpora Snowflaku v Qliku je opravdu na velmi solidní úrovni.

A ještě jedna otázka, co znamená kvazi Data Warehouse? Když se podíváme na „warehouseovou“ vrstvu v Qliku, jak si to mám představit? Kde to začíná a kde končí? Tam je to v podstatě dělané tak, že…

Tady je opravená verze textu:

Takže data se ukládají do tzv. QVD souborů, což jsou Qlikem optimalizované soubory. Máme to rozdělené do různých vrstev, jak se říká extract, transform a load (ETL). Většinou si vystačíme právě s těmi třemi vrstvami. Možná nevýhoda je, že pokud bychom chtěli data posílat dál, tak málo aplikací je schopno číst QVD soubory. Jedna z možností, která je podle mě fajn, je využít Qlik API, které umožňuje získávat data přímo z koncových aplikací pomocí API volání. To znamená, že data lze napojit na ostatní systémy nejen jako ETL pipeline, ale přímo přes API.

Když jsme v cloudu, tak vzhledem k tomu, že datový transfer ze systému zákazníka do cloudu se zpravidla neobejde bez nějakého mezikroku, obvykle není možné připojení úplně přímo, je potřeba nějaký další nástroj. Proto dává smysl data ukládat v Data Lake nebo Data Warehouse nástrojích typu Snowflake, Azure Synapse či podobně, kde se rovnou zajistí jejich opětovné použití, protože datovému transferu stejně neujdeme.

To je také chvíle, kdy při transformaci firmy do BI procesu se snažíme co nejvíc omezit používání Excelu. Na začátku se často využívají Excelovské číselníky, řídící dokumenty apod., které slouží jako zdroj pro Qlik, ale postupem času chceme, aby byla data i s těmito doplňky spravována přímo v BI nástrojích. S uživateli konzultujeme, aby neexportovali data z Qliku do Excelu, ale aby si raději vytvářeli vlastní reporty v rámci self-service. Chceme je v Qliku držet, aby využívali všechny výhody, které platforma přináší a aby nepřicházeli o efektivitu každodenní práce.

Z mého pohledu je to největší výzva právě u lidí, kteří dlouhodobě pracují s jedním rozsáhlým Excelovým souborem, do kterého každý zadává data a pak přijde někdo s novým řešením v Qliku. Je to ta transformace, která vždycky bolí – naučit člověka používat novou aplikaci na svém počítači. Určitě je to záležitost především podpory šampionů v jednotlivých odděleních, často i nadřízených.

Co my nabízíme, díky Writebacku, je možnost říct uživatelům „toto je Excel, ale mnohem lepší“. Můžeme se postavit do role, kdy lidem neubereme funkce, ale naopak jim přidáme nové možnosti. Mohou spolupracovat, vkládat sdílené komentáře, prolinkovat je, vytvářet bookmarky, které odkazují přímo na konkrétní stav aplikace, a sdílet je s celým týmem.

Snažíme se proto při školeních i běžné práci využívat Writeback tak, aby číselníky, které dříve udržovali v Excelu, mohli spravovat přímo v Qliku. Vypadá to úplně stejně, funguje tam Ctrl-C, Ctrl-V, lze kliknout na reload aplikace a všechny změny se okamžitě projeví a vidíte jejich dopad. To výrazně urychluje práci, a na tento cíl směřujeme.

Ještě bych dodal otázku hardware, protože samozřejmě, jak adopce probíhá a přibývají datové nároky, je potřeba přemýšlet i o technickém zázemí…

Pokud potřebujete pokračovat nebo doplnit, dejte vědět!

Zde je opravený text s úpravami pro lepší srozumitelnost, plynulost a správnost:

S přibývajícím počtem sad a aplikací samozřejmě může dojít ke zpomalení klikovského prostředí. Výhodou ale je, že se jedná o multinodové prostředí, což znamená, že může být složeno z více serverů, z nichž každý má na starosti jiný úkol, pokud to tak řeknu. Navýšení hardwarových zdrojů pak přispívá k tomu, aby bylo prostředí opravdu rychlé a aby s ním uživatelé mohli pohodlně pracovat.

To vše platí pro on-premise řešení, zatímco cloudové prostředí škáluje automaticky díky autoscalingu. Přesně tak. Jak je tedy klik cloudový – jaký máte poměr cloudových a on-premise klientů? Já musím říct, že se hodně orientuji na on-premise zákazníky, takže o cloudu může více říct Círka, který je v tomhle směru pokročilejší. Dalo by se říct, že naši největší klienti jsou už téměř výhradně cloudoví. Když ale přebíráme nějaké větší, již zavedené prostředí, často jde o on-premise, kde je z důvodu bezpečnosti dat stále preferováno interní řešení. Vnímá se to jako jednodušší způsob kontroly nad vlastními daty. U nových klientů je to zhruba 50 % na 50 %.

Klik oproti tomu nabízí poměrně jednoduchou on-premise implementaci: přijdu, nainstaluji ho na server, nastavím potřebné množství RAM a jedu. V porovnání třeba s Power BI, kde je potřeba složitější příprava, ETL procesy a podobně. Budoucnost ale podle klik vidíme jednoznačně v cloudu – všechny nové funkce se nejdříve dostanou do cloudového prostředí a trvá třeba půl roku nebo déle, než se většina z nich postupně přenese do on-premise verzí. Do budoucna to tedy vypadá, že poměr cloudových klientů bude stále růst.

Jirku bych ale trošku opravil. Myslím si, že náš největší zákazník je Foxconn, který na cloudu zatím není. Migrace by tam byla dost komplikovaná. Foxconn je náš dlouhodobý zákazník a zajímavé je, že ho podporujeme bez přístupu do jejich prostředí. Support probíhá přes komunikaci s osobou z Foxconnu, která má klik na starosti. Takže když dojde k nějakému problému, řešíme to se správcem, který je třeba v serverovně v Prostějově.

Ne úplně – support probíhá skrz sdílenou obrazovku nebo nám posílají hlášení, co klik vyhazuje, a my na základě toho i díky zkušenostem a komunitě hledáme příčinu problémů. Myslím, že velmi dobře známe jejich architekturu a klikovské procesy, což je hlavní klíč k tomu, abychom mohli i na dálku analyzovat a řešit potíže.

Když zůstanu u Foxconnu, což je opravdu velký klient, co všechno tam v kliku běží? Jak velkou část jejich BI řešení klik tvoří? Já si myslím, že velmi velkou. Je to tam rozdělené i na divize, takže každá divize si pak třeba vybírá…

Pokud byste chtěl zpracovat celý rozhovor nebo pokračovat v textu, dejte vědět.

Ještě sama. Tam je důležité, že tam mají člověka, který se stará o Klick, ten se stará spíš o ty ETL a koncové aplikace. Každé oddělení pak má své vlastní developery. Vím, že data z Klicku byla dokonce i ve výrobě na monitorech, kde ukazovala aktuální stav. Takže výroba využívá data a ještě nějaké use case, například reporting nebo HR systémy, určitě reporting.

Finance jsou tam hodně široké, je tam spousta uživatelů a opravdu hodně aplikací. To už člověk možná ani nespočítá. Jak na to Martin narazil, u Foxconnu je to už takové dospělé prostředí. V těchto případech je přidaná hodnota těžší k nalezení, protože firma si většinou už dokáže postavit vlastní BI oddělení, které si aplikace vyvíjí samo. My se pak dostáváme jen ke speciálním případům, takovým extrémním situacím, kde si jejich datový tým neporadí. Je to zajímavé, ale znamená to také, že vidíme většinou ty nejtěžší problémy, se kterými se setkávají.

A jaké jsou ty nejhorší problémy, které řeší? Můžu zmínit třeba Porsche, které jsme převzali a to je opět poměrně dospělé prostředí, rozvíjené v průběhu zhruba 10 let. Jsou tam klíčové business-critical procesy, které stále běží. Architektura je na jediném serveru, všechny procesy tam běží, a když to začnou uživatelé používat ráno, zpomalí se to. Musí všechny reloady (bez ohledu na kumulaci) nechat doběhnout v určitou dobu. Pokud je úkolí optimalizace, musíme se ponořit hluboko do skriptu, zjistit, jak to autoři mysleli, než to fungovalo – jedná se o provázané systémy, kde často ani neexistuje dokumentace, takže je to hodně o analýze na místě. Musíme zjistit, jestli by se to dalo udělat lépe a rychleji. To jsou typické výzvy, kterým čelí pokročilejší zákazníci, kteří už nějaké BI mají, často hodně pokročilé z minulosti.

Pro mě je zajímavé, že Porsche a Foxconn používají Klick. Pro mě je to jedna z méně populárních technologií, ale díky vám, Emarku, vidím její sílu a kde všude se používá. Proč lidé pak přecházejí, nebo máte zkušenost, že jdou do Power BI? Bavíme se hodně o firmách, které jsou v Excelu, tedy v Microsoft prostředí. Microsoft velmi rád a vehementně nabízí Power BI. Jaká je vaše zkušenost? Jak často to řešíte? To musí být denní chleba, ne? Mohli byste udělat srovnání Klicku a Power BI?

Určitě tohle řeší hlavně sales tým. My také vyvíjíme v Power BI, nesnažíme se být konkurencí Klicku, spíše vybíráme nástroj, který nejvíc splní požadavky klienta. Minimálně u implementace na „zelené louce“ hodně pomůže, že máme vestavěné ETL.

Co se týče konkurenčních výhod Power BI – pokud jste v cloudu, což je moderní přístup a předpokládám, že manažer směřuje tímto směrem, a pravděpodobně máte Office, pak je jen malý krok používat Power Query…

Jsi vytvořil nějakou základní extrační architekturu, zaplatil si pár licencí na Power BI a používal jsi nějaký datalek, třeba od Microsoftu, kam si všechna data nahrneš. Takže to rozhodně nechci přímo srovnávat. Oba nástroje mají své výhody i nevýhody.

Z našeho pohledu v Kliku je robustnější zejména ETL architektura a skriptování, protože spoustu věcí můžeme vyřešit na jednom místě. Když srovnám Power BI aplikaci, se kterou jsem nikdy nepracoval, a klikovskou, navíc klik má ten skript soustředěný na jednom místě, nemusím tolik zkoumat, kde co bylo vymyšleno. V Power BI jsou extrační a transformační nástroje často rozptýlené jinde, například v DAXu a podobně.

Jak už Jirka řekl, pro nás je denním chlebem porovnávání ClickSense a Power BI. Snažíme se být multiplatformní, jak zmínil kolega Jirka. Mám ale dost případů, třeba zákazníků, kteří měli Qlik a snažili se přejít na Power BI, ale nezdařilo se jim to. Jeden zákazník začal komunikovat hodně odtažitě, občas až agresivně, a my jsme moc nevěděli proč. Komunikoval s námi minimálně a až zpětně jsme zjistili, že se pokoušeli naše klikovské řešení přepracovat do Power BI, což se nezdařilo. Pak se nám ozvali a požadovali podporu a komunikace už byla na mnohem lepší úrovni. To je jeden příklad.

Druhý příklad mám z nadnárodní společnosti, obchodního řetězce, kde mateřská společnost v Belgii doporučuje Power BI jako platformu, ale oni už mají běžící Qlik prostředí, třeba s velmi zajímavou aplikací, která dohledává data až na úroveň položky na účtence. To je právě naše řešení, kvůli kterému jsme museli trochu upravit prostředí. Měli jsme tam jeden přístupový server s jedním terabytem RAM, což není obvyklé, ale aplikace šlapala velmi dobře.

Migrace u tohoto zákazníka trvá už druhým nebo třetím rokem a vím, že mají úspěšnost kolem 50 %. Hlavně u těch větších aplikací je podle mě Qlik lepší, pokud se jedná o velké datové sady. V tomto ohledu je Qlik výrazně napřed oproti Power BI. Někdo Big Data nemá rád, někdo je preferuje, ale v těchto pokročilých prostředích je těžké něco nového vymyslet.

Naše přidaná hodnota leží tam, kam se soustředíme — například v rightbacku používáme nástroj Infinity Forms, který zapisuje zpět do databáze, a díky tomu jsme schopni vytvořit něco, co si v běžném BI nástroji člověk ani nepředstaví, například plánování.

Právě teď předvádím aplikaci, která kombinuje statistické a AI nástroje, aby se předgeneroval výrobní plán, do kterého je ale stále možné manuálně zasahovat a doladit detaily. Součástí je hodnotící část, kde po několika měsících můžeme porovnat, jaké výsledky vygeneroval statistický model, co přineslo machine learning, a jak to odpovídá vstupním údajům od zkušeného odborníka. Podíváme se, co mělo největší váhu, co dopadlo nejlépe a co bylo nejpřesnější.

A to všechno postavíš v Qliku.

Jasně, tady je opravený a lehce upravený text pro lepší srozumitelnost a plynulost:

Už jsi to viděl, jo?
V Kliku, v kombinaci se zpětným zápisem a případně dalšími nástroji. Klik v cloudu má možnost přímo integrovaného machine learningu, takže si na pár kliknutí rozjedu učební modely. A pokud jsem on-premise, můžu zapojit třeba Python – to jsou plánovací moduly, neforecastovací moduly jako Profit, Odmety a podobně.

Takže máme i integrované nástroje pro předpovídání časových řad. Je velký rozdíl udělat všechno v Excelu, kde je plánování hlavní doménou, ale strašně špatně se tam s těmi daty pracuje. S writebackem si můžeš udělat prognózu pomocí machine learningu, pár manuálních úprav a pak jediným klikem aplikovat jednotlivé plány, které pak vidíš přímo v grafech nebo na dashboardu.

Soustředíme se tedy na to, aby naše nejpokročilejší aplikace směřovaly tímto směrem, protože tam vidíme opravdovou hodnotu a uživatelské zkušenosti jsou poměrně dobré.

No a jak to myslíš s velkou customizací? V čem to píšete? Přímo v prostředí Kliku, kde si jen házíte “what you see is what you get” kostky a komponenty, nebo chcete doprogramovávat v nějakém jazyce, případně rovnou vkládat Python? Jak to funguje?

Záleží na složitosti, kterou chceš. Úplně základní plánování, nepočítaje statistické komponenty, zvládneš s writebackem. Používáme Infinity Forms, abychom mohli zapisovat zpět do databáze a vytvořit něco jako Excelovskou tabulku, ale s výhodami BI – tedy plnou provázaností na data, verzováním, schvalovacími procesy, spoluprací a tak dále.

Pokud chceš komplexnější plánování, ukážeme vám tohle a pak půjdeme agilně vyvíjet další komponenty. Chcete předgenerovat data pomocí umělé inteligence? Zapojíme machine learning a na základě minulých dat vyrobíme první návrh plánů, které se budou upravovat.

Nebo chcete použít Pythonové nástroje, třeba Prophet? V tom případě Klik používáme jako orchestrátor – načte data z Klika, vyexportuje je do Pythonu, ten provede predikci a výsledky se zase načtou zpátky do datových modelů a zobrazí.

A když mluvíš o Infinity Forms a writebacku do databáze… Myslíš tím databázi Klika, nebo jakoukoliv jinou?

Infinity Forms umí ukládat do XML, QVD (to je optimalizovaný soubor Klika), ale i do jakékoliv databáze, která má JDBC konektor. Nedávno vyšla nová verze Forms s vylepšenou podporou Snowflake, takže umí ukládat prakticky do jakékoliv databáze s JDBC připojením.

V řešení, na kterém teď pracuju, používáme Snowflake jako databázi, a všechno tak putuje zpátky do jejich detailních dat ve Snowflakeu – odtamtud se data načítají a tam se i ukládají. Takže nejsme fixovaní na „klikovské“ soubory, nejsme nikdy limitovaní – můžeme ukládat kamkoliv chceme.

Kdybys chtěl, můžu ti pomoci s dalšími úpravami nebo doplněním.

Jasně, tady je opravený a upravený text pro lepší plynulost a stylistiku:

Můžeme načíst prakticky jakoukoliv databázi přes JDBC.

K plánování bych ještě dodal, že často to na začátku vypadá jednoduše – uděláme jednoduchou plánovací aplikaci. Ale jak se říká, s jídlem roste chuť. Když pak zákazník vidí, co všechno aplikace dokáže na jednotlivých milnících, přichází s dalšími požadavky na funkcionalitu. Takže z menšího projektu se může stát opravdu rozsáhlé, komplexní řešení. Přesně to se nám stalo u jednoho zákazníka, kde jsme s Jirkou rozjížděli plánování a postupně přibývaly nové požadavky: „Chtěli bychom tohle, a ještě tohle…“ Když si zákazník dokáže představit možnosti, požadavky neustále přibývají.

No a když jsme začínali, ten impuls, co firmu donutí začít řešit BI, je jako takový šampan – Jirko, ty jsi říkal, že COVID-19 může být takovým Cčkem digitální transformace. Jak vnímáte vlnu posledních dvou a něco let s generativní AI, respektive AI obecně? Zdá se, že spousta lidí se díky tomu opět začala zajímat o data, všichni teď najednou chtějí mít AI v organizaci. Jaká je vaše zkušenost? Jak AI změnila vaši práci? Nebo je to v tomto světě úplně něco jiného a na tuhle vlnu jste se příliš nechytli?

Když mluvíme o základních AI technologiích, které přišly ještě před současnou generativní AI vlnou, zapojujeme je velmi rádi. Jsou to skvělé use case, například predikce udržitelnosti zákazníků – tedy komu hrozí odchod. Klasický machine learning, který je oblíbený a užitečný i u plánovacích aplikací. Co se týká generativní AI, tady je potřeba být při implementaci trochu skeptický.

Máme pěkný proof of concept, kde uživatel pomocí přirozeného jazyka zadává svá pravidla, která chce aplikovat. Generativní AI pak na základě dotazu vrací klikovský skript, takže uživatel nemusí být vývojář a může si sám upravovat aplikaci cenotvorby. Například manažer se může v noci probudit a změnit pravidla cenotvorby přímo v aplikaci – a tohle řešení mu to umožňuje.

Je to tedy vlastně něco jako vlastní „vizuální editor“?
Klik Answers jsou právě taková generativní AI přímo v rámci aplikace klik, bez komunikace s externími servery. V našem případě jsme použili Klik společně s Infinity Form pro writeback, což znamená, že uživatel zadá dotaz, který se přes REST API odešle do ChatGPT. Na základě našeho složitého dotazu, kterým AI navádíme k přesným odpovědím, dostaneme zpět klasickou klikovskou syntaxi, kterou uživatel rovnou použije.

A ještě tě zastavím – je nutné, aby uživatelé při adopci Klik uměli klikovskou syntaxi a skriptování?
To záleží na úrovni. Základní self-service je velice jednoduché – uživatel může pracovat drag and drop stylem, přidávat tabulky, dimenze a metriky, které jsou předpřipravené. To zvládne každý a často je to i součástí našich školení.

Pokud chceš, mohu ti pomoci i s dalšími úpravami.

Zde je opravený text:

V též něco pokročilejšího, to znamená pokročilé filtrování zobrazení určitých oblastí, ad hoc reporting a podobné věci, se už do určité míry nevyhneš tomu, abys vstoupil do objektu, upravil ho, zapsal nějakou základní klikovskou syntax nebo si zapnul či vypnul zobrazovací podmínky pro objekty a tak dále. Ta self-service je na dostatečně…

Takže to je na úrovni třeba SQL, nebo… Dá se říct, že syntax, kterou Qlik používá v load editoru, má něco společného se SQL, takže pokud člověk nemá žádnou představu, je to podobné; syntaxe, dotazy, které tam píšeme, formátovací úpravy – to má něco společného.

Super, díky. A ještě k AI – tím pádem super, že Qlik také vstupuje do generálních funkcionalit, které zákazníci, s nimiž se setkáváte – tedy zejména menší firmy na „zelené louce“ – často požadují. Jak často se za poslední dva roky setkáváte s tím, že chtějí AI, že říkají „Co vy tam vyvíjíte nějaký plánovací nástroje a řešíte infrastrukturu, vždyť už tady máme AI, která měla nahradit celé jejich oddělení“? Tato typická poptávka po AI tam určitě je.

Já zase jsem takový, nechci říct úplně skeptický, ale spíše mírně opatrný a nechci AI dávat úplně všude, což jsou věci, které lidi někdy dělají. Například jsme řešili dokumentování aplikací, které někdo dělal v Qliku před námi, takže uvažujeme o využití AI pro dokumentování – ať už kódu, spíše té technologické části, protože ta byznysová stránka je vždycky trochu jiná, nebo vyloženě koncové aplikace. Takže využití AI pro nějaké dokumentování.

My jako vývojáři samozřejmě používáme AI, abychom byli schopní pracovat s obskurnějšími věcmi. Pokud například potřebuji nyní hned vyvinout něco v PowerShellu nebo Pythonu, určitě nemám tolik praxe, abych to sám na zelené louce zvládl, ale v koordinaci s nějakým GenAI nástrojem, který je už dostatečně pokročilý, to jde. Nemusím být ani programátor, nemusím vědět, kdy mi AI píše nesmysly; dokážu logicky odvodit, co je dobré a co špatné, a díky tomu můžu vytvořit i relativně pokročilé věci jen se znalostmi BI reportingu a BI skriptování, aniž bych byl výslovně IT specialista.

A máte pocit, že ta poptávka – ty jsi na začátku, Martine, říkal, že vám to zvedlo poptávku – přicházejí k vám teď klienti, které byste nečekali? Všímáte si toho, že BI je už standard, že už jsme tam, nebo pořád vládne Excel a podobné nástroje a BI je spíše okrajová záležitost? Pořád ještě přijdu do firmy a vidím, že základ jejich technologického stacku tvoří Excel. Takže určitě ještě nejsme tak daleko. I přesto musíš být schopen uvažovat datově analyticky, aby ses dokázal transformovat a správně používat GenAI.

Určitě se naše práce nezruší, jde o kooperaci – do toho to chci dál dotáhnout. Stačí jeden člověk, který dokáže firmu posunout, když to…

Pokud chceš, mohu opravit i pokračování.

Jasně, tady je upravený a více plynulý text:

Přeženu to, ale vidíme to jako přechod z doby temna do plné BI implementace. V rámci toho, jak my s těmi lidmi pracujeme, pozorujeme, jak postupně získávají zkušenosti – ať už interakcí s námi, nebo prací s BI nástrojem. Začínají pozvolna přecházet z klasického, když to přeženu, excelovského myšlení do analytického. A to je pro nás ten nejlepší pocit, ta obrovská přidaná hodnota – když se člověk, který s námi spolupracuje, změní z klienta na partnera, který je schopný něco tvořit, připravovat a zároveň i obohatit nás.

Pod to bych se podepsal. Mám radost, protože podle mě neexistuje lepší potvrzení, že to děláte správně, než když vychováváte a posouváte samotnou organizaci. Nejenže jste žába na prameni, za vámi pořád chodí, ale oni sami se posouvají, transformují a společně to partnersky rozvíjíte.

Každopádně, kluci, mockrát děkuju, že jste tady sdíleli své zkušenosti a ukázali, že ne všechny firmy běží úplně v cloudu a nerozhodují se jen, který vizualizační nástroj použijí. Stále je většina jejich BI nebo procesů v Excelu. Děkuju, že je posouváte z doby temna do data-driven světa. Držím vám palce, ať máte nejen víc malých klientů na zelené louce, ale i víc Foxconů, a ať se vám daří. Děkujeme za pozvání.

Pokud chceš, mohu to ještě více formalizovat nebo zkrátit.