Почему миграция данных SAP терпит неудачу и как это исправить

Миграция данных SAP срывается чаще всего по одной причине: план строят на том, как бизнес представляет свои данные, а не на том, что показывает выгрузка. Это руководство для директоров программ, руководителей по данным и финансовых руководителей на программе S/4HANA. В нём разобрано, почему миграции ломаются, какие пять ошибок стоят за большинством сбоев cutover, как выглядит план пробных загрузок, который можно скопировать, и какие инструменты SAP подходят для каких задач в 2026 году. Если вы сделаете на этой неделе только одно, возьмите полную выгрузку основных данных клиентов, поставщиков и материалов и сами посчитайте записи.

Производственная компания потратила на внедрение SAP 18 месяцев и 4,5 млн долларов. Наступил день запуска. Все нервничали, но были воодушевлены. Потом миграция данных не удалась.

Ничего не работало как надо. Данные клиентов отсутствовали. Складские остатки были неверны. Бухгалтерия не смогла закрыть книги. Генеральный директор был в ярости.

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

Модель данных SAP не сводится к плоскому импорту. Записи зависят друг от друга. У основной записи материала есть общая запись (MARA), данные по заводу (MARC), данные оценки (MBEW) и, где используются области MRP, данные области MRP (MDMA). Если загрузить заголовок без зависимых представлений, материал существует, но использовать его в транзакциях нельзя.

S/4HANA добавляет своё правило. Клиенты и поставщики являются бизнес-партнёрами. Клиент из устаревшей системы становится бизнес-партнёром с ролью клиента, а поставщик бизнес-партнёром с ролью поставщика. Кредитные лимиты, банковские реквизиты и налоговые номера привязаны к этому бизнес-партнёру. Запись, которую устаревшая система терпела с пропусками, здесь не пройдёт проверку.

Есть ещё объём. Большинство компаний шокирует, сколько данных у них на самом деле. Один клиент думал, что у него около 50 000 записей материалов. С учётом всех вариантов и записей по заводам число оказалось ближе к 500 000. План, рассчитанный на первое число, второго не переживёт.

Оценка бизнесаПолная выгрузка

Записи материалов в объёме500,000+450,000 · +900%

Оценка бизнеса50,000

Полная выгрузка500,000

• Посчитаны все варианты и записи по заводам
• План, рассчитанный на оценку, её не переживёт

Это не было проблемой миграции данных. Это была проблема определения объёма, которая ею стала.

Оценка качества данных в начале проекта обычно оказывается описанием данных, а не их проверкой. Финансовый директор говорит, что основные данные поставщиков ведутся хорошо. Начальник склада говорит, что материалы в основном чистые. Это впечатления.

Первая выгрузка говорит правду. Поставщики, которых собирались почистить много лет назад и не почистили. Материалы, снятые с производства давно и так и не деактивированные. Адреса клиентов с несогласованными кодами стран. Отсутствующие банковские реквизиты у поставщиков, которым платят электронным переводом.

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

1. Миграцию считают поздней технической задачей

Миграции есть место в каждой фазе SAP Activate. Explore определяет объём: объекты, системы-источники, объёмы и качество. Realize создаёт шаблоны и проводит пробные загрузки. Deploy проводит финальную репетицию и загрузку при cutover. Run сверяет первое закрытие периода на реальных данных.

Проекты, которые начинают работу над миграцией в Deploy, начинают её на месяцы позже, чем нужно. Проблемы качества, которые надо было решить в Realize, всплывают в первой пробной загрузке, за недели до cutover. Мой гид по планированию сроков внедрения SAP показывает, где миграция находится в общем плане.

2. Слишком мало участия бизнеса

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

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

3. Слишком мало запланированных пробных загрузок

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

4. Пробные загрузки не сверяют

Задание загрузки, завершившееся без ошибок, не является валидацией. Валидация сравнивает то, что загружено, с ожидаемым: количество записей, финансовые итоги, остатки по открытым позициям. Затем проверка основных процессов (smoke test) подтверждает, что данные работают в транзакциях.

