文章
【数据治理实践】
第七期:多层次多途径的数据标准落地方式
前言
在前两期中,我们分别介绍了基础类数据标准和指标类标准的编制难点与应对方案,对于已经完成或即将完成数据标准编制工作的银行,继而面临着另一个巨大的挑战——如何才能有效地落地应用数据标准?本期,我们一起来探讨如何把握落标(编者按,数据标准落地应用简称落标)的契机、如何日常化地开展落标工作,各位读者也可以借此找到适合自身的落标推进方法。
监管要求
在《银行业金融机构数据治理指引》(下称“指引”)第三章的数据管理部分对数据标准的执行提出明确要求。
第二十条 银行业金融机构应当建立覆盖全部数据的标准化规划,遵循统一的业务规范和技术标准。数据标准应当符合国家标准化政策及监管规定,并确保被有效执行。 ——《银行业金融机构数据治理指引》 |
数据标准只是一份规范文档,它的有效落地执行才是全行数据能否标准化的必经之路。
落标的难点
自2004年中国建设银行首次提出银行业“数据标准化”概念,各大国有银行、全国股份制商业银行、城商行、农商行等陆续开展数据标准化工作,并持续推进数据标准的落地应用,银行业数据标准化历程已经走过15年。但在数标落地推进过程中,不同体量不同类型的银行遇到了类似的难点:
- 标准本身:数据标准的定义不契合业务实际,或后续缺乏有效维护更新。
- 系统方面:外购系统难以按照行内数据标准改造;为了落标而改造系统的影响范围过大。
- 流程方面:数据标准落标管控不严格、不重视,业务部门在业务需求中鲜有提及数据标准落标要求,技术部门在开发流程中往往将业务功能开发的重要程度排在落标前。
- 人员意识:缺乏对业务人员和技术人员的培训,业务人员不知如何提出数据标准落标要求,技术人员无落标意识。
那么,如何才能解决这些难点呢?我们注意到在优秀的银行业落标实践中,数据标准落地需要把握关键落标契机,也需要将落标这件事融入日常流程。下面,我们来简单分享一下。
把握落标的契机
较为常见的数据标准落地的契机包括4个时间点:系统新建/改造、主数据建设、指标库建设和数据质量提升驱动。那么,如何利用这些契机开展有效落标呢?
图:数据标准落地契机
1. 优化系统需求、开发、测试、上线流程
数据标准落地推进的关键在于借助和融入信息系统的需求、设计与开发等各个阶段,为此落标流程优化均是基于常见的银行系统开发管理的流程进行优化建议。
- 立项阶段优化
调整优化数据标准落地项目的成员角色。项目组成立阶段,在项目实施小组中增加数据标准管理角色。数据标准落地方案实施初期阶段,由数据治理归口管理部门对项目实施小组进行数据标准落地培训。数据标准管理角色作为项目实施小组成员之一,可以加入项目评审组、讨论群,参与到项目开发的各个阶段中。 - 设计开发阶段优化
调整优化需求规格说明书,增加数据需求章节。需求提出部门在业务需求说明书中明确数据标准执行要求,引用行内已有的数据标准,指导后续的设计、开发与验收。数据治理归口管理部门牵头组织数据标准信息项归口管理部门审核《业务需求说明书》中的数据标准执行要求,确保该要求符合行内的已有数据标准规范。
另一方面,对数据字典的逻辑模型与物理模型做标准化要求。项目实施小组相关成员在概要设计阶段提交数据字典,相关成员根据数据标准对数据字典中用到的表名、字段名等做设计。 - 上线阶段优化
系统在验收测试及交付阶段,增加数据模型、数据标准、数据字典核对验收的环节,并由数据治理归口管理部门参与审核。
在信息系统新建/改造流程中嵌入数据标准落地要求,可以 “试点先行、逐步推进”,选定重点系统试点推行,再逐步扩大数据标准落地管控的系统范围。
可能遇到的阻力1:试点项目的选择可能会存在业务部门的阻力 可能遇到的阻力2:外购系统改造难 可能遇到的阻力3:数据标准与业务实际脱节,系统建设中无法应用 |
2. 建设可扩展的指标库
通过建设指标库,搭建指标管理统一视图,银行可全方位了解指标全貌,更方便的了解和检索各类指标的口径、加工地点、存储地点和具体数值。指标体系梳理是指标库建设的关键环节,也是指标类数据标准落地的重要环节。指标体系梳理环节中,引用已经建设完成的指标数据标准,保障指标数据源头的权威性和唯一性,有效推进指标数据标准的落地。
在指标库建设过程中,完善指标模型设计,增加包括源系统、源数据表、源字段、更新频次等技术方面设计,并由指标数据标准归口管理部门标记其可行性,形成能够指导系统开发的指标模型。指标数据模型是指标数据技术的数据框架,屏蔽源系统变化对数据的影响,有效保留历史数据,支撑数据分析与应用。
基于指标库的建设,可以搭建高管驾驶舱、优化报表建设与协助自主分析:
- 高管驾驶舱建设
高管驾驶舱是行内领导开展经营管理和决策的重要工具,通过高管驾驶舱,不仅可以统一行内的管理,包括指标、数据、权限等,还可以对全行的风险进行监控,对行内关键的指标与同业进行对标,为管理者的决策提供支持。 - 优化报表建设与自主分析
业务人员根据指标库建设成果,快速设计报表。设计报表要用到的数据:参数、指标、信息项、公共统计规则、函数,指标库可以为业务人员提供所需信息。引入直接把标准数据引入到数据准备区,供设计报表时候直接拖拽使用,而无需用户手工填写数据标准项。
设计的报表对指标数据标准进行规范化的引用,保障数据标准的落地。对于新增的额外的指标项可以作为未来指标标准建设与定义的输入,加强指标数据标准的生命力。
3. 梳理主数据模型与标准
主数据的建设过程也是数据标准落地的关键契机。如,在建设企业客户信息工厂(ECIF)时,落地客户主题数据标准;在建设HR系统时,落地员工主题数据标准;在建设OA或统一认证平台等系统时,落标内部机构主题数据标准。
以ECIF建设为例,ECIF的建设以实现全行客户信息统一管理,确立客户信息的权威数据源,以供全行各业务领域共享使用,这是典型的主数据建设。在ECIF建设过程中,同步梳理行内现有系统中客户数据分布情况,建立客户主数据模型,完善客户主题数据标准。ECIF作为最权威的全行客户数据来源(作为全行的客户主题的黄金数据源),落地客户数据标准后,则能保障未来全行使用的来自ECIF的客户数据都是符合数据标准的。
对于主数据中定义的所有主数据字段,各主系统的开发都需参考相应数据标准的描述,属性字段方面原则上应保持一致与完整,以方便今后提供相应主数据信息。
初始阶段,没有主数据管理平台和应用集成接口时,分散建设的系统中数据查重不能跨系统进行,建议各系统可按照主数据编码规则生成数据,先各自管理,平台实施时,可以一次性进行数据清理合并,再导入主数据管理平台。
4. 利用数据质量提升驱动数据标准化
将数据质量检核作为数据标准落地效果的检核手段,评估数据标准的落地情况。通过数据质量问题的整改,在数据质量提升过程中推进旧有系统的升级与改造,以遵循全行数据标准。
数据质量问题的产生源于多个方面与环节,包括数据质量管理层面、数据录入环节、数据处理环节、系统设计环节、甚至在数据质量问题整改环节等。
如数据质量问题产生源于系统设计缺陷,数据质量问题整改则涉及信息系统的改造,在系统改造流程中严格按照信息系统开发与变更流程执行数据标准的对标,落地数据标准,提高数据质量。
日常化地开展落标
我们可以从以下四个方面日常化的开展数据标准落标工作:厘清相关方职责、建立数据标准管理工具、数据标准闭环管理机制、培养人员落标意识。
1. 各司其职
厘清数据标准编制、维护、落地过程中的相关方职责,充分利用考核手段、数据治理问责与激励机制,推动数据标准管理和执行落地。
数据治理归口管理部门:负责建立企业级数据标准化规划、统筹数据标准新增、维护、停用需求、牵头建立数据标准管理工具(如数据管控系统)、组织开展数据标准相关培训。
数据标准业务责任部门:负责编制、维护与解释归属于本部门的数据标准。
系统建设/报表开发需求部门:负责在系统建设或报表开发的业务需求提出过程中,明确数据标准执行要求。
科技部门:负责应用数据标准规范系统建设与改造流程、确保数据标准被有效执行。
所有部门:在业务制度规范、业务或管理数据手工台账等中执行数据标准要求。
2. 工欲善其事必先利其器
数据标准管理工作繁杂,需要借助有力的工具支撑,——数据管控系统:首先,数据管控系统能支持数据标准的维护工作。其次,将数据管控系统对接银行OA、科管平台,把数据标准管理流程嵌入日常工作流中,加强数据标准落地流程管控。同时,利用数据管控系统的元数据管理功能,自动化进行系统落标分析,针对变更与停用数据标准,能有效分析哪些系统表字段将受到影响,通知相关人员。
3. 有“生命力”的数据标准
定期评估适用性:定期评估数据标准的适用性, 包括数据标准是否可以覆盖外部监管要求;数据标准是否可以有效满足国际、国家、行业标准及业务需求;数据标准的系统应用情况;数据标准是否有对应的业务责任部门。
科技部门参与制定:数据标准责任部门在制定数据标准时,需要科技部门辅助提供数据字典、模型、测试数据等文档,同时,也需要与科技部门沟通了解数据现状。
落地效果评价:持续收集数据标准实施落地后产生的问题并进行应对,以元数据管理为基础,核对元数据的落标映射情况,定期评估数据标准的落地效果。
4. 落标意识培养
通过多种方式加强数据标准落标各个环节中的人员培训工作,提高系统开发测试人员的数据标准落地意识,保障在信息系统建设或改造过程中数据标准有效落地。
结语
数据标准的切实落地,既满足各监管机构海量数据、高频次和更新频繁的报送要求,减轻报送工作量,达到数据统计完整性和准确性要求,提升数据质量,同时也会促进银行跨业务部门的数据共享,夯实数据价值实现基础。虽然数据标准的三篇文章暂告一段落,但数据标准的编制、维护、落地都是“细水长流”的工作,并非一蹴而就,还需各位同仁继续努力,在日常工作中为实现数据标准化的目标而持续推进。