Vítejte u dalšího dílu SAP Unfiltered Q&A. Dnes je mi ctí přivítat dva hosty, projektové manažery ze společnosti EG.D, která nedávno dokončila transformační projekt přechodu na SAP S/4HANA. Jsou jimi Vítězslav Hrbek a Jaromír Král. Rád bych začal tím, že jste oba projektoví manažeři – jeden za stranu IT a druhý za byznys. Je skvělé, že vás tu máme oba, protože se budeme bavit o tom, jak jste tento náročný projekt společně realizovali.

Začnu tedy já. Jsem projektový manažer za stranu byznysu v EG.D s. r. o., kde zároveň vedu podporu zákaznických systémů. Kolega Jaromír Král je projektovým manažerem za stranu IT v E.ON Digital Technology CZ, s. r. o. Na projektu jsme začali intenzivně spolupracovat na podzim roku 2019 a od té doby jsme, myslím, velmi sehraný tým. Jaromíre, chceš mě doplnit?

Jak zmínil Vítek, jsem ze společnosti E.ON, což je servisní organizace dodávající mimo jiné IT služby pro EG.D. Projekt byl tedy z hlediska vedení zastoupen Vítkem za byznys a mnou za IT.

Je důležité zmínit toto rozdělení na distribuční část (síť) a servisní organizaci (IT). Energetický sektor si prošel transformací, při které často docházelo k oddělení správy sítě od prodeje komodit. Váš projekt byl nedávno úspěšně ukončen a v srpnu jste přešli do ostrého provozu. Jaké jsou vaše pocity po prvních třech měsících?

Tento projekt byl jedním z největších v historii naší firmy. Z mého pohledu jde o vrchol mé dvacetileté kariéry u společnosti. Vše dopadlo velmi dobře. Jaromír možná okomentuje délku fáze hypercare.

Trvala nakonec jen dva týdny z původně plánovaných čtyř.

Přesně tak. Nenarazili jsme na žádné závažné chyby. Během odstávky jsme řešili pouze drobnosti s nastavováním síťových prostupů, což se u tak velkých akcí stává téměř vždy – v testovacím prostředí nelze nasimulovat úplně vše. Samotná odstávka pro byznys trvala pouhých 72 hodin, takže ji naši zákazníci prakticky nepocítili. V pondělí 18. srpna ráno jsme najeli na produkční systém. Hypercare jsme zkrátili i proto, že jsme v září potřebovali implementovat další legislativní změny. Úspěch přičítám precizní přípravě a také tomu, že se nám před spuštěním podařilo udržet dlouhý „freeze“.

Můžete pro posluchače vysvětlit, co přesně ten „freeze“ znamená?

Freeze znamená výrazné nebo úplné omezení jakéhokoliv zákaznického vývoje v systému. Cílem je mít systém v závěrečné fázi projektu, kdy probíhají poslední testy, technicky naprosto stabilní. Tím eliminujeme riziko, že by paralelní změny vyvolaly technické komplikace, kolidovaly s novým nastavením nebo do systému zanesly nečekané chyby.

Děkuji za objasnění. Vrátil bych se k tomu, že se pohybujeme ve specifickém sektoru utilit (energetiky). Zmínil jste, že odstávka trvala 72 hodin, aby měla co nejmenší dopad na zákazníky. Kdo jsou vlastně vaši zákazníci? Můžete nám říct, kolik jich je? Patříte totiž k největším hráčům na trhu, co se týče počtu odběrných míst. Jaký dopad má toto řešení na koncové uživatele?

Společnost EG.D je členem skupiny E.ON a působíme jako distributor na celém území jižní Moravy a v jižních Čechách. V jižních Čechách distribuujeme plyn i elektřinu, na jižní Moravě pak elektřinu. Celkem obsluhujeme zhruba 1,7 milionu zákazníků. Velká část z nich má tzv. sdružené smlouvy, což znamená, že je po administrativní stránce obsluhuje jejich obchodník. Dopady upgradu systému tedy pociťují primárně tito obchodníci.

Zároveň máme určitý počet individuálních zákazníků, většinou jde o velké firmy či teplárny. Ze zákona máme povinnost provádět různé změny sazeb či montáže elektroměrů. Tyto činnosti jsme samozřejmě nepozastavili pouze na oněch 72 hodin. Historicky, když se nasazovaly nové systémy, trvaly odstávky výrazně déle – běžně týden až čtrnáct dní. Během tak dlouhé doby ale práci přerušit nemůžete.

