一笔业务的五流闭环

01业务起点

02协作与交接

03结果与复盘

图3：每个阶段门都要把上游承诺翻译为下游可执行对象，并保留谁在何时依据什么作出决定。

5.1 从机会到销项的ID链

OPP-I04-N01 → BID-I04-N01 → CONTRACT-I04-N01 → ORDER-I04-N01 → PROJECT-I04-N01 → WP-I04-N01-* → REQ/INT/MIG-I04-N01-* → ACC-I04-N01-* → BILL/INV/AR/PAY-I04-N01-* → CLOSE-I04-N01。发生范围变化时插入 CHANGE-I04-*，发生生产影响时插入 INC-I04-*，发生价格抵扣或退款时插入 CREDIT-I04-*。任何财务调整都能回到业务事件，任何业务事件也能查到是否影响客户权利、项目成本和现金。

5.2 合同评审形成“可签版本”，签署才形成合同权利义务

合同评审在签署前形成内部放行的可签版本，不应写成已经形成对客户的权利义务。评审清单覆盖签约主体、文件优先级、范围与排除、客户依赖、里程碑、验收、付款、变更、知识产权、数据角色、安全、第三方、质保、维护、服务抵扣、责任上限、终止与退出。只有有权代表完成签署且满足约定生效条件后，才按事实判断合同权利义务成立。

时间	事件	状态	可做	不可做
T-10	法务商务评审	内部评审	提偏差、算风险	向客户承诺已生效
T-5	形成可签版本	内部放行	发有版本号文本	改范围不重审
T0	双方有权人签署	已签	创建订单与项目	倒签未授权交付
T0/T+N	生效条件满足	生效	按合同启动	忽略前置条件
T+N	预付款到账	已收款	按约定更新信用状态	自动认定已履约

5.3 启动门不是签约庆祝会

启动门验证四类准备度：商务准备度包括生效、订单、信用和开票信息；客户准备度包括A、团队、时间和决策机制；技术准备度包括环境、身份、网络、第三方和样本；交付准备度包括项目章程、基线计划、风险、质量和供应商。未满足项必须有所有者、截止日、影响和可接受的临时方案。

5.4 需求基线要能向两端追踪

需求向上追踪到业务目标、来源和批准人，向下追踪到设计、配置、代码、测试、培训、验收和运行手册。需求字段至少包括：稳定ID、版本、表述、业务原因、范围归属、优先级、来源、验收标准、数据与权限影响、非功能要求、依赖、状态和批准证据。

正在绘制业务流程…

5.5 接口卡必须描述失败世界

每张接口卡写两端系统和所有者、业务对象、触发方式、频率、字段映射、身份认证、加密、容量、超时、重试、幂等键、顺序、重复、迟到、补偿、对账、监控、保留和停用。只写“REST API、实时同步”无法验收。对订单接口，至少测试正常创建、重复消息、金额不平、主数据缺失、下游超时、乱序取消、部分成功、补偿重放和权限过期。

5.6 数据迁移是一条受控生产线

01业务起点

02协作与交接

03结果与复盘

图4：迁移成功不仅是文件被导入，而是对象数量、金额控制总额、关系完整性和关键业务场景同时通过。

数据迁移依次经过盘点、剖析、范围批准、映射、清洗归属、转换开发、试迁、技术核验、业务抽样、差异处置、正式抽取、加载、对账、批准和源数据处置。每一批 MIG-* 都记录源快照、查询或文件哈希、对象数量、金额控制总额、错误数、排除数、重跑次数、批准人和目标环境。

控制	示例	为什么需要	失败动作
数量控制	源1,200,000、排除2,000、目标1,198,000	防漏数和重复	停止批准、查差异
金额控制	未结订单净额前后相等	防字段映射造成金额偏差	按法人/币种下钻
关系控制	订单行必须有订单头和客户	防孤儿记录	隔离并回源修复
业务抽样	高额、跨期、取消、退货样本	防“总数对但语义错”	业务所有者判定
权限控制	迁移账号限环境、限时、限对象	降低批量暴露	吊销、调查、重发
可回放	保留脚本版本、参数和日志	支持复现与审计	禁止手工改库补数

