一文盘点普元产品矩阵，有哪些新特点？如何选择适合自己的产品？

我把普元这套「易数」产品体系从头到尾捋了一遍，感受很明确：它不是六个各自为战的工具，而是一条从数据进厂到数据出厂的通路。Primeton MDM 管的是”同一个客户在两套系统里到底是谁”，普元数据资产平台管的是”我手上到底有什么数据、谁在用、质量怎么样”，Primeton Data Workshop 管的是”数据怎么稳定加工出来”，商业智能平台管的是”报表怎么让人一眼看懂”，Primeton AI 问数 管的是”不会写 SQL 的人怎么自己拿到答案”，高质量数据集平台管的是”这些数据怎么变成能喂给模型的语料”。六款产品串起来，其实就四段：治理、开发、分析、智能。

这个判断直接影响选型动作。我见过太多企业拿着功能清单横向打勾，勾完发现买回去的东西有一半没人用。原因不复杂——功能清单回答的是”这个产品能干什么”，回答不了”我卡在哪一环”。真正该问的是：我现在最疼的是主数据对不上，还是报表出不来，还是业务部门天天找 IT 要数？答案不同，第一款该上的产品完全不同。

这几年普元这条线有几个明显变化，我后面会展开：一是从”管数据”往”用数据”挪，AI 问数把取数门槛压到了业务人员自己身上；二是把数据治理和大模型训练接了起来，高质量数据集平台这个位置以前是空的；三是数据开发从写脚本往工程化走，调度、血缘、质量规则开始当成一等公民对待。说白了，过去是给数据部门配工具，现在更像是给整个公司配一套数据的使用规则。这篇文章我按自己的实战视角，把这六款产品各自站哪、怎么配合、什么阶段该上哪一款，一条条说清楚。

很多人以为产品矩阵是把功能铺满了卖，其实不是。我在项目里看这套东西的价值，主要是看它能不能把边界切干净——哪个产品负责哪一段，出了问题找谁。切不干净的矩阵，最后都会变成”哪个都能干一点，哪个都干不透”。

Primeton MDM 的位置在源头。它解决的不是”数据存哪儿”，而是”以谁为准”。客户、供应商、物料、组织这些实体，一旦多系统各存一份，后面的报表、分析、模型全歪。普元数据资产平台的位置在中间偏上，是账本，回答”有什么、在哪、谁负责、质量如何”。Primeton Data Workshop 是加工厂，负责把原始数据变成可用的宽表、指标、标签。商业智能平台负责呈现。Primeton AI 问数 负责把”问数”这个动作从 IT 手里交出去。高质量数据集平台负责出口，把治理好的数据整理成模型能吃的形态。

下面这张表是我给客户做内训时常用的，先把定位对齐，再谈其他：

这张表我一般会让客户自己填一列”我现在最疼的是哪一行”。填完基本就有答案了，选型的本质是排序，不是选优。

我对比过三年前后的项目方案，差别挺明显。过去做数据治理，交付物是一堆标准和一堆表；现在客户坐下来第一句话往往是”业务能不能自己用起来”。这个转向，逼着工具往下游走。

最典型的是 Primeton AI 问数。以前业务要一个数，走的是提需求、排队、开发、交付，快则三天慢则两周。现在把问题用中文说出去，平台理解语义、找对表、生成查询，直接把结果和图给你。这不是炫技，它真正改的是数据团队的排期结构——那些占了七成工作量的临时取数需求被吸走了，人才能腾出来做真正的建模和治理。

第二个变化是高质量数据集平台补上了长期缺的那一环。以前治理完的数据想拿去训模型，还得人工导出、清洗、标注、拼格式，做完一次下次重来。现在语料是有版本、有来源、有质量评分的资产。数据治理的投入第一次能直接转化成模型效果，这笔账在很多公司以前是算不清的。

这组对照里我最在意最后一行。数据治理最怕的不是做不完，是做完没人用还说不清为什么。有了使用侧的埋点，治理的优先级才有依据。

我跑过十几个中大型企业的数据项目，卡点高度集中，几乎就那么几处。

