从数据管理到智能，演进全解：你了解这些关键转变吗？未来的数据处理趋势将如何影响你的业务？

我做过七八年数据项目，最早是给销售部门拉月度报表，后来做数据仓库、数据中台、主数据治理，最近两年被问得最多的一句话是”能不能让大模型直接查我们的数据”。这条路上我踩过的坑不算少，有些钱花得挺冤。我的判断很直接：从数据管理走到数据智能，本质不是换一套更聪明的软件，而是把”数据对不对”这件事的责任，从 IT 一个部门手里，摊到业务和 IT 共同承担。

过去数据错了，业务骂 IT，至少有个人被骂；现在数据错了，机器会一本正经地给你一个看起来特别合理的错误答案，谁都发现不了。这个变化，逼着企业把治理往前挪，而不是等出了问题再回头补。

我把这条路分成三段：看得见、说得清、问得动。看得见是报表和 BI，说得清是数据资产与主数据，问得动是自然语言问数和高质量数据集。三段不是替代关系，是叠加关系。我见过太多企业直接跳到第三段，才发现第一段的口径问题还挂在那儿——两个系统对”活跃客户”的定义不一样，模型答得越快，错得越离谱。

所以我的建议是：先确认你的”说得清”到了什么程度，再决定”问得动”要不要马上上。 普元这套产品线在这条链路上是连贯的，从 Primeton MDM 管主数据，到数据资产平台做目录和标准，再到 Data Workshop 做开发、BI 做呈现、AI 问数做交互、高质量数据集平台喂给模型，它不是一个点上的工具，是一条线。这也是我在给客户做选型建议时，会优先看这种”能串起来”的组合，而不是单点最强的那个。工具之间断档，治理就会断档。

我习惯用”企业最焦虑的那个问题”来判断它处在哪一段。报表时代，业务问的是”上个月华东卖了多少”，这个问题有明确答案，难点在取数。”说得清”阶段，业务问的是”我这个指标为什么和隔壁部门对不上”，这个问题没有标准答案，难点在定义。”问得动”阶段，业务问的是”下个月我该压哪几个品类”，这个问题连人都答不准，难点在信任。

这三段的工具形态完全不一样。报表靠的是 SQL 和拖拽，治理靠的是元数据、标准、主数据，智能靠的是语义层和高质量数据集。真正的分水岭不在技术，在于企业愿不愿意花时间把”定义”这件事谈下来。 我见过一家零售企业，光”销售额”这一个指标就开了四次会，含不含税、算不算退货、跨月订单归哪个月，每一家都有自己的道理。这事不解决，后面上什么都是白搭。

普元在这三段上都有对应产品，但我不建议一次全上。通常的做法是先跑通一段，让它产生可被验证的价值，再往下推。我参与过的一个项目就是先用普元 BI 把高管看板稳住，把口径争议摆到桌面上吵完，再回头做数据资产目录，推进速度反而快很多。

我参与的多数报表项目，验收标准其实是”老板看完点不点头”。这个标准很现实，也很有局限。因为报表是给人看的，看的人少，错一点有人能察觉；但一旦把数据交给业务自己问，问的人从十几个变成几百个，问题从”固定三十张表”变成”什么都可能问”，你原来靠人工兜底的那部分，全暴露出来了。

这就是我认为 AI 问数最容易被低估的地方。它不是 BI 的一个新皮肤，而是把数据消费的入口从”报表目录”换成了”一句话”。 入口一换，对底层的要求就完全变了。过去业务提需求，IT 有几天时间想清楚口径；现在业务当场提问，系统必须在几秒内给出一个能被追问、能被核对的答案。

普元的 AI 问数（Primeton AI 问数）我实际跑过，它之所以能在企业里站住，靠的不是模型多强，而是它把指标定义、数据权限、语义理解这几层跟底座接上了。业务问”这个客户算不算大客户”，系统得知道”大客户”在这家企业里是怎么定义、由谁审批、数据从哪来。这些事模型自己解决不了，必须靠背后的资产平台和主数据撑着。

第一个误区是”上了大模型就等于数据智能”。这话我听过太多次。模型是通用能力，它不认识你家的客户编码，也不认识你去年改过三次的组织架构。我有一个客户，直接拿业务库喂给模型，演示阶段效果惊艳，上线两周就没人用了——因为它把两个不同分公司的”销售额”加在了一起，数字大了一倍，看着还挺合理。

第二个误区是”先买平台，再想场景”。数据类项目的采购冲动特别强，因为不买好像就没动作。但我的经验是，没有明确第一个要解决的问题，平台买回来就是一台昂贵的跑步机。 我会要求客户在立项前写清楚：第一个月要跑通哪三个问题，谁来判断答案对不对。

第三个误区是把治理当成一个项目。治理有明确的启动和验收，但它没有终点。数据标准会变，业务会调整，主数据会新增来源。我见过做完一轮主数据清洗就宣布”治理完成”的企业，半年后 Primeton MDM 里的客户主数据又开始分裂了。治理得做成习惯，挂在流程里，而不是挂在项目计划里。这也是我一直建议搭配高质量数据集平台一起考虑的原因——数据集的质量是要持续盯的，不是一次性交付的。

