很多企业其实已经做了很多年的数据管理。

数据标准在做，数据质量在做，元数据在做，主数据在做，数据安全也在做。再往前一步，数据目录、数据资产、数据共享交换、数据治理平台也陆续建设起来了。从工作内容来看，围绕数据该做的事情似乎已经越来越完整。

但真正进入业务现场以后，往往又会看到另一幅景象。

同一个指标，不同部门仍然可能有不同口径；已经发布的数据标准，新系统建设时未必真正采用；质量平台发现了大量问题，但真正能够推动整改的只是其中一部分；数据责任人虽然已经写进制度，真正出了问题，却还要重新讨论“这件事到底应该谁负责”。

这就产生了一个很值得讨论的问题：

如果企业已经在管理数据，为什么还需要数据治理？

这个问题如果只是从概念上回答，很容易变成一句话：数据治理负责机制，数据管理负责执行。这当然没有错，但还没有真正解释两者之间为什么会存在差异。

更准确地说，数据管理能够帮助企业把一件件具体的数据工作做好，但它并不能天然保证这些工作能够长期、稳定地发生。

而数据治理真正要解决的，恰恰是这种持续性。

企业的数据管理体系，很多都是随着具体问题逐渐发展出来的。

不同系统里的字段定义不一致，于是有了数据标准；同一个客户在多个系统中存在多个编码，于是需要主数据管理；数据缺失、重复、异常，于是需要数据质量管理；数据越来越多，不知道在哪里、从哪里来、流向哪里，于是又发展出元数据管理。

这些工作都有非常明确的对象，也逐渐形成了成熟的方法、流程和工具。所以从本质上看，数据管理首先是一种专业能力。

它解决的是：面对一类已经明确的数据问题，应该用什么方法把事情做对。比如，一个字段空值率过高，可以建立完整性校验；一个指标存在多套口径，可以重新统一定义；一个核心业务对象在多个系统中重复维护，可以建立统一的主数据体系。这些都属于非常典型的数据管理工作。

而且在很多项目中，真正困难的并不是“不知道正确答案是什么”。设备编码应该唯一，大家通常都知道；关键指标应该统一，几乎没有人会反对；重要字段应该完整、准确，也不存在太多争议。

真正麻烦的，是这些正确的规则为什么没有被执行。标准已经发布了，新系统为什么还可以按照另一套方式设计？统一编码已经确定了，为什么不同部门仍然可以继续维护自己的编码？质量问题已经发现了，为什么迟迟没有人整改？数据责任人已经明确了，为什么真正发生问题以后，还要靠项目组逐个协调？

到了这里，问题已经不再是“数据应该怎么管”。它开始变成另一类问题：谁有权制定规则，谁必须执行规则，谁对结果负责，以及规则没有被执行时应该怎么办。

这正是数据治理开始出现的地方。

很多企业的数据治理，最初都是从数据质量开始的。找出问题数据，制定质量规则，形成问题清单，推动业务整改。这种方式非常直接，也往往能够在短时间内看到效果。

原来缺失的数据补齐了，重复数据清理了，错误编码修正了，质量指标也随之提升。但过一段时间以后重新检查，经常会发现一些熟悉的问题又回来了。原因其实并不复杂。上一次解决的是已经产生的问题，而产生问题的过程并没有真正改变。

业务人员仍然可以随意填写某些字段，系统录入端仍然没有必要的约束；两个系统仍然分别维护同一个业务对象；新的开发需求仍然可以绕开已经发布的数据标准；质量平台虽然能够发现异常，但问题最终能不能关闭，依然取决于人工协调。

于是企业很容易陷入一种循环：发现问题、整改问题、重新检查，然后再发现问题。如果把这种循环本身理解成数据治理，就很容易得出一个结论：数据治理是一项永远也做不完的工作。

但真正的问题其实不在数据本身。数据只是最后把问题暴露出来。一个错误的设备信息，可能来自业务录入流程；一条重复的客户记录，可能来自多个系统之间缺少统一身份管理；一个经营指标口径冲突，背后可能是不同部门对同一个业务概念存在不同理解。

如果这些过程没有发生变化，那么再好的数据清洗，也只能让某一个时间点的数据变得正确。新的问题仍然会继续被生产出来。所以数据治理真正需要做的，是把视角从“出了问题以后怎么办”，逐渐向前移动到“问题为什么能够被生产出来”。这也是数据管理和数据治理之间非常重要的一道分界线。前者更多处理已经明确的管理对象和问题，后者开始关注这些问题背后的组织、流程和控制机制。

传统的数据管理通常按照专业领域进行划分。标准是一类工作，质量是一类工作，主数据是一类工作，元数据又是一类工作。这种划分有其必要性，因为每一个领域都需要专业的方法和能力，但企业里的数据并不会按照这些专业边界运行。

以一个设备对象为例。业务首先要定义什么是一台设备，哪些属性能够唯一识别它；数据标准需要把这些定义转化为编码规则、字段规则和口径要求；信息系统按照这些规则采集和保存设备信息；接口又将这些数据传递到其他系统；质量规则负责判断数据是否完整、准确和唯一；元数据记录这些数据出现在哪里、如何流转；最终，分析系统再利用这些数据支撑统计、运营和决策。

这是一条完整的数据链路。真正决定这条链路能不能稳定运行的，并不是某一个数据管理模块做得够不够好，而是这些环节之间有没有形成稳定的连接。

