Ко всем статьям
Импортозамещение корпоративного ПО редко начинается с выбора продукта. В реальности оно начинается с инвентаризации процессов, зависимостей и рисков: какие системы критичны, где есть интеграции, какие данные нельзя потерять. Если сразу заменить «коробку на коробку», можно получить простой, ручные обходные операции и конфликт между ИТ и подразделениями.
Начать с карты процессов, а не с каталога вендоров
Первый шаг — понять, какие функции фактически выполняет текущая система. В корпоративной среде одно приложение часто закрывает больше задач, чем указано в договоре: хранит справочники, запускает согласования, передает данные в бухгалтерию, формирует отчеты, выступает источником прав доступа. Если эти связи не описать до миграции, новая платформа будет внедрена формально, но процессы начнут ломаться на стыках.
Практичный подход — собрать реестр систем и привязать их к бизнес-функциям. Для каждой системы фиксируются владелец, пользователи, критичность, интеграции, объем данных, требования к доступности, лицензии и ограничения по безопасности. Такой реестр быстро показывает, где можно заменить продукт стандартным решением, а где потребуется доработка или заказная разработка.
Разделить системы по уровню риска
Не все системы нужно менять одновременно. Ошибка многих проектов — запускать импортозамещение как большую кампанию с единой датой перехода. Безопаснее выделить волны миграции: сначала низкорисковые сервисы, затем вспомогательные системы, после этого критичные процессы с высокой зависимостью от данных и интеграций.
- Низкий риск: сервисы без сложных интеграций, внутренние порталы, отдельные отчетные инструменты, базы знаний.
- Средний риск: документооборот, CRM, сервис-деск, системы управления задачами, где важны сценарии согласований и права доступа.
- Высокий риск: ERP, IdM, биллинг, производственные системы, хранилища мастер-данных и решения, влияющие на непрерывность операций.
Такая классификация позволяет не тормозить весь проект из-за самых сложных участков. Компания получает быстрые результаты там, где это безопасно, и параллельно готовит архитектуру для критичных систем.
Проверить интеграции и данные до выбора решения
При замене корпоративного ПО основные затраты часто возникают не в лицензиях, а в переносе данных и восстановлении интеграций. Важно заранее определить, какие справочники являются эталонными, какие форматы обмена используются, где есть выгрузки в Excel, какие API доступны, а какие связи построены через устаревшие скрипты или прямой доступ к базе.
На этом этапе полезен технический аудит. Он показывает, какие интеграции можно перенести без изменений, где нужен адаптер, а где лучше пересмотреть сам процесс. Например, если старая система передает права доступа через файл раз в сутки, при внедрении IdM-платформы логично перейти к событийной модели.
Не переносить старые проблемы в новую платформу
Импортозамещение не должно превращаться в копирование устаревшей логики. Если в текущей системе накопились обходные маршруты, дубли справочников, ручные согласования и роли «на всякий случай», слепой перенос закрепит эти проблемы еще на несколько лет. Перед миграцией стоит выделить процессы, которые можно упростить без риска для бизнеса.
Особенно это важно для систем с большим числом пользователей. Новый интерфейс сам по себе не решает проблему, если сотрудники продолжают работать по старым инструкциям. Нужны понятные сценарии перехода: пилотная группа, обучение ключевых пользователей, обратная связь, параллельная эксплуатация на ограниченный срок и план отката.
Собрать дорожную карту и критерии приемки
У проекта должны быть измеримые критерии успеха. Недостаточно написать «заменить зарубежное ПО». Нужно определить, какие функции должны работать на российской платформе, какие данные перенести, какие интеграции восстановить, какой уровень доступности требуется, какие отчеты и роли должны пройти проверку.
- перечень процессов, которые переходят в новую систему;
- матрица интеграций и ответственных за каждую сторону обмена;
- план миграции данных с проверкой полноты и качества;
- сценарии приемочного тестирования для бизнес-пользователей;
- план поддержки после запуска и правила обработки инцидентов.
Такой набор документов не утяжеляет проект, а снижает вероятность спорных ситуаций.
Вывод: импортозамещение корпоративного ПО лучше начинать с архитектурной и процессной диагностики. Рабочая последовательность — инвентаризация, оценка рисков, проверка интеграций, пилот, затем поэтапная миграция. Так замена платформы становится управляемым проектом, а не аварийным ремонтом процессов.