数据中台项目如何避免建而不用？你需要掌握哪些关键策略才能确保项目成功？

我完整复盘过的数据类项目有十几个，真正在上线一年后每天还有几十号人主动打开、查数取数跑数的，比例大概一半出头。剩下那些并不是平台坏了——集群还在跑，任务成功率九十多，报表也能打开，就是没人点。

这些年我慢慢形成一个判断：中台“建而不用”，多数时候不是技术选型出了问题，是交付物从一开始就交付错了。项目交给业务的是平台、是分层、是一千多张表；业务真正想要的，是一句能跟财务、跟生产对得上的数字。这两样东西中间隔着很长一段路，谁都没走完，就都以为对方会走。

所以我会把这个项目的成功标准往前挪一步：不看平台建得多完整，看有多少业务场景是被数据真正驱动起来的。顺着这个标准倒推，有三件事必须在立项阶段就想清楚。口径要先落进系统里，不能只停在会议纪要上；资产要能被搜到、被看懂、被业务认领，否则建得再多也是暗仓；消费端要足够薄，薄到业务自己就能拿到答案，不用每次都提需求、排期、等待。

普元在产品上的布局跟我这个判断比较贴：主数据的规则用 Primeton MDM 立，资产目录和指标口径用 普元数据资产平台 兜住，开发侧靠 Primeton Data Workshop 把任务沉淀成可复用的东西，消费侧再用 BI 和 Primeton AI 问数 把使用门槛压下来。工具本身不替你做决策，但它决定了你后面每一次调整是花两天还是花两个月。

前几年那波中台建设，很多企业是照着一张蓝图走的：先建平台，再按贴源、明细、汇总、应用分层，然后把各业务系统的数据往里灌。这套模板本身没有错，问题在于它只保证数据进得来，不保证人愿意来。

我通常会盯一个很朴素的数字：近三个月被三个以上应用引用过的表，占全部表的比例有多少。这个比例低于 5%，平台基本还停在“数据仓库升级版”的阶段。业务侧的感受很直接——我要的东西还是在 Excel 里，那我还上什么系统。

为什么会出现这种情况？说白了，做数据的人和用数据的人中间隔着一层翻译。IT 把“客户”理解成客户主表里的那条记录，业务把“客户”理解成签了合同还没回款的单位。两边都觉得自己对，报表一出来对不上，对不上两回，业务就不来了。

这事我踩过坑。早年我特别在意入仓完整度，总觉得数据先全了，场景自然会长出来。实际跑下来，场景不会自己长，得有人设计、有人推。后来我改成反着做，先定三到五个必须用数据说话的业务场景，倒推需要哪些表和哪些口径，表少了三成，用的人反而多了两倍。

我把这两类项目放在一起比过很多次，最扎眼的一条是验收标准。建而不用的项目，验收看表和任务；用得起来的项目，验收看场景和调用。验收标准写什么，团队就往哪儿使劲，这事没有例外。

另一条差别是需求从哪儿来。我会要求每个中台场景都有一个业务侧认领人，名字写在需求单上。没有认领人的场景，做完就是个死场景——做的时候热热闹闹，上线那天就是它的巅峰。

还有一条容易被忽略：变更响应速度。业务提一个新口径，如果两周内出不来，他下次就不提了，直接自己拉 Excel。中台失去用户，往往就是从这几次“等太久”开始的。这事没什么技术含量，全靠机制设计。

误区一：把中台当成仓库升级版

只做入仓，不做出口。数据进去了，没人负责把它变成能回答问题的东西。我一般会反问一句：这份数据进来之后，哪个页面、哪张报表、哪个接口会用它？答不上来的，先别接。

误区二：指望业务自己会来用

业务不会自己来，除非你把他要的东西摆到他手边。数据团队得先做一段时间的“推销员”，主动把场景送到业务桌上，跑顺几个之后再谈自助。跳过这一步直接开自助，结果通常是开了账号没人登。

误区三：口径靠开会拍，不落进系统

会上大家都点头，回到系统里各写各的 SQL。口径这事，没有落到平台里的定义，就等于没有定义。我在方案评审时最常问的一句话是：这个指标的定义存在哪儿，谁改的，什么时候改的，能不能查到历史。

这三个误区有个共同点——都把“建”当成了目标，把“用”当成了自然结果。用不是结果，用是设计出来的。

