Vaše skupina už platformu SAP využívala, a proto bych se na začátek chtěla zaměřit na hlavní výzvy, kterým jste čelili. Jednak společnost už měla aktuální vizi, a s tím souvisela určitá úprava procesů a přechod na standardizaci, to byl jeden z důvodů, proč se nakonec šlo do cloudu. Zároveň tam byl i velmi zajímavý model samotného rolloutu. Nebo řekněme projekt a postupné routy, tak můžeme k těm hlavním výzvám. Co byste si dali jako hlavní priority? 

Ono to bylo poháněné samotným byznysem. První věc byla to, že před přibližně dvěma lety jsme od společnosti Chemours koupili americkou divizi výroby kyanidových produktů. Oni sami už SAP měli. Velmi starou verzi. Ta byla neskutečně přecustomizovaná, už jsme v ní nemohli dělat vůbec nic. Všechno neskutečně složité. A kromě toho, že už byla mimo podporu.

Druhá věc je, že Draslovka roste nejen organicky, ale i akvizicemi. Rosteme velmi významně. Není to jen samotná výroba, ale v současné době vyvíjíme i vlastní produkt na bázi strojového učení. To je jedna z inovativních věcí, a plus jsme potřebovali jako skupina konsolidovat. To znamená, potřebovali jsme mít jednotné procesy, aby když byznys v Americe řekne, že je to A, tak potřebujeme, aby byznys v Evropě nebo v Austrálii řekl, že je to taky A.

 A poslední věc je právě poháněná tím, že jsme potřebovali zvládnout akvizice co nejrychleji a posouvat se dál.  Chtěli jsme být schopní rychle adaptovat nové společnosti. Tam si nemůžete dovolit v ten daný okamžik každou firmu nastavovat znovu a vymýšlet všechno znova.

Ne všichni v SAPu předtím pracovali, jako například Lučební závody v Kolíně nebo ostatní byznysy v Austrálii, jižní Africe, tam třeba měly svoje vlastní lokální softwary.

 Rozhodlo se, že to bude SAP a bylo to logické, protože jsme evropská firma a SAP Evropě vládne. Takže SAP bylo jednoznačné rozhodnutí, nebo řekněme první volba.  Další důležitý krok bylo, jak do toho. 
 
Mně se strašně líbilo, když jsme si spolu o tom povídali, a i v rámci obchodního cyklu, jak jste přistoupili k těm dvěma pohledům? První, ten end-to-end pohled, to znamená ne nutně reflektovat tak, jak SAP má moduly, nebo nějakým způsobem to rozdělené, ale opravdu se podívat, jakým způsobem chcete end-to-end pokrýt jednotlivě. Protože jste zmínil, že každý váš závod je maličko jiný, má nějaká svá specifika, ale zároveň udržet standardy. Které všechny procesy třeba nakonec jste museli změnit? Myslím, že to byla organizační struktura, dokonce snad i účetní osnova. Jak velký zásah pro firmu to nakonec byl?

Byl to obrovský zásah a pořád to ještě je velká změna. Není to o tom, že bychom tu změnu udělali one-shot a jdeme od toho. My jsme do SAP řekli, že musíme udělat jednotné procesy v rámci firmy a pojďme se na to podívat v rámci SAP best practices. Pojďme se na to podívat prakticky. To znamená, tam, kde to fyzicky dává smysl, tak tam pojďme ten proces upravit. Pokud to je možné v rámci standardu, ale nebylo tam stoprocentní dogma toho, že to musí být čistý standard SAP. Teď jsme na 90, 95, 92 procentech standardů SAP. Jde jen o to změnit mentalitu lidí.

Daleko větší problém bylo to, že jsme řekli, že potřebujeme jednotnou měnu pro celou skupinu a jednotný účetní standard, protože máme tady US GAAP, máme tady kanadský GAAP, mexický GAAP, český GAAP, australský, všechny ty lokální GAAPy. Americká část jela v US GAAPu, tady v Čechách jsme jeli v IFRS, Austrálie a spol. se konsolidovalo do IFRS. To nám trvalo, upřímně řeknu, jako jednotky měsíců. Velká diskuze byla o tom, v čem vlastně budeme konsolidovat, co bude náš takzvaný primární ledger, a zároveň co bude měna. Budete se divit, ale zvolili jsme si IFRS a měnu americký dolar. I tohle nám SAP bez problémů nabídnul, což je výborná kombinace. A to ze dvou důvodů: je to stabilita měny, ale je to zase naše další vize, a proto jsme se rozhodli pro IFRS. A to byla úplná revoluce přes celou skupinu, protože vysvětlujte v Americe, co to je IFRS, ty znají svůj US GAAP, ten je jim svatý, a najednou to – máte napasovat na jiný účetní standard

