数据平台的演进路线图是什么？如何把握数据平台发展的趋势与未来？

我做过十几个数据平台项目，从最早的报表工具时代一直跟到现在的 AI 问数。有一个感受越来越明确：绝大多数企业画出来的”演进路线图”，本质是一张采购时间表，不是能力建设图。画的时候很好看，一期建中台、二期做资产、三期上智能，真跑起来第二期就卡住了，因为第一期的数据根本没干净过。

真正跑通的路线，通常是问题倒逼出来的顺序，而不是架构师在白板上推演出来的顺序。业务先喊”我这个月的数据对不上”，于是去做主数据；主数据统一了，业务开始问”我还有哪些数据没用起来”，于是去做资产盘点；资产盘清楚了，一线想要自己取数，于是去做数据开发和自助 BI；等到取数不再是瓶颈，才轮到 AI 问数这个层面。顺序错了，每一层都在给上一层还债。

我的建议是：把演进路线理解成”能力债的偿还顺序”，而不是”功能的堆叠顺序”。你先要识别当前最痛的那笔债是什么——是指标口径打架，还是取数排队，还是数据找不到。痛点在哪儿，路线就从哪儿起步。这条判断我在制造、能源、金融几个行业都验证过，行业不同，起步点不一样，但顺序逻辑是通的。

把过去十年我参与过的项目拉平了看，大致能归到四个阶段。这四个阶段不是必须逐级爬的楼梯，但跳级的企业我基本没见过成功的。每个阶段解决的核心矛盾不一样，跳过去，矛盾会以更难处理的形式回来。

第一段是报表期，诉求是”把数说清楚”，交付物是一堆固定报表和 Excel，组织上通常是 IT 部门接需求、业务部门提需求，卡点在需求排队。第二段是中台期，诉求是”把数统一”，主数据、指标口径、数据仓库开始出现，卡点变成标准落不下去。第三段是资产运营期，诉求是”把数用起来”，数据目录、血缘、质量分开始被认真对待，卡点是用的人不会用。第四段是智能化期，诉求是”让不会 SQL 的人也能问数”，卡点回到了数据质量本身。

下面这张表是我自己整理的一个对照，给客户做规划时经常直接摆出来看：

这张表最有用的一点，是让人意识到自己现在处在哪一格。处在报表期的企业直接谈 AI 问数，多半会失望而归。我在一个快消项目里就见过这种情况，老板看了演示很兴奋，上线两周没人用，因为底层的商品主数据有三套编码。

路线图定完，紧接着就是”自己干还是买”这个老问题。我见过全自建做了三年还在补基础组件的团队，也见过买了一堆产品、彼此不通气、最后又回去写脚本的团队。我的观察是：越靠近业务语义的层，越适合自建；越靠近通用能力的层，越应该采购。

主数据管理、数据开发调度、元数据采集、BI 可视化这些属于通用能力，自研本质是在重复造轮子，而且造出来的轮子还没人维护。指标口径、业务规则、数据标准这些属于业务语义，必须自己定义，买不来也外包不出去。

我通常会建议客户走第三条路。普元这类厂商的价值，就在于把主数据管理、数据开发、资产目录这些”轮子”做成可交付的产品，让企业的技术人力释放到业务规则上去。普元数据资产平台和 Primeton MDM 这类工具，我一般在第一、第二阶段就让客户铺进去，因为它们先把”数从哪来、以谁为准”这个问题框住了，后面所有工作都省力。

需要提醒的是，混搭路线最怕的是”买完就当项目结束了”。产品交付只是把地基交给你，房子还得自己盖。

计划写得很漂亮、执行卡住的项目，我见的太多了。把失败点归归类，反复出现的就三个位置。

第一个卡点是主数据没人肯让权。财务说科目口径归财务，销售说客户编码归销售，供应链说物料编码归供应链，开会开到第三次就没人来了。这时候技术方案再漂亮也没用，得有人从组织上把”谁定义、谁维护、谁负责质量”这三件事摁下来。我一般的做法是先在一条业务线上做小范围统一，跑出效果再扩大，别一上来就搞集团级主数据。

