Что переживет миграцию с ECC на S/4HANA?

К 2027 году миграция с ECC на S/4HANA должна не начаться, а закончиться. К этому сроку нужно принять сложные решения, переписать нужные части системы, провести репетиции и получить согласование бизнеса. Стандартная конвертация SAP редко срывает программу. Обычно мешает частная система, которая двадцать лет росла вокруг SAP: Z-программы, измененные includes, user exits, BAdI, фоновые задания, обмен файлами, формы, отчеты и нигде не записанные допущения.

Если считать этот массив обычной кучей ABAP, которую достаточно успешно скомпилировать, получится технически исправная система со сломанным поведением бизнеса. Для каждого объекта проверка должна установить четыре разных факта: запускается ли он, допускает ли SAP прежнюю точку расширения, пользуется ли им кто-то и остается ли результат верным. Для каждого факта нужны свои доказательства. Один сканер не ответит на все четыре вопроса.

Срок 2027 года меняет порядок работ

SAP обещает стандартное сопровождение основных приложений SAP Business Suite 7 до конца 2027 года. Клиенты могут отдельно купить расширенное сопровождение до конца 2030 года. Оно дает запас времени, но не проект миграции. Отдел закупок может оплатить поддержку, однако не вернет годы, которые нужны, чтобы разобраться в недокументированной логике расчетов или безопасно перестроить интерфейс склада.

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

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

Срок влияет и на очередность. Заказной код нужно анализировать до окончательного определения масштаба конвертации, потому что результаты могут изменить место назначения. Сильно измененная транзакция ECC может стать расширением S/4HANA, отдельным сервисом, стандартной возможностью или отправиться в архив. Эти варианты нельзя честно оценить, пока неизвестно, какой код и какие данные затрагивает каждая транзакция.

Заказная система больше пространства имен Z

Список Z-объектов полезен для начала и опасен как определение границ. Поведение клиента может скрываться в пространствах имен, изменениях объектов SAP, реализациях расширений, сгенерированном коде, вариантах, правилах workflow, содержимом BRFplus, формах, цепочках заданий, ветках по полномочиям и внешних программах, которые вызывают RFC или читают файлы. В некоторых особенно важных фрагментах нет Z-транзакции, которую узнал бы владелец процесса.

Соберите реестр из нескольких источников и сохраните ключи для их объединения. Метаданные репозитория показывают, что существует. ATC и проверки S/4HANA находят статические шаблоны, которые конфликтуют с целевой версией. SCMON и SUSG показывают процедуры, выполненные за представительный период. Данные ST03N связывают транзакции с пользователями. История SM37 раскрывает пакетные маршруты. Там, где менялись объекты SAP, SPAU и SPDD показывают отличия клиента. Каталоги интерфейсов, направления RFC, настройки IDoc и расписания передачи файлов охватывают пути вне диалоговой работы.

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

Сложнее всего косвенно вызываемый код. User exit из стандартной обработки может ни разу не появиться в статистике как отдельная транзакция. Функциональный модуль может запускаться только через внешний RFC. Подпрограмма формы может выбираться настройкой. Анализ зависимостей должен начинаться с точек входа бизнеса и проходить через вызовы, таблицы, сообщения, задания и интерфейсы. Подсчет отдельных объектов скрывает группы, которые придется переносить вместе.

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

Компиляция доказывает меньше, чем хочется

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

S/4HANA меняет модели данных и местами предоставляет представления совместимости, чтобы облегчить переход. Старые чтения могут продолжить работу и скрыть архитектурную проблему. Код получит правдоподобные данные из такого представления, но обойдет опубликованный API или семантическую модель нового проекта. Возможно, доступ нужно заменить, заказной путь убрать или временно оставить с явным сроком удаления. Зеленый результат ATC не принимает проектные решения.

Неявное поведение базы тоже создает ложную уверенность. Рассмотрим старую процедуру:

SELECT * FROM vbap
  INTO TABLE @DATA(items)
  WHERE vbeln = @order_number.

READ TABLE items INDEX 1 INTO DATA(first_item).

Без ORDER BY база не обещает, какая строка будет первой. Если последующий код считает первый индекс самой ранней позицией, смена базы или плана выполнения изменит результат без ошибки синтаксиса. Нельзя просто добавить произвольную сортировку, пока тест не пройдет. Команда должна восстановить задуманное правило бизнеса, явно его записать и проверить граничные случаи: отклоненные, перенумерованные и удаленные позиции.

