168大数据

标题: 【数据治理实践】第七期：多层次多途径的数据标准落地方式 [打印本页]
作者: 168主编    时间: 2019-9-30 10:36
标题: 【数据治理实践】第七期：多层次多途径的数据标准落地方式
本帖最后由 168主编 于 2019-10-28 10:39 编辑

前言
在前两期中，我们分别介绍了基础类数据标准和指标类标准的编制难点与应对方案，对于已经完成或即将完成数据标准编制工作的银行，继而面临着另一个巨大的挑战——如何才能有效地落地应用数据标准？本期，我们一起来探讨如何把握落标（编者按，数据标准落地应用简称落标）的契机、如何日常化地开展落标工作，各位读者也可以借此找到适合自身的落标推进方法。



监管要求
在《银行业金融机构数据治理指引》（下称“指引”）第三章的数据管理部分对数据标准的执行提出明确要求。
第二十条 银行业金融机构应当建立覆盖全部数据的标准化规划，遵循统一的业务规范和技术标准。数据标准应当符合国家标准化政策及监管规定，并确保被有效执行。
——《银行业金融机构数据治理指引》

数据标准只是一份规范文档，它的有效落地执行才是全行数据能否标准化的必经之路。



落标的难点
自2004年中国建设银行首次提出银行业“数据标准化”概念，各大国有银行、全国股份制商业银行、城商行、农商行等陆续开展数据标准化工作，并持续推进数据标准的落地应用，银行业数据标准化历程已经走过15年。但在数标落地推进过程中，不同体量不同类型的银行遇到了类似的难点：
那么，如何才能解决这些难点呢？我们注意到在优秀的银行业落标实践中，数据标准落地需要把握关键落标契机，也需要将落标这件事融入日常流程。下面，我们来简单分享一下。



把握落标的契机
较为常见的数据标准落地的契机包括4个时间点：系统新建/改造、主数据建设、指标库建设和数据质量提升驱动。那么，如何利用这些契机开展有效落标呢？
图：数据标准落地契机




1. 优化系统需求、开发、测试、上线流程
数据标准落地推进的关键在于借助和融入信息系统的需求、设计与开发等各个阶段，为此落标流程优化均是基于常见的银行系统开发管理的流程进行优化建议。
在信息系统新建/改造流程中嵌入数据标准落地要求，可以 “试点先行、逐步推进”，选定重点系统试点推行，再逐步扩大数据标准落地管控的系统范围。
可能遇到的阻力1：试点项目的选择可能会存在业务部门的阻力
化解之道：建议银行数据治理归口管理部门与科技部门共同讨论确定范围，再在行内高层会议上作为本行推进数据治理试点的举措之一进行开展。行内高层推动试点开展的项目将为后续跨部门协作，资源调配，信息共享等方面提供积极的帮助。
可能遇到的阻力2：外购系统改造难
化解之道：在系统选型和设计过程中尽量考虑行内数据标准的管理要求，对于因成熟产品而需要做基础数据标准变更的应充分评估数据标准的影响范围，避免随意修改数据标准，保障数据标准在全行范围内的权威和统一。
可能遇到的阻力3：数据标准与业务实际脱节，系统建设中无法应用
化解之道：数据标准落地时，并不能仅按照“以数据标准为准”的原则，如系统实际数据超出标准范畴，或需要修改标准，根据标准发布流程进行修订， 保障标准与实际业务的一致，指导系统建设。





2. 建设可扩展的指标库
通过建设指标库，搭建指标管理统一视图，银行可全方位了解指标全貌，更方便的了解和检索各类指标的口径、加工地点、存储地点和具体数值。指标体系梳理是指标库建设的关键环节，也是指标类数据标准落地的重要环节。指标体系梳理环节中，引用已经建设完成的指标数据标准，保障指标数据源头的权威性和唯一性，有效推进指标数据标准的落地。
在指标库建设过程中，完善指标模型设计，增加包括源系统、源数据表、源字段、更新频次等技术方面设计，并由指标数据标准归口管理部门标记其可行性，形成能够指导系统开发的指标模型。指标数据模型是指标数据技术的数据框架，屏蔽源系统变化对数据的影响，有效保留历史数据，支撑数据分析与应用。
基于指标库的建设，可以搭建高管驾驶舱、优化报表建设与协助自主分析：