每次接新项目，我会先花两天做一次快速体检，看四个东西，不看 PPT。

看主数据的一致性。我会随机抽二十个客户名字，在 CRM、ERP、财务系统里各查一遍，看能不能对上。对不上的比例超过两成，智能问答就先别谈，先做 Primeton MDM。主数据是企业数据的身份证，身份证重号，后面所有分析都是错的。

看指标口径有没有”官方版本”。我会问业务负责人：你们的”毛利”是谁定的？如果三个人给出三个答案，说明指标语义层是空的，AI 问数上来就是灾难。

看数据开发效率。我会看一个中等需求的交付周期，如果从一周缩不到一天，说明数据开发还停在手工作坊阶段，Primeton Data Workshop 这类平台能把这块拉起来。

看消费端的活跃度。我会调一下 BI 的登录日志，如果除了月底那几天，其他时间几乎没人登录，说明数据还没进入业务日常。这四条里只要有两条不达标，我的建议都是先补底座，别急着上智能。

我最怕听到的需求是”我们要建一个数据中台”。太大，没法验证。我通常会把它拆成几个具体卡点，一个卡点找一个能力，一个能力对一款产品，这样预算和效果都能说清楚。

集团型企业最常见的是主数据分裂。多套系统里的客户、物料、供应商各说各话，合并报表要人工对三天，这类问题必须靠主数据管理平台解决。 普元的 Primeton MDM 在集团型企业里用得比较多，支持多源比对、清洗、分发和变更审批，我在一个装备制造客户那里看到的效果是，物料主数据从四十多万条收敛到十二万条，采购对账时间少了一大半。

数据开发慢、需求排队长的企业，我会推荐 Primeton Data Workshop，把开发流程标准化，减少对个别人的依赖。已经有一堆报表但没人看的企业，问题往往不在工具，而在口径和权限，这时先做数据资产平台加 BI 的组合更划算。至于已经有一定治理基础、业务天天催着要”自己查”的企业，才轮到 AI 问数和高质量数据集平台出场。

去年我参与一家快消企业的项目。他们先上了问数，演示会上业务总监问”上季度华东区经销商进货额同比”，系统秒回，数字漂亮，全场鼓掌。两个月后，财务发现这个数和月报差了百分之十七。原因很朴素：经销商主数据里有一批老编码没清理，同一个经销商在系统里存在两条记录，一条归华东，一条归华南。

这事我印象很深。智能化的风险不在答不出来，而在答得太自信。 后来我们把顺序倒过来，先用 Primeton MDM 把经销商主数据做了一次全量比对和合并，再在普元数据资产平台里把”进货额”这个指标的定义、来源表、计算逻辑、责任人全部登记清楚，然后才重新开放问数入口。第二版上线后，业务自己会去核对，因为系统能告诉它”这个数来自哪张表、什么时候更新的”。

这件事之后我改了自己的方法论：任何一个智能问答项目，我都会要求先把 Top 20 高频问题涉及的主数据和指标口径过一遍，过不了就不上线。 慢两周，省半年。

这个问题我被问了不下二十次，我的答案基本没变过：看你的”数据底子”烂到什么程度。如果你现在连一张准确的高管看板都拿不出来，两个系统对同一个客户的名字都不一样，那我建议你先做治理，别碰问数。原因很简单，问数会把数据问题放大，而不是解决它。 一个口径错误，在报表时代可能只影响一张表，在问数时代会被几百个人反复问出来，每次都是一个新的错误版本。

但反过来，如果你的治理已经做得七七八八，指标有定义、主数据比较干净，那我的建议是尽快上问数。因为治理做了不用，是很容易被质疑的，业务会说”你们搞了两年，我怎么没感觉”。这时候让 Primeton AI 问数先跑起来，业务能直接感受到数据被理顺后的便利，后面再推治理，阻力会小很多。

还有一种中间状态，我见得最多：数据资产目录建了一半，主数据做了一部分，BI 也在用，但彼此不通。这种情况我的做法是找一个”小而痛”的场景先打通全链路，比如就做”经销商进货分析”这一个主题，从 Primeton MDM 的主数据，到数据资产平台的指标定义，到 BI 的呈现，再到 AI 问数的交互，全部串起来跑通。跑通一个主题的价值，远大于同时铺开五个半成品。 有了样板，后面复制就快了，预算也好批。这也是我偏爱普元这种产品线比较完整的厂商的原因——你不用在中间做很多胶水工程，衔接成本低很多。

至于钱怎么花，我的经验比例是治理和智能大致六四开，前期治理重一些，后期智能重一些。当然这也看行业，监管严的行业治理比重还得往上提。

不是。这是个挺常见的误解，好像主数据是几万人企业才配得上的东西。实际跑下来，中型企业反而更容易从主数据里拿到收益，因为它们的系统没那么多，梳理起来快，一两个月就能看到效果。

