Замена зарубежного ПО на отечественные аналоги

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

Коротко о задаче

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

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

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

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

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

Мы начинаем не с продукта, а с процессов.

Что входит в услугу

• Обследование фактического использования

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

• Подбор вариантов замены

Сопоставляем требования с тем, что предлагает рынок. Рассматриваем продукты из реестра отечественного программного обеспечения, свободное программное обеспечение и собственную разработку. Даём сравнение с честным перечнем ограничений каждого варианта.

• Пилотное внедрение

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

• Перенос данных

Выгружаем из старой системы, преобразуем, загружаем, сверяем полноту. Смотрите {{ссылка: Миграция и консолидация баз данных}}.

• Восстановление интеграций

Возвращаем связи с остальными системами: обмен с учётной системой, выгрузки, уведомления. Смотрите {{ссылка: Интеграция систем и разработка API}}.

• Доработка под недостающее

Когда отечественный аналог закрывает не всё, дописываем недостающее отдельным модулем или сервисом вместо отказа от продукта целиком.

• Собственная разработка

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

• Обучение и сопровождение перехода

Инструкции, обучение, поддержка пользователей в первые недели. Этот этап определяет, приживётся замена или её саботируют.

Что это даёт заказчику

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

Как мы работаем

Начинаем с обследования процессов, а не с обзора рынка. Пока непонятно, что именно делают люди, любое сравнение продуктов остаётся сравнением рекламных описаний.

Даём честную оценку каждого варианта, включая тот, где замена пока не нужна. Иногда правильное решение — оставить продукт работать в изолированном контуре ещё год и потратить бюджет на более срочное.

Инфраструктурная часть замещения — переход на отечественные операционные системы и среды виртуализации — идёт по соседнему направлению: {{ссылка: Импортозамещение инфраструктуры}}.

Наш опыт

Мы разрабатываем программное обеспечение на .NET и PostgreSQL и заменяли готовые продукты собственной разработкой там, где готовое не подходило. Электронную систему сбора данных клинических исследований мы разработали для заказчика вместо использовавшегося решения, за которое приходилось платить отдельно за каждое исследование. Система работает с 2023 года и развивается. {{ссылка: Подробнее о проекте}}

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

Расскажите, от какого продукта нужно уйти и что в нём критично. Начнём с обследования того, как им пользуются на самом деле.