Несверенная пробная загрузка всё равно стоит времени. Расхождение, которое она породила, остаётся и в следующей пробной загрузке, только теперь его труднее проследить до причины. Сверяйте каждую загрузку, прежде чем начинать следующую.

5. Загрузка при cutover отличается от репетиций

Миграция при cutover должна точно повторять финальную пробную: те же скрипты выгрузки, та же логика преобразования, последовательность загрузки, проверки и тайминг. Любое изменение при cutover несёт непроверенный риск в точке наибольшего давления в программе.

Хуже всего протестирована обычно дельта. Между финальной пробной загрузкой и cutover бизнес продолжает добавлять поставщиков, менять заказы и перемещать запасы. Определите дату заморозки данных и отрепетируйте загрузку дельты в рамках финальной пробной загрузки.

Возьмите эту структуру циклов за отправную точку. У каждого цикла есть цель и критерий выхода, и он не завершён, пока сверка не подписана.

Цикл	Цель	Критерий выхода	Владелец
Пробная загрузка 1	Структура: каждый объект загружается в порядке зависимостей	Пробелы маппинга и ошибки формата записаны по каждому объекту	Руководитель миграции данных
Пробная загрузка 2	Качество: проверка исправлений маппинга и выявление проблем с данными	Доля ошибок по каждому объекту снижается; решения по очистке записаны	Стюарды данных
Пробная загрузка 3	Бизнес-правила: исключения и пограничные случаи	Стюарды принимают сверенную выборку в каждой предметной области	Стюарды данных
Пробная загрузка 4	Объём и тайминг при полном производственном размере	Полная загрузка укладывается в окно cutover	Руководитель cutover
Финальная репетиция	Генеральная репетиция cutover, включая дельту и заморозку	Количество записей и финансовые итоги сверены и подписаны	Финансовый контролёр и руководитель по данным

Вокруг этого плана решают дело пять вещей:

1. Полная выгрузка в Prepare. Вся, а не выборка. Профилируйте полноту, точность, согласованность и дубликаты, затем оцените очистку и сроки по результатам.
2. Маппинг по объектам. Для каждого объекта (бизнес-партнёры, материалы, открытые заказы на закупку и продажу, открытые позиции, запасы, основные средства) задокументируйте поля от источника к приёмнику, правила преобразования, проверки валидации и правила исключений.
3. Назначенные стюарды данных. Финансы отвечают за финансовые данные клиентов и поставщиков. Закупки отвечают за основные данные материалов. Склад отвечает за запасы. Каждый стюард подписывает свою область после каждого цикла.
4. Сверка, определённая заранее. Договоритесь, какие количества и итоги доказывают корректность загрузки, до первой пробной загрузки, чтобы при cutover никто об этом не спорил.
5. Письменная последовательность cutover. Заморозка, выгрузка, преобразование, загрузка, валидация, подпись бизнеса, go/no-go. Та же последовательность, что на финальной репетиции.

Для нового внедрения S/4HANA SAP S/4HANA Migration Cockpit является рекомендованным SAP инструментом для первоначальной загрузки. Начиная с S/4HANA 2020 он работает как приложение Fiori Migrate Your Data. Транзакция LTMC признана устаревшей, а существующие проекты LTMC можно только просматривать. Приложение предлагает два подхода: миграция данных через промежуточные (staging) таблицы, которые заполняются из файлов или вашими собственными инструментами, и миграция данных напрямую из исходной системы SAP. Команды on-premise и частного облака используют транзакцию LTMOM, модельер объектов миграции, чтобы изменять стандартные объекты или создавать собственные. Cockpit создан для первоначальных загрузок, а не для регулярных интерфейсов или массовых изменений.

У SAP есть ETL-платформа SAP Data Services. Используйте её при больших объёмах, сложной логике преобразования, нескольких системах-источниках или когда вам нужна повторно используемая структура качества данных, которая переживёт проект.

