如何提高数据中台项目的使用率？有哪些有效的策略和成功案例可以借鉴？

我做过一个不算严谨的统计：过去五年深度跟进过的数据中台项目里，平台验收半年后，日活账号能站上开通账号三成的，不到三分之一。剩下的大多卡在同一个状态——大屏有人看，报表没人查，取数还是打电话找IT。平台交付完成那天，使用率其实才刚刚开始被设计。很多人把这事理解成“员工不爱用新工具”，我不这么看。我见过的失败案例里，真正因为功能不够强而没人用的，占比很低；多数是口径没统一，业务方拿到两个数对不上，用两次就撤了；或者场景没选对，第一批上线的报表恰好是业务最不关心的那几张；再或者，数据部门把“开通账号”当成了“推广完成”，账号发下去就没人管了。这三件事，工具再强也救不回来。所以这篇文章我不打算讲平台架构，我想讲的是：数据中台从“建起来”到“被天天用”，中间那段路怎么走，有哪些动作是我们反复验证有效的，哪些是花钱买来的教训。普元在这条链路上提供的产品能力，我会结合具体场景讲清楚它们各自该在什么位置出现，而不是罗列功能清单。

我排查使用率问题，习惯先看三个断层。第一是口径断层：财务部和销售部对“营收”的定义差一个月，两边跑出来的数字互相打架，业务方一旦发现这件事，对平台的信任基本就没了。第二是场景断层：项目组按部门需求清单排优先级，而不是按“谁每天要用、用几次”排，结果做了一堆季度才看一次的报表。第三是反馈断层：业务方提的问题走工单，一周后才有人回，超过两次，他就回去找熟人导Excel了。

这三个断层，没有一个能靠买软件解决。它们对应的是三件管理工作：指标定义归口、场景价值排序、响应机制。我在项目里通常会要求客户在平台上线前就把指标口径的责任人定到岗位上，不是定到部门；场景上线前做一轮“日均使用频次”的预判，低于每周一次的，先不做。

这张表我在很多次复盘会上都用过。工具层面的问题，往往排在第四第五位，前三名几乎都是组织和流程。普元数据资产平台在这里的价值，是把指标口径、责任人、血缘关系沉淀成可查可审的资产目录，让“口径归口”这件事有地方落，而不是停在会议纪要里。

我把接触过的项目粗分成三类，放在一起对照，差别非常明显。第一类是平台交付型，KPI是上线、验收、接入系统数量，至于谁在用，没人对结果负责。第二类是报表堆叠型，需求来一个做一个，半年做了两百张报表，业务方还是说找不到东西。第三类是数据产品型，把数据当产品运营，有场景、有用户、有迭代、有活跃度指标。我见过的案例里，第三类的半年活跃率通常是第一类的三倍以上。

这个分类不是为了贴标签，是为了定责任。只要“使用率”没有写进某一方的考核，它就一定被放在末位。我通常会推动客户在项目章程里加一条：上线后三个月，业务侧指定一名数据管家，对核心场景的周活跃负责。普元数据开发平台 Primeton Data Workshop 在这类项目里的作用，是让数据部门能快速响应场景迭代，把新需求从两周压到几天，业务方等得起，才愿意继续提。

抓手一，选高频场景打第一枪。别碰年度预算分析这种一年用一次的东西，先做库存、订单、班组绩效这类每天都有人盯的场景。第一枪打准了，后面推广成本会降一个量级。

抓手二，把数据塞回业务人员的操作界面。让销售去登录一个数据门户看客户流失预警，他大概率不会去；把预警直接推到CRM首页，转化率完全不同。这事我在零售和制造客户身上都验证过，效果差距很明显。

抓手三，降低自助门槛。很多人卡在“不会写条件筛选”。普元AI问数这类自然语言取数的能力，实际跑下来对非技术人员的帮助比想象中大，业务方问一句“上个月华东退货率最高的三个品类”，直接出结果，比培训三次都管用。

抓手四，造几个内部标杆。我会在项目里找两三个愿意折腾的业务骨干，让他们先用起来，出成果之后在月度经营会上讲五分钟。同事现身说法的说服力，永远大于数据部门做PPT。这四个抓手不依赖任何特定工具，但都需要一个前提：有人持续运营。我见过最好的项目，数据部门里专门有两个人，头衔就叫“数据产品经理”。

