一、本文预期读者：

• 企业领导

• 各主要业务部门领导

• 技术执行管理人员：在客户数据治理路线规划、设计和实施当中，需要资

深的管理人员支持。

• 数据管理相关部门：负责客户数据管理和监管报送相关的部门及其领导。

• 业务部门主要用户：相关业务部门的主要用户，如：数据分析人员、超级

用户、应用软件专业用户等。

• BI 项目组：任何负责实施 BI 的项目开发团队，以及正在进行实施的项目

开发团队中的项目经理、系统开发人员、程序/客户分析师等等角色。

二、内容结构

这部分介绍了数据问题产生的原因以及给企业带来的影响，同时介绍了数据治理的概念和数据认责的概念。

三、数据治理与数据认责概述

数据治理是国外银行业自 90 年代兴起的概念，最开始的主要目标是进行客户数据清理、完善数据标准、确保银行数据的完整性，随着银行业务不断拓展、数据及其相关理论逐步完善，数据治理的概念和方法在金融行业已经达成了共识，即数据不但是有价值而且还是有竞争价值的资产，为了让数据一致、准确、及时地交付给数据使用者，最重要的是，为了让数据能被使用者充分理解，企业必须要对现有的数据进行治理。

数据治理体现了围绕企业数据处理所进行的数据质量、数据管理、数据政策、业务流程管理与风险管理等一系列实践的融合。企业顺利获得数据治理可以保证数据的可信性，并且对数据认责的流程和方法可以施以持续主动的控制。数据治理需要以多种形式综合使用各种技术手段来辅助治理流程，需要时要赋予相关人员以权力得用技术手段来建立流程。

四、数据不佳的根本原因

我们经常会听到数据使用者对数据的抱怨：

• “我们有很多的重复数据”---没有解决方案

• “数字永远加不起来” ---不同部门使用不同的代码和统计口径

• “我的报告到达总是延迟，得到的总是过时的信息” ---给予关键数据的接

口经常出错

• “我们永远不知道在哪里可以找到我们想要的信息” ---缺乏对数据的理解

• “我们不能同意对我们的考核指标” ---部门使用不同的标准来衡量他们的绩

效

• “我怎样才能取得这个信息” ---没有明确的保密和安全流程

而这些数据问题的来源是多方面的，业务和 IT 都会产生数据问题。下面显示

的是来自一个调研组织的调查结果。

顺利获得上面的调研结果，我们可以看到各种数据问题产生的主要原因包括：

• 76％数据录入错误

• 53％源系统的变化

• 48％数据迁移或项目改建

• 46％用户不同的期望

• 26％系统错误

今天，许多组织开始认识到，为了把数据作为一项有价值的商业资产，或者甚至作为他们的财务资产，他们需要做一些更好的工作来管理这些数据。

现实的情况是，企业往往在口头上承认数据是企业的经营资产。他们谈论实施组织，标准，规则，流程和工具来管理和提高数据的需要，但未能实现，并支持他们。因此，数据的质量就会大打折扣。

“我们用系统来管理我们业务的各个方面，却没有一个地方来管理系统本身”，

如果企业数据管理流程失败了，数据仍然会流经我们的 IT 系统，但是这些数据将不会也不能自我管理！虽然我们采取了相关的数据管理措施，如：数据质量管理、数据整合、元数据管理、数据标准管理、数据模型和数据安全方面的管理，但是，流经我们各个系统的数据的可信度，完整性，安全性还是得不到保证的，因为数据质量问题的根本原因是：缺乏数据政策，数据标准，指导原则和规则，缺乏工具和流程。

五、数据问题制约了业务的快速开展

一份研究组织所作的调研结果是：47％的决策者对数据没有信心；59％的决策者遇到缺失的数据；42％的决策者知道，他们使用了错误的信息。因此，数据问题将制约业务的快速开展，导致企业缺乏竞争力。

1、数据质量缺陷将导致 ：

• 由于财务报表上的有失准确和数据之间的互相矛盾带来更高的违规风险

• 由于客户信息的有失准确造成市场营销的低效

• 过度打扰客户

2、数据模型缺陷将导致 ：

• 不同业务和数据主题之间数据的定义不一致

• 资源浪费：重复的数据对象和数据元素

• 耗时的工作去找到你要找的数据。

• 选择了错误的数据拜访问

3、元数据管理缺陷将导致 ：

• 寻找一个数据需要花费很长的时间

• 由于认识不足造成低效或错误的决策

• 延长开发周期，提高培训成本

• 由于对数据和业务规则缺乏信心造成低使用率

4、数据整合缺陷将导致 ：

• 由于各系统之间数据互相矛盾或不能关联带来痛苦的数据比对

