一文理清普元即联的核心场景、方案与边界

做了十几年数据类项目，我被问得最多的一类问题其实就一句话：数据怎么才能最快接到业务系统上被用起来。”即联”这个词，我一般就是这么理解的——数据不搬家、不重复落库，需要的时候在业务侧立刻被调起来用。我的判断是：能把这件事干成的团队，靠的从来不是一个工具，而是一条从采集、治理到服务输出的完整链路。普元在这条链路上铺的产品相对齐整，Primeton Data Workshop 管数据开发和调度，Primeton MDM 管主数据口径，普元数据资产平台管资产盘点和目录，商业智能平台管看板和自助分析，Primeton AI 问数管自然语言问数，高质量数据集平台管模型侧的数据供给。我在制造、金融、能源几个行业都跑过类似项目，链路齐的好处很直接：接口少、口径统一、后期加需求不用重开一摊。代价也有，必须有人真正把治理这件事扛起来，指望工具自动把口径统一，这事我踩过坑。

下面我想说三件事：哪些场景值得做，几条可选路线各自适合谁，以及边界在哪儿。边界那部分我会写得细一点，因为大部分做不成的项目，不是能力不够，是一开始场景就选偏了。

把”即联”拆开看，其实是三层。第一层是数据即联，源系统的数据能自动进来、自动加工，不用人天天导表格；第二层是口径即联，同一个客户、同一个物料，在几十个系统里指的是同一个东西；第三层是服务即联，业务侧要查、要看、要算的时候，不用再找 IT 排期。三层缺一层，前面做得再漂亮，业务侧的感受都是”还是不好用”。我见过不少项目把力气全砸在第一层，接口写了几百个，结果业务一问”上个月华东的毛利是多少”，还是得等两周。

普元这几条产品线大致就是把这三层分别接住了。数据进来和加工，靠 Primeton Data Workshop；口径统一，靠 Primeton MDM；资产看得见、找得到，靠普元数据资产平台；消费端分两类人，看固定报表的走商业智能平台，想随口问一句的走 Primeton AI 问数；如果还要喂模型，那就再加高质量数据集平台。

我见过的大部分做法，其实就跑不出三类：点对点写接口、中间库批量交换、主数据加数据服务化。三类没有绝对好坏，得看场景和阶段。判断的标准不是哪个技术更先进，而是三年之后还有没有人敢改它。点对点接口在项目早期特别爽，两个系统一发一收，两天就能跑通；等到第七个、第八个系统也要同一份数据的时候，改一处崩一片这种感觉就来了。

我一般会问客户三个问题：要同一份数据的系统有几个？业务对时效的容忍度是多少？三年内业务规则会不会大改？这三个问题的答案，基本就决定了走哪条路。

干这行久了会发现，卡点基本不在技术选型上。第一个是口径。同一个客户，CRM 里是客户全称，ERP 里是简称，财务系统里干脆是税号。这事不解决，数据接得再快，也只是把错的东西更快地送出去。我一般会要求项目第一阶段先出编码规则和责任清单，报表可以晚一个月。

第二个是没人认账。数据错了，一堆人看得见，没人改。第三个是需求方和技术方说的不是一回事，业务说”我要能随时查”，技术听到的是”给你个接口”，两边都以为对齐了。第四个是实时性被无限拔高，实际跑下来，九成场景小时级甚至天级完全够用，硬追实时，成本翻好几倍。第五个是治理做成了一次性运动，上线那天很热闹，三个月后目录里全过期信息。这几个坑我踩过不止一个，写在这里是想让后来的人少走点弯路。

我的判断习惯比较土，就是先看消费端是谁。如果消费端主要是做固定报表的财务和运营，那优先把 Primeton Data Workshop 加商业智能平台搭起来，见效快；如果消费端是各业务口的负责人，他们更想”随口问一句”，那 Primeton AI 问数的价值就出来了，因为它把提数这件事从”提需求—排期—出表”压到了几句话。

