《SAP S/4HANA Architecture》——清洁核心：ERP的下一站（下）

在上篇《SAP S/4HANA Architecture》——清洁核心：ERP的下一站（上），我们聊了S/4HANA的前两层变革：数据层用VDM和CDS把散落的表变成了统一的对象；逻辑层用RAP和三种扩展方式把个性化从核心中剥离出来。清洁核心的“地基”已经筑牢。

但一个现代企业系统不能是孤岛。有了干净的数据和逻辑，S/4如何与外部世界安全对话？如何让用户用得爽、让企业管得省？

这篇，我们继续攀登后两层：连接层（从私有协议到开放标准）和交付层（从功能到服务）。如果说前两层是“造好一辆车”，后两层就是“铺好路、让人开得顺”。

第三层：连接层——从“私有协议”到“开放标准”

一个企业系统不是孤岛，S/4 HANA需要跟外部系统连接。可能的原因有多种：

SAP产品间需要链接。SAP S/4 HANA只是SAP家族中的一员，需要与其他SAP 产品交互；
混合部署的现实。许多企业处于过渡期，有的模块在ECC上，有的模块在S/4 HANA上，需要链接交互；
数字化转型需求。企业需要从不同合作伙伴之间进行交流，使用的可能是不同的系统，例如电商平台、物流系统、仓管系统等等；

这部分内容解决的，是S/4 HANA如何与外界对话的问题。

从私有协议到标准API ---> 主要接口技术（用什么对话）

ECC时代，SAP与外界的对话主要靠RFC、IDoc这些私有协议。它们性能好、功能强，但有个致命问题：非SAP系统很难直接调用。你要连一个电商平台，得先装SAP RFC SDK，还要在防火墙上开一堆端口，麻烦且不安全。

S/4HANA的战略方向是：用开放的行业标准替代私有协议。

下面是SAP S/4 HANA主要接口技术：

不同的部署方式对接口技术的支持存在差异：

这张图的指导意义非常直接：在公有云环境中，你必须拥抱以OData为代表的现代API；而本地和私有云部署，则为你提供了更灵活的过渡方案。

2. S/4 HANA Cloud的沟通管理(云专属)--> 通信管理（API权限管理）

上面提供了那么多接口、那么多语言，他们解决的问题是：用什么对话的问题。

但是对外开放还有更重要的问题需要解决：权限管理（谁可以进来、进来能做什么）。

在传统的本地部署环境中，这个问题通常通过SAP GUI的权限管理（PFCG角色）来解决：你给一个用户分配角色，他就能登录系统、调用事务代码、执行RFC函数。这种方式对“人类用户”很友好，但对“系统用户”（比如电商平台、第三方应用）来说，就不太合适了。例如，系统user不需要登录GUI/ 系统user往往只需要个别API权限，传统角色容易过大/系统的会话机制与人不同等等。

S/4 HANA 公有云中，这个问题被彻底重构了。SAP引入了一套专门针对“系统到系统”通信的权限管理模型，这就是通信管理（Communication Management）。

通信管理的本质：API权限管理。

管理的核心组件是通信安排（Communication Arrangement），它由三个要素构成：

通信场景（Communication Scenario）：预定义的业务能力包，比如“销售订单集成”。它规定了允许调用哪些API、需要什么认证方式、是入站还是出站。
通信系统（Communication System）：外部系统的地址、端口、协议、认证信息。
通信用户（Communication User）：专门用于API调用的技术账号，没有GUI登录权限。

当你配置好一个通信安排，相当于你做三件事：

明确了谁（通信用户）要来
明确了从哪来（通信系统的地址）
明确了能干什么（通信场景定义的API）

系统会生成一个唯一的API端点，外部系统拿着通信用户的凭证，就能安全地调用指定API。

几个要素的关系如下：

这里Scenarios似乎重复了，但其实也不重复：上面是预定义模板，下面是实例。

注意：传统PFCG角色管理的是人类用户，通信安排管理的是系统用户。两者完全分离，各司其职。

至此，接口协议确定了，外部系统的权限设置也妥当了，就可以开始调用了。

但是新的问题又来了：通常简单场景直接调用API即可，但是如果是多系统、多应用，就会变得麻烦且容易混乱，怎么办？（这里针对云的讨论）

3. SAP Integration Suite-->调度中心

SAP的不同应用之间的集成：

简单情况：在大多数的情况下，直接链接 --> API
复杂情况：特定场景、复杂场景，需要专门的集成中间件 -->S/4 HANA给出的答案：SAP Integration Suit
注意，中间件并不是替代API，而是对API进行编排和管理
这里做了一些关系图，尝试理清他们的位置、作用和关系：

需要注意，SAP Integration Suite并不是S/4 HANA的内置功能，而是BTP上的核心服务。另外，它是一个云平台，但它不是“云”专属的，因为通过混合部署能力，可以无缝延伸到本地环境。

怎么连接到本地呢？说到混合部署，需要提一个组件“云连接器（Cloud Connector）”。

4. 云连接器（Cloud Connector） --> 解决云与非云的连接问题

