Dobrý den. Vítám vás u dalšího dílu Unfiltered podcastu. Tentokrát se znovu vrátíme k nákupu a budeme se bavit s Martinem Pokorným. Dobrý den, Martine.

Dobrý den, Hanko.

Martin je ředitel nákupu v Siemens Energy. Kdybych měla představit vaši společnost, tak je to relativně mladá firma se 150letou historií, protože jste se vyčlenili ze Siemensu v roce 2020. Nejste ale žádný drobeček – je vás přes 100 000 v 90 zemích světa. A co je pro mě asi úplně nejzajímavější, je fakt, že téměř šestina veškeré produkce elektrické energie je nějakým způsobem provozovaná nebo realizovaná tím vším, co děláte. Takže mladá firma s velkou tradicí a velkým dosahem. Co vlastně nakupujete, Martine? Zeptám se takto na úvod.

Máte pravdu, máte perfektní znalosti o tom, co děláme a kým jsme. Já konkrétně mám na starosti nákup v České republice a 95 % aktivit mého týmu se věnuje parním turbínám. To znamená světu parních turbín, turbosoustrojí a zařízení, která s tím souvisí.

Pomozte mi – co taková parní turbína potřebuje? Co objednáváte?

Parní turbína ke svému provozu potřebuje v první řadě páru. Ale co se týče nákupu, objednáváme celou řadu věcí – od surových materiálů přes polotovary až po funkční zařízení a celky. Realizujeme i stavební práce u zákazníků. Nakupujeme tedy ocel, ložiska, výkovky, odlitky či svařence, ale i složitá zařízení, jako jsou převodovky, rychloběžné spojky, kondenzátory a generátory. Zajišťujeme také práce na stavbách, uvádění do provozu nebo supervizi. Je to velmi různorodý svět, projektový byznys, který je neuvěřitelně zajímavý.

A co z toho všeho nakupujete nejraději?

Co mám nejraději? Abych se přiznal, prošel jsem si vším a je to moje srdeční záležitost. Mám rád jak výkovky, tak generátory – líbí se mi vlastně všechno a nemohu říct, co z toho je nejhezčí.

To se asi na e-shopu nakupovat nedá, že?

Na e-shopu ne. Musím přiznat, že kvalifikační proces pro naše partnery je velmi robustní a vytěžující, a to i pro nás. Máme případy, kdy nového partnera kvalifikujeme i několik let. Bohužel, nebo možná bohudík, vzhledem k tomu, co dodáváme našim zákazníkům, není úplně snadné najít nového partnera a začlenit ho do řetězce.

Ptám se na to proto, že téma a projekt, o kterém se dnes budeme bavit, je Master Data Governance. Společně jsme totiž – v podstatě až na druhý pokus, k čemuž se určitě dostaneme – zvládli v Siemens Energy v podstatě revoluci v tom, jakým způsobem spravujete data a údaje o svých dodavatelích a partnerech. To je pro vás naprosto klíčové. Když slyšíme o turbínách a dalších složitých zařízeních, je jasné, že nejde o jednoduchý nákup. Pojďme se vrátit o pár let zpátky. Co bylo tím hlavním impulsem a myšlenkou, proč jste se pustili do projektu Master Data Governance?

Jak už jste zmínila, jsme firma s dlouhou historií, ale zároveň jsme mladá firma. Odštěpili jsme se v roce 2020 a součástí této dohody s původním vlastníkem, Siemens AG, bylo i to, že se vyčleníme s nástroji, systémy a technologiemi, které Siemens AG používá. Jedním z hlavních motivů tedy byla přirozeně změna nástroje na správu Master dat, respektive dat o našich byznys partnerech, dodavatelích a zákaznících. K tomu samozřejmě patří i harmonizace a standardizace. Jako firma jsme za posledních 150 let postupně rostli, takže když jsme nyní měnili systémy na MDG, odcházeli jsme od pěti různých nástrojů, které zahrnovaly několik dalších podskupin a různých procesů. Bylo to velice komplikované. Řekl bych, že to byl sice malý krok pro lidstvo, ale obrovský krok pro Siemens Energy.

