数据治理，到底是谁的事？
数据治理，到底是谁的事？
这个问题不搞清楚，花再多钱买平台也是打水漂
先说结论：数据治理是所有人的事，但必须有人牵头。把数据治理甩给IT部门的企业，最后都花了双倍的钱，走了双倍的路，还到了一个错的地方。
01 一场似曾相识的甩锅大会
你一定参加过这样的会。
会议室里坐着IT总监、业务部门负责人、财务总监，还有从外面请来的数据治理咨询顾问。议题是"数据质量为什么一直上不去"。
IT总监先开口："我们上了MDM平台，上了数据质量监控工具，规则都配好了，但业务部门不配合，数据录进来就是错的，我们也没办法。"
业务部门负责人接话："我们录的时候系统也没提示，培训也没做过，谁知道该怎么填？而且那些数据标准跟我们实际业务根本对不上。"
财务总监皱眉："每个部门给我的数据口径都不一样，我这个报表根本没法做。你们到底谁来管？"
然后大家齐刷刷看向咨询顾问。顾问清了清嗓子："数据治理需要建立组织架构，明确认责体系……"
会开了两小时，结论是：下周再开一次。
这个场景在多少企业里反复上演？数据出了问题，IT说业务不配合，业务说系统不好用，财务说口径不统一，最后谁都不认账。
为什么会这样？因为从一开始就没搞清楚一个根本问题——数据治理，到底是谁的事？
02 数据治理的四个"家"
先看看数据治理在企业里通常住在哪里。基本上有四个"家"：
第一个家：IT部门
这是最传统的归宿。数据在系统里，系统归IT管，所以数据也归IT管。逻辑上说得通，但实际上跑偏了。
IT能管的是技术——数据库怎么建、接口怎么通、权限怎么控。但IT管不了的是业务——客户名称该怎么填、物料分类该怎么分、财务科目该怎么对应。这些是业务的事，IT再聪明也替业务做不了这个决定。
把数据治理放在IT，最大的风险是：技术方案越来越精美，业务问题一个没解决。平台搭得漂漂亮亮，数据该脏还是脏。
第二个家：合规/风控部门
在金融、医疗等强监管行业，数据治理经常挂在合规或风控下面。合规团队关注的是数据能不能存、能不能用、有没有违规风险。
这没毛病，但如果数据治理完全由合规驱动，容易走另一个极端——只管限制不管赋能。数据是安全了，但谁也用不了，业务部门觉得数据治理就是"添堵"。
第三个家：数据管理团队
成熟一些的企业会成立专门的数据管理或数据治理团队，由CDO（首席数据官）或数据治理负责人带队。这是目前的主流方向。
但这个团队经常面临一个尴尬：有责任没权力。数据出了问题要他们背锅，但他们没有权力要求业务部门改流程、改系统、改习惯。没有高层授权，数据治理团队就是个"光杆司令"。
第四个家：业务部门
最近几年越来越多人说"数据是业务的事"。营销、财务、供应链——谁产生数据、谁使用数据最多，谁就该对数据负责。
这个方向是对的，但如果完全推给业务，没有统一框架，结果是各部门各搞一套，数据标准碎片化，跨部门协同时对不上。
结论：数据治理不能只住一个"家"。它需要一个"联邦制"——中央统一标准，各业务部门分头执行。既不能全集中（IT说了算，业务不买账），也不能全分散（各搞各的，标准打架）。
03 一句话定调：业务即行为，行为即记录，记录即数据
华为在数据治理实践中提出了一句话，我认为是关于"数据是谁的事"最精准的回答：
业务即行为，行为即记录，记录即数据。
这句话翻译一下：数据不是凭空产生的，它是业务活动的副产品。销售员录了一笔订单，产生了销售数据；仓库管理员做了一次入库，产生了库存数据；采购员下了一个采购单，产生了采购数据。
每一条数据的背后，都有一个具体的业务动作。谁做了这个动作，谁就应该对这条数据负责。
所以答案很清楚：数据是业务的事。不是IT的事，不是咨询顾问的事，不是数据治理办公室的事。
但这不意味着IT和数据治理团队没事干。他们的角色是赋能者和支撑者——提供工具、制定标准、搭建流程，让业务部门能够方便地"做对的事"。
用一个比喻：数据治理就像交通治理。交警（数据治理团队）负责制定规则、设置红绿灯、安装监控。但真正遵守规则的，是每一个开车的人（业务部门）。你不能指望交警替你开车，但如果没有交警，路就乱了。
04 四个角色：把责任钉到人
说"数据是所有人的事"容易，但"所有人"等于"没有人"。真正落地，需要把责任拆解到具体角色上。
业内公认的数据认责模型有四个核心角色：
角色
是谁
干什么
数据所有者
(Data Owner)
业务部门负责人
定标准、批权限、扛质量。对数据有最终决策权
数据管家
(Data Steward)
业务骨干+IT骨干
日常执行。业务管家管标准定义，技术管家管工具落地
数据生产者
(Data Producer)
一线操作人员
录入、采集、生成数据的人。谁录入谁负责源头质量
数据使用者
(Data Consumer)
分析师、报表开发、管理层
按标准用数据，发现问题及时反馈
这四个角色，缺一不可。
很多企业的问题出在哪？只有使用者，没有所有者；只有IT在当管家，业务在当旁观者。
数据出了问题，找不到Owner；标准要定义，业务部门说"你们IT定就行"；质量要考核，谁也不愿意把数据质量指标挂到自己头上。
国网确山供电公司有一个做法值得借鉴：严格按"谁产生谁负责、谁主管谁负责、管业务必须管数据"的原则，落实"数据主人制"——每一条数据都有明确的主人，生产者、管理者、使用者角色清晰界定，严把数据质量关。
核心原则：谁产生谁负责，谁使用谁维护，谁主管谁担责。这不是口号，是必须写进制度、挂进考核、落到人头上的铁律。
05 三层组织：一个人扛不动这件事
光有角色定义还不够，得有组织架构来支撑。数据治理的组织架构，建议分三层：
第一层：数据治理委员会（决策层）
由企业高管（CIO或CDO）牵头，各业务部门负责人参与。这是最高决策机构，负责：
审批数据治理战略和标准
协调跨部门的数据治理争议（也就是"甩锅大会"升级到这里来裁）
评估数据治理的投入产出
提供资源支持（人、钱、系统）
关键点：这个委员会必须由有实权的高管牵头。找个副总挂名但不实际参与的，等于没有。每季度开一次例会，重大事项随时召集。
第二层：数据治理办公室（管理层）
这是执行和协调机构，由专职的数据治理负责人、数据架构师、数据质量分析师组成。职责是：
制定数据治理流程和标准
维护数据资产目录
组织数据质量评估
推动数据治理工具落地
培训业务部门的数据管家
这个团队是数据治理的"中枢神经"，不需要很多人，但需要既懂业务又懂数据的复合型人才。
第三层：数据管家网络（执行层）
由各业务部门和IT部门的数据管理员组成，散布在组织的各个角落。他们负责：
在本部门执行数据标准
监控数据质量
处理日常数据问题
反馈标准落地中的实际问题
数据管家通常不是专职角色，而是在原有岗位职责中增加数据治理的职责。所以选人很重要——要选在部门内有影响力、有专业能力的人，否则推不动。
三层架构的本质是：高层给权力，中层给方法，基层给执行。缺高层，推不动；缺中层，没章法；缺基层，不落地。
06 联邦制：最适合大型集团的模式
大型集团企业下设多个事业部、子公司，每个单位都有自己的业务特点。数据治理该集中管还是分散管？
有三种模式：
模式
特点
风险
集中式
总部统一制定所有标准，强力推行
脱离业务实际，响应慢
分布式
各业务部门自己管，总部只提供基础支持
标准碎片化，数据孤岛
联邦式（推荐）
中央定核心标准+工具平台，各业务部门在框架内自主治理
需要强有力的协调机制
联邦式的核心逻辑是：统一的是"语言"，灵活的是"用法"。
总部统一制定核心数据标准（比如物料编码规则、客户主数据字段定义），搭统一的数据治理平台。各业务部门在核心标准的基础上，制定自己的扩展标准（比如某事业部的特殊物料分类），但必须与核心标准兼容。
华为就是联邦制的典型实践。他们在公司层面设置公司数据Owner，在各业务领域设置领域数据Owner。公司数据Owner统筹规划，领域数据Owner兼顾各业务领域的灵活性。两者配合，既确保了全公司数据"语言"统一，又不会把业务部门绑死。
07 认责不是喊口号：三把火烧到位
角色定义了，组织搭好了，最关键的一步是：怎么让认责真正落地？
光靠制度文件不够——制度贴在墙上没人看。光靠领导讲话也不够——开完会大家该干嘛干嘛。真正让认责落地的，是三把火：
第一把火：制度驱动——认责矩阵
把每一类数据对应的Owner、Steward、Producer、Consumer写清楚，形成全企业统一的数据认责矩阵。
比如：客户主数据——Owner是市场部总监，Steward是市场部数据专员，Producer是销售员（录入），Consumer是财务部和客服部。
这个矩阵不是存在PPT里的，而是要嵌入到MDM系统里——每条数据记录都能追溯到责任人。数据出了问题，不用开会扯皮，直接定位到具体环节和责任主体。
第二把火：工具驱动——数据血缘
数据血缘回答的是"数据从哪来、经过了谁的手"。通过血缘分析工具，从报表一路追溯到源系统、源字段，中间经过了哪些加工、哪些口径转换，一目了然。
某银行的做法是：根据报送平台定期生成数据质量报告，结合血缘分析工具追本溯源，找到数据的产生部门，本着"谁生产、谁负责、谁治理"的原则，从源头上解决问题。
工具的价值在于：把"谁的问题"从"开会讨论"变成"系统查证"。数据对不上时，不用拍桌子，看血缘图就行。
第三把火：考核落地——KPI挂钩
这是最痛但最有效的一把火。
必须将数据质量指标纳入业务部门的绩效考核体系。字段完整率、口径准确率、问题响应时效——都应该有明确的考核标准和奖惩机制。
某企业将数据质量纳入相关单位负责人KPI，制定统计工作责任清单，建立"日监测、周通报、月分析"质量管控机制。数据质量从"有没有"变成了"好不好"，从"好心了"变成了"考核了"。
认责机制的终极目标不是"出了问题能找到背锅的人"，而是"让数据在产生的那一刻就有人对它的质量负责"。当每一段数据都有明确的主人，跨部门沟通中的"踢皮球"才会从源头减少。
08 五个灵魂拷问
最后，用五个问题帮你检验自己企业的数据治理责任体系是否真正建立起来：
问题一：你的企业有数据Owner吗？
不是挂名的，是真正在管事的。客户数据有Owner吗？物料数据有Owner吗？财务数据有Owner吗？如果回答不出来，说明认责体系还没建立。
问题二：数据出了问题，第一个电话打给谁？
如果答案是"打给IT"，那你的数据治理还停留在IT主导阶段。正确答案是"打给数据Owner"——业务部门负责人对数据质量负总责。
问题三：数据质量指标在谁的KPI里？
如果在IT部门KPI里，方向错了。数据质量KPI应该在业务部门负责人的绩效考核里，与奖金和晋升挂钩。
问题四：一线录数据的人知道标准吗？
数据质量的第一道防线是数据生产者——一线操作人员。如果他们不知道标准、系统不做校验、培训不到位，数据从源头就是脏的，后面再怎么治理也是事倍功半。
问题五：数据治理是"项目"还是"日常"？
如果数据治理是有起止日期的"项目"，做完就散了，那它注定失败。数据治理是日常运营，不是运动式推进。组织架构的成熟度通常需要2-3年才能达到稳定状态，需要高层持续的支持和足够的耐心。
09 最后一句话
行业里有一句话：数据治理是20%的技术加80%的组织和管理。
20%的技术解决的是"能不能做"的问题——有平台、有工具、有方法。80%的组织和管理解决的是"愿不愿做"和"该谁做"的问题——有架构、有制度、有考核。
大部分企业卡在80%上。不是买不起平台，不是请不起顾问，是没有人愿意站出来说"这个数据我来负责"。
所以回到最初的问题：数据治理到底是谁的事？
答案是：每个人的事，但必须有一个人牵头。
数据生产者对源头负责，数据使用者对反馈负责，数据管家对执行负责，数据Owner对决策负责，数据治理委员会对方向负责。IT提供工具支撑，业务承担主体责任，高层给资源给权力。
数据治理不是某一个部门的独角戏，是整个企业的集体工程。只有业务与技术深度融合，让"人人用数据、人人管数据"从口号变成习惯，数据治理才能真正落地。
最后送一句话：
数据治理不是IT的KPI，是企业每一个人的必修课。谁产生谁负责，谁使用谁维护，谁主管谁担责。
本文来自微信公众号“数据驱动智能”（ID：Data_0101），作者：王建峰，36氪经授权发布。