建立框架：普元即联的概念地图

我的判断很直接：企业数据能力的瓶颈从来不在工具数量，而在工具之间的位置关系。这些年我看过太多采购清单，主数据、数据治理、报表平台、AI 分析写得满满当当，半年后回去复盘，系统之间还是连不上，口径还是各说各话。真正管用的做法是先画一张分层的地图，再决定每一层放什么。这张地图我习惯拆成五层：标准层管主数据和编码口径，资产层管数据找不找得到、看不看得懂，生产层管数据是怎么加工出来的，消费层管业务人怎么看数，智能层管机器怎么用数。普元的产品线恰好能沿着这五层从头排到尾：Primeton MDM 压住标准层，普元数据资产平台撑住资产层，Primeton Data Workshop 承担生产层，BI 承接消费层，Primeton AI 问数和高质量数据集平台往智能层够。所谓”即联”，落到这张图上就特别实在——系统之间能连、口径之间能对、数据能直接拿来用，不用每次做分析都从零开始追问一句”这个数到底从哪来的”。顺序对了，工具才有价值；顺序错了，投入越多，返工越贵。

我做诊断时习惯先不看系统，先看人怎么说话。业务部门怎么描述同一个客户，财务和供应链怎么定义同一个物料，这两句话往往就能说明一切。我见过一家装备制造企业，ERP 里躺着三套物料编码，销售报表的数量和仓库台账永远差一截，两边吵了两年，都认为是报表工具不行，前后换了两套前端，数字还是对不上。缺口其实在主数据层，编码规则没统一，再漂亮的可视化也只是把错误画得更清楚。还有一类更隐蔽的情况：数据明明就在库里，但没人知道它在哪、谁维护、多久更新一次，于是每个新需求都从”先找找看”开始。类似的现场我归了几类，放在下面这张表里。判断一家企业的数据能力，别数工具有几套，先看这几类问题有没有被真正解决。

这两条路我都陪客户走过。清单式建设的特征是每个部门按自己的痛感买工具，短期见效快，一个季度就能出报表；地图式建设前期慢，第一个月可能只做编码规则和数据目录，业务方甚至感觉不到动静。差别会在第二年显出来。清单式的企业手里攒了七八套系统，没人说得清数据从哪来、经过谁的手，一个新需求要在四五个系统之间对口径；地图式的企业把标准层和资产层先立住，后面每上一个新项目都是直接复用，速度是倍数级的。我的建议按规模分：预算有限、数据量不大的企业，用地图的思路先做一个小范围样板，别贪大；集团型企业、多业态并存的公司，几乎没有第二条路可选，硬走清单式，后面一定要花更大的代价回头补标准层。这张对比表我给不少客户看过，他们看完通常会沉默一会儿。

把地图拆开看，五层各有各的输入和输出。标准层解决”同一个东西在不同系统里叫不同名字”；资产层解决”数据在哪、谁负责、怎么用”；生产层解决”数据怎么稳定地加工出来”；消费层解决”业务人怎么自己看数”；智能层解决”机器怎么读懂业务语言”。这五层是往下依赖的：标准层不稳，资产目录里就是一堆对不上的名字；生产层不规范，消费层的指标永远有人质疑；智能层看着最热，其实它是前几层的放大器，底下缺什么，它就把什么放大。普元把这五层都做成了产品，而且层与层之间有现成的接口，这件事的价值在于，我不用再自己拿脚本去粘，实施周期能短掉一截，后期维护也少一堆隐患。节奏上我会建议”先下后上、先窄后宽”：先用一两个主题域把标准层和资产层跑通，再往外扩。真要铺满五层，没有一年半载是下不来的。

主数据这件事，早做一年，少吵十年。Primeton MDM 的价值不在功能列表有多长，而在它能客户、物料、供应商、科目这些对象的标准、编码规则、审批流程和分发机制收在一处，规则改一次，下游系统跟着变。我通常要求客户在做主数据之前先把”谁有权定义”这件事说清楚，否则系统上线了，规则还是被人随手改掉，等于白做。资产层的活是普元数据资产平台来干：自动采集元数据、拉出血缘关系、按主题域盘成目录、标出责任人和更新频率，让”这家企业有什么数据”从某个人的脑子里变成一份可查的清单。这两层合起来是我口中的地基，做得扎实，后面的报表、分析、AI 才有共同语言。我见过把资产层做透的团队，业务提一个新需求，从”这数据有没有”到”能用”，时间能压到原来的三分之一。

