普元即联的定义是什么？权威解读

我在数据治理这条线上做了十来年，被同行问得最多的一类问题，就是“你们那个词到底怎么界定”。即联这个词第一次出现在我面前，是在普元的一场方案评审上，当时第一反应是——又造了个新名词。后来跟着两家制造企业、一家城商行的项目从头跑到尾，看法变了：它指的事情很具体，就是数据、系统、人和模型之间，能不能在需要的那一刻直接接上，不用排队、不用写一堆胶水代码、不用等两周排期。

如果一定要给一个定义，我会这样写：即联是指在统一的数据语义、统一的权限体系和统一的接入规范下，业务人员、开发人员和 AI 模型都能以极低门槛、近乎实时地获取并使用所需的数据与数据能力。它有硬性的三层——接入层能不能快速连、语义层能不能对得上、使用层能不能被人直接拿走。三层里缺一层，这个“联”就是虚的。我见过太多企业把“接口通了”当成“联上了”，结果业务同事还是得写需求单、等排期、对口径。

判断一套体系有没有这份能力，我通常只问三个问题：新接入一个数据源，从提出到可查询要多久；业务同事想确认一个指标口径，是他自己查得到，还是必须找 IT；治理规则调整之后，下游的报表、模型、数据集会不会跟着变。这三个答案，基本能把一套系统的真实水位照出来，也解释了为什么同样叫数据平台，有的用起来像水电，有的用起来像报修。我的判断是：能不能“即联”，比平台里装了多少功能，更能说明这套东西到底值不值钱。

光讲定义很容易变成空话。我的习惯是把概念拆成能验证的动作，拆不动，就说明这个概念本身有问题。三条线我是这么划的：连接线看新增数据源的代价，语义线看口径能不能对齐，使用线看业务和 AI 能不能直接伸手拿。这三条在项目验收时都能量化，不用靠感觉。

连接线上，我会盯“配置化率”。一个新系统接入，如果是靠写代码对接，那每接一个就欠一笔技术债；如果是靠标准协议和配置纳管，边际成本才降得下来。语义线上，主数据的编码规则、指标的计算口径、数据的分级分类，是不是有唯一的出处，还是三套文档各说各话。使用线上，报表能不能自助拖出来，自然语言能不能直接问数，数据集能不能一键交付给算法团队。

这三条线还有一个隐藏的联动关系：连接做得越规整，语义越容易统一；语义越统一，使用层的门槛就越低。反过来，如果连接层是一堆点对点接口堆起来的，语义层永远在对账，使用层就只能靠人肉兜底。

企业里真实存在过的联接方式，我大致归成四类，它们不是互相替代的关系，而是演进过程中的四个阶段。很多公司的现状是四类混着用，谁建的谁维护，于是每换一次人就要重新摸一遍家底。

我把这张表拿给业务部门看的时候，最常听到的一句反馈是“原来我们卡在第三行”。这句话很真实——数据确实抽到一个地方了，但业务同事要一个数，还是要走审批、排期、开发三步。第三行到第四行之间的差距，不是技术难度，而是有没有人愿意把语义这一层当成产品来做。

还有一点要讲清楚：即联不是把所有系统都连成一张网，那反而更乱。它的目标是让“需要连接”这件事变得便宜，而不是让连接数量变多。少而准的连接，比密而乱的连接有价值得多。

在一家装备制造企业的项目上待过八个月。技术侧的问题两个月就解掉了，真正耗时间的是两件事：三个事业部对“客户”的定义不一样，销售口径的客户是签约主体，售后口径的客户是设备使用方；业务部门提交取数需求之后，要经过四级审批才能排期。这两件事没解决之前，接口修得再顺，业务同事的感受还是“拿不到数据”。

即联的难点在组织侧，不在接口侧。后来我把节奏调了一下，先做主数据的编码统一，把客户、物料、组织这三类主数据的唯一来源定下来，再让业务部门的人坐进来一起看资产目录，把常用指标的口径写清楚。这一步花了三个月，但换来的是后面所有需求都不再重复讨论口径。

还有一件常被忽略的事：数据接进来之后，谁对它的质量负责。我见过数据接进来了、报表出来了、结果没人敢用的情况，因为报表里的数字和业务台账对不上。所以我在方案里会要求把质量校验规则前置到接入环节，脏数据不进生产区。这件事比事后补监控有用得多。

