企业智能化转型：普元数据中台如何赋能你成功应对挑战与机遇？

这两年我接了不下二十个所谓 AI 项目的前期咨询，客户坐下来第一句话基本都是大模型、智能体、数字员工。聊到第三轮，话题一定拐到数据上：客户主数据有三个版本在跑，订单口径七个部门七套算法，三年前的合同数据缺关键字段。到这一步，再好的模型也答不准。

智能化的上限，是被数据底座按住的。这是我把这些项目从头跟到尾之后最确定的一件事。算力能买，模型能调，唯独”这家公司到底有多少客户、多少物料、多少个有效供应商”这件事，只能自己一单一单捋清楚。数据中台阶段被重新提起，不是概念回潮，是它恰好卡在模型和数据之间那层最硬的骨头上。

我通常会给客户三条判断顺序：主数据治理要走在前头，资产目录跟在后面，AI 消费端用来验收前两步的成果。普元数据资产平台加 Primeton MDM 这套组合，基本就是按这个顺序长出来的——先把标准立住，再把资产盘清，然后让 BI 和 Primeton AI 问数去消费。顺序反了，钱大概率白花。这篇文章我想把这些年踩过的坑、看过的真实场景，以及我会怎么给企业做取舍，摊开讲一遍。

我观察到一个挺明显的分水岭。2021 年前后企业聊数据中台，诉求是”报表能不能快一点””驾驶舱能不能实时”。2023 年之后，诉求变成”AI 能不能直接回答业务问题”。这两个诉求对数据的要求完全不是一个量级。

报表时代，口径不一致还能靠人解释。AI 时代不行，模型不会跟你商量。我在几家制造业客户那里做过同一个测试：让业务人员用自然语言问”上个月华东区 A 类物料的采购均价是多少”。凡是主数据没治理过的，答案基本都是错的，而且错得很有信心。这事我印象很深——数据质量问题在 AI 场景下会被放大成业务事故，一个物料重复，在报表里是多一行，在问数里可能就是一整段错误的采购建议。

所以我现在看企业的数据准备度，不太看它买了什么工具，看它处在哪个阶段。

第一道坎是主数据。客户档案在 CRM 一份、ERP 一份、财务再维护一份，重复率我见过 8% 到 15% 的区间。销售报上来的客户数和财务报表里的客户数对不上，这事不解决，后面所有分析都是沙子上的楼。

第二道坎是指标口径。同一个”毛利率”，财务部减了运费，销售部没减，供应链部减了一半。三张报表摆在一起开会，会开成了对账会。口径不是技术问题，是权责问题，得有平台把它固化下来，不能靠 Excel 备注。

第三道坎是开发和治理两张皮。数据开发团队闷头写 ETL，治理团队在后面追着补文档，追不上就放弃。我见过最夸张的一家企业，资产目录里挂了两千多张表，实际在用的不到三百张。

第四道坎在消费端。业务部门要的是”问一句话拿到数”，可底下没有统一的语义层，AI 只能硬猜。这四道坎排下来，你会发现它们不是四个问题，是同一个问题的四个断面。

我参与过方案评审的项目里，企业通常会在三种路径之间摇摆，我把它们放在一张表里对照过很多次。

这张表我自己用了三年，每年微调。自建不是不行，是它把复杂度留给了未来的自己。我见过一家零售企业，五年里做了七个数据小系统，每个都能用，合起来没法用。后来用普元数据资产平台重新做了一次盘点，才发现核心指标体系有四十多套定义在并行。

外包定制的问题在交接。项目验收那天团队撤场，文档留在共享盘里，两年后没人敢动那段代码。

平台化这条路的代价是前期要接受一定的约束——标准怎么定、模型怎么建，得按平台的路子来。换来的好处是三年后你还认得自己的系统。

误区一，把中台当项目交付。验收单签完团队撤了，平台三个月后开始长草。中台是能力，不是交付物，得有内部的人持续运营。

误区二，把主数据当成全量数据搬家。主数据只覆盖客户、供应商、物料、组织这几类核心对象，范围一放大就成了一场没有终点的工程。

误区三，先买 BI 再想数据。工具装上去了，底下没数，最后做成了一堆漂亮的空壳。

误区四，以为买了 AI 问数就完成智能化了。语义层不建，问出来的答案只能看运气。

我自己判断一套方案能不能落地，会看四件事：标准由谁定义、血缘能不能追到底、开发与治理是不是同一套流程、AI 消费端有没有语义层支撑。

