SAP S/4HANA brownfield migráció: amikor a no-go a helyes döntés
Egy több terabájtos átállás, egy több mint 24 órája ébren lévő csapat, egy apró áfakód-változás – és egy hajnali 4 órás internetkiesés a go/no-go megbeszélés közepén
Projekt: SAP ECC – S/4HANA brownfield migráció (system conversion)
Környezet: több terabájtos, több országban használt SAP rendszer
Tervezett üzleti leállás: 48–72 óra
Döntés: no-go – a migrációt leállítottuk
Valószínű ok: az eÁFA M2M megoldáshoz köthető áfakód-változás – a gyökérok-elemzés (RCA) még folyamatban van
Több mint 20 éve dolgozom SAP-pal. A 2000-es évek elején, 16–17 évesen már SAP rendszereket telepítettem és konfiguráltam. Azóta számos SAP kezdeményezésben vettem részt, az elmúlt 10 évben pedig sok ECC – S/4HANA migrációban.
Emellett 10–15 év tapasztalatom van Axaptával és Dynamicsszal – ma már Dynamics 365-tel. Pontosan erre a kettős rálátásra van szükség egy összetett SAP környezetben: nemcsak tudni, mire képes a rendszer, hanem azt is, hogyan kell egy projektet irányítani, amikor nem a terv szerint halad. Ez a történet egy ilyen alkalomról szól.
Egyben egy már elmesélt történet „másik fele” is: a hajnali 4 órás Telekom-kiesés pontosan ennek az átállásnak a közepén történt.
ECC kontra S/4HANA: a testreszabástól a standardig
Az SAP ECC szinte korlátlanul testreszabható rendszer volt. A cégek az évek során saját fejlesztéseket, saját táblákat és saját logikát építettek bele. Ma pontosan ez a rugalmasság a migráció legnagyobb kihívása.
Az S/4HANA sokkal standardizáltabb. A „clean core” elv szerint a központi rendszer a lehető legközelebb marad a standardhoz, az egyedi bővítések pedig az SAP BTP-re (Business Technology Platform) kerülnek. Ez a jövőbeli frissítéseket és projekteket jóval egyszerűbbé teszi – az ECC-ről odáig vezető út viszont nem egyszerű.
- Sok adatkör megváltozik – például a vevőkből és szállítókból üzleti partnerek (Business Partner) lesznek, a pénzügy pedig új, egységes adatmodellre (Universal Journal) kerül.
- Az SAP Activate az ajánlott módszertan az ECC – S/4HANA transzformációkhoz.
- A Fit-to-Standard workshopok a régóta megszokott egyedi megoldásokat, ahol csak lehet, visszaterelik a standardba.
A cégek itt gyakran frusztráltak lesznek. Egy folyamat, amely 15 éve „a mi módunkon” működik, hirtelen a standard szerint kell, hogy működjön. Ráadásul egy brownfield migráció jellemzően 48–72 óra üzleti leállással jár – és ebből minden óra látszik.
A nagy logikai különbség: Dynamics 365 kontra SAP
Dynamics 365
- Felhőszolgáltatás (SaaS), amelyet a Microsoft üzemeltet.
- Alapból standard, folyamatos, ütemezett frissítésekkel – hasonlóan a SharePoint Online-hoz vagy a Microsoft 365-höz.
- A bővítések a standard köré épülnek, nem bele.
SAP S/4HANA
- Most fejlődik ugyanerre a szintre: az S/4HANA Cloud Public Edition valódi SaaS standard.
- A Private Edition és az on-premise még nagyobb szabadságot ad – de a clean core ugyanebbe az irányba mutat.
- Az ECC-ről indulva az odáig vezető út komoly adat- és folyamat-átalakításon keresztül vezet.
Egyszerűen fogalmazva: a Dynamics 365 a standardból indult, az SAP pedig most érkezik meg oda – évtizednyi testreszabott ECC rendszer felől. Ezért egy ECC – S/4HANA migráció nemcsak technikai frissítés, hanem üzleti átalakítás is.
Egy tipikus hétvégi runbook közepes rendszerre (1–5 TB)
Viszonyításként így néz ki egy tájékoztató jellegű brownfield cutover runbook egy közepes méretű rendszernél. A pontos időket az adatbázis mérete, a hardver, az országok és interfészek száma, valamint a mock futtatások eredményei határozzák meg.
| Mikor | Lépés | Tájékoztató időtartam |
|---|---|---|
| T–2 hét | Utolsó mock jóváhagyva, változtatási tilalom (change freeze) éles rendszerben | – |
| Péntek 18:00 | Felhasználók zárolása, háttérjobok felfüggesztése, interfészek leállítása | 1–2 óra |
| Péntek este | Előellenőrzések, időszakzárási ellenőrzések, teljes mentés | 2–4 óra |
| Péntek éjjel – szombat | Technikai konverzió és adatbázis-migráció (SUM / DMO) | 10–20 óra |
| Szombat – vasárnap | Alkalmazásadat-konverzió (pl. pénzügy), utófeldolgozás | 8–16 óra |
| Vasárnap reggel | Technikai utómunkák, transzportok, interfészek visszakapcsolása | 4–6 óra |
| Vasárnap délután | Üzleti validálás, pénzügyi egyeztetés, smoke tesztek | 4–8 óra |
| Vasárnap este | Go/no-go döntés – az utolsó pont, ahol a visszaállás még reális | – |
| Hétfő 06:00 | Felhasználók feloldása, indul a hypercare | – |
A mi átállásunk
A mi rendszerünk nagyobb volt ennél a példánál: egy több terabájtos, több országban használt SAP. A méret miatt úgy döntöttek, hogy a felhasználókat nem hétvégén, hanem már kedd délután zárolják.
A go/no-go megbeszélést egy egyedi hibapont szakította meg – a sajátom.
A Cordia Woodlandben lakom, Budapest IX. kerületének közepén – egy olyan épületben, ahol szinte nincs Telekom mobillefedettség. Amikor hajnali 4-kor leállt az optika, egyszerre veszítettem el mindent. Egy cutover döntéshozó, aki nem tud csatlakozni, maga is kockázat. Két utcával arrébb a probléma már nem is létezett.
A döntés: leállítás, és pihenés a csapatnak
Csütörtök reggelre egyértelmű lett: nincs esély arra, hogy a brownfield migrációt ebben az ablakban befejezzük. A döntés az volt, hogy leállítjuk – és a csapatot pihenni küldjük.
A döntés mindkét fele fontos. Egy több mint 24 órája ébren lévő csapat nem javítja a hibákat, hanem újakat csinál. A no-go pedig nem kudarc. Az lett volna a kudarc, ha több országban hibás áfakódokkal élesedünk.
Mi csúszott el: egy apró eÁFA-változás egy több terabájtos migrációban
Az SAP rendszert több országban használják. A magyar adatokra már bevezették az új eÁFA megoldást – a NAV elektronikus áfarendszerét, amellyel az ERP közvetlenül, M2M (gép–gép) kapcsolaton keresztül kommunikál.
Az eddigi információk szerint ez a bevezetés megváltoztatott valamit az áfakódokban. A mockok és a tényleges brownfield migráció között ez valahol elsikkadt. A gyökérok-elemzés (RCA) még folyamatban van.
Nem egy nagy fejlesztés, nem egy új modul – egy egyetlen országra vonatkozó lokalizációs változás, egy több országban használt rendszerben. Pontosan az a fajta változás, ami „csak gyorsan” bekerül két mock között.
Tanulságok a következő átálláshoz
- A change freeze azt jelenti: semmi – az adó- és jogszabályi lokalizációkat is beleértve. Az eÁFA, az e-számla és az áfaváltozások is változások. Ami az utolsó mock után kerül élesbe, ahhoz új mock vagy legalább célzott delta teszt kell.
- A mocknak meg kell egyeznie az élessel. Átállás előtt hasonlítsd össze az utolsó mock konfigurációját és transzportjait az éles rendszerrel. A különbségben van a kockázat.
- A go/no-go kritériumokat előre egyeztesd. És gondoskodj róla, hogy ne csak a 24 órája ébren lévő csapat döntsön.
- Az emberek is a kritikus úton vannak. A műszakokat és a pihenőidőket ugyanúgy tervezd be a runbookba, mint az adatbázis-lépéseket.
- A saját infrastruktúrád is része az átállásnak. A kulcs döntéshozók kapcsolata egyedi hibapont. Legyen olyan tartalék, amely nem ugyanattól a szolgáltatótól és nem ugyanattól az épülettől függ.
- RCA a következő kísérlet előtt. Az új ablaknak csak akkor van értelme, ha pontosan tudjuk, mi történt az áfakódokkal – és hogyan előzhető meg.
Nektek mi a tapasztalatotok?
- Láttatok már olyat, hogy egy lokalizációs vagy adóügyi változás borított egy átállást?
- Hogyan kezelitek a change freeze-t, amikor a jogszabályi határidők nem várnak a projektre?
- Nálatok ki hozza meg a go/no-go döntést – és mennyire kipihent?