每个阶段到底在做什么
每家咨询公司都有一份方法论 PPT，阶段清晰、箭头整齐。本文讲的是另一个版本：每个阶段实际发生了什么、你实际要交付什么，以及项目真正容易出问题的地方。
1. 五个阶段（传统本地部署 / 私有云）
项目准备 → 蓝图设计 → 系统实现 → 上线准备与切换 → 上线支持
如果你做的是 SAP Cloud ERP，阶段名称会变（Prepare、Explore、Realize、Deploy、Run，见 SAP Activate 一文），但底层工作出奇地相似。最大的区别在中间：Cloud ERP 用"演示标准、确认差异"取代了"写蓝图"。
2. 逐个阶段
阶段 1——项目准备
做什么
- 项目启动会、组织架构、团队通讯录、计划和管理机制（每周例会、每月督导会）。
- 约定文档规范：模板、命名规则、版本号、谁来签字。
交付什么
- 项目章程 / 计划、团队结构、文档规范、问题与风险清单。
经验： 第一天就约定文档编号和版本规则。 一个项目可能有几百份说明书、测试脚本和模板，统一的编号体系（例如 FS-MM-013、UT-MM-005、IT-MM-001）能让任何人在几个月后找到最新的签字版。
阶段 2——蓝图设计（需求与方案）
做什么
- 工作坊之前先做现场调研：去工厂、仓库、药房走一遍。在现场一天学到的，比开一周会还多。
- 按流程领域开工作坊，记录"现状 → 期望 → 方案建议"。
- 设计 SAP 中的组织架构（公司代码、工厂、库存地点、采购组织）。
- 设计主数据：编码和描述规则、物料类型和物料组、哪些字段必填、由谁维护。
- 列出所有标准配置之外的内容：报表、接口、数据转换、增强、表单、工作流（经典的 "RICEFW" 清单）。
交付什么
- 各模块业务蓝图（常为中英双语）、流程图、需求清单、开发清单、接口清单。
- 客户签字确认。
经验
- 主数据设计就是架构设计。 当产品有很多技术属性时，物料编码和描述规则决定了下游系统（MES、销售、报表）能否用好这些数据。在蓝图阶段把这件事做对，后面能省好几个月。
- 接口往往是范围的大头。 尤其在国内项目，SAP 很少是孤立的：OA 审批、MES、医院 HIS/LIS、政府采购平台、金税系统。一个模块一半以上的开发都是接口，并不少见。要尽早列清楚，两边都有负责人。
- 区分"我们现在怎么做"和"我们需要什么"。 很多需求只是旧系统留下的习惯，要追问业务原因。
阶段 3——系统实现（开发与测试）
做什么
- 配置系统并写配置文档。
- 为每个开发写功能说明书（FS）；开发人员开发；顾问测试。
- 单元测试 → 跨模块、跨系统的集成测试。
- 设计用户角色和权限。
- 启动数据迁移：把收集模板发给业务、数据清洗、测试导入。
- 准备关键用户培训。
交付什么
- 配置文档、功能说明书（签字版）、单元测试结果、集成测试脚本及结果、权限设计、数据模板、培训手册。
经验
- 好的功能说明书，能在开发人员提问之前就回答他的问题。 包含：业务背景、触发条件、输入 / 选择屏幕、逐步逻辑、输出格式、报错信息、权限和测试案例。附上真实的样例数据。
- 说明书会不断演变——保留历史。 一份报表说明书可能改十个版本。保留修改记录和签字版；当有人说"我们要的不是这个"时，它能保护你。
- 集成测试要把对方系统的团队请到现场。 大部分集成缺陷出在映射和时序上，而不是 SAP 本身。
- 按流程培训关键用户，并写会议纪要。 按主题（主数据、采购、库存移动、寄售）培训并记录问题，这些纪要会成为最后阶段需求变更的最好来源。
阶段 4——上线准备与切换
做什么
- 数据迁移演练：完整模拟数据的抽取、转换、导入和核对——正式切换前通常至少两次。
- 按小时排的切换计划：系统冻结、未清单据、期初库存、未清采购订单、余额。
- 最终用户培训、Go/No-Go 决策。
交付什么
- 迁移方案、转换规则、演练计划及结果、切换计划、Go/No-Go 检查表。
经验
- 数据迁移永远比计划的大。 收集模板会改很多个版本，不同物料类型往往还要分批导入。要为多轮迭代留出时间。
- 转换规则是业务决策。 旧供应商编码对应新的业务伙伴、旧物料号对应新物料号、旧科目对应新科目表——必须由业务决定并签字，而不是顾问拍板。
- 演练到无聊为止。 两次或更多迁移演练（MR1、MR2）应在正式切换周末之前发现大部分问题。记录两次演练之间的每个问题，修正的是规则，而不只是数据。
- 要核对，不只是导入。 每个对象都要检查：记录数、数量和金额，新旧对比。
阶段 5——上线支持（Hypercare）
做什么
- 每天检查关键流程、接口和错误日志。
- 快速处理：数据修正、缺失的主数据、权限问题。
- 收集真正用起来之后才出现的新需求。
- 交接给运维支持团队。
经验
- 建立每日检查表。 一张简短的清单（失败的接口消息、卡住的单据、库存异常），每天早上跑一遍，能在用户打电话之前发现问题。
- 给用户自助工具。 上传模板和批量维护程序（例如把物料批量扩展到新工厂）能省掉数百个工单。
- 区分缺陷和新需求。 上线后什么都显得紧急。一份清晰的记录既保护项目，也保护客户关系。
3. 你会遇到的几种项目变体
| 项目类型 | 有什么不同 |
|---|---|
| 二期推广（新工厂或新区域） | 复用现有蓝图，附上修改记录更新；重点关注新实体不一样的地方。 |
| 全球模板推广 / ECC → S/4HANA | 设计自由度很小；主要精力在转换规则、数据清洗、迁移演练，以及向用户解释"关键变化"。 |
| Cloud ERP（公有云） | 用 Fit-to-Standard 取代蓝图；Gap 只能通过认可的扩展方式解决；每个版本都要重新测试。 |
| 售前 / 方案建议书 | 理解痛点、提出范围和计划、复用过去项目验证过的模板。 |
4. 随身检查清单
- 第 1 周确定文档编号和版本规则
- 蓝图工作坊前完成现场调研
- 主数据规则设计完成并签字
- 完整的接口清单，两边都有负责人
- 每个开发都有签字的说明书和单元测试记录
- 权限设计在实现阶段就开始，而不是上线时
- 尽早把数据模板发给业务；数据清洗有明确负责人
- 至少两次带核对的迁移演练
- 按小时排的切换计划
- 每日上线支持检查表，以及清晰的"缺陷 / 新需求"记录