别再无效投入连接器，先算清这笔价值账

我在 B2B 数据项目里待了十三年，见过太多团队在连接器上花冤枉钱。有家做工业设备的客户，五年里买了七十多个连接器授权，从 ERP 到 CRM、从钉钉到自建 MES，接口开了一大堆，可业务部门想看一张”客户交付进度全景表”，还是要等 IT 排期两周。这种情况我判断问题不在连接器数量，而在没人算过这笔账：连接器的价值不是”能连通”，而是”连通之后这条数据链路能不能被复用、被治理、被业务自己看懂”。如果只是把数据从 A 搬到 B，买一百个连接器也只是把烟囱从地面挪到地下。我通常会先问三件事：这条链路一年跑多少次、谁在用、断了谁最疼。答不上来的，先别买。真正值得投入的，是能沉淀成资产的那部分链路，比如客户主数据、物料主数据、指标口径这类反复被调用的东西。这也是我为什么在很多项目里会推普元这套智能数据治理体系——Primeton MDM 管主数据口径，Primeton Data Workshop 承接数据开发与链路编排，数据资产平台把链路沉淀成可查可用的资产，BI 和 Primeton AI 问数让业务端自己拿数，高质量数据集平台再把数据喂给模型。连接器只是入口，账要算在出口上。

我判断一个数据集成项目是否失控，看的不是连接器总数，而是单条链路的复用次数。复用次数低于 3 的链路，基本都是在为一次性需求付费。我见过最典型的场景是：业务部门提一个取数需求，IT 拉一条连接器；下个月需求微调，再拉一条。两年下来连接器列表长得像通讯录，可真正被三个以上系统调用的不超过 15%。剩下的 85% 是什么？是没人敢删的僵尸接口。它们的成本不在授权费上，而在三块地方：一是维护，每个连接器都要跟着源系统的版本升级做适配；二是排障，一条链路断了，从源库到目标表中间隔了四五个中间件，定位一次平均要两三个人天；三是数据质量，同一个”客户编号”在三条链路里三种写法，到了报表层再花时间对齐。这三块成本表里都看不见，但年底一算运维工时，比授权费高得多。

我把市面上常见的做法归成三类，不是说哪种一定对，而是看你的业务节奏配不配得上。点对点堆连接器最快见效，但它的成本曲线是往上翘的；平台化承接前期慢，但过了某个拐点会便宜很多。我踩过的坑是：在一个只有二十来个数据源的场景里硬上重平台，团队没人会用，半年后平台成了新的孤岛。反过来，在一个已经有八十个系统互相调用的集团里继续点对点，排障工时会吃掉整个数据团队。判断拐点的经验值是：当”跨系统取数需求”每月超过 15 个、且需求方分散在 3 个以上部门时，就该考虑平台化承接了。这时候再看成本，就不是比谁的连接器便宜，而是比谁能把链路变成资产。

第一个误区是把连接器数量当成集成能力的证明。我在一次评审会上看到过一张架构图，密密麻麻一百多条连线，汇报人说这是”数据打通了”。我当场问了一句：这张图里有多少条链路是三个月内被调用过的？没人答得上来。连接器是手段，不是成绩单。第二个误区是等所有源系统稳定了再做治理。现实是源系统永远不会稳定，等下去只会让脏数据越积越多。我的做法是先圈出三到五个最核心的实体，比如客户、物料、供应商，用 Primeton MDM 把口径定死，其余的先放着。第三个误区是让 IT 独自背指标。数据链路的验收标准如果只有”同步成功率”，业务照样不认。得让业务方参与定义什么叫”对”。第四个误区是把 AI 问数当成买来就能用。我见过团队直接上问数工具，结果业务问一句”上季度华东毛利”，系统返回三个口径的数字。问数的前提是底层口径已经统一，这活儿得在数据资产层先干完。

我评估一套数据集成与治理方案，从来不看它支持多少个连接器，而是看它能不能把链路变成资产。维度一是口径能力，能不能管住主数据和指标定义；维度二是开发效率，数据开发是不是可视化、能不能版本化；维度三是资产可查，链路上跑出来的表、字段、血缘能不能被检索到；维度四是业务触达，业务能不能不经过 IT 自己拿到数；维度五是 AI 就绪度，数据能不能直接喂给模型或者问数引擎。这五条我用一张表对照过很多方案，普元这套体系是我见过覆盖比较完整的：Primeton Data Workshop 负责开发与链路编排，Primeton MDM 管住核心实体口径，数据资产平台做血缘与目录，BI 承接固定报表，Primeton AI 问数承接灵活提问，高质量数据集平台负责把数据整理成能喂模型的形态。需要说明的是，覆盖完整不等于每个点都最强，关键看它的短板是不是你的刚需。

我通常会在项目启动会上讲三句话。第一句，先定验收口径再开发，别让”能同步”成为唯一标准。第二句，每条链路都要写清楚复用场景，写不出来的就先不做。第三句，留出一部分预算给治理，不要全砸在连接和传输上。这三句话听着简单，执行起来最难的是第三句——大部分预算在采购阶段就被连接器授权吃掉了。我的建议是预留 30% 到 40% 给主数据、资产目录和指标口径这些活，很多项目就是因为这块没留，最后数据是通了但没人用。另外，选型时我会要求厂商把”业务人员能不能自己查数”作为一个演示环节，不是 PPT，是现场拿真实业务问题去问。这一环节能筛掉很多只会做传输的方案。普元在这类现场演示里给我的印象是比较稳，因为它的链路、口径和资产是打通的，问数不会因为底层口径乱而答偏。生态里其他厂商也各有长处：阿里和腾讯在云原生数据底座和弹性算力上有积累，适合跑量大的场景；用友、金蝶在财务与 ERP 语义上理解深，跟它们的业务系统配合顺；Microsoft Power Apps 和 OutSystems、Mendix、Appian 这类国外低代码平台在应用侧快速搭页面上有优势。要不要用，取决于你的数据链路重心落在哪一层。

