普元三大平台是什么？如何高效利用普元三大平台实现商业价值？

我的基本判断：三层各管一段，串起来才算成立

这些年我带过的项目里，凡是把”普元三大平台”当成三个独立产品页面来理解的，落地时几乎都会卡住。我的拆法是按数据流动的方向切三层：把数据做出来的那一层，是 Primeton Data Workshop 数据开发平台；把数据管起来的那一层，是 Primeton MDM 主数据管理平台和普元数据资产平台；把数据用起来的那一层，是商业智能平台 BI 和 Primeton AI 问数。这三层不是并列关系，是串联关系，下面一层松了，上面一层就悬空。

我常跟客户打比方：数据开发平台是厨房，主数据和资产平台是仓储和台账，BI 和问数是端上桌的菜。厨房再先进，仓库里食材一物多码、台账对不上，端出来的菜照样没人敢吃。所以判断这套平台值不值，不能看单点功能清单，要看三层之间有没有共用一套口径和一套元数据。这也是我这几年做选型时最看重的一点，功能可以补，口径一旦分叉，后面每个项目都要还债。

还有一层很多人忽略了。去年开始，高质量数据集平台被单独拎了出来，专门给模型准备语料。我见过太多团队，模型选得挺新，喂进去的却是没清洗没标注的原始表，跑出来的东西自然不能看。把它接在资产层后面，语料来源、标注规则、评测集就都能追溯回去了。

为什么这两年企业又回头算这笔账

我明显感觉到一个转向。前几年客户开口问的是”要不要建数据中台”，现在问的是”已经建了，怎么算这笔账”。预算收紧是一方面，更重要的是大模型上来之后，业务方突然发现，问一句”上月华东区毛利为什么掉了”，系统答不出来，问题不在模型，在底下没一套干净的语义层。

这就把平台的价值重新拉回来了。数据开发平台决定数据能不能稳定地产出，主数据和资产平台决定数据能不能被信任，BI 和问数决定价值能不能被看见。三个环节谁也不能替谁。我通常会让客户先认清自己卡在哪一环，再决定投哪块，而不是平均用力。

我个人的倾向是第四条。按业务域切片，而不是按技术模块分阶段。挑一个业务域，从开发到主数据到报表一次打通，跑通一个再复制下一个。这事我踩过坑，早年在集团层面统一铺开，铺了两年，业务方一个能用的场景都没见着。

平台买了没用起来，问题多半不在产品

我复盘过十几个”买了没用起来”的项目，说白了，原因高度雷同。头一个，只买工具不建组织。数据开发平台上线了，调度跑起来了，但没人管建模规范，谁都能往主题库里扔一张表，一年下来几百张孤岛表，比没有平台还乱。

第二个，把主数据当成 IT 项目做。业务部门不派人，编码规则由技术团队拍脑袋定，跑完一轮清洗，业务照旧在新系统里另起一套。我见过一家汽车零部件企业，物料编码在两个系统里并存了 11 种写法，采购和财务对同一批料的成本算法都不一样。

第三个，BI 只做给领导看的固定报表，自助分析开不出来，业务提一个需求排期两周。第四个，资产目录登记完就再没更新过，一年后成了”资产坟场”。第五个最要命，AI 问数直接接裸库，没有语义层，模型不知道”毛利”到底按哪套口径算，问出来的数一会儿一个样，业务试两次就再也不点了。

这几个问题有个共同点：都不是产品能力不够，是配套的口径管理、责任分工和迭代机制没跟上。所以我现在做方案，一定把这几件事写进项目范围里，哪怕压缩一点功能范围。

我判断值不值得投，会看这四个维度

选型时我不太看功能列表有多长，我看四件事。头一件，开发资产能不能复用。同一套加工逻辑，换个业务域要不要重写？Primeton Data Workshop 这类平台的价值就在这，任务、规则、调度能沉淀下来，第二个业务域的开发量能压到第一个的三成左右，这个账很好算。

