条件一：接口可达
要逐套确认取数方式：开放接口、数据库只读视图、中间表还是文件导出。老系统常只支持文件，就要接受时效性。核查时让工程师现场取一条真实数据，比看接口文档可靠得多，也快得多。
条件二：厂商配合
许可是否包含接口调用、超出是否计费、故障响应多长，都要问清并留书面答复。厂商更替频繁的系统，还要确认新厂商是否承接接口义务。这一项不落实，后面所有排期都是纸面计划。
条件三：主数据可映射
客户、供应商、物料、组织架构要有可对齐的键，哪怕是名称加税号这类组合键。映射规则要写成表并由业务确认，不能靠实施人员凭经验猜。映射错一处，聚合结果就会长期偏差，且很难自查。
条件四：账号可统一
统一身份需要目录服务或人事系统的账号源，并明确离职停用如何同步。若各系统账号各自维护，聚合层只能做跳转式登录，体验打折但风险可控；强行代管密码则带来安全与责任问题。
适用与不适用
适合谁
- 正在做聚合可行性评估的信息部门
- 系统由多家厂商建设、接口不统一的集团
不适合谁
- 关键系统不允许任何形式取数的场景
- 主数据完全无规律、也没有业务方配合梳理的企业
典型场景
某集团核查发现：四套系统可开只读视图，两套只支持月度文件，一套接口需另付费，客户编码缺统一键。团队据此把首期定为三套系统的查询聚合，时效标注到天；需付费接口列入二期预算，账号先做跳转式登录。
可执行步骤
- 逐套确认取数方式，并要求工程师现场各取一条真实数据验证
- 向厂商书面确认接口许可、调用费用、响应时限与支持方式
- 梳理主数据的可用键，形成映射规则表后交业务部门确认
- 确认账号源与离职停用的同步方式，并把验证做到聚合层
常见坑
- 只看接口文档不实测，开发时才发现字段缺一半，返工与排期延误同时到来，成本无人承担。
- 厂商口头答应配合但无书面答复，关键节点找不到人，项目只能干等，风险无法上报。
- 映射规则由实施方单方拟定，业务不认，上线后每次对账都要重新解释，争议不断。
自检与验收清单
- 每套系统是否都做过现场取数实测并记录结果
- 厂商许可、费用与响应时限是否有书面答复
- 主数据映射规则是否经业务部门书面确认
- 账号源与离职停用的同步方式是否明确
常见问题
老系统只有文件导出怎么办？
可以做，但要接受时效并按天或按批标注。关键是把文件格式与落库规则固定下来，配失败告警；靠人工上传的文件最容易断，一旦断链，聚合结果会静默变旧而无人察觉。
接口要付费是不是就不做？
不必一刀切。先评估该接口支撑的业务价值与替代方案，能用视图或文件替代的先替代；确实必要的列入二期单独核算。最忌讳先开工再发现要付费，预算与工期都没留余量。
账号不统一能聚合吗？
能，做跳转式登录即可：聚合层完成身份识别后跳转到原系统，由原系统校验。代价是用户仍面对多套密码，体验打折，但避免了代管密码带来的安全责任，通常是可以接受的过渡方案。