Podcast

Dobrý den, jmenuji se Jirka Vicherek a vítám vás u nového dílu podcastu Datatolk. Dnes zde ve studiu se mnou jsou dva vzácní hosté, Ondra Klement, COO, a Jindra Košťál, seniorní konzultant implementace ze společnosti Logio. Ahoj kluci.
Ahoj Jirko.
Ahoj.

Pro pravidelné posluchače podcastu Datatolk připomenu, že toto není první díl, kde se Logiem hostíme. Zhruba před rokem zde byli dva jiní zástupci firmy Logio, Jirka Dědeček a Filip Vondruška. Přestože mám pocit, že Logio je taková legendární firma na české technologické scéně, že máte za sebou spoustu úspěchů a jste poměrně známí, tak Ondro, pověz nám, co dělá Logio pro ty, kteří o Logiu nikdy neslyšeli.

Ondra: Logio se dlouhodobě zabývá optimalizací dodavatelských řetězců. Na firmu se díváme ze dvou perspektiv. Máme část, která je čistě poradenská — to jsou kluci Jirka s Filipem, kteří tu byli před rokem — a ti pomáhají firmám na míru zefektivnit část nebo celý jejich supply chain. My s Jindrou jsme z druhé části firmy, která vyvíjí vlastní produkty. V současné době má Logio tři produkty, které firmám pomáhají v rámci jejich dodavatelských řetězců. Jsou to optimalizační nástroje založené na pokročilé matematice, analyzují data a snaží se najít řešení, jak někde ušetřit, jinde naopak navýšit, aby se zboží prodávalo lépe, zásobování bylo kvalitnější a tak dále.

Jirka: Jak velké je celé Logio a jak velké jsou ty divize?

Ondra: V současnosti je to zhruba půl na půl. Celkově máme asi 180 zaměstnanců ve třech pobočkách — v Praze, Brně a Hradci Králové. Nechci zapomenout, že máme také „neoficiální“ pobočku ve Škodovce v Mladé Boleslavi, kde je dedikovaný tým konzultantů. V letošním roce poprvé překročíme tržby 300 milionů, takže jsme už poměrně velká firma.

Jirka: Ty jsi profesně starší než Jindra, asi i věkově?

Ondra: Asi ano, takhle to nechtěl říct.

Jirka: Podívejme se na váš osobní příběh. Ondro, jsi v Logiu dlouho, jak dlouho?

Ondra: Jsem v Logiu 15 let, což je dlouho. A v půlce letošního výročí jsem dostal hezký dárek. Nastoupil jsem do Logia hned po vysoké škole, kde jsem vystudoval informatiku na VUT. Důvod, proč jsem v Logiu tak dlouho, odráží firemní kulturu a hodnoty. V Logiu si, když chcete, můžete najít různorodou cestu. Když jsem v určité fázi potřeboval změnu, prostě jsem ji našel v rámci firmy. Začínal jsem jako programátor a nyní jsem COO, což je „C“ pozice — říkáme tomu director of operations, aby to bylo správně pojmenováno na globální úrovni.

Jirka: Když jsi nastupoval jako programátor, jak velké bylo Logio?

Ondra: To je výborná otázka. Bylo nás tehdy kolem 30 až 40 lidí. Kdybych se vrátil v čase, firmu bych dnes vůbec nepoznal. Tenkrát to byla parta nadšených studentů, kteří se vrhli do spousty zajímavých věcí. Postupem času firma vyrostla a musela se řídit více profesionálně, už to nebyla garážová šikana s večírky, ale velká zodpovědnost vůči stovce zaměstnanců a klientům.

Jirka: Zodpovědnost za klienty také značně vzrostla, že?

Ondra: Ano, tehdy jsme měli klienty s malými firmami a malými obraty. Dnes máme klienty jako řetězec Albert se 400 prodejnami a obratem 60 miliard ročně. Záminka udělat chybu tak bolí mnohem více.

Jirka: A kdybys to shrnul, jaká byla tvoje kariérní cesta?

Ondra: Začínal jsem jako programátor, tehdy jsem programoval v PHP a používal MySQL databáze. Už na vysoké škole jsem dělal e-shopy, takže technologie mi byly blízké. Popravdě mě však nebavilo sedět celý den u počítače. Brzy jsem v Logiu pochopil, že consulting je zajímavější — jezdíme nasazovat systém u zákazníků, školíme je, vidíme, jak funguje jejich byznys. A tak jsem se stal konzultantem pro implementaci, což nyní dělá Jindra. Tato dráha mi vydržela dlouho. Logio stále rostlo — přibývali velcí klienti i zahraniční, tři nové produkty. Vždy jsem byl ochotný se pouštět do novinek, například když bylo třeba vyzkoušet nový produkt v Rumunsku nebo Srbsku, byl jsem první, kdo řekl, že do toho půjde. To mě ochránilo před syndromem vyhoření, vždy jsem si našel nový drive. Nakonec jsem chtěl více pracovat s lidmi, řídit je, věnovat se číslům a vidět fungování firmy jako celku, nikoliv jen zákazníků. To je teď můj současný stav.

Jirka: A kam do tohoto příběhu zapadá Jindra?

Jindra: Myslím, že jsem nastoupil v roce 2019, tedy před pěti a půl lety. Po škole jsem měl jedno zaměstnání a více méně jsem se s kamarády věnoval obchodování na Forexu. To mě chvíli bavilo, ale pak jsem přemýšlel, kde bych mohl dělat něco s reálným a pozitivním dopadem ve světě. Jeden známý mi doporučil Logio, že je to zajímavá firma, dělají zajímavé věci. Podíval jsem se na jejich stránky a poslal životopis.

Studoval jsem ekonomiku se zaměřením na logistiku, takže z dodavatelských řetězců jsem něco tušil, ale profesionálem jsem nebyl. Na začátku jsem se neviděl jako datový analytik, i když data jsou v naší práci důležitá. Viděl jsem to spíš jako implementačního konzultanta a říkal jsem si, že to zkusím. A za ty první roky mě to fakt chytlo.

Vzpomínám si, že když jsme přijímali nové kolegy, například právě Jindru, byl to i můj úkol vést přijímací proces vedle Petra Tulacha. Pamatuji si, že máme pro uchazeče úkol, který není úplně exaktní, dává prostor pro kreativitu při zkoumání dat. Jindruv úkol byl úplně mimo naše očekávání, co bychom tam hledali, a byl skvělý. Dodnes si pamatuji, jak jsme se Petro s úsměvem dívali na jeho řešení, které dávalo smysl, viděl věci, které nás nenapadly. To je přístup, který hledáme. Jindra je pro nás etalon — už pět let ho nikdo nepřekonal.

