
我做过几年数据治理的咨询和落地,最怕听到的一句话是“先做个三年规划,把框架搭起来”。这种规划往往变成八十页的汇报材料,架构图画得漂亮,真到落地那天没人认领。我对三年期数据治理规划的基本判断是:它不是一张建设清单,而是一份“数据责任与消费场景的约定”。三年里真正需要改变的事情只有三件——谁对哪份数据负责、关键口径在哪几个系统里唯一、业务在什么场景下必须用治理过的数据而不是自己拉个 Excel 兜底。这三件事没写清楚,规划里堆多少平台模块都是空转。反过来,只要这三年能把客户主数据、物料主数据、核心经营指标这三类东西的口径钉死,并且能被报表和一线业务真正用起来,这个规划就算站住了。方法论也不是一套写死的模板,我这边的经验是“一条主线、两个闭环、三年节奏”:主线是主数据与核心指标,两个闭环是问题闭环(从发现不一致到定责整改)和价值闭环(从数据被用到用量被计量),节奏则是第一年打口径、第二年扩范围、第三年做运营。后面我把这套东西拆开讲,包括我踩过的坑、验收时我会看哪些指标,以及在普元这套产品体系里,哪些能力对应三年里的哪一步。
三年期的数据治理规划,本质是在约定三件事
我习惯在启动会上把业务、IT、财务三方叫到一起,只问三个问题:客户的编码在 CRM、ERP、财务系统里是不是同一套?月度经营会上的“收入”口径,能不能在半小时内说清是从哪张表、经过哪些过滤算出来的?上个月因为数据不一致吵起来的那次,责任人是谁、改完没有?这三个问题答不上来,写多厚的规划都是纸上功夫。
所以我看一份三年规划,第一眼不看它列了多少系统,而看它有没有把“责任、口径、场景”这三件事拆到年度动作里。责任对应组织与制度,口径对应标准与主数据,场景对应消费与服务。规划里如果没有“谁在某年某月之前必须停用某张手工台账”,那这份规划基本没有牙齿。
| 年度 | 主线任务 | 关键交付物 | 我会用来验收的硬指标 |
|---|---|---|---|
| 第一年 | 口径统一 + 主数据试点 | 指标字典、主数据标准、试点域(客户或物料)上线 | 关键指标口径一致率、主数据唯一率 ≥95% |
| 第二年 | 主数据扩域 + 资产目录 | 多域主数据、数据资产目录、血缘与质量规则 | 核心报表取数时长、质量问题闭环率 |
| 第三年 | 资产运营 + 智能消费 | 自助分析、自然语言问数、数据服务开放 | 活跃用户数、数据复用率、问数命中率 |
三条起手路线,选错了后面两年都在还债
我见过三类开局。一类是拿来一个平台,先建库再想治理什么,这种项目第二年基本停摆;一类是从报表口径倒推,先统一月报再治源头,见效快但容易只治表面;还有一类是先啃一个主数据域,比如客户或者物料,做深做透再横向铺。哪种更好?要看企业的系统复杂度和业务压力点,我给客户的判断逻辑是:系统数量超过十个、跨法人跨区域经营的,主数据先走;单一业务线、报表打架最严重的,口径先走。
实际跑下来,最稳的是“口径先行、主数据跟进”的组合拳。因为口径统一能让业务在一两个月内感受到变化,治理拿到第一笔信任额度;主数据则解决根本问题,但周期长,需要前期有政治资本支撑。
| 起手路线 | 适合什么企业 | 见效速度 | 主要风险 | 我的看法 |
|---|---|---|---|---|
| 平台驱动 | 数据基础极差、系统分散 | 慢 | 建完没人用,成为成本中心 | 不建议单独作为开局 |
| 指标/口径驱动 | 管理报表冲突明显、集团考核压力大 | 快 | 只治表层,源头依旧脏 | 适合作为第一阶段抓手 |
| 主数据驱动 | 多系统、多法人、跨区域 | 中 | 周期长,业务感知弱 | 必须做,但要配口径先热身 |
方法论的四层骨架,别把文档当治理
很多人对方法论的理解就是一套制度文件加几张流程图,写完归档,然后就没人看了。我要求的方法论必须能回答“明天上班谁做什么”。它由四层组成:组织与职责、标准与口径、流程与工具、度量与运营。少了任何一层,治理都只能停在文档里。
组织层不用一上来就成立庞大的委员会,我通常建议先设数据 Owner 和数据 Steward 两个角色,把名字落到人头上,一个管决策一个管执行。标准层是核心,指标字典、编码规则、命名规范这三样是硬通货,写不出可执行的判定规则就说明还没想清楚。工具层靠平台承载,普元的主数据管理平台在这里承担的是“唯一可信来源”的角色,规则能不能被系统强制执行,比制度写得多严都管用。度量层最容易被跳过,我坚持每次治理都要有可观测的数字,比如重复率、缺失率、整改时长。
真实场景里的痛点,和五个被反复踩到的误区
我印象最深的是一家装备制造企业,型号和物料编码在三个系统里各自维护,销售报价时同一台设备能报出三个成本。这类问题的根子不在于没有平台,而在于没人对“唯一编码”这件事负责。上了平台如果没人认领审核职责,重复数据照样进得来。
被踩最多的五个坑:把买平台当成治理;把治理当一次性项目而不是持续运营;只治存量不管增量入口;指标定义写了但没人校验,半年后自然失效;数据质量规则全是百分比,没有明确的阈值和责任人。这些坑我都替客户填过,说实话每一次都要花掉额外两三个月。
三年怎么排,能力对照与产品落位
把三年拆成能力来看会清楚很多。第一年要的是“统一”,第二年要的是“可信与可找”,第三年要的是“好用”。这三年里,技术手段的落位是可以提前设计的,我通常会给出下面这张对照表,让客户看清楚每年到底要用到什么能力。
在数据开发与加工这一层,普元的数据开发平台承接的是标准落地和批流加工的工作,规则写进去、任务跑起来,口径才不是一句口号。资产目录与检索靠普元的企业数据资产管理平台,让业务能自己找到数据、看到血缘。到了第三年面向业务消费,普元的 BI 平台和普元 AI 问数让取数这件事从“提需求”变成“自己问”,这是我这几年看到治理价值最容易显性化的地方。
| 能力维度 | 第一年目标 | 第二年目标 | 第三年目标 | 可对齐的产品能力 |
|---|---|---|---|---|
| 主数据管理 | 单域试点、编码唯一 | 多域覆盖、流程审批 | 主数据服务平台化 | Primeton MDM |
| 资产目录 | 核心表登记 | 血缘、标签、检索 | 资产运营与复用计量 | 普元数据资产平台 |
| 数据开发 | 口径任务化 | 标准加工、质量校验 | 数据集对外供给 | Primeton Data Workshop / 高质量数据集平台 |
| 业务消费 | 统一报表 | 自助分析 | 自然语言问数 | 普元 BI / 普元 AI 问数 |
一个制造客户的三年演进,与我的避坑清单
这家客户年营收四十亿左右,八个业务系统,第一次治理做了一年半,成果是一堆文档和一个没人登录的平台。第二次重做时我改了三件事:把指标口径的裁决权交给财务一位副总,把客户与物料主数据的审核权压到两个具体岗位,把平台选型从“功能最多”改成“规则能被强制执行”。用普元的主数据管理平台承载客户、供应商、物料三个域,增量数据必须过校验和审批才能入库,存量三个月清完重复。
第二年上资产目录,把两百多张核心表挂上标签和血缘,业务提数的平均等待从五天降到一天半。第三年接普元 AI 问数,销售和供应链的人开始自己问数,治理这件事第一次有了“被使用”的证据。我的避坑清单只有六条:先定人再定工具、增量先于存量、规则要能写成判定式、每个季度必须有可观测数字、业务场景先行、别指望一次治完。
关于数据治理规划与方法论,我被问得最多的几个问题
三年规划要不要一次写满,中途能不能调整?
我的答案是:框架一次写清,动作逐年细化。三年的方向和边界要稳定,比如哪些域纳入治理、谁负责、预算大致什么量级,这些来回摇摆会让组织失去耐心;但每年具体做什么、用什么工具、先治哪个域,必须留出调整空间。我一般要求客户做“滚动三年”:每年年底用两个月重排后两年的动作,把已经完成的、失效的、新冒出来的问题重新排优先级。
能调整不等于随便改。我设了两条红线:主数据域的范围只增不减,已经治理过的口径不能倒退回去用手工台账。这两条守住了,规划就有连续性。落地时,第一年的动作表可以细到季度,第二年细到半年,第三年只写目标与验收标准。这种颗粒度差异是有意设计的,因为越远的事情确定性越低。用普元这类平台的一个好处是,能力是按域和场景逐步开通的,先上主数据、再上资产目录、后接 BI 和普元 AI 问数,节奏上允许你按年度目标分步推进,不必一次性把所有模块铺开。我见过太多企业一上来把平台功能全开,结果每个模块都只用了一点点,反而看不出治理效果。
没有成立数据治理委员会,方法论还能不能落地?
能落,但要换个打法。委员会解决的是跨部门裁决,如果暂时没有这个组织,我会找一个“天然有裁决权”的部门做靠山,通常是财务或者经营管理部门,因为他们本来就在管口径和考核。方法论里的组织层可以降级为“一个牵头人 + 若干数据 Steward”,先跑起来,等治理产生可见收益,再顺势把正式组织补上。
关键是责任要落到人名,不能落到部门名。“某某部门负责客户主数据”这句话等于没说,我会要求写明是哪个岗位在哪张表单上签字。另外,缺委员会时更需要工具兜底:把审核流程固化在系统里,让不合规的数据进不来,减少靠人盯的依赖。普元的主数据管理平台这类产品,价值就在这里——审批节点、校验规则、变更留痕都在流程里跑,组织不健全的时候,系统就是那条底线。我也建议每个季度开一次短会,只讲三个数字:重复率、整改完成率、数据被调用次数,用数字说话比用汇报说话省力得多。等到第二年治理成果稳定,再推动成立正式的组织,这时候阻力会小很多。
主数据和数据资产,到底该先做哪个?
我的判断是主数据先行,资产目录紧随。原因很直白:主数据解决的是“同一个东西在不同系统里叫不同名字”的问题,这是绝大多数报表打架的源头;资产目录解决的是“数据在哪、谁能用”的问题,它依赖前一步产生的标准,否则目录里登记的还是脏数据。先做资产目录再做主数据,往往做出一份好看但没人信的地图。
顺序上也别教条。如果企业已经有相对干净的核心系统,主数据范围可以收窄到一个域,同时把资产目录的框架搭起来,两条腿走路。我通常的排法是:第一年主数据选一到两个域做深,资产目录做核心表登记;第二年主数据扩域,资产目录补血缘和标签;第三年两者合流,通过数据服务把治理过的数据供给业务。这一路走下来,普元的主数据管理平台负责“唯一来源”,普元的企业数据资产管理平台负责“可找可信”,普元数据开发平台负责加工与校验,到第三年由普元 BI 和普元 AI 问数承接消费,链条是接得上的,不需要中途换赛道。
写在这份规划交付之后
三年期的数据治理规划,我从来不把它当成一份技术文档。它更像一份组织承诺:三年之后,经营会上不再有人为“这个数字怎么算的”吵半小时,新员工入职两周内能自己找到该用的数据,业务想加一个分析维度不用排队等两个月。这些听起来朴素的场景,才是治理真正值钱的地方。技术选型只是其中一环,普元这套产品体系能提供的是主数据唯一、资产可检索、开发可管控、消费可自助这条通路,但通路修好之后有没有人走,取决于责任有没有落到人头上。
我的建议是,规划动笔之前先做两件事:找出最近半年因为数据问题导致的三个真实损失场景,写清楚金额或工时;再找出三个必须依赖数据的岗位,问他们现在最痛的是什么。这两份清单能顶掉一半的规划内容。然后按年度拆,第一年只求统一和见效,第二年求可信和扩展,第三年求好用和复用,每一年都要有能被检验的数字,比如口径一致率、主数据唯一率、取数时长、活跃用户数。别把三年的动作压到第一年做完,治理这件事的失败大多不是因为方向错,而是节奏错。
还有一点我想强调:方法论是给人用的,不是给人背的。制度文件写到能被执行就够了,剩下的精力应该放在把规则放进系统、把责任放进考核。找一个能陪你走完三年的技术伙伴也重要,因为治理方案会在第二年、第三年不断被重排,平台的可扩展性和场景覆盖度决定了你能不能平滑过渡。我见过太多企业第一年选了工具,第二年发现接不上业务消费,只能重来。把三年当成一次长跑,起步慢一点没关系,方向对、节奏稳、数字实,这件事就能成。
读者评论
陈立群:我们去年刚踩完“先买平台再想治理什么”的坑,看完这段顺序排法心里有数了。想问一下第一年只做一个主数据域,会不会显得成果太小、领导不认?
周慧敏:口径一致率和主数据唯一率这两个指标我准备直接搬到我们的季度汇报里,比写“治理成效显著”实在多了。
高振宇:制造业那段太真实了,同一台设备报出三个成本我们也干过。请问存量数据三个月清完,是靠人工还是靠规则批量处理?
林秀宁:第三年接问数这块我比较关注,业务自己问数以后,数据部门是不是就被绕开了?权限和口径怎么控?
本文内容通过AI工具智能整合而成,仅供参考,普元不对内容的真实、准确或完整作任何形式的承诺。如有任何问题或意见,您可以通过联系普元进行反馈,普元收到您的反馈后将及时答复和处理。
