Стратегия Clean Core в SAP: что это значит и как её применить

Clean Core решает, займёт обновление S/4HANA шесть недель или шесть месяцев. Если ваша система набита модификациями стандартных объектов SAP, каждый релиз превращается в регрессионный проект. Если ваша собственная логика стоит за выпущенными интерфейсами, обновления становятся рутинным сопровождением.

Я видел, как компании сокращали сроки обновлений на 40 %, применив принципы Clean Core до старта программы S/4HANA. Одна компания в сфере товаров массового потребления заменила устаревшую логику ценообразования модульным приложением Fiori, созданным вне ядра, и её обновления перестали ломать эту логику.

С тех пор как я впервые написал эту статью в апреле 2025 года, многое изменилось. SAP теперь описывает Clean Core через пять руководящих принципов, а с августа 2025 года относит каждое расширение к одному из четырёх уровней. Яснее стали и сроки по ECC. Эта версия учитывает всё это.

Clean Core означает держать вашу систему S/4HANA как можно ближе к стандарту SAP, насколько это позволяет бизнес, а всё дополнительное строить так, чтобы оно переживало обновления.

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

• On-stack, с ABAP Cloud. Расширения работают внутри S/4HANA, но используют только выпущенные API и точки расширения.
• Side-by-side, на SAP BTP. Расширения работают как отдельные приложения и общаются с S/4HANA через API или события.

Собственная рекомендация SAP: выбирать под каждый сценарий, отдавая приоритет BTP. По моему опыту, не так важно, где работает код, как то, нужен ли для требования код вообще.

«Грязное» ядро знакомо каждому, кто работал с ECC: изменённые стандартные программы, Z-таблицы, в которые пишут напрямую, интерфейсы, читающие внутренности SAP, неявные расширения, которые никто не документировал. Когда это создавали, ничего из этого не было ошибкой. Просто оно не было рассчитано на систему, которая обновляется каждый год или два.

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

Принцип	Что имеет в виду SAP	Что я проверяю в первую очередь
Процессы	Держаться как можно ближе к стандартному процессу SAP	Какие варианты процессов существуют только потому, что «мы всегда так делали»
Расширяемость	Расширения отделены от ядра через выпущенные API, а выбор варианта находится под управлением	Сколько самописного кода есть, сколько из него используется и на каком уровне он находится
Данные	Чистые данные, соответствующие требованиям, с отлаженной моделью управления	Дублирующиеся и неполные основные данные, пользовательские поля, которые никто не может объяснить
Интеграции	Стандартизованные защищённые соединения на поддерживаемых технологиях	Интеграции «точка-точка», которые читают таблицы напрямую
Эксплуатация	Управление, люди, процессы и инструменты, которые удерживают остальные четыре принципа	Кто утверждает расширение и что остановит следующую модификацию

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

В августе 2025 года SAP заменила прежнюю трёхуровневую модель расширяемости концепцией уровней Clean Core. Каждое расширение оценивается по тому, как оно построено, насколько отделено от ядра и как легко его обновлять.

Уровень	Описание SAP	Что это значит для вашего обновления
A	Расширение с помощью SAP Build. Только публично выпущенные стабильные интерфейсы, on-stack с ABAP Cloud или side-by-side на BTP	Наименьший риск. SAP подкрепляет эти интерфейсы контрактами стабильности
B	Дополнительно использует классические API и технологии SAP	В целом стабильно при обновлениях, но вне модели облачной разработки
C	Обращается к внутренним объектам SAP	Частичное соответствие. Каждое обновление требует проверки; SAP планирует журнал изменений для внутренних объектов
D	Не рекомендуется: модификации, запись в таблицы SAP, неявные расширения, явно нерекомендуемые объекты	Технический долг, который нужно убрать первым

Это полезнее прежнего спора «чистое ядро или нет». Такой подход позволяет задать цель для каждого объекта. Не всё должно достигать уровня A. Перевод объектов уровня D на B или C до обновления уже реально снижает риск.

Уровень AУровень BУровень CУровень D

Что используетсяУровень AТолько публично выпущенные стабильные интерфейсыУровень BТакже классические API SAPУровень CВнутренние объекты SAPУровень DМодификации, запись в таблицы SAP, неявные расширения