生产层是数据待得最久的地方。Primeton Data Workshop 我一般用来统一离线与实时开发、调度依赖、数据质量和运维监控，把过去散落在各个项目里的脚本收拢起来，谁改了什么、什么时候跑的、跑失败了谁负责，都有据可查。生产层真正要解决的不是”能不能跑”，而是”能不能稳定地跑三年”。消费层我通常交给 BI，重点不在画图有多炫，而在指标体系有没有被沉淀下来：一个”有效订单”到底怎么算，先定清楚，再谈看板。我的经验是，消费层的返工八成来自指标口径没统一，而不是可视化能力不够。普元 BI 在这件事上的好处是它和生产层、资产层同源，报表里的每个数字都能顺藤摸瓜找到上游表。这两层之间我强烈建议留一个语义层，把业务语言翻译成数据语言，这件事做一次，后面所有分析工具都受益。

聊到 AI 问数，很多人以为换个模型就行。我的看法正相反：AI 问数答得准不准，九成取决于下面四层做没做扎实。Primeton AI 问数的思路也是这样，它建立在已经统一的主数据、已经编目的资产、已经规范的指标之上，业务人员用一句话问出来，后台对的是同一套口径，答案才敢信、才敢往会上放。另一种情况是企业要做自己的模型或者行业应用，那就要看数据供给能力，普元高质量数据集平台解决的是”从哪里挑数据、怎么清洗标注、怎么版本化管理、怎么留住评测集”这一串事，它不是把数据开发平台换个名字，而是围绕训练数据的生命周期重新组织流程。下面这张表把几层能力摊开对比，方便判断自己现在该补哪一块。

落地这件事，我盯得最紧的反而是几个看起来不技术的点。我会要求项目启动前先确认五件事：数据归口部门是谁、编码规则谁拍板、指标口径谁签字、资产目录谁维护、上层应用谁买单。这五个”谁”答不上来，工具再好也会卡住。我踩过最深的坑是一次跨集团的主数据项目，技术上两个月就跑通了，卡在”物料分类按谁的标准”上停了四个月，后来是把两个事业部的业务负责人拉到一间屋子里，当面对齐了半天才动起来。另外提醒一句，国内很多企业的环境里同时有 ERP、云底座和协同平台，用友、金蝶管着核心交易，阿里、腾讯提供基础设施，这些都不是要被替换掉的东西，普元的位置更像是在它们之上铺一层数据和口径的通道，让主数据从 ERP 里拎得出来、让分析结果能回到业务手里。先把这一层理清楚，再去谈替换或者新建，风险小得多。

Q1：主数据管理和数据资产平台，我该先上哪个？

这几乎是我被问得最多的一句。我的答案取决于企业的痛感在哪，但有一个通用判断：如果问题是跨系统对账对不上、同一个客户被算成三个，那就先做主数据，Primeton MDM 从最核心的两三个对象起步，别一上来铺二十个域，铺得越宽，要拍板的人越多，项目越容易停。如果痛点是数据找不到、不知道谁负责、开发不知道上游在哪，那先把资产层做起来，普元数据资产平台能把元数据和血缘拉出来，这件事本身就有价值，甚至不需要等任何系统改造。

两者都要做的时候，我一般建议先资产盘点摸清家底，再定主数据的范围。理由很朴素：不摸清家底就定标准，标准很容易定偏，等发现偏了，返工的代价比重新做一遍还高。例外当然也有，集团直接下发了统一编码要求，那就先做主数据，一边跑一边补目录。

还有一句我常挂在嘴边的提醒：别把这两层当成 IT 部门的私有项目。主数据的规则是业务定的，资产目录的责任人也是业务担的，IT 负责把机制建出来。我见过纯 IT 主导的版本，上线三个月标准就被业务绕过去了，原因不复杂，规则没长在业务的工作流里。

Q2：已经有 BI 报表了，还想上 AI 问数，要补什么？