3. 梳理主数据模型与标准
主数据的建设过程也是数据标准落地的关键契机。如，在建设企业客户信息工厂（ECIF）时，落地客户主题数据标准；在建设HR系统时，落地员工主题数据标准；在建设OA或统一认证平台等系统时，落标内部机构主题数据标准。
以ECIF建设为例，ECIF的建设以实现全行客户信息统一管理，确立客户信息的权威数据源，以供全行各业务领域共享使用，这是典型的主数据建设。在ECIF建设过程中，同步梳理行内现有系统中客户数据分布情况，建立客户主数据模型，完善客户主题数据标准。ECIF作为最权威的全行客户数据来源（作为全行的客户主题的黄金数据源），落地客户数据标准后，则能保障未来全行使用的来自ECIF的客户数据都是符合数据标准的。
对于主数据中定义的所有主数据字段，各主系统的开发都需参考相应数据标准的描述，属性字段方面原则上应保持一致与完整，以方便今后提供相应主数据信息。
初始阶段，没有主数据管理平台和应用集成接口时，分散建设的系统中数据查重不能跨系统进行，建议各系统可按照主数据编码规则生成数据，先各自管理，平台实施时，可以一次性进行数据清理合并，再导入主数据管理平台。
4. 利用数据质量提升驱动数据标准化
将数据质量检核作为数据标准落地效果的检核手段，评估数据标准的落地情况。通过数据质量问题的整改，在数据质量提升过程中推进旧有系统的升级与改造，以遵循全行数据标准。
数据质量问题的产生源于多个方面与环节，包括数据质量管理层面、数据录入环节、数据处理环节、系统设计环节、甚至在数据质量问题整改环节等。
如数据质量问题产生源于系统设计缺陷，数据质量问题整改则涉及信息系统的改造，在系统改造流程中严格按照信息系统开发与变更流程执行数据标准的对标，落地数据标准，提高数据质量。



日常化地开展落标
我们可以从以下四个方面日常化的开展数据标准落标工作：厘清相关方职责、建立数据标准管理工具、数据标准闭环管理机制、培养人员落标意识。
1. 各司其职
厘清数据标准编制、维护、落地过程中的相关方职责，充分利用考核手段、数据治理问责与激励机制，推动数据标准管理和执行落地。
数据治理归口管理部门：负责建立企业级数据标准化规划、统筹数据标准新增、维护、停用需求、牵头建立数据标准管理工具（如数据管控系统）、组织开展数据标准相关培训。
数据标准业务责任部门：负责编制、维护与解释归属于本部门的数据标准。
系统建设/报表开发需求部门：负责在系统建设或报表开发的业务需求提出过程中，明确数据标准执行要求。
科技部门：负责应用数据标准规范系统建设与改造流程、确保数据标准被有效执行。
所有部门：在业务制度规范、业务或管理数据手工台账等中执行数据标准要求。
2. 工欲善其事必先利其器
数据标准管理工作繁杂，需要借助有力的工具支撑，——数据管控系统：首先，数据管控系统能支持数据标准的维护工作。其次，将数据管控系统对接银行OA、科管平台，把数据标准管理流程嵌入日常工作流中，加强数据标准落地流程管控。同时，利用数据管控系统的元数据管理功能，自动化进行系统落标分析，针对变更与停用数据标准，能有效分析哪些系统表字段将受到影响，通知相关人员。
3. 有“生命力”的数据标准
定期评估适用性：定期评估数据标准的适用性， 包括数据标准是否可以覆盖外部监管要求；数据标准是否可以有效满足国际、国家、行业标准及业务需求；数据标准的系统应用情况；数据标准是否有对应的业务责任部门。
科技部门参与制定：数据标准责任部门在制定数据标准时，需要科技部门辅助提供数据字典、模型、测试数据等文档，同时，也需要与科技部门沟通了解数据现状。
落地效果评价：持续收集数据标准实施落地后产生的问题并进行应对，以元数据管理为基础，核对元数据的落标映射情况，定期评估数据标准的落地效果。
4. 落标意识培养
通过多种方式加强数据标准落标各个环节中的人员培训工作，提高系统开发测试人员的数据标准落地意识，保障在信息系统建设或改造过程中数据标准有效落地。



结语
数据标准的切实落地，既满足各监管机构海量数据、高频次和更新频繁的报送要求，减轻报送工作量，达到数据统计完整性和准确性要求，提升数据质量，同时也会促进银行跨业务部门的数据共享，夯实数据价值实现基础。虽然数据标准的三篇文章暂告一段落，但数据标准的编制、维护、落地都是“细水长流”的工作，并非一蹴而就，还需各位同仁继续努力，在日常工作中为实现数据标准化的目标而持续推进。







欢迎光临 168大数据 (http://www.bi168.cn/) Powered by Discuz! X3.2