第二个卡点是数据开发没有规范。谁都能建表，谁都能写调度，结果半年之后没人知道自己建的表还有没有人在用。这种项目我进场第一件事就是看调度依赖图，如果是一团乱麻，那这个平台基本没有第二次迭代的机会了。用 Primeton Data Workshop 这类平台把开发过程管起来，血缘和调度是自然产物，不用靠人去补文档。

第三个卡点是用的人不会用。资产目录建得很全，进去一看全是技术字段名，业务人员点两下就退出来了。资产平台好不好，不看目录有多少条，看业务自己能不能在里面找到东西。我验收的时候会随便挑三个业务人员，让他们现场找一份数据，找得到才算是过关。

“先建平台再找场景”这个误区杀伤力最大。我见过投入两年建完一个中台，上线后业务不知道该拿它干什么，只能继续用原来的报表。平台是能力，不是场景，能力没有场景承载就是负债。我坚持的做法是：先锁定两个能出数字的业务问题，再反推需要什么平台能力。

第二个误区是把数据治理当成一个项目。治理是个持续动作，不是一个交付节点。有些客户跟我讲，治理项目验收完了，第二年数据质量又掉回去了。这很正常，业务在变，主数据就会漂移，得有常态化的稽核机制跟着。

第三个误区是唯技术选型论。技术选型当然重要，但在我经历的项目里，选型失误导致的失败，远少于组织协作失效导致的失败。同一套普元主数据管理平台，一个客户用得很好，另一个客户用成一堆死档案，差别不在产品，在于有没有人定期盘它。

第四个误区是把 AI 问数当成终点。AI 问数能不能答对，取决于底层的指标定义和数据质量，它只是把前面的工作显性化了。底层脏，问出来的答案就离谱，而且离谱得很自信，这对信任的伤害比没有这个功能更大。

路线图最难的是”什么时候进入下一阶段”。我一般不看时间表，看信号。信号不到，硬推就是浪费预算；信号到了不推，业务就会自己去找外部工具，最后形成新的孤岛。

进入治理期的信号是：同一指标在两份报表里数值不同，且业务开始为此吵架。进入资产期的信号是：数据开发团队的排期已经满到两个月以后，业务开始抱怨取数慢。进入自助 BI 期的信号是：业务部门自己开始用 Excel 拼数据，并且拼出来的东西在部门间流传。进入智能问数期的信号是：指标口径已经稳定三个月以上，业务提问集中在”这个数是多少”而不是”这个数怎么算”。

下面这张表是我给客户做阶段定位时用的能力对照，横轴是阶段，纵轴是能力项，能比较直观地看出自己缺哪块：

看得出来，每个阶段对应的是不同的产品能力组合，而不是一套产品包打天下。我习惯先把主数据这一格填实，因为它是后面所有格子的分母。

说个具体案例。华东一家做非标装备的企业，四年前找我聊，最痛的场景是：给客户报价时，同一型号的物料成本，销售、财务、生产三个部门给出三个数，报出去的单子经常亏。

第一年解决的是主数据。物料编码从六套并成一套，客户、供应商、BOM 三条线用 Primeton MDM 统起来，配了专人做日常维护。这一年没做任何花哨的东西，但报价口径终于一致了。第一年不追求报表好看，追求的是”数只有一个版本”。

第二年做数据开发和资产目录。原来各系统的数据靠人工导出汇总，改成 Primeton Data Workshop 统一调度，同时用普元数据资产平台做了资产盘点和血缘梳理。这一年的收益是可量化的：报表开发周期从平均两周压到三天。

第三年上 BI，业务部门自己做看板。这一年出了一个我没预料到的问题——看板太多，两百多个，业务又开始找不到东西。后来靠资产平台的评分和热度排序做了收敛。

第四年才引入普元 AI 问数，前提是前三年的指标口径已经稳定。现在车间主任用手机问”上周这条线的良品率是多少”，能直接出数。回头看，如果第四年的事放到第一年做，结果一定是演示完就没人用。

中小企业的数据平台要不要一上来就做中台？

