SAP 清洁核心的拓展白皮书 - 如何实现清洁的拓展 (3)

本文内容主要来自 Clean core extensibility 白皮书

SAP 发现企业在实施定制化拓展时往往遇到很多问题，包括但不限于：标准功能是否满足需求，有哪些拓展方式是可选的，不同方式可以达成什么样的效果，未来该如何维护这些拓展才能保证持续的创新能力等等。

所以 SAP 推出了 Clean Core 方法论，为组织在拓展核心 IT 系统时提供指导意见，帮助组织打造一个清洁的核心。

清洁核心方法论下又包含了五个维度的清洁，分别是业务流程/拓展/数据/集成/运营 维度的清洁性，本白皮书主要关注拓展层面的清洁核心原则

本文包含了章节 4 的内容，主要介绍如何实现清洁的扩展，提供实用的、分步的治理、测量和实施清洁扩展的框架。涵盖工具、方法论（如 SAP 应用扩展方法论）和监控和执行 Clean Core 遵循的 KPI。

4 如何实现扩展性的 Clean Core？ 

4.1 Clean Core 测量框架

Clean Core 测量框架将成熟度评估与定量 KPI 相结合，推动持续改进：

4.1.1 治理与成熟度—— 评估 Clean Core 的方法

评估方法旨在批判性地评估和加强组织内的治理流程，使其与 Clean Core 最佳实践保持一致。它通过提供更深入、更注重实践的 Clean Core 治理视角来补充 RISE with SAP 方法论。

虽然这种方法涵盖了所有五个洁净核心维度，但本白皮书重点关注可扩展性。为此，评估框架围绕 12 个关键方面构建：7 个方面评估治理成熟度，5 个方面评估底层系统的就绪程度。

每个方面都代表了维护 Clean Core 所必需的独特治理领域。治理成熟度通过详细的评估标准进行衡量——按照从 0（未开始）到 5（专家级）的成熟度量表进行评分。这种评分使组织能够将其当前状态与目标成熟度水平进行基准对比。

通过识别每个实践当前得分与期望得分之间的差距，企业可以精确定位需要改进的领域。由此产生的洞察有助于定义有针对性的行动，然后可以在结构化路线图中对这些行动进行优先排序和调度。这确保了改进动作既实用又可在规定时间内实现，推动向强大的 Clean Core 扩展性框架持续进步。

4.1.2 可测量性：扩展性 KPI

这些 KPI 用于衡量 Clean Core 原则的遵循情况。它们来源于从客户系统收集和分析的数据。此外，我们还将解释如何计算这些 KPI，以及可以利用哪些工具让不同层级获得洞察。

下表提供了可扩展性相关 KPI 的高层次概述 

在以下内容中，将为每个 KPI 解释目的、测量方法和相关数据源。

 4.1.2.1 Clean Core 份额

 4.1.2.1.1 为什么测量 Clean Core 份额？

该 KPI 提供自定义代码对象如何在不同 Clean Core 等级中分布的全面概述。它帮助识别可能需要立即关注的领域以及可以期待改进的地方，例如，减少等级 D 对象的比例。

4.1.2.1.2 Clean Core 份额的洞察是什么？ 

Clean Core 份额根据 Clean Core 等级概念，基于其最差参考等级，对每个自定义代码对象进行分类。

4.1.2.1.3 如何测量 Clean Core 份额？ 

Clean Core 份额通过根据其最差/最低参考等级对每个对象进行分类来计算。

例如，如果某自开发对象甲引用了内部对象，则被归类为等级 C，而 ABAP Cloud 模式下的自开发对象被归类为等级 A。份额计算为所有自开发对象在各等级的分布，例如，等级 A：10%（100 个自开发对象属于等级 A），等级 B：50%（500 个自开发对象属于等级 B），等级 C：35%（350 个对象），等级 D：5%（50 个对象）。

4.1.2.2 技术债务评分

4.1.2.2.1 为什么要测量技术债务评分？

虽然 Clean Core 份额提供总体概览，但技术债务评分更具可操作性。它量化每个自定义代码对象中技术债务的程度，提供影响系统可维护性因素的清晰客观衡量。

4.1.2.2.2 技术债务评分的见解是什么？ 