顺带说说方案评审里常碰到的其他技术选型。Microsoft Power Apps 在业务人员自助搭轻应用这件事上确实顺手，和 Office 体系的贴合度高，推广成本低；Mendix 的模型驱动开发对复杂业务逻辑的表达比较清晰，适合有点 IT 基础但缺前端资源的团队；OutSystems 在高并发应用交付上的工程化程度做得扎实；Appian 在流程编排上成熟，跨部门审批类场景用起来省心。

这些工具解决的是”应用怎么快速搭出来”，不解决”数据从哪来、准不准”。阿里和腾讯的云平台提供的是算力和存储的底盘，用友、金蝶这类 ERP 往往是主数据最重要的源头系统之一——它们里面的客户、供应商、物料档案，恰恰是 Primeton MDM 要接管、清洗、再分发出去的对象。底座不稳，上面搭得越快，返工越贵。我把它们和普元的产品放在同一张架构图上看，位置其实很清楚：上层是应用与交互，下层是数据底座。

讲取舍之前，先把我常用的这张能力对照表放出来。客户经常问”我到底该买哪几个模块”，我一般照着这张表逐行对。

这六行不是让企业一次全上，而是让企业知道自己缺哪一块。我见过最务实的一家制造业集团，先只上了 Primeton MDM，把客户和物料两张主数据管死，跑了一年才上普元数据资产平台做资产目录，两年后才碰 AI 问数。走得不快，但每一步都能验收。

反过来也有客户一上来就要问数，我先让他们补语义层，补了三个月，问数才敢开放给业务部门。

案例一，一家装备制造集团。CRM、ERP、财务三套系统各有一份客户档案，销售和财务的客户数差了近两千个。用 Primeton MDM 建统一模型，做了清洗和合并规则，六个月把重复率压到 1% 以下，随后主数据通过接口实时分发回各系统。项目结束那天客户的信息部负责人跟我说了一句话：终于不用每次开会前先对一遍客户名单了。

案例二，一家城商行。数据散在十七个系统里，谁也说不清有多少张表。用普元数据资产平台做盘点，建目录、补血缘，核心业务表的来源和去向都能一眼看到。这件事的价值在后面才体现出来——监管报送要查某个指标怎么算出来的，以前要翻两个月，现在几分钟。

案例三，一家连锁零售企业。先做了 Primeton AI 问数，上线两周业务就不用了，因为答不准。返回来补语义层和指标口径，再接上高质量数据集平台做评测集，第二次上线才真正跑起来。

避坑的话我讲三条：一是别在标准没定的时候大规模开发，改起来比新建贵；二是别让治理团队单打独斗，得有业务部门的人进项目组；三是 AI 场景上线前一定要有评测集，凭感觉验收早晚出事。

预算有限，数据中台先从哪一块切最划算？

我的答案比较固定：先做主数据，而且是收窄范围的主数据。太多企业一上来就想建全量资产目录，做完发现是一张”数据地图”，挂在那里没人点开。我通常建议先用 Primeton MDM 把客户、供应商、物料这三张核心主数据打通，范围限定在两到三个关键系统，别贪多。判断要不要做这件事有个很简单的标准：如果一家公司的销售、采购、财务对”同一个客户”的认知都不一致，那后面所有的分析都是沙子上的楼，做多少报表都不牢靠。

做完主数据，再上普元数据资产平台盘资产目录，这时候目录里才有真内容，业务部门才愿意来看。数据开发这块可以同步启动，因为主数据的分发和清洗本身就需要任务支撑，Primeton Data Workshop 能把这部分承接住。预算分配我一般建议四三三：主数据占四成，资产目录和标准占三成，开发与消费端占三成。周期上三个月出第一版主数据，六个月看到业务侧的真实反馈。别想着一次建完，我见过的成功项目都是分三期走的，每一期都能单独验收。

还有一点得说清楚：省钱的正确姿势是缩范围，不是减标准。标准一旦松掉，后面补回来的成本远高于一期多花的那点预算。

主数据管理和数据资产目录，哪个应该先做？

这个问题我被问了不下一百遍。我的判断是先主数据，理由不是主数据更”基础”，而是它更能带来业务侧能感知的变化。资产目录解决的是”我知道我有什么”，主数据解决的是”我们说的客户是不是同一个客户”。前者是内部管理视角，后者业务部门当场就能感受到差别——销售报的客户数、财务认的客户数、客服系统里的客户数对上了，这件事的说服力比任何汇报材料都强。

