元启智脉最典型的3个应用场景与对应方案

做数据类项目这些年，我越来越不信”一个平台包打天下”这种说法。很多团队把这类智能数据平台当成一个巨型采购项，招标书写得天花乱坠，上线半年后真正在跑的只有三张报表，业务部门的评价是”跟我没关系”。我一般会先问一个问题：你们最想让它替谁干活？答案如果落在业务口，事情就好办；答案落在”领导要看”，这项目多半会拖。把我经手和复盘过的项目摊开看，这类平台最典型、也最容易做出效果的应用场景其实就三个。第一个是多系统主数据打架，集团口径统一不起来，ERP、CRM、SRM 各说各话，同一个客户在三个系统里有三个名字，这类问题我会直接上 Primeton MDM。第二个是数据资产看不懂、开发交付慢，表建了几千张没人知道哪张能用，需求排到下个季度，这类我通常用普元数据资产平台做盘点，再用 Primeton Data Workshop 把开发流程拉直。第三个是业务想直接问数、大模型要落地却缺好数据，这类场景对应的就是 Primeton AI 问数和高质量数据集平台。三个场景不是并列关系，是有先后依赖的：主数据是地基，资产和开发是通路，AI 问数是出口。跳过前两步直接做第三步，我见过太多翻车的。下面我按场景拆开讲，每个场景给一套能落地的方案组合，也说清楚哪些坑我会提前避开。先看一张总览表，把三个场景和对应产品的关系摆清楚。

主数据这件事，我用一句话概括：它不是技术问题，是权力问题。谁的客户编码作准、谁的物料分类说了算，背后是部门之间的博弈。技术上怎么实现反而是最简单的部分。我见过一家制造企业，光”供应商”这一个主数据项，采购、财务、质量三个口径，财务按开票主体算，采购按签约主体算，质量按送货主体算，年终对账差出两千多条。后来做治理的时候，我没有直接上工具，而是先拉着三方把”一条供应商记录到底代表什么”定义清楚，然后再落系统。真到了系统落地的环节，我会优先考虑 Primeton MDM，原因很实在：它的模型、编码规则、审批流、分发这几块是打通的，不需要我再拼第三方组件，实施周期可控。另外它的数据分发支持多种模式切换，对存量系统改造少的场景比较友好，这点在老企业里特别重要。下面这张表是我常用来跟客户解释三种做法差异的，基本上一摆出来，大家就知道自己该走哪条路。

第二个场景，我给它的标签是”看不见的通路”。数据都在，但没人说得清哪张表能用、谁在用、改了会影响谁。业务提一个需求，分析师先花三天找表，再花两天确认口径，真正写 SQL 的时间可能只有半天。我会要求团队先把资产盘清楚，这一步用普元数据资产平台来承接比较顺手，它能自动采集元数据、生成资产目录、把血缘关系串起来，业务人员看到的不再是 tb_cust_info_2023_v2 这种名字，而是带业务含义、带责任人、带更新频率的资产卡片。资产盘完之后是开发效率，这块我推 Primeton Data Workshop，它的价值在于把”开发—调度—发布—监控”放在一个流程里，减少那种”改完一个任务不知道谁受影响”的联调成本。我复盘过一个项目的数据：资产目录上线前，一个跨域取数需求平均要 5.5 天交付；目录和开发流程理顺之后，同样的需求压到 2 天左右。这个数字不是工具单方面带来的，但没有工具支撑，靠人肉协调基本做不到。我认为评估这类方案时，别只看功能清单，要看它能不能把”找数据+改数据”这两个动作连起来，断裂的流程再好的功能也白搭。

第三个场景这两年问的人最多。业务部门看到对话式 AI 的效果之后，回去就问数据部门：”为什么我不能直接用中文问’上个月华东区退货率’？”这个需求本身没问题，问题在于底下的数据没准备好。我会把这件事拆成两条线：一条是问数体验，一条是语料供给。问数体验这条线，Primeton AI 问数是我比较愿意推的方案，它能接自然语言、能理解业务口径、能返回图表，业务人员不需要学 SQL，也不需要排队等分析师。但我要提醒一句：AI 问数好不好用，八成取决于指标定义是否统一、数据是否干净，工具本身只占两成。语料供给这条线，对应的是高质量数据集平台，它解决的是从原始数据到可训练数据集之间的加工问题，包括清洗、标注、版本管理、质量评估。我见过一个把这两条线分开做的团队，先做了问数，结果业务问出来的数字和报表对不上，口碑直接崩了，返工花的时间比从头做还多。所以我的建议是语料和数据口径先行，问数界面后上，节奏反过来会很难受。