技术债务评分按对象计算，可以按各种标准（如开发包）聚合。它通过衡量每个对象与理想 Clean Core 等级 A 的偏差，突出扩展中最大技术债务的位置。当与扩展对象的大小结合时，技术债务评分有助于确定债务的相对规模。

4.1.2.2.3 如何测量技术债务评分？ 

技术债务评分是基于对 SAP 对象引用严重性的加权评分。例如 ABAP 测试驾驶舱 test cockpit 中报错的权重因子分分布为：每个错误 10 分，每个警告 5 分，每个信息消息 1 分。评分是这些加权值的总和。示例：5 个错误、20 个警告和 10 个信息消息导致评分为 5*10 + 20*5 + 10*1 = 160 分。

4.1.2.3 未使用代码份额 

4.1.2.3.1 为什么测量未使用代码份额？

每个自定义代码对象都代表潜在的技术债务。识别和移除未使用的代码对象对于维护清洁高效的系统至关重要。

4.1.2.3.2 未使用代码份额的见解是什么？ 

自定义对象是 SAP 标准之外的客户创建扩展。Clean Core 的一个关键目标是最小化未使用自定义对象的数量。未使用代码份额测量未被使用的自定义对象比例，突出潜在清理和优化领域。

4.1.2.3.3 如何测量未使用代码份额？ 

测量未使用代码份额需要激活使用数据测量。推荐使用 ABAP 调用监控器（SCMON）收集此数据，以及事务 SUSG 用于随时间聚合使用数据。

基于系统中自定义对象的总数，可以确定未使用对象的份额。例如，如果 1,000 个自定义对象中有 300 个未被使用，则未使用代码份额为 30%。

4.1.2.4 业务修改（在 RISE with SAP 方法论仪表板中可用） 

4.1.2.4.1 为什么要测量业务修改数量？ 

修改涉及对扩展点之外的 SAP 标准代码的更改。因此，它们通常构成升级风险并可能导致额外的维护工作。

4.1.2.4.2 业务修改数量的见解是什么？ 

业务修改是经典扩展方式的子集，记录在 SMODILOG 表中。它们解决 SAP 标准功能的差距，但不符合 Clean Core 原则且影响升级。测量此 KPI 有助于识别此类修改的程度，突出对更清洁扩展实践的需要。

4.1.2.4.3 如何测量业务修改数量？

修改分析解释了如何从 SAP 表 SMODILOG 提取数据，以识别非有意创建为业务修改的技术修改。结果可以在自定义代码分析仪表板或 RISE with SAP 方法论仪表板中查看（参见第 4.4.1 章的示例）。

4.2 通过"保持清洁"和"获得清洁"达到 Clean Core

在 SAP 扩展性中实现 Clean Core 需要一个结构化的、持续的治理过程，引导每个扩展朝着最小化技术债务，并同时最大化业务价值的方向发展。两个互补的模式指导用户如何实现这种效果：保持清洁和获得清洁。

保持清洁专注于防止扩展积累不必要的复杂性。它首先严格评估功能需求。任何候选新扩展必须是无法通过标准 SAP 功能解决的，有清晰的业务场景的（反映 Clean Core 在业务流程维度的原则）。

接下来是扩展架构设计，这一步确保通过治理化、结构化的框架（如 SAP 应用扩展方法论）选择最适配的架构方法，并记录透明的，可复用的文档。在扩展实施期间，开发人员接受集中支持和控制——如授权检查和自动化质量工具（如 ABAP 测试驾驶舱）——以确保他们遵循架构标准，同时对任何偏差进行彻底的文档记录和治理。最后，通过了强制合规和质量检查的代码进入生产。

获得清洁通过解决现有技术债务来补充“保持清洁”这种预防性方法。它涉及测量相关 KPI 以精确定位改进目标，采用"童子军原则"，鼓励开发人员在任何期间努力使代码更清洁，并为遗留代码中的技术债务减少设定目标。这些模式共同建立了一个整体、迭代的治理框架，维护扩展性的 Clean Core 基础，平衡创新速度与长期系统可维护性。

以下章节将探讨基于这种方法实现 Clean Core 所涉及的步骤。

4.3 保持清洁：如何创建清洁的扩展

4.3.1 功能需求

功能需求是标准 SAP 解决方案未满足的业务需要。它们通常在适配标准 Fit-to-standard 会议期间识别，并在 SAP Cloud ALM 中管理，后者将功能需求与业务流程链接。虽然功能需求很常见，但数据隐私、安全性和可扩展性等非功能方面的考虑也是扩展设计的关键驱动因素。

