3. 切换计划与里程碑设计

在 S/4HANA 上线切换中，真正决定成败的不是“切换当天做了什么”，而是切换前 90 天到切换后 30 天这条时间轴上，任务是否被拆到可执行粒度、依赖是否被识别、资源是否被锁定、责任是否被明确。本节以 T 日（切换日，Cutover Day）为基准，把 T-90 到 T+30 划分为五个阶段，并给出任务分解、依赖关系、资源分配与 RACI 矩阵的落地方法。

一、时间轴与阶段划分

切换计划采用相对时间标记，T 为切换日，T-90 表示切换前 90 天，T+30 表示切换后 30 天。五个阶段分别是：T-90～T-60 准备与冻结规划、T-60～T-30 数据与配置就绪、T-30～T-1 演练与最终冻结、T 日切换执行、T+1～T+30 稳定运行与收尾。每个阶段有明确的退出准则（Exit Criteria），未满足退出准则不得进入下一阶段。

需要特别说明的是，T 日并非单日，而是一个切换窗口（Cutover Window），通常为周五 18:00 至周一 06:00，共 60 小时。所有 T 日任务必须按分钟级排程，并预留 20% 缓冲时间。

二、任务分解结构（WBS）与依赖关系

切换任务分解采用三级 WBS：一级为阶段，二级为工作包，三级为具体任务。每个三级任务必须满足“可分配、可度量、可验收”三个条件。以下以 T-30～T-1 演练阶段为例，展示任务分解与依赖关系。

依赖关系分为三类：硬依赖（FS，不可压缩）、软依赖（SS，可并行但需协调）、外部依赖（依赖供应商或第三方）。硬依赖必须严格串行，软依赖可通过资源调配并行执行。例如“主数据清洗”与“配置传输验证”可并行，但两者都必须在“全流程演练”之前完成。

三、资源分配与 RACI 矩阵

资源分配的核心是“人、时间、环境”三要素。切换期间需要锁定关键资源：切换经理 1 名（全程）、各模块顾问 6 名（T-30 至 T+7）、BASIS 顾问 2 名（T-7 至 T+3）、DBA 1 名（T 日全程）、业务关键用户 8 名（T 日及 T+1 至 T+5）。所有资源在 T-14 前必须完成书面确认，避免切换期间被其他项目占用。

RACI 矩阵用于明确每个任务的执行者（R）、批准者（A）、咨询者（C）和知会者（I）。以下为切换核心任务的 RACI 示例。

四、T 日切换窗口的分钟级排程示例

T 日切换窗口从周五 18:00 开始，至周一 06:00 结束。以下为关键节点排程（示例参数，实际项目需根据系统规模调整）：

T日 18:00  旧系统停止用户访问，冻结所有业务操作
T日 18:30  旧系统最终备份完成，确认备份可用
T日 19:00  开始数据迁移：主数据 → 未清项 → 期初余额
T日 23:00  数据迁移完成，执行数据校验（记录数、金额合计）
T+1 01:00  校验通过，开始配置传输与接口切换
T+1 04:00  配置传输完成，系统启动
T+1 05:00  冒烟测试：登录、凭证录入、报表查询、接口调用
T+1 07:00  冒烟测试通过，业务用户开始验证
T+1 12:00  业务确认签字，切换完成
T+1 14:00  旧系统只读开放，新系统正式启用

每个节点必须设置检查点（Checkpoint），检查点未通过则触发回退决策。回退决策由切换经理提出，PMO 批准，回退窗口最晚为 T+1 04:00，超过该时间点则只能向前修复，不再回退。

五、T+1 至 T+30 稳定运行任务

切换完成不等于项目结束。T+1 至 T+30 的核心任务是“稳住业务、闭环问题、验证性能”。具体包括：每日日结验证（T+1 至 T+5）、第一个月结验证（T+30 前后）、性能基线监控（响应时间、并发用户数）、问题分级处理（P1 问题 2 小时内响应，P2 问题 8 小时内响应）、用户操作支持与补充培训。

建议在 T+7 召开第一次稳定运行评审，T+30 召开项目收尾评审。收尾评审的输入包括：问题闭环率、性能达标率、用户满意度、切换实际耗时与计划偏差。若问题闭环率低于 95% 或性能未达标，需制定专项改进计划并延长稳定运行期。