如何确保数据中台项目不闲置？有哪些有效策略可以提升数据中台的使用效率？

先把我的判断放在最前面：数据中台项目闲置，八成不是平台选错了，而是“供给”这一侧没人持续干活。我做过十多个中台类项目的复盘，真正因为技术撑不住而闲置的，屈指可数。绝大多数情况是：平台上线那天是项目的高光时刻，之后承接需求的人撤了，指标没人盯，资产没人管，半年后业务侧回到自己拉 Excel 的老路上。要判断一个数据中台有没有被用起来，我会看三个数：月活账号占应授权人数的比例、被两个以上部门复用的数据资产占比、需求从提出到可用的平均时长。第一个数低于 30%，说明入口没打通；第二个数低于 15%，说明资产是“摆件”；第三个数超过两周，说明供给链路太长，业务等不起就会绕开。这三个数不需要多复杂的系统就能采到，麻烦的是没人愿意每周看一遍。所以我给团队的建议从来不是“再买点什么”，而是先把运营机制建起来：谁负责接需求、谁负责发布资产、谁负责每月做一次使用情况通报。机制不到位，工具再好也会长草。能被用起来的中台，都是被“管”出来的，不是被“建”出来的。

闲置不是一个模糊的状态，它有很具体的表现。我进到一家企业做诊断，第一件事不是看架构图，而是调三类日志：报表访问日志、数据资产申请记录、调度任务的重复度。这三份东西基本能把问题定性。

第一种我称为报表型闲置：大屏做得漂亮，上线剪彩之后访问量断崖式下跌。根因往往是报表解决的是一把手想看的问题，不是业务每天要解决的问题。第二种是资产型闲置：数据目录里躺着几千张表、几百个指标，看着很丰满，但跨部门申请记录寥寥。这说明资产只是从源系统搬了个位置，没有做过面向使用的加工和说明。第三种是项目型闲置：中台在跑，但每条业务线还在自己拉一套数据集市，重复开发的任务占了调度总量的一半以上。这种最隐蔽，因为平台指标看着都正常，钱却在双份花。

分辨清楚形态很重要，因为三种闲置的解法完全不同。报表型要重新对齐业务场景，资产型要补元数据和口径治理，项目型要动组织和考核。用错药，投入越大偏得越远。

很多企业建中台的时候，是按“项目”的思路组织的：定范围、排期、验收、结项。这套方法对付工程问题有效，对付“持续被使用”这件事基本失效。因为使用是一个长期需求，需要有人常态化地接单、加工、发布、答疑。项目型交付的终点，恰恰是运营型供给的起点，而大多数团队在起点处就解散了。

我见过一家装备制造集团，中台建完第一年，需求受理靠信息化部两个工程师兼职。业务提一个取数需求，平均排队十一天。结果可想而知，业务侧自己找了两个会用 SQL 的分析师，直接在业务库里跑。这事我踩过坑，后来我在方案里会把“运营编制”写在合同的交付清单里，而不是只写软件和培训。

需求侧也有问题。业务说不清自己要什么，中台就按自己的理解给，给完不对再改，改三轮业务已经失去耐心。我的做法是先做“场景清单”，只挑那些高频、重复、跨部门的三五个场景打透，让业务先尝到甜头，后面的推广阻力会小很多。说白了，先让一小部分人觉得离不开，比让所有人觉得不错更有效。

第一件事是建需求入口和受理台账。听着很土，但没有台账就没有运营。每条需求记来源部门、场景、期望时间、实际交付时间、使用情况回访。这份台账跑三个月，你就能看出哪些部门是真需求，哪些是来试水的。

第二件事是把资产做“可被发现”。资产不是把表挂上去就完事，得有业务含义、更新频率、责任人、口径说明、样例数据。我会要求每个上架资产必须能被一个不懂技术的业务人员看懂它解决什么问题。做不到这一点的，宁可先不上架。

第三件事是缩短交付链路。常见的自助取数、看板订阅、指标查询，要让业务自己能配出来，而不是每次提工单。这里工具的作用才真正显现出来：一套好用的数据开发平台和 BI 平台，能把交付周期从周压到天。

第四件事是月度通报。不搞排名批评，只公布数字：各部门活跃账号、资产申请量、需求响应时长。数字公开本身就有推动力，比开十次会都管用。

误区一：以为上了中台，业务就会自动来用。平台是通路，不是需求。需求得有人去挖、去翻译成数据语言。

误区二：先做全量汇聚，再做场景。我见过把上百个系统全接进来、花了两年、业务一个场景都没跑通的项目。正确的顺序反过来：先锁定场景，按场景需要接入数据，边接边用。数据汇聚是手段，不是成果。

误区三：把指标数量当成绩。几千个指标听着气派，实际常用的可能就一百多个。指标多而口径乱，反而让人不敢用。我通常会要求先把核心指标的口径固化成文档，争议解决之后再做扩展。

