Модернизирайте системата, която никой не смее да пипне, функция по функция.
Десетилетия бизнес правила живеят в COBOL, PL/I, Oracle Forms и ранни версии на Java и .NET. Възстановяваме тези правила, изграждаме предпазна мрежа от тестове и пренасяме функция по функция зад фасаден слой, с паралелна работа и съпоставяне на резултатите, преди нещо да бъде изключено.
За български организации с критични системи, при които прекъсване или загубено правило не е допустимо.
Портфолиото се оценява и целевото състояние се договаря. Бизнес правилата се възстановяват от кода с помощта на AI и се проверяват от хора. Характеризиращите тестове образуват предпазна мрежа. Всяка функция се изгражда наново зад фасаден слой и работи паралелно със старата система; разликите се анализират и отстраняват, преди собственикът от бизнеса да одобри превключването и старата част да бъде изведена от употреба.
Преди и след
Какво се променя в начина Ви на работа
Днес
Със системата
Днес
Днес: Всяка промяна е риск
Малки нормативни промени отнемат месеци, защото никой не може да предвиди какво още ще засегнат.
Със системата
Със системата: Промени, подкрепени с тестове
Характеризиращите тестове описват какво прави системата днес, така че всяка промяна показва ефекта си преди пускането.
Днес
Днес: Знанието се пенсионира
Хората, които разбират кода, наближават пенсия, а документацията отдавна не отговаря на системата.
Със системата
Със системата: Записани и проверени правила
Бизнес правилата, възстановени от кода, се документират на разбираем език и се потвърждават от експерти в предметната област.
Днес
Днес: Големите планове засядат
Програмите за пълна замяна обещават една дата на превключване, която постоянно се отлага, докато разходите растат.
Със системата
Със системата: Ползата идва на части
Функциите се пренасят една по една зад фасаден слой. Всяка част заработва самостоятелно и може да бъде върната назад.
Днес
Днес: Данни, заключени в стари структури
Новите услуги и AI приложенията не достигат до данните без крехки извлечения и нощни пакетни обработки.
Със системата
Със системата: Данни, достъпни чрез API
Пренесените области предоставят данните си чрез документирани API и се съпоставят със старата система, докато тя бъде изведена от употреба.
Работен процес
Как протича работният процес
Подход по модела strangler fig: новата система расте около старата, функция по функция. Цикълът между паралелната работа и новото изграждане е мястото, където се върши по-голямата част от реалната работа.
Примерен работен процес
7 стъпки · 3 човешки проверки
Легенда
Система
AI агент
Човек
Човешка проверка
Път при изключение
Модернизация на стари системи: примерен работен процес с цикъл на съпоставяне
Прочетете диаграмата като текст
Основният път води от оценката на портфолиото и възстановяването на бизнес правилата, през изграждането на предпазна мрежа от характеризиращи тестове и новото изграждане на една функция зад фасаден слой, до паралелната работа на старата и новата система и накрая до превключването и извеждането на старата част от употреба.
Хора одобряват целевата архитектура, проверяват всяко възстановено правило и одобряват всяко превключване: това са човешките проверки.
Когато паралелната работа покаже различни резултати, частта напуска основния път за анализ от инженери и експерти в предметната област и се връща към стъпката за ново изграждане, докато старата и новата система не дадат съвпадащи резултати.
01
Стъпка 1: Оценка на портфолиотоЧовек
Опис на приложенията, карта на зависимостите и потоците от данни и решение за всяко приложение: извеждане от употреба, запазване, пренасяне в друга среда, смяна на платформата, ново изграждане или замяна. Предметните области се описват, за да се намерят местата, където системата може да се раздели на части.
Човешка проверка
Вашият архитектурен съвет одобрява целевата архитектура и реда на частите.
02
Стъпка 2: Възстановяване на бизнес правилатаAI агент
Анализът на кода с помощта на AI чете COBOL, PL/I, JCL, Oracle Forms и по-стари Java или .NET и подготвя чернови на документация, графи на извикванията и каталог на бизнес правилата.
Човешка проверка
Инженери и експерти в предметната област проверяват всяко извлечено правило, преди то да се използва като спецификация. Непроверените правила се маркират като такива.
03
Стъпка 3: Изграждане на предпазната мрежаСистема
Характеризиращите тестове се създават от анонимизирани входни и изходни данни от реалната среда, така че сегашното поведение, включително особеностите му, е описано, преди нещо да се промени.
04
Стъпка 4: Нова част зад фасаден слойСистема
Пред старата система се поставя маршрутизиращ фасаден слой или API слой. Една функция се изгражда наново като нова услуга, а данните ѝ се пренасят и се поддържат синхронизирани.
05
Стъпка 5: Паралелна работа и съпоставянеСистема
Старата и новата система обработват едни и същи транзакции. Резултатите и данните се сравняват автоматично, а всяка разлика се отчита по правило и по запис.
06
Стъпка 6: Анализ на разликитеЧовек
Инженери и експерти в предметната област решават дали всяка разлика е дефект в новата услуга, дефект в старата или планирана промяна, и връщат частта за доработка.
Път при изключение: Резултатите се различават· Връща се към стъпка 4
07
Стъпка 7: Превключване и извеждане от употребаЧовек
Трафикът за функцията се пренасочва към новата услуга през фасадния слой. След стабилен период старият код и данните му се извеждат от употреба и се архивират.
Човешка проверка
Собственикът от бизнеса одобрява всяко превключване въз основа на резултатите от съпоставянето. Връщането назад през фасадния слой остава възможно до извеждането от употреба.
Компоненти
Какво бихме изградили
01
Карта на портфолиото и зависимостите
Опис, карта на интерфейсите и потоците от данни и модел на предметните области, който показва къде системата може да се раздели на части.
Salesforce като нова система за работа с клиентиПлатформаSalesforce
Интеграционна платформа и API шлюз
Целеви облак или център за данни
Контролни механизми
Вградени механизми за контрол
Граници на достъпа
Анализът на кода се извършва в среда под Ваш контрол и изходният код не се изпраща към услуги, които не сте одобрили. Данните от реалната среда, използвани за тестове, се анонимизират, преди да напуснат производствената зона.
Човешка проверка
Възстановените правила се проверяват от инженери и експерти в предметната област, преди да станат спецификации. Всяко превключване се одобрява от собственика от бизнеса въз основа на резултатите от съпоставянето, с възможност за връщане назад.
Проследимост
Всяко правило в каталога води до кода, от който идва, и до човека, който го е проверил. Отчетите за съпоставяне се пазят като доказателство за всяко превключване.
Защита на данните
Пренасянето на данни следва документирано съответствие на полетата и се проверява чрез броя на записите и контролни суми, а личните данни в тестовите набори се свеждат до минимум. Правилата за съхранение се пренасят заедно с данните.
Прозрачност на изкуствения интелект
Когато AI изготвя чернова на документация или код, резултатът се маркира, преглежда и версионира като всеки друг инженерен артефакт.
Показатели
Какво бихме измервали
Договаряме тези показатели с Вас по време на оценката и ги следим за всяка част, а не само за програмата като цяло.
Какво бихме измервали
Показател
Защо е важно
Как бихме го измерили
01Време за въвеждане на промяна
Защо е важноНай-ясният признак, че системата става по-лесна за промяна.
Как бихме го измерилиВремето от одобреното искане за промяна до реалната среда, за старите и за модернизираните части.
02Състояние на съпоставянето
Защо е важноПоказва дали новата услуга наистина се държи като старата там, където трябва.
Как бихме го измерилиДелът на транзакциите и записите, които съвпадат при паралелната работа, и откритите разлики по причина.
03Покритие на правилата
Защо е важноНеизвестните правила са основният риск при всяка замяна.
Как бихме го измерилиДелът на възстановените бизнес правила, проверени от експерти и покрити с тестове.
04Остатък от старата система
Защо е важноМодернизацията се изплаща, когато старите компоненти наистина се изключат.
Как бихме го измерилиИзведени от употреба функции, части от кода, пакетни задачи и лицензи, отчетени за всяка част.
Не определяме целеви стойности, преди да има изходно измерване.
Внедряване
Как бихме го въвели
Фаза 01
Оценка
Портфолио, зависимости, предметни области и рискове. Избираме първа част, която е важна за бизнеса, но може да бъде върната назад.
Критерии за завършване
Одобрена целева архитектура
Договорен ред на частите
Осигурен достъп до тестове и данни
Фаза 02
Първа част
Възстановяване на правилата, предпазна мрежа, фасаден слой и една нова функция, която работи паралелно със старата система.
Критерии за завършване
Съпоставяне в рамките на договорения толеранс
Собственикът от бизнеса одобрява превключването
Изпробвано връщане назад
Фаза 03
Част по част
Следващите функции минават по същия път, всяка със своя паралелна работа и решение за превключване.
Критерии за завършване
Всяка част съпоставена и превключена
Знанието предадено на Вашия екип
Фаза 04
Извеждане от употреба
Старите части от кода, пакетните задачи и хранилищата за данни се архивират и изключват.
Системата за администриране на полици на застраховател или платежни системи на мейнфрейм, модернизирани зад API, докато счетоводните данни остават съпоставени.
Собствената ERP система на семейна фирма или специфични разширения и системи в завода, пренесени успоредно с преминаването към SAP S/4HANA.
Илюстративен пример
Регистрова система на държавна агенция
Ситуация
Държавна агенция води регистър в система, изградена преди повече от двадесет години. Всяка промяна в закона изисква месеци работа, преминаването към евро е направено с поправки в кода, а двама от разработчиците, които познават системата, скоро се пенсионират.
Система
Правилата се възстановяват от кода и се проверяват от експертите на агенцията. Фасаден слой пренасочва първо една услуга, например издаването на справки от регистъра, към нова услуга, която работи паралелно със старата система, докато резултатите съвпаднат.
Човешки контрол
Експертите проверяват всяко правило. Директорът на отговорната дирекция одобрява всяко превключване, а връщането назад през фасадния слой остава възможно.
Какво бихме измервали
Състояние на съпоставянето, покритие на правилата и време за въвеждане на следващата нормативна промяна.
България
Модернизация по българските и европейските правила
От 1 януари 2026 г. системите в България работят в евро, а предстоят и други промени: законопроект, внесен в Народното събрание на 5 ноември 2026 г., предвижда структурирани електронни фактури от 1 юли 2028 г. Всяка такава промяна в стара система е риск, когато правилата не са записани никъде. Подреждаме модернизацията така, че всяка част да бъде пренесена и съпоставена със старата система, преди нещо да бъде изключено.
Модернизираните услуги се разполагат на платформи, проектирани с оглед на Закона за киберсигурност, който от 17 февруари 2026 г. въвежда NIS2. Правилата на Акта за данните за смяна на доставчика на услуги за обработка на данни са причина данните да останат преносими още от първата част. Когато записите съдържат лични данни, съответствието на полетата и тестовите данни следват Общия регламент относно защитата на данните (GDPR).
Защото едно-единствено превключване съсредоточава целия риск в една дата, а бизнесът чака години за каквато и да е полза. Когато пренасяте функция по функция, всяка част се доказва при паралелна работа, заработва самостоятелно и може да бъде върната назад при нужда.
02Може ли AI да преведе нашия COBOL на Java?
Преводът ред по ред обикновено дава код, който е толкова труден за промяна, колкото и оригиналът. Използваме AI, за да четем и документираме стария код и да изготвяме чернови на правила и тестове, а след това проектираме новите услуги както трябва. Всяко възстановено правило се проверява от хора, преди да бъде използвано.
03Нашите експерти се пенсионират. Как запазвате знанието им?
Чрез структурирани срещи, на които експертите преглеждат възстановените правила и характеризиращите тестове. Знанието им се записва в документация и тестове, които остават при Вашия екип, а не в нашите глави.
04Важи ли това и за SAP ECC?
Да. Същите принципи важат за преработката на собствения код и за преминаването към SAP S/4HANA: оценявате какво още се използва, възстановявате и тествате важното и се движите на контролирани стъпки.
05Колко дълго старата и новата система работят паралелно?
Докато резултатите от съпоставянето достигнат толеранса, договорен със собственика от бизнеса, и достатъчно дълго, за да обхванат периодичните процеси, например приключването на месеца или годишните обработки.