Jirka: Jindro, říkal jsi, že máš nějaké povědomí o supply chainu z ekonomie a logistiky. Pro posluchače, kteří o tom slyší poprvé, co je to dodavatelský řetězec? Určitě si představí logistiku, sklady, produkty, fyzický svět. Co z toho vlastně v Logiu řešíte?

Jindra: Souvisí to s členěním Logia. V poradenství pomáháme firmám v jakékoliv části dodavatelského řetězce — ať už je to vnitřní rozložení skladů, jejich rozmístění, velikost, frekvence přepravy, nebo firemní procesy.

Když se bavíme o softwarové části, hlavní produkt se věnuje optimálnímu zásobování skladů, prodeji, distribuci, nákupu a výrobě, pokud je firma výrobní. Jsme pokrýváme široké spektrum těchto oblastí.

Co je důležité, je, že supply chain není jen logistika. Často jsou logistická oddělení exekutory rozhodnutí obchodních a produktových týmů. Logio se vydalo cestou, kdy kromě optimalizace samotného dodavatelského řetězce i optimalizujeme věci, které ho ovlivňují. To znamená plánování promo akcí, výprodejů, tvorbu cen a produktového portfolia — tedy oblasti spadající do komerční sféry, obchodů a marketingu, které mají velký vliv na dodavatelský řetězec.

Naše cesta je zabývat se supply chainem komplexně — od začátku do konce, tedy end to end. To znamená nejen řídit tok zboží, ale i pořádně vyhodnocovat zpětnou vazbu. Například když vznikne problém při zásobování, a není možné ho vyřešit jen ve supply chainu, dokážeme systémem podpořit rozhodnutí — třeba prodat skladové zboží za cenu s minimální marží, než aby se vyhodilo. Takto uzavíráme smyčku zpětné vazby.

Jirka: Takže, co vlastně software Logia dělá?

Jindra: Máme tři řešení, ne vždy nabízíme všechna, ale pro potravinářský retail je logické mít je komplexně. První řeší zásobování a plánování nákupu a distribuce.

Jak už Ondra zmínil, aby toto plánování fungovalo, potřebujeme kvalitní vstupní data, a proto se zabýváme i plánováním promo akcí. V dnešní době zhruba 50 % všech prodejů realizovaných přes promoce je plánováno naším nástrojem, což je v Česku významné číslo. Lidem dáváme nástroj, aby vytvářeli umělé promo akce v datech a ověřili, co by se stalo, kdyby danou akci spustili — jak by to ovlivnilo prodeje a zisky.

Pomáhá to firmám dostat se ze slepé uličky.

Jindra: Dále máme nástroje pro cenotvorbu — tedy jak nastavovat slevy a akční ceny tak, aby byly efektivní, vyplatily se a plnily cíle firmy.

Zároveň…

[text je nedokončen]

My od jedné naší přátelské firmy máme i regulérní cenotvorbu, kdy vlastně říkáme: „Hele, tenhle produkt možná trošku třeba zlevnit, tenhle zase zdražit“ – a takovéto doporučení dáváme. Celkově, když máme informace o tom, co se plánuje za akce, jestli se třeba něco bude předceňovat, tak tyhle informace jsou potom vstupy do supply chainu, kdy můžeš říct: „Dívej, tohle zboží dává smysl objednat ve větším množství nebo naopak v menším.“

Já bych řekl, že náš výstup z celého procesu není úplně tak složitý. Výstupem je vlastně každý den nějaký seznam, který – když to řeknu hloupě – obsahuje tu polovinu informací, která ti říká, kup tohle v takovém množství od třeba tohoto dodavatele, anebo naopak převeď toto v nějakém množství z jednoho skladu na druhý nebo z jednoho skladu na prodejnu, ať už je to nastaveno jakkoliv.

Víceméně si to můžeš představit tak, že pokud například přijdeš do Albert hypermarketu – což už tady bylo zmíněno a kde je naším klientem právě Albert – a vidíš, že na jogurtu je napsáno „Pomoc neplýtvat – 30 % sleva“, může to být částečně náš problém, protože jsme toho jogurtu tam přivezli příliš mnoho. Zároveň, pokud přijdeš a vidíš, že na regálu chybí tvoje oblíbená čokoláda, a ta tam není, tak to může být, ale nemusí být náš problém, protože jsme třeba na základě dat řekli, že máme přivézt 17 balení, respektive jedno balení po 20 kusech, a přitom bylo potřeba přivézt třeba dvě balení.

V celém řetězci může být spousta chyb. Dodavatel to třeba neměl skladem, nebo ho má ve skladu prodejny, ale nevystavil ho, takže si to nemůžeš koupit. Nemůžeš proto vždycky tvrdit, že je to náš problém. Ale můžu – a od teďka budu. Tady u nás v Albert Bieda už je to takový můj lakmusový papírek pro to, jak vám funguje software. Rozumím tomu.

Vytvořit denní seznam, co kde a jak nakoupit nebo převést, je komplexní problém, protože musíš začít tím, kolik předpokládáš, že budeš prodávat. Spočítáš si nějakým způsobem předpovědi. Potom máš různé podmínky, jak je daný produkt zásobován – máš balení, máš lead time, což znamená, že aby ses mohl trefit s dodávkou na prodejnu třeba několik dní dopředu, musíš mít zboží několik dní předem na centrálním skladu, a aby ses trefil tam, musíš ho zase několik dní předem objednat u dodavatele.

Řídíš to tedy komplexně a do toho vstupují právě promoakce, kdy se ti toho najednou prodává desetkrát tolik než obvykle, nebo vstupují jiné faktory. Dodavatel ti dodá méně a ty musíš efektivně rozdělit zásoby mezi prodejny, aby někde nevznikly zásoby na 14 dní, zatímco zbylé prodejny už nemají co prodávat. Takovéto problémy tedy řešíme.

Říkáš, že uvnitř softwaru je nějaký šelmstroj, a výsledkem je tabulka, co nakupovat, co převést, odkud, kam a jak řídit supply chain. Kdo je však uživatel? Kdo v té firmě má otevřené okno, v němž běží váš software?

To je dost různorodé, záleží na dvou faktorech: na míře automatizace a na centralizaci. Máme klienty v celém spektru. Někteří mají proces opravdu velmi centralizovaný a často také automatizovaný, a v tom případě se do systému dívá již jen manažer nebo vyšší pozice, která systém globálně ovlivňuje.

Na druhé straně máme menší zákazníky, kde není tak vysoká automatizace, a tam například nákupčí systém používá spíše jako pomocný nástroj, kdy přemýšlí víceméně o každém řádku.