业务定义变化以后，标准是否同步调整？标准调整以后，相关系统是否能够得到通知并完成改造？系统完成改造以后，质量规则是否同步更新？质量发现问题以后，是否能够准确找到责任环节？责任人完成整改以后，又有没有办法证明问题已经真正关闭？

如果这些关系没有建立起来，那么数据标准、数据质量、主数据、元数据做得再多，也很容易变成一个个相对独立的管理模块。这也是很多企业数据管理工作“看起来什么都有，真正运行起来却总差一点”的根本原因。

数据治理真正需要做的，就是把这些分散的管理能力连接起来。所以它治理的，并不只是数据本身，更重要的是围绕数据形成的责任关系、规则关系、流程关系和系统关系。

从这个角度看，数据治理并不是在数据标准、数据质量、元数据之外再增加一个新的管理模块。它更像是一套控制机制。它要让这些原本分散的数据管理能力真正嵌入企业的数据生产和使用过程，使数据要求不再只是“数据部门提出的要求”，而逐渐成为企业运行过程中必须遵循的规则。

如果把企业的数据形成过程完整展开，会发现数据从来不是静止的。业务活动不断产生数据，系统不断采集数据，数据在不同系统之间传递，再经过加工、汇总和计算，最终进入报表、分析、模型和各种业务应用。

所以数据问题也不是在数据库里凭空产生的。它一定来自这条链路中的某一个环节。传统的数据管理往往更容易在结果端进行处理。数据进入数仓以后检查质量，进入共享平台以后进行安全控制，在资产平台中补充目录和标签。这些工作当然重要。但治理越深入，控制点就越需要向数据产生的前端移动。因为越靠近源头，治理的成本越低。

一个错误字段如果在业务录入时就被系统拦截，成本可能只是重新填写一次。如果这条错误数据已经经过多个系统流转，进入几十张报表、多个模型和下游应用，再去整改，影响的就不再是一条数据，而是一整条数据链路。所以真正成熟的数据治理，一定会从“结果整改”逐渐转向“过程控制”。

业务定义形成时要有统一规则，系统设计时要引用已有标准，数据进入系统时要进行必要校验，跨系统交换时要保持语义一致，加工过程要能够追溯，重要数据输出之前还要经过质量和安全检查。一旦出现偏差，也不能停留在“发现问题”，还需要责任分派、整改、核验和复评。

这样一来，治理的目标就发生了变化。它不再追求某一个时间点的数据“没有问题”，而是希望整条数据生产链能够长期维持在一个稳定、可控、可追溯的状态。

这其实和工业生产中的质量管理非常相似。一个成熟的制造体系，不会因为最终产品检验合格，就认为质量管理已经完成。真正的质量控制一定会进入原材料、生产工艺、设备状态、过程检验和异常处理。

数据治理也是如此。如果所有控制都放在数据最终形成以后，那么治理永远只能追着问题跑。只有当标准、责任和控制真正进入数据产生的过程，治理才开始从“治理数据”变成“治理数据生产”。

理解到这里，再回头看数据治理和数据管理，两者之间的关系其实就比较清晰了。

治理从来不会替代这些专业工作。但治理也绝不是把数据标准、质量、主数据、元数据、安全这些工作简单加在一起。它要解决的是另外一个问题：怎样让这些管理能力真正进入企业的运行过程，并长期发挥作用。

所以，一个企业完全可能拥有比较成熟的数据管理能力，却仍然没有形成真正的数据治理。它可以有很好的平台、有完整的标准库、有大量质量规则，但问题出现以后依然主要依靠人工协调；标准发布以后有没有执行，缺少真正的控制；项目结束以后，原有机制也逐渐停止运行。

而真正成熟的数据治理，也不应该表现为“数据部门管得越来越多”。恰恰相反，治理越成熟，很多数据要求就越应该自然地进入业务流程、系统建设和项目管理过程。

数据标准不再只是数据团队维护的一份文档，而应该成为系统设计和需求评审的输入。数据质量也不再只是事后发现问题的工具，而应该逐渐成为数据生产过程中的控制条件。数据责任更不应该只是治理平台里的一列名字，而应真正对应到业务流程和组织职责。

到了这个阶段，数据治理已经开始超出传统数据管理的边界。因为它处理的已经不仅仅是数据专业问题。它开始涉及企业如何定义业务对象、如何分配责任、如何建设系统、如何推动跨部门协同，以及如何证明这些规则确实在运行。

所以，如果一定要概括数据治理和数据管理之间的区别，我更愿意这样理解：数据管理提供的是把数据管好的专业方法，数据治理建立的是让这些方法能够长期发挥作用的企业运行机制。

企业之所以需要数据治理，并不是因为过去的数据管理做得还不够多。而是因为随着数据越来越深地进入企业经营、生产和决策，仅靠一个个独立的管理动作，已经很难保证整个数据体系持续稳定运行。

数据标准可以告诉企业什么是对的，数据质量可以告诉企业哪里出了问题，元数据可以帮助企业找到问题发生在哪里。而治理真正要解决的是：这些要求由谁落实，偏差由谁纠正，责任如何传递，规则如何进入业务和系统，以及整个过程能不能长期保持受控。

从这个意义上说，数据治理最终面对的确实是数据。但它真正改变的，是企业围绕数据运行的方式。