Возвращение поставщика корпоративного программного обеспечения кажется вопросом выбора бренда. На практике заказчик выбирает архитектуру зависимости на годы вперёд: форматы данных, интеграции, компетенции команды, правила обновления, лицензии и возможность продолжить работу при разрыве отношений. РБК Отрасли (RBC Industries) 8 июля 2025 года рассмотрел, насколько российский рынок готов к гипотетическому возвращению зарубежных ИТ-вендоров.

Исследование компании Юзергейт (UserGate), проведённое в апреле 2025 года, оценило вероятность частичного возвращения западных поставщиков информационной безопасности в диапазоне 3070%. Такой широкий коридор показывает не прогноз, а неопределённость условий: геополитику, санкции, экономический интерес, регулирование и готовность клиентов снова принять риск внешнего отключения.

За время отсутствия прежних лидеров рынок изменился. По оценке главного коммерческого директора Группы Астра (Astra Group) Николая Прянишникова (Nikolai Pryanishnikov), доля российского ПО в инфраструктурном сегменте превысила 50% и может достигнуть 90%, а отечественные аналоги закрывают 7080% потребностей. При этом зрелость распределена неравномерно: базы данных и отдельные корпоративные классы сильны, инженерные и аппаратно зависимые контуры сложнее.

Для России (Russia) конкурентный вопрос уже нельзя свести к происхождению лицензии. Важнее способность системы обеспечить непрерывность, совместимость и измеримую экономику владения. Хорошая политика не запирает заказчика у нового монополиста, а создаёт условия, при которых несколько поставщиков конкурируют качеством и сохраняют переносимость данных.

Доля рынка не равна зрелости экосистемы

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

Зрелость начинается с работоспособности под реальной нагрузкой. Система должна выдерживать объём транзакций, интегрироваться с оборудованием, восстанавливаться после сбоя и обновляться без длительной остановки. Кроме кода нужны документация, обучение, линия поддержки, партнёры внедрения и понятный жизненный цикл версии.

Генеральный директор СберТеха (SberTech) Максим Тятюшев (Maxim Tyatyshev) отметил, что в каждом классе Единого реестра российского ПО можно найти десять и более поставщиков. Численность создаёт выбор, но способна фрагментировать ресурсы. Десять несовместимых продуктов не образуют экосистему, если заказчик каждый раз строит уникальный переход.

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

Стоимость переключения стала главным конкурентным барьером

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

Руководитель ИТ-подразделения агентства Полилог (Polylog) Людмила Богатырёва (Lyudmila Bogatyreva) напомнила, что к моменту ухода иностранных брендов полноценной замены системам Автокад (AutoCAD) и САП (SAP) во многих контурах не существовало. Оборудование Сименс (Siemens) могло быть настроено на совместимость с Оракл (Oracle) или САП. Замена одного слоя требовала пересмотреть остальные.

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

Именно поэтому 67% крупных клиентов в исследовании МойОфис (MyOffice), о котором рассказал Алексей Дмитриев (Alexey Dmitriev), высказались против возврата к западным продуктам. Это не обязательно оценка абсолютного качества. После дорогой миграции повторное переключение должно дать выгоду, превышающую новую стоимость и риск.

Полная карта затрат на миграцию

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

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

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

Доверие превратилось в техническое требование

Генеральный директор Софтлайн (Softline) Владимир Лавров (Vladimir Lavrov) указал, что некоторые зарубежные поставщики не выполнили коммерческие обязательства и оставили клиентов без оплаченной поддержки. Директор по стратегическому развитию Планоплан (Planoplan) Антон Яковлев (Anton Yakovlev) добавил риск блокировки аккаунтов и баз данных без действенного правового механизма восстановления.

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

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

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

Регулирование меняет форму конкуренции

Для компаний с государственным участием и объектов критической информационной инфраструктуры использование иностранных решений ограничено. В информационной безопасности действуют сертификация Федеральной службы по техническому и экспортному контролю (Federal Service for Technical and Export Control), включая предоставление исходных кодов, лицензирование Федеральной службы безопасности (Federal Security Service) и отраслевые требования Банка России (Bank of Russia).

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

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

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

Совместимость важнее полного копирования функций

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

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

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

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

Сильные категории показывают модель развития

Эксперты назвали зрелыми российские системы управления базами данных, корпоративное ПО, облачную инфраструктуру, кибербезопасность и финансовые технологии. Среди участников упоминались 1С (1C), МойОфис, Р7-Офис (R7-Office), Селектел (Selectel), Яндекс Облако (Yandex Cloud), Облако.ру (Cloud.ru), Позитив Текнолоджиз (Positive Technologies), Касперский (Kaspersky) и Ростелеком-Солар (Rostelecom Solar).

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

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

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

Остаточная зависимость переместилась в аппаратный слой

Коммерческий директор группы Солар (Solar Group) Николай Сивак (Nikolai Sivak) отметил, что микроэлектроника и чипы остаются импортными, несмотря на перспективные российские разработки. Программная независимость ограничена, если вычислительная платформа, сетевой контроллер или производственное оборудование требует недоступного компонента.

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

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

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

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

Возвращение конкурентов может улучшить продукт

Заместитель генерального директора Корус Консалтинг (Korus Consulting) Сергей Карпуничев (Sergey Karpunichev) назвал среди плюсов возвращения иностранных производителей здоровую конкуренцию, повышение качества и связь с глобальными тенденциями. Изоляция защищает долю, но способна сохранять слабые функции и высокий уровень затрат.

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

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

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

Китайские и индийские поставщики меняют географию риска

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

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

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

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

Заказчик должен управлять портфелем, а не списком лицензий

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

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

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

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

Практический тест технологической независимости

  1. Назвать процессы, которые остановятся вместе с системой.
  2. Проверить владение данными, формат экспорта и независимый резерв.
  3. Картировать интеграции, оборудование и редкие компетенции.
  4. Измерить производительность, восстановление и качество обновлений.
  5. Рассчитать владение и выход на многолетнем горизонте.
  6. Проверить альтернативу в ограниченном реальном контуре.
  7. Зафиксировать договорные обязанности при прекращении сервиса.

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

Главный вывод: конкуренция переместилась из лицензии в архитектуру

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

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

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

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

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