Импортозамещение ПО: как составить план перехода

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

Кого требования касаются напрямую

Жёстче всего регулируются субъекты критической информационной инфраструктуры — организации в энергетике, транспорте, связи, здравоохранении, финансах, промышленности и ряде других отраслей. Для значимых объектов КИИ ограничения на иностранное ПО и средства защиты действуют с 1 января 2026 года; базовый горизонт полного перехода — 2028 год, и ответственность за срыв сроков прорабатывается.

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

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

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

Порядок действий

Шаг 1. Инвентаризация

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

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

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

Шаг 2. Категорирование по критичности

Три группы:

• Остановит бизнес. Учётная система, система заказов, производственное ПО.
• Затруднит работу. Почта, таск-трекер, средства коммуникации.
• Переживём. Вспомогательные утилиты.

Первая группа — приоритет, даже если замена там сложнее и дороже.

Проверка простая: сколько компания проработает без системы, прежде чем это заметят клиенты. Если счёт идёт на часы — это первая группа.

Шаг 3. Поиск замены

По каждой позиции из первой группы — три варианта:

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

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

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

Шаг 4. Пилот

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

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

Шаг 5. Перенос данных

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

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

Что решается заказной разработкой

Готовый аналог существует не для всего. Чаще всего своя разработка оказывается разумной там, где:

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

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

У своей разработки есть обратная сторона: обновления, резервные копии и безопасность становятся вашей зоной ответственности. Если поручить это некому, готовый продукт с поддержкой честнее.

Как сравнивать варианты по деньгам

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

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

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

Второй параметр — срок. Своя разработка в любом случае дольше внедрения готового продукта. Если дедлайн близко, сравнение по деньгам уже не решает: успеть важнее.

Когда общее правило не работает

Открытое ПО не равно российское. Свободная лицензия сама по себе не делает продукт отечественным и не заменяет запись в реестре.

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

ПО внутри оборудования. Прошивку станка или прибора нельзя заменить отдельно от самого оборудования. Такие позиции решаются вместе с планом обновления парка.

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

Частая ошибка

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

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

Отсюда и календарь: он строится от даты, к которой должна работать самая сложная позиция.

Что должно быть в плане

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

Частые вопросы

Обязательно ли переходить обычной коммерческой компании?

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

Что делать, если российского аналога нет?

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

Сколько времени занимает переход?

Ориентир по одной системе: месяц на пилот, дальше перенос данных и параллельная работа со старой системой. Системы с интеграциями идут дольше — по ним и строится календарь.

Российское ПО хуже?

Зависит от класса систем, а не от страны. Где-то есть зрелые продукты, где-то замена означает потерю части функциональности. Это и выясняется на пилоте.

Стоит ли заодно перестроить процессы?

Нет. Смена системы и перестройка процессов одновременно — два изменения в одном, и при сбое непонятно, что именно не работает. Сначала переезд как есть.