Já si myslím, že je důležité skloubit dvě věci. Přizvat experty. A to experty z venku, kteří rozumí tomu produktu a dokážou vás provést implementací, a ve vhodný okamžik přizvat i ty vnitřní experty, kteří zase rozumí tomu procesu, produktu, výrobě a tak dále

 A já si vzpomínám z toho našeho povídání, že jste hrozně hezky popisoval propojení Mexika a Kolína a zapojení všech expertů dohromady. Můžete to trošičku víc rozvést. 

Já možná řeknu na začátek jednu věc, konzultanti vám nevyřeší váš problém. A bylo to i na naší straně. Všichni lidé si mysleli, že přijde konzultant, řekne jim, jak to má být, co je pro nás nejlepší, a podle toho to nastaví. A takříkajíc, my si umyjeme ruce, otestujeme to nebo ideálně, aby ta konzultační firma to i za nás otestovala a vyškolila nás, jak s tím dělat, ono to poběží. Tak to není.

První velký mindset, který bylo potřeba změnit: vy musíte těm konzultantům říct, co chcete, a oni vám vlastně jenom řeknou, jaké jsou nejlepší možnosti, jak to udělat. Ale konzultant vám neřekne, účtujte to na účet 1, 2, 3, 4. Konzultant vám řekne, že ve většině firem se to dává sem, ale jestli to chcete mít někde jinde, proč ne. Takže konzultanti jsou poradci a vaši mentoři k tomu, co jsou vaše myšlenky, vaše požadavky.

Ale to, co my jsme vlastně udělali, tak tenhle projekt nebyl drivovaný IT, implementace SAP, která je drivovaná IT, je, řeknu, minimálně z 50 a více procent předurčena k zániku a neúspěchu, protože IT není pupek světa. My jsme přes celý svět vybrali specialisty nebo experty na tu svoji oblast. Bylo úplně jedno, jestli to je právě člověk z Mexika, který má na starosti logistiku, nebo jestli je to člověk z Ameriky, který má na starosti finance, nebo jestli je to člověk z Prahy. Bylo to o tom, že jsme dali dohromady ty nejpovolanější lidi přes celou skupinu. A nasměrovali jsme ty procesy tak, aby to všechno do sebe klapalo v rámci celé skupiny, jak to vlastně chceme mít. To znamená, to, co nejlíp funguje v dané oblasti, do budoucna budeme fungovat stejně a díky tomu získáme ve výsledku stejná čísla.

Má to několik úskalí. První úskalí, které je vždycky, je jazyková bariéra. Pro nás je angličtina pracovní jazyk, ale stejně já mluvím českou angličtinou, Španěl nebo Mexičan mluví španělskou angličtinou a podobně. Komunikace je kvůli jazykové bariéře složitější. Poslední věc, která byla asi největší problém, je časová diference. Časová pásma, to je něco, kdy najednou zjistíte, že ten tým je schopný se potkat jenom ve čtyřhodinovém okně každý den a tím ztrácíte flexibilitu nebo dynamiku toho projektu. Ale má to zase obrovský benefit toho, že, když si to takhle složíte po streamech a máte někoho, kdo vám to složí dohromady, tak to funguje a všichni to přijmou, to je to krásný. 

Já se zeptám ještě prakticky, protože vy jste udělali velmi zajímavou kombinaci i při výběru partnerů, kdy v podstatě to nebyl takový ten klasický model, jeden velký generální partner, který to z jedné země řídí, ale právě že jste měli i výběr partnerů, cross a dokázali ten tým namíchat. Jak jste s tím byl spokojený a jakým způsobem byste to dneska vyhodnotil? Byla to součást úspěchu projektu?

