Цифровая трансформация ИТ: как избежать копирования систем

Промышленная цифровизация уперлась не в дефицит ИИ, а в архитектуру. На «Иннопроме» в Екатеринбурге эксперты обсуждали, почему импортозамещение и генеративный ИИ сами по себе не дают модернизации, если новые системы копируют старые западные контуры и тащат за собой устаревшие процессы. Для ИТ-команд и заказчиков SaaS/enterprise-решений это практический сигнал: оценивать надо не витрину продукта, а его способность менять технологическую логику.

Копия старой системы — не стратегия

По данным материала Рамблера, участники сессии на «Иннопроме» отдельно обозначили две проблемы: дублирование разработок и устаревшее наследие. Первая типична для рынка: разные команды делают однотипные продукты, расходуя бюджет на параллельные реализации. Вторая хуже: часть российских решений создается как прямая калька с западных систем, разработанных десятилетия назад.

Гендиректор «УльтимаТек» Павел Растопшин сформулировал позицию жестко: рынок импортозамещения и средства заказчиков должны работать на инновации, а не на копирование решений, чей технологический цикл завершен. В качестве примера он упомянул продукты уровня Siemens, которым около тридцати лет, и указал, что они не должны становиться ориентиром для будущего.

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

ИИ полезен только после ревизии процессов

В материале также приводится статистика, озвученная на ЦИПРе в докладе Михаила Мишустина: около 50% российских предприятий уже так или иначе используют технологии ИИ. Отдельно сказано, что внедрения генеративного и искусственного интеллекта в промышленности составили почти 364 млн долларов.

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

Показательный пример привел директор по ИТ ВСМПО-АВИСМА Артем Мерзликин: при внедрении новой ERP-системы бизнес запросил полторы тысячи отчетов, но реально востребованными оказались только тридцать. Это хороший тест на зрелость проекта. Если команда автоматизирует весь исторический мусор, она не трансформирует процесс. Она консервирует его в новой оболочке.

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

Что проверять перед внедрением

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

В качестве примеров источники называют российский программно-аппаратный комплекс РСУ Externum от РЕГЛАБ, описанный как аналог решений Honeywell, Emerson и Yokogawa, а также решение «Позитив Технолоджиз» для промышленной кибербезопасности, которое автоматически выстраивает сценарии устранения уязвимостей и сокращает время реакции с дней до часов. В других сообщениях по теме говорится, что южноуральские ИТ-компании представили разработки на «Иннопроме-2026», а ГК «СиСофт» показала проекты цифровой трансформации судостроения. Деталей в доступных фрагментах нет, поэтому выводы по этим кейсам делать рано.

Практический минимум для заказчика:

• требовать не только карту импортозамещения, но и описание новой архитектуры;
• проверять, какие процессы поставщик предлагает удалить, а не автоматизировать;
• фиксировать критичные знания по legacy-системам до миграции;
• оценивать ИИ-модули через риски, интеграции и сценарии отказа;
• не принимать «аналог западного продукта» как техническое преимущество без бенчмарка и спецификации.

Главный вывод сухой: цифровая трансформация начинается не с ИИ и не с реестра ПО. Она начинается с отказа копировать старую систему вместе с ее дефектами.