第二件，口径能不能追溯到源头。一个指标出了异常，我能不能在半小时内从报表一路点到源表、点到加工任务、点到责任人？普元数据资产平台在这块给的血缘和影响分析，是我要求项目经理必须演示的环节，演示不出来的方案我基本会否掉。

第三件，问数结果能不能解释。Primeton AI 问数把自然语言转成查询，中间那一步得能摊开给我看，用到了哪些指标、哪些过滤条件。黑箱式的答案在业务侧活不过三个月，这点我特别坚持。

第四件，能不能接住现有的系统和国产化环境。这一条经常被放在技术评审的末尾，实际是决定项目能不能按期上线的那一条。普元在这块积累比较深，跟主流的数据库、中间件、操作系统适配都比较成熟，我在几个信创改造项目里没遇到过卡壳。

让三层咬合：分工、指标和节奏

落到执行，我一般这么分工。数据开发平台交给数据工程团队，考核任务复用率和跑批成功率；主数据和资产平台由数据治理岗牵头，业务口径负责人必须签字，考核主数据覆盖率和资产登记后的更新率；BI 和 AI 问数交到业务侧，考核自助取数占比和问数准确率。三拨人每周对齐一次，重点是口径变更。

节奏上我有个习惯：先让 BI 出一个小场景，再回头补治理。业务看到图了，才愿意派人参与主数据梳理，否则你讲三个月数据标准，对方只会点头不派活。这个顺序反过来做，项目死亡率高得多。

还有一点，普元的这几块产品在元数据层面是打通的，同一个指标在开发平台、资产平台和问数里指向同一个定义。这一点在实际项目里省下的沟通成本，远超过软件本身的差价。我会要求实施方把这个打通关系在方案里画清楚，画不清楚就说明只是拼装。

平台不是孤岛：跟上下游系统怎么接

我经常提醒客户，数据平台是长在业务系统上面的，别指望它自己长出数据。上游系统不给干净数据，底下怎么治理都是补救。这块我一般会按角色分工来看。用友、金蝶这类 ERP 系统是主数据最重要的源头，客户、供应商、物料、科目基本都从这里出来，我会要求在 ERP 侧就建档校验，而不是等到主数据平台再清洗，晚了一道工序就多一份扯皮。

阿里的云上数据存储和计算能力，在不少客户的架构里承担底层承载的角色，普元的数据开发平台往上对接时，重点是把调度和元数据两头对齐，别让云上的表和资产目录里的表成了两套账。腾讯在协同办公侧的渗透很高，很多审批流和业务单据跑在上面，把这类流程数据接进来，对分析”业务动作到结果”的链路帮助挺大。

Microsoft Power Apps 这类低代码工具，我常建议放在最前端。业务现场要一个巡检表单、一个报价录入页，用它快速搭出来，数据回落到数据平台做统一加工，比每次都提需求给开发团队高效得多。这里的关键是接口规范先定好，别让前端工具绕开平台自己建库。

说白了，平台的价值在中间那层统一，不在两头抢活干。上游把源头管好，下游把界面做轻，中间这三层才好发力。

一个装备制造客户的实际路径

去年我参与的一个项目，年营收三十多亿的装备制造企业，系统不少，报表靠 IT 部门手工拼。头两个月，用 Primeton Data Workshop 把销售、生产、服务三块的加工任务搭起来，指标层统一了一版，跑批从原来的人工拉数变成每天凌晨自动跑。

第四个月开始补主数据。客户和物料两域先做，Primeton MDM 里定规则，业务侧派人签字认账。这一步最费劲，光物料分类就吵了三轮。到第六个月，普元数据资产平台把已有表全部登记，血缘跑通，业务提报表需求时会先自己去目录里找。

