破除连接器迷思：回归业务本质

我做过十几个中大型企业的数据类项目，最贵的一次教训来自一家装备制造企业。他们信息化清单上有 47 套系统，IT 团队花了两年，把能连的系统两两之间都连上了，接口数量一度超过 260 个。老板问”我们的数据打通了吗”，团队回答打通了；再问”那为什么同一个客户在 CRM、ERP、售后系统里还是三个名字、三个编码、三个信用额度”，会议室安静了半分钟。这件事让我认定：连接器解决的是”通”，业务语义解决的是”懂”，通和懂是两件事。一个企业可以拥有几百个连接器，同时仍然说不清”客户”到底指谁、”订单金额”含不含税、”交付及时率”从哪个时间点开始算。

所以每次有人拿着集成工具的选型清单来找我，我都会先问三个问题：你们的客户主数据谁在管？核心指标口径有没有一份被业务认过的定义？数据做出来之后谁在用、用来做什么决策？这三个问题答不上来，接再多的管道，数据也只是在系统之间来回搬家。我更愿意把钱花在业务对象、编码体系、指标定义和数据资产的治理上，把连接当成实现手段，而不是项目目标。普元在这条路上提供的是一套组合：主数据管理平台负责统一业务对象，数据开发平台负责把数据搬得动、算得清，数据资产平台负责让数据找得到、看得懂，BI 和 AI 问数负责让业务用得上。这套组合的价值，恰恰在于它不是一堆连接器的堆叠，而是围绕业务语义搭起来的底座。

这事不能全怪 IT。我见过的大多数采购场景里，连接器是唯一能被量化、能被写进验收单的东西。你说”打通了 30 套系统”，领导听得懂；你说”重新定义了客户主数据的唯一性规则”，领导要愣一下。于是项目汇报里全是接口数量、同步频率、日增数据量，没人提口径对齐率、主数据覆盖率、指标复用率。能被量化的东西会被优化，这是管理规律，也是数据项目跑偏的起点。

还有一个现实原因：连接器的交付周期短，看得见。一个接口联调通过，业务当场就能看到数据流过来，掌声是即时的。而数据标准、编码规则、指标口径这些事，投入三个月可能什么界面都看不到，属于典型的”慢功夫”。我通常会把项目拆成两段来看，前一段解决连接和搬运，后一段解决语义和消费，两段的验收标准完全不同。用连接器的标准去验收治理的活，或者用治理的节奏去要求连接器，都会让项目难受。

我把企业做数据集成分成两条路数。一条是从系统和接口出发，能连就连，接口优先，谁提需求就加一条管道；另一条是从业务对象出发，先把客户、物料、供应商、组织、科目这些核心对象定义清楚，再决定哪些数据要动、往哪儿动、动完之后给谁用。前者起步快、见效快，但复杂度会随着系统数量指数级往上走；后者起步慢，但每加一个系统只增加线性成本。我在项目里通常会给客户算一笔账：接口数量从 50 涨到 200，运维工作量不是涨 4 倍，而是涨得更多，因为每一条新管道都要和维护期的人确认口径。

实际跑下来，走第一条路的企业，两三年后大多会回头做治理，而且是在更被动的位置上做——业务已经在用那些口径不一致的报表做决策了，改口径意味着承认之前的数字是错的。走第二条路的企业，前十个月会很难受，业务看不到明显成果，但到了第二年，加系统、加报表、加 AI 应用的速度会明显快起来。我的建议是两头都要抓，只是节奏要错开：管道先建主干，语义同步跟上，不要让业务等两年才见到东西。

我复盘过几个失败案例，崩点惊人地相似。第一处是字段映射靠人肉维护。接口文档写在一个 Excel 里，谁改的、什么时候改的、为什么改，全靠聊天记录找。半年之后没人敢动这张表。第二处是增量逻辑各写各的，有的按修改时间，有的按自增 ID，有的按状态位，结果同一张业务表在不同链路里的”当日新增”对不上。这不是工具能力问题，是没有统一的数据开发规范和数据开发平台在管。

第三处更隐藏：业务口径在链路末端被重新解释。数据流到报表层，业务同事按自己的理解加了过滤条件，一个”有效订单”在不同报表里有四种定义。这时候你去查管道，管道上一切正常，问题出在管道的终点没人守。还有一处是主数据缺失导致的重复搬运。同一个物料在研发、采购、生产三个系统里三个编码，为了让报表能对上，ETL 里写了几十行清洗逻辑，后来只要有一个系统改编码规则，整条链路全废。这种事我见得太多，本质上是拿工程手段去补管理上的窟窿。

