Импортозамещение ПО

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

Рынок за этим стоит большой и активный, и он не сводится к госсектору. Массовый уход зарубежных вендоров сделал вопрос практическим для коммерческих компаний: истёкшие лицензии, закрытый доступ к обновлениям безопасности, неработающие облачные панели, отвалившиеся SDK и платёжные интеграции. Здесь импортозамещение перестаёт быть регуляторной темой и становится вопросом эксплуатационного риска. Сложившийся отечественный стек закрывает большинство типовых потребностей: операционные системы и офисные пакеты, СУБД на базе PostgreSQL, отечественные облака, корпоративные коммуникации, CRM и учётные системы, CMS для сайтов.

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

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

Смежные термины

• Легаси-кодЛегаси-код — работающий код, который дорого менять: он написан на устаревшем стеке, не покрыт тестами или потерял авторов, поэтому любая правка требует восстанавливать логику по исходникам и грозит поломкой в непредсказуемом месте.
• 152-ФЗ152-ФЗ — закон «О персональных данных», который обязывает собирать данные россиян в базах на территории России, уведомлять Роскомнадзор об обработке, брать отдельное согласие на неё и сообщать об утечке в течение 24 часов.
• Техническое заданиеТехническое задание — документ, фиксирующий, что именно должно быть сделано и по каким признакам работа считается принятой: цели, роли, сценарии, требования по экранам, интеграции, нефункциональные требования и отдельный раздел о том, что в проект не входит.
• Аутсорс и инхаусАутсорс и инхаус — два способа закрыть потребность в разработке: нанять внешнюю команду по договору с фиксированной стоимостью часа или собрать штат, где к зарплатам добавляются страховые взносы, найм, оборудование и управление.
• SLASLA — соглашение об уровне сервиса: в нём зафиксированы доступность системы в процентах, время реакции и время устранения по классам инцидентов, часы работы поддержки и компенсации на случай, если подрядчик эти показатели не выдержал.

Услуги по теме

• IT-консалтинг и продуктовый аудитСамые дорогие ошибки в разработке делаются до первой строчки кода: неверно понятая задача, стек, выбранный по привычке подрядчика, и ТЗ, которого нет. Консалтинг нужен, чтобы разобраться до того, как начнётся счётчик разработки: что именно строить, из чего, за сколько и в каком порядке. Результат — документ, а не мнение на созвоне.
• Внедрение CRM и автоматизация продажЗаявки в мессенджерах, почте и звонках теряются, если единственное место, где они собираются, — память менеджера. CRM закрывает это, но только если её настроили под ваш процесс продаж, а не поставили «как есть из коробки». Мы внедряем amoCRM и Битрикс24, настраиваем автоматизацию и связываем всё с сайтом, телефонией и аналитикой.
• AI-стратегия для бизнесаБольшинство компаний уже запустили хотя бы один пилот с ИИ. Меньшинство довело хоть один пилот до устойчивой эксплуатации. Разница обычно не в модели, а в том, выбрали ли процесс с измеримым эффектом и посчитали ли реальную стоимость эксплуатации до старта. Мы помогаем выбрать правильную точку входа и не потратить бюджет на демо, которое так и останется демо.

Почитать подробнее

• Как выбрать стек технологий для проекта: критерии, а не модаСтек выбирают на 3–5 лет вперёд, а решают за один созвон. Разбираем, в каком порядке принимать решения, какие критерии реально имеют вес, какие стеки работают для шести типов проектов и сколько стоит ошибка.
• Редизайн сайта без потери трафика: этапы, риски и SEO-чеклист переездаПоловина запросов на редизайн — это на самом деле проблемы контента, скорости или оффера. Разбираем, как отличить одно от другого, почему поэтапный вывод безопаснее большого запуска и что должно быть в чеклисте переезда, чтобы не потерять органику.
• Как выбрать подрядчика на разработку: чек-лист вопросов и красные флагиПрактическое руководство по выбору подрядчика: кому подходит фрилансер, а кому интегратор, какие 25 вопросов задать на первом созвоне, как проверить кейсы в портфолио и что обязательно должно быть в договоре.