O konverzi systému SAP z SAP ECC na SAP S/4HANA existuje mnoho článků, blogů a prezentací (většina z nich v angličtině), které popisují technický postup provedení konverze. Kromě toho existuje skoro stejně marketingových materiálů, které se snaží čtenáře přesvědčit, jak skvělé je konvertovat systém nebo že nejlepší je provést konverzi s konkrétním dodavatelem. Tento článek se nesnaží ani o jedno z toho. Jeho cílem je podat přehled možností, jak konverzi provést, základní postup a jaké záludnosti nás mohou u jednotlivých variant čekat. Cílovou skupinou jsou IT a projektoví manageři.

Proč vůbec konvertovat?

Dne 4. února 2020 společnost SAP ve své tiskové zprávě oznámila nový harmonogram údržby pro SAP S/4HANA a SAP Business Suite 7. SAP se zavázal k podpoře SAP S/4HANA do konce roku 2040, což má zákazníkům umožnit plánování investic s ohledem na podporované verze software SAP. Společnost SAP navíc pro SAP Business Suite 7 přidala dodatečný časový rámec pro údržbu. Běžná údržba bude poskytována do konce roku 2027, po níž bude následovat volitelné období prodloužené údržby do konce roku 2030.

Po skončení běžné údržby nabídne SAP zákazníkům od roku 2028 další možnosti volby údržby pro základní aplikace SAP Business Suite 7:

Zákazníci si mohou zvolit nabídku prodloužené údržby (extended maintenance). Ta je dodávána s příplatkem dvou procentních bodů z ceny údržby pro všechny nabídky podpory v rozsahu SAP Business Suite 7. Bude k dispozici po dobu tří let od začátku roku 2028 do konce roku 2030.
Zákazníci, kteří se nerozhodnou pro prodlouženou údržbu nebo u kterých prodloužená údržba skončila, obdrží pro své aplikace SAP Business Suite 7 specifickou údržbu. (Že to nebude zadarmo není třeba rozebírat.)

Poznámka: Uvedené datumy jsou v kompetenci společnosti SAP a mohou podléhat změně.

Pro zákazníky SAP, kteří provozují systém SAP ERP na verzi 6.0 (neboli ECC) to znamená provedení přechodu na SAP S/4HANA v nejbližších letech (pokud tak ještě neudělali). Pro provedení přechodu na S/4HANA se vžil pojem „konverze“ a my se ho v tomto článku budeme držet. Rovnou na začátku je potřeba zdůraznit, že nejde u upgrade. S/4HANA je systém s jiným datovým modelem a nic takového jako technický upgrade neexistuje.

Vezmeme-li v úvahu, že běžné projekty SAP trvají jeden rok a více, je konec roku 2027 již velmi blízko. Pro některé společnosti může být samozřejmě businessově ospravedlnitelné odložit přechod na S/4HANA a přejít od 1.1.2028 do módu extended maintenance, to však odkládá problém přechodu na S/4HANA (pouze) o 3 roky. Řada zákazníků SAP už přechod provedla a mají tedy „vystaráno“. Další zákazníci jsou ve fázi konverzního projektu. Mnoho zákazníků však přechod teprve připravuje.

Pojďme se v této souvislosti podívat na to, jaké jsou strategie konverze a jaké mají výhody, nevýhody a rizika. Nebudeme tedy popisovat technické postupy, ale uvedeme pouze přehled pro základní orientaci. V zásadě se jedná o 3 možnosti:

Brownfield konverze – převedení systému na novou verzi (chci víceméně to stejné, jako to mám teď)
Greenfield konverze – nová implementace (chci to jinak, než to mám teď)
Bluefield konverze – něco mezi

Plánování konverze je též ovlivněno skutečností, jestli systém je již na SAP HANA databázi nebo je potřeba jako součást konverze provést i migraci z aktuální databáze.

Brownfield konverze