• 由于缺乏统一的整合方法给项目带来不必要的复杂性和不一致性

• 重复建设，冗余复杂的接口，性能问题

5、主数据管理缺陷将导致 ：

• 客户和产品的缺乏标准或缺乏对应会带来客户服务的问题

• 延长了产品开发和导入的周期

• 给深入分析客户之间的关系和层级带来困难

6、安全和隐私缺陷将导致 ：

• 带来不断增加的合规风险，分散或不一致的数据

• 在客户、合作方、和监管组织眼中银行的信誉下降

• 身份被盗用和授权被滥用的风险

业界利用数据整合的优势推行信息导向经营战略是银行在激烈的市场竞争中

取得竞争优势的最优选择。从全球多家银行业的实践经验来看，顺利获得信息导向的经

营战略取得成功的银行通常具备下述特征：

• 以数据分析和数字化管理的理念贯彻整个组织；

• 决策者藉由数据运用，找到驾驭及引导变革的机会与关键信息；

• 以数据为中心的业务流程设计覆盖各个主要领域的管理需求；

• 建立数字化管理的组织文化，依据量化数据进行决策，不论是新进人员或具

经验的银行人员，均可基于一致的资料基础上做出业务决策；

• 组织灵活有弹性，随时能够开展新的业务模式；能够创造 20-30%的经济效

益。

六、数据治理概念

数据治理这个名词翻译自英文 Data Governance，有时也会被翻译成“数据管控”。业界权威组织 Gartner 对数据治理定义是：数据治理是顺利获得组织、制度、流程、技术的结合与实践活动，用以管理、维护和开发作为企业信息资产的数据。治理不同于管理，管理是你做出的决定，治理就是为这些决定制定愿景，政策，标准，流程和规则。

• 治理是执政的行为。它涉及到定义期望值，授予权力（决策权），并且对结

果进行验证。

• 治理是统一的管理，有凝聚力的政策，指导，流程和规则，以确保我们在合

适的时间，以正确的方式在做正确的事情。

• 治理将为企业建立一个愿景，并制定相应的政策，企业愿景，指导原则，标

准和规则，管理是确保这些政策，标准，原则和规则的实际应用，并在新的

和现有的系统中体现。治理把与业务战略相关的决策和监督与实际操作紧密

联系起来。

因此，数据治理也不同于数据管理（Data Management），数据管理更关注的是管理过程，例如数据质量管理、数据标准管理。而数据治理关注的是组织架构、制度、流程这些管理要素的整合和执行。对于银行来讲，数据管理的内容会有很多方面，而数据治理的内容只有一个。因此数据治理可以理解为是对数据管理的管理。近些年来，国内多家银行在数据治理领域也在做不断的探索，很多大中型银行都启动了数据治理相关的咨询项目和落地项目，但是在这些项目实践中也发现，缺乏成熟的方法论、缺乏整体的治理框架、缺乏整体的实施路线图，这些问题往往制约着数据治理工作的召开。

为了确保从数据中获取商业价值，所有与数据和信息相关的治理需要协同运作。这意味着他们将承担共同的责任，以确保正确的数据被传送，并在正确的时间，以正确的方式，被正确的人员使用

• IT 治理 监督选定的技术是否符合企业的 IT 基础架构，与经过批准的标准的

技术和 IT 流程一致。

• 数据治理 确保了数据是正确的，数据的定义和使用是一致的，BI 治理将确

保数据以正确的方式展示，仓库治理和 IT 治理顺利获得确保仓库和 IT 基础架构

的有效性来支持数据的正确交付。

• DW 治理 指导和控制数据仓库的管理，对 DW 的有效性和效率负责。IT 治

理政策（像 IT 支持政策，版本控制等）和数据治理流程（如数据分析和清

洁）也应适用于数据仓库，使其高效和有效的。

• BI 治理 对商业智能（BI）和业务分析进行管理控制，负责信息的正确使用

和传递。

上图显示了不同的治理类型在 EDW 中的关系，从左到右:

1. 左边数据产生，及数据的输入（手工）或数据创建（办自动化/自动）:

• 数据治理：负责建立输入或创建数据的政策、指导原则、标准和规

则。

2. 产生的数据存储在运营系统中，支持报表或者被其他操作流程提取:

• 数据治理：负责在操作型系统中制定数据访问和安全政策，以及在定

义数据和数据建模时如何应用标准。

• IT 治理：负责确保操作型系统持续可用，用户可以输入数据。

3. 数据仓库从不同的独立的源系统中获取:

• 数据治理：负责决定什么数据应该被获取，以及数据获取的频率。

• IT 治理：负责决定数据获取的技术，工具使用的条件以及文件格