4.3.1.1 需求收集 

适配标准 Fit-to-standard 研讨会的关键目标之一是确保收集适当的需求。SAP Cloud ALM（RISE with SAP 方法论的组成部分）通过提供在业务环境中以简单格式创建需求的功能来简化需求收集过程。识别需求和定义扩展与 Clean Core"流程"原则密切相关。无论流程是 SAP 标准流程还是客户流程。有关基于行业标准构建韧性业务流程和评估差异化扩展需要的更多指导，请参考 SAP S/4HANA Cloud Clean Core 业务流程白皮书。

需求可以分解为更小的用户故事，但业务用户在最一开始时只是陈述需要；专家顾问需要稍后确定最佳解决方案，无论是通过配置还是扩展开发。

当功能差距需要扩展时，必须以 Clean Core 合规的方式开发。这意味着扩展必须与 SAP S/4HANA Cloud 代码解耦，以确保它不会破坏升级（例如由于数据损坏或系统故障）。Clean Core 扩展性模型旨在实现这种分离，允许客户从 SAP 获取持续创新而不受干扰。

4.3.1.2 治理：建立并遵循 Clean Core 指导原则 

强大的治理框架对于维护 Clean Core 至关重要。主要目标是尽可能接近 SAP 标准，确保任何偏差提供清晰的增值差异化。这涉及建立分段的业务流程层次结构，将业务流程分类为标准、差异化（增强和自定义开发）和创新层，以优化资源分配并将开发重点放在高影响领域。

图 9 展示了当前和目标

流程类别分布之间的示例比较，强调标准和创新流程的增加。

一旦业务流程符合 Clean Core 要求，就更容易确定偏离标准的地方。清晰的治理过程确保可以选择最佳的拓展方式。

如前所述，重要的是最小化扩展的使用以降低 ERP 系统的复杂性和维护开销。根据这一目标，扩展的批准应该由明确定义的治理结构允许。组织必须为评估扩展设定高标准。每个扩展的理由和提供的预期业务价值必须清楚记录。

图 10 概述了在 SAP 系统内评估和实施新业务需求或差距的结构化决策过程，支持制造或购买决策。

如果用例不能被标准解决方案覆盖，且足够有价值，以证明自定义扩展的合理性，流程将继续进行扩展架构方法以进行实施 

根据功能需求定义和文档期间概述的设计，将应用 SAP 应用扩展方法论（参见下一章）来定义扩展架构。

通过建立中央权威机构或团队（如解决方案标准化委员会）来监督 SAP ERP 中业务流程的设计和实施，验证扩展的必要性并确保首先考虑 SAP 标准选项，可以实现对待开发流程、业务需求和设计批准的集中治理。这使组织能够：

• 在满足业务需求的同时使所有流程与最佳实践保持一致

• 根据个人需要强制执行"清洁"开发

• 要求对选定的扩展域进行清晰文档记录和证明

• 确保所有偏差以标准化和一致的方式得到批准

4.3.1.3 使用 SAP Cloud ALM 支持 Clean Core 治理

SAP Cloud ALM 对于建立 Clean Core 至关重要。通过利用 SAP Cloud ALM，组织可以采用 SAP 的最佳实践内容，管理适配标准研讨会，并简化其需求管理流程。这有助于限制定制，降低复杂性并维护核心系统的完整性。集成的分析和可追溯性功能提供 Clean Core 合规性的清晰视图，使企业能够有效跟踪和管理其项目。

为了根据既定的 Clean Core 治理对 SAP Cloud ALM 实体进行分类，可以为流程、需求、用户故事和功能创建标签（例如"清洁"和"不清洁"）。

这些标签可以应用在 SAP Cloud ALM 的解决方案流程可追溯性报告上。它们允许评估计划或实施的解决方案流程以及分配的需求、用户故事和功能是否被分类为"清洁"或"不清洁"。从此视图，用户还可以导航到相关的可追溯性和概述页面（例如需求可追溯性）以检查更多详细信息。

4.3.2 扩展架构

SAP 应用扩展方法论为客户和合作伙伴定义组织特定扩展策略提供结构化、技术无关的方法。 