Brownfield konverze je pro ty, kdo by nejraději udělali upgrade, kdyby to šlo. Prostě převést systém na vyšší verzi s nějakými menšími vylepšeními, ale jinak aby to fungovalo v podstatě stejně. A na vyšší technologické úrovni, a tedy s lepšími možnostmi rozvoje později.

Upgrade sice neexistuje, ale existuje program pro převod systému. Jenže to má háček. Zkušení zákazníci SAP vědí, že upgrade předchozích verzí SAP software nebylo, že „se něco přes noc pustí a ráno jsme na nové verzi“. Ale byl to projekt na měsíce. A teď navíc S/4HANA má jiný datový model a částečně i jinou funkcionalitu. A to může mít některé negativní důsledky:

Zákaznické programy provádějící update do databáze nemusí fungovat
Zákaznická rozšíření některých tabulek je potřeba předělat
Nemusí fungovat oprávnění
Nemusí fungovat add-ons
…

Naštěstí SAP dává několik nástrojů, které v tom mnohou účinně pomoct. A první z nich je tzv. SAP Readiness Check, což je především plánovací nástroj, který byste měli spustit již v rané fázi projektu konverze systému, abyste získali přehled o požadovaných aktivitách. Dá se také použít pro sledování těchto aktivit v průběhu projektu.

Ještě před započetím konverze je potřeba zkontrolovat všechna add-on v systému, a získat od jejich dodavatelů nástroje na převod těchto add-on na S/4HANA. A to může být oříšek. Různí dodavatelé k tomu přistupují různě: úprava add-on před konverzí, v průběhu konverze, po konverzi, kombinace možností – fantazii se meze nekladou. Některá add-on je potřeba před konverzí odstranit a po konverzi nainstalovat novou verzi. A co s daty, která add-on uchovává ve svých tabulkách – zůstanou zachována? V každém případě je potřeba co nejdříve vstoupit do jednání s dodavateli, postup si s nimi ujasnit a zaplánovat jak do harmonogramu projektu, tak do cut-over plánu. Konverze add-on může významně prodloužit downtime, tj. dobu, kdy bude organizace bez funkčního systému při vlastním přechodu produkčního systému na S/4HANA.

Další zajímavou položkou jsou tzv. Simplification Items. Pro optimisty to může znít jako něco, co vám zjednoduší práci se systémem, ale ve skutečnosti je to hlavně něco, co zjednoduší život firmě SAP jako dodavateli software. Jsou to v podstatě změny nebo úpravy provedené ve stávajících funkcích, datových modelech nebo procesech v SAP S/4HANA. Jejich účelem by mělo být, aby optimalizovaly systém, eliminovaly redundance a zlepšily celkový výkon. Ve svém důsledku to v delším časovém horizontu je pozitivní i pro zákazníky SAP, ale při konverzi to komplikuje život. Nástroj SI Check vám pomůže najít, kde jsou tyto změny nekonzistentní s vašimi úpravami systému a donutí vás vaše úpravy změnit tak, aby konzistentní byly. Konzistentní z datového a programátorského hlediska – jestli budou správně fungovat procesy, to si musíte otestovat sami. A když říkáme, že vás donutí, tím myslíme, že vám zabrání pokračovat v konverzi, dokud není opraveno.

A jaký je doporučený postup?

Nebudeme popisovat technické detaily, na to jsou jiní. Hlavní kroky jsou:

Vyřešit všechny předpoklady z SAP Readiness Check.
Vytvořit kopii (produkčního) systému bez dat na nový server. Nový proto, že změny na stávající (ECC) verzi pokračují co nejdéle.
Konverze systému bez dat a ověřit základními testy za pomoci nástroje Software Update Manager (zkratka SUM).
Opakovat body 2. a 3. „dokud se to nepovede“ .
Znovu opakovat body 2. a 3., tentokrát s daty („dokud se to nepovede“ ).
Zastavit změny na stávajícím systému, kromě změn vynucených legislativou.
Konverze vývojového a poté testovacího systému.
Provést komplexní end-to-end (integrační) testy.
Konverze produkčního systému.
V případě úspěchu předchozího bodu 😉 zahájit produktivní provoz na S/4HANA.