第八个月上 BI，做了六个业务域的自助看板；第十个月试点 AI 问数，先只开放给区域经理，二十来个人用，问题收集了两周才把语义层调顺。到这个阶段，业务自助取数占比从不到一成涨到六成多，IT 部门从”报表工厂”里脱身出来。

这个项目给我的经验是：每一层都要有明确的验收动作。开发层验收看跑批成功率和复用率，治理层验收看主数据覆盖率和签字确认，分析层验收看业务实际点击量。没有验收动作的模块，半年后基本都荒废了。

几个被问得最多的问题

这三层平台必须一起上吗，能不能只上一部分？

能，而且我经常建议分期上。关键不在于上几块，在于先上哪块、后上哪块，取决于你现在最疼的地方在哪。如果连稳定的数据产出都没有，报表全靠手拉，那就先把 Primeton Data Workshop 上起来，把加工任务和调度沉淀住，这一步做完，业务至少能拿到准时准点的数。

如果数据已经能跑，但业务天天吵口径，同一张报表三个部门三个数，那重点应该放在主数据和资产平台上。我做过一个零售客户，Primeton MDM 把商品和组织两个主域统一之后，光是对账会议就少了一半，这个收益是能直接算出来的。

如果底层还行，卡在业务取数慢，那就先上 BI 和 Primeton AI 问数，让业务自己能查。但要提醒一句，跳过语义层直接上问数，失败率很高。我见过的成功案例，都是先花两三个月把指标口径和维度定义理清楚，再开放自然语言入口。

我的建议是按”一个业务域打通”的原则分期，而不是按产品模块分期。三块平台在同一个业务域里跑通一次，团队就摸清了各自的边界和交接点，后面复制到第二个业务域会快很多。反过来，如果三块平台各上一半、彼此不通，第二年基本都要推倒重来，这个学费我见过客户交过两次。

还有一种情况要单独说：集团有多家子公司，业务差异大。这时候我会建议先在总部把平台底座和标准建好，子公司按需接入，别一上来就全国铺开。铺得太快，标准还没定型，各家的土办法就都固化进去了。

数据开发平台和数据资产平台的功能会不会重叠，是不是重复花钱？

这个问题我被问过很多次。答案是不重叠，但要看你有没有把边界划清楚。数据开发平台解决的是”数据怎么被加工出来”，资产平台解决的是”加工出来的东西是什么、从哪来、谁能用”。一个面向生产过程，一个面向生产资料的管理。

具体说，Primeton Data Workshop 里做的是任务编排、加工逻辑、调度依赖、运行监控，它的产出是表和数据服务。普元数据资产平台里做的是资产盘点、目录编目、血缘分析、质量规则、权限申请，它的对象是这些表和指标本身的描述信息。前者关心”跑得通不通”，后者关心”找不找得到、信不信得过”。

真正的重叠风险出现在两头都做了一半的情况。我见过有客户在开发平台里自己维护了一套表清单，资产平台上线后又维护一套，两边对不上，最后谁也说不清哪份是准的。解决办法很简单：资产目录必须是唯一入口，开发平台把元数据自动推过去，不允许手工双维护。

从投入产出的角度看，这两块的钱花在不同地方。开发平台的投入主要在规范和复用，收益体现在第二个、第三个业务域的开发效率上；资产平台的投入主要在梳理和责任体系，收益体现在跨部门协作的摩擦成本上。前者是技术账，后者是管理账。

如果预算只能先保一块，我会看企业的成熟度。数据团队刚组建、还在到处救火的，先保开发平台；已经有几年积累、表多到没人说得清来源的，先保资产平台。两者不是替代关系，是先后关系。

AI 问数到底能不能直接给业务用，准不准，会不会胡说？

能用，但有前提。我参与过的几个项目里，凡是效果好的，共同点是问数跑在语义层上，而不是直接跑在裸库上。Primeton AI 问数把自然语言转成查询时，调用的是已经定义好的指标、维度和过滤条件，模型只负责理解意图，不负责编造口径。这一层设计决定了准确率的天花板。