Native SQL, подсказки базе, допущения о pooled- и cluster-таблицах, прямые обновления таблиц SAP и широкие запросы SELECT * требуют внимания, но ими проверка не исчерпывается. Динамические вызовы, процедуры с большим количеством field symbols и сгенерированные инструкции могут обойти простое статическое отслеживание. Дополните автоматические результаты внимательным чтением кода вокруг точек входа с тяжелыми последствиями. Статический анализ дает карту, но не объясняет, зачем построили дорогу.

User exits и BAdI нужно читать как контракты

Реализацию расширения нельзя оценить только по коду внутри нее. Настоящий контракт включает момент вызова из SAP, полноту данных в этот момент, выполнение изменений в диалоге или update task, исключения на стороне вызывающего кода и стандартную логику, которая позже может перезаписать результат. У нового BAdI с похожим названием контракт может отличаться.

Классические user exits и customer exits часто содержат мало кода с огромным весом для бизнеса. Несколько строк могут вывести центр прибыли, отклонить заказ, изменить расчет цены или направить согласование. Во время проверки запишите для каждой реализации триггер, входное состояние, побочные эффекты, обработку ошибок и следующего потребителя. Затем сопоставьте ее с рекомендованной точкой расширения для точной версии S/4HANA и модели развертывания. Не считайте, что вариант on-premise одинаково доступен в любой цели.

Популярный совет немедленно заменить каждый exit на BAdI слишком груб. Он звучит современно и дает программе простую метрику, но оболочка не определяет качество проекта. Одной логике подойдет опубликованное in-app расширение, другой side-by-side сервис, третьей стандартная настройка, а четвертую нужно удалить. Перенос непрозрачной логики в более новый hook оставляет ее непрозрачной.

Изменения объектов SAP требуют еще более жесткого решения. Выясните, зачем они появились, предоставила ли SAP позднее ту же возможность и нужен ли бизнесу этот разрыв сейчас. Работа в SPAU не должна превращаться в обряд повторного применения всех исторических изменений. Каждое восстановленное изменение усложняет будущие обновления, поэтому ответственный должен защитить его свежими доказательствами и тестом, который без него падает.

Запишите решение как контракт: при таком событии и состоянии расширение обязано внести указанные изменения или вернуть указанную ошибку и не должно менять защищенные поля. Формулировка пригодится, будет ли целью ABAP, настройка, Go или workflow вне ядра.

Данным об использовании нужен календарь бизнеса

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

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

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

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

Еще одна ловушка связана с дублированием логики. Две Z-программы могут по-разному считать одно понятие в диалоге и пакетном режиме. Анализ выполнения видит два активных объекта, а анализ бизнеса должен увидеть спорное правило. Разберите расхождения до миграции. Точная переработка обеих версий сохранит дефект в знаниях организации.

Результаты Simplification требуют решений

SAP Readiness Check, Simplification Item Catalog и проверки ATC дают обязательные сведения, но каждый результат нужно истолковать в местном проекте. Simplification Item сообщает о важном техническом или функциональном изменении. Он не знает, устарела ли ваша программа, допустим ли временный путь совместимости и какой результат бизнеса должен сохраниться.

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

Практичная последовательность выглядит так:

1. Запустите проверки ATC для целевой версии по всему заказному объему, включая изменения и пространства имен.
2. Свяжите результаты с наблюдаемым использованием и группами зависимостей, а не разбирайте объекты по алфавиту.
3. Проследите каждую группу с тяжелыми последствиями до точки входа бизнеса и ответственного.
4. Выберите вывод, временное сохранение, адаптацию или новый проект и запишите причину.
5. Приложите исполняемое доказательство: регрессионный сценарий, сверенный результат, записанный обмен интерфейса или одобренное исключение.

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

Делайте исключения узкими и ограниченными по времени. Если замечание остается из-за временно разрешенного представления совместимости, укажите допущение о версии и условие удаления. Бессрочные исключения без проектной записи станут археологией для следующей миграции.

Интерфейсы ломаются на границах ответственности

Проверка интерфейса должна охватывать протокол, смысл данных и эксплуатационное соглашение. Команды часто перечисляют RFC, IDoc, API и файлы, после чего считают интерфейс понятным, потому что знают его endpoint. Ошибки прячутся в значении полей, последовательности, обработке дублей, подтверждениях и ручном восстановлении при недоступности одной из сторон.