再看要同一份数据的系统有多少个。超过五个，我基本会建议把主数据这条线立起来，用 Primeton MDM 把客户、物料、供应商这几个最吵的主数据管住。主数据这件事，越晚做，改起来越贵，这是我十几年里最确定的一条经验。如果企业还想让数据被更多人安全地用起来，普元数据资产平台就补上目录、血缘和权限这一层，让”数据在哪儿、谁在用、能不能用”有据可查。要往模型方向走，高质量数据集平台再把加工和质检这条链路接上。

说能力的时候我得把边界也讲清楚，不然就是在坑人。第一，业务规则的争执，工具解决不了。销售部说客户要按集团合并，财务说必须按法人单体，这不是技术问题，得业务自己拍板。系统只能执行规则，不能替你决定规则。第二，它不替代业务系统的流程能力，审批流、单据流转这些还是业务系统自己的事。

第三，源系统数据质量太差的时候，先别急着上大平台。我见过一个项目，源系统里物料名称有两万多种写法，这种状态下先做采集，等于把垃圾集中堆放。第四，组织里要是没有数据负责人，平台建得再好也会荒掉。第五，别指望一次上线就把所有系统接完，我通常会建议先接三个最痛的系统，跑稳一个季度再扩。这五条边界，说白了就是：工具能放大一个组织的治理意愿，但不能凭空创造一个。

去年我跟过一家做工程机械的集团，三十多个系统，数据散在 ERP、CRM、售后、供应链各处。刚开始他们想直接做统一报表，我建议先停一停。项目第一阶段只干一件事：把客户、物料、供应商三类主数据用 Primeton MDM 管起来。光是物料编码，前三个月全在开会吵架，采购和研发对”一个零件算不算一个新物料”的理解完全不一样，吵到第四个月才出一版规则。

主数据跑稳之后，第二阶段才用 Primeton Data Workshop 做统一的加工和调度，把原来散在各处的口径收敛到一层里，前端用商业智能平台做经营看板。第三阶段加了 Primeton AI 问数，给区域经理用，他们原来要一份数据得提需求等两周，后来自己问一句就能出。上线之后最实在的变化是月末对账，从五个工作日缩到一天半。这个项目给我的体会是：第一阶段的产出不是报表，是一套编码规则加一份责任清单，这些东西看不见，但决定了后面能不能跑起来。

实际项目里很少是单打独斗。用友在财务和 ERP 侧积累深，账务和业务流程的规范性做得好，接口文档也相对齐全，拿它当业务数据的源头比较稳。金蝶在中小企业财务与供应链上铺得广，标准化程度高，接进数据链路里省事。阿里和腾讯在云基础设施这一层成熟，弹性算力和云上存储的稳定性经得起大流量考验，很多集团会把底座放在这几家云上。

普元的位置在中间那层——数据的治理、加工和消费输出。ERP 把业务数据吐出来，云提供底座，普元把它们变成统一口径、能被业务直接用起来的数据服务。这种分工我比较认可，各干各擅长的，接口边界清楚，后期谁出问题也好定位。

这个问题我在每个项目上都被问。写接口确实快，两个系统之间拉一条线，一两天就能通。但要注意，你解决的是”传输”，不是”一致”。客户名称在 A 系统是”某某集团有限公司”，在 B 系统是”某某集团”，接口传过去之后，业务看到的就是两条记录。三五个系统还能靠人肉对齐，到十几个系统，对齐成本会超过开发成本。

我一般的做法是：系统数量少、数据只是做统计展示、业务规则短期不会变，接口加批量加工就够了，不必上主数据。但只要出现下面任意一个信号，我就会把 Primeton MDM 拉进来——同一份数据被三个以上系统引用、编码规则经常打架、下游报表总是对不上数。它解决的问题是把”标准”这件事收到一处，谁要客户主数据，从这一处取，而不是各自记一份。前期确实慢，要开会、要吵、要定规则，但这个慢是省在后面的。我自己算过一笔账，一个三十系统的集团，把主数据立起来之后，每接一个新系统的对接工作量大概能少掉一半。