Testovací konverze je potřeba opakovat tolikrát, až je vyladěn úspěšný postup s dosaženým požadovaným časem nedostupnosti (downtime) produkčního systému během konverze. Přitom se zároveň vytváří a ladí cut-over plán (plán přechodu do produktivního provozu). Ten by měl být tak detailní, aby se v průběhu konverze produkčního systému již nic nevymýšlelo (nejhorší je, když někdo při konverzi produkčního systému v půl čtvrté ráno „dostane nápad“).

Jak dlouho budeme bez produkčního systému?

Jinými slovy, jak dlouhý bude system downtime? Žádná organizace si samozřejmě nemůže dovolit fungovat bez produkčního systému libovolně dlouho, pro výrobní nebo logistické provozy však toto může být vskutku kardinální otázka.

Jak jsme se zmínili výše, vlastní konverzi provádí nástroj SUM. Jeho běh se člení na Uptime Processing, při kterém je stále možno do systému pořizovat data, a Technical Downtime, kde to již nelze. Nástroj se v uptime co nejvíce připravuje na cílovou verzi, přičemž produkční provoz probíhá paralelně. K tomu využívá koncept stínového systému (SHD). Stínový systém je minimální kostra cílového systému, ve které se provádějí určité přípravné činnosti. V downtimu se pak provádí migrace databáze, update programů a datová konverze, následované dalšími kroky (manuální migrace, add-on upgrade, indexace databáze atd.).

Pokud testovací konverze ukazují, že se do maximálně povoleného času bez systému vejdeme, je to na drobnou oslavu (tu velkou si necháme na konec projektu). Pokud ne, co s tím?

První možností je optimalizovat Technical Downtime standardního SUM. To má bohužel své limity.

Další možnost je použít Downtime-optimized conversion. Tento přístup redukuje downtime tím, že část konverzí a migrací provádí ještě v uptime. Je k dispozici pouze pro speciálně školené experty a vyžaduje vyšší úsilí spočívající v komplexnějším plánování, testovacích konverzích apod., vyšší nároky na HW a vyšší nároky na omezení systémových změn před konverzí produkčního systému.

Mezi standardní konverzí a Downtime-optimized conversion existují dvě další možnosti, jak zkrátit downtime: downtime-optimized Database Migration Option (DMO), obecně dostupné a near-Zero Downtime Maintenance (nZDM) pokud není nutná migrace databáze, protože zdrojový systém běží na databázi SAP HANA 2.0 s dostatečnou úrovní Support Package.

Greenfield konverze

Přechod z ECC na S/4HANA je ideální příležitostí „vyčistit“ systém. Spousta systémů je opravdu zaplevelených zbytečnými zákaznickými programy, nepoužívanými procesy, vadnými daty atd. Jde jenom o to, si tuto skutečnost přiznat. A uvědomit si, že lepší příležitost k úklidu se jen tak nenaskytne (naštěstí – kdo by si kromě SAP partnerů přál další konverzní projekt).

Greenfield konverze, jak už sám název napovídá, je „postavení systému na zelené louce“, tj. v podstatě nová implementace na nové technologii. Oproti iniciální implementaci systému SAP je samozřejmě výhoda v tom, že organizace už zná technologie SAP a má své procesy (více či méně) přizpůsobené této technologii, má poměrně kvalitní datovou základnu atd.

