Это не про замену софта. Это про замену корабля в открытом море

Импортозамещение ПО в крупном бизнесе часто сравнивают с заменой двигателя самолёта в полёте. Сравнение неточное. Самолёт один. В enterprise у вас — флот. Десятки систем, тысячи интеграций, legacy, накопленный за 15–20 лет, разрозненные вендоры и ни одного полного black box-понимания того, что на чём держится.

Опыт 2022–2025 показал: компании, которые подошли к импортозамещению как к «проекту замены софта», потеряли в 2–5 раз больше запланированного. Те, кто воспринял это как enterprise-трансформацию на 3–5 лет, — контролируют ситуацию.

Эта статья — для второго типа компаний.

Executive Summary: 5 выводов, 3 риска, 1 рекомендация

Если у вас есть 2 минуты — прочитайте этот блок. Всё остальное — детали.

5 ключевых выводов:

Coexistence — единственная реалистичная модель. Big Bang не работает в enterprise. Миграция идёт годы, не месяцы. Заложите 3–5 лет.
Главная статья расходов — не лицензии, а интеграции. Стоимость переписывания связей между системами часто превышает стоимость самих систем. Integration bus, data migration, IAM — вот основные бюджеты.
Люди — более узкое место, чем технологии. Архитектора enterprise-миграции ищут 6-9 месяцев. Начинайте с команды, а не с выбора ПО.

Регуляторка по отраслям влияет неравномерно. Промышленность пока имеет больший люфт, чем банки или госсектор. Но это временно. Готовиться надо сейчас.
Некоторые системы трогать рано. BI, CAD/PLM, industrial SCADA — российские аналоги не достигли enterprise-зрелости. Замещайте OS, DB, IAM, почту — в первую очередь.

3 главных риска:

Недооценка стоимости. Реальный бюджет enterprise-миграции — в 2–5 раз выше первоначальных оценок. Основной драйвер — интеграции и двойные лицензии в период coexistence.

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

Деградация бизнеса в период миграции. Полгода coexistence — и операционная эффективность падает на 15–30%. Бизнес должен быть к этому готов.

Рекомендация: Начните с аудита ландшафта и формирования команды. Не с выбора ПО. Первые 6 месяцев должны уйти на application portfolio mapping, анализ зависимостей и найм ключевых ролей. Без этого выбор сценария — гадание.

Анатомия enterprise-ландшафта: что на самом деле нужно замещать

Прежде чем говорить о сценариях, важно понять структуру IT-ландшафта крупной компании. Слово «ERP» покрывает лишь верхушку.

Back-office системы (административный контур):

• ERP (SAP, Oracle, 1С)
• HR / HCM (SuccessFactors, Oracle HCM)
• Finance / Treasury (SAP FI, Oracle EPM)
• ECM / Document management (Documentum, Directum)
• BI / Analytics (Power BI, Tableau, Qlik)

Operational / Industrial системы (производственный контур, OT):

• MES / Manufacturing Execution (SAP ME, Siemens Simatic IT)
• SCADA (WinCC, ICONICS, MasterSCADA)
• PLM / CAD (Siemens Teamcenter, SolidWorks, NX, Compass)
• Process Historians (OSIsoft PI, Canary)
• WMS / Logistics (SAP EWM, Manhattan, Solvo)
• LIMS / Quality (LabWare, STARLIMS)

Инфраструктурный контур:

• Virtualization (VMware → zVirt / Arena)
• OS / Server (Windows Server → Astra Linux / RED OS / ALT)
• DB (Oracle / MSSQL → Postgres Pro / Arenadata)
• Identity / IAM (Active Directory → ALD Pro / Keycloak)
• Monitoring / Observability (Zabbix, Prometheus)
• Backup / DR (Veeam → Кибер Бэкап / Акронис)

Data & Integration контур:

• ESB / Integration Bus (SAP PI/PO, IBM ACE, WebMethods)
• Data Warehouse (Teradata, Greenplum, Vertica)
• Data Lake (Hadoop, Spark)
• API Gateway (Kong, Apigee, WSO2)

Ключевое различие: back-office можно замещать относительно последовательно. Industrial OT требует остановки производства или дорогостоящих параллельных контуров. Это разные миграции.

---

