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

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

Импортозамещение в финансах затрагивает не только рабочие места сотрудников, но и глубоко интегрированные платформы: автоматизированные банковские системы (АБС), процессинг, дистанционное банковское обслуживание, CRM уровня Siebel, а также инфраструктурные и прикладные решения, исторически завязанные на западных вендорах.

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

ИТ-компании переходят на отечественные фреймворки для разработки, платформы управления данными, серверные ОС и решения для DevOps и CI/CD. Особая сложность возникает там, где требуется высокая производительность и безотказность — например, в высоконагруженных финтех-системах или масштабных облачных сервисах.

Отдельные банки публично сообщают о выборе российских технологических стеков в качестве основы инфраструктуры. Например, Россельхозбанк в рамках программы импортозамещения протестировал альтернативы и выбрал Astra Linux Special Edition в качестве защищённой платформы для автоматизированных рабочих мест, опираясь на требования отказоустойчивости, безопасность и доступ к поддержке и кастомизации со стороны вендора. Такой сценарий типичен: переход сопровождается пилотами, проверкой совместимости и постепенным тиражированием.

Смена стека автоматически поднимает спрос на специалистов, знакомых с российскими ОС (Astra Linux, РЕД ОС), отечественными СУБД (PostgreSQL/Postgres Pro, ClickHouse, Greenplum‑совместимые решения), отечественными офисными и корпоративными платформами (1С‑экосистема, МойОфис, локальные CRM/ERP). Компании ищут инженеров, которые способны не просто администрировать новые продукты, но и планировать миграцию с западных решений, оптимизировать производительность и закрывать вопросы регуляторной и кибербезопасности.

Банкам нужны инженеры, которые способны вести миграцию на отечественные ОС (Astra Linux, РЕД ОС), СУБД (PostgreSQL/Postgres Pro, ClickHouse) и решения для безопасной инфраструктуры.

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

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

Несмотря на программы подготовки кадров и переквалификации, дефицит специалистов среднего и старшего уровня остаётся существенным; время поиска инженеров с нужным стеком выросло, а компании конкурируют за опытных Linux‑разработчиков, DevOps‑инженеров, безопасников, архитекторов и разработчиков отечественных систем. На рынке сохраняется нехватка компетенций в направлениях ИБ, ИИ/ML и интеграции импортонезависимых решений; дефицит усиливается тем, что крупные игроки перетягивают специалистов у средних компаний.

Банковские ИТ‑ландшафты переживают одновременную миграцию и усиление требований к киберустойчивости. Руководители крупнейших банков в 2025 году подчёркивают необходимость реальных (а не формальных) проверок безопасности при переходе на новые платформы; регуляторно значимые контуры требуют отечественного ПО, сертифицированных средств защиты и тестирования производительности на российском железе. Параллельно эксперты отмечают общий рост спроса на специалистов по ИБ, включая архитекторов, пентестеров и инженеров защиты облачных и контейнерных сред.

Массовая миграция — удобный момент, чтобы пересмотреть архитектуру. Компании переходят от монолитов к микросервисам, активно используют контейнеризацию и Kubernetes‑совместимые платформы (включая адаптированные под требования регуляторов отечественные сборки). Параллельно формируется запрос на platform engineering — внутренние платформы для разработчиков, ускоряющие доставку изменений, что особенно важно при переработке больших регуляторно значимых систем. Это направление усиливает спрос на DevOps/Platform инженеров с опытом автоматизации CI/CD и безопасного развертывания в импортонезависимых стэках.

С ростом цифровизации финансового сектора и объёмов транзакционных данных повышается ценность компетенций в области Big Data, машинного обучения и прикладного ИИ: от антифрода и риск‑моделей до речевой аналитики и персонализированных сервисов. Банки и технологические компании отмечают растущую потребность в специалистах, способных применять ИИ к практическим задачам, а также в дата‑инженерах и аналитиках, умеющих работать с отечественными СУБД и сетями обмена данными.

На фоне кадрового дефицита и необходимости быстро заменять функциональность западных систем компании активнее обращаются к low‑code и no‑code платформам. Это помогает бизнес‑подразделениям запускать внутренние сервисы и прототипы без ожидания редких разработчиков, а ИТ‑командам — сосредоточиться на сложных миграциях и интеграциях. Спрос на специалистов, умеющих внедрять и поддерживать такие платформы (включая отечественные), растёт.

Ниже приведем укрупнённый список компетенций, который мы видим в запросах банков и крупных ИТ‑подразделений в связи с импортозамещением и переходом в архитектуру нового поколения. Список составлен на основе отраслевых публикаций и экспертных комментариев.

• Планирование перехода с западных АБС/CRM/процессинга на российские продукты
• Перенос данных (Oracle → PostgreSQL/Postgres Pro, др.) и обеспечение целостности
• Кастомизация и доработка отечественных платформ под высокие нагрузки
• Интеграция с реестровыми решениями Минцифры

• Astra Linux / РЕД ОС / сертифицированные сборки Linux
• Управление защищёнными АРМ в банках
• Совместимость с отечественными средствами защиты информации

• PostgreSQL / Postgres Pro, ClickHouse, Greenplum‑совместимые решения
• Производительность, репликация, отказоустойчивость в высоконагруженных средах
• Миграция схем и прикладного кода с проприетарных СУБД

• Тестирование киберустойчивости новых контуров
• Secure‑by‑design и защита цепочек поставок ПО
• Пентест, SOC‑интеграции, защита контейнерных / облачных сред

• Построение витрин и дата‑платформ на отечественных СУБД
• Машинное обучение в задачах антифрода, риска, персонализации
• Гибридные команды: инженеры + доменные эксперты + регуляторика

• Управление изменениями при массовой миграции
• Коммуникация между ИТ и бизнесом по приоритизации систем
• Обучение и переквалификация сотрудников под новый стек
• Работа распределённых команд в условиях дефицита экспертов

1. Проведите картирование текущего стека: какие системы ещё завязаны на западные продукты; оцените критичность. Это нужно, чтобы понять, где вы зависите от западных продуктов и насколько критичны эти зависимости для регуляторных и бизнес‑систем. Без карты рисков невозможно расставить приоритеты миграции и бюджета

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

3. Определите зоны риска по людям (bus factor): кто единственный знает «старую» систему. В миграционных проектах критично знать, где один человек держит на себе технологию или интеграцию, и его отпуск или уход (или иная загруженность, не позволяющая участвовать в миграции) может создать операционный риск.

4. Запланируйте переквалификацию: быстрые курсы по Astra Linux / Postgres / контейнеризации и т.д. Бывает, что быстрее и дешевле вырастить или усилить часть навыков внутри, чем искать редких экспертов на рынке. Кроме, это ещё и фактор удержания – обучение внутри компании положительно сказывается на лояльности сотрудников.

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

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

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

StarsMap превращает эти вопросы в данные и помогает строить план развития и внутренней мобильности — без длинных и сложных Excel‑таблиц.

Если вы готовитесь к проектам 2025 года и началу 2026-го и хотите оценить готовность команды к импортозамещению — попробуйте StarsMap в открытой бете.