SAP 实施排期规划：各阶段周期与需要避免的 5 个错误

按我的经验，SAP实施在GROW with SAP上需要6到9个月，在RISE with SAP上需要9到18个月。从SAP ECC迁出，棕地转换或选择性数据迁移需要12到18个月，绿地实施需要18到24个月。

简短的回答：在Explore结束时锁定日期，而不是在项目启动时，并在供应商估算之外再加15%到20%的缓冲。数据工作要在Discover阶段开始，因为数据迁移占实施工作量的30%到40%。每多延误一个月，仅咨询费就至少是六位数。

本指南写给正在制定计划或挽救计划的项目总监和发起人。它讲的是需要多久，而不是怎么做：每个阶段做什么、由谁来做，请看我的SAP实施分步指南。

2024年在欧洲的一个制造业项目上，我遇到一位项目经理，他的SAP项目比计划落后了六个月。严格按照SAP Activate的阶段重新调整之后，他们用四个月完成了剩余的工作。

他的原话是：“有了清晰的阶段和具体的交付物，一切都不一样了。我们始终清楚下一步该做什么。”

对SAP实施时间表影响最大的，是部署模式的选择。下面是我做计划时的基准范围：

起点与目标	典型周期	决定节奏的因素
GROW with SAP（SAP Cloud ERP，公有版）	6到9个月	只用标准流程；扩展基于已发布的API
RISE with SAP（SAP Cloud ERP Private）	9到18个月	范围、扩展数量、数据量
ECC棕地转换	12到18个月	自定义代码、简化项、测试
从ECC进行绿地实施	18到24个月	流程再造、用户承受的变革负担
选择性数据迁移	12到18个月	数据范围界定和专业工具

作为对比，一位审阅过数百个公有版项目的SAP产品专家认为，典型的上线时间是五到七个月。SAP在2026年初推出的GROW Fast，目标是在固定范围内用两到四个月完成。我仍按6到9个月来规划GROW项目，因为数据、决策和培训所需的时间，软件省不掉。

在RISE上，基础设施由SAP运营，这会省掉一部分Prepare阶段的工作，但省不掉数据、测试和变革方面的工作。如何在棕地、绿地和选择性之间做选择，ECC到S/4HANA迁移指南里有说明。

SAP Concur是差旅与费用管理产品，属于独立的云产品，有自己的项目。要把它作为单独的工作流来规划，带有与S/4HANA财务的独立集成，而不是放进S/4HANA的阶段计划里。

预算和日期在哪里失守

我见过的最大错误，是一开始没有好好规划。日期和预算在Explore阶段超支：工作流、报表、接口、数据转换、增强和表单（WRICEF）清单不断膨胀，掌控范围的变成了供应商，而不是客户。

我的SAP实施成本拆解展示了这如何演变成50%的超支。能守住的时间表有三个共同点：现实的缓冲、锁定前经过验证的假设，以及被当作硬性停止点的质量关口。

大多数超期都源于五个错误。每一个都可以预见，每一个都有对策。

错误一：还没弄清范围就定截止日期

2023年在海湾地区的一个零售项目上，客户向董事会承诺九个月完成实施，没有留任何缓冲。数据迁移比预期耗时更长，结果错过截止日期三个月，高管们也对团队失去了信心。我直截了当地告诉他们：那个时间表太激进了。

对策：在Explore之后锁定时间表，而不是在项目启动时，并且一开始就把这一点告诉董事会。在供应商估算之外再加15%到20%的缓冲。

错误二：把数据迁移当成可以晚些开始的工作流

大多数团队任命数据迁移负责人太晚，投入的资源也不够。最初的数据评估几乎总是低估问题，随后就是在系统已上线的压力下进行三个月的清理。

对策：数据画像要在Discover阶段开始，而不是Realize。在集成测试开始之前，在Realize阶段完整地跑一次模拟迁移。我的文章SAP数据迁移为什么会失败详细讲了模拟迁移的周期。

错误三：在进度压力下跳过质量关口

Realize和Deploy之间的关口，是团队最常跳过的一道，因为“先上线再说”的压力在这里达到顶峰。为了“守住进度”跳过质量关口，后面会造成更大的延误。

对策：把可衡量的退出标准写进项目章程，并由指导委员会执行。我在每个项目上都把为期三天的月结演练作为就绪关口。关口设计的更多内容，请看我的SAP质量关口指南。

错误四：在上线前两个月培训用户