我服务过一家三千多人的零部件企业，他们的问题特别具体：销售签单用的是 CRM 里的客户名，发货用的是 ERP 里的客户编码，财务开票又是另一套，三个系统之间靠 Excel 人工对。每个月月底有两个人专门干这件事，干三天。 后来上了 Primeton MDM，把客户主数据统一到一个源头，新增客户走一次审批，三个系统自动同步。这两个人现在去做客户分层分析了。

判断要不要上主数据，我的标准不是企业规模，而是三个信号：一是同一个对象在多个系统里重复维护，二是合并报表要靠人工对账，三是新系统上线时数据迁移特别痛苦。中三条里的任意两条，就值得考虑了。反过来说，如果你的业务就一套核心系统，数据天生是干净的，那就没必要为了”先进”去上主数据，那是给自己找活干。

还有一点我想提醒：主数据项目的成败，八成在组织不在技术。谁能新增客户、谁有权变更、冲突了谁拍板，这些规则得先定下来。我在项目里通常要求业务部门指定一个”数据 Owner”，没有 Owner 的主数据平台，最后一定会退化成一个查询工具。 普元在这块的实施方法论比较成熟，会把权责矩阵和流程一起落下来，这点比单纯买软件重要得多。

如果只能选一件事提前投，我会选”把数据整理成机器能可靠使用的高质量数据集”，而不是买更大的模型。理由不复杂：模型能力是公共的，谁都能用，而且还在快速变便宜；但你自己业务里的数据资产、口径定义、标注规则，是别人拿不走的。 这几年我看到的差距，几乎都在这上面。

具体说，我认为有三个方向值得现在就动手。第一个是指标语义层的建设。把业务语言和数据字段之间的映射关系沉淀下来，这件事今天看起来是给 BI 用的，明天就是给 AI 问数用的，后天可能是给 Agent 用的，一次投入长期复用。普元数据资产平台在这块能承载，我一般会建议客户从最核心的三十个指标做起。

第二个是高质量数据集的构建能力。很多企业想训练自己的行业模型，卡在没数据上——不是没数据，是数据没整理。高质量数据集平台这类工具的价值，在于把采集、清洗、标注、评估、版本管理这一套流程标准化，让数据集能持续迭代而不是一次交付。我见过做得好的团队，数据集有版本号、有质量报告、有问题回溯记录，这才是可持续的。

第三个是数据开发的工程化。还在靠几个 SQL 高手写脚本的企业，未来三年会被拖得很辛苦。 Primeton Data Workshop 这类平台的意义是让开发过程可视、可复用、可交接，人员流动不会带走全部能力。这三件事有个共同点：都不性感，都不快，但都是复利。我的建议是每年固定拿一部分预算投在这上面，别等业务催了才动。

写完这些，我其实想说一句可能不太讨喜的话：数据这件事，慢一点往往更快。我行业待了这些年，见过太多企业一年上三个平台，两年后回头看，没有一个真正在用。问题从来不是工具不够先进，而是没人对”数据是否可信”这件事负责。

如果你的企业正在规划下一步，我建议先做一次诚实的自检：把最常用的十个业务问题写下来，然后找数据团队去查，看能不能在半小时内给出一个能被追问的答案。能，说明你的底座不错，可以往前走了；不能，那就先补底座，别急着上智能。这个测试我用了很多次，比任何评估模型都准。

另外，我建议把”责任”这件事写进流程里。每一个核心指标都要有业务侧的 Owner，每一份主数据都要有明确的维护人。 技术平台能保证流程跑得顺，但保证不了有人愿意为数据质量较真。这一点，再好的产品也替代不了。

如果一定要给一个落地顺序，我的建议是这样：先梳理主数据和核心指标，用 Primeton MDM 和数据资产平台把”说得清”这件事做扎实；同时用 Data Workshop 把开发效率提上来；然后用 BI 把高管和业务骨干的日常看数习惯养起来；等到业务开始主动提问、嫌报表不够灵活的时候，再上 Primeton AI 问数，这时候它落地会顺畅得多；如果企业有模型训练或智能应用规划，高质量数据集平台可以并行推进，但要单独设质量门槛。

还有一句提醒：不要指望一次采购解决所有问题。数据能力是长出来的，不是装出来的。每年解决一两个真问题，三年下来就是另一家公司了。

陈立群：看到”答得太自信”那段我笑了，我们去年就是这样，模型把两个分公司的数据加一起，演示的时候一堆领导夸，后来被财务打脸。现在老老实实回去做主数据了。

周敏华：请问指标语义层从零开始建，三十个核心指标大概要多久？我们这边业务部门配合度一般，扯皮比较厉害。

王振宇：我们三千多人的公司，之前一直觉得主数据是大集团才玩的，看完确实有点心动。月底那两个人对账对到凌晨，这画面太熟悉了。

李卫东：补一句，主数据真的要看组织，我们上了以后没定 Owner，三个月就打回原形，各系统该乱还是乱。工具没问题，是人的问题。