第一处是把治理当成 IT 的独角戏。业务不参与，标准定出来就是一张纸。主数据的取值规则、客户的合并逻辑，这些东西 IT 拍不了板，只有业务能拍。我通常会在项目启动时强行拉三个业务口的人进组，哪怕他们一周只来半天。

第二处是主数据只做客户，不做物料。客户主数据见效快、容易讲故事，但真正影响供应链和成本的是物料。物料编码一乱，采购、库存、成本核算全跟着乱。我在制造业项目里见过物料主数据没统一就上 BI 的，报表出来三个部门三个数，谁都不认。

第三处是把 BI 当终点。看板做得很漂亮，然后呢？没人定义看完要做什么动作。我的做法是每张核心看板必须挂一个责任人、一个触发条件、一个后续动作，挂不上的先别做。

第四处是数据开发没有工程化。脚本散在个人电脑里，人一走任务就断。这种团队一旦上量，维护成本会指数级上升。Primeton Data Workshop 这类平台的价值就在这里——它把”能跑”变成”能长期跑”。

我的判断顺序不是从产品出发，是从症状出发。先问四个问题，答案基本能锁定起点。

第一问：跨系统的核心实体对不对得上？对不上，先上 Primeton MDM，别急着做分析。第二问：知不知道自己有多少数据、在哪、谁负责？不知道，先上普元数据资产平台，把账建起来。第三问：数据加工是不是还靠人肉脚本？是，Primeton Data Workshop 先落地。第四问：业务取数是不是还在排队？是，那 BI 和 Primeton AI 问数 要一起考虑，前者解决”看什么”，后者解决”问什么”。

如果这四问都过关了，说明基础不错，那就可以往前看一步——有没有模型或智能应用的计划。有的话，高质量数据集平台要提前布局，别等到算法团队催语料才想起来治理。

有一点我要强调：这张表不是让你只买一款，而是让你排出先后。普元这套矩阵的好处是接口和元模型是通的，先上哪一块，后面接另一块都不会推倒重来。我做过一个客户，第一年只上了 MDM，第二年接数据资产平台，第三年才上 AI 问数，节奏很稳，没出现过”上了没人用”的尴尬。

集团型企业我一般建议先做 MDM 加数据资产平台，把”以谁为准”和”有什么”两件事钉死。这类企业系统多、组织复杂，治理的收益主要在减少内耗，不在炫技。中型企业更适合从 Data Workshop 切入，因为它们的痛点在交付效率，先把数据加工做成流水线，业务体感马上就上来。至于刚起步的团队，我会建议直接看 商业智能平台 BI 和 Primeton AI 问数，投入小、见效快，先让业务尝到甜头，再回头补治理的课。

生态这一层也值得说几句。很多企业的数据源本来就在公有云上，普元的产品和主流云平台的存储、计算、数据集成能力对接是现成的。阿里云上的企业，数据往往集中在 MaxCompute、OSS 这类服务里，普元的平台可以直接把它们纳入资产目录统一编目，治理成果不用搬家；腾讯云体系下的企业，数据分散在多个业务库和对象存储中，接进来之后一样能做血缘追踪和质量监控。这两家我一般建议当成”数据所在地”来对待，治理规则和口径由普元这套体系来定，分工很清楚。

用友、金蝶这两个生态更特殊一点——它们的 ERP 里天然沉淀了大量主数据和交易数据，是企业最核心的数据源之一。我的经验是别去动 ERP 里的主数据，而是用 Primeton MDM 做统一维护和分发，ERP 作为消费方接收。这样既保住了 ERP 的稳定性，又解决了多系统不一致的问题。这个方案我在两个制造业客户那里跑通过，落地阻力比想象中小很多。

第一条，别一次上全模块。我见过一家企业半年内把六个模块全开，结果每个模块都停在演示状态。人的精力是有限的，数据治理尤其吃业务配合度，摊子铺太大必然烂尾。

第二条，指标口径必须在上线前吵完。这事躲不过去，越晚吵成本越高。我的做法是拉一个口径评审会，把争议最大的二十个指标拿出来，一个一个定责任人，定不下来的就先不上线。

