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

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

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

Российское промышленное ПО для нефтегаза есть, однако есть «но» 

На сентябрь 2026 года в Едином реестре российских программ для ЭВМ находится более 32 тысяч записей. Сам по себе масштаб реестра показывает, что рынок предложения сформирован. Ещё один показатель — работа индустриальных центров компетенций. По данным РФРИТ и материалов ЦИПР 2026, в контуре ИЦК реализуется 175 особо значимых проектов; к середине 2026 года завершено не менее 120, а созданные решения использовали более 900 отечественных предприятий.

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

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

Почему закупка и внедрение дают разные показатели

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

«Закупка происходит за один квартал и попадает в отчёт как выполненное поручение. Внедрение занимает два-три года, не имеет красивой даты завершения и в отчёт не попадает вовсе. Когда с компании спрашивают долю российского ПО, она предъявляет закупленные лицензии, а не работающие процессы. Цифра растёт, производство работает по-старому», — подчёркивает Никита Малов, основатель и управляющий партнёр аналитической компании «ДОВОД».

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

«Это три очень разные величины, и расстояние между первой и третьей во многом и есть тот разрыв, о котором говорят в отрасли», — считает Никита Осокин, генеральный директор Центра цифровых решений «Цикл-ОН».

Показательно, что в обновлённом стратегическом направлении цифровой трансформации обрабатывающей промышленности Правительство установило на 2030 год ориентир именно по использованию российского ПО в системах, обеспечивающих основные производственные и управленческие процессы: не менее 80% предприятий отрасли, а для организаций с государственным участием свыше 50% — уровень использования 95%. 

Промышленное ПО внедряется не в чистую архитектуру

На нефтегазовом предприятии почти не бывает изолированной системы. ERP связана с бухгалтерией, закупками, складами, управлением ремонтами, производственным планированием и корпоративным хранилищем данных. MES получает задания сверху и фактические данные снизу. SCADA и АСУ ТП обмениваются сигналами с контроллерами и оборудованием разных поколений. Инженерные системы хранят модели, спецификации и библиотеки, созданные в прежних форматах. Замена одного компонента меняет поведение всей цепочки.

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

Шесть барьеров между продуктом и промышленной эксплуатацией

Накопленная бизнес-логика

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

Данные и качество переноса

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

Совместимость с оборудованием и соседними системами

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

Полная стоимость перехода

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

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

Команда внедрения

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

Читайте также: «Как нефтегаз конкурирует с ИТ-компаниями за одних и тех же специалистов».

Пользовательский переход

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

Документация и приёмка

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

«Дефицит бьёт по внедрению сильнее, чем по разработке. Продукт можно купить, команду внедрения купить нельзя — её собирают годами», — подмечает Никита Осокин.

Что требования к КИИ означают на практике

Указ Президента РФ № 166 установил с 1 января 2025 года запрет на использование иностранного ПО органами государственной власти и заказчиками на принадлежащих им значимых объектах критической информационной инфраструктуры, если иное не установлено федеральным законом. В апреле 2025 года формулировка была уточнена Указом № 214. С 1 сентября 2025 года вступили в силу поправки к закону № 187-ФЗ: для субъектов КИИ, которым принадлежат значимые объекты, закреплена обязанность использовать включённое в российский реестр ПО, а Правительство уполномочено устанавливать порядок и сроки перехода. Таким образом, регулирование стало шире первоначального указа, но по-прежнему относится к значимым объектам КИИ, а не ко всему программному обеспечению промышленной компании.

После изменений в закон о безопасности КИИ в 2025 году Правительство утвердило перечень типовых отраслевых объектов КИИ распоряжением № 360-р от 26 февраля 2026 года.

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

Из этого следуют три практических вывода:

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

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

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

Почему работающая старая система часто выигрывает бюджет

Замена ERP, PLM или производственного контура редко создаёт такой же прямой денежный поток, как модернизация оборудования. Буровая, линия или новый агрегат имеют понятную производственную отдачу. Миграция корпоративной системы прежде всего снижает вероятность будущего ущерба. Пока риск не переведён в деньги, проект выглядит дорогим и откладываемым.

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

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

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

Именно поэтому проект импортозамещения следует защищать как программу управления риском и улучшения процессов, а не как покупку аналога.

Рабочая модель внедрения отечественного ПО

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

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

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

Какие показатели показывают реальное импортозамещение

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

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

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

Что должно измениться на рынке

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

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

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

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