Нормативная база: что реально регулирует импортозамещение

Для топ-менеджмента ключевой драйвер — не «хотим своё», а «обязаны по закону». Вот актуальная регуляторка РФ на 2025–2026:

Нормативный акт	Что требует	Кого касается
Указ Президента № 166 (2022)	Запрет на закупку иностранного ПО для критической инфраструктуры без согласования	Все субъекты КИИ
187-ФЗ «О КИИ»	Переход на доверенные решения, импортозамещение в объектах КИИ	Банки, энергетика, промышленность, транспорт, связь
Приказы Минцифры, ФСТЭК	Требования к аппаратному/программному обеспечению на объектах КИИ	Операторы КИИ
Постановление ПП РФ № 1236	Запрет на допуск иностранного ПО при госзакупках	Госкомпании, бюджетники
Методические рекомендации Минцифры	План перехода на отечественное ПО	Госкомпании, субъекты КИИ
152-ФЗ «О персональных данных»	Хранение и обработка ПДн на серверах в РФ	Все компании

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

Три сценария: что изменилось за 2022–2025

Практика enterprise-миграций в РФ за последние 3 года показала, что из трёх классических сценариев реально работает только один.

Сценарий 1. Big Bang — полная замена

Суть: единовременный отказ от иностранного ПО и переход на российские аналоги.
Практика 2022–2025: почти нигде не сработал.
Даже «относительно простые» компании с 10–15 системами (CRM, ERP, AD, BI, ЭДО, WMS) имеют слишком плотную сеть связей. Big Bang без многомесячного паралича бизнеса — редкое исключение.
Где был применён успешно: малые и средние компании без сложных интеграций, стартапы на начальной стадии, «дочки» иностранных компаний при уходе материнской структуры.
Где применяется с риском: производственные холдинги, распределённые компании с филиальной структурой.

Сценарий 2. Coexistence — гибридный подход

Суть: поэтапная миграция. Критичные контуры (финансы, кадры, документооборот) — в первую очередь. Industrial / OT — по мере зрелости аналогов.
Практика 2022–2025: доминирующая модель в РФ.
Ключевые особенности:

• Период coexistence может длиться 2–4 года
• Двойные лицензии — закладывайте ×1,5–2 от текущего IT-бюджета на переходный период
• Самая сложная часть — не замена систем, а поддержание интеграций между старым и новым стеком
• Бесшовной миграции не бывает — бизнес должен быть готов к временному снижению эффективности

Критическое ограничение: требует сильного проектного офиса и архитектурного надзора. Без них гибрид превращается в хаос («частично на 1С, частично на SAP, непонятно где какие данные»).

Сценарий 3. Retain — осознанное отложенное решение

Суть: продление лицензий через параллельный импорт, использование open-source форков.

Когда оправданно:

• Системы не входят в КИИ, нет регуляторного дедлайна
• На рынке нет зрелого российского аналога (например, PLM/CAD в машиностроении)
• Время выигрывается для архитектурной подготовки — application portfolio rationalization, dependency mapping

Риски, которые растут экспоненциально:

• Без обновлений безопасности риски растут
• Уход специалистов по устаревшим системам
• Рост стоимости параллельного импорта (по данным 2024–2025 — +30–50% в год)
• Регуляторный риск: законодательство может стать жёстче быстрее, чем вы готовы

Архитектурная реальность: почему миграция — это не «купил новое и включил»

Enterprise-миграция ломается не на системах. Она ломается на связях. Перед миграцией критически важно:

• Полная инвентаризация: что у вас есть, кто владелец, какие версии, какие лицензии
• Построение dependency map: какие системы с какими обмениваются данными
• Оценка data lineage: какие данные критичны для бизнеса

Integration Bus / ESB. Самая частая архитектурная ловушка:
«Заменили SAP PI на российскую шину — а все 200+ integration flows пришлось переписывать, потому что форматы сообщений отличаются».
Стоимость миграции интеграционного слоя часто сопоставима с заменой самих бизнес-систем.
Data Migration. Перенос данных из старой системы в новую — не техническая, а бизнес-задача:

• Маппинг полей и форматов
• Дедупликация и очистка
• Исторические данные: переносить всё или только последние N лет?
• Cutover strategy: как обеспечить консистентность данных в момент переключения

