Миграция SAP ECC на S/4HANA: кейс ближневосточного ритейлера

Это мой любимый кейс. Известный ближневосточный ритейлер моды и товаров массового потребления перешёл с SAP ECC 6.0 на S/4HANA. В компании работало около 18 000 человек, было более 1200 торговых точек в семи странах и растущий канал электронной коммерции. ECC использовался годами, и 44% его объектов были кастомизированы. Мы выбрали brownfield-конверсию с выборочным редизайном. Закрытие месяца перестало растягиваться на выходные и стало заканчиваться до обеда, а объём самописного кода сократился почти вдвое.

Если вы управляете сильно кастомизированной системой ECC и не знаете, сколько из неё переносить дальше, вот как на этот вопрос ответила одна программа.

Кастомизация копилась медленно, срочное исправление за срочным исправлением. К моменту старта даже небольшие обновления несли риск. Интеграции были хрупкими: небольшое изменение в финансах могло что-то сломать в розничных операциях. Бизнес хотел гибкости и скорости. ИТ был поглощён тушением пожаров. Обе стороны признавали, что тянут в разные стороны.

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

Триггером стало окончание основного сопровождения ECC. SAP ERP 6.0 на пакетах расширения с 6 по 8 выходит из основного сопровождения в конце 2027 года (SAP News). Реальные причины лежали глубже. Финансы каждый месяц при закрытии делали ручные выгрузки. Магазинам нужна была видимость остатков, которую не мог дать ночной пакетный режим. Основные усилия ИТ уходили на то, чтобы самописный код оставался живым.

SAP Readiness Check подтвердил наши подозрения: сильно кастомизированная система и значительный объём доработок впереди. Simplification Item List показал, где стандартный S/4HANA уже делает то, что делал самописный код ECC. Финансисты обнаружили, что некоторые отчёты, которые годами поддерживались, теперь избыточны. Облегчение на той встрече было очевидным.

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

Простая конверсияBrownfield с выборочным редизайномПолная перестройка с нуля

Сохранённая конфигурацияПростая конверсияВся, вместе с проблемамиBrownfield с выборочным редизайномТо, что было надёжнымПолная перестройка с нуляНичего, десятилетие работы выброшено

44% кастомных объектовПростая конверсияПереносятся как естьBrownfield с выборочным редизайномКаждый помечен: вывести из эксплуатации, заменить или переделатьПолная перестройка с нуляНе переносятся

Что это значитПростая конверсияПроблемы переезжают в S/4HANABrownfield с выборочным редизайномПочистить то, что требует чистки, перестроить только сломанноеПолная перестройка с нуляКаждый работающий процесс строится заново

Вызов	Что мы сделали
44% кастомизированных объектов	Бизнес и ИТ вместе помечали каждый объект: вывести из эксплуатации, заменить или переделать; контрольные точки качества по фазам
Хрупкие интеграции	План регрессионного тестирования, охватывающий POS, WMS, финансы, HR и порталы поставщиков; связи «точка-точка» перенесены на паттерны SAP Integration Suite
Качество данных	Стюарды данных по функциям со SLA; ежедневный учёт дефектов; очистка завершена до QA
Принятие системы в разных странах	Ролевые инструкции по работе, обходы рабочих мест ближе к go-live, обучение, привязанное к реальным задачам

Самописный код в масштабе

Результаты readiness сработали как фильтр. Бизнес и ИТ сели вместе и пометили каждый объект. Одни были явно избыточными, как отчёты, которые никто не мог вспомнить, когда запускал. Другие поддерживали действительно уникальные розничные процессы и требовали аккуратного редизайна. Это заставило команды решать, а не откладывать. SAP Signavio помог определить новые процессы относительно лучших практик, а smartShift взял на себя автоматические проверки кода и малоценные исправления, что сохранило время старших специалистов для редизайна. В моём руководстве по Clean Core описано, как я классифицирую самописный код сегодня.

Интеграции

ECC был связан с кассовыми системами (POS), системой управления складом (WMS), финансами, HR и несколькими порталами поставщиков. Мы построили план регрессионного тестирования по всем этим системам и тестировали после каждого значимого изменения конфигурации, а не только в конце. Ночные пакетные задания в S/4HANA должны были завершаться быстрее, иначе утренние отчёты склада не были бы готовы.

Качество данных

Дубли записей поставщиков и устаревшие основные данные затягивали тестирование. Решение было структурным: стюард данных в каждой функции со SLA на устранение. Если данные не были чистыми к началу QA, они возвращались стюарду. По мере приближения cutover мы репетировали загрузки от начала до конца и ежедневно отслеживали дефекты. Эта простая рутина работала лучше любого модного дашборда, что до сих пор меня удивляет. Закономерность описана в моей статье о том, почему миграция данных SAP не удаётся.

