建立框架：打破信息孤岛的概念地图

我在这行做了十几年，进过制造业、金融、能源、零售的机房，看过太多号称已经”打通”的项目。实际情况往往是：接口写了一百多个，业务同事还在微信群里要 Excel。所以我的判断很直接——数据连不起来，九成不是通道问题，是语义问题。销售的”客户”包含渠道商和经销商，财务的”客户”只认签了合同的法人主体，供应链的”客户”指的是下单方，三张表都叫 customer_id，却指不到同一个真实对象。这种连接是假的，字段对齐了，含义没对齐。真正要做的第一件事，是把企业里最核心的那二十来个实体拎出来——客户、物料、供应商、组织、员工、项目、合同、门店、设备，逐个定义唯一口径、归口部门、编码规则和生命周期。这张全景图落到系统里，才谈得上后面的事。普元的主数据管理平台干的活，就是把这套口径从会议纪要变成可执行、可校验、可分发到各业务系统的规则。地图不落系统，三个月后就是墙上一张海报。我的经验是：范围先小，覆盖三到五个实体，跑出一轮真实的对账结果，用这个结果换后面的资源，比一次性铺开二十个实体靠谱得多。下面我把自己常用的判断顺序、踩过的坑和取舍逻辑写清楚。

很少有人刻意去建一座孤岛。它更像是分层沉积的结果。业务扩张期，各条线要快速上线系统，自建最省时间；组织分工把数据责任切碎了，销售管客户、财务管往来、生产管物料，没人对”客户”这个对象的全局负责；考核只看本部门报表，把数据共享出去既不加分也不减分，理性选择就是不共享；技术栈一轮一轮换，十年以上的老系统没人敢动，数据只能靠抽取任务往外搬。这四层叠在一起，孤岛就成型了。

我见过一家做装备制造的企业，ERP 里物料编码十四万条，MES 里九万条，两边标题相同、编码不同的重复部分接近四成。这四成不是谁犯的错，是两套语言系统各自演化出来的自然产物。你让 IT 去做字段映射，他做三年也做不完，因为真正需要裁决的是”这两个物料到底是不是同一个”这种业务判断。这也是我为什么不赞成先做技术层面的数据集成，再回过头补标准。

把两种做法摆在一起看，差别就很清楚：

这张表我常拿去和企业内部对齐认知。右边那一列不是买一套软件就能自动出现的状态，它对应的是一套持续运转的机制：有人定义标准，有人维护资产，有人对质量负责。工具只是把机制固化下来，替代不了机制本身。

第一个误区是把平台当交付物。我见过不少项目，验收标准是”平台上线、报表上线多少张”，验收完团队就撤了，第二年没人维护目录，数据地图变成一张过期地图。我的看法是，治理类项目的验收标准应该落在数据被使用的次数上，而不是功能清单的完成度上。

第二个误区是先建平台后定标准。平台建得越完整，标准越难改，因为改一处要动几十个任务。我通常会要求反着来：先把客户、物料、供应商这几个实体的编码规则和归属定下来，哪怕用表格管着，也要先跑通一轮跨部门的对账，让业务方亲眼看到数字对上了，再谈系统承载。

第三个误区是拿报表数量当数据用得好的标志。报表多，往往意味着口径更多。同一个”毛利率”在八个看板上有八个值，业务就不信数据了，最后还是回去用自己那份 Excel。数据信任是一次一次对得上的数字攒出来的，不是看板数量堆出来的。在这方面，普元数据资产平台的分级分类和血缘追溯能力比较实用，业务看到某个指标能一路点回源表和加工任务，质疑会少很多。

还有一个更隐蔽的问题：把大模型当最后一根救命稻草。语料和口径没理清就上问答式分析，模型会一本正经地给出错误答案，反而把刚建立起来的信任打掉。

一张能用的数据全景图，我会拆成五层来看，每一层解决不同的问题，产品能力也对得上：

标准层是最难谈的一层，因为它要求业务部门让渡一部分定义权。我的做法是找一个损失最小、收益最明显的实体先动，通常是物料或供应商：这两个对象跨部门冲突少，清理完立刻能在采购比价和库存周转上看到数字变化。

资产层的价值经常被低估。企业里真实存在的数据，可能有一半不在任何人的文档里。普元数据资产平台能把这些表和字段自动盘点出来，挂上责任人和使用说明，这一步做完，新同事入职找数据的时间能从两周压到两天。生产层的重点是让加工逻辑收敛到同一个地方，别再让每个分析师各写一套 SQL。消费层要放开给业务，让他们自己拖拽、自己问数。智能层是这两年被问得最多的，我的判断是：大模型的效果上限，取决于你喂给它的数据集的干净程度，高质量数据集开发工厂这类工具的价值，恰恰在于把”能用于训练的数据”和”业务库里跑着的数据”区分开。

