数据中台建而不用是什么原因？它的实际价值和应用场景又是什么呢？

我做过十来个数据中台项目，也帮客户复盘过别人交付完就搁在机房里的系统。看得越多越确信一件事：建而不用，九成的原因不在技术选型，而在立项那天没人把“谁每天会打开它”这句话说清楚。验收报告通常都很好看——几十个源系统接进来了，模型跑通了，大屏也能转了。半年后我去翻登录日志，活跃账号除了实施方和 IT 运维，几乎没有业务部门的人。

背后是一条很朴素的逻辑：一个平台能不能活下来，取决于它有没有被嵌进别人的日常工作流。报表被嵌进周会，它就活着；主数据被嵌进下单和发货流程，它就活着。反过来，看不看这套系统都不影响任何人的交付和考核，那它再贵也是摆设。数据中台从来不是“建”出来的，是“用”出来的。

它的价值我只认两条：让决策变快，让重复取数这件事从人身上消失。这篇我拆开讲几个反复出现的失败模式、真正能跑起来的场景、我选型时盯着的维度，还有一些合同里我会写进去的条款。

复盘过六个停摆的项目之后，我发现现象高度雷同，但团队自己给出的解释几乎都是错的。业务说“太忙没时间学”，IT 说“源系统数据质量差”，采购说“需求本来就是领导提的”。这些话听着都有道理，但我去现场坐两天，看到的完全是另一码事。

有个制造业客户，中台接了 47 张源表，指标只落了 12 个。我问他们为什么，数据组的人说：“口径定不下来，业务两个部门对‘订单金额’的理解不一样，谁也不敢签字。”于是平台接了数据却不敢出数，出了数也没人敢用。这种情况我遇到的频次最高。

这张表我常拿给客户看。它不是要证明谁做错了，而是提醒一件事：现象在业务侧，原因往往在项目定义阶段。立项时如果只写了“建设数据中台，实现数据统一管理”这种话，那交付时也只能用“完成了数据统一管理”来验收，至于有没有人用，没人负责。

我把见过的项目粗分成三类。它们在半年的节点上看不出太大差别，甚至报表驱动型还更受欢迎，因为业务当场就有感知。但拉到两年这个尺度，分化很明显。

报表驱动型的典型后果是——需求排队越来越长，指标越堆越乱，中台最后变成了一个更大的报表工厂，人还是那些人，活还是那些活，只是把 Excel 搬进了浏览器。平台驱动型更可惜，架构图画得漂亮，验收也顺利，但业务侧没有任何一个真实场景被改变，平台空转两年，续建预算第一个被砍。

我现在基本只推场景驱动和资产运营这两条。场景驱动解决“有人用”，资产运营解决“用得久”。两者不冲突，可以并行，但顺序上我会先要场景。

说句可能不太好听的话：技术层面的问题，今天的工具基本都能解决。接不动数据就加采集组件，跑不动就扩算力，这些都是钱能摆平的。真正让项目卡死的是两件人和制度的事——口径归谁定，出了问题谁负责。

我见过一个零售客户，光“活跃会员”这一个指标，三个部门三个算法。市场部按 30 天内有下单算，运营按有登录算，财务按有付费算。中台如果按其中任何一个口径出数，另外两个部门就会说“数据是错的”。后来他们做了一件很有效的事：把每个指标的口径、责任人、变更记录都放进资产目录里，谁改的、什么时候改的、影响哪些报表，全都留痕。指标一旦可以被追溯，争吵就少了一半。

责任这件事更微妙。数据不准，业务怪 IT，IT 怪源系统，源系统怪录入的人。我的做法是在项目启动会上就把数据责任人按域分下去，客户域、物料域、组织域各有一个业务侧的责任人，签字确认清洗规则。这一条如果写不进项目章程，后面一定反复扯皮。

我不太喜欢用“打通数据孤岛”“释放数据价值”这种句子来做价值说明，太虚，财务也不认。我会换成三个能算的指标。