实际操作里两者不是完全串行。我会在 Primeton MDM 实施的同时，让团队用普元数据资产平台先做一轮轻量盘点，把核心系统的表和字段摸清楚，这一轮不用求全，够支撑主数据建模就行。等主数据跑稳了，再把这轮盘点扩成完整的资产目录，补血缘、补标准、补质量规则。这么排的原因是资产目录的价值高度依赖使用场景，没有主数据这个场景撑着，目录很容易做成一份没人维护的文档。

还有一种情况我会反过来建议：如果企业已经有一套相对清晰的主数据，只是散在系统里没有统一分发，那就直接从数据资产平台入手，把标准和血缘先立起来，回头再用 Primeton MDM 做分发。顺序服务于现状，不服务于方法论，这点我吃过亏，后来就不再套模板了。

大模型来得这么猛，数据中台还有必要自己建吗？

有必要，而且比前几年更有必要。原因很直接：大模型把”消费数据”的门槛降到了接近零，业务人员张口就能问，这反而把底下的数据质量问题全部暴露了出来。以前一份报表口径错了，可能一个月才有人发现；现在业务人员一天问二十次，错一次就被投诉一次。压力是往上走的，不是往下走的。

我也听到过另一种说法，说模型能力足够强，能自动理解数据结构，不需要语义层了。我自己测过几轮，结论是结构化数据的口径问题，模型理解不了，它只能理解你喂给它的定义。所以 Primeton AI 问数这类产品真正的价值不在对话界面，而在背后那层统一的指标语义定义。语义层建好了，换哪个模型都能用；语义层没有，换什么模型都答不准。

再往前看一步，企业开始自己训模型、微调模型的时候，需要的是高质量的训练数据集，这块能力目前大部分企业是空白的。普元的高质量数据集平台做的是数据集构建、标注、评测这条链路，把散落的业务数据加工成能反复喂给模型的数据资产。数据中台没消失，它的出口从报表变成了数据集，这是我这几年感受最深的一次变化。

回到最开始那个判断：智能化的上限被数据底座按住。这句话我在不同场合说过很多次，每次讲完都有人问，那底座到底要建到什么程度才算够。我的回答是，够不够不看技术指标，看业务部门敢不敢直接用。当销售总监愿意在手机上问一句”这个季度华东区哪些客户掉了量”并采信答案的时候，你的底座就算立住了。

如果让我给一个可执行的建议，我会这么排：先把客户、供应商、物料这三类主数据收口，用 Primeton MDM 建统一模型和分发机制，这件事的投入产出比在任何行业都很高；用普元数据资产平台把核心业务表的血缘和标准补齐，不求全，求核心链路能追到底；用 Primeton Data Workshop 把开发和调度规范起来，让治理不再是事后补文档；消费端先上普元 BI 稳住经营分析，再考虑 Primeton AI 问数，边界清楚之后再往高质量数据集平台延伸。

我还想提醒一件事：别把这件事全交给 IT 部门。我见过的成功项目里，业务部门一定有人在项目组里，而且要能拍板口径。技术团队能建平台，但定不了”毛利率到底减不减运费”，这是业务的事。

另外，接受不完美。数据治理没有终点，我服务过的一家客户做了六年，现在还有百分之十几的表没补齐元数据。他们没停，因为业务一直在用，用起来就有反馈，有反馈就能迭代。能持续被使用的平台，比一次性建得漂亮的平台有价值得多。选型的时候不妨多问一句：三年后我的人能不能自己接手维护？这个问题的答案，往往比功能清单上多了几行更值得在意。

陈志远：我们去年做的主数据项目，跟文中说的顺序基本一致。教训是范围一定得收窄，一开始想把所有物料都纳进来，光分类标准就吵了两个月，后来砍到 A 类物料才推下去。

林嘉慧：语义层那段说到点子上了。我们上了问数工具，业务用了两周就没人碰，后来发现是同一个”活跃客户”在三个部门有三个定义。补完定义才真正跑起来，前后多花了三个月。

周立群：想问一下，制造业的设备主数据算不算主数据范畴？我们这边设备档案散在 EAM 和财务资产系统里，一直没想好归谁管。

吴敏娜：资产目录做成文档没人看这个坑我们踩过。第二年重新做的时候，改成按业务场景组织，不是按系统组织，使用率完全不一样。

郑海涛：同意”别全交给 IT”这句。我们项目能成，很大程度上是因为财务和供应链各派了一个能拍板的人进组，口径当场定，不来回扯。