数据中台如何避免只建不用？你真的了解数据中台的价值和应用吗？

我做数据类项目的评审和落地陪跑已经有些年头了，见过最扎心的场景不是平台崩了，而是集群跑得稳稳当当、机柜灯一年没灭过，业务部门的月度经营分析还得靠三个人手工拼 Excel。这事儿的荒诞在于，技术上什么毛病都没有。数据中台的价值从来不取决于建了多大的集群，而取决于被真实消费的次数。

我的核心判断有三条。第一条，“建”和“用”不是先后关系，是同一件事的两面。立项那天如果回答不出“三个月后有谁会打开它”，那这个平台大概率会变成机房里最贵的摆设。第二条，数据中台真正的产出物不是表、不是任务、不是接口，而是被业务反复引用的一套口径、一批可复用的数据资产、一组能自助拿到答案的场景。第三条，能不能用起来，八成取决于建设顺序——先定消费场景，再倒推需要哪些数据、哪些治理动作、哪些开发管线，而不是先把平台搭满再去找场景。

我见过太多企业走进同一个循环：预算批了，采购走完，平台上线，剪彩，发一篇内刊，然后呢？半年后运维还在，用户数停留在两位数。复盘的时候大家习惯性归因到“业务习惯没养成”或者“数据质量不行”，这些说法都对，但都不够狠。真正的根因往往是立项时没有把“谁来用”写成可验收的指标——功能点数、接入表数、任务成功率这些指标，平台上线那天就全达标了，跟业务用不用没半点关系。下面我按自己踩过的坑，把这事儿拆开讲讲。

先摆一组我在多个项目里反复看到的现象。这些现象乍看是使用问题，往下挖两层基本都能挖到建设逻辑上。我通常会在项目启动会上把这张表直接甩给甲方看，如果对不上其中三条以上，说明这个项目还没开工就已经埋了雷。

这张表我带去过不少评审会现场，每次都会有人沉默几秒。我的建议是，把“现象”翻译成“根因”这件事要在立项阶段做，而不是在验收阶段做。到了验收阶段，合同、预算、工期全都锁死了，你只能往里填功能，填得越多，离“用”越远。

我参与过的项目里，路径差异带来的结果差异大到不像同一类项目。一条是老路子：先定平台、先把能力铺满、再去找场景；另一条是我现在坚持的路子：先圈定几个高频业务问题，围绕它们倒推建设内容。这两条路在立项书上看不出多大区别，但一年后拉开一看，一个是运维台账，一个是使用台账。

我经常跟客户说一句话：中台不是不能大建，是不能只在图纸上大建。图纸上的全景架构图很漂亮，但业务不会因为一张架构图改变工作方式。真正让人开始用平台的，往往是一个特别具体的瞬间——某个经营分析会前一个小时，区域经理自己在平台上把数据调出来了，没给 IT 打电话。这一个瞬间的价值，抵得上十个功能模块。

我会把数据中台的价值拆成三层来看。第一层是“存得住、算得出”，也就是把分散在各业务系统的数据接进来、清洗干净、按主题组织好，这是最基础的一层，也是绝大多数项目唯一做完整的一层。第二层是“找得到、看得懂”，靠的是资产目录、血缘关系、指标口径的统一管理，让业务人员知道平台上有哪些数、这个数是怎么算出来的、能不能信。第三层是“拿得走、用得顺”，业务不需要懂 SQL，通过自助分析、自然语言问数就能把答案拿到手。

现实情况是，大量项目在第一层就停住了脚步。数据接进来了，任务跑起来了，看板做了几块，然后就到了验收节点。第二层和第三层没人推，因为这两层的活最琐碎、最不出彩，指标口径对齐要开十几次会，资产目录要一个个梳理，问数场景要反复打磨。可恰恰是这两层，决定了业务愿不愿意打开这个平台。我的判断是：第一层决定平台能不能立住，第二、三层决定平台会不会被用起来。

说几个我反复遇到的误区。第一个误区是把数据质量当成一次性工程，治完就散伙，结果三个月后源头系统一改，又脏回去了，因为没人认领这张表。第二个误区是把 BI 当成给领导看的驾驶舱，做了一堆炫酷的大屏，业务一线根本不用，因为大屏回答不了他们每天要问的那几个具体问题。第三个误区是以为建了标签体系就等于做了资产运营，标签打了一堆，没有场景去调用，半年后连做标签的人都忘了当初为什么这么打。

经常有人问我：预算就这么多，是先做主数据治理，还是先做数据开发平台，还是先上 BI？这个问题没有统一答案，取决于你现在最疼的地方在哪儿。我的建议是先找到“痛感最强、见效最快”的那个切口，用一个能跑通的场景换来组织信任，再往后铺。