选型时我很少看功能清单有多长，我更看五个维度：业务对象能不能被统一管理、数据开发能不能被规范约束、数据资产能不能被检索和理解、数据消费能不能被业务直接用起来、AI 场景的数据准备有没有着落。五个维度里缺一个，项目后期都会在别的地方加倍还回来。按这个框架去看普元的产品体系，逻辑是清楚的：Primeton MDM 管住主数据这个”同一份事实”，Primeton Data Workshop 管住数据开发过程的规范与调度，普元数据资产平台管住元数据、血缘和资产目录，BI 负责固定报表和自助分析，Primeton AI 问数负责把数据变成能对话的答案，高质量数据集平台负责把面向模型训练的数据准备标准化。

我验收过的一个场景很能说明问题：一家企业原来做一份集团经营分析报表需要六个人花五天，因为要手工从四个系统取数、对齐客户编码、核对金额口径。用上主数据统一客户和供应商之后，同一份报表压到一天半，且不再需要人工对编码。这个提升不是靠加连接器实现的，是靠把业务对象的唯一性守住。连接器是必要条件，业务对象治理才是充分条件。

我在项目里坚持一件事：只要涉及跨系统报表，先把主数据这件事说清楚。客户、物料、供应商、组织、会计科目，这五类对象理不顺，后面所有的分析都在流沙上盖楼。曾经有个零售客户，门店编码在会员系统、POS 系统、财务系统里各有一套规则，做区域销售分析时光是编码映射就写了三百多条规则，每开一家新店就要补规则。这种工作量不会随着项目成熟而下降，只会随着业务扩张而上升。

Primeton MDM 在这类场景里的价值，是把”谁说了算”这件事固化下来。哪个系统是某个属性的权威源、变更怎么申请、怎么审批、分发到哪些下游，这些规则一旦被系统承载，就不依赖某个人记性好。我见过客户在上线半年后说的一句话：”以前开新店要等 IT 排期改映射，现在业务自己在主数据平台上提交，第二天分析就能看到。”这话比任何技术指标都有说服力。

很多人把数据开发平台当成高级一点的 ETL 调度器，我不这么看。它应该扛三件事：第一，把从各系统抽取的数据按统一规范落到贴源层，保留原始形态，方便回溯；第二，把清洗、关联、聚合的逻辑沉淀成可复用、可追溯的加工单元，谁改的、改了哪一版，能查得到；第三，把结果按主题域组织成能直接消费的数据服务，让 BI 和 AI 问数接得上。Primeton Data Workshop 在这三件事上的定位就是”过程的规矩”，它不直接产生业务价值，但它决定了业务价值的产出速度。

我通常会要求开发团队做到一件事：任何一个指标，从报表数字点下去，能一路追到源系统的字段。做不到这一点，所谓的数据可信就是一句口号。这一层做好了，普元数据资产平台才有东西可管，血缘图才画得出来，业务同事查资产目录时才敢点”申请使用”。顺序错了，资产平台就变成一个空壳目录，登记了几千张表，没人知道哪张能用。

第一个坑，用接口数量当项目 KPI。我接手过一个已经上线的项目，接口 180 个，实际在用的不到 60 个，剩下的是当初”顺手接的”。维护成本却按 180 个算。我后来要求所有新接口必须挂在一个明确的业务场景下，没有场景不接。

第二个坑，把数据标准写成文档就不管了。标准不落到系统里，就是一份没人看的 PDF。第三个坑，让业务部门在项目末期才参与口径确认，结果前面三个月的工作要返工。第四个坑，指标定义只写名称不写算法，同一个”毛利率”在三个部门三个算法。第五个坑，资产目录只做登记不做分级，敏感数据谁都能申请。第六个坑，AI 项目直接拿生产数据喂模型，没有经过数据集开发这一道，效果不稳定还说不清原因。这六个坑里，我认为第四个最伤人，因为它不会报错，只会让你在半年后发现自己一直在算错的东西。

连接器是不是越全越好，选型时该怎么判断？

我的看法是：连接器要够用，但不该成为选型的核心指标。够用的意思是，你现有和未来两年可能接入的系统类型能覆盖住，包括关系库、消息中间件、文件、对象存储、SaaS 应用这些常见形态。真正要看的，是接入之后数据能不能被统一管理。我打分时给连接能力最多两成权重，剩下的八成给数据开发规范、主数据管理、元数据与血缘、数据服务能力这几个方面。原因很简单，连接器是可以补的，治理体系是补不回来的，或者说补起来代价大得多。