云连接器，是一种安装在本地网络中的计算机上的组件，用于实现云应用与本地应用之间的通信。即，它解决的是本地跟云连接的问题。

功能包括：

建立安全隧道（不需要在本地防火墙上开放入站端口）
资源映射与访问控制（最小权限原则）
协议转换与路由

云连接器只是开路，不负责真正运输和调度。下面这个图就很形象地理清他们的关系了，注意S/4 HANA， BTP和Integration suite的位置。

至此，系统间集成的接口问题、权限管理问题、调度问题都解决了，那集成就完整了么？还没有！

前面解决的问题都是针对“主动调用”的场景，是为主动调用做准备。但是实际系统集成还有一个大的问题：怎么保持数据同步。

S/4 HANA是怎么解决数据同步问题的呢？“数据集成”

5. 数据集成--> 幕后工作者，不同系统间数据同步

ECC时代的主数据同步，像是用不同的交通方式（卡车、火车、轮船）在多个城市间运送货物；而S/4HANA时代，则是在这些城市之间修建了统一的高速公路网（API/MDI），并配备了现代化的物流调度中心（MDG/MDI）和标准化的集装箱（ODM/CDS视图）。

数据同步对比，ECC Vs S/4 HANA

至此，S/4 HANA成为平台核心，所有能力通过API开放。

\===============================

第四层：交付层——从“功能”到“服务”

经过前面三层，S/4HANA已经成为一个数据统一、逻辑干净、接口开放的强大平台。但技术的终点是人的体验。用户不需要知道VDM、RAP或API，他们只需要一个简单直观的界面来完成工作；企业不需要关心升级打补丁，他们只需要系统稳定、安全、合规。

第四层，从‘功能’走向‘服务’，一起看看S/4HANA如何通过现代化的用户体验和云运维模式，把技术能力真正交付给用户和企业。

1. 用户视角：好用 -->从“操作功能”到“完成任务”

1.1 操作：简洁的操作体验

在ECC时代，我们要完成什么特定操作都需要运行的事务代码，因此也需要记住一堆的事务代码。但是在S/4 HANA会有一个很好的体验：我不再需要背事务代码，我只需要找到它。

这得得益于S/4 HANA的Forio和Search功能。

Fiori：是SAP推出的一套设计理念和应用集合，负责视觉和交互，数据怎么呈现，怎么完成任务；
本质：把交互界面更简洁 & 把SAP复杂的业务功能，封装成一个个以“用户任务”为中心的小应用。
Search:链接用户与海量数据，它解决入口问题，数据怎么被找到。
本质：让用户不必知道“数据存在哪个表、用哪个事务代码”，直接搜就能进入工作状态。
搜索分“企业级搜索”和“应用内搜索”，举例：
企业级搜索：在Launchpad顶部输入“ABC公司”，得到该公司的客户主数据、销售订单、交货单、发票等相关信息，跟据需要选择点击进去；
应用内搜索：进入“客户主数据”应用输入"ABC公司"，只显示一条该公司的客户主数据信息。

1.2 报表：从“延迟报表”到“实时智能”

嵌入式分析--> 告别等待！

在ECC时代分析和交易是两套系统。交易数据在ECC里产生，分析报表则需要通过ETL过程抽取到BW（数据仓库）中，再进行建模和展示。这个过程通常以“天”为单位——你今天看到的报表，数据其实是昨天的。

数据流：ECC业务数据 → ETL抽取 → BW建模 → 报表展示（用户看到的是昨天的数据）

S/4HANA的核心突破在于：分析和交易在同一个系统中完成。用户不需要离开Fiori界面去打开另一个系统，在销售订单的创建界面，就能实时看到客户的信用评分、历史购买趋势、毛利率等KPI。数据和报表之间，只隔着一个CDS视图。这套架构的关键就是前面第一层提到的是VDM（虚拟数据模型）。

机器学习：从“发生了什么”到“将会发生什么”

如果说嵌入式分析回答的是“现在发生了什么”，那么机器学习回答的是“接下来会发生什么”——这标志着分析能力从描述性（发生了什么）向预测性（将会发生什么）和规范性（应该怎么做）的跃迁。

SAP S/4HANA在HANA数据库层面内置了机器学习能力。其核心包括：

PAL（Predictive Analysis Library，预测分析库）：提供分类、回归、聚类、时间序列等算法，可在HANA数据库内直接运行。
APL（Automated Predictive Library，自动化预测库）：进一步降低了使用门槛，业务用户也能利用AI驱动的预测分析进行业务预测和供应链规划。

1.3 输出管理：从NAST到BRPplus(即，从条件技术到业务规则)

传统方式（ECC）：基于条件技术（NAST），配置复杂（条件表、存取顺序），各模块分散。

S/4HANA方式：

BRFplus（业务规则框架），用决策表配置输出规则，业务人员可参与。
多渠道：一个输出类型可同时支持打印、邮件、EDI、XML。
两阶段设计：管理阶段（创建输出请求）和执行阶段（实际发送/打印），实现决策与执行解耦。
云打印：通过Print Queue + SAP Cloud Print Manager实现云端到本地打印机的安全传输。

