Стратегия Clean Core в SAP: смысл, уровни от A до D и управление

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

Коротко: Clean Core это дисциплина того, как вы расширяете SAP и управляете системой. Собственная логика работает on-stack на ABAP Cloud или side-by-side на SAP BTP, а SAP оценивает каждое расширение по шкале от уровня A (самый чистый) до уровня D (модификации, которые нужно убрать). Выигрыш в более быстрых обновлениях: я видел, как компании так сокращали сроки обновлений на 40%.

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

Я видел, как компании сокращали сроки обновлений на 40%, применяя принципы Clean Core. Они добились этого, сведя доработки к минимуму и выстроив управление теми, что оставили.

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

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

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

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

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

Я также разбираю эту тему в видео на моём YouTube-канале (на английском).

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

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

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

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

Уровень 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 года

Уровень A использует только публично выпущенные интерфейсы с контрактами стабильности и строится на SAP Build, ABAP Cloud или BTP. Уровень B добавляет классические API SAP. Уровень C затрагивает внутренние объекты SAP, и SAP планирует для них журнал изменений, чтобы помочь в планировании обновлений.

Уровень D это модификации, запись в таблицы SAP, неявные расширения и другие техники, которые SAP не рекомендует. Такая шкала полезнее старого спора «чисто или не чисто», потому что позволяет задать цель для каждого объекта. Перевести объекты уровня D на B или C до обновления уже означает реально снизить риск.

ABAP Cloud это облачная модель разработки на ABAP от SAP. Разработчики используют языковую версию «ABAP for Cloud Development» и могут строить только на выпущенных объектах, публичных API и точках расширения. Модель появилась в среде ABAP на SAP BTP и теперь доступна во всех редакциях S/4HANA (FAQ по ABAP Cloud от SAP).

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

Редакция определяет, сколько у вас выбора:

	S/4HANA Cloud Public Edition	S/4HANA Cloud Private Edition и on-premise
Разработка на ABAP	Только ABAP Cloud, обязательно для новых клиентов с релиза 2208	ABAP Cloud рекомендуется с 2022 года; классический ABAP по-прежнему разрешен
Изменения кода SAP	Невозможны	Возможны, но относятся к уровню D
Расширения ключевых пользователей и side-by-side на BTP	Доступны	Доступны
Кто обеспечивает Clean Core	Система	Ваше управление

Мое правило для клиентов Private Edition: для всего нового ведите себя так, будто у вас Public Edition. Классический ABAP разрешен, но каждый классический объект, который вы добавляете сегодня, это решение, которое кому-то придется защищать при следующем обновлении.

Решениями по Clean Core должен владеть архитектурный совет (design authority) из представителей бизнеса и ИТ. ИТ в одиночку одобрит все, что технически возможно. Бизнес в одиночку попросит вернуть старый процесс.

Вот как я бы это выстроил:

1. Назовите участников. Владельцы бизнес-процессов по каждому крупному направлению, плюс архитектор решения и ведущий разработчик. Владельцы от бизнеса решают, реально ли требование, а ИТ решает, как его реализовать.
2. Согласуйте порядок предпочтений до начала разработки. Сначала стандартный процесс, затем расширяемость для ключевых пользователей, затем уровень A на ABAP Cloud или BTP. Для уровня B или C нужно письменное обоснование, для уровня D нужен план выхода.
3. У каждого запроса на расширение должны быть владелец и бизнес-причина. Нет владельца, нет разработки. Решение и принятый уровень вносятся в единый реестр.
4. Поставьте технический барьер перед транспортами. Запускайте проверки Clean Core в ABAP test cockpit по расписанию и останавливайте новый код уровня D до того, как он попадет в продуктив.
5. Пересматривайте реестр перед каждым обновлением. Выводите из эксплуатации то, чем больше никто не пользуется, и поднимайте на более высокий уровень все, что теперь может туда перейти.

Раньше за этим столом спрашивали: «Почему это нельзя разместить на BTP?» Сегодня я бы спросил: «Почему это не может быть уровнем A?» Если не может, следующий вопрос: какой уровень вы принимаете и почему.

