第一段：盘点与边界
这段决定后面所有排期。产出是资产台账、接口清单与首期范围，准出条件是每套系统的取数方式与许可状态都已确认。若接口需厂商排期，应在这里就发出请求，而不是等开发阶段再联系。
第二段：适配层
按接口类型分批：视图与接口先做，文件类随后。每接通一套就做一次单系统验证，确认字段与更新时效符合台账。准出条件是适配层能独立回归，某套系统故障时不影响其他系统取数。
第三段：聚合入口
入口按业务闭环组织，一个闭环跑通再开下一个。准出条件是该闭环涉及的字段来源、跳转路径与失败提示都已就位。按页面数量排期容易做出很多半成品，用户仍旧回到原系统操作。
第四段：对账与试运行
影子运行两到四周，双入口比对，差异归因后修正。准出条件是对账报告完成、差异收敛、运维手册交付。这段常被压缩，压缩后差异会在上线后被业务逐条发现，处理成本反而更高。
适用与不适用
适合谁
- 需要向管理层承诺上线时间的项目负责人
- 接口由多家厂商提供、排期不可控的聚合项目
不适合谁
- 单系统、接口单一的小型集成项目
- 不愿意做对账、只求尽快上线的项目
典型场景
某集团原计划三个月完成五套系统聚合。盘点发现两套接口需厂商排期，项目组把首期改为三套系统的查询闭环，接口排期与开发并行。第四个月完成对账，差异从最初的四十七处收敛到三处并标注时延，之后才开放办理。
可执行步骤
- 先出资产台账与接口清单，逐套确认取数方式与许可状态
- 接口需厂商排期的，在盘点阶段就发出书面请求并记录时限
- 按业务闭环而不是页面数量安排开发顺序，并设验收节点
- 每套系统接通后先做单系统验证，通过后再做整体回归测试
- 影子运行做双入口对账，差异收敛并标注时延后再开放上线
常见坑
- 按开发工作量排期，忽略厂商排期，关键路径被外部节奏卡住，承诺的日期无法兑现。
- 一次并行开五个业务闭环，每个都做到一半，用户看不到可用功能，内部信心迅速下降。
- 跳过影子运行直接上线，差异由业务方在月结时发现，处理成本远高于提前试运行。
自检与验收清单
- 接口许可状态是否在盘点阶段逐套确认
- 里程碑是否以业务闭环而非页面数量为单位
- 是否安排影子运行与双入口对账并留报告
- 运维手册是否在试运行结束前交付并讲解
常见问题
周期一般多长？
取决于接口数量与厂商配合，通常以季度为单位衡量，单套系统接入约需数周。接口需另购或排期的项目会更长，且时间不完全由实施方掌握，建议在立项时把外部依赖单列为风险项。
能边开发边谈接口吗？
风险很高。接口未定时开发只能做壳，字段一改就要返工。更稳的做法是盘点阶段并行推进接口申请与首期范围确认，开发只针对已确认的接口，未确认的列入后续批次。
里程碑能按系统数量算吗？
不建议。接通五套系统但一个业务闭环都跑不通，对用户没有价值。按闭环算能自然收敛范围，也能让业务方在早期参与验证，避免全部功能做完才发现字段不对。