2. 企业视角：云交付 -->好配置、好管理、好运维

2.1 好配置：从SPRO到CBC

SAP顾问最熟悉的配置工具莫过于SPRO，它功能强大，给予顾问无限的自由，几乎可以修改系统的每一个角落。但这种自由也是一把双刃剑，复杂、分散、依赖个人经验，容易出错。进入云时代，SAP带来了一场配置革命：CBC（SAP Central Business Configuration）。

CBC引入了一套全新的标准化“预制构件”概念。理解它们，是理解CBC工作流的基础：

项目体验 (Project Experience)：这是CBC的唯一入口和主界面。它像一个“施工导览图”，将整个配置过程分为“评估项目”（Explore）和“实施项目”（Realize）等阶段，并引导你一步步完成所有配置活动。
参考内容 (Reference Content)：这是SAP提供的海量“预制构件库”，是CBC配置的基石。（最佳实践的内容库）
范围项 (Scope Items)：这是参考内容的核心，是SAP预定义的、可独立激活的业务流程单元。例如，用于销售订单处理的 J45（销售订单处理）就是一个范围项。在CBC中，你不需要配置它，而是直接激活它。
业务配置集 (Business Configuration Sets)：这是实现范围项的“施工图纸包”，是一系列相关配置的集合。激活一个范围项，CBC就会自动引用对应的业务配置集，并为你生成需要配置的活动清单。
配置活动 (Configuration Activities)：这些是激活范围项后，你需要完成的“个性化任务”。CBC会自动将活动分为三类：
必选 (Mandatory)：必须完成，如配置公司代码、工厂等组织结构。
推荐 (Recommended)：有默认值，但需要你确认或调整，如定价过程。
可选 (Optional)：有默认值，通常无需修改。
测试脚本 (Test Scripts)：每个范围项都附带SAP预定义的标准测试脚本，用于在实现阶段验证配置是否正确。
主数据脚本 (Master Data Scripts)：用于在系统中自动生成测试或上线所需的主数据，如客户、物料等。
使用指南 (Introduction Guides)：包含业务流程的详细说明和操作手册，帮助顾问和关键用户理解业务场景。

CBC的项目体验将复杂的配置过程，凝练成了清晰的三步流程。

A. 范围确定 (Scope)：这是配置的第一步，也是“定调子”的关键一步。

选择国家与方案范围：在“范围确定”阶段，你首先要选择项目实施的国家和行业方案（公共/私营等）。
激活范围项：接下来，你需要从SAP最佳实践库中，勾选出企业所需的业务场景（即激活对应的范围项）。例如，如果企业需要管理销售订单，就激活销售相关的范围项。
分配部署目标：最后，将配置好的项目分配给具体的系统租户，如开发系统、测试系统或生产系统。

B. 组织结构配置 (Organizational Structure)：在业务范围确定后，CBC会引导你构建企业的组织架构。你需要在CBC中创建并关联所有业务模块所需的组织单元，如公司代码、销售组织、工厂、采购组织等。CBC提供图形化的工具，让组织结构的创建和维护变得非常直观。

C. 产品特定配置(Product-Specific Configuration)：这是配置流程的最后一步，也是最核心的“执行”阶段。在这里，CBC会根据你激活的范围项和组织结构，自动为你生成一份“配置活动”清单。你只需要按照清单逐一完成配置即可，系统会自动检查依赖关系，确保你不会遗漏或搞错顺序。

尝试简单总结和用画图的方式梳理一下这些内容：

CBC就是一个“引导式配置平台”：它通过一系列问题和选项，帮你界定业务范围（范围项），自动匹配对应的配置内容（业务配置集等），然后将这些配置推送到开发系统，再按需传输到测试和生产系统。

逻辑主线：CBC以“范围定义”为起点，依次引导完成组织结构设计和业务流程配置，过程中通过约束检查保障合规性，最终将配置自动部署到系统，并在后续通过内容更新和本地化能力持续维护。

2.2 好管理：身份与权限管理 - 人与系统分离

传统方式：所有用户（人和系统）都通过PFCG角色管理，权限混在一起。

S/4HANA Cloud方式：

人类用户：通过PFCG角色 + 业务目录管理Fiori应用和事务代码权限。
系统用户：通过通信安排管理API调用权限（技术用户，无GUI登录）。

2.3 好运维：云运维 - 由SAP负责，客户专注业务

在S/4HANA Cloud中，SAP接管了基础设施、系统升级、备份、性能监控和安全补丁等传统运维工作。客户无需再关心硬件和版本升级，只需通过SAP Cloud ALM等工具监控业务配置和扩展，真正从“维护软件”转向“使用服务”。

至此，S/4HANA的四层变革全部走完：数据层统一了语言，逻辑层隔离了变化，连接层打开了边界，交付层简化了体验。从底层的表到顶端的应用，清洁核心不再是抽象的理念，而是一套可落地、可扩展、可云化的技术体系。

回头看开篇的问题：个性化与可升级，真的能兼得吗？S/4HANA用这四层递进给出了肯定的答案——不是靠妥协，而是靠重构。

更多文章，见我的微信公众号：日行一步。