Dříve se data během odstávky zaznamenávala buď do staršího systému, nebo dokonce na papír, a následně se do nového systému zpětně migrovala. Tím, že jsme konverzi zvládli za 72 hodin, jsme si tuto administrativní zátěž ušetřili. To nás velmi potěšilo, protože délka migrace je vždy zdrojem potenciálních problémů. I díky tomu mohl být hypercare, jak zmínil Jaromír, tak krátký.

To je skutečně netypické a gratuluji vám. Sám jsem byl součástí projektů, kde byl hypercare rozhodně delší a složitější. Jsem rád, že už se můžete věnovat dalšímu rozvoji systému. Zmínili jste, že klíčová byla příprava. Jaromíre, mohl byste popsat, jak dlouho tato fáze trvala? Běžel realizační projekt skutečně jen rok, nebo mu předcházela dlouhá příprava včetně Proof of Conceptu (PoC)? Pokud vím, přecházeli jste formou systémové konverze z on-premise řešení SAP ECC do hostovaného prostředí v rámci programu RISE with SAP, což s sebou nese mnoho změn, například v oblasti prostupnosti a správy systému.

Pokud to vezmu od konce, tak samotný realizační projekt trval přibližně rok a měsíc. Nicméně počátky příprav sahají až do roku 2019. Tehdy jsme začali s intenzivní archivací dat v databázi. To je jeden z faktorů, který projektu výrazně pomůže – menší databáze znamená rychlejší konverzi, kratší odstávku a menší dopady na byznys.

Po archivaci následoval Proof of Concept (PoC). Provedli jsme cvičnou konverzi, jejímž cílem bylo technicky ověřit proveditelnost, odhadnout nároky na hardware nového cílového systému a identifikovat úskalí a rizika. Také to umožnilo kolegům z byznysu i IT poprvé se podívat do systému na nové platformě. Ostrý realizační projekt začal v červenci 2023 s tím, že v srpnu 2024 proběhl úspěšný Go-Live. (Pozn. v původním textu byly uvedeny roky 2024 a 2025, pro logickou návaznost upraveno na aktuální cyklus). Víťo, chceš mě doplnit?

Doplnil bych to z pohledu byznysu. Díky PoC jsme si ověřili skutečné provozní náklady. Jedna věc je rozpočet na samotný projekt, ale my jsme chtěli mít udržitelné náklady i pro následný provoz.

Co se týče archivace, s touto myšlenkou jsme si pohrávali už od roku 2019. Největší výzvou – ani ne tak technickou, jako mentální – byla změna myšlení, a to hlavně na straně byznysu. Museli jsme si přiznat, že v systému pro obsluhu zákazníků nepotřebujeme všechna historická data, ale jen ta, která jsou nezbytná pro vyřízení aktuálních požadavků a reklamací. Je to běžný nešvar; uživatelé mají rádi celou historii „na kliknutí“, i když se do ní ve skutečnosti nikdo nikdy nepodívá.

Začali jsme tedy u největších tabulek identifikovaných na workshopech s dodavatelem a postupně jsme zužovali období dat ponechaných v systému. Některá data mažeme, jiná archivujeme do DMS. Pokud jsou však potřeba pro reklamaci, dokážeme je do systému obnovit. To byl pro lidi z byznysu klíčový argument – stačí odarchivovat jednu konkrétní fakturu, není nutné jich tam mít miliony „pro jistotu“.

Zlom v vnímání přišel v momentě, kdy zkrachovala Bohemia Energy a my jsme museli řešit agendu DPI (dodavatele poslední instance). Operace, které nám dříve kvůli obrovským databázím trvaly dny, jsme po archivaci zvládli v řádu hodin. V ten moment všichni pochopili, že archivace není jen úklid, ale cesta k efektivitě a úspoře peněz za provoz in-memory databáze SAP S/4 HANA. Tím, že jsme s Jaromírem začali už v roce 2019, jsme měli dostatek času ujasnit si, co skutečně chceme. Na rozdíl od minulosti jsme tyto koncepční otázky neřešili až za pochodu v rámci realizačního projektu.

To vyžadovalo velkou podporu managementu. Prosadit dlouhý „freeze“ a odolat tlaku byznysu na neustálé zavádění novinek bývá v mnoha firmách nelehký úkol. Skupina E.ON je navíc známá důrazem na agilní řízení. Jak vypadala vaše spolupráce v praxi? Seděli jste spolu v jedné kanceláři, nebo jste využívali moderní nástroje pro vzdálenou kooperaci?