Já bych se ještě vrátila k tématu Master Data Governance. Občas mám pocit, že je to vnímáno jen jako takové „nice to have“. Říká se: „Bylo by dobré, kdybychom ta data jednou vyčistili,“ ale pak přijdou urgentní záležitosti – potřeba nástrojů pro tendry, aukce nebo správu smluv, tedy věci úzce napojené na byznys. Co vám dnes, s odstupem času, potvrdilo, že investovat tolik času, peněz a lidí právě do Master Data Managementu mělo svou přidanou hodnotu?

Ta přidaná hodnota spočívala určitě i ve vyčištění dat, jak už jste zmínila. V rámci implementace jsme totiž zjistili, že některé obchodní partnery máme v systému vedené různými způsoby, pod různými jmény nebo hlavičkami, a to klidně i několikrát. Došlo tedy k odstranění duplicit a triplicit, k celkové harmonizaci a standardizaci procesů i podpory. Díky tomu máme dnes jeden centrální podpůrný tým, který obsluhuje všechny naše výrobní i obchodní jednotky v rámci 90 zemí, kde operujeme. Je to standardizovaný proces s jednotným přístupem – všichni přesně vědí, jak postupovat. Nestává se nám tak, že by měl každý region svůj vlastní nástroj a tým jen proto, že nikdo jiný neví, jak s daným systémem pracovat.

Dostali jsme k tomu i určitou nadstavbu. Není to jen o správě dat, ale o správě údajů o obchodním partnerovi jako takovém. Je jedno, jestli jde o zákazníka nebo dodavatele, navíc se to v čase vyvíjí – naši dodavatelé mohou být zároveň našimi zákazníky. Správa je pak mnohem jednodušší, i když se způsob spolupráce s daným partnerem změní.

Vlastně to zasahuje celou firmu. S dovolením použiji výraz „shit in, shit out“ – pokud chcete, aby výsledek vypadal jinak, musíte se vrátit na úplný začátek. U aukcí nebo jiných nástrojů bývá vlastník jasně daný, ale tady jde o projekt napříč celou společností. Bylo právě nejasné vlastnictví a určité „přetahování“ o to, zda za projekt odpovídá IT, finance, nebo nákup, příčinou toho, že jste to zvládli až na druhý pokus? V úvodu jsem naznačila, že tam došlo k prvotnímu nezdaru, nebo, řekněme, „fuckupu“.

Určitě. Upřímně řečeno, těch problémů tam byla celá řada a nejasné vlastnictví procesu bylo jedním z nich. Někdo v boardu rozhodl, že aby se zachovala neutralita, nebude projekt řídit nákup ani obchod, ale tým financí. Nechci hodnotit, jestli to bylo dobře, nebo špatně, ale pro vlastnictví procesu a motivaci mít systém k určitému datu funkční to nebylo ideální. Tým financí nemá v praxi s byznysem se zákazníky ani dodavateli mnoho společného. K tomu se přidaly další chyby: příprava byla krátká a málo intenzivní, nebyly nachystané scénáře ani plány B. Mohl bych jmenovat celou řadu dalších věcí.

K tomu se postupně dostaneme, ale považuji to za velmi důležité. Při tom „resetu“, kdy se projekt restartoval, už bylo vlastnictví jasné. Když jsme si spolu povídali, zmínil jste také redefinici role klíčového uživatele a úpravu zadání. Můžete popsat, v čem se po tom úvodním nezdaru změnil přístup k roli klíčového uživatele, aby to tentokrát dopadlo dobře?

Tady se musím vrátit do období, kdy jsme končili s původním nástrojem. Tehdy jsme „klíčového uživatele“ chápali jako někoho, kdo má uživatelskou znalost nástroje, ale už nemusí mít technický přesah nebo představu o tom, jak by měl fungovat systém nový. Definice byla špatná – klíčovými uživateli se stali ti, kteří s nástrojem sice pracovali, ale v mnoha případech to byly asistentky oddělení. Dnes už vím, že asistentky nejsou ti praví lidé pro implementační a testovací fázi.

