简介：面向SAP顾问、架构师及企业IT决策者的SAP S/4HANA部署方式梳理文档，聚焦云部署场景下不同模式的差异与选型思路，帮助读者厘清各类部署形态的定位与适用边界。资源包共1个docx文件，约62KB，以文字说明为主，便于快速查阅与对照。内容围绕S/4HANA Cloud Essentials（原MTE多租户模型，预配置必备业务流程、开箱即用）、S/4HANA Cloud Extended（原STE单租户模型，支持在云上配置、增强与扩展应用）、S/4HANA Enterprise Cloud（HEC，即S/4HANA私有云，灵活性接近本地部署）以及S/4HANA On-premise本地部署展开，并说明各方式在SAP最新命名下的对应关系与业务导向含义。已有245人学习，适合需要理解云部署分类、评估迁移路径或向团队做方案说明的从业者参考。
1. 四种部署方式摆在面前，先别急着选“云”
去年帮一家制造企业做系统架构评审，会议室里坐了运维、财务 IT、业务负责人三方，投影上列着四个候选：MTE、STE、HEC、On-Premise。运维说“上云省事”，财务 IT 说“数据不能出去”，业务负责人只关心“能不能改流程”。三个小时后没吵出结果，因为大家嘴里的“云”根本不是同一个东西。SAP S/4HANA 的部署方式命名这几年改过好几轮，MTE 现在叫 Cloud Essentials，STE 现在叫 Cloud Extended，HEC 又常被叫作 Private Cloud，同一个词在不同供应商、不同年份的文档里指向完全不同的隔离模型和扩展权限。这篇就把这四种方式拆开，按隔离级别、扩展自由度、运维归属、成本结构四个维度逐项对比，给正在做选型的人一张能直接拿去开会用的判断表，也给已经上线的人一份排查清单。
2. 先把四个名字对齐：MTE、STE、HEC、On-Premise 到底是什么
2.1 命名变迁史：为什么同一个东西有三个叫法
SAP 这几年的产品命名调整，本质是把技术术语换成业务术语。MTE 全称 Multi Tenant Edition，多租户模型，现在官方叫 S/4HANA Cloud Essentials，强调“预配置了所有必备业务流程，开箱即用”。STE 全称 Single Tenant Edition，单租户模型，现在叫 S/4HANA Cloud Extended，强调客户可以在云上配置、增强、扩展自己的应用。HEC 是 S/4HANA Enterprise Cloud，也叫 S/4HANA in the Cloud 或 S/4HANA Private Cloud，本质是 SAP 托管的企业云，灵活性接近本地部署。On-Premise 就是传统本地部署，和 ECC 时代的部署方式一致。
我一般会这么跟客户解释：名字里带 Essentials 的，是“标准套餐”，流程是预置好的；带 Extended 的，是“标准套餐加自定义厨房”，你能改能扩但厨房还是别人的；HEC 是“整栋楼租给你，物业是 SAP”；On-Premise 是“自己买地盖楼”。这个比喻不严谨，但开会时能省二十分钟。
需要提醒的是，命名变更不代表底层架构变了。MTE 还是多租户，STE 还是单租户，隔离级别没动，动的是市场话术和合同条款。选型时如果只看最新宣传材料，很容易把“Cloud Extended”误以为比“Cloud Essentials”高一个档次，实际上两者是并列的两种隔离模型，不是版本升级关系。
2.2 隔离模型对比：多租户和单租户差在哪
多租户意味着你的系统和别的客户共享底层应用层和数据库实例，逻辑隔离靠租户 ID 和权限体系。单租户意味着你独占一个应用实例和数据库，物理或虚拟层面独立。这个差别直接决定三件事：你能不能改标准代码、你的升级节奏跟谁走、出故障时影响面多大。
| 维度 | MTE（Cloud Essentials） | STE（Cloud Extended） | HEC | On-Premise |
|---|---|---|---|---|
| 隔离级别 | 多租户共享应用层 | 单租户独占实例 | 单租户独占，SAP 托管 | 完全自主 |
| 标准代码修改 | 不允许 | 有限允许（扩展框架内） | 允许，接近本地 | 完全允许 |
| 升级节奏 | 强制跟随 SAP 季度更新 | 可选窗口，但仍受约束 | 客户主导 | 客户完全主导 |
| 运维归属 | SAP | SAP | SAP 托管 + 客户共管 | 客户 |
| 扩展方式 | Key User Extensibility 为主 | Key User + Developer Extensibility | 全量 ABAP 扩展 | 全量 |
这张表里最容易被低估的是“升级节奏”这一行。MTE 的季度强制更新对标准化程度高的企业是好事，对流程有大量自定义的企业就是灾难，因为每次更新都要重新验证一遍扩展点。STE 给了窗口选择权，但底层还是云平台，SAP 推的大版本你躲不掉。HEC 和 On-Premise 才能做到“我想什么时候升就什么时候升”，代价是升级工作全落在自己头上。
2.3 扩展自由度：Key User 和 Developer 的边界
MTE 的扩展主要走 Key User Extensibility，业务顾问在 Fiori 界面上加字段、改表单、配审批流，不碰代码。这条路对业务人员友好，但天花板很低，一旦涉及跨模块逻辑或外部系统深度集成，就得走 Developer Extensibility，而 MTE 对 Developer Extensibility 的支持是受限的，很多场景需要走 side-by-side 扩展，也就是在 BTP 上单独部署一个扩展应用，通过 API 和主系统通信。
STE 和 HEC 则允许在系统内做 ABAP 增强，HEC 基本等同于本地部署的扩展能力。这里有个血泪经验：很多团队在选型阶段觉得“我们不需要改标准代码”，上线半年后业务提了一个跨模块的定制需求，才发现 MTE 的扩展框架接不住，临时改架构的成本远高于当初选 STE 的差价。判断依据很简单，问业务方一个问题：未来三年有没有可能改标准流程的审批逻辑？如果有，MTE 就要慎重。
3. 选型决策表：四个维度打分，别凭感觉
3.1 维度一：业务标准化程度决定隔离模型
业务标准化程度是第一个筛子。如果企业的核心流程就是行业标准流程，差异只在报表和少量字段，MTE 是性价比最高的选择，预配置流程开箱即用，实施周期短。如果企业有大量行业特有流程，比如复杂的按项目核算或特殊定价体系，STE 更合适，因为单租户实例给了扩展空间。HEC 适合那些流程高度定制但又不愿意自建机房的企业，On-Premise 适合有强合规要求或已有成熟运维团队的企业。
我一般会用一个简单的打分法：列出十个核心业务流程，每个流程问“能否接受不改标准逻辑”，能接受记 0 分，需要字段级扩展记 1 分，需要逻辑级扩展记 2 分。总分低于 5 分倾向 MTE，5 到 12 分倾向 STE，12 分以上倾向 HEC 或 On-Premise。这个打分不精确，但能把“感觉上云好”变成可讨论的数字。
3.2 维度二：合规与数据驻留要求
数据驻留是很多企业绕不开的硬约束。MTE 和 STE 都是 SAP 云基础设施，数据存放在 SAP 指定的区域数据中心，客户不能自选机房位置。HEC 虽然也是 SAP 托管，但通常可以协商部署区域，灵活性高于前两者。On-Premise 则完全自主。
这里要注意一个常见误解：很多人以为“私有云”就等于数据在自己手里，HEC 的“Private Cloud”指的是独占实例，不是数据物理位置自主。如果合规要求数据必须存放在企业自有数据中心，只有 On-Premise 能满足。选型会上如果合规方提出数据驻留条款，先把这条摆出来，能直接排除掉两个选项，省掉后面大量讨论。
3.3 维度三：运维能力与团队结构
运维归属直接决定长期人力投入。MTE 和 STE 的日常运维由 SAP 负责，客户团队只需要关注配置和业务支持，适合 IT 团队规模小、没有 BASIS 专职人员的企业。HEC 是共管模式，SAP 管基础设施，客户管应用层配置和部分监控，需要至少一名熟悉 SAP 运维的工程师。On-Premise 则需要完整的 BASIS、DBA、安全运维团队。
我见过一家中型企业选了 On-Premise，理由是“可控”，结果上线后没有专职 BASIS，每次打补丁都要外聘顾问，一年运维成本超过订阅差价。反过来也有企业选了 MTE，业务部门提了个性化需求发现改不了，又回头补 side-by-side 扩展的开发预算。运维能力和扩展需求要一起算总账，不能分开看。
3.4 维度四：总拥有成本的时间曲线
成本对比不能只看第一年订阅费。MTE 的订阅费低，但扩展受限，后期可能需要额外采购 BTP 服务做 side-by-side 扩展。STE 订阅费中等，扩展空间大，但单租户实例的硬件资源是独占的，费用高于多租户。HEC 的费用结构接近托管服务，包含基础设施和部分运维，长期看比自建机房省人力但单价高。On-Premise 前期硬件和 license 投入大，后期运维人力持续投入，适合已有数据中心的企业摊薄成本。
| 成本项 | MTE | STE | HEC | On-Premise |
|---|---|---|---|---|
| 初期投入 | 低 | 中 | 中高 | 高 |
| 年度订阅/托管费 | 低 | 中 | 高 | 无（转运维） |
| 扩展开发成本 | 高（需 side-by-side） | 中 | 低 | 低 |
| 运维人力 | 低 | 低 | 中 | 高 |
| 升级适配成本 | 低（强制但标准化） | 中 | 中高 | 高（自主但工作量大） |
这张表的关键读法是看“扩展开发成本”和“升级适配成本”两行的交叉。MTE 在前者高、后者低，适合流程稳定、扩展少的企业；On-Premise 反过来，适合扩展多、有专职团队的企业。中间两种是折中，折中的代价是两边都不极致。
4. 避坑清单：五个真实踩过的坑
4.1 坑一：把 Cloud Extended 当成 Essentials 的升级版
现象：选型会上有人提出“既然 Extended 名字更高级，那就选 Extended”。原因：命名调整后，Essentials 和 Extended 听起来像版本层级，实际是并列的隔离模型。解决：看隔离级别而不是名字，多租户选 Essentials，单租户选 Extended，和“高级”无关。
4.2 坑二：低估 MTE 的扩展天花板
现象：上线后业务提跨模块定制需求，发现 Key User Extensibility 接不住，临时上 BTP 做扩展，工期和预算双超。原因：选型阶段只评估了当前需求，没做三年流程演进的假设。解决：选型时强制做一次“最坏扩展场景”推演，把可能需要改标准逻辑的流程列出来，逐条确认目标部署方式能否承接。
4.3 坑三：以为 HEC 等于数据自主
现象：合规评审时发现 HEC 的数据存放位置仍需协商，不能默认放在企业自有数据中心。原因：Private Cloud 指的是独占实例，不是数据物理位置自主。解决：合规要求数据必须落在自有数据中心的，直接排除 HEC，不要等到合同阶段才发现。
4.4 坑四：忽略强制升级对扩展点的冲击
现象：MTE 季度更新后，之前配的某个扩展字段行为变了，业务反馈报表数据异常。原因：多租户环境的升级是全局推送，扩展点依赖的标准对象可能随版本调整。解决：每次升级前跑一遍扩展点回归清单，重点检查依赖标准表的自定义字段和审批流。
4.5 坑五：运维人力按“云等于不用管”来配
现象：选了 HEC 但没配专职应用运维，日常监控和补丁协调出现空档。原因：HEC 是共管模式，SAP 管基础设施，应用层配置和监控仍在客户侧。解决：选型时把运维职责矩阵写进方案，明确哪些工作 SAP 做、哪些客户做，按矩阵配人。
5. 落到执行：一张决策流程图和三个验证动作
把上面的维度收拢成一个可执行的判断顺序。第一步问合规：数据是否必须存放在自有数据中心？是则选 On-Premise，否则进入第二步。第二步问扩展：未来三年是否需要修改标准流程逻辑？否则倾向 MTE，是则进入第三步。第三步问运维：是否有专职 BASIS 团队？有则 HEC 或 On-Premise 均可，无则选 STE。这个顺序不能反，因为合规是硬约束，扩展是中期约束，运维是长期约束，硬约束先排除，后面讨论才有意义。
三个验证动作建议在签约前做完。第一，让业务方列出十个核心流程，逐个标注扩展级别，用 3.1 的打分法算出倾向值，和架构团队的判断对照，偏差超过三分的流程单独讨论。第二，向 SAP 或实施方索取目标部署方式的扩展能力清单，重点确认 Developer Extensibility 的边界，别只看宣传材料里的“支持扩展”。第三，做一次升级影响模拟，拿一个已有的自定义字段或审批流，走一遍目标环境的更新流程，看回归工作量有多大。
# 升级影响模拟的检查清单（以扩展字段为例） # 1. 记录当前扩展字段依赖的标准表和视图 # 2. 在目标环境执行一次模拟更新 # 3. 对比更新前后字段行为差异 # 4. 统计需要回归验证的报表和接口数量这段清单不是自动化脚本，是人工检查的步骤模板。关键是第三步“对比行为差异”，很多团队只验证字段还在不在，不验证行为变没变，结果升级后数据口径悄悄变了。参数上建议把“需要回归验证的报表和接口数量”作为量化指标，超过团队一周工作量就要提前排期。
回过头看，我在第一个项目里犯的错是拿着“云更先进”的结论去倒推选型，而不是先摆约束再选方案。从那以后我每次做部署方式评审，都强制先走一遍合规和扩展两道筛子，再谈成本和运维。希望帮到你。
本文还有配套的精品资源，点击获取
