什么是SAP实施？分步指南

SAP实施，是把一家企业的财务、采购、供应链、销售和人力资源，迁到同一套SAP系统上的项目，通常是S/4HANA。它按SAP的Activate方法分六个阶段进行，成败取决于在任何人动手配置之前所做的工作：流程设计、数据质量，以及合适的团队。

这篇指南写给即将启动实施的高管和项目负责人。它依次讲解各个阶段、每个阶段必须产出什么、必须先做的规划，以及现在启动的项目面临哪些变化。如果您只读一节，请读“配置开始之前的规划”。

做了25年的ERP实施之后，我一再看到同样的规律。把实施当作软件安装的企业，会很吃力。把系统当作最后一步、先把流程工作做完的企业，能按时交付，也能拿到向董事会承诺的成果。

S/4HANA是SAP当前的ERP，运行在SAP HANA内存数据库上。许多企业仍在运行较老的ECC系统，但ECC的主流维护将于2027年12月31日结束，另有可选的延长维护，至2030年底，费用更高。

多数实施最先涉及的核心模块：

模块	管理的内容
FI（财务会计）	总账、应付账款、应收账款、资产会计
CO（管理会计）	成本中心、利润中心、内部订单、管理报表
MM（物料管理）	采购、库存、货物移动、供应商管理
SD（销售与分销）	订单到收款、定价、发货、开票
PP（生产计划）	生产订单、产能计划、MRP
HCM（人力资本管理）	HR主数据、薪资、时间管理

多数企业从FI/CO和一两个运营模块开始。其余的内容，在后续阶段再逐步建设。

SAP Activate取代了较早的ASAP方法。它有六个阶段，每个阶段都有一道关口，过了关口才能继续。

SAP Activate的六个阶段

1. 01

   发现

   确认业务论证，并在试用或演示系统上测试优先级最高的流程。

2. 02

   准备

   动员：团队、治理、范围文件、计划和系统访问权限。

3. 03

   探索

   与流程负责人一起开Fit-to-Standard研讨会。建立配置、集成和扩展的待办清单。

4. 04

   实现

   配置、扩展、迁移数据并测试。这是最长的阶段。退出的条件是一次干净的回归测试。

5. 05

   部署

   用真实流程培训用户，演练切换，在作战室就位的情况下上线。

6. 06

   运行

   上线后重点保障、优化，以及移交给卓越中心。

这张表是我贴在项目办公室墙上的版本：每个阶段必须产出什么、由谁负责，以及进入下一个阶段之前必须满足什么条件。

阶段	必须产出	负责人	通过的关口
发现	业务论证、目标范围、部署方式的选择	发起人和CFO	资金获批
准备	范围文件、计划、治理、团队就位	项目总监	发起人签字确认范围
探索	Fit-to-Standard的结果、待办清单、扩展决策	解决方案架构师与流程负责人	没有未解决的差距
实现	配置并测试完毕的系统、已迁移的测试数据	功能和技术负责人	回归测试干净通过；数据对得上
部署	受过培训的用户、已演练的切换、上线与否（go/no-go）决策材料	切换经理	通过三天的月结演练
运行	重点保障记录、移交卓越中心、第二期待办清单	服务交付负责人	没有未关闭的P1/P2；卓越中心验收

每个阶段背后的模板，都在我写的SAP Activate模板指南里。

三天月结演练这道关口

实现与部署之间的这道关口，是团队在进度压力下最常跳过的。我建议在真正上线之前，做一次为期三天的月结演练。如果财务无法在新系统里关账，您的数据迁移就是没有准备好，不管IT怎么说。跳过这道关口所付出的代价，比它可能造成的延误更高。

顺序很重要。在做出任何一个配置决策之前，有四件事需要完成。

1. 01梳理现有流程按它们真实运行的样子，包括变通办法
2. 02决定用标准还是扩展标准几乎总是更快
3. 03审查数据质量在数据迁移开始之前
4. 04先配齐团队，再确定范围谁有空，决定了您能交付什么

到这时才开始配置

按流程真实运行的样子去梳理

不是流程应该是什么样子。而是它实际是什么样子，包括各种变通办法。那些没人写下来的需求，就藏在变通办法里。

为每个流程决定用标准还是扩展

找出哪些流程由SAP的标准功能覆盖，哪些需要扩展。标准几乎总是更快。每一个扩展都会增加测试周期、升级风险和维护工作。按照SAP的Clean Core指引，每个扩展还得被有意识地放在某个位置，这使得这项决定更加重要，而不是更不重要。

在数据迁移开始之前审查数据质量

