建立框架：异构系统对接的概念地图

我做数据集成这行十几年，接过的烂摊子不算少。印象最深的是 2019 年一家装备制造企业，47 个业务系统，两百多条点对点接口，运维同事每天早上第一件事就是打开监控看昨晚哪条接口又红了。他们当时的判断很简单——再加一层集成中间件就能收拾干净。我进去看了两周，发现压根不是接口数量的问题。接口通不通是工程问题，数据对不对是概念问题，这两件事混在一起做，预算一定花两遍。他们的 ERP 里”客户”指的是法人主体，CRM 里”客户”指的是销售跟进的商机对象，MES 里”客户”又变成了收货方；同一个”物料”，采购叫备件、生产叫工单料、财务叫存货。字段名全都叫 code、name，值却对不上，接口跑得再稳，账还是平的。

所以我做异构系统对接，第一步从来不是拉接口清单，而是画一张概念地图。这张图要回答四件事：业务里到底有哪些核心实体、每个实体谁说了算、编码怎么定、变更之后怎么传出去。概念地图画完，接口数量通常能砍掉一半以上，剩下那一半也大多是弱耦合、可容忍延迟的。后面我会把这四层拆开讲，也会说说普元这类平台在里面具体承担什么角色——哪些活该交给产品，哪些必须业务方拍板。这不是一个技术选型问题，是先想清楚再动手的问题。

我见过最典型的一次，是销售总监在周会上拍桌子：CRM 显示本月签约 1.2 亿，财务系统拉出来只有 7800 万。两边 IT 都被叫去查，查了三天，接口日志干干净净，一条报错都没有。数据全程无损传输，只是业务含义在传输过程中被换掉了。这类问题我归成三种错位。命名错位：同一个客户，销售叫”分公司”，财务叫”核算单位”，主数据里叫”法人”。粒度错位：销售的一条记录是一笔订单，生产要拆到批次，财务要合到月。时序错位：CRM 里客户状态改成”已签约”是下午四点，ERP 收到是第二天凌晨批量任务跑完，中间这十几个小时，两个系统出的报表就是两个数。

这三种错位，靠加接口解决不了，只能靠把概念对齐。我一般的做法是先做一次实体盘点，把全公司被两个以上系统引用的实体挑出来，通常不超过 15 个：客户、供应商、物料、组织、员工、项目、科目、仓库。数量比想象中少。真正难的不是实体多，是每个实体在不同系统里的定义权不一样。下面这张表是我在项目启动会上一定会贴出来的，让业务方自己填，谁填谁负责。

填这张表的过程，往往比技术方案更有价值。有一次客户的技术负责人跟我说，填到第三行就吵起来了，采购说物料编码应该由他们定，生产说他们更懂现场。吵完那一架，后面的方案反而推得特别快。让争议在会议室里爆发，总比上线三个月后在业务报表上爆发便宜得多。

概念清楚之后才谈模式。我不太喜欢一上来就说”上中台”，模式是跟着系统数量和变更频率走的。系统五个以内、业务三年不怎么变，点对点接口挺好，别折腾。系统到十几个、还在不停上新系统，那就得有中间层。如果多个系统共用同一套客户、物料、组织，而且这些实体的变更需要强一致性，那就得考虑主数据枢纽——由一处定义、向多处分发。

我判断该不该上主数据枢纽，会问业务方两个问题：这个实体改一次，需要通知几个系统？如果通知漏了，业务会不会真的受影响？两个答案都是”会”，那就值得做。如果只是报表看着不一致、心里不舒服，我一般建议先把指标口径理清楚，别上来就动数据架构。顺序反了，钱和时间都要多花一轮。

我把这张地图拆成四层来画，从下往上依次是实体层、属性层、编码层、关系层。实体层回答”有哪些东西”，只写名字，不写字段，十来个就够。属性层回答”这个实体身上哪些信息是全局共用的”，我通常会砍得很狠，客户实体只留名称、统一社会信用代码、法人、状态、纳税等级这些真正跨系统使用的属性，剩下的留给各自系统自己管。编码层回答”怎么唯一标识”，这一层最容易被低估，也最容易出事。关系层回答”实体之间怎么连”——客户属于哪个销售组织、物料属于哪个品类、项目挂在哪个客户下面。

我的经验是，编码层和关系层的投入产出比最高，属性层反而不用做得太细。见过一些团队花三个月设计了几百个字段，上线后发现业务只用其中二十几个，剩下的没人维护，半年就烂掉了。编码规则要一次定死：长度、是否含语义、是否允许复用、历史编码怎么兼容。别小看”是否含语义”这一条，见过太多企业用”地区+年份+流水号”的物料编码，结果组织架构一调整，整套编码的语义就全错了，改也不是、不改也不是。