ETL-инструменты сторонних производителей, такие как Informatica, Talend или Microsoft SSIS, имеют смысл там, где организация уже владеет ими и обладает нужными навыками.

SAP Datasphere, теперь входящий в SAP Business Data Cloud, не является инструментом миграции. Его место в аналитическом слое после go-live. Он важен, если вы оставляете историю в устаревшей системе и вам всё ещё нужно по ней строить отчётность.

В большинстве стандартных внедрений Migration Cockpit покрывает большую часть объектов. Большие объёмы, сильно доработанные устаревшие системы или необычные структуры источников обычно требуют Data Services или ETL-инструмента рядом с ним. Конверсии с ECC представляют собой отдельную задачу, она разобрана в моём руководстве по миграции с ECC на S/4HANA.

Что такое миграция данных SAP?

Миграция данных SAP заключается в извлечении данных из устаревших систем, их преобразовании под структуры и правила SAP и загрузке в SAP в рамках внедрения или конверсии. Типичные объекты: бизнес-партнёры (клиенты и поставщики), материалы с данными по заводам, открытые заказы на закупку и продажу, остатки запасов, финансовые открытые позиции и основные средства. Это сложно, потому что SAP применяет зависимости и правила валидации, которых устаревшие системы часто не имели.

Каковы основные подходы к миграции данных SAP?

Новое внедрение (greenfield) загружает отобранные основные данные и открытые позиции в чистую систему S/4HANA, оставляя историю в устаревшей системе или архиве. Системная конверсия (brownfield) преобразует существующую систему ECC вместе с её историей на месте. Выборочный переход данных занимает промежуточное положение: переносятся выбранные балансовые единицы, объекты или временные срезы. Правильный выбор зависит от качества данных, требований к истории и того, сколько из старого процесса вы хотите сохранить.

Что такое SAP Migration Cockpit и когда его использовать?

SAP S/4HANA Migration Cockpit является рекомендованным SAP инструментом для первоначальной загрузки данных в S/4HANA во всех редакциях. Начиная с S/4HANA 2020 он работает как приложение Fiori Migrate Your Data; транзакция LTMC признана устаревшей. Он предоставляет предопределённые объекты миграции, проверяет данные перед проведением и сообщает об ошибках на уровне полей. Используйте его для стандартных объектов при обычных объёмах. Добавляйте SAP Data Services или другой ETL-инструмент, когда объёмы, логика преобразования или структуры источников выходят за пределы того, что обрабатывают шаблоны.

Сколько пробных загрузок нужно планировать для миграции данных SAP?

Не меньше трёх, причём последняя должна быть полной репетицией cutover. Сложным программам нужно больше. В типичном плане первая выявляет структурные пробелы маппинга. Вторая проверяет исправления и вскрывает проблемы качества данных. Третья отрабатывает бизнес-правила и пограничные случаи. Финальный прогон точно повторяет cutover, и его сверка становится базовой точкой для дня go-live.

Как перенести клиентов и поставщиков в SAP S/4HANA?

Как бизнес-партнёров. В S/4HANA основные данные клиентов и поставщиков ведутся через бизнес-партнёра с присвоенными ролями клиента и поставщика. В новом внедрении Migration Cockpit загружает их через свои объекты бизнес-партнёров. При конверсии с ECC интеграцию клиентов и поставщиков (customer-vendor integration) нужно настроить и выполнить до самой конверсии.

Что вызывает сбой миграции данных SAP при cutover?

Большинство сбоев при cutover вызывают пять сценариев. Слишком мало пробных загрузок. Последовательность cutover, ни разу не проверенная от начала до конца. Изменения в устаревшей системе после финальной пробной загрузки с непроверенной загрузкой дельты. Неустранённые расхождения при сверке. Подпись бизнеса на основе выборочной проверки. «Первые 1 000 записей выглядели нормально» не является валидацией. Для go-live нужны сверенные количества и итоги.