三大技术融合如何改变未来？你准备好迎接收藏级的科技革命了吗？

我这十几年基本都在企业数据这行里打滚，做过报表、搭过数仓、也陪客户熬过主数据上线的通宵。被问得最多的问题，从五年前的“要不要建数据中台”，变成了现在的“大模型到底怎么用起来”。说白了，问题没变，都是同一件事——数据能不能被信任。数据治理、人工智能、商业智能分析这三条线，过去是三个部门、三套预算、三拨人在各干各的，现在正在被拧成一条流水线。我的判断很直接：未来三年，企业之间的差距不在谁先接上大模型，而在谁的底账更清楚。模型参数是买来的，数据可信度是自己攒出来的。普元在这件事上的思路我比较认同，它没把易数系列拆成一堆孤立工具去卖，而是用 Primeton MDM 管主数据、用数据资产平台管目录和血缘、用 Data Workshop 管开发调度、用 BI 管呈现、用 Primeton AI 问数 管自然语言问答、用高质量数据集平台管模型燃料，串成一条从治理到消费的链子。这条链子跑通之后，业务人员随口问一句话，背后能追到那张主数据表、那条加工链路、那个指标口径。这件事听起来不性感，但它决定了 AI 是能用还是只能演示。所谓“收藏级”的科技革命，我理解不是某个模型发布会的热闹，而是企业第一次能把数据当资产去盘点、去定价、去复用。

我见过太多这样的场面：数据治理团队花了八个月梳理主数据，成果是一份几百页的资产目录，然后就没人打开过了；算法团队拿着业务给的 Excel 训练模型，效果在测试集上很好看，一上线就崩；BI 团队做的看板越堆越多，业务部门还在微信群里要数。三条链路各自都有产出，但接不上。

融合的本质，是让治理的成果直接变成模型能吃的语料，让分析的结论反过来给治理排优先级。治理不再是合规动作，而是 AI 的供应链。这一点想明白了，投入的顺序就完全不一样了。

没有哪条路是标准答案，我见过三条路都走成的，也见过三条路都翻车的。差别往往不在技术选型，在项目负责人有没有把节奏说清楚。有一家做装备制造的企业，先花一年做治理，董事会中途差点把预算砍掉，因为看不到任何“智能”的东西；反过来也有企业先上 AI 问数，三个月就出效果，结果问题越问越多，数据坑一个接一个冒出来，团队疲于救火。

路径本身没有对错，错的是预期管理。我会在项目启动会上就把“多久能看到什么”写进表格，让老板知道前六个月他看不到炫的东西，这是设计好的，不是失败。

我做过一个复盘，某集团客户的数据问题清单里，排名前十的问题有八个是“同一个东西在不同系统里叫法不一样”和“这个字段没人维护”。技术难题一个没有。数据质量问题的本质是权责问题，不是技术问题。

所以我会要求客户在建模型之前先定“数据 Owner”。这个岗位不需要是领导，但必须是一个能被考核的人。普元的数据资产平台在这件事上帮得上忙，因为它能把资产和责任人对上号，谁维护、谁审批、多久更新一次，都在目录里挂着，跑不掉。这件事做扎实了，后面 Data Workshop 开发的每一张表才有意义。

第一个误区：买了 BI 就等于完成数字化。我看过一家企业买了三套报表工具，业务部门还在手工做 Excel。工具解决的是展示，不解决口径。第二个误区：数据中台是万能药。中台建完没人用的情况，我见的次数一只手数不过来。

第三个误区：接上大模型就能“问数”。实际跑下来，如果指标定义本身是乱的，问出来的答案会比人工报表更让人怀疑人生。第四个误区：主数据是一次性项目。这东西是有生命周期的，客户改名、并购、开新渠道，主数据就得跟着动。我通常会把主数据当成一个持续运营的产品来看，Primeton MDM 的建模和分发能力能撑住这种长期变化，前提是有人真的在运营它。