这是最被低估的工作线。我见过一些企业，因为过时的客户记录未经检查就被导入，花了好几个月来修复报表。有一位客户有超过1.8万条重复的客户记录，在上线后修复它们，让开票中断了好几周。

先配齐团队，再最终确定范围

您能交付的范围，取决于有谁可以负责配置、测试和管理每一条工作线。先定范围、后配人的团队，会花好几个月，去重建他们当初承诺过头的东西。

挑战	表现	如何应对
范围蔓延	“既然都动到这儿了，顺手加一个……”之类的请求越堆越多	从第一天起就有正式的变更控制；每一项请求都要做影响评估
数据质量	迁移时暴露出没人知道的不一致	在上线前六个月做数据剖析；在源系统里清洗
用户抵触	上线两周之内，用户就回到了Excel	从探索阶段起就让最终用户参与设计；要的是参与，而不只是培训
集成失败	第三方连接在UAT中出故障	在探索阶段梳理接口；尽早用接近真实的数据量测试
测试周期被砍	为了赶日期，缩短回归测试	保护测试阶段；构建阶段的滑期不能挤压测试
团队疲劳	最后冲刺阶段，士气下降，缺陷率上升	用一个简单的每周情绪指数来跟踪疲劳；根据我的经验，当它超过25%时，测试缺陷率就会飙升

我记得有一个案例，一家公司为了加快速度，跳过了一些小的回归测试。一周后，财务无法对平关键的报表。随后是几个月的清理。这并不是什么重大的系统缺陷，只是一个本可避免的疏忽。

上线之前、之中和之后

上线之前：做月结演练，用对账报表验证迁移后的数据，用真实流程而不是演示场景来培训，并测试回退方案。带着指导委员会逐条过一遍上线与否（go/no-go）的标准，并拿到明确的签字，而不是心照不宣的点头。

上线期间：加强监控，并在最初的72小时里让切换团队全天候待命。那几个小时里做出的决定，决定了重点保障是带着信心开始，还是带着一长串工单开始。

上线之后：重点保障（hypercare）至少持续四周。按类别跟踪支持工单；它们会告诉您培训在哪里失灵了、配置在哪里需要调整。从稳定下来的基线出发，规划第二期。18个月前推迟的范围，需要对照业务现在的需要重新检查。

一家中型制造企业总是缺原材料。采购怪计划员；计划员怪没人信任的电子表格。我们用S/4HANA取代了这套做法，并大量依赖配置好MRP的SAP PP。库存水平从凭猜测变成了实时数据，采购订单按需触发，六个月后短缺减少了50%以上。这让连持怀疑态度的人都感到意外。成果来自配置之前的流程再造。没有流程工作的PP，只会更快地给出错误的答案。财务也受益了：月结更快了，CFO说，这些数字有一阵子以来第一次“感觉可信”。

一家全球专业服务公司的问题不同。每个国家都用自己的财务平台，没有一样能对上，报表每个月都要手工重做。我们在一个亲力亲为的指导委员会之下，分阶段推出了SAP财务。月结从两周多缩短到一周出头，各区域报表终于对上了，连审计师也少了许多顾虑。

为2022年写的指南，到了2026年的买家面前就站不住脚。有四个变化，需要从启动会起就设计进去。

云版本是默认选项

SAP现在销售两个云ERP版本：SAP Cloud ERP（公有云版，前身是S/4HANA Cloud公有云版）和SAP Cloud ERP Private（私有云版）。RISE with SAP把私有云版与SAP运营的服务、一整套转型工具链打包在一起，其中包括SAP Signavio、SAP LeanIX和SAP Cloud ALM。SAP GROW则是面向使用公有云版的中型企业的套餐。

版本的选择，如今凌驾于以往的各种上线方式之争之上。大爆炸还是分阶段，绿地、棕地还是选择性迁移，都是在版本之内做的选择，而不是取代版本选择。如果您还在用ECC、需要更多时间，SAP销售一种面向2031年至2033年的ERP私有云版过渡选项，但SAP明确表示，这是一项付费的过渡方案，不是维护期的延长。

Clean Core是分级的，不是非黑即白

2025年8月，SAP推出了四个Clean Core级别，从A到D。A级只使用已发布的、稳定的API，要么在SAP BTP上并行（side by side）实现，要么在系统内用ABAP Cloud。B级允许经典API和仍被视为干净的技术。C级需要特殊措施。D级则不算干净。

公有云版只允许A级扩展。私有云版和本地部署允许经典扩展，所以那里的纪律，来自治理，而不是来自平台挡着您。对项目而言，实际的要点是：在探索阶段，就决定每个扩展的级别和位置，并指定一位能说“不”的负责人。没有SAP BTP和ABAP Cloud经验的合作伙伴，从第一周起就在制造C级和D级的债务。

