避免代价高昂失误的最佳 SAP 实施策略

最好的 SAP 实施策略，是适合您的业务、并且您的团队能够坚持下去的那一种。归结起来是三个决定。选哪种部署模式：S/4HANA Cloud Public Edition（公有云版，通常通过 GROW with SAP 获得）、Private Edition（私有云版，通常通过 RISE with SAP 获得），还是本地部署。选哪条迁移路径：Greenfield、Brownfield 还是 Bluefield。以及选哪种上线模式：Big Bang、分阶段还是混合。本指南写给为 S/4HANA 选择实施方式的 CIO、项目总监和发起人。先回答下面五个问题，先做部署模式的决定，再用对比表和决策树来确定另外两个。

在我参与过的 21 个项目中，规律是一致的。策略选择确实重要，但它只是决策中较小的一半。更大的一半是：在选项表格被归档之后，团队能否在长达 14 个月的执行期里守住纪律。

目标不是最快或最便宜的方案，而是适合业务的方案：适合它的结构、文化、节奏、监管状况和长期目标。

要先回答的五个问题

1. 您的组织结构有多复杂：单一主体、多主体，还是多国家？
2. 您的团队需要时间适应，还是已经准备好迎接变化？
3. 您是从多个遗留系统、一套 ERP，还是从一张白纸开始迁移？
4. 您有内部的 SAP 专业能力，还是要依赖合作伙伴？
5. 上线时您能承受多大程度的业务中断？

没有放之四海而皆准的答案。您的策略应该反映您自己的现实，而不是别人的成功故事。

2023 年到 2026 年发生了什么变化

RISE 和 GROW 成了在云端购买 S/4HANA 的标准方式。 RISE with SAP 把软件（通常是 Private Edition）、由 SAP 运营的基础设施和技术运维，以及 BTP 额度打包在一份订阅里。GROW with SAP 则把 Public Edition 打包给流程标准的中型公司。传统的先购买许可、再实施的方式在本地部署上仍然存在，但大多数新的洽谈都从 RISE 或 GROW 开始。

Clean Core 从建议变成了架构。 在 Public Edition 上您无法修改核心：扩展使用已发布的 API，要么用 ABAP Cloud 做栈内扩展，要么在 SAP BTP 上做并行扩展。在 Private Edition 和本地部署上仍然可以修改，但 SAP 的指引把修改视为最后手段，因为每一次修改都会增加升级工作。没有 Clean Core 经验的合作伙伴，从第一周起就在制造技术债。

AI 进入了交付工具。 SAP Joule for Consultants（自 2025 年 5 月起正式发布）依据 SAP 自己的内容回答配置问题。SAP Cloud ALM 可以根据 Fit-to-Standard 研讨会的转录稿起草需求。SAP Build Code（自 2024 年 3 月起正式发布）用 Joule 生成 Java 和 JavaScript 扩展，而面向开发者的 Joule 自 2024 年底起增加了 ABAP 代码生成和解释。这些都不会改变战略选择。它们改变的是您所做的任何选择之内的成本和时间。

策略在哪里成功或失败

执行比选择更重要。无论选了哪种方式，都会出现四种失败模式。

1. 高管参与度消失。 在一家银行的 S/4HANA 实施中，CEO 出席了每一次重要会议，提出了很好的问题，并支持团队。项目按时完成，花费还低于计划。一家连锁商店的高管们则在启动会之后就全部放手。项目停滞了好几个月，因为没有人能做决定。
2. 把数据迁移当作 IT 任务。 一位客户坚持认为其产品主数据“足够干净”。第一天，其仓库就收到了三年前已停产产品的订单。清理花了好几周，还让它失去了一位大客户。数据迁移需要业务方负责。
3. 培训被跳过或仓促进行。 我在 SAP 上线两周后去过一间办公室。会计团队的显示器上贴满了便利贴，提醒着基本操作；他们只接受过一天的培训。他们的经理对我说：“我们只是想撑下去。”那家公司在第一年里多花了 20 万美元的支持费用。
4. 员工绕开系统。 我合作过一家工厂，它以为培训就够了。工人不信任新系统，又回去用电子表格。上线之后再来修复，代价高昂。变革管理是在业务内部的沟通、参与和倡导者，培训只是其中一部分。