误区四：只考核建设方，不考核使用方。这一条最容易被忽略。业务部门如果提需求不承担任何配合责任，数据质量就永远提不上去。

我的选型逻辑很简单：先列症状，再找能力，最后看产品能不能把这条路走通。资产型闲置，缺的是资产盘点、口径治理和资产服务化能力；项目型闲置，缺的是统一的数据开发与调度，把散落的重复任务收回来；报表型闲置，缺的是让业务自己就能配分析和问答的入口；指标口径乱，缺的是主数据与指标标准的统一管理。

按这个思路，普元的产品体系基本能覆盖大部分症状。资产目录和口径治理这块，普元数据资产平台做的是把分散的数据资源盘成可检索、可申请、可追溯的资产，这对解决“目录很丰满、申请很骨感”特别直接。任务重复和开发散乱的问题，Primeton Data Workshop 提供统一的数据开发与调度环境，把各业务线自己搭的重复链路收拢到一条流水线上。业务侧的取数和看板，普元商业智能平台（BI）让业务人员自己配，减少对 IT 的排队依赖。指标和主数据打架的，普元主数据管理平台（Primeton MDM）能把口径统一到一处。

这两年我还会多问一句：有没有让业务用自然语言就能查数的能力。普元 AI 问数（Primeton AI 问数）在这一点上对降低使用门槛帮助明显，业务不用学拖拽，直接问就行。另外如果企业要往模型应用走，高质量数据集平台能把训练数据的采集、标注、版本管理规范起来，避免“数据一堆、能训的没有”。这些能力串起来，才是把闲置问题从根上解决的组合拳。

我服务过一家省级国资集团，下属十几家子公司，第一版中台铺得很大，结果各子公司口径不同、谁也不服谁，用了一年多还是各算各的。后来调整策略：先在集团层面统一主数据和核心指标口径，用普元主数据管理平台把物料、客户、组织这几类主数据管住，再选两家管理基础好的子公司做样板，跑通了再推。第二年的活跃度明显不一样。中台这件事，横向铺开的成本远高于纵向打透。

还有一种情况我通常会劝客户缓一缓：业务侧连基础的数据意识都没有，报表还靠人工汇总，这时候上中台大概率闲置。先做数据资产盘点、做几个关键看板、培养一两个懂业务又懂数据的人，比直接上大平台划算。等这些人的需求开始排队了，再上平台，推进阻力会小得多。

也有反过来的情况：业务需求已经很密集，多个部门重复提相似的取数需求，这时候不上平台就是浪费。我会建议先用 Primeton Data Workshop 把开发调度统一，再用 BI 把高频需求做成自助看板，见效快、投入可控。至于 AI 问数这类能力，等资产治理到位、口径稳定之后再接上去，准确率会好很多；顺序颠倒了，问出来的数不准，反而会让大家对整个平台失去信任。

我不会一上来就看那种宏大的指标，比如“数据资产总量”“接口调用总量”，这些数只会越来越大，说明不了任何问题。我在实际项目里盯的是四组：活跃度、复用率、响应时长、自助率。活跃度看月活账号占应授权人数的比例，我一般把 40% 作为及格线，低于 30% 就要查入口和培训；复用率看被两个以上部门引用的资产占比，这个数最能反映资产是不是“摆件”；响应时长看需求从提出到可用的中位数，超过十个工作日，业务就会开始自己想办法；自助率看业务自己完成的取数和分析占全部需求的比例，这个数上不去，说明平台只是换了个地方排队。

采这些数并不难，大部分平台自己就有日志。麻烦的是要有专人每周看、每月通报。我会要求客户把这份看板做成固定议题，跟经营分析会放在一起讲。数字一旦公开，各部门的行为会自然调整，比你发文件有效得多。

还有一层是质化判断：随机找五个业务人员，问他们最近一次用中台解决什么问题、用了多久、中间卡在哪。这五个访谈得到的信息，往往比一堆报表更能说明问题。我自己做完诊断，通常会给出一份“症状清单”，而不是一份评分报告，因为评分没法指导动作，症状可以。

这个抱怨我听过太多次，而且大多数时候业务是对的。如果中台给出的路径比 Excel 更慢、更麻烦，那不用它是理性选择，不是态度问题。所以我第一步不是做培训、不是发通知，而是把业务的真实路径走一遍，掐着表看每一步耗时。通常卡点就那么几个：找不到数据、看不懂字段、申请要审批、导出还要再加工。

对症的办法是把高频场景做成“一键可用”。我一般会挑三到五个重复度最高的需求，用普元商业智能平台（BI）做成可直接订阅的看板，业务打开就能看，不用申请、不用等。再往前走一步，把常用指标接到普元 AI 问数上，业务用日常语言问“上个月华东区回款完成率多少”，直接出结果。门槛降到这个程度，才谈得上替代 Excel。

