SAP Clean Core 战略：含义与落地方法

Clean Core 决定了一次 S/4HANA 升级是花六周还是六个月。如果您的系统里充满了对 SAP 标准对象的修改，每一次发布都会变成一个回归测试项目。如果您的定制逻辑位于已发布的接口之后，升级就成了例行维护。

我见过一些企业，在 S/4HANA 项目启动之前就应用 Clean Core 原则，把升级时间缩短了 40%。一家消费品公司用在核心之外构建的模块化 Fiori 应用，替换了遗留的定价逻辑，此后它的升级不再破坏这段逻辑。

自从 2025 年 4 月我第一次写这篇文章以来，变化很大。SAP 现在通过五项指导原则来描述 Clean Core，并且自 2025 年 8 月起，把每一项扩展划入四个级别之一。ECC 的截止日期也更清晰了。这个版本反映了这些变化。

Clean Core 的意思，是让您的 S/4HANA 系统在业务允许的范围内尽量贴近 SAP 标准，并且把任何额外的东西，构建成能够经受住升级的方式。

您仍然可以做定制。但定制必须使用 SAP 已发布、并承诺保持稳定的接口。SAP 提供两种做法：

• 内嵌（on-stack），使用 ABAP Cloud。 扩展运行在 S/4HANA 内部，但只使用已发布的 API 和扩展点。
• 并行（side-by-side），在 SAP BTP 上。 扩展作为独立的应用运行，通过 API 或事件与 S/4HANA 通信。

SAP 自己的指导意见是按用例来选择，优先考虑 BTP。依我的经验，代码在哪里运行，不如这项需求究竟需不需要代码来得重要。

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

SAP 围绕五项指导原则来组织 Clean Core。这篇文章的早期版本列出过不同的标题。下面是 SAP 现在使用的原则，以及我在每一项上首先看什么：

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

大多数团队从可扩展性开始，也在可扩展性结束，因为它最容易衡量。依我的经验，造成更多延误的是流程和数据。定制代码通常是症状。背后的流程才是原因。

2025 年 8 月，SAP 用 Clean Core 分级概念取代了之前的三层可扩展性模型。每一项扩展，都根据它是如何构建的、与核心的解耦程度，以及升级的难易程度来评估。

级别	SAP 的描述	对您的升级意味着什么
A	用 SAP Build 扩展。只使用公开发布的稳定接口，在 ABAP Cloud 上内嵌，或在 BTP 上并行	风险最低。SAP 以稳定性契约为这些接口背书
B	还使用 SAP 的经典 API 和技术	总体上升级稳定，但处在云开发模型之外
C	访问 SAP 内部对象	部分合规。每次升级都需要检查；SAP 计划为内部对象提供变更日志
D	不推荐：修改、写入 SAP 表、隐式增强、明确不推荐使用的对象	首先要清除的技术债务

这比过去那种“干净还是不干净”的争论更有用。它让您可以按对象设定目标。不是所有东西都必须达到 A 级。在升级之前，把您的 D 级对象迁到 B 级或 C 级，就已经是实实在在地降低了风险。

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 月

如果您请我在下个月评估您的系统，这就是我会遵循的顺序。

1. 找出哪些在被使用。 运行 SAP Readiness Check（它随您的维护协议提供），并收集您定制代码的使用数据。在一个项目上，用 smartShift 分析，我们把 18,000 个定制对象减到了 3,200 个。其余的大部分，只是没有人用。
2. 把剩下的按 A 至 D 级分类。 ABAP test cockpit 是 SAP 用于代码级检查的工具。在 RISE 下，RISE with SAP Methodology 仪表板会报告 Clean Core 的采用情况。
3. 逐个对象做决定。 淘汰它、迁到已发布的接口、在 BTP 上重建，或者带着书面理由保留它。从每天都在运行的代码开始。某个地区团队一年只用两次的报表，可以往后放。
4. 让业务人员到场。 我合作过的一位财务负责人，是在经过 45 分钟的演示讲解之后，才真正理解了他们新的 Fiori 应用。那次会议，在 UAT 阶段省下了两周的反复沟通。
5. 质疑“我们的流程不一样”。 在一次销售团队的工作坊上，那个“独特”的流程，结果有 80% 是多余的遗留行政工作。一旦去掉那些变通做法，标准 SAP 反而改善了他们的客户体验。
6. 尽早启动数据工作。 一位零售客户有超过 15,000 个自定义字段需要梳理。依我的经验，数据迁移要占实施工作量的 30% 至 40%，而它是大多数计划最容易低估的部分。我在SAP 数据迁移为何失败里讲了原因。
7. 在上线前确立治理。 设计权威机构应当评审每一项新扩展。过去默认的问题是“为什么这个不能放在 BTP 上？”今天我会问：“为什么这个不能是 A 级？如果不能，我们接受的是哪个级别，为什么？”

