第一步：盘成台账
台账要写系统名称、版本、厂商、接口形式、许可条款、数据量与业务责任人。没有台账，做完才发现某套系统接口要另付费，或早已停用。盘点通常比预期慢，但它是后面所有取舍的依据，跳不过去。
第二步：先定读写边界
聚合不等于替人操作。建议先开放查询，再逐步开放办理，写操作必须走原系统的业务校验，不由聚合层直接改库。边界写清楚，才不至于一次聚合把多年积累的权限与审批规则整个绕过去。
第三步：适配层与身份
接口差异在适配层消化：老系统用数据库视图或中间表，新系统走接口，文件类做定时导入。统一身份解决一人多套账号的问题，权限仍以原系统为准，聚合层只做映射与转发，不再造一套权限体系。
第四步：入口围绕任务
员工关心的是查一个客户的全部往来、走完一张单据，而不是登录五个系统。入口按任务组织，把跨系统字段拼在一起，并标明每个字段来自哪套系统、更新到什么时候，否则数字冲突时无从解释。
适用与不适用
适合谁
- 同时运行三套以上存量系统、入口分散的企业
- 并购后系统并存、需要统一视图的集团
不适合谁
- 系统数量少、接口已经统一的企业
- 希望聚合层直接改库、绕过原系统流程的诉求
典型场景
某集团有 ERP、OA、进销存与两套自建系统，员工查一个客户要登录四次。项目组先盘出四十七个可用接口与九个需另付费的接口，把首期范围限定为查询，适配层用视图与接口混合，统一身份接入现有账号体系。试运行两周后才开放办理。
可执行步骤
- 逐套盘点系统版本、接口形式、许可条款与业务责任人，填入台账
- 先定查询优先、办理其次的次序，把首期范围与不做清单写进方案
- 在适配层用视图、接口与文件三类方式消化差异，接入统一身份
- 按任务而非系统组织入口，逐字段标注来源、更新时间与责任人
- 影子运行两周做双入口对账，差异收敛后再开放办理类写操作
常见坑
- 跳过许可条款核查，实施到一半被厂商要求另购接口，工期与预算双双失控，责任还说不清。
- 聚合层直接写原系统数据库，绕过业务校验，账实不符时无法界定是谁改的，追溯几乎不可能。
- 只按系统分菜单不做任务编排，员工仍要在多个页面间跳转，聚合失去意义，使用率很快回落。
自检与验收清单
- 资产台账是否含接口形式、许可条款与业务责任人
- 首期范围是否限定为查询类功能，并附不做清单
- 统一身份是否接入现有账号体系，离职如何同步
- 入口是否逐字段标注来源系统与更新时间
常见问题
聚合要不要替换老系统？
不需要。聚合的定位是在存量系统之上加一层统一入口，老系统仍是数据的权威来源。替换属于另一类项目，周期与风险高得多，通常只在系统确实停服或厂商退出时才考虑。
接口要厂商配合怎么办？
在台账阶段就把厂商配合与费用写清。能走数据库只读视图的先用视图，避免全部依赖厂商开接口；合同里约定配合义务与响应时限，否则接口排期完全受制于人，项目节奏会被拖散。
员工会真的用吗？
取决于入口是否围绕任务而不是系统。若只是把五个系统的菜单摆在一页，员工仍会回到原系统；把跨系统字段拼成一张客户视图，并支持一键跳转办理，使用率才会起来，也才留得住。