Сроки миграции на S/4HANA и план проекта по путям

По моему опыту, миграция с SAP ECC на S/4HANA занимает от 12 до 18 месяцев при конвертации brownfield и от 18 до 24 месяцев при внедрении greenfield. Выборочный перенос данных длится от 12 до 18 месяцев. План проекта следует шести фазам SAP Activate, а чаще всего за сроки выходит фаза собственного кода.

Коротко: начинайте план с SAP Readiness Check и отводите данным 30–40% трудозатрат. На brownfield запланируйте три пробные конвертации и рассчитывайте на простой при cutover от одних выходных до недели.

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

Длительность задаёт путь. Моё правило: greenfield, если вы переходите с других систем или нужно определить новые процессы. Brownfield, если процессы определены и работают, и выборочный перенос, если процессы части областей нужно переопределить.

Вот сколько длится каждый путь в программах, которые я видел, и что обычно его растягивает:

Путь	Типичный срок	Вокруг чего строится план	Что обычно растягивает срок
Brownfield (конвертация системы)	12–18 месяцев	Конвертация существующей системы ECC с помощью Software Update Manager, затем повторные тестовые конвертации	Адаптация собственного кода и конвертация бизнес-партнёров
Greenfield (новое внедрение)	18–24 месяца	Дизайн Fit-to-Standard, разработка и повторные циклы загрузки данных	Воркшопы Explore, которые превращаются в длинные списки требований, и очистка данных
Выборочный перенос данных	12–18 месяцев	Согласование, какие балансовые единицы, подразделения и история переносятся, затем специализированные инструменты	Определение объёма данных и зависимость от профильных партнёров

Календарь важен не меньше пути. Для ECC на enhancement packages 6–8 основная поддержка заканчивается 31 декабря 2027 года (SAP News). Brownfield, начатый в этом месяце, выходит в go-live между октябрём 2027 и апрелем 2028 года, а greenfield, начатый сейчас, завершается в 2028 году.

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

RISE with SAP это коммерческий пакет, а не путь. Brownfield или выборочный переход в рамках RISE приводит на SAP Cloud ERP Private: так SAP сейчас называет то, что многие до сих пор ищут как S/4HANA Cloud Private Edition. Названные мной 6–9 месяцев для GROW with SAP и 9–18 месяцев для RISE относятся к новым внедрениям, а не к переходам с ECC.

SAP Activate это методология SAP для внедрения S/4HANA. В ней шесть фаз: Discover, Prepare, Explore, Realize, Deploy и Run (SAP Activate).

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

План проекта миграции

1. 01

   Discover

   Readiness Check, выбор пути и бизнес-кейс.

2. 02

   Prepare

   План, управление, команда и первая песочница.

3. 03

   Explore

   Fit-to-Standard или дельта-дизайн, согласованный список WRICEF.

4. 04

   Realize

   Разработка, собственный код, загрузка данных, тестовые конвертации.

5. 05

   Deploy

   Генеральная репетиция, cutover и go-live.

6. 06

   Run

   Hypercare, стабилизация и вывод ECC из эксплуатации.

Вот что входит в каждую фазу при миграции и чем различаются пути:

Фаза	Что происходит при миграции	Чем различаются пути
Discover	SAP Readiness Check, выбор пути, бизнес-кейс, первый взгляд на собственный код и данные	Для выборочного переноса здесь нужен первый объём данных
Prepare	План, управление, команда, ответственность за данные, песочница	Brownfield выполняет первую конвертацию в песочнице; greenfield настраивает систему и график воркшопов
Explore	Воркшопы Fit-to-Standard или дельта-дизайн, согласованный список WRICEF, маппинг данных	Greenfield проводит здесь больше всего времени; brownfield прорабатывает применимые simplification items
Realize	Разработка, адаптация собственного кода, циклы загрузки данных, раунды тестирования	Brownfield проводит пробные конвертации; greenfield проводит циклы загрузки, обычно через Migration Cockpit
Deploy	Генеральная репетиция, cutover, go-live	Окно простоя зависит от пути, объёма данных и подхода
Run	Hypercare, стабилизация	Выведите ECC из эксплуатации и заархивируйте то, что сохранили

WRICEF означает workflows, reports, interfaces, conversions, enhancements и forms. Это список всего, что вы разрабатываете сверх стандарта SAP, и именно за этой цифрой нужно следить.

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

Brownfield: план вокруг тестовых конвертаций

План brownfield строится вокруг цикла конвертации. Software Update Manager конвертирует систему, и каждый тестовый прогон показывает, сколько займёт настоящий и что сломается.

На brownfield я планирую три пробные конвертации до cutover. Каждая должна идти на свежей копии продуктивной системы, чтобы замеры времени что-то значили. Последняя должна вести себя как go-live: та же последовательность, те же люди, те же проверки.

Собственный план SAP для подхода с оптимизацией простоя похож на это. В нём предусмотрены прогон в песочнице, прогон в системе обеспечения качества, проверка загрузки на клоне и генеральная репетиция (SAP Learning). SAP отмечает, что меньшее число прогонов технически возможно, но повышает риск.

Greenfield: план вокруг дизайна и загрузки данных

На greenfield время уходит в Explore. Воркшопы Fit-to-Standard определяют, сколько стандарта SAP вы принимаете, и каждый разрыв становится объектом WRICEF, который нужно разработать, протестировать и сопровождать.

Данные переносятся циклами загрузки, обычно через SAP S/4HANA Migration Cockpit. Запланируйте несколько полных циклов загрузки, после каждого из которых идёт сверка, подписанная бизнесом. Промежуточные таблицы, объекты миграции и процесс загрузки разобраны в моём пошаговом руководстве по Migration Cockpit.

