数据治理项目数据质量提升方案建议.docx

数据治理项目数据质量提升方案建议.docx

《数据治理项目数据质量提升方案建议.docx》由会员分享，可在线阅读，更多相关《数据治理项目数据质量提升方案建议.docx（10页珍藏版）》请在冰豆网上搜索。

数据质量提升方案建议

1数据质量提升方案概述

通过对国内多个商业银行的数据治理经验总结出的一套完善的数据质量问题专项治理方法。

1.1数据质量问题调研

对相关数据质量:

范围对业务系统及主管业务部门进行调研确定数据质量具体问题，调研内容包括以下方面：

■问题产生的源系统：

■问题具体描述：

■问题产生的影响：

■问题发现时间:

■问题涉及到的表名、字段名:

■业务系统的应急方案：

■对源系统的要求。

下图为调研示意图。

1.2数据质量问题统计

根据调研反馈的问题，编写程序进行问题数据统计，包括:

■问題数据总数，统计相关表或字段产生的问题总数：

■问题数据明细，统计相关问题重要信息项的明细情况。

下图为统计程序的示意图。

1.3问题分析确定原因

将统计的数据反馈相关源系统.由其确认问题产生是由于自身程序导致或是外围系统下传造成，源系统需在规定的时间内完成确认锁定原因，原因包括：

■源系统程序缺陷，对重要信息的輸出端未加以逻辑控制，导致问题数据出现：

■外围系统F传给源系统的数据，外围系统本身的数据存在问题：

■源系统信息项不全所致。

参考制定的相关主题标准对信息项进行补全，确保信息项完善：

■指标口径不一致所致。

参考制定的指标主题对相关指标进行逻辑调整.确保上下游关联系统之间同一指标的口径一致。

1.4讨论确定需求费任

根据源系统反馈的原因，集中涉及到的相关部门进行讨论确定治理方案,包括业务部门、

关联源系统等，讨论主要范围包括:

■属于源系统程序缺陷问题，由业务部门提供业务逻辑，源系统根据业务逻辑进行程序控制优化：

■ 属于外围系统下传问题.相关外围系统和源系统共同商讨程序优化方案，保证各步数据质量：

■ 属于信息项不全的问题,由业务部门参考相关主题标准提出需求，源系统按需求补全信息项。

下图为需求贡任认定示意图。

1.5存量问题数据治理

对现存的问题数据进行治理，结合业务实际应用和系统现状确定数据治理方案，包括:

■现存数据量较小且相对独立，可以通过业务部门提出差错単方式提取数据，源系统

按正确的逻辑进行清理：

■现存数据量较大且对下游系统产生影响.需要集中相关部门讨论确认淸理方案。

待确定清理方案后，通过下发专项清理清单的形式对清理专题进行归纳整理，F图为清

理前的示意图。

1.6新増数据控制提升

为了保证新增数据的质量，后续避免新增数据出现同样的数据质量问题。

■对已出现的涉及到程序缺陷的问题进行优化控制，由业务部门提供的逻辑源系统进

行程序优化控制，保证输出端数据质量:

：

■参考制定的各主题标准完善补全信息项，保证信息一致性、有效性、标准性。

1.7数据质量检核监控

数据质量治理完成后，需要后续做好监控工作，包括制定一套检核体系对数据质量进行定期检核监控，确保数据质量。

■制定检核规则

每月定期对相关系统进行数据质量检核.确定检核的业务规则，包括确定检核对象、检

核主题等。

■对检核结果进行考核

对检核对象进行考核，包括主管业务部门、业务系统、标准主题等，做到数据质量:

的监控。

2数据质量度量标准

数据质量的度量标准，分为功能性和功能性的标准：

■功能性

♦完整性：

主要包括实体缺失、属性缺失、记录缺失和字段值缺失四个方面

♦唯一性：

指主键唯一和候选键唯一两个方面

♦一致性：

指统一数据来源、冗余存储和统一口径的一致性

♦准确性：

指计量误差、度量单位等方面的精确度

♦合法性：

主要包括格式、类型、值域和业务规则的有效性

■非功能性

■及时性：

指数据刷新、修改和提取等的及时和快速性

■安全性：

主要包括数据在传输、使用过程中的安全性

■扩展性：

该系统数据体系在不满足业务需求时进行扩展的可能性与复杂度高

除此之外.数据质量度量标准的制定还应从用户的视角进行考虑,重视用户对数据的满

意程度。

3数据质量检核规则

在数据的整个流转过程中涉及三种角色，即数据的产生者、数据的管理者、数据的使用者。