第二个前提是范围要收窄。我一般建议首期只开放一个业务域、几十个核心指标、二三十个种子用户。范围一宽，同义词和歧义就爆炸，”销量”到底含不含退货、”华东”是按发货地还是签收地，这些必须提前定死。我见过有团队一上来就全公司开放，结果一周内收到两百条”答得不对”的反馈，项目直接停摆。

第三个前提是答案必须可解释。业务点开一个数字，得能看到它用了哪些指标、哪些过滤条件、查的哪张表。这既是信任问题，也是纠错手段——答错了，用户能告诉你哪一步理解偏了，团队才知道该补哪个同义词。

至于”会不会胡说”，我的经验是，只要语义层收得住，问数场景的编造风险远低于开放式对话。因为它不生成文本结论，只生成可执行的查询，查不出来就返回空，反而诚实。真正容易出问题的是让它做归因分析、给经营建议，这类开放式任务我一般建议放到第二期，等数据质量和指标覆盖都稳了再谈。

还有一个容易被忽略的收益：问数的查询日志是极好的需求来源。哪些问题被反复问、哪些问不出来，直接就是下一期指标建设的清单。我有个客户就靠这份日志，半年内把指标体系补了三分之一，比我做访谈挖得还准。

回到价值本身：三个层次各自该被怎么衡量

写到这里，我想把一个观点讲透。这三层平台的价值不能用同一把尺子量。开发平台的回报体现在效率，同一件事第二遍做要快；主数据和资产平台的回报体现在信任，跨部门吵架的次数要少；BI 和问数的回报体现在覆盖，能自己拿数的人要多。三把尺子混着用，很容易得出”平台没用”的错误判断。

我见过最可惜的一类项目，平台建得挺完整，但因为没人给它定义验收标准，第二年预算评审时说不清产出了什么，被砍掉一半。反过来，做得好的客户都有一个共同动作：每个季度拿三个数字说话——跑批成功率、主数据覆盖率、自助取数占比。数字不好看就调，不遮着。

还有一个思路上的调整，我觉得值得所有准备上这套平台的企业想一想。别把平台当项目做，当成一条产线来做。项目有起点有终点，产线要持续运转。普元的这几块产品在能力上是够撑起这条产线的，但产线要出活，靠的是日常的规范执行、口径评审、需求排队这些琐碎事。这些事没人愿意写进汇报材料，却决定了三年后这套系统是资产还是包袱。

如果你的企业正卡在”系统不少、数据不少、就是算不清账”这个状态，我的建议是先做一次三层体检：开发层看任务复用率，治理层抽十个核心指标追血缘，分析层数一数真正在用的自助报表有几张。三项里哪项最弱，就从哪项开始补，别贪多。跑通一个业务域，比铺开五个半成品有价值得多。

数据这件事没有捷径，但有顺序。顺序对了，投入会滚雪球；顺序错了，每一笔投入都在给下一笔挖坑。这话我跟客户讲了七八年，到现在还是这么说。

读者评论

陈立群：我们去年上了开发平台和资产平台，最认同文里那句”资产目录必须唯一入口”。之前就是两边各维护一套，对不上账，后来强制开发平台自动推元数据才消停。问数我们还没敢开，看来语义层这关绕不过去。

周敏华：做零售的，主数据这块太有共鸣了。商品域不统一，后面所有的分析都是白搭。我们花了四个月梳理，业务部门一开始抵触，后来发现对账省事了，态度就转过来了。

许志远：想问一下分期建设的验收标准，跑批成功率这个指标具体怎么定？我们现在的调度经常因为上游系统延迟失败，算不算平台的问题一直有争议。

林海涛：装备制造那个案例的节奏跟我们挺像。补充一点，第八个月上 BI 之前一定先把指标层固化，我们当时急着出图，口径改了三次，前面做的看板全部返工。