Naše práce má určité agilní rysy, jako jsou samoorganizované týmy nebo koučovací přístup k vedení. Pro sledování životního cyklu úkolů používáme Atlassian Jira. Nicméně tento projekt byl silně technologicky orientovaný, takže klasické dvoutýdenní sprinty nebo každodenní stand-upy by nám nevyhovovovaly. Postupovali jsme v logických etapách, které byly definovány testovacími konverzemi a závěrečným Go-Live.

Vzhledem k tomu, že členové týmu jsou z různých lokalit, scházeli jsme se virtuálně přes MS Teams. Bylo by neefektivní se fyzicky sjíždět na jedno místo. Odřídili jsme tak celý projekt, aniž by to mělo negativní dopad na atmosféru nebo kvalitu komunikace.

Je to tak, díky zkušenostem z pandemie jsme na tento styl práce byli připraveni. Měli jsme pravidelné úterní stand-upy, kde jsme procházeli úkoly v Jiře. Musím říct, že Jira pro mě byla obrovským přínosem. Dříve se vše řešilo v Excelech, po mailech a telefonech. Teď máme vše v „příbězích“ a komentářích. Když se potřebuji v deset večer podívat, v jakém stavu je úkol, prostě se přihlásím a vidím to.

V tomhle mi Jaromír hodně pomohl, protože nebylo snadné přesvědčit celý tým, který má široké věkové spektrum od 25 do 60 let, aby tento nástroj přijali za svůj. Postupně jsme systém vylepšovali, aby lidi administrativně co nejméně zatěžoval. Dnes je v Jiře i vykazování práce IT. Pro mě jako zástupce byznysu je neocenitelný i ten benefit, že je vše stoprocentně auditovatelné – přesně víme, kdy proběhly transporty a jaké se vyskytly chyby. Tento transparentní přehled nám pomohl projekt výrazně urychlit.

Byl jsem nadšený z toho, jakým způsobem tuto stránku dokumentujete. Ne každý projekt má všechnu historii na jednom místě, přitom je to stěžejní faktor – zejména když lidé odcházejí nebo přicházejí. Zmiňovali jste, že klíčová byla fáze přípravy a nastavení očekávání. Často je konverze vnímána jen jako upgrade nebo technická záležitost v režii IT. Já se se zákazníky hodně věnuji právě tomu, aby všichni chápali cíle dříve, než do projektu skočí. Jak se vám podařilo tuto přípravnou fázi uchopit? Co bylo hlavní motivací – byla to jen končící podpora staré verze, nebo i snaha o inovace?

Bez zapojení kolegů z byznysu by ten projekt neproběhl dobře. Zadáním projektu byla v podstatě technická konverze stávajícího systému z databáze Oracle na novou platformu SAP S/4HANA „jedna ku jedné“ – tedy bez rozšiřování scope, změn v nastavení procesů nebo nového vývoje. To je cílem až následných projektů. Tento projekt měl jasně definovaný technický scope, což ale neznamená, že se obešel bez byznysu. Součinnost kolegů je nenahraditelná v každé fázi, a nejvíce při testování.

Jen bych doplnil, že SAP S/4HANA je přece jen jiný systém než ten původní, takže drobné změny proběhly. Byli jsme v unikátní situaci – v roce 2019 jsme systém oddělili od obchodu, takže byl poměrně nový a procesy odladěné. Z pohledu byznysu jsme chtěli přejít co nejefektivněji. Hlavním faktorem bylo ukončení podpory stávajícího řešení, ale také budoucnost energetického trhu.

Víme, že vznikne Energetické datové centrum (EDC), což je největší změna na trhu s elektřinou za posledních 20 let. Finální řešení má běžet od roku 2027, ale už teď se řeší sdílení elektřiny. Chtěli jsme tyto nové věci dělat už v novém systému a vyzkoušet si moderní technologie jako SAP BTP nebo aplikace Fiori. Původně jsme nebyli vyhranění pro „Brownfield“ (technickou konverzi), ale workshopy v letech 2020 a 2021 ukázaly, že jsme schopni výrazně zredukovat databázi. Brownfield se ukázal jako nejrychlejší a nejlevnější cesta.