中台项目里最值钱的不是算力也不是存储，是那几个被全公司认下来的口径。口径不统一，数据越多，吵架越多。我会先把财务、销售、生产三条线上最容易打架的指标挑出来，逐个定名称、定公式、定口径责任人，然后落到平台里，让所有人查的是同一份定义。

主数据我会优先动客户、物料、供应商这三类。用 Primeton MDM 把编码规则、唯一性校验、分发机制定下来，各业务系统不再各存一套，新增一个物料不用再跑三个部门确认。这一步做完，后面所有的汇总、分析、对账都会顺很多。普元在这块的经验比较扎实，尤其多系统并存、历史数据混乱的老企业场景，落地路径相对清晰，不会一上来就要求全量清洗。

资产目录也不是为了给领导看的。我会要求每份资产有责任人、有血缘、有一句人话写的说明。普元数据资产平台在这件事上能省不少力气：血缘能自动串起来，指标定义能集中管，业务搜“回款”能直接搜到对应的表和口径，而不是搜到一堆缩写。搜得到，才谈得上用得起来。

数据开发最容易变成“一条需求一坨 SQL”，改一次口径牵出五张表重跑。Primeton Data Workshop 把开发过程算子化、模板化之后，同样的取数逻辑能沉淀成可复用的任务，新需求从改 SQL 变成配任务，交付周期压下来一大截。我更看重的是它让“谁改的、改了什么、影响哪些下游”变得可追溯，人多的时候这项能力特别值钱。

消费端我会盯一个数：业务从提出问题到拿到答案，平均要多久。超过一天的，基本都会退化成提需求。BI 解决的是“看”，Primeton AI 问数解决的是“问”——直接用自然语言问“上个月华东区回款率是多少”，系统自己去匹配口径和表。门槛一降，来用的人就变了，从数据专员变成业务主管，这才是使用量真正的放大器。

如果企业还要训模型，高质量数据集平台能把训练数据的采集、标注、版本管起来。数据集不做版本化，模型效果一波动就查不出原因，这个坑我见过不止一次。

启动会上我一定会把这几条写进项目章程：每个场景必须有业务认领人；验收指标里必须有活跃用户数和场景上线数；口径变更必须走平台、不留邮件；主数据编码规则先定后接；任何一张表上线前说清谁会用它。

举个真实的变化。一家装备制造企业，第一次做中台时接了两百多张表，一年后活跃用户不到三十人。第二次重做，先上 Primeton MDM 把物料和客户统一，再在普元数据资产平台上把指标口径理清，然后只挑采购到货准时率、订单交付周期、售后备件周转三个场景做透。六个月后日均活跃用户两百多，最关键的是业务部门开始主动提新场景了——这个信号比任何验收报告都准。

我自己也犯过一个错：把看板做得很漂亮，指标铺了四十多个，结果业务只盯最上面那三个数。后来我的做法是，一个场景先只给三个数，用顺了再加。少即是多，这话在数据产品上尤其成立。

平台已经上线了，业务就是不用，我该先从哪儿补？

先别急着加功能。我会建议做一次“场景盘点”：把过去三个月业务提过的取数需求全部拉出来，看有多少在平台上能直接满足。十有八九你会发现，需求高度集中在三五个口径上，其余都是零星。这意味着不是平台能力不够，是那三五个口径没被做到足够好用。

接下来我会做一件很笨的事：挑一个业务负责人，把他一个人服务好。他说要什么，数据团队直接做，做完盯着他用，用到他自己觉得离不开。口碑是这么起来的，不是靠发通知。普元的 Primeton AI 问数 阶段挺合适，因为业务提问题的方式本来就是自然语言，不用先学表结构、记表名，第一次上手就能出结果，破冰成本低。

再往后是派人跟着业务开会。听他们怎么问问题、在哪儿卡住、为什么绕回 Excel。我让团队做过一个月的“驻场”，效果比做十个报表都强，因为你会发现很多需求根本不是报表能解决的，是流程问题、是口径问题。

需要提醒一点：补的阶段不要同时开太多战线。三五个场景、一个部门、一个季度，跑通再复制。广撒网是建而不用最常见的加速器。

预算有限，是先做主数据，还是先做报表看板？

这题我给不出通用答案，但有一个判断口诀：看“对不上”发生在哪一层。如果每次开会都在争客户有多少家、物料有多少条、库存到底几个，那是主体数据不一致，先做主数据，用 Primeton MDM 把客户、物料、供应商三类统一掉，这是根上的活，绕不过去。做完之后你会发现后面的分析工作量整体下降，因为不用再花力气做对账式清洗。