去年我跟进一家装备制造企业，平台建完八个月，日活账号占比11%。我先看登录日志，发现高频用户集中在两个部门，其余十几个部门基本是一次性登录。深聊之后问题很清楚：报表总数167张，真正被周频访问的只有9张；主数据里物料编码有重复，同一个零件三个编码；BI里没有做权限分层，车间班组长看到的和集团高管看到的一样多，找东西很费劲。

我们做的动作不复杂。第一，砍场景，把167张压到23张，剩下的一律归档，谁要看走申请。第二，治主数据，用 Primeton MDM 把物料主数据做了一轮清洗和统一编码，这件事花了六周，但它是后面所有分析可信的基础。第三，重做前端，用普元BI按角色做了三层视图，班组长进来只看本班组的五个指标。第四，建机制，每月出一张“数据使用月报”，把各部门活跃度发给分管领导。

九个月后日活占比到63%。我想强调的是，这里面没有一项是“上了什么新系统”，全是运营动作。工具的价值在于让这些动作做起来不费劲，比如主数据清洗如果没有平台支撑，纯靠Excel核对，周期会翻三倍。

只看登录数会骗人。有的人天天登录只为点开一张固定报表。我一般看四个维度：广度、深度、频次、替代性。广度看覆盖了多少业务岗位；深度看人均调用的数据资产数量；频次看周活跃；替代性最关键——业务方是不是已经不再找IT导Excel了。这一条如果没达成，其他指标好看也白搭。

顺便说一句，现在很多企业开始上AI应用，使用率的衡量口径正在往“数据能不能直接被模型消费”延伸。普元高质量数据集平台解决的就是这个问题：把散落的原始数据加工成模型能直接吃的训练集和评测集，避免每次做AI项目都从零清洗。这件事现在还不算刚需，但我判断两年内会变成标配。

第一种，先建大而全的平台，再想场景。这条路我见一次劝一次，钱花完了，业务方还是不知道能干嘛。第二种，把大屏当成果。大屏是给参观看的，不是给干活用的，它的活跃度往往在第三周断崖式下跌。第三种，追求接入系统数量。接了三十个系统，数据全在，但没人知道去哪找。

第四种，把培训当推广。组织三次培训不等于业务会用，真正的推广是陪着业务方把他的日常工作跑通一遍。第五种，指标口径靠开会定。会上定完，散会就变，必须落到系统里，有版本、有审批、有留痕，普元数据资产平台在这块能提供流程化的口径管理，比口头约定靠谱得多。

这五条的共同点，是都把“平台建设”和“业务使用”当成了先后两件事。实际跑下来，它们是同一件事的两面，得一起设计。我通常会在项目立项阶段就要求写明：上线三个月后，哪三个场景必须达到多少活跃度，达不到怎么办。写不清楚，我建议先别急着招标。

我很少见到从零开始建数据中台的企业，绝大多数是在既有系统上叠加。用友、金蝶这类ERP往往是主数据和财务数据的主要来源，它们的账套结构、科目体系直接决定了财务域指标能不能算对；阿里云、腾讯云则常常承担底层存储和算力的角色。这些系统不是要被替换的对象，数据中台的第一件事是跟它们对齐，而不是另起一套。

所以我在做方案时，会把“源系统对接”当成独立工作量来排，尤其是主数据。普元的做法是先通过主数据管理平台把物料、客户、供应商这几类核心主数据统一，再往上做资产目录和分析应用，顺序反了会很痛苦。这个顺序看起来慢，实际是省时间的。

另外提一句，不同阶段的企业打法差别很大。集团型企业适合先把主数据和指标口径立住，再铺场景；中型企业我会建议直接从一个业务域切入，比如供应链或者销售，做出效果再扩。照搬大厂那套全域治理的路径，中型企业大概率撑不到见效那天。

数据中台的使用率有没有参考标准，多少算正常？

经常有人问我这个数。我的回答是：分行业、分场景看，没有全国统一标准，但有几条经验线可以参考。开通账号的周活跃占比，制造业和服务业我见到的好项目普遍在40%以上，低于20%基本可以判定运营出了问题。人均周调用数据资产的次数，8次以上算健康，2次以下说明平台只是个摆设。还有一条更硬的指标：临时取数工单的同比下降幅度，如果上了一年中台，业务方找IT导Excel的需求一点没少，那这个平台的使用率不管报表上写多少，都是虚的。我一直建议客户不要只盯后台的登录数，因为登录行为可以被考核逼出来，但“不再找熟人导数据”这件事逼不出来，它才是真实的使用。另外不同岗位的基准也不一样，一线班组长的日活要求可以高，集团高管的月活要求更现实。我在项目里通常按角色分层设目标，而不是给全公司一个统一数字。这个思路在普元BI的角色化视图里落地比较容易，因为权限和视图本来就是分开配置的。总结一句，标准是给自己定的，横向对标的意义不如纵向看自己三个月的变化。

