Импортозамещение SAP: методология поэтапной миграции без остановки бизнеса

Короткий ответ: уходить с SAP нужно процесс за процессом, а не разовой заменой системы. Рабочая схема — параллельный контур: новый модуль запускается рядом с действующей системой, какое-то время они живут вместе, и только после проверки на реальных данных процесс переключается целиком. Пилот ключевого процесса занимает 6–10 недель, полная поэтапная миграция — 6–12 месяцев.

К нам приходят с одной из двух вводных:

«SAP официально ушёл, лицензии продлевать нельзя, нужна замена вчера».

«Мы третий год пытаемся заменить SAP, что-то никак не выходит».

Обе — про одну и ту же ошибку: попытка заменить систему целиком за один заход. Такой проект длится 18–36 месяцев, стоит десятки миллионов и в 60% случаев не доходит до промышленной эксплуатации.

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

Шаг 1: Инвентаризация функций

Перед первым коммитом кода нужно понять, что именно вы используете в SAP. Обычно 30–40% функций либо не используются, либо используются 2–3 раза в год и могут быть заменены Excel-выгрузкой.

Что делаем на этом шаге:

• Опрос ключевых пользователей (30–60 человек, зависит от масштаба).
• Аудит логов SAP: какие транзакции реально вызывались за последние 12 месяцев.
• Матрица «функция ↔ критичность ↔ частота использования ↔ сложность миграции».

Выход: шорт-лист из 5–10 функций для пилота и полный реестр функций для дальнейших этапов.

Шаг 2: Пилот на некритичном процессе

Пилот — это НЕ MVP замены SAP. Пилот — это доказательство архитектуры на самом простом процессе, где ошибка не остановит бизнес.

Типичные кандидаты в пилот:

• Управление складом (WMS), если не завязано на банк.
• Учёт заявок на закупки (до этапа документооборота).
• Каталог номенклатуры и справочники.

Что должно быть в пилоте:

• Двусторонний обмен с 1С (или альтернативной учётной системой).
• Ролевая модель, соответствующая SAP-шной.
• Аудит-лог всех операций.
• Развёрнутый мониторинг: latency, ошибки, консистентность данных.

Срок пилота: 8–12 недель. Бюджет: 2–4 млн ₽. После пилота — go / no-go для миграции критичных процессов.

Шаг 3: Параллельный контур

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

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

Параллельный контур строится так:

• Все транзакции идут в новую систему.
• Новая система асинхронно шлёт события в SAP (или наоборот, в зависимости от направления миграции).
• Ежедневная сверка ключевых показателей.
• Ежедневный дайджест расхождений в Telegram / почте.

Через 4–6 недель, когда расхождений нет, отключаем запись в SAP.

Шаг 4: Миграция исторических данных

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

Наш подход:

• Актуальные данные (последние 2 года) — переносим полностью, они нужны для операционных запросов.
• Историю глубже — переносим в архивный контур (отдельная БД, отдельный интерфейс).
• Юридически значимые документы — переносим полностью, независимо от возраста.

Для архивного доступа делаем отдельный веб-интерфейс с поиском. Это дешевле, чем оптимизировать поиск в живой ERP-базе на 30+ миллионах строк.

Шаг 5: Вывод SAP из критичного контура

После 3–6 месяцев работы новой системы SAP отключается для операционных задач. Остаётся:

• Reference-режим — read-only доступ для аудита и разбора инцидентов.
• Экспорт юридически значимых данных — на случай проверок.
• Отключение лицензий — часто после этого шага, а не до.

Если SAP-лицензий уже нет физически (случай большинства российских клиентов) — этот шаг совмещается с миграцией: старая система остаётся в read-only контейнере с истёкшими лицензиями, но данные доступны.

Отдельный случай: замена SAP PO и PI

Интеграционную шину — SAP Process Orchestration или более старый Process Integration — часто забывают при планировании и вспоминают в середине проекта. А она обычно оказывается тем узлом, через который ходит половина обменов компании: с банками, складом, маркетплейсами, производственными системами.

Особенность в том, что шина не имеет собственной бизнес-ценности. Её нельзя «перенести частично» и нельзя оставить работать после ухода остальных модулей: лицензии на неё считаются отдельно, а поддержка заканчивается вместе со всем остальным.

Практический порядок замены такой.

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

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

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

Чаще всего вместе с шиной переезжает и обмен с 1С — и это удобный момент, чтобы перестроить его нормально, через HTTP-сервисы или очередь, а не через обмен файлами по расписанию, который достался в наследство.

Типичные провалы, которые видим

1. «Сделаем всё сразу» — 24 месяца пилота, потом всё срывается. Разделяйте на этапы по 3–4 месяца.
2. «Возьмём коробочный 1С:ERP как есть» — 1С не заменяет SAP один-в-один. Кастомизация обязательна, и её объём часто равен объёму заказной разработки.
3. «Мигрируем без параллельного контура» — cutover без сверки почти всегда обнажает 5–15 несостыковок, которые не были покрыты аудитом.
4. «Историю не переносим — юристы разберутся» — переносите юридически значимое, иначе первая проверка станет катастрофой.
5. «Пилот на самом сложном процессе» — вы застрянете в пилоте на 12 месяцев и не докажете архитектуру.

Сколько это реально стоит

Для среднего бизнеса (100–500 сотрудников на SAP):

• Аудит + пилот: 1.5 – 4 млн ₽, 3–4 месяца.
• Основная миграция (3–5 модулей): 8 – 20 млн ₽, 8–14 месяцев.
• Вывод и поддержка: retainer от 300 тыс. ₽/мес.

Для крупного бизнеса цифры кратно выше, но методология та же.

Что делать сейчас

Если у вас SAP в критичном контуре и нет плана миграции — начинайте с инвентаризации функций. Разбор занимает 2–3 недели и стоит 500 тыс. – 1.5 млн ₽. По итогам будет понятно, что можно закрыть 1С, а что требует заказной разработки.

Если хочется живой пример — кейс замены западной WMS с интеграцией 1С.

Или запишитесь на бесплатную встречу — за 60 минут разберём вашу конкретную ситуацию.