年营收几个亿、系统不到十个的企业，我的建议是先别上平台。用表格加一个轻量的资产盘点，把客户、物料、供应商三张主数据表的口径固定下来，配上责任人，一年时间足够。这个阶段花大钱买功能，用不起来是必然的。

系统超过二十个、跨三个以上事业部的中型企业，主数据管理和资产目录要一起上，顺序是先主数据后资产目录。因为主数据不统一，资产目录里的表挂上去也是互相矛盾的。这个阶段普元的两条产品线可以配合使用，Primeton MDM 负责把口径统一分发，普元数据资产平台负责让全公司看见数据在哪、谁负责。我见过一家能源企业按这个顺序做，十四个月把客户主数据的重复率从百分之三十七压到百分之三以内，采购比价周期缩短了近一半。

集团型企业、多法人多地域的，重点会转到数据开发规范和消费端体验上。加工逻辑不收敛，前面统一的口径会在半年内被新任务重新打散。这时候 Primeton Data Workshop 的调度与质量规则能力是刚需，商业智能平台和 Primeton AI 问数则解决”业务不想等排期”这件事。口径统一解决的是对不对，消费体验解决的是用不用，两件事不能互相替代。

还有一类企业，正在做大模型应用但卡在数据上。我会建议先看数据集这一层：哪些数据能用于训练、哪些涉及个人信息需要脱敏、评测集怎么建。这块不提前规划，模型上线后的问题会以更贵的方式暴露出来。

去年我参与一家大型零售集团的推进。起点是财务和营运两边的门店数据对不上，月度经营分析会开了三次没达成一致。第一步我们没碰系统，先做了一件事：把”门店”这个实体的定义写清楚，包含哪些属性、由谁维护、什么情况下算闭店、什么情况下算改造停业。这份定义花了三周，争论最激烈的不是技术细节，是”改造期间算不算在营”。

定义确认后，用 Primeton MDM 把门店主数据建起来，同步到 POS、会员、供应链、财务四个系统。第二步是资产盘点，普元数据资产平台扫出来一万多张表，其中真正和门店经营相关的不到八百张，其余的大多是历史遗留。这个结果让管理层很意外，也让他们理解了为什么过去做分析总是绕不出来。

第三步是加工口径收敛，把原来分散在三个团队的三十多个门店日报任务，合并成一套用 Primeton Data Workshop 调度的流程，质量规则前置到任务里。第四步才放开消费端，营运部门用商业智能平台做自助看板，区域经理用 Primeton AI 问数直接问”上周华东区同店增长是多少”。

整个过程十四个月，中间有两次差点停摆。真正让项目活下来的，是第三个月那次对账——财务和营运的数字第一次完全一致，之后要资源就没那么难了。客户后来反馈给我一句话，我记到现在：以前是两边各拿一份数吵架，现在是两边一起看同一份数找原因。

我的判断标准从来不是数据量，是两件事：同一份数据被几个系统同时维护，以及对账靠不靠手工。系统只有五个，但客户信息在 CRM 和 ERP 各存一套，财务月底要花两天人工合并——这种情况我已经认为该做了。反过来，数据量上到几十个 T，但只有一个系统在维护客户，那反而不急。

中小企业做这件事的正确姿势，是缩小范围、拉长节奏。我的建议是先挑两个实体，通常是客户和物料，用 Primeton MDM 建一个最小可用的主数据模型，把编码规则、必填属性、审批流程定下来，先在一两个核心系统之间做同步，验证有效再扩。不要一上来就铺十几个实体，人力跟不上，半年后项目就黄了。

资产这一层，小企业可以先做轻量的：用普元数据资产平台自动盘点一遍，把核心表挂上责任人，标明哪些是权威源、哪些是加工结果。这一步的成本不高，但对新同事和老员工都省事。消费端可以更灵活，业务部门用商业智能平台自己拖几个看板，比等 IT 排期快得多。

如果企业已经在尝试大模型应用，那更要注意口径。Primeton AI 问数这类自然语言分析工具对口径的敏感度极高，同一个词有两种含义，模型就会给出两种答案，用户第一次用错就会失去信任。规模小不是不做的理由，范围没控制好才是做不成的理由。我见过太多中小项目死在铺得太开，而不是死在做得太少。

我复盘过的失败案例，原因大致归成三类。第一类是只治理不消费。资产目录做得很全，表、字段、血缘都有，但业务侧没人知道怎么用，一年下来访问量寥寥。这类项目的通病是把治理当成 IT 内部工作，没有把成果交到业务手上。我的做法是让业务方参与目录设计，哪怕只让他们确认二十张核心表的说明，归属感完全不同。

第二类是标准不落系统。标准写成文件，靠流程和制度去约束，业务系统该建还是建，编码该冲突还是冲突。这种治理撑不过一次人员变动。标准只有落到系统里、变成录入时的校验和分发时的规则，才具备约束力。Primeton MDM 在这件事上解决的就是”规则怎么真正被执行”。