IAM / Identity. В enterprise 5–10 тысяч сотрудников, десятки приложений. При смене AD на ALD Pro / Keycloak нужно обеспечить Zero Downtime для аутентификации и авторизации.
Monitoring / Observability. При переходе на новый стек старые мониторинги перестают работать. Без работающего observability вы слепнете в самый ответственный момент.

Кадровый кризис: настоящий bottleneck импортозамещения

В 2025–2026 главная проблема импортозамещения — не ПО, а люди.

Рынок перегрет по ключевым ролям (да ещё и AI-фильтры чаще ломают найм, чем помогают ему, но это тема отдельной статьи):

Роль	Дефицит	Средний срок закрытия вакансии
Архитектор enterprise-миграции	Критический	6-9 месяцев
DevOps / Platform engineer	Высокий	3-6 месяцев
DBA (Postgres Pro / Arenadata)	Высокий	3-6 месяцев
1С enterprise-архитектор	Высокий	4-8 месяцев
Linux-инженер (Astra / RED OS)	Средний	2-4 месяца
Migration lead / PM	Высокий	4-6 месяцев

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

Стратегии смягчения:

• Формирование команды за 6-12 месяцев до старта миграции с опережающим наймом
• Партнёрство с системными интеграторами с выделенными ресурсами
• Обучение существующей команды (hard skills: Linux, Postgres, Kubernetes за 3-6 месяцев)
• Использование аутсорсинга для непрофильных задач (инфраструктура, миграция данных, тестирование)

Что НЕ надо импортозамещать прямо сейчас

Сильный CTO отличается от среднего умением сказать «нет». Вот что я бы не трогал в первую очередь:

1. BI / Analytics. Power BI, Tableau не имеют прямых российских аналогов сопоставимого качества. Аналитика — это не про «что», а про «как». Временное решение: остаться на текущих лицензиях, готовить переход к open-source (Superset, Metabase) + Yandex Datalens.

2. PLM / CAD (машиностроение, авиапром). Замена Siemens Teamcenter / SolidWorks / CATIA — проект на 5+ лет. На рынке нет аналогов enterprise-уровня. Альтернатива: Compass 3D, но с ограничениями по сложным сборкам.

3. Core Industrial SCADA. Если SCADA завязана на программируемые контроллеры (Siemens, Beckhoff, WAGO) — замена потребует не только ПО, но и замены контроллеров. Это бюджет ×10 от изначального.

4. Core Banking / АБС. В банках полная замена core banking — не завершена нигде в РФ на 2025. Тактическое решение: не заменять, а строить новый слой поверх через microservices / API, замещая функциональность поэтапно.

Что замещать в первую очередь:

• OS / Virtualization (Windows Server → Astra Linux, VMware → zVirt / Arena)
• DB (Oracle / MSSQL → Postgres Pro)
• AD / IAM (пока Keycloak + ALD Pro)
• ECM / Doc Management (Directum / TESSA)
• Офисный пакет (Р7 / МойОфис)
• Почта (CommuniGate / VK WorkSpace)

Модель зрелости импортозамещения

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

Уровень 1. Хаотичное — «тушим пожары»

Как выглядит: решения принимаются ad-hoc под давлением — регулятор сказал «надо», лицензия кончилась, вендор ушёл. Миграции идут без плана, команда собирается на ходу, интеграции переписываются в аврале.
Риски: максимальные. Бюджет улетает в 3–5 раз. Бизнес-процессы деградируют.
Что делать: остановитесь. Проведите аудит. Сформируйте хотя бы минимальный проектный офис. Лучше год готовиться и сделать за 2 года, чем начать завтра и не закончить никогда.

Уровень 2. Управляемый coexistence — «есть план»

Как выглядит: утверждена стратегия на 3–5 лет. Есть program manager, утверждён бюджет с резервом. Миграции идут по road map, но архитектурный надзор слабый — интеграции переписываются ситуативно.
Риски: средние. Основной — «разрастание» стоимости через неучтённые интеграции и двойные лицензии.
Что делать: усиливать архитектурную функцию. Внедрить карту зависимостей и контроль происхождения данных. Назначить архитектора программы.

Уровень 3. Управляемая миграция — «есть governance»

