Отчёт о круглом столе по импортозамещению ИТ

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

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

Что обсуждают на круглом столе по импортозамещению ИТ

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

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

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

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

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

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

Почему тема импортозамещения ИТ стала стратегической

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

Импортозамещение ИТ влияет на три уровня управления

1. Операционный уровень

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

2. Архитектурный уровень

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

3. Стратегический уровень

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

Почему старый подход больше не работает

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

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

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

Ключевые выводы круглого стола по импортозамещению ИТ

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

1. Замещать нужно не всё подряд, а по критичности

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

Правильнее идти от картографии рисков. Это значит: сначала понять, отказ каких систем приведёт к остановке бизнеса, и только потом планировать последовательность миграции.

Что следует выделить в первую очередь

• системы, влияющие на непрерывность операций — всё, что напрямую связано с производством, логистикой, отгрузкой;
• ядро ERP, MES, CRM, документооборот — системы, через которые проходят основные бизнес-процессы;
• инфраструктурный слой: виртуализация, СУБД, операционные системы, резервное копирование — то, на чём держится всё остальное;
• каналы обмена данными с партнёрами и государственными системами — здесь риски не только технологические, но и регуляторные;
• средства кибербезопасности и мониторинга — потому что в переходный период компания особенно уязвима.

2. Импортозамещение ИТ — это проект на уровне портфеля, а не одной службы

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

Нужна совместная модель управления, где у каждого своя зона ответственности:

• CEO задаёт рамку по допустимому риску и срокам — без этого любое обсуждение тонет в деталях;
• CFO контролирует экономику и совокупную стоимость владения (TCO), а не только цену лицензий;
• CIO отвечает за архитектуру и исполнение — это его прямая зона;
• CDO/CTO связывают изменения с развитием цифровых продуктов и платформ, чтобы импортозамещение не тормозило трансформацию;
• служба безопасности оценивает технологические и регуляторные риски — особенно в части работы с персональными данными и критической инфраструктурой;
• бизнес-владельцы процессов подтверждают, что система действительно нужна, и участвуют в приёмочных испытаниях.

На одном из круглых столов прозвучала точная формулировка: «Если на проекте по импортозамещению нет конфликтов между CIO и бизнесом — значит, бизнес ещё не включился».

3. Самое сложное — не лицензия, а экосистема

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

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

4. Миграция без целевой архитектуры почти всегда дороже

Если компания просто меняет продукт на продукт, не пересматривая архитектуру, она получает predictable problems: рост ручных операций на стыках систем; дублирование контуров, когда старый и новый работают параллельно; хаос в интеграциях, потому что старые интерфейсы не стыкуются с новыми; временные костыли, которые остаются на годы.

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

Как оценивать готовность компании к импортозамещению ИТ

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

Таблица: быстрая диагностика готовности

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

На что обращают внимание CIO и архитекторы

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

Ключевые параметры, которые стоит проверить

Совместимость

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

Производительность

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

Поддерживаемость

Вопрос не только в том, как система работает, но и в том, кто и как её будет сопровождать. Есть ли SLA с понятными метриками? Насколько быстро выходят исправления критических ошибок? Как устроена документация — можно ли по ней обучить новую команду? Доступны ли специалисты на рынке или вы будете зависеть от единственного партнёра? Это те вопросы, которые определяют совокупную стоимость владения на годы вперёд.

Масштабируемость

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

Типовые ошибки при импортозамещении ИТ

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

Ошибка 1. Замена ради отчётности

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

Ошибка 2. Отсутствие приоритизации

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

Ошибка 3. Игнорирование пользователей

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

Ошибка 4. Недооценка интеграций

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

Ошибка 5. Экономия на тестировании

Если тестировать только «чтобы запустилось», а не «чтобы работало под нагрузкой и в аварийных сценариях», проблемы появятся уже в продуктиве. Чем опасно: инциденты на реальных данных, простой бизнес-процессов, потеря доверия к проекту со стороны руководства.

Практический подход: как строить план импортозамещения ИТ

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

Шаг 1. Инвентаризация ИТ-ландшафта

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

Шаг 2. Сегментация по приоритету

Разделите всё на три группы: критично сейчас (системы, отказ которых остановит бизнес в ближайшие месяцы), критично в горизонте 12–18 месяцев (системы, которые пока работают, но риски нарастают), можно заменить позже (периферийные решения с низким уровнем риска). Эта сегментация определяет не только последовательность, но и распределение бюджета.

Шаг 3. Анализ альтернатив

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

Шаг 4. Построение целевой архитектуры

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

Шаг 5. Пилоты и поэтапный переход

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

Шаг 6. Контроль эффектов

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

Какие вопросы стоит задать поставщику

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

Чек-лист вопросов

• Сколько внедрений есть в компаниях нашего масштаба и нашей отрасли? Можно ли пообщаться с кем-то из них?
• Какие ограничения по нагрузке — и что происходит при их превышении?
• Как решаются обновления: автоматически, вручную, с простоем или без?
• Какой стек нужен для интеграций — и есть ли документированные API?
• Кто сопровождает продукт после внедрения: вы сами или партнёры? Какая у них экспертиза?
• Есть ли дорожная карта развития на ближайшие два-три года?
• Что происходит, если нужен срочный багфикс в продуктиве? Регламент, сроки, ответственность?
• Как выглядит переход с зарубежного аналога: есть ли инструменты миграции данных, методология, опыт?
• Какие риски чаще всего возникают на проектах — и как вы с ними работаете?
• Какие ресурсы нужны со стороны заказчика: люди, компетенции, инфраструктура?

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

Импортозамещение ИТ и технологические риски

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

Основные риски

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

Как снизить риски

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

Роль CEO, CDO и совета директоров

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

CEO

Определяет, какой уровень риска допустим для бизнеса и сколько времени компания готова жить в переходном состоянии. Это не техническое решение — это стратегический выбор. Если CEO говорит: «Делайте, но чтобы бизнес не заметил», — это значит, что проект обречён на компромиссы, которые рано или поздно проявятся в сбоях.

CDO

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

Совет директоров

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

Что должно быть в хорошем отчёте по круглом столу

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

В отчёте стоит отразить:

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

Что полезно добавить

• таблицу приоритетов — что меняем в первую очередь, что во вторую;
• матрицу рисков — вероятность и влияние;
• список систем-кандидатов на замену — с обоснованием;
• дорожную карту на 6–12 месяцев — с контрольными точками;
• блок «что делать прямо сейчас» — три-пять действий, которые можно начать завтра.

FAQ

Что такое импортозамещение ИТ простыми словами?

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

Почему нельзя просто заменить одну систему на другую?

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

С чего начать импортозамещение ИТ?

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

Кто должен отвечать за проект?

Не только ИТ-директор. Нужна совместная ответственность CIO, бизнеса, финансов и службы безопасности. Если проект висит на одном человеке, он становится уязвимым — и для компании, и для самого руководителя.

Как понять, что проект идёт правильно?

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

Итог

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

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