Замена SAP: как переходить по процессам, а не одним запуском

Уточните, что именно хотите заменить

SAP в компании может поддерживать финансы, закупки, склад, производство, кадровые операции и отчётность. Один и тот же термин скрывает разные конфигурации и доработки. Составьте реестр процессов: владельцы, пользователи, объём операций, критичные даты, внешние интеграции и отчёты.

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

Выберите границы первой волны

Хороший кандидат имеет понятный результат и контролируемые связи с остальным ландшафтом. Например, можно прорабатывать контур заявок на закупку или взаимодействие с перевозчиками, оставив финансовый учёт в прежней системе на переходный период.

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

Данные требуют отдельного проекта

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

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

Подготовьте переход и возврат

План запуска должен описывать окно изменений, сверку остатков и открытых операций, каналы поддержки и ответственных за решение о продолжении. Если критерии не выполнены, команде нужен заранее согласованный способ возврата или продления параллельной работы.

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

Роль UNIUM в таком проекте

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

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

Таблица готовности для первой волны

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

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