Pojem i chápání té role jsme proto od základu změnili. Musí to být člověk, který chápe věci v souvislostech a dokáže ostatní provést celým procesem správy Master dat. Musí umět připravit scénáře, manuály a videonávody a být součástí týmu, který řeší konflikty a chyby. Dnes vnímáme klíčového uživatele jako člověka s technickým přesahem, který je schopen trénovat další kolegy.

A pokud si pamatuji správně, v počtu těchto lidí jste se dostali ze 4 na 25.

Ano, to byla další věc. My jsme de facto v Siemens Energy změnili metodiku a rozhodli se, že správu dat si bude každý uživatel byznys partnera provádět sám. To se ukázalo jako další problém. Jsme totiž projektový byznys, což znamená, že lidé v určitých rolích spravují Master data svých zákazníků nebo dodavatelů jen velmi zřídka – třeba jednou či dvakrát za rok, protože tak často partnery neměníme ani nepřidáváme.

Z toho vyplývá, že tito lidé mají omezenou znalost práce se systémem i samotným procesem. Když něco děláte jednou za rok, logicky v tom nejste dokonalí. Původně jsme měli čtyři lidi, kteří to dělali denně, a najednou jsme jich měli dvacet pět. Těchto pětadvacet lidí nám později ukázalo, jak obrovská může být v takovém procesu kreativita a invence. Zjistili jsme, že se nám vytvořilo šest až sedm skupin a každá z nich dělala věci malinko jinak, jinak pracovala s daty a odlišně chápala dopady svých kroků v systému. To nám nakonec způsobilo takový chaos, že jsme ani nedokázali přesně popsat chyby, které vznikaly, abychom je mohli eskalovat a řešit s technickým týmem. Takže i v tomto směru to byla obrovská změna.

To nás vede k dalšímu důležitému ponaučení, které z první fáze vyplynulo. Už jste zmínil testovací scénáře, jejich popis a obecně přípravu – testování, vyškolení a to, co jste hezky nazval přenosem know-how, ať už procesního, věcného, nebo technického. Co byste vypíchl pro někoho, kdo by se ocitl v podobné situaci? Tedy v momentě, kdy si uvědomí, že projekt neodpovídá očekávání, a zvažuje, jak se reálně připravit na use-case a testování?

Pro nás to bylo obrovské ponaučení a odnášíme si z toho spoustu lekcí do budoucna. Firma obecně podcenila testovací a přípravnou fázi. Obdrželi jsme sice rozsáhlé manuály, jak se systémem pracovat, ale chyběly v nich scénáře pro správu konkrétních master dat. Tedy například: jak zadat nového partnera? Jak navést existujícího partnera z jiného závodu? Jak změnit bankovní nebo technické údaje?

Nic z toho nebylo otestováno. Skočili jsme do toho s obecným manuálem, který byl sice dlouhý, ale uživatele nenavedl ke konkrétnímu kroku. Prakticky každý náš zásah do dat byl chybný. Postupně jsme tedy začali připravovat scénáře pro konkrétní situace – jako klasické FAQ. K tomu jsme přidali videa, manuály a online tréninky. Dnes to zpětně hodnotíme jako naprostou nezbytnost už v testovací fázi.

V podstatě se potvrdilo, že bez prováděcího předpisu a zapojení lidí můžete mít nejlepší technologii, ale lidstvo zůstane tak kreativní, že do ní vloží něco, co nikdo nevymyslí.

Přesně tak. A to nebyl jediný systém, který jsme implementovali. Konkrétně v nákupu jich máme asi tři desítky a za posledních pět let jsme jich minimálně dvacet měnili. Lidé už pociťují určitou frustraci. Po každém členovi týmu dnes vyžadujeme určité digitální a technologické know-how, což není jednoduché. Dříve jsme žili ve světě, kde se nic neměnilo a vše fungovalo automaticky. Dnes tato dynamika mění i profil lidí, které ve společnosti potřebujeme.

Vaše oddělení se v tom pomyslném běžeckém závodě dostalo trochu dopředu. Máte unikátní know-how, jak dělat change management, protože jste museli absorbovat obrovské množství změn ve velmi krátkém čase. Stali jste se nositeli tohoto know-how pro celou firmu?