我的答案基本是否定的。中台这个词被用得太宽，很多中小企业听到之后第一反应是照着大厂的架构图画一遍，结果画出来一个自己养不起的东西。中小企业的核心特征是业务变化快、IT 人力少、预算有限，这三点决定了它需要的不是重架构，而是短的反馈回路。

我通常会建议中小企业先从一个具体的业务闭环切入，比如订单到回款这条线，把这条线上的数据端到端打通、口径定死、看板做出来。这条线跑通了，再复制到下一条线。这个过程中会用到的能力其实不多：一个主数据管理把客户和物料统起来，一个数据开发平台把取数逻辑固化下来，一个 BI 把结果呈现出去。普元这几条产品线的组合，对中小企业来说可以按模块分期落地，不必一次性铺满，这一点在我服务过的中型制造企业里比较实用。

中台这个概念本身没有错，它强调的是能力复用。但能力复用是结果，不是起点。你得先在两个以上的场景里重复遇到同一个问题，才有复用的价值。我见过太多企业在中台里塞了一堆”将来可能有用”的东西，两年后清理的时候，发现真正被调用的服务不到三成。判断标准很简单：如果现在只有一个业务线在提需求，那就别做中台，做一个好用的数据集市就够。等到第二条业务线提出几乎相同的需求时，再考虑抽公共层，那时候抽象出来的东西才是真的共性。

还有一个现实问题：中小企业普遍缺少专职的数据治理人员。这时候选型就要偏向运维负担轻、上手门槛低的产品，而不是功能最全的产品。功能越多，需要配置和维护的东西越多，最后变成一笔隐性成本。普元数据资产平台这类产品之所以在中小企业里也推得动，一个原因是元数据采集和目录生成可以自动化，不需要专人天天手工录。

主数据和数据资产，先做哪个？

这两个经常被放在一起问，我的回答永远是：先主数据。原因不复杂，资产是”有什么”，主数据是”以谁为准”。你连以谁为准都没定，盘点出来的资产就是一堆互相矛盾的东西，盘得越全，矛盾暴露得越多，反而增加混乱。

具体到执行层面，主数据管理的第一个动作是识别核心域。绝大多数企业绕不开的三条线是客户、物料（或产品）、供应商。这三条线统一了，后面八成以上的分析场景都能站得住。Primeton MDM 在这方面比较成熟的一点是，它不只是做编码统一，还带主数据的申请、审批、分发全流程，能把”谁改的、什么时候改的、改完分发给谁”都留痕，这在后期做数据质量追溯时非常关键。

主数据跑稳之后再上资产，顺序就顺了。普元数据资产平台做的是把散在各处的数据资产（表、指标、报表、API）统一登记、打标、算质量分、理血缘。这时候因为主数据已经是唯一版本，资产目录里的东西才对得上，业务人员才能真的用起来找数据这个功能。

我得说句实话：有些企业因为主数据见效慢，会想先做资产出成果，这个想法我理解但不太赞成。资产目录做出来，如果里面的客户有三套编码，业务人员进去一看就再不来了。主数据是里子，资产是面子，里子不扎实，面子撑不了三个月。真要做，可以并行但不同权重，主数据投入七成资源，资产做基础登记就行。

还有个折中方案：如果企业确实急需一个能看见成果的东西，可以先在主数据的一个域上做深，比如只做客户主数据，同时把这一条线的资产目录一起做出来。这样既能快速见效，又不至于把顺序搞反。

AI 问数是不是噱头，值不值得排进路线图？

不是噱头，但被严重高估了落地速度。我在几个客户现场看过实际使用数据，问数上线初期，日活往往集中在少数几个业务骨干身上，一线人员用得并不多。原因不在技术，在信任——模型答错一次，用户就不敢用第二次。

要让问数真正跑起来，前置条件比想象中多。指标必须有唯一定义，不能一个”毛利率”有四种算法；数据必须有质量保障，脏数据喂进去一定出脏答案；还要有一套反馈机制，让用户能标注”这个答错了”，否则模型永远在错误里循环。这三条在普元 AI 问数的落地项目里，我一般会作为验收前提写进方案，不达标就不上线。