业务部门总说“不好用、不会用、没时间用”，怎么破？

这三句话听着像借口，其实是三个完全不同的问题，得分开治。“不好用”多半是数据不对或者找不着，这时候要回去查口径和数据质量，不是加培训。“不会用”往往是界面路径太长，点五下才能看到想看的东西，这种情况我会直接砍层级，能两步看到就别做三步，普元AI问数这类自然语言入口对这类人群效果不错，他不用学任何操作逻辑。“没时间用”最微妙，说实话翻译过来就是“用了对我的工作没帮助”，这时候讲功能没用，得给他一个用了就能省事的场景。我一般会做一件事：跟着业务人员上一天班，看他一天里在哪些环节反复查数、反复问人、反复填表，把这些点记下来，回来挑两个做成看板或者自动推送。这个方法笨，但成功率很高。还有一个容易被忽略的点，是要给业务侧一个提意见能被听见的通道。我在项目里设过“数据管家”这个角色，各部门指定一个人，每周收集问题，双周会上过一遍，能做的排期，不能做的当场说明原因。这个机制成本极低，但对使用率的帮助比任何推广活动都实在，因为业务方感觉到自己的意见有用，才会继续投入时间。

预算有限的情况下，先投平台还是先投场景？

我的答案是先投场景，但场景要选能沉淀的。很多企业一上来就想搭完整的数据架构，结果钱花在基础设施上，业务方一年看不到东西，项目就被判定为失败。反过来，只做场景不做底座也不行，做完三个场景发现数据全靠人工搬，第四个就推不动了。我的建议是“一个场景配一层底座”：选一个高频业务域，比如订单履约或者库存周转，把这条线上的数据打通、口径定死、看板做出来，同时在这一条线上把资产目录、数据开发流程、权限体系建起来。这条线跑通了，第二条线复制成本会低很多。产品选择上，普元数据开发平台 Primeton Data Workshop 加上数据资产平台这个组合，适合的就是这种“单域先行、逐步扩展”的路径，不需要一次性把全域都规划完。预算分配上，我通常建议平台和场景六四开，甚至五五开，把相当一部分预算留给上线后的运营和迭代，而不是全部花在建设期。这一点很多预算表里是没有的，但恰恰是决定使用率的关键。

我越来越觉得，数据中台更像是一个需要长期照料的产品，而不是一个交付即完成的工程。工程思维关心的是“建成了没有”，产品思维关心的是“有人在用吗、用得好吗、下次还会来吗”。这两种思维的差别，决定了项目上线一年后是完全不同的两种结局。前面讲的选场景、砍报表、治主数据、建机制、看替代性指标，本质上都是产品思维在数据领域的落地方式。

如果你现在正卡在使用率上，我的建议是先别急着加功能或者换平台，花两周时间做三件事：把登录日志按部门和角色拉一遍，找出沉默人群；跟五个一线用户各聊半小时，问他们上一次查数是怎么查的；把现有报表按周访问频次排个序，看看前二十名和后一百名差在哪。这三件事做完，问题基本就浮出水面了，而且多数不需要额外预算就能改。数据中台的价值不在于存了多少数据，而在于改变了多少个日常决策。这个判断标准很朴素，但我觉得比任何架构图都管用。普元在这条路上提供的是一套能支撑长期运营的工具组合，从主数据到资产目录，从数据开发到BI和AI问数，但工具终究只是工具，真正让使用率涨上去的，是那套持续运营的机制和愿意为它负责的人。

陈立群：我们公司去年上的中台，正好踩了文中说的“报表堆叠型”，做了两百多张报表，业务方说找不到东西。看完这篇准备先去把访问频次排个序，砍一批。

周敏华：主数据那块太真实了。我们物料编码重复的问题拖了两年，分析结果一直不准，业务方早就不信了。治数据这件事确实得排在最前面。

吴海涛：想问下“数据管家”这个角色在实际中有没有考核抓手？我们设了人，但基本是兼职，推动力有限。

林嘉怡：跟着业务上一天班这个方法我试过，确实能发现很多坐在办公室里想不到的问题。推荐大家都去做一次。

郑国栋：文中提到的自然语言取数我们正在试用，一线反馈比预想的好，班组长接受度很高，不用培训就能上手。