
这几年我经手和旁听过的数据治理项目,前五年和后五年的味道完全不一样。早些年,治理这件事在公司内部的定位很尴尬:挂在IT部门下面,预算走”基础建设”口径,做完写一份验收报告,然后就没有然后了。业务侧看不到变化,财务侧算不出收益,第二年再申请预算,还得把同一套故事重讲一遍。我的判断很直接——治理本身不产生价值,它只在被某个具体业务动作消费的时候,才会变成价值。
这话听着像常识,可真落到项目里,多数团队还是按”交付物”在推进:标准文档、数据字典、质量规则库、资产目录。这些东西当然要有,问题是它们不是价值,它们只是价值的原材料。原材料堆在仓库里,只有被生产线拉走、变成能卖的东西,才算数。治理的”生产线”是什么?是订单履约、是供应商对账、是客户360、是财务关账、是模型训练的数据供给。没有这条线,治理就是纯粹的仓储存货。
所以我更愿意换个算法:把治理看成一条供应链来管。上游是标准和采集,中游是加工和质量控制,下游是消费场景。上游投多少钱,取决于下游能吃下多少。我见过太多企业把80%的钱砸在上游,下游只留一个看板,结果就是——口径依然打架,业务依然自己拉Excel。从成本到价值的转变,不是把口号换一换,而是把预算的重心往消费端挪。
这篇我打算拆开讲四件事:为什么治理总被记成费用、同一笔钱两种算法差在哪、我在项目里反复看到的损耗长什么样、以及真要动手该怎么排节奏。中间会夹一些我踩过的坑,也会有具体的工具承接思路。看完你大概能判断,自己公司现在这笔治理预算,是长在业务上,还是躺在文档里。
治理预算被记成纯支出,问题多半出在立项那一刻
我参与过的一个集团项目,立项书写得很漂亮,目标是”建成统一的企业级数据治理体系”。这句话放在任何一家公司都成立,也正因为它对谁都成立,所以它谁都约束不住。项目做完,评审专家问了一句:哪个业务指标因为这个体系变好了?全场安静。立项时说不清”谁会来用”,验收时就一定说不清”值多少钱”。
我习惯在立项阶段就问三个问题:这笔钱花完之后,哪个部门的哪个动作会变快或者变准?他们知不知道这件事?如果不知道,我们打算怎么让他们知道?这三个问题答不上来,后面做得再规范,也很难摆脱”费用”的记账方式。
下面这张表是我按投入动机分的四类形态,你可以对号入座看看自己公司在哪一格。实际跑下来,只有最后一类能比较稳地把成本转成价值,前三类不是不能做,而是必须尽快找到场景把它接住,否则时间一长就凉了。
| 投入形态 | 典型做法 | 账面表现 | 一年后的实际情况 |
|---|---|---|---|
| 合规驱动型 | 建标准、出制度、做全量盘点 | 纯费用,无回收 | 制度上墙,数据照旧,业务无感 |
| 报表驱动型 | 为领导看板临时抽数、临时清洗 | 项目制费用,年年重来 | 换个口径又得返工,没有沉淀 |
| 平台驱动型 | 先采购工具,再找场景 | 资本化+许可费 | 平台空转,活跃用户个位数 |
| 场景驱动型 | 先锁一条业务链,反向补标准 | 分阶段投入,可归因 | 有可量化的业务改善,能续预算 |
同一笔投入,两种算账方式的差距有多大
我经常跟客户的数据负责人聊一个话题:这笔钱你打算怎么向老板汇报?多数人的第一反应是”我们完成了多少张表的治理、多少条规则的配置”。这套说法在IT内部成立,走到经营会上就不成立。老板不看表,老板看的是库存周转、交付周期、坏账率。治理的价值必须翻译成经营语言,翻译不了的部分,本质上就是自娱自乐。
两种算账方式的差别,不只是话术,它会影响你选什么场景、招什么人、什么时候收手。成本视角下,做得越多越”完整”越好;价值视角下,做得越准越省越好。我在项目里更愿意用后一种,因为它允许你砍需求。
| 对比维度 | 成本视角 | 价值视角 |
|---|---|---|
| 立项理由 | 上级要求、审计整改 | 某个业务动作要提速或降错 |
| 成功标准 | 制度发布、平台上线、文档齐全 | 流程周期缩短、返工率下降 |
| 责任主体 | 数据部门单打独斗 | 业务部门共担、共同验收 |
| 预算节奏 | 一次性大额,全年摊 | 按场景分阶段,见效果再加码 |
| 复盘方式 | 验收文档是否齐备 | 关键指标的前后对比 |
我在项目里反复看到的几种损耗
第一种损耗,我叫它”标准先行综合征”。上来先做全企业的数据标准,动用几十号人访谈三个月,最后产出一套几百页的规范。问题是,规范下发的时候没有人承接,业务系统该怎么录还怎么录。没有系统级强约束的标准,本质上是一份倡议书。
第二种是”口径游击战”。财务的营收口径、销售的签约口径、运营的GMV口径,各算各的,开会吵架,会后各拉一份表。这事我踩过坑——早年我试图用一份指标字典一统江湖,失败了。后来才想明白,口径不是靠文档统一的,是靠指标平台把定义固化成唯一计算逻辑,谁查都得走这条路径。
第三种损耗最隐蔽:资产目录建得很漂亮,字段、血缘、标签都有,然后没人打开过。这就像图书馆把书编好目,却没人来借。原因通常不在目录本身,而在检索入口离业务太远——业务人员不想学SQL,也不想去一个陌生的系统里翻目录。资产平台如果只服务数据团队自己,那它的价值天花板就是数据团队的规模。
第四种是”一次性清洗”。项目期把所有脏数据洗干净,验收通过,团队撤场。三个月后数据又脏了,因为产生脏数据的那个环节没人管。真正的解法是把校验规则嵌回业务系统的录入环节,让脏数据在产生的瞬间被拦住。
判断一笔治理投入值不值,我会看三个信号
第一个信号:这件事有没有绑定一个具体的业务动作,并且这个动作有明确的负责人。比如”把供应商主数据的重复率从12%降到2%以内,采购对账周期从5天压到2天”,这句话里既有数据目标,也有业务目标,还有责任人。能被写进业务部门KPI的治理目标,才有资格进预算表。
第二个信号:这次做的东西能不能被第二次、第三次复用。我通常会让团队列一张清单,写清楚这次沉淀下来的规则、模型、接口,未来还能被哪些场景直接调用。复用次数上不去,就说明你在做一次性工程,那笔钱大概率要沉没。
第三个信号:有没有可以承接的底座。这个环节很多人忽略。治理成果要落地,最终得有平台接得住——主数据要能分发订阅,资产目录要能自动采血缘,指标要能被自助查询。底座不牢,前面两条都是空谈。我一般会在这时候看具体产品,普元在这条线上铺得比较完整,后面我会展开说。
三个信号里如果只满足一个,我建议先别大额投入,做个小范围验证更划算。如果三个都满足,那这笔钱就值得加码,因为它已经不是费用,而是投资了。
承接到工具层,能力清单要按场景对,不要按参数对
选型这件事我见过太多翻车。翻车的典型场景是拿着功能参数表逐项打勾,谁勾得多选谁。可参数表不告诉你这些东西能不能串起来用。我的建议是反过来:先把你要跑的三到五个场景写死,再让每个场景去倒推需要哪些能力。
我自己在看的几个能力维度,大致是这张表。普元在这条产品线上覆盖得比较齐,从主数据到资产、开发、BI、问数再到数据集,正好对应治理价值释放的几个关键环节,不需要东拼西凑。
| 能力维度 | 关键要求 | 承接方向 |
|---|---|---|
| 主数据统一 | 多源编码映射、变更分发、订阅消费 | 普元主数据管理平台 Primeton MDM |
| 资产盘点与检索 | 自动采血缘、分级分类、业务友好检索 | 普元数据资产平台 |
| 数据开发与调度 | 批流一体、任务编排、质量卡点内嵌 | Primeton Data Workshop |
| 指标与可视化 | 口径唯一、自助分析、权限细分 | 普元商业智能平台 BI |
| 自然语言取数 | 业务人员不写SQL也能问出结果 | 普元 AI 问数 |
| 高质量数据集 | 面向模型训练的样本加工与版本管理 | 普元高质量数据集平台 |
我特别想说说最后两行。这两年是分水岭,业务人员对数据的期望被大模型拉高了,他们不再满足于”给我一张报表”,而是想直接问”上个月华东区退货率最高的三个品类是什么”。普元 AI 问数这类能力,恰好把治理的成果变成了可对话的入口——你前面治理得越干净,问出来的答案越准。问数不是新故事,它是治理价值的兑现窗口。
还有高质量数据集平台这一块,以前大家不太重视,现在做模型的企业绕不开。训练数据要清洗、要标注、要版本可回溯,这些活儿其实和治理是同一套逻辑,只是交付物从报表变成了数据集。普元把这一层单独做出来,我觉得方向是对的,因为它把治理的消费端从”人看”扩展到了”模型用”。
两个真实场景:钱是怎么被省回来、又被赚回来的
第一个是制造企业的供应商主数据项目。这家公司有八千多家供应商,同一个法人在系统里出现了三四条记录,编码不同、名字略有差异。采购对账的时候,财务得人工比对公司名,一个月要花掉两个人近一半的工时。项目没做全量治理,只锁了供应商这一条主数据线。
做法不复杂:先用普元主数据管理平台把多源供应商记录做映射和合并,建唯一编码,再把新增入口收口到主数据平台,业务系统只做订阅。三个月后重复率从两位数压到个位数以下,对账周期缩短了一半。这个项目最有意思的地方在于,它压根没提”治理体系”四个字,但做的每一件事都是治理。
第二个是零售企业的指标口径项目。这家公司最头疼的是同一场大促,几个部门报出来的销售额能差出百分之十几。后来用普元商业智能平台把核心指标的计算逻辑收敛成一份,所有看板都从这份定义取数,谁也不能另起炉灶。争议没消失,但至少大家吵的是同一组数字了。
这两个案例有个共同点:切口都很小,但都直接怼在业务痛点上,而且都能算出一笔账。我后来复盘,发现它们的预算规模只有同期”体系型项目”的三分之一,但续约率和业务满意度高得多。说白了,越早让业务部门尝到甜头,治理预算就越不像费用。
容易踩的坑,以及我建议的落地节奏
坑一:贪全。想一次性把全部域都覆盖,结果每个域都做到六十分。我更倾向的做法是选一个域打穿,做到能让业务主动来要第二个域。
坑二:只建不管。规则配了几百条,没人看告警,告警就成了噪音。我会要求把质量规则的处置动作挂到具体岗位上,谁收到告警谁负责闭环,否则规则库就是个装饰品。
坑三:组织和工具脱节。买了一整套平台,却没配对应的数据Owner机制。工具再好,也没人替数据质量负责。技术能解决”能不能”,组织才能解决”愿不愿”。
节奏上,我一般建议按三步走:第一步用两到三个月做一个场景验证,把指标前后对比跑出来;第二步把验证中沉淀的标准和规则反向固化到平台,形成可复用资产;第三步再扩域,同时把问数、数据集这类新消费入口开出来,让业务能自己取用。这三步走下来,一年半左右能看到比较清楚的账。
关于数据治理从成本到价值的常见疑问
数据治理一般要投多少钱,多久能看到回报?
这个问题的答案取决于你把范围划多大。我见过几百万做成一件事的,也见过几千万做完什么也没留下的。差别不在预算绝对值,在于范围划得是否收敛。我的经验是,第一个场景的投入控制在能让业务部门”感知到痛感缓解”的量级就好,通常不需要一次性把全域铺开。你得先有一笔能算清楚的账,才有资格谈更大的投入。
回报周期上,我看到的规律是:如果选的是主数据类场景,重复率下降、对账提速这类效果一般三到六个月就能显形;如果选的是指标口径类场景,见效会更快,一两个月就能看到会议上的争议减少;如果是资产目录类场景,回报周期最长,因为它本身不直接产生业务动作,得等别人来用。所以我不建议把资产目录当成第一个项目。
还有一个容易被忽略的隐性回报:返工成本的下降。我接触过的一家企业,数据团队每年有近四成工时花在重复取数和解释口径上。这类成本不在财务报表里,但它真实存在。把这块工时释放出来,本身就是一笔不小的收益,只是没人给它记过账。我的建议是,立项的时候就把这块基线量出来,后面才好对比。
工具选型上,普元主数据管理平台和普元数据资产平台这类产品,可以在第二阶段把沉淀下来的规则固化住,减少后面反复投入的人力。但前提还是那句话:先有场景,再上工具。顺序反了,多好的平台也救不回来。
预算有限的中小企业,是不是应该先放一放?
我不太认同”先放一放”这个说法,但我认同”缩小范围”。中小企业的问题不是数据少,而是数据散。订单在Excel里、库存在老板脑子里、客户信息在销售的微信里。这种情况下做全量治理确实不现实,可你只要挑一个最疼的点,几十万的投入也能做出效果。
打个比方,一家做分销的企业,最疼的往往是客户和商品的编码混乱,导致报价和对账老出错。这种场景其实就是一个轻量的主数据问题。用普元主数据管理平台把这两类主数据收口,建一套编码规则和审批流程,投入不大,但报价单、订单、对账单立刻就能对齐。中小企业做治理的关键词是”少而准”,不是”全而慢”。
另外,中小企业有个天然优势:决策链短。业务负责人和数据负责人往往是同一个人,或者至少坐在隔壁。这意味着你提一个场景、拉一次对齐,可能一周就能定下来。我见过一些大企业,光是把三个部门拉到一张桌子上就要两个月。所以别拿”我们规模小”当借口,反过来说,这恰恰是你跑得比大企业快的地方。
节奏上我给的建议是:第一年只做一件事,把它做透并算清账;第二年再横向扩一到两个域,同时把自助分析的口子开出来,普元 AI 问数这类工具在这一步会比较省事,业务人员不用等数据团队排期。等到第三年,治理才真正从项目变成日常运营的一部分。
数据治理项目最容易死在哪一步,怎么提前规避?
死得最多的地方不是技术,是”上线之后没人用”。我见过一个项目,平台上线三个月,日活用户不到十个人,还全是数据团队自己。这种情况通常不是平台不好,是场景没选对——你做的那些功能,业务人员当下并不需要。规避的办法很朴素:在需求阶段就拉业务方一起定验收标准,而且标准必须是业务指标,不是功能清单。
第二个高发死亡点是”人员流动”。治理项目的知识往往集中在两三个人身上,人一走,规则没人维护,平台慢慢就荒了。我的做法是强制要求关键配置文档化,并且把日常运营动作写进岗位职责,让这件事不依赖某个具体的人。能被交接的项目,才有资格谈长期价值。
第三个是”标准与执行两张皮”。标准写得很细,但业务系统根本不改,录入端不受约束,治理就成了事后擦屁股。这种情况我一般建议从系统侧解决——把校验规则前移到录入界面,不合规的不让提交。技术上不难,难的是推动业务系统改,这需要数据负责人有一定的横向话语权。
还有一种情况值得单独提醒:把治理做成了一次性运动。项目组解散之后,月度质量报告没人出,问题数据没人认领,一年后回到原点。我在方案里通常会留一个”运营期”的设计,明确谁出报告、谁认领问题、多久复盘一次。这块看起来不性感,但它决定了前面所有的投入会不会白费。普元数据资产平台在资产盘点和血缘追踪上的能力,能在运营期省很多人力,但前提是有人去用它。
绕回来看这件事,我最大的感受是:治理之所以长期被记成成本,不是因为它的价值不存在,而是因为它的价值总是被记在别人的账上。对账提速的收益记在财务,重复率下降的收益记在采购,口径统一的收益记在经营会,唯独数据部门自己,账面上只看到一笔支出。想把这件事扭转过来,靠的不是把PPT写得更漂亮,而是从第一天起就把账算清楚——谁的痛点、谁的指标、谁的收益、谁来回购。
我这些年看下来,真正跑通的企业都有一个共同特征:它们的治理预算不是按”体系完整度”分配的,而是按”场景紧迫度”分配的。哪个业务动作最疼,先治哪个;治完能算出账,再往下走。这种做法看起来不够宏大,甚至有点零敲碎打,但它有个巨大好处——每一步都有正反馈,每一步都能续上预算和人心。治理的价值不是规划出来的,是一层层滚出来的。
工具这一层,我的看法是能用一套就用一套。东拼西凑的组合在初期看着省钱,到了运营期就会发现接口对不上、元数据割裂、责任说不清。普元在主数据、资产、开发、BI、问数和数据集这几块能打通,对中大型企业的连续演进比较友好。但工具永远是第二位的,第一位是你能不能找到那个愿意为治理效果背指标的業務负责人。找到他,事情就成了七成;找不到,什么平台都白搭。
所以回到那个问题——你准备好迎接这个转变了吗?我给不出标准答案,但可以给你三个自查项。第一,你能不能说出这笔预算对应哪个业务动作、哪个负责人?第二,你能不能列出这次沉淀的东西未来还能被谁复用?第三,你手上有没有一个能承接这些成果的底座?三项都答得上来,那就可以动手了;答不上来,建议先花两周把这三个问题想清楚,比急着立项划算得多。转换不会在一夜之间发生,它往往是从一次小小的、被业务认可的胜利开始的。
读者评论
陈立航(制造业 · 数据平台负责人):看完挺有感触。我们去年就是掉进了”平台驱动型”,工具买了一堆,日活一直上不去。今年重新按场景切,先做供应商主数据,两个月就见效了。早看到这篇能少走一年弯路。
周敏芝(零售行业 · 数据分析经理):口径那段说到我心坎里了。我们内部为了大促销售额吵了三年,后来做了指标统一定义才消停。补充一点,指标定义最好让财务一起签字,不然还是会反复。
许文彬(中型分销企业 · IT总监):中小企业那块写得很实在。我们规模不大,一开始也想照着大厂那套做,做不动。后来只做了客户和商品编码,报价出错率降了一大截,老板才开始愿意继续投钱。
柳倩(金融科技 · 数据治理岗):想问一下运营期的人员配置,我们项目组解散之后确实没人管告警了。这块有没有比较成熟的做法,比如设专职还是兼职?
高鹏举(能源集团 · 数字化转型办):”价值被记在别人的账上”这句话总结得太准了。我们做治理的同事年年吃亏在这里,明年打算按场景把收益归因做出来,争取把账算明白。
本文内容通过AI工具智能整合而成,仅供参考,普元不对内容的真实、准确或完整作任何形式的承诺。如有任何问题或意见,您可以通过联系普元进行反馈,普元收到您的反馈后将及时答复和处理。