遵循此方法论确保所有相关者使用相同术语，并快速达成对业务场景和解决方案的共同理解。

阶段 1 专注于基于定义区域内的业务需求。它涉及理解系统环境并相应记录扩展程序场景。

阶段 2 引入关键概念，如扩展样式、扩展任务和扩展域。它提供称为技术扩展构建块的各种扩展技术概述。结合扩展任务，它们帮助将业务需求转化为技术需求。

阶段 3 基于整体需求以及前一阶段扩展任务和构建块之间的技术映射，支持对目标解决方案使用哪些技术扩展构建块的明智决策。各种决策指导资产——如扩展架构指南、SAP Discovery Center 和 SAP 架构中心——在塑造和完善目标解决方案方面提供进一步支持。

为了进行彻底分析，组织应该使用扩展任务指导模板和扩展任务技术映射模板，在选择技术栈之前记录自定义指导。

此过程支持开发清晰的设计指导，以确保考虑最佳 Clean Core 等级。SAP 应用扩展方法论模板还协助设定排序和评估标准，以选择最合适的技术构建块。

开发人员可能偏好熟悉的工具而非最优解决方案，特别是当他们不熟悉 ABAP Cloud 或 SAP BTP 功能时。这种结构化方法有助于指导架构决策。

完成方法论后，产生几个交付成果：应用程序扩展用例描述（来自阶段 1）、技术扩展构建块决策（来自阶段 3）和扩展目标解决方案（来自阶段 3）。这些交付成果可用作 SAP Cloud ALM 用户故事的输入。

有关 SAP 应用扩展方法论的更多信息和访问模板，请访问 SAP 帮助门户。

4.3.3 扩展实施

建立 Clean Core 思维

良好的开发实践涉及编写不仅解决即时需求，还考虑远期价值：清洁的架构、系统稳定性、长期可维护性以及与组织未来策略的一致性。一个实际例子：基于 ABAP 列表查看器网格 List Viewer grid 创建的报告在系统升级期间可能不会造成问题，但当组织计划迁移到 SAP S/4HANA 公有云时，它就会成为技术债务。

代码不仅仅是技术性的——它是战略性的。

然而，采用 Clean Core 思维超越了编写代码。它还涉及花时间考虑复用，重新评估开发方法而不是匆忙实施。Clean Core 思维塑造了扩展的规划和执行方式。

开发指导原则

为了将 Clean Core 思维转化为日常实践，建立清晰的开发指导原则很重要。这些指导原则有助于确保一致的实践，无论是关于使用正确的 API、避免某些增强，还是遵循命名约定和编码标准。

当规则清晰时，开发人员可以专注于构建高质量、面向未来的解决方案，而无需猜测业务的期望。

明确定义和记录的标准也使新开发人员更容易入职，并在不同项目中保持一致。这些指导原则应该易于访问、定期更新，并通过自动化代码检查和同行评审等工具得到加强。有了这样的结构，团队将有坚实的基础。虽然这些指导原则可能总是个性化的，但在开发指导原则方面有很好的起点可以考虑和参考：

• "在云端和本地使用基于 ABAP 的扩展扩展 SAP S/4HANA"指南

• 清洁 ABAP 指南和备忘单

• ABAP 备忘单

技能发展

在建立开发规则后，重要的是根据员工的角色和技能分配任务：开发人员需要学习如何为 SAP S/4HANA 构建现代业务应用程序，并从经典 ABAP 开发人员发展为 ABAP Cloud 开发人员。

SAP Learning 提供几个免费学习路径，如：

• 获得核心 ABAP 技能

• 管理 SAP S/4HANA Cloud 的 Clean Core

• 实践 S/4HANA Cloud 的 Clean Core 扩展性 

这些路径有助于准备获得 SAP 认证助理——后端开发人员——ABAP Cloud 认证。

此外，首席开发人员和架构师应该扩展其知识以保持扩展开发的全面视图。这可以通过成为 SAP BTP 解决方案架构师的学习路径实现，该路径也提供认证。

这个启用过程需要时间和管理承诺。为相关主题建立一个或多个卓越中心 COE 可以支持推广并有助于推动整个组织的 Clean Core 采用。

开发清洁的扩展