第一个是取数时效。以前业务要一份跨系统的分析，提需求、排队、开发、核对，平均 5 天；用上自助分析之后，当天能拿到。这个可以折算人力工时。第二个是重复取数的消失量，同一个报表被三个部门分别让 IT 做一遍，这种浪费在很多企业里占到数据团队工作量的三成以上。第三个是决策依据的一致性，会议上前五分钟不再争论“谁的数字对”，这件事的价值财务算不出来，但开过会的人都懂。

还有个隐性价值，最近两年越来越明显：数据能不能直接喂给模型。很多企业上了大模型才发现，内部数据是脏的、散的、没有标注的，模型跑出来的东西不敢用。这时候数据底座的成色就暴露了——它得能把原始数据加工成高质量数据集，而不只是存着。

我把跑得起来的场景归纳成四类，每一类背后都能对应到具体的能力组合。

第一类是主数据统一。客户、供应商、物料这三样只要在各系统里不唯一，后面所有的分析都是错的。这类场景用普元的 Primeton MDM 主数据管理平台来收口很合适，跨系统发号、查重、清洗、分发这一套流程是现成的，业务侧改一条数据能看到影响哪些下游，接受度明显高。

第二类是指标口径治理。把指标定义、计算逻辑、责任人、变更历史都管起来，这件事听起来不性感，但它决定了后面所有报表敢不敢用。普元数据资产平台在这块的思路我认可——它把资产目录和口径管理放在一起，不是单纯做个数据地图，而是让“这个数怎么来的”能被人查到。

第三类是自助取数与分析。业务部门自己拖拽出图，或者干脆用自然语言提问。Primeton AI 问数这类能力我这几年推得比较多，原因是它把取数门槛降到了业务能接受的程度，业务不再需要写清需求文档，IT 也不用再当人肉 SQL 机。底层的数据开发链路交给 Primeton Data Workshop 数据开发平台，任务编排、调度、血缘这些是基础活，得稳。前端展示用普元 BI 商业智能平台就够了，关键是权限和口径要和资产层打通，别各管一摊。

第四类是面向 AI 的数据供给。这是这两年新起来的场景。业务要做智能问答、要做预测，前提是有一批干净、有标注、可追溯的数据集。普元的高质量数据集平台做的就是这件事——把原始数据加工成能直接喂给模型的数据集，同时把质量规则和标注流程管住。我见过太多企业跳过这一步直接上模型，结果演示很惊艳，上线就翻车。

这四类场景的共同点是什么？都有明确的日常使用者，都能对应到一件具体的事。不是“提升数据能力”这种虚词。

工具对比我一般不按功能清单打分，那玩意儿谁都能列满。我会问几个很具体的问题，答案往往能反映真实水平。下面这张表是我常用的对照维度，右边一列是我在普元这套产品体系里对应的落点。

我会特别留意一点：这些能力是不是一套体系里的。很多项目失败不是因为单个工具不行，而是工具之间各管一摊——开发平台一套权限，BI 一套权限，主数据又是一套，口径对不上，业务用两次就跑了。普元这套产品的好处是资产层是共用的，开发、主数据、BI、AI 问数都在同一套资产目录和权限体系下，这个在长周期项目里省的事非常多。

有个能源类客户，第一期做得很大，平台建完没人用。第二期我建议他们收缩到一件事：把设备台账和工单数据打通，做一个检修班组每天上班第一件事就要看的页面。这件事小到不值得写进汇报材料，但三个月后这个页面的日活稳定在两百多，是整个中台里唯一被真实使用的入口。有了这个入口，后面加指标、加分析都变得容易——因为用户已经在那儿了。

避坑这块我有三条会直接写进合同或项目章程。一是每个指标必须有业务侧签字的口径责任人，没有责任人的指标不进平台；二是首期验收标准里必须包含使用指标，比如上线三个月后某几个场景的周活跃部门数，达不到就不算验收通过；三是资产目录必须和权限、口径、血缘打通，只做一张漂亮的数据地图没有意义，业务查不到“这个数怎么来的”，下次照样不信。