Problém je opravdu rozsáhlý. Když se bavíme o Albertu, máme tam přibližně osm milionů produktů v prodejnách. Lidé si to často nedovedou představit, ale v obyčejném supermarketu je zpravidla kolem 10 tisíc různých produktů – základní jako mouka, vejce, chleba, ale i drogérie, koření, různé velikosti balení a další.

V hypermarketu může být v klidu 40 až 50 tisíc produktů. Každý den, kdy můžeš některý z těchto produktů objednat, musíš učinit rozhodnutí, jestli ho objednat nebo ne, a pokud ano, v jakém množství.

Konkrétně v Albertu to znamená, že by lidé museli denně učinit asi 700 tisíc takových rozhodnutí v rámci celého řetězce asi 350 prodejen. To představuje obrovský nápor na data a myšlení.

Tento problém skutečně řešíme. Komplexita a rozsah jsou enormní.

Je to samozřejmě jiné, když mluvíme o potravinách, oproti jiným oborům. Mluvil jsi o velkých zákaznících, kde je vysoká automatizace a centralizace, ale při menších zákaznících je situace přece jen odlišná.

Když se podíváme na obory, například mladoboleslavskou Škodu, v čem se liší velké průmyslové firmy od FMCG potravin?

Já bych řekl, že logika je tam zcela odlišná.

Za prvé, Škodu auto zde náš software neřídí, to spravuje druhá divize našich konzultantů.

Ale pokud jde o naše klienty ve zmíněných odvětvích, je opravdu velký rozdíl, zda například vozíš věci z Číny v kontejnerech, kde máš lead time i tři měsíce na lodní dopravu, anebo jestli řešíš rohlíky na prodejně.

Náš software je vyvinutý spíše genericky. V rámci implementace ho ovšem přizpůsobujeme konkrétním procesům a požadavkům klienta. Pokud klient řídí rohlíky, je to naprosto jiné než například super fresh sortiment čerstvého pečiva nebo zeleniny.

V těchto oblastech už vstupujeme jen částečně, protože je to velmi náročné a plná automatizace je zde méně častá. Tam obvykle dáváme návrhy pro pracovníky, kteří řeší zásobování individuálně, protože u ovoce a zeleniny záleží na mnoha faktorech – není jablko jako jablko. I když je označené jako Golden Delicious, nemusí být stejné velikosti nebo chuťově identické. To závisí i na subjektivním pocitu člověka, jak se konkrétní produkt bude prodávat.

Tady se naráží i na spolupráci s datovými specialisty, například Martin Hronec je Data Scientist v Albertu, který řeší plánování výroby pečiva.

Rozumím tedy i těm rozdílům v lead time a další.

To mě právě zaujalo na softwaru – jeho generičnost.

Co tedy software vevnitř dělá? Co je ten šelmstroj?

Systém je založený na forecastovacím jádru, složeném z různých matematických modelů nebo algoritmů. Používáme statistické modely, neuronové sítě, genetické programování a podobně.

Je hodně velký rozdíl mezi FMCG a ostatními industriemi, zejména v hustotě dat, protože systém je generický, ale díky široké škále modelů si vybere ten nejvhodnější.

Například u Alberta, kde je velká hustota dat, se lépe využijí neuronové sítě, protože denně se prodá mnoho rohlíků na spoustě účtenek, což je ideální pro trénink modelů.

Oproti tomu například u stavebnin, jako jsou Siko koupelny, kde se myvadla prodávají třeba třikrát do roka, je hustota dat nízká, a proto využíváme jiné statistické modely, které si s tím poradí.

Tímto způsobem systém není „one size fits all“, ale je generický a zároveň customizovatelný díky vhodnému výběru modelů na míru klientovi.

To je velmi důležitá konkurenční výhoda našeho řešení.

Někdy je potřeba i uvnitř odlišovat sortiment, například v stavebninách je osa na rychleji obrátkové zboží, jako cement, který se prodá desítky kusů denně, a naopak speciálky, které se prodají velmi zřídka.

Totéž platí i u potravin – například některé šampony se neprodávají v desítkách kusů denně.

Pokud se podíváme „pod kapotu“ softwaru, jaká je architektura a technologie?

Jako každá dlouho fungující softwarová firma jsme hodně ovlivněni technologiemi, které jsme zvolili před 18 lety.

Některé starší části jsou stále v PHP, což je vtip mezi programátory, ale nový produkty vyvíjíme v kombinaci JavaScriptu na frontendu a modely běží v .NET/C#.

Databázi používáme MariaDB, což je fork MySQL, s konfigurací upravenou podle našich potřeb.

Jde o on-premise řešení, ale v posledních letech v Čechách i v regionu probíhá silný posun směrem k modelu Cloud First.

V technologické roadmapě na dva roky máme proto zařazený přechod na cloudové nebo cloud-ready řešení.

Jak velký tým na softwaru pracuje?

Celkem máme asi 75 lidí: zhruba třetina se věnuje nasazení u zákazníků, třetina servisuje stávající klienty a třetina pracuje na vývoji a rozvoji jádra systému.

Na co je software napojený a čím ho krmíte?

To je nejzásadnější téma implementací a často jedna z největších nákladových položek.

Snažíme se jít cestou vysoké automatizace, což vyžaduje co nejvíce dostupných dat, aby systém mohl správně analyzovat situaci a nabídnout relevantní rozhodnutí.

V rámci implementace musíme zjistit, kde klient data má a domluvit se, jak je dostaneme.

Není to jednoduché, protože není jednotný způsob integrace – i SAP, který má většina klientů, je nastavován a implementován velmi rozdílně s různými vlastními úpravami a customizacemi.

Proto je nutné vše detailně analyzovat, vyspecifikovat a pak integrovat systém na míru každému klientovi.

Historicky jsme většinu integrací řešili pomocí file transferu, protože jde o on-premise řešení.

Nyní se však klienti posouvají k integracím pomocí databází a API.

Výběr technologie pro integraci závisí na rovnováze mezi náklady, stabilitou a rychlostí získání dat.

Proč jsou data tak důležitá?

Protože často máme velmi krátké časové okno, aby systém mohl být natrénován na aktuálních datech a generovat návrhy.

Například Albert má některé prodejny otevřené do půlnoci, Dr. Max některé lékárny nonstop, ale objednávky na centrální sklady od externích dodavatelů již běží večer – během tohoto okna musí systém všechno spočítat a tato data dostat.

Často klienti říkají, že potřebují data nejprve seskupit, vyčistit a dostat je do ERP nebo SAP, což může trvat i několik hodin, než nám je předají.

Proto řešíme různé varianty připojení – přímo k pokladním systémům, pomocí ERP systémů nebo kombinací obojího.

