Старые системы как исполняемое ТЗ: модернизация без остановки организации

1. Почему старые системы — это не мусор, а память организации

Старая система редко появляется как «плохая система». Обычно это результат многих лет доработок, срочных регуляторных изменений, обходных решений, смены подрядчиков, новых отчетов, интеграций, управленческих требований и пользовательских компромиссов. В какой-то момент она становится неудобной, дорогой и рискованной, но продолжает выполнять критически важную функцию.

Главная ошибка модернизации — смотреть на старый ИТ-контур только глазами разработчика. Для разработчика это устаревший стек, монолит, неочевидные зависимости, старые библиотеки, хранимые процедуры, ручные выгрузки и отсутствие тестов. Для организации это может быть фактический реестр обязательств, кадровая история, складской контур, бухгалтерские состояния, архив решений, маршруты согласования, контроль исполнения и юридически значимые документы.

Поэтому старая система часто знает о бизнесе больше, чем актуальная документация. Документация могла не обновляться годами. Регламент мог измениться «устно». Пользовательские инструкции могли отражать только нормальный сценарий, а реальные исключения — жить в кнопках, запросах к базам данных, статусах, Excel-выгрузках и обращениях в поддержку.

Управленческий вывод: старый ИТ-контур нельзя просто выбросить. Его нужно исследовать как исполняемое ТЗ — источник фактической спецификации, которую нужно восстановить, проверить, очистить и перенести в новую архитектуру.

Старая система — это не только код. Это архив управленческих решений, которые организация часто уже забыла.

2. Российский контекст: импортонезависимость делает старые системы видимыми

В российской повестке старый ИТ-контур перестал быть внутренней ИТ-проблемой. Он стал частью технологического суверенитета, импортозамещения, регуляторной устойчивости и эффективности управления. Указ Президента РФ №309 от 7 мая 2024 года закрепляет среди национальных целей технологическое лидерство и цифровую трансформацию государственного и муниципального управления, экономики и социальной сферы. В нем также установлены целевые ориентиры: к 2030 году не менее 80% российских организаций ключевых отраслей должны перейти на базовое и прикладное российское ПО в системах, обеспечивающих основные производственные и управленческие процессы, а доля использования российского ПО в госорганах, госкорпорациях и компаниях с преобладающим участием РФ должна достичь 95%.¹

Это резко меняет смысл проектов модернизации. Речь уже не только о том, чтобы «обновить интерфейс» или «уйти с устаревшей СУБД». Нужно обеспечить управляемый переход на отечественные решения, не потеряв непрерывность, данные, отчетность, интеграции и контроль рисков.

Рынок корпоративных систем подтверждает сложность задачи. По данным CNews Analytics, среди российских организаций система планирования ресурсов предприятия используют около 29,9% организаций, среди крупных компаний — 57%; доля отечественных система планирования ресурсов предприятия среди используемых решений оценивается в 38%, а в реестре российского ПО на начало 2026 года было 234 продукта класса система планирования ресурсов предприятия.⁷

При этом ИТ-ландшафты организаций часто остаются разнородными. В исследовании, приведенном CNews со ссылкой на «К2Тех», ИТ-руководители называли среди острых проблем дефицит компетенций, «зоопарк» вендоров, риски ручного управления и недостаток прозрачности инфраструктуры.⁸

Для отдельных отраслей добавляется фактор КИИ. Распоряжение Правительства РФ от 26 февраля 2026 года №360-р утвердило перечень типовых отраслевых объектов критической информационной инфраструктуры, охватывающий, в частности, здравоохранение, транспорт, связь, энергетику, финансы, ТЭК, атомную энергетику, оборонную, ракетно-космическую, горнодобывающую, металлургическую и химическую промышленность.³ Деловые и отраслевые СМИ отдельно отмечали включение система планирования ресурсов предприятия-систем для ряда промышленных отраслей в контур КИИ, что повышает требования к аудиту, защите и управлению изменениями.¹⁶

Для госсектора важен и платформенный вектор. Минцифры описывает «ГосТех» как платформу для создания, перевода и развития государственных информационных систем; официальный сайт платформы позиционирует ее как облачное платформенное решение для федеральных и региональных органов власти.⁶ Но переход ГИС на платформенную модель не отменяет старые данные, интеграции, юридические следы и ведомственные процессы. Он делает их еще более важными: перед переносом нужно понять, что именно система исполняет.

