一家厂里同时跑着四五套系统，是这几年很常见的状态。财务一套，ERP 一套，车间上了 MES，仓库还有自己的台账，官网后台和 CRM 又各占一处。每套都是当时为了解决一个具体问题买的，验收时都能跑通，报表也出得来。
麻烦出现在它们要一起用的时候。销售订单在 CRM 里改了交期，ERP 那边还是老日期；仓库按批次出了料，MES 里对应工单却记着另一个批号；月底财务要按项目归费用，发现成本中心在两套系统里叫法不同。没人故意填错，只是同一个事实被存了好几份，各自有人改。
一、系统是一套一套攒起来的
很少有企业是一次性规划好全部系统再统一上线的。多数是先有财务，业务量大了加进销存，车间管不住了再上 MES，客户要求追溯又补一套。每次选型都很认真，比较功能、比较价格、比较实施周期，唯独很少有人问一句：新系统里那些数据，原来在哪套系统里已经有了一份。
于是接口往往是在上线前才临时拉起来的。实施人员按当时的需求把几个字段打通，能跑就交付，字段名、触发时点、失败怎么补，写在一份很少有人再打开的文档里。半年后业务改了流程，那条接口还在按老规则跑，数据照传，只是传的东西已经不对了。
二、讨论的重心在从上了多少挪到能不能一起跑
前些年谈制造业数字化，问得多的是接了多少台设备、上了几个模块、覆盖率到多少。近两年的问法明显变了，更常问这些数据有没有进到具体业务动作里，跨系统能不能对得上，出了问题能不能查到源头。各类文件和评价表的名称与条款都不相同，本文不引用任何具体条款，只说这个取向对企业自己意味着什么。
意味着一件不太好量化的事被摆到台面上：系统之间的责任。功能不够可以买模块，接口责任没定，买再多模块也只是多几份要对齐的数据。
选型问题与并存问题不是一类问题
选型是选一个供应商、一份合同、一个实施团队，责任边界比较清楚。并存问题涉及两三套系统、两三家供应商、企业内部两个部门，任何一方都可以说问题不在自己这边。责任不清，改动就没人敢做，最后变成谁都不动，靠人工在中间搬数据。
三、接口责任难定，通常卡在三处
字段映射没人认领
客户编码在 A 系统按地区加序号生成，在 B 系统按拼音缩写，中间靠一张映射表转换。这张表最初是谁整理的、新客户进来谁补一行、停用编码什么时候清掉，常常没有明确说法。表一旦过期，同步就会把数据写到错误的对象上，而且不报错。
改动之前没有影响评估
业务那边把某个状态从三项改成四项，在自己系统里是件小事。但下游接口按三项写的判断，第四项进来以后可能落不进任何分支。这类问题上线当天看不出来，往往在月底对账时才浮上来。
出现差异找不到该找谁
两边数量差了几笔，A 供应商说接口发送成功，B 供应商说接收日志正常，企业内部业务和 IT 各执一词。缺的不是日志，是一条事先约好的规则：哪一侧是数据的源头，差异以谁为准，由谁发起核对。
四、可以先列一张接口清单
不用先上集成平台，也不用把系统推倒重来。把现有的对接一条条写下来，很多含糊的地方自己就显出来了。
- 每类数据的源头系统：物料、客户、订单、库存、工序记录，各自只认一个写入方，其他系统只读或按规则派生。
- 字段映射与取值：把编码、单位、状态的对应关系写成表，注明谁维护、多久复核一次。
- 触发时点与失败处理：实时还是定时，失败是重传还是进待处理队列，补数由谁触发。
- 差异核对口径：按什么键对、多久对一次、以哪边为准、差异单归谁。
- 变更影响评估：任一侧要改字段或状态，先列出会读到它的接口，改完一起验。
这张表不需要多漂亮，能让人在出问题时三分钟内找到该找的人，就算合格。难的是持续维护：新上一个系统、新增一条对接，要有人记得回来补一行。比列清单本身更琐碎，也更关键。
功能是买得来的，责任是买不来的；系统数量增加以后，后者才是决定数据能不能用的那一头。
五、有些企业可以晚一点做
系统就两三套、数据几乎不交叉、接口只有一两条的小厂，人工核对的成本比维护清单还低，先不必形式化。真要判断该不该投入，看一个信号就够：同一个数被不同部门报出不同结果，而且每次都要临时拉人查一遍。出现两次以上，就值得把清单列起来了。
还有一类情况要提醒：别把清单做成一次性的整改项目。业务在变，系统也会加，清单跟着变才有用。把它放进日常变更流程里，改动之前顺手看一眼，比每年集中梳理一回省事得多。