Součástí implementačního projektu je i podprojekt, kdy s klientem definujeme, kde data jsou, protože klient často neví, odkud je nejlepší je brát, a jak jim nejdříve zajistit čistotu a správnost…

[Text zde končí neúplně, ukončeno v půlce věty.]

Istit, aby vůbec měli kvalitu, co mají začít sbírat. Takže ten takový datový integrační projekt se vždycky posouvá v čase, je to lepší. Mám pocit, že ta hodnotná data a ten fokus na data jako taková, na to, jak sbírat a zlepšovat jejich kvalitu, roste. Je to jenom moje bublina tohoto studia, nebo máš pocit, že v projektu a světě se to skutečně projevuje?

Určitě ano. Jsou tam několik aspektů, které se hýbou. Jak říkáš, zákazníci zjišťují, že by se mohli na základě dat rozhodovat, že to je super, že tam něco vyčtou, což je fajn, takže zjistí, že chtějí data sbírat. Druhá věc je, že se posouvají typicky ERP systémy dál. Před patnácti lety, kdybychom implementovali, většina zákazníků měla nějaký zbouchaný informační systém, který jim naprogramoval nějaký kamarád z vysoké školy. Dnes většina těch větších zákazníků má nějaký ERP systém od firmy, která je dlouho na trhu, má s tím zkušenosti a třeba 100 zákazníků, takže už to má nějakou hlavu a patu, i datové objekty a datové modely na pozadí.

To je druhý aspekt. Třetí aspekt je, že před patnácti lety jsme byli takový jako jednorožec, bohužel jsme to úplně nevyužili, ale toto řešení jsme už měli a na světě konkurentů na této úrovni moc nebylo, možná žádní. V dnešní době vzniká po světě dost konkurenčních řešení a velmi často už jdeme do projektu s tím, že zákazník měl nějaké řešení, které optimalizovalo supply chain, a měníme produkt za lepší nebo jiný. Doufám, že lepší — to nechci tady podsouvat. Tím pádem už takový integrační projekt, vyčištění a sbírání dat, si už fakticky odbyly s jiným dodavatelem před námi.

To je takový další aspekt, který se mění podle našich pozorování.

Jindro, jak se u klientů řeší rozhodnutí: rychleji s „špinavějšími“ daty versus pomaleji s čistými při integraci dat? Jaké jsou důležité rozhodnutí v této části? Je to přístup „Better done than perfect“, aby začali dostávat nějaké lehce suboptimální výsledky, ale pořád lepší než současný stav? Nebo raději delší příprava s perfektní kvalitou? Jak se tato rozhodnutí řeší?

To je zajímavá otázka. Pohled na to je různý a často záleží na přání klienta, protože každý to vnímá jinak. Více méně oni si řeknou, co chtějí. Navíc je tu ještě jedna forma, jak na to nahlížet — my bychom preferovali nějaký datový formát, který by k nám šel. Ale oni zase rádi dodají to, co mají, a nějak si to přemodelují. To je samo o sobě problém, protože firmy s tím nemají tolik zkušeností.

Transformovat data z jedné datové struktury do jiné děláme poměrně často, protože máme lidské zdroje i know-how. Pokud se jdeme tou cestou, že chceme to uspíšit, řekneme: „Dobře, prostě nám to vylijte, jak máte, my si v tom nějak pohrabeme a vytvoříme si to na naší straně.“ Je to určitě rychlejší řešení, a může být v ten daný moment stejně kvalitní.

Ale potom, když se v průběhu času změní implementační tým na straně klienta a na jejich straně je někde necitlivě nastavená datová transformace, které nikdo moc nerozumí, může to přinášet nevýhody.

Snažíme se proto vždy najít kompromis — něco vytvoří zákazník, něco doděláme my, často do datové transformace implementujeme nějaká byznys pravidla. Například klient má nějaký příznak, se kterým neumíme pracovat, ale napojíme ho na jeden z našich příznaků, a tím říkáme, že se to bude chovat tak nebo tak. To už je docela složité.

Nevím, jestli jsem odpověděl na otázku, snad to bylo srozumitelné. Můžu dát nějaký příklad dvou různých přístupů?

Jistě.

Máme například dva vzorce chování systému k produktu, který vylistuješ. Buď prostě řekneš: „Produkt neobjednávej,“ a tak ho neobjednáváš. Nebo máš příznak, že doprodávej produkt, kdy ještě počítáš se zásobou, kterou budeš doprodávat. To pak může mít vliv na forecasting a další věci.

Pokud někdo řekne: „Dobrý, mám tady vylistovaný produkt,“ u nás defaultně nemáme něco jako „vylistovaný produkt“. Musíš ho napojit na jeden z těchto příznaků, nebo jich může být více — třeba „neforecastovat“ nebo „nedržet pojistné zásoby“. A může se to nastavit různě kreativně.

Je to na dohodě s klientem — musíš se ho ptát: „Jak ten proces delistace produktu funguje? Co pro vás znamená vylistovaný produkt? Už nemá žádnou zásobu, nebo prostě jen nejde objednat dál?“ Tyto otázky si musíme s klientem fakticky rozebrat a podle toho udělat implementaci.

V tom je slyšet, co říkal Ondra — že vidíme do byznysu hodně do hloubky.

Jak často se vám stává, že vaši defaultní datovou strukturu převezmou klienti jako svou defaultní supply chain strukturu? Učíte je to, nebo je to spíš jejich styl fungování, na který se musíte přizpůsobit? Existují nějaké standardy, jeden správný způsob, nebo je to opravdu tak, že každá firma si dělá věci po svém, protože i byznys model a interní procesy jsou úplně jiné?

Souhlasím, není to moc vidět, ale přesně tak to je. Každá firma si dělá věci hodně po svém. Nemyslím si, že bychom byli schopni říct firmám: „Změňte svůj proces a dělejte to takhle, protože tak je to správně.“ Firmy mají často očekávání, že s implementací nového ERP se změní procesy a budou dělat věci jinak, ale u nás to většinou není globální projekt pro celou firmu, ale spíš aktivita pro oddělení supply chain nebo nákupu.

Oni to nevidí jako globální projekt a mnohdy vůbec nejsou ochotní přejít na něco jiného. Proto se často musíme přizpůsobovat jejich stávajícím věcem, i když to nedává úplný smysl. Někdo jim tak nastavil ERP, procesy jsou dané, lidi něco řídí, a my tu logiku víceméně pak přeneseme na naší stranu a s ní pracujeme.

Takže fakt každá firma si žije svým vlastním světem a dělá věci po svém.

Proč je implementace tak zásadní část a integrace? Jak implementace probíhá? Jak dlouho trvá, než to začne fungovat? Kolik lidí se na tom podílí? Jak si to mám představit u průměrného ideálního klienta?

