SAP сворачивает присутствие в России. Облачные сервисы для местных клиентов отключены ещё в 2022 году, продажи и продление лицензий остановлены, а поддержка локальных установок дотягивает до конца действия контрактов. Для тех, кто продолжает работать на ERP, S/4HANA, SuccessFactors или Ariba, это означает простую вещь: обновлений безопасности, патчей и официальной техподдержки больше не будет. Системы продолжают работать, но превращаются в чёрный ящик, который никто не чинит. Откладывать переход дальше – значит копить риск, который однажды сработает в самый неудобный момент.

Чем грозит работа на «замороженной» SAP

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

Вторая – операционные сбои. Любое изменение во внешней среде (новые форматы отчётности, требования ФНС, интеграции с банками) больше не сопровождается вендором. Дорабатывать придётся своими силами, без доступа к исходникам ядра и без гарантий совместимости.

Третья – кадры и компетенции. Специалисты по SAP уходят с рынка или переключаются на отечественные платформы. Чем дольше вы держитесь за legacy-систему, тем дороже обходится её сопровождение и тем сложнее найти людей, готовых её поддерживать.

Варианты замены: от «коробки» до заказной разработки

Готовых сценариев несколько, и выбор зависит от масштаба и отраслевой специфики.

Тиражные российские ERP (1С, «Галактика» и другие) закрывают типовые процессы – учёт, финансы, кадры, закупки. Это быстрый путь для компаний, чьи процессы укладываются в стандартную логику. Но крупный бизнес и госорганизации почти всегда упираются в ограничения: уникальные регламенты, отраслевые требования, сложные интеграции с десятками смежных систем.

Здесь работает гибридный подход – ядро на тиражной платформе плюс заказные модули под то, что не ложится в стандарт. Так удаётся перенести накопленную бизнес-логику без потери критичных функций, а не подгонять процессы под чужую «коробку».

Отдельный пласт – данные. За годы в SAP накопились исторические массивы, которые нельзя просто бросить. Их стоит не только перенести, но и подготовить для аналитики и моделей машинного обучения. Как выстроить такой контур, мы разбирали в материале про современную платформу данных и ML.

Как мигрировать без остановки бизнеса

Миграция ERP – это не разовый «переезд за выходные», а программа на месяцы. Рабочий порядок выглядит так:

  1. Аудит. Опишите фактические процессы, интеграции, кастомизации и реальную нагрузку. Часто половина доработок в SAP давно не используется – переносить их незачем.
  2. Целевая архитектура. Решите, что закрывает тиражная платформа, а что требует заказной разработки, и как стыковать это с остальным ИТ-ландшафтом.
  3. Перенос данных. Очистка, маппинг, выверка. Этап, который недооценивают чаще всего.
  4. Параллельная работа. Новая и старая системы какое-то время идут вместе, пока вы не убедитесь в корректности.
  5. Перевод и сопровождение. Обучение пользователей, поддержка, постепенный отказ от SAP.

На этапе доработок и сопровождения есть смысл закладывать автоматизацию рутины сразу. Например, обработку входящих документов разумно строить на современных инструментах – об этом мы писали в разборе автоматизации работы с документами на базе ИИ.

Вывод

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