Импортозамещение перестало быть авралом

Что произошло

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

Второй сдвиг — регуляторный. Для значимых объектов критической информационной инфраструктуры установлен срок перехода на отечественные решения — 1 января 2028 года. Это не завтра, но это и не «когда-нибудь»: для крупной ERP или хранилища данных цикл замены с инвентаризацией, миграцией и стабилизацией занимает годы, а не месяцы. Компании, которые начнут за год до срока, не успеют. Те, кто начинает сейчас, находятся в плановом графике.

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

Как это устроено

Инвентаризация доработок: часть кода мертва

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

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

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

Разделение доработок на три категории сокращает объём переноса в разы. Без инвентаризации компания переносит всё, включая то, чем не пользуется, и платит за это полную цену.

Маппинг: функция на функцию, а не продукт на продукт

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

Правильная единица маппинга — бизнес-функция. Для каждого процесса определяется: как он реализован в исходной системе (стандарт, доработка, обходной путь), как он может быть реализован в целевой (стандарт, настройка, доработка, изменение процесса), и какой вариант выбран. Таблица маппинга — центральный документ проекта; она определяет объём разработки, объём обучения и объём изменений в регламентах.

Задача миграции — не воспроизвести старую систему на новой платформе, а перенести бизнес-функции с минимально необходимым объёмом доработок.

Миграция волнами

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

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

Каждая волна — законченный цикл: миграция данных, настройка, тестирование, обучение, запуск, стабилизация. Между волнами — пауза на закрытие дефектов и корректировку плана. Это удлиняет общий срок, но резко снижает вероятность остановки бизнеса.

Параллельная эксплуатация

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

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

Переобучение на операциях, а не на интерфейсе

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

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

Как это выглядит на практике

Производственный холдинг, замена ERP. Инвентаризация выявила несколько сотен доработок в исходной системе. После классификации оказалось, что живых — явное меньшинство; остальные либо не использовались, либо дублировали стандарт целевой системы. Объём разработки сократился в разы относительно первоначальной оценки, которая делалась по принципу «перенести всё». Миграция прошла в три волны; параллельная эксплуатация учётного контура длилась два квартала с ежемесячной сверкой.

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

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

Что это значит для российской компании

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

Направления замены сложились. Рынок прошёл этап выбора и определил основные маршруты:

Класс системы	Что заменяется	На что	Где основная стоимость
ERP	SAP, Oracle	1С:ERP	Перенос доработок, переобучение пользователей, изменение процессов
СУБД	Oracle, MS SQL	PostgreSQL	Перенос хранимых процедур и специфичного SQL, тестирование
BI	Power BI, Tableau	Российские и open-source BI	Пересборка витрин, переобучение аналитиков
ОС	Windows, зарубежные Linux	Astra Linux, РЕД ОС	Совместимость прикладного ПО, переобучение администраторов

В каждом направлении стоимость лицензий — меньшая часть. Основная — в правом столбце.

Кадры — узкое место. Специалисты по целевым платформам — 1С:ERP, PostgreSQL, отечественные ОС — востребованы одновременно всем рынком. Компании, которые не начали формировать внутреннюю экспертизу, будут зависеть от подрядчиков в период максимального спроса. Разумная стратегия — привлекать подрядчика на проект с обязательной передачей знаний внутренней команде, чтобы эксплуатация не требовала внешних ресурсов.

Закрытый контур усложняет тестирование. В регулируемых отраслях тестовые среды должны быть изолированы, а данные для тестов — обезличены. Это добавляет этап подготовки тестовых данных, который в аварийной фазе часто пропускали. В плановом режиме его нужно закладывать.

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

Что делать: пошагово

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

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

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

4. Спроектируйте волны. Определите порядок по зависимостям и рискам, для каждой волны — состав, критерии готовности, критерии успешного запуска, план отката.

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

6. Подготовьте программу обучения по операциям. Для каждой роли — перечень операций, для каждой операции — инструкция в целевой системе. Обучение проверяется выполнением операции.

7. Организуйте передачу знаний. Если проект ведёт подрядчик, зафиксируйте в договоре, что внутренняя команда участвует во всех этапах и получает документацию, достаточную для самостоятельной эксплуатации.

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

Типичные ошибки

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

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

Одно переключение. Все блоки запускаются одновременно. Почему это проблема: любая ошибка останавливает компанию, откат невозможен. Что вместо: волны с критериями готовности и планом отката.

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

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

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

Как понять, что вы на верном пути

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

Вопросы, которые нам задают

Стоит ли ждать зрелости отечественных решений?

Основные направления уже прошли стадию зрелости: 1С:ERP, PostgreSQL, отечественные ОС эксплуатируются в крупных компаниях. Ожидание не снижает стоимость перехода — накопленные доработки не уменьшаются со временем, а регуляторный срок не сдвигается. Ждать имеет смысл только по узким классам ПО, где рынок действительно не сложился, и то с планом на случай, если он не сложится.

Можно ли сохранить зарубежную систему на автономной поддержке?

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

Как оценить бюджет до инвентаризации?

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

Что делать с историей данных в старой системе?

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