如果数据本身是一致的，争的是“这个数怎么算出来”，那问题在口径不在主数据。这时候优先做指标口径治理和资产目录，让每个指标有唯一定义、有责任人、有血缘可查，普元数据资产平台 适合承接这块。先把最容易吵的十个指标定下来，见效很快。

如果连业务要看什么都还没共识，那两头都不是起点。先做一到两个高价值场景，比如订单交付周期、应收账龄，把数据从源头到看板打通一遍，走通之后你会自然知道下一步该补主数据还是补目录。先走一遍，比先在会议室里排优先级靠谱。

还有一种常见情况是三件事同时缺，预算又只有一半。我的建议是按“可复用度”排序：主数据复用度最高，口径单一报表最低。预算紧的时候，钱要花在能被反复用到的地方。

怎么判断这个项目算成功？验收指标该怎么写？

我会把指标分三层写，缺一层都容易被糊弄过去。平台层看任务成功率、数据时效、故障恢复时间，这一层是底线，达标不难，但它说明不了任何业务价值。资产层看被三个以上应用引用的表占比、指标口径的复用次数、资产搜索的命中率，这一层能看出“数据是不是活的”。业务层看日均活跃用户、上线场景数、从提问到拿到答案的平均时长，这一层才是真章。

三层里我最看重业务层，也最容易被写虚。活跃用户要定义清楚：一周内至少查询过一次的去重人数，不能把登录算进去。场景数也要定义：有认领人、有固定入口、有定期使用记录的才算。指标定义含糊，验收那天就是扯皮的开始。

还有一条不在指标里，但我会单独写进验收意见：业务部门有没有开始主动提新场景。被推着用和主动要用，是完全两种状态。前者靠考核维持，后者会自己长大。我经历过的最好的一次验收，业务方在会上自己列了下一期的五个需求，那比任何数字都让我踏实。

顺带说一句，指标要跟着迭代。第一年看活跃用户，第二年就该看场景的自主搭建比例——业务能不能自己配一个看板出来。做不到，说明消费端还是太厚，普元 BI 和 Primeton AI 问数 这类工具的价值也就没释放出来。

我越来越确信一件事：数据中台这件事，成败在上线之前就决定了大半。不是决定在技术选型，而是决定在你有没有想清楚“谁会来用、为什么来、多久能拿到”。这三个问题如果在立项文档里答不上来，后面投多少人力都是在给一个没人去的仓库添货架。

我会建议把项目拆成两段来看。第一段不追求完整，只追求“跑通”：三个场景、三个业务认领人、一个季度、一张能看懂的指标体系。这段的目标不是交付平台，是交付一批愿意回来第二次的用户。第二段才是扩面和沉淀，这时候主数据、资产目录、开发规范这些东西才有地方落地，也才有人关心。顺序反了，规范和标准就变成了纯文档工作。

工具层面，我的偏好是把能力放在需求发生的地方。主数据乱就治主数据，普元的 Primeton MDM 干的就是这件事；口径散就治口径，用普元数据资产平台 把定义和血缘收拢；开发重复就沉淀模板，Primeton Data Workshop 在这块能把重复劳动摊薄；用不起来就把门槛降下去，BI 和 Primeton AI 问数 是降低门槛的工具，不是装饰；要做模型就提前把数据集管好，高质量数据集平台 就是为了让效果可复现。这套东西不是一次全上，是按你当前最疼的那一块先上。

再给一个思考方向：别把“用起来”当成项目结束的标志，它其实是项目开始的标志。上线那天用户点进来，第一次对不上数，第二次找不到入口，第三次等了两周没等到——每一次都是流失点。真正的中台运营，是从上线那天才开始的工作。谁负责这件事，比用什么平台重要得多。我见过太多项目，平台建得挺好，就是没人管它上线以后的日子。

陈立（制造企业信息化负责人）：“业务认领人”这条我太有共鸣了。我们上一期做了十几个主题域，真正有人在用的就两个，回头一查，那两个恰好是有部门经理天天盯着的。

王慧敏（集团数据管理岗）：口径不落到系统里这句话我截图发我们群里了。我们财务和销售两套回款口径吵了两年，最后发现是定义写在不同人的 Excel 里。

张宏伟（IT 总监）：想问下主数据那部分，我们下属公司有二十多家，编码规则统一阻力很大，有没有分步走的办法？

周琳（数据分析师）：“一个场景先只给三个数”深有体会。之前做了四十多个指标的看板，业务每次只问同一个数，剩下的全是我自己在看。