孙玲的空间1. 从“能跑就行”到“不许乱动”：Clean Core 到底在倒逼什么
做过几年 SAP 实施的人都清楚，过去十年我们面对 ERP 的方式，基本可以概括成“能跑就行”。外围系统要对接，直接在 Standard Report 后面塞一段自定义逻辑；业务部门要一个新字段，Process Order 表里加个 ZZ 开头字段；报表不够灵活，干脆把 Function Module 改一改。系统确实能跑，数据也确实在流转，问题也暂时没人追究。但这种“自由发挥”累积到一定量级之后，系统的每一次升级、每一个 Notes 的导入、每一次 S/4HANA 版本迁移，都变成一场赌博。改过的对象、增强过的逻辑、自建的表，随时可能在升级过程中被新标准覆盖，或者干脆和新版本的标准功能产生语义冲突。这个时候，家里一旦决定上 S/4HANA，或者已经在 S/4HANA 上打算持续迭代，董事会和高层自然会问一个问题：我们的 SAP 系统到底干净不干净？还能不能安全地升级？
“Clean Core”这个概念就是在这样的背景下被推到台前的。它的本意很简单：SAP 系统里，标准的部分就保持标准，不要动；个性化的部分，尽量搬到外围；必要留在核心里的扩展，用 SAP 支持的、可持续升级的机制去做，而不是用修改标准对象的方式硬塞。
理念归理念，真正落到项目里，绝大多数企业的第一反应是：行，那我把那些自定义增强都干掉，以后新需求都尽量少往核心塞。但真到了动手拆的时候，就会撞上一堵墙。过去十年、二十年塞进 ECC 的自定义逻辑，不是平白无故长出来的。每一段 ABAP 代码背后，都对应着一条业务规则、一个流程步骤、一次数据转换。你把这些逻辑从核心剥出来，剥到哪里去？原来一个程序内部直接读取数据库、然后内存里算一步、再写回另一个表，这种语言逻辑想要原封不动搬到核心外面，靠什么搬？业务系统之间要实时联动了，靠什么通讯？
这时候就必须面对一个很现实的技术岔路口：你得有一个专门承担集成和扩展的中间层，SAP Integration Suite 和它底下的 API Management 就是 SAP 在这个岔路口上给你准备好的两条车道。很多企业以为 Clean Core 是一个“整理核心”的动作，做着做着才发现，Clean Core 实际上是一个“重建外围”的工程。而这个工程的地基，就是 API 化、事件化、服务化——每一条自定义业务逻辑，都要变成可以被调用、被编排、被监控的独立服务。
所以，说“Clean Core 几乎绕不开 SAP Integration Suite 和 API Management”，不是在帮 SAP 卖产品，而是 Clean Core 的落地路径天然指向了这个方向。你不想让核心里长满杂草，就得把种子挪到花盆里。而花盆与花盆之间、花盆与土地之间的水管，就是集成平台和 API 网关。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 为什么“不动核心”反而需要更庞大的外围设施：集成层被低估的复杂度
很多企业第一次听到 Clean Core 时，有个直觉反应：以后 SAP 系统里的自定义代码少了，运维负担是不是就轻了？这个想法对了一半。核心的升级负担确实会减轻，但整体架构的复杂度并不会消失，它只是换了位置——从 ABAP 编程环境，转移到了集成层和扩展层。换句话说，你少写了几百个 ABAP 程序，但可能要配置几十个 Integration Flow、发布上百个 API、维护一套 API 网关的认证授权策略。两边的技能栈完全不同，人员配置、工具链、监控方式也完全不一样。
2.1 从紧耦合到松耦合，中间的“胶水”并不好熬
过去在 ECC 里做增强，本质上是一种紧耦合。数据源在系统内部，处理逻辑在系统内部，结果也在系统内部。一个财务凭证增强，无非是 BADI 里加几十行代码，读写几张内表，到了月末结账的时候自然触发。这种做法的最大问题是“快”，但快的前提是业务系统本身是一个封闭的宇宙。
Clean Core 要求把非标准的逻辑搬出核心，这就意味着业务逻辑要被拆分到若干个系统上：S/4HANA 负责标准交易处理，外围的扩展应用负责个性化规则，第三方系统负责数据补充。要让这些跨系统的调用协调工作，你需要的并不是“一个接口”，而是一整套的集成基础设施。
这中间涉及的复杂度是很多人一开始没意识到的：
- 协议转换：RFC 时代的 ABAP 程序只需要被 ABAP 环境内部调用；搬到外围之后，可能消费者是 Java 服务、.NET 程序、移动端 App，你的服务需要暴露成 REST、SOAP 或 OData，甚至要支持异步事件。
- 数据映射：核心系统里的字段命名和数据结构，是经过多年标准化沉淀的，而某个外围应用可能需要完全不同的数据模型。映射逻辑放在哪里、由谁维护，是一个必须提前规划的问题。
- 事务边界：原来一个 ABAP 程序里读两个表、写三个表，天然处于同一个 LUW 之下；拆成跨系统调用之后，分布式事务的问题直接冒出来。谁先提交？失败之后怎么补偿？是否需要防腐层？
- 安全模型：内部调用不需要考虑太多，跨系统调用就要考虑 API 的认证方式、权限粒度、证书轮换、审计日志。
这些看起来都是“基本功”，但真正落地的企业大多会发现，自己的团队从来没正经做过这件事。过去的 ERP 里