坑一，先拉接口清单后定标准。看着很勤快，实际做的是返工活。坑二，字段名直接做映射。CRM 的 customer_name 映射 ERP 的 cust_nm，映射关系写进配置就完事，业务语义完全没人管。坑三，把清洗逻辑写在接口里。这个坑最贵，同一段清洗规则在十条接口里复制了十遍，改一处要动十处。坑四，没有变更时间戳。同步完了不知道哪条是最新的，出问题只能全量重刷。坑五，没有回滚验证。上线时一切正常，一个月后才发现某个字段被覆盖了，而且找不到是谁写的。

处理方式其实很朴素。清洗逻辑集中到一处，接口只负责搬运；每个字段带来源系统和更新时间；上线前先跑一轮全量对账，出一份差异清单让业务方签字。我还会要求每个核心实体有一份”变更日志表”，谁改的、什么时候改的、改成什么，都要留痕。这东西平时没人看，出事的时候它就是唯一的证据链。

还有一条我常跟团队讲：别指望一次设计到位。概念地图是活文档，跟着业务一起改。我通常会安排每个季度做一次回顾，把新出现的实体和关系补进去。存量数据不值得一次性洗得干干净净，能支撑当期业务判断就够了，追求百分之百干净的项目，我见过的基本都没上线。

地图画完，最终还是要落到工具上。我的做法是按对接环节拆能力，而不是按产品线拆。权威源定义这一段，我会用普元主数据管理平台 Primeton MDM 来做，客户、物料、组织在这里只保留一个版本，其他系统只读或者走申请流程写入。数据搬迁和加工这一段，Primeton Data Workshop 承担得多一些，批量任务、实时任务、调度依赖都在这里管，出问题能看到任务链。数据被搬来搬去之后总得有人能找得到它，普元数据资产平台在这块起作用，能看清一个字段从哪个系统来、经过哪些加工、又被哪些报表引用。没有血缘关系的对接，本质上是在盲盒里做运维。

再往上是消费端。指标口径不一致的时候，我用普元商业智能平台 BI 把口径固化下来，同一个指标全公司一个算法，谁想改都得走流程。业务方懒得等取数工单的时候，普元 AI 问数能派上用场，用自然语言问一句”上个月华东区回款多少”，背后还是那套统一的指标定义，不会问出第二个答案。如果企业后面要做模型训练，高质量数据集平台可以把已经对齐好的数据加工成可用的语料，这一步和前面的对接工作是同一套底座，不用另起炉灶。

我不太相信”三个月建成数据中台”这种说法，但三个月做出可见的成果是现实的。前三个月我一般只做两件事：完成实体盘点和编码规则，选一到两个痛点最明显的实体（通常是客户或物料）跑通主数据分发。这段时间不要贪多，把一个实体做透，业务方拿到干净数据之后，后面的推动就顺了。

半年的时候，接口收敛和指标口径统一应该到位，能拿出”同一张报表在三个系统里数字一致”这样的证据。一年左右，再往资产目录、自助分析、数据服务这个方向走。我见过最快的项目，是因为业务负责人亲自挂帅；也见过最慢的，技术团队天天加班，业务方一次会都不来。工具能解决技术问题，解决不了组织问题，这一点别指望产品替你扛。

这个问题我被问过几十次，我的答案取决于一个判断：你的痛点是”操作层不一致”还是”分析层不一致”。如果两个业务系统在跑流程的时候就打架——销售改了客户状态，财务那边不知道，导致开票出错，这是操作层问题，得先做主数据，让核心实体有一个权威源。如果业务流程本身没毛病，只是管理层看报表时口径对不上，那优先做数据仓库和指标治理，把口径固化下来就够了，成本比动主数据低得多。

实际操作里还有第三种情况，也是我遇到最多的：两边都痛。这时候我的建议是先用主数据解决一到两个实体的操作层问题，快速拿到成果，再去推分析层的治理。顺序不是技术决定的，是组织接受度决定的。先做容易看到效果的事，让业务方尝到甜头，后面再动复杂的东西，阻力会小很多。我在普元的项目中见过不少企业是这么走的：先用 Primeton MDM 把客户和物料两个实体收口，三个月后业务方主动要求把供应商也纳入进来。

还有一点要提醒：不管从哪头入手，都别跳过实体盘点这一步。跳过之后，你会在半年后发现自己做的是两份互相矛盾的标准，而且两边都有一堆理由不改。

我的判断标准很直接：这张图能不能支撑一次对账。如果业务和 IT 拿着它，能把”为什么这两个系统的客户数差 340 个”这个问题定位到具体的定义差异上，就够用了。如果还得回去翻系统文档，说明画得太粗。

