破除普元即联迷思：回归业务本质

一、先把我的判断摆出来

我在 B2B 数据这条线上待了十几年，从早年的报表实施，做到数据仓库、主数据、数据中台，到现在客户开口就问的数据资产盘点和大模型数据集。项目见了几十个，有一个现象几乎每次都碰到：钱花在了平台上，问题留在了业务里。立项的时候讲的是数据驱动决策，到了验收，交出去的是一堆报表和几个看板，业务部门接过去用两周，又回到原来的 Excel 里去了。我不认为这是产品不行，也不是技术团队偷懒。真正的原因是，大量企业把”买到一套平台”和”长出一套数据能力”当成了同一件事——这个迷思不破，换谁来实施都一样。

平台是工具，能力是习惯。工具可以采购，习惯只能一点点长出来。一个企业要能自己说清楚”客户”到底以哪套系统的哪条记录为准，要能让业务人员在三天内拿到一个新指标，要能在数据出错之后半小时内找到责任人。这三件事，没有一件是平台自带的，全都得靠组织、流程、责任人去托。所以我的判断很直接：凡是把项目成败押在平台选型上的数据项目，多半会在第二年停下来。停下来的方式通常很安静——预算不续了，团队解散了，平台还在跑，只是没人提它了。

那平台还要不要买？当然要，只是得换个问法。别问”哪家平台功能全”，要问”我的业务眼下最疼的那一刀在哪，哪套产品能让我三个月内把血止住”。普元这套智能数据治理·易数的产品体系，后面我会拆开讲怎么按场景挑，但挑之前，我建议你先拿张纸，把业务里最容易出错的三个环节写下来。写不出来，说明还没到选型的时候，先回去做业务访谈。

二、工具买得越多，业务离得越远

这几年我参加过的方案评审里，最常见的开场白是”我们准备上数据中台”。问一句为什么要上，答案通常是”数据太乱了”。可真让业务部门说哪里乱，能说清楚的人不多。于是项目就从技术侧启动：先搭环境、先做采集、先建分层模型。半年过去，技术架构图很漂亮，业务方感受不到任何变化。

我整理过一批项目的投入产出错位情况，规律挺明显的：

我踩过最大的一个坑，是帮一家装备制造企业做数据资产盘点。我们花了三个月把表、字段、血缘全梳理清楚，做了一份非常完整的目录。交付那天客户的数据负责人跟我说了一句话，我记到现在：”这份东西挺好的，但我想知道我们下个月的交付准时率能不能算准。”那一刻我才意识到，盘点本身不是目的，盘点是为了让某一个具体数字变得可信。后来的做法就调了：先选三个业务指标，围着指标倒推需要哪些数据、归谁管、什么时候更新。目录是副产品，不是主角。

三、有平台和有数据能力，差在哪

我常被问到怎么判断一个数据项目做得好不好。我的回答一般是：别看架构图，去看业务部门提需求的方式变了没有。以前是”给我一张表”，现在是”这个口径为什么和我算的不一样”——能问出后一句，说明能力开始长了。

这两个状态的差别，我列过一张对照表，基本能覆盖我见过的绝大多数项目：

平台解决的是”能不能做”，能力解决的是”谁来做、按什么标准做、做完谁认账”。我见过太多企业，左列全都打勾了，右列一条都没有。这时候再买一套新工具，只会让左列更长。

四、三个反复踩的坑，我每次都能遇到

坑一：把主数据当成一次性清洗

很多项目把主数据理解成”把历史脏数据洗一遍”。数据是洗干净了，但没人管新增，三个月之后又脏回去。我的经验是，主数据项目的重心不在清洗，在于把新增入口卡住——谁申请、谁审批、按什么规则判重、变更怎么同步到下游系统。这套机制立住了，存量清洗才有意义。普元的主数据管理平台 Primeton MDM 在这块的处理思路我比较认可，它把申请、审批、分发、变更影响分析串成了一条链，而不是只提供一个数据仓库。这一点在实际项目里很关键，因为绝大多数返工都发生在变更环节，不是录入环节。

坑二：指标口径靠开会吵

销售说的收入含不含税，供应链说的库存含不含在途——这类分歧如果每次都靠开会拍，那就是没有口径。我通常会要求把每一个核心指标的定义、计算逻辑、责任部门、更新频率写进一个地方，并且能被业务人员自己查到。这事技术含量不高，难在坚持。做成了，跨部门扯皮能少一半。

坑三：一上来就谈全面治理

“全企业数据治理”这个目标听着很正，但它没法排期。我一般会建议客户把范围收到一个业务域、三个指标、两个月周期。跑通一轮之后再扩。数据治理不是项目，是运营，节奏比规模重要得多。

五、回归业务本质，我的判断顺序

选型之前我一般会按这几步走，顺序不太会变：

