Как рынок ИТ учится выбирать российское ПО

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

Виталий Попов, директор департамента реализации инфраструктурных проектов «Софтлайн Решения» (ГК Softline), рассказал о том, как за последние годы трансформировались требования клиентов и в каких сегментах зависимость от иностранных технологий сохраняется сильнее всего.

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

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

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

Если оценивать результаты этого первого этапа — что стало его главным достижением с точки зрения рынка?

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

Как изменились приоритеты заказчиков?

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

А на что конкретно смотрят сейчас? И есть ли разница между крупными госкомпаниями и коммерческим сектором?

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

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

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

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

Если говорить не о громких победах, а о точках напряжения — в каких сферах сегодня самый сложный задел для обеспечения технологической независимости? 

Говоря о заделе для обеспечения технологической независимости, правильнее обозначить «зоны роста» — те направления, где переход на отечественное требует наибольших усилий. Я бы выделил три такие зоны: тяжелая инфраструктура и высоконагруженные системы, отраслевой промышленный софт (CAD/CAM/PLM), а также аппаратная база и зависимый стек.

Давайте начнем с тяжелой инфраструктуры. В чем здесь главная сложность?

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

Вторая зона — промышленный софт, инженерные и расчетные системы. Почему это один из самых сложных пластов?

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

Не забываем и про обучение сотрудников. Люди годами работали с определенными инструментами. К примеру, все мы знаем, что такое AutoCAD — на него учат если не со школьной скамьи, то в вузе точно. И тут нам дают что-то российское. Производительность падает, растет цена ошибки. 

И третья зона — аппаратная база. Здесь проблема в том, что софт уже заменили, а «железо» осталось западное?

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