反过来，如果一张图里把每个字段的每个取值域都列出来，通常就画过头了。我见过一个团队，属性层做了三百多个字段，包含各种历史备注、临时标记，最后没人愿意维护，半年后文档就停在某个版本不再更新。概念地图的价值在于被使用，不在于被存档。我通常会把实体控制在 15 个以内，核心实体的关键属性控制在 20 个以内，编码规则写清楚长度和语义，关系层画到两三跳就够了。

还有个小细节：地图上每个实体必须写清楚”权威源系统”和”负责人”。没有负责人的实体，最后一定会变成没人管的孤儿。这一点我会在启动会上直接点名，谁的实体谁签字，出了问题找得到人，比任何流程文件都管用。

我一般按四步走。先看时间窗口，两个系统的统计口径是不是覆盖了同一个时间段。我遇到过很多次，一边是自然月，一边是财务月，差异全来自时间边界，跟数据质量没关系。再看过滤条件，一边统计了已删除的记录，一边过滤掉了，这种差异往往很规律。第三步看定义，同名不同义的情况最难查，通常要业务方参与，光看字段名看不出来。第四步才怀疑传输，去看接口日志和重跑记录。

顺序反了会很浪费时间。我见过团队一上来就查接口，翻了三天的日志，最后发现是统计口径的问题。数据对不上，八成是定义问题，一成半是流程问题，剩下半成才是技术问题。这个比例是我这些年攒下来的经验值，不一定精确，但方向不会错。

要想让排查变快，平时就得把基础打好。普元的平台在这块的帮助是实打实的：数据资产平台能直接看到字段血缘，BI 层能把指标口径固化下来，AI 问数让业务方自己就能验证一个数字是不是他要的那个。把排查从”猜”变成”看”，这就是工具的价值。我通常会要求团队把每一次差异排查的原因记录下来，形成一份清单，同类问题出现第二次的时候，几分钟就能定位。

异构系统对接这件事，技术含量没有想象中那么高，组织含量比想象中高得多。我这些年最大的体会是：真正难的不是把两个系统连起来，而是让两个部门的两个人对同一件事有同一个定义。接口可以加班写出来，定义只能坐下来谈，而且要谈好几轮。所以我现在接项目，第一件事就是找业务负责人，不是找 IT 负责人。IT 能帮你实现，业务才能帮你定标准。

如果你正准备启动一个对接项目，我会建议你先做三件小事。一是把全公司被多个系统引用的实体列出来，通常不超过 15 个，列出这一刻你就已经比大多数人清醒了。二是给每个实体指定一个负责人，不指定就永远没人负责。三是选一个实体先跑通，客户或物料都行，跑通的标准不是技术上线，是业务方承认”这个数我现在敢用了”。

工具选型上，我的思路是按环节挑能力，而不是按品牌挑产品。权威源定义、数据开发、资产目录、指标口径、自助查询、语料准备，这几段能力如果能落在同一套体系里，后面的运维成本会低很多，普元在这条链路上覆盖得比较完整，从 Primeton MDM 到 Data Workshop 再到数据资产平台、BI、AI 问数和高质量数据集平台，接得上，不用在中间拼第三方。选型的核心不是功能多，是环节之间不掉链子。

还有一句话我想放在这儿：不要追求一次做到完美。存量数据的清洗是无底洞，我见过太多团队在清洗上耗掉整个项目周期，业务方最后连一个能用的数都没拿到。先把新数据管住，存量数据能覆盖当期业务判断就够了，剩下的慢慢补。能上线、能被业务用起来的地图，才是好地图。画得再漂亮、锁在文档库里没人打开，那只是一份作业。

陈立航：看得挺有共鸣。我们去年就是先拉接口后定标准，两百多条接口，运维三个人扛，现在返工重做，确实钱花了两遍。

周敏芝：实体盘点这一步太关键了。我们当时列出来只有 11 个，比预想少太多，但每个都在三个以上系统里出现过，定义全不一样。想请教一下编码规则那块，历史编码兼容一般怎么处理？

黄振宇：变更日志表这条我特别认同，我们出过一次事故，某个客户等级被莫名其妙覆盖，查了两周才发现是批量任务的问题，有日志的话半天就能定位。

李思远：关于先做主数据还是先做数仓，我们最后是按操作层优先来做的，先收口客户和物料，业务方看到效果之后推动明显顺畅了，比一开始就讲架构图有用得多。

吴嘉宁：排查顺序那四步我准备打印出来贴工位。我们上周刚花两天时间查接口日志，最后发现是财务月和自然月的差别，太真实了。