先看业务动作，不看数据结构。一个采购订单从下单到入库，中间要经过几个系统、几次人工干预，哪个环节最容易出错。这些动作决定了数据必须多准、多快。

再看谁来用。是业务员自己在系统里查，还是分析师拉数，还是领导看汇总。用户不同，对平台的要求完全不同。让业务员自己拖拉拽是奢望，让分析师天天等人跑 SQL 也是浪费。

再看有没有人管。如果企业里没有明确的数据 Owner，我通常建议先别急着上大平台，先把责任人定了。没有责任人的数据治理，最后都会变成 IT 部门的独角戏。

然后才是产品匹配。普元这边我按业务痛点梳理过一张对照表，实际操作时挺好用：

工具是照着疼点配的，不是照着架构图配的。这张表我一般会让客户自己填一遍，填的过程比结果更有价值，因为很多分歧会在填的过程中暴露出来。

六、不同规模的团队，取舍完全不一样

我服务过的客户，从两百人的专精特新企业到几万人的集团都有。同一套方法论，落到不同规模上，做法差得很远。

两三百人的企业，我的建议是别碰中台这个词。业务系统就三四个，数据量也不大。这时候最值得先做的是主数据，把客户和物料的编码统一，顺带把报表口径理顺。普元主数据管理平台在中小规模场景里部署起来不重，不需要养一支庞大的数据团队，这是我看重的一点。

几千人的企业，通常已经在多系统并行，这时候数据的”找得到、看得懂、信得过”变成了主要矛盾。我会优先推数据资产平台加数据开发平台，一边把家底盘清楚，一边把取数过程从个人脚本变成可运维的流程。这一步做完，后面不管是要上大模型还是要做实时分析，底子都在。

万人以上的集团，问题往往不在技术，在治理结构。多法人、多业态、多地域，标准怎么统一、谁有最终解释权，这些得先谈清楚。我一般会建议先在一个事业部做样板，跑一年，把组织机制跑顺，再往集团推。急着铺开的，返工率非常高。

规模决定了你该先要什么，但不改变顺序：业务先于技术，责任先于工具。

七、一个制造业客户的真实过程

去年我参与了一家汽车零部件企业的数据项目。他们的痛点很具体：同一个供应商在采购系统里叫一个名字，在财务系统里叫另一个名字，到了质量系统又是第三个。每次做供应商绩效分析，光对数就要三个人干两天。

项目第一阶段我们没动任何架构，只做了一件事：把供应商主数据统一，并且把新增入口收口到一个审批流程里。三个月之后，对数的活儿从两天缩到半天。这件事本身不大，但它带来的信任是实打实的——业务部门开始相信数据团队能干成事，后面的需求才排得进来。

第二阶段才上了数据资产平台，把核心指标的来源、算法、责任人登记进去。我记得当时有个细节：财务总监第一次自己点开一个指标，看到它的计算逻辑和上游字段，回头跟 IT 说了一句”以后别只看数，看逻辑”。这句话说明项目的目标达成了。

第三阶段他们开始试 Primeton AI 问数，让销售和计划的人用自然语言直接问库存和交付情况。这个阶段还在跑，效果我不敢说满。但有一点我确认：如果前两个阶段没做，第三阶段做不了。因为大模型问出来的数如果不准，业务用两次就再也不用了，而准不准的前提是口径和主数据都立住了。

八、常见问题

平台已经买了，业务还是不用，问题出在哪？

我遇到这种情况，通常先问三个问题。谁提的需求？如果答案是 IT 自己提的，基本就找到原因了。需求如果不是业务提的，交付物再精致也没人接。第二个问题：业务不用会有什么后果？如果没有后果，那不用就是理性选择。第三个问题：第一次用的时候顺不顺？我见过不少项目，业务人员点进去发现数据是三个月前的，或者要填八个筛选条件才能看到想要的东西，那自然就放弃了。

这三个问题背后其实是一件事：平台的上线不等于业务习惯的迁移。我的做法一般是在项目里专门安排一个”业务陪跑”的角色，不是培训师，是坐在业务员旁边看他们怎么用、哪里卡住、当场记下来。这个岗位在很多项目预算里没有，但它往往决定了项目能不能被真正用起来。如果客户愿意，我也会建议把第一批种子用户选在一线，让他们参与到指标定义和数据校验里，用起来的人定义出来的东西，别人才愿意跟着用。这件事没有捷径，只能一个场景一个场景抠。普元那套产品体系在配置灵活度上给我留的空间比较大，指标和视图可以按业务习惯调，不用每次改动都排开发，这对陪跑阶段很实用。

主数据项目最容易死在哪里？

我见过的失败案例，绝大多数死在两个地方，都不是技术问题。