Ano a ne. Já jsem zvyklý si vybírat to nejlepší. Tudíž implementačního partnera pro IRP jsme si zvolili americkou firmu, v té době Enova, dneska je to Reply, prošli akvizicí a koupila je firma Reply. Ale neměli zase úplně dobré znalosti a zkušenosti se SAP BTP cloudem jako takovým. Takže jsem sáhnul po lidech, o kterých jsem věděl, že to velmi dobře umějí. Je to tady v Čechách firma EFFIIS, nebo respektive teď se odčlenili a nově se jmenují tuším Climate, a ti umějí výborně integrační platformu, BTP technologie a další věci. Pro konkurz jsme si právě zvolili tady v Čechách Deloitte, protože měli zkušenosti a doporučení, a musím říct, že to funguje, ale je to všechno o lidech.

To znamená, ano, úspěchem rozhodně bylo to, že jsme si vybrali to nejlepší, nebo teda velmi dobré implementační firmy, a o tom, že lidé byli mezi sebou schopní povídat se a schopní pracovat nad rámec svých zodpovědností. To znamená, my jsme řekli, chceme to mít takhle, ale nebylo to detailní zadání a oni to udělali tak, aby to fungovalo, jak to má běžet.

 
Mně se líbila v tomto řekněme detailnost, jak moc jít do posledního šroubečku definice. Ten moment, přestože nebyl perfektní a nebyl dokonalý, tak jste si řekli, už to stačí, jdeme dál. Jak byste tohle dneska zhodnotil, narazili jste tam potom na to, že jste nešli až do těch 100 % a spokojili jste se s vysokou kvalitou blueprintu, ale třeba ne úplně dokonalou? 
 
Náš přístup byl v tomto pragmatický. My jsme si nejdřív vzali best practices a nechali jsme byznys vybrat všechny best practices. Řekli jsme si dobře, takhle to nejde a vybrali jsme takzvané MVP – minimum valuable produkt.  Řekli jsme si, co je opravdu must to have, bez čeho nebudeme fungovat. Poté jsme si určili, co můžeme nasadit později ve fázi dva, dokážeme bez toho žít, ale je dobrý to mít v další fázi. A v poslední fázi jsou všechna ta velká přání advance functionalit speciálně jako machine learning a další věci.

Základ je to, že lidi nevědí, že v systému musíte mít data. Proto, potřebujete třeba dva roky dat, aby se na tom systém mohl učit. Takže jsme řekli, tohle je něco na to C, víme o tom, že bychom to rádi, ale na to zapomeňme. B je něco, co si teďka zaparkujeme, ale mějme to připravené pro budoucí design. A to je něco, co je opravdu must to have. Udělali jsme si revizi procesů a šli jsme na to systémem agnostik. Jinými slovy, revidovali jsme to primárně z pohledu našich end to end procesů.

To znamená, máme tady template a přesně to byly ty kulaté stoly a další věci, aby ty věci fungovaly do sebe. Plus k tomu byly vstupy od byznysu, které říkaly, ale my potřebujeme mít detailnější analýzu ziskovosti. My potřebujeme být schopni detailněji analyzovat tyhle náklady a podobně. To znamená takové ty praktické věci ohledně KPI a dalších.

Takže první byly procesy. Vůbec jsme neřešili, jestli to bude doklad typu A nebo typu B. Procesy jsme prošli jako majoritu, 90 - 95 % jsme skutečně prošli a šli jsme na to blokama. To znamená tam, kde už jsme ten blok zavřeli, tak už jsme šli do detailního blueprintu, pokud to nemělo přesah někam do jiného streamu. My jsme nešli principem toho, že uděláme hlavní blueprint nebo high level blueprint a ten úplně zavřeme a budeme teprve potom pokračovat detailním blueprintu. Když byla zavřená konkrétní sekce a neměla přesah do jiné oblasti, protože samozřejmě v ten daný okamžik se muselo počkat na danou oblast, tak jsme šli do detailního blueprintu. Mělo to svoje pro a proti. Občas to proti je, že jsme se museli vrátit a revidovat to, protože někdo přišel se spásnou myšlenkou, novým procesem a podobně. Ale obrovskou výhodou bylo, že tam byl drive streamu, ten stream rovnou. Přešel z procesu do detailního designu a začal přemýšlet detailněji. Zase streamy, které byly pomalejší a nebyly třeba tak komplexní, ale potřebovali vyřešit více procesních věcí, tak měli svůj čas. To byla výhoda, nevýhoda samozřejmě bylo finanční řízení v daný okamžik, musíte si extrémně dobře hlídat budget, dodávky - co je už dodané a co není. Je to náročnější na projekt management. Neřeknu, že jsme byli stoprocentně úspěšní, to rozhodně ne v téhle oblasti, ale flexibilita a dynamika dodání projektu získávala obrovský drive. 