交付团队里的Joule和SAP Build Code

Joule现在位于SAP Activate Roadmap Viewer和SAP Cloud ALM里面，在那里回答任务方面的问题，并根据方法论起草内容。SAP Build Code自2024年起正式发布，借助Joule，为SAP BTP上的Java和JavaScript扩展生成应用逻辑、数据模型和测试。SAP还为ABAP开发人员增加了类似的生成式AI辅助。

诚实的看法是：AI在SAP项目里是真实存在的，但数据质量决定它的价值。干净的流程文档和干净的主数据，能产出有用的结果。脏数据只会产出自信满满的噪音。这一切都没有消除对一个为每项决策负责的人的需要。

这对现在启动的项目意味着什么

这套打法依然管用。各个阶段依然适用，工作的顺序依然重要。变化的是版本的决策、扩展的纪律，以及团队的工具。在启动时就吸收这些变化的项目，把它们当作设计约束。无视它们的项目，头三个月都在摸索发生了什么变化，通常是从合作伙伴的变更请求里才知道的。

关于同样这些决策在成本方面的情况，请看我写的SAP实施成本拆解。如果您还在用ECC，ECC迁移到S/4HANA指南讲了转换的各条路径。

SAP是用来做什么的？

SAP把核心业务职能（财务、采购、供应链、人力资源、销售）放在同一个系统里，用同一个数据模型运行。

实际上，一笔收货会更新库存、触发应付账款流程，并流入管理报表，无需重复录入。报表的准确度只取决于它底下的交易，所以流程设计和数据质量，比配置更重要。

SAP实施需要多长时间？

范围和团队，是对时间表影响最大的两个变量。一个为单一公司、涵盖FI/CO和一个运营模块的聚焦型S/4HANA实施，可能需要6到9个月。一个涉及众多实体、模块和语言的全球推广，则需要18到36个月。

拖长时间表的因素有：很晚才发现的数据问题、增加范围却不挪日期、关键角色由人兼任，以及为了挽回之前的滑期而砍掉的测试周期。所有这些，在规划阶段都是可以控制的。

SAP Activate的六个阶段是什么？

发现（Discover，业务论证和契合度）、准备（Prepare，团队、治理、计划）、探索（Explore，Fit-to-Standard研讨会和待办清单）、实现（Realize，配置、扩展、迁移、测试）、部署（Deploy，培训、演练切换、上线）和运行（Run，重点保障以及移交给卓越中心）。

SAP实施失败最常见的原因是什么？

几乎每个陷入困境的项目，都有三个根本原因。流程工作被跳过，于是SAP是照着有问题的旧流程去配置的。数据质量被忽视，直到切换时才处理，那时已经没有时间好好修复。变革管理被当成培训：培训教人怎么点鼠标，变革管理让人愿意去用。

第四个原因比较新：合作伙伴在没有Clean Core规划的情况下构建扩展，留下的债务，会在第一次大版本升级时浮出水面。

如何选择合适的SAP实施合作伙伴？

要看在您这个规模上的行业经验，以及您真的能打电话去问的参考客户。要有明确的资深人员参与：在方案宣讲时出现的那个人，应该来主持项目。要看独立性：靠许可或订阅销售赚钱的合作伙伴，有动机推荐更多的范围。要看Clean Core经验：问问他们构建过多少个SAP BTP和ABAP Cloud扩展，并要求看一看。

再多说一条规则。将来负责交付的合作伙伴，不应该替您写业务论证。他们的动机是开始。您的动机是完成。

上线之后会发生什么？

重点保障（hypercare）至少持续四周，全体团队待命，并每天评审未关闭的问题。第一周的工单类别，是最诚实的信号，说明培训在哪里不足、配置在哪里出了错。

重点保障结束之后，由卓越中心接手功能增强、升级规划、新员工培训和变更治理。在项目期间跳过建设卓越中心的企业，通常会在之后两年里，为本该由内部完成的工作，继续给顾问付钱。

什么是RISE with SAP，它适合我的组织吗？

RISE with SAP是SAP面向SAP Cloud ERP Private的订阅套餐：包括软件、由SAP管理的基础设施和运营，以及一套用于流程分析、架构和生命周期管理的工具链。实施仍由您的合作伙伴交付。

它适合那些要从ECC迁移出来、希望平台和运营只签一份SAP合同的大型组织。能够贴近标准运作的中型企业，应该看看公有云版上的SAP GROW。如果监管要求客户自行管理基础设施，或者大量的自定义代码在现有时间内无法清理，RISE就不那么合适。