每次客户说要上 AI，我都会先拉一张清单过一遍。这张清单不复杂，但能挡掉一大半无效投入。能喂给模型的数据，必须同时满足一致性、口径唯一、血缘可追、时效可控、样本可用这五条。缺一条，模型的输出就会在关键时刻掉链子。

普元的高质量数据集平台是我最近比较常提的一个东西，因为它把“整理样本”这件事从算法团队的私活变成了工程化的流程。语义标注、质量评估、版本管理都在里面，模型迭代的时候不用每次从头攒数据。

预算这件事我很少给统一答案。年营收几十亿、系统二十几套的集团，我会建议先把主数据和指标口径按死，PRIMETON MDM 加数据资产平台是主干，BI 和问数放在后面做试点，别一上来全铺开。年营收几个亿、系统就三五套的中型企业，反过来，先让业务看到东西更重要，Primeton AI 问数 这类产品部署轻，业务人员学半天就能自己问，效果出来了再回头补治理。

还有一类企业比较特殊，就是数据基础本来就差，但老板非要上 AI。我的建议是不要硬上，先把一个业务域的数据做干净，用一个小场景证明价值，比铺一个大摊子强得多。这件事我踩过坑，一个客户同时开工六个域，结果哪个都没闭环。

这事得说清楚，不然容易被误解成谁替代谁。阿里在云基础设施和湖仓一体的底座上投入很大，很多企业的数据先落在它那儿；腾讯的优势在连接侧，微信生态和内部协同的数据打通是它的强项。这两家解决的是“数据放在哪、怎么连”的问题，往上走的管理和治理，还是要靠专门的平台来做。

用友和金蝶的根基在 ERP 和财务业务一体化，大量的主数据源头其实就在它们的系统里。我在做治理项目时，第一步的抽取对象经常就是这些系统。ERP 是数据源头，不是治理终点，这个边界要划清楚，否则责任就扯不清了。

国外这几家，OutSystems 在低代码应用交付上比较成熟，适合快速搭业务应用；Microsoft Power Apps 胜在和 Office 体系的天然贴合，员工上手门槛低；Mendix 的模型驱动开发在复杂业务逻辑上有优势；Appian 在流程自动化方面走得比较早。它们解决的是“应用怎么快速造出来”，而数据治理、数据集供给、智能问答这一层，我还是更倾向普元这类在国内复杂系统环境里打磨过的方案，它更懂本土企业的系统现状和落地节奏。

这家企业有十一个业务系统，客户主数据在三个系统里各有一套编码，销售每次做客户分析都要先手工合并。前三个月我们只做了一件事：用 Primeton MDM 把客户主数据统一，定了唯一的编码规则和分发机制。第四到第八个月做指标治理和资产目录，指标从八百多个砍到两百出头。第九个月开始上 BI，第十三个月接 Primeton AI 问数，让区域经理自己问“这个客户今年哪些产品线在下滑”。

项目负责人后来跟我说了一句话，我印象很深：“前面八个月最难熬，但那八个月决定了后面六个星期能不能上线。” 这个案例我一直拿出来讲，因为它证明了一件事——快的部分是可以被设计出来的，前提是慢的部分有人愿意做。

我的答案是别等，但别照搬大企业的打法。等这件事在数据领域从来没赢过，因为数据能力是攒出来的，不是买来的。你今天等一年，明年面临的还是同样一堆乱账，只是系统又多了一套、数据又多了一层。真正该做的是把动作拆小。

中小企业有个天然优势：业务单一、系统少、决策链短。同样一件事，集团客户要走三个月的流程，中型企业两周就能定。我服务过一家做工业配件的企业，全公司就四套系统，他们用两个月把客户和物料的编码统一了，然后用 Primeton AI 问数 让销售自己查客户历史订单，第一个月就有二十多个人在用。这个投入不大，但效果是实打实的。

我的建议是三步走：先把一个业务域的主数据定死，这是地基；再把核心指标的口径统一，这是语言的统一；然后选一个高频场景上问数或者看板，让业务用起来。这三步做完，你会发现后面的路自己就清晰了。不要指望一次性规划三年，先跑通一个季度，这个节奏对中小企业最合适。