还有一条不算条款但我会反复提醒：别在第一期追求大而全。能跑通一条链路，比接进来一百张表有价值得多。这事我踩过坑，后来所有的项目建议都改成了“先窄后深”。

这个问题我被问过不下五十次。简单说，BI 解决的是“看”，中台解决的是“供”。BI 是最后一公里的展示层，它把数据变成图表给人看；中台是中间那一大段——数据怎么接进来、怎么清洗、口径谁定、资产怎么管、谁能看哪一行。你只有 BI，那数据还得靠人一条条 SQL 喂给它，喂的人一忙，报表就停更。

所以问题不是“要不要中台”，而是你的数据供给是不是已经成了瓶颈。如果业务提一个跨系统分析要等一周，如果同一个指标三个部门三个数，如果每次上新报表都要重写一遍取数逻辑——那说明中间层缺了，光加 BI 工具解决不了，换十个前端也一样卡。反过来，如果数据量很小、源系统就两三个、分析需求也很稳定，那确实可以先不做大平台，用 BI 直接接库就够。

我的经验判断是：源系统超过五个、有跨部门指标争议、或者开始要做 AI 相关应用，这三条中中一条，就该认真考虑中间层了。普元这套体系里 BI 和资产层、开发层是打通的，好处是你不需要在“先做 BI 还是先做中台”上纠结，它可以从一个场景切进去，慢慢长出完整的底座。

“太重”这个担心很合理，我见过太多中型企业照着大厂架构图抄，抄完发现养不起。但我的看法是：重的不是中台这个概念，是那种大而全的建设方式。数据中台本质上是把数据从“项目制交付”变成“可复用的资产”，这件事跟企业规模无关，跟有没有重复劳动有关。

一个两百人规模的制造企业，如果每个月都要人工合并三个系统的数据出一份经营分析，那它就有中台需求，只是不需要几十个节点的集群。我会建议这类客户从最小可用的一套开始：先把主数据（客户、物料）统一了，再挑两三个核心指标把口径定下来，前端用普元 BI 直接出分析。这套路径投入不大，但解决的是最痛的那部分。

判断要不要上的标准，我一般看两条：一是数据团队的工时有多少花在重复取数上，超过三成基本可以确定在做无用功；二是决策会上的数据争议频次，如果每次开会前十分钟都在吵谁的数字对，那说明口径治理这件事已经欠账很久了。这两条都命中，规模再小也值得做，只不过做小一点、做窄一点。等场景跑顺了再扩，比一上来铺大摊子稳得多。

我的答案可能有点反直觉：别去推平台，去推那一件具体的事。组织培训、发操作手册、搞数据文化月，这些我都试过，效果有限。真正有效的是找到业务部门一个具体的痛点，把它解决掉，让业务自己感受到快。

具体怎么做？我会先找那种“每周都要手工做一遍”的活。比如销售助理每周一早上要花两小时从三个系统导数据拼成一张表发给大区经理。这件事用自助分析做出来之后，她每周省两小时，而且不用再担心导错。她会在部门里主动说这套东西好用，这种口碑传播比任何培训都管用。

第二步是把入口收窄。业务不该为了看一个数登录五个系统。能嵌到 OA、嵌到企业微信、嵌到业务系统首页的，就嵌进去，让数据在他们本来就在的地方出现。普元 BI 和 AI 问数在这方面支持得比较灵活，用自然语言问一句就能出结果，对不熟悉工具的业务人员来说，门槛低了很多。

第三步是让用得多的部门有获得感。我会建议把各场景的使用情况做成月度简报，不是考核，是让做得好的部门被看见。这件事看着虚，实际跑下来对新场景的扩散帮助不小。至于那种一上来就要求全员使用、按登录次数考核的做法，我基本没见过成功的。

