接口能力与配额
确认源系统提供 API、中间库、文件还是消息队列，调用频率与维护窗口如何。只有文件导出时，设计分批处理与去重规则，别假设能实时对接，否则方案从一开始就错，补做时也要再花一遍同样的时间，评审也更省事。
主数据编码是否统一
客户、物料、组织编码不一致是集成返工的主因。先做编码对照表并指定维护人，再谈字段映射，否则每次新增数据都要人工修，越往后越难收拾，对照表要能自动校验，对照表也需要专人定期维护，维护也更省心。
网络与部署边界
内网互通、白名单、代理、证书、是否允许出网调用模型服务，这些决定部署形态。跨网调用需要提前申请，临时开通往往要等数周，足以拖垮上线窗口，也会打乱排期，客户也会质疑前期的准备不足，方案也更稳。
身份协议与账号
确认支持单点登录的协议类型，服务账号的申请与轮换流程。账号审批周期常被低估，应写入项目计划，否则开发完成却无法联调，团队只能干等，进度整体顺延，业务方也会怀疑团队的交付能力，评审也更顺。
日志与非功能约束
源系统日志是否记录请求标识，决定故障能否端到端追踪；峰值并发、时延要求、月结期间禁变更也要提前确认。忽略业务日历，窗口可能被整体推迟一个月，业务方也会拒绝配合做联调与验证，预算也更好批。
适用与不适用
适合谁
- 准备立项、需要评估集成可行性的企业
- 多套异构系统并存、主数据混乱的单位
- 对可用性与变更窗口有严格要求的行业
不适合谁
- 系统单一、接口标准化程度高的轻量场景
- 仅做离线分析、不涉及业务流程的项目
典型场景
某集团在集成前做条件核查，发现三个子公司的客户编码规则不同、月结期间禁止变更。项目组先统一编码对照表，并把上线窗口排在月结之后，避免了两次返工，并同步给财务与业务，并把核查结论一并写进立项材料，也有据可查。
可执行步骤
- 逐系统登记接口类型、调用配额与维护窗口，登记责任人与联系方式，并约定窗口
- 建立主数据编码对照表，并指定维护人与校验规则，纳入变更流程，并指定复核人
- 确认网络连通、白名单、证书与出网策略，并预留审批时间，并写入项目排期
- 核对身份协议与服务账号审批周期，写入排期，作为里程碑前置条件，并留缓冲
- 把业务日历与变更禁令写进上线计划，并通知相关业务方，并请业务方确认
常见坑
- 假设源系统有实时接口，实际只能每日导出，整体方案要推翻重做，前期投入白费，方案也要返工，方案也白做了。
- 跳过编码对照，联调时靠人工改数据，越改越乱且无法复现，对账时集中爆发，事后补数的代价很高。
- 忽略账号审批周期，开发完成却无法联调，白白等上两周，进度被迫后移，责任也难划清，业务方也会质疑。
- 在月结期间上线，业务方拒绝配合验证，只能延期到下个月，窗口再次错过，预算也要重新走一遍，季度目标也受影响。
自检与验收清单
- 接口类型、配额与窗口是否登记并指定责任人，且有人跟进
- 编码对照表是否有人维护与校验，规则是否自动
- 网络、证书与出网策略是否已开通，且已开通验证
- 账号审批周期是否计入排期，并留有足够缓冲与责任人
- 业务日历与变更禁令是否核对，形成书面，且有通知
常见问题
源系统没有接口怎么办？
可用中间库、定时导出或界面自动化过渡，但要评估稳定性与维护成本。长期方案仍应推动源系统开放标准接口，否则每次业务变化都要重做适配，这一点要提前说明，也更省时间。
主数据不一致能先上线吗？
可以先用对照表兜底，但必须指定维护人并设置校验规则。没有对照表就上线，数据错配会在对账时集中暴露，处理成本远高于前期梳理，也会影响业务方信任，后期补救更贵。
能不能跨网调用外部模型？
取决于客户网络策略与数据分级。涉及敏感数据时优先内网部署；确需出网应走安全评审并做脱敏与审计，把审批时间计入排期，别留到最后一周，也能少做一次返工，项目也更顺。