Начните с наблюдаемых обменов и настроек, а не с названия в каталоге. Запишите инициатора, расписание или триггер, аутентификацию, версию payload, форму объема, timeout, повторы, идемпотентность, допущение о порядке и ответственного за сверку. Для файлов добавьте правила имен, кодировку, разделители, контрольные суммы, каталоги и архивирование. Для IDoc сохраните тип сообщения, базовый тип, расширения, партнерские профили, статусы и задания повторной обработки. Для RFC найдите внешних вызывающих вместе с направлениями внутри SAP.

Заказной ABAP часто случайно открывает контракт данных. Потребитель может зависеть от недокументированного поля, точного текста сообщения, пустого значения вместо нуля или порядка строк. S/4HANA может предложить более чистый опубликованный API, однако смена endpoint не уберет эти ожидания. Сравните старый и новый контракты поле за полем, затем решите, менять ли потребителя, ставить ли слой совместимости на границе или версионировать обмен.

Для сверки нужен отдельный тест. Успешный ответ HTTP или зеленый статус IDoc доказывает доставку до одного технического этапа. Он не доказывает, что обе системы приняли одно событие бизнеса ровно один раз. Определите ключ сопоставления, суммы или состояния для операторов, допустимую задержку и способ повторить элемент без двойной проводки. Запишите нынешние исключения, потому что ручное восстановление может содержать правила, которых нет в программе.

Я прошу команды полностью пройти один сбой. Допустим, ECC ночью записывает файл цен, передает его складской системе и архивирует исходник. Передача завершается по timeout после сохранения у получателя, но до записи успеха в ECC. Повтор отправляет вторую копию. Если получатель узнает файлы только по входному имени, он импортирует оба и дважды изменит оценку запасов. Миграция должна сохранить или улучшить поиск дублей, а не только воспроизвести успешный путь. Тест паритета должен проверить timeout, повтор и сверку.

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

Считайте каждого недокументированного потребителя открытым риском. Изучите доступные журналы сети и gateway, активность технических пользователей, получение файлов и спросите операторов, какие выгрузки они переносят вручную. Сделайте контракт явным до изменения производителя. Хуже всего узнать, что небольшая настольная база еще читает Z-отчет, после первого закрытия в новой системе.

Паритет нужно записать до переработки

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

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

Запись сценария может быть простой:

{
  "case_id": "sales-order-credit-hold",
  "entry_point": "order_create",
  "input_ref": "fixture/credit-hold-017.json",
  "expected": {
    "status": "HELD",
    "posted_documents": 0,
    "message_id": "ZCREDIT-014"
  }
}

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

Записанный производственный трафик нужно отбирать. Воспроизводить каждый вызов обычно не требуется, а общий объем чрезмерно представляет простые успешные случаи. Выберите классы эквивалентности, граничные суммы, редкие сочетания статусов, ошибки и все известные регуляторные или договорные ветки. Добавьте правила, найденные при чтении кода, даже если они не попали в окно записи.

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

Часть ABAP не должна переходить в S/4HANA

Миграция позволяет сократить заказное ядро, но «clean core» не требует перенести каждую сомнительную программу на другую платформу. Место зависит от поведения, транзакционной границы, владения данными, задержки и модели поддержки. Вынос тесно связанной проверки в удаленный сервис может добавить сбои, не создав полезной границы.

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

Целевой язык вторичен. Go может подойти сервисам с ясными интерфейсами и эксплуатационной ответственностью. Rust может подойти вычислительным ядрам, где важны правильность и контроль. TypeScript может подойти клиентам и workflow. Ни один язык не исправит отсутствующий контракт бизнеса. Если команда не может сказать, что должна делать ABAP-процедура, перевод на модный язык лишь сделает неопределенность дороже.

Остерегайтесь удаленного кода, который продолжает считать таблицы SAP своей базой. Вынос Z-программы при сохранении прямого доступа создает распределенный монолит и добавляет сетевые сбои. Определите контракт API или события, владельца состояния, повторы и идемпотентность, проверьте частичные отказы. Аккуратная схема без сверки еще не готовый проект.

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

Результат проверки должен поддерживать решение о запуске

Достоверная проверка показывает руководителю, что можно убрать, адаптировать или перепроектировать, что остается неизвестным и какие доказательства стоят за выводами. Инженер должен проследить главный риск до объектов, зависимостей, трафика и тестов. Если кому-то нужна отдельная устная история, результат не закончен.

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

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

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

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

Планируйте проверку с учетом неопределенности, а не только известных исправлений. Оставьте ресурс на решения по объектам без владельца, динамическим вызовам, невоспроизводимым отчетам и интерфейсам с неизвестными потребителями. Это не мелкие административные хвосты. В этих местах объем меняется поздно, когда кто-то наконец выясняет назначение кода.

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

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