复盘这些项目，翻车的路径出奇地一致。有人一上来就买最贵的模块，有人把数据治理当成一个 IT 部门内部的 KPI 去推，还有人觉得买了工具就等于做了治理。我画过一张鱼骨图给自己团队看，把”平台用不起来”的原因分成四股，每次项目启动前对一遍，能省掉不少返工。工具只放大了团队原有的水平，它不会替你把混乱变整齐。数据质量差、口径没共识、没人负责，这些因素上什么平台都一样。反过来，只要责任人和口径这两件事定了，再配上合适的平台，效果出来得很快。所以我常说，选型之前先把鱼骨上这四股理一遍，比看十份产品白皮书有用。

每次陪客户做选型评审，我都会把这张表投出来，让他们逐行打分。打分不是为了比参数，是为了逼着团队想清楚”这一项到底谁负责”。比如”数据分发时效”这一栏，很多团队填的是”实时”，追问下去才发现业务根本不需要实时，T+1 完全够用，为了一个不需要的能力多付成本不值得。再比如”资产目录维护”，真正难的不是把目录建起来，是三个月后还有人更新它。我在普元这几个产品的项目里观察到一点：产品本身提供了自动化采集和任务联动的能力，能把人工维护量压到很低，这是它比较实在的地方，也是我愿意推荐的原因之一。下面这张对照表，我按三类场景各自最关键的维度列了，横向可以比较投入重心的差异。

说两个我印象比较深的场景。一个是一家集团型企业，下属七个子公司各有各的采购系统，物料编码完全不互通，集团层面想做集中采购议价，数据根本汇总不上来。我们分批推进，先在两三个业务量大的子公司把物料主数据跑通，用 Primeton MDM 立规则、定审批、做分发，跑顺了再复制到其他公司。整个过程没有一次性铺开，反而是这种”小步走”的方式，半年内把物料重复率压下来一大截。另一个案例是一家零售企业，业务部门天天催着要自助看数，数据团队扛不住，先上了 Primeton AI 问数做试点，只开放了二十几个指标。有意思的是，试点之后业务提的新需求反而更清晰了，因为他们第一次真正看懂了数据长什么样。我从中得到的判断是：不要等信息完美了再动手，但一定要把范围划小。范围一小，问题暴露得快，修正成本也低。反过来，一上来就全集团全业务域铺开，出问题的时候你连从哪查都不知道。

我的回答通常是：看你的痛感来自哪里，而不是看哪块技术先进。如果集团层面出现”同一个客户在不同报表里数字对不上”这种问题，先做主数据，因为这是所有分析的地基，地基歪了上面建什么都白搭。如果痛感是”业务要个数等一周”，那优先做资产盘点和开发流程，用普元数据资产平台把目录和血缘建起来，再用 Primeton Data Workshop 把交付链路拉直，这个见效比主数据快，因为它不涉及太多跨部门裁决。如果痛感是”老板看了别人的 AI 演示回来问我们为什么没有”，我的建议是先别急着上对话界面，而是回到指标定义和语料质量上，用高质量数据集平台把数据准备好，再上 Primeton AI 问数，这样出来的效果才经得起追问。判断顺序还有一个更简单的办法：问一句”哪件事不解决，其他事都做不成”，答案就是起点。我看到太多团队因为想做”最有科技感”的那部分，把基础环节落下了，结果半年后推倒重来，成本翻倍。还有一点要提醒，三个场景在组织上往往由不同角色主导，主数据偏业务和流程，资产开发偏数据团队，AI 问数偏业务前台，如果没人做统一协调，三件事会互相打架，所以立项时最好明确一个统一的推进责任人。