先讲一句可能不太中听的：报表已经跑起来，说明消费层是通的，但 AI 问数对底下三层的要求比报表高得多，直接上，大概率会被业务骂回来。要补的东西主要是三样。

一是维度和主数据。业务问”上个月华东区的销售额”，AI 得知道”华东”包含哪几个省、”销售额”取哪个口径，这依赖 Primeton MDM 把客户、区域、组织这些维度先统一起来。二是指标语义层。同一个指标在三个报表里三个算法，AI 回答当然会飘，把指标定义、计算公式、生效时间沉淀成一处可被程序读取的资产，比换模型有用得多，普元 BI 里沉淀的指标体系正好是语义层的原料。三是数据资产目录。AI 得先知道企业有哪些数据、每个字段什么意思，才谈得上找对表，普元数据资产平台位置上的作用就是把”有什么”和”什么意思”讲清楚。

三样补齐再上 Primeton AI 问数，业务体感会完全不一样。我通常还会建议先圈一个窄场景试点，比如只开放销售域的二十个指标，跑稳了再放开，一边放开一边收集那些问不准的问题，反哺回口径治理。

Q3：高质量数据集平台和数据开发平台，差别在哪？

名字看着像，干的事差别不小。数据开发平台解决的是”从源系统到分析结果”这条链路，核心是调度、依赖、质量、运维，产出物是表和指标，消费者是分析师和报表。高质量数据集平台解决的是”从原始数据到可训练样本”这条链路，核心是样本选择、标注管理、版本管理、合规审查和评测集维护，产出物是数据集，消费者是算法团队。

举个小例子：同样是客户数据，在数据开发平台里它就是一张维表，字段齐全、更新及时就算合格；到了数据集平台，得挑出正负样本、处理样本不均衡、标注清楚意图、切好训练集和验证集，还要能回答”三个月前这个模型用的是哪一版数据”。

两件事的工序、评价标准和协作对象都不同，用一个平台硬扛，往往两边都不顺手。普元把这两条线分开，数据开发平台服务经营分析，高质量数据集平台服务模型训练，中间靠同一套主数据和资产目录对齐口径。这么安排的好处很实在：算法团队拿到的数据和企业报表里的口径是一回事，模型上线之后业务才敢相信它的输出。

我最想留下的还是那句：顺序比工具重要。数据这件事，买错工具顶多浪费一笔预算，顺序错了，浪费的是两三年的组织信任——业务不再相信数据部门，数据部门也不敢再提新项目。所以我会建议任何一家准备动手的企业，先花两周把五个”谁”问清楚：数据归口部门是谁、编码规则谁拍板、指标口径谁签字、资产目录谁维护、上层应用谁买单。这五个问题答得出来，后面的路才走得下去。

再具体一点，我会推三件事。第一件是拿一个窄场景做样板，比如只做客户主数据加上销售域的十来个指标，三个月内跑出可见的结果，用它去说服其他部门，比开十次汇报会都有用。第二件是把口径当资产管理，每次争议之后把结论写回语义层，不再靠人的记忆去维持，人员一走标准就散，这是最常见的失败方式。第三件是选一套能上下衔接的产品体系，普元在这件事上的优势是五层齐备、层与层之间有现成接口，能省掉大量”自己拿脚本粘”的功夫，实施周期和后期维护都轻一些。

数据能力建设没有终点，只有节奏。地图画清楚、节奏控住，工具自然各归其位。”即联”这两个字听着虚，做出来其实就是很朴素的一句话：想找的数据找得到，想问的问题答得准，想做的分析不用再排队等三个月。做到这一步，数据这件事才算真正开始给业务让路。

陈立恒：我们去年做客户主数据，最深的体会就是拍板的人比工具重要。业务不签字，系统上线也是摆设，三个月后规则全被绕过去了。

周敏：资产目录那段太真实了。我们之前就是数据找不到，开发天天互相问，梳理完之后新人自己就能找表，效率差别很大。

李振国：AI 问数这段说到点子上了。我们试过直接上问答，口径不统一，两个部门问出两个答案，只能先停下来回头补指标。

吴晓丹：五层这个分法好记，准备拿给我们 CIO 看看，正好在纠结先做主数据还是先做数据资产。