3. Почему «переписать с нуля» часто опаснее, чем оставить старое

Одномоментная замена выглядит привлекательно на презентации: новая архитектура, чистая модель данных, современный интерфейс, российский стек, единая платформа, новые процессы. Но в реальности одномоментная замена сталкивается с четырьмя типовыми ударами.

Первый удар — данные. Старые записи могут иметь неодинаковые форматы, дубли, устаревшие идентификаторы, ручные исправления, исторические статусы и поля, значение которых знает только один отдел. При миграции данные могут «переехать», но начать неправильно работать в процессах.

Второй удар — интеграции. Старые системы редко существует изолированно. Оно связано с бухгалтерией, СЭД, система управления клиентскими отношениями, WMS, порталом, система бизнес-аналитики, межведомственными обменами, платежными контурами, сервисами уведомлений, шлюзами и ручными Excel-маршрутами. При разрыве интеграции организация обнаруживает, что остановилась не «старая система», а закупка, отчетность, выдача услуги или производственный процесс.

Третий удар — приемка. Пользователи принимают не архитектуру, а воспроизводимость реального результата. Если новая система не выдает привычный отчет, не находит старый документ, не поддерживает исключение или меняет маршрут согласования, формальная готовность проекта не превращается в эксплуатационную готовность.

Четвертый удар — операционная устойчивость. Международный пример TSB Bank показателен: в 2018 году банк провел крупную миграцию ИТ-платформы, после чего возникли технические сбои, затронувшие филиалы, онлайн- и мобильный банкинг; британские регуляторы впоследствии оштрафовали банк на £48,65 млн за недостатки управления операционными рисками и ИТ-программой.¹⁰

Этот пример не про банковскую специфику. Он про управленческий принцип: если система критична, модернизация должна быть проектом операционной устойчивости, а не только разработки.

Переписать код проще, чем восстановить доверие пользователей после остановки критического процесса.

4. Карта источников фактической спецификации

Старые системы как исполняемое ТЗ нужно читать не из одного источника. Код покажет часть логики, база — часть данных, отчеты — управленческие формулы, формы — пользовательские сценарии, обращения — реальные боли, логи — фактическое использование.

Ключевой принцип: ни один источник не является абсолютной истиной. Код может отражать старый костыль. Регламент может быть устаревшим. Пользователь может помнить только свой участок. Отчет может скрывать ручную корректировку. Поэтому фактическую спецификацию нужно строить как сводную модель с уровнем доверия к каждому правилу.

5. Большие языковые модели в разборе старого ИТ-контура: ускоритель, но не автопилот

Большие языковые модели полезны именно там, где старый ИТ-контур создает информационную перегрузку. Они могут быстро читать фрагменты старого кода, запросы к базам данных, процедуры, XML/JSON-конфигурации, инструкции, обращения, схемы БД и фрагменты логов. В правильном контуре Большая языковая модель помогает не «переписать систему», а ускорить восстановление знания о ней.

Практические сценарии: объяснение кода и хранимых процедур на языке бизнес-правил; поиск похожих запросов к базам данных и дублирующих отчетов; генерация первичных карт зависимостей; перевод старых форм в словарь полей; классификация обращений пользователей; подготовка тест-кейсов на основе фактического поведения; выявление неиспользуемых или редко используемых функций; сопоставление регламента, инструкции и реального сценария.

Но большие языковые модели нельзя превращать в единственного источника решений. OWASP относит к рискам приложений на базе больших языковых моделей внедрение вредоносных инструкций в запрос, небезопасную обработку выхода, раскрытие чувствительной информации и чрезмерное доверие к результатам модели.¹² рамка NIST по управлению рисками ИИ и профиль для генеративного ИИ также подчеркивают необходимость управления надежностью, безопасностью, оценкой и рисками ИИ-систем.¹³

Для старого ИТ-контура это означает несколько правил. Нельзя отправлять чувствительные данные и код во внешний контур без правовой, ИБ- и архитектурной проверки. Нельзя принимать сгенерированное бизнес-правило без подтверждения владельцем процесса. Нельзя переносить предложенный моделью код без тестов, ревью и контроля безопасности. Нельзя считать текстовое описание поведения заменой исполняемого теста.