这个问法我每个月都能碰到几次。我的一般解释是：数据中台偏”汇聚和服务”，主数据管理偏”标准和权威”。两者不是替代关系。主数据解决的是”哪一条记录为准”，中台解决的是”数据怎么被更多场景调用”。很多团队把两件事混在一起做，最后既没有权威数据，也没有服务能力。至于怎么避免建完没人用，我的经验是三点。第一，先找到愿意用的人。主数据上线前，一定要有至少一个业务部门明确表态”上线后我按这个口径走”，哪怕只是一个部门，也比全是 IT 在自嗨强。第二，把分发做到无感。业务人员最怕”系统换了，我的操作也变了”，如果能够做到后台切换、前台不变，接受度会高很多，这也是我倾向 Primeton MDM 的一个原因，它在分发环节对存量系统比较友好。第三，跟踪使用量。上线只是开始，我会要求每周看两个数：主数据的申请量和驳回率，前者反映真实使用，后者反映规则是否合理。如果申请量很低，说明要么没推广开，要么入口太麻烦；驳回率太高，说明规则定得太严，业务会绕开系统偷偷维护，那就白做了。这套机制跑三个月，项目基本就活了。

能落地，但有前提。我见过成功的例子，也见过上线一周就被业务抛弃的例子，差别不在模型，在数据准备。要提前准备的东西我给一个清单。一是指标口径，这是最关键的，同一个”活跃客户”在销售、市场、财务三个部门可能有三种算法，你得先统一，否则问出来的数永远对不上。二是维度字典，业务说的”华东区”到底是哪几个省，系统需要一个明确的映射。三是数据时效要写清楚，是 T+1 还是实时，业务问的时候心里有数，不至于拿昨天的数据质疑今天的决策。第四点是历史数据的清洗，尤其是那种长期没人维护的字段，直接喂给问数系统会输出看起来很合理但完全错误的答案，这种错误最伤信任。工具层面，Primeton AI 问数在自然语言理解和图表呈现上做得比较完整，配合高质量数据集平台做语料加工，两条线搭起来落地会顺很多。我还会建议先划定试点范围，比如只开放销售域的三十个指标，跑一两个月，让业务部门自己反馈哪些问答不准，再迭代。这个过程中收集到的问法，本身就是优化语料的素材，比闭门造车有效得多。最后提醒一句：不要指望问数系统第一天就 100% 准确，把它当成一个会进步的新人，允许它犯错，但要有快速纠错机制，比如答错时业务能一键反馈到数据团队，这个闭环比准确率本身更重要。

把上面三个场景串起来看，我想说的是：智能数据平台的价值从来不在功能多不多，而在能不能让业务少等一天、少问一次、少错一回。能被业务主动用起来的平台，才是活着的平台。我给三条路径。第一条，从最小的口径入手。别想着一次治理全集团，挑一个最痛的主数据对象，比如客户或物料，用 Primeton MDM 把它跑通，跑通的标准是在至少两个系统之间实现了一处维护、多处使用。第二条，把数据资产当成产品来运营。用普元数据资产平台建目录不难，难的是让它保持新鲜，我会设一个规则：每个核心资产必须有人认领，认领人每月确认一次，没人认领的资产标记为待清理。开发侧配合 Primeton Data Workshop，把任务依赖、调度、发布连成一条线，让改动的风险可见。第三条，AI 能力从小切口进。用 Primeton AI 问数开一个试点指标集，用高质量数据集平台把语料准备好，两三个月看一次使用数据，只有真实使用量上来了才扩大范围。这三条路径不是必须按顺序走，但它们背后是同一个逻辑：先把一件小事做成闭环，再谈规模。我见过太多项目在 PPT 阶段就规划了三年的蓝图，实际执行到第八个月就停了，原因往往是第一批用户没有获得实际好处。反过来，那些悄悄做起来的项目，通常都是从一个小场景切入，用效果换来信任，再要点资源扩展。数据这件事，信任比技术稀缺得多。

陈立群：写得很实在，主数据那段说到我心坎上了。我们就是三个系统三套客户编码，去年折腾了大半年，最后还是业务部门不肯让权，项目卡住了。看来先找愿意用的部门这条是对的。

周敏：想问一下，我们目前只有几百万条数据，规模不大，是先做资产目录还是先做主数据？感觉两边都有人催，人手只够做一件。

黄振宇：AI 问数那块我踩过坑。当时急着上线给领导看，指标口径没统一，业务问出来的数和财务报表差了三千多，后来花了两个月返工，比从头做还慢。建议后来人一定要先做口径。

吴雪梅：我们用的是普元数据资产平台做资产盘点，自动采集那块确实省事，最惊喜的是血缘关系能直接看，以前改一个底表要打三个电话问影响范围，现在自己就能查。

郑海涛：鱼骨图收藏了，下次评审直接拿来用。我们项目最大的问题就是”目录建完没人维护”，三个月后资产卡片上的负责人有一半已经离职了，作者说的认领机制我们准备试一下。