📚 课程目录第4章售前与交付交接管理

4. 售前与交付交接管理

在 Pure Storage 项目交付中，售前与交付之间的交接往往决定了整个项目的成败。销售团队关注商务条款与客户关系，解决方案架构师（SA）关注技术方案与产品选型，而交付团队关注的是“能不能落地、怎么落地、落地后谁来验收”。这三者之间的信息传递如果出现断层，最常见的后果是：交付团队进场后才发现客户环境与方案假设不符、范围边界模糊导致反复扯皮、性能指标没有量化依据、维保与许可条款缺失。因此，交接管理不是一张“签字确认单”，而是一次结构化的信息转移与风险前置。

一、交接的核心对象与信息流

交接的本质是把售前阶段形成的“承诺”转化为交付阶段可执行的“任务”。这里的承诺包括：技术架构承诺（如 FlashArray//X 双活、ActiveCluster 仲裁拓扑）、性能承诺（如 4K 随机读 IOPS、时延上限）、容量与扩展承诺（如初始可用容量、扩展槽位）、服务承诺（如安装窗口、培训场次、维保年限）。交付团队需要拿到这些承诺的原始依据，而不是二手转述。

信息流应当遵循“销售→SA→交付”的主链路，但交付团队必须在方案冻结前介入评审，形成双向确认。下图展示了三方在交接过程中的信息传递关系与关键交付物。

二、需求确认：把“客户说的”变成“可验证的”

需求确认不是复述客户原话，而是把模糊表述转化为可量化、可验证的指标。例如客户说“数据库要快”，SA 需要将其转化为：Oracle RAC 双节点，峰值 4K 随机读 IOPS ≥ 150,000，读时延 ≤ 1ms，写时延 ≤ 2ms，且需通过 SLOB 或 Orion 工具在交付后实测验证。再如客户说“要双活”，需要确认是 Pure Storage ActiveCluster 还是基于第三方仲裁的 Stretch Cluster，仲裁节点部署在哪个站点，站点间 RTT 是否满足 ≤ 5ms 的要求。

需求确认的输出应当是一份《需求确认书》，至少包含：业务需求描述、技术指标、验证方法、优先级（Must/Should/Could）、确认人与日期。对于 Must 级需求，若无法满足，必须在交接前提出，而不是等到交付阶段才暴露。

三、范围界定：明确“做什么”与“不做什么”

范围界定是交接中最容易产生争议的环节。Pure Storage 项目常见范围模糊点包括：

硬件安装范围：是否包含机柜上架、导轨安装、电源接线、光纤跳线？还是仅包含设备上电与初始化？
网络配置范围：是否包含交换机 zoning 配置、iSCSI VLAN 划分、DNS/NTP 配置？还是仅提供配置建议？
数据迁移范围：是否包含从旧存储到 Pure 的数据迁移？迁移工具（如 Pure Storage 的 pMotion 或第三方工具）由谁提供？迁移窗口多长？
主机端配置范围：是否包含多路径软件安装、HBA 驱动升级、集群软件配置？
培训与文档范围：培训场次、人数、语言、文档交付清单与格式。

建议使用《范围界定表》逐项标注“包含/不包含/待定”，并由销售、SA、交付三方签字。对于“待定”项，必须指定责任人与关闭时间，否则视为风险。

四、风险识别：前置暴露，而非事后救火

交接阶段的风险识别应覆盖技术、商务、资源、进度四个维度。技术风险如：客户现有 SAN 交换机端口不足、机柜空间与承重不满足、光纤跳线类型不匹配（OM3 与 OM4 混用）、客户安全策略禁止带外管理。商务风险如：合同未包含线缆与光模块、维保起始时间与验收时间脱节。资源风险如：交付工程师档期冲突、客户侧配合人员未指定。进度风险如：客户机房准入审批周期长、变更窗口受限。

每项风险应记录：风险描述、影响程度（高/中/低）、发生概率、应对措施、责任人、关闭状态。风险登记册应在交接会上逐项过审，高风险项必须制定缓解计划后方可进入交付。

五、交接文档模板与签署

交接文档包不需要追求篇幅，但必须覆盖关键字段。以下给出一个可直接参考的交接文档模板结构（示例）：

【Pure Storage 项目售前-交付交接文档】

1. 项目基本信息
   - 项目名称 / 合同编号 / 客户名称
   - 销售负责人 / SA / 交付经理
   - 交接日期 / 计划交付启动日期

2. 需求确认书
   - 业务需求描述
   - 技术指标（IOPS / 时延 / 容量 / 可用性）
   - 验证方法与验收标准
   - 优先级与确认签字

3. 范围界定表
   - 硬件安装：包含 / 不包含
   - 网络配置：包含 / 不包含
   - 数据迁移：包含 / 不包含
   - 主机端配置：包含 / 不包含
   - 培训与文档：包含 / 不包含
   - 待定项与责任人

4. 风险登记册
   - 风险描述 / 影响 / 概率 / 应对措施 / 责任人 / 状态

5. 技术方案摘要
   - 产品型号与数量（如 FlashArray//X70 2台）
   - 拓扑结构（ActiveCluster / 双活 / 仲裁节点）
   - 容量规划（可用容量 / 预留 / 快照策略）
   - 兼容性列表（主机 / 交换机 / 操作系统版本）

6. 环境检查表
   - 机柜空间 / 电源 / 承重
   - 交换机端口 / 光纤类型 / 光模块
   - 管理网络 / DNS / NTP
   - 客户联系人矩阵

7. 签署页
   - 销售签字 / SA签字 / 交付经理签字
   - 日期

交接会不是“走过场”。建议在交接会上由 SA 逐项讲解技术方案与假设条件，交付团队当场提出疑问，销售确认商务边界。三方签字后，文档归档至项目共享目录，后续任何变更需走变更记录流程。

常见误区：销售口头承诺“客户说没问题”而不写入文档；SA 只给配置清单不给设计依据；交付团队进场后才第一次看到方案。这三类问题都会导致交付阶段返工与成本超支。

交接完成后，交付团队应输出一份《交接确认回执》，列明已接收的文档、待澄清事项、以及交付启动的前置条件。只有前置条件全部关闭，项目才进入实施阶段。这样做的目的不是增加流程负担，而是让三方在同一套事实基础上工作，减少后期争议与返工。