Přiznám se, že stali, i když jsme k tomu byli spíše donuceni okolnostmi. Potřebovali jsme s daty partnerů pracovat, abychom mohli objednávat a podepisovat smlouvy. Bez aktivního partnera v systému to nešlo. Museli jsme tedy převzít velkou část znalostní báze, připravovat manuály i pro ostatní a pomáhat jiným týmům například se správou zákaznických účtů. Je to pro nás poučení pro další implementace.

Dnes vidíme stále častěji, že byznysová oddělení musí přebírat roli experta i vlastníka (ownera) designu. Vy víte nejlépe, co k dokončení objednávky potřebujete. To za vás žádný technologický partner nevymyslí.

Uhodila jste hřebíček na hlavičku. Působíme v 90 zemích a máme 20 SAP systémů. Je nereálné, aby jeden centrální tým pojal potřeby všech závodů. Potřeba know-how se přenáší přímo do byznysu a nákupu. V první fázi jsme to vyřešili jedním velmi šikovným člověkem, ale cílem je, aby se tyto dovednosti dostaly ke každému uživateli, včetně mě.

Ráda bych, abyste okomentoval tři věci týkající se týmu. První je připravenost kapacit a vybalancování operativy tak, aby nezasahovala do práce na projektu. To byla v druhé fázi velká změna, včetně identifikace lidí – pokud se nepletu, vybral jste ty nejlepší z nejlepších.

Stoprocentně. To byla další věc, se kterou jsme se potýkali. Role globálního týmu podpory de facto skončila s očekávaným koncem implementace. Roll-out začal v září, končit měl v listopadu, ale my jsme ještě půl roku poté řešili tisíce otevřených ticketů. Ten tým skončil příliš brzy a byl příliš malý. Operace, která měla trvat dvě minuty, trvala hodiny, protože uživatelé neustále zkoumali, zda zadali data správně. Míra frustrace rostla a zde byla klíčová role lídrů, aby atmosféru v týmu uklidnili.

To mě vede k vaší větě: „Kdo se tomu měl věnovat a kdo neměl, jsme pochopili, až když nám to nešlo.“ V čem bylo to hlavní poučení?

Neměl se tomu věnovat nikdo, komu ten byznys proces nepatří. Ten člověk totiž nemá vazbu na následky, které způsobí nefunkčnost systému. Ideální je, když to dělají lidé, kterým proces patří – rychleji si systém osvojí, dokáží lépe popsat potřeby pro podporu a hlavně připraví scénáře, aby se nezastavil byznys. My jsme se v určitých chvílích museli vrátit k papírovým objednávkám mimo SAP, ale tyto „plány B“ jsme bohužel připravovali až ex post, když jsme zjistili, že 90 % zadaných dat je nefunkčních.

Muselo to být náročné období, stovky ticketů a pokusy systém „prošťouchnout“, což jen zvyšovalo komplexitu. Zavedli jste ale dva nástroje: „tiskového mluvčího“ pro komunikaci se supportem a protokol eskalace. Jak vám to pomohlo?

Důležité je nečekat, že vše bude od prvního dne perfektní. Musíte mít připravený proces, jak chyby popisovat a komu je předávat. My jsme to vymýšleli za běhu a proces eskalace se nám několikrát změnil. Někdy byl tak složitý, že lidi až odrazoval. Moje doporučení zní: připravte jednoduchý proces eskalace a scénáře komunikace s uživateli hned od začátku. U nás byl problém, že jsme dny i týdny nedostávali zpětnou vazbu. I prostá zpráva „víme o vás, řešíme to, ale máme jiné priority“ by tým uklidnila. Otevřená a transparentní komunikace by odstranila mnoho frustrace.

Siemens Energy má složitou strukturu – byli jste součástí globálního projektu, druhý spuštěný region po Americe, podpora v Indii, mnoho lokalit. Jak byl projekt nastaven z hlediska komunikace?

Jsme rozděleni do čtyř hlavních divizí a každá měla svého technického lídra. Ten komunikoval s IT týmy, poskytovateli i procesními týmy. V tomto rámci jsme se museli pohybovat, přičemž lidé se měnili za pochodu. Zjišťovali jsme, že v jiných divizích věci fungují jinak, a hledali jsme ne technicky správnou, ale nejrychlejší cestu k výsledku. To samozřejmě opět zvyšovalo frustraci, když kolegové viděli, že se jejich požadavky neřeší dostatečně rychle.

