Modernizați sistemul pe care nimeni nu îndrăznește să-l atingă, câte o funcționalitate pe rând.
Reguli de business acumulate în decenii trăiesc în COBOL, PL/I, Oracle Forms și în primele versiuni de Java și .NET. Recuperăm aceste reguli, construim o plasă de siguranță din teste și mutăm funcționalitate după funcționalitate în spatele unei fațade, cu rulare în paralel și reconciliere înainte ca ceva să fie oprit.
Pentru organizații care operează sisteme critice în mai multe țări, unde întreruperile și regulile pierdute nu sunt o opțiune.
04Reconstruirea unei bucăți în spatele fațadeiSistem
05Rulare în paralel și reconciliereSistem
06Analiza diferențelorPersoană
07Trecere și retragerePersoană
Portofoliul de aplicații este evaluat și ținta este convenită. Regulile de business sunt recuperate din cod cu ajutorul IA și verificate de oameni. Testele de caracterizare formează o plasă de siguranță. Fiecare funcționalitate este reconstruită în spatele unei fațade și rulată în paralel cu sistemul vechi; diferențele sunt analizate și corectate înainte ca responsabilul de business să aprobe trecerea, iar partea veche este retrasă.
Înainte și după
Ce se schimbă în felul în care lucrați
Astăzi
Cu sistemul
Astăzi
Astăzi: Orice modificare este un risc
Modificările legislative mici durează luni, pentru că nimeni nu poate anticipa ce altceva va fi afectat.
Cu sistemul
Cu sistemul: Modificări susținute de teste
Testele de caracterizare surprind ce face sistemul astăzi, astfel încât fiecare modificare își arată efectul înainte de lansare.
Astăzi
Astăzi: Cunoștințele ies la pensie
Oamenii care înțeleg codul sunt aproape de pensie, iar documentația a încetat de mult să corespundă sistemului.
Cu sistemul
Cu sistemul: Reguli scrise și verificate
Regulile de business recuperate din cod sunt documentate în limbaj clar și confirmate de experții de domeniu.
Astăzi
Astăzi: Planurile de înlocuire dintr-odată se blochează
Programele de înlocuire completă promit o singură dată de trecere, care tot se amână, în timp ce costurile cresc.
Cu sistemul
Cu sistemul: Valoare livrată pe bucăți
Funcționalitățile se mută pe rând, în spatele unei fațade. Fiecare bucată intră în producție separat și poate fi readusă la starea anterioară.
Astăzi
Astăzi: Date blocate în structuri vechi
Serviciile noi și cazurile de utilizare IA nu pot ajunge la date fără extrageri fragile și procesări peste noapte.
Cu sistemul
Cu sistemul: Date disponibile prin API-uri
Domeniile migrate își expun datele prin API-uri documentate, reconciliate cu sistemul vechi până la retragerea acestuia.
Flux de lucru
Cum funcționează fluxul de lucru
O abordare de tip „strangler fig”: noul sistem crește în jurul celui vechi, funcționalitate după funcționalitate. Bucla dintre rularea în paralel și reconstruire este locul în care se face cea mai mare parte a muncii reale.
Flux de lucru ilustrativ
7 pași · 3 verificări umane
Legendă
Sistem
Agent IA
Persoană
Verificare umană
Ramură de excepție
Modernizarea sistemelor legacy: flux de lucru ilustrativ cu buclă de reconciliere
Citiți diagrama ca text
Ramura principală merge de la evaluarea portofoliului și recuperarea regulilor de business, prin construirea unei plase de siguranță din teste de caracterizare și reconstruirea unei funcționalități în spatele unei fațade, până la rularea în paralel a sistemului vechi și a celui nou și, în final, la trecere și retragerea părții vechi.
Oamenii aprobă arhitectura-țintă, verifică fiecare regulă recuperată și aprobă fiecare trecere: acestea sunt punctele de verificare umană.
Când rularea în paralel arată că ieșirile diferă, bucata părăsește ramura principală pentru analiză de către ingineri și experți de domeniu și revine la pasul de reconstruire până când sistemul vechi și cel nou se reconciliază.
01
Pasul 1: Evaluarea portofoliuluiPersoană
Inventarul aplicațiilor, harta dependențelor și a fluxurilor de date și o decizie pentru fiecare aplicație: retragere, păstrare, mutare pe altă infrastructură, mutare pe altă platformă, reconstruire sau înlocuire. Domeniile sunt cartografiate pentru a găsi punctele în care sistemul poate fi împărțit.
Verificare umană
Comitetul dumneavoastră de arhitectură aprobă arhitectura-țintă și ordinea etapelor.
02
Pasul 2: Recuperarea regulilor de businessAgent IA
Analiza codului asistată de IA citește COBOL, PL/I, JCL, Oracle Forms și versiuni mai vechi de Java sau .NET și redactează documentație, grafuri de apeluri și un catalog de reguli de business.
Verificare umană
Inginerii și experții de domeniu verifică fiecare regulă extrasă înainte ca ea să fie folosită ca specificație. Regulile neverificate sunt marcate ca atare.
03
Pasul 3: Construirea plasei de siguranțăSistem
Testele de caracterizare sunt generate din intrări și ieșiri de producție anonimizate, astfel încât comportamentul actual, inclusiv particularitățile lui, este surprins înainte de orice schimbare.
04
Pasul 4: Reconstruirea unei bucăți în spatele fațadeiSistem
O fațadă de rutare sau un strat de API-uri este plasat în fața sistemului vechi. O funcționalitate este reconstruită ca serviciu nou, cu datele ei migrate și sincronizate.
05
Pasul 5: Rulare în paralel și reconciliereSistem
Sistemul vechi și cel nou procesează aceleași tranzacții. Ieșirile și datele sunt comparate automat, iar fiecare diferență este raportată pe regulă și pe înregistrare.
06
Pasul 6: Analiza diferențelorPersoană
Inginerii și experții de domeniu decid dacă fiecare diferență este un defect al serviciului nou, un defect al celui vechi sau o schimbare intenționată și trimit bucata înapoi la refacere.
Ramură de excepție: Ieșirile diferă· Revine la pasul 4
07
Pasul 7: Trecere și retragerePersoană
Traficul pentru funcționalitatea respectivă trece prin fațadă la serviciul nou. După o perioadă stabilă, ramura veche de cod și datele ei sunt retrase și arhivate.
Verificare umană
Responsabilul de business aprobă fiecare trecere pe baza rezultatelor reconcilierii. Revenirea prin fațadă rămâne posibilă până la retragere.
Componente
Ce am construi
01
Harta portofoliului și a dependențelor
Inventar, harta interfețelor și a fluxurilor de date și un model de domeniu care arată unde poate fi împărțit sistemul.
Analiza codului rulează într-un mediu pe care îl controlați, fără ca vreo linie de cod sursă să fie trimisă către servicii pe care nu le-ați aprobat. Datele de producție folosite pentru teste sunt anonimizate înainte de a ieși din zona de producție.
Verificare umană
Regulile recuperate sunt verificate de ingineri și de experții de domeniu înainte de a deveni specificații. Fiecare trecere este aprobată de responsabilul de business pe baza rezultatelor reconcilierii, cu posibilitatea de revenire.
Auditabilitate
Fiecare regulă din catalog poate fi urmărită până la codul din care provine și până la persoana care a verificat-o. Rapoartele de reconciliere sunt păstrate ca dovadă pentru fiecare trecere.
Protecția datelor
Migrarea datelor urmează o corespondență documentată, cu numărul de înregistrări și sume de control, iar datele cu caracter personal sunt reduse la minimum în seturile de test. Regulile de păstrare se mută odată cu datele.
Transparența IA
Acolo unde IA redactează documentație sau cod, rezultatul este marcat, verificat și versionat ca orice alt artefact de inginerie.
Indicatori
Ce am măsura
Stabilim acești indicatori împreună cu dumneavoastră în etapa de evaluare și îi urmărim pentru fiecare etapă, nu doar pentru programul în ansamblu.
Ce am măsura
Indicator
De ce contează
Cum l-am măsura
01Timpul de implementare a unei modificări
De ce conteazăCel mai clar semn că sistemul devine mai ușor de modificat.
Cum l-am măsuraTimpul de la cererea de modificare aprobată până la producție, pentru partea veche și pentru cea modernizată.
02Stadiul reconcilierii
De ce conteazăArată dacă serviciul nou se comportă cu adevărat ca cel vechi acolo unde trebuie.
Cum l-am măsuraPonderea tranzacțiilor și a înregistrărilor care coincid pe durata rulării în paralel, cu diferențele deschise grupate pe cauze.
03Acoperirea regulilor
De ce conteazăRegulile necunoscute sunt principalul risc al oricărei înlocuiri.
Cum l-am măsuraPonderea regulilor de business recuperate care sunt verificate de experții de domeniu și acoperite de teste.
04Amprenta legacy
De ce conteazăModernizarea se justifică atunci când componentele vechi sunt efectiv oprite.
Cum l-am măsuraFuncționalități, ramuri de cod, joburi batch și licențe retrase, urmărite pe fiecare etapă.
Nu stabilim ținte înainte de a avea o valoare de referință.
Implementare
Cum l-am pune în funcțiune
Etapa 01
Evaluare
Portofoliul, dependențele, domeniile și riscurile. Alegem o primă bucată care contează pentru business, dar care poate fi readusă la starea anterioară.
Criterii de încheiere
Arhitectura-țintă aprobată
Ordinea etapelor convenită
Accesul la teste și la date asigurat
Etapa 02
Prima bucată
Recuperarea regulilor, plasa de siguranță, fațada și o funcționalitate reconstruită, rulată în paralel cu sistemul vechi.
Criterii de încheiere
Reconcilierea în limitele toleranței convenite
Responsabilul de business aprobă trecerea
Revenirea testată
Etapa 03
Bucată cu bucată
Celelalte funcționalități urmează același drum, fiecare cu propria rulare în paralel și propria decizie de trecere.
Criterii de încheiere
Fiecare bucată reconciliată și trecută în producție
Cunoștințele transferate echipei dumneavoastră
Etapa 04
Retragere
Ramurile vechi de cod, joburile batch și depozitele de date sunt arhivate și oprite.
Aplicații pentru beneficii sociale, taxe locale și evidențe, în care legislația este codificată în programe vechi de zeci de ani, iar modificările continuă să apară; de exemplu, aplicația de beneficii a unei direcții județene, modernizată modul cu modul.
Extensii ERP dezvoltate la comandă și sisteme din fabrică, mutate odată cu migrarea la SAP S/4HANA.
Exemplu ilustrativ
Un sistem de polițe comun pentru trei țări
Situație
Un sistem mainframe calculează primele de asigurare pentru filialele din România, Bulgaria și Ungaria ale unui grup de asigurări. Fiecare țară are modificări de reguli în așteptare, iar doi dintre programatorii care cunosc codul se pensionează.
Sistem
Regulile sunt recuperate și verificate pentru fiecare țară. O fațadă direcționează mai întâi calculele unei singure țări către un serviciu nou, care rulează în paralel cu mainframe-ul până când rezultatele se reconciliază.
Control uman
Experții de domeniu din fiecare țară își verifică regulile. Responsabilul de business din fiecare țară aprobă trecerea; revenirea prin fațadă rămâne posibilă.
Ce am măsura
Stadiul reconcilierii pe fiecare țară, acoperirea regulilor și timpul de implementare a următoarei modificări legislative.
România
Modernizare sub reguli europene și românești
Grupurile europene folosesc adesea același sistem central legacy pentru mai multe țări, inclusiv pentru filialele din România, fiecare cu propriile modificări legislative în așteptare. Ordonăm modernizarea astfel încât variantele naționale să se mute pe rând, cu sistemul vechi și cel nou reconciliate pentru fiecare jurisdicție înainte ca ceva să fie oprit.
Serviciile modernizate ajung pe platforme proiectate ținând cont de obligațiile de securitate din OUG nr. 155/2024, care transpune Directiva NIS2 și are Directoratul Național de Securitate Cibernetică (DNSC) ca autoritate competentă. Pentru bănci și asigurători se adaugă DORA, pus în aplicare în România prin OUG nr. 14/2026, cu BNR sau ASF ca autoritate competentă, în funcție de tipul entității. Regulile de schimbare a furnizorului din Regulamentul privind datele sunt un motiv în plus să păstrați datele portabile încă de la prima etapă, iar acolo unde înregistrările conțin date cu caracter personal, corespondențele de migrare și datele de test respectă RGPD.
Pentru că o singură trecere concentrează tot riscul într-o singură zi, iar organizația așteaptă ani până la primul beneficiu. Mutarea funcționalitate cu funcționalitate permite fiecărei bucăți să se dovedească în rularea în paralel, să intre în producție separat și să fie retrasă la nevoie.
02Poate IA să traducă codul nostru COBOL în Java?
Traducerea linie cu linie produce de obicei un cod la fel de greu de modificat ca originalul. Folosim IA pentru a citi și documenta codul vechi și pentru a redacta reguli și teste, apoi proiectăm corect serviciile noi. Fiecare regulă recuperată este verificată de oameni înainte de a fi folosită.
03Experții noștri ies la pensie. Cum păstrați ce știu ei?
Prin sesiuni structurate în care experții verifică regulile recuperate și testele de caracterizare. Cunoștințele lor ajung în documentație și în teste care rămân la echipa dumneavoastră, nu în mintea noastră.
04Se aplică și pentru SAP ECC?
Da. Aceleași principii se aplică la remedierea codului personalizat și la o migrare la SAP S/4HANA: evaluați ce se mai folosește, recuperați și testați ce contează și mutați totul în pași controlați.
05Cât timp rulează în paralel sistemul vechi și cel nou?
Până când rezultatele reconcilierii se încadrează în toleranța convenită cu responsabilul de business și suficient de mult pentru a acoperi procesările periodice, cum ar fi închiderea de lună sau procesările anuale.
Spuneți-ne ce sistem vă ține pe loc și ce depinde de el. Vă propunem o primă bucată și un mod sigur de a o valida, indiferent pentru ce țări funcționează.