在实施开始时，识别与 SAP 标准的所有接触点至关重要，如用户界面（应用程序、表单、报告）、集成（集成流、事件）、业务逻辑（业务附加组件）、API（CDS 视图、业务对象接口、BAPI）以及持久性（表）。这种方法有助于澄清与 SAP 标准和核心的所有潜在依赖关系，并显示扩展的耦合程度。

有了这些信息，应该使用自顶向下的方法规划开发，从 Clean Core 等级 A 到 Clean Core 等级 D，从紧密耦合过渡到松散或完全解耦的扩展。

对于紧密耦合的扩展，起点是 SAP S/4HANA 关键用户扩展性选项（等级 A），并搜索合适的扩展点。发布的扩展点可能是，例如，业务环境中的字段扩展或业务逻辑扩展。识别这些发布扩展点的方法可能因特定 SAP ERP 部署模型（SAP S/4HANA 公有云、SAP S/4HANA 私有云或 SAP S/4HANA）和版本而异。

在较旧的 SAP S/4HANA 版本上，可能需要直接在目标应用程序的文档中检查扩展性选项。可以通过在 SAP Fiori 应用程序参考库中搜索相应系统版本的应用程序、导航到实施信息选项卡并找到扩展性部分来访问。那里链接的应用程序扩展性文档提供有关扩展性选项的详细信息，如用于此应用程序的业务上下文。对于其他对象，可以使用事务 SCFD_REGISTRY 查找系统中注册的每个扩展点。

当需求过于复杂而无法通过关键用户扩展性实现时，需要使用开发人员扩展性（等级 A）的扩展。在”体外 Side by Side”或混合扩展域中，流程通常从探索 SAP Business Accelerator Hub 上的远程公共 API 开始，如 OData 服务、REST 服务或可以从核心系统公开的事件。SAP Business Accelerator Hub 为使用这些 API 提供全面资源，包括业务文档和扩展选项详细信息。对于”体内 On Stack”扩展，可以使用 Eclipse 的 ABAP 开发工具通过基于 API 状态过滤对象来识别发布的公共 API，如 CDS 视图、业务对象接口或业务附加组件。

注意：必须查看每个 API 的引用业务文档，因为某些 API 可能不合适——例如，如果业务功能未实现。如果适用，检查是否存在前身经典 API。

当已知经典 ABAP 对象时，用户可以通过检查 API 状态属性或咨询云化存储库来识别后续对象。

云化存储库还提供对发布 API 未来的一瞥。通过选择所需的系统版本，可以检查 API 是否将在即将发布的版本中变得可用。如果不存在发布的本地公共 API，下一步是在云化存储库中探索经典 API（等级 B）。

要识别合适的扩展技术或框架，请参考 SAP 注释 3578329，它将遗留技术分类为 Clean Core 等级并提供推荐使用的清晰指导。

当超出等级 A 的边界时，开发人员应该在应用程序开发期间实施额外的保护措施。由于内部对象可能不稳定，监控 SAP 对象变更日志以接收有关不兼容变更的早期警告并在使用此类对象时格外小心是至关重要的。为了验证预期行为，应该创建单元测试并在每次系统升级后运行，特别是使用内部或不推荐对象时。

SAP 强烈建议在等级 A（ABAP Cloud）内最大化开发，以减少对等级 B 到 D 对象的依赖。一个有效策略是在包装器内封装经典 API、内部对象或不推荐对象，然后可以使用 API 合同为 ABAP Cloud 公开。详细信息可在 ABAP Cloud API 启用指导原则中找到。

4.3.4 扩展部署 

一旦扩展按照 Clean Core 方法设计和实施，下一个关键步骤是通过结构化治理和技术控制来强制执行这些原则。即使是最严格的开发策略也可能被单个未审查的传输或管理不当的豁免所破坏。

为了确保长期可持续性、代码质量和系统稳定性，必须将自动化执行和问责机制直接嵌入到开发和部署流程中。

图 14 显示了不同的 Clean Core 治理选项，在以下段落中解释。 

在非 ABAP 环境中，使用静态代码分析工具（例如，CAP 的 CDS Lint）来确保代码遵循定义的编码规则。SAP S/4HANA 系统内运营 Clean Core 治理的核心依赖于使用 ABAP 测试驾驶舱的自动化检查。这些检查应该紧密集成到传输释放流程中。SAP 提供预交付的 ABAP 测试驾驶舱变体，作为强制执行 Clean Core 规则的可靠基准。鼓励组织定制这些变体以与其内部政策保持一致。