Dnes už jste nějakou dobu po nasazení a data se stále čistí. Vraťme se ale ke dni D. U vás to byl „Big Bang“. Jak ten den probíhal a čeho jste se nejvíc báli? Sdílela jsem vám větu jiného zákazníka: „Nebál jsem se, že to 10. ledna nepustíme, ale že to 15. ledna vypneme.“

Upřímně, já jsem se nebál, že by to nebylo funkční, což byla moje chyba. Měl jsem se bát víc. Koncem září jsme vypli starý systém, následoval týden „freeze periody“ a pak se otevřel systém nový. Mylně jsme očekávali, že díky manuálům budou lidé schopni správně zadávat data. Během prvních dnů jsme ale zjistili, že systém je buď nefunkční, nebo neznáme proces. Zažili jsme ten velký třesk se vším všudy. Na druhou stranu, kdybychom šli cestou pomalého učení, nebyli bychom schopni systém plně implementovat ani za dva roky.

Někdy je srážka se zdí nutná, aby člověk pochopil, kudy cesta nevede a že musí změnit přístup.

Zpětně to vidím jako fantastickou zkušenost, která nás připravila na další změny. Prověřilo to naši kreativitu a schopnost zvládat krize. Krizový manuál je k ničemu, když ho vytáhnete jednou za deset let. Důležité je vědět, jak budeme postupovat – kdo koho svolá, jak se bude komunikovat, kdo bude eskalovat a kdo trénovat, aby se to vše nesešlo na jednom přetíženém člověku.

Co tato zkušenost přinesla vám jako lídrovi? Musel jste reagovat rychle a ne vše bylo pod vaší přímou kontrolou.

Myslím, že každý lídr by si měl něčím takovým projít, protože v krizi se odhalí charakter. Nikdo ode mě nečekal, že budu řešit technické detaily, ale očekávalo se, že budu součástí týmu pro přípravu plánů B. Důležité je nebát se rozhodnout, nebát se eskalovat a přijmout zodpovědnost. Neházet vinu na druhé, ale soustředit se na řešení a vnést do týmu klid a harmonii, nikoliv paniku.

U kolikátého písmene v plánech jste skončili? Měli jste i plán E?

Asi tak nějak. Plány jsme měnili za pochodu, protože implementace trvala místo šesti týdnů několik měsíců. Ale krize nám paradoxně pomohla zlepšit technické know-how lidí v práci se systémem MDG.

Líbí se mi, jak z toho dokážete vytáhnout to pozitivní. Kdybyste měl vybrat tři věci, které už nikdy nechcete dělat stejně, co by to bylo?

Určitě bych změnil přípravnou a testovací fázi – jít do nejmenšího detailu a mít připravené scénáře i s videonávody. A za druhé, správně vydefinovat roli klíčových uživatelů pro technickou podporu i procesní řešení. To jsou klíčové věci.

Pod tím vším stojí technologie SAP. Uvažovali jste někdy během těch problémů o změně technologie?

Vůbec ne. Nedovedu si představit, že bychom v půlce procesu měnili technologii. Máme ERP systém SAP a další návazné systémy, takže implementace MDG byla naprosto logická. Kdybychom systém změnili, opakovali bychom stejné chyby znovu a lidem, kteří se s tím už naučili pracovat, bychom jen přinesli další frustraci.

Můžete mít skvělou technologii, ale pokud se na ni lidsky nepřipravíme, nebude fungovat. Náš čas se blíží ke konci. Na co se v Siemens Energy v nejbližší době těšíte?

V rámci nákupu i mimo něj mě teď nejvíc těší mentoringový program, který otevíráme pro Českou a Slovenskou republiku. Těším se, že dáme příležitost lidem, kteří se chtějí rozvíjet, a zkušení kolegové jim budou moci předat své know-how a inspiraci.

To přesně sedí k mladé firmě se 150letou tradicí. Martine, moc děkuji za váš čas. Hostem Unfiltered podcastu byl Martin Pokorný, ředitel nákupu Siemens Energy.

Já moc děkuji za pozvání.