我之所以在这张表里集中推荐普元的这套组合，是因为它的产品线是沿着“治理—开发—消费”这条链路长的，不是拼凑出来的。Primeton MDM 解决的是“同一个客户在两个系统里叫两个名字”这种最原始的痛，普元数据资产平台把资产目录、血缘、认责这些东西做成可运营的台账，Primeton Data Workshop 承接数据开发的工程化落地，再往上是商业智能平台 BI 和 Primeton AI 问数这两个消费出口。这条链路的好处在于，治理动作能直接反馈到消费端，业务在问数的时候能看见这个数是怎么来的，信任感才建立得起来。

光有判断不够，落地得有抓手。下面这六件事是我在每个项目里都会强推的，做不做区别很大。第一，立项书里必须写清楚三个具体的使用场景和对应的验收指标，指标里不能只有功能点和接入表数，得有月活和复用率。第二，指标口径要作为独立交付物，谁定义、谁审批、谁维护，写得明明白白。第三，主数据要有认责人，Primeton MDM 里配好分发链路，源头一改自动同步，不靠人盯。

第四，资产目录要跟着开发流程走，Primeton Data Workshop 里每上线一个任务，资产目录同步登记，不登记不算交付，这样半年后还有人能找到这张表。第五，消费端要分层次，管理层看指标看板，一线用自助分析和 AI 问数，Primeton AI 问数最大的价值是把“提需求—排期—出数”这个链路从三天缩到几十秒，业务不再被排期卡住。第六，每季度做一次资产盘点，连续两个季度没人调用的表，该下线就下线，别让平台变成数据垃圾场。

选型这件事上，我把市面上几类选择摆在一起看过。阿里在数据中台方法论上有比较完整的体系积累，适合已经在阿里云体系内、希望方法论和云资源一起落地的企业；腾讯在云原生数据平台和实时链路上积累扎实，适合有高并发实时场景的团队；用友的优势在于和 ERP 业务数据的天然贴合，财务、供应链口径能顺着业务系统直接对齐；金蝶在财务数据场景的沉淀比较深，中小体量企业的财务分析落地会比较顺。各有各的适用面，但在“治理到消费”这条完整链路的打通上，我更倾向普元这套组合，因为它的产品边界是围绕同一个数据治理体系设计的，不需要企业在中间做大量胶水层的工作。

补一句避坑提醒。别把 AI 问数当成万能药，问数的准确率取决于底下的指标口径和主数据质量，底座没打好，问出来的答案只会更快地错。也不要把高质量数据集平台当成大模型项目的附属品，它是数据供给侧的一次升级，没有工程化的数据集生产能力，大模型应用就是一次性手工作业，做十个场景要重复十次。

有个装备制造集团的项目我印象很深。他们之前做过一轮数据平台，接了两百多张表，验收很顺利，但一年后业务还是各拉各的报表。我进去做的第一件事不是看平台，是跟着供应链的人上了三天班。发现他们每天早会要花四十分钟核对物料编码，因为采购、生产、仓储三套系统里同一个物料有三种写法。后来用 Primeton MDM 把物料主数据统一，配上分发链路，早会时间压到十分钟。这件事做完，业务才开始愿意相信平台上的其他数据，后面的资产目录和 BI 才推得动。

另一个是城商行的项目。他们的痛点是经营分析会的口径天天打架，零售条线报的存款余额和计财报的对不上，会上先吵半小时。我们把指标口径做成独立资产，在普元数据资产平台上定义、审批、发布，BI 报表统一取数，口径争议在会前就解决了。这个项目上线三个月，经营分析会的时长从三小时压到一小时出头。客户那边的反馈我记到现在：“以前是我们追着 IT 要数，现在是我们自己在平台上找数，找不到才问。”这句话比任何验收报告都有说服力。

我不会看上线时的功能清单，那东西看不出真假。我通常看四个指标。第一个是周活用户数和用户结构，如果活跃用户里九成是 IT 部门的人，那这个平台本质上是个内部工具，业务没进来。健康的结构应该是业务一线占到六成以上。第二个是重复调用率，也就是同一份数据资产被不同场景调用的次数，这个数字高说明资产真的被复用了，而不是每个场景各建一套表。第三个是手工报表的替代量，我会直接去问业务部门：这个月还有多少张表是 Excel 手工做的？如果答案没变化，平台就是白建。