数据的产生者是各业务系统,数据平台是数据的管理者，数据的使用者主要是各业务部门和其应用分析系统。

数据从源业务系统流转到数据平台，在到下游数据应用系统，经过很多环节。

数据质量问题可能来自多方面和多个环节，一般来说，数据质量问题（即低数据质量）可能源于以下方面：

1）源业务系统的数据质量问题

■信息不正确：

指数据无效或错误，或者是应该填充的信息未填充，以及违反数据约束规则和业务规则等情况。

■信息不完整：

指数据管理平台分析中所用到的内容，源系统存在遗漏或未填充的情况。

有些信息在业务系统中不是作为必须填写的内容，但这些信息的缺失会严重影响数据管理平台系统的应用分析。

■信息不一致：

是指当同一信息内容来自于多个业务系统时，存在冲突和差异，或者同一业务系统内部的冗余信息之冋存在冲突。

对于业务系统源数据的质量问题，需要把该问题反馈到业务系统，对源数据进行修正，并修改业务系统应用软件，或制定相关操作规范，确保该问题不再重现。

■）数据平台的数据质量问题

除以上说明的源系统的数据质量问题外,数据平台本身也可能产生新的数据质量问题。

■代码的数据质量问题

♦代码不完全、不合理即数据平台统一编码不能很好地反映或包含各业务系统的代码，使得许多代码不能归类到数据管理平台编码，将导致数据平台统计分析报表中“未知''一栏的数量奇高，降低了应用分析的价值,并将影响使用人员对数据质量的信任度。

♦代码映射不合理：

即把业务系统的代码归类到数据平台编码时有错误或不合理，这将导致数据平台统计分析报表中各分类数据与业务系统存在重大差距，而通常这是

难以接受的，并将花费大量的精力来査找分析数据不一致的原因。

♦各业务系统代码发生调整，数据平台未同步修改：

业务系统的代码发生增加修改时，数据平台的代码映射未及时更新调整，这将导致所有新增的代码全部归类到数据平台编码的，未知”一类，同时对于修改的代码，当其含义发生变化时，未能调整归类到正确的数据管理平台编码。

当业务系统的代码发生增加修改时，应及时维护代码映射表。

■ETL数据质量问题

ETL数据质量问题是指在把数据从业务系统抽取、传输、转换、加载到数据管理平台过程中，产生的数据缺失、数据错误等数据质量问题，包括技术性问题和非技术性问题。

♦技术性问题包括脚本未按规范编写，存在语法错误或逻辑错误，或者没有遵循数据约束规则（如唯一性、引用性、非空等），所导致的数据质量问题。

该问题由脚本维护人员进行修正。

♦非技术性问题非技术性问题包括对业务规则理解不准确、代码规则不一致等产生的问题。

非技术性问题通常需要项目组内部协商讨论，或者向业务专家、统计专家、系统维护人员咨询。

3）数据应用的数据质量问题

数据应用层面的质量问题，也会出现如上的所述的代码问题和ETL质量等问题.除此之外，指标间一致性的质量:

问题在数据应用层面问题比较突出。

■同一个指标在不同应用中的一致性问题：

识别出是同一个指标，但在不同的报表间数据计算结果不同，通常是指标计算逻辑岀错或者指标展现差异的质量问题。

■指标间关系的一致性问题：

如多个财务报表间的指标是有业务计算逻辑关系的，若指标不符合业务上的逻辑关系，通常可能因为指标口径差异、指标计算逻辑不一致导致的质量问题。

数据质量的检核规则应由业务人员和技术人员共同参与制定，业务人员从业务的角度提出检查规则，技术人员从技术的角度实施检査。

4数据质量认责方案

4.1数据认贵的概念

国内外许多企业已经认识到，数据不但是有竞争价值而且还是有战略意义的资产。

为了让数据一致、准确、及时地交付给数据使用者，并让数据使用者充分地理解，企业必须对数据进行治理。

数据治理是围绕企业数据处理所进行的数据质量、数据政策、流程管理等一系列实践的融合,要以多种形式、综合使用各种技术手段来辅助,要赋予相关人员以相应的权力来建立和完善治理的流程。

数据认责和数据治理都是近十年间才出现的概念，仍在不断的发展演化过程中。

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

数据认责与数据治理密不可分，通过数据治理企业可以提高数据的可信性，而通过数据认责才能对数据治理的流程和方法施以主动控制。

为了让数据治理工作能够有效运转下去,企业需要周密健全的数据认责机制来保障。

4.2数据认责的原则

为了保证规划结果的合理性,数据认责体系规划要遵循下述原则：