5.7 SIT与UAT回答不同问题

SIT由供应商验证组件和系统之间按设计工作；UAT由客户业务代表验证系统能支持约定业务并满足验收标准。两者都要有环境、版本、数据、用例、预期、实际、证据、缺陷和结论。GB/T 38634.2-2020与GB/T 38634.3-2020分别提供现行测试过程和测试文档标准入口；二者已存在修订计划，因此真实项目要记录采用版本并跟踪变更，来源为 SRC-I04-SAMR-TEST-PROCESS-2020、SRC-I04-SAMR-TEST-DOC-2020。

测试层	主要问题	负责人	进入条件	退出证据
单元/配置	单一规则是否工作	ROLE-I04-11	设计与环境就绪	自动/人工结果
接口契约	两端消息是否兼容	ROLE-I04-12	契约版本冻结	正反向场景
SIT	端到端技术链是否闭合	ROLE-I04-14	构建和迁移批次稳定	覆盖、缺陷和对账
性能安全	非功能边界是否满足	ROLE-I04-08	可代表环境与数据	报告和例外批准
UAT	业务是否愿意接受	客户业务A	SIT退出、用户和数据就绪	客户签署与保留项
演练	切换和回退能否执行	ROLE-I04-15	生产化脚本冻结	时长、步骤、问题

5.8 缺陷不是需求，需求也不能伪装成缺陷

缺陷是实现偏离已批准需求或设计；变更是对已批准基线的新增、删除或修改；数据问题是源数据或转换规则导致的质量差异；服务请求是运行期标准动作。分类错误会造成免费范围、错误优先级、虚假质量指标和财务遗漏。争议项先由业务分析、技术和测试形成事实包，再由约定的唯一A决定分类；分类变化要保留历史。

5.9 切换门的四个决定

进入切换前分别做业务、技术、安全和经营决定。业务问关键用户、冻结和手工应急是否就绪；技术问版本、容量、监控、备份和回退是否就绪；安全问生产权限、数据、漏洞和第三方是否可接受；经营问未决事项是否影响合同、赔付、开票或声誉。最终go/no-go只有一个客户A，供应商ROLE-I04-09给出建议并记录异议。

正在绘制业务流程…

5.10 验收、开票、收入和收款分别触发

验收由合同定义的成果和标准触发；开票由付款条款与可开票事件触发；收入由履约事实及适用会计判断触发；收款由客户付款行为触发。四者可以同日，也可以相隔数月。系统应保存四套日期和证据，禁止用“项目状态=已完成”同时驱动全部动作。

5.11 关闭项目不等于停止计时

关闭包包括成果与保留项、最终验收、变更和索赔状态、最终成本/EAC、供应商结算、发票与应收、配置基线、源码与文档移交、生产权限回收、数据副本处置、质保与维护起止、知识转移、经验教训和客户确认。只有关闭条件全部满足，项目才能从交付治理转入维护治理；未收尾的应收、诉讼或缺陷继续有明确责任人。

5.12 交付物审查要区分“存在、完整、正确、可用”

一份设计文档存在，只说明文件可找到；字段齐全说明形式完整；与获批需求和架构一致才说明内容正确；客户运行团队能据此部署、排错和维护，才说明可用。审查表将四层分别记录，避免用“已上传”代表已交付。源码交付同样要验证可构建、依赖可取得、配置可重现、测试可执行和许可可履行，而不是只计算文件数量。