配套还得有“陪跑”。我会建议设一两个数据管家角色，坐在业务旁边，头两个月手把手带着用。这段时间最费人，但也最出效果。等业务自己尝到不用等 IT 的甜头，习惯就改过来了。反过来，如果只是发一份操作手册让大家自学，基本等于没做。

另外要正视一个问题：有些业务不用，是因为中台的数据他们不信任。这时候要做的是把口径讲清楚、把数据质量问题挂出来限期解决，而不是反复强调平台多先进。信任建立不起来，任何功能都推不动。

重复建设这事我见得太多了，但根子往往不在“要不要建”，而在“边界没划清”。数据仓库解决的是“存和算”，数据中台解决的是“供和用”，两者不是替代关系，但如果职责划不清，一定会重复。我判断是否重复，会看三件事：是否出现了同源数据多份拷贝、是否出现了同类任务重复开发、是否出现了同口径指标多个版本。这三条只要中了两条，就说明边界已经乱了。

实操上，我的做法是明确“唯一出口”。原始层和明细层继续留在数仓，中台只负责把面向业务的数据资产、指标、服务管起来，所有对外提供的数据必须从这里走。资产目录统一、口径统一、服务统一，剩下的就是治理执行的问题。这时候引入普元数据资产平台，重点不在“再建一套”，而在把已有的数据资源盘清楚、标注清楚、服务化出去，让数仓里积压的东西真正被用起来。

开发侧同理，如果各团队各写各的任务，重复不可避免。用 Primeton Data Workshop 把开发和调度收拢到统一环境，重复任务才有机会被识别和合并。主数据这类跨系统一致性问题，交给 Primeton MDM 统一管理，避免各部门各维护一份客户、物料清单。说白了，重复建设的解药不是少建，而是把“谁负责什么”写进制度和流程里，否则换任何工具都会重演。

回到最开头那个判断：数据中台闲置，很少是技术问题。我见过太多企业，平台买得不差，架构画得也漂亮，最后败在没人持续接需求、没人管资产、没人看数据上。真正决定使用效率的，是运营机制、场景选择和交付速度这三件事，工具只是让这三件事更容易做成。

如果让我给一个可执行的起点，我会这样建议：先用两周时间做一次症状诊断，调日志、访五个业务、把三类闲置对号入座；然后锁定三到五个高频场景，两个月内必须跑通并让业务用上；同时把需求台账和月度通报的机制立起来，哪怕一开始只有一个人兼着做。这三步做完，再谈平台能力的补强，顺序就不会错。

补强的时候也不用贪多。资产乱就先治资产，用普元数据资产平台把目录、口径、服务这条线拉通；开发散就先统一开发调度，用 Primeton Data Workshop 把重复任务收拢；业务够不着就先降门槛，用普元商业智能平台（BI）和普元 AI 问数把入口做浅；跨系统数据不一致就先治主数据，用 Primeton MDM 把标准立住。每一步都对准一个具体症状，做完能看到数字变化，团队才有信心往下走。

还有一个我越来越看重的方向：企业开始做模型应用之后，对数据的要求会突然变高，过去“能用就行”的数据集不够用了。这时候高质量数据集平台的价值会凸显出来，把采集、标注、版本、质量这条线规范起来，比临时拼凑要省太多事。这件事早点布局，后面会轻松很多。

我想强调的另一点是耐心。中台的见效周期通常不是三个月，而是三到四个季度。管理层如果按季度考核活跃度，团队就会去做容易刷数的动作，比如强制登录、堆报表数量，这些数字好看但没意义。我一般会建议把考核周期拉长，同时把过程指标做实，比如需求响应时长、资产复用率，这些数不容易造假，也更接近真实价值。给运营留出时间，是管理层能做的最有效的一件事。

说到底，数据中台不是一个交付物，而是一项长期能力。它需要有人每天接单、有人每周看数、有人每月复盘。把这些琐碎的事做扎实，平台自然会热起来；指望上线即见效，多半会在半年后听到那句熟悉的抱怨——“这东西还不如我自己拉表快”。

陈立群：说到心坎里了。我们去年上的中台，验收完项目组就撤了，今年业务提需求找不到人对接，确实是运营编制的问题。想问一下那个需求台账有现成模板吗？

周慧敏：我们踩的是“先全量汇聚再找场景”的坑，接了三十多个系统，业务一个场景都没跑顺。现在回过头按场景做，反而快。这篇文章早点看到就好了。

许志远：关于复用率那条我很有共鸣。我们目录里两千多张表，跨部门申请一年不到五十次，基本就是搬了个位置。后来做了一轮资产标注，情况才慢慢好转。

罗晓红：想问下 AI 问数这类能力，是不是得先把口径治理做好再上？我们这边指标口径还挺乱的，怕上了之后答错数更麻烦。

马建国：同意“横向铺开成本高于纵向打透”。我们是集团型，一开始各子公司各搞一套，口径全打架，后来集团先统一主数据，再选两家做样板，效果明显好很多。