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

Реестр и правило обоснования

Логика постановления простая. Минкомсвязь ведёт реестр отечественного ПО. Если в реестре есть продукт нужного класса, госзаказчик не может купить иностранный аналог без письменного обоснования. Обоснование публикуется вместе с закупочной документацией и проверяется. Формулировки «привыкли к этому вендору» или «так исторически сложилось» не пройдут – нужно доказать, что российские продукты объективно не покрывают требования.

Это меняет роль технического задания. Раньше ТЗ часто писали под конкретный зарубежный продукт, перечисляя его фирменные функции. Теперь такой документ – прямой риск для заказчика. Требования придётся формулировать через функции и стандарты, а не через торговые марки. Для интеграторов это значит, что архитектуру решений нужно описывать в терминах открытых протоколов и форматов, а не привязки к одному поставщику.

Что попадает под замену в первую очередь

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

Сложнее с инфраструктурным и прикладным софтом, который годами врастал в процессы. Миграция СУБД или замена серверной ОS – это не переустановка, а пересборка интеграций, скриптов и регламентов эксплуатации. Тот же вопрос встаёт с клиентскими рабочими местами: переход на отечественные платформы требует ревизии всего, что было завязано, например, на сценарии миграции вроде перехода на Windows 10 Enterprise – теперь такие планы нужно пересматривать в пользу российских ОС.

Хорошая новость в том, что технологический фундамент для независимости от вендора уже существует. Контейнеризация и оркестрация снимают жёсткую привязку приложения к конкретной платформе: вышедший в этом месяце релиз Kubernetes 1.0 и создание CNCF дают зрелый инструмент для переносимых развёртываний. А механизмы service discovery позволяют менять компоненты под капотом, не переписывая остальную систему. Архитектура, построенная на этих принципах, переживает смену поставщика гораздо легче монолита.

Как готовиться заказчику

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

Замена софта в продуктивной среде – это управляемый проект с пилотом, параллельной эксплуатацией и откатом, а не разовая операция. Чтобы переход не остановил рабочие процессы, миграцию на отечественные платформы стоит вести поэтапно, начиная с систем, где риски минимальны.

Вывод

Постановление №1236 превращает импортозамещение из лозунга в закупочную процедуру с проверяемыми обоснованиями. До 1 января 2016 года заказчикам стоит провести инвентаризацию, расставить приоритеты и перестроить ТЗ. Кто начнёт сейчас, войдёт в новый режим с готовым планом, а не с авральной заменой систем под давлением сроков.