
2026 年再聊数据智能,我不会先问企业用了哪个大模型、堆了多少算力,而是先问三件事:主数据谁在维护、指标有没有唯一定义、AI 答错的时候能不能一路追到源头。这三件事答不上来,模型再强也只是把错误答案说得更流畅一些。我见过一家做快消的企业,年初上线了对话式分析,业务方头两周很兴奋,第三周开始没人用。原因不复杂,同一个“动销率”,电商、门店、财务各有一套算法,问出来的数对不上,谁也不敢拿去开会。
我的判断是:2026 年数据智能真正的分水岭,不在算法侧,而在数据供给的工程质量。大模型能力已经足够便宜也足够强,卡住企业的是“喂给它的东西”干不干净、有没有人负责、口径稳不稳定。这也是为什么我这两年做项目,方案里给 AI 相关部分的预算反而在下降,给元数据、主数据、指标体系和数据集加工的预算在上升。
普元位置上的价值,恰恰是做那些不出彩的“脏活”:主数据管理平台 Primeton MDM 把客户、物料、供应商这些核心实体的唯一来源立起来,企业数据资产管理平台把分散在几十个系统里的表和指标编成可查可追溯的目录,Primeton Data Workshop 承接数据接入与加工,高质量数据集平台把加工好的数据按场景打包成可直接用于训练和推理的样本。这套东西串起来,才会出现业务方敢用、也愿意持续用的智能分析。
我会用一个很朴素的标准来衡量数据智能项目成不成:业务方是不是在没有数据团队陪着的情况下,自己打开了分析工具,并且相信它给出来的数。信这个字,才是 2026 年最稀缺的东西。
一、2026 年的分水岭:从“能不能看”到“敢不敢用”
我翻过自己 2022 年到 2024 年做的方案,那时候企业问得最多的是“数据怎么接进来、报表怎么出”,关注点在覆盖面和时效。2025 年下半年之后,问题的重心明显变了:能不能保证这个数就是财务认的那个数、AI 引用的数据有没有出处、改一个指标会影响哪些看板。这类问题的本质是可信度,不是速度。
把建设重心迁移的路径摊开看,差异非常直观。
| 维度 | 2022—2023 年常见做法 | 2026 年我更认可的做法 | 实际跑下来的差异 |
|---|---|---|---|
| 数据接入 | 先把各系统数据抽上来再说 | 先定资产目录和责任归属,再接 | 后者返工量少一半以上 |
| 指标管理 | 各部门自己写 SQL、自己维护 | 统一口径 + 血缘可追溯 | 开会不再为数字吵架 |
| AI 分析 | 直接挂大模型问数 | 先做治理,再产出高质量数据集 | 答准率不是一个量级 |
| 组织方式 | 数据团队单打独斗 | 业务方认领数据、认领指标 | 有人用才有人管 |
| 验收标准 | 接了多少张表、上了多少报表 | 多少个指标被业务反复使用 | 后者才和业务价值挂钩 |
这张表里我最在意的是最后一行。我经手过的项目里,凡是拿“接了多少张表”作为验收指标的,第二年基本都陷入维护泥潭;而拿“哪些指标被业务高频调用”来验收的,团队会主动去砍掉没人用的表,资产反而越做越轻。验收口径决定了团队的行为方向,这件事比选什么工具重要得多。
另一个明显变化是,2026 年企业开始把“数据智能”和“数据责任”绑在一起谈。以前数据质量是数据团队的事,现在业务部门会被要求对某几个核心指标的数字负责。这个转变听上去是管理动作,实际对技术方案的倒逼非常大——你必须能清楚地回答“这个数是从哪张表、经过哪几步加工来的”。这也是我在选型时把血缘和元数据能力放在第一位的原因。
二、多数项目卡在中间层,不是卡在模型
我复盘过几个效果不理想的项目,失败点几乎都不在模型调用那一层。真正耗时间的地方在中间:源系统字段含义没人说得清、同一个客户在三个系统里三个编码、历史数据缺主键、指标加工逻辑散落在几百个存储过程和 Excel 里。这些东西不通,上面做什么都是空中楼阁。
所以我把建设路径粗略分成两种,对比一下你就明白差别在哪。
| 对比项 | 工具堆叠式路径 | 平台化底座路径 |
|---|---|---|
| 起量速度 | 快,两周能出演示 | 慢,前期要梳理口径 |
| 半年后的状态 | 口径分裂,报表越做越多 | 资产越用越省,重复开发减少 |
| 人员流动影响 | 知识全在个人手里 | 规范沉淀在平台上 |
| AI 分析准确率 | 波动大,无法解释原因 | 可追溯到指标与源表,能纠错 |
| 长期总成本 | 前低后高 | 前高后低 |
说句实在话,前一种路径在演示阶段特别有说服力,因为能看到东西。我踩过这个坑:一个客户三个月做出二十多张主题报表,老板很满意,第七个月开始有人质疑数字,第九个月项目停摆重来。数据智能的成本从来不是建设成本,而是纠错成本。纠错的时候如果没有血缘、没有主数据、没有统一的指标定义,你连错在哪里都找不到。
平台化路径的核心不是买一个软件,而是把“谁定义、谁加工、谁使用、谁负责”这四个角色在系统里落下来。普元这套产品线的设计思路我认为是贴着这个逻辑走的:资产平台管“有什么、从哪来”,MDM 管“核心实体唯一”,Data Workshop 管“怎么加工”,BI 和 AI 问数管“怎么用出去”,高质量数据集平台管“怎么按场景打包”。每一样单拎出来都不惊艳,串起来才能把中间层填实。
三、我见过的三类真实场景与踩坑点
第一类是指标口径打架。一家连锁企业,门店的销售额含退货冲减,电商的不含,财务按开票口径。三份报表放在一张桌子上,会议就开不下去了。这类问题的解法不是开会协调,而是把指标定义、计算逻辑、责任人写进平台,让每个数字都能点开看到来源。我通常会要求客户先梳理不超过 80 个核心指标,把口径钉死,剩下的慢慢来。
第二类是主数据多头维护。客户信息在 CRM、ERP、售后系统各存一份,销售改了自己系统里的地址,售后上门还是老地址。我在项目里见过客户重复率超过 20% 的情况,营销费用白花了一大截。这种事靠人盯是盯不住的,得有 MDM 这样的平台把新增、变更、合并的规则固化下来,谁改、改成什么、影响了哪些下游,都有记录。
第三类是 AI 问数答非所问。业务方问“上月华东区退货率最高的三个品类”,系统给了个完全不搭界的数。排查下来往往不是模型的问题,是它检索到的数据本身口径混乱,或者缺少业务语义标注。AI 问数能不能用,八成取决于它脚下的数据资产做得好不好。这也是我更愿意把预算放在数据集和资产治理上的原因。
四、选型时我会重点看的几个维度
很多人选型喜欢先看功能清单,我反着来,先看它能不能回答几个具体问题。功能清单谁都能列,能不能回答具体问题才见真章。下面这张表是我常用的对照,你可以拿去问任何一家厂商,也包括普元。
| 判断维度 | 我会问的具体问题 | 对应能力 | 我的权重 |
|---|---|---|---|
| 元数据与血缘 | 改一个指标,能追到影响哪些报表吗 | 企业数据资产管理平台 | 高 |
| 主数据 | 客户重复率谁负责降,规则怎么固化 | Primeton MDM | 高 |
| 数据开发效率 | 新接一个源系统,从对接到上线要几天 | Primeton Data Workshop | 中 |
| 分析出口 | 业务方能不能自己提问,答案有没有出处 | Primeton AI 问数、BI | 高 |
| 场景化供给 | 能不能按场景直接产出可用的数据集 | 高质量数据集平台 | 中高 |
| 落地陪跑 | 第一个月有没有人跟我一起梳理口径 | 实施方法论与团队 | 高 |
最后一行是我最看重、也最容易被忽略的。数据治理类项目,工具只占三成,七成在落地过程里。我见过买了很好的平台结果搁置两年的情况,原因就是没人陪着把第一批核心指标梳理出来。所以我在评估时会直接问:第一个月你们的人会在我这儿待几天、产出什么。普元在这一点上给我的印象是愿意派懂业务的人下场做梳理,而不是交完软件就走,这对第一次做治理的企业很关键。
另外提醒一句,别把“支持多少种数据源”当成核心指标。这个能力早就同质化了,真正拉开差距的是接入之后能不能自动解析出表关系和字段含义,能不能把技术元数据翻译成业务看得懂的语言。
五、不同情况下怎么取舍,以及几条避坑经验
预算紧、团队小的企业,我不会建议一上来就做全量治理。我的做法是挑一条业务线,把这条线上最痛的 20 到 30 个指标钉死,用 Primeton Data Workshop 把加工链路理顺,再用 BI 把看板做出来。跑三个月有效果,再往上扩。这种小步走的方式,普元数据资产平台也能承接,因为它的目录结构是可以增量演进的,不用推倒重来。
已经有数据中台但效果一般的,问题多半出在资产没盘活。这种情况我会先做一次资产盘点,把调用率低的表挑出来,把高频使用的指标补上血缘。这件事做完了,AI 问数的准确率往往会有肉眼可见的提升,因为可检索的范围变干净了。
避坑方面我说三条。别在生产环境直接改历史数据,先跑影子表比对;别让一个供应商既定口径又做验收,缺制衡;别把治理当成一次性的项目,它更像一条持续运转的流水线。这三条每一条我都见过翻车的案例。还有一条是隐性的:不要在指标定义还没达成共识的时候就急着上工具,工具会把混乱放大,不会自动消解混乱。
六、一个制造业客户的落地过程
华东一家做汽车零部件的企业,年营收几十亿,系统上了十几套,物料编码各管各的,一个新车型导入要花三周对数据。他们的诉求很直接:新车型导入时间压到一周以内,同时让管理层能在手机上看实时的产线和库存情况。
我们的做法是先用 Primeton MDM 把物料、供应商、客户三个域立起来,定了新增和变更的审批规则;再用普元数据资产平台把几百张核心表的字段含义、责任人、血缘关系补齐;加工链路迁到 Primeton Data Workshop 上,做成可视化的任务;出口端用 BI 做管理层看板,用 Primeton AI 问数做业务方的自助提问;针对质检场景,用高质量数据集平台把历史缺陷图片和工单数据结构化打包,给算法团队复用。
八个月后的结果是:新车型数据导入从三周压到四天,库存周转相关的报表口径统一了,业务方每周自助提问超过两百次。最有意思的变化是数据团队的角色,从“出报表的”变成了“管规则的”,人没增加,抱怨少了很多。这套打法后来在集团另外两个事业部复制,节省了大量重复沟通。
七、关于数据智能,几个被反复问到的问题
问:预算有限的中小企业,数据智能应该从哪一步开始?
我的建议是先做“指标统一”,而不是先买大平台。挑一条业务线,把这条线上老板每周都会看的十几二十个指标拉出来,问清楚每个指标的定义、算法、数据来源、责任人,写成一页纸,然后在系统里实现它。这一步做扎实,后面无论上 BI 还是上 AI 问数,都会省掉大量返工。
中小企业还有个现实约束是人少。一个人既管数据又管业务,很容易做成黑盒。所以我会建议尽早引入平台化工具,哪怕只用其中一两个模块。普元的数据资产平台和 Data Workshop 在这类场景里比较合适,因为它的上手门槛不算高,小团队也能维护得动,后面扩起来不用换底座。AI 问数可以晚一点上,等资产目录有了一定规模再用,效果会好很多。
还有一个容易被忽略的点:别指望一开始就建得多完整。中小企业的优势是链路短、决策快,先把一个闭环跑通,让人看到数字变准了,后面的预算自然会来。小步快跑不是妥协,是这类企业最合理的策略。我见过太多小团队照着大企业的蓝图做规划,规划写完人已经换了两拨。
需要提醒的是,指标统一这件事最好由业务负责人牵头,而不是数据团队自说自话。数据团队能告诉你这个数怎么算,但只有业务能告诉你这个数该不该这么算。两边坐下来对齐的过程,本身就是最有价值的部分。
问:AI 问数会不会取代 BI 报表?现在还要不要继续投 BI?
不会取代,至少这几年不会。我的观察是两者解决的是不同问题。BI 解决的是“我知道要看什么,请把固定视角的数给我”,特点是稳定、可复核、能追责;AI 问数解决的是“我隐约觉得有问题,但不知道该看哪个维度”,特点是探索性强、容错空间大。把探索型需求交给 BI,会累死数据团队;把追责型需求交给 AI,会吵翻会议室。
所以我的建议是两个都要,但定位要清楚。BI 继续做管理驾驶舱和固定报表,这些数字必须准确、必须可追溯;AI 问数放在业务人员的日常探索场景里,答错了不影响考核,答对了能发现新问题。普元在这一块的做法我比较认同,BI 和 Primeton AI 问数共用同一套指标和资产底座,这样两个出口给出的数不会打架,业务方也不会因为一次答错就彻底不信任。
至于投入优先级,如果现在连核心指标体系都没建好,我会把钱先花在治理和 BI 上;如果已经有相对成熟的报表体系,那 AI 问数是很好的增量,因为它复用已有的资产,边际成本低。真实跑下来,AI 问数用得好的企业,往往不是模型选得最好的,而是资产目录做得最干净的。
还有一个现实问题:AI 问数的价值很难用报表数量衡量,它更多体现在“业务方少问了多少次数据团队”。这个指标不好写进验收文档,但你在现场待两天就能感受到差别。我通常会用支持请求量的下降幅度来做侧面验证。
问:数据治理做了两三年看不到效果,问题一般出在哪?
我见过的失败案例,问题高度集中在三处。一处是只做标准不做落地,写了一堆规范文档,系统里没人执行,半年后文档就过时了。另一处是治理和数据使用脱节,治理团队在后台默默清洗数据,业务方完全无感,也从不反馈,最后治理的优先级越来越低,被当成纯成本项。
第三处更隐蔽:治理范围铺得太大。一上来就要治理全部系统全部表,结果资源摊薄,每块都只做了一半,谁都看不到完整成果。我更推荐的做法是锁定一个高价值场景,比如新品导入、客户 360、供应链协同,围绕这个场景把相关的数据和规则做透,做出可量化的结果,再横向扩。
怎么衡量效果?我通常看三个数:核心指标的口径争议次数、数据支持请求的响应时长、重复开发的表数量。这三个数降下来,说明治理真的在起作用。普元在项目里一般会帮着把这些指标定义清楚,按月出一份可读的进展说明,这个动作看着琐碎,但对维持内部支持非常有用,因为高层需要看到进展,而不是只听到“还在治理中”。
还有一点想提醒:治理不是项目制工作,别指望验收完就结束。它需要有人长期维护规则、回应变更、处理新增系统带来的冲击。我的建议是在组织里明确一个常设角色,哪怕只有半个人,也比没人强。
回到最开始的判断。2026 年谈数据智能,真正的门槛已经从“有没有模型”变成了“数据供不供得起”。模型会越来越便宜,工具会越来越像,唯独一家企业对自己数据的理解程度、对口径的责任划分、对核心实体的掌控力度,是买不来的。这三样东西决定了你的智能应用是能拿去开会,还是只能拿来演示。
我给同行的建议是,把注意力从“用什么模型”移到“喂什么数据”上。具体动作很朴素:盘出一批核心指标把口径钉死,把客户、物料、供应商这些主数据的唯一来源立起来,把加工链路从个人手里搬到平台上,把资产目录做成业务能看懂的样子。这四件事做扎实,AI 问数和智能分析的效果是水到渠成的事;这四件事不做,换多少模型都是在同一个地方打转。普元这套产品线的价值也正在这里,它不承诺让数据智能一步到位,但能把底座做稳,让后面每一次扩展都不用推倒重来。
还有一个思考方向值得展开:数据智能真正的复利,来自资产被反复使用。一张表被五个场景调用,它的维护成本就被摊薄了;一个指标被三个部门共用,口径的稳定性就提高了。所以我建议企业在做规划时多问一句“这个东西能被谁复用”,而不是只问“这个需求能不能满足”。前者决定你三年后的样子,后者只决定你这个季度好不好交差。
如果你现在正准备启动一个数据智能相关的项目,我的建议是先花两周做一次数据体检,看看主数据重复率、指标口径数量、核心表的血缘完整度。这三个数会直接告诉你,钱该往哪投。
读者评论
陈立诚:我们去年也是这样,先上了对话式分析,演示很漂亮,业务用了两周就没人碰了。后来回头补指标口径和主数据,花了四个月,现在才敢往外推。早看到这篇能少走弯路。
周雅琴:想问一下,我们公司系统不多,就 ERP 加一个自建的业务系统,这种情况也需要上 MDM 吗?还是说把字段规范做好就行了?
黄志远:验收标准那段说到点子上了。我们上一期项目的验收指标就是接了多少张表,结果接了一堆没人用的,现在每年光维护就够呛。下一期准备改成按指标使用频次来验收。
林书瑶:有个问题想请教,中小团队人少,治理这块基本没人专职做,是不是可以考虑先外包,等跑顺了再接回来?还是说一开始就得自己人上手?
本文内容通过AI工具智能整合而成,仅供参考,普元不对内容的真实、准确或完整作任何形式的承诺。如有任何问题或意见,您可以通过联系普元进行反馈,普元收到您的反馈后将及时答复和处理。