Malí klienti — tam bych řekl, že se můžeme pohybovat lehce pod rok, třeba tři čtvrtě roku až kolem roku. Projekt to není věc na lusknutí prstů, že druhý měsíc to funguje. U malého klienta, pokud to je optimistické, může být půl roku, pokud má fakt data.

Malý klient je podle nás třeba firma s tržbami kolem tří miliard korun. Pro některé z našich posluchačů může být malý klient podstatně menší. Pro kontext: firma s dvěma až třemi miliardami tržeb – u ní se dá předpokládat půl roku až rok implementace.

Hodně záleží na řadě faktorů — například na připravenosti dat. Jestli vůbec mají interní systém a know-how o jeho fungování, nebo jestli ho mají od externího dodavatele a jak je ten dodavatel schopný připravit data.

Někdy ti řeknou: „OK, za měsíc to bude,“ a za měsíc to je. Jindy trvá půl roku jenom získat data, aby mohl projekt začít.

Na otázku o týmu — větší tým často urychlení nepřináší, protože musí proběhnout čekání na data, potom testování, které může trvat i měsíc. Test se nedá udělat za den.

Vlastně projekt začíná tak, že první dva měsíce je to o návštěvách klienta, kdy se ptáme na byznys procesy, strategii firmy, protože vše má vliv na to, jak software implementovat — na co se zaměřit, jaké problémy řešit.

Je třeba pochopit rozložení skladů, e-shopy, kamenné prodejny, jak procesy fungují mezi odděleními. Velmi často to není jeden tým, ale více oddělení — třeba komerce řeší zalistování produktu, pak nákup a případné promoakce, kde je víc proměnných. Také IT se podílí na přenosech dat.

Musíš najít správný způsob, jak systém ve firmě nasadit, aby kryl ty procesy nebo na ně navazoval.

To je první část projektu.

Pak přichází fáze, kdy konzultant říká programátorovi: „Vymysleli jsme nějaké speciality, něco jde nastavit, něco ne,“ a řeší se požadavky změn (Request for Change, RFC). Pak zadáváme programátorům úpravy systému, ať už přes konfiguraci (nejjednodušší metoda, kterou hodně využíváme, protože umožňuje například říci, že pokud je určité datum, pak se produkt objedná, jinak ne), nebo přes custom úpravy jádra systému.

Pak přichází testování — nejprve posíláme objednávky na zkoušku, klient sleduje, dá zpětnou vazbu. Pak se ladí.

Druhý krok testování je pilot na pár prodejnách, protože některé věci neodhalíš, dokud řešení nefunguje v reálném provozu.

Můžeš desetkrát poslat návrhy objednávek, ptát se paní na prodejně, zda to dává smysl, ale reálný provoz odhalí skryté problémy.

Mám příklad ze zahraničního klienta, který měl malý řetězec masných prodejen a továrnu na uzeniny. Po čtyřech dnech hlásili, že se hromadí „zbytkové kosti pro psy“ na prodejně, protože neměli proces pro příjem těchto výrobků.

Dorazilo 50 kilo kostí, pracovníci je jenom odložili, lidé si je brali, ale protože nebylo zaznamenáno jejich přijetí, program další den objednal další. Tím se kosti hromadily a zabíraly místo pro normální zboží.

Tyto věci neodladíš bez reálného testu, protože lidé skutečností zjistí, kde je problém.

Teprve tak je možné systém skutečně doladit.

Ještě krátká odbočka — zajímá mě, jak se rozhodujete, co přidat do produktu, tedy do softwaru přímo, a co zůstává custom implementací specifickou pro klienta? Jak to máte produktově nastavené?

Řekl bych, že díky tomu, co říkal Jindra, je potřeba si uvědomit, že systém má určitou míru konfigurovatelnosti.

Občas zákazník chce věci jinak, ale nemusíme nutně vyvíjet na míru — stačí změnit konfiguraci.

Systém umožňuje danou funkčnost se dvěma různými chováními a pro každého klienta se konfigurace přepne. Každý klient má svůj konfigurační set.

Samozřejmě děláme i hard customizace jádra systému.

Máme produktové oddělení, které dvakrát ročně vydává novou verzi systému a shromažďuje požadavky z implementací, obchodu, servisu a dalších oddělení.

Tímto jsem přepsal text do spisovné češtiny, zachoval veškerý obsah, informace a význam.

Ty náměty na toto téma – kolikátý klient to vlastně chce, nebo zda dává smysl, že by to mohli chtít další – si klient sestaví takový backlog a z toho pak podle priority a uvážení vydává nové verze. Takže přibližně dvakrát ročně vyjde nová verze, která třeba už danou funkcionalitu podporuje.

Velká část je řešena nějakou konfigurací, takže tu část prostě nakonfigurujete, vyzkoušíte, doladíte, co se děje, když to dá, už jste vychytali ty okrajové případy (edge cases), a pak to může jít do produkce.

Je hrozně důležité uvědomit si, že pokud měníte styl nebo proces nákupů, tak se to skutečně musí promítnout do procesní struktury dané firmy. A tam je určitě na nich, a je to také často velké dilema nebo téma, jak tu firmu správně adaptovat na nový proces. Často je to vlastně ten rozhodující faktor, zda je projekt úspěšný nebo ne. Firma musí říct: „OK, teď měníme styl práce, co se dělalo takto, teď se bude dělat jinak, máme nový proces.“ Samozřejmě pak pokračujeme školením lidí, to je jakási spolupráce s firmou.

Ale rozhodně to musí být změna, kterou firma chce udělat, a nemůže to být tak, že my jim z externí pozice říkáme: „Hele, udělejte to takto,“ a snažíme se je nutit pracovat jinak. Musí to být v kooperaci s managementem dané společnosti, který řekne: „Hele, dříve nákup fungoval takto, teď bude fungovat jinak.“ Například musí být nastaveny nové KPI, a změna je procesní.

Jak jsem říkal, datové procesy se moc nemění, ale tady je to jednoznačné místo, kde je to potřeba měnit v rámci firmy. Pokud uděláte námi navrhované kroky, od naší strany provedeme školení, pak probíhá proces rollout, kdy většinou začínáme na menším počtu prodejen, protože celý systém hned nespuštíte.

To je i z důvodu školení nových lidí, kteří potřebují větší podporu a mají dotazy, plus z hlediska vytížení týmu. Zkrátka se zapojuje po blocích – například jeden kraj, pak další kraj, nebo se to může dělat i podle sortimentu – např. začnete s mléčným sortimentem, pak pokračujete dále. Záleží také, jestli se proces spouští s vysokou automatizací, nebo spíše jako podklad pro nákupčí – podle toho se to odvíjí.

