失败一：只聚界面
把几套系统的菜单放进一个门户，点进去仍是原页面，字段各说各话。信号是用户仍然打开原系统。规避办法是先做数据聚合与字段映射，界面聚合放在后面；顺序颠倒会白做一轮，还得回头补。
失败二：许可与接口卡壳
盘点时没看许可条款，实施中被告知接口另购或需厂商排期，进度停摆。信号是接口清单迟迟定不下来。规避办法是把厂商配合义务、费用与响应时限写进采购与实施合同，让它成为可追的条款。
失败三：主数据不对齐
同一客户在四套系统有四个编码，聚合后出现四条记录。信号是同一对象在入口里重复出现。规避办法是先建映射表并指定维护方，再谈聚合范围；映射没人维护，半年后又会散掉，等于白建。
失败四：写操作绕过校验
为让体验顺畅，聚合层直接改库或跳过审批，单据进了系统却不合规。信号是原系统日志里出现来源不明的变更。规避办法是所有写操作回原系统执行，聚合层只做跳转与参数传递，不自行落库。
失败五：没有退役计划
只加不减，聚合层接得越来越多，该停的老系统还在跑，维护成本逐年上升。信号是台账里的系统数量只增不减。规避办法是在立项时约定退役条件与时间表，把下线写进交付物，而不是当例外处理。
适用与不适用
适合谁
- 已启动或准备启动聚合项目的负责人
- 并购后需要整合系统资产与账号的企业
不适合谁
- 只有一两套系统、集成需求简单的企业
- 不愿意触碰厂商合同与许可条款的项目
典型场景
某企业的聚合项目在第四个月停摆：九个接口中四个需另购授权，两个要厂商排期；客户编码在四套系统里不一致，入口里同一客户出现四行。复盘后团队先补映射表与厂商配合条款，把首期范围收回到查询，项目才重新推进。
可执行步骤
- 对照五个失败模式逐项检查现有方案，标出最可能发生的两项
- 先补齐厂商配合条款、接口费用清单与响应时限，再谈排期
- 建主数据映射表并指定维护方，映射规则经业务确认后固化
- 约定老系统的退役条件与时间表，把下线一并写进交付清单
常见坑
- 把界面聚合当数据聚合，做完发现字段对不上，第二轮返工几乎等于重做，时间成本最高。
- 厂商配合没有合同约束，接口排期一拖再拖，项目节奏完全被动，承诺的上线日无法兑现。
- 主数据映射无人维护，新客户录入又产生新编码，聚合成果逐月退化，用户重新回到原系统。
自检与验收清单
- 是否先做数据聚合，再考虑界面与菜单的统一
- 厂商配合义务与响应时限是否写入合同
- 主数据映射是否有明确维护方与更新节奏
- 是否约定退役条件与时间表并纳入交付
常见问题
五个失败哪个最致命？
许可与接口卡壳最致命，因为它会让项目直接停摆，其他问题至少还能边做边改。建议在立项第一周就核清每个接口的授权状态与厂商响应时限，把不可控项前置暴露出来。
界面聚合一点用没有吗？
有用，但应建立在数据聚合之上。纯界面聚合能减少登录次数，价值有限且容易被用户放弃；一旦字段打通、任务能在一个页面完成，入口才有留存，否则只是多了一个书签。
退役计划一定要现在定吗？
至少要有原则：哪些系统在什么条件下停用、数据如何归档、谁批准。具体时间可以后定，但没有原则就会出现只加不减，维护成本逐年累积，最后没人敢动任何一套系统。