式，等等。

• 仓库治理：负责确保获取数据时仓库是可用的，以及数据提交

（batch,file）的格式，等等。

4. 获取的数据存储在数据仓库的数据获取层:

• 数据治理：负责决定数据进行整合之前是否进行数据剖析（data

profiling），是否额外的控制字段需要加入到数据结构中。

• IT 治理：负责确保 IT 基础架构已经建立(数据传输的网络，仓库服务

器）。

• 仓库治理：负责决定多少历史数据必须加载，哪些数据可以归档。

5. 获取的源数据经过转换进入到数据整合层，数据整合层给予一个整合的数据

视图而不论数据的来源，整合层具有范式化的数据结构来支持数据在企业方

位内可以重用:

• 数据治理：定义元数据管理政策，确保数据具有业务含义。

• IT 治理：标准的数据建模工具。

• 仓库治理：负责确保 DW 容量规划符合将来新的数据导入需要。

6. 范式化和集成的数据需要在访问层被“非范式化” ，使得数据能够目标业务

用户访问:

• 数据治理：定义数据访问政策，即定义什么角色可以访问哪类数据。

• IT 治理：定义开发访问层组件的 IT 版本控制策略。

• 仓库治理：定义和监控 SLA 协议，确保现在的性能和工作负载管理

是最优的。

• BI 治理：制定访问层业务元数据建立的指导原则和规则。

7. 访问层给予的数据发布到目标系统（分析应用和操作，立方体，报表，文件等），使信息消费。

8. 对存储在目标系统的数据作进一步的分析或决策（业务用户或分析师）。

因此，数据治理是一个跨系统、跨业务部门和技术部门的系统工程，同时作为企业高阶的规划，数据治理的规划通常是在企业开展战略高层次的规划指引下，结合IT 治理规划进行。

七、数据认责概念

那么，谁对数据负责呢，有人会说：“不是 IT 负责吗？”。但是通常 IT 对此

没有太大的帮助，除非他们具有以下的业务知识：

• 能够解释在业务使用环境中需要的信息和可能用到的数据。

• 识别受污染数据的根源和其他数据问题的根源

• 解决数据问题

• 从其他数据分离出干净的数据

• 等等

IT 是负责系统和基础设施的，对数据认责的人员应该来自于业务部门，因为他们是系统的使用人员，知道什么是最好的数据。Gartner 在 2008 年的一份报告中指出：“以提升数据质量为己任的企业必须要指派数据管理人员。数据认责若要成功，企业文化必须转变，数据应视为竞争性资产

而非不得已而为之的手段。”数据认责的主要内涵是确定数据治理工作的相关各方的责任和关系，包括数据治理过程中的决策、执行、解释、汇报、协调等活动的参与方和负责方，以及各方承担的角色和职责等。

• 数据认责适用于所有参与其中的人员，如：管理和提升数据质量的数据专

家，当录入数据时需要分析数据政策和规则的业务用户，当数据变更或规则

变更时需要知情的数据消费者，正在进行数据开发项目需要清楚数据管理标

准，指导方针，工具和流程的项目组成员。

• 认责制可以防止事情“遭忽略而产生缺陷/失败”，这经常存在于企业的责

任认定中。

• 认责制并不一定都在企业的高层人员，而是定位在最适当的水平，只要这个

人员能够对这项工作担负起责任。

数据认责要达到的目标是：

• 形成由数据治理负责部门牵头的，全员参与的主动认责文化，重视问题的沟

通，能够主动剖析和快速响应出现的认责问题；

• 建立全行统一的认责流程，认责流程管理持续优化；

• 细化和落实各类数据认责流程、管理办法，并成功地将数据认责纳入企业绩

效考核体系当中；

• 执行基于数据域的数据认责模式，数据域的划分清晰且合理，理清各部门、

各小组以及各参与人所承担的角色职责，在全行推广数据认责。

下图显示了一个数据问题管理流程，在这个流程中我们可以看到数据认责的四个主要的角色：

• 数据使用者

需要理解数据标准、数据制度和规则，遵守和执行数据治理相关的流程，根据数据的相关要求使用数据，并提出数据质量问题。

• 数据所有者

对数据资产负责，同时对数据管理的政策、标准、规则、流程负责，给予数据的业务需求，分配数据的使用权，解释数据的业务规则和含义，执行关于数据分类、访问控制和数据管理的最终决策。

• 数据给予者

负责按相关的数据标准、数据制度和规则、业务操作流程的要求生产数据，并对生产数据的质量负责。

• 数据管理者

负责落实数据需求，对数据实施管理，保证数据的完整性、准确性、一致性和隐私，负责数据的日常管理与维护。