Já bych se posunula malinko dál, protože si myslím, že všechno toto vyvrcholilo úplně úžasně vaším dnem D, který nebyl jenom jeden den. Co všechno se stalo tenkrát v Mexiku? 

Primárně jsme to řídili z Ameriky z Memphisu, ale jenom pro posluchače. Šli jsme živě v Kanadě, Americe, Mexiku a Chile.  Tam máme jeden výrobní závod, hromadu terminálů, distribuuje se zde zboží a k tomu je tam i  obchod a další. My jsme spustili ještěrku v private cloudu, což je moje oblíbenější část, protože to není ten public cloud, kde máte velkou flexibilitu, ale máte tam omezení v nastavení systému, ale tady v private cloudu de facto mixujete výhodu publiku a on-premisu systému. To je takový správný mix pro mě, takže IRP, BTP, kde jsme šli dohromady s workflow managementem, integrační platformou, task centrem, pustili jsme Concur. Pustili jsme Kiribu, což není SAPové řešení, ale je to treasury řešení, kde jsme se napojovali na city banku. A okolo ještě hromada dalších věcí. 
 
Takže takový velký big bang. 
 
Ano, byl to obrovský big bang a šli jsme v režimu, já si dovolím říct big bangu, ale postupných startů. My jsme nejdřív pustili ERP a integrační platformu, což byl opravdu den D.  Svolali jsme celý svět, nebo ty, co na to měli, plus implementační firmu do výrobního závodu do Memphisu. 
 
Žádný Microsoft Teams? Tam jste se skutečně spolehl na fyzickou přítomnost všech lidí? 

Ono to jinak nejde. Opravdu já jsem těch go-live už zažil hodně jako konzultant. Bez toho, aniž byste ten tým, konzultanty a lidi z toho byznysu měli na jednom místě a mohli se tam potkat a ukázat si to, to prostě nefunguje. Takže my jsme vytvořili SAP control room, tak jsme to nazvali, což byla obrovská zasedačka v Memphisu. Tam seděli všichni konzultanti a v Memphisu v našem výrobním závodu byli všichni klíčoví uživatelé, vyjma nákupu. To z toho důvodu, protože celý nákup máme v Mexiku, takže naopak ten stream lead byl v Mexiku s tím týmem v Mexiko city. Jinak jsme všichni 14 dní, včetně mě, seděli v Memphisu a najížděli jsme v režimu kontrolovaného nájezdu. Jinými slovy, zadali jsme první prodejní zakázku a celý se to zkontrolovalo, že to funguje. Když to funguje, zadala se druhá. Když to fungovalo, tak se pustilo zadávání zakázek a jenom jsme to monitorovali. Udělali jsme výdej ze skladu, zase jsme to zkontrolovali, jestli se to zaúčtuje a takhle postupně jsme ve třech dnech spustili celý SAP. Nebudu nalhávat, nebylo to úplně stoprocentní, chyby tam byly. A kdo si myslí, že jde najet SAP bez chyby, to už není ani optimismus, já nevím, co je nad tím. 
 
Ještě prozraďte, jak proběhla ta příprava? Protože Draslovka jede, co se týče výroby, téměř nepřetržitě, pokud se nepletu, tak přerušujete dvakrát, třikrát ročně jenom z důvodů nějakých nutných technických přestávek. Jinak jedete pořád.  Jaké kroky jste musely podniknout, abyste nemusely zastavit na celých 14 dní? Jak jste se na to připravovali?
 
Skutečně dvakrát za rok máme technologickou odstávku. Jinak se jede furt. My jsme si dopředu vytipovali veškeré oblasti už v rámci business continuity plánu. Vlastně jsme si zaživa ozkoušeli business continuity plán, protože jsme vzali všechny postupy, které jsou a začali jsme uplatňovat. Dopředu jsme si řekli, co je potřeba udělat z pohledu logistiky a nákupu, když nebude systém fungovat.  Abychom si zabezpečili byznys lidi dopředu. Aby věděli, že mají mít vytištěný papíry, kde si zapisovat, co se vydává, co se dává, protože tu výrobu prostě nezastavíte. Obchodníci věděli, že veškerý díly musejí zadat dopředu a vyfakturovat dopředu.