2024年在海湾地区的一个零售项目上，客户在上线前两个月就培训了所有用户。到了上线当天，大多数人已经忘了系统怎么用。我们在每个工位都放了操作指引卡，并把现场支持人数翻了一倍。

对策：把培训安排在上线前两到三周，并让关键用户担任讲师，因为人们更愿意向自己信任的同事学习。我的SAP员工培训策略文章有完整的方法。

错误五：把上线安排在业务高峰期

Hershey在1999年7月让基于SAP R/3、Siebel和Manugistics的系统上线，比计划晚了三个月，正好撞上万圣节订货季。其CEO告诉分析师，这些问题会让Hershey无法交付价值1亿美元的万圣节订单。

对策：为每个受影响的业务单元梳理高峰周期，包括月末和季末结账。即使要推迟六周，也要在业务量低的窗口上线。推迟可以弥补，旺季上线失败却无法挽回。

SAP Activate有六个阶段，无论云端还是本地部署，它们都是所有S/4HANA计划的骨架。下面的时长是单个项目做计划时的起点，不是承诺。

1. 1Discover2到4周。退出条件：签署范围和成功标准
2. 2Prepare3到6周。退出条件：章程获批，资源书面承诺
3. 3Explore4到8周。退出条件：差距决策有负责人，时间表锁定
4. 4Realize8到16周。退出条件：模拟迁移通过，集成测试关闭
5. 5Deploy2到4周。退出条件：UAT签字，月结演练，上线决策
6. 6Run4到8周的上线后支持。退出条件：缺陷低于阈值，支持移交签字

这是我每次做计划时的起点阶段表：

阶段	典型时长	主要工作	进入下一阶段前的退出关口
Discover	2到4周	业务论证、范围、部署方式选择（公有云、私有云或本地部署）	签署范围和可衡量的成功标准
Prepare	3到6周	团队入职、治理、系统架构、基线计划、风险登记册	章程获批，每个模块有指定的决策人，资源有书面承诺
Explore	4到8周	Fit-to-Standard研讨会、差距日志、WRICEF清单	差距决策连同负责人一起记录在案；时间表锁定
Realize	8到16周	配置、开发、单元测试和集成测试、模拟迁移	模拟迁移通过；集成测试关闭
Deploy	2到4周	用户验收测试、切换演练、最终用户培训、最终数据加载	UAT签字，月结演练通过，上线决策
Run	4到8周的上线后支持	现场支持、每日问题分拣、移交给运维支持	未关闭缺陷低于约定阈值；支持移交签字

时间实际花在了哪里

Discover往往被赶工。团队还没弄清范围就定下截止日期，也不设可衡量的成功标准，比如“把月结缩短三天”。

在本地部署中，技术上的延误从Prepare就开始了，因为基础设施由客户和合作伙伴搭建。资源承诺要白纸黑字。口头答应的时间说没就没。

Explore阶段，记录很关键。如果当初没有把决策及其负责人写下来，六个月后就没人记得退货为什么要那样处理。

Realize是最长的阶段，也是大多数超期发生的地方，原因通常是Explore产出了一份过于乐观的差距清单。您的第一次模拟迁移会失败，而您需要它在测试中失败，而不是在生产中。

Deploy需要一份切换计划，写明确切的步骤、时间和负责人。“迁移数据”不算一个步骤。

2023年在美国的一个医疗健康项目上，客户比计划落后三个月，面临200万美元的预算超支。我们用SAP Activate的Fit-to-Standard研讨会重新调整。团队找出了28个可以零定制运行的流程。

他们项目经理的原话是：“我们浪费了好几个月，去设计SAP早就做好的东西。”六周之内，他们就回到了原定进度。

2024年在欧洲的一个零售项目上，客户发现自己70%的需求都能用SAP标准流程满足。在亲眼看到系统运行之前，它一直在计划大量定制。

Clean Core让这一点更加突出。在公有版上，标准流程是唯一的选择，扩展放在SAP BTP或已发布的API上。在私有版和本地部署上仍然可以修改，但当每个差距都需要一个附带成本的扩展决策时，关于定制的讨论就会变得更坦诚。

行业会带来各自的拖累。下面的范围针对的是完整的多工厂S/4HANA企业级项目，所以比9到18个月的单次RISE部署更长：