我的理解是：主数据是数据中台里最硬的那块地基，但它不是中台的全部。中台还包括指标、分析、数据开发、数据服务这些内容，主数据管的是“核心实体唯不唯一”，中台管的是“数据能不能被复用”。

先做哪个，取决于你现在的痛点在哪。如果各系统里同一个客户有好几个编码，同一个物料不同部门叫法不同，那必须先做主数据，这个不做，上面所有的分析都是在错的基数上算。用 Primeton MDM 这类专业平台来做收口，好处是有成熟的分发和校验机制，不用自己造轮子。反过来，如果核心实体已经统一了，痛点在“取数慢、报表乱”，那直接从指标治理和自助分析切入更划算。

实际项目里我经常是两条线并行：主数据先挑一个域（通常是客户域）做试点，同时用普元数据资产平台把指标口径管起来。这两个动作不冲突，而且能互相印证——主数据保证了实体的唯一，资产管理保证了指标的一致，业务用起来才敢信。等这两块稳了，再往上叠 BI 和 AI 问数，风险小很多。急着铺全量的，我见到的结果大多不太好。

写到这里，我想把话收回到最开头那个判断上。数据中台这件事的成败，从来不是由架构多先进、接了多少张表、大屏多好看决定的。它由一件很小的事决定——有没有一个人的一天，因为这套系统变得轻松了一点。如果有，它就会活下来，然后慢慢长大；如果没有，投多少钱都是在给机房添设备。

我这些年最大的转变，是不再热衷于讲“数据资产化”“数据驱动”这些大词。我现在跟客户聊的第一句话是：“你们哪个部门每周要做一次重复的报表？我们把它干掉。”这句话很土，但它能直接指向一个真实的人、一件真实的事。事情做成了，平台自然就有了存在的理由。

从这个角度看，数据中台的实际价值就两条线：往内，它把重复劳动从人身上拿走；往外，它让决策有据可依。应用场景也围绕这两条线展开——主数据统一让人不再为“这个客户到底是谁”扯皮，指标治理让会议不再纠结数字对不对，自助分析和 AI 问数让业务不必排队等 IT，高质量数据集让模型有真东西可学。这几件事都不是宏大叙事，全是具体的、每天在发生的琐碎。

如果你正在筹备这类项目，我的建议是：把首期的范围砍到原来的三分之一，把验收标准从“完成建设”改成“某个场景被某部门稳定使用”。宁可慢半年，也别做一个验收时人人满意、半年后无人登录的系统。真要做大，等第一批用起来的人替你去说服别人，那比自己讲一百页 PPT 都管用。

还有一点想提醒：别把这件事当成一次性工程。数据口径会变，业务会变，源系统会换，平台得跟着长。选一个能长期演进、能力在同一个体系里不打架的底座，比当下省的那点预算重要得多。

陈立群（制造业 信息化负责人）：我们去年就是这样，平台上线开了发布会，半年后除了 IT 没人登。看完这篇才反应过来，当时验收报告里真的没有一个使用指标。现在正在按场景重做，先啃设备台账那一块。

苏敏（零售集团 数据分析师）：口径那段说到我心里了。“活跃会员”我们也是三套算法，每次开会先吵半小时。后来做了口径台账，确实好很多。想请教下指标责任人签字这块，业务部门不太愿意签，怎么推的。

周皓（能源行业 数据平台架构师）：同意“先窄后深”。我们一期铺得太开，几十个源系统接进来，指标没落地几个，后面想收都收不回来。二期砍到一个班组场景，反而跑通了。教训挺贵的。

何秀云（医药企业 业务运营）：作为业务方说句实话，我们不关心平台叫什么，只关心要的数能不能马上拿到、准不准。之前那套系统要点七八层才出结果，还不如自己拉表。后来换成能直接问的，用得就勤了。

罗建平（咨询顾问）：补充一点，很多项目失败是因为甲方内部没有能持续运营的人。平台交付完，实施方撤场，甲方连一个专职的数据运营都没有，资产目录半年就过期了。这事得在立项时就配人配预算，不然再好的工具也白搭。