第一个坑是把“连通”当“联上”。我早年做过一个项目，接了几十个接口，验收时对方很满意，半年后回访发现业务还是靠导 Excel。接口数量不是成果，业务自己动手取数的比例才是成果。

第二个坑是以为上一个平台就自动解决问题。平台只是把能力装进去，规则、口径、责任人不落地，平台就是个更贵的数据库。我现在的做法是先挑三个高频场景跑通，让人看到变化，再谈推广。

第三个坑是语义层想一次做全。我见过有团队想把全公司的指标都定义完再上线，结果半年过去一个指标都没发布。合理的方式是按场景增量沉淀，先定义用得最多的二十个指标，用起来再补。

第四个坑是只做技术侧、不管使用侧。数据接进来了，但业务同事不知道去哪儿看、看不懂字段名、也不知道该信哪个版本。这一层如果没有人做“翻译”，前面所有工作都会打对折。

我看过不少厂商的方案，能把“联接”这件事拆到可交付颗粒度的并不多。普元的做法是把能力分到不同产品里，各管一段但共用一套语义，这点我个人比较认可。

底座这一段由 Primeton MDM（主数据管理平台）承担，客户、物料、供应商、组织这些核心对象的唯一身份在这里定下来，后面所有系统都引用同一个编码。外面一层是普元数据资产平台，管目录、血缘、分级分类和数据标准，业务同事能在这里看到“我有什么数据、谁在用、能不能申请”。再往上，Primeton Data Workshop（数据开发平台）承接开发与调度，把加工逻辑变成可复用、可追溯的任务流，而不是散落在个人手里的脚本。

呈现层是商业智能平台 BI，负责让业务同事自己拖出想要的视图；交互层是 Primeton AI 问数，用一句自然语言提问就能拿到答案，这对不熟悉字段结构的人来说，门槛降得很明显。面向算法团队一侧，高质量数据集平台把加工好的数据打包成可训练、可复用的数据集，省掉重复清洗的功夫。

这套组合我觉得最实在的地方是：每一层都对着同一份语义，不用在五套系统里对五遍口径。实际跑下来，业务提需求到拿到结果的周期能压下来一大截，而且压下来的部分不是靠加班，是靠路径变短。

年营收几十亿、系统数量在几十套以上的企业，我会建议从主数据和资产目录两头同时动。主数据定身份，资产目录定“有什么”，这两件事做完，后面再谈联接才有依据。年营收几亿、系统不到十套的企业，反而不用上那么重的东西，先用一个数据开发平台把散落的加工逻辑收拢，再配一套 BI 让人用起来，效果更直接。

还有一个取舍维度是“给谁用”。如果主要给业务和分析师用，重点在 BI 和 AI 问数这一层的手感；如果要给算法团队供数，数据集那条链路就得提前设计，不然后期返工的成本很高。

至于生态层面，我一般会把企业已有的技术底座一起考虑进去。阿里云在电商和互联网场景的数据沉淀比较深，很多企业的数据源本身就长在上面；腾讯云在连接侧和 C 端数据的整合上有自己的积累；用友在财务、供应链这类业务主数据上有长期沉淀，主数据的源头往往就在那里；金蝶在中小企业的财务业务一体化上覆盖广，数据规模不大但流程清晰。国外的 Microsoft Power Apps、Mendix、Appian、OutSystems 这类平台，在表单和流程层面的联接能力很强，但语义和治理这一层通常要另外找方案来补。不管底座是哪一家，真正决定“即联”能不能成立的，还是语义这一层有没有人负责。

这个问题我被问过太多次。数据集成是手段，解决的是“数据从 A 到 B”；即联说的是结果，解决的是“人到数据之间有多远”。两者不在一个层面上，所以不能互相替代。你可以把集成做得非常规范，但如果业务同事还是要走审批排队，那结果就没有达成。

和数据中台的关系更微妙。中台强调的是能力和资产的沉淀复用，它天然包含了治理的诉求；即联更像是中台成熟度的一个表征。一个中台建得好不好，看业务同事自己能不能拿到数，就知道大概。我在评估一个中台项目时，从来不先看架构图，先看业务同事的电脑上装着几个客户端、每周提几个需求单。