行业	规划范围	拉长周期的因素
制造业	14到20个月	BOM和工艺路线质量、MRP调优、QM要求
零售与消费品	12到18个月	POS集成、主数据量、旺季窗口
制药	16到22个月	GxP验证、批次追溯、序列化
公用事业	15到20个月	设备管理、计费费率结构、GIS和SCADA集成
公共部门	18到24个月	基金会计、采购法规、审批负担、数据驻留
汽车	16到22个月	准时化供应链、工程变更控制
航空航天与国防	20到26个月	政府报告、项目会计、安全供应链
石油和天然气	18到24个月	合资会计、资产密集型运营
金融服务	14到20个月	基于职责分离的角色设计、监管验证

AI工具能改变什么，不能改变什么

SAP Joule for Consultants于2025年正式发布。它能根据SAP自己的知识库（包括SAP Notes）回答配置问题，并解释ABAP代码。SAP Build Code自2024年3月起正式发布，借助Joule在SAP BTP上生成Java和JavaScript扩展代码。

两者都能帮到单个顾问和开发人员。但两者都改变不了研讨会、决策、数据清洗和用户验收所需的时间。做计划时可以考虑它们，但在您自己的团队实测出效果之前，不要从计划里砍掉几周。

下面这些风险，我会放进每周的项目会议议程。任何一项如果拖到每月的指导委员会再处理，都会让日期挪动。

1. 后期范围变更。 在Explore结束时锁定范围。此后，每项变更都要由变更控制委员会审批，并附上对时间表和预算的影响。
2. 数据质量。 大多数企业在规划阶段跳过了数据评估。数据质量差，是模拟迁移失败最一贯的原因。
3. 资源瓶颈。 要求部门负责人书面承诺具体的人员和日期。为每个关键角色培养一名后备。
4. 决策拖延。 范围分歧要在48小时内上报。不要让决策排队等每月的评审。
5. 变革管理太晚。 在Prepare阶段就开始与最终用户沟通，而不是上线前两周。

工具方面，SAP Cloud ALM是SAP用于实施管理的平台。SAP Solution Manager 7.2的主流维护将于2027年底结束，部分功能的延长维护持续到2030年。SAP Best Practices Explorer已于2023年停用，其流程内容现在放在SAP Signavio Process Navigator中。

本指南是我的SAP 实施指南的一部分，该指南汇总了从业务论证到上线的所有主题。

SAP S/4HANA实施需要多长时间？

按我的经验，GROW with SAP（公有版）需要6到9个月，RISE with SAP（私有版）需要9到18个月。从ECC迁移，棕地转换或选择性数据迁移需要12到18个月，绿地实施需要18到24个月。

SAP Activate每个阶段需要多长时间？

作为规划起点：Discover 2到4周，Prepare 3到6周，Explore 4到8周，Realize 8到16周，Deploy 2到4周，Run是4到8周的上线后支持。在较大的项目上，Realize拉长得最多。

RISE with SAP对时间表有什么影响？

RISE把基础设施的责任交给SAP，这会省掉一部分Prepare阶段的工作。但它不会缩短数据迁移、测试、培训或决策的时间，而大部分时间恰恰花在这些地方。如果Clean Core纪律能在自定义开发开始之前就把它拦住，就能缩短Realize。

SAP实施时间表应该留多少缓冲？

在供应商估算之外再加15%到20%的缓冲。在Explore结束、范围和差距都清楚时锁定日期，并在项目启动之前把这一点告诉董事会。

怎样才能缩短SAP实施周期？

严格执行Fit-to-Standard，因为每避免一项定制都能省下几周。在Discover阶段就开始数据清洗，业务人员要全职投入，而不是兼职借调。在Realize期间而不是之后准备切换计划。

SAP推行应该选择大爆炸式还是分阶段？

大爆炸式是一次性全部上线。整体更快，风险也更高，适合范围较小或变革管理能力强的组织。分阶段推行按模块、工厂或业务单元逐步进行，风险更低、周期更长，适合大型多实体集团。

SAP项目延期最常见的原因是什么？

不受控制的变更请求、意料之外的数据质量问题、变革管理太晚、第三方集成故障、项目中途流失关键人员，以及指导委员会决策缓慢。最让大多数团队意外的是数据质量。人人都以为遗留数据是干净的，而它几乎从来都不是。

SAP上线后的支持期（Hypercare）有多长？

计划四到八周的上线后支持：现场支持、每日问题分拣和性能监控。之后，系统移交给应用支持团队或内部的卓越中心。