Выборочный перенос: план вокруг объёма данных

План выборочного переноса начинается с объёма данных. Какие балансовые единицы, бизнес-подразделения и годы истории переносятся и какие процессы перепроектируются.

Этот объём определяет инструменты, профильного партнёра и тестовые циклы. Измените его поздно, и сроки сдвинутся вместе с ним.

По моему опыту, чаще всего за сроки выходит фаза собственного кода. Это ещё и самая забываемая скрытая статья затрат при миграции, о которой говорится в моём руководстве по стоимости миграции на S/4HANA.

Вот места, за которыми я бы следил, по порядку:

1. Собственный код. Команды оценивают его объём по отчёту, а реальный размер обнаруживают, когда начинается доработка. В одной программе анализ с помощью smartShift сократил число собственных объектов с 18 000 до 3 200. Сначала выводите из использования, потом адаптируйте.
2. Собственные объекты, которые оценка пропустила. По моему опыту, именно собственные объекты, пропущенные SAP Readiness Check, бьют больнее всего потом. Прочитайте моё руководство по SAP Readiness Check, прежде чем считать его результат своим объёмом работ.
3. Данные. Миграция данных занимает 30–40% трудозатрат. Когда у очистки нет ответственного, она начинается поздно и потом сжимает тестовые циклы. Подробнее в моей статье о том, почему миграция данных SAP проваливается.
4. Explore. Бюджеты страдают в Explore, по мере того как растёт список WRICEF. Когда объём контролирует поставщик, ни у кого на его стороне нет причин останавливать этот рост.
5. Репетиции, урезанные ради экономии времени. Репетиция, отменённая ради сохранения даты, обычно стоит в выходные go-live больше времени, чем сэкономила.

Моё мнение: фиксируйте дату go-live в конце Explore, когда известны список WRICEF и объём собственного кода. Дата, назначенная на старте проекта, это догадка с приложенной презентацией для совета директоров.

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

Для brownfield SAP предлагает в Software Update Manager подход к конвертации с оптимизацией простоя. Он переносит часть конвертации и миграции данных в период работы системы, пока продуктивная система продолжает работать.

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

Поэтому согласуйте допустимый для бизнеса простой до выбора технического подхода. Затем подтвердите его на пробных конвертациях, а не в выходные go-live. Не ставьте cutover на закрытие месяца и на пиковый сезон.

План хорош настолько, насколько хороши допущения, на которых он стоит. Вот вопросы, которые я бы задал до того, как кто-либо что-то подпишет:

1. Какой путь предполагает план и что в результатах нашего Readiness Check это подтверждает?
2. Сколько собственных объектов остаётся в объёме после анализа использования и сколько будет выведено из использования?
3. Кто отвечает за очистку данных и в какой фазе она начинается?
4. Сколько пробных конвертаций или циклов загрузки запланировано и на каких данных?
5. Какой простой предполагает план и какой тестовый прогон его подтверждает?
6. Когда фиксируется дата и что с ней будет, если список WRICEF вырастет в Explore?

Попросите у партнёра рекомендации из программ, похожих на вашу, и его high-level design. Если ответы общие и не относятся к вашему бизнесу, считайте это тревожным сигналом.

Запустите SAP Readiness Check в этом квартале. Положите выводы по собственному коду и данным перед CFO и руководителем программы до того, как кто-либо возьмёт на себя обязательство по дате go-live.

Затем стройте план в обратном порядке от окна cutover, которое вы готовы принять, с тремя пробными конвертациями на brownfield или с циклами загрузки, которые нужны вашему пути. Чтобы сначала проверить сам путь, пройдите мою оценку миграции greenfield или brownfield.

Я помогаю организациям составлять и проверять на прочность такие планы миграции. Если вам нужен независимый взгляд, свяжитесь со мной.

Сколько длится миграция на S/4HANA?

По моему опыту, конвертация brownfield с ECC занимает от 12 до 18 месяцев, внедрение greenfield от 18 до 24 месяцев, а выборочный перенос данных от 12 до 18 месяцев. Чаще всего за сроки выходит фаза собственного кода, а миграция данных занимает 30–40% трудозатрат.

Из каких фаз состоит план проекта миграции на S/4HANA?

План следует SAP Activate: Discover, Prepare, Explore, Realize, Deploy и Run. При миграции в Discover входят Readiness Check и выбор пути, в Realize собственный код, загрузка данных и тестовые конвертации, а в Deploy генеральная репетиция и cutover.

Сколько пробных конвертаций нужно для миграции S/4HANA brownfield?

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

Сколько длится простой при cutover на S/4HANA?

Простой при cutover, который я видел, длился от одних выходных до недели. Он зависит от объёма данных, подхода к конвертации и числа юрлиц и интерфейсов, запускаемых одновременно. Конвертация SAP с оптимизацией простоя переносит часть работы в период работы системы, но требует больше тестовых прогонов и планирования.

Успеем ли мы завершить миграцию на S/4HANA до окончания поддержки ECC в 2027 году?

Основная поддержка ECC на enhancement packages 6–8 заканчивается 31 декабря 2027 года. Brownfield, начатый в октябре 2026 года, выходит в go-live между октябрём 2027 и апрелем 2028 года, а greenfield в 2028 году. Большинству программ, стартующих сейчас, стоит заложить в бюджет расширенную поддержку.

Что сильнее всего задерживает проекты миграции на S/4HANA?

По моему опыту, чаще всего за сроки выходит собственный код, затем очистка данных, начатая поздно, и список WRICEF, который продолжает расти в Explore. Корень большинства этих проблем в том, что программу не спланировали как следует в самом начале.