Самая большая ошибка с Clean Core, которую я вижу, это попытка заставить SAP работать как Oracle. Принимайте стандартные процессы SAP, а не воссоздавайте логику другой системы в собственном коде. Если вы еще выбираете между ними, я сравниваю их в статье SAP или Oracle.

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

Этот разговор идет легче, когда бизнес видит новый процесс в работе, а не слайд о нем. Он идет легче и тогда, когда вы проверяете утверждение, что процесс уникален, потому что часто это не так (см. шаги 4 и 5 ниже).

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

Соответствие Clean Core показывает, какая доля вашей системы отвечает критериям SAP по пяти принципам. Без цифр управлять им нельзя, и SAP дает три источника этих цифр.

1. ABAP test cockpit. Инструмент SAP для проверок на уровне кода. Он показывает, какие собственные объекты используют невыпущенные объекты, модификации или прямой доступ к таблицам.
2. SAP Readiness Check. Входит в ваш договор на поддержку и показывает, что затронет переход на S/4HANA, еще до того, как вы возьмете на себя обязательства.
3. Дашборд RISE with SAP Methodology, он же дашборд Clean Core. Он работает в SAP Cloud ALM. Его системное представление проверяет версию S/4HANA, подтверждает, что инструменты сбора данных активны, и анализирует расширения перед обновлением, а представление эксплуатации отслеживает операционные KPI.

Цифры, которые я бы каждый месяц клал на стол архитектурному совету, простые. Сколько собственных объектов находится на каждом уровне и снижается ли уровень D? Сколько исключений открыто и есть ли у каждого владелец?

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

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

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

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

Не как общее правило. В Public Edition его обеспечивает система, а в Private Edition и on-premise вы по-прежнему можете модифицировать ядро.

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

Сколько времени у меня осталось на ECC?

Для SAP ERP 6.0 на пакетах расширений 6–8 основная поддержка заканчивается 31 декабря 2027 года. Опциональная расширенная поддержка действует до 31 декабря 2030 года за дополнительную плату.

После этого переходный вариант SAP ERP, private edition покрывает период с 2031 по 2033 год. Он применим только к крупным системам, уже перенесенным на SAP ERP, private edition на SAP HANA до конца 2030 года.

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

Важен ли Clean Core для AI?

Да. Стандартный SAP помогает AI и Joule работать лучше, а сильно модифицированные процессы как раз те места, где внедрить их сложнее всего.

SAP строит свои функции AI, включая Joule, на стандартных процессах и модели данных. Joule для разработчиков генерирует код на ABAP Cloud на основе выпущенных API. Как облако, AI и Clean Core связаны между собой, я разбираю в статье о модернизации ERP.

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

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

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

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

Какие пять принципов у SAP Clean Core?

Пять руководящих принципов Clean Core от SAP: процессы, расширяемость, данные, интеграции и эксплуатация. Процессы остаются близкими к стандарту, расширения используют выпущенные 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 допускает только ABAP Cloud и выпущенные интерфейсы, поэтому технически обеспечивает Clean Core. В Private Edition ядро по-прежнему можно модифицировать, поэтому Clean Core там это решение в рамках управления, которое SAP отслеживает через дашборд RISE with SAP Methodology.

Что такое ABAP Cloud?

ABAP Cloud это облачная модель разработки на ABAP от SAP. Она допускает только выпущенные объекты, публичные API и точки расширения, благодаря чему собственный код остается стабильным при обновлениях. Она обязательна в S/4HANA Cloud Public Edition для новых клиентов с релиза 2208 и рекомендуется в Private Edition и on-premise с 2022 года.

Как измерить Clean Core?

Используйте ABAP test cockpit для проверок на уровне кода и распределите собственные объекты по уровням от A до D. Клиенты RISE могут отслеживать внедрение на дашборде RISE with SAP Methodology, который также называют дашбордом Clean Core, в SAP Cloud ALM. Я отслеживаю число объектов на каждом уровне, динамику уровня D и количество открытых исключений с владельцем.

Кто должен владеть управлением SAP Clean Core?

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

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

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