← Предыдущая статья

Покупка ПО вызывает приятное чувство завершенности.

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

Но корпоративные ИТ умеют подпортить торжественные минуты.

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

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

На вечерней пленарке АКПО-Конф 2026 этот вопрос не звучал впрямую, но четко угадывался. Фаза выбора и покупки российского ПО заканчивается. Дальше начинается более зрелая и очень кропотливая работа: интеграция, согласованная сборка решений, эксплуатация и обоснование экономического эффекта.

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

Факты

По итогам АКПО-Конф 2026

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

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

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

После этого разговор перешел к более общей проблеме. Компании уже многое купили. Часть решений лежит на полке, часть активно внедряется. После закупки всплывает вопрос, на который нельзя ответить одним закрывающим документом: способен ли продукт работать в крупном корпоративном контуре без «танцев с бубном» на каждом следующем шаге? Акцент смещается с самой покупки на проверку в реальной работе: обмен данными, безопасность, производительность, поддержка, привычные сценарии пользователей и возможность доработать продукт без превращения его в уникальную разработку под одного заказчика.

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

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

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

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

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

Что видно по российским реалиям

Через месяц после АКПО-Конф та же тема прозвучала уже в публичной повестке ЦИПР-2026. В открытых материалах форум описывал переход российской ИТ-отрасли от поиска замены ушедшим западным продуктам к внедрению собственных решений. В поручениях по итогам сессии отдельно появились актуализация ИТ-ландшафтов индустриальных центров компетенций и определение первоочередных задач до 2030 года (РБК Пресс-центр).

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

РФРИТ дает к этой рамке более предметные цифры. Из первоначально отобранных 170 инициатив индустриальных центров компетенций более двух третей выполнены, а их общая стоимость оценивается примерно в 84 млрд рублей. В том же материале отдельно названа задача продолжать внедрение российского ПО на объектах критически значимой инфраструктуры (РФРИТ).

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

Та же логика видна в истории с промышленной ИТ-витриной. На ЦИПР-2026 «Газпром нефть» с партнерами представила концепцию российской витрины приложений для промышленности на базе Национальной платформы промышленной автоматизации. По замыслу, предприятия смогут подбирать, скачивать и внедрять проверенные программные решения (НППА).

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

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

Покупка может закрыть закупочную потребность. Рабочую потребность закрывает внедрение.

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

Что подсказывает внешний SAP-фон

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

Поэтому внешний SAP-фон полезен не в качестве примера «как надо», а в качестве защиты от самообмана. DSAG Investment Report 2026 показывает, что компании становятся осторожнее и щепетильнее в SAP-инвестициях: бюджеты могут расти, но на каждое вложение все чаще требуют объяснения, какую отдачу оно принесет (DSAG Investment Report 2026).

Clean Core говорит о том же с архитектурной стороны. ERP-ландшафт должен оставаться управляемым: процессы, расширения, интеграции, данные и эксплуатация не должны превращаться в клубок исключений, который невозможно обновлять и сопровождать без пота и крови (SAP Clean Core).

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

Редакционное наблюдение

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

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

Поэтому вопрос «что купили?» слишком рано ставит точку.

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

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

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

Попытка объяснения

Возможно, путаница возникает потому, что закупку легко измерить.

У нее есть договор, поставщик, сумма, срок, закрывающий документ, строка в плане и понятный управленческий маркер: задача закрыта. Закупка достаточно линейна: здесь легко поставить дату, назначить ответственного и показать результат в отчете.

Внедрение устроено иначе. Оно зацикливается, разветвляется и распадается на десятки проверок. Работает ли сценарий? Дошел ли документ? Не потерялись ли данные? Не выросло ли время операции? Не появилось ли ручное дублирование? Не ушла ли нагрузка в соседнюю систему? Не начал ли бизнес вести параллельный учет «на всякий случай»?

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

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

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

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

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

Гипотеза

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

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

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

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

Пишите на y.nechitaylov@sappro.ru, в комментариях к соответствующим постам в сообществе в ВК или в комментариях под этим материалом на sappro.ru.

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

Автор

Юрий Нечитайлов, главный редактор SAP Professional Journal Россия