很多企业的系统集成项目，都是在业务催得很急的时候启动的。采购要看供应商到货，财务要核对结算，销售要追订单状态，工厂要同步排产，几个系统一接上去，会议室里常常会先出现一种错觉：只要接口打通，流程自然就顺了。可真正上线后，最先冒出来的问题往往不是接口连不上，而是同一个客户、同一类物料、同一个组织部门，在不同系统里名字不同、编码不同、审批责任也不同。
这类问题表面看像数据格式不统一，实质上是主数据责任没有先梳理。谁负责新建客户档案，谁决定物料编码规则，供应商停用后由哪个系统先变更状态，权限调整后由谁同步到 ERP、CRM、MES 或采购平台，这些问题如果在项目启动前没有讲清，后面接口接得越多，返工面反而越大。项目组最后会发现，自己不是在做系统集成，而是在不停地追着错误数据补洞。
主数据责任之所以容易被忽略，是因为它不像接口联调那样看得见进度。接口可以列清单，环境可以搭建，字段可以映射，但客户、物料、仓库、部门、价格体系这些对象背后的口径，往往分散在不同部门手里。销售关注录单速度，供应链关注履约准确，财务关注核算口径，运维只想先保证系统稳定。每个部门都觉得自己只改一点点，等数据真正跨系统流动时，问题才会一起放大。
在企业数字化项目里，更稳的顺序不是先问“要对接多少个系统”，而是先问“哪些对象必须被所有系统共同识别”。通常第一批要拉出来的，就是客户、物料、供应商、组织、项目、权限这些核心对象。每一个对象都要对应到明确的维护责任：谁发起，谁审批，谁生效，谁回写，谁负责异常纠偏。只有这些边界先落下来，后面的接口、流程、看板和报表才不会建立在一套不断漂移的基础上。
很多项目失败并不是因为技术方案太弱，而是因为把主数据治理放到了联调后面。等 ERP 已经接了，CRM 已经改了，OA 审批也上线了，才开始争论“客户主档到底以谁为准”，这时候每改一次规则，接口映射、权限配置和历史数据都要跟着回头重算。对项目经理来说，这种返工最伤进度；对业务部门来说，这种返工最伤信任，因为一线用户看到的不是集成能力，而是订单查不到、审批串错人、库存口径对不上。
所以，系统集成项目开工前，最好先做一轮主数据责任盘点。不是写一份很大的制度文件，而是把几个关键问题讲实：核心对象有哪些，唯一编码怎么定，跨系统的字段映射以谁为准，新增和变更走什么流程，异常数据由哪个岗位兜底。如果这一轮盘点做得足够清楚，后面的接口开发会更短，测试重点也会更集中，权限治理和流程协同才有可能稳定下来。
上线前还要补一个常被低估的动作，就是验证主数据在真实场景里的流转，而不是只测单个接口能不能通。例如新客户建档后，销售系统、财务系统和交付系统是否都能按同一编码识别；物料停用后，库存、采购和生产排程是否会同步收敛；组织调整后，审批链和报表权限是否会自动更新。这些看起来像测试细节，实际上决定了项目能否从“演示可用”走到“长期可用”。
企业做系统集成，接口当然重要，但接口只是把信息送过去，不能替企业决定哪份数据算数。主数据责任先不清，系统越多，流程越长，问题就越难收。反过来看，只要对象边界、维护责任、变更流程和异常补偿先讲明白，系统集成才真正像一个可交付的项目，而不是一场永远收不了尾的联调。