Chtěli jsme migrovat jenom to nezbytně nutné minimum dat.  A to bylo něco, tu firmu pomohlo rozjet rychleji, protože my jsme nemigrovali tu strašnou zátěž z historie, ale jenom to nutný, i z pohledu konsolidace.

Na jednu stranu jsme si velmi dobře osvěžili a odtrénovali business kontinuity plán. Ale velká část byla taky vytrénovat lidi, kteří dělají byznys a vy jim do toho ještě hodíte nový procesy. Teď je musíte vyškolit, optimálně týden maximálně čtrnáct dní před go-live. Samozřejmě vytrénovat 300 lidí není úplně jednoduchý a o to víc, když jsou přes dva kontinenty.  A samozřejmě musíte do toho systému dodat historii. To znamená, co se stalo od okamžiku takzvaného blackoutu, kdy ten systém zavřete. Pak doplníte ty data, který jsou jakoby ty starý a teprve potom rozjedete ty nový.  Papír se často ztrácí, a největší výzvou bylo zorganizovat, aby si lidé po směně svůj papír s daty vzali a odnesli na ho správné místo, tak aby se nic neztratilo. Myslím, že tohle jsou velmi neocenitelné zkušenosti, zejména právě z těch provozů, kdy to nemůžete zastavit.
 
Dnes je to čtvrtý měsíc od spuštění. Jak to vnímáte teď? Posouvá vás to už dál? Bylo tam spoustu věcí, o kterých jste věděli předem, že je budete standardizovat, harmonizovat a posouvat dál z pohledu byznysu.

Je to datový sklad. My jsme měli největší problém to, že nejdřív ty data extrahujte, pak je někam natahujete, ztratíte tu časovou osu a lidi na to koukají s časovým řezem. Jenom na ty data, který mají v tom datovém skladu. No, a hlavně když ty data nemáte a nemáte tu informaci, tak ji nedohledáte, nejste schopní ji analyzovat.  Jednou ze strategických věcí, na kterých jsme se shodli, bylo, že rozhodně nebudeme implementovat datový warehouse s verzí 4. Jednak to nedává smysl a jednak je určení SAP S/4HANA úplně jiné než u datového skladu, a to zejména v kombinaci s analytickým cloudem.

To si můžete dovolit dělat jako hodně velký věci v real time, takže my jsme velký tlak kladli na lidi, aby do těch jednotlivých transakcí doplňovaly ty data nejenom teď, že tu informaci potřebuji, ale že s ní můžu do budoucna pracovat. My nejdřív musíme rozumět těm transakcím. Jinými slovy, vy musíte vědět, co v těch transakcích je. Pak se na to můžete podívat následně, když vám ty data sdružujeme v reportech, tak budete rozumět obsahu těch reportů a teprve potom si udělejme dashboardy.

Já už na to nemusím koukat jenom tak, kolik mám obratu přes dodavatele. Já už se na to můžu podívat, který materiály, který skupiny, proč nakupuji tenhle materiál od těchto dodavatelů.  Ukáže mi to, proč mi to padá na tyhle cost centra. To znamená, my jsme začali řešit alokaci nákladů, že ten vlastník toho cost centra je ten, který má říct, ano, já souhlasím s tím, že mi ten náklad patří. SAP S/4HANA vám přinese to, že vaše rozhodovací schopnost se posunou tak o 1 až 2 úroveň níž. Ta míra detailu, kdy manažer dřív viděl je to 100 milionů, teď si prostě ten report rozklikne a podívá se na to do detailu. Řekne, hele, prosím tě, proč jsme u tohohle utratili tolik. Nebo řekne, ale já už tenhle report nepotřebuji, co jsem po tobě chtěl. Já to vidím v těch datech rovnou. 