Большая языковая модель особенно сильна как инструмент первичного анализа. Но финальное решение должны принимать системный аналитик, архитектор, эксперт предметной области, владелец данных и ИБ. Для разработки и модернизации безопасный жизненный цикл также должен включать практики защищенной разработки; NIST SSDF прямо описывает необходимость встраивать практики защищенной разработки в жизненном цикле ПО.¹⁴

Большая языковая модель ускоряет чтение старого ИТ-контура, но ответственность за смысл, безопасность и приемку остается у людей.

6. Постепенный перенос функций на новую платформу: вытеснять, а не взрывать

Лучший путь модернизации — постепенное вытеснение старой системы. Этот подход близок к известному паттерну постепенного вытеснения старой системы: новая система создается вокруг старой и постепенно забирает на себя функции, снижая риск одномоментного перехода. Martin Fowler подчеркивает, что такой подход не делает модернизацию легкой, но позволяет инвестициям и результатам появляться постепенно и видимо, а главная причина выбирать его вместо резкого переписывания и переключения — снижение риска.¹¹

Эта модель особенно важна для госсектора и крупного бизнеса. Ведомство не может остановить прием заявлений. Завод не может остановить учет производства. Банк не может остановить платежный контур. Ретейл не может остановить склад. Госкорпорация не может потерять цепочку юридически значимых документов.

7. Методология: 12 шагов восстановления контроля

1. Инвентаризация систем. Составить реестр старых ИТ-систем: назначение, владельцы, подрядчики, стек, версии, пользователи, данные, интеграции, критичность, стоимость сопровождения, регуляторные ограничения.
2. Классификация модулей по критичности. Разделить функции на критичные, важные, вспомогательные и кандидаты на отключение. Критичность определяется не мнением ИТ, а последствиями для процесса, отчетности, безопасности и обязательств.
3. Карта данных. Описать таблицы, справочники, мастер-данные, исторические данные, идентификаторы, дубли, владельцев, качество, требования хранения и миграционные ограничения.
4. Карта ролей и прав. Собрать фактическую матрицу доступа: кто что видит, согласует, изменяет, выгружает, подписывает, администрирует. Отдельно выделить сверхправа и неформальные делегирования.
5. Карта интеграций. Описать все обмены: программные интерфейсы, файлы, очереди, СМЭВ/межведомственные контуры, ЭДО, система бизнес-аналитики, бухгалтерию, внешние сервисы, расписания, форматы и владельцев.
6. Карта отчетов. Определить, какие отчеты используются для управления, регуляторной отчетности, внутреннего контроля, финансового закрытия, производственного планирования и приемки.
7. Выявление фактических бизнес-правил. Извлечь правила из кода, язык запросов к базам данных, процедур, форм, инструкций, обращений, логов и интервью. Каждому правилу присвоить статус: подтверждено, требует проверки, устарело, технический костыль.
8. Определение модулей для первоочередного переноса. Начинать не с самого сложного ядра, а с участка, где есть бизнес-эффект, измеримость, понятная приемка и низкий риск остановки.
9. Создание метаплатформенного ядра. Сформировать общие компоненты: управление пользователями, роли, справочники, журналирование, интеграционный слой, программные интерфейсы, модель данных, аудит, мониторинг, большие языковые модели и контур поиска по проверенным источникам перед ответом модели для анализа и документации.
10. Параллельная эксплуатация. Запустить новый участок рядом со старым. Пользователи работают в новом контуре, но результаты сверяются со старым источником.
11. Сверка данных. Использовать сверочные отчеты: количество записей, суммы, статусы, контрольные документы, временные интервалы, выборки по пользователям и исключениям.
12. Постепенное отключение старого контура. Отключать не систему целиком, а конкретные функции. Для каждого отключения нужен акт готовности: данные, роли, интеграции, отчеты, архив, ИБ, эксплуатация, поддержка, обучение.

8. Данные: то, что нельзя «переписать»

В проектах по работе с наследованными системами руководители часто переоценивают роль интерфейса и недооценивают данные. Но именно данные определяют, пройдет ли приемка, сохранится ли управляемость и не возникнут ли юридические последствия.

Исторические данные. Их не всегда нужно переносить в активный контур целиком. Часто правильнее разделить: оперативные данные — в новую систему, исторические — в архивный доступ с поиском, аудитом и доказуемой неизменностью.

