Modernizálja azt a rendszert, amelyhez senki sem mer hozzányúlni, funkcióról funkcióra.
Évtizedek üzleti szabályai élnek COBOL-, PL/I-, Oracle Forms- és korai Java- vagy .NET-kódban. Feltárjuk ezeket a szabályokat, tesztekből biztonsági hálót építünk, és egy homlokzati réteg mögött funkcióról funkcióra haladunk, párhuzamos futtatással és egyeztetéssel, mielőtt bármit lekapcsolnánk.
Szervezeteknek, amelyek kritikus rendszerei több országot szolgálnak ki, és ahol sem leállás, sem elveszett szabály nem fér bele.
04Egy szelet újraépítése a homlokzat mögöttRendszer
05Párhuzamos futtatás és egyeztetésRendszer
06Az eltérések kivizsgálásaSzemély
07Átállás és kivezetésSzemély
Felmérjük az alkalmazásportfóliót, és megállapodunk a célállapotban. Az üzleti szabályokat MI segítségével tárjuk fel a kódból, és emberek ellenőrzik őket. Karakterizációs tesztek adják a biztonsági hálót. Minden funkciót egy homlokzati réteg mögött építünk újra, és a régi rendszerrel párhuzamosan futtatunk; az eltéréseket kivizsgáljuk és kijavítjuk, mielőtt az üzleti gazda jóváhagyja az átállást, és a régi részt kivezetjük.
Előtte és utána
Mi változik a munkájában
Ma
A rendszerrel
Ma
Ma: Minden módosítás kockázat
Kisebb jogszabályi változások is hónapokig tartanak, mert senki sem tudja előre, mi mindenre hat egy módosítás.
A rendszerrel
A rendszerrel: Tesztekkel alátámasztott módosítások
A karakterizációs tesztek rögzítik, mit csinál ma a rendszer, így minden módosítás hatása a kiadás előtt látszik.
Ma
Ma: A tudás nyugdíjba megy
Akik értik a kódot, közel vannak a nyugdíjhoz, a dokumentáció pedig már régóta nem egyezik a rendszerrel.
A rendszerrel
A rendszerrel: Leírt és ellenőrzött szabályok
A kódból feltárt üzleti szabályokat közérthetően dokumentáljuk, és a szakterületi szakértők megerősítik őket.
Ma
Ma: Az egyszerre váltó tervek elakadnak
A teljes kiváltási programok egyetlen átállási dátumot ígérnek, amely folyamatosan csúszik, miközben nőnek a költségek.
A rendszerrel
A rendszerrel: Érték szeletenként
A funkciók egyenként költöznek át egy homlokzati réteg mögé. Minden szelet önállóan élesedik, és visszaállítható.
Ma
Ma: Régi szerkezetekbe zárt adatok
Az új szolgáltatások és MI-felhasználások csak törékeny kivonatokon és éjszakai kötegeken keresztül érik el az adatokat.
A rendszerrel
A rendszerrel: Adatok API-kon keresztül
Az átköltöztetett szakterületek dokumentált API-kon adják ki az adataikat, amelyeket a régi rendszer kivezetéséig egyeztetünk vele.
Munkafolyamat
Hogyan fut a munkafolyamat
Strangler fig megközelítés: az új rendszer funkcióról funkcióra nő a régi köré. A valódi munka nagy része a párhuzamos futtatás és az újraépítés közötti körben zajlik.
Szemléltető munkafolyamat
7 lépés · 3 emberi ellenőrzőpont
Jelmagyarázat
Rendszer
MI-ügynök
Személy
Emberi ellenőrzőpont
Kivételág
Örökölt rendszerek modernizálása: szemléltető munkafolyamat egyeztetési körrel
Az ábra szöveges változata
A fő ág a portfólió felmérésétől és az üzleti szabályok feltárásától a karakterizációs tesztekből álló biztonsági háló kiépítésén és egy funkció homlokzati réteg mögötti újraépítésén át a régi és az új rendszer párhuzamos futtatásáig, végül az átállásig és a régi rész kivezetéséig tart.
Emberek hagyják jóvá a célarchitektúrát, ellenőrzik az összes feltárt szabályt, és hagynak jóvá minden átállást: ezek az emberi ellenőrzőpontok.
Ha a párhuzamos futtatás eltérő kimeneteket mutat, a szelet kilép a fő ágból, a fejlesztők és a szakterületi szakértők kivizsgálják, majd visszakerül az újraépítés lépéséhez, amíg a régi és az új rendszer eredményei nem egyeznek.
01
1. lépés: A portfólió felméréseSzemély
Alkalmazásleltár, a függőségek és adatfolyamok feltérképezése, és alkalmazásonként döntés: kivezetés, megtartás, áthelyezés, platformváltás, újraépítés vagy csere. A szakterületek feltérképezésével megkeressük azokat a varratokat, ahol a rendszer szeletekre bontható.
Emberi ellenőrzőpont
Az Ön architektúra-testülete hagyja jóvá a célarchitektúrát és a szeletek sorrendjét.
02
2. lépés: Az üzleti szabályok feltárásaMI-ügynök
MI-támogatott kódelemzés olvassa a COBOL-, PL/I-, JCL-, Oracle Forms- és régebbi Java- vagy .NET-kódot, és dokumentációt, hívási gráfokat és üzletiszabály-katalógust készít tervezetként.
Emberi ellenőrzőpont
A fejlesztők és a szakterületi szakértők minden feltárt szabályt ellenőriznek, mielőtt specifikációként használnánk. A nem ellenőrzött szabályokat ennek megfelelően jelöljük.
03
3. lépés: A biztonsági háló kiépítéseRendszer
Anonimizált éles bemenetekből és kimenetekből karakterizációs teszteket állítunk elő, így a jelenlegi működést, a furcsaságaival együtt, rögzítjük, mielőtt bármi változna.
04
4. lépés: Egy szelet újraépítése a homlokzat mögöttRendszer
A régi rendszer elé útválasztó homlokzati réteg vagy API-réteg kerül. Egy funkciót új szolgáltatásként építünk újra, az adatait átköltöztetjük és szinkronban tartjuk.
05
5. lépés: Párhuzamos futtatás és egyeztetésRendszer
A régi és az új rendszer ugyanazokat a tranzakciókat dolgozza fel. A kimeneteket és az adatokat automatikusan összevetjük, és minden eltérést szabályonként és rekordonként jelentünk.
06
6. lépés: Az eltérések kivizsgálásaSzemély
A fejlesztők és a szakterületi szakértők eldöntik, hogy egy eltérés az új szolgáltatás hibája, a régié, vagy szándékos változás, és a szeletet visszaküldik átdolgozásra.
Kivételág: Eltérő kimenetek· Visszatérés ide: 4. lépés
07
7. lépés: Átállás és kivezetésSzemély
Az adott funkció forgalma a homlokzati rétegen keresztül az új szolgáltatásra költözik. Egy stabil időszak után a régi kódútvonalat és az adatait kivezetjük és archiváljuk.
Emberi ellenőrzőpont
Az üzleti gazda az egyeztetés eredményei alapján hagy jóvá minden átállást. A homlokzati rétegen keresztüli visszaállítás a kivezetésig elérhető marad.
Összetevők
Mit építenénk meg
01
Portfólió- és függőségi térkép
Leltár, az interfészek és adatfolyamok feltérképezése, valamint egy szakterületi modell, amely megmutatja, hol bontható a rendszer szeletekre.
A kódelemzés az Ön által ellenőrzött környezetben fut, és forráskód nem kerül olyan szolgáltatáshoz, amelyet nem hagyott jóvá. A tesztekhez használt éles adatokat anonimizáljuk, mielőtt elhagynák az éles zónát.
Emberi felülvizsgálat
A feltárt szabályokat a fejlesztők és a szakterületi szakértők ellenőrzik, mielőtt specifikációvá válnak. Minden átállást az üzleti gazda hagy jóvá az egyeztetés eredményei alapján, visszaállítási lehetőséggel.
Visszakereshetőség
A katalógus minden szabálya visszavezethető arra a kódra, amelyből származik, és arra a személyre, aki ellenőrizte. Az egyeztetési jelentéseket minden átállásnál bizonyítékként megőrizzük.
Adatvédelem
Az adatmigráció dokumentált leképezést követ rekordszámokkal és ellenőrzőösszegekkel, a tesztkészletekben pedig a személyes adatokat a szükséges minimumra korlátozzuk. A megőrzési szabályok az adatokkal együtt költöznek.
MI-átláthatóság
Ahol MI készít dokumentáció- vagy kódtervezetet, az eredményt megjelöljük, átnézzük és verziózzuk, mint bármely más fejlesztési terméket.
Mérőszámok
Mit mérnénk
Ezeket a mutatókat a felmérés során egyeztetjük Önnel, és szeletenként követjük, nem csak a program egészére.
Mit mérnénk
Mutató
Miért fontos
Hogyan mérnénk
01A módosítások átfutási ideje
Miért fontosEz a legvilágosabb jele annak, hogy a rendszer egyre könnyebben módosítható.
Hogyan mérnénkA jóváhagyott módosítási kérelemtől az éles üzemig eltelt idő a régi és a modernizált részeken.
02Az egyeztetés állapota
Miért fontosMegmutatja, hogy az új szolgáltatás valóban úgy viselkedik-e, mint a régi, ott, ahol ez elvárás.
Hogyan mérnénkA párhuzamos futtatás alatt egyező tranzakciók és rekordok aránya, a nyitott eltérések okonként.
03Szabálylefedettség
Miért fontosMinden kiváltásnál az ismeretlen szabályok jelentik a fő kockázatot.
Hogyan mérnénkA szakterületi szakértők által ellenőrzött és tesztekkel lefedett feltárt üzleti szabályok aránya.
04Az örökölt rendszer mérete
Miért fontosA modernizálás akkor térül meg, amikor a régi összetevőket ténylegesen lekapcsolják.
Hogyan mérnénkA kivezetett funkciók, kódútvonalak, kötegelt feladatok és licencek, szeletenként követve.
Kiinduló mérés nélkül nem tűzünk ki célértéket.
Bevezetés
Hogyan vezetnénk be
01. szakasz
Felmérés
Portfólió, függőségek, szakterületek és kockázatok. Olyan első szeletet választunk, amely fontos az üzletnek, de visszaállítható.
Lezárási feltételek
Célarchitektúra jóváhagyva
A szeletek sorrendje egyeztetve
Teszt- és adathozzáférés biztosítva
02. szakasz
Az első szelet
Szabályfeltárás, biztonsági háló, homlokzati réteg és egy újraépített funkció, a régi rendszerrel párhuzamosan futtatva.
Lezárási feltételek
Az egyeztetés az elfogadott tűréshatáron belül
Az üzleti gazda jóváhagyja az átállást
Visszaállítás kipróbálva
03. szakasz
Szeletről szeletre
A további funkciók ugyanazt az utat járják be, mindegyik saját párhuzamos futtatással és átállási döntéssel.
Lezárási feltételek
Minden szelet egyeztetve és átállítva
A tudás átadva a csapatának
04. szakasz
Kivezetés
A régi kódútvonalakat, kötegelt feladatokat és adattárakat archiváljuk és lekapcsoljuk.
Egyedi ERP-kiegészítések és gyári rendszerek, egy SAP S/4HANA-migrációval párhuzamosan átköltöztetve.
Szemléltető példa
Saját fejlesztésű ERP egy családi vállalkozásnál
Helyzet
Egy családi vállalkozás magyar, szlovák és román leányvállalatai egy évtizedek óta házon belül fejlesztett ERP-rendszert használnak. A magyar számlázás az Online Számla adatszolgáltatáshoz kapcsolódik, minden országban várnak jogszabályi változások, és a kódot ismerő két fejlesztő közül az egyik hamarosan nyugdíjba megy.
Rendszer
Az üzleti szabályokat országonként tárjuk fel és ellenőrizzük. Egy homlokzati réteg először a magyar számlázást irányítja egy új szolgáltatásra, amely a régi rendszerrel párhuzamosan fut, amíg a számlák és a NAV-nak küldött adatok nem egyeznek.
Emberi kontroll
Minden országban a pénzügyi szakértők ellenőrzik a saját szabályaikat. Az átállást országonként az üzleti gazda hagyja jóvá; a homlokzati rétegen keresztüli visszaállítás elérhető marad.
Amit mérnénk
Az egyeztetés állapota országonként, a szabálylefedettség, valamint a következő jogszabályi módosítás átfutási ideje.
Magyarország
Modernizálás a magyar és az uniós szabályok szerint
Sok magyar vállalat és nemzetközi csoport ugyanazt az örökölt alaprendszert használja több országban, mindegyikben saját sorban álló jogszabályi változásokkal. A modernizálást úgy ütemezzük, hogy az országonkénti változatok szeletenként költözzenek, és a régi és az új rendszer eredményeit országonként egyeztessük, mielőtt bármit lekapcsolnánk. Ha egy szelet számlát állít ki, az Online Számla adatszolgáltatásnak az átállás alatt is megszakítás nélkül működnie kell a NAV felé.
A kiberbiztonsági törvény (2024. évi LXIX. törvény) 2025. január 1-je óta hatályos: a magánszféra érintett szervezeteit az SZTFH, a közigazgatást az NKI felügyeli; a már működő érintett szervezeteknek 2025. február 15-ig jelentkezniük kellett az SZTFH-nál, és 2025. december 31-ig el kellett végezniük az első kiberbiztonsági auditot. A modernizált szolgáltatások olyan platformra kerülnek, amelyet ezek a kötelezettségek szerint tervezünk. Az adatrendelet szolgáltatóváltási szabályai miatt az adatokat már az első szelettől hordozhatóan tartjuk, a személyes adatokat tartalmazó nyilvántartásoknál pedig a migrációs leképezések és a tesztadatok a GDPR-t követik.
01Miért nem váltják ki egyszerre az egész rendszert?
Mert egyetlen átállás minden kockázatot egy napra összpontosít, és az üzlet évekig vár bármilyen haszonra. Ha funkcióról funkcióra haladunk, minden szelet párhuzamos futtatásban bizonyít, önállóan élesedik, és szükség esetén visszaállítható.
02Le tudja fordítani az MI a COBOL-kódunkat Javára?
A soronkénti fordítás általában ugyanolyan nehezen módosítható kódot eredményez, mint az eredeti. Az MI-t arra használjuk, hogy elolvassa és dokumentálja a régi kódot, és szabály- és tesztterveket készítsen, az új szolgáltatásokat pedig rendesen megtervezzük. Minden feltárt szabályt emberek ellenőriznek, mielőtt felhasználnánk.
03A szakértőink nyugdíjba mennek. Hogyan rögzítik a tudásukat?
Strukturált egyeztetéseken, ahol a szakértők átnézik a feltárt szabályokat és a karakterizációs teszteket. Tudásuk dokumentációban és tesztekben marad meg, amelyek a csapatánál maradnak, nem a mi fejünkben.
04Ez az SAP ECC-re is érvényes?
Igen. Ugyanezek az elvek érvényesek az egyedi kód rendbetételére és egy SAP S/4HANA-migrációra: felmérjük, mi van még használatban, feltárjuk és teszteljük, ami számít, és ellenőrzött lépésekben haladunk.
05Meddig fut párhuzamosan a régi és az új rendszer?
Amíg az egyeztetés eredményei el nem érik az üzleti gazdával megállapított tűréshatárt, és elég hosszan ahhoz, hogy az időszakos folyamatokat, például a havi zárást vagy az éves futtatásokat is lefedje.
Mondja el, melyik rendszer fogja vissza a szervezetét, és mi függ tőle. Javaslatot teszünk az első szeletre, és arra, hogyan igazolható biztonságosan, akárhány országot szolgál ki.