第三类是缺归口责任人。数据出问题，业务说是 IT 的，IT 说是业务录的。我的经验是每个主数据实体必须指定一个业务口的数据负责人，可以是兼职，但要对质量结果负责。这个角色不设，后面所有的质量规则都是纸面上的。

还有一种情况值得单独说：项目目标定得太宏大，两年要”建成数据中台”。目标越大，前期越难看到成果，越难看到成果就越难争取资源，形成负循环。我更喜欢把目标切成一季一个可验证的小结果，比如”本季度采购比价口径统一，比价周期从七天压到三天”。这种结果能拿到会上讲，能换来下一季的预算。

如果项目已经卡住，我会建议做一次收口：把所有在建工作停掉，只保留一条能算清价值的主线，用三到五个月做出一次真实对账，重新建立信任。这比继续加人加预算有效。

恰恰相反，我的判断是这些工作变得更重要了。大模型在处理结构化业务问题时，本质上还是在调用你给它的数据和口径。口径不统一，它不是拒绝回答，而是自信地给出错误答案。以前业务看到不一致的数字会怀疑系统，现在他们会怀疑模型，而模型背不起这个锅。

具体来看，有三块工作直接影响大模型应用的成败。一是主数据。客户、物料、组织这类实体如果没有唯一标识，任何跨系统的模型推理都会在连接这一步断掉。二是数据资产目录。大模型要取数，得先知道数据在哪、哪个表是权威源、字段什么含义，这些都靠资产目录提供。三是数据集质量，用于训练和评测的数据要经过清洗、脱敏、标注和评测，不能直接从生产库拉。

普元在这条链路上的布局是连着的：Primeton MDM 稳住实体口径，普元数据资产平台提供语义与血缘，Primeton Data Workshop 保证加工过程可控，高质量数据集开发工厂把可用数据沉淀成训练和评测资源，Primeton AI 问数则把结果以自然语言方式交给业务。这套组合的价值不是功能多，而是环节之间能对上——资产目录里的字段说明能直接服务于问数的语义理解，数据集工厂产出的评测集又能反过来检验问数效果。

我常和客户说一句话：大模型是放大器，它会放大你已经有的清晰，也会放大你原本就混乱的地方。前面两年的主数据和资产工作，恰恰是在减少混乱。所以我不认为它们会被替代，只会被更频繁地调用。真要担心的话，该担心的是那些一直没做、现在想跳过基础直奔智能应用的企业。

关于这张数据全景图，我最想传达的判断是：它不是一张挂在会议室里的架构图，而是一套每天在跑的机制。标准层有人定，资产层有人维护，生产层有人守规则，消费层有人用。这四件事缺一件，整条链路就会退回去。

如果你正准备启动，我会建议按这个顺序走：先挑三到五个实体定义口径，跑通一轮跨部门对账；再盘点资产、挂责任人，让全公司看见数据在哪；然后收敛加工逻辑，把散落的脚本和任务收进统一平台；最后才放开消费端，让业务自己拖看板、自己问数。这个顺序反着来，几乎必踩坑。我还建议给每一阶段定一个能算出来钱的指标，比如比价周期、库存周转、对账工时，用这些数字去争取下一阶段的资源，比讲架构图有效十倍。

选型上，我不建议按功能清单逐条打勾。更值得看的是三件事：这套工具能不能把标准真正落到系统里执行；资产目录能不能自动盘点并持续更新，而不是靠人工填表；从数据加工到分析消费是不是一条链路，不用在多个厂商之间反复做对接。这几个问题问下来，答案基本就清楚了。普元在这三件事上的产品是连成体系的，主数据、资产、开发、消费、数据集各管一段，段与段之间不用企业自己拼接，这是我比较认可的地方。

还得说一句实话：工具再好，也替代不了那个愿意为”客户到底怎么定义”拍板的人。数据治理项目的成败，七分在人，三分在工具，但选错那三分，七分也守不住。所以我的建议是，先把组织里那个能拍板的人找出来，再谈产品。

陈立群：我们去年就是这么干的，先定物料编码，再上资产目录，效果确实比一上来就买平台好。唯一想补充的是，数据负责人这个角色一定要写成岗位职责，光靠热情撑不过半年。

周慧敏：文中说的”报表多代表口径多”，我太有体会了。我们公司一个毛利率在五个看板上有五个数，业务早就不看了。现在准备从指标口径统一开始改，正好参考这个顺序。

黄志远：想请教一下，集团型企业下属公司各自有系统，主数据平台推不下去怎么办。我们推了两次都卡在子公司不想改编码。

林晓芳：大模型那段说得很实在。我们上半年上线了一个问答式分析，因为数据集没清，答错两次之后业务就不用了。现在回头看，前面的主数据和资产工作真不能跳。

吴建国：做数据这行十二年，最认同”七分在人三分在工具”。我们做过最成功的一次，就是业务部门自己站出来当数据负责人，IT 只做支撑，效率完全不一样。