Риск обновленияУровень AНаименьший, подкреплён контрактами стабильностиУровень BВ целом стабильно при обновленияхУровень CНужна проверка при каждом обновленииУровень DНаивысший

Что решитьУровень AВариант по умолчанию для всего новогоУровень BПринять, записав причинуУровень CПринять с обоснованием, перепроверять при каждом обновленииУровень DУбрать в первую очередь или перевести на B или C

Источник: Концепция уровней Clean Core от SAP, SAP News, август 2025 года

Если бы вы попросили меня оценить вашу систему в следующем месяце, я бы действовал в таком порядке.

1. Выясните, что используется. Запустите SAP Readiness Check, он входит в ваш договор поддержки, и соберите данные об использовании вашего самописного кода. На одной программе анализ с помощью smartShift позволил нам сократить 18 000 самописных объектов до 3 200. Большая часть остального просто не использовалась.
2. Классифицируйте то, что осталось, по уровням от A до D. Для проверок на уровне кода у SAP есть инструмент ABAP test cockpit. В RISE о внедрении Clean Core сообщает дашборд RISE with SAP Methodology.
3. Решайте по каждому объекту. Выведите его из эксплуатации, переведите на выпущенный интерфейс, перестройте на BTP или оставьте с документированной причиной. Начните с кода, который работает каждый день. Отчёт, который дважды в год использует одна региональная команда, может подождать.
4. Пригласите бизнес за стол. Финансовый руководитель, с которым я работал, понял своё новое приложение Fiori только после 45-минутной демонстрации. Эта встреча сэкономила две недели переписки туда-обратно на UAT.
5. Оспаривайте «наш процесс особенный». На одном воркшопе с командой продаж «уникальный» процесс оказался на 80 % избыточным унаследованным административным балластом. Стандартный SAP улучшил их клиентский опыт, как только ушли обходные пути.
6. Начните работу с данными заранее. У одного розничного клиента было больше 15 000 пользовательских полей, которые нужно было разобрать. По моему опыту, миграция данных занимает от 30 до 40 % трудозатрат внедрения, и именно эту часть большинство планов недооценивает. Причины я разбираю в статье о том, почему миграция данных SAP терпит неудачу.
7. Задайте правила управления до go-live. Архитектурный совет (design authority) должен рассматривать каждое новое расширение. Раньше стандартным вопросом было «почему это не может жить на BTP?». Сегодня я бы спросил: «почему это не может быть уровнем A, а если не может, какой уровень мы принимаем и почему?»

Навыки важны не меньше инструментов. Команда ABAP, не работавшая с ABAP Cloud или BTP, замедлит программу, пока учится. Один производитель, с которым я работал, провёл трёхмесячную внутреннюю программу по BTP до старта проекта S/4HANA, и это окупилось: во время разработки сюрпризов было меньше.

Три вопроса возникают почти в каждом моём разговоре на эту тему.

Обязателен ли Clean Core в RISE with SAP? Не как общее правило. В S/4HANA Cloud Public Edition расширять можно только через выпущенные интерфейсы, так что требование обеспечивает сама система. В Private Edition и on-premise ядро по-прежнему можно модифицировать. Там Clean Core остаётся управленческим выбором, и SAP отслеживает его через дашборд методологии RISE. Если системный интегратор говорит вам, что это прописано в контракте, попросите показать пункт.

Сколько времени у меня есть на ECC? Для SAP ERP 6.0 с пакетами расширений 6–8 основная поддержка заканчивается 31 декабря 2027 года. Опциональная расширенная поддержка действует до 31 декабря 2030 года за дополнительную плату, и SAP просит клиентов заказать её до третьего квартала 2027 года. Для более ранних пакетов расширений основная поддержка закончилась в конце 2025 года. После 2030 года вариант перехода SAP ERP, private edition охватывает период с 2031 по 2033 год. Он действует только для крупных систем, которые уже перешли на SAP ERP, private edition на SAP HANA до конца 2030 года, и только вместе с планом SAP max success. Считайте 2033 год исключительным маршрутом, а не плановой датой. Варианты маршрута разобраны в моём руководстве по миграции с ECC на S/4HANA.

