Modernizujte systém, na který si nikdo netroufne sáhnout, jednu funkci po druhé.
Desítky let obchodních pravidel žijí v COBOLu, PL/I, Oracle Forms, v raných verzích Javy a .NET nebo ve vlastním ERP z devadesátých let. Tato pravidla z kódu vytáhneme, postavíme záchrannou síť z testů a funkce převádíme jednu po druhé za fasádou, se souběžným provozem a porovnáním výsledků dřív, než se cokoli vypne.
Pro firmy a úřady v Česku, které provozují kritické systémy, u nichž si nemohou dovolit výpadek ani ztrátu pravidel.
Posoudí se portfolio aplikací a dohodne cílový stav. Obchodní pravidla se z kódu získají s pomocí AI a lidé je ověří. Charakterizační testy tvoří záchrannou síť. Každá funkce se znovu postaví za fasádou a běží souběžně se starým systémem; rozdíly se roztřídí a opraví, než věcný garant schválí přepnutí a stará část se vyřadí.
Před a po
Co se změní ve způsobu práce
Dnes
Se systémem
Dnes
Dnes: Každá změna je riziko
Malé legislativní změny trvají měsíce, protože nikdo nedokáže předvídat, co dalšího změna ovlivní.
Se systémem
Se systémem: Změny podložené testy
Charakterizační testy zachytí, co systém dělá dnes, takže každá změna ukáže svůj dopad ještě před vydáním.
Dnes
Dnes: Znalosti odcházejí do důchodu
Lidé, kteří kódu rozumějí, se blíží důchodu a dokumentace přestala odpovídat systému už dávno.
Se systémem
Se systémem: Pravidla sepsaná a ověřená
Obchodní pravidla získaná z kódu jsou popsaná srozumitelným jazykem a potvrzená odborníky na danou oblast.
Dnes
Dnes: Velké plány se zasekávají
Programy úplné náhrady slibují jediný den přechodu, který se stále posouvá, zatímco náklady rostou.
Se systémem
Se systémem: Přínos po částech
Funkce se přesouvají jedna po druhé za fasádou. Každá část jde do provozu samostatně a lze ji vrátit zpět.
Dnes
Dnes: Data uzamčená ve starých strukturách
Nové služby a využití AI se k datům nedostanou bez křehkých exportů a nočních dávek.
Se systémem
Se systémem: Data dostupná přes API
Převedené oblasti zpřístupňují svá data přes zdokumentovaná API a až do vyřazení starého systému se s ním porovnávají.
Pracovní postup
Jak pracovní postup probíhá
Přístup podle vzoru strangler fig: nový systém postupně obrůstá ten starý, funkci po funkci. Většina skutečné práce se odehrává ve smyčce mezi souběžným provozem a přestavbou.
Ilustrativní pracovní postup
7 kroků · 3 kontroly člověkem
Legenda
Systém
AI agent
Člověk
Kontrola člověkem
Postup při výjimce
Modernizace starších systémů: ilustrativní pracovní postup se smyčkou porovnání
Zobrazit diagram jako text
Hlavní cesta vede od posouzení portfolia a získání obchodních pravidel přes záchrannou síť z charakterizačních testů a novou funkci za fasádou k souběžnému provozu starého a nového systému a nakonec k přepnutí a vyřazení staré části.
Lidé schvalují cílovou architekturu, ověřují každé získané pravidlo a schvalují každé přepnutí: to jsou kontroly člověkem.
Když souběžný provoz ukáže rozdílné výstupy, část opustí hlavní cestu a vývojáři s odborníky rozdíly roztřídí. Poté se vrací ke kroku nové části za fasádou, dokud se výsledky starého a nového systému neshodují.
01
Krok 1: Posouzení portfoliaČlověk
Soupis aplikací, mapa závislostí a datových toků a rozhodnutí pro každou aplikaci: vyřadit, ponechat, přesunout, přenést na novou platformu, přestavět nebo nahradit. Mapování oblastí najde místa, kde lze systém rozdělit na části.
Kontrola člověkem
Cílovou architekturu a pořadí částí schvaluje vaše architektonická rada.
02
Krok 2: Získání obchodních pravidelAI agent
Analýza kódu s pomocí AI čte COBOL, PL/I, JCL, Oracle Forms a starší Javu nebo .NET a připravuje návrh dokumentace, grafy volání a katalog obchodních pravidel.
Kontrola člověkem
Vývojáři a odborníci na danou oblast ověří každé získané pravidlo dřív, než se použije jako specifikace. Neověřená pravidla jsou tak označená.
03
Krok 3: Záchranná síť z testůSystém
Charakterizační testy vznikají z anonymizovaných vstupů a výstupů z ostrého provozu, takže současné chování včetně jeho zvláštností je zachycené dřív, než se cokoli změní.
04
Krok 4: Nová část za fasádouSystém
Před starý systém se umístí směrovací fasáda nebo vrstva API. Jedna funkce se znovu postaví jako nová služba, její data se převedou a průběžně synchronizují.
05
Krok 5: Souběžný provoz a porovnáníSystém
Starý i nový systém zpracovávají stejné transakce. Výstupy a data se automaticky porovnávají a každý rozdíl se vykáže podle pravidla a záznamu.
06
Krok 6: Roztřídění rozdílůČlověk
Vývojáři a odborníci rozhodnou, zda je každý rozdíl chybou nové služby, chybou starého systému, nebo zamýšlenou změnou, a vrátí část k přepracování.
Postup při výjimce: Výstupy se liší· Vrací se ke kroku 4
07
Krok 7: Přepnutí a vyřazeníČlověk
Provoz pro danou funkci se přes fasádu přesune na novou službu. Po stabilním období se stará cesta v kódu i její data vyřadí a archivují.
Kontrola člověkem
Každé přepnutí schvaluje věcný garant na základě výsledků porovnání. Návrat zpět přes fasádu zůstává dostupný až do vyřazení.
Komponenty
Co bychom postavili
01
Mapa portfolia a závislostí
Soupis, mapa rozhraní a datových toků a doménový model, který ukáže, kde lze systém rozdělit na části.
Salesforce jako nový front officePlatformaSalesforce
Integrační platforma a API gateway
Cílový cloud nebo datové centrum
Kontrolní mechanismy
Zabudované kontrolní mechanismy
Hranice přístupu
Analýza kódu běží v prostředí, které máte pod kontrolou, a žádný zdrojový kód se neposílá do služeb, které jste neschválili. Data z ostrého provozu použitá pro testy se anonymizují dřív, než opustí produkční zónu.
Kontrola člověkem
Získaná pravidla ověřují vývojáři a odborníci na danou oblast dřív, než se z nich stanou specifikace. Každé přepnutí schvaluje věcný garant na základě výsledků porovnání, s možností návratu zpět.
Auditovatelnost
Každé pravidlo v katalogu lze dohledat ke kódu, ze kterého pochází, a k člověku, který ho ověřil. Přehledy porovnání se uchovávají jako doklad ke každému přepnutí.
Ochrana dat
Migrace dat se řídí zdokumentovaným mapováním s počty záznamů a kontrolními součty a osobní údaje se v testovacích sadách omezují na minimum. Pravidla uchování se přesouvají spolu s daty.
Transparentnost AI
Kde AI připravuje návrh dokumentace nebo kódu, je výstup označen, zkontrolován a verzován jako jakýkoli jiný technický artefakt.
Ukazatele
Co bychom měřili
Tyto ukazatele s vámi dohodneme během posouzení a sledujeme je pro každou část, nejen za celý program.
Co bychom měřili
Ukazatel
Proč na něm záleží
Jak bychom ho měřili
01Doba realizace změny
Proč na něm záležíNejjasnější znamení, že se systém dá snáz měnit.
Jak bychom ho měřiliDoba od schváleného požadavku na změnu po nasazení do ostrého provozu, pro starou i modernizovanou část.
02Stav porovnání
Proč na něm záležíUkazuje, zda se nová služba chová jako stará všude, kde má.
Jak bychom ho měřiliPodíl transakcí a záznamů, které se během souběžného provozu shodují, s otevřenými rozdíly podle příčiny.
03Pokrytí pravidel
Proč na něm záležíNeznámá pravidla jsou hlavním rizikem každé náhrady.
Jak bychom ho měřiliPodíl získaných obchodních pravidel, která odborníci ověřili a která jsou pokrytá testy.
04Rozsah starého systému
Proč na něm záležíModernizace se vyplatí, až když se staré komponenty opravdu vypnou.
Jak bychom ho měřiliVyřazené funkce, cesty v kódu, dávkové úlohy a licence, sledované pro každou část.
Dokud neznáme výchozí stav, cíle nestanovujeme.
Zavedení
Jak bychom řešení zavedli
Fáze 01
Posouzení
Portfolio, závislosti, oblasti a rizika. Vybereme první část, na které byznysu záleží, ale kterou lze vrátit zpět.
Kritéria dokončení
Cílová architektura schválena
Pořadí částí dohodnuto
Přístup k testům a datům zajištěn
Fáze 02
První část
Získání pravidel, záchranná síť, fasáda a jedna přestavěná funkce v souběžném provozu se starým systémem.
Kritéria dokončení
Porovnání v dohodnuté toleranci
Věcný garant schválil přepnutí
Návrat zpět otestován
Fáze 03
Část po části
Další funkce jdou stejnou cestou, každá s vlastním souběžným provozem a rozhodnutím o přepnutí.
Kritéria dokončení
Každá část porovnána a přepnuta
Znalosti předány vašemu týmu
Fáze 04
Vyřazení
Staré cesty v kódu, dávkové úlohy a datová úložiště se archivují a vypnou.
Agendové systémy krajů a obcí, například pro sociální služby, poplatky nebo evidence, kde jsou právní předpisy zakódované v desítky let starém kódu a změny stále přibývají.
Vlastní rozšíření ERP a systémy ve výrobě, převáděné souběžně s migrací na SAP S/4HANA, nebo vlastní ERP rodinné firmy nahrazované po částech.
Ilustrativní příklad
Systém pojistných smluv pojišťovny
Situace
Pojišťovna spravuje pojistné smlouvy v systému starém několik desetiletí, napsaném v COBOLu s nadstavbou v Oracle Forms. Na změny produktů a předpisů se čeká měsíce a dva z vývojářů, kteří kódu rozumějí, odcházejí do důchodu.
Systém
Pravidla se získají a ověří pro každou produktovou řadu. Fasáda nejdřív přesměruje výpočty jedné produktové řady na novou službu, která běží souběžně se starým systémem, dokud se výsledky neshodují.
Kde rozhoduje člověk
Produktoví specialisté a pojistní matematici ověří pravidla své produktové řady. Přepnutí schvaluje vlastník produktové řady; návrat zpět přes fasádu zůstává dostupný.
Co bychom měřili
Stav porovnání pro každou produktovou řadu, pokrytí pravidel a doba realizace příští změny produktu nebo předpisu.
Česko
Modernizace podle českých a evropských pravidel
Mnoho českých firem a úřadů provozuje agendové systémy nebo vlastní ERP, které vznikly před desítkami let a na které se nabalují legislativní změny. Modernizaci řadíme tak, aby se každá část přesunula samostatně a starý i nový systém se porovnaly dřív, než se cokoli vypne.
Od 1. listopadu 2025 je účinný zákon č. 264/2025 Sb., o kybernetické bezpečnosti, nad jehož dodržováním vykonává dozor Národní úřad pro kybernetickou a informační bezpečnost (NÚKIB). Modernizované služby proto stavíme na platformách navržených s ohledem na bezpečnostní opatření regulovaných služeb. Pravidla nařízení o datech pro přechod mezi poskytovateli jsou důvodem držet data přenositelná od první části, a kde záznamy obsahují osobní údaje, řídí se migrační mapování i testovací data GDPR.
Protože jediný den přechodu soustředí celé riziko do jednoho data a byznys čeká roky na jakýkoli přínos. Při postupu funkci po funkci se každá část prověří v souběžném provozu, jde do provozu samostatně a v případě potřeby ji lze vrátit zpět.
02Dokáže AI přeložit náš COBOL do Javy?
Překlad řádek po řádku obvykle vytvoří kód, který se mění stejně těžko jako původní. AI používáme ke čtení a dokumentaci starého kódu a k návrhu pravidel a testů; nové služby pak navrhujeme řádně. Každé získané pravidlo ověří lidé dřív, než se použije.
03Naši odborníci odcházejí do důchodu. Jak zachytíte, co vědí?
Strukturovanými setkáními, na kterých odborníci procházejí získaná pravidla a charakterizační testy. Jejich znalosti skončí v dokumentaci a testech, které zůstanou vašemu týmu, ne v našich hlavách.
04Platí to i pro SAP ECC?
Ano. Stejné principy platí pro úpravy vlastního kódu i pro migraci na SAP S/4HANA: posoudit, co se ještě používá, získat a otestovat to podstatné a postupovat v řízených krocích.
05Jak dlouho běží starý a nový systém vedle sebe?
Dokud výsledky porovnání nesplní toleranci dohodnutou s věcným garantem, a dost dlouho na to, aby pokryly i periodické procesy, jako je měsíční nebo roční uzávěrka.