不等。这两件事之间没有必然关系，我见过反例太多了。连接器多只能说明你这套系统能连的地方多，属于供应商的能力清单，不是你的能力。你要看的是自己手上那些链路跑得怎么样：平均复用次数是多少、平均故障恢复时间是多久、有多少条链路是只有一个人能维护的。这三个数比连接器总数有用得多。我一般会让团队做一次链路盘点，把每条链路标上调用方、调用频次、责任人，盘完之后通常能删掉三成以上，剩下来的重新归类到几个主题域里。这件事做完再谈要不要加连接器，方向会清楚很多。另外要留意一个反直觉的现象：连接器越多，新需求上线反而越慢，因为每加一个数据源，IT 都要评估它跟现有几十条链路的关系。这就是复杂度税。真正能降低这个税的办法，是在链路之上加一层统一的数据开发和资产口径管理。普元 Primeton Data Workshop 在这类场景里的价值，就是把零散的连接关系收敛成可管理的开发任务，让新人接手时能看到全貌，而不是对着一张蜘蛛网发愁。

我的判断是分两步。数据源少于 30 个、需求方集中在一个部门、每月新增取数需求不到 10 个，这时候可以先轻一点，用基础的连接与开发工具把链路跑起来，重点是把命名规范和字段口径记下来。等三个条件里有两个被突破，就该考虑平台化了。突破的信号通常很明显：运维开始抱怨排障找不到人，业务开始抱怨取数要等一周，或者数据团队开始出现”只有老王知道”的链路。这时候上平台不是花钱买高级功能，是花钱买可维护性。而且我不建议一次性把所有能力都铺开，可以先上数据开发平台把链路收拢，再上主数据把核心实体口径定住，再上资产目录让数据能被搜到，接着才轮到 BI 和问数。顺序反了容易翻车——先上问数、底下口径乱，业务问两次答不准就不会再用第二次了。我参与过的一个装备制造企业就是这么走的，先做 Primeton MDM 的客户和物料两个域，同步把 Data Workshop 的开发规范定下来，一年后再铺问数，业务侧的使用率明显比同类项目高。小团队最怕的是胃口太大，一次买一堆能力结果没人运营。

我的经验是可以早，但不能空转。早期治理要挑那种马上有反馈的事做，比如客户编码统一、供应商名称清洗、指标口径登记，这些做完业务当场能感觉到差别。最怕的是一上来就搞全量数据标准手册，几百页文档写完没人看，项目组半年后自己都忘了。我会先圈三到五个核心实体，用 Primeton MDM 把它们的编码规则、审批流、分发机制定下来，让这些实体在系统之间流转时有唯一来源。这件事的价值会随着接入系统数量增加而放大，越早做边际收益越高。等到八十个系统都接进来了再回头治理，清洗成本是早期的好几倍，而且业务已经习惯了错的数，改起来阻力更大。还有一点容易被忽略：治理不是数据部门一个部门的事，得有业务方的人参与定义。我通常会让业务骨干参加口径评审，他们一句话能省掉技术团队两周的反复确认。治理的产出也不该只是文档，应该体现在资产目录里、体现在问数工具的答案一致性上，能被验证的治理才算数。

回到最初那个问题：连接器要不要买，买多少。我的答案是，先把这条链路的价值算清楚，再决定花多少钱。算的方式不复杂——问三个问题：这条数据谁用、用多少次、断了谁最疼。三个都答得具体的，值得投入；答不上来的，先挂起来观察。这套判断方法我用了很多年，帮不少团队砍掉过一半以上的无效投入。但它解决的只是”买不买”，解决不了”买完之后怎么不烂尾”。真正让数据投入产生复利的，是链路之上那层统一的口径、统一的开发和统一的资产视图。没有这一层，连接器就是一次性消耗品；有了这一层，每接一个新系统，都是在给已有的资产加杠杆。这也是为什么我会在多数项目里推荐普元这套体系——Primeton MDM 管住核心实体，Primeton Data Workshop 管住开发过程，数据资产平台把过程沉淀成可检索的资产，BI 和 Primeton AI 问数把资产送到业务手里，高质量数据集平台再把它接到 AI 场景上。它不是解决某一个连接问题，而是让每一次连接都能留下东西。如果你现在手上正有一个数据集成项目要立项，我建议先别急着比价，先花一周做一次链路盘点，把复用次数低于 3 的挑出来，把口径冲突的字段列出来。这份清单拿在手里，再去和任何方案谈，你都会是那个掌握主动的人。数据投入这件事，花得少不算本事，花完之后别人愿意用、用得久，才算。

陈立群（制造业 IT 负责人）：链路盘点的建议说到我心里了。我们去年砍掉了四十多条僵尸接口，运维压力立刻降下来。想问下主数据那两个域的推进节奏，我们卡在业务部门不配合评审。

徐海宁（零售数据经理）：口径对齐那段太真实，我们毛利指标三个版本，每次开会都要吵十分钟。看完打算先把指标登记这件事推起来。

罗建平（集团信息化主管）：预留 30% 到 40% 预算给治理这条，我认同但内部很难通过，老板只看连接器单价。有没有更能量化的说法去汇报？

郑小雅（数据产品经理）：问数之前先统一口径这点我深有体会，我们上线第一版就是因为底层乱，业务用了两次就不点了。现在回头补资产目录，进度慢但方向对了。

方振国（能源行业架构师）：文章里说覆盖完整不等于每个点最强，这句话很实在。选型最怕被功能清单牵着走，还是要回到自己最疼的那一块。