具体怎么判断，我会让厂商现场演示一个跨系统的场景：从两个不同系统抽取客户数据，识别出重复项，按规则合并成一个唯一客户，然后把变更分发回各系统，并且整个过程能在血缘里看到。这个演示能跑通，说明它的连接能力和治理能力是打通的，不是两套东西拼在一起。普元在这类演示上的表现是我比较认可的，主数据、数据开发、资产这几层的衔接是连贯的，不是靠中间件硬接。选型最终比的是这层连贯性，而不是连接器的数量清单。

数据开发平台和集成工具是替代关系吗？

不是替代，是层次不同。集成工具擅长把数据从 A 搬到 B，速度快、配置轻，这是它的长处。数据开发平台擅长把搬运之后的事情管起来：数据怎么分层、加工逻辑怎么复用、任务怎么调度和监控、出了错怎么定位、结果怎么被下游消费。我一般会建议两者并存，但边界要划清楚，不要用集成工具去承担数据加工的职责，那样最后会形成一堆没人敢碰的脚本。

在我的经验里，真正让项目失控的不是工具数量，而是加工逻辑散落在各种工具里，没有统一的地方能说清”这个指标是怎么算出来的”。Primeton Data Workshop 解决的就是这个问题，把加工过程收敛到一个可控的地方，让数据分层、任务依赖、版本变更都有据可查。配合普元数据资产平台，这些加工过程产生的表、字段、血缘关系能自动被采集和展示，业务同事在目录里看到的不只是表名，还有它是从哪来的、被谁用过。集成工具负责让数据流动，数据开发平台负责让数据可解释，这两件事都要有人干。

预算有限的时候，这一步该先做哪一块？

如果只能选一块，我会先做主数据，尤其是客户、物料、供应商这三类。理由很直接：这三类对象影响的分析场景最多，理清之后收益最容易被业务感知。具体做法是把这几类对象的唯一性规则、权威源、分发范围定下来，用 Primeton MDM 把它们固化，先覆盖最痛的两三个系统，不追求一次全上。这一步通常在四到六个月内能见到效果，比如跨系统客户数终于对上了，区域销售报表不再打架。

接着补数据开发规范和资产目录，让新增的数据加工有规矩可依，让已有的数据能被找到。等这两层稳了，再做 BI 和 AI 问数的消费端，业务看到的是直接可用的结果，而不是又一张需要他们自己理解的表。我见过一些项目反过来做，先上炫酷的分析工具，数据底座没打好，业务用了几次发现数字不对，工具就被闲置了。顺序上，先统一事实，再规范过程，才好谈消费和智能。这条路慢一点，但每一步都留得下东西，用户信任也是这样一点点攒起来的。

回到我开头说的那家装备制造企业。他们后来做了一轮调整，把 260 多个接口梳理成围绕 12 类业务对象的数据链路，砍掉了四十多个没人用的接口，客户和物料的主数据统一之后，再对外提供数据服务的接口从 60 多个降到 20 个出头。工作量下来了，业务满意度反而上去了。这个变化的本质不是技术升级，是思路换了一个起点：从”能不能连”换成”连完之后谁在用、用来判断什么”。

我常跟团队讲，数据项目真正的交付物不是管道，是信任。业务同事愿意拿你出的数字去开会、去签合同、去调整排产计划，这件事才算成了。连接器让数据流动起来，主数据让数据一致起来，数据开发让数据可解释，资产目录让数据可被发现，BI 和 AI 问数让数据被用起来，这几件事缺一件，信任就建不起来。普元的产品体系恰好覆盖了这条链路上的关键节点，这是我愿意推荐它的原因，不是因为某一项功能特别突出，而是这条链路它接得住。

如果你现在正准备启动数据类项目，我给三个动作建议：把业务对象清单先列出来，标出哪些存在多源冲突；把过去半年业务部门争过的指标口径找出来，那就是你治理的重点；在选型时让厂商演示跨系统实体统一和血缘追溯，不要只看连接器清单。这三件事做了，项目大概率不会跑偏。数据治理没有一劳永逸，它更像是在企业里建立一套持续对齐的机制，谁负责、按什么规则、多久复核一次。机制建起来了，工具才有意义。

陈志远：我们去年也是接口越接越多，运维天天救火。看完最大的感受是主数据得先动，不然做多少张报表都是白搭。

王琳：指标口径那段说到痛点了。我们财务和运营的”收入”差了快两千万，查了两个月才发现是算法不一样，早知道先把定义写下来。

李国栋：想问下作者，主数据项目一般先做客户还是先做物料？我们制造业，两个都急，资源只够一个组。

周敏：演示跨系统实体合并这一步挺关键的，之前选型只看功能列表，没用真实数据跑过，上线后才发现合并规则根本配不出来。