两种主要的上线模式

Big Bang

• 一次切换，全部上线
• 最快实现流程标准化
• 前期成本较低，上线首日风险较高
• 需要严格的演练和干净的数据

分阶段

• 按模块、地区或职能分批上线
• 各批次之间有更多纠偏空间
• 支持成本更长，需要维护更多集成
• 需要持续的纪律和治理

Big Bang

我曾参与一家制造企业的 SAP 上线，所有系统在一个周末完成切换。财务、采购、销售和制造都在周一早上上线。过程很紧张，但那种清晰很有力量。所有人同步行动，不会搞不清该信哪个系统、哪份数据。

它之所以成功：团队多次演练切换，提前几周清洗数据，并用真实的测试案例培训用户。好处是对齐更快、回报更快。坏处是没有容错余地。当第一天销售订单出现定价问题时，每个地区都受到了影响。

适用情形： 流程已经标准化，团队准备充分，管理层会守住范围。

分阶段

在另一个项目中，面对一家零售连锁企业，我们采用了分阶段：先上财务、HR 和采购，再上物流和销售点。前后花了一年多，但给了各团队喘息的空间。HR 团队用第一个月理清了工作流，然后才去培训其他所有人。这在 Big Bang 里是做不到的。

代价是支持期更长，而且在已上线和尚未上线的系统之间流动的数据，需要格外小心。

适用情形： 组织规模大或分布广，各地区流程不同，或者管理层希望留出纠偏的空间。

混合

有时答案是两者兼用。

我合作过的一家英国消费电子分销商，需要财务和采购尽快上线。它的仓库因为依赖项太多而没有准备好。于是财务和采购先上，物流和仓储随后跟进。一个领域用 Big Bang，另一个领域分阶段。

混合会增加协调工作。如果采购已在 SAP 中而销售还没有，二者之间的数据同步就需要仔细设计，治理在整个过程中也必须保持敏锐。

适用情形： 各业务单元的节奏不同，某些部门必须更快推进，或者销售旺季排除了某些上线日期。

下面是三者的对比：

维度	Big Bang	分阶段	混合
时间线	最短：一次全部完成	较长：分散在多个批次	居中：有些领域快，其他较慢
业务中断	上线出问题时影响大	较小：变化是渐进的	第一批影响大，之后较小
风险	问题波及整个业务	问题限制在一个阶段内	集中在 Big Bang 的部分
成本	前期较低，出错代价昂贵	总成本较高，紧急情况较少	居中；协调是变数
数据迁移	一个窗口；必须完整	分批加载，每阶段更少	已上线和未上线系统之间的接口是难点
用户采纳	困难：一夜之间改变	较容易：逐步接触	第一批是先行者；后续批次从他们身上学习
最适合	较小的组织、标准流程、就绪度高	流程多样的大型分布式企业	多业务单元组织，其中一些已就绪而另一些尚未

Decide

哪条迁移路径适合您的情况？

遗留系统支离破碎，您想重新设计流程

→Greenfield

流程合理，ECC 稳定，历史数据必须保留

→Brownfield

多主体，希望部分复用并选择性迁移数据

→Bluefield

Greenfield：全新开始

我在一家零售公司的项目中见过这种做法，它通过收购迅速成长，系统支离破碎。我们从零开始，在 S/4HANA 上设计统一的流程。习惯了各自做法的团队起初有抵触。结果是各地区更加一致，报表更干净，系统之间也能互相对话。

适用于： 遗留系统过于零散或定制过度，无法干净地迁移，而且业务想要重新思考自己的工作方式，而不是把旧习惯数字化。

Brownfield：转换和升级

在我早期的一个项目中，面对一家制造企业，Brownfield 是正确的选择。客户对其 ECC 系统做了大量定制，重新开始感觉风险太大。我们专注于向 S/4HANA 的技术转换。用户适应得更快，我们上线也更早，但我们也把一些本应重新设计的笨拙工作流带了过来。

适用于： 现有流程合理且有文档，交易历史对审计或合规很重要，预算或时间紧张，而且组织没有在重组。

Bluefield：选择性过渡