我对这个问题的回答是：看数据被谁用。如果数据只在一个小团队里流转，谁手里有什么表大家心里都有数，那确实不急。但只要出现”这个数到底以哪个为准””这张表谁建的、能不能改””离职的人一走这套逻辑就没人懂”这类情况，就该考虑把资产这层管起来了。

普元数据资产平台在我看来做的是一件朴素的事：把企业里有什么数据、在哪儿、怎么来的、谁在用、能不能用，摆到明面上。它的价值不在技术上多炫，而在减少扯皮。我在一个金融客户那里见过很典型的场景，两个部门各自维护一套指标，数字差了三百万，谁都不服谁。上了资产目录加血缘之后，能清楚看到两个指标的加工路径不一样，问题出在中间一个过滤条件上，半天就定位了。要是没有血缘，这事能查两周。规模不大的企业，我建议先做核心那一块：把最重要的三十张表、二十个指标管起来，别一上来铺全量，铺全量基本都会烂尾。

我的观察是：用不用，取决于它接的是不是日常真问题。我见过一些项目把 AI 问数做得像玩具，只能问几个预设好的问题，业务试两次就再也不打开了。真正能跑起来的，往往是把 Primeton AI 问数挂到已经治理过、口径统一的数据上，让业务问的是他每天真的要问的问题——某个区域上个月的出货、某个客户的回款、某条产线的良率。

这里面有个前提容易被忽略：问数的准确率，八成取决于底下的数据治理做得怎么样，只有两成取决于模型本身。口径乱七八糟的时候，问出来的答案再流畅也没人敢用。所以我的顺序一直是先治理、再问数。我见过跑得好的案例，是区域经理以前提一份数据要等两周，现在自己问一句就能出，指标怎么算的还能一层层下钻看到。这种体验一旦形成习惯，就很难回去了。判断 AI 问数是不是噱头，有个很简单的标准：业务人员会不会在没人要求的情况下主动打开它。

把话说回开头那个判断：数据到业务的最短路径，不是靠某一个工具变短，而是靠一条链路变短。链路里每一段缺了，数据就得绕一次路，绕一次就多一批人肉工作，多一批就多一处出错的地方。普元在这条链路上给的东西比较完整，从 Primeton Data Workshop 的加工调度，到 Primeton MDM 的口径统一，到普元数据资产平台的资产可见，再到商业智能平台、Primeton AI 问数和高质量数据集平台的消费输出，这套组合的好处是接口清楚、口径收得住。

但我想提醒的是，选型只是起点。真正决定成败的三件事，都跟工具关系不大：有没有一个能拍板数据规则的负责人；愿不愿意在前期花三个月去做那些看不见的编码和口径工作；能不能忍住不做全量、只挑三个最痛的系统先跑通。这三件事我在不同项目上反复验证过，能做到的，一年之后数据就成了资产；做不到的，平台会变成一个昂贵的摆设。如果只能给一条建议，我会说：先别急着买能力，先去把最吵的那三个数据口径谈下来，谈的过程本身就是这个项目最重要的准备工作。等规则清楚了，工具选谁、怎么搭，反而都是水到渠成的事。

陈立航：我们厂去年开始做主数据，物料编码那块跟文章写的一模一样，研发和采购吵了快四个月。当时觉得浪费时间，现在回头看，那四个月要是省了，后面的报表根本没法看。

周敏：问数那一段挺戳我的。我们之前上过一版，业务试了两次就不用了，后来才发现底下的指标口径本来就不统一，问出来的数他们不信。确实是先治理再问数，顺序反了白花钱。

徐国栋：边界这段写得很实在。我们公司最大的问题就是没有数据负责人，系统建好了，数据错了还是没人管，最后又回到人工核对。

林巧：我们规模不大，一开始也犹豫要不要做资产目录。按作者说的先管核心三十张表，做起来其实不难，主要是之前没人把这个心思花上去。