SAP Clean Core：五项原则、A 至 D 级与治理

要点

SAP Clean Core 是指让 S/4HANA 尽量贴近标准，扩展只通过已发布的接口构建，要么用 ABAP Cloud 在栈内实现，要么在 SAP BTP 上以并行方式实现
SAP 提出的 Clean Core 五项原则是：流程、扩展性、数据、集成和运营
自 2025 年 8 月起，SAP 将扩展分为 A 至 D 四个级别；D 级（修改、隐式增强、写入 SAP 表）是最先要清除的技术债
Public Edition 只允许使用 ABAP Cloud，因此由系统强制执行 Clean Core；在 Private Edition 和本地部署中，这是一项治理决策
每一项 Clean Core 决策都应由业务与 IT 组成的设计治理委员会负责；用 ABAP 测试驾驶舱和 SAP Cloud ALM 中的 RISE with SAP Methodology 仪表板衡量进展
SAP ERP 6.0 EHP 6 至 8 的主流维护于 2027 年 12 月 31 日结束；可选的延长维护持续到 2030 年 12 月 31 日

Clean Core 对您的 ERP 意味着什么
SAP Clean Core 的五项原则
Clean Core 的 A 至 D 级
面向 S/4HANA Cloud 的 ABAP Cloud 与 BTP 扩展
Clean Core 治理：谁来负责决策
Clean Core 与变革管理
Clean Core 合规：如何衡量
我会从哪里开始
Clean Core、RISE 与 AI：哪些是必需的，哪些不是
在 RISE with SAP 下，Clean Core 是强制的吗？
ECC 我还能用多久？
Clean Core 对 AI 重要吗？
常见问题

SAP Clean Core 是指在业务允许的范围内，让您的 S/4HANA 系统尽可能贴近 SAP 标准。您添加的任何内容都通过 SAP 已发布并承诺保持稳定的接口来构建，因此升级不会破坏它。

简而言之，Clean Core 是一套关于如何扩展和治理 SAP 的纪律。自定义逻辑要么用 ABAP Cloud 放在栈内，要么放在 SAP BTP 上并行运行，SAP 会把每个扩展从 A 级（最干净）到 D 级（应当清除的修改）进行分级。回报是更快的升级：我见过企业用这种方式把升级周期缩短了 40%。

如果您的系统里满是对 SAP 标准对象的修改，每次版本发布都会变成一个回归测试项目。如果您的自定义逻辑位于已发布的接口之后，升级就会成为例行维护。

我见过企业通过应用 Clean Core 原则，把升级周期缩短了 40%。他们的做法是把定制保持在最低限度，并对保留下来的定制进行治理。

2024 年，一家欧洲消费品企业用一个在 SAP BTP 上、构建于核心之外的模块化 Fiori 应用，替换了原有的旧定价逻辑。这让这部分逻辑的回归测试彻底消失了。

Clean Core 对您的 ERP 意味着什么

Clean Core 的 ERP 依然可以定制。只是定制必须使用 SAP 已发布并承诺保持稳定的接口。SAP 为此提供了两种方式：

栈内扩展，使用 ABAP Cloud。 扩展在 S/4HANA 内部运行，但只使用已发布的 API 和扩展点。
并行扩展，使用 SAP BTP。 扩展作为独立应用运行，通过 API 或事件与 S/4HANA 通信。

SAP 将其方法描述为 BTP 优先，按用例选择。根据我的经验，代码在哪里运行，远不如这个需求究竟是否需要代码重要。

脏核心对任何运行过 ECC 的人来说都很眼熟：被修改的标准程序、被直接写入的 Z 表、读取 SAP 内部结构的接口、没人记录过的隐式增强。这些在构建时都没有错。只是它们不是为一个每一两年就升级一次的系统而构建的。

我也在自己的 YouTube 频道上用一段视频（英文）讲解了这个话题。

