★ FEATURED ARTICLE 1. 从DCMM说起为什么数据治理绕不开成熟度评估1.1 DCMM不是又一个IT治理框架先聊聊DCMM到底是什么。DCMM的全称是数据管理能力成熟度评估模型它跟传统IT治理框架最大的区别在于它把“以数据为中心”作为出发点评估的是一个组织在数据战略、数据治理、数据架构、数据应用、数据安全、数据质量、数据标准、数据生存周期这八个领域的管理能力而不是盯着服务器、数据库、中间件这些基础设施转。早些年很多企业聊数据治理聊着聊着就变成了“上平台、建系统、接接口”结果是ODS层盖了一堆数据仓库也搭起来了但数据口径还在打架取数还得靠人工写SQL领导问数据为什么不准没人能给出答案。这套PPT方案之所以值得参考是因为它没有一上来就讲平台和工具而是先用DCMM做了一次“体检”把问题放到八大能力域的框架里逐个定位再给出治理路径。这给人的感觉是完全不同的前者是头痛医头后者是先把整个人体的代谢系统做一次全面检查。另外一个理解DCMM的角度是“行业标尺”。这些年我在不同行业都见过类似诉求有的企业想搞清楚自己数据管理水平到底处在什么位置有的企业希望招投标时有数据能力证明还有的企业想借外部评估来推动内部变革。DCMM恰好解决了这三个问题它是一套能被量化评估的标准不是一个只能挂在墙上的理念。1.2 八大能力域一张地图读懂全部图谱既然DCMM的核心是八大能力域那就先把这张地图摊开。八个域不是随意堆出来的它们组成的逻辑线很清晰先定战略方向再做治理保障然后搭架构、建标准接着确保质量和安全最后通过数据应用把价值释放出来。如果你的视角是“数据从产生到使用再到退役”你会发现八大域正好覆盖了这条生命线。能力域核心关注点典型建设内容数据战略数据工作与企业战略目标是否对齐数据战略规划、数据战略实施、数据战略评估数据治理数据管理组织、制度、流程是否健全数据治理组织、数据制度建设、数据治理沟通数据架构数据模型与数据流转是否清晰数据模型、数据分布、数据集成与共享数据应用数据能否被便捷分析和服务化数据需求、数据开发、数据分析、数据服务数据安全数据在采集、存储、使用中是否合规受控数据安全策略、数据安全管理、数据安全审计数据质量数据是否满足业务使用要求数据质量需求、数据质量检查、数据质量提升数据标准数据定义、格式、编码是否统一业务数据标准、参考数据和主数据标准、数据元标准、指标数据标准数据生存周期各阶段数据管理活动是否规范数据采集、数据存储、数据维护、数据使用、数据退役从表格里能看得出来数据治理只是八大域中的一个域但标题里说的“治理体系”覆盖面远不止这一个域。实际操作中也是这个感觉数据治理组织建得再好看数据架构乱了标准没了质量差了安全漏了治理根本落不了地。所以方案把这些域放在一起本质上是在建一套完整的“数据管理操作系统”。在这八个域里我个人觉得最难的不是数据质量和数据安全而是数据战略。因为战略这件事牵扯到决策层如果企业高管只是口头说重视但预算、编制、考核都不向数据管理倾斜那你后面七个域做得再辛苦也很难持续。很多DCMM评估做到后面卡住的恰恰是数据战略这一域的“数据战略规划”能力项。1.3 成熟度等级从1级到5级意味着什么DCMM把每个能力项都分成五个成熟度等级从低到高分别是初始级、受管理级、稳健级、量化管理级和优化级。简单理解就是初始级数据管理活动基本靠个人经验没有统一规范项目做了就做了做完没人复盘。受管理级项目级的数据管理已经形成了一些规范但没有上升到组织级各搞各的。稳健级组织层面有统一管理制度、流程和责任人数据管理工作可以被考核。量化管理级管理过程可以量化能用数据分析来优化数据管理活动而不是拍脑袋决策。优化级持续优化数据和数据管理成为企业的核心竞争力甚至对外输出方法论。很多企业一上来就说“我们要过DCMM四级”这个说法本身就很值得警惕。成熟度的提升需要组织土壤光靠一次性项目冲刺是上不去的。我的理解是评估等级是结果不是目标真正的目标是把数据管理的短板补上让数据在业务里真正好用。55页PPT里一定也会涉及“现在在几级、目标定几级、差距在哪”的评估结论这比盲目追高要有意义得多。2. 把55页PPT拆开看一套成熟治理方案的骨架2.1 为什么是55页结构设计背后的逻辑把这套方案拿在手里你可能会想什么样的内容需要讲到55页我拆了几遍之后发现55页其实是一个很合理的容量。它不是在凑页数而是按照“为什么要做、差距在哪、怎么做、怎么保障”这条完整链路铺开的。你把它压缩成30页分域方案一定讲不透你把它拉到100页决策层根本没耐心听完。如果按内容序列去猜这套PPT的逻辑大概可以是这样的走向前面一小段讲背景和驱动力比如政策要求、业务痛点、行业趋势然后用几页介绍DCMM模型本身告诉读者“下面所有的分析都会用同一套标准语言”接着进入现状评估和差距分析这部分通常会用雷达图或者矩阵图把八大域的现状画出来再往后的重头戏就是基于差距输出治理目标、总体架构、分域建设方案最后是实施路径、组织保障和预期成效。这套结构最值得学习的是“先达成共识再谈方案”。很多治理项目翻车不是因为方案不好而是因为大家对“痛点是什么”都没达成一致。数据部门认为是质量差业务部门认为是口径乱高管认为是缺数据驱动决策的能力。如果PPT开头不把共识统一后面讲得再精彩听众也只是礼貌性点头。2.2 从现状评估到差距分析先承认问题再谈建设现状评估是整套方案里最基础也最容易做水的一块。做得好的评估能让人看完之后心生感慨原来我们数据管理水平确实一般。做得不好的评估就是找几个人填几张问卷最后画一张全绿的雷达图皆大欢喜。基于DCMM的评估一般会采用访谈、资料审查、系统抽查相结合的方式。访谈对象要覆盖决策层、业务中层和技术骨干因为不同层级对数据管理的感知完全不同。资料审查看的是制度、规范、流程这些“留痕”系统抽查则用来验证制度和现实是否一致——很多企业嘴上说着有数据标准打开系统一看相同客户编码在三个库里各叫各的这种就是典型的“两张皮”。差距分析输出最重要的一份东西是优先级清单。八个能力域不可能同时建一定有些域要先做有些域可以缓做。优先级怎么排我的经验是两大原则一是看业务痛点最集中在哪二是看建设难度和见效周期。业务痛点集中、并且快速见效的域优先启动比如数据标准化和数据质量它们几乎是所有数据应用的基础也是很多问题的根源。2.3 分域落地八大域的先后顺序和推进策略这55页PPT里最有含金量的部分应该是八大能力域的具体建设方案。如果只列出一堆概念和名词那方案就是“正确的废话”。真正好的分域方案会针对每一个域给出建设思路、关键动作、交付物和验收标准。从推进策略上看我比较推荐一个顺序先由数据战略统一方向和目标同时搭建数据治理组织来明确责任接着做数据架构梳理把系统、表、数据流向这些家底摸清楚然后启动数据标准化工作因为标准是质量、应用、共享的基础数据质量和安全可以在中期同步推进数据应用则要贯穿始终每个阶段都要让业务看到数据带来的改变。这里有个容易忽略的点并不是每个企业都需要在八大域均衡发力。比如一家刚完成信息化建设的企业最需要的是数据架构、数据质量和数据标准因为基础还没打牢而一家数字化程度较高的企业可能更需要数据应用、数据安全和数据战略来提升附加值和合规能力。方案里如果能体现这种“对症下药”的思想比机械地一个域写两页要高级得多。2.4 从方案到资源治理策略、组织与保障如何设计治理体系建不建得起来关键看组织其次看考核。55页PPT最后几页通常都会讲保障体系但很多方案会写得比较虚比如“领导重视”“全员参与”这类话听着对实际没用。组织层面我建议梳理三层结构。决策层是数据管理委员会负责定战略、批预算、出原则必须有足够话语权的领导参与管理层是数据管理的牵头部门负责日常协调、制度细化、任务派发很多企业会放在数据管理部或信息化部门执行层是各业务部门和IT部门的对接人负责本领域的数据标准执行、质量整改和需求衔接。三层都有人事情才转得起来。考核机制同样不能缺席。我给不少项目设计过数据治理的评分卡维度包括元数据覆盖率、数据质量问题闭环率、标准执行偏差率、数据安全事故数、数据应用调用次数等。这些指标全部要落到部门和具体责任人和绩效挂钩。没有考核的治理等同于没有牙齿的老虎看着吓人实际不咬人。3. 从PPT到落地我实际操作下来的关键路径3.1 第一步数据盘点先把家底摸清楚我接手任何一个数据治理项目做的第一件事永远是数据盘点。因为你不盘点就不知道企业到底有哪些系统、哪些库、哪些表不知道哪些数据在用、哪些数据是垃圾。没有盘点的治理方案就像不知道家里有多少东西就开始搞收纳最后一定是刚收拾完又乱回去。盘点怎么做最接地气的办法是先从系统清单出发把企业现有的业务系统、数据库、接口清单全部梳理一遍。接着做元数据采集把每张表的表名、字段、类型、含义、数据量、更新频率这些基础信息捞出来形成一份数据字典。再往下就要找业务认领了让每个业务域确认这些数据是不是自己的、叫什么、怎么定义这步其实就是在打数据标准的基础。我在一个制造类客户的现场做过盘点光系统就有三十多个数据库十几种类型很多老系统的表没有注释字段命名全靠猜。那轮盘点我们花了四周时间产出物是四百多张表的资产清单。之后建立数据资产目录就顺理成章了业务部门检索数据时终于有一个统一的入口。但这里要提醒一句盘点的产出不能只交付一份静态文档必须把它沉淀到工具里后面才能持续更新否则半年之后就又是一笔糊涂账。3.2 第二步数据分类分级安全与使用的平衡数据分类分级这两年关注度越来越高因为数据安全的监管要求越来越明确。分类分级并不是把数据锁起来就完事而是要在安全和使用之间找到平衡点。常见做法是把数据按业务域分类比如财务类、人事类、研发类、采购类、销售类等再按敏感程度分级比如公开级、内部级、秘密级、机密级。实际操作中分类相对好做因为有业务驱动分级比较有争议因为业务方普遍担心“定高了自己用起来麻烦定低了又怕出事”。我的建议是不追求一步到位先抓重点识别出核心业务数据里的敏感数据比如客户个人信息、银行账号、身份证明、健康信息、薪酬数据等把这些重点数据的权限边界、脱敏策略、导出审批规则先立起来。其他数据可以按默认级别处理后续逐步精细化。有一类现象很常见就是安全部门为了保证不出事把大量数据统统定成秘密级最后业务取数要走一遍申请审批流程一个简单分析需求要等一周。这种“一管就死”的局面会反噬治理项目让业务觉得“你们说数据驱动业务结果数据越来越难用”。所以在方案里强调平衡非常关键分类分级的粒度要贴合业务场景审批流程要分级授权不能让所有需求都跑到最高审批人那里。3.3 第三步数据标准和数据质量两条腿走路数据标准建设最忌贪大求全。有些项目团队上来就要建几百个数据元标准结果搞了半年全部卡死在评审环节。我的做法是先挑核心主数据标准客户、供应商、物料、人员、组织、参考数据标准枚举值、编码规则、核心指标标准收入、成本、利润等口径解释。这三个优先级最高因为它们直接影响数据能否跨系统对齐。数据质量工作要跟标准同步走因为它俩是一体两面。质量标准解决“怎么算好”数据质量解决“好不好”。最常见的质量维度无非四类完整性、准确性、一致性、及时性。完整性看有没有缺漏准确性看数值对不对一致性看不同系统取值是否相同及时性看数据更新是否够快。每一类都需要量化规则比如“客户信息完整率不低于98%”“薪酬接口数据次日凌晨6点前完成同步”这类可度量的指标。质量问题的闭环处理是一套组合拳问题发现后要派发给责任部门明确整改时限完成后复核再定期通报。很多项目做到“发现问题”就停了缺少派发和复核报表出了质量问题数但没有后续业务就慢慢失去信任。我做项目时一定会建一个问题挂账机制按“未派发、处理中、已整改、已复核”四个状态跟踪月度在治理例会上晒一次效果比单纯出报告好得多。3.4 第四步治理平台与常态运营机制谈到治理平台很多人的第一反应是买一套“数据治理工具”回来。工具当然重要但不应该一上来就追求大而全。我的选型原则是四个字轻量起步。先解决元数据管理、数据质量管理、数据安全管控三个核心场景能跑通就行后面有需求再逐步扩展数据服务、数据资产门户、数据血缘追踪这些模块。我见过不止一家企业平台买回来后真正在用的模块不到一半因为需求没想清楚功能上了没人用最后变成采购部门的一笔资产、IT部门的一个运维负担。如果你要重来一次最实际的路径是先用开源或自研的简单工具把元数据采起来用脚本跑数据质量规则用表格管理权限清单。等量级上来、流程跑顺了再评估是否需要商业工具的调度能力、血缘分析能力和数据服务编排能力。治理平台是工具不是目的本质还是借助它把组织、制度、流程固定下来。常态运营机制是治理可持续的最后一块拼图。我强烈建议建立三个例行机制月度发布数据质量报告季度开一次治理专项例会年度做一次DCMM成熟度复评。前两个机制是保持热度防止事情干着干着就凉了第三个机制是用来检验一年来的治理效果看能力域评分有没有提升下一步该往哪个方向投入。这套循环跑起来治理才真正成为企业运营的一部分而不是一次性的项目。4. 常见问题和避坑实录4.1 治理变成了数据部门的大合唱这个问题在绝大多数企业都会出现具体表现是开治理推进会时几十号人坐在会议室里业务部门的人在刷手机IT部门的人在做记录数据部门的人在卖力演示所有整改事项最后都落在数据部门自己头上。原因是“数据治理”这四个字听起来就是IT的事业务部门始终觉得数据是技术问题。解决思路只有一条让业务部门因为数据问题感受到疼也让业务部门因为数据改善得到甜。怎么实现可以把业务最痛的数据问题列成清单比如财务月结数据不准导致报表反复调整、销售线索重复导致跟单效率低、成本测算差异大影响投标报价把这些问题的责任主体明确指向业务部门。考核和激励同时挂钩谁的数据质量差、整改不及时就对谁的绩效产生直接影响。我在实操中还会用一个小技巧每次治理例会都请业务负责人来讲本领域数据问题的整改情况让他们从旁听者变成汇报者状态完全不同。4.2 制度有厚厚一叠却没人照做很多治理项目都会产出一大堆制度文件比如数据管理总纲、元数据管理办法、数据质量管理办法、数据安全制度、数据标准管理细则打印出来能装订成手册。但现实很残酷制度写完放在OA里点击量屈指可数实际执行更是无从谈起。问题的根源在于制度没有嵌入流程也没有落到工具。你规定“数据变更必须走审批”但流程不在线上系统里大家还是口头打个招呼就改了。你规定“指标口径必须统一”但指标系统里仍然允许各团队自定义新增根本没有系统校验。我后来的经验是任何制度出台都必须配套一个系统功能让规则变成线上不可绕过的步骤。如果暂时没有系统实现就先用简单表单工具强约束让流程“先线上化、再逐步自动化”。4.3 标准定得太理想业务跑不齐数据标准落地难是所有数据治理项目共同的痛点。常见的情况是咨询团队根据行业标杆设计了一套完美标准比如客户主数据要求有几十个必填字段编码规则要完全统一。但到了实际系统里老系统字段根本存不下那么全历史数据又脏又乱新标准一上线业务根本跑不动。我的处理思路是“分阶段贴近现实”。第一轮标准可以适度收紧但不是一步到位比如先统一编码规则和高频必填字段其他字段标记建议非强制同时做存量数据清洗把那些严重脏、乱、重的历史数据先治理出一条干净的版本。第二轮再逐步增加强制字段和校验规则。记住一个原则标准是给业务用的不是放在文档里供着的一个能被90%场景使用的简版标准其价值远远大于一个永远停留在纸面上的完美标准。4.4 治理做完业务没有感知价值看不见这是最致命的问题因为它决定了项目能不能继续拿到资源。数据治理做了大半年数据团队天天在加班但业务部门感觉不到变化高管看不到数据带来的效率提升或成本下降。此时再提明年要增加预算决策层大概率会犹豫。解决这个问题要靠“早期速赢项目”。在治理方案启动时就要选定一两个高频、高痛点的数据场景定向攻坚争取两三个月内让业务有明显体感。比如销售报表原来手工整合要靠两天治理之后系统自动输出只要十几分钟月结关账原来要五号才能完成标准化之后二号就出数重要经营指标原来口径各说各话治理后统一在指标库中一键取用。这些成果必须在治理例会和项目汇报中反复出现让管理层的直观感受是“数据治理确实带来了东西”而不是“花了一堆钱建了一堆制度”。4.5 踩过几次坑之后的几点经验说了这么多问题最后分享几条我自己的习惯。第一项目一开始就要先把“数据资产目录”立起来哪怕只是一个简陋的Excel表也要有因为它是所有人后续沟通的共同语言。第二不要等到所有制度都写完才开始推落地而是先把一两个域的流程跑通用样板间效应带动全局。第三每次汇报都少讲“我们建了什么”多讲“业务因此改变和提升到了什么”数字化项目最忌讳自嗨式汇报。我个人觉得CDMM这套框架最高明的地方不是提供了什么新工具而是建立了一门“行业通用语言”。有了这门语言数据部门可以跟高层讲投入产出跟业务讲责任边界跟IT讲建设优先级。不管你是不是准备拿DCMM的等级证书把八大能力域在自己脑子里过一遍再和企业的实际问题对应起来你对数据治理的理解都会上一个大台阶。后面如果再有人给你递来一份五六十页的数据治理方案你大概一眼就能看出它究竟是真功夫还是花架子。
阅读完成 · 觉得有帮助？
