Az elmúlt években volt szerencsém megfigyelni, illetve részese lenni több esküvőszervezésnek, ahogyan ahhoz is, hogy részt vegyek több SAP S/4HANA rendszer bevezetésében, az új rendszerre történő átállás tervezésében és lebonyolításában is.
Bár elsőre nagyon távolinak tűnnek egymástól, én mégis kísérletet teszek arra, hogy egy esküvőszervezés hasonlatával mutassam be, miért is fontos egy teljeskörű átállási terv (cutover plan). Cikkemben kitérek rá, hogy mennyire részletesnek kell lennie, az idő előrehaladtával hogyan kell pontosabbá válnia, és hogyan kell felkészülnie a havária helyzetekre, az éles indulást illető döntésre (go / no go), a már tudott csúszásokra (pl. workaroundok kialakítása), magára a percről percre történő átállásra és az átállást követő – ahogy egyik ügyfelünk nevezte – „siralomvölgyre”, a sikeres átállás érdekében.
De hogyan is jutunk el az esküvőig, akarom mondani az átállásig?
Két ember találkozik, megtalálják a közös célt, és úgy döntenek, hogy összekötik az életüket. Megtörténik az eljegyzés és a pár boldogan közli a családdal, barátokkal, hogy a megismerkedésük évfordulóján, következő év július 1-jén szeretnének megesküdni. Van némi elképzelésük, hogy hol és hogyan történjen a nagy esemény, mekkora legyen a násznép, de ezek még csak elképzelések, hiszen még nem kezdték meg az előkészületeket, az esküvőszervezést. Boldogok, hogy van egy számukra fontos dátum, és innen szemlélve befuthatónak látszik, hogy minden összejöjjön a kívánt időpontra. Hiszen más is szervezett már esküvőt ennyi idő alatt….
Ugyanez történik egy vállalat életében is, amikor úgy dönt, hogy le szeretné cserélni jelenlegi ERP rendszerét SAP S/4HANA-ra (továbbiakban S/4). Meghatározza elképzeléseit, üzleti igényeit, IT rendszerekre vonatkozó elvárásait, kiír egy tendert, majd év elején kiválasztja a bevezetést támogató szállítókat. Így megszületik a közös cél, az S/4 bevezetése, és kitűzésre kerül a bevezetés tervezett dátuma, következő év július 1-je, vagyis közel másfél év múlva. Az ismert információk alapján mind a vállalat, mind a szállítók úgy vélik, hogy a tervezett dátumig a rendszerbevezetés befutható. Igaz, ekkor még csak elnagyolt dátumok állnak rendelkezésre arról, hogy a bevezetés mely lépése mennyi időt vesz igénybe. Ezeket a tenderkiírás és egyeztetések alapján határoztak meg közösen a felek. És egyébként is, más is vezetett már be S/4 rendszert ennyi idő alatt…
A pár egyik tagja „to do” lista mániás, így elkezdi egy Excelben összeírni, hogy milyen feladataik vannak, kinek mi lesz a szerepe a szervezésben, és mikor mit kell csinálni, így megkezdődik az esküvő megtervezésének hosszú folyamata. A pár elmegy az önkormányzathoz, a lehetséges rendezvényhelyszínekre, egyeztet fotósokkal, videósokkal, catering cégekkel. Kicsit elkedvetlenedve tapasztalják, hogy az áhított július 1-je vagy csak kompromisszumokkal, vagy egyáltalán nem jön össze. Vagy a rendezvényhelyszínen nincs aznap szabad időpont, vagy a zenekar nem ér rá, és ráadásul a Julcsiéknak is pont azon a hétvégén van az esküvője. Ahogy telik-múlik az idő, egyre nagyobb a nyomás, hogy döntést kell hozni. Az egyik opció, hogy ragaszkodnak az eredeti dátumhoz, bizonyos kompromisszumok mellett, míg a másik opció, hogy kitolják az esküvő dátumát pár héttel/hónappal, de akkor a lehető legjobb kombináció áll elő a helyszín – fotós – videós – zenekar – catering stb. többszereplős egyenletet tekintve.
A vállalat kiválasztja a megfelelő eszközt az S/4 bevezetési projekt feltervezésére, nyomon követésére, a fejlesztések státuszolására, a tesztelés nyomon követésére, és a hibák kezelésére (pl. JIRA és MsProject), és megkezdi a tervezés hosszú folyamatát. Feladatok végrehajtásának tömkelege kezdődik el: egyeztetnek a szállítókkal, rögzítik a részletes üzleti specifikációkat, összeállítják a fejlesztési terveket, azonosítják a szükséges rendszerekkel történő integrációs pontokat, összeállítják az interfészek fejlesztési specifikációit, megrendelik a szükséges hardver, szoftver komponenseket, és egyre pontosabban látják, hogy mely lépéseket meddig lehet nagy biztonsággal megvalósítani. Feltervezésre kerülnek a bevezetés egyéb fontos feladatai is, mint a migráció, a tesztelés, az oktatás, a jogosultságok beállítása.
Ekkor érkezünk el ahhoz a dátumhoz, amikor dönteni kell, hogy ismerve minden elmaradásunkat, ragaszkodunk-e az eredetileg tervezett július 1-jei átálláshoz. Ezen a ponton már tudjuk, hogy bizonyos fejlesztések, funkciók, interfészek, tesztelések nem, vagy csak korlátosan készülnek el addigra (pl. nincs teljes körű tesztelés, kevesebb migrációs kör stb.), és emiatt ideiglenes, vagy akár végső elkerülő megoldások kialakítása válik szükségessé. Az is opcióként merül fel, hogy eltoljuk az átállás dátumát pár héttel/hónappal, annak reményében, hogy az új dátumig minden kritikus, fő folyamatokat érintő fejlesztés, tesztelés, migráció elkészül.
A pár úgy dönt, hogy vannak dolgok, amelyekben hajlandók kompromisszumot kötni (pl. zenekar helyett DJ), de vannak dolgok, amelyekhez ragaszkodnak (pl. rendezvényhelyszín), ezért kijelölik az új dátumot: szeptember 1. Meggyőzik magukat, hogy ez jó döntés, mert így két hónappal több idő van mindent alaposan megtervezni az utolsó napokig, órákig, és legalább nem lesz olyan meleg, a DJ egyébként is jobb választás, mint a zenekar, és legalább a barátoknak sem kell választania, hogy a Julcsi vagy az ő esküvőjükre menjenek-e el. Ekkor megkezdődik az utolsó nagy tervezési roham, az esküvőt megelőző hetek, az esküvő napja, majd az azt követő napok részletes megtervezése.
Hogy néz ki ez a helyzet az S/4 rendszer bevezetésénél? A vállalat úgy dönt, hogy vannak olyan kritikus fejlesztések, interfészek, tesztelendő funkciók, amelyek nélkülözhetetlenek az üzletfolytonosság biztosításához, és emiatt ezeknek mindenképp el kell készülniük. Továbbá meghatároz olyan fejlesztéseket, funkciókat, teszteléseket, interfészeket, amelyek elkészültével még tud várni, így ideiglenes elkerülő megoldások bevezetése mellett megtörténhet az átállás. Ezért meghozzák a döntést a bevezetés elhalasztásáról. Az új bevezetési dátum: szeptember 1. Bár nem az fog megvalósulni, amit a legelején július 1-jei dátummal terveztek, de üzletileg a legjobb kompromisszum születik. Ekkor – az esküvőszervezéshez hasonlóan – megkezdődik az utolsó nagy tervezési roham, az átállási terv alábontása, amely már részletesen tartalmazza majd a hátralévő heteknek, az átállás előtti napoknak, magának az átállás napjának és az azt követő napoknak, heteknek a feladatait.
Ahogy közeledik az esküvő napja, egyre tisztábban rajzolódik ki a részletes program. Az esküvő előtti hetekben még csak napi bontásban, de az esküvőhöz közeledve már szinte óránkénti bontásban előáll a táblázatban, hogy mikor kinek mi a feladata, hova kell mennie, mit kell csinálnia. A felmerülő problémákra gyors megoldást kell találni (pl., ha leszakad a gomb a vőlegény ingén), és készülni kell olyan történésekre is, amikor döntést kell hozni, hogy hogyan folytatódjon tovább az esemény (pl. covidos lesz a menyasszony tanúja, ezért új tanút kell választani).
A sorrendiség megjelölése is fontos, ugyanis, ha valamely programpontnál csúszás van, ez további kapcsolódó programpontokra lehet hatással (pl. a kozmetikusnál több időt tölt a menyasszony, ezért késve érkezik a fodrászhoz, így az ifjú pár fotózását a szertartás utánra kell ütemezni). Amikor a program elindul, már csak kevés ponton lehet beavatkozni, pláne úgy, hogy az ne indítson be egy láncreakciót, ezért az ilyen esetekre is érdemes előre készülni.
A vállalat esetében is különösen fontos megtervezni az utolsó folyamatokat, tranzakciókat, amelyekre még a régi rendszerben kerül sor. Számba kell venni, hogy mennyi időbe telik a régi rendszerben lévő folyamatok leállítása, adatok másolása, meglévő interfészek lekapcsolása, valamint az új rendszer felállítása, manuális beállítások és transzportok futtatása, migráció elvégzése, adatok, funkciók ellenőrzése.
Azon fejlesztések, funkciók, interfészek esetében, amelyek az éles átállásig nem készülnek el, átmeneti, elkerülő megoldásokat (workaround) kell kialakítani (pl. egy automatikusan működő workflow helyett ideiglenesen e-mail-küldéssel működik a feladat adott ponton történő, szervezetek közötti átadása). Az átállási tervben fel kell készülni nem várt események kezelésére is (pl. ha hibás transzport esetén a hibakeresés jelentős időkiesést okoz).
Majd elérkezik a pont, amikor dönteni kell az éles átállásról (go / no go). Ez azért fontos, mert az átállás során van egy időablak, amit követően már nincs lehetőség a visszatérésre (no return point), és előfordulhat, hogy a régi rendszer már leállításra került, így az új rendszer indulásának akkor is meg kell történnie, ha az új rendszer működése nem hibamentes. Ezért szükséges előre meghatározni, hogy milyen feltételek teljesülése esetén, illetve milyen hibák, funkciókiesések ismerete mellett ki hozza meg az éles indulásról a döntést.
Az átállási tervben azért azonosítjuk a kapcsolódó, egymást követő feladatok láncolatát, hogy mindenki számára egyértelmű legyen, hogy mely feladatot milyen előfeltétel teljesülése után lehet megkezdeni, illetve mikor melyik felelőst kell értesíteni, ha valamely feladat esetében csúszás vagy megállás van. Nagyon jól tud működni az ilyen esetekre felállított „war room” vagy gyors döntések bizottsága, ahol a megfelelő kompetenciával, illetve felelősségi, döntési jogkörrel rendelkező kollégák gyorsan tudnak reagálni a felmerült csúszásokra, hibákra.
Térjünk vissza az esküvőnk példájára: elérkezik a várva várt nap, és kisebb-nagyobb döccenőkkel ugyan (pl. a virágosnál összecserélik a két aznapi esküvő csokrait), de minden tervezett eseménypont szépen egymást követi. Bár az ifjú pár számára egy kissé stresszes napról van szó, de szerencsére semmi olyan nem történik, amire ne lettek volna előre felkészülve. Megtörténik maga a szertartás, innentől ásó, kapa, nagyharang, és egyébként sem volt senkinek olyan indoka, ami miatt a fiatal pár ne kelhetett volna egybe.
S/4 implementációnk esetében is hasonló helyzetet látunk: elérkezik az átállás napja, és az átállási terv mentén az érintett szereplők a megfelelő láncolati sorrendben megkezdik a feladatokat. Az átállásért felelős szereplők a „war room”-ban a kivetített cutover (átállási) tervben folyamatosan nyomon követik, hogy hol tart az átállás. A szereplők folyamatosan tájékoztatják egymást, ha valamely feladat elkészült, vagy ha valamely ponton csúszás van, így azok felelősei tudják, mikor készüljenek a feladataik megkezdésére.
Kisebb-nagyobb döccenőkkel ugyan (pl. egy migrációs lépés több időt vesz igénybe, vagy hibára fut egy transzport, és hibajavításra van szükség), de minden tervezett feladatot végrehajtanak. Az új rendszerben a kulcsfelhasználók megkezdik az átállás eredményének tesztelését és a szükséges hibajavításokat, mielőtt az első éles tranzakciókat elindítanák. Mivel semmi olyan nyomós indok nem adódott, amely miatt az átállás, vagyis az új rendszer indulása ne történhetne meg, a döntéshozók meghozzák az éles indulásról a döntést, és az éles rendszert átadják a végfelhasználóknak.
Az ifjú pár az esküvőt követő napokban elvégzi az esküvő utáni feladatait (pl. visszaviszik az esküvői ruhát a szalonba vagy a tortástálat a cukrászdába). Az esküvő nagyon jól sikerült, mindenkitől csupa jó visszajelzést kaptak. Boldogok, hogy megérte alaposan felkészülni, mert így kevésbé volt stresszes számukra egy ekkora esemény levezénylése. Az esküvőt követő harmadik napon pedig elégedettséggel telve utaznak el közös életük megünnepléseként a nászútra.
Az új rendszer használatba vételét követően folytatódnak a feladatok az átállási terv mentén, de ebben a fázisban visszatérnek a naponkénti/hetenkénti, és nem percenkénti feladatokhoz, elindulnak az új tranzakciók, az éles működés. Bár előfordulhat, hogy még vannak hibajavítások, és a bevezetett átmeneti elkerülő megoldások eleinte több manualitást igényelnek, de tudják, hogy ez később kiváltásra kerül, mikor a fejlesztések elkészülnek. Napok, hetek telnek el, mire a működés helyreáll, és az átállás során keletkezett backlogokat ledolgozzák, de a részletesen kimunkált átállási tervnek köszönhetően semmi olyan helyzet nem merült fel, amire ne lettek volna előre felkészülve, vagy ne tudták volna gyorsan lereagálni. A projektcsapat ugyan kissé elcsigázott, de egyben boldog is, hiszen sikeresen bonyolítottak le egy ekkora projektet. Így az átállást követő harmadik hónapban egy átálláspartival ünneplik meg az új rendszer sikeres indulását.
Cikkemben az SAP S/4HANA rendszer bevezetése kapcsán mutattam be az átállási terv szerepét, de ennek minden ERP rendszer bevezetési projektnél nagy jelentősége van. Példánk mentén érzékeltettük, hogy egy S/4 rendszer sikeres bevezetéséhez hogyan járul hozzá egy teljeskörű átállási terv megléte, amely végigköveti a projektet egészen az új rendszer bevezetéséig, az éles működés kezdetéig. Az átállási terv nem egy rögzített agenda, a projektet befolyásoló tényezők hatására folyamatosan változik, egyre részletesebbé, konkrétabbá válnak a feladatok, a felelősségi körök, a dátumok, az átfutási idők, illetve kapcsolódási pontok. Az átállási terv – az esküvőtervhez hasonlóan - legfontosabb feladata az, hogy összefogja az átállásban érintett összes kulcsszereplőt, és itinerként szolgáljon az átállási feladatok sikeres, gördülékeny lebonyolításában.
A szerző az IFUA Horváth vezető tanácsadója
Olvasson tovább a témáról az IFUA Horváth honlapján!
Szakértőink vállalati projektekben szerzett tapasztalatait és ügyfeleink elismeréseit egyaránt megosztjuk.
Cimkék: átállási terv, ERP rendszer, SAP S/4HANA