交付物	存在性	完整性	正确性	可用性验证
需求基线	有受控版本	来源、验收、依赖齐全	与客户决定一致	能生成追踪和变更影响
接口说明	有每接口文档	正常、异常、安全、对账齐全	与真实两端契约一致	新人员可独立联调和补偿
迁移脚本	版本和参数可追	对象、日志、回退齐全	控制总额一致	在洁净环境可重复运行
运行手册	有批准版本	监控、恢复、升级、联系人齐全	与生产配置一致	客户团队通过情景演练

5.13 UAT脚本要从风险和业务日历取样

UAT不能平均地给每个功能写相同数量用例。高金额、月末、跨法人、权限冲突、重复消息、取消反向、历史追溯和人工补偿等场景应获得更多覆盖。每个脚本包含前置数据、操作角色、步骤、预期业务结果、财务或控制总额、证据位置和清理动作。跨系统场景还要说明哪一步由客户执行、哪一步由供应商观察，避免供应商替客户点击后让客户“代签”。

UAT每日看板不只报通过率。它同时报告计划/已执行/阻断、按风险级别覆盖、开放缺陷、等待客户决定、等待数据、复测队列和距切换剩余时间。通过率很高但高风险场景未执行时，整体仍不可放行。任何带保留项通过都要有影响、替代控制、修复日和客户有权人批准。

5.14 培训、采用和验收的关系

培训完成是能力转移的输入，不自动证明系统被采用。培训包按岗位设计学习目标、真实任务、练习环境、材料版本、讲师、出席、测验和补课；运行接管者还需执行故障和补偿演练。采用指标观察关键流程的正确完成、异常处理和主管使用结果，不能只看登录次数。若合同把培训作为独立成果，验收标准应明确场次、对象、材料和完成证据；若培训只是主成果的一部分，则按合同事实处理。

5.15 质保不是免费需求池

质保处理已交付成果对获批基线的偏离，维护处理服务期内约定的支持与运行活动，新需求和环境重大变化走变更。质保起止点、严重度、响应、修复、排除和延长机制应写清。客户升级操作系统、第三方API改变或未按运行手册操作，不应未经事实分析一概归为供应商缺陷；供应商也不能把真实逃逸缺陷改名为收费需求。

5.16 估算校准需要保存“预测时点”

每个完成项目保存投标估算、蓝图后重估、关键变更后预测和最终实际，按工作包比较数量驱动、工时、成本、周期与原因。只保存最终实际会产生后见之明，无法判断哪一时点本可发现偏差。估算偏差按需求遗漏、复杂度、生产率、客户等待、供应商、质量返工、人员变化和未识别风险分类，并验证下一版估算参数是否真正改善。

5.17 组合产能要看技能、月份和阶段

公司有一百人并不代表任何项目都能立刻得到一百人。资源计划用“技能×月份×阶段”建立热力图：业务分析集中在前期，接口与开发在中期，迁移测试和切换在后期；同一个架构师同时被三个项目安排在同一周参加关键设计门，就是不可执行计划。组合治理先保护关键路径和客户承诺，再决定招聘、分包、延后或拒绝新单；不能通过给一个人排百分之一百五十利用率解决冲突。

资源信号	说明	可能动作	不当动作
未来八周接口能力缺口	已签项目需求超过可排产	调整顺序、合格分包、与客户变更	假定夜间加班永久补足
架构师售前占比过高	赢单依赖少数专家	方案资产化、培养副手、提高资格门	把所有会议都记客户项目
测试后期尖峰	多项目同时进入UAT	错峰、自动化、提前准备数据	临时减少高风险用例
维护抢占项目团队	交接不完整或质量差	提前服务转移、问题管理	把维护工时藏进新项目

5.18 项目状态要以事实而非颜色定义

绿色表示关键里程碑、范围、EAC、质量、客户决定、供应商、数据、安全和现金均在获批容差内；黄色表示已触发阈值但有具名恢复计划；红色表示承诺或控制已失效，需要管理层决定。颜色变化必须伴随事实、影响、动作、责任人和决定日。项目经理不能因为“客户不喜欢看到红色”修改状态，也不能让红色长期存在而没有决策。