Máš nějaké dobré nebo špatné zkušenosti, tipy či triky ohledně change managementu? Jak jste se naučili lidi naučit systém používat a získat si je pro sebe?

Já si myslím, že stěžejní je, a Jindra to zde nakousnul, mít správná očekávání od projektu. Není to jen o implementaci, ale klíčová je pre-sales fáze, protože historicky jsme se setkávali s tím, že jsme obchodně nastavili extrémně vysoká očekávání, a pak jsme doručili projekt, který jim viditelně ušetřil čas a fungoval skvěle, ale přesto byli někdy zklamaní, hledali mouchy a problémy, protože v pre-sales fázi měli neodpovídající představy. Čekali Ferrari, ale dostali Mercedes, a přitom předtím jezdili v Žiguliku. Proto je potřeba správně nastavit očekávání také neustále v průběhu projektu.

Je to úkol manažera projektu, aby se k tomu stále vracel. Dobrou metodou je využití logického rámce – na začátku s klientem jasně definovat, co očekává, jaké jsou cíle a jak je dosáhneme – a pak pravidelně tuto dohodu připomínat. I obyčejný Excel nebo matice pomohou – ale nejhodnotnější je diskuze, kdy si klient uvědomí, co dostane a co ne, a pak to lépe přijímá.

Dále bych se chtěl zastavit u té doby dodání a nákladů, které implementace přináší. Často to vypadá draze a trvá to dlouho, takže zákazník musí mít důvěru, protože třeba Jindra už s námi jezdí půl roku a ještě není vidět výsledek. Jak vyvážit realistická očekávání, aby projekt nebyl přepřehnaný, ale aby klient věděl, že bude náročný a bolestivý?

Opět, pokud to klientům na začátku jasně sdělíte – že to bude trvat přibližně rok, bude potřeba práce z jejich strany a změny procesů – je to v pořádku, pokud se to nezdrží na dvojnásobek. Důležité je, že to není tak, že po podpisu smlouvy jsou na rok beze zpráv. Naopak s nimi průběžně komunikujeme, řešíme věci, a často už v průběhu projektu dochází k dílčím zlepšením – třeba průběžné inventury skladových zásob, které je začnou naplno motivovat.

Je pravda, že zprvu musí začít sbírat nová data, což je výzva, ale jakmile vidí přínosy – například, že slečna z financí přestala dělat ruční operace, protože systém tyto činnosti podporuje –, cítí motivaci pokračovat.

Důležité je mít od začátku nastavený partnerský přístup s managementem, jak řekl Jindra, nikoliv jen scénář zákazník versus dodavatel, „tady je smlouva, dodávejte to v termínu a za peníze“. Když naopak vystupujete společně jako partneři, kde jdete na začátku společně do projektu, pomáháte si, věříte si a na konci z toho mají radost všichni, pak to funguje lépe.

Klienti tak cítí zodpovědnost, mají podporu managementu, který vás představil, a berou zodpovědnost za výsledek jako svou vlastní. Když je něco špatně, berou to jako svou chybu a vše se lépe řeší.

Tam, kde se tohle podaří od začátku vytvořit, proběhne změna lépe, protože jsou všichni zataženi a ví, že jsou její součástí.

Jak se to dělá? To je ta výzva – většina chce být partnerem, nikoliv dodavatelem. Vsadím se, že každý to má na svých webových stránkách, ale skutečně díky zkušenostem a tím, jak se nastavují očekávání v pre-sales, když klientům říkáte nepříjemné pravdy už na začátku, se to dá zvládnout.

Kdo by si mohl vzít nějaké zkušenosti, kdo nedělá velké projekty jako my s Logiem? První věc je, že se nám 100 % nevede, to, co popisuju, je ideál. Většinou se to nepodaří plně, a hodně záleží na lidech.

Některé velké korporace mají korporátní manažery, kteří vás berou jako dodavatele – je tam procurement, právní oddělení a říkají: „Neměňte nám to, my chceme jen hezký bonusy na konci, že jsme zlepšili.“ Takový přístup komplikuje změnu.

Za mě stojí za vyzkoušení logický rámec pro vyjasnění očekávání, sednout si a mluvit pravdu, neslibovat nereálné věci v obchodní fázi.

Další věc je přesvědčit lidi, že pokud projekt dobře dopadne, pomáhá to i jim. Máme kolegu – šéfa projektové kanceláře, který říká: „Pokud s klientem projekt domluvíme, měl by někdo z jejich strany mít zájem na jeho úspěšném dokončení.“ To je záruka, že klient chce projekt dotáhnout do konce.

Já preferuji upřímnou, otevřenou a transparentní komunikaci od začátku. Nejhorší je, když se zabarikádujete, na vaší straně se řeší nějaký problém, ale klient neví, co se děje, protože jste mlčeli.

Jasně nastavte očekávání, otevřeně a upřímně komunikujte, vysvětlete týmům, že projekt dopadne dobře, pokud budou spolupracovat. Vysvětlete, jak může pomoci jim osobně i celé firmě, ukažte příklady a reference.

Takové věci nám fungují, i když se to 100 % nepodaří.

Co Jindra zmínil, že při implementaci klienti mají řadu rozhodnutí, do projektu vkládají svoje know-how, takže systém je jejich a funguje na základě jejich požadavků. Nemůžeme pak říct, že nefunguje, když to běží tak, jak si přáli. Tento jejich involvement rozhodně pomáhá.

Jindra?

Ano, určitě. Stavíme to společně s klientem a na druhé straně potřebujeme mít člověka, se kterým konzultujeme. Díky tomu mu můžeme vysvětlit různé dopady, pokud systém používáme tak, nebo onak. Nemyšlíme za něj, ale dáváme mu podklady k rozhodování.

Skutečná spolupráce je nezbytná.

Pokud se k vám klient chová dobře, vytvoří se vztah autority – vy v daném úzkém oboru víte mnohem víc, než on. Proto není těžké stát se jeho autoritou a ve většině případů jsme dosáhli dobrých, až kamarádských vztahů.

Navážu k tématu závazků managementu. Mít někde na straně management, který řekne firmě, že chce řešení, je klíčové. Další důležitá věc je udržet klienta v nadhledu, že řešení pomáhá jako celek a že neřešíme jednotlivé případy, kde to někdy může fungovat hůře než ruční práce.

Nastane to vždycky.

Nejhorší, co se nám stalo, je, když se obě strany utopily v řešení detailů, například, že v některých prodejnách chybí petržel nebo kapky do nosu. Vždycky takové případy budou.

Důležité je soustředit se na celkový progres zákazníka, že ukazatele se zlepšují.

To je potřeba u klientů na začátku pochopit, aby měli nadhled a věděli, že pomáháme celému supply chainu a jednotky případů budou vždy.