Идентификаторы. Старые ID, номера документов, табельные номера, коды контрагентов и внутренние ключи могут быть связаны с отчетами, актами, интеграциями и юридическими документами. Если идентификаторы меняются, нужна таблица соответствия, правила ссылочной целостности и процедура сверки.

Дедупликация. Дубли нельзя удалять механически. Нужно определить владельца мастер-данных, правило выживания записи, обработку конфликтов и последствия для истории операций.

Мастер-данные. управление мастер-данными — это не только ИТ-система. Это управленческая модель: кто владеет справочником, кто утверждает изменения, кто отвечает за качество и кто имеет право исправлять ошибку.

Миграционные сценарии. Для критичных систем обычно нужны несколько прогонов: пробная миграция, нагрузочный прогон, миграция контрольного периода, параллельная сверка, план отката.

Сверочные отчеты. Приемка данных должна быть числовой: количество записей, суммы, статусы, контрольные даты, расхождения, дубли, невалидные ссылки, документы без владельца, операции без основания.

Аудит. Нужно сохранить, кто и когда создал, изменил, согласовал, подписал или отменил запись. Особенно если данные связаны с персональными данными, закупками, финансовым учетом, услугами, кадровыми решениями или производственной безопасностью.

Архивный доступ. Вывод старой системы из эксплуатации не означает потерю доступа к истории. Нужен архив только для чтения, понятная модель прав, журнал обращений и процедура восстановления доказательств.

Юридическая значимость. Акты, договоры, решения, электронные подписи, уведомления, статусы и сроки хранения требуют проверки с юристами и архивистами. В сфере персональных данных нужно учитывать обязанности оператора, включая уведомления Роскомнадзора о начале обработки, а при инцидентах — сроки уведомления 24 и 72 часа, указанные на портале персональных данных.¹⁵

Данные мигрируют не в таблицы. Они мигрируют в ответственность, отчетность и доказуемость.

9. Метрики успеха: как понять, что модернизация работает

Модернизация старых систем должна оцениваться не количеством переписанных строк кода, а управленческими показателями.

10. Риски и ограничения: зрелая позиция вместо технооптимизма

Заключение

В цифровой трансформации старый ИТ-контур нужно рассматривать не как мусор, а как фактическую память организации. Старые системы неудобны, дороги и рискованны, но они годами исполняли реальные процессы. В них накоплены данные, роли, исключения, отчеты, интеграции, статусы, юридические следы и пользовательские сценарии, которые нельзя восстановить одной проектной сессией.

Главная управленческая ошибка — противопоставлять «старое» и «новое» слишком грубо. Старое не должно бесконечно жить только потому, что его боятся трогать. Но новое не должно внедряться так, будто история организации начинается с даты запуска проекта. Между этими крайностями находится зрелая архитектурная позиция: старый ИТ-контур нужно читать, измерять, документировать, проверять и постепенно вытеснять.

Большие языковые модели меняют экономику этой работы. Они позволяют быстрее разбирать код, запросы к базам данных, процедуры, инструкции, формы, отчеты, логи и обращения. Они могут помочь восстановить карту бизнес-правил, подготовить тесты, найти дубли и сформировать черновую документацию. Но они не отменяют ответственности. Модель не знает, какое правило юридически значимо, какой отчет является управленческим, какой статус связан с обязательством, а какой фрагмент кода — исторический костыль. Это знают люди: аналитики, архитекторы, владельцы процессов, ИБ, юристы, пользователи и руководители.

Правильная модернизация — это не переписывание старого кода. Это восстановление контроля над бизнес-архитектурой, данными и процессами. Код можно заменить. Интерфейс можно обновить. Платформу можно сменить. Но нельзя потерять фактическую логику работы организации. Поэтому лучший путь — не одномоментная замена, а постепенный перенос функций на новую платформу: обернуть, наблюдать, вынести данные, заменить модуль, сверить, отключить старый участок и повторить цикл.

Для бизнеса это способ снизить операционный риск и стоимость изменений. Для государства — способ развивать цифровые сервисы без потери доказуемости, преемственности и управляемости. Для ИТ-директора и директора по цифровой трансформации — способ перейти от режима «поддерживаем то, что боимся трогать» к режиму архитектурного контроля.

Старые системы — это не прошлое, которое мешает будущему. Это материал, из которого нужно аккуратно извлечь фактическое ТЗ для новой цифровой архитектуры.