Bluefield（选择性数据过渡）迁移的是特定的公司代码、业务单元或日期范围，而不是全部。它适合因并购或剥离而形成的企业，或者带着多年没人需要的数据的系统。对于您选择保留的部分，您既有 Greenfield 式的流程自由，又有 Brownfield 式的连续性。我的 ECC 到 S/4HANA 迁移指南更深入地讲了这三条路径及其时间线。

2018 年，上线模式和迁移路径就是全部策略。到了 2026 年，有了第三个决定，它限定了另外两个：您运行 S/4HANA 的哪个版本，以及您如何购买它。

1. 03上线模式Big Bang、分阶段或混合，取决于您能承受多大的中断
2. 02迁移路径Greenfield、Brownfield 或 Bluefield，在版本所支持的范围内
3. 01部署模式Public Edition、Private Edition 或本地部署。先决定这一项

S/4HANA Cloud Public Edition（通常通过 GROW with SAP 购买，SAP 将其作为 SAP Cloud ERP 推广）。多租户 SaaS，SAP 的标准流程，每六个月升级一次，不修改核心。只支持 Greenfield。见效最快，灵活性最低。最适合愿意采用 SAP 标准的中型公司。如果您的流程需要大幅偏离标准，它就是错误的答案。

S/4HANA Cloud Private Edition（通常通过 RISE with SAP 购买）。单租户，由 SAP 运营基础设施，每两年发布一个新版本，主流维护期七年，有更多的配置和扩展空间。支持 Brownfield、Greenfield 和选择性过渡。是大多数大型企业项目的默认选择。

S/4HANA 本地部署。 基础设施由您或您的超大规模云服务商来运行。扩展性和控制力最强，升级节奏最慢。建议 Clean Core，但不强制。适合有严格数据驻留要求的情形，以及拥有强大内部 Basis 团队的组织。SAP 的新能力越来越多地先到达云版本。

上线模式和迁移路径随后落在您所选的版本之内。Public Edition 项目按定义就是 Greenfield。对大量定制的 ECC 系统做转换的 Private Edition 项目，通常是 Brownfield 或 Bluefield，而且规模大时通常是分阶段。关于 RISE 和 GROW 的商务方面，请看我的 GROW with SAP 和 RISE with SAP 页面。

那是一个周四的早上，设计研讨会进行到一半。IT 负责人刚演示完 SAP 标准的订单到收款流程。销售部门有人说：“是啊，但我们不是这么做的。”会议室安静了下来。几乎每个项目都会出现这一刻。

Fit-to-Standard

坚持使用标准 SAP，可以缩短实施时间，降低长期维护成本。升级不会破坏并不存在的自定义逻辑。在我参与的一个零售项目中，Fit-to-Standard 帮助客户在不到六个月内上线：活动部件更少，来回沟通更少，系统对未来升级更干净。

经验法则： 只有在法规要求，或者该流程能给您带来真正的竞争优势时才定制。绝不要因为“我们一直都是这么做的”。

Clean Core 的实践

请每一家合作伙伴举例说明它在已发布 API 或 SAP BTP 上构建过哪些扩展。如果回答含糊，就当作红旗信号。把本地部署的习惯带进云项目的合作伙伴，从第一个冲刺起就在积累技术债。

当代码无法避免时

有些定制开发是必要的。SAP Build Code 和面向开发者的 Joule 这样的 AI 工具，降低了编写它的成本，却没有降低维护它的成本。

没人记录的自定义逻辑，会变成没人愿意碰的逻辑，并拖慢之后的每一次变更。没有哪个 AI 工具能解决这一点。文档纪律可以。如果必须定制，就从一开始就做好文档，基于已发布 API 或 BTP 来构建，并让它与核心保持隔离。干净的定制有一份可以收回的真实成本。不干净的定制，则有一份您要持续支付的成本。

这些是我在 2026 年美国市场上看到的 S/4HANA 项目总成本区间。它们因范围、复杂度、行业、合作伙伴和版本而异。请把它们当作预算规划的参照锚点，而不是报价。

策略和范围	典型的项目总成本
中型市场 Brownfield，分阶段	500 万至 1500 万美元
中型市场 Greenfield，Big Bang	800 万至 2000 万美元
中型市场 GROW with SAP（订阅和交付）	200 万至 600 万美元
大型企业 Brownfield，分阶段	2500 万至 8000 万美元
大型企业 Greenfield，Big Bang	3500 万至 1.2 亿美元
大型企业 RISE with SAP（订阅和交付）	2000 万至 8000 万美元
全球多区域，任意组合	1 亿至 3 亿美元以上

