Минкомсвязь опубликовала проект плана импортозамещения программного обеспечения – приказ №96. Документ задаёт правила игры на ближайшие годы: какие классы ПО считать критичными, к каким долям отечественных продуктов стремиться и в какие сроки. Для системных интеграторов и заказчиков из госсектора это не абстрактная декларация, а ориентир для бюджетов 2015–2016 годов. Разберём, что в приказе действительно меняет планирование закупок и архитектуры.

Что вводит приказ №96

Минкомсвязь делит софт на три группы по сложности замещения. Первая – массовые продукты, где российские аналоги уже конкурентоспособны: офисные пакеты, антивирусы, почтовые системы. Здесь ведомство ставит самые жёсткие целевые доли и короткие сроки.

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

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

Ключевой управленческий инструмент – реестр отечественного ПО. Попадание в реестр станет условием преференций при госзакупках. Это значит, что заказчику недостаточно купить «российский» продукт по названию – поставщик должен формально подтвердить происхождение.

Что это меняет для заказчиков

Главная ошибка – читать приказ как требование разовой замены лицензий. Импортозамещение проприетарного стека редко сводится к установке другого дистрибутива. Зависимости тянутся вглубь: прикладной код завязан на конкретную СУБД, интеграции – на форматы и протоколы вендора, эксплуатация – на привычный инструментарий администраторов.

Поэтому замещение разумно вести не «снизу вверх» от ОС, а от архитектуры приложений. Если прикладная логика отделена от платформы, смена СУБД или сервера приложений перестаёт быть катастрофой. Здесь помогают подходы, которые мы описывали раньше: вынос интеграций за единый контур через шлюз API снижает связанность с конкретными backend-системами, а контейнеризация по схеме из сборки релизов на Docker Compose делает перенос стека между платформами предсказуемым и воспроизводимым.

Второй практический вывод – начинать с инвентаризации. Без карты того, какой софт где работает и какие данные обрабатывает, ни один план не превратится в смету. Класс ПО из приказа определяет приоритет: офисные системы и почту замещают первыми, ядро бизнес-логики – последним и осторожнее всего.

С чего начать в 2015 году

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

Разумный первый шаг – аудит зависимостей и пилот на некритичном контуре. Пилот показывает реальную трудоёмкость и вскрывает скрытые привязки к вендору до того, как они сорвут сроки на ядре. Современный веб-слой это упрощает: переход на реактивный фронтенд с тонким клиентом и API-контрактом отвязывает интерфейс от серверной платформы, и замена backend перестаёт требовать переписывания UI.

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

Вывод

Приказ №96 – это не запрет на иностранный софт, а план перераспределения приоритетов закупок. Выигрывают те, кто начнёт с архитектуры и инвентаризации, а не с поспешной замены лицензий. Чем раньше заказчик отделит прикладную логику от платформы, тем дешевле и спокойнее пройдёт замещение в установленные сроки.