将这些变体纳入传输释放流程确保每当开发人员释放传输时检查自动运行。当识别出高优先级问题（通常是优先级 1 或 2）时，应该阻止传输，直到违规得到解决或通过定义的治理流程明确豁免。

要为经典 ABAP 开发模型设置治理，请参考 ABAP 扩展性指南。

然而，如果没有结构化的豁免流程，任何执行策略都是不完整的。虽然 Clean Core 政策应该严格应用，但可能出现合理的例外情况。应该建立正式的豁免程序，由指定的质量经理（理想情况下是高级开发人员或架构师）负责审查并批准或拒绝请求。每个豁免请求必须包括清晰的理由。所有决策必须记录在 ABAP 测试驾驶舱内，以确保完全可追溯性和问责制。应该为每个豁免定义时间限制，并且应该避免在对象或包级别的广泛豁免。现有豁免的定期审查，通常涵盖 10-20%的案例，有助于验证持续相关性并支持开发指导原则的持续完善。

为了在结构上强制执行 Clean Core 开发，最有效的措施之一是将 ABAP 语言版本限制为 ABAP Cloud。这种限制可以通过分配 S_ABAPLNVS 授权对象和/或创建仅支持 ABAP Cloud 的专用软件组件来实现。建立这样的组件引入了清晰的架构边界，并允许开发人员角色的分离。

标准 ABAP Cloud 开发人员可以与具有提升权限的受信任开发人员区分开来，使管理谁被允许使用遗留或无限制对象变得更容易。这种分离增强了透明度，简化了维护，并降低了引入不合规代码的风险。

除了管理语言版本限制外，组织应该激活监控 API 使用和增强技术的 ABAP 测试驾驶舱检查。这些检查在 SAP 注释 3565942 中提供，通过基于稳定性和升级安全性对 API 和技术进行分类，来引入 Clean Core 等级。有关设置详细信息，请参考 ABAP 扩展性指南中的"为经典 ABAP 开发模型设置治理"章节。

当使用等级 B、C 或 D 对象时，开发人员本质上使用标准 ABAP 语言版本，这是包括 ABAP Cloud 和关键用户 ABAP 的超集。虽然使用 ABAP Cloud Readiness check variant 就绪检查变体不是必选，但强烈推荐。激活此变体有助于减少对标准 ABAP 语句的不必要依赖，并促进等级 A 中云就绪和升级稳定代码的开发。

为了支持等级 A 对象的使用并进一步增加其份额，组织应该为“未发布的”SAP 对象创建封装包装器。这些包装器可以发布供 ABAP Cloud 使用，有效地弥合不合规遗留代码和现代合规开发实践之间的差距。

自动化 ABAP 单元测试在维护代码稳定性方面发挥重要作用，特别是在处理经典 API（等级 B）、不确定稳定性的对象（等级 C）或缺乏正式 API 的开发（等级 D）时。虽然结构性变更（例如，重命名字段）通常可以在编译时检测到，但行为变更，如改变的逻辑或计算，通常不会被注意到。ABAP 单元测试充当此类回归的保护措施，确保即使底层实现发生演变，预期的代码行为也得到维护。

SAP 在 SAP 对象变更日志中持续发布经典 API 和内部对象的更新。通过定期审查此变更日志，开发团队可以主动识别潜在的破坏性变更，进一步加强系统稳定性。

最后，培养透明度和持续改进的文化至关重要。从 ABAP 测试驾驶舱扫描和豁免审查中获得的见解应该与更广泛的开发团队分享。这种开放性建立了维护高质量、合规代码的共同责任感，并鼓励持续学习和完善。通过将治理深度集成到工具和文化中，组织可以确保其 SAP 环境保持稳定、可扩展，并为未来创新做好准备。

4.4 获得清洁：如何测量 Clean Core 的当前状态？

 4.4.1 RISE with SAP 方法论仪表板

RISE with SAP 是来自 SAP 的综合之旅，将几个元素捆绑在一起，支持客户的数字化转型，用 SAP Business Suite 替换遗留系统。它以 RISE with SAP 方法论为基础，沿着个人云转型路径全面引导客户，降低复杂性并为各种规模的企业促进更平滑的过渡。它帮助本地客户在云中现代化其业务流程，基于 Clean Core 原则，以实现持续创新。

