最近拜仁慕尼黑和 SAP 的新闻又把“Clean Core”这个词拉回到了技术圈的话题中心。作为长期做 SAP 实施和运维的人我看到拜仁选择 SAP Cloud ERP Private Edition 推进云战略转型第一反应是这不仅是足球俱乐部信息化的一次升级更是 SAP 生态里一套典型且值得拆解的“存量系统上云、标准核心净核”的路径。过去几年我们谈 S/4HANA 升级多数还在纠结是绿field还是棕field现在 Clean Core 成了绕不开的硬指标而拜仁这个案例恰好把选型逻辑、业务痛点和落地节奏都摆在了台面上很有参考价值。这篇文章不打算复述新闻稿而是从 SAP 从业者的角度把“拜仁慕尼黑启用 SAP Cloud ERP Private 推进 Clean Core 云战略转型”背后的技术选择、实施思路、常见坑点逐个拆开。无论你是在做 S/4HANA 升级评估还是已经在 Cloud ERP Private 上做净核改造里面的内容都能直接对应到你的项目里。1. 从一个足球俱乐部的IT选型说起拜仁慕尼黑为什么选Clean Core1.1 为什么是 Cloud ERP Private Edition而不是 Public 或传统私有化部署很多客户问过我一个问题既然要上云为什么不直接选 SAP S/4HANA Cloud Public EditionPublic 版本标准化程度高、升级快、TCO 低看起来更“云原生”。但拜仁这种企业既不是从零开始上 SAP 的新客户也不是标准流程能完全覆盖的中小型企业。作为一家全球顶级足球俱乐部它背后有票务、赞助商管理、球员转会与合同、 merchandise周边商品、青训体系、赛事运营等一系列复杂业务这些流程里既有行业特性也有长期沉淀下来的管理习惯。Cloud ERP Private Edition 在技术上等同于 S/4HANA 私有云版本由 SAP 托管基础设施和系统运维但租户是隔离的客户仍然拥有对系统的完全访问权限可以安装自定义代码、使用传统的 ABAP 扩展、访问底层数据库。这就给了拜仁一个很关键的过渡空间既享受云运维的红利又不必像 Public 版本那样把所有自定义开发都推到 Side-by-Side 扩展平台。对于从 ECC 迁移上来的存量客户Private Edition 几乎是唯一顺滑的路线因为它支持系统转换而不是只有新实施。我见过太多客户在选型时被“云”字吓住以为上了 Cloud ERP 就什么都不能改了。实际上Private Edition 的净核目标不是禁止你改而是要求你把改动控制在“必要且优雅”的范围内。拜仁选择 Private Edition本质上是在标准化和个性化之间找平衡这也是绝大多数大型企业迁移 S/4HANA 的真实诉求。1.2 Clean Core 在业务层面意味着什么Clean Core 这个词听起来很技术但业务人员更容易理解的说法是核心系统里的标准流程保持干净、可升级把那些和行业特性、公司特色强相关的逻辑尽量挪到核心之外的扩展层去。传统 ECC 时代我们习惯在标准程序里塞增强、在标准表后面加 Append 字段、甚至直接改标准功能结果一到升级就痛不欲生。S/4HANA 时代SAP 把“可升级性”提到了前所未有的高度Clean Core 不是理念而是强制要求——尤其在 Cloud ERP Private Edition 的订阅模式下SAP 每年都会推送技术更新如果核心代码太脏升级就会冲突不断。具体到拜仁的场景票务系统可能需要实时同步到财务球员转会的摊销逻辑可能和标准资产管理流程不完全一致赞助商权益的确认收入节点也可能有行业特殊性。这些逻辑如果全部做成标准功能的增强核心就会被撑得越来越复杂。Clean Core 的做法是优先用标准功能配置满足配置解决不了的用 Side-by-Side 扩展比如 SAP BTP、CAP、RAP或者偶发性的、可管理的 ABAP 扩展来承载确保核心代码库保持精简。从我实操的项目经验看判断 Clean Core 是否达标SAP 有一个叫“自定义代码分析”的工具也就是 Custom Code Cockpit或者通过 SAP Readiness Check 2.0 分析自定义代码的兼容性。真正做得好的项目最后交付的自定义代码行数会大幅下降一部分被标准功能替代一部分被重构到 BTP 上核心系统里的增强点位清晰可控升级窗口从过去的半年缩短到几天。2. Clean Core 的技术底座从 ECC 到 S/4HANA Cloud Private 的迁移思路2.1 盘点现状那些年我们改过的 Z 程序不管是哪个行业做 S/4HANA 迁移的第一步永远是摸清家底。你可以让 BASIS 团队跑一下程序把系统中所有的 Z 对象导出来Z 程序、Z 表、Z 功能模块、用户出口、隐式增强、BADI 实现再看看有多少是真正在用的。很多系统的现实是几百个 Z 程序里真正高频调用的不到一半剩下的都是历史项目遗留、做了一半的测试程序或者是某个顾问离职前留下的“一次性工具”。我在一个制造企业做过评估光自定义表就有 400 多张其中超过 200 张没有数据或只有测试数据。这类“僵尸对象”是 Clean Core 改造的第一批清理目标删掉之后不仅让系统干净了还减少了升级时的兼容性检查工作量。SAP 的 Readiness Check 2.0 会自动扫描这些对象并给出红灯、黄灯、绿灯分类。红灯对象通常是使用了废弃功能或者需要重新实现的黄灯对象可能有语法兼容问题绿灯对象可以直接带过去。做自定义代码盘点时我建议按业务模块分组让每个模块的负责人认领自己的 Z 对象逐个确认“是否仍在使用”“能否被标准功能替代”“能否搬到 BTP ”。不要只让开发人员自己判断因为很多代码是业务提需求时写的业务可能早就换了流程。逐条确认虽然耗时但能避免上线后被业务反问“为什么这个功能没了”的尴尬。2.2 标准功能优先扩展走 Side-by-SideClean Core 的实施原则我习惯总结成一个决策树第一看标准配置能不能搞定。S/4HANA 的标准功能比 ECC 强大了很多比如物料账、销售定价、资产管理、利润分析都做了重构很多旧的增强逻辑在标准配置里就有对应开关。第二如果配置搞不定看能不能用 Key User Extensibility也就是所谓的“应用内扩展”比如自定义字段、自定义表、自定义报表但必须遵循 SAP 的扩展点。第三如果业务逻辑非常复杂涉及跨系统集成或需要很强的灵活性才考虑 Side-by-Side 扩展也就是在 BTP 上用 CAP、RAP、Kyma 等开发微服务通过 API 和 S/4HANA 通信。拜仁这种俱乐部最典型的例子是球员转会和合同管理。转会费需要在合同期内摊销但球员表现相关的奖金、二次转会分成条款可能和标准资产摊销模型不匹配。这类逻辑如果写在核心系统里会涉及财务、合同、人力资源多个模块而且规则变化频繁。放到 Side-by-Side 上做成一个独立的资产管理服务通过 API 把摊销凭证回传到 S/4HANA核心系统只需要保留标准的资产主数据和凭证接口规则变化时只改外部服务不用动核心也不影响升级。实际操作中很多开发人员不适应这种模式因为他们习惯了直接在 SAP 里改。我的建议是项目一开始就定好扩展策略形成书面规范哪些场景允许 ABAP 扩展哪些必须走 Side-by-Side。没有规范的约束开发人员很快就会回到老路上去。2.3 数据迁移与接口改造的关键点从 ECC 迁移到 S/4HANA很多人关注的是功能差异但真正容易翻车的是数据迁移和接口兼容。S/4HANA 在数据模型上有重大变化比如物料主数据的部分表结构变化、财务凭证表从 BKPF/BSEG 变成了 ACDOCA 的简化结构、销售和MM的表也做了 HANA 优化。这些变化意味着老接口如果直接读取旧表结构迁移后很可能取不到数据。我见过一个很典型的坑有一个老系统外围的报表平台每天凌晨从 ECC 拉取财务凭证用的是 BSEG 表直接 SQL 读取。S/4HANA 迁移后BSEG 虽然还存在但已经不是财务凭证的完整数据来源很多字段迁移到了 ACDOCA甚至某些行项目数据只存在于 ACDOCABSEG 里只有总账视图。结果报表平台的数据缺了一大块。所以接口改造要趁早把所有以直接读表方式访问 ECC 的接口全部列出来改成 BAPI、CDS View 或者 OData 服务。数据迁移的另一个重点是主数据质量。S/4HANA 强化了业务伙伴BP模型客户和供应商统一用 BP 管理传统的 KNA1、LFA1 不再是主入口。如果你的系统里客户主数据里面挂了大量历史遗留的地址、税号、银行信息异常迁移前一定要先做数据清洗否则 BP 同步会让你头大。拜仁的案例里合作伙伴管理BP的梳理一定是个绕不开的项目因为俱乐部有大量 VIP 客户、赞助商、转播商、票务代理这些主数据不干净后续的销售、开票、财务对账都会出问题。3. 实操中的核心环节权限、增强与财务集成的落地细节3.1 PFCG 权限角色在云环境的收敛权限角色管理是每个 SAP 项目里最容易被低估、又最容易延期的工作。传统 ECC 环境里很多公司把权限做得很散一个人有几十个角色有些角色甚至复制了整个 SAP_ALL美其名曰“方便”。S/4HANA Cloud Private 的目标是 Clean Core权限模型也要跟着瘦身否则上云之后审计和合规就会成为大问题。PFCG权限角色生成器在 S/4HANA 里依然是核心工具但角色设计逻辑要更简洁。我建议把所有角色按“岗位”而不是按“个人”来定义一个岗位对应一套最小权限集合用户只需要分配少量岗位角色系统自动组合权限。还要重点关注 Fiori 的权限目录和组因为 Fiori 的 Tile 可见性受 PFCG 控制很多用户反映“上了 Fiori 后看不到某个应用”绝大多数都是权限目录没配好。另一个常见坑是迁移后自定义程序调用了旧的事务代码但新角色没有分配对应的权限对象导致用户报错。Clean Core 实践里建议把自定义程序尽量用 OData 服务和 Fiori 应用暴露隐藏底层事务代码入口这样权限控制可以通过服务目录统一管理而不是给用户开一长串事务代码。3.2 从 MD07/MPS 到计划与执行的闭环MD07物料需求清单是物料管理和生产计划人员天天用的东西在 S/4HANA 里对应的是新的 MRP 应用比如 Manage MRP Groups。很多从 ECC 迁过来的用户会问为什么 MD07 找不到了其实它还在只是入口和界面变了。S/4HANA 里推荐用 Fiori 的 MRP 应用比如 Material Coverage、Manage MRP Exception它们的底层数据更加实时配合 HANA 的列式存储能力跑 MRP 清单的速度比 ECC 快一个量级。和 Clean Core 关系更密切的是 MPS 的优化。以前很多企业在 MPS/MRP 运行时会做大量自定义增强比如根据销售订单类型自动调整安全库存、按客户优先级分配可用量。这些逻辑如果是通过修改标准 MRP 程序实现的迁移后大概率会出问题。我更推荐的做法是把这类逻辑放到 BAdI 增强点里用官方的用户出口来实现并且在迁移前用 ATCABAP Test Cockpit检查增强点是否兼容。我的经验是MRP 相关的增强尽量用“事件”而非“修改程序”的方式去实现减少对标准逻辑的覆盖。如果你有一些旧的 MPS 分析逻辑例如从销售订单产生生产工单时自动根据物料主数据里的策略组决定计划方式这类逻辑在 S/4HANA 里完全可以通过标准的策略配置和 MRP 组配置实现不需要写增强。3.3 FICO 集成评估类、总账科目与凭证增强的清理财务模块在整个 Clean Core 转型里是工作量最大、风险最高的部分。因为财务数据牵连太广哪怕一个科目配置错误都会导致月末结账不平衡。S/4HANA 在财务上的核心变化是 Universal JournalACDOCA它把财务会计、管理会计、资产会计全部统一到了一张表上字段数量非常大所有模块过账都会写进 ACDOCA。在 ECC 时代评估类和总账科目的关系是通过“科目确定”的规则实现的很多公司为了适应特殊的存货计价会写一堆替代Substitution和校验Validation逻辑。到了 S/4HANA这些逻辑如果还挂在标准过账里很容易导致 ACDOCA 里的数据不一致。我在一个项目中遇到过一个问题物料移动过账时系统无法确定评估类对应的总账科目原因是标准科目确定规则被替代逻辑覆盖了而替代逻辑里引用的表在 S/4HANA 中已被弃用。这种情况必须重新梳理科目确定规则把替代逻辑尽量收敛到官方支持的增强点或者改用 S/4HANA 的扩展字段。财务凭证的“确认”和“替代”一直是 SAP“那点事”的经典话题。在 Clean Core 框架下会计凭证的确认Validation和替代Substitution属于核心中的核心SAP 允许使用但必须走标准的增强点比如 BADI_ACC_DOCUMENT。不能再用老的 USEREXIT 或者直接改标准程序。实操中如果你要判断一个凭证增强是否合格就看它是否在 ATC 检查中没有任何“过时 API”的警告。如果有警告升级后大概率会失效。另外评估类的配置也要注意S/4HANA 里物料账的激活方式有所变化如果启用了物料分类账评估类变化会影响实际成本核算。建议在项目计划里专门留出“财务日切测试”的窗口用真实业务数据跑一遍月结确认所有过账码、科目确定、增值税逻辑都没有脏数据再谈上线。3.4 MIRO 拆分增强与清账问题的处理采购发票校验MIRO是财务月结前的高频操作一旦出问题直接影响应付账款和后续清账。热搜词里可以看到很多人在搜“MIRO拆分增强”“MIRO贷项凭证提示完全冲销”“拆分增强后无法清账”这说明这几乎是所有做过 MIRO 增强的项目的共同痛点。为什么会出现 MIRO 拆分增强最常见的原因是业务需要一张发票对应多个采购订单、多个公司代码或者多个利润中心而标准 MIRO 的凭证流模型不支持某些拆分维度。于是 ECC 时代有人通过增强拆分行项目甚至绕过标准记账逻辑。在 S/4HANA 里一定要重新评估这种增强是否还有必要因为新的 Universal Journal 支持更多的行项目维度很多拆分需求可以通过配置“拆分规则”来实现而不需要写代码。如果确实需要增强我强烈建议用 BAdI BADI_INVOICE_CREATE 或相关的发票行项目增强点不要去修改标准屏幕和标准逻辑。而且必须特别注意清账逻辑拆分增强后财务后续做付款清账F-44时如果拆分出的行项目没有正确关联到原始发票凭证就会出现“清账时找不到未清项”的错误。解决这个问题的关键是在增强里保证拆分后的每个行项目都带有正确的参考凭证字段包括采购订单号、发票凭证号、行项目编号让系统在清账时能通过标准逻辑找到这些行项目。如果你正在维护旧系统里已有的拆分增强迁移到 S/4HANA 之前一定要先做一遍增强代码的兼容性检查。我在项目里遇到过的情况是旧的拆分增强里面用了一个内部表字段名和 S/4HANA 标准结构冲突编译都过不了。这种问题要在 UAT 之前就暴露不要拖到上线前。3.5 用 BDC/LSMW 清理存量数据的风险数据迁移时很多人喜欢用 LSMW 录屏的方式导主数据或者用 BDC 批量处理事务。这在 ECC 时代是常规操作但 S/4HANA Cloud Private 环境下由于 Fiori UI 替代了大量 SAP GUI 界面录屏 BDC 的兼容性面临很大风险。尤其是使用 Fiori 应用创建主数据时后台调用的 API 可能没有对应的 BDC 事务代码路径。我的建议是能调用 BAPI 或 API 的优先用 BAPI。例如创建物料用 BAPI_MATERIAL_SAVEDATA创建客户用 BAPI_CUSTOMER_CREATEFROMDATA1创建供应商用 BAPI_VENDOR_CREATEBP 主数据用 BAPI_BUPA_CREATE_FROM_DATA。这些 BAPI 在 S/4HANA 中仍然受支持返回的消息结构清晰容易做错误日志。LSMW 更适合那些没有 BAPI 的场景但需要确保录屏的事务代码仍然存在且行为一致。另一个常见问题是 BDC 在 SAP GUI 脚本模式下执行时如果系统开启了多语言登录录屏时的语言环境和执行时不一致会导致屏幕上按钮位置偏移BDC 报错。这类问题排查起来很费时间不如一开始就用标准 BAPI 或者采用 SAP 提供的 Migration Cockpit 进行数据迁移。Migration Cockpit 基于 CDS View 和 API向导式操作能自动校验数据是目前 S/4HANA Cloud 项目里更稳妥的选择。4. 常见问题与排查技巧实录4.1 Clean Core 审核不通过往往栽在自定义表上SAP 在云环境里对自定义表Z 表的管理有自己的规则。SAP 允许创建自定义表但建议使用带有“SAP 扩展字段”的方式而不是在标准表上大量加 Append 结构。很多项目的自定义表是因为业务报表需要直接把旧系统的 Z 表搬了过来但旧表里面有很多冗余字段甚至数据类型和 S/4HANA 标准字段冲突。我在审核一个项目时发现有一张 Z 表存了物料凭证的历史数据原本是为了弥补标准表查询效率低的问题。但 S/4HANA 中行项目已经存在 ACDOCA 和 MATDOC查询性能非常高Z 表完全多余。这种表断然删掉相关程序改成基于 CDS View 或 ADT 查询标准表。Clean Core 审核时SAP 会检查自定义对象的数量和使用范围如果自定义表过多且没有充分理由会被打回。审查团队不会关心你历史原因他们只关心你是否破坏了标准核心的扩展性。如果你确实需要自定义表建议遵循这些规则表名以 Z 开头但不要有下划线某些云环境限制字段尽量使用内置类型必须包含 MANDT 字段创建时选择“Delivery Class”为 A应用表而不是 C客户表主键尽量短不要直接物理删除数据而是通过 API 或定制的 Fiori 应用来维护。4.2 Fiori SM30 维护自定义表的新姿势在 SAP GUI 里SM30 是维护表的经典事务。到了 S/4HANA Cloud Private虽然 SM30 还能用但 SAP 官方更推荐把这些表通过 OData 服务暴露到 Fiori 里做成自定义维护应用或者使用“Custom Fields and Logic” App 来管理扩展字段。我见过很多客户在迁移后依旧让 Key User 用 SM30 维护自定义表然后因为权限控制不当出现了“生产数据被误改”的事故。Clean Core 思路下建议把自定义表的维护权限收口到少数管理员并且为业务用户创建基于 Fiori 的维护界面这样既能审计又能避免误操作。如果你通过 Fiori 开发自定义维护应用推荐用 RAPABAP RESTful Application Programming Model来实现。RAP 在 S/4HANA 2021 之后已经非常成熟支持表的 CRUD 操作、字段校验、关联查询等而且生成的 OData 服务天然符合 Fiori 的发布规范。比起老式的 Web Dynpro 或者 Screen PainterRAP 的开发效率和维护性都高很多。4.3 API 与 RFC 调用权限的坑S/4HANA Cloud Private 里核心系统和外围系统之间的同步大多通过 OData、SOAP、RFC 实现。Clean Core 原则下SAP 鼓励使用标准 API尤其是 OData 服务和 SAP 提供的“Communication Scenarios”。在传统系统里我们习惯为某个接口直接授权一个服务用户然后这个用户拥有很大的权限。云环境下这种做法会被严格限制因为所有接口调用都走通信角色必须按最小权限分配。我遇到过的坑是财务凭证从外围系统通过 BAPI_ACC_DOCUMENT_POST 调用时服务用户没有分配合适的“Start External System”权限对象导致调用直接返回“Authorization missing for object S_RFC”。排查这类问题除了检查 PFCG还要留意 S/4HANA 的 Communication User 和 Communication System 配置这两个对象把接口权限独立于业务用户管理比传统方式更清晰。另一个容易踩的坑是某些接口在开发环境能用一到生产环境就报“RFC destination not found”或者“Partner not authorized”。这是因为生产环境的 RFC 目标和信任关系没有配置。S/4HANA Cloud Private 虽然底层由 SAP 管理但客户仍然需要在 IAM 里配置通信系统并且需要在云连接器Cloud Connector里配置好暴露的 backend 资源。这些工作要在 UAT 阶段就完成验证不要拖到切换演练时才做。4.4 项目节奏与上线切换的经验从我的项目经验看Clean Core 转型项目最容易翻车的不是技术而是节奏控制。业务方通常不理解为什么要花那么多时间清理自定义代码他们只关心现有功能能不能保留。这个沟通成本如果处理不好项目很容易在“范围蔓延”中失控。建议把项目分成几个阶段第一阶段是现状评估和自定义代码清理第二阶段是系统转换与功能适配第三阶段是接口改造与数据迁移第四阶段是 UAT 与上线切换。每个阶段都要有明确的准入和准出标准尤其是第一阶段不要急着装 S/4HANA先把标准的自定义代码清单和清理计划做出来。切换方案上Cloud ERP Private 支持系统转换Migration和新实施Greenfield两种方式两者也可以结合——先做 ECC 到 S/4HANA 的系统转换再逐步重构有问题的自定义代码到 Side-by-Side。拜仁慕尼黑的案例很可能也是这个思路毕竟俱乐部的存量业务数据太复杂完全推倒重来不现实系统转换加净核才是更务实的路径。最后再分享一个我自己的体会Clean Core 不是一次性的改造项目而是一个需要长期维持的治理机制。很多团队在项目上线时把自定义代码清理得很干净但上线后业务一着急开发人员又开始在标准程序里临时改代码系统迅速重新变脏。要想让 Clean Core 落地既要靠技术工具比如 ATC 检查、代码评审、DevOps 流水线也要靠管理手段比如建立“自定义代码准入规则”任何新增的 ABAP 增强都必须经过架构评审优先给出标准配置或 Side-by-Side 的替代方案。拜仁慕尼黑选择 SAP Cloud ERP Private Edition背后是体育产业数字化对敏捷性和稳定性的双重需求。对于关注这个案例的同行我的建议是不要只盯着“上线”那一刻多想想上线之后如何保证核心持续干净。把 Clean Core 当成一项长期工程来做云战略转型才能真正产生价值。