Rajská hudba pro moje uši. V rámci toho, že máte tak poučené uživatele. A skutečně řekněme chtivé uživatele, hledat tyhlety benefity toho systému jako takového. Ono to určitě potom spojuje i tu další věc. A to je snižování byrokracie a opravdu eliminace všech těch činností, které se dělaly navíc duplikované.  Pokud si to controlling umí vytáhnout sám a pokud se může dívat na spoustu dalších věcí, ke kterým třeba se dřív museli připravovat reporty. To je samozřejmě obrovská úspora. Ale já se vás chci ještě zeptat na jinou věc. Ve chvíli, kdy si představím, že někteří kolegové by předstoupili a řekli, ne, my vám teď ten report prostě v tom dělat nebudeme, protože se nejdřív musíte naučit, co tady máte a podívat se na to, co tady máte. Jak se vám to povedlo, že vás poslechli? 

Řeknu to trošku ošklivě, oni stejně neměli na výběr, protože ono je to o tom, že když do určitého času položíte obrovský množství úkolů, tak v určitý okamžik, je musíte prioritizovat. My jsme jim slíbili, že jim ty data dodáme, ale řekli jsme a upřímně, že prostě ty reporty nejsou. Je to jedna z těch problematických oblastí, na kterou teďka narážíme.  My řídíme ty data a jako některý data prostě dáváme dohromady v Excelu, zjišťujeme a párujeme je proti sobě a pak to čistíme. Je to daň za rychlost.

Ta ideální doba implementace SAP S/4HANA je podle mého tak osmnáct měsíců. My jsme jí měli něco přes dvanáct. Jsem za to tlučený teďka, takže jako nebudu nalhávat, že ne. Ale na druhou stranu je to o tom, že ty požadavky na ty reporty a ty legacy se mění a už to není: já chci, aby to bylo tak, jak jsem to měl já, ale potřebuji tam tyhle data a tyhle data.  Na jednu stranu je to nevýhoda pro tu firmu,  ale na druhou stranu je to velká výhoda, protože my jsme tam nepřenesli to, co nás původně byznys tlačil. My jsme se dohodli, že to prostě nedodáme a dodá se to po go-live. Ale na druhou stranu jakoby ten byznys nás částečně tluče, že ty data nemá, ale na druhou stranu říkáme, ono je to vlastně dobře, protože my na to koukáme jinak. 
 
Kdyby jste měl vypíchnout jednu věc, kterou byste znova udělal stejně, protože ji považujete za řekněme, kámen toho úspěchu a naopak. Možná to, co jste zmínil k tomu školení těch lidí nebo co by bylo řekněme dneska, když už vidíte těch dvanáct měsíců a máte i tu zkušenost těch čtyřech měsíců živého provozu. Co byste zkusil udělat jinak? 

To, co bylo inovativní, nebo to, co bych nechal tak, jak je, je skutečně jednak volba, kde nám ten systém běží. To znamená opravdu ta kombinace, to znamená SAP S/4HANA v private cloudu v RISE, BTP, integrační platforma, prostě ta volba těch technologií a i ten mechanismus toho blueprintu. To znamená high-level, byznys blueprints, proces. Pojďme si uvědomit, co chceme, pak detail, pak implementace. To opravdu hodně pomohlo i v rámci zapojení týmu. To, co bych změnil na prvním místě teď po těch čtyřech měsících, by byl ten produkt VIM (Vendor Invoice Management) od OpenText, včetně OCR a všeho. Bohužel ten americký dodavatel totálně selhal, takže my teď máme obrovské problémy a vlastně to teďka celý přenastavujeme. Dělá to tady česká firma. To bylo prostě, to je peklo na zemi. Řeknu nepokrytě, že ano. Takže ověření opravdu dodávky, jakoby to, co je a jak to funguje. To je jedna věc a druhá oblast je více trvat na dokumentaci toho, že ty věci se staly. Dám vám příklad, byznys testoval nějaký proces a úspěšně reportoval, že ho otestoval. Minimálně v test trackeru bylo označeno, že proces proběhl. Šlo se na produkci, byl go-live a my jsme zjistili, že to v životě nemohlo fungovat, protože ta věc prostě nebyla nastavena. Ale samozřejmě všichni si udělali zkratku, takže se odreportovalo, že to fungovalo. Takže opravdu větší preciznost hlídání těch věcí a v dokumentování. Je to opravdu o tom si nechat udělat printscreen z toho testu, dát si tam čísla dokladů a uložit si ty věci tak, aby to bylo opravdu zdokumentováno. Tady stokrát platí, důvěřuj, ale prověřuj.