■数据认责体系规划是逐级论证的过程，结论的合理性是层层推导得来的,每个阶段都是下一阶段的基础，各阶段合理性都需要详细论证,这也就是规划的具体工作内容；

■规划要与企业愿景和企业文化保持高度一致，规划要对非技术因素予以足够的重视；

■规划过程要参考同业最佳实践，要融合数据治理工作组所有专家的知识、意见和反馈，要在现状分析和差异分析的基础上进行；

■数据认责与数据治理采取相同的组织架构，组织架构参考了与数据治理行业的最佳实践；

■认责角色职责、流程与数据标准、数据质量、元数据和角色要匹配一致。

具体内容要做到前后连贯、逻辑严谨、层层推进、多重视角。

前后连贯指的是认责体系规划前后一致,行文要承前启后，而非突兀,不成体系；逻辑严谨是指规划要符合逻辑，形式与内容保持统一，细节与整体保持统一;层层推进是指规划要遵循上述流程，有优先顺序，而非没有章法，随意而为；多重视角说的是规划要站在不同的角度论证，同时涵盖IT部门和业务部门的观点，不失偏颇。

4.3数据认费流程

数据治理要以全行的视角来协调和统领各个层面上的数据管理工作，确保银行内部各类人员能够在正确的时间、正确的环境获得可信的数据支持与服务,而促使和保障数据治理效果得以持续展现的则是完善的数据认责流程和健全的数据认责制度。

4.3.1数据认责关系确认流程

数据认责关系确认流程描述的是创建和变更数据认责关系也即数据认责矩阵时要遵循的高阶流程。

在业务部门或技术部门提出数据认责需求时，数据治理工作组/数据治理负责部门会组织收集需求，进行需求分类、过滤、筛选，并组织相关部门的工作人员小范围讨论，这时如果能够明确数据认责关系，就确认发布，如果有争议，就等定期召开的数据治理协调会议上广泛讨论后确定,如果仍有争议,就要升级至数据治理决策会议确定。

4.3.2数据认责争议处理流程

数据认责争议处理流程是高阶数据认责问题解决流程,旨在以一种程式化的模式解决部门之间的数据认责争议，其中涉及了问题汇报、争议升级等处理措施。

数据认责争议处理流程与数据认责关系确认流程大致相似,业务部门或技术部门里承担各类认责角色的人员均可提出数据认责问题，由所在部门的数据协调员统一汇总记录后,提交至数据治理工作组/数据治理负责部门。

数据治理工作组/数据治理负责部门记录问题后,确认数据认责问題影响边界和范围，并组织相关人员沟通讨论,商量解决方案，如果无法沟通协调,可升级争议至数据治理协调会议上解决，如仍无法协调,可再升级至数据治理决策会议上解决。

数据治理决策会议是银行内部最高级别的治理会议,制定好解决方案以后,数据治理工作组/数据治理负责部门应监督争议的解决过程，并做好事后记录。

4.3.3数据认责内部审査流程

数据认责内部审查流程旨在监督企业认责执行状况，并采取必要的修正措施改变缺陷,提升认责流程的执行力与效率。

数据认责内部审查首先由数据治理小组或数据治理负责部门牵头组织当次审查的临时团队,然后由临时团队以问卷调研、面对面访谈等形式开展为期一周或两周的认责内审活动，并形成数据认责内审报告，提交高层审核，让银行高层对于行内数据认责现状的认识能够得到及时更新。

同时，针对数据认责内审报告中难以解决的问题,银行高层要督办数据治理工作组/数据治理负责部门着手解决，数据治理工作组/数据治理负责部门可择机组织召开数据治理协调会议/数据治理决策会议集中解决。

4.4数据认责方法

数据认责的最终结果会以数据认责矩阵的形式呈现，数据认责矩阵亦称为数据认责表.记录的是数据治理工作相关各方的责任和关系。

数据认责矩阵在企业数据治理和认责中扮演若至关重要的角色,认责流程借助数据认责矩阵才能执行下去，缺乏数据认责矩阵认责流程就会无法正常运转，数据治理就不会达到预期的效果，数据认责矩阵的存在某种程度上提升了企业数据的有效利用率。

数据认责矩阵的具体作用包括：

■数据认责矩阵可以唯一指定数据认责关系，对企业内部的数据共享和数据复用起到支持作用；

■数据认责矩阵可以有效消除一数多义，提升数据的唯一性、一致性；

■使用数据认责矩阵可以有效识别某类数据的认责干系人，包括所有者、管理者和使用者；

■数据认责矩阵可以使部门之间的沟通更加明确，针对性更强。