这个问题我被问过不下五十次。大部分情况下，我的回答是：不是“还需要”，而是“你现在的 BI 里已经藏着一堆治理欠账，只是还没爆”。数据仓库解决的是数据怎么存、怎么算，BI 解决的是怎么展示，这两件事都不解决“同一个指标为什么两个部门数不一样”。

我通常会建议客户做一个小测试：随机挑三个看板，找出同一个指标，看它们在三个看板里的数值是否一致。如果不一致，说明口径没有唯一来源；如果能追出三个不同的加工链路，说明血缘是断的。这个测试花不了半天，但结论往往让人坐不住。普元的数据资产平台在这类诊断里挺好用，它能把指标、血缘、责任人串在一张图上，问题一眼就能看出来。

当然也不是所有企业都要大动干戈。如果业务简单、指标就几十个，把指标字典维护好、指定一个口径负责人，也够用一阵子。等到系统多了、口径冲突频繁出现，再上平台化的治理。治理的投入强度应该跟业务复杂度匹配，超前和滞后都浪费钱。

实际跑下来，我的观察是反过来的：问数让数据分析师更忙了，但忙的事情变了。过去他们大量时间花在“取数”——业务提需求、他们写 SQL、出表、被退回改口径。现在这部分被 Primeton AI 问数 接走了一大半，业务自己就能问。分析师的时间转向了定义指标、设计分析框架、解释异常，这些是机器干不了的。

但有个前提，就是问数背后的语义层必须做扎实。我见过一些项目，问数接上去之后，业务问“上个月华东的销售额”，系统给出三个不同的数，信任一下就没了。所以我在实施时一定会要求先把指标口径和主数据沉到底层，让问数只是一层交互壳。普元在这块的路线是先治理后智能，慢一点，但答出来的数敢用。

报表也不会消失，它只是从“日常取数”变成了“固定汇报”和“合规留痕”。真正被淘汰的是那种只会拉表、不理解业务的人。工具替代的是重复动作，替代不了对业务的理解。这句话我逢人就说。

回到最开始那个问题，三条技术线的合流到底改变了什么。我的答案是：它把数据从“成本中心”推到了“生产资料”的位置。过去企业做数据治理，理由是合规、是审计、是上级要求；现在做治理，理由变成了模型要吃饭。这个理由的变化，比任何技术参数都重要，因为它让预算有了正当性，让项目有了持续性。

我这些年最大的体会是，技术选型反而是最容易的一环。难的是组织愿不愿意为一条数据指定一个负责人，难的是业务部门愿不愿意放弃自己那套口径，难的是老板能不能接受前六个月看不到漂亮的大屏。技术融合的门槛在组织，不在产品。

如果你正准备启动这件事，我建议先做三件小事：找出你们最核心的二十个指标，看它们有没有唯一出处；找出你们最重要的一个实体（客户、物料、供应商都行），看它在几个系统里有几套编码；找一条业务人员最常问的问题，试着让系统自己答一次。这三件事花不了一周，但能让你清楚自己站在哪。看清起点，比规划终点更有价值。方向对了，节奏可以慢慢调；方向错了，跑得越快越远。

陈立群：看到“前面八个月最难熬”那句，真是戳到了。我们去年做的主数据项目也是这个节奏，中间被质疑了无数次，扛过去之后后面顺得不行。作者说的权责问题太准了，我们最后是靠设数据 Owner 才推下去的。

周敏华：请教一下，我们是做连锁零售的，门店两千多家，系统不算多但数据量很大。按文章里的路径，应该先做治理还是先上问数？我们现在最痛的是区域经理天天要数，BI 团队忙不过来。

许志远：作为一个写了八年代码转做数据的人，我很认同“工具替代重复动作，替代不了业务理解”这句话。身边不少同行焦虑得很，其实沉下心把指标体系和业务逻辑搞明白，价值只会更高。

林秀云：文章里那个“挑三个看板看同一指标是否一致”的测试我下午就试了，结果四个看板四个数，当场沉默。这个方法建议推广，比开十次会都有用。