Na druhou stranu je zde nebezpečí, že klíčoví uživatelé budou zase prosazovat nastavení systému „jak jsme to měli předtím“ protože „to jinak nejde“ a „bez toho nemůžeme fungovat“, a pak organizace utratí celkem slušné náklady a bude tam, kde předtím. Se všemi problematickými zákaznickými úpravami. Je potřeba se právě naopak podívat na funkcionality, které SAP S/4HANA nově nabízí a využít je ku prospěchu organizace. A samozřejmě zbavit se co nejvíce zákaznických úprav a „přejít do standardu“, protože lepší příležitost k tomu jen tak nebude.

Také zde, stejně jako při brownfield konverzi, je potřeba vyřešit správné verze add-on. Také je potřeba přijmout rozhodnutí jaká data se budou migrovat do nového systému (jak moc do historie) a jakým způsobem archivovat data která se migrovat nebudou.

Samostatnou kapitolou je zákaznický kód – jakýkoli. Když se zeptáte uživatelů, tak potřebují do S/4HANA převést všechno (protože jestli bude cokoli chybět, tak to zastaví chod organizace, že ), prostě „jak jsme to měli předtím“. Bohužel, implementační partner v tom většinou nebývá příliš nápomocen, zejména pokud má kontrakt na bázi fixed price (o vendor-lock raději ani nemluvme). Proč by měl trávit spoustu času s procházením jednotlivých programů a rozhodováním, zda ho lze nahradit standardní funkcionalitou nebo se mu vyhnout změnou procesu. A některé zákaznické kódy skutečně nahradit nelze (cenové podmínky, výpočet mezd…). Přenášení velkého množství zákaznických programů jeden po druhém však může být pracné, a tak se může greenfield konverze v průběhu projektu změnit na bluefield konverzi.

Bluefield konverze

Jak už jsme řekli výše, je to něco mezi, a společnost SAP ji ve své dokumentaci většinou ani neuvádí jako separátní možnost.

A o co se tedy jedná:

Provede se konverze systému (bez dat) stejnou technologií, jako při brownfield
Do vzniklého systému na S/4HANA se provedou úpravy
Následuje migrace dat jako při greenfield

Kdy je tato varianta vhodná:

Nechceme do nového systému přenášet všechna historická data.
Chceme sice v průběhu projektu implementovat změny, ale zároveň si chceme ušetřit práci s přenášením nastavení a zákaznického kódu, které měnit nechceme.
Chceme minimalizovat downtime, ale z nějakého důvodu pro nás není vhodná některá z Downtime-optimized variant popsaných výše.
A samozřejmě kombinace předchozích bodů.

Ještě připomeňme, že konverze systému bez dat je jedním z prvních kroků brownfield konverze (viz výše). A také se stává, že původně plánovaná greenfield konverze se po počáteční analýze změní na bluefield z důvodů pracnosti přenosů nastavení a kódu.

Nevýhodou této varianty zůstává, že se nevyhneme přizpůsobení všech zákaznických úprav novému systému a zároveň i přizpůsobení struktury migrovaných dat a archivace těch, která nejsou migrována.

Závěrem

Konverze na S/4HANA není jednoduchý projekt. Je potřeba počítat s tím, že bude trvat několik (minimálně vyšší jednotky) měsíců, bude vyžadovat čas interního týmu (nejen IT ale i odborných oddělení), a samozřejmě rozpočet na externí služby a případně HW vybavení. Také omezí rozvoj systému v době konverzního projektu.

Kromě toho, že to není jednoduché, je to obvykle velmi nepopulární: utratíme spoustu peněz a úsilí a co za to dostaneme? Systém na vyšší technologické platformě. Tato hodnota se někdy top managementu těžko vysvětluje , takže je dobré v průběhu konverze realizovat alespoň nějaká quick-wins, i když to na druhé straně projekt komplikuje.

A na úplný závěr: jakkoli bych vám mohl popřát hodně štěstí při vaší konverzi, raději zdůrazním, že dobrým plánováním, správným výběrem vhodného dodavatele a pečlivým řízením celého procesu je možné jít tomu štěstíčku výrazně naproti.