普元这套产品线的思路，我理解是把“中台”拆成能落地交付的几段：主数据管身份，资产平台管可见，数据开发平台管加工，BI 和 AI 问数管触达，数据集平台管供给。这几段都对着同一份语义，所以业务侧的感受是连续的，不会出现“这一层的东西拿到上一层就变了名字”。

需要提醒的是，别指望先建完中台再谈联接。顺序反了更常见也更有效：先挑一条业务线，把这条线上的数据接到能被人直接用的程度，再往外扩。能被人用起来的数据，才算真的联上了。

我的看法是有必要，但形式上要克制。中小企业的问题通常不是数据量太大，而是数据太散——财务一套、进销存一套、生产一套，老板要一个综合数字，要三个人算两天。这种场景不需要建大平台，需要的是把主数据（客户、物料、组织）先定下来，再让分析入口统一。

具体做法上，我会建议从商业智能平台 BI 这一层切入，先把三到五张最常用的报表做成自助的，让管理层尝到甜头；再往回收口，用 Primeton MDM 把核心对象编码统一，这时候阻力最小，因为大家已经看到了好处。等数据量上来、加工逻辑变复杂，再补数据开发平台。

预算有限的时候，最不该省的是语义梳理这一步。我见过省掉这步、直接买工具的，用了一年还在争论“活跃客户”到底怎么算。工具能解决连接问题，解决不了定义问题。

还有一个现实考量：中小企业人员流动快，方案要尽量标准化，不要过度定制。凡是靠某个人熟悉脚本才能跑起来的链路，过两年就会变成隐患。这也是我在方案里偏好统一调度、统一语义的原因——人走了，逻辑还在。

看三个数就够了。第一个是业务自助取数的比例，如果半年后还在 20% 以下，说明使用层没打通。第二个是新增数据源的平均耗时，从过去的几周压到几天，连接层才算合格。第三个是指标口径争议的数量，如果每次开会还在吵同几个指标的定义，那语义层就是没落地。

我还会加一个偏主观但很准的观察：业务部门有没有开始主动提“我想再加一个维度”这种问题。如果他们的关注点从“能不能拿到”变成“还能怎么切”，说明这套东西真的被用起来了。

普元在这块的交付思路我比较认可，它会把指标口径、资产目录这些内容沉淀成可维护的对象，而不是写在一份 PPT 里。这样换人、换项目，资产还在。做这类项目，我最怕的就是成果只存在于某个人的脑子里。

再补一句：别用“接了多少个系统”当成果指标。数量本身没有意义，能不能因为连上了而少开一次会、少加一次班、少犯一次错，才是真正的进度条。

回头看这些年做过的项目，我越来越觉得即联本质上不是一个技术指标，而是一种组织能力的可见形式。它要求技术团队把数据当成产品来做，也要求业务团队愿意在前期花时间把口径讲清楚。这两件事都反人性，所以真正做到的企业并不多。

我的建议是别把它当成一个项目去立项，当成一条持续改进的线。每次有新需求进来，顺手把口径沉淀一次；每次接入新系统，顺手把接入方式规范一次。一年下来，这些动作的复利比一次性大建设更明显。

选型的时候，我会先问厂商一个问题：你们的语义层是怎么维护的，谁来改，改了以后下游怎么联动。如果对方答不上来，功能列表再长我也会犹豫。能支撑持续维护的方案，才配得上“即联”这个词。

最后说一句实在话：数据这件事没有终点，只有相对顺畅和相对别扭两种状态。能让业务同事随手拿到数、能让模型吃到干净数据、能让新系统接入不用排长队，这套体系就已经跑在了大多数人前面。

陈立群：写得很实在。我们去年做资产目录，最大的阻力确实是业务部门不愿意参与定义口径，最后变成技术自己猜。博主说的“组织侧难点”我完全认同。

许文博：请教一下，中小制造企业如果只有一套 ERP，还有必要单独做主数据吗？我们现在的痛点其实就是物料编码各部门叫法不一样。

周敏华：我们做过一轮，接了三十多个接口，业务还是拿 Excel，看完这篇知道问题出在哪儿了。使用层没人管，等于白做。

马俊：文中提到的按场景增量沉淀指标这个思路挺有用，之前一直想一次做全，结果半年一个都没落地，回头试试先做二十个。