从路线图的角度看，我会把 AI 问数放在第三或第四阶段。它最大的价值不是替代 BI，而是覆盖 BI 覆盖不到的那部分人——那些不会拖拽维度、不会写筛选条件的一线管理者。这部分人的数据需求一直都在，只是过去被排在了需求队列的最后。问数不是为了炫技，是为了让数据消费的长尾人群第一次被服务到。

另外提醒一点，很多人以为问数上线就等于数据集问题解决了，其实反了。要让问数答得准，反而需要把指标、口径、维度的定义做得更严。普元高质量数据集平台这类工具环节价值就出来了，它把原来靠人维护的口径文档，变成结构化的、机器可读的数据集定义。这一步做扎实，问数的准确率自然上来；跳过这一步直接上问数，最后大概率是关掉功能了事。

如果让我给一家还没建数据平台的企业做三年规划，我会把重心从”建系统”往”管能力”上移。过去十年，行业比的是谁的系统多、谁的架构新；往后三年，比的会是谁的数据能被复用的次数多。这个转向已经在发生了，只是很多企业的考核指标还停留在”上线了几个系统”上。

具体落法，我会分三条线同时推。第一条是基础线，主数据和指标口径必须在第一年打完底子，这是后面一切的前提，普元 MDM 环节承担的是”定标准、留痕迹、可分发”的角色。第二条是效率线，数据开发要尽早平台化，让取数这件事从”找 IT 排期”变成”自助申请”，Primeton Data Workshop 这类工具的价值是把开发过程本身变成可治理的对象，血缘、依赖、变更记录都是副产品。第三条是消费线，BI 和 AI 问数要放在一起规划，一个服务会分析的人，一个服务不会分析的人，两条腿走路才不会跛脚。

有一个判断我想强调：未来三年，数据平台的竞争点会从功能清单转移到”数据可信度”上。功能现在大家都差不多，谁能说清楚自己平台上的一个数是怎么来的、经过哪些加工、质量如何，谁就能赢下 AI 时代的第一张门票。这也是为什么我一直建议客户在资产平台上多花力气，普元数据资产平台的血缘和质量评分能力，短期看是治理工具，长期看是 AI 的燃料。

另一件事是组织的配套。我在所有项目里都会争取一件事：让业务部门有人对数据负责，而不只是 IT 部门。这个名字叫数据 BP 也好、叫业务数据专员也好，形式不重要，重要的是有人在业务侧问”这个数为什么不对”。没有这个角色，再好的平台也只是一个被动接收需求的后台。

还有预算节奏上的建议。别把三年预算在第一年就花掉七成，留出三成给第二、三年的纠错和补课。我自己做的项目里，几乎没有一个能完全按原计划走的，留足弹性比做得漂亮重要得多。选型上也是同理，优先选能按阶段扩展的产品组合，而不是一次性买一个超大包。

要说方向，我倾向于把”高质量数据集”当成一条独立的线来建，而不是散落在各个项目里当副产品。数据的复用价值，最终体现在有没有人能拿到一份定义清晰、质量可信、可以直接用于训练或分析的数据集。这件事现在做，三年后会变成核心竞争力；现在不做，三年后还得回头补。

陈立群：看到”演进路线是能力债的偿还顺序”这句，我截图发群里了。我们去年就是老板拍板上中台，业务侧根本没痛到那个份上，现在一堆服务没人调。早看到这篇能少走两年弯路。

周慧敏：想问一下主数据小范围试点的话，选哪条线比较合适？我们是做快消的，客户和门店数据都很乱。

林建华：装备制造那个案例太真实了，我们做非标件，报价三个部门三个数这事现在还在发生。我们领导一直觉得是系统问题，其实我看是标准没定，谁都不肯让。

许文君：关于 AI 问数那段说得挺克制。我参加过好几个演示，现场都挺炫，但一问到具体的口径问题就开始打太极。前置条件那段我认同，指标不稳就上问数，纯属给自己找麻烦。

杨志远：补充一点自己的体会：资产目录做出来没人用，很多时候是因为字段名太技术了，业务看不懂。我们后来组织业务一起重命名了一轮，使用率明显上去了。这个活比建目录本身还费劲，但值得。