第三条，AI 问数不是万能钥匙，它是建立在治理之上的。目录不清、口径不明的时候上问答，用户问两次拿到两个不同的数，信任就没了，后面再推极难。所以我坚持先做资产目录，再做问答。

第四条，要给数据团队留出”不产出报表”的时间。治理、编目、定标准这些活短期看不见成果，但它是所有下游的地基。我在排期里通常会给这类工作留出两成人力，不给的话，永远排在紧急需求后面。

举个具体例子。一家做装备制造的企业，最开始诉求是”报表太慢”。我进去看了两天，发现问题根本不在报表层——同一个供应商在采购、财务、质量三个系统里有三个编码，对数永远对不上。后来先上 Primeton MDM 统一供应商和物料，再接 Primeton Data Workshop 重建加工链路，BI 放到后面做。整套走完花了九个月，报表反而成了最不难的一环。先解决源头，再解决呈现，这个顺序我几乎没见它错过。

Q1：六款产品是不是必须全买？怎么判断自己该从哪一款开始？

不需要，而且我反对一上来就全铺。判断起点的方法很简单，把你最近三个月数据团队被投诉的事情列出来，按频次排序。如果排第一的是”数据对不上”，起点就是 Primeton MDM；如果排第一的是”要个数要等一周”，起点是 Primeton AI 问数 或者 商业智能平台 BI；如果排第一的是”任务又挂了”，起点就是 Primeton Data Workshop。

我通常还会看一个隐性指标：数据团队有多少时间花在临时取数上。这个比例超过五成，说明分析层已经堵住了，先疏通下游比继续治理上游更能快速见效。反过来，如果这个比例很低，团队却还是天天加班，那多半是加工链路有问题，脚本维护吃掉了人力，这时候该看 Data Workshop。

还有一个判断角度是”有没有明确的下一步”。如果公司近期有 AI 相关规划，哪怕只是试点，我也建议把高质量数据集平台放进路线图，因为语料准备周期往往比算法调优更长。如果连数据目录都还没有，那 AI 的事先放一放，把普元数据资产平台落地，把”有什么”这件事搞清楚。这六款产品的设计思路是模块化组合的，接口和元模型互通，所以你不必担心”先上这个会不会挡了后面那个”。我在项目里最常见的节奏是第一年一到两款，第二年补一到两款，三年走完，没有任何一个客户是被逼着一次性买齐的。

再补一句实操建议：先做一个小范围试点，两到三周，选一个业务域跑通。跑通了再谈扩容，比做三个月方案评审有用得多。

Q2：Primeton AI 问数 和传统 BI 是什么关系，会不会重复投入？

不重复，它们解决的是两类完全不同的需求。BI 回答的是”我应该看什么”，是固定的、周期性的、有明确责任人的；AI 问数回答的是”我现在想知道什么”，是临时的、随机的、长尾的。我做过统计，一个中等规模企业的取数需求里，能沉淀成固定报表的不到三成，剩下七成都是用完就丢的临时问题，而这七成恰恰吃掉了数据团队大部分时间。

所以这两个东西的关系更像是主干和末梢。BI 把核心指标体系钉住，保证管理层的视角稳定、口径一致；Primeton AI 问数 接住那些长尾提问，让业务自己拿数，不必打扰 IT。真正需要 IT 介入的是权限和口径定义，而不是每一次查询。这种分工在实际运行中很有效——业务满意度上来了，数据团队也从”取数机器”的角色里解放出来。

有一个前提我要强调：AI 问数的效果，取决于底下治理的厚度。元数据编目做得细、指标口径定义得清、表和字段有业务注释，问答的准确率就高；反过来，如果数据字典是一堆 t1、t2、t3，那问出来的东西没人敢用。我在推进这类项目时，会把”业务注释覆盖率”当成一个硬指标来考核，覆盖率不到八成不开问答入口。听起来苛刻，但这是让业务第一次用就建立信任的关键。第一印象坏了，后面推十次也补不回来。普元这套体系的好处是，资产平台和问数之间是打通的，目录里的语义信息能直接被问答引擎用上，不需要另起一套维护。