Имеет ли Clean Core значение для ИИ? SAP строит свои функции ИИ, включая Joule, поверх стандартных процессов и модели данных. Joule для разработчиков генерирует код ABAP Cloud на основе выпущенных API. Моя рабочая позиция проста: чем ближе ваши процессы и данные к стандарту, тем меньше адаптации требуется, прежде чем эти функции станут для вас полезными. Труднее всего внедрять функции ИИ там, где процессы сильно изменены.

Команды, которые пропускают Clean Core, не избегают работы. Они откладывают её, и она возвращается в виде заблокированных обновлений, марафонов регрессионного тестирования и самописного кода, который никто не понимает.

Если вы собираетесь подписывать контракт на S/4HANA или RISE, попросите у вашего системного интегратора классификацию текущего самописного кода по уровням от A до D, прежде чем согласовывать объём. Если её нет, это кое-что говорит об оценке. Проверить варианты миграции можно с помощью моей оценки миграции с ECC на S/4HANA, либо запишитесь на звонок, и мы разберём вашу ситуацию.

Что такое SAP Clean Core?

Clean Core означает держать S/4HANA близко к стандарту SAP и создавать расширения только через интерфейсы, которые SAP выпустила и обязалась сохранять стабильными. Расширения работают либо on-stack с ABAP Cloud, либо side-by-side на SAP BTP. Цель в том, чтобы обновления не ломали вашу собственную логику.

Каковы пять измерений SAP Clean Core?

SAP называет их пятью руководящими принципами Clean Core: процессы, расширяемость, данные, интеграции и эксплуатация. Процессы остаются близкими к стандарту. Расширения используют выпущенные API. Данные поддерживаются в чистом виде в рамках модели управления. Интеграции используют стандартизованные поддерживаемые технологии. Эксплуатация охватывает управление, людей и инструменты, которые удерживают остальные четыре принципа.

Что означают уровни A, B, C и D в SAP Clean Core?

С августа 2025 года SAP относит расширения к четырём уровням. Уровень A использует только публично выпущенные стабильные интерфейсы. Уровень B дополнительно использует классические API SAP. Уровень C обращается к внутренним объектам SAP и требует проверки при каждом обновлении. Уровень D охватывает модификации, запись в таблицы SAP, неявные расширения и другие нерекомендуемые приёмы и несёт наибольший риск.

Обязателен ли Clean Core в RISE with SAP?

Не как общее правило. S/4HANA Cloud Public Edition допускает расширения только через выпущенные интерфейсы, поэтому обеспечивает Clean Core на техническом уровне. В Private Edition ядро по-прежнему можно модифицировать, поэтому Clean Core остаётся управленческим решением. SAP сообщает о внедрении Clean Core через дашборд RISE with SAP Methodology.

Когда заканчивается поддержка SAP ECC?

Для SAP ERP 6.0 с пакетами расширений 6–8 основная поддержка заканчивается 31 декабря 2027 года, а опциональная расширенная поддержка действует до 31 декабря 2030 года за дополнительную плату. Для более ранних пакетов расширений основная поддержка закончилась в конце 2025 года. Вариант перехода SAP ERP, private edition продлевается до 2033 года только для подходящих крупных систем, которые перешли на SAP ERP, private edition на SAP HANA до конца 2030 года.

Как оценить готовность моей системы SAP к Clean Core?

Начните с SAP Readiness Check и данных об использовании вашего самописного кода. Классифицируйте всё, что ещё используется, по уровням от A до D, применяя ABAP test cockpit для проверок на уровне кода. Затем решите по каждому объекту: вывести из эксплуатации, перевести на выпущенный интерфейс, перестроить на SAP BTP или оставить с документированной причиной. Одновременно проверьте процессы и данные, потому что они обычно объясняют, зачем код существует.

Какова роль SAP BTP в стратегии Clean Core?

Side-by-side расширения работают на SAP BTP. Приложения на BTP подключаются к S/4HANA через API и события, поэтому ядро остаётся нетронутым. SAP рекомендует подход BTP-first с расширениями ABAP Cloud on-stack там, где логика должна находиться рядом с данными или транзакцией.