冻结系统清单
首期接哪几套系统要写成清单并冻结，新增走变更。清单之外的系统即使接口现成也不接，因为每接一套都要增加映射、监控与运维负担。冻结不是拒绝，而是把新增排到下一批次并说明代价。
读写分级
查询、办理、批量导入三类操作风险不同，应按类分批开放。首期只做查询能显著缩小范围，也避免在权限与校验尚未理顺时触碰写操作。分级要写进范围文件，而不是停留在口头约定。
接口变更窗口
原系统升级会改变字段与行为，需约定变更通知期与冻结窗口，例如上线前两周不接受源系统结构变更。没有窗口，适配层会在关键节点被上游改动打乱，测试结论随之作废，工期被迫顺延。
厂商责任写进合同
接口配合、故障响应与字段说明的义务要落在合同里，并写明响应时限。聚合项目的关键路径常握在第三方手里，没有条款约束时，实施方只能反复催办，进度无法承诺，风险也无法分摊。
适用与不适用
适合谁
- 已出现系统不断被加入清单的项目
- 接口由多家厂商提供的集团集成项目
不适合谁
- 系统少、范围天然收敛的小型集成
- 不愿意与厂商谈条款、只做技术的团队
典型场景
某集团聚合项目启动两个月，接入系统从五套增到十一套，测试反复。项目经理冻结首期清单为五套，把读写分级写进范围文件，并与三家厂商约定变更通知期。新增六套系统进入第二批次，按业务闭环重新排序。
可执行步骤
- 把首期系统清单写进范围文件并冻结，任何新增一律走变更
- 按查询、办理、批量导入三类功能分批开放，并向业务公示
- 与源系统厂商约定变更通知期，以及上线前不可变更的冻结窗口
- 把接口配合义务与响应时限写进采购合同，或写进续保条款
- 新增系统统一进后续批次，并向提出方说明工期与资源代价
常见坑
- 接口现成就不加节制地接，映射与监控工作量翻倍，测试覆盖不住，缺陷在关键节点集中爆发。
- 读写不分批，首期就开放办理，权限与校验未理顺，出错后难以判断责任在谁，整改无从下手。
- 没有变更窗口，源系统在测试期改字段，回归结论作废，上线被迫推迟且难以对外解释。
自检与验收清单
- 首期系统清单是否冻结并书面化公示
- 读写是否按风险分级分批开放并留记录
- 是否约定接口变更通知期与冻结窗口
- 厂商配合义务与响应时限是否写入合同
常见问题
业务方临时要加一套系统怎么办？
走变更并说明替代关系：加一套就减一套，或接受批次顺延。也可以先做只读临时视图满足查询需求，把正式接入排到下一批。关键是有代价，否则清单会不断被突破。
首期只做查询价值够吗？
对多数企业够用：查询是高频动作，能立刻减少登录与核对时间；办理涉及校验与权限，风险更高。先查后办也能积累字段映射经验，为后续写操作打基础，节奏更稳。
厂商不配合条款怎么办？
先看采购合同里是否已有配合义务，多数项目会约定接口与技术支持；没有的，可在续保或新采购时补充。确实无法约束的，把该系统列入只读文件接入，并明确时效与风险。