部署模式是最常被低估的成本变量。把多年的承诺加起来之后，RISE 和 GROW 的订阅并不比本地部署许可更便宜。它们的价值在于转移的基础设施责任、更快的价值实现和可预测的订阅成本。选择 RISE 或 GROW 的理由很少是总成本，而是运营模式。

什么是 SAP 实施策略？

它是公司部署 SAP 所采用的方式：范围、方法、部署模式、迁移路径、上线模式和时间线。2026 年的主要选择是部署模式（Public Edition、Private Edition 或本地部署）、迁移路径（Greenfield、Brownfield 或 Bluefield）和上线模式（Big Bang、分阶段或混合）。

重要的是这个组合是否适合组织的就绪程度、流程复杂度、监管状况和对中断的容忍度。

Big Bang 实施在什么时候行得通？

当流程已经标准化，用户训练有素，数据在迁移前已经清洗，而且管理层会守住范围。缺少其中任何一项，尤其是干净的数据和用户就绪度，就是一场赌博。

上线时的问题会同时冲击所有部分。有准备的话，这是可控的。没有准备，就是一场危机。

Greenfield 和 Brownfield 的 SAP 实施有什么区别？

Greenfield 从一套新系统开始，不带任何遗留配置。您围绕 SAP 的标准从头设计流程。Brownfield 则转换现有系统，保留交易历史和配置。

Greenfield 前期成本更高，得到的系统更干净，也更面向未来。Brownfield 更快、干扰更小，但会把权宜做法和自定义代码一并带过去。Bluefield 是中间路线：对您选定的主体和数据做选择性迁移。

RISE with SAP 和 GROW with SAP 有什么区别？

RISE with SAP 是 SAP 面向大型企业的订阅产品，通常基于 S/4HANA Cloud Private Edition，由 SAP 运营的基础设施和技术运维包含在一份合同里。在美国市场，我通常看到包含交付在内的总项目成本为 2000 万至 8000 万美元。

GROW with SAP 面向中型公司，运行在 S/4HANA Cloud Public Edition 上，采用 SAP 的标准流程。我通常看到的是包含交付在内 200 万至 600 万美元。

公司规模，以及您的流程必须偏离 SAP 标准多远，决定了该选哪一个。

SAP 中的 Fit-to-Standard 是什么，为什么现在更重要？

Fit-to-Standard 指让您的流程适应 SAP 的标准功能，而不是按您今天的工作方式去定制 SAP。它缩短实施时间，降低维护成本，让升级更干净。

现在它更重要，是因为 Clean Core。在 Public Edition 上，根本无法修改核心。在 Private Edition 和本地部署上，每一次修改都会增加升级工作。要问的问题是：是否存在标准 SAP 无法满足的真实业务理由；如果存在，您的合作伙伴能否在已发布的 API 或 SAP BTP 上构建这个扩展。

SAP Activate 方法论有哪些阶段？

SAP Activate 有六个阶段。Discover（探索 SAP 的产品和业务案例），然后是四个核心交付阶段：Prepare（规划、治理、组建团队）、Explore（Fit-to-Standard 研讨会和待办列表）、Realize（以冲刺方式配置、扩展、测试）和 Deploy（切换、上线和 Hypercare）。Run 涵盖上线后的运营。

Realize 是大多数项目耗费时间最多的阶段，尤其是在测试中暴露数据质量问题，或者定制范围扩大的时候。在整个 Realize 阶段守住严格的范围基线，是按时上线与不断漂移的项目之间的分水岭。

SAP 实施为什么会失败？

四个原因造成了大多数失败：高管参与度在启动之后消失，数据迁移被当作 IT 任务，变革管理仅限于培训手册，以及缺乏 Clean Core 经验的合作伙伴制造了技术债，在第一次升级时暴露出来。

技术很少失败。当决策没有做出、脏数据进入新系统、用户找到了绕开系统的办法，或者定制不得不重做时，项目就失败了。策略很重要。执行纪律更重要。