Принятие системы

Обучение охватило 26 000 сотрудников. У финансов и розничных операций были разные приоритеты, что проявилось на раннем воркшопе и изменило структуру обучения. Когда перед go-live давление выросло, мы использовали ролевые инструкции и обходы рабочих мест. Одна из руководителей магазинов позже сказала, что двухстраничная инструкция значила больше любого общего собрания. Я ей поверил.

Поэтапная поставка по SAP Activate. Сначала перешли базовые финансы и цепочка поставок, затем HR и порталы поставщиков, чтобы службы поддержки не оказались перегружены. У каждой среды была одна задача. Sandbox проверял путь и фиксировал объём. Development закалял транспорты. QA прогонял реальные бизнес-объёмы и настраивал задания. Pre-production был настоящей генеральной репетицией. Даты развёртывания согласовали с пиками и спадами розничного сезона.

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

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

Hypercare. Общий штаб для ИТ и бизнеса, чёткие SLA и ежедневные журналы действий. Выходные смены ротировались, а передачи поддержки расписывались по минутам. Обычно люди запоминают цифры. Я больше всего запомнил первую тихую ночь.

Закрытие периода. Команды говорили, что закрытие месяца теперь заканчивается до обеда, а раньше растягивалось на выходные. Больше всего финансового директора порадовало, что отчёты он стал получать намного быстрее. Один из финансовых руководителей пошутил, что система наконец-то работает «быстрее кофемашины». Такие моменты дают больше уверенности, чем любая презентация.

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

Отчётность и пользовательский опыт. Руководители магазинов перешли от старых экранов транзакций к приложениям SAP Fiori. Время обучения сократилось, потому что приложения работали так, как люди ожидали. Один менеджер назвал это «освежающим».

Интеграции. Связи POS, WMS и финансов стали стабильнее, а ночные задания заканчивались раньше.

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

Урок	Что произошло	Что я сделал бы в следующий раз
Согласовывайте рано	На одном воркшопе руководители магазинов сказали, что их потребности в отчётности сильно отличаются от потребностей финансов. Это выявилось рано, и мы подстроились; позже это взорвалось бы на cutover	Назначить структурированные сессии согласования до начала проектирования
Начинайте ревизию кода с первого дня	Несколько объектов пришлось переделывать под давлением ближе к go-live	Принимать решения «вывести, заменить или переделать» с самого старта
Сделайте данные задачей бизнеса	Дубли записей поставщиков тормозили тестирование	Назначить стюардов данных по функциям со SLA на первой неделе
Репетируйте больше, чем кажется нужным	Пробный прогон выявил конфликты последовательности между POS и WMS, которых никто не предвидел	Запланировать дополнительные репетиции; последняя перед go-live должна быть скучной

Если бы та же программа стартовала сегодня, изменились бы три вещи. Большинство компаний в такой ситуации теперь рассматривали бы S/4HANA Cloud Private Edition в составе RISE with SAP, а не остались бы on-premise. Решения «вывести, заменить или переделать» формулировались бы относительно уровней Clean Core от A до D по SAP. Отслеживание изменений и развёртываний велось бы в SAP Cloud ALM, потому что Solution Manager 7.2 выходит из основного сопровождения в конце 2027 года. Стюарды данных, репетиции, общий штаб и двухстраничные инструкции остались бы ровно такими же. О человеческой стороне читайте в моём руководстве по стратегиям обучения SAP.

Почему компании переходят с SAP ECC на S/4HANA?

Триггер: окончание основного сопровождения ECC в 2027 году. Более веские причины операционные: отчётность в реальном времени, более быстрое закрытие и меньше усилий на поддержание самописного кода и хрупких интеграций. В этом кейсе бизнес хотел аналитику розницы в реальном времени и более короткое закрытие месяца.

Что показал SAP Readiness Check в этом кейсе?

Он подтвердил, что 44% объектов были кастомизированы и многие годами не использовались. Это изменило структуру работы с самописным кодом: сначала вывести из эксплуатации, где возможно заменить стандартом и переделывать только то, что имело реальную бизнес-ценность. Simplification Item List также показал отчёты, которые стандартный S/4HANA сделал избыточными.

Почему выбран brownfield с выборочным редизайном?

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

Что бывает, если оставить очистку данных на потом?

Тестирование тормозится, репетиции проваливаются, go-live сдвигается. Здесь дубли записей поставщиков и устаревшие основные данные вызвали недели трений в тестировании. Решением стали стюарды данных в каждой функции со SLA, а очистка отслеживалась как показатель здоровья программы.

Как решались интеграции при миграции?

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

Как выглядит хороший hypercare после go-live S/4HANA?

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