该方法论在一系列定义阶段中提供结构化指导和推荐步骤。它由 SAP 专家和合作伙伴支持，并通过工具和服务实施。该方法论基于 Clean Core 策略，所有服务和工具协同工作，在整个生命周期中支持客户。

RISE with SAP 方法论遵循标准化框架，帮助公司更快地采用 SAP Business Suite 应用程序，并提供与其特定业务需求一致的定制转型路线图。它利用集成工具链进行简化协作和高效项目执行，确保整个过程中的内聚、高效工作流。该方法论通过端到端参与模型由 SAP 和合格合作伙伴的专家指导。

当客户踏上转型之旅时，他们需要提供当前状态可见性、关键项目进展以及指导下一步和策略的见解的工具。这就是 SAP Cloud ALM 中的 RISE with SAP 方法论仪表板变得必要的地方，帮助组织保持其 ERP 系统敏捷、创新，并为持续改进而优化，以释放 SAP 解决方案的全部价值。

RISE with SAP 方法论仪表板对于采用 Clean Core 方法的企业发挥关键作用。通过专注于韧性流程和高效运营，组织可以实现无缝集成。采用标准流程增强了整体一致性，而创建独特扩展的能力促进了差异化。这种方法确保业务关键系统保持敏捷、成本效益，并为创新做好准备。

RISE with SAP 方法论仪表板支持客户的转型之旅。拥有 RISE with SAP 合同的客户可以访问 SAP Cloud ALM 启动板上的 RISE with SAP 选项卡，从中可以打开系统视图仪表板。此仪表板提供系统 Clean Core 合规状态的清晰概述。

在系统视图中，客户可以验证安装在其系统上的当前 SAP S/4HANA 产品版本是否最新，并确保收集 Clean Core 相关数据所需的工具处于活动状态且按预期运行。最后，他们可以审查当前扩展，以评估和准备下次升级中的任何潜在问题。

一般来说，RISE with SAP 方法论仪表板中的系统视图包括以下选项卡：

• 软件堆栈

为您提供系统软件堆栈的概述，并提供为您的系统运行的最新 SAP S/4HANA 升级就绪检查的关键结果。

• Clean Core 工具状态

此部分显示收集 Clean Core 相关数据所需工具的状态。这里提到的每个工具都提供测量系统 Clean Core 合规性所必需的数据。

• 扩展性

此部分提供不同扩展性相关 KPI 的概述（另见"可测量性：扩展性 KPI"章节）。系统视图中 RISE with SAP 方法论仪表板当前提供的 KPI 包括：

– ABAP Cloud 开发设置

显示您是否遵循创建 ABAP Cloud 软件组件的建议。

– 未使用的客户对象（另见可测量性：KPI 章节）

– 客户对象执行

显示可执行客户对象在您的系统中运行的频率，与系统中所有可执行对象（包括 SAP、合作伙伴和客户对象）的总执行次数相比较

– ABAP Cloud：等级 A 客户对象

代表有限的 Clean Core 份额视图（另见可测量性：KPI 章节），因为只考虑等级 A 对象

– ABAP 经典：业务修改

属于不推荐扩展组，因为业务修改既不升级稳定也不云就绪

注意：

客户已经可以使用 ABAP 测试驾驶舱测量新扩展性概念中定义的等级。

然而，这些等级尚未在 RISE with SAP 方法论仪表板中可视化。计划在未来版本中进行完整的仪表板集成。

4.4.2 单独评估 Clean Core KPI

虽然 SAP 通过 RISE with SAP 方法论仪表板提供了跟踪 KPI 的强大框架，但某些场景可能需要比标准仪表板中当前或未来版本可用的更细粒度的见解。一个常见需求是应用个别过滤和分析标准，最常见的是将包和命名空间映射到业务单位，允许不仅在系统级别而且跨组织边界分析 Clean CoreKPI。

虽然第 4.4.1 章讨论了通过 RISE with SAP 方法论仪表板提供的标准方法，但也可以手动提取底层 KPI 数据，特别是对于第 4.1.2 章中描述的 KPI。特别是，Clean Core 份额和技术债务评分等指标可以通过利用基于其引用元素和 ABAP 测试驾驶舱检查结果对自定义代码对象进行分类的 SAP 工具来计算。

