很多企业推进数据治理时，最先遇到的往往不是技术问题，而是责任问题。销售报表出现数据偏差，业务部门认为系统计算有误；IT排查后发现源头录入不完整；数据部门制定了标准，却没有权限推动业务整改。最后，问题在多个部门之间来回流转：谁都参与了，但没有人对最终结果负责。
数据治理不能简单交给某一个部门。更合理的责任划分是： 业务部门对数据含义和源头质量负责， IT部门对技术平台和数据链路负责， 数据部门对标准、监督和跨部门协同负责， 管理层对重大争议和资源投入负责。
一、为什么数据治理总是“谁都管，谁都不负责”？
很多企业习惯按照系统划分责任。ERP归IT部门，客户数据归销售部门，财务数据归财务部门，数据仓库归数据团队。表面上看，每个系统都有人负责，但真正出现数据问题时，责任边界仍然非常模糊。
因为，系统责任不等于数据责任。 例如，一项“客户销售收入”指标，可能经历以下环节：销售人员在CRM中维护客户信息，订单系统记录交易，ERP完成出库，财务系统确认收入，数据平台进行汇总加工，最后进入经营看板。
如果最终收入数据不准确，问题可能出现在多个位置：客户编码是否重复；订单是否被取消；出库数据是否延迟；收入确认时间是否正确；数据同步任务是否遗漏；指标公式是否使用了错误字段。
只按照系统找负责人，只能判断数据存放在哪里，却不能回答：谁定义数据含义？谁保证源头记录真实？谁审核加工规则？谁判断异常属于业务问题还是技术问题？谁负责推动问题关闭？因此，企业需要把责任落到数据对象、数据流程和治理事项上，而不是笼统地写成“某部门负责某系统”。这也是数据治理责任划分的前提：先看清数据怎么流动，才能说清责任应该落在哪里。
二、业务部门：对“数据是什么、源头对不对”负责
业务部门最了解业务事实和管理规则，因此应该承担数据所有者的责任。
1.定义数据的业务含义
客户、订单、收入、库存、回款等数据，不能由技术人员根据字段名称自行理解。例如，“有效客户”到底是指完成注册的客户、已经下单的客户，还是最近六个月内产生交易的客户，必须由业务负责人明确。技术人员能够实现计算公式，但不能替业务部门决定公式应该表达什么。
业务部门需要明确：数据的业务定义；统计范围和排除条件；状态变化规则；数据生效时间；适用部门和使用场景。
2.保证源头数据质量
如果销售人员随意填写客户名称，采购人员漏录合同编号，仓库人员延迟确认出库，那么再先进的数据平台也只能得到错误结果。IT可以设置必填、格式、长度和取值范围校验，却无法判断一笔交易是否真实，也无法判断客户等级是否合理。
因此，谁产生数据，谁就应该对源头真实性和完整性负责。 这项责任不能只写到“销售部”或“财务部”，还要继续落实到具体岗位，例如录入人、审核人、业务主管和数据所有者。
3.审批业务口径变更
当组织架构、业务流程、客户分类或会计政策发生变化时，数据口径也可能需要调整。业务部门不能只通知IT“把公式改一下”，还要说明：为什么需要变更；新口径什么时候生效；哪些指标和报表会受到影响；历史数据是否重新计算；新旧口径是否需要并行保留。
4.解决问题背后的业务根因
数据治理不能停留在补数和改表。如果某类异常持续出现，说明问题可能不在单条记录，而在业务流程、审核机制或岗位要求。例如，客户编码反复重复，不能每次都由数据人员手工合并，而应检查客户建档权限、查重规则和审核流程。业务部门最终负责的，不只是把错误数据改对，更是防止同类错误继续发生。
三、IT部门：对“数据怎样稳定、安全地流动”负责
IT部门是数据治理的重要执行者，但不应该成为所有数据问题的最终责任人。IT部门主要负责四类事项。
1.建设和维护技术平台
包括数据库、数据仓库、数据集成平台、主数据系统、接口平台、权限系统和备份环境。这些平台需要具备稳定性、扩展性和可维护性，能够支撑数据持续接入、加工、存储和调用。
2.保障数据链路稳定运行
IT需要关注：接口是否正常连接；同步任务是否按时执行；数据是否存在积压；任务失败后能否恢复；上游结构变化是否影响下游；数据是否完整写入目标系统。IT承担的是技术链路是否可靠、数据是否按时到达、平台是否稳定运行，而不是被动接收所有“数字不对”的投诉。
3.制定和执行技术规范
IT需要统一字段类型、数据库命名、接口格式、模型分层、开发测试和上线流程。例如，同一个客户编码不能在一个系统中使用字符型，在另一个系统中使用数值型；日期字段不能同时存在多种无法兼容的格式。技术规范不统一，会让每一次数据整合都变成临时改造。
4.落实数据安全控制
身份认证、访问权限、数据脱敏、传输加密、日志审计和备份恢复，主要依赖IT部门落地。但权限分配不能完全由IT自行决定。业务数据由谁查看，应由数据所有者审批；IT负责按照审批结果完成技术配置，并留下操作记录。
四、数据部门：对“规则能否统一、问题能否闭环”负责
数据部门可能被称为数据管理部、数据治理办公室、数据中台团队或数据资产管理团队。它既不是业务和IT之间的传话人，也不是专门替各部门清洗脏数据的团队。数据部门真正承担的是治理机制设计、标准组织、问题监督和跨部门协调。
1.建立统一的数据标准
数据部门需要组织制定：数据分类和编码标准；主数据管理标准；元数据管理标准；指标口径标准；数据质量规则；数据安全分级标准。
但标准不能由数据部门闭门制定。业务部门负责确认业务含义，IT确认技术可行性，数据部门负责组织评审、统一格式、维护版本和推动发布。
2.建立数据质量规则
“数据要准确”不是一条能够直接执行的规则。数据部门需要把它拆成可检测的要求，例如：客户统一社会信用代码不能为空；订单编号不能重复；出库日期不能早于订单日期；销售金额必须等于明细金额之和；核心报表必须在每天9点前完成更新。
工具负责发现和记录异常，数据部门负责制定规则和监督进度，业务部门负责修复源头问题，IT负责处理链路故障。只有责任连续衔接，质量检测才不会沦为一张无人处理的异常报表。
3.推动问题闭环
完整的数据问题处理流程应包括：发现问题、判断类型、确认影响、分配责任、制定时限、完成整改、复核结果和正式关闭。
数据部门需要重点关注的，不只是问题是否关闭，还包括：是否超过处理时限；是否影响核心经营指标；是否属于重复发生问题；是否需要修改业务流程；是否需要新增校验规则。数据部门可以监督问题，却不能替业务部门承担源头责任。
五、高层和治理委员会：负责跨部门裁决
很多数据治理项目没有效果，并不是因为企业缺少制度，而是因为数据部门没有足够的推动权限。当销售、财务和供应链对收入口径存在分歧，当源系统改造需要预算，当业务部门长期不处理数据问题时，单靠数据团队协调往往无法解决。
企业需要建立数据治理委员会，由管理层牵头，业务、IT、数据、财务、法务和安全等部门共同参与。治理委员会主要负责三类事项。
1.审批重大制度和治理项目
包括公司级数据标准、主数据建设、数据仓库规划、系统改造和重要数据治理项目。
2.裁决跨部门争议
例如：收入按发货还是验收统计；集团客户如何归属；同一指标是否允许多个版本；敏感数据由谁审批使用；
历史口径是否重新计算。这些问题不能长期停留在部门协商层面，必须有明确的最终裁决人。
3.决定资源投入并纳入考核
如果数据治理只依靠员工自觉，很容易被日常业务挤压。治理委员会需要确定预算、人员和系统改造优先级，并把关键数据责任纳入部门评价。
任务运行记录、异常数量、数据到达时间和问题处理情况，可以为治理评价提供客观依据。管理层看到的不再只是“某部门配合度不足”这样的主观描述，而是哪些链路长期延迟、哪些问题反复出现、哪些责任事项没有按期完成。没有管理层授权，数据治理只能停留在倡议层面；没有事实依据，治理考核也容易变成部门之间的相互指责。
六、用责任矩阵，把“共同负责”拆成具体动作
“业务、IT和数据部门共同负责”听起来没有问题，但在实际执行中最容易造成责任模糊。企业可以采用RACI责任矩阵，将每项治理工作拆成四类角色： R，执行者： 具体完成这项工作的人； A，最终负责人： 对结果承担最终责任的人； C，协商者： 需要参与讨论和提供意见的人； I，知会者： 需要了解结果但不直接参与的人。
例如：指标口径定义应由业务数据管理员负责整理，业务负责人承担最终责任，数据部门组织评审，IT部门确认技术可实现性。源头数据质量应由录入和审核岗位具体执行，业务负责人承担最终责任，数据部门监督质量结果，IT提供系统校验能力。数据集成任务应由IT或数据开发人员负责建设和维护，业务部门确认数据范围和加工逻辑，数据部门检查是否符合标准。数据权限申请应由使用部门提出，数据所有者审批，安全或数据部门复核，IT负责完成权限配置和日志记录。
质量问题整改则需要先判断问题类型：业务录入错误，由业务部门整改；同步任务失败，由IT处理；标准定义冲突，由数据部门组织评审；跨部门口径争议，由治理委员会裁决。责任矩阵的核心，不是让更多人参与，而是确保每项工作只有一个明确的最终负责人。
责任矩阵还需要配套三项机制。第一，建立责任清单。不能只写“销售部负责客户数据”，而要细化到客户名称、编码、等级、区域和有效状态等具体字段。第二，设置处理时限。一般问题、核心报表问题和影响监管披露的问题，应采用不同的响应和升级机制。第三，建立治理评价。除了问题关闭率，还应关注重复发生率、标准覆盖率、核心字段完整率和数据任务及时率。
其中，重复发生率比单纯的问题数量更重要。 一个问题被修复十次，不代表治理能力强，反而说明源头流程始终没有得到改善。
结语
数据治理不是寻找一个能够承担所有责任的“总负责部门”，而是建立一套分层负责、相互制约、能够闭环的治理体系。业务部门负责数据含义和源头质量，IT部门负责平台、链路和安全，数据部门负责标准、监督和协调，管理层负责重大裁决和资源保障。
真正成熟的数据治理，不是数据出错后才开始寻找责任人，而是在数据产生之前，就已经明确：谁定义？谁录入？谁审核？谁维护？谁检查？谁审批变更？谁承担最终责任？
只有责任边界足够具体，数据问题才能停止在部门之间反复流转，数据治理也才能从一次性项目，真正变成企业长期运行的管理机制。