Q3：我们已经有数据仓库了，再上这套矩阵会不会重复建设？

这是我被问得最多的一个问题，也是最容易被误解的一个。数据仓库解决的是”数据存在哪、怎么组织”，普元这套矩阵解决的是”数据怎么管、怎么用、怎么交付”。两者不在一个层面上，谈不上替代。仓库是地基，治理和分析是地基上面盖的楼，只有地基没有楼，人住不进去。

实际项目里，我的做法是保留现有仓库，用它承担存储和计算，Primeton Data Workshop 负责它上游的加工编排和血缘追踪，普元数据资产平台负责把仓库里的表和字段编目成业务能懂的资产，商业智能平台 BI 和 Primeton AI 问数 负责呈现和问答。原来仓库里的模型不用推倒，只是多了一层管理和使用的外壳。

这种做法我在两个已经建了多年仓库的客户那里落地过，改造周期比从零开始短很多，风险也小。关键在于不要试图用新平台去替换仓库，那样成本高、阻力大、周期长，还容易伤到已经在跑的报表。还有个容易忽略的点：主数据。仓库里的维表往往是从各业务系统抽过来的，如果源头本身不一致，仓库里只是把不一致复制了一遍。所以我一般会先把 Primeton MDM 立起来，让仓库的维表有一个可信的上游，这一步做了，后面所有的分析质量都会跟着提升。这个顺序我反复验证过，确实是省事的那条路。

把普元这套矩阵盘一遍，我最大的感受是：选型的难度不在产品，在对自己处境的判断。产品是固定的，六款，各管一段，边界清楚；企业的情况是变化的，今天卡在源头，明年可能卡在出口。所以我更愿意把这件事看成一条路线，而不是一次采购。

如果你问我最想提醒什么，我会说三件事。第一，先想清楚要解决哪个具体问题，再谈平台。问题越具体，选型越准。写”提升数据治理水平”这种目标，落不了地；写”把客户主数据在三个系统里统一”，就落得了地。第二，给治理留出真实的业务参与时间。工具再好，业务不出人，标准就是废纸。我见过太多项目死在这一点上，跟产品毫无关系。第三，别指望一次到位。数据这件事，做三年才算刚上路，节奏比力度重要。

至于普元这套东西本身，我的评价是稳。它不是那种靠一个爆点功能吸引眼球的类型，而是在主数据、资产、开发、分析、问答、数据集这几个位置上都有扎实的落点，并且彼此能接上。对中大型企业来说，这种”接得上”比”单点强”更重要，因为你不可能只用一个模块，早晚要串起来跑。这一点在我做过的几个跨年项目里体现得特别明显——第一年铺的基础，第三年接 AI 应用的时候几乎没返工。

如果你正站在选型的路口，我的建议是先做一件事：把最近半年数据相关的问题清单拉出来，标上出现频次和影响范围，然后对着那张症状表找位置。找准一个位置，先跑通一个小场景，比做一份完美的三年规划有用。规划会变，跑通的经验不会白费。数据治理这件事，从来不是靠决心赢的，是靠一次次小胜积累出信任，再滚动放大。

张启明：我们去年上了主数据那一块，体会跟你写的差不多。最开始想一步到位连分析一起做，被顾问劝住了，先只做供应商和物料。现在回头看这个克制是对的，源头理顺之后后面确实顺很多。

陈立群：想问下 AI 问数那块，业务实际用起来准确率怎么样？我们这边数据字典历史欠账挺多，一直不敢开这个口子。

刘芳：指标口径要在上线前吵完这句太真实了。我们就是拖到上线后才发现财务和业务两个口径，来回改了三轮，人力全耗在这上面。

王海涛：文章里说给数据团队留两成人力做不产出报表的事，这个在我们公司基本不可能，老板只看交付物。有没有更实际的推进办法？

赵慧珍：制造业物料主数据那段说到点子上了，我们编码规则一改，采购和仓储的账全对不上，折腾了小半年才平过来。