S tímto přístupem to funguje dobře.

Nahráváš mi?

Ano.

Co jsou hlavní důvody, proč chtějí klienti použít Logio? Peníze? Chceme ušetřit, máme větší agilitu? Je to kvůli neobratnosti, kvůli délce trvání procesů? Nebo kvůli legislativě?

Říkají, že například chtějí kontrolovat, aby neplýtvali potravinami, protože musí odepisovat vyhozené zboží a chtějí minimalizovat ztráty.

Mění se to u firem?

Ano, souvisí to s jejich situací.

Pamatuji si, že v době ekonomické krize například kolem roku 2008 až 2010 byl hlavní motiv týkající se Logia úspora zásob – aby při stejném prodeji měli méně na skladech, zlepšili cash flow, měli menší vázaný kapitál a méně si půjčovali.

Pak jsme se postupně dostávali z finanční krize do situace, kdy banka půjčovala za velmi nízké úroky (někdy i 0,01 %) a klienti říkali, že naše snaha šetřit zásoby není úplně klíčová…

Nezajímá mě to, já si to zadarmo půjčím. Takže já mohu být klidný zásob, ať chcete cokoliv. To, co chtěli, bylo růst. Prostě byly na to dobré podmínky. To, co je zajímalo, bylo, jestli zlepšíte dostupnost pro koncového zákazníka, protože když si toho zákazník koupí více, bude spokojenější, bude tam častěji chodit a tím se zvýší tržba. Takže sledovali tento ukazatel. Tento systém dokáže také doručovat.

V době covidu to bylo trochu nahoru-dolu, někteří se báli, vraceli se zpátky a raději šetřili a tak dále. A zapomněl jsem zmínit, že bylo jedno období, kdy byla v České republice velmi nízká nezaměstnanost. Říkali, že to bylo 4 %, což České statistický úřad uvádí, ale ve skutečnosti to byla nula, protože z těch 3 % lidí, kteří byli na pracovním trhu, nikdo z nich nechtěl pracovat. Takže reálně to byla nulová nezaměstnanost. V podstatě v té chvíli to, co chtěli, bylo ušetřit ty lidi. Klíčovým prvkem byla automatizace. Když ušetřím na každé prodejně hodinu práce vedoucímu, je to bomba, protože nepotřebuji brigádníka. To bylo super, toto období bylo významné.

Poslední dobou, jak jsi říkal, opravdu tím často hýbou dva efekty, které jsou teď hodně oblíbené. První je ekologie, což znamená, že díky systému dokážeme snižovat ztráty a vyhazování, čímž zamezujeme plýtvání. To je určitě častý důvod, z hlediska ESG (environmentální, sociální a správní odpovědnost). Dále snižujeme počet transportů, protože zavezeme zásoby optimálně jednou či dvakrát denně, takže tím snížíme uhlíkovou stopu. Druhý faktor, který často výrazně ovlivňuje zájem, je umělá inteligence (AI), protože pokud má systém nějaké prvky strojového učení (machine learning), všichni to nyní chtějí. My už to máme deset let, ale tehdy si to nikdo nedokázal představit. Nyní každý manažer větší firmy chce mít v systému odškrtnuté, že má AI nebo ML. Takové dotazy skutečně přicházejí.

Je to velmi super systém, ale pak mě zajímá, k čemu přesně slouží. Může se to zdát přehnané, ale občas si říkám: „Pane bože, že to tak opravdu je.“ Nebojí se lidé, že jim vezmete práci, když mluvíte o AI? Na jednu stranu si odškrtnou kolonku, že mají AI, a mluví o šetření času. Jak to máte vlastně se systémem? Když ho integrujete – Jindra mluvil o tom, že v těch velkých centralizovaných operacích, které mají dostatek dat, už je to z velké části automatizovaný systém, který se rozhoduje sám, a manažer supply chainu ho jen kontroluje, nastavuje a řeší. V jakých oblastech to bere lidem práci a v jakých jim to pomáhá (augmentuje), mění pracovní návyky a fungování?

To je velmi ožehavé a citlivé téma, ke kterému je potřeba přistupovat pomocí správné komunikace se zákazníky. Když jsem popisoval období, kdy bylo zaměstnanců dost a nešlo nikoho sehnat, tak to bylo v pohodě a super, protože ušetřilo práci stávajícím zaměstnancům, které nestačily běžné činnosti vykonávat. Když jsme slyšeli různé narážky a biznis case, říkali jsme: Člověka přímo neušetříte v penězích (P&L), nezaměstnáte ho, ale on se začne věnovat činnostem, které dosud nestíhal, protože na trhu nejsou další lidé. Díky tomu se zlepší fungování, služba zákazníkům, zákazníci si koupí více, protože zboží bude lépe vystavené a další sekundární benefity. To je pozitivní.

V dnešní době však už je třeba zpřísnit přístup, protože lidé se více bojí ztráty pracovních míst a nástupu automatizace. Měli jsme klienta, kde si přesně pamatuji implementaci, nebudu ho jmenovat, ale neustále prodlužovali zavedení, lidé přicházeli s problémy – stále jsme to házeli na správní radu (board) a říkali jsme, že něco nespolupracuje, že je potřeba to vyřešit, ale měsíc na to se řešení odkládalo. Po druhé lahvi vína mi jedna paní řekla, že celý tým se bojí, že až se to spustí, budou propuštěni. Slyšeli jsme, že management má tabulky na propouštění zaměstnanců. V té chvíli bylo dobré transparentně vysvětlit, že to jsou jen fámy, nic takového se neděje. My víme, že to není pravda, protože lidé nestíhají a naše práce jim pomáhá dělat hodnotnější činnosti. Díky tomu se projekt odblokoval.

Když k tomu přistupujeme, říkáme zákazníkům: Nevyhodíte ty lidi. Budou dělat práci, kterou počítač nemůže dělat. Člověk není stoprocentně nahraditelný počítačem. Má spoustu úkolů, třeba poradit zákazníkovi nebo servírovat lidskou sociální stránku, kterou nelze nahradit. Když je tisíc položek denně, není vhodné, aby to dělal člověk.

My se tedy zaměřujeme pouze na operativní, nudnou činnost – spočítat analýzy, sčítat data – což je nad lidské síly a je zbytečné, aby se tím zabývali. Ať se raději věnují péči o zákazníky a třeba prodají tři produkty navíc, protože se usmějí, vytvoří přátelský vztah. To jsou vlastně přínosy projektu.

Jak to děláš ty, Jindro, v implementační fázi? Jak se rozhoduješ, jak moc to bude automat a jak moc doporučovací systém?