Kdybychom se zpozdili, ovlivnilo by to další projekty ve firmě, což bylo neakceptovatelné. Nakonec to byla jasná volba. Někdo nás sice odrazoval, ale pro byznys je výhodou kontinuita historie zákazníků. Ušetřili jsme spoustu času na zaškolení obsluhy, protože procesy plynule pokračovaly dál. Kdybychom šli formou „Greenfieldu“ (stavba na zelené louce), musely by kolegyně při opravné fakturaci pracovat ve dvou systémech zároveň, což by byla obrovská zátěž.

Takže konverze nebyla jen upgrade, ale i příprava na legislativní změny v energetice. Přecházeli jste do prostředí RISE with SAP, což znamenalo i změnu infrastruktury. Jaký byl tento přechod pro IT? Najednou do vztahu vstupuje více stran – nejen váš dodavatel, ale i SAP a provozovatel infrastruktury (AWS). Jak jste se na to chystali?

Rozhodnutí umístit cílový systém do SAP RISE na AWS přišlo až v průběhu projektu. Původně jsme počítali s Microsoft Azure, ale museli jsme respektovat korporátní rozhodnutí. Byli jsme jednou z prvních společností v rámci E.ONu, která do SAP RISE mířila. To způsobilo určité časové zpoždění, než se ustavily procesy a týmy pro konfiguraci prostředí a vyřešení všech prostupů. Kvůli tomu se zkrátila první etapa testování, ale vše jsme stihli dohnat ve druhém cyklu.

Navzdory zpoždění jste zvládli „Go-live“ v plánovaném termínu. Proč byl vybrán právě srpen? Má to nějaký byznysový důvod?

Srpen se nám historicky osvědčil. Požadavků od zákazníků je v létě méně a navíc potřebujeme celý podzim na implementaci legislativních změn, které přicházejí k 1. lednu. Nechávali jsme si tam prostor pro případné komplikace. Musím říct, že nám neskutečně pomohl náš externí partner, kdy kolegové pracovali po nocích i víkendech, abychom to měsíční zpoždění způsobené prostředím dohnali. Výběr partnera byl klíčový.

Zpětně jsem za RISE rád, protože jsme si ušetřili jednu migraci po naběhnutí systému. Dnes máme část infrastruktury stále v Azure, takže pro kolegy z IT je to o něco složitější na správu mezi více poskytovateli, ale byznysově má RISE přínos třeba v rychlosti kopií testovacích systémů přes víkend, což nám šetří čas.

Dva týdny „Hypercare“ (zvýšené podpory po spuštění) jsou velmi krátká doba, to je obdivuhodné. Zmínili jste také platformu BTP. Plánujete se jí v budoucnu věnovat více, například v oblasti AI nebo Fiori aplikací?

Chceme se držet zásady „Clean Core“ a doporučení SAPu. Nějaké drobné pokusy s AI jsme měli už ve starém systému, ale nové věci chceme vyvíjet standardizovaně na BTP platformě. AI vidíme jako velkou pomoc při zpracování dat – například u revizních zpráv, které jsou v papírové formě, nebo při kontrole naměřených dat. Chceme využít AI k tomu, aby nám pomohla rozlišit reálnou chybu ve výpočtu od přirozeného výkyvu spotřeby, třeba když začne topná sezóna. Je potřeba se toho nebát a technologie si osahat.

Blížíme se k závěru. Zvládli jste projekt včas a pod rozpočtem, což je skvělé. Co byste v jedné či dvou větách vypíchli jako hlavní doporučení pro ostatní?

Za byznys je to jednoznačně tým. Každý člen musí vědět, proč tu změnu děláme, a projekt musí mít stoprocentní podporu managementu.

Souhlasím, podpora managementu a vzájemná důvěra jsou klíčové. Z technického pohledu bych dodal: nepodceňte archivaci dat a zmenšení databáze. Je potřeba dobře nadimenzovat cílový systém, otestovat rychlost komunikace mezi systémy a zajistit si ve vhodnou chvíli „Development Freeze“ (zastavení vývoje). Potřebujete kvalitní testování s manažerem, který má „tah na branku“, a detailní „Cutover plán“ rozepsaný klidně po půl hodinách. A samozřejmě generálního partnera na straně IT, se kterým si tým lidsky i odborně sedne a dokáže věci řešit konstruktivně a bez odkladů.

Velice oceňuji, jak to byznysová strana s kolegy zvládla. Děkuji vám za sdílení těchto cenných informací – potvrzuje se, že žádnou část projektu není radno přeskakovat. Přeji vám, aby i další projekty v rámci vaší skupiny dopadly takto úspěšně.