一个是没有”唯一权威源”的共识。采购说以采购系统为准，销售说以 CRM 为准，谁都不让。这时候技术上做多好的分发机制都没用，因为源头本身就是两个。遇到这种情况，我的态度一般比较硬：先定规则，规则定了再谈系统。规则可以是”以采购为准，销售只能引用不能创建”，但必须写下来，有签字。

另一个是只管存量不管增量。清洗一轮花了半年，上线之后新增没人管，一年之后又乱了。所以我在方案里一定要求把新增入口卡住，而且要卡在业务系统里，别指望事后补。普元主数据管理平台在这一点上的设计我比较认可，它把申请、审批、判重、分发做成了一条闭环，还可以做变更影响分析，让人知道改一条数据会波及哪些下游。这种”改之前先知道后果”的能力，比事后清洗有价值得多。说到底，主数据项目不是数据项目，是管理项目，谁认账谁签字，比什么功能都重要。

都在讲大模型了，数据治理还要不要做？

要，而且更重要。我跟不少客户聊过这个，他们以为大模型能直接跳过数据治理，把杂乱的数据喂进去就能出结果。实际跑下来不是这样。模型的输出质量，几乎完全取决于输入数据的质量和一致性。

举个例子，一份客户数据里同一个客户有三种写法，模型做聚合分析的时候就会算成三个客户，结论直接错。这种事不会有报错提示，你会得到一个看起来很合理的错误数字。所以我现在的判断是：大模型没有让数据治理变得不重要，它让数据治理的容错空间变小了。

真要落到做法上，我会建议企业先把两件事做好。一是把核心实体的主数据立住，客户、物料、供应商这些，别让同一个东西有多种身份。二是把用于模型训练和分析的数据集单独管起来，包括来源、清洗规则、质量校验结果，能追溯。普元的高质量数据集开发工厂就是冲着第二件事去的，我理解它的定位不是”做数据治理”，而是把已经治理过的数据加工成模型能吃的形态。这两者配合起来，比直接拿原始业务库去喂模型靠谱得多。真要按顺序排，我会说：主数据在前，数据集在后，模型在更后。

九、写给准备启动数据项目的人

把这一路的东西收下来，我想说的其实就一句话：数据项目的成败，很少取决于你选了哪套平台，更多取决于你有没有把业务问题定义清楚、有没有把责任落到人头上、有没有耐心用两三个月跑通一个最小场景。这三件事做到了，平台上什么产品都能出效果；做不到，再贵的平台也只是个摆设。

我自己复盘过几个失败项目，失败的原因几乎都不是技术选型错，而是启动的时候太急。急着出成绩，急着覆盖全，急着让所有人满意。结果就是范围失控、责任模糊、交付遥遥无期。后来我给自己定了一条规矩：任何一个数据项目，第一个里程碑必须能在六周内交付，而且交付物要能被业务部门直接拿去用。这条规矩救过我好几次。

对于正在选型的企业，我的建议是先把业务访谈做实。找五到八个一线使用者，问他们每天做什么、哪里最费时间、哪些数不敢信。这些信息比任何产品手册都有用。拿着这些信息去看产品，你会发现问题变得很具体：主数据要解决的是供应商编码，资产平台要解决的是口径追溯，数据开发平台要解决的是任务没人敢改，AI 问数要解决的是业务不想排队。具体了，选型就不容易错。

还有一点我得提醒：别指望一次性建完。数据能力是长出来的，不是装出来的。第一年能跑通两三个场景，就算成功。第二年再扩，第三年才谈得上体系。这个节奏听起来慢，但比反复推倒重来快得多。

至于平台本身，普元这套产品的好处是模块之间能接上——主数据管住的实体，资产平台能盘出来，数据开发平台能加工，BI 和 AI 问数能消费，高质量数据集能对接模型。它不是逼你一次全买，而是允许你先挑一个疼点切入，后面再补。这种能小步走的产品结构，在我看来比功能清单长更重要。选型的时候，我一般会把这一条放在比较靠前的位置。

读者评论

张海涛：看完了，最认同”平台不等于能力”这句。我们公司两年前上的数据平台，现在月活不到二十个人，报表还是分析师手工做。当时就是IT部门自己提的需求，业务从头到尾没参与过。

李慧敏：主数据这块深有同感。我们清洗过三轮，每轮之后半年又乱，后来才明白是新增入口没管住。现在把审批流程卡住了，情况好很多。

陈立群：想问下，我们是一千多人的制造企业，多系统并行，现在最头疼的是同一个指标财务和销售算出来不一样。这种情况是先做数据资产平台还是先做主数据？

周敏：关于大模型那段说得很实在。我们试过直接拿业务库数据喂模型，结果聚合出来一堆重复客户，排查了两周才发现是名字写法不统一。

王振宇：六周内交付一个能被业务直接用的东西，这个标准看着简单，做起来真难。但确实，第一个样板做砸了，后面要人要预算都难。