После импортозамещения: зачем российскому ТЭК новая цифровая эффективность

Импортозамещение переходит в фазу зрелости

По прозвучавшим на сессии оценкам, примерно в 80–90% классов ИТ-решений уже существуют российские варианты. Выбор есть практически во всех основных классах программного обеспечения и оборудования. Однако наличие отечественных продуктов ещё не означает, что задача замещения решена.

На практике остаются вопросы стоимости, поддержки, удобства использования, функциональности и совместимости. В инфраструктуре сохраняются отдельные позиции, по которым сроки замещения могут доходить до 2028–2029 годов. На некоторых объектах атомной отрасли продолжают использоваться импортные решения для АСУ ТП.

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

В атомной отрасли переход на отечественные решения одновременно используется как возможность изменить архитектуру корпоративных систем. Для общекорпоративных функций формируются единые шаблоны, тогда как производственные системы — PLM, MES и другие — требуют большей гибкости и учёта специфики конкретного бизнеса.

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

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

Проблема касается не только программных продуктов. В отдельных инженерных областях российские решения существуют, но пока могут уступать зарубежным аналогам по отдельным модулям и расчётным функциям. В качестве примера приводились САПР, где российские продукты представлены достаточно широко, но некоторые специализированные расчёты, в том числе связанные с тепловыми нагрузками, ещё требуют дальнейшего развития.

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

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

Цифровизация перестаёт быть отдельным классом проектов

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

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

В крупных компаниях также размывается граница между автоматизацией и цифровизацией. В качестве одного из примеров приводилась практика использования KPI по уровню цифровизации для руководителей. При этом значение самого показателя постепенно снижается: цифровые инструменты становятся привычной частью деятельности, а на первый план выходят эффективность и производительность.

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

На производственном уровне подход остаётся более гибким. Здесь невозможно полностью отказаться от отраслевой специфики, поэтому такие системы, как PLM и MES, должны учитывать особенности конкретных производственных процессов.

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

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

Экономический эффект становится главным фильтром

Изменение подходов особенно заметно в инвестиционном планировании. В одном из приведённых на сессии примеров портфель цифровой трансформации включает 427 проектов с горизонтом пять лет. При этом детально и с высокой степенью определённости сегодня можно планировать примерно на год. Более длинный горизонт требует регулярного пересмотра.

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

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

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

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

«Купить или сделать» больше не является простым выбором

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

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

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

Похожая модель применяется и в области промышленной автоматизации. При необходимости расширения компетенций по SCADA-системам можно привлекать вендора как партнёра, одновременно формируя собственную экспертизу и выполняя значительную часть внедрений самостоятельно.

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

Искусственный интеллект выходит из экспериментального контура

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

При этом постепенно смещается акцент с административных задач на производственные. ИИ рассматривается как инструмент сокращения производственных циклов и увеличения выпуска, а не только как способ автоматизировать работу офисных подразделений.

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

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

Именно поэтому следующий этап развития ИИ связан не столько с приобретением более мощной модели, сколько с подготовкой собственных данных и знаний.

Суверенность ИИ — это не только отечественная модель

Вопрос технологического суверенитета в отношении ИИ имеет ещё одно измерение: где работает модель и какие данные через неё проходят. Крупным организациям не обязательно самостоятельно создавать все языковые модели. Однако специализированные модели, предназначенные, например, для предиктивной аналитики или повышения качества производства, целесообразно размещать внутри контролируемого контура.

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

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

В качестве исторической аналогии приводилась партия IBM Deep Blue с Гарри Каспаровым. При ограниченных вычислительных ресурсах шахматисты помогали системе выбирать направления поиска.
Обе истории позволяют поставить один и тот же практический вопрос: если результат создаётся с помощью внешней модели, где находятся знания, использованные для его получения, какие данные проходят через систему и кто контролирует саму модель.

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

ИИ ускоряет разработку, но не отменяет инженера

Отдельно обсуждалось применение ИИ при программировании. Практические эксперименты показывают, что качество генерируемого кода может существенно различаться. В одном из сценариев весь результат требовал перепроверки. В другом около 90% кода было признано достаточно качественным, а примерно 10% содержало ошибки.

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

Поэтому даже существенное ускорение программирования не означает пропорционального снижения стоимости проекта. Результат также сильно зависит от качества постановки задачи. Необходимы архитектура, корректно определённые роли, ограничения, среда выполнения и данные.

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

При этом ИИ создаёт возможности для автоматизации процессов, которые раньше было экономически нецелесообразно автоматизировать. Если процесс часто меняется, традиционная разработка может стоить дороже самого эффекта. Поэтому в ряде случаев было проще продолжать использовать Excel, даже если в нём постепенно накапливались сложные макросы.

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

Ещё один уровень — персональная производительность. ИИ уже используется для подготовки документов, презентаций и другой рутинной работы. Однако и здесь качество результата определяется тем, насколько правильно поставлена задача и насколько полные данные получает модель.

В критических системах скорость внедрения ограничивает цена ошибки

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

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

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

Вычислительная инфраструктура становится отдельным ограничением

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

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

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

Потенциал ИИ определяется не количеством моделей

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

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

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

Главная ошибка — начинать с технологии

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

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

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

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

От замены — к результату

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

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

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

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

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

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

_________________________
Аналитический материал подготовлен на основе содержания докладов конференции с использованием инструментов искусственного интеллекта. Все выводы основаны исключительно на материалах представленных выступлений.
© СТА-ПРЕСС, 2026