技能与工具同样重要。没有接触过 ABAP Cloud 或 BTP 的 ABAP 团队，在学习期间会拖慢项目。我合作过的一家制造企业，在 S/4HANA 项目启动之前，开展了为期三个月的内部 BTP 项目，这在开发阶段带来了更少的意外，物有所值。

在我谈起这个话题的几乎每一次对话里，都会出现三个问题。

在 RISE with SAP 下，Clean Core 是强制性的吗？ 不是一刀切的规则。在 S/4HANA Cloud Public Edition 中，您只能通过已发布的接口来扩展，所以系统本身就强制执行。在 Private Edition 和本地部署中，您仍然可以修改核心。在那里，Clean Core 是一项治理选择，SAP 通过 RISE 方法论仪表板来跟踪它。如果系统集成商告诉您这是合同要求，请让他们把条款拿给您看。

ECC 我还能用多久？ 对于增强包 6 至 8 上的 SAP ERP 6.0，主流维护将于 2027 年 12 月 31 日结束。可选的延长维护，需额外付费，持续到 2030 年 12 月 31 日，SAP 要求客户在 2027 年第三季度之前下单订购。更早的增强包，已在 2025 年底退出主流维护。2030 年之后，SAP ERP 私有版过渡选项覆盖 2031 年到 2033 年。它只适用于在 2030 年底之前，已经迁移到 SAP HANA 上 SAP ERP 私有版的大型系统，并且只能搭配 SAP 的 max success 计划。请把 2033 年当作例外路线，而不是规划日期。我的从 ECC 迁移到 S/4HANA 指南讲了路线的选择。

Clean Core 对 AI 重要吗？ SAP 在其标准流程和数据模型之上，构建自己的 AI 功能，包括 Joule。面向开发人员的 Joule，会针对已发布的 API 生成 ABAP Cloud 代码。我的基本看法很简单：您的流程和数据越贴近标准，这些功能对您发挥作用之前所需的适配就越少。被大量修改过的流程，是 AI 功能最难落地的地方。

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

如果您即将签订 S/4HANA 或 RISE 合同，在您同意范围之前，请让您的系统集成商，对您当前的定制代码，按 A 至 D 级做一次分类。如果他们拿不出来，这本身就说明了那份估算的一些问题。您可以用我的从 ECC 迁移到 S/4HANA 评估来测试您的迁移选项，或者预约一次通话，我们一起看看您的情况。

什么是 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 只允许通过已发布的接口来扩展，所以它从技术上强制执行 Clean Core。在 Private Edition 中，您仍然可以修改核心，所以 Clean Core 是一项治理决策。SAP 通过 RISE with SAP Methodology 仪表板来报告 Clean Core 的采用情况。

SAP ECC 的支持什么时候结束？

对于增强包 6 至 8 上的 SAP ERP 6.0，主流维护于 2027 年 12 月 31 日结束，可选的延长维护需额外付费，持续到 2030 年 12 月 31 日。更早的增强包，已在 2025 年底退出主流维护。SAP ERP 私有版过渡选项，延伸到 2033 年，只适用于在 2030 年底之前已迁移到 SAP HANA 上 SAP ERP 私有版、且符合条件的大型系统。

如何评估我的 SAP 系统是否具备 Clean Core 就绪度？

从 SAP Readiness Check 和您定制代码的使用数据开始。把仍在使用的部分，按 A 至 D 级分类，用 ABAP test cockpit 做代码级检查。然后逐个对象决定：是淘汰它、迁到已发布的接口、在 SAP BTP 上重建，还是带着书面理由保留。同时审视流程和数据，因为它们通常能解释这些代码为什么存在。

SAP BTP 在 Clean Core 战略中扮演什么角色？

SAP BTP 是并行扩展运行的地方。BTP 上的应用通过 API 和事件连接到 S/4HANA，所以核心保持不动。SAP 建议优先采用 BTP 的做法；当逻辑需要贴近数据或事务时，则使用内嵌的 ABAP Cloud 扩展。