Импортозамещение 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-сервисы или очередь, а не через обмен файлами по расписанию, который достался в наследство.

Отдельный случай: SAP EWM и переход на российскую WMS

Склад — единственный контур, который нельзя остановить «на выходные, пока переключаемся». Поэтому замена SAP EWM (Extended Warehouse Management) устроена иначе, чем замена финансового или закупочного модуля, и планировать её по общей методике нельзя.

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

Второе: тяжесть проекта задаёт не EWM, а автоматика. Если склад ручной или полуручной — терминалы сбора данных, этикетки, отбор по заданиям — это проект по внедрению WMS обычного объёма. Если же через EWM управляется механика (конвейеры, автоматические склады, сортеры) — то есть задействован MFS, — это уже проект промышленной автоматизации: придётся заново описывать обмен с контроллерами оборудования и проверять его на живой линии. Сроки и риски там принципиально другие, и подрядчик нужен с опытом именно такой интеграции.

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

Порядок, который работает:

1. Снять текущую топологию и стратегии. Зоны, типы ячеек, правила размещения и отбора, приоритеты заданий, схема волн. Это самая недооценённая часть: в EWM за годы накапливаются десятки правил, про которые не помнит уже никто, а работают они каждый день.
2. Выбрать целевую систему под тип склада, а не по названию. На российском рынке это 1С:WMS, Solvo.WMS, AXELOT WMS и несколько отраслевых продуктов. Заказная разработка WMS с нуля оправдана редко — обычно только там, где процесс действительно уникален, а не «у нас всё по-особенному».
3. Пилот на одном складе, и лучше не на самом крупном. 3–6 месяцев, включая обучение кладовщиков и обкатку терминалов.
4. Переключение по площадке: стоп, инвентаризация, загрузка остатков и топологии в новую систему, запуск. Остатки переносятся на момент стопа, история движений — в архив или хранилище, а не в новую WMS: она ей не нужна, а миграция истории удлиняет проект без пользы.
5. Терминалы, печать и связь — отдельная строка бюджета. Замена WMS почти всегда тянет за собой замену или перепрошивку ТСД, новые шаблоны этикеток и проверку покрытия Wi-Fi в зонах, где старая система работала годами.

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

Наш опыт здесь такой: завершённого проекта замены SAP EWM у нас нет, и выдавать за него чужой мы не станем. Разбор того, как такой проект устроен изнутри, есть у нас отдельно — WMS для FMCG-производителя, и там прямо помечено, что это сценарий проекта, а не сданное внедрение.

Выше — разбор факторов, из-за которых такие проекты идут дольше плановых: интеграция с ERP, обмен с оборудованием, перенос стратегий отбора и размещения. Наша сильная сторона в этой части — интеграционный слой: обмен между WMS, ERP и 1С, очереди и адаптеры, сверка расхождений. Если задача в этом, поговорить есть о чём; если нужен подрядчик с десятком сданных складов — честнее сказать сразу.

Oracle: под одним словом прячутся три разных проекта

«Импортозамещение Oracle» звучит как одна задача, а на деле это три проекта с разной трудоёмкостью, и первым делом нужно понять, о каком из них речь. Путаница здесь стоит дороже всего: оценку дают по одному, а делать приходится другое.

1. Oracle Database → PostgreSQL. Самый частый случай. Целевые системы — Postgres Pro, Tantor и другие сборки из реестра. Данные переносятся относительно просто; проблема в том, что в Oracle логика живёт внутри самой базы — пакеты PL/SQL, триггеры, джобы планировщика. Поэтому «перенести базу» превращается в «переписать часть приложения».

Что переписывается руками почти всегда: иерархические запросы CONNECT BY, автономные транзакции, хинты оптимизатора, специфика последовательностей — и поведение пустой строки: в Oracle '' это NULL, в PostgreSQL нет, и это тихо меняет результаты сравнений. Автоматические конвертеры дают процентов 60–80 кода, остаток — ручная работа, и именно она определяет срок.

Оценивается такой проект не объёмом данных, а инвентаризацией PL/SQL: сколько пакетов, сколько строк, что из этого вызывается хотя бы раз в год.

2. Oracle E-Business Suite или Oracle ERP → 1С:ERP либо заказная система. Это уже не база, а бизнес-процессы, и проект устроен ровно как уход с SAP: инвентаризация функций, пилот, параллельный контур, волны. Всё, что написано выше в этой статье, относится сюда целиком.

3. Инфраструктура — Exadata, Oracle Linux, средства резервного копирования. Отдельная работа, ближе к системному администрированию, чем к разработке. Часто идёт параллельно с первым пунктом и своим темпом.

Ориентир по срокам для первого случая: база среднего размера с активной серверной логикой — 4–9 месяцев с параллельным контуром и сверкой результатов на реальных данных. Меньше бывает там, где PL/SQL почти нет и база работает как хранилище: тогда это недели.

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

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

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 минут разберём вашу конкретную ситуацию.