为了进一步定制并使技术债务评分与特定环境和治理流程保持一致，SAP 推广开源自定义 ABAP 测试驾驶舱检查项目 Kernseife。它支持集成 SAP 对象的自定义分类模型，以导出适合独特组织需求的技术债务评分。这种方法产生更可操作的见解，并增强了在减少技术债务方面优先干预的能力。

4.5 如何实现 Clean Core

每个 Clean Core 之旅都是独特的。

本白皮书概述了一般策略和原则，但您自己的方法将由您的起点和未来几年设定的战略目标塑造。无论您是已经在 SAP S/4HANA 上严格的 Clean Core 规则下产品化运营、准备带有遗留扩展的系统转换，还是启动绿地实施，您的路径都会有所不同。

无论从哪里开始，Clean Core 都是一种可以——且需要——根据特定需求定制的方法。一些组织可能已经接近其理想状态，而其他组织需要管理通过多年或数十年自定义开发积累的技术债务。无论您的出发点如何，两个关键目标是普遍有效的：

1. A) 保持清洁

对于所有新开发，您的目标应该是严格遵循 Clean Core 原则。这意味着通过确保每个扩展遵循明确指导原则来避免任何不必要的技术债务。如"保持清洁：如何创建清洁扩展"章节中强调的，这需要强大的治理、最新的指导原则，并通过持续培训和技能提升来启用您的开发团队。即使您的组织尚未使用 SAP S/4HANA 2022 或仍在运行 SAP ECC，您也可以通过应用尽可能多的 Clean Core 模型开始。例如，基于 SAP BTP 构建的扩展已经可以实施。通过现在建立这些习惯，您为未来在当前 SAP S/4HANA 版本上向"清洁"ABAP Cloud 扩展的过渡奠定了基础。

1. B) 获得清洁

接下来，专注于您现有的环境——或您正在构建的环境。首先使用 RISE with SAP 方法论仪表板或 ABAP 测试驾驶舱等工具测量技术债务。使用此基准推动您的长期减少策略：识别未使用或过时的代码，优先处理灯塔扩展（当您需要重新工作时用清洁技术重建这些），并设定现实但雄心勃勃的目标——如初始减少目标 10%。记住，未检查的技术债务将继续增长，但持续的增量改进，如采用"童子军原则"（总是让代码比发现时更清洁），会随着时间的推移累积。

Clean Core 是一个持续的旅程，不是一次性努力。进展不仅通过技术衡量，还通过流程、治理的成熟度，最重要的是——您的人员。根据您的业务优先级调整您的方法，始终平衡有针对性的改进与它们为业务增加的价值。

4.5.1 Clean Core 之旅的关键步骤和建议

虽然每个 Clean Core 之旅会因目标、当前情况和系统历史而不同，但以下摘要像指南针一样指导您的旅程：

• 建立清晰的治理：定义清洁扩展指导原则，确保它们涵盖所有相关的 SAP S/4HANA 或 SAP ECC 开发。

• 赋能您的治理：涉及业务和技术团队——都由高层管理的明确承诺支持。

• 评估您的起点：清楚了解您当前的技术债务和 Clean Core 采用情况。使用工具测量并创造透明度。

• 提升和赋能您的开发人员：定期培训您的团队 Clean Core 原则和新功能（如 SAP Build 中的 ABAP Cloud）。

• 为转换场景调整：如果您正在迁移，与 SAP S/4HANA 功能变更保持一致，并在可行的情况下减少范围或复杂性。

• 设定增量、可实现的目标：制定雄心勃勃但现实的技术债务减少目标（例如，每年 10%）。

• 优先考虑业务价值：将修复工作重点放在具有切实业务影响的代码和定制上。

• 持续监控和改进：将 Clean Core 测量和改进纳入常规开发周期和审查中。

• 采用"童子军原则"：鼓励在每次变更时增量清理代码的文化。

• 为未来做准备：利用当前机会（如 SAP BTP 扩展）并为随着环境演变的进一步 Clean Core 采用奠定基础。

通过一致地按照这些原则行动，您的组织可以限制技术债务，提升敏捷性，并构建准备好持续创新的韧性 SAP 环境

文章整理：Arthur Yang

文章来源：https://mp.weixin.qq.com/s/Yv_BmaG7-p6ae3RFjtXQcQ