Ale i z toho jak jste o tom dneska povídal, celkovou komunikaci vnímám jako velmi důležitou.  Nejenom ty kulaté stoly, o kterých jste hovořil, ale vlastně i ten model toho, jak byly jednotlivé týmy informováni o celém progresu. To, jakým způsobem jste skutečně dotáhli úroveň té komunikace a toho, že vlastně ten tým byl pořád zapojený, to se mi strašně líbilo.  
 
 Za to jsem v té firmě strašně vděčný. Byla tam obrovská podpora managementu, což je další stavební kamínek a základ pro ten projekt. Management dal prioritu klíčovým lidem a vyčlenil jim časové kapacity. Neřekl jen: „Dělej svou práci a k tomu ještě tohle.“ Měli jsme konkrétní dedikované lidi, kteří věnovali 80 % svého času projektu a 20 % běžné agendě, aby byznys plynule pokračoval.

Strašně záleží na čase, kdy se to dělo. Ale toto a podpora managementu byla opravdu velice důležitá. A i ta flexibilita nebo vstřícnost těch lidí. Ono, v rámci takovýhle velký změn a té akvizice. A do toho ještě byznys změny do toho tlak na budget. Do to všecho udržet ty lidi mentálně v tom běhu je strašně důležitý.

Důležitá věc kterou musím říct, my jsme odkládali go-live, odkládali jsme ho dvakrát.  Nejdříve jsme plánovali duben, ale to by byla fakt obrovská chellenge, takže jsme ho posunuli na červenec. A to už vypadalo, že jedeme, ale ještě jsme nějaký potřebovali čas. Byznys to chtěl posunout dva až tři měsíce, ale my jsme řekli, ne, dáme vám měsíc. Bylo to z toho důvodu, že jsme si byli jsme vědomí toho, že když jim dáme víc času, tak ztratíme jejich pozornost.  My jsme věděli, že nenajíždíme stoprocentní systém. My jsme věděli, že tam jsou chyby a nedodělky, ale šli jsme do toho.  Byli jsme si vědomí toho, že když to začneme řešit na produkci, tak se to vyřeší daleko rychleji, než když to budeme neustále jak blázni do kolečka testovat. Protože stejně nikdy nedosáhnete 100%. Bude to 99,9, ale nikdy to nebude 100%. 
 
Myslím, že dneska žijeme ve světě, kde prostě stoprocentní jistota neexistuje a myslím si, že právě společnosti jako jste vy, který dokážou přijmout určitou míru rizika a nejistoty, tak je hybatel toho, aby vůbec ty projekty mohly být úspěšný. Ale musí zatím být ten management, který vás v tom nenechá a který ví, proč se to dělá a kam vás to má posunout. tak je hybatel toho, aby vůbec ty projekty mohly být úspěšný.

Pokud vám s tím management nechce pomoct nebo řekne, že je to IT projekt, tak ať si to udělá IT. Tak pravděpodobnost, že takový projekt skončí špatně anebo nedopadne, je obrovská. Pokud management není ochotný adoptovat změny procesů nebo změny myšlení, nebo říct těm lidem, hele, sorry, prostě, ale už jako nejsi ochotný adoptovat tu změnu, tak jako tady zůstaneš, jenom to dodělat v rámci starého systému, ale nahradí tě někdo ochotnější a to udělá takový neuvěřitelný signál pro ten zbytek toho týmu. V rámci našeho managementu to byly ochotný udělat, ne vyhodit lidi, ale řekli, jsme si vědomi, že už jsi starší, že máš čas do důchodu, tak to s námi vydrž a dotáhni to. Pak sem vezmeme nového člověka, který to začne řešit, a ty mu budeš k ruce.

Já si myslím, že v rámci vašeho projektu je tam celá řada ještě dalších best practices. Věřím, že na nějaké příští akci si o tom budeme moct ještě popovídat podrobněji. Třeba o tom, jakým způsobem zapojit jednotlivé lidi a udržet si to know-how, je něco, co prostě dává klíčové prvky tomu projektu.

Honzo, já moc děkuju za dnešní povídání. Moc si toho vážím, že jste byl prvním v rámci této minisérie. A tím dalším bude společnost Gasnet. A tam uvidíte celou řadu dalších paralel s tím, o čem jsme dnes hovořili. A já ještě jednou děkuji Honzovi.