数据治理咨询项目
目 录
1 公司简介
1.1 公司基本情况
1.2 商业智能事业部及团队介绍
2 项目需求理解
2.1 项目背景及目标
2.2 项目主要工作内容
3 数据标准建设方案
3.1 数据标准建设方法论
3.2 数据标准分类
3.3 数据标准现状调研
3.4 基础数据标准设计
3.5 分析类数据标准设计
3.6 数据标准映射
3.7 数据标准执行
3.8 数据标准维护与增强
4 数据治理体系建设
4.1 数据治理体系的概念
4.2 数据治理体系评估诊断
4.3 数据治理体系蓝图设计
4.4 数据治理体系实施路线图
4.5 数据治理体系制度建设及落地指导
5 数据质量提升方案建议
5.1 数据质量提升方案概述
5.2 数据质量度量标准
5.3 数据质量检核规则
5.4 数据质量认责方案
6 数据架构实施路线
6.1 数据体系架构建设规划
6.2 数据体系架构实施路线
6.3 阶段性目标及计划
7 项目实施方案
7.1 项目计划
7.2 项目组织架构及费用
7.3 项目交付成果
7.4 项目管理方案
7.5 项目质量保障计划
7.6 知识培训方案
7.7 项目实施的主要风险点及规避措施
8 知识产权说明
9 现场XX实施优势
1 项目需求理解
1.1 项目背景及目标
1.1.1 项目背景
从全球银行业的实践经验来看，建立信息化导向的管理体系和以高度整合数据为中心的量化决策机制，是帮助商业银行应对监管要求和获得竞争优势的关键手段，而数据的完整性、准确性、一致性和时效性是这一关键手段的基础。
2008年金融危机暴露出的信息缺口问题也凸显了金融统计标准化的必要性，国际金融组织和全球中央银行对此都在进行反思，特别是在数据采集和信息共享方面。2009年10月，人民银行启动了金融统计标准化改革进程，目前已经陆续发布了一系列标准，后续除了继续发布标准外，还将部署各家金融机构落实具体标准的实施。2011年5月，银监会发布了《监管统计数据质量良好标准》，从组织机构及人员、制度建设、系统保障和数据标准、数据质量的监控、检查与评价、数据的报送、应用和存储等五大方面对银行业金融机构提出了明确的要求。
由于数据治理体系建设大大滞后于业务系统及管理分析类系统的建设，因此各商业银行在数据的管理和应用上，均在不同程度上出现了不同业务系统之间由于数据业务和技术定义不一致、数据缺乏共享机制而导致的数据难以整合一致、难以有效利用的问题，这些问题已经成为制约业务发展和技术实现的瓶颈。
为应对监管要求和日益激烈的市场竞争，国内各家金融机构如国家开发银行、国家进出口银行、工商银行、建设银行、农业银行、光大银行、广发银行、招商银行、兴业银行、平安银行、北京银行、南京银行、厦门银行等也纷纷在近几年结合自身实际情况开始了数据治理体系的相关建设工作。
目前，正处于业务高速发展期，业务系统建设按照IT规划和业务需求持续进行。相比业务系统，数据治理方面建设工作投入较少，存在一些问题，无法较好的支持业务的开展，主要表现在：缺少明确的数据治理体系；缺失数据标准，数据质量检查不完善，效率较低；未能满足精细化管理要求，现有数据治理体系有待完善；需进一步论证数据架构和完善数据架构修订审批流程等。因此，希望通过数据治理项目对IT数据规划进行论证，搭建全行数据治理体系，建立数据标准体系，按照数据标准内容对数据质量进行检测管理，对重点数据问题进行改造，以便达到整体上提高数据质量，提高数据管理水平的目的。
1.1.2 项目建设目标
本次项目的建设目标包括以下四个方面：
n 根据的实际情况，结合外部监管需求、同行业的实践经验，初步建立数据标准模型；根据的实际业务情况，结合数据标准模型，分别建立基础类数据标准体系、分析类数据标准体系、专有类数据标准体系。
n 通过对数据治理（管控）现状的评估、同时对比行业最佳实践诊断分析数据治理（管控）的差距，制定适合的数据治理（管控）能力发展规划及实施路线图；对管理信息中心运营架构及管理职能进行规划设计，根据的实际情况，建立适合数据服务的管理模式、组织架构、组织和岗位职责、运营流程、制度框架，提高数据服务能力，支撑全行数据共享与数据应用对业务管理和决策的支持。
n 结合数据标准模型，通过对核心系统、信贷系统、资金业务管理系统、总账系统及财务管理系统的分析，整理出数据质量分析报告，以此为数据质量提升方案切入点，根据数据质量的情况，制定数据质量改进方案，推动数据标准在关键系统的落地实施，有效提升运用数据支持自身战略发展的能力，主动应对监管部门日益严格的数据披露要求。
n 根据实际情况，参考同业的先进经验，制定符合实际的数据架构建设方案，明确数据架构体系建设的阶段、目标和建设思路，明确数据架构建设中数据处理方法和原则，为后续数据架构建设制定可行的方案。
1.2 项目主要工作内容
1.2.1 数据标准建设
n 搭建数据标准模型，根据的实际情况、结合外部监管需求、同业经验建立一套标准数据模型；
n 结合标准数据模型，完成客户、产品、合约、交易、渠道等主题基础类数据标准编制
1、 客户数据标准主要根据个人客户、公司客户、同业客户等从基本信息、财务信息、风险信息、关联信息、管理信息、联系信息、往来信息、重要事件等8个方面制定客户相关的基础类数据标准；
2、 产品数据标准主要根据业务发展情况，定义全信合的产品清单，以及定义产品主题日常维护管理所需的数据标准；
3、 合约数据标准主要针对行内一些主要业务进行信息项设定，并针对每个信息项的内容进行数据字典的定义，形成合约的基础类数据标准；
4、 交易数据标准主要是为满足日常管理分析需要，定义在发生一笔交易时，在系统内、系统间流转过程中必须具有的一些基础类数据标准。
5、 渠道数据标准主要根据服务窗口情况，规划设定全行信合的渠道清单，以及渠道主题日常管理维护所需的数据标准。
n 根据日常分析管理需求，结合同行的实践经验，建立一套满足日常管理分析、监管报送所需的指标体系，建立分析类数据标准。
n 建立一套数据标准管理办法，明确数据标准各岗位职责和功能、变更流程、管理模式等。
1.2.2 数据治理体系建设
1.2.2.1 数据治理体系评估诊断
n 通过调研访谈、调查问卷、资料分析等方式，从组织架构、岗位职责、政策制度、业务管理、系统技术等方面对全行数据治理现状进行全面评估，并参照同业银行领先实践，对全行数据治理现状进行差距分析，提出改进建议。
1.2.2.2 数据治理体系规划设计
n 基于数据治理现状调研与差距分析成果，规划设计数据治理体系总体框架，内容包括：
- 设计数据治理体系总体框架，明确数据治理各领域管理内容及工作任务；
- 设计数据治理组织架构，明确相关岗位职责；
- 设计数据治理制度框架及编制要求
n 基于数据治理体系设计成果，提出全行数据体系建设策略和发展目标，制定符合发展现状的未来3至5年的数据应用与服务、数据标准、数据质量、元数据管理、数据架构、数据保留与归档、数据隐私与安全等数据治理各领域的实施路线图。
n 结合未来数据应用、数据服务的发展趋势，对管理信息中心的业务模式和运营体系进行规划设计，其中包括数据服务的业务和管理模式、组织架构、组织和岗位职责、运营流程、制度框架。
1.2.2.3 数据治理体系制度建设及落地指导
n 基于数据治理体系设计成果，制定全行的管理政策及组织工作章程，明确数据管理的总体目标、工作原则、工作内容以及组织工作章程。
n 制定数据管理考核办法，明确数据管理考核工作的组织与流程，明确数据管理工作考核的具体内容，包括考核的维度、考核指标及其计分方式等。
n 基于数据治理体系设计成果，制定数据标准管理，明确数据标准管理的工作内容、组织职责和工作流程，包括数据标准的职责分工、数据标准申请、数据标准制定、数据标准审批、数据标准发布、数据标准执行、数据标准维护和修订等。
n 基于数据治理体系设计成果，制定数据质量管理，明确数据质量管理的工作内容、组织职责和工作流程，包括数据质量的职责分工、数据质量目标计划管理、度量规则管理、数据质量监测、数据质量发现、分析、整改、评估流程等。制定数据质量考核办法，明确数据质量考核工作的组织与流程，明确数据质量考核的具体内容，包括考核的维度、考核指标及其计分方式等。
1.2.3 数据质量提升
n 通过对核心系统、信贷系统、资金业务管理系统、总账系统及财务管理系统 的数据分析，结构数据标准，形成各系统的数据质量报告。
n 根据分析得到的数据质量情况，按照不同的质量类型提出不同数据质量提升方案，推动数据标准在关键系统的落地实施。
1.2.4 数据架构建设
n 在充分考虑大数据处理、MPP数据库等技术处理的基础上，结合行业的成功实践经验，规划符合实际需求的数据架构方案。
n 根据规划的数据体系架构提出实施路线图。
n 明确数据体系架构建设的阶段性目标及建设思路
n 确各类型数据在数据体系架构中的作用、实现方式、适用技术体系，并结合数据架构建设的阶段性目标确定各类型数据处理的实现计划。
2 数据标准建设方案
搭建数据标准框架。在数据标准大框架的指导下，收集和梳理的数据现状和数据标准需求，基于现状分析的成果，定义客户、产品、合约、交易、渠道等主题的数据标准，经各相关部门审议后进行数据标准发布。数据标准发布后，应建立数据标准与各相关主系统的映射关系，从而评估各系统与数据标准的差异，为推动数据标准落地执行提供依据。基于映射成果，分别针对客户、产品、合约、交易、渠道等主题提出相应的执行建议和实施方案，用于指导全行各相关系统的数据标准落地工作。
2.1 数据标准建设方法论
通常来说，IT系统由硬件、软件、数据和通讯等四个部分构成。数据是指信息的可再解释的形式化表示，具有业务和技术两种属性。业务属性包括数据的业务定义、分类和规则等，技术属性包括数据的类型、格式、形态等。数据标准就是描述和阐释数据业务属性和技术属性的规范文档。IT系统应根据数据标准的规定，采集数据，生产数据，存储数据，交换和共享数据。
数据标准中定义的数据范围，广义地说，应包括IT系统中的全部数据。但从标准建设的经济性和实用性出发，一般主要包括IT系统中需要与其他系统（包括人机间）进行交换和共享的部分，即该部分数据是否存在业务应用的需求和数据交换的需求。
基于上述认识，我们认为数据标准建设总的原则如下图所示，是由业务部门的业务需求和IT系统的数据交换需求共同驱动的。
在上述总体原则的指导下，数据标准建设的具体实施步骤如下图所示，包括标准框架、现状调研、标准设计、实施映射、标准执行和维护增强六个步骤。
2.1.1 标准分类
此阶段的工作目标是要回答“标准的范围应该包括哪些”，数据标准分类作为数据标准化工作开展的基础，主要包括明确标准定义范围、确定主题定义目的、明确主题定义指导原则、确定数据标准层次、明确主题定义内容等内容。
2.1.2 现状调研
此阶段的工作目标是要回答“待建设的主题目前数据状况如何”。通过制定调查问卷、安排现场访谈、收集文档资料等手段，从业务和技术两方面开展调研，了解跟标准相关的内容，包括现有定义、使用习惯、数据分布、数据流向、业务规则、服务部门、主要矛盾、差异产生原因等，在此基础上对标准建设的背景、建设的难度、影响的范围才能够有清晰的了解，便于设定合理的标准建设目标、制定可行的标准实施规划。
本环节的主要工作内容如下：
1) 业务需求采集
在数据标准分类指导下，从数据应用出发，针对其细节信息设计合理的调查问卷，最大限度减少业务人员的工作量，能够在短时间内帮助业务人员了解标准建设的背景以及必要性、重要性，同时采集到业务部门目前主要存在的问题以及对标准的期望。
2) 系统现状调研
对包括数据结构、数据字典、系统之间的关系（数据流向）、重要业务规则在系统中的体现方式等方面的内容进行调研。需要各系统的管理维护人员提供相应支持，保证提供的材料文档说明能够跟现行系统保持高度一致。
3) 分析应用调研
针对重要的分析类应用系统进行调研，分析其涉及到的数据/业务范围、重点数据需求、主要问题等。
4) 现状整理分析
将此阶段采集到的业务需求、现状问题等进行全面的整理，包括调查问卷汇总、数据结构/字典规范化、样本数据案例等，便于问题的汇总以及标准的现状差异分析和影响范围分析。
5) 重点问题访谈
根据现状整理和分析的结果，结合数据标准建设的整体规划和目标，针对其中的重点问题如果存在了解不全面、采集信息存在歧义、参考文档不一致等情况，可以适当召集相关人员做专题访谈澄清问题，便于后续工作的开展。
2.1.3 标准设计
此阶段的工作目标是要回答“标准应该是什么样的”，基于标准规划的分类，以现状调研的成果作为重要依据，完成待建设主题数据标准设计和定义工作，包括信息类的划分和定义，信息项的业务定义和描述，数据类型及其他技术属性的指导意见等。
本环节的主要工作内容如下：
1) 方法原则确定
结合上一阶段的产出成果，确定各主题标准定义原则和定义方式以及大体的工作范围和详细程度。
2) 信息视图定义
根据各主题数据具体情况，进行大/中/小等不同层次的信息类定义，阐述其业务内涵以及应该包括的内容，以大/中/小类的组织方式形成业务视图。
3) 信息项定义
梳理每个类别下具体的信息项列表，针对每个信息项进行标准的设计工作，包括业务层面的定义和描述，力求完整、准确，尤其应明确；同时根据信息项的标准业务含义，为其定义技术属性，如数据类型、推荐长度等；如果信息项涉及到相关代码，同步进行整理和定义；如果信息项需要设定重要的检核规则，也可酌情、有选择地加以设置并与之关联。
4) 标准定义审核
组织相关部门和人员采用书面确认的方式对已经完成的标准定义工作进行检核和补充，如有必要，可针对未能达成共识的重要问题进行集中评审，应着重考察标准对业务的适用性、先进性和全面性等。
5) 管理员名单拟定
根据数据标准使用者和维护者，拟定相应管理员，并报领导小组进行审批。
2.1.4 标准映射
此阶段的工作目标是要回答“和标准相关的内容都在哪儿”，将已定义数据标准与业务系统、业务应用进行映射，描述标准和现状的关系，以及可能的影响范围，作为后续差距分析和标准执行的输入。
本环节的主要工作内容如下：
1) 工作范围确定
在现有的业务系统和应用中，制定系统选择的优先策略，针对稳定的（近期没有升级改造计划）、有代表性（涵盖普遍性业务）的系统确定后续详细映射的工作范围。
2) 源系统分析
对选定的源系统进行详细分析，选取内容与标准涉及到的主题信息项、公共代码等相关的数据表、数据字段，并针对这些选中的数据抽取相关样本协助分析。
3) 样本数据分析
针对重要信息（如证件种类、渠道代码等）或者差异很大，而且跟先期规划重点相关的部分，需要对样本数据进行分析，以便更清晰地表现问题，并了解问题产生的背景。需要补充说明的是，此工作可能在整个项目进行过程中会持续、分批、分次开展。
4) 信息项映射
针对标准中具体的信息项，在准确理解其含义的基础上，将其映射到所有选中系统的数据表、数据字段上，建立两者关联关系。
5) 回顾和检查
组织专家小组对标准映射范围选取的适当性，映射的准确性等进行回顾和检查，并最终确认。
2.1.5 标准执行
此阶段的工作目标是要回答“标准应该如何执行”，针对现有系统和新建系统，对已定义数据标准进行执行落地工作，包括制定执行策略、编写执行建议和实施方案。在标准执行阶段，应充分考虑业务需求和实施难易程度，最大程度上结合目标和现状，针对不同类型的系统制定相应策略，并设定合理的阶段性目标。
本环节的主要工作内容如下：
1) 标准执行策略确定
针对新老系统、业务处理或分析系统、自行开发或外购系统等不同类型的系统，充分考虑其各自的特点，在满足标准需要，影响最小化的基础上分别制定不同的执行策略。
2) 相关系统执行分析
对需要落地执行数据标准的系统进行执行调研和影响性分析，确认其数据标准落地执行要涉及到的改造工作。
3) 标准执行建议编写
结合业务优先级和实施难度分析结果，根据上一阶段的系统执行情况调研结果，针对目前急迫解决的业务问题确定标准的执行方向，执行建议应作为实施方案的主要参考文档。
4) 标准实施方案编写
与项目组或具体系统技术人员通过会议、邮件或访谈的形式进行充分沟通和交流，相互合作编写实施方案，包括具体的标准执行内容、执行方式、执行步骤等。
5) 实施方案审批
将标准实施方案提交领导小组进行论证和评审。
2.1.6 维护增强
此阶段的工作目标是要回答“如何管理维护标准”，结合的数据管理需求和机制，培养管理员负责相应工作，在全行范围内培训和宣讲数据标准。
1) 数据标准管理办法制定：制定相关的管理办法，用以规范数据标准的使用、维护与管理，确保数据标准的有效性、适用性，推动数据管控体系建设，促进信息在全行范围内的共享。该办法需由相关部门监督执行。
2) 数据标准培训：定期对数据标准的相关内容进行全行内的系统培训和专题培训，制定培训时间表，包括培训内容、培训方式、培训人员和培训时间。
3) 标准的维护更新：收集整理各部门数据标准更新需求，根据数据标准管理办法，分期分批地进行标准更新、发布等工作。
2.2 数据标准分类
u 工作目标
数据标准分类作为数据标准化工作开展的基础，其主要目标是：
u 明确标准定义范围——结合行业最佳实践，明确标准化主题的定义范围，指明未来数据标准化工作的重点和发展方向。
u 确定主题定义目的——明确各主题标准化的目的，即标准定义所能带来的的业务/技术价值，为后期推动标准落地实施奠定基础。
u 明确主题定义内容——根据主题标准化目的明确标准规范化工作的侧重点和具体事项，为后续实际开展标准定义工作提供依据和指引。
u 工作内容
u 标准分类设计：基于XX在国内多家银行实施数据标准咨询的经验，结合业务管理及系统建设现状，完成数据标准分类的设计，包括：明确数据标准的定义范围；明确数据标准层次划分；明确各主题标准定义工作的侧重点和具体定义内容，指导和规范后续数据标准体系建设。
示例：
u 行内沟通汇报：就标准分类在行内相关部门进行汇报沟通，形成全行共识，并获得对规划的认同和批准。
2.3 数据标准现状调研
n 业务需求采集：针对细节信息设计合理的调查问卷，最大限度减少业务人员的工作量，能够在短时间内帮助业务人员了解对标准建设的背景以及必要性、重要性，同时采集到业务部门目前主要存在的问题以及对标准的期望。
示例：业务调研问卷示例
n 系统现状调研：对包括数据结构、数据字典、系统之间的关系（数据流向）、重要业务规则在系统中的体现方式等方面的内容进行调研。需要各系统的管理维护人员提供相应支持，保证提供的材料文档说明能够跟现行系统保持高度一致。
示例：系统调研问卷示例
n 现状整理分析：将此阶段采集到的业务需求、现状问题等进行全面的整理，包括调查问卷汇总、数据结构/字典规范化、样本数据案例等，便于问题的汇总以及标准的现状差异分析和影响范围分析。
示例：现状整理分析过程文档示例
n 重点问题访谈：根据现状整理和分析的结果，结合数据标准建设的整体规划和目标，针对其中的重点问题如果存在了解不全面、采集信息存在歧义、参考文档不一致等情况，可以适当召集相关人员做专题访谈澄清问题，便于后续工作的开展。
2.4 基础数据标准设计
2.4.1 数据标准设计方法
本环节的主要工作内容如下：
1) 方法原则确定
结合现状调研的产出成果，确定各主题标准定义原则和定义方式以及大体的工作范围和详细程度。
2) 信息视图定义
根据各主题数据具体情况，进行大/中/小等不同层次的信息类定义，阐述其业务内涵以及应该包括的内容，以大/中/小类的组织方式形成业务视图。
3) 信息项定义
梳理每个类别下具体的信息项列表，针对每个信息项进行标准的设计工作，包括业务层面的定义和描述，力求完整、准确，尤其应明确标准在不同应用主题中的不同要求，如客户管理、风险管理、财务管理、运营管理四大应用主题对数据标准的具体要求；同时根据信息项的标准业务含义，为其定义技术属性，如数据类型、推荐长度等；如果信息项涉及到相关代码，同步进行整理和定义；如果信息项需要设定重要的检核规则，也可酌情、有选择地加以设置并与之关联。
4) 标准定义审核
组织相关部门和人员采用书面确认的方式对已经完成的标准定义工作进行检核和补充，如有必要，可针对未能达成共识的重要问题进行集中评审，应着重考察标准对业务的适用性、先进性和全面性等。
5) 管理员名单拟定
根据数据标准使用者和维护者，拟定相应管理员，并报领导小组进行审批。
2.4.2 数据标准设计原则
数据标准的定义应遵循共享性、唯一性、稳定性、可扩展性、前瞻性、可行性六大原则。随着业务的不断发展和标准需求的不断扩展延伸，需要科学合理地进行标准化工作，确保数据标准的可持续性发展。
共享性——作为全行共同遵循的准则，数据标准并不为特定部门服务，它所包含的定义内容应具有跨部门的共享特性。
唯一性——标准的命名、定义等内容应具有唯一性和排他性，不允许同一层次下标准内容出现二义性。
稳定性——数据标准需要保证其权威性，不应频繁对其进行修订或删除，应在特定范围和时间区间内尽量保持其稳定性。
可扩展性——数据标准并非一成不变的，业务环境的发展变化可能会触发标准定义的需求，因此数据标准应具有可扩展性，其体系架构应能应对标准的不断充实和更新。
前瞻性——数据标准定义应积极借鉴国际、国内、行业标准和规范，并充分参考同业的先进实践经验，使数据标准能够充分体现业务的发展方向。
可行性——数据标准应依托于现状，充分考虑业务改造风险和技术实施风险，并能够指导数据标准在业务、技术、操作、流程、应用等各个层面的落地工作。
2.4.3 客户主题数据标准设计
完整的客户信息是各类以客户为中心的分析应用的基础。通过建立客户主题数据标准，可以在全行范围内形成对客户的统一认识。基于全面一致的客户统一视图，业务部门可以更加透彻地洞察客户需求，为客户提供满足其需要的个性化的产品和服务，同时能够更精确地控制风险，从而提高银行收益。
客户主题数据标准的内容应包括：
n 客户定义
n 客户分类
n 客户信息模型
1) 客户定义
客户定义，即明确“谁是我们的客户”， 明确纳入客户主题数据标准的客户本质和内涵。
示例：客户定义
2) 客户分类
制定划分合理、覆盖全面、相对稳定的客户分类，并以此为基础开展信息模型的定义工作，一般客户类别包括公司客户、个人客户、同业客户三类。
3) 客户信息模型
客户主题信息模型应包括企业关心的与客户相关的各类信息。公司客户和同业客户属性可包括识别信息、财务信息、交易信息、信用信息、往来信息、管理信息等。个人客户属性可包括财务信息、关联信息、管理信息、识别信息、往来信息、信用信息、营销信息等。
2.4.4 产品主题数据标准设计
产品主题数据标准的目的是把不同的可销售产品和服务进行标准定义和规范分类，提供给业务部门一致通用的产品定义、不重不漏的产品目录和供识别产品的产品代码，从而实现更好的产品管理和产品盈利分析。
产品主题数据标准的内容应包括：
n 产品定义
n 产品分类
n 产品信息模型
n 产品清单
1) 产品定义
明确产品定义，即回答“什么是产品”的问题。一般来说，各业务部门因业务管理的侧重点不同，对产品的理解也可能是不同的。建立各部门通用的产品标准定义，将有助于统一各部门对产品的认识。
2) 产品分类
制定相对稳定的产品分类，分类结果可用于产品定位和管理。产品分类需遵循以下分类原则：
n 能够被行业普遍接受的
n 应该是相对稳定的
3) 产品信息模型
产品主题信息模型应涵盖企业关心的与产品相关的各类信息。包括：产品基本信息、产品管理信息、产品特征信息等。
4) 产品清单
基于产品定义和产品分类，建立现有的所有产品的清单，为全行提供可共享的产品描述，为业务部门针对产品的营销策划、分析应用等工作提供支撑和参考。
产品清单需遵循以下定义原则：
n 产品和产品间定义应界限分明，不应存在同一业务场景可以属于两个或两个以上产品的情况
n 产品应对应到一个且唯一一个产品最细分类中
n 产品粒度需适中，由全体业务部门共同决定是否按照特定维度进行细分，例如按币种、期限、对象等维度细分
示例1：如下是我们建议的产品清单的高阶分类
示例2：以下是产品清单成果的部分示例
|
产品编号 |
第一层 |
第二层 |
第三层 |
第四层 |
第五层 |
产品名称 |
产品定义 |
|
0001 |
零售银行 |
存款 |
自营存款 |
活期储蓄存款 |
|
活期储蓄存款 |
指个人存款人在我行开立账户存入资金或货币，由我行出具存款凭证，办理不约定期限、可随时存取并按期给付利息的存款。 |
|
0002 |
零售银行 |
存款 |
自营存款 |
定期储蓄存款 |
整存整取储蓄存款 |
整存整取储蓄存款 |
指个人存款人在我行开立账户存入资金或货币，由我行出具存款凭证，办理约定期限、利率，本金一次存入，到期一次性支取本息的存款。 |
|
0003 |
零售银行 |
存款 |
自营存款 |
定期储蓄存款 |
零存整取储蓄存款 |
零存整取储蓄存款 |
指个人存款人在我行开立账户存入资金或货币，由我行出具存款凭证，办理约定期限、利率，每月固定存额，到期一次性支取本息的存款。 |
|
0004 |
零售银行 |
存款 |
自营存款 |
定期储蓄存款 |
存本取息储蓄存款 |
存本取息储蓄存款 |
指个人存款人在我行开立账户存入资金或货币，由我行出具存款凭证，办理约定期限、利率，本金一次性存入，分次支取利息，到期一次支取本金的存款。 |
|
0312 |
零售银行 |
存款 |
自营存款 |
定期储蓄存款 |
整存零取储蓄存款 |
整存零取储蓄存款 |
指个人存款人在我行开立账户存入资金或货币，由我行出具存款凭证，办理约定期限、利率，本金一次性存入，按约定期次和金额支取本金，到期一次性支取利息的存款。 |
|
0005 |
零售银行 |
存款 |
自营存款 |
定期储蓄存款 |
教育储蓄存款 |
教育储蓄存款 |
指个人存款人在我行开立账户存入资金或货币，由我行出具存款凭证，办理约定期限、利率，每月固定存额、用于教育目的的专项定期储蓄存款，是一种专门为学生支付非义务教育所需教育金的专项储蓄，具有储户特定、存期灵活、总额控制、利率优惠、利息免税的特点。 |
|
0006 |
零售银行 |
存款 |
自营存款 |
定活两便存款 |
|
定活两便存款 |
指个人存款人在我行开立账户存入资金或货币，由我行出具存款凭证，办理不约定存期、本金一次性存入，支取时一次性支付全部本金和税后利息，具有定期和活期双重性质的一种存款 |
|
0007 |
零售银行 |
存款 |
自营存款 |
个人通知存款 |
|
个人通知存款 |
指个人存款人在我行开立账户存入资金或货币，由我行出具存款凭证，办理不约定存期，支取时需提前一定时间通知我行，约定支取日期和金额的存款。 |
2.4.5 合约主题数据标准设计
合约是客户和银行往来的重要载体，是银行分析和决策支持应用的基础，其主要特点是类型众多、含义丰富、数据分布广泛。合约主题的标准化工作旨在梳理合约主要分类及其重要信息项，以支持应用分析需求和合约跨系统整合识别。
合约主题数据标准的内容应包括：
n 合约定义
n 合约分类
n 合约核心信息
1) 合约定义
明确“什么是合约”，明确纳入合约主题数据标准的合约本质和内涵。
示例：合约定义示例
2) 合约分类
把银行不同用途的合约进行逻辑划分，提供各业务部门相对中性的合约分类定义。合约分类需遵循以下分类原则：
n 合约分类应该是被行业所普遍接受的
n 合约分类应该是跨部门统一的
n 合约分类之间应该没有重叠，且所有同层分类汇总应该包含银行现有的所有合约
n 同类合约应该具有相似的合约特征/功能/目的
n 合约分类应该粒度适中，兼顾合约信息项需求和统计分析需求
3) 合约核心信息
规范合约核心信息项，用来描述合约的关键信息。包括：合约基本信息、合约管理信息、合约资产信息等。
2.4.6 事件主题数据标准设计
事件是一个范围很广的概念，包括各种与银行相关的活动的详细情况，比如存款、提款、付款、收取信用卡年费、计算利息和费用、投诉、查询产品、查询地址、查询余额、网上交易等。
事件主题标准化工作旨在梳理交易主要分类及其重要信息项，以支持基于交易的各种绩效考核、风险监测、客户行为分析等应用，并为在数据层面进行事件跨系统识别提供依据和参考。
事件主题数据标准应包括：
n 事件定义
n 事件分类
n 事件核心信息
1) 事件定义
明确“什么是事件”，明确纳入事件主题数据标准的事件本质和内涵。
以下给出事件参考定义：
银行为满足客户的金融服务需求或自身的经营管理需要，进行的用来实现价值转移、服务提供的活动。
2) 事件分类
事件分类需要提供一种交易分类的依据，解决交易统计过程中口径交叉、相对不稳定的现状，并帮助银行和客户对事件形成共同的认知。
事件分类需遵循以下分类原则：
n 事件类型应该是排他的，即同一层次上不同的交易类型不能用于同一个交易场景中
n 事件类型应该是稳定的，不应随着统计分析需求变化而大幅变动，因此不宜粒度过细
n 同一事件分类下的不同事件信息项应尽量具有相似性。
3) 事件核心信息
规范事件核心信息项，用来描述事件的关键信息。包括：事件基本信息、事件管理信息、事件关系信息等。
2.4.7 渠道主题数据标准设计
渠道主题所描述的是当事双方（主要是指客户和银行）进行交互和接触的手段及方法，客户通过渠道与银行进行接触、购买产品、使用服务并交流信息。
渠道主题标准定义旨在全行范围内达成对渠道的统一认知，为各业务部门提供一致通用的渠道定义和逻辑清晰的渠道分类，并梳理渠道的信息项，以支持渠道管理和分析的需求。
渠道主题数据标准应包括：
n 渠道定义
n 渠道分类
n 渠道信息模型
1) 渠道定义
渠道定义，及明确“什么是渠道”， 明确纳入渠道主题数据标准的渠道本质和内涵。
以下给出渠道参考定义：
渠道是客户获取银行或银行产品的信息、购买或使用银行产品或服务的媒介。
2) 渠道分类
渠道分类需要提供一种具体渠道的分类依据，解决渠道统计分析过程中口径交叉、范围不清的现状，并帮助银行和客户对渠道形成共同的认知。
渠道分类需遵循以下分类原则：
n 依据渠道自然、固有属性进行分类，不应依部门或系统进行划分
n 应能覆盖所有的渠道
n 渠道分类不可交叉重叠
3) 渠道核心信息
渠道主题信息模型应包括企业关心的与渠道相关的各类信息。包括：渠道基本信息、渠道管理信息、渠道分析信息、渠道运营信息等。
2.4.8 专有类数据标准设计
根据的独特法人治理模式，通过机构主题设计专有的数据标准。
机构是银行进行内控和管理的重要对象。机构的定义不同、范围不同、命名不规范、编码方式不同、相互之间映射不完整、层级架构在不同系统中不一致等问题，将影响银行灵活高效地应对外部监管要求、满足内部统计分析和管理要求。
机构主题标准化工作将梳理各系统机构管理状况，达成全行范围内对机构的统一认知。
机构主题数据标准应包括：
n 机构定义
n 机构分类
n 机构信息模型
n 机构树
1) 机构定义
机构定义，即明确“什么是机构”， 明确纳入机构主题数据标准的机构本质和内涵。
示例：机构定义示例
2) 机构分类
为了便于进行内控和管理，需要制定一个机构的分类方法，该分类方法需根据机构基本、自然的属性进行划分，并适当考虑现有习惯和数据情况。
3) 机构信息模型
机构主题信息模型应包括企业关心的与机构相关的各类信息。包括：机构基本信息、机构管理信息、机构营业信息等。
示例：以下是机构模型的部分示例
|
信息大类 |
信息小类 |
信息项 |
|
基本信息 |
编码信息 |
机构编码 |
|
基本信息 |
编码信息 |
机构类型 |
|
基本信息 |
编码信息 |
机构层级 |
|
基本信息 |
编码信息 |
机构等级 |
|
基本信息 |
名称信息 |
机构中文全称 |
|
基本信息 |
名称信息 |
机构中文简称 |
|
基本信息 |
名称信息 |
机构英文全称 |
|
基本信息 |
名称信息 |
机构英文简称 |
|
基本信息 |
状态信息 |
机构状态 |
|
基本信息 |
物理地址 |
物理地址 |
|
基本信息 |
物理地址 |
国家代码 |
|
基本信息 |
物理地址 |
省份代码 |
|
基本信息 |
物理地址 |
地市代码 |
|
基本信息 |
物理地址 |
邮政编码 |
|
基本信息 |
物理地址 |
物理地址生效时间 |
|
基本信息 |
物理地址 |
物理地址失效时间 |
|
基本信息 |
电子地址 |
电子地址类型 |
|
基本信息 |
电子地址 |
电子地址 |
|
基本信息 |
电子地址 |
电子地址生效时间 |
|
基本信息 |
电子地址 |
电子地址失效时间 |
4) 机构树
梳理现有所有机构及机构之间的行政隶属关系，建立全行标准化的机构树。建立机构树所需的行政隶属关系必须具有稳定性强、边界明确、内部共识和外部认可等特点。
2.5 分析类数据标准设计
随着银行本身对管理需求的不断增加和监管报送要求的不断提高，全行需要一个全面、准确、统一的报送接口。
指标是银行对经营管理状况的定量评价，在统计分析、管理决策、监管报送中占据重要的地位，指标体系从全行级的视角对经营管理指标进行集中管理与统一定义。建立全行级指标体系：从管理层面上看，有利于统一经营管理指标的规范，实现指标的集中管理；从业务层面上看，指标库统一计算口径、业务定义、数据来源，在全行范围内保证指标数据的一致性；从数据层面上看，落地实施后经营管理指标实现集中加工与存储，既方便用户直接访问，也可以为其它应用提供数据服务，有利于数据共享，并保证数据的一致性。
指标体系对经营管理指标的编码、命名、维度、度量、管理、统计口径等信息进行规范定义，是对指标进行归类及管理的重要参照，有助于对指标的深入理解、合理使用和统一管理，指导指标的建设与持续完善。
本期工作的范围是完成对外监管报送（1104、人行大集中、标准化报送）和行内管理口径指标，统一指标在全行的命名、业务定义和统计口径，明确归口管理职责。
2.5.1 指标标准设计原则
2.5.1.1 指标准入原则
指标作为全行对内、对外通用的定量分析数据来源，对于进入作为指标体系进行预前加工和整理的重要数据信息，对每个作为指标进行管理的项必须能满足如下条件：
1. 必须是可量化的，对于定性评价不纳入指标库。
2. 使用范围广：在全行范围内公用
3. 必须是常规性的，周期性的。
4. 且至少满足以下条件之一：
a) 指标层次高：记录和揭示全行经营管理汇总状况
b) 对外报送：外部监管部门固定报送(1104、人行大集中、标准化报送)等
c) 报送高层：报送机构内部管理部门的指标
d) 重点关注：经营战略重点关注项指标
f) 管理需求：日常经营管理需求指标
2.5.1.2 指标粒度原则
在指标标准定义中，为避免指标的重复定义、保持指标粗细粒度的基本一致且较为合适，需要对原始指标进行合并或拆分。
1. 合并：根据常用维度与度量分类列表对指标需求进行合并。
2. 拆分：如果一个指标的计算公式中隐含了其它指标需求，则把该指标拆分为多个指标。
3. 作为准入原则之一，经营管理指标粒度不宜太细，维度的组合不宜过多。
4. 特殊情况处理
a) 监管部门指定的指标保留原状，不予合并。如正常类贷款迁徙率、关注类贷款迁徙率、次级类贷款迁徙率、可疑类贷款迁徙率继续保留，不必合并为贷款迁徙率。
b) 如果是特别关注的多维度组合指标，即保留原状，不予合并。
2.5.2 指标分类框架
指标是指对基础数据进行特定维度的汇总、整合、分析应用，通常按照一定的业务规则进行加工，拥有相对复杂的业务逻辑的数据。
根据各业务条线的业务需求和应用目标，进行指标的分类和层次的定义，阐述其业务内涵以及应该包括的内容，以大/中/小类的组织方式形成指标分类标准的业务视图。
示例：指标分类架构示例
2.5.3 指标标准设计
2.5.3.1 指标命名规则
1. 对于定义来源于外部的指标，以外部监管机构或部门的命名为准。
2. 同业通用的指标，优先考虑通用名称。
3. 对于内部定义的指标，
a) 比例类指标，如果是部分与整体之比，则命名为：××占比，否则，命名为：××比率或××率。
b) 时点金额指标：××余额。该指标的日均值，变化量，变化比例则分别命名为：××日均余额，××余额增量，××余额增长率
c) 统计区域、统计期间不在指标名称中体现。
d) 两个或数个差异指标的名称，在标准名称中加适用范围的简称（人行、银监会、行内等）以示区别。
2.5.3.2 指标定义
针对每个指标必须具有相应的指标含义的说明，每个指标的具体含义和功能进行详细的阐述，为后续的使用和理解提供清晰的解释。
2.5.3.3 指标信息项
指标信息项按照信息项目的不同用途可分为名称、管理、计算维度、度量、其他等5类，在实际使用时，根据指标的具体作用可进行合理的筛选和定义。
示例（指标整理时维度清单）：
|
信息项 |
含义 |
|
|
名称 |
指标编码 |
1. 是每一个指标的唯一标识,由系统自动产生。 |
|
指标名称 |
指标标准定义后的名称。 |
|
|
业务含义 |
统计指标的业务含义和相关用途。 |
|
|
管理 |
管理部门 |
指标提出部门。同一指标不能归属2个发起部门。 |
|
归属业务线 |
发起部门所属的业务线。 |
|
|
指标类型 |
总行统一规定类型名称，从管理的角度对指标的分类。 |
|
|
特色标识 |
对在某些方面的特殊性进行标识。 |
|
|
统计维度 |
机构维度 |
选择机构维度下的具体统计维度。（参见《公共维度列表》） |
|
币种维度 |
选择币种维度下的具体统计维度。（参见《公共维度列表》） |
|
|
时间维度 |
指标统计跨度。 |
|
|
可选维度1 |
除机构/币种之外的其他可能维度的具体统计维度，可在备选维度中至多选择2个进行组合。 |
|
|
可选维度2 |
||
|
度量 |
计算公式 |
具体计算公式。 |
|
度量类型 |
选择指标所属度量类型。 |
|
|
计算类型 |
选择指标涉及的计算类型。 |
|
|
计算频度 |
系统计算指标的频率。 |
|
示例(指标整理清单)：
2.6 数据标准映射
工作目标
此阶段的工作目标是将已定义的数据标准与现有系统，特别是关键系统如核心系统、信贷管理系统等系统数据进行映射，描述标准和现状的关系，以及可能的影响范围，作为后续差距分析和标准执行的输入。
工作内容
1) 工作范围确定
在现有的业务系统和应用中，制定系统选择的优先策略，针对稳定的（近期没有升级改造计划）的系统确定后续详细映射的工作范围，优先考虑核心系统、信贷管理系统等保存了较为重要、完整、准确的各类主题数据的系统。
2) 源系统分析
对选定的源系统进行详细分析，选取内容与标准涉及到的数据表、数据字段，并针对这些选中的数据抽取相关样本协助分析。
3) 样本数据分析
针对重要信息或者差异很大，而且跟先期规划重点相关的部分，需要对样本数据进行分析，以便更清晰地表现问题，并了解问题产生的背景。需要补充说明的是，此工作可能在整个项目进行过程中会持续、分批、分次开展。
4) 信息项映射
针对标准中具体的信息项，在准确理解其含义的基础上，将其映射到所有选中系统的数据表、数据字段上，建立两者关联关系。
示例：个人客户模型部分映射示例
组织专家小组对标准映射范围选取的适当性，映射的准确性等进行回顾和检查，并最终确认。
2.7 数据标准执行
工作目标
此阶段的工作目标是在标准映射的基础上，制定数据标准在现有系统中落地的实际方案和实施操作建议。
工作内容
1) 标准执行分析
通过数据标准映射，分析对数据标准的满足情况，明确当前存在的缺口。
2) 制定标准实施方案
根据映射分析的结果，制定各主题数据标准的落地实施方案。包括数据标准实施总体策略、定义和分类实施方案、信息模型实施方案等。
示例：客户主题实施方案
3) 制定标准实施操作建议
根据制定的数据标准实施方案，给出具体的实施操作建议，包括实施时机、操作流程、牵头责任部门等。
针对每个纳入到管理体系的指标，进行源系统满足度的分析，并映射具体的源表、字段的取数规则。对满足度较差的指标，进行后续使用影响分析以及源系统改造或调整建议。
2.8 数据标准维护与增强
数据标准管理工作包括数据标准建立发布、变更核准、定期复审和执行监督等内容，为规范相关流程，需制定相关的“管理办法”，各部门与数据标准制定、使用、维护和执行相关的人员开展数据标准管理工作时，应当遵守本办法。办法中应明确：
l 组织架构和职责分工
l 数据标准建立流程
l 数据标准变更流程
l 数据标准复审机制
l 数据标准执行流程
本项目对客户、机构和公共代码基础数据标准和指标数据标准进行全面分析和统一定义后，标准一经发布就会作为指导源系统建设的重要依据。随着时间推移，业务管理现状和系统建设现状在不停变化，当标准不能适用现状，需要对标准进行持续的维护和增强工作。依靠建立的数据标准制定流程，对标准进行持续的维护和增强，让标准始终满足需求和现状。
3 数据治理体系建设
3.1 数据治理体系的概念
数据治理（Data Governance）是国外银行业自90年代兴起的概念，业界权威组织Gartner对数据治理的定义是“数据治理是根据企业的数据治理政策，通过组织人员、流程和技术的相互协作，使企业能将数据作为企业的核心资产”。著名的国际数据管理协会（The Data Management Association）认为“数据治理是对数据管理的高层计划与控制，体现了数据资产管理的权威性和控制性活动（规划、监控和强制执行）”。从权威组织对数据治理的定义可以了解到数据治理是一个复杂的综合管理问题。数据治理是用于采集、存储、监控、使用、改进和保护企业数据的管理机制，其规定了在数据管理过程中，为达到期望目的而制定的权责划分以及职责体系。数据治理的核心是实现组织、制度、流程和技术的协同工作。具体来讲就是在企业的治理机构中成立数据治理机构（或虚拟组织），确定数据治理各层级的相关角色及职责，贯彻执行数据治理管控流程，使用技术工具等自动化手段，提升数据质量，充分利用数据，最大程度挖掘隐藏在数据当中的业务价值。
此外，数据治理与公司治理、数据管理之间既存在联系又存在区别。数据治理作为商业银行公司治理的一部分，是随着信息技术应用和银行风险管理及经营稳健要求的强化而新发展起来的一个新的公司治理领域。好的公司治理必然要有好的数据治理来支撑，通过明确数据使用者、数据所有者和数据管理者之间的权责关系，形成长久稳定、高效运转的管理机制。
数据治理不同于数据管理，数据管理就是在既定的数据治理模式下，管理层为达到数据质量目标而采取的行动，关注的是管理过程，例如数据质量管理、数据标准管理等。对于商业银行来讲，数据管理的内容会有很多，往往聚焦在某些专项领域。而数据治理要对所有数据管理活动进行统一计划与控制，例如通过专业的数据治理组织对各类数据管理活动涉及的资源进行协调，辅助决策层进行数据治理战略目标的制定。因此，数据治理可以理解为是对数据管理的管理。
3.2 数据治理体系评估诊断
数据治理体系诊断将根据XX的数据治理方法论与咨询规划思路的指引下进行，通过调研访谈、调查问卷、资料分析等方式，从组织架构、岗位职责、政策制度、业务管理、系统技术等方面对全行数据治理现状进行全面评估，并参照同业银行领先实践，对全行数据治理现状进行差距分析，提出改进建议。
3.2.1 数据治理体系评估模型
XX的数据治理评估模型分为六个阶段，各阶段定义如下图所示：
评估模型从数据治理的影响因素进行评估，用以评估银行的数据治理综合水平。
n 启动期
一般认为，数据治理的起步期出现在企业已经对信息技术具有一定的了解，并已经具备了一些职能化IT系统，希望利用信息技术和信息系统解决工作中的问题，给管理和业务带来便利。在这个阶段，企业主要关注面向业务处理的软硬件投资，对数据管理的理解停留在数据存储的层面，基本上不具备数据再利用的客观条件和主观意识，也没有面向数据的产品和服务。
n 理解期
在理解期，企业在业务处理方面大量投资进行系统建设，在这个阶段，我国大量地引进了欧美先进国家的软硬件。企业开始在数据层面寻求突破，初步意识到数据资源所具有的价值，开始进行数据的再利用，主要的应用领域偏好客户管理、绩效管理，手段以简单的统计分析为主。
n 变革期
在变革期，企业更加深刻体会到数据运用的价值，产生了大量的数据需求，尤其是一些全局性数据需求的出现。变更阶段是整个数据治理进程中重要的转折点，是此前的种种驱动力推动下从量变转向质变的一个跃变阶段，标志着企业进行有目的、有计划的数据治理工作的真正开始。在这一阶段，吸取此前缺乏计划和规划的教训，企业开始进行全面的规划，结合企业自身的战略规划制定系统规划和数据规划，使得信息系统的建设和改进均纳入既定安排中有序执行。
n 成长期
在随后的成长期，随着数据运用在企业中普及并向纵深发展，数据治理得以收到实效从而能够进一步促进数据的使用。在数据的有力支持下，企业的内部管理及对外营销均逐步实现精细化；而系统与数据则趋向于统一化：实现业务的集中处理以及数据的集中管理。在成长期，企业的信息化建设真正进入到数据处理阶段，在这一阶段，企业会选择统一的数据平台、数据管理体系，并建设的统一的数据管理平台，以技术手段统一数据的管理和使用，在部门间、系统间实现资源整合和信息共享。
n 全面竞争期
在全面竞争期，企业通过此前成功的数据治理获得竞争力，数据不仅仅是一种共享性资源，而成为企业的战略性资源。在此阶段，高质量数据基础以及丰富的数据处理经验使得企业具备价值衡量的能力，从而能够在做出各类决策的时候以价值为主要依据，以更快更准确的决策在与同业的竞争中取得优势；这些经验本身需要进行长期的积累，也是企业独有的竞争优势。在这一阶段，随着数据标准的全面推进，数据标准以及数据治理的其他工作逐步常态化。
n 创新期
在创新期，由于企业在数据治理方面取得卓越成效，对企业的业务也产生很大的助力，因此企业在行业中得以取得领先地位，取得举足轻重的话语权，成为行业标准的制订者。
总的来说，企业数据治理的各个发展阶段会在组织、流程、技术各方面具备以下特征：
|
|
组织 |
流程 |
技术 |
|
启动期 |
临时人员 |
无 |
手工 |
|
理解期 |
科技人员兼任 |
以项目为依托的临时流程 |
Office文档 分散的数据 |
|
变革期 |
专职或兼职； 有明确职责； |
系统内、部门内的固化流程 |
系统内数据管理 数据集市 |
|
成长期 |
专职组织； 人员增长； 分工细化； 数据服务； |
跨系统、跨部门固化流程 |
数据仓库 仓库级数据管理 企业级模型管理 |
|
竞争期 |
专职组织； 人员、分工常态化； 数据服务； |
全面的管理流程 |
企业级数据管理平台 |
|
创新期 |
专职组织； 人员、分工常态化； 数据服务； |
优化管理流程 |
动态数据仓库和企业级数据管理平台的结合 |
3.2.2 数据治理业内最佳实践示例
XX曾成功地为国内外多个银行做过数据治理咨询和交付数据治理服务，从中选取了一些的经典的数据治理最佳实践案例，经过多方面的分析和总结，列出部分最佳实践，这可以作为后续整个诊断的参考依据。
3.2.2.1 组织规划
n 都成立了数据治理相关部门，国内银行大多命名为：管理信息中心、管理信息部、信息服务和管理部等。这些部门有归属信息技术部的，也有归属业务部门的，还有的是独立的部门。
n 数据治理组织的成员由了解业务和技术方面的专家组成。
n 除了数据治理工作，大多数数据治理部门也提供数据服务内容，例如数据挖掘，灵活查询等。
3.2.2.2 政策制度
n 都有明文发布的企业数据治理章程，数据治理工作具有比较高的业务优先级。
n 每个业务部门在年初的计划中会设定数据质量目标，年终会考核相关人员的数据质量目标完成情况。
3.2.2.3 管理流程
n 数据治理流程在分配数据管理权时，是以数据域而非以项目和一次性活动进行。
n 数据治理流程贯穿从数据政策规划到软件开发管理、项目管理到运维管理等多种管理活动和流程中。
n 数据治理委员会制定了详细周全的沟通和培训计划，并且定期组织召开数据治理和认责会议，通报治理成果和指标。
n 定期进行数据治理投资回报(ROI)分析，并通过计算数据使用成本引导业务部门合理规范的使用数据。
3.2.2.4 技术手段
n 国内某大型金融企业，在开发中心建立了企业级元数据管理平台，并逐渐向数据标准管理、生命周期管理等数据治理专题方面进行扩展。
n 业界很多数据治理与认责实践都是从企业级数据仓库开始的。
这些最佳实践都可以在项目咨询过程中作为参考依据，为的数据治理提供方向性指导。
3.2.3 数据治理体系评估诊断方法
数据治理现状分析通过采用资料收集、调研问卷、现场访谈三类调研手段完成。通过现状调研达成以下三个目标：
n 了解近期及中长期在业务和技术上的策略及目标,特别是与数据治理有关的策略及目标；
n 梳理数据治理的详细现状；
通过书面访谈和现场访谈中的知识宣讲环节在全行更广泛的范围内营造数据治理的氛围，形成一定程度的共识。
3.3 数据治理体系蓝图设计
3.3.1 业界数据治理框架模型
数据治理是一个复杂的系统工程，涉及业务、技术和数据三方面的领域。为了能够概括、抽象地描述清楚数据治理工作的重点和范围，有必要通过框架来进行组织和分析。建立框架是科学研究中的一种常用方法，它可以从纷繁复杂的现实世界提炼出本质内容。框架所反映的不是事物的全部，它只抽象出事物的核心内容，忽略细节，突出重点，使复杂问题抽象化、简单化。
国际上一些得到广泛应用的数据治理框架有来自数据管理的专业组织和机构，也有来自在数据治理领域经验丰富的企业。这些框架源于数据治理的基本需求，面向多个行业，提供了可以借鉴的理论基础。本文对数据治理领域具有一定影响力的数据治理框架进行研究，并在此基础上建立符合我国商业银行业实际的体系框架。
3.3.1.1 DAMA数据治理框架
DAMA（Data Management Association）是国际数据管理协会的简称，是国际上首家服务于数据管理专业人员的专业组织，主要为数据管理专业制定标准和方法。DAMA数据治理框架是描述数据管理的框架，包括两个部分，一个是数据管理职能框架，一个是环境元素框架。
数据管理职能框架如下图所示，包括十大数据管理职能。中心要素是数据治理，在数据管理和使用层面之上进行规划、监督和控制。其余九个职能要素围绕数据治理核心开展活动。
图 4 1DAMA数据管理职能框架
以上十个职能要素分别包括多个活动清单，简要的职能定义如下：
n 数据治理
数据资产管理的权威性和控制性活动（规划、监视和强制执行）。数据治理是对数据管理的高层计划与控制。
n 数据架构管理
定义企业的数据需求，并设计蓝图以便满足这一需求。
n 数据开发
为满足企业的数据需求、设计、实施、与维护解决方案。也就是系统开发生命周期（SDLC）中以数据为主的活动，包括数据建模、数据需求分析、设计、实施和维护数据库中数据相关的解决方案。
n 数据操作管理
对于结构化的数据资产在整个数据生命周期（从数据的产生、获取到存档和清除）进行的规划、控制与支持。
n 数据安全管理
规划、开发和执行安全政策与措施，提供适当的身份以确认、授权、访问与审计。
n 参考数据和主数据管理
规划、实施和控制活动，以确保特定环境下的数值的“黄金版本”。
n 数据仓库和商务智能管理
规划、实施与控制过程，给管理层和决策层在报告，查询和分析过程中提供数据和技术支持。
n 文件和内容管理
规划、实施和控制在电子文件和物理记录（包括文本、图形、图像、声音及音像）中发现的数据储存，保护和访问问题。
n 元数据管理
为获得高质量的、整合的元数据而进行的规划、实施与控制活动。
n 数据质量管理
运用质量管理的技术来衡量、访问、提高和确保使用数据适当性的规划、实施与控制活动。
环境元素框架提供了一个逻辑和一致的方法，通过识别出过程（过程、交付成果、方法、元素）、技术和人（角色和责任、组织、文化）的关键元素，为每个数据管理职能提供战略规划指导。如下图所示：
图 4 2DAMA数据管理环境元素框架
基本的环境元素包括：
n 目标和原则
每个职能的方向性业务目标以及职能履行中的基本指导原则。
n 活动
每个职能都被进一步分解成更低层次的活动，一些活动组合在一起构成子职能，活动能被进一步分解成任务或步骤。
n 交付结果
作为每个职能的中间结果或最终结果建立起来的输出信息、物理数据库和文档。
n 角色和职责
在执行一个职能和对功能进行监督过程中所涉及的业务角色和 IT角色，以及在该职能中每个角色所涉及的具体责任。
支持性环境元素包括：
n 实践和规程
用于执行这些过程和生成交付结果的常见和流行的方法和具体技术，也可能包括常见的约定、推荐的最佳实践方法和简要介绍的候选方法。
n 技术
各种支撑技术（主要是软件工具）、标准和合约、产品选择标准和常见学习曲线。
n 组织和文化
主要包括汇报体系、权威和授权、共同价值和理念、企业传统以及变革管理。
3.3.1.2 DGI数据治理框架
数据治理研究协会DGI（Data Governance Institute）认为数据治理是确定数据相关的过程中的决策权和责任制的一个体系，根据一个描绘了谁、在什么情境下、使用何种方法可以对哪些数据做出何种举措的一致认同的模型，对数据进行管理。如下图所示：
DGI数据治理框架
DGI数据治理框架基于“5W”模型描述了组成数据治理的十大组成要素，并且表达了这些组成要素之间的关系和工作顺序。
首先是数据治理的目标，阐明为什么企业要进行数据治理。其次是数据治理关注的重点领域，值得一提的是，DGI数据治理框架在关注领域中明确了数据治理的六项主要内容，包括政策/标准/策略、数据质量、隐私/合规/安全、架构/集成、数据仓库与商业智能、管理支持；第三是数据规范和定义，指的是数据相关策略、标准和一致性要求，业务规范以及数据定义等；第四是决策权，在所有规范创建以及数据相关的决策做出之前，应该事先约定谁来做决定、何时做决定，使用哪些流程等；第五是问责制，明确数据所有者、管理者和使用者之间的彼此权利和责任；第六是控制机制，因为数据总是存在风险的，因此需要采取控制措施去预防风险事件的发生。
其次是人员和组织，包括数据相关者、数据治理办公室以及数据管理员。
最后是流程。包括预先定义、排列规则，在数据治理中提供跨边界的数据保护，当数据与规则出现不一致时的解决办法。
3.3.2 XX数据治理体系框架
XX的数据治理体系框架如下图所示：
数据治理体系框架
数据治理体系框架由以下五个部分组成：战略、机制、专题、实现、数据认责。这五个组成部分的简要介绍如下：
n 战略
数据治理工作是在银行的企业战略和企业规划的指引下进行设计，这些战略和规划包括业务发展目标、IT治理规划以及数据治理相关的发展规划。
- 数据治理目标和规划
遵循数据治理工作的总体目标和规划。
n 机制
机制是数据治理工作实施的保证，机制通过组织、制度、流程的建设和执行得以落实。机制是数据治理工作中的重点，数据治理执行效果就是机制的落实效果。
- 组织
组织是数据治理团队、角色、职责的统称，是数据治理体系建设的基础，以数据治理组织的引领才可能高效的开展数据治理相关工作，根据银行的组织架构现状，进行了数据治理部门的规划。数据治理组织的部门职责包括统筹规划、组织落实、日常管理、跟踪监控。
- 制度
数据治理中的人员、流程、技术通过数据治理制度进行实施和管理。数据治理制度包括数据政策、数据管理办法、操作手册。
本期项目规划三个数据治理专题管理办法：《数据标准管理办法》、《数据质量管理办法》。
- 流程
流程是数据治理工作可以有效展开的基础。
n 专题
数据治理专题是数据治理的工作内容。数据治理内容由多个专题组成，专题的数量和内容可以随着数据治理成熟度的提高而演进。
n 数据认责
数据认责是通过明确的数据相关责任，将机制、专题、实现结合起来，以贯彻执行数据治理工作任务。
n 实现
数据治理工作最终是通过具体的实现手段得以贯彻，数据治理的实现手段多种多样，包括了开发管理、治理平台等。
本次项目将以此治理体系为依据，建立的数据治理体系。其中，组织架构尤为重要。
3.3.3 数据治理组织架构
数据治理组织架构是数据治理体系建设的基础，建立数据治理组织架构才能有效的开展数据治理的日常工作。
建立数据治理组织架构的目的是：
n 负责数据管理者的职责
担当企业内部的数据管理者职责。协调业务和技术的配合部门，落实数据治理工作责任，确保数据治理工作有相应数据治理的参与者负责，将数据治理的每项具体工作内容落实到执行层面。
n 推动落实全行数据治理工作，建立决策、沟通、监控、考核的机制
建立数据治理决策机制，制订数据治理相关制度，推动数据相关活动的决策和执行，监控和考核进行的数据治理行动；通过专职的管理人员、专业的团队和专门的会议，形成数据治理的机制，定义和落实相关的数据治理举措，从而推动数据管理工作的整体发展。
n 建立培训和推广机制，创造数据治理文化
建立数据治理的培训和推广机制，催进数据治理相关的交流，通过数据治理部门的活动在全行创造数据治理的企业文化。
数据治理组织架构定义数据治理的参与方组成，以及相互之间的汇报和管理关系，相关角色的定义进一步明确数据治理参与各方的职责和能力需求。
3.3.3.1 专职部门的建设和原则
数据治理专职部门建设需要遵循以下五个原则：
- 前瞻性
数据治理专职部门建设需要与企业的发展战略和愿景相结合，数据治理专职部门的建设目标是为企业的发展服务的，因此在专职部门建设上需要考虑企业未来对数据治理的需求，为企业发展提供数据资产保障的支持。
- 渐进性
数据治理专职部门的组织架构会随着时间而不断演进，在不同的阶段数据治理组织形式会有所不同，在建设初期，从具体的需求和相应的数据治理价值驱动，后期可逐步建立完善的数据治理专职部门。
- 适应性
数据治理专职部门的建设需要适应目前银行的组织架构情况和数据管理现状，合理设置数据治理的组织架构，合理分配人员角色，在企业中全方位地建立数据治理的角色和职责。
- 专业性
数据治理需要有专门的、专业的人员进行管理，这些人员有技术的，也有业务的，同时还需要有管理方面的人员进行组织和协调。
- 集中性
数据治理专职部门与角色的建设须集中设置，集中设置的专业性的组织能够更有利于数据治理工作的推动，可以短期内集中优势力量达成数据治理专题目标。
- 服务性
数据治理专职部门的设立，是为了更好的向各业务部门和技术部门提供数据治理的相关服务。
3.3.3.2 数据治理专职部门的建设
通常来讲，数据治理专职部门架构策略可划分为分布式、联邦式和集中式三种，三种策略的特点、优势和挑战如所示。
分布式策略所有认责人员都是兼职，隶属于各个业务部门或技术部门，但现有组织架构不会受到影响，过渡平稳，缺点是管控力度太弱，对人员的组织协调能力和主观能动性要求比较高，但权威性不够。
联邦式策略配置了数据治理专职部门来牵头数据治理工作，有专职人员负责，问题处理有权威性，业务和技术部门中有常设的数据管理人员负责协调和沟通。
集中式策略设立的数据治理部门权力更大，专职人员更多，数据治理部门是一个集权部门，拥有所有系统和项目的数据所有权和管理权，业务部门和技术部门使用数据的时候要向该部门提出申请，经授权审批后方可使用。
3.3.3.3 角色与责任
n 决策层
决策层的工作职责主要是重大决策，监控数据治理投入产出成果，掌控数据治理总体发展方向，解决重大的认责冲突。数据治理的决策层包括：行领导和信息技术委员会。
n 管理层
- 数据治理部门
数据治理部门的主要工作职责是协调和指导企业数据治理的策略与流程、安排人员、制定角色职责并设置岗位，通过组织分层实现治理；在企业层面上和项目内部提供协调、沟通、信息共享、冲突仲裁的机制，调配资源，申请召开数据治理协调会议等。
数据治理部门包括以下的角色和分组：
- 数据管理主管
- 数据标准专题组
- 数据质量专题组
- 元数据专题组
- 数据生命周期专题组
n 执行层
数据治理的执行层分为两部分组成：
业务部门是数据认责角色中的数据拥有者(Data Owner)和数据使用者(Data User)。业务部门主要承担业务专家角色，负责提出数据需求和业务规则，协调部门业务专家参与数据治理相关工作，反馈数据治理在系统中实施的效果，指导对数据治理策略、标准和流程的调整。
技术部门是数据认责角色中的数据使用者(Data User)。技术部门承担技术支持角色，参与数据规划、数据标准定义、数据治理流程设计及维护、问题分析等工作，将数据治理流程落实到应用系统中。
- 业务部门执行层角色
- 数据协调员
- 业务专家
- 技术部门执行层角色
- 数据协调员
- 架构专家
- 需求专家
- DBA
3.3.4 数据治理部门职责
3.3.4.1 数据治理部门职责简介
流程是数据治理工作可以有效展开的基础。数据治理的各专题和组成的职责总体概括起来在以下四个工作职责范围内：
其中，统筹规划与跟踪监控是数据治理组织主要开展的工作，执行落实与日常管理是数据治理相关业务/技术部门的执行层开展的工作。
3.3.4.2 统筹规划
统筹规划工作职责是数据治理工作的总体规划部分包括以下几个内容：
n 路线图规划
制订数据治理发展路线图规划，包括组织的规划、制度的规划、各治理专题的发展规划、以及数据治理支撑技术的发展规划。
n 政策与规划制订
政策与规划制订的管理，主要包括以下的内容：
- 制订数据管理制度和管理政策。
- 制订数据治理相关主题的管理办法
- 制订数据治理的指标和考核办法
- 制订数据标准的定义
- 制订数据质量检查指标
- 制订数据安全和隐私规范
- 制订数据生命周期管理规范
n 政策管理
政策管理包括上述数据治理的政策、制度、管理办法和相关规范的：
- 新增
- 修改
- 审核
- 发布
- 版本维护
n 培训与推广
数据治理需要通过持续的培训和推广以达到提高数据价值和重要性的目的。通过培训和推广数据治理各个相关责任角色能够理解数据管理的问题和数据治理工作的价值。通过培训达到以下目标：
- 数据治理相关角色理解数据治理工作流程和数据认责机制
- 数据使用者清楚数据质量问题的管理流程
- 开发者清楚在软件生命周期的数据治理规范，以及合规检查流程
- 系统运维者清楚运维管理中的数据治理规范，以及处理流程
数据治理的推广手段包括以下：
- 问题管理会议
- 数据治理协调会议
- 定期的数据治理简报和邮件
3.3.4.3 组织落实
n 规范实施
数据治理规范的组织落实主要体现在软件开发生命周期管理过程中，主要实施的过程包括：
-
- 项目立项
- 业务需求
- 软需开发
- 模型和数据库的概要设计
- 模型和数据库的详细设计
n 评审
数据治理的实施落地的评审，主要是体现在软件开发生命周期管理过程中，在各阶段的评审工作中，对数据治理要素进行复查，检查系统是否按照数据治理相关规范进行设计和开发。
n 服务水平合约(SLA)制订
数据治理的组织落实的职责，还包括制订服务水平合约(SLA)，主要是体现在系统运维过程中，根据数据治理制订的规范（例如：数据质量规范、数据生命周期规范等）制订具体的服务水平合约内容（例如：对数据质量的要求、对数据访问的要求等）。
3.3.4.4 日常管理
n 数据治理专题管理
日常管理工作中，包括对数据治理的各专题的日常管理，主要包括以下部分：
- 数据质量日常运维管理
- 数据安全日常运维管理
- 数据生命周期规范执行
- 提供数据服务
n 服务水平合约管理
日常管理工作中，系统运维专家和数据治理运维人员对服务水平合约进行日常管理，主要包括以下部分：
- 数据质量监控
- 性能安全监控
- 数据时效性监控
- 性能和容量监控
n 数据治理冲突解决
日常管理工作中，包括解决数据治理的各种冲突，冲突包括但并不限于以下内容：
-
- 数据认责冲突
数据出现多人认责、无人认责或认责不清的情况。
-
- 数据标准冲突
数据标准与在建系统或者在升级系统发生冲突的情况。
-
- 数据质量冲突
数据质量发现问题归属冲突情况。
发生数据治理冲突问题，按照冲突解决流程进行解决，可以在执行层面解决的在执行层面解决，不能解决的升级到数据治理管理层和决策层进行解决。
n 问题管理
问题管理数据治理日常管理的重要组成。是为了解决数据治理中的问题而启动，数据治理的问题通常会启动冲突解决流程和问题管理流程，冲突解决流程重在问题的协调和解决；问题管理流程重在问题的跟踪和统计。问题管理由以下几个原因触发：
- 数据质量问题
- 数据认责冲突问题
- 数据命名规范和定义冲突
- 业务规则冲突
- 数据安全、隐私问题
- 监控发现不合规的治理问题
大多数问题都可以在数据治理执行层面解决；部分问题跨部门、跨系统和数据域，需要提交数据管理组织进行协调解决；少量问题涉及到数据治理战略、管理、规划相关的问题，需要提交决策层解决。
不论问题在哪个层面解决，都需要进行问题登记、问题解决状态跟踪、问题统计与分析，问题统计和分析的主要内容有：
- 问题状态
- 问题分类（所属专题、出现和解决日期、类型等）
- 问题解决方式
- 问题的根源部门、角色、流程和技术
3.3.4.5 跟踪监控
n 绩效考核
绩效考核是数据治理跟踪监控工作职责的重要部分，是对数据治理工作执行情况的全面评估，对数据治理相关部门和角色的工作评价，也是对数据治理规范和考核指标的修正过程。数据治理绩效考核根据规划流程中制订的各专题考核指标进行考核，绩效考核内容主要包括：
- 数据治理考核指标统计
- 数据治理考核指标评分
- 汇总统计结果发送指标干系人确认
- 生成和公布考核报告
n 定期开展的数据治理专项检查
除了在运维流程中被动的发现问题，数据治理组织会定期启动数据治理专项检查流程，通过主动的检查发现数据治理问题，这些流程主要包括以下内容：
- 数据标准规范检查
- 数据质量剖析
- 数据安全规范检查
- 元数据规范检查
- 数据生命周期规范检查
3.4 数据治理体系实施路线图
数据治理体系实施示例
如上图示例，基于数据治理体系设计成果，提出全行数据体系建设策略和发展目标，制定符合我行发展现状的未来3至5年的数据应用与服务、数据标准、数据质量、元数据管理、数据架构、数据保留与归档、数据隐私与安全等数据治理各领域的实施路线图
3.5 数据治理体系制度建设及落地指导
3.5.1 数据管理政策
数据质量的管理政策应包括管理办法和实施细则两个层次，并设计相应的技术规范和模板。具体框架如下图所示：
在具体咨询过程中，将根据行业最佳实践，建立自己的数据管理政策。
3.5.2 数据标准体系咨询与规划
3.5.2.1 数据标准管理办法
u 工作目标
为规范数据标准建设，符合国家标准化政策及监管统计规定，满足内部数据标准需求，特制定数据标准管理办法，用于明确数据标准管理内容、组织架构和职责、规范数据标准制定的行动，从而使数据标准管理从制度上有据可依，推动数据标准长期有效的指导行内数据管理工作。此管理办法是数据标准管理工作的总纲领。
u 工作内容
u 现状调研：
全面学习和了解的组织架构，充分理解各部门间职能、职责和权限划分，以及数据标准管理相关的人员、角色情况、当前IT系统开发流程等。
充分了解各业务部门对数据标准管理的观点和需求。
u 调研分析
基于以上的调研结果，进一步整理和分析数据标准管理方面的现状和需求，明确数据标准的管理者、关注着、执行者之间的关系。
u 成果产出
制定切合实际情况和数据标准管理需求的管理办法，包括数据标准组织架构与职责、数据标准制定的管理细则、数据标准应用的管理细则、和数据标准管理工具等内容。
3.5.2.2 数据标准管理组织架构
u 工作目标
在数据标准管理办法的指导下，细化数据标准管理组织架构，以期进一步明确数据标准管理的各部门间职责分工、角色权限、人员安排等情况。
u 工作内容
u 现状分析
基于上述数据标准管理办法的调研成果，进一步分析和清分数据标准管理现状的组织架构和人员情况。为数据标准管理组织架构的确定提供重要输入。
u 成果产出
制定切合实际情况和管理需求的数据标准组织架构。
示例：数据标准组织架构示例
3.5.2.3 数据标准管理流程
u 工作目标
在数据标准管理办法的指导下，进一步明确数据标准管理流程，以期明确数据标准管理员、专员、操作员等各岗位职能之间的分工和协作关系。
u 工作内容
u 现状分析
基于上述数据标准管理办法的调研成果，进一步分析部门间数据管理的现有流程、从而明确各部门间的数据标准管理职能和流程。为数据标准管理流程的确定提供重要输入。
u 成果产出
制定切合实际情况和管理需求的数据标准管理流程。
示例1：以数据标准制定流程为例
示例2：数据标准制定流程使用到的数据标准需求审批表示例
数据标准需求审批表
申请部门：【申请人所在部门】 总行/分行：【 】
|
申请人 |
|
所在处室 |
|
|
申请时间 |
|
需求类型 |
□新增 □变更 □落地 |
|
原因说明 |
【说明该需求的主要业务原因 】 |
||
|
需求详情 |
【说明该数据标准需求的详细情况，或附件说明】 |
||
|
需求提出部门负责人意见：
签字： 日期： |
|||
|
总行相关部门数据标准管理员意见：
签字： 日期： |
|||
3.5.3 数据质量体系咨询与规划
建立和颁布一套符合实际情况与需求的数据质量体系架构，包括：数据质量管理办法、数据质量管理业务流程，数据质量管理的组织架构、人员角色和岗位职责。
数据质量管理办法
u 工作目标
为进一步规范数据质量管理工作，有力支持业务运营、管理分析和决策，提升银行数据资产的业务价值，特制定数据质量管理办法，用于明确数据质量管理内容、组织架构和职责、规范数据质量问题管理，从而使数据质量管理从制度上有据可依，推动数据质量提升长期有效的运行下去，形成良性闭环。此管理办法是数据质量管理工作的总纲领。
u 工作内容
u 现状调研：
全面学习和了解的组织架构，充分理解各部门间职能、职责和权限划分，以及数据质量管理相关的人员、角色情况、当前IT系统在数据质量层面的管理和开发现状。
充分了解各业务部门对数据质量管理的观点和需求。
u 调研分析
基于以上的调研结果，进一步整理和分析数据管理方面的现状和需求，明确数据质量的管理者、关注着、受益者、执行者之间的关系。
u 成果产出
制定切合实际情况和管理需求的管理办法，包括数据质量管理组织架构与职责的细分、数据质量问题管理的细则、数据质量规则管理的细则、和明确管理工具等内容。
3.5.3.1 数据质量管理组织架构
u 工作目标
在数据质量管理办法的指导下，细化数据质量管理组织架构，以期进一步明确数据质量管理的各部门间职责分工、角色权限、人员安排等情况。
u 工作内容
u 现状分析
基于上述数据质量管理办法的调研成果，进一步分析和清分数据质量管理现状的组织架构和人员情况。为数据质量管理组织架构的确定提供重要输入。
u 成果产出
制定切合实际情况和管理需求的数据质量组织架构。
示例：数据质量组织架构示例
3.5.3.2 数据质量管理流程
u 工作目标
在数据质量管理办法的指导下，进一步明确数据质量管理流程，以期明确数据质量管理员、专员、操作员等各岗位职能之间的分工和协作关系。
u 工作内容
u 现状分析
基于上述数据质量管理办法的调研成果，进一步分析部门间数据管理的现有流程、从而明确各部门间的数据质量管理职能和流程。为数据质量管理流程的确定提供重要输入。
u 成果产出
制定切合实际情况和管理需求的数据质量管理流程。
3.5.3.3 数据质量考核办法
数据质量考核内容包括数据质量管理综合评价和关键主题数据质量综合评价两部分，每部分中的考评细项以指标方式体现。考评采取缺陷扣分制，总行部门及分行最大扣分值为10分，最小扣分值为0分。
- 数据质量管理综合评价是对数据质量管理相关的组织、人员、制度、流程、执行能力等的考评，包括数据质量管理的机制建设和履职情况两部分内容。
- 关键主题数据质量综合评价是对特定数据主题范围内的特定数据集的数据质量水平的考评，从各数据主题的数据质量的精确性、一致性等，以及监管报送数据的及时性、报送准确性、完整性和真实性等方面进行考评。关键主题是依据基础数据模型中定义的数据主题（如客户、产品等主题），结合考评期内全行重点关注的数据质量问题选取。
考核指标参考如下：
|
维度 |
分值说明 |
评价领域 |
考核指标 |
|
数据质量管理综合评价 |
最大扣分值1分，最大加分值0.3分 |
数据质量管理工作配合程度 |
数据质量管理工作配合度综合评价 |
|
数据质量管理工作落实情况 |
数据质量整改履职情况 |
||
|
数据质量管理工作主动性表现 |
数据质量问题发现及上报情况 |
4 数据质量提升方案建议
4.1 数据质量提升方案概述
通过对国内多个商业银行的数据治理经验总结出的一套完善的数据质量问题专项治理方法。
4.1.1 数据质量问题调研
对相关数据质量范围对业务系统及主管业务部门进行调研确定数据质量具体问题，调研内容包括以下方面：
n 问题产生的源系统；
n 问题具体描述；
n 问题产生的影响；
n 问题发现时间；
n 问题涉及到的表名、字段名；
n 业务系统的应急方案；
n 对源系统的要求。
下图为调研示意图。
4.1.2 数据质量问题统计
根据调研反馈的问题，编写程序进行问题数据统计，包括：
n 问题数据总数，统计相关表或字段产生的问题总数；
n 问题数据明细，统计相关问题重要信息项的明细情况。
下图为统计程序的示意图。
4.1.3 问题分析确定原因
将统计的数据反馈相关源系统，由其确认问题产生是由于自身程序导致或是外围系统下传造成，源系统需在规定的时间内完成确认锁定原因，原因包括：
n 源系统程序缺陷，对重要信息的输出端未加以逻辑控制，导致问题数据出现；
n 外围系统下传给源系统的数据，外围系统本身的数据存在问题；
n 源系统信息项不全所致。参考制定的相关主题标准对信息项进行补全，确保信息项完善；
n 指标口径不一致所致。参考制定的指标主题对相关指标进行逻辑调整，确保上下游关联系统之间同一指标的口径一致。
4.1.4 讨论确定需求责任
根据源系统反馈的原因，集中涉及到的相关部门进行讨论确定治理方案，包括业务部门、关联源系统等，讨论主要范围包括：
n 属于源系统程序缺陷问题，由业务部门提供业务逻辑，源系统根据业务逻辑进行程序控制优化；
n 属于外围系统下传问题，相关外围系统和源系统共同商讨程序优化方案，保证各步数据质量；
n 属于信息项不全的问题，由业务部门参考相关主题标准提出需求，源系统按需求补全信息项。
下图为需求责任认定示意图。
4.1.5 存量问题数据治理
对现存的问题数据进行治理，结合业务实际应用和系统现状确定数据治理方案，包括：
n 现存数据量较小且相对独立，可以通过业务部门提出差错单方式提取数据，源系统按正确的逻辑进行清理；
n 现存数据量较大且对下游系统产生影响，需要集中相关部门讨论确认清理方案。
待确定清理方案后，通过下发专项清理清单的形式对清理专题进行归纳整理，下图为清理前的示意图。
下图为清理后的示意图。
4.1.6 新增数据控制提升
为了保证新增数据的质量，后续避免新增数据出现同样的数据质量问题。
n 对已出现的涉及到程序缺陷的问题进行优化控制，由业务部门提供的逻辑源系统进行程序优化控制，保证输出端数据质量；
n 参考制定的各主题标准完善补全信息项，保证信息一致性、有效性、标准性。
4.1.7 数据质量检核监控
数据质量治理完成后，需要后续做好监控工作，包括制定一套检核体系对数据质量进行定期检核监控，确保数据质量。
n 制定检核规则
每月定期对相关系统进行数据质量检核，确定检核的业务规则，包括确定检核对象、检核主题等。
n 对检核结果进行考核
对检核对象进行考核，包括主管业务部门、业务系统、标准主题等，做到数据质量的监控。
4.2 数据质量度量标准
数据质量的度量标准，分为功能性和功能性的标准：
n 功能性
u 完整性：主要包括实体缺失、属性缺失、记录缺失和字段值缺失四个方面
u 唯一性：指主键唯一和候选键唯一两个方面
u 一致性：指统一数据来源、冗余存储和统一口径的一致性
u 准确性：指计量误差、度量单位等方面的精确度
u 合法性：主要包括格式、类型、值域和业务规则的有效性
n 非功能性
u 及时性：指数据刷新、修改和提取等的及时和快速性
u 安全性：主要包括数据在传输、使用过程中的安全性
u 扩展性：该系统数据体系在不满足业务需求时进行扩展的可能性与复杂度
除此之外，数据质量度量标准的制定还应从用户的视角进行考虑，重视用户对数据的满意程度。
4.3 数据质量检核规则
在数据的整个流转过程中涉及三种角色，即数据的产生者、数据的管理者、数据的使用者。数据的产生者是各业务系统，数据平台是数据的管理者，数据的使用者主要是各业务部门和其应用分析系统。数据从源业务系统流转到数据平台，在到下游数据应用系统，经过很多环节。数据质量问题可能来自多方面和多个环节，一般来说，数据质量问题（即低数据质量）可能源于以下方面：
1) 源业务系统的数据质量问题
n 信息不正确：指数据无效或错误，或者是应该填充的信息未填充，以及违反数据约束规则和业务规则等情况。
n 信息不完整： 指数据管理平台分析中所用到的内容，源系统存在遗漏或未填充的情况。有些信息在业务系统中不是作为必须填写的内容，但这些信息的缺失会严重影响数据管理平台系统的应用分析。
n 信息不一致：是指当同一信息内容来自于多个业务系统时，存在冲突和差异，或者同一业务系统内部的冗余信息之间存在冲突。
对于业务系统源数据的质量问题，需要把该问题反馈到业务系统，对源数据进行修正，并修改业务系统应用软件，或制定相关操作规范，确保该问题不再重现。
2) 数据平台的数据质量问题
除以上说明的源系统的数据质量问题外，数据平台本身也可能产生新的数据质量问题。
n 代码的数据质量问题
u 代码不完全、不合理：即数据平台统一编码不能很好地反映或包含各业务系统的代码，使得许多代码不能归类到数据管理平台编码，将导致数据平台统计分析报表中“未知”一栏的数量奇高，降低了应用分析的价值，并将影响使用人员对数据质量的信任度。
u 代码映射不合理：即把业务系统的代码归类到数据平台编码时有错误或不合理，这将导致数据平台统计分析报表中各分类数据与业务系统存在重大差距，而通常这是难以接受的，并将花费大量的精力来查找分析数据不一致的原因。
u 各业务系统代码发生调整，数据平台未同步修改： 业务系统的代码发生增加修改时，数据平台的代码映射未及时更新调整，这将导致所有新增的代码全部归类到数据平台编码的“未知”一类，同时对于修改的代码，当其含义发生变化时，未能调整归类到正确的数据管理平台编码。当业务系统的代码发生增加修改时，应及时维护代码映射表。
n ETL数据质量问题
ETL数据质量问题是指在把数据从业务系统抽取、传输、转换、加载到数据管理平台过程中，产生的数据缺失、数据错误等数据质量问题，包括技术性问题和非技术性问题。
u 技术性问题：包括脚本未按规范编写，存在语法错误或逻辑错误，或者没有遵循数据约束规则（如唯一性、引用性、非空等），所导致的数据质量问题。该问题由脚本维护人员进行修正。
u 非技术性问题：非技术性问题包括对业务规则理解不准确、代码规则不一致等产生的问题。非技术性问题通常需要项目组内部协商讨论，或者向业务专家、统计专家、系统维护人员咨询。
3) 数据应用的数据质量问题
数据应用层面的质量问题，也会出现如上的所述的代码问题和ETL质量等问题，除此之外，指标间一致性的质量问题在数据应用层面问题比较突出。
n 同一个指标在不同应用中的一致性问题：识别出是同一个指标，但在不同的报表间数据计算结果不同，通常是指标计算逻辑出错或者指标展现差异的质量问题。
n 指标间关系的一致性问题：如多个财务报表间的指标是有业务计算逻辑关系的，若指标不符合业务上的逻辑关系，通常可能因为指标口径差异、指标计算逻辑不一致导致的质量问题。数据质量的检核规则应由业务人员和技术人员共同参与制定，业务人员从业务的角度提出检查规则，技术人员从技术的角度实施检查。
4.4 数据质量认责方案
4.4.1 数据认责的概念
国内外许多企业已经认识到，数据不但是有竞争价值而且还是有战略意义的资产。为了让数据一致、准确、及时地交付给数据使用者，并让数据使用者充分地理解，企业必须对数据进行治理。
数据治理是围绕企业数据处理所进行的数据质量、数据政策、流程管理等一系列实践的融合，要以多种形式、综合使用各种技术手段来辅助，要赋予相关人员以相应的权力来建立和完善治理的流程。
数据认责和数据治理都是近十年间才出现的概念，仍在不断的发展演化过程中。数据认责的主要内涵是确定数据治理工作的相关各方的责任和关系，包括数据治理过程中的决策、执行、解释、汇报、协调等活动的参与方和负责方，以及各方承担的角色和职责等。
数据认责与数据治理密不可分，通过数据治理企业可以提高数据的可信性，而通过数据认责才能对数据治理的流程和方法施以主动控制。为了让数据治理工作能够有效运转下去，企业需要周密健全的数据认责机制来保障。
4.4.2 数据认责的原则
为了保证规划结果的合理性，数据认责体系规划要遵循下述原则：
n 数据认责体系规划是逐级论证的过程，结论的合理性是层层推导得来的，每个阶段都是下一阶段的基础，各阶段合理性都需要详细论证，这也就是规划的具体工作内容；
n 规划要与企业愿景和企业文化保持高度一致，规划要对非技术因素予以足够的重视；
n 规划过程要参考同业最佳实践，要融合数据治理工作组所有专家的知识、意见和反馈，要在现状分析和差异分析的基础上进行；
n 数据认责与数据治理采取相同的组织架构，组织架构参考了与数据治理行业的最佳实践；
n 认责角色职责、流程与数据标准、数据质量、元数据和角色要匹配一致。
具体内容要做到前后连贯、逻辑严谨、层层推进、多重视角。前后连贯指的是认责体系规划前后一致，行文要承前启后，而非突兀，不成体系；逻辑严谨是指规划要符合逻辑，形式与内容保持统一，细节与整体保持统一；层层推进是指规划要遵循上述流程，有优先顺序，而非没有章法，随意而为；多重视角说的是规划要站在不同的角度论证，同时涵盖IT部门和业务部门的观点，不失偏颇。
4.4.3 数据认责流程
数据治理要以全行的视角来协调和统领各个层面上的数据管理工作，确保银行内部各类人员能够在正确的时间、正确的环境获得可信的数据支持与服务，而促使和保障数据治理效果得以持续展现的则是完善的数据认责流程和健全的数据认责制度。
4.4.3.1 数据认责关系确认流程
数据认责关系确认流程描述的是创建和变更数据认责关系也即数据认责矩阵时要遵循的高阶流程。在业务部门或技术部门提出数据认责需求时，数据治理工作组/数据治理负责部门会组织收集需求，进行需求分类、过滤、筛选，并组织相关部门的工作人员小范围讨论，这时如果能够明确数据认责关系，就确认发布，如果有争议，就等定期召开的数据治理协调会议上广泛讨论后确定，如果仍有争议，就要升级至数据治理决策会议确定。
4.4.3.2 数据认责争议处理流程
数据认责争议处理流程是高阶数据认责问题解决流程，旨在以一种程式化的模式解决部门之间的数据认责争议，其中涉及了问题汇报、争议升级等处理措施。
数据认责争议处理流程与数据认责关系确认流程大致相似，业务部门或技术部门里承担各类认责角色的人员均可提出数据认责问题，由所在部门的数据协调员统一汇总记录后，提交至数据治理工作组/数据治理负责部门。数据治理工作组/数据治理负责部门记录问题后，确认数据认责问题影响边界和范围，并组织相关人员沟通讨论，商量解决方案，如果无法沟通协调，可升级争议至数据治理协调会议上解决，如仍无法协调，可再升级至数据治理决策会议上解决。数据治理决策会议是银行内部最高级别的治理会议，制定好解决方案以后，数据治理工作组/数据治理负责部门应监督争议的解决过程，并做好事后记录。
4.4.3.3 数据认责内部审查流程
数据认责内部审查流程旨在监督企业认责执行状况，并采取必要的修正措施改变缺陷，提升认责流程的执行力与效率。
数据认责内部审查首先由数据治理小组或数据治理负责部门牵头组织当次审查的临时团队，然后由临时团队以问卷调研、面对面访谈等形式开展为期一周或两周的认责内审活动，并形成数据认责内审报告，提交高层审核，让银行高层对于行内数据认责现状的认识能够得到及时更新。同时，针对数据认责内审报告中难以解决的问题，银行高层要督办数据治理工作组/数据治理负责部门着手解决，数据治理工作组/数据治理负责部门可择机组织召开数据治理协调会议/数据治理决策会议集中解决。
4.4.4 数据认责方法
数据认责的最终结果会以数据认责矩阵的形式呈现，数据认责矩阵亦称为数据认责表，记录的是数据治理工作相关各方的责任和关系。
数据认责矩阵在企业数据治理和认责中扮演着至关重要的角色，认责流程借助数据认责矩阵才能执行下去，缺乏数据认责矩阵认责流程就会无法正常运转，数据治理就不会达到预期的效果，数据认责矩阵的存在某种程度上提升了企业数据的有效利用率。数据认责矩阵的具体作用包括：
n 数据认责矩阵可以唯一指定数据认责关系，对企业内部的数据共享和数据复用起到支持作用；
n 数据认责矩阵可以有效消除一数多义，提升数据的唯一性、一致性；
n 使用数据认责矩阵可以有效识别某类数据的认责干系人，包括所有者、管理者和使用者；
n 数据认责矩阵可以使部门之间的沟通更加明确，针对性更强。
5
数据架构实施路线
XX对于数据架构实施路线规划思路如下：
1、进行整体逻辑架构规划，展现未来数据架构蓝图。
2、根据蓝图进行技术架构规划，明确需要实现的平台或功能。
3、技术架构逐块分析，给出技术方案和数据体系架构实施路线。
4、给出数据管控体系实施路线。
5、根据规划给出阶段性目标及计划。
5.1 数据体系架构建设规划
5.1.1 整体逻辑架构规划
结合业内先进经验，遵循数据体系架构平台化、构件化思路，规划逻辑架构如下图所示：
整体逻辑架构规划13项平台或功能构件，简单说明如下：
|
序号 |
平台或功能构件 |
说明 |
规划安排 |
|
1 |
数据仓库的数据管理 |
依托于数据管理平台部署数据仓库相关数据管理功能； |
总体规划 |
|
2 |
数据仓库的安全管理 |
依托于行内统一运维监控平台和数据仓库相关软硬件功能实现仓库安全管理； |
与数据安全与灾备建设项目衔接 |
|
3 |
ODS平台 |
负责支持贴源存储层数据存储，并且对外提供数据服务； |
总体规划 |
|
4 |
数据仓库平台 |
负责支持主题模型层、共性加工层、业务能力层模型存储和数据服务;同时满足主动式数据探索和模型实验室需要的数据存储和服务； |
总体规划 |
|
5 |
报表查询平台 |
满足统一报表平台、管理驾驶舱等以报表查询类为主的应用功能建设 |
专题规划 |
|
6 |
应用服务平台 |
满足专有计算、展示引擎的应用工具类产品部署平台； |
专题规划 |
|
7 |
主动探索平台 |
满足业务用户基于数据仓库的主动式数据探索服务功能建设； |
专题规划 |
|
8 |
数据挖掘平台 |
满足支持深入决策的挖掘模型构建、验证、监控以及模型管理功能建设； |
专题规划 |
|
9 |
数据仓库门户 |
满足基于集成型数据区面向各种用户访问的多种应用模式、功能集成； |
与数据仓库门户项目衔接 |
|
10 |
实时决策区 |
满足基于总线获取数据，基于内存数据库进行实时决策分析的功能建设； |
专题规划 |
|
11 |
大数据处理区 |
满足基于批量、实时流数据的半结构化、非结构化数据处理功能的建设； |
专题规划 |
|
12 |
历史数据存储区 |
满足数据归档以及支持历史数据访问； |
专题规划、与数据归档系统衔接 |
|
13 |
统一采集/交换/调度平台 |
满足全行统一非实时的数据采集、数据交换功能；满足统一的作业调度处理； |
专题规划 |
5.1.2 技术架构规划
为进行整体规划蓝图的落地，真正变规划为成果，我们根据逻辑架构规划了技术架构，对应各个实施单元，方便逐个分析并规划实施路径。技术架构如下图所示：
有了技术架构，我们会针对各模块给出一些技术方案策略和建议，并在咨询阶段和项目实施阶段加以细化和实现。技术方案大致包括：数据平台硬件选型、应用服务体系选型策略、统一访问门户、数据管控体系实施策略、平台管控策略、历史数据初始化策略、分行支持策略等。
5.2 数据体系架构实施路线
笼统来说，一般数据体系架构实施路线分准备阶段、数据仓库基础建设阶段、应用建设与管控提升阶段、全面推广与持续优化阶段。如下图所示。
5.2.1 数据管控体系实施规划
本次咨询将为数据管控体系实施及数据平台实施打下良好基础，我们队数据管控体系的实施规划如下：
5.2.2 数据体系架构实施规划
我们根据技术架构各模块技术方案实现难易程度，结合他行实施经验，给出陕西农信数据体系架构实施路线如下图所示：
5.3 阶段性目标及计划
数据体系架构实施第一阶段，阶段性目标及计划安排如下：
6 项目实施方案
6.1 项目计划
6.1.1 项目高阶计划
本期项目的项目高阶计划如下：
6.1.2 项目里程碑
为加强项目的监督管理，确保项目进度，本次项目拟设定的里程碑如下：
|
里程碑编号 |
预计完成时间 |
里程碑描述 |
|
1 |
第1周 |
完成项目启动并提交： |
|
2 |
第14周 |
完成数据治理体系评估诊断，数据治理体系规划设计，数据治理体系制度建设及落地指导等工作，并提交： 《数据治理体系设计报告》 《数据治理体系实施规划报告》 《管理信息中心职能规划及发展路线图》 《数据管理政策》 《数据管理工作考核办法》 《数据标准管理办法》 《数据质量管理办法》 《数据质量考核办法》 《数据标准体系规划》 |
|
3 |
第18周 |
完成数据标准咨询，并提交： 《分析类数据标准》 《专有类数据标准》 《数据标准差异分析及落地建议》 |
|
4 |
第22周 |
完成业务系统数据质量分析，提交： 《数据质量分析报表》 完成数据质量提升方案等工作，并提交： 《数据质量认责方案》 《数据架构体系实施规划》 |
|
6 |
第24周 |
汇报与评审，修改定稿并提交： |
6.2 项目组织架构及费用
6.2.1 项目组织架构
6.2.2 人力投入计划及费用
根据项目高阶计划和项目组织架构，我们规划的人力投入计划及费用如下：
6.3 项目交付成果
6.3.1 项目交付物
在本项目完成后向提交以下（但不限于）项目交付：
|
工作内容 |
提交物 |
|
数据治理体系评估诊断 |
数据治理体系现状诊断分析报告 |
|
数据治理体系规划设计 |
数据治理体系设计报告 数据治理体系实施规划报告 管理信息中心职能规划及发展路线图 |
|
数据治理体系制度建设及落地指导 |
数据管理政策 数据管理工作考核办法 数据标准管理办法 数据质量管理办法 数据质量考核办法 |
|
数据标准建设 |
数据标准体系规划 客户主题、机构主题、公共代码主题基础数据标准 核心指标标准 数据标准差异分析及落地建议 |
|
数据质量提升 |
数据质量度量规则定义、数据质量分析、改进方案和实施方案 数据质量认责方案 |
6.3.2 提交文档要求
n XX公司将指定文档管理人员，负责在各阶段向甲方提交项目文档。
n 文档编制既要严格按照项目开发规范的要求进行编写，针对不同的阅读者，文档应有不同的表达方法和不同的详细程度，并对今后的培训、运行、维护和管理具有较强的指导作用。
n 在项目进行过程中，应充分发挥文档的作用，指导整个项目工作。
n 除特别指明的并经甲方同意的英文提交文档之外，该项目要求提供中文文档。
n 电子文档交付格式要求：WORD、EXCEL、POWERPOINT、VISIO、MS PROJECT等原始电子文档形式，对于关键性的电子文档，同时提交PDF文件。
6.3.3 项目验收方法
6.3.3.1 项目验收流程
在本项目实施过程中，XX公司拟定项目验收流程如下：
n XX公司在正式验收前应该完成合同中规定的所有服务内容；
n XX公司提交所有的工作成果：包括文档和源代码；
n 在收到XX公司的工作成果后，根据验收标准，在1个月内开始验收；
n 通过确认、演示、分析等方法进行验收
n 如验收结果符合验收标准，与XX公司共同签署《项目验收报告》。经验收发现本项目不完全符合验收标准，但该种不符合不属于实质性不符合的，签署《项目遗留问题备忘录》，并由XX公司负责解决遗留问题。XX公司应在双方确定的期限内解决遗留问题，经验收后签署《项目验收报告》，最终签署该报告为验收合格。
6.3.3.2 项目验收方法
在项目验收工作中，主要包括以下四种验收方法：
n 确认：相关分析结果得到负责方的确认；
n 演示：通过对已批准的演示计划对提交件进行演示，证明提交件符合相关规格；
n 分析：通过专家意见、抽样等方法对系统及提交件进行分析，验证系统及提交件满足相关标准；
n 检验：对提交件进行检查，证明提交件满足相关规格。
6.3.3.3 双方职责
n XX公司职责：
u 在验收期间应积极进行运行问题的跟踪与分析工作；
u 在验收前根据规定的验收方法做好验收计划及所需环境与材料的准备；
u 及时向提交验收申请及有关材料；
u 及时按要求对验收过程出现的问题解决。
n 职责
u 配合及最终批准XX公司提交的验收申请与验收计划；
u 配合XX公司进行验收过程；
u 及时做出验收结论。
6.3.3.4 验收标准
4.3.3.4.1 文档验收标准
n 验收方法：演示与分析
n 验收通过标准：
u 要求提供中文文档。
u 电子文档交付格式要求：WORD、EXCEL、POWERPOINT、VISIO、MS PRJECT 等原始电子文档形式，对于关键性的电子文档，同时提交PDF 文件。
u 文档是否齐全，文档内容是否完整；
u 项目提交件文档是否符合“项目提交件”的要求；
u 内容充分性：指该文档全面、详细的程度；
u 图表翔实性：是否包含了足够的图形和表格；
u 内容一致性：是否存在前后矛盾；是否存在需求说明中提到的功能在概要设计、详细设计中没有涉及的情况；
u 文字明确性：不使用“可能”、“也许”、“待定”等语义含糊不清的语句；
u 易读性：能够在一篇文档中说明清楚的内容，尽量不要拆分成若干文档，不要循环引用，文档目录一目了然，结构清晰。
XX提交的文档或图纸在经批准后仍不得免除厂家保证文档正确性以及遵守合同各项规定的责任。XX不得以为遵守合同条款需要修订文档而造成耽搁为由收取额外费用和要求延期。如果XX被告知文件中存在错误、遗漏或前后不一致，无论在批准前或批准后，XX都必须立即修订该不足，并在发出通知之日起30日内重新提交给。
6.4 项目管理方案
6.4.1 项目沟通管理
项目沟通管理保证及时与恰当地生成、搜集、传播、存储、检索和最终处置项目信息所需的过程。本项目采用进场开发实施的方式。
6.4.1.1 项目沟通计划
在本项目执行过程中制定和维护一个顺畅、高效的沟通渠道和沟通方式对本项目的成败至关重要。
项目会议是服务于项目工作的，是为了更好的加强项目沟通、解决项目实施过程中存在的各种问题。每次会议都要有专人做会议记录，会议纪要的格式参见双方约定文档规范中的会议纪要模板，会后由记录人员将会议纪要分发给相关人员，并上传版本库中。
本项目根据项目实际情况拟设立以下项目会议形式。
6.4.1.1.1 项目小组周例会
n 会议时间：每周五下午2:30，必要时可作调整。
n 参加人员：项目小组全体成员。甲方项目经理和乙方项目经理应列席会议。
n 会议主持：会议由项目小组负责人主持。
n 会议议程：
u 总结本周项目小组工作情况，包括计划内工作完成情况、计划外工作和临时性工作执行情况；
u 讨论工作执行中遇到的各种问题；
u 交流工作经验；
u 针对项目进度计划安排下周工作；
n 会议结果：
项目小组负责人整理会议纪要，形成小组工作周报；
小组工作周报应于当日上报乙方项目经理，作为项目经理周例会的基础材料；
6.4.1.1.2 项目管理周例会
参加人员：双方项目经理、各项目小组负责人。若有必要，可邀请项目指导委员会成员参加会议。
会议时间：每周一上午9:30，必要时可作调整。
会议主持：会议由乙方项目经理主持。
会议议程：
总结上周项目进展情况，包括计划内工作完成情况、计划外工作和临时性工作执行情况；
已出现问题的解决状况；
提出项目组无法解决、需更高层领导决策的问题；
风险评估以及相应的预防、补救措施；
安排本周工作任务；
会议讨论；
会议总结；
会议结果：
u 由乙方项目经理整理会议纪要，形成项目周报，内容包括上周工作完成情况、问题及解决方案、本周计划工作、风险跟踪、需领导小组关注的事项等。
u 项目周报应在一个工作日内提交给甲方项目经理以供其审批。审批通过后的项目周报应发给各项目小组负责人，并报送项目指导委员会。
6.4.1.1.3 项目状态报告会议
n 参加人员：双方项目经理、项目指导委员会成员、项目领导小组成员（如有必要）。
n 会议时间：每月最后一个星期的周五上午9:30，具体时间由双方项目经理协商而定。
n 会议主持：会议由乙方项目经理主持。
n 会议议程：
总结本月项目进展情况，包括计划内工作完成情况、计划外工作和临时性工作执行情况；
已出现问题的解决状况；
提出项目组无法解决、需项目指导委员会或项目领导小组决策的问题；
风险评估以及相应的预防、补救措施；
汇报下月工作任务安排；
会议讨论；
会议总结；
n 会议结果：
u 由乙方项目经理整理会议纪要，形成项目状态报告，内容包括本月工作完成情况、问题及解决方案、下月计划工作、风险跟踪、需项目指导委员会和项目领导小组关注的事项等。
u 项目状态报告应在一个工作日内提交给甲方项目经理以供其审批。审批通过后的项目状态报告应报送项目指导委员会成员和项目领导小组。
6.4.1.1.4 临时会议
n 各项目小组、项目经理、项目指导委员会和项目领导小组根据需要可以召开临时会议；
n 临时会议须提前通知；
n 会议后，由临时会议发起人整理会议纪要，报送相关人员。
6.4.1.2 项目周报制度
EDW项目组内各小组于每周四上午提交各小组的项目周报，提交到项目经理；根据项目状态，总结各组提交的项目周报，形成项目组的状态周报，并于每周二下午5点之前上传到版本库中的周报目录上。
项目组周报将在每星期二发送给项目领导。
6.4.1.3 项目沟通手段
1) 开会或直接交流
按需要组织会议进行沟通，或者直接找相关的人进行讨论，注意记录沟通和讨论结果，重要问题讨论必须有书面会议记录。
2) 电话或电话会议
通过电话的方式进行信息沟通。对比较重要的事情，需要包括开发地点以外的人员，则需要利用电话会议的方式进行讨论，沟通。
3) 传真外部
定义收发传真的规范。
4) 电子邮件
建立项目组电子邮件系统及与外界联系的电子邮件系统。
5) 内部电子邮件
在项目组内部建立电子邮件系统，以便内部沟通。
6) 工作联系单
工作联系单作为重要的项目组与外界沟通方式，一般需由项目经理发起，特殊情况下由项目经理授权其他人员发起，项目经理审核。
6.4.1.4 项目沟通原则
沟通原则
项目组应遵循主动沟通和及时沟通的原则：项目工作中有相互依赖性时，项目组成员需主动与相关人员沟通。因沟通不及时而造成工作延误的责任不能推托给别人，由自己负责。
沟通方式
沟通方式以书面或邮件沟通为主，口头沟通为辅。书面或邮件沟通便于跟踪相关问题及处理结果，小组成员间的沟通要抄送给项目小组负责人，小组负责人之间的沟通要抄送给双方项目经理。口头沟通便于及时交流。
6.4.2 项目风险管理
风险管理作为项目管理的主要组成部分，应得到双方的高度重视，有责任在尽可能早的时期对风险进行识别，并进行分析、监控等工作，提出缓解计划与应对计划。
在本项目中XX公司负责项目的风险和成败，并指定专人对风险列表进行管理与监控，而甲方配合XX公司进行项目的风险管理，同时双方都应指定相关风险的责任人。
完整的风险管理包含以下几个主要部分：
6.4.2.1 风险管理的流程
风险管理包括：
n 定义标准的流程，以识别、分析评估、监控风险的防范
n 采用集中统一的风险日志工具，来记录和跟踪项目的风险
n 采用风险评估表，量化评估风险的可能性和影响程度
n 标准的风险报告
风险管理主要由项目经理负责，项目组的成员对于日常中发现的各种风险，都有责任汇报给风险管理的责任人。对于识别风险而产生的纠正与预防措施，指定责任人、列入项目计划进度表实施。风险管理内容包括：
识别风险：是管理风险的第一步，即识别整个项目过程中可能存在的风险。包括技术、性能、质量、组织、公司外、行为性等方面；
风险分析：风险分析的目的是确定每个风险对项目的影响大小，一般是对已经识别出来的项目风险进行量化估计。评估风险的影响、风险概率和风险值。
风险应对：确定风险的应对策略，编制风险应对计划。
风险监控：跟踪已识别风险的发展变化情况；根据风险的变化情况及时调整风险应对计划，每周周期性的提交《风险控制表》。
建立风险经验库，项目管理部根据各个项目的风险经验，管理和定期风险经验库，发布风险汇总表，为各个项目提高风险管理能力作参考。
6.4.2.2 风险的识别及控制
|
风险类别 |
风险描述 |
风险级别 |
风险责任人 |
控制措施 |
控制时间或者阶段 |
|
成本风险 |
未预见成本，如人员追加投入 |
1 |
项目风险经理 |
方案设计考虑周详，对甲方需求进行详细核查。 |
项目需求阶段 |
|
工作范围变动引起成本增加 |
2 |
项目风险经理 |
通过项目变更管理控制工作范围的变更 |
项目设计及咨询阶段 |
|
|
进度风险 |
需求变更引起的进度计划延误 |
1 |
项目风险经理 |
通过项目变更管理控制工作范围的变更 |
项目设计、咨询及推广阶段 |
|
资源配置缺乏、进度估算错误 |
2 |
项目风险经理 |
详细评估需求，设计合理性，系统需成熟技术及构件。 |
项目设计及咨询阶段 |
|
|
技术风险 |
产品质量及成熟度不够 |
3 |
项目风险经理 |
详细评估所采用产品的成熟度，并通过相关流程控制其质量 |
项目咨询及测试阶段 |
|
支撑平台及开发技术未达到预期 |
3 |
项目风险经理 |
尽量采用成熟或者已经实现或实施成功的技术 |
项目详细设计及咨询阶段 |
|
|
外部环境风险 |
政策变化及行业标准变动 |
3 |
项目风险经理 |
关注政策及行业标准变动 |
项目详细设计及咨询阶段 |
|
决策导向 |
2 |
项目风险经理 |
关注公司的战略决策。 |
项目计划及需求阶段 |
|
|
人员风险 |
流动及组织架构不当 |
1 |
项目风险经理 |
不断地对组织机构进行调整并与上级人员进行协调 |
项目周期 |
|
项目人员工作时间过长导致士气不振 |
1 |
项目风险经理 |
对项目组成员进行有效地激励 |
项目周期 |
|
|
运作风险 |
整个体系运作尚未正式启动，存在不可预见因素较多 |
1 |
项目风险经理 |
对计划进行详细评估，并在实施时对风险进行及时识别和跟踪 |
项目周期 |
注：（1）风险级别：1－需高度注意 2－中度注意，3－保持关注 （2）本表中的项目风险经理是指角色。
风险控制方法如下图：
风险的控制是通过不断地对风险进行识别和监控才能进行有效控制，因为每个阶段的风险以及风险级别都是不一样的。如上图只有通过不断地对风险进行跟综管理才能真正控制住风险，当然不可抗力因素除外。
6.4.2.3 风险控制工具
风险管理可以通过下图中的风险日志模板实现对风险的跟踪和识别。
6.4.3 项目变更管理
每个项目都会在技术设计、进度安排、预计成本、项目交付、甚至项目范围等方面上做出变更。如果不对此类变更进行缜密的控制，项目就很容易失控。“项目变更控制流程”正是用于管理项目实施期间发生的此类变更。这个流程的目的是协调和正确记录项目中出现的任何计划外情况。这个流程不仅适用于新的项目内容，也适用于对已有项目内容的增强。项目变更控制流程将从项目开始日期予以执行，并且在项目期间持续有效。
在本项目中，乙方项目经理负责制定和管理变更控制流程。通过该流程识别、归档对项目的变更，并且通过一个正式的批准和控制流程处理变更。此变更控制流程确保项目文档和合同得到更新以反映变更，确保预算和进度表得到调整，并且最终确保项目产生的解决方案可以按照客户的要求运行。
注：本文档中制定的“变更控制管理流程”不适用于处理甲方组织中的变更，或任何不在乙方控制或管理范围内的变更。
6.4.3.1 变更控制委员会
针对本项目，建议变更控制委员会由下列人员组成：
乙方：
n 项目指导委员会中乙方方人员
n 项目经理
n 咨询组组长
n 客户经理
甲方变更控制委员会包含以下人员：
n 项目指导委员会中甲方人员
n 项目经理
n 咨询组组长
6.4.3.2 变更控制流程
1) 变更申请
在项目实施期间，以下任何人员均可提出“变更申请”：
甲方项目经理
乙方项目经理，作为“风险管理”流程的一部分
小组成员，作为“项目小组报告流程”的一部分
乙方项目经理将评估内部变更请求是否需要更改对甲方做出的承诺。如果需要，内部变更请求必须转为正式变更请求，一起与甲方进行处理。
甲方和乙方将使用“项目变更申请报告”作为对任何所希望的项目变更的交流工具。项目变更申请报告说明变更内容、变更原因、以及对项目造成的影响。申请变更一方的项目经理将提交一份书面的《项目变更申请报告》给另一方的项目经理。
2) 变更评估和分析
甲方或乙方将对所接到的项目变更申请报告进行评估和分析，以便项目变更控制委员会决定是否批准、修改后批准、推迟决定做进一步研究、或予以否决。甲方和乙方将仔细评估和分析实施变更请求对项目成本和进度的影响。评估和分析的结果将产生一个修订的项目计划，在接受变更请求之前双方要复审这个修订的项目计划。
变更评估和分析是整个变更控制流程的关键部分。变更的影响需要在以下核心方面进行评估和分析：
n 成本影响
n 进度影响
n 服务范围（在“工作内容说明书”/“合同”中定义）的变更
n 提交件（在“工作内容说明书”/“功能规范”中定义）的变更
项目小组相关成员或乙方公司相关顾问（行业顾问以及解决方案专家）将协助乙方项目经理对变更影响进行评估和分析。
3) 变更审议和审批
项目变更控制委员会将审议变更评估和分析结果，并决定是否批准、修改后批准、推迟决定做进一步研究、或予以否决。
如果双方认可或拒绝了项目变更申请，甲方和乙方将填写并签署一份《项目变更申请评估及响应报告》，对任何增加费用和/或成本的金额数量和支付形式，以及任何对项目计划/项目进度的影响达成一致意见。乙方和甲方将举行会议协商合同的变更，合同的变更必须符合批准的《项目变更申请评估及响应报告》。
甲方项目经理和乙方项目经理将依据最终批准的项目变更在项目状态报告中记录任务计划和进度表的调整，以及变更的验收标准，更新项目计划，并且通知项目实施小组。
4) 变更执行
此子流程的目的是合并用于启动批准的“项目变更”所需的工作。它包括：
n 甲方项目经理和乙方项目经理向各自项目小组成员通报变更批准决定。
n 乙方项目经理与有关各方一起确认项目变更任务和阶段目标，以及时间进度、计划人员工作量和有关方面，以便实施变更。
n 乙方项目经理相应地更新“项目进度表”。
6.4.3.3 变更控制记录
在项目期限内发生和处理的所有变更请求的状态（拒绝/执行）、进度及其影响的“历史记录”将由乙方项目经理负责维护，并且将作为“变更控制记录”使用。
“变更控制记录”由乙方项目经理采用Excel或其它适当的文件格式维护，并在项目状态报告中进行报告。以下是“变更控制记录”的框架示例：
|
ID |
发起方 |
摘要 |
影响 |
输入日期 |
发起方 |
状态 |
|
CR1 |
|
|
|
|
|
|
|
CR2 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
“变更控制记录”包含有关所有变更请求的信息。
n “发起方”列应指出变更发起人。
n “摘要”列应指出变更内容、变更原因等。
n “影响”列应指出变更对项目造成的影响（高/中/低）。
n “输入日期”列应列出“变更请求”周期中主要事件的发生日期。
n “接收方”列应指出变更批准人或变更拒绝人。
n “状态”列应指出变更的状态（待决/拒绝/正在进行/完成并被接受）。如果拒绝变更，“状态”列应指出拒绝的时间及原因；如果没有拒绝，则指出批准时间、进度和实施时间、对配置项有何影响等。
6.4.4 项目文档
乙方项目经理和甲方项目经理应在本项目开始执行之前商议和确定项目文档管理的方针和策略。
如果甲方已经部署了公司范围的文档管理规范和文档管理工具，则本项目的文档管理工作将遵从甲方的项目文档管理规范，使用甲方的文档管理工具，由甲方项目经理负责提供项目文档管理规范和工具。如果甲方还没有已部署的标准文档管理规范，则建议在本项目中采用本章节制定的项目文档管理规范。
6.4.4.1 文档命名约定
本项目中所有正式成文的文档名称应遵循以下命名标准：
n HNB数据治理项目_文档名称_v版本号_日期.扩展名
其中：
n “HNB数据治理项目”为本项目的名称简称；
n “文档名称”为该文档内容的简要说明，例如“数据模型设计说明书”；
n “版本号”表示文档的当前版本，从1.0开始。在每次修订后版本号依次增加，例如1.1、2.0等；
n “日期”表示文档的提交日期，格式为：YYYYMMDD，例如20050601；
注：本“项目计划”也应遵循此定义的命名约定。文件名为“XXXX_项目计划_v1.0_YYYYMMDD.doc”。
6.4.4.2 文档目录结构
1) 目录命名约定
本项目中文档目录结构的目录名称应遵循以下命名标准：
n 编码＋目录名称
其中：
n “编码”是识别目录或子目录在目录结构中的位置的唯一编码。编目规则如下所述；
n “目录名称”是对该目录内容的简要说明。
2) 目录编码规则
目录编码规则如下：n
n 编码采用4位编码。如“0010项目计划”、“1100需求分析”，等等。
n 第一级目录将项目文档组织成“项目管理”类和“项目执行”类两大类。
n 第二级目录为工作大类目录，用于存放某类工作的工作产出。“项目管理”目录下的第二级目录编码为“0XXX”， 例如“0010项目计划”、“0020项目报告”等，目录编码按“10”增加，为可能的下级子目录留出10级的编码空间。“项目执行”目录下的第二级目录编码首位从“1”开始，即“1XXX”、“2XXX”，等等。
n 第三级目录为某工作大类下的具体工作目录，存放具体工作的工作产出。“项目管理”目录下的第三级目录编码按“1”增加，例如“0022项目周报”、“0023项目状态报告”等等。“项目执行”目录下的第三级目录编码按“10”增加，例如“1910应用规划”、“1920应用开发”，等等，为可能的下级子目录留出10级的编码空间。
n 原则上在“项目管理”的第三级目录下不再创建子目录。可以视具体情况在“项目执行”的第三级目录下再创建子目录。
n 下级子目录的编码将继承其上级目录的编码，并按顺序递增。
3) 新目录创建流程
在项目执行过程中，如果需要在第三级目录下增加第四级目录，则应由项目小组负责人向乙方项目经理提出，由乙方项目经理创建或指定相关人员创建。在创建任何子目录时，创建者必须考虑以下因素：
n 只能在第三级目录下增加第四级目录。
n 子目录必须遵守上述目录命名标准，以主目录的编码及其在主目录中的顺序为依据进行命名
n 在项目期间的任何时候创建新的子目录，所有项目小组成员都应得到通知。
6.4.4.3 文档模版
乙方项目经理已经为本项目准备了必要的项目管理文档和项目实施文档的模板文件。本项目的所有正式成文文档应按照规定的模板格式进行编写。这些文档模板文件保存在文档目录结构中“过程模板”目录下。
在项目执行过程中，如果需要增加文档模板文件，则应由项目小组负责人向乙方项目经理提出，由乙方项目经理制定或指定相关人员制定。
6.4.4.4 文档管理环境
1) 文档服务器与文档管理工具
甲方应为本项目准备一台专用的文档服务器，以存放所有正式成文的文档和项目最终提交件。文档服务器的配置要求如下：
Windows操作系统；
2GB内存以上；
足够的硬盘空间（建议最少120GB）；
TCP/IP网络连接；
另外，甲方还应为本项目准备适用的文档管理工具。推荐使用微软公司的Visual SourceSafe (VSS)软件。
2) 文档服务器系统管理员
乙方项目经理和甲方项目经理应共同商定委派专人作为文档服务器的系统管理员（可由系统管理员或数据库管理员担当）。文档服务器的系统管理员应负责：
安装和配置文档管理工具软件；
为项目团队成员建立用户账户，并授予相应的访问权限；
当增减项目团队成员或访问权限发生变更时，及时通知所有项目团队成员。
维护文档服务器的稳定运行，定期备份所有重要的文件（操作系统文件、系统配置文件、项目提交文档、等等）。
6.5 项目质量保障计划
任何与项目有关的事件及过程都是项目管理所应关注、协调、管理的，一般包括下面几个主要方面：
l 项目过程管理
l 项目质量管理
l 项目变更管理
l 项目风险管理
项目管理系统的内容及流程如下图：
XX公司现行的质量管理体系是基于ISO9001：2000标准和CMM标准之上的一套相对完善的质量管理体系。通过实施ISO001:2000标准，使得公司在产品的生命周期（从售前到维护）以及相关资源的使用都有了明确的规范。在此之上，公司又投入大量人力和资金实施CMMI5级标准，使得我公司软件开发过程更加精细和灵活，也使得公司质量管理体系更加适合于各种类型的软件项目，软件产品质量有了进一步保证。
本项目在实施过程中将严格遵守公司的质量管理体系（符合ISO9001:2000和CMMI5标准），生产一流质量的软件产品。在实施过程中公司将派出独立于项目组之外的人员担任项目组的SQA（软件质量保证员），辅导和监督项目组实施质量管理体系，同时还定期和不定期对项目组的质量管理活动进行审核。
以下各小节将从质量控制体系的内容、质量控制体系的实施要点、主要角色和职责和项目过程文档等几个方面阐述本项目的质量管理和控制。
1.1.
6.5.1 质量控制体系
XX的质量控制体系文档包括四个层次的文档，它们是：
l 质量手册；
l 流程文件；
l 模板、指南；
l 表单；
本节分别从流程的主要功能和流程关系图来阐述质量控制体系的大致概貌。
6.5.1.1 流程文件
仅列出与本项目相关的流程：
|
标准 |
流程名称 |
主要功能 |
|
IS09001 |
质量手册 |
质量管理体系的总体描述文件和索引文件，质量手册通常至少应包括或涉及： 1、质量方针； 2、影响质量的管理、执行、验证或评审工作人员的职责、权限及相互关系； 3、质量体系程序 |
|
IS09001 |
文件管理流程 |
本流程对公司质量体系所要求的文件和资料的编写、发放、使用、修改和作废等过程进行控制，以确保公司各部门和工作场所使用现行有效的文件和资料，并保持公司质量管理体系运行的符合性。 |
|
IS09001 |
记录管理流程 |
本流程文件规定了质量活动过程中各种记录的标识、存储、检索、保护、保存期限和处置的方法和流程，用于证实产品质量满足规定要求的程度，为评价质量体系运行的有效性提供客观依据，并为保持产品可追溯性以及采取纠正和预防措施提供依据。 |
|
IS09001 |
目标管理流程 |
明确公司质量目标的制定、审核、分配、反馈所应执行的过程，以及为实现目标分解、反馈应开展的活动。 |
|
IS09001 |
合同管理流程 |
使合同的各项管理制度化、规范化，减少合同风险，确保合同的正常实施。 |
|
IS09001 |
系统集成流程 |
规范公司系统集成的售前、实施、售后工作。 |
|
IS09001 |
售前支持流程 |
规范公司软件项目、系统集成的售前支持。 |
|
IS09001 |
风险管理流程 |
规范软件开发风险管理流程，确保风险得到标识和有效控制。 |
|
IS09001 |
客户培训流程 |
有效管理客户培训过程的策划、组织、实施和反馈改进的过程，确保客户培训过程质量和客户满意度。 |
|
IS09001 |
客户满意度流程 |
调查、分析客户满意度，为管理评审提供分析数据，提高产品和服务质量。 |
|
IS09001 |
售后服务流程 |
规范本公司的售后服务执行、客户服务受理过程，确保服务过程和质量满足客户要求，达到客户满意。 |
|
IS09001 |
内部审核流程 |
规定了本公司进行内部审核的工作内容和方法，以评价公司质量体系与ISO9001：2000标准的符合性以及质量体系的有效性，审核质量体系所开展的质量活动及其结果是否符合计划规定的安排，确保质量体系持续有效的运行，并为管理评审和质量体系的持续改进提供依据。 |
|
IS09001 |
不合格品管理流程 |
本流程针对为客户提供的软硬件产品、客户服务以及采购产品中出现的不合格品进行控制以确保不合格品得到纠正，确保软硬件产品、服务过程和采购产品的质量，并为质量改进提供分析依据。 |
|
IS09001 |
数据分析与持续改进流程 |
该流程规定了对质量活动中的记录数据进行分析的过程要求，提出纠正和预防措施，实现质量管理体系的持续改进；有效的确定、验证和评价质量活动的过程能力及产品和服务的符合性，为质量改进提供依据。 |
|
IS09001 |
纠正与预防流程 |
规定纠正、预防措施的制定、实施和跟踪管理要求；确定质量管理体系运行中已出现或可能出现的潜在不合格项及不合格服务，分析其原因，采取预防和纠正措施，防止不合格再发生或潜在不合格的发生。 |
|
CMM |
RM-2-01需求管理流程 |
此文档的目的是建立软件解决项目的管理需求的步骤。基本步骤包括： . 收集总体需求； . 控制需求变更。 |
|
CMM |
RM-2-02需求变更管理流程 |
需求变更管理流程的目的是通过跟踪、控制需求变更的全过程，保证系统中所有的文档、软件、源代码等软件工作产品的一致性，进而提高软件质量。 |
|
CMM |
SPP-2-01项目计划流程 |
l 为执行软件工程活动和管理软件项目制定合理的计划； l 为项目建立估算，以便在项目计划和项目跟踪过程中使用； l 确定项目开发的活动和承诺，文档化，逐步向客户履行承诺； l 相关组织和个人认同项目计划约定。 |
|
CMM |
SPP-2-02估算流程 |
义公司项目估算的过程，推荐几种估算方法，对软件规模、工作量、成本、进 度、关键计算机资源进行估算，以便制定合理的项目计划。 |
|
CMM |
SPTO-2-01 软件项目跟踪与监控流程 |
根据文档化的软件项目计划来跟踪和审查软件的完成情况和成果，使管理者在软件项目的实际性能明显偏离软件计划时进行纠正偏差和（或）调整项目计划，提高对项目实际进展的可视性。 |
|
CMM |
SQA-2-01 软件质量保证流程 |
向高级经理提 供适当的对软件项目开发过程活动和开发中产品的可视性。它通过对软件产品和活 动进行评审和审查，验证是否符合已定义的计划、流程和标准，并向高级经理、项目经理提供评审和审查的结果，使软件项目满足我公司软件开发方针的要求，确保项目实施中质量问题尽早发现并解决，为公司定期进行的内部质量审核提供数据，为高级经理在项目实施过程中的决策提供相关依据。 |
|
CMM |
SCM-2-01 软件配置管理流程 |
l 在项目的整个软件生命周期中，建立和维护软件产品的完整性 l 。 l 使软件配置管理活动是有计划的； l 所选定的软件工作产品是经过标识、受控和可用的； l 对已标识的软件工作产品的变更是受控的； l 使受影响的组和个人能及时得到基线的状态和内容。
|
|
CMM |
SCM-2-02 配置项变更控制流程 |
描述对已标识的软件工作产品的变更控制流程。 |
|
CMM |
OPF-2-01组织过程焦点和定义 |
指导制定和维护组织的标准软件过程；对照过程标准，收集和评审相关软件项目使用ossp的信息，使得公司所用的软件过程的优点和缺点能被识别。 指导公司范围内标准过程的制定和改进活动，使得公司过程能力不断得到提高。 公司层软件过程的制定和改进活动是有计划进行的。在整个公司中，软件过程的制定和改进活动是协调一致的。 |
|
CMM |
SPE-2-01 设计流程 |
描述软件的设计、编码、测试和发布过程。 |
|
CMM |
SPE-2-02 编码流程 |
|
|
CMM |
SPE-2-03 单元测试流程 |
|
|
CMM |
SPE-2-04 集成测试流程 |
|
|
CMM |
SPE-2-05 系统测试流程 |
|
|
CMM |
SPE-2-06 发布-上线流程 |
|
|
CMM |
IC-2-01 组间协调流程 |
组间协调的目的是识别项目开发过程中的关键依赖关系，消除软件开发小组和各关键实施小组之间的问题和矛盾，确保软件开发小组和各实施小组全体成员随时了解项目进度，有序、高效地进行项目建设，从而使项目有效果和高效率地、更好地满足客户需求。 |
6.5.1.2 公司ISO9001：2000体系流程的关系图
公司ISO9001：2000体系的各流程不是独立工作的，他们之间协调一致的工作才能保证体系的有效性。公司体系流程的相互关系大致如下：
6.5.1.3 CMMI软件过程体系结构图
质量控制体系的实施要点
许多公司虽然有一套质量管理体系文档，但却无法按体系的规定去实施。造成这种情况的主要原因在于体系落实和实施。体系不能落实，质量管理过程就得不到执行，软件质量就无从保证。XX公司非常重视质量管理体系的落实问题。XX在体系落实方面主要有以下几个手段：
成立专门的部门（项目管理部）负责主持制定、维护和推广质量管理体系，同时具体项目还有专人进行跟踪、落实；
各项目组都设有相关的质量目标，质量目标的完成情况与项目组和个人的绩效考核挂钩，目标完成情况直接影响个人的奖金发放，以此提高项目组实施质量管理过程的主动性和自觉性；
公司还组织定期的审核活动，包括ISO9001体系的内部审核和SQA的各种审核活动，进一步促进质量管理体系的落实和不断改进。
以下小节将分别介绍目标管理、组织级SQA和监督审核的大致情况。
1、目标管理
项目组的目标主要包括质量、成本、进度和范围四个方面的目标，其中质量目标一般会有以下一些内容：
|
目标名称 |
说明 |
|
测试效率 |
测试检测缺陷数/测试阶段总工作量 |
|
评审工作量比例 |
实际阶段评审工作量/实际阶段总工作量 |
|
交付质量 |
release后检测所有缺陷数/标准交付代码行数 |
|
评审效率 |
评审的文档页数/评审会议用时 |
|
评审效果 |
发现的缺陷数/评审的文档页数 |
|
缺陷密度(FD) |
评审缺陷总数/文档页数 |
|
过程符合度 |
∑（不一致问题*严重系数）/项目规模(人月) |
2、组织级的SQA
XX公司设有组织级的SQA。他们独立于项目组之外，分别隶属不同的部门管理。这样才能在制度上保证质量审核人员可以独立的、不受干扰的审核项目组的质量管理过程执行情况，督促和报告项目的质量情况，进而保证软件开发质量。
目前XX的SQA都经过了严格的培训，同时他们也都参与了公司质量管理体系的编制、维护和推广工作，对公司的质量管理体系有着深刻的了解。他们都能很好的胜任项目组的SQA工作，并辅导项目组实施质量管理体系。
3、角色职责
在项目实施过程中，有关质量管理的角色有SQA（软件质量保证人员）和CMO（配置管理员）。他们的职责说明如下：
|
角色 |
职责 |
|
SQA |
1 制定SQA 计划，并按计划进行软件质量的保证工作。 2 参与项目计划和适用于该项目的《PDSP》的制定（包括标准和流程）。 3 定期或事件驱动地审查项目的软件开发活动和工作产品，确保各项开发活动都遵照项目计划和组织的标准、流程来执行，并记录不一致问题。 4 跟踪解决不一致问题，上报项目组内部不能解决的不一致问题。 5 定期或事件驱动地向项目经理、高级经理汇报工作。 6 对开发人员进行软件质量保证知识的相关培训。 7 进行软件生命周期全过程质量数据的收集和分析。 |
|
CMO |
8 负责创建和管理项目软件基线库。 9 制定、维护和发布SCM计划。 10 制定配置项清单。 11 管理对基线库的访问。 12 更新软件基线。 13 从基线库中生成工作产品。 14 记录SCM活动。 15 生成和发布SCM报告。 |
6.5.2 评审和审计管理
在开发的每个阶段，项目管理组在项目评审小组的指导下，组织对阶段性交付物进行评审和审计。评审包含技术和管理方面的评审。
项目评审组：根据要求，项目评审组由项目经理，项目副经理和质量管理员构成。
项目评审活动：活动开展方法包括正式的评审、检视和代码走查等REVIEW活动。包含：
l 对项目实施计划、标准、过程、需求分析、程序设计、数据库设计、用户操作手册、测试用例、测试报告等进行评审；
l 对程序代码进行走查和评审；
l 对项目组的阶段性工作进行管理评审。
通过评审规程规范项目组的评审开展，质量管理小组对评审过程进行审计，每个文档和代码的评审采用查检单（checklist），规范，指导评审应该达到的效果
质量管理小组参与所有的评审活动，确保评审过程有效和发现的缺陷能够得到跟踪和解决，并向双方项目经理做出阶段质量评估报告。
6.5.3 项目实施过程其他质量控制细节
n XX将为本项目配备专职QA人员并提供足够的测试人员，来保证每一阶段，每一版本的的测试进度及测试质量。QA及测试组将直接向项目决策层汇报，不对项目经理负责。
n QA人员在项目前期就参与项目，并开始根据客户需求做测试案例。
n 在需求确认后，设计完成时就确定了测试方案，在项目组第一个子系统发布之时开始，项目组将每天提交一个编译版本（DailyBuild），给XX测试人员进行功能测试。
n 开发人员的单元测试结果和代码一起入库(Checkin)。
n 项目组合理地安排每个测试版本的发布周期。
n 所有测试发现的Bug都由配置工具软件(例如ClearCase)来管理，以达到及时的控制、追踪其状态。
n 在项目经理的周报中，明确每个Bug的责任人及解决期限（一般Bug是24小时内解决）
n XX人员需遵守的相关工作规范和开发规范，如果有违反则按照的规定进行处罚，情节严重的招标人有权要求换人。
6.6 知识培训方案
6.6.1 知识转移及培训方案
咨询成果和系统的成功推广和顺利应用关键在于用户，对各类用户的培训工作是咨询成果宣导和系统实施与推广工作的重要环节之一，也是整个推广活动中的重要组成部分。通过专门设计可实际操作和有效运行的培训方案，促进推广、应用与知识转移。
本培训方案从培训原则、培训对象、培训方式、培训大纲等方面进行了全面设计。
针对的领导、业务人员、技术人员，根据不同层级用户，选派有经验的教员、编制相应的培训教材、培训方案，安排适当的课时，对系统操作使用、系统管理、项目管理、规范术语和标准等内容进行培训。
本项目将建立专门的培训团队，并保障培训团队成员具有相应培训经验和相应资质水平，并接受本项目的项目经理管理。项目经理组织培训团队进行培训方案的实施。培训团队从培训原则、培训对象、培训方式、培训大纲以及培训达到的效果等方面进行培训方案的落实。在培训课程的设计上，培训团队从应用系统管理运维培训、应用系统相关标准规范培训、应用系统功能培训等方面进行培训大纲、培训内容、培训材料的准备，并安排相应的培训时间、培训场地，培训场次、培训教员提供优质的培训服务。在培训的实施过程中，公司承诺承担相应的培训费用，并对实际的培训效果进行跟踪和反馈，以便及时调整相应的培训策略，提供人性化的培训服务。
6.6.2 培训总体承诺
公司承诺，在项目培训阶段，保证提供最有经验的教员，为不同层级用户提供相应的培训和交流；同时提供培训教材、教师授课等配套培训服务，并确保培训质量。
公司与双方在项目实施过程中共同负责培训计划的制订。培训分为前期培训和后期培训。
培训内容保证包括所提供系统的结构、性能、维护、定制和升级等各个方面，并提供培训教材和培训课程计划表。
公司应对解决方案所需的所有产品提供管理、操作及维护方面的培训。保证培训课程设计全面，满足所有用户类型的培训要求。
使用中文在中国进行培训。所有培训教员均具备熟练的中文会话和书写能力，可以和培训对象进行有效的技术交流。
针对各项具体的培训内容，公司至少为50人次人员提供培训机会。
培训开始三周前，公司应提供培训时间表、课程、课时、课程方式、课程目标、前提要求及面向听众等。培训应有针对性、标准化且结构清晰。
保证提供具有资质水平且经验丰富的教员，使参加培训的相关人员在培训后能够独立地对系统进行操作、管理、维护。
针对不同的培训对象制定不同的培训方案，确保使每个参加培训的人员能掌握系统的使用方法。保证提供以下培训资料：
n 培训大纲：说明每次课程的内容和目标；
n 培训计划：说明每次培训课程的时间、地点及课时；
n 培训内容设计：包括系统的性能、相关技术原理和操作使用方法，维护管理的技术，实际的操作练习；
n 课程的文件和资料。
我公司承诺提供科学合理的培训计划，并辅以强有力的培训保障措施，以保障培训效果及培训工作的顺利开展。
我公司承诺根据项目情况，可按照行方的要求对培训内容、时间、批次进行调整；对于由于我公司原因未达到预期效果的，提供二次培训服务。
6.6.3 培训原则、对象及方式
6.6.3.1 培训原则
1) 统一规范的原则
统一规划培训教材和培训方案，按照培训方案要求开展培训。
2) 理论联系实际的原则
培训过程中注重理论联系实际，除了对应用系统的功能及操作进行培训，使参加培训的人员在掌握纯技术课程的基础上，能够更好的理解应用系统的建设意义，有利于在应用系统的推广和应用。
3) 耐心、细心讲解的原则
在培训中，公司培训人员会对技术人员提出的每一个问题进行耐心、细心的讲解，并记录每个技术人员的掌握情况。
6.6.3.2 培训对象
培训对象为相关业务人员和技术人员及领导。各培训对象的培训内容分别描述如下：
1) 数据管控体系咨询与建设项目的相关领导：
数据管控体系咨询与建设项目的相关领导，针对此类培训对象进行数据管控体系的总体培训，数据管控平台总体功能与技术概要培训，使领导了解当前数据管控体系建设的现状，了解体系的总体设计；明确信息化建设的基本发展方向，对数据管控体系实施与推广应用起领导和促进作用。
2) 数据管控体系执行人员：
数据管控体系咨询与建设项目的执行与使用人员包括的业务部门人员，针对此类培训对象进行数据管控体系规划宣导、数据标准咨询成果、数据质量咨询成果、术语和标准规范、信息资源、系统软件、应用软件等培训。使其了解数据管控体系的业务流程、原理和技术路线。
培训目的是使数据管控体系咨询与建设项目的各级各类用户能理解数据管控体系咨询与建设的建设意义，为数据管控体系推广和系统实施后的运维及顺利应用奠定坚实的基础。
6.6.3.3 培训方式
培训服务可以采用本地、远程相结合，集中、临时相结合的方式。
1) 集中培训：
对相关领导、相关业务和维护人员进行应用系统使用及管理培训。
培训师资由公司培训中心提供。
2) 二次培训：
作为集中培训的辅助方式，临时培训根据提出的培训要求，在系统运行阶段，根据实际情况协助完成相关培训。对认为集中培训课程没有达到培训效果的课程，提供二次培训。对系统运行中由于系统业务变化、业务人员变化等原因导致需要进行培训时，根据实际情况配合组织培训。
3) 远程培训：
作为本地培训的辅助方式，远程培训将网站和公司相关的服务网站进行远程网上培训，通过定期发布培训课件、教材和学习资料，用户可以进行网上自学或远程教学。
培训课件的制作与培训资料的整理由项目培训服务组承担。
6.6.3.4 培训内容大纲
培训内容大纲分别针对数据管控高级管理人员、执行人员进行设计。课程内容包括所提供数据管控体系宣导、数据架构咨询成果介绍、数据标准咨询成果介绍、数据质量咨询成果介绍，并提供全套培训教材。
本项目培训主要包括以下课程：
n 实施方法论培训
n 数据管控体系规划培训
n 数据标准咨询成果培训
n 数据质量咨询成果培训
6.6.4 培训内容计划
实施厂商主要提供的培训内容计划如下：
|
培训主题 |
培训内容 |
培训时间 |
培训方式 |
培训对象 |
|
实施方法论培训 |
本项目实施方法论的相关内容培训 |
0.5天 |
集中授课培训 |
项目管理人员 相关人员 |
|
数据管控体系规划培训 |
数据管控体系规划的培训 |
1天 |
集中授课培训 |
项目管理人员 相关人员 |
|
数据标准咨询成果培训 |
数据标准咨询成果的介绍 |
1-2天 |
集中授课培训 |
项目管理人员 相关人员 |
|
数据质量咨询成果培训 |
数据质量咨询成果介绍 |
1-2天 |
集中授课培训 |
项目管理人员 相关人员 |
6.7 项目实施的主要风险点及规避措施
1) 数据标准化
在项目实施中，会借助数据标准咨询的成果，指导各业务系统和数据平台的数据模型设计及数据质量检核规则的生成，但数据标准在业务系统的落地程度将影响数据标准在数据平台落地的程度。指导数据标准在各源业务系统和数据平台中落地时，应本着最小化投入成本的原则，若源业务系统数据粒度达到数据标准要求，应建议由数据平台完成数据标准落地的转换工作。
2) 数据质量提升
数据质量提升是一个长期的过程，质量提升目标不是为了消除所有质量问题，而是为了控制数据质量能基本满足数据使用需求。数据质量问题的产生原因也是多种多样，有些质量问题需要进行数据补录，系统功能改造等工作才能解决。故数据质量提升的过程中常常会遇到很多阻力，建立一个行之有效的数据质量管理流程和专人小组，并长期跟进全行数据质量情况，定期发布数据质量报告。
3) 业务人员参与程度
如何才能高质量的完成数据管控体系的搭建？较大程度上取决于业务人员的参与。通过业务人员在定义业务需求，数据标准制定与维护，数据管控等方面承担重要角色，将业务人员的潜在需求通过数据标准转化为可便捷获取的生产力。同时，数据管控体系建设完成后，需要业务部门配合积极推动数据管控体系推广，切实的提高了全行的数据质量，从而进一步支持业务分析的需求。所以在项目建设的过程中，充分调动业务人员的积极性，是数据管控体系建设成功的重要保障。
7 知识产权说明
本项目服务过程中所产生的所有工作成果（包括但不限于发明、相关技术资料、文档、等）的知识产权归所有。XX承诺，未经书面许可，不得在其他项目中使用。而且无论任何情况，XX承诺，不将项目中属于特有的业务和技术情况对外透露或应用于其他项目。
在本合同有效期内，和授权的第三方在遵守本合同规定的保密条款的基础上拥有本系统及所有使用的软件产品在使用范围内的使用权、修改权和复制权。
XX对提供的所有业务技术资料、文档，对第三方保密。
8 现场XX实施优势
XX商业智能团队在数据管控体系咨询与建设项目的优势如下：
拥有国内最丰富的数据管控体系咨询与实施经验，拥有最丰富的数据管控体系的实施经验：国家开发银行、国家进出口银行、工商银行、建设银行、农业银行、光大银行、北京银行、南京银行等。
咨询与平台建设相配合，数据管控体系浑然一体，XX数据管控咨询与数据管控平台浑然一体，并得到了多家银行的验证。数据标准管理平台、数据质量管理平台和元数据管理平台的无缝集成，更好的支持数据管控体系的搭建。
XX商业智能团队也是数据平台系统咨询与建设的服务提供商，对数据平台解决方案的深入理解，有助于和同期开展的数据平台系统咨询与建设项目相配合，更好的提供全行数据管控服务。
XX商业智能团队分为专业咨询和专业服务两个大的团队，长期从事数据管控相关的咨询规划和实施工作，以高端咨询带动低端实施的方式，咨询和实施人员均能满足项目的要求，无需人力外包。
XX商业智能团队拥有自主知识产权且同业广泛实施的元数据管理系统、数据标准管理系统、数据质量管理系统三大产品，可以达到快速部署，快速实施的要求，并提供可定制的客户化开发服务。
标签：项目,管理,标准,数据管理,治理,咨询,数据,质量 From： https://www.cnblogs.com/HondaHsu/p/17069125.html