Hodně záleží na očekávání klienta. Jak už Ondra říkal, je potřeba vše nastavit s klientem dopředu. Logika je zajímavá. Pokud chceš mít systém plně automatický, tak má to své stinné stránky a věci, které je potřeba udělat.

Výhodou plné automatizace je větší přínos systému, lidé se nemusí tolik zapojovat. Ale musíš mít zvládnutou digitalizaci, protože systém automaticky musí dostávat většinu vstupních dat, která v firmy existují. Například pokud systém nemá evidenci balení, může navrhnout 16,5 kusu, ale neví, že má objednat 20, což člověk ví z praxe. To je jedna ze zásadních věcí, o které musíte přemýšlet při automatizaci – mít zvládnutou digitalizaci a dosaženou určitou úroveň firemní zralosti, tedy že věci jsou zaznamenávány elektronicky a data jsou k dispozici. Jinak systém nemůže správně fungovat.

Druhá věc je, že implementujete model, do kterého zahrnujete určitá vstupní data a ladíte jej. Model nikdy nebude dokonale odpovídat realitě – už by pak nebyl modelem. Musíte do něj promítnout spoustu parametrů. To znamená, že implementace dá práci a je dražší. Když měníte procesy, musíte upravovat i model.

Máme několik klientů, což je běžné – například mají kamenné prodejny a právě rozjíždějí e-shop. Pokud máš plnou automatizaci, nejsi schopen jen říct, „pojďme zavést e-shop“ a zadat nové procesy lidem. Musíš řešit s námi změnu procesů v systému tak, aby se to promítlo do modelu a systém mohl reagovat správně. Tento krok vyžaduje určité fixní náklady – bez ohledu na počet prodejen – protože musíš nastavit model tak, aby odpovídal realitě.

Rozdíl je potom v tom, že větší firmy z toho mají násobný přínos, například když máš 500 prodejen, přínos je 500krát větší než u firmy s 10 prodejnami, kde je efekt nižší.

Ze zkušenosti tedy u větších klientů usilujeme o co nejvyšší automatizaci, protože dává ekonomický smysl. U menších klientů to často končí nástrojem, který nákupčímu napovídá, kolik by se mělo objednat, ale některé věci, které zná jen člověk, tam nejsou zahrnuté a musí být zohledněny ručně.

I velcí klienti, kteří mají plně automatizovaný systém, potřebují mít „volant“, tedy možnost do systému zadávat vlastní vstupy, například informaci, že na trhu se objevil nový hráč nebo sortiment, který je relevantní a musí být zohledněný. Některé informace nikdy nelze plně automaticky digitálně získat. Systém je takto postaven.

To mi skvěle nahráváš. Jak moc se změnila realita a obchodní situace kvůli covidu, ukrajinské válce, přerušení dodavatelských řetězců, blokování Suezkého průplavu či podobným velkým událostem, které změnily fyzický svět? Museli jste hodně zasahovat do kódu, nebo šlo hlavně o konfiguraci a změnu obchodní strategie, která se podle toho promítla do konfigurace softwaru – například přechod od maximalizace zásob k minimalizaci skladů?

Dá se říct, že jsme nic doprogramovávat nemuseli. Pouze jsme využívali nástroje, které klienti mají k dispozici pro řízení. Ti si sami definují nastavení, například předpokládají, že u některých produktů nastalo těžší období, tak budou měnit limity a očekávají, že se bude prodávat méně nebo více. Tyto vstupy zadává klient.

Další věcí je centralizace rozhodovacích procesů. Pokud máte náš software, jako manažer rozhodnete a systém automaticky přenese rozhodnutí na všechny prodejny, takže efekt nastane téměř okamžitě. V případě decentralizace, kdy za nákup zodpovídají jednotliví vedoucí prodejen, je potřeba komunikovat s mnoha lidmi, což může být těžší. Každý má svůj úsudek, situaci řeší individuálně.

To je důležité téma, stejně jako automatizace celkově.

Ondro, mě zajímalo, jak moc se dá na základě historických dat predikovat budoucnost, když jsou události jako covid, kdy jsou predikce extrémně těžké?

Často musíme nejdříve vyčistit vstupní data pro modely, například zkrátit historii a ignorovat starší data, protože neplatí. Naši algoritmy jsme vylepšili tak, aby více reagovaly na poslední dny a týdny prodejních dat.

Takže jsme provedli jen změny konfigurace, aby model reagoval rychleji na nové situace. Tato opatření zahrnují vyčištění dat a úpravu citlivosti modelů.

Ohledně budoucnosti je to obtížné, protože nikdo neví, co přijde. Například u covidové pandemie jsme neměli historická data k předpovědím, obdobu nemáme od 30. let 20. století. Doufáme, že už takové černé labutě nebudou.

Existují ale i takzvané bílé labutě, což jsou události, které lze do určité míry předvídat.

Co aktuálně v Logiu řešíte? Na čem pracujete?

Odcházíte od on-premise řešení směřujete více do cloudu. Jaké další milníky vás čekají?

Technologicky je to právě cloud.

Obchodně se snažíme zaměřit na větší klienty, zejména nadnárodní firmy. Nemohu uvádět jména, ale obecně to tak je. Spolupráce například s Dr. Maxem, Albertou, Nestlé a dalšími velkými firmami nás posouvá dál.

Důležité je, že díky nim se dostáváme i na zahraniční trhy. Máme totiž různé pokusy i strategie, jak expandovat do zahraničí. Nejefektivnější cesta je proniknout skrze klienty z Česka, kteří jsou nadnárodní skupiny. Máme-li již reference v rámci skupiny, postup v zahraničí je snazší, protože nás doporučují a máme kontakty.

Například když jsme přišli do Itálie, bylo těžké získat klienty. Ale když tam máme již jednou zavedeného klienta, můžeme na něj navázat a máme italské kontakty. To nám hodně pomáhá.

Z obchodního hlediska se tedy snažíme primárně jít za velkými klienty v zahraničí.

Když mluvíme o zahraničí, máme na mysli především jihovýchodní Evropu a jihozápad, i když velmi doufám, že Itálie a Francie budou naše další trhy. Vždy mě baví, jak se někdo snaží vyslovovat Logio různě, ačkoli to má latinský původ, což dodává určitou mezinárodnost a ležérnost.

Doufám, že jednoho dne bude Logio ve Francii také velké a uznávané u velkých klientů.

Děkuji moc, že jste u nás šířili lásku k supply chainu. Držím palce a věřím, že se ještě uvidíme.

Děkujeme, bylo to skvělé.

Super, díky.

Tímto to končí. Děkujeme, že jste doposlouchali až sem. Díky také našim partnerům.

Pokud vás zajímá víc, navštivte naše stránky datatalk.cz a přihlaste se k odběru našeho newsletteru.