Скрытые сложности модернизации корпоративных ИТ-систем
При подготовке модернизации выясняется, насколько тесно старые приложения связаны с производственными, финансовыми и управленческими процессами и каких затрат потребует их замена.
По результатам исследования ИТ-дистрибьютора OCS, представленного на «Софт Форуме 2026» в конце сентября, у четверти крупных российских компаний технический долг затрагивает более половины инфраструктурного ПО. Чаще всего проблемы обнаруживаются в системах резервного копирования и аварийного восстановления (27%), операционных системах (23%), средствах управления и мониторинга (21%). При этом масштабное обновление инфраструктуры планируют лишь 11% опрошенных организаций, а 35% намерены ограничиться заменой отдельных платформ.
Такая осторожность объяснима. Масштабная модернизация затрагивает сразу несколько взаимосвязанных систем, а замена отдельных компонентов позволяет проводить работы постепенно и распределять расходы. Впрочем, границы такого проекта не всегда удается определить заранее. При обследовании обнаруживаются зависимости, которые не учитывались в первоначальном плане, и объем необходимых изменений увеличивается.
Система работает. Стоит ли ее трогать?
В одном из проектов замены иностранной CRM после детального обследования выяснилось, что воспроизведение существующей функциональности займет больше двух с половиной лет. Все эти годы компании пришлось бы поддерживать прежнюю систему и одновременно создавать новую. При этом дополнительных возможностей для бизнеса проект не предусматривал. От миграции отказались, а средства направили на устранение наиболее существенных ограничений действующего решения.
Совсем иначе закончилась история с корпоративной DWH/OLAP-платформой, пережившей три серьезных рефакторинга. За семь лет бизнес вырос примерно втрое, количество источников данных увеличилось в той же пропорции, а число отчетов и показателей — более чем вчетверо. Очередная переделка старой платформы требовала примерно тех же ресурсов, что и переход на новую. Компания выбрала замену.
За годы эксплуатации корпоративная система приобретает функциональность, которой не было в первоначальном проекте. Помимо документированных доработок появляются специальные правила обработки данных, нестандартные интеграции, локальные настройки. При обследовании приходится восстанавливать историю изменений, выяснять назначение отдельных функций и договариваться с владельцами процессов, какие из них действительно необходимы.
Иногда проще сохранить основную учетную систему, постепенно вынося новые функции в отдельные приложения. Такой вариант позволяет развивать пользовательские сервисы, не затрагивая устойчиво работающую платформу. В других случаях накопленные архитектурные ограничения делают очередной рефакторинг сопоставимым по трудоемкости с полноценной заменой.
Расчет, сделанный при принятии решения, со временем устаревает. Меняются расходы на сопровождение, требования безопасности, доступность специалистов и возможности интеграции. Поэтому отложенная модернизация нуждается в повторной оценке, особенно перед запуском новых проектов, которые будут зависеть от прежней инфраструктуры.
Наследство, о котором мало кто помнит
Еще в начале прошлого года IT-World приводил пример системы обслуживания техники на крупном оборонном предприятии. За годы эксплуатации она накопила такое количество доработок, что перенос на другую платформу практически исключен. Предприятию предстоит еще пять-шесть лет поддерживать существующее решение, после чего разрабатывать замену заново.
Проблема хорошо знакома организациям, много лет развивающим собственное ПО или глубоко адаптирующим тиражные продукты. Каждая новая функция могла появиться по вполне понятной причине. Где-то потребовалось срочно изменить технологический процесс, где-то — обеспечить особый порядок согласования документов, где-то — устранить ошибку без остановки эксплуатации. Далеко не все временные решения впоследствии пересматривались.
Так постепенно накапливается технический долг. При очередной модернизации обнаруживается, что привычная функциональность зависит от устаревших библиотек, собственных программных модулей и давно не поддерживаемых интерфейсов.
Есть еще человеческая сторона проблемы. Уходят специалисты, участвовавшие во внедрении, меняются подрядчики, документация отстает от фактического состояния системы. Иногда эксплуатационная команда знает, как восстановить работу после типового сбоя, но уже не располагает достаточными знаниями для серьезного изменения архитектуры.
Особенно дорого подобная зависимость обходится большим холдингам. После присоединения очередного предприятия головная компания получает собственные конфигурации 1С, локальных администраторов, уникальные доработки и правила учета. Приведение всего этого к единой системе встречает сопротивление подразделений, для которых существующая конфигурация давно стала привычным рабочим инструментом.
В одном из таких проектов команда сначала перенесла разрозненные базы 1С на централизованную инфраструктуру, сохранив действующие конфигурации. Централизация позволила организовать единое резервирование и сопровождение. Позднее часть подразделений согласилась перейти на типовые конфигурации. Сохранение привычного приложения на первом этапе помогло провести инфраструктурные изменения без одновременной перестройки всех бизнес-процессов.
Своевременность замены определяется и тем, насколько легко развивается действующая система. Так по сообщению «Группы Лента», например, прежняя ITSM-платформа OmniTracker постепенно теряла привлекательность для новых инициатив. После перехода на российское решение интерес к развитию сервисных процессов заметно вырос.
По сообщению компании, сегодня система обслуживает около 1500 площадок, обрабатывает более 55 тысяч обращений ежемесячно и содержит свыше 279 тысяч конфигурационных единиц. За год количество реализованных запросов на изменения увеличилось на 70%.
Сам по себе рост числа изменений еще не доказывает технического превосходства новой платформы. Но он показывает, насколько существенным для заказчика может оказаться восстановление возможности развивать процессы, которые на прежнем решении практически перестали меняться.
Производство не может обновляться по расписанию ИТ-службы
На промышленном предприятии программное обеспечение часто остается в эксплуатации столько же, сколько оборудование, для которого оно предназначено. Десятилетиями могут работать станок или технологическая линия. Вместе с ними сохраняются инженерные приложения, драйверы, операторские станции и старые версии операционных систем.
В таких условиях обновление Windows иногда требует проверки всей цепочки взаимодействия с оборудованием. Производитель станка мог предусмотреть работу только с определенной версией ОС. Документация на интерфейсы бывает неполной, исходные разработчики больше не оказывают поддержку, а замена инженерного компьютера требует дополнительных испытаний.
В июле 2026 года «Информзащита» сообщила, что с киберинцидентами, связанными с legacy Windows, в первом полугодии столкнулись 43% обследованных промышленных организаций против 35% годом ранее. Среди препятствий для обновления 54% респондентов назвали совместимость с оборудованием, 38% — стоимость модернизации, 35% — риск производственного простоя.
Сами обстоятельства хорошо известны производственным ИТ-службам. Устаревшая рабочая станция может сохраняться ради одного критичного приложения, а установка современных средств защиты иногда вступает в конфликт с драйверами или нарушает производительность технологического ПО.
При этом специалистам приходится обслуживать несколько площадок с разным оборудованием и программными комплексами. IT World недавно подробно разбирался в ситуации, когда предприятия используют разные системы управления, оборудование и локальные регламенты. Их полная унификация не всегда оправданна. Гораздо важнее иметь сведения о критичных активах, владельцах систем, границах ответственности и порядке восстановления при аварии.
Для информационной безопасности длительная эксплуатация неподдерживаемых систем создает дополнительные трудности. Уязвимости остаются неисправленными, штатные обновления недоступны, а привычные средства защиты не всегда совместимы с технологической средой. Приходится ограничивать сетевое взаимодействие, отдельно контролировать удаленные подключения подрядчиков и предусматривать восстановление старых рабочих станций вместе с их конфигурациями.
На практике подобные меры иногда позволяют годами сохранять эксплуатацию критичных компонентов. Но возможность восстановления требует проверки. Если оборудование вышло из строя, недостаточно иметь копию программного обеспечения — понадобится совместимая платформа, на которой оно сможет работать.
Непредвиденные расходы
При замене ERP, MES или PLM стоимость лицензий и базового внедрения далеко не всегда составляет основную часть проекта. Значительные средства уходят на восстановление накопленной бизнес-логики, перенос данных и адаптацию интеграций.
По оценке BusinessPad, в отдельных промышленных проектах расходы на переход к российским решениям увеличивались в три-четыре раза относительно первоначальных планов. Компания приводит диапазон от 40–50 млн до 150–200 млн рублей. Независимого подтверждения этих оценок и подробной методики расчетов пока нет.
В одном из описанных проектов машиностроительное предприятие с двумя тысячами сотрудников более двух лет переходило на отечественные ERP, PLM и MES. При миграции истории изменений изделий в спецификациях появились ошибки и дубли. По сообщению компании, объем брака и пересортицы увеличился на 8–15%.
Дополнительные трудности возникли при взаимодействии MES с контроллерами. Модуль диспетчеризации неверно передавал задания между сменами, некоторые операции дублировались или терялись. Часть программного обеспечения пришлось переписывать, а сотрудники вернулись к параллельному учету в Excel.
Даже при благополучном переносе данных остаются вопросы к работе новых компонентов в составе действующей инфраструктуры. Испытания отдельного продукта не гарантируют поведения всей системы под производственной нагрузкой. При смене версий меняются драйверы, интерфейсы, механизмы обработки транзакций. Комбинаций оборудования и программного обеспечения настолько много, что производители не способны проверить каждую.
Участники рынка обращают внимание на необходимость проверять конкретные сочетания продуктов, учитывать версии и заранее определять, кто отвечает за сопровождение совместной конфигурации.
Еще сложнее оценить стоимость изменений, если предприятие не располагает полным описанием интеграций. У одной системы может быть десяток документированных интерфейсов и несколько обменов, о которых помнят только сотрудники отдельных подразделений. Данные могут передаваться через промежуточные файлы, собственные скрипты или ручные операции.
Отдельные интеграционные зависимости выявляются уже при обследовании процессов. Подобные случаи подробно разбирались на круглом столе о взаимодействии корпоративных ИТ-систем.
Чем больше таких связей обнаруживается в ходе проекта, тем заметнее меняются сроки и стоимость перехода. Причем некоторые дополнительные расходы неизбежны даже при качественном первоначальном обследовании — поведение сложной системы под реальной нагрузкой удается воспроизвести далеко не полностью.
При замене одного компонента могут обнаружиться требования к устаревшим протоколам, специфическим форматам данных и механизмам резервирования, которые не учитывались при подготовке проекта. Эти скрытые зависимости увеличивают объем доработок и испытаний, а вместе с ним сроки и стоимость модернизации.
Критичное приложение, которого не было в плане
На одном из обсуждений IT-World участники вспомнили ситуацию, когда пилот импортозамещения прошел успешно, но при масштабировании обнаружилось критичное приложение на небольшой виртуальной машине удаленного филиала. Оно не входило в первоначальный план и оказалось несовместимо с выбранной архитектурой. Без него филиал не мог продолжать работу.
Этот случай хорошо показывает последствия неполной инвентаризации. Крупные системы находятся под постоянным вниманием ИТ-службы, а небольшие локальные приложения могут годами оставаться вне общего учета. При этом от них зависят реальные бизнес-операции.
Сложность усиливается, когда разные части инфраструктуры имеют собственные циклы обновления. Приложение уже заменили, а хранилище данных оставили прежним. Или обновили серверную платформу, сохранив старую систему управления производством. В подобных конфигурациях особенно важны ограничения сопряжения компонентов.
Похожие проблемы возникают и за пределами корпоративных ИТ. Российские городские системы видеонаблюдения создавались в разное время, с использованием оборудования и программного обеспечения нескольких производителей. При попытке объединить их обнаруживаются несовместимые форматы хранения, протоколы передачи данных и ограничения доступа. Дополнительные сложности связаны с тем, что за отдельные участки инфраструктуры отвечают разные подрядчики и операторы.
В результате действующие камеры и аналитические системы не всегда удаётся использовать совместно. Для поиска человека это означает потерю времени на получение и сопоставление записей.
В обоих случаях проблема связана с отсутствием полной картины действующей инфраструктуры. В филиале не учли критичное приложение, а в городских системах видеонаблюдения оборудование и программные комплексы годами развивались независимо друг от друга. Исправление таких ограничений требует дополнительных работ, которые могут не входить в первоначальный проект модернизации.
Испытания перед переключением
При миграции критичной системы задача усложняется необходимостью подтвердить корректность всех операций на новой технологической платформе. Особенно высоки требования к системам, обрабатывающим финансовые данные.
ЮMoney совместно с «ПрограмБанком» перевела АБС на Linux и PostgreSQL. Для проверки был развернут отдельный вычислительный контур, в котором новая система обрабатывала тот же поток входных данных, что и действующая платформа.
Команда сравнивала финансовые результаты, время выполнения операций и взаимодействие со связанными системами. После обнаружения расхождений вносили исправления и повторяли испытания. Переключение выполнили только после достижения соответствия финансовых показателей и приемлемого времени обработки.
По сообщению ЮMoney, финальный переход занял несколько часов и практически не повлиял на работу клиентов и бэк-офиса.
Методика параллельной обработки полезна именно возможностью сравнить результаты на одинаковых исходных данных. Но она требует отдельной инфраструктуры, подготовки сценариев испытаний и решения вопросов с внешними операциями, которые нельзя без последствий выполнить дважды.
Еще один пример — миграция АБС Газпромбанка на новую технологическую платформу с Postgres Pro Enterprise и ПАК «Скала^р». В проекте участвовала группа Rubytech. По опубликованным данным банка, перед переключением проводились нагрузочные испытания с использованием профиля реальной нагрузки и настройка компонентов. Финальный переход занял три часа.
Публичные сообщения об успешной миграции редко позволяют понять, сколько попыток потребовалось для достижения нужных результатов. Какие проблемы обнаружились при нагрузочных испытаниях, что пришлось изменить в конфигурации, какие сценарии восстановления предусмотрели на случай неудачного переключения? Именно такие подробности особенно полезны другим заказчикам.
После завершения миграции часть прежней инфраструктуры нередко продолжает работать. Старые приложения сохраняют ради отдельных функций, оборудование — из-за ограничений совместимости, а временные механизмы обмена данными остаются необходимыми для взаимодействия систем. Поддерживать приходится уже обновлённую платформу вместе с компонентами, которые не удалось заменить.
Поэтому при закрытии проекта имеет смысл оценивать не только работу нового решения, но и состояние оставшейся инфраструктуры. Сократилось ли количество зависимостей, упростилось ли сопровождение, появились ли возможности для дальнейших изменений? Иначе очередная модернизация может начаться с разбора тех же технических ограничений, которые не удалось устранить при предыдущей.
Опубликовано 21.10.2026
Практический алгоритм выглядит так: сначала выделить критичные бизнес‑процессы и зафиксировать целевые SLA (время простоя, RPO/RTO). Затем оценить, насколько текущая система им соответствует и насколько сложно будет обеспечить эти показатели дальше. Параллельно важно просчитать «стоимость бездействия»: сколько бизнес потеряет при сбое или невозможности масштабирования.
Наконец, нужно сопоставить это с профилем перехода: если вендор уходит с рынка, ИТ-продукт больше не сертифицируется или под него не хватает компетенций — срок замены стоит максимально сократить, даже если текущие затраты кажутся невысокими. Такой подход помогает отделить «живые» системы, которые еще имеют смысл поддерживать, от тех, где дальнейшая эксплуатация становится скрытым риском для бизнеса.