Your S/4HANA Migration Is Already Broken without Clean Core (Here's Why)18 min

SAP Clean Core 的五项原则

SAP 围绕五项指导原则来组织 Clean Core。下面是 SAP 对每项原则的定义，以及我最先查看的内容：

原则	SAP 的含义	我最先检查什么
流程	尽可能贴近 SAP 标准流程	哪些流程变体只是因为“我们一直都这么做”而存在
扩展性	通过已发布的 API 与核心解耦的扩展，并对采用哪种方式进行治理	有多少自定义代码、其中多少在使用、分别处于哪个级别
数据	在既定治理模式下保持干净、合规的数据	重复和不完整的主数据，没人说得清的自定义字段
集成	基于受支持技术的标准化、安全的连接	直接读取表的点对点接口
运营	让其他四项得以保持的治理、人员、流程和工具	谁来审批扩展，又是什么在阻止下一次修改

大多数团队从扩展性开始，也止步于扩展性，因为它最容易衡量。根据我的经验，流程和数据造成的延误更多。自定义代码通常只是症状，背后的流程才是原因。

Clean Core 的 A 至 D 级

2025 年 8 月，SAP 用 Clean Core 级别概念取代了此前的三层扩展性模型。每个扩展都根据其构建方式、与核心的解耦程度以及能否安全地经受升级来评级。如果您读到的旧版 SAP 资料还在谈“层级”，那么取代它的就是这套概念。

Clean Core 的 A 至 D 级升级风险从 A 级到 D 级逐级上升。并非所有内容都要达到 A 级，但 D 级是最先要清除的技术债。

A 级B 级C 级D 级

使用什么A 级仅限公开发布的稳定接口B 级还使用 SAP 的经典 APIC 级SAP 内部对象D 级修改、写入 SAP 表、隐式增强

升级风险A 级最低，有稳定性契约保障B 级总体上升级稳定C 级每次升级都需检查D 级最高

需要决定什么A 级所有新开发的默认选择B 级接受，并记录理由C 级附理由接受，每次升级重新检查D 级最先清除，或迁移到 B 级或 C 级

来源: SAP Clean Core 级别概念，SAP News，2025 年 8 月

A 级只使用带稳定性契约的公开发布接口，通过 SAP Build、ABAP Cloud 或 BTP 构建。B 级还会使用 SAP 的经典 API。C 级会触及 SAP 内部对象，SAP 计划为这些对象提供变更日志，帮助规划升级。

D 级是修改、写入 SAP 表、隐式增强以及其他 SAP 不推荐的技术。这比过去“干净还是不干净”的争论更有用，因为它让您可以为每个对象设定目标。在升级前把 D 级对象迁移到 B 级或 C 级，本身就是实实在在的风险降低。

面向 S/4HANA Cloud 的 ABAP Cloud 与 BTP 扩展

ABAP Cloud 是 SAP 面向云的 ABAP 开发模型。开发人员使用“ABAP for Cloud Development”语言版本，只能基于已发布的对象、公共 API 和扩展点进行开发。它最早出现在 SAP BTP ABAP 环境中，如今在所有 S/4HANA 版本中都可使用（SAP ABAP Cloud FAQ）。

S/4HANA Cloud 提供三条扩展路径。关键用户扩展涵盖简单的字段、逻辑和 UI 变更，无需改动 SAP 代码。基于 ABAP Cloud 的开发者扩展处理紧耦合的逻辑，而 SAP BTP 上的并行扩展处理一切应当保持解耦的内容。

您有多少选择，取决于所用的版本：

	S/4HANA Cloud Public Edition	S/4HANA Cloud Private Edition 与本地部署
ABAP 开发	仅限 ABAP Cloud，自 2208 版本起对新客户强制要求	自 2022 年起推荐 ABAP Cloud；仍允许使用经典 ABAP
修改 SAP 代码	不可能	可以，但属于 D 级
关键用户扩展与 BTP 并行扩展	可用	可用
由谁强制执行 Clean Core	系统	您的治理

我对 Private Edition 客户的规则是：凡是新开发的内容，都当作 Public Edition 来对待。经典 ABAP 是允许的，但您今天添加的每一个经典对象，都是下次升级时必须有人出面辩护的决定。

Clean Core 治理：谁来负责决策

Clean Core 决策应由业务与 IT 共同组成的设计治理委员会负责。只交给 IT，凡是技术上可行的都会获批。只交给业务，他们会要求恢复旧流程。

我会这样设置：

指定成员。 每个主要领域的业务流程负责人，加上解决方案架构师和首席开发人员。业务负责人判断需求是否真实，IT 决定如何构建。
在开始构建前就优先顺序达成一致。 先用标准流程，其次是关键用户扩展，再次是基于 ABAP Cloud 或 BTP 的 A 级。B 级或 C 级需要书面理由，D 级需要退出计划。
每个扩展申请都必须有负责人和业务理由。 没有负责人，就不构建。决策和所接受的级别记录在同一份登记册中。
在传输之前设置技术关卡。 定期运行 ABAP 测试驾驶舱的 Clean Core 检查，在新的 D 级代码进入生产环境之前将其拦下。
每次升级前都审查登记册。 淘汰已经没人使用的内容，并把现在可以提升级别的内容迁移上去。

过去在那张会议桌上问的是“为什么这个不能放在 BTP 上？”如今我会问“为什么这个不能做到 A 级？”如果做不到，下一个问题就是您接受哪个级别，以及为什么。

我看到的最大的 Clean Core 错误，是试图让 SAP 像 Oracle 一样运作。请采用 SAP 的标准流程，而不是用自定义代码重建另一套系统的逻辑。如果您还在两者之间做选择，我在 SAP 与 Oracle 对比中做了比较。

Clean Core 与变革管理

Clean Core 首先是变革管理问题，其次才是技术问题。每个自定义对象之所以存在，都是因为有人提出了要求。要移除它，就得说服那个人标准流程已经够用。

当业务部门看到新流程实际运行，而不是看一张介绍它的幻灯片时，这种沟通会顺利得多。当您去检验“流程很独特”这一说法时，沟通也会更顺利，因为它往往并不独特（见下文第 4 步和第 5 步）。

技能和工具同样重要。没有用过 ABAP Cloud 或 BTP 的 ABAP 团队，在学习过程中会拖慢整个项目群。我合作过的一家制造企业在 S/4HANA 项目启动前开展了为期三个月的内部 BTP 培训计划，回报是构建阶段的意外明显减少。

Clean Core 合规：如何衡量

Clean Core 合规是指您的系统在五项原则上有多大比例符合 SAP 的标准。没有数字就无法管理，而 SAP 提供了三个获取这些数字的地方。

ABAP 测试驾驶舱。 SAP 用于代码级检查的工具。它会显示哪些自定义对象使用了未发布的对象、修改或直接访问表。
SAP Readiness Check。 它包含在您的维护协议中，能在您做出承诺之前，显示迁移到 S/4HANA 会影响哪些内容。
RISE with SAP Methodology 仪表板，也称 Clean Core 仪表板。 它运行在 SAP Cloud ALM 中。其系统视图会检查您的 S/4HANA 版本，确认数据收集工具已启用，并在升级前审查扩展；其运营视图则跟踪运营 KPI。

我每个月会摆在设计治理委员会面前的数字很简单。每个级别各有多少自定义对象，D 级是否在减少？有多少例外尚未关闭，每个例外是否都有负责人？

跳过 Clean Core 的团队并没有省掉这些工作。他们只是把工作推迟了，而它会以受阻的升级和没人看得懂的自定义代码的形式回来。

我会从哪里开始

如果您请我下个月评估您的系统，我会按以下顺序进行。

弄清哪些在用。 运行 SAP Readiness Check，并收集自定义代码的使用数据。在一个项目群中，借助 smartShift 的分析，我们把 18,000 个自定义对象缩减到 3,200 个，因为其余大部分根本没有被使用。
将剩余对象划分为 A 至 D 级。 代码部分使用 ABAP 测试驾驶舱。如果您使用的是 RISE，之后就由 Clean Core 仪表板进行跟踪。
逐个对象做决定。 淘汰它，迁移到已发布的接口，在 BTP 上重建，或者保留并记录理由。从每天都在运行的代码开始，因为某个区域团队一年只用两次的报表可以先放一放。
让业务部门参与进来。 我合作过的一位财务负责人，直到经过 45 分钟的演示讲解后，才真正理解新的 Fiori 应用。那次讲解在 UAT 阶段省下了两周的来回沟通。
质疑“我们的流程不一样”。 2023 年，在一家欧洲工业企业的销售团队研讨会上，所谓“独特”的流程有 80% 原来是多余的旧行政事务。去掉这些变通做法后，标准 SAP 改善了他们的客户体验。
尽早开始数据工作。 我在 2024 年合作的一家海湾地区（GCC）零售客户，有超过 15,000 个自定义字段需要梳理。根据我的经验，数据迁移占实施工作量的 30% 至 40%，我的 SAP 实施成本指南说明了这部分会落在预算的哪里。
在上线前确立治理。 建立上文所述的设计治理委员会，并让它成为新扩展的唯一通道。

Clean Core、RISE 与 AI：哪些是必需的，哪些不是

几乎每次谈到这个话题，都会出现三个问题。

在 RISE with SAP 下，Clean Core 是强制的吗？

并非一刀切的规定。在 Public Edition 中由系统强制执行，而在 Private Edition 和本地部署中，您仍然可以修改核心。

在后者中，Clean Core 是一种治理选择，SAP 通过 RISE methodology 仪表板进行跟踪。如果系统集成商告诉您这是合同要求，请让他们把条款拿给您看。

ECC 我还能用多久？

对于增强包 6 至 8 上的 SAP ERP 6.0，主流维护于 2027 年 12 月 31 日结束。可选的延长维护需额外付费，持续到 2030 年 12 月 31 日。

此后，SAP ERP, private edition, transition option 覆盖 2031 至 2033 年。它只适用于在 2030 年底前已迁移到基于 SAP HANA 的 SAP ERP, private edition 的大型系统。

请把 2033 年当作例外路径，而不是规划日期。我的 ECC 到 S/4HANA 迁移指南介绍了路径选择。

Clean Core 对 AI 重要吗？

重要。保持 SAP 标准有助于 AI 和 Joule 更好地发挥作用，而经过大量修改的流程正是它们最难落地的地方。

SAP 的 AI 功能，包括 Joule，都构建在其标准流程和数据模型之上。Joule for developers 会基于已发布的 API 生成 ABAP Cloud 代码。关于云、AI 和 Clean Core 如何结合，我在 ERP 现代化中做了介绍。

跳过 Clean Core 的团队并没有省掉这些工作。他们只是把工作推迟了，而它会以受阻的升级、马拉松式的回归测试和没人看得懂的自定义代码的形式回来。

在签署 S/4HANA 或 RISE 合同之前，请让您的系统集成商把现有自定义代码划分为 A 至 D 级。如果他们拿不出来，这就能让您对他们的估算有所判断。预约通话，我们可以一起看看您的情况。

常见问题

SAP 中的 Clean Core 是什么？

Clean Core 是指让 S/4HANA 贴近 SAP 标准，扩展只通过 SAP 已发布并承诺保持稳定的接口来构建。扩展要么用 ABAP Cloud 在栈内运行，要么在 SAP BTP 上并行运行。目标是让升级不会破坏您的自定义逻辑。

SAP Clean Core 的五项原则是什么？

SAP 提出的 Clean Core 五项指导原则是流程、扩展性、数据、集成和运营。流程贴近标准，扩展使用已发布的 API，数据在治理模式下保持干净。集成使用受支持的技术，运营则涵盖让其他四项得以保持的治理、人员和工具。

SAP Clean Core 的 A、B、C、D 级是什么？

自 2025 年 8 月起，SAP 将扩展分为四个级别。A 级只使用公开发布的稳定接口，B 级还使用经典 SAP API，C 级访问 SAP 内部对象。D 级包括修改、写入 SAP 表和隐式增强，升级风险最高。

RISE with SAP 是否强制要求 Clean Core？

并非一刀切的规定。S/4HANA Cloud Public Edition 只允许使用 ABAP Cloud 和已发布的接口，因此在技术上强制执行 Clean Core。在 Private Edition 中您仍然可以修改核心，因此 Clean Core 是一项治理决策，SAP 通过 RISE with SAP Methodology 仪表板进行跟踪。

什么是 ABAP Cloud？

ABAP Cloud 是 SAP 面向云的 ABAP 开发模型。它只允许使用已发布的对象、公共 API 和扩展点，从而让自定义代码在升级时保持稳定。自 2208 版本起，它在 S/4HANA Cloud Public Edition 中对新客户是强制要求，并自 2022 年起在 Private Edition 和本地部署中被推荐使用。

如何衡量 Clean Core？

使用 ABAP 测试驾驶舱进行代码级检查，并将自定义对象划分为 A 至 D 级。RISE 客户可以在 SAP Cloud ALM 的 RISE with SAP Methodology 仪表板（也称 Clean Core 仪表板）中跟踪采用情况。我跟踪的是每个级别的对象数量、D 级的变化趋势，以及有负责人的未关闭例外数量。

谁应该负责 SAP Clean Core 治理？

每一项 Clean Core 决策都应由业务与 IT 共同组成的设计治理委员会负责。业务流程负责人判断需求是否真实，IT 决定如何构建以及采用哪个级别。每个例外都连同负责人一起记录，并在每次升级前审查。

SAP ECC 的支持何时结束？

对于增强包 6 至 8 上的 SAP ERP 6.0，主流维护于 2027 年 12 月 31 日结束，可选的延长维护需额外付费，持续到 2030 年 12 月 31 日。SAP ERP, private edition, transition option 持续到 2033 年，但仅适用于在 2030 年底前已迁移到基于 SAP HANA 的 SAP ERP, private edition 的合格大型系统。