Как выглядит: работает steering committee, KPI утверждены, критерии приёмки согласованы с бизнесом. Архитектурный надзор ведётся по каждому контуру. Двойные лицензии контролируются.
Риски: низкие. Отклонения — в пределах 10–15% от плана.
Что делать: масштабировать. Переходить к промышленному контуру (OT). Оптимизировать период coexistence.

Уровень 4. Трансформированная архитектура — «цель достигнута»

Как выглядит: российский стек работает. Интеграции стабильны. Процессы не деградировали, а улучшились.
Риски: минимальные.
Что делать: поддерживать. Пересматривать стек раз в год. Не допускать нового vendor lock-in.

Куда двигаться

Текущий уровень	Цель (1 год)	Цель (3 года)
Хаотичное	Управляемый coexistence	Управляемая миграция
Управляемый coexistence	Управляемая миграция	Трансформированная архитектура
Управляемая миграция	Трансформированная архитектура	—

Decision Framework: как выбрать сценарий

Матрица принятия решения для enterprise:

Критерий	Big Bang	Coexistence	Retain
Сложность ландшафта (количество интеграций)	<20	20–100	>100 или OT
Регуляторный дедлайн	<6 мес	6–24 мес	>24 мес или нет
Зрелость российских аналогов	Высокая	Средняя	Низкая
Доступность команды	Своя + интегратор	Интегратор	Формирование
IT-бюджет на миграцию (% от текущего)	30–50%	15–30%	5–10% (подготовка)
Рекомендация	Только для простых случаев	Основной сценарий	Тактическая пауза

Phased Roadmap: 3 этапа типовой enterprise-миграции

Этап 1 — Подготовка и Foundation

• Аудит ландшафта (application portfolio, dependency map, data lineage)
• Пилот: замена OS и virtualization на 20% парка
• Выбор вендоров для основных систем (ERP, DB, IAM)
• Формирование команды и партнёрств с интеграторами
• Миграция первой «лёгкой» системы (почта, документооборот)
• Бюджет: 10–15% общего бюджета миграции

Этап 2 — Массовая миграция back-office

• Замена ERP (пилот + rollout на первые бизнес-единицы)
• Замена DB (Postgres Pro → Oracle)
• Миграция IAM и инфраструктуры
• Запуск интеграционной шины
• Data migration основной массы исторических данных
• Бюджет: 40–50%

Этап 3 — Industrial / OT + масштабирование

• Пилот на одном заводе: MES / SCADA
• Rollout ERP на остальные бизнес-единицы
• Миграция BI и аналитики
• Cutover legacy-систем
• Закрытие периода coexistence
• Бюджет: 35–45%

Governance migration program: как не потерять управление

Без governance enterprise-миграция превращается в хаос. Минимальный набор:

Steering Committee:

• CEO (спонсор программы)
• CIO (архитектурный и операционный лидер)
• CFO (контроль бюджета)
• Представители бизнес-подразделений (acceptance)

Project Office:

• Program manager (один, senior)
• Migration leads по каждому контуру (ERP, infra, data, OT)
• QA / Testing lead
• Change management lead

KPI миграции:

• % завершённых миграций по плану
• Отклонение бюджета (целевое: <±15%)
• Время простоя при cutover (целевое: <4 часа)
• Количество инцидентов уровня P1 после миграции
• User adoption rate (целевое: >80% за 3 месяца)

Prerequisites для старта:

• Аудит ландшафта завершён
• Dependency map построена
• Data lineage оценена
• Бюджет утверждён с резервом 20–30%
• Ключевые люди наняты (или контракты с интеграторами подписаны)
• Пилотный проект определён
• Acceptance criteria согласованы с бизнесом

---

Резюме

Импортозамещение в enterprise — это не ИТ-проект. Это программа трансформации бизнеса на несколько лет.

Главные уроки 2022–2025:

• Coexistence — единственная реалистичная модель для крупного бизнеса
• Люди — более узкое горло, чем технологии. Начинайте с команды
• Регуляторика — основной драйвер, но она неравномерна по отраслям
• Интеграции и данные — самая дорогая и рискованная часть migration program
• Российские аналоги есть, но их maturity разная. Некоторые системы трогать рано