数据治理做久了你会发现一个挺有意思的规律:决定一个数据治理项目生死的,往往不是平台跑得有多快,也不是制度写得有多厚,而是组织里那层看不见摸不着的数据治理文化。这次《数据治理概论》连载正好翻到了第10章,全书用67页的篇幅来展开这个话题,我一开始觉得有点夸张,后来对照自己做过的项目,才明白这一页一页都是冲着企业里的真问题去的。
前几天和一个做数据治理项目的朋友吃饭,他说项目上线三个月,制度发了两轮,数据平台也搭好了,可一线就是不填数。我问他:你给业务讲过为什么要填这个数吗?他说没时间。我说问题可能就出在这里。数据治理文化听起来很虚,但几乎所有治理项目卡壳,都卡在这个"虚"的东西上。这篇文章把这一章里最值得琢磨的内容做一个落地化的解读,配套一些我自己的实操体会。想推进数据治理、又觉得文化无从下手的从业者,或者正在写数据治理规划的朋友,应该都能从里面找到点能直接用的思路。
1. 为什么数据治理文化是整套体系的灵魂
1.1 数据治理体系里,文化到底站在哪
刚接触数据治理的人,很容易把注意力全放在数据平台、数据标准、数据质量规则这些"看得见摸得着"的东西上。这是人之常情,毕竟制度的落地效果可以用考核来量化,平台的性能可以用指标来衡量,唯独文化这件事,不好量化,也就容易被排到优先级列表最末尾。但做了几年数据治理项目之后,我的感受刚好相反:数据治理文化不是一个独立的功能模块,而是让所有治理机制运转起来的一套底层操作系统。
经典的治理框架里通常会包含数据战略、数据组织、数据制度、数据标准、数据质量、数据安全,以及贯穿始终的文化与沟通。组织里经常能看到这种情况:数据标准文档发布了一套又一套,认责矩阵也画得清清楚楚,但一线人员填数的时候还是凭感觉。问起来原因,多半是"不知道这个标准有什么用""反正没人真的看"。这种时候,问题不在标准本身,而在标准背后没有形成一种共同认可的数据价值观。第10章用67页来展开文化这件事,我翻完才意识到,它把文化放在这么重的位置,是因为它看到了大量项目在制度之后停滞不前的真相。
对照自己经手的项目,这个道理其实很朴素。平台和制度是治理的骨架,文化是肌肉和血液。没有血液供给,骨架搭得再标准,也不过是一副空架子。数据治理这一章之所以要把文化单独拿出来讲,核心目的就是提醒所有做治理的人:别光盯着交付物,先看看组织里的人到底怎么想。
1.2 有文化和没文化的组织,运行差距到底有多大
同样一套数据治理流程,放到两个不同文化的组织里跑,结果可以天差地别。我见过一个有数据文化氛围的组织。业务人员在系统里发现客户主数据有重复,第一反应不是绕过,而是直接在数据质量平台上提了一个工单,并且主动把重复记录的两条编号一起附上。数据治理团队收到之后,顺着工单找到责任人,当天就完成了合并,还在周报里把这个案例列成了全员数据质量共建的正面示例。这样一个闭环,看起来简单,背后是整套文化在支撑:大家默认数据是公共资产,发现问题人人有责。
另一个组织就完全是反例。同样的问题,业务人员发现了,但觉得这个数据不归自己管,提了工单还要被追问,干脆选择沉默。数据治理团队自己也忙,质量问题反馈通道形同虚设。最后客户数据越积越乱,等到做客户画像项目的时候才发现,真正能用的记录不到六成。同样是数据治理流程,两个组织的差距不在流程设计,而在文化氛围带来的默认行为差异。
这种差距还会自我强化。有文化的组织,数据问题被及时反馈和修正,数据越来越可信,也就有更多人愿意用数据做决策,形成正向循环。没文化的组织,数据没人维护,质量越来越差,越来越没人敢用,最后连数据仓库都没人访问。这个飞轮转起来,方向一旦错了,靠一两个制度很难扳回来。遇到这种情况,我的建议是先别急着加制度,先想想怎么把飞轮朝另一个方向推一把。
1.3 只靠制度强推,为什么总在半年后反弹
有人可能会说,制度也能约束行为,文化不强的组织先靠制度推不就行了?我见过太多"制度先行"的案例,结果往往是这样的:数据质量考核指标刚上线的时候,效果立竿见影,很多人的填数准确率明显提升,因为怕被扣分。但半年之后问题开始冒出来——数据填报出现"合规式表演",表面看字段都填了,内容却经不起推敲;有问题不愿意上报,因为报了说明你管理不到位;跨部门的协调邮件越来越少,大家都按最保守的方式处理数据。
制度的本质是外部约束,它能改变行为,但改变不了行为背后的认知。一旦外部约束力度减弱,或者换了一个管理者不再盯着,行为就会迅速回退。文化的作用正好相反,它把"为什么要这样做"变成共识,把数据管理的动作内化成一种习惯。制度解决的是"不得不做",文化解决的是"愿意做"和"知道为什么做"。这也是为什么成熟的治理体系从来不把制度和文化割裂开来——制度本质上是文化的初级表现形式,当制度被广泛接受并自觉执行,它就成了文化的一部分;而文化反过来又会持续修正制度,让规则更加贴合实际。
如果说制度是给组织装上了刹车片,那文化就是让每个司机都本能地知道什么时候该踩刹车。没有文化的组织,制度写了十页纸也挡不住一次抢跑;有文化的组织,哪怕制度只有三页纸,执行效果反而更好。这是我做了几个项目之后,对"制度与文化"关系最直观的体会。
2. 数据治理文化的核心构成与成熟度评估
2.1 文化的三层结构:理念层、制度层、行为层
要建设数据治理文化,首先得知道它由哪些部分组成。我习惯把文化拆成三层,类似一座冰山。水面之上是行为层,也就是组织中每个人跟数据打交道时的具体动作,比如是否按标准填写字段、质量出问题时是否上报、做决策前是否会先看数据。这是唯一能直接被观察到的部分,也是大多数人判断"一个组织的文化怎么样"的依据。
水面之下,第一层是制度层,包括数据管理制度、标准规范、认责矩阵、考核办法等。制度是人写出来的,体现的是组织对"数据应该被怎么管"的正式回答。制度层比行为层稳定,因为它是成文的,但制度层有一个弱点:它只在大家主动遵守时才有效。再往下,隐藏最深的,是理念层,也就是组织对数据的基本认知和价值观,比如"数据是资产还是负担""数据是公共资源还是部门私有财产""数据质量出问题应该追责还是掩盖"。理念层很少被写下来,却最深刻地影响着制度设计和行为产生。
三个层次之间存在传导关系:理念层决定制度层怎么设计,制度层又持续塑造行为层;反过来,行为层的长期改变也会慢慢影响理念层。拿数据质量举例就更清楚。如果组织在理念上认为"数据是业务运营的副产品",那制度多半不会给数据维护留足够资源,一线人员行为自然就是"差不多就行";反之,如果理念上认为"数据是有价值的资产",制度上就会配套质量标准、责任划分、质量考核,最终一线人员才会形成"主动保证数据准确"的行为习惯。所以做文化评估的时候,不能只看大家嘴上怎么说,要看行为背后的默认假设。
2.2 数据治理文化成熟的五个阶段
判断组织的数据治理文化成熟度,我会先看它处在哪个阶段。参考了不少成熟度模型的思路,再结合自己项目里的观察,我把文化分成了五个阶段:
| 阶段 | 阶段名称 | 典型特征 | 一句话写照 |
|---|---|---|---|
| 一 | 对立孤岛期 | 各部门各自管理数据,互不共享,出现数据问题互相推诿 | 数据是我部门的,凭什么给你 |
| 二 | 被动合规期 | 制度和考核上线,大家为了应付检查而填数、纠错 | 只要不被扣分就行 |
| 三 | 主动管理期 | 业务部门开始主动关注数据质量,主动提出数据需求 | 数据质量不好,影响我自己用 |
| 四 | 协同赋能期 | 跨部门围绕数据协同,数据作为资产被纳入经营讨论 | 我们需要一套共同的数据语言 |
| 五 | 数据驱动期 | 数据文化成为组织本能,决策默认看数据,数据问题自动闭环 | 先看数据再说 |
判断组织处于哪个阶段,不能单靠问卷,要用行为来验证。比如去看各部门提交的数据问题工单数量:如果几乎为零,可能不是没有问题,而是没人愿意提。再比如去观察数据质量考核结果是否长期"全绿",如果所有指标都好得异常,多半有人在填数上做了表面文章。这些都是比问卷更真实的文化信号。从阶段一到阶段二,靠制度通常就能推动;从阶段二到阶段三,需要激发利益认同;从阶段三到阶段五,则要依靠领导力、协作机制和持续的价值呈现。很多组织在第二阶段卡很久,不是不够努力,而是把文化问题单纯当成了制度问题在解。
2.3 量化评估:把文化从"感觉"变成可以观测的指标
文化听起来不可量化,但作为管理对象,必须找到可以观测的锚点。我在评估组织的数据治理文化时,会重点盯五个维度:领导力、共识度、行为渗透率、知识覆盖率和协作机制。领导力看高管层是否真的把数据当资产来管,比如数据治理议题在管理层会议中出现的频率;共识度看大家对数据认责和数据标准有没有一致认知,可以通过访谈来判断;行为渗透率看制度发布后,实际业务动作里有多少真正按制度执行;知识覆盖率可以用数据素养培训的覆盖率来近似;协作机制看跨部门数据问题能否通过明确流程快速闭环。
具体操作上,我一般会设计一份简单的诊断问卷,只在管理层访谈和部门骨干访谈中使用,不用做全员普查。问题大概围绕这么几个方向:你所在部门的数据由谁负责质量?数据质量出问题第一反应是什么?你上一次主动使用数据做决策是什么时候?跨部门申请数据走什么流程,顺畅吗?公司发了哪些数据管理制度,你能说出三条吗?这些问题的答案本身没有对错,但能帮助判断这个组织文化的阶段。
需要提醒的是,文化评估不要做成考试,更不要拿评估结果排名通报。一旦大家知道评估结果影响绩效,接下来的答案就会变成标准答案,测出来的就不是文化,而是大家对你评估目的的猜测。文化评估的正确用法,是给自己画一张现状图,找到最值得投入的改善点。我在项目里,第一周基本都在做这件事,磨刀不误砍柴工。
3. 建设数据治理文化的关键抓手与实操方法
3.1 把数据治理委员会从"通报会"开成"决策会"
高层支持这件事,几乎所有数据治理规划里都会写,但能不能真的落地,差距很大。我见过不少组织成立了数据治理委员会,章程写得很完整,但开起会来,实际上是数据部门向各部门领导汇报进度,汇报完就散会,领导们点点头,什么问题都没有真正决策。这种委员会开一百次也不会对文化产生任何影响。我自己带的项目,会刻意做一件事:每一次委员会会议,都必须带着决策议题来。
具体做法是,每次会议纪要后面附一份决策清单,列清楚本次会议做了哪几项决策、每项决策的责任人是谁、完成时限是什么时候。如果一次会议开完,决策清单是空的,那就说明这个会没必要开。真正有效的委员会,会当场确认某个数据域的Owner是谁,会当场决定跨部门数据标准的争议按哪个口径执行,会当场拍板数据质量整改的预算来源。当高层开始用决策来推动数据工作时,组织的文化信号就会非常明确:数据治理不是财报里的一个口号,而是管理层真正花时间拍板的事。
还有一个比开会更有效的高层动作:公开处理一次数据事件。我做过一个项目,公司有个人擅自从生产库导出了敏感数据用于私下分析,领导层得知后公开宣布了处理结果,并同步发布了数据访问授权的新规则。这件事之后,整个组织对数据安全管理有了完全不同的敬畏感。一次公开的、严肃的处理,比发十份制度文件更能塑造文化。当然这里的处理不是要惩罚谁,而是要让所有人看到,公司对数据规则是认真的。
3.2 数据素养培训:分层设计,讲业务听得懂的话
数据治理文化要落地,培训是绕不开的。但很多组织的培训有一个通病:请一个外部专家来讲两小时数据治理概念,PPT很精美,听众全程昏昏欲睡。问题不在内容,而在没有分层。不同层级的人,对数据的关注点完全不同,用一个模板教育所有人,效果必然有限。我把受众分成三层:决策层、业务骨干、IT与数据技术人员,每层讲的东西完全不一样。
决策层真正关心的,是数据不治会带来什么风险、数据资产化能带来什么机会、治理投入怎么算回报,所以要给他们讲数据风险案例、数据资产盘点这些视角。业务骨干关心的,永远是"这和我手上的活有什么关系",所以要给他们讲真实业务场景中的数据错误成本,比如客户字段缺失怎么影响销售线索分配。IT和数据分析师关心技术实现,但要提醒他们先听懂业务语言,再谈技术方案。
| 受众 | 核心关注 | 培训重点 |
|---|---|---|
| 决策层 | 风险、投资回报、资产化 | 数据风险案例、治理ROI、数据资产盘点 |
| 业务骨干 | 与自己工作的关系 | 标准产生的业务原因、质量问题的下游影响、上报流程 |
| IT与数据技术人员 | 实现方式与协作界面 | 元数据管理、主数据管理、业务术语对齐 |
培训案例必须用组织内部的真实数据,哪怕是一个小场景,也比外部案例有说服力。记得之前给一家企业做培训,展示过一个真实工单:一位客户经理填客户资料时漏了行业字段,导致这个客户进入不了行业分析报表,最终影响了一个季度的重点客户评估。就这么一个简单的例子,当时会议室里好几位业务负责人一下就听明白了,为什么要认真维护字段。讲远不如讲近,讲企业自己的痛,比讲十页教科书都有用。
3.3 用激励和考核把数据行为放进"指挥棒"
文化建设不能只讲道理,还需要机制来传导。激励机制设计得好,会形成良性循环;设计不好,则会催生大量应对行为。我比较推荐的做法是设立月度"数据质量红黑榜",在经营分析会上用十分钟时间,把数据质量改进最好的部门和问题最突出的部门各列三个出来,点名到具体案例。注意,这个榜不是为了罚人,而是要形成一种公开讨论数据的氛围。被表扬的部门介绍经验,被点名的部门说明整改计划,坚持半年,效果比任何培训都好。
考核方面,建议把数据管理指标纳入部门绩效,但权重不宜太高,5%到10%之间比较合适。太轻,大家不当回事;太重,会逼着部门在数据上做表面文章甚至造假。指标不要只设一个"数据质量得分",可以拆成几个行为类指标,比如数据问题工单按期闭环率、数据认责落实进度、主数据维护及时率等。行为类指标比结果类指标更容易落地,因为结果类指标往往受很多不可控因素影响。
最后记住一条:所有的激励和考核,都要服务于一个目标,让数据治理这件事从"数据部门的事"变成"每个人的事"。考核是手段,认同才是目的。如果考核执行了两年,大家还是只想着怎么不被扣分,那就说明考核设计出了问题,而不是大家配合度不够。
4. 文化落地的常见阻力与应对策略
4.1 业务部门"事不关己":翻译比说服更重要
推进数据治理文化时,最常见的阻力就是业务部门的不配合。业务人员的第一反应通常很一致:数据是你们数据部门的事,我们只管干活。这种心态不是业务人员的问题,而是数据治理团队没有把价值和业务语言关联起来。破解的方法不是去说服,而是去翻译。举一个实际的例子:销售团队不愿意在CRM里维护客户信息,因为觉得填字段耽误拜访客户的时间。如果数据治理直接下发通知,要求必须在几号前完成字段补全,效果一定很差。换个方式呢?先分析客户字段完整度对销售线索分配的影响,整理出"客户信息完整率每提高10%,线索转出准确率提高约多少"这样的相关性数据,再以业务案例的形式发给销售管理层。当业务团队发现维护数据质量能直接影响自己的线索质量时,不催着也要改。
我在项目里总结了一个话术习惯:少讲"数据标准",多讲"数据能帮你看到什么";少讲"责任",多讲"权益"。数据治理文化的建设,本质上不是增加业务负担,而是改变业务获得价值的方式。谁能先把这种价值讲清楚,谁就能把阻力变成动力。这不是话术技巧,而是对业务问题的真正理解。
4.2 数据"部门所有制":把Owner从主人变成监护人
第二类阻力来自组织架构。很多企业内部,数据实际上是按部门边界划分的"部门资产"。市场部认为客户数据是自己的,财务部认为财务数据是自己的,跨部门申请数据要层层审批,甚至被直接拒绝。这种领地意识直接阻碍了数据的流动和共享,也让数据标准的统一无从谈起。要解决这个问题,核心是把数据Owner的定位从"拥有者"变为"监护人"。数据本身是组织的公共资产,只是因为业务需要,交给了特定部门来维护。
我建议推行数据认责时明确三层角色:数据生产者负责源头数据准确,数据维护者负责持续更新和清洗,数据使用者负责合规使用和反馈问题。一个部门在它的数据域里是监护人,不是所有者,它有责任管好数据,但不能以"这是我的数据"为由拒绝合理的内部共享需求。当然,理念转变不能只靠开会,要在机制上落地。可以做一个跨部门数据共享协议模板,把申请方、使用目的、授权范围、安全要求、责任界定都写清楚,让"拒绝"变成需要解释的行为,让"共享"变成默认选项。先把流程理顺,再谈文化转变,不然光是理念上认同共享,实操中出了安全问题又没有人兜底,很快大家又会退回到保守状态。
4.3 数据质量差的恶性循环:先止血,再谈文化
还有一个现实中特别普遍的困境:组织的数据质量已经差到没人信,而没人信又导致更没人去维护,于是质量更差。在这样的组织里谈文化,很多人会觉得是天方夜谭。这时候不能一上来就推文化,得先做速赢。我的做法是选择一个影响面最大、最容易被感知的主题域,比如客户主数据,集中资源把它治理清楚。目标不要定太大,就定"三个月内客户主数据唯一标识准确率达到95%"这样的具体指标。当业务部门发现,以前错漏百出的客户数据现在能直接用于销售分析时,他们对数据治理的态度会发生微妙的变化。这时候再慢慢扩展数据文化建设,阻力会小很多。
这个策略之所以有效,是因为文化改变需要正反馈。人只有尝到了数据治理给自己带来的实际好处,才会相信"数据是有价值的资产"这句话不是口号。一个数据治理团队如果一开始就试图在所有领域全面铺开、用文化宣贯开路,大概率会在看不见成效的疲惫中被消耗掉。先解决一个痛到不能再痛的痛点,让数据治理文化的种子在真实成功案例里生根,比任何抽象布道都更有力量。
5. 关于数据治理文化,我最后想说的几句实在话
第10章用67页来讲数据治理文化,如果只记住一句话,我记住的是:数据治理的最终成果,不是平台的数量、制度的厚度、项目的数量,而是一个组织里每个人对数据的默认态度。文化听起来软,其实是最硬的地基。从实际操作角度,我对想推进数据治理文化的读者有几个建议:第一,别急着开全员宣贯大会,先从诊断开始,搞清楚你的组织目前在哪个阶段,最该改的环节是什么。第二,把文化建设项目排期放宽,至少要给自己六个月以上,文化不是培训几场就能形成的。第三,找到一个业务上真正痛的点,用数据治理解决它,然后用这个案例去撬动更多人的认同。
我自己做数据治理项目,每到一个新组织,会先问一个问题:你们最近一次管理层会议,有多少时间在讨论数据?这个问题的答案,往往比任何成熟度模型都更直接地反映出这个组织的数据治理文化现状。如果你也有类似的体会,或者在实际推进文化落地的过程中遇到了别的坎,欢迎在评论区聊聊各自的解法。