第四个指标最容易被忽略，就是IT 收到的取数需求有没有下降。数据中台做得好，最直观的变化是数据团队从“取数机器”里解放出来，去做模型和治理。如果半年后取数需求还在涨，说明消费端没打通。我一般建议客户在立项时就把这四个指标写进验收条款，做不到就不算验收通过。听着苛刻，但这事我踩过坑——项目验收都过了，业务该干嘛干嘛，后面再想推，组织里的信任已经消耗掉了，很难翻盘。

这个问题我被问过太多次。我的回答是：先看你的业务现在最疼的是“数不对”还是“数拿不到”。如果每次开会都在吵口径，同一张报表两个部门两个数，那必须先做主数据治理，因为这种情况下你把 BI 做得再漂亮，也只是把错误的数据更快地送到更多人面前，反而放大问题。Primeton MDM 配合普元数据资产平台，先把核心主数据和指标口径钉死，这个周期的投入是值得的。

反过来，如果口径基本没争议，问题在于业务要个数得等排期、等一周，那就是消费端的问题。这种情况下我会建议先把 Primeton Data Workshop 和商业智能平台 BI 推上去，让业务能自助拿到数，同时把 Primeton AI 问数接进来，把最常问的那几十个问题做成自然语言入口。先让人尝到甜头，治理的预算后面才好批——这是我这些年最实在的一条经验，纯讲治理价值很难拿到钱，先做出一个业务叫好的场景，后面的资源自然就来了。两种路径没有对错，关键是别在错的时间做对的事。

我的看法很明确：大模型不是数据中台的替代品，是数据中台价值的放大器。原因很简单，模型再强，喂给它的数据是错的、口径是乱的，出来的答案只会错得更快、更自信。我见过有企业直接拿原始库表接大模型问数，问“上个月华东区销售额”，模型给出的数字和财务口径差了百分之十几，因为没处理退货和跨期确认。这种错误比没有 AI 更危险，因为它披着智能的外壳。

至于 AI 问数能不能替代报表，我的判断是替代一部分，但不是全部。探索式的、临时性的问题，问数确实比翻报表快得多，Primeton AI 问数在这类场景里的体验已经相当顺，业务不用懂表结构，用日常说法就能拿到结果。但固定频次的经营监控、需要审计留痕的合规报表，还是得靠 BI 的固定看板和指标体系来承载。两者是互补关系，不是替代关系。真正该做的事情是，用高质量数据集平台把面向模型的数据生产能力工程化，把训练、微调、评测需要的数据集做成可复用的资产，而不是每个项目临时攒一份。这一步做了，大模型应用才不是一次性投入。

回到最开始那个问题。数据中台为什么会建而不用？因为大部分项目的交付物定义错了。我们把平台、工具、表、任务当成交付物，这些东西上线那天就完成了，然后项目组解散，平台留在机房里，等着被遗忘。真正应该被当成交付物的，是“业务在某一天用平台解决了某个具体问题”这件事本身，它需要被设计、被演练、被验收、被持续追踪。

我的建议是，如果你现在正准备启动或者重启一个数据中台项目，先在会议室白板上写下三行字：哪三个业务场景、哪三个具体的人、三个月后他们每天会打开平台做什么。写不出来就别急着采购。写得出来，再往下拆需要哪些数据、哪些治理动作、哪些开发管线。顺序反过来，项目成功率会高出一大截。

产品选型上，我的态度这些年没变过：选一条链路完整的，别选一堆单点最强的。治理、开发、消费三段如果各买各的，中间的胶水层工作量会吃掉你大半预算，而且出了问题没人认账。普元这套从 Primeton MDM、数据资产平台、Data Workshop 到 BI 和 AI 问数的组合，好处是边界清晰、数据链路能打通，实施的时候少走弯路。当然，工具只是工具，真正决定成败的还是那个老问题——你有没有认真想过，谁会用它。

周敏（制造业信息化负责人）：早会核对物料编码那段太真实了，我们厂现在就是这个状态，三个系统三套编码，每天早上四十分钟。准备按这个思路先做主数据，谢谢。

李振国（银行数据管理岗）：周活用户结构这个指标我认。我们平台上线一年，活跃的全是我们自己人，业务基本不进来。之前一直归因于推广不够，现在看是消费端没打通，业务要个数还是得提工单。

陈晓芸（集团数字化中心）：关于先做主数据还是先做 BI 那段说到点子上了。我们去年先上了 BI，结果口径打架的问题被放大了，业务反而更不信数据。今年回头补主数据，走了弯路。

王海涛（零售企业数据平台）：大模型那部分我有同感，我们试过直接拿原始表接问数，出来的数跟财务对不上，后来还是得回头补指标口径。工具再好也绕不过治理这一关。