智库文档所有分类

（97页PPT）大数据数据质量提升与企业级数据模型构建策略.ppt

下载

用户#5378980

95页 | 3.88MB | 0次下载 |

0.0

(0人评价)

我要评价：

投诉举报

用手机看文档

扫一扫,手机看文档

下载

开通VIP

《大数据数据质量提升规划方案》 22| 本交付物为B-6银行大数据数据质量提升规划方案 x 本文件资料来源：麦肯锡分析高阶整体报告（行领导）交付物类别数据整合与应用数据人才与组织数据治理数据系统与工具总体数据战略分项报告（部门）具体交付物大数据愿景及战略规划 A1 大数据的整体实施路线图 A4大数据关键能力提升整体方案 A2 大数据治理机制及运营模式方案 A3 大数据业务用例需求分析框架 B4 大数据业务用例整体管理方案 B5 大数据战略相关业务用例实施路线图 B10 大数据数据质量提升规划方案 B6 大数据相关数据治理体系设计方案 B8 大数据战略相关数据治理规划实施路线图 B12 大数据数据平台规划设计方案 B7 大数据战略相关数据平台建设实施路线图 B11 大数据能力现状诊断报告 B1 大数据体系整体设计原则国内外同业大数据应用案例集 B3B2 大数据业务场景需求清单（完整版/优先排序前）大数据业务场景优先排序模型大数据规划-业务用例清单 C11 C13C12 数据分析相关系统的使用情况现状分析 C5 数据模型架构现状分析 C7 大数据相关组织架构设计方案 B9 大数据战略相关数据组织规划实施路线图 B13 数据相关关键岗位的职责、角色、核心能力要求和考核规划 C14 数据相关关键岗位的岗位需求规划分析 C15 数据系统架构现状分析 C8 数据质量现状分析C6 大数据关键能力缺口和提升方向初判 C10 数据分析业务运作机制现状分析 C9 33| 领先方法参考国际领先做法先进实践结合实际案例对标提升方案设计符合现状的未来发展规划和具体提升方案设计方法：基于领先的设计方法，参照先进实践，设计贴合现状和未来发展方向的定制化提升方案 44| 数据质量与治理是实现大数据战略的3大重要支撑之一数据战略用于指导在组织内的数据使用和分析及其如何与商业价值挂钩的总体目标和态度数据人才在组织内个人进行分析活动的能力及如何将其安排在组织结构中数据质量与治理对数据进行采集、清理、存储、管理和维护的各项流程数据系统与工具大数据分析所使用的内外部的系统架构、平台、工具等数据整合与应用业务和技术的接口和界面，将数据洞见转化为业务价值的过程资料来源：小组分析；麦肯锡相关研究大数据能力分析的整体框架 – Data Analytics Maturity Assessment (DAMA) 数据人才与组织数据系统与工具业绩提升风险管控运营优化决策支持大数据高级分析对银行的潜在价值 3 5 数据整合与应用数据治理数据战略 2 4 1 本次分析重点方向 55| 目录 ▪ 数据质量现状回顾 ▪ 数据质量提升方案 ▪ 数据模型架构 66| 缺乏统筹和自上而下的推动则是阻碍当前的大数据应用规模化的主要原因现状诊断导致的结果 ▪ 整体处于数据应用的初级阶段：虽然目前已有~300个模型，但大部分与风险管理相关，难以有效支持前线营销及高管决策 ▪ 全行缺乏大数据整体战略：对于大数据的定位和发展目标缺乏共识，没有未来发展优先排序，以部门自发探索模式主导 ▪ “开发难以规模化”：数据用例开发速度慢、数量少、结构不尽然合理大数据战略 ▪ 数据团队人力不足，且各部门自行搭建，未形成合力：数据团队现有~170名人员，主体是报表统计或系统开发岗位，真正从事高级分析的数据人才仅有~25人 ▪ “专业人才难以规模化”：高级分析的关键环节（如模型开发）高度依赖外包，核心能力不能沉淀在体内数据人才与组织 ▪ 基础数据质量不佳：基础数据在一致性、真实性、完整性及规范性上都存在明显的问题，已成为转型关键项目实施的“瓶颈” ▪ 责任部门不明，政出多门：缺乏全行级的数据模型架构和数据治理规范，包含明确的责任人、管控指标、政策及流程等 ▪ “满足分析要求的数据难以规模化”：数据质量饱受诟病，乃至成为推广数据应用的障碍数据质量与治理 ▪ 全行平台未整合，标准不一，功能定位不清：各部门从各自需求出发，跨层情况十分普遍，导致数据链路混乱，数据血液失控 ▪ 处理速度慢，扩容成本高：局部已经启动优化和技术升级，但未在全行形成统一原则 ▪ “系统处理能力难以规模化” 系统运算能力不足，未分流导致处理速度慢，不能满足大量高级分析需要数据系统与工具 ▪ 各部门单打独斗，横向缺乏协同，纵向不能实现闭环：以零售事业部数据化营销死循环为例，在最能体现大数据应用价值的零售客户中，近90%的非零非有效客户，未能有效提升价值；高价值 (私银/卓然/悠然)老客户维护不力，净流出明显 ▪ “实施难以规模化”：数据线索执行率低，如已有渠道的执行容量不足，即使投放到一线的数据线索耗损高，总行下发的线索执行率不足50% 数据整合与应用资料来源：小组分析 77| 通常通过一致性、完整性、规范性和准确性这四个指标来衡量数据质量，数据质量的好坏对于风险、合规、业务经营都至关重要资料来源：小组讨论; 2013 FIMA（Financial Information Management）衡量数据质量的四大指标一致性：数据口径和定义是否清晰一致规范性：数据是否具有标准的格式准确性：数据是否与事实相符完整性：数据是否有缺失数据质量对于金融机构的业务经营至关重要超过82%的金融机构将数据治理和质量提升作为未来12个月的工作重点 70%左右的金融机构普遍认为合规管理和风险管理是受数据质量影响最大的业务应用通过数据质量提升驱动的数据转型，通常可以给金融机构带来相当于年利润净增1%~7%不等的价值提升 60%的金融机构已经有试运行或完整的数据治理机制，其余35%也在治理机制的设计阶段超过80%的金融机构，采取业务和IT共同对数据治理负责的治理模式数据质量对风险、合规和业务经营的影响重大…… 因此，都将数据治理放在至关重要的位置…… ✔ ✔ ✔ ✔ ✔ 88| 现状影响一致性 ▪ 多个数据来源：不同系统统计的社区银行网点数不同，从渠道部的3503家到安保系统的5879家，最多相差70% ▪ 不同部门/机构对于社区网点定义不同，无统一标准，无法对社区网点形成准确估算，阻碍全成本口径统计完整性 ▪ 源数据缺失：员工、渠道维度目前仅有部分数据，如员工目前仅有客户经理和交据，需要扩充数据 ▪ 信息颗粒度不足：客户、产品维度数据颗粒度需要进一步提升，如提升客户费用精细度 ▪ 缺失全景分析，导致无法进行精准的成本核算及决策分析 ▪ 缺乏精确的数据支持，决策需要多轮沟通，效率低规范性 ▪ 缺乏统一管理机制：信息零散，缺乏清晰的管理流程与逻辑关系 ▪ 缺少定期管理报表，可视性与透明度底 ▪ 没有全行统一标准，部门各自发挥，导致重复工作 ▪ 透明度底，决策需要多轮沟通，效率低 G1成本项目目标：通过成本透明化，促进成本管理精细化，更科学、有效地投入资源；同时制定了涵盖7大领域的降本举措，如全部落地预计节约50亿元资料来源：优化成本管理体系，全面提升成本效率项目组分析数据已经成为转型项目实施的瓶颈————成本项目（G1）成本数据颗粒度不足，影响成本项细分的精准度现状诊断及差距分析 99| 数据已经成为转型项目实施的瓶颈————科学定价项目（ F2 ）需要对客户信息有更真实和完整的把握真实性完整性规范性一致性现状影响 ▪ 多个数据来源：新管会系统与新CRM系统对客户EVA的计算结果不同 ▪ 同一数据取值不统一：信息中心、资负部、经营机构等对资本成本率取值差异大，从 6%-16% ▪ 不同部门/机构对于同一指标的计算逻辑与基础取值不同，定价取数需要甄别，工作量大 ▪ 对公客户行业信息真实性差：其他行业占比高达30%，即使有明确行业分类准确率较低 ▪ 无法进行有效的客户分群 ▪ 定价需要参考所在分群的前 20%-30%的均值，行业数据不准确导致无法精准对标 ▪ 客户/产品维度信息缺失：发债、资管计划、结构性贸等产品/客户维度信息缺失 ▪ 信息未集成：单笔交PD/LGD未进行客户/ 产品维度集成；管会约21%收入无法归集到客户；约5%收入无法归集到产品 ▪ 缺失客户全景分析，无法有效的开展账户规划 ▪ 无法直接使用计算风险成本，工作量大 ▪ 无法精准定价 ▪ 手工台帐规范性差：资金池业务台账信息记录完整，但未进入客户综合贡献计算 ▪ 缺乏统一管理机制：信息零散，缺乏清晰的管理流程与逻辑关系 ▪ 没有全行统一标准，部门各自发挥，导致重复工作 F2科学定价项目目标：建立以客户为某省市场为导向的科学定价技术方法；同时制定了反漏损速赢计划，预计全面铺开后，预计全行对公收入可提升6-8%，即实现40-50亿的利润增长资料来源：基于科学定价项目组分析现状诊断及差距分析 1010| 现状影响 1 新管会系统记录了2015年之后的客户级收入，且较为准确，但无法回溯资料来源：基于数据的营销体系设计和速赢项目组分析 C7零售大数据项目目标：将通过大数据分析，搭建零售数据化营销蓝图、客户全景试图、建立可视化管理看板体系，设计并落地零售数据营销速赢计划及全面推广方案 ▪ 数据分散存储，口径不一，且未打通，例如：不同产品交存储且未整合 ▪ 有两套计算口径1，但都不够精确： – 基于金融资产规模进行客户价值分层 – 整合信用卡和个金积分的客户贡献度积分 ▪ 后台：数据整合难度大，模型效果打折扣 ▪ 前台：用户界面散乱，体验不佳，打击了一线使用积极性一致性完整性数据已经成为转型项目实施的瓶颈————零售大数据项目（ C7 ）业务口径不一致、大量客户关键信息记录不完整现状诊断及差距分析社交信息 ▪ 互相转账较多的同行异名账户 ▪ 夫妻标识、小孩标识网点拜访 ▪ 访问客群信息 (时间、地点) ▪ 最近一次访问距今时间网银/手机浏览 ▪ 1/3/7/30天内登陆次数 ▪ 点击商品与服务纪录 ▪ 浏览路线图理财产品交易 ▪ 3/7/30天内累计购买金额 ▪ 未到期产品中最近与最远一个到期时间距今天数/产品金额 ▪ 部分关键客户信息未被留存和加工 ▪ 精准营销机会：家庭账户、亲子账户、学生贷款、车贷等 ▪ 更好了解客户渠道使用偏好，规划网点布局和业态定位 ▪ 能更有的放矢地向客户推荐产品，提高销售成功率 ▪ 客户价值维持和提升关键营销时间点，靠人工记录容 ▪ 可能错失大量客户价值提升的良机 1111|SOURCE: Source 数据已经成为转型项目实施的瓶颈————关键岗位（H1）、网点布局（C5）、资产负债管理（F1）项目大量数据不具备现状诊断及差距分析现状影响 ▪ 人力资源分析所需数据当前都只存在于线下，大量手工的统计，如：绩效统计 ▪ 未进行以员工为维度的全方位信息收集 ▪ 也不具备人力资源主数据的管理，存在人员信息在多处的不一致，如：分散在各部门 ▪ 难以对全行关键岗位核心人才的就绪度监督和改进，基于数字的“接班人板凳计划管理”难以展开 ▪ 无法对关键岗位人才进行全方位管理和精准招募、培训、留存 HR 网点资负 ▪ 网点的分布、数据口径在多个系统的定位不一致，如：网点数量有5个不同版本 ▪ 网点的运营信息配置信息未进入系统采集和管理，如：人员数量、各模块布局、人流和各类交计 ▪ 行外数据收集不足：民收入、商业分布、竞争对手情况等 ▪ 无法统一网点计算口径 ▪ 无法根据户和竞争对手业态环境分布，明确该网点经营定位 ▪ 无法根据现有网点模块的运营情况，针对性调整模块布局 ▪ 表外及表表外的数据多为手工台帐，各分行数据口径不一，且完整性不足 ▪ 大量资产负债管理及决策报表所需数据，需要多方采集、手动加工后才能呈现，不但耗时、缺乏效率且 ▪ 预算及资源分配时，条线/产品业务数据颗粒度不足，难以作为有效的模型输入 ▪ 无法有效掌控表外/表表外的产金池规模及流动性 ▪ 无法提升资产负管理效率，大量时间花在报表准备及数据整理上 ▪ 无法精准配置条线/产品的资源，难以作到有效预算管控 1212|资料来源：小组分析数据战略数据整合与应用数据人才与组织数据治理数据系统与工具 1. “战略聚焦”：的大数据战略应服务于全行整体规划，因而“凤凰计划”应成为未来三年全行级业务用例的主要输入 2. “抓大放小”：考虑到未来三年能力建设与业务用例推进并行，实施难度和资源投入都较大，全行应聚焦于影响力最大的~20个用例，贵精不贵多 3. “长短兼顾”：业务用例应依照同类技术能力和数据域的治理分批次推进 4. 建立变革引擎，全行统筹排序：落实主体及权责，推动跨部门等变革中的问题 5. “向成本要效益、向应用要价值”：业务用例开发应实行成本约束和绩效约束 6. 组织集约化：推动成本效率、确保管理一致性、实现人才运用的规模效应 7. 某省市场化、专业化：壮大数据人才队伍，某省市场化和专业化 8. 数据治理“实用、落地”：建立数据治理架构和数据责任人制度，理顺数据采集、管理与使用中的权责边界，将数据质量KPI纳入各部门数据责任人的考核 9. 系统架构“开放、前瞻、简单、高效”：加强实时营销/经营分析能力，增强非结构化数据的采集与应用能力；明确重点系统分工，减少架构复杂度 10. 系统优化“补缺优先（先做加法，再做减法）”：结合现状利用现在已有基础，重点放在补缺补漏，明确设计规则，为新系统设计打下基础设计原则概览大数据体系整体指导原则：链接现状诊断和未来设计，使数据能力建设有的放矢 1313| 数据质量提升的10大关键举措资料来源：联合小组分析 “做什么” “怎么做” 关键问题质量提升关键举措关键数据项 4大治理方法、 4大治理保障  全行数据分级管理，优先治理关键数据： - 建立数据重要性分级机制，梳理全行数据资产，区分关键和非关键数据 - 首批，可以从用例数据需求出发，优先治理~50个关键数据项  统一全行数据标准，建立元数据管理： - 数据治理中心发布全行数据标准规范和政策， - 数据管家参照标准规范定义关键数据项标准、口径，并完善元数  定义黄金数据源，集中治理管控，简化数据架构  建立数据质量指标体系，健全数据问题治理机制  建立全行主数据的强管理，从客户主数据开始，逐个纳入  能力建设：建立数据治理培训体系，提供数据治理资质认证，  意愿调动：以数据质量和管控的指标体系作为考核依据，采取部门为主体的奖惩激励机制（参考B8考核激励部分设计）  工具部署：部署3大数据管理工具，包括：元数据、数据质量和数据标准管理系统（参考B工具和系统部分设计）  流程标准化：建立数据治理流程体系框架，优先详细界定7大关键流程（参考B8数据治理流程的设计） 2 3 4 5 7 8 9 6 10 “谁来做” 业务IT双轮驱动  建立全行治理体系，业务IT双轮驱动： - 建立由上至下、科技推动、业务负责的全行治理体系，包括：数据管理委员会、数据治理中心、以及业务的数据域/项管家 - 率先任命首批业务用例方的数据责任人和数据管家 1 1515| 目录 ▪ 数据质量现状回顾 ▪ 数据质量提升方案 – 谁来做？——明确数据治理责任人 – 做什么？——定义治理范畴（即关键数据项）和标准 – 怎么做？——工作方法和机制保障（能力、意愿） ▪ 数据模型架构 1616| 数据质量提升的10大关键举措资料来源：联合小组分析 “做什么” “怎么做” 关键问题质量提升关键举措关键数据项 4大治理方法、 4大治理保障  全行数据分级管理，优先治理关键数据： - 建立数据重要性分级机制，梳理全行数据资产，区分关键和非关键数据 - 首批，可以从用例数据需求出发，优先治理~50个关键数据项  统一全行数据标准，建立元数据管理： - 数据治理中心发布全行数据标准规范和政策 - 数据管家参照标准规范定义关键数据项标准、口径，并完善元数据业务定义  定义黄金数据源，集中治理管控，简化数据架构  建立数据质量指标体系，健全数据问题治理机制  建立全行主数据的强管理，从客户主数据开始，逐个纳入  能力建设：建立数据治理培训体系，提供数据治理资质认证，  意愿调动：以数据质量和管控的指标体系作为考核依据，采取部门为主体的奖惩激励机制（参考B8考核激励部分设计）  工具部署：部署3大数据管理工具，包括：元数据、数据质量和数据标准管理系统（参考B工具和系统部分设计）  流程标准化：建立数据治理流程体系框架，优先详细界定7大关键流程（参考B8数据治理流程的设计） 2 3 4 5 7 8 9 6 10 “谁来做” 业务IT双轮驱动  建立全行治理体系，业务IT双轮驱动： - 建立由上至下、科技推动、业务负责的全行治理体系，包括：数据管理委员会、数据治理中心、以及业务的数据域/项管家 - 率先任命首批业务用例方的数据责任人和数据管家 1 1717| 由上至下，建立科技推动、业务负责的全行治理体系资料来源：小组分析 1 银行的数据治理全行体系行长数据域管家事业部数据治理中心业务科技数据域管家数据管家决策治理规划标准科信委 ▪ 数据治理战略和路径的规划审批 ▪ 数据治理资源投入的支持和审批科技业务 ▪ 数据管理政策、标准化流程制定、发布和监督执行质量管理 ▪ 数据域负责人和管家任命，遵照管控要求执行科技和业务的分工与职责信息科技部信息管理部数据协调人业务部门数据责任人数据管家标准和元数据管理岗数据质量管理岗数据治理规划岗数据管家培训和资质认证岗培训 ▪ 第三方数据采购和服务管理 ▪ 外部获取和新建数据需求提出 ▪ 黄金数据源筛选标准制定、选取和建立 ▪ 参与黄金数据源选取的评估和讨论 ▪ 数据质量和管控指标体系建设 ▪ 监督日常数据质量和跟踪治理进展 ▪ 数据项的业务定义制定、统一和维护 ▪ 数据质量追踪、监督和修复执行 ▪ 关键数据项选取标准制定和推进 ▪ 元数据管理规范和要求制定和字典整合 ▪ 关键数据项的评估和筛选 ▪ 所辖元数据信息的补充完善和字典维护 ▪ 开发培训体系、组织培训和发放资质认证 ▪ 参与培训，并获得资质认证 1818| 业务条线有数据协调人、责任人和数据管家3大关键角色银行的数据治理全行体系（业务）行长数据域管家事业部数据管理委员会数据域管家数据管家数据协调人业务部门数据责任人关键数据管家资料来源：小组分析 1 分行数据责任人业务条线数据治理角色的关键职责和人选定位角色职责人选数据协调人 ▪ 指定数据责任人 ▪ 审批和确保数据治理资源 ▪ 促使跨数据域间的统筹协调 ▪ 通常是事业部级别高层领导 ▪ 能够作用多个数据域数据责任人 ▪ 建立数据域治理目标和优先级 ▪ 指定数据管家 ▪ 控制数据治理资源 ▪ 批准重要数据治理决策，如：业务部门关键数据项的选取 ▪ 负责P&L的业务部门主管 ▪ 足够资深可以实施改变和满足数据用户需求 ▪ 对于前线有掌控和影响力数据管家 ▪ 执行数据治理策略 ▪ 管理元数据业务定义 ▪ 管理数据质量（如：追踪数据质量报表、设计数据质量解决方案和落地执行） ▪ 管理和数据关键用户的关系和需求收集 ▪ 数据域数据和用户需求的深刻理解 ▪ 有能力执行日常的执行工作 ▪ 通常直接汇报给数据负责人 ▪ 有能力管理多项数据治理工作兼职/专职兼职兼职兼职为主，关键数据管家可以全职 a bb c a b c 数据治理的关键业务岗位 c 1919| 以数据域为单位，界定数据管家的管辖范围，企业级关键数据项也可以有专职的数据管家资料来源：小组分析 1 专职兼职数据管家的设置 “需要先做好数据域划分和关键数据分类” …… 个人存款个人贷款个人理财个人存款数据管家个人贷款数据管家个人理财数据管家个人客户关键数据管家1 个金总经理私银总经理零售银行事业部零售数据总协调人 …… 个金数据责任人 ▪ 针对关键数据设置专岗数据管家集中治理 ▪ 其他非关键数据以关键使用岗位兼任数据管家数据域的概念和作用什么是数据域？ ▪ 通常银行有4大类数据域，主数据域、交域、衍生数据域和挖掘数据域 ▪ 数据域代表不同的数据类型和特性及差异化的管理方式，不随数据的存储方式和模型而变动主数据域交域衍生数据域挖掘数据域 ▪ 全行层级关键的被多方调用的核心经营主体数据，如：客户、产品、机构等 ▪ 运营端产生的产品类交产品类交互，如：支付交易、客服交互等 ▪ 贴近业务应用端支持某类特定业务目的的数据某省市场风险、反欺诈等 ▪ 通常以经营主体客户为对象的用于数据挖掘的宽表，如：客户360 数据域的作用？ ▪ 梳理归类全行不同类型的数据资产，用于管理目的 ▪ 作为数据治理的基础单位，指定数据管家，明确数据责任的边界和范围 1 对于负责跨多部门的关键数据项的关键数据管家，需要负责关键数据项所在黄金数据源的质量，作为质量问题识别和协调解决的关键发起人与协调人，具体质量问题的执行负责人，可以是对应业务部门的相关来源数据项的数据管家 2020| 数据域的划分以业务管理逻辑为主，便于资料来源：小组分析 1 ▪ 适用于 – 分步骤以域为单位，进行黄金数据源的选定、治理和发布 – 针对不同域的数据，规范黄金数据源的数据架构摆放原则 – 根据数据域分派和指定数据域的业务管家 – 根据数据域指导数据存放和管理逻辑 ▪ 不适用于 – 统一数据的存储模型架构 – 指定数据的物理存放重业务管理的用途，不涉及物理存放的设计数据域的主要用途和特性数据域体系的细分方法主数据域交域衍生数据域挖掘数据域一级子域二级子域三级子域示例客户个人客户基本信息贷款零售贷款个金贷款某省市场风险客户个人客户营销挖掘主题分类（如：客户、机构等）对象分类（如：个人、对公等）内容分类交（如：贷款、存款）条线分类（如：零售、对公）部门分类（如：个金、私银）应用大类（如：风险、财务）应用细类某省市场、操作）其他细类（如有）主题分类（如：客户、机构）对象分类（如：个人、对公）目的分类（如：营销、挽留） 2121| 数据管家的指派，由数据治理中心统筹，根据数据重要性进行选取和任命1 资料来源：小组分析数据域级关键数据项（D-CDE）非关键数据项（L-CDE）企业级关键数据项（E-CDE）数据协调人数据责任人关键数据管家（全职）数据管家数据治理中心根据数据项的重要性分配给相应的数据协调人/责任人数据协调人/责任人报送数据管家人选数据治理中心进行管家资格审核和培训数据管理委员会予以资格认证和正式任命数据管家选取原则选取原则：  需要经过数据管理委员会认证  数据的关键使用者  了解数据的问题和需求  归属于业务部门  具备一定数据分析能力  可以追踪数据质量和诊断数据问题和定出治理方案  能够协调多方资源适合人选：  优先业务部门下属数据分析人员  若无可以考某省市场岗位的业务人员不同重要性的数据项业务责任任命规则 2222| 目录 ▪ 数据质量现状回顾 ▪ 数据质量提升方案 – 谁来做？——明确数据治理责任人 – 做什么？——定义治理范畴（即关键数据项）和标准 – 怎么做？——工作方法和机制保障（能力、意愿） ▪ 数据模型架构 2323| 数据质量提升的10大关键举措资料来源：联合小组分析 “做什么” “怎么做” 关键问题质量提升关键举措关键数据项 4大治理方法、 4大治理保障  全行数据分级管理，优先治理关键数据： - 建立数据重要性分级机制，梳理全行数据资产，形成全行一致的业务数据资产地图，区分关键和非关键数据 - 首批，可以从用例数据需求出发，优先治理~50个关键数据项  统一全行数据标准，建立元数据管理： - 数据治理中心发布全行数据标准规范和政策 - 数据管家参照标准规范定义关键数据项标准、口径，并完善元数据业务定义  定义黄金数据源，集中治理管控，简化数据架构  建立数据质量指标体系，健全数据问题治理机制  建立全行主数据的强管理，从客户主数据开始，逐个纳入  能力建设：建立数据治理培训体系，提供数据治理资质认证，  意愿调动：以数据质量和管控的指标体系作为考核依据，采取部门为主体的奖惩激励机制（参考B8考核激励部分设计）  工具部署：部署3大数据管理工具，包括：元数据、数据质量和数据标准管理系统（参考B工具和系统部分设计）  流程标准化：建立数据治理流程体系框架，优先详细界定7大关键流程（参考B8数据治理流程的设计） 2 3 4 5 7 8 9 6 10 “谁来做” 业务IT双轮驱动  建立全行治理体系，业务IT双轮驱动： - 建立由上至下、科技推动、业务负责的全行治理体系，包括：数据管理委员会、数据治理中心、以及业务的数据域/项管家 - 率先任命首批业务用例方的数据责任人和数据管家 1 2424| 领先银行会对全行数据进行重要性分级，优先治理对经营、风控影响最大的 30~50个关键数据项资料来源：小组分析 2 字段数关键性通常做法领先银行治理推进节奏 30-50 500-750 超出数据治理范畴的数据项非关键数据项（L- CDE） (E-CDE) 条线级关键数据项（B-CDE）企业关键数据项高 2,000- 5,000 5万- 10万  重点治理  优先启动（通常前1年内完成）  选择性治理  重点治理  次优先启动（通常前3年内完成）  以1年半的时间治理了70 个关键数据项  3年内将治理范围扩大到 200多个  通常不治理  不治理  未作为关键数据项管理  第一年重点治理4大关键数据域  第二年参考数据域和重要衍生数据域  第三年重要的交域  不治理  日常化各业务条线自理 2525| 不同等级的关键数据项，采取差异化的管理方式资料来源：小组分析 2 M O N/A E-CDE B-CDE 非关键数据管理的要求 M M M M M O M O N/A M M N/A M M O M M M M O N/A M O N/A M M O ▪ 规定与数据项(DE)相关的职责，将每个数据项与数据域一一对应，并确定每个数据域的责任人员 ▪ 建立数据质量报告的（DQ）机制和流程，按照具体的数据质量规则监控数据项的数据质量，并定期向数据治理中心质量管理岗报告 ▪ 报告数据项的数据质量结果，并针对数据治理中心质量管理岗关注的质量问题，跟踪相关补救措施的进度 ▪ 报告数据项的数据质量结果，并针对数据管理委员会关注的质量问题，跟踪相关补救措施的进度 ▪ 在企业数据字典中填写数据项的最重要的业务和技术元数据属性（例如：标准定义、责任方、数据质量规则） ▪ 遵循企业问题解决及响应SLA(服务水平协议可按各个数据项重要水平规定不同服务水平） ▪ 在企业数据字典中填写全部数据项的业务和技术元数据属性（包括：来源系统、数据血缘、黄金数据源等） ▪ 记录数据项的端对端数据血缘关系，跟踪数据项的起源直至前端的来源系统 ▪ 记录部分数据项的数据血缘（例如，回溯至数据仓库（EDW）或立即回溯至源系统来源）强制性可选的不适用数据责任数据问题追踪数据血缘梳理元数据维护服务要求质量报告 2626| 1. 只针对重要数据项进行CDE优先排序审核 2. 验证数据项是否用作重要报告（诸如 FRY-9C、FRY-14A/M/Q、10K/Q报告）的指标或指标的输入值优先排序决策框架数据治理中心向各业务部门收集该数据项的影响程度评估结果（高/中/低）数据治理中心整合各业务部门的反馈结果，并计算企业层面的平均影响程度（高/ 中/低）数据治理中心与各数据责任人和管家协作，确定数据项对监管的影响程度（高/中/低）中等/较低影响程度数据治理中心初步判断数据项 (DE)是否需要进行优先级审核1 数据治理中心与各数据责任人和管家协作，确定数据项是否用于监管报送2 数据域级关键数据项（D-CDE）非关键数据项（L- CDE）企业关键数据项（E- CDE）已使用中等影响程度影响水平较低高影响程度监管影响考虑维度  资本要求  资产负债表  利润表  合规业务影响考虑维度  财务  运营  客户未使用数据治理中心将待审核清单发送给数据责任人和管家重要性的考虑因素  被某个数据域使用  对于某个业务流程非常重要  需要一定程度的监管/重视数据影响评估监管评估预审阶段关键数据项的分级筛选方法2 资料来源：小组分析 2727| 1. 在普通股一级资本比率为%时，其1%约等于10个基点示例分析监管影响和业务影响的评估维度业务影响评估监管影响评估高中运营影响对于业务单元的日常运营绝对需要，否则可能造成一天以上的停业对于业务单元的日常运营并不需要；但如果没有，则可能造成运营低效对于业务单元的日常运营并不需要；即使没有，也不会造成运营低效对业务合规的影响违反了一项企业政策并未违反任何企业政策对业务单元实际税前净利润的影响大于5% 对业务单元实际税前净利润的影响在%--5%之间对业务单元实际税前净利润的影响小于% 客户影响导致业务单元客户流失率上升，增幅为当前值的10%以上财务影响导致业务单元客户流失率上升，增幅为当前值的5%至 10% 导致业务单元客户流失率上升，增幅为当前值的5% 以下对资产负债表的的影响对银行已列报资产负债表的影响大于1% 影响水平不到银行报告的资产负债表的1%，但超过银行报告的税前净收入的% 对银行已列报税前净利润的影响小于% 影响水平大于已列报普通股一级资本比率的1% 1 影响水平不到报告的普通股权一级资本比率的1%，但大于1个基本点可能造成监管报告事项(例如，需要立即关注/关注的事项（MRIA/MRA)）对资本要求的影响对已列报普通股一级资本比率的的影响小于1个基点对银行报告的税前净收入的影响水平超过5% 对银行已列报税前净利润的影响小于5%，但大于% 对利润表的影响对银行已列报税前净利润的影响小于% 低对该分行净影响的默认值将采用四个维度的最高影响水平对该分行的净影响将采用所有三个维度的平均影响水平维度各数据域应采用上述标准对数据项进行总体评估，而非按单项记录进行评估 2 资料来源：小组分析 2828| 数据项监管影响评估业务影响评估重要性评估数据项域在重要主力报告中的利用重要报告影响将数据项列为高影响水平的部门将数据项列为中等影响水平的部门将数据项列为低影响水平的部门企业影响得分重要性层级数据责任人数据管家评估日期审核日期 FRB代码管制报告录入FRY 9C附表HCR 和HCC FRY-14A/Q/M ，以及美国证券交会（SEC）10K/Q报表评估指标高 N/A N/A N/A N/A ECDE -- 按FRB代码划分的贷款余额管制报告 FRY-9C 附表 HCC和 FRY-14A/Q/M中的评估指标录入FRY -9C附表HCR ，FRY-14Q管制转换附表、FRY-14A，以及美国证券交会（SEC）10K/Q报表的评估指标高 N/A N/A N/A N/A ECDE -- 贷款的风险加权资产（RWA）管制报告 FRY 9C附表HCR， FRY-14Q转换附表， FRY-14A，以及美国证券交会（SEC）10K/Q 报表的评估指标高 N/A N/A N/A N/A ECDE -- “业务影响评估”部分说明数据项在所有业务部门的重要性 “重要性评估”部分说明数据项的最终“ 重要性”层级和审批记录 “监管影响评估”部分说明数据项在特定主要报告中的使用情况数据治理中心利用所提供的模板记录了优先排序的理论依据资料来源：小组分析 2 示例分析 2929| 首批，可以从用例数据需求出发，优先治理~50个关键数据项资料来源：小组分析 2 示例分析治理评估结果数据域一级数据子域二级数据子域三级数据子域涉及数据项/ 数据内容详细数据项数据所在系统可能的黄金数据源选择编号来源/ 关联数据项问题描述对应用例解决方案大类细化解决方案数据治理难度首批重点治理对象数据内容问题描述解决方案质量问题归类问题提出方定位具体的数据项数据项所在系统可能的黄金数据源来源数据项 1.数据项缺失 2.数据项质量差 – 不完整 3.数据质量差 – 不一致 4.数据质量差 – 不准确 5.数据质量差 – 不规范 1.业务提出的对于数据问题的简单描述 2.通过进一步的核实和分析之后，针对数据问题情况的详细说明，可能包含具体的示例首批业务用例，采用“ 编号 – 用例名称”的方式呈现问题提出的来源： 1.标准 – 期 2.用例业务方 3.其他业务部门针对具体数据问题，分阶段的解决方案描述根据具体解决方案，评估治理难度，以需要达到数据治理效果具体投入和耗费的时间、资源进行估算判断数据项是否作为首批重点治理对象，主要考虑维度： 1.数据项是都跨业务部门和应用被使用 2.数据项治理难度首批优先治理的关键数据项筛选表格数据域层级和具体归属的内容项目组建议首批业务用例的~50个关键数据项  项目组基于首批推进的6个业务用例，收集了关键数据项和数据问题  分析、梳理和诊断数据问题之后，明确首批治理对象 3030| 目录 ▪ 数据质量现状回顾 ▪ 数据质量提升方案 – 谁来做？——明确数据治理责任人 – 做什么？——定义治理范畴（即关键数据项）和标准 – 怎么做？——工作方法和机制保障（能力、意愿） ▪ 数据模型架构 3131| 数据质量提升的10大关键举措资料来源：联合小组分析 “做什么” “怎么做” 关键问题质量提升关键举措关键数据项 4大治理方法、 4大治理保障  全行数据分级管理，优先治理关键数据： - 建立数据重要性分级机制，梳理全行数据资产，区分关键和非关键数据 - 首批，可以从用例数据需求出发，优先治理~50个关键数据项  统一全行数据标准，建立元数据管理： - 数据治理中心发布全行数据标准规范和政策 - 数据管家参照标准规范定义关键数据项标准、口径，并完善元数据业务定义  定义黄金数据源，集中治理管控，简化数据架构  建立数据质量指标体系，健全数据问题治理机制  建立全行主数据的强管理，从客户主数据开始，逐个纳入  能力建设：建立数据治理培训体系，提供数据治理资质认证，  意愿调动：以数据质量和管控的指标体系作为考核依据，采取部门为主体的奖惩激励机制（参考B8考核激励部分设计）  工具部署：部署3大数据管理工具，包括：元数据、数据质量和数据标准管理系统（参考B工具和系统部分设计）  流程标准化：建立数据治理流程体系框架，优先详细界定7大关键流程（参考B8数据治理流程的设计） 2 3 4 5 7 8 9 6 10 “谁来做” 业务IT双轮驱动  建立全行治理体系，业务IT双轮驱动： - 建立由上至下、科技推动、业务负责的全行治理体系，包括：数据管理委员会、数据治理中心、以及业务的数据域/项管家 - 率先任命首批业务用例方的数据责任人和数据管家 1 3232| 遵照标准流程进行数据标准定义3 资料来源：小组分析 1. 发布全行数据标准指导准则和框架数据责任人数据管家数据标准和元数据管理岗数据质量管理岗数据治理规划岗角色发布标准框架和模板评审和纳入数据标准平台定义数据项业务和技术标准业务人员数据治理中心 2. 发布数据标准信息模板 3. 定义业务数据标准 IT 人员系统平台开发人员1 5. 定义技术数据标准 6. 整合数据项业务和技术标准并进行审批 4. 审批业务数据标准数据项标准实施 8. 数据项标准技术实现标准一期项目 3大基础主题成果导入 7. 纳入企业级数据标准平台 1. 对应数据项所在系统平台的开发维护人员数据管家定义业务标准数据标准和元数据管理岗经过审核后，将数据标准纳入标准平台体系 3333| 元数据在开发和运维过程的强管理流程3 资料来源：小组分析 1. 对应数据项所在系统平台的开发维护人员 1. 提交所在系统的数据规格数据责任人数据管家数据标准和元数据管理岗数据治理规划岗角色开发系统提交自有系统数据规格供审核再次提交和审核审核并提出修改意见和具体指标标准新增需求业务人员数据治理中心 2. 和全行已有数据标准进行比对与审核 IT 人员系统平台开发人员1 系统正式上线 5. 出具评审结果和修改意见 6. 根据意见修改数据规格符合统一标准 3. 提出新增数据项标准定义需求 4. 进行数据标准定义（参照标准流程） 7. 再次提交审核 8. 审核通过 9. 系统上线数据质量管理岗所有新的系统上线前或是系统有修改更新，需要提交数据标准和元数据管理岗进行审核若有新的数据项为定义标准的，则发起标准定义的流程针对已有的数据项和标准，要求进行统一通过审核方可正式上线元数据管理原则数据字典  存量：分批次进行收集、整合和补全  新增：在开发和运维过程中进行强管理  考核：元数据的信息收集纳入平台技术管理人员考核数据血缘  存量：分批次由源系统进行提交  新增：需要评估和维护对于已有血缘关系的影响  考核：对于源系统开发人员考核是否按时提交 3434| 元数据数据质量检验规则数据标准元数据直接调用数据标准和数据质量检验规则示例模板3 数据标准编号数据标准定义（业务）所在数据域数据标准名称数据标准定义（技术所在主题数据标准类型1 …… 数据质量规则编号数据质量规则（业务）所对应数据项数据质量规则名称数据质量规则（技术）检查频率规则指标目标 …… 数据项名称（业务）数据项名称（技术）数据项所在系统名称数据项所在表单名称数据项所在数据域数据项管家数据责任人技术管理员数据项对应标准编号数据项对应标准名称数据项来源系统数据项血缘关系数据项重要性等级数据项黄金数据源数据项对应质量编号数据项对应质量名称数据项访问使用权限 …… 关联调用关联调用 3535| 数据治理中心的标准和元数据管理岗负责创建和维护企业级的数据字典框架与模板 3 资料来源：小组分析元数据定义分类关键属性价值描述定义域相关人 ▪ 唯一的数据项标识 ▪ 关键数据项名称 ▪ 业务定义 ▪ 数据域的名称 ▪ 数据域的类型 ▪ 数据域主责单位 ▪ 数据的责任人和管家 ▪ 技术管理员 ▪ 最后由谁更新为用户提供关于数据项的情境信息有助于将数据项映射到其他数据项，两者与同一特定主题范围有关。确定有关某个特定数据项的接触点，以供参考定义数据项，并提供附加的使用信息提供关于数据项所属数据域的信息提供负责数据项的成员/人员信息质量更新技术血缘 ▪ 业务规则和CDE状态 ▪ 数据质量技术规则 ▪ 数据质量指标目标和门槛 ▪ 最后更新日期 ▪ 最后核对日期 ▪ 更新说明 ▪ 技术名称 ▪ 唯一标识符 ▪ 官方数据源 ▪ 官方数据源 ▪ 上游来源 ▪ 下游用途提高数据项存储信息的可信度提供可视性，保证数据项是最新的支持数据血缘的追踪和技术数据质量规则的创建赋予用户追踪数据来解决问题或得到更优质信息的能力应用到数据项的数据质量度量细节追踪最后添加到数据项中的变化细节，包括更新的论据数据项的技术定义细节提供从数据项源到数据消耗/转化的追踪业务为主技术为主业务技术共同 3636| 数据字典框架模板中的部分信息项示例说明示例模板3 描述元数据属性示例类别定义和归属分类质量相关人数据血缘 ▪ 业务定义 ▪ 某一特定数据项的业务用例定义 ▪ 表明贷款落入哪类FED代码分类的数据项系统输入字段 ▪ 数据项名称 ▪ 数据项的名称（DE） ▪ FRB代码/ Fed代码 ▪ 域名 ▪ 数据项所属的数据域的名称 ▪ 监管报表 ▪ 数据管家 ▪ 业务方具体负责数据项/域管理的数据管家 ▪ BBB ▪ 数据责任人 ▪ 业务部门的数据责任人 ▪ AAA ▪ 技术负责人 ▪ 负责技术管理及系统维护的人 ▪ CCC ▪ 重要性层级 ▪ 数据项重要级别的定义（非关键/ CDE/ECDE） ▪ ECDE ▪ 业务规则 ▪ 数据项必须满足的质量规则 ▪ 所有贷款应该有一个FRB码 ▪ 贷款应该有一个唯一的代码 FRB ▪ 此DE值应为大于0的3位数字 ERM 贷款 CRS SQLABC  Fed代码  Fed贷款  NAICS  组织类型  国家  Fed商业类型  免税设施标志  贷款用途  主要抵押品  抵押品类别/类型  NAICS  组织类型  国家  派生的Fed类黄金数据源 3737| 定义和归属相关人分类质量数据血缘数据项数据项名称业务定义重要性数据负责人数据管家平台管理员重要性层级业务规则系统输入字段 1 贷款号码贷款产品的连续编号 CDE 抵押贷款 2 财产街道地址抵押财产对象的地址 ECDE 抵押贷款 3 财产某省市抵押财产对象所某省市 CDE 抵押贷款 4 财产所在州抵押财产对象所在的州 n/a 抵押贷款在有完备的标准、元数据和质量管理系统之前，可以通过excel模板进行数据字典的维护示例模板3 资料来源：联合小组分析 3838| 数据质量提升的10大关键举措资料来源：联合小组分析 “做什么” “怎么做” 关键问题质量提升关键举措关键数据项 4大治理方法、 4大治理保障  全行数据分级管理，优先治理关键数据： - 建立数据重要性分级机制，梳理全行数据资产，区分关键和非关键数据 - 首批，可以从用例数据需求出发，优先治理~50个关键数据项  统一全行数据标准，建立元数据管理： - 数据治理中心发布全行数据标准规范和政策 - 数据管家参照标准规范定义关键数据项标准、口径，并完善元数据业务定义  定义黄金数据源，集中治理管控，简化数据架构  建立数据质量指标体系，健全数据问题治理机制  建立全行主数据的强管理，从客户主数据开始，逐个纳入  能力建设：建立数据治理培训体系，提供数据治理资质认证，  意愿调动：以数据质量和管控的指标体系作为考核依据，采取部门为主体的奖惩激励机制  工具部署：部署3大数据管理工具，包括：元数据、数据质量和数据标准管理系统  流程标准化：建立数据治理流程体系框架，优先详细界定7大关键流程 2 3 4 5 7 8 9 6 10 “谁来做” 业务IT双轮驱动  建立全行治理体系，业务IT双轮驱动： - 建立由上至下、科技推动、业务负责的全行治理体系，包括：数据管理委员会、数据治理中心、以及业务的数据域/项管家 - 率先任命首批业务用例方的数据责任人和数据管家 1 3939| 黄金数据源的筛选：为什么要建立“黄金数据源”4 资料来源：小组分析数据质量管理的困扰 “黄金数据源”可以解决的问题  所需管理的数据存在系统中的多个地方，管理千头万绪，无从下手  不同业务用户从不同的源头取数，造成不一致  类似数据存多套，造成数据存储的冗余，占用存储空间  数据多处引用，造成数据链路复杂，维护成本高  无法形成唯一的数据质量衡量结果，各来源情况不一  集中在黄金数据源管理一类数据  用户可以清晰知道应该从哪里获取高质量的定义明确的数据  减少冗余的数据存储，释放多余空间，降低运维成本  简化数据架构和链路，降低开发和维护难度  可以获取唯一的数据质量衡量结果，形成统一认知 4040| 黄金数据源的筛选：黄金数据源应符合7大条件4 资料来源：小组分析说明黄金数据源的原则专人管理 ▪ 将有公认的业务、数据和科技人员对每个黄金数据源进行管理（例如：黄金数据源所涵盖的数据域的数据责任人和数据管家、系统管理人员、数据治理中负责人员）唯一性 ▪ 每个关键数据项（CDE）可存在多个系统，但将只有一个唯一的黄金数据源 ▪ 黄金数据源是以数据域为单元的，即一个数据域内的数据项都存放在一个黄金数据源，便于集中个管理 ▪ 黄金数据源将相对平等地支持各个业务条线和各个企业职能部门的的需求（例如：提供足够广的数据覆盖面和细化程度，以满足所有需求） ▪ 黄金数据源将符合企业的数据访问和使用标准（例如：跨业务条线的数据访问） ▪ 黄金数据源将作为评估、监控和执行该数据域的数据质量的节点（问题修复将在上游的问题产生点进行）存储多个历史版本，供追溯历史和问题诊断 ▪ 交数据来源将仅存储三个财务年度(截至当日的年数)的版本记录 ▪ 参考官方数据来源将无限期存储历史版本记录 ▪ 黄金数据源将带来数据架构的简化和标准化，并确保与企业标准相一致（例如：降低数据资产的存储份数），适当的时候充分利用新一代技术 1 2 满足企业数据需求 3 符合控制标准 4 数据质量和数据域控制的官方节点5 存储历史版本记录，为数据质量控制提供支持 6 简化和标准化数据架构 7 4141| 黄金数据源的筛选：黄金数据源的定位规划和管理方式4 资料来源：小组分析主数据域交域衍生数据域挖掘数据域 ▪ 全行层级关键的被多方调用的核心经营主体数据，如：客户、产品、机构等 ▪ 运营端产生的产品类交产品类交互，如：支付交易、客服交互等 ▪ 贴近业务应用端支持某类特定业务目的的数据某省市场风险、反欺诈等 ▪ 通常以经营主体客户为对象的用于数据挖掘的宽表，如：客户360 数据域数据域描述来源系统 ▪ 交 ▪ 交 ▪ 进行指标计算和存储的系统 ▪ 进行指标计算和存储的系统黄金数据源位置 ▪ 主数据管理系统 ▪ 支持运营和分析数据需求的ODS （如：MDS） ▪ 主要支持业务应用分析需求的数据仓库（如：EDW） ▪ 支持高级分析数据需求的数据仓库或沙盘 ▪ 管理方式 – 一个黄金数据源一般对应多个数据来源系统 – 每个数据来源有指定的数据管家 – 一个黄金数据源可能对应多个数据管家共同管理，各自负责来源系统问题并就争议达成一致意见 ▪ 数据提供方式 – 为了便于黄金数据源的对外供数，实际用户对于数据的获取和访问可以通过建立镜像和虚拟存储的方式来实现 4242| 黄金数据源的实现主要步骤黄金数据源的筛选：黄金数据源的实现路径4 资料来源：小组分析公开发布“ 黄金数据源 ” 优先治理关键数据项（数据标准、口径和定义）治理并建立黄金数据源限定时间进行用户迁徙和数据链路切换圈定所在数据域范畴和数据项清单选定黄金数据源明确来源系统和相关数据管家明确数据范畴和来源系统选定和建立黄金数据源发布和完成用户迁徙黄金数据源的实现路径要点治理顺序先从衍生类指标的关键数据项开始，配合主数据管理系统进行主数据的黄金数据源建立，然后是交据的源头系统的规范和治理治理范围从关键数据项发起，但以数据项所在数据域为单位，选定黄金数据源，明确来源系统和数据管家先“治理” 后“发布” 先将选定的黄金数据源治理完毕（达到一定数据质量、明确具体数据项清单和边界、具备集中和供数功能），再正式对外发布，进行迁徙和切换日常维护和管理对于前端系统的新增和修改，都会借助元数据管理，识别是否涉及已发布黄金数据源的数据域，进行源系统的添加和链路集中 4343| 黄金数据源的筛选：如何定义黄金数据源4 资料来源：小组分析选定黄金数据源明确数据范畴和来源系统治理并建立黄建数据源数据用户数据管家 IT系统开发人员数据标准和元数据管理岗 1. 发起数据域的“黄金数据源”选取要求角色业务人员 IT 人员数据治理中心数据质量管理岗数据架构负责人 2. 提供该数据域所分布的各数据源当前系统评估结果 4. 制定数据架构实现和迁徙方案 2. 从业务角度提供“ 黄金数据源 ”选取建议和输入 2. 从管理角度提供“ 黄金数据源 ”选取建议和输入 5. 数据项元数据维护和更新 5. 企业级数据字典更新整合 5. 数据质量指标产出规则更新 5. 系统架构实施 7. 适应新的数据使用和获取的方式途径变更数据负责人数据治理规划岗 3. 开展圆桌会议进行 “黄金数据源 ”选取的探讨和决议 a b ca a 后续展开公开发布“黄金数据源”，完成用户迁徙 6. 公开发布“黄金数据源” 4444| 标准问题 1.可行性目前是否存在？如目前尚不存在，那么未来1年内是否会存在（基于当前的预算投入），从而可由下游用户开始采用？ 2.完整性是否包含整个银行对该类型数据的全部记录（包含所有来源系统）？如不包含全部，那么包含该类型数据的百分比是多少？ 3.深度是否包含历史记录？如包含历史记录，那么包含多少期间的（日、月、年）？ 4.使用 a. 是否向重要职能部门（风险、资本、资金管理）提供当期数据？如提供，提供多少？ b. 是否向重要职能部门（风险、资本、资金管理）提供历史数据？如提供，提供多少？ 5.频率数据获取的频率？向用户提供数据的频率是多少？ 6.质量与总账对账的流程是否已有规定并有效运行？目前能达到的准确度？ 7.记录元数据记录及维护流程是否已有规定并有效运行？如是，可提供何种元数据信息（例如，业务/技术性元数据）？覆盖深度如何？ 8.业务责任方 a. 是否支持特定的业务应用（例如，特定风险管理/融资部门的用途）？ b. 业务部门是否参与数据的标准化？ c. 谁是业务责任方？黄金数据源的筛选：制订一整套标准，并根据这些标准评定该类数据所在的各个数据源的情况，作为黄金数据源筛选的评判基础 4a 资料来源：小组分析 4545| 标准/问题按揭贷款数据储存库 DB1 DB2 DB3 可行性  目前是否存在？是是是  如目前尚不存在，那么未来1年内是否会存在，从而可可由下游用户开始采用？ . 是将实施简化方法完整性  是否包含整个银行对该数据类型的记录？否是否（自由标签或预先购买账户）  如否，所包含的来源系统的百分比是多少？ 10% 100% 100% 深度  是否包含历史记录？否作为2014年度历史数据合并项目的组成部分是  如不包含历史记录，那么包含多少期间（月、日、年）？ . 在2013年11月开始的数据永久保存。在2014年，对15个年度期间的历史月度数据进行了合并，但保存在一个字段子集之中 1年期间在线数据/7 年期间离线数据使用  目前是否向重要职能部门（风险、资本、资金管理、核心融资）提供当期数据？否是是  如提供，提供多少？风险、资本、资金管理、融资、 14A/14M、CCAR 风险/资本/资金管理融资/消费  目前是否向重要职能部门（风险、资本、资金管理、核心融资）提供历史数据？否是是  如提供，提供多少？ . 风险,资本风险/资本/资金管理融资/消费频率  频率每天每日核心数据；每月的特定融资/ 会计核算流程每日/每周/每月质量  与总账对账的流程是否已有规定并有效运行？否每天包括双图表字段（总账以下）否黄金数据源的筛选：通过多个数据源的评估结果，选取黄金数据源 ▪ “黄金数据源”通常显而（或者至少是数量有限的几个来源） ▪ 在本例中，DB2将是“黄金数据源” 的首选项，其原因是其最补的不足和进行下游用户的迁移示例4a 资料来源：小组分析建议选取的黄金数据源 4646| 黄金数据源的筛选：需要举行跨业务部门的工作会议，确定每个域/项的黄金数据源参与“黄金数据源”决策研讨会的每位成员的议题对不同技术和业务部门之间的诉求不一致，可以通过如下方式进行管理：  为“黄金数据源”定义一个结构化的决策框架，提前收集相关数据，以便在会议期间做出基于事实的评估  将工作会议成员限定为由系统平台管理者、数据管家和业务部门用户（例如风险和财务部门）组成的小团体，随着治理模式的进一步完善，之后再扩大到其他参与者针对单个数据域 “黄金数据源” 的决策研讨会关键业务方的数据管家 ▪ 优先推选处于他们业务线控制之下的数据资产/系统负责不同数据源的系统平台管理者 ▪ 将自己的数据源推举为黄金数据源，以保持其连续性 ▪ 争取获得额外维护升级预算 ▪ 避免承担企业治理要求的额外责任相关的业务数据用户 ▪ 优先选择对他们而言最好用的数据来源（通常支持目前他们在用的数据资产来源） ▪ 确保“黄金数据源”获得足够的预算以满足他们新的需求（如巴塞尔协议III）数据治理中心的成员 ▪ 优先选取符合企业数据标准的数据来源（例如具备元数据记录） ▪ 平衡益相关者的需求 ▪ 确保各小组的参与案例4b 资料来源：小组分析 4747| 黄金数据源的筛选：明确黄金数据源之后，通过有规划的数据来源和出口归集，完成数据的集中和迁徙第一年第二年第三年第四年阶段描述分批次迁徙用户，使用黄金数据源率先迁移优先客户和关键应用，再迁徙其他用户，同时依照严格的QA/QC活动进行管理除役所有遗留系统和冗余存储进口出口都统一之后，移除其他冗余的中间存储源头数据统一归口到黄金数据源让所有相关源数据都统一供数给“黄金数据源”，形成集中的归口和节点，统一管控和治理分析现状，厘清链路，指定“黄金数据源” 针对数据域（项）厘清数据链路，充分评估会议决策“黄金数据源”的建立和选取 1 OSD Legacy User User SOR SOR SOR SOR OSD Legacy User User SOR SOR SOR SOR OSD Legacy User User SOR SOR SOR SOR OSD User User SOR SOR SOR SOR 指定黄金数据源归集数据归集出口移除冗余2 3 4阶段计划 OSD 黄建数据源 4c 资料来源：小组分析 4848| 数据质量提升的10大关键举措资料来源：联合小组分析 “做什么” “怎么做” 关键问题质量提升关键举措关键数据项 4大治理方法、 4大治理保障  全行数据分级管理，优先治理关键数据： - 建立数据重要性分级机制，梳理全行数据资产，区分关键和非关键数据 - 首批，可以从用例数据需求出发，优先治理~50个关键数据项  统一全行数据标准，建立元数据管理： - 数据治理中心发布全行数据标准规范和政策 - 数据管家参照标准规范定义关键数据项标准、口径，并完善元数据业务定义  定义黄金数据源，集中治理管控，简化数据架构  建立数据质量指标体系，健全数据问题治理机制  建立全行主数据的强管理，从客户主数据开始，逐个纳入  能力建设：建立数据治理培训体系，提供数据治理资质认证，  意愿调动：以数据质量和管控的指标体系作为考核依据，采取部门为主体的奖惩激励机制（参考B8考核激励部分设计）  工具部署：部署3大数据管理工具，包括：元数据、数据质量和数据标准管理系统（参考B工具和系统部分设计）  流程标准化：建立数据治理流程体系框架，优先详细界定7大关键流程（参考B8数据治理流程的设计） 2 3 4 5 7 8 9 6 10 “谁来做” 业务IT双轮驱动  建立全行治理体系，业务IT双轮驱动： - 建立由上至下、科技推动、业务负责的全行治理体系，包括：数据管理委员会、数据治理中心、以及业务的数据域/项管家 - 率先任命首批业务用例方的数据责任人和数据管家 1 4949| 建立三个层次的数据质量报表，进行体系化数据质量追踪管理，建立KPI考核体系作为运作保障机制企业级管理指标数据域管理指标关键数据项质量指标用户 ▪ 监督各数据域的质量和治理情况 ▪ 触发相关干预措施 ▪ 进行检视，发现、分析和解决问题 ▪ 追踪质量提升情况 ▪ 作为考核数据责任人和域管家治理成效的关键指标 ▪ 对结果进行检视，如有问题则遵循数据问题解决流程进行处理 ▪ 作为考核关键数据项管家治理成效的关键指标汇总细分作用和考核 ▪ 数据治理中心 ▪ 数据责任人 ▪ 数据域管家 ▪ 关键数据项管家 ▪ 数据管理委员会 ▪ 作为考核数据治理中心治理工作的重要依据内容 ▪ 企业级数据质量报告，包含所有数据域 ▪ 指标涉及3大方面：管控、质量标准和元数据 ▪ 衡量数据域中关键数据项的数据质量情况，是关键数据项汇总之后的结果 ▪ 也包含管控和元数据管理情况 ▪ 衡量关键数据项是否符合数据标准，包括：规范性、完整性、准确性、一致性等关键质量指标资料来源：小组分析 5 5050| 根据数据质量标准建立数据质量指标规则，明确治理目标，并持续监控、分析和进行问题修复 5 资料来源：小组分析顺利进行问题 / 疑虑延迟客户域现状目标问题状态根本原因问题执行人问题负责人指标规则 80% 95% 问题缓解待定待定待定1- 规范性（A）按照国某省市、区、弄…拆分存储 70% 95% 补救计划核准待定待定待定1- 规范性（B）每个拆分项符合数据格式要求 60% 95% 问题审视中待定待定待定1- 规范性（C）每个拆分项符合字符长度要求 25% 95% 问题审视中待定待定待定2- 完整性所有个人客户中家庭地址不为空的比例 60% 80% 文字待定待定待定3- 真实性通过定期抽查、一线反馈或和外部数据交叉比对，获得的抽样真实性比例范围 CDE 家庭地址数据项状态方案 ▪ 问题审视中 ▪ 补救计划设计进行中 ▪ 补救计划核准 ▪ 执行中 ▪ 问题缓解 1. 根据定义的数据标准建立数据质量指标规则 2. 设立每类数据质量指标的目标 3. 根据现状和目标差距，设立质量门槛，识别质量问题，分析原因，指定负责人和执行人，提出解决方案，并根据解决进度解决方案说明：针对需要追溯由多个数据管家协同修复的数据质量问题，会被记录在同一个数据质量问题下，且每个相关的数据管家，都会有相应需要负责处理的问题，问题的管理者将由数据治理中心的质量管理岗担当 5151| 典型数据质量问题的几类修复方案5 资料来源：小组分析一致性完整性规范性真实性 ▪ 标准口径定义不完善 ▪ 多个数据来源不统一 ▪ 计算加工逻辑存在偏差 ▪ 数据采集不完善 ▪ 数据整合不完整 ▪ 前线认为因素导致，如：不理解、偷懒和故意屏蔽 ▪ 数据整合更新不及时 ▪ 缺乏规范性定义 ▪ 采集前端不规范 ▪ 处理过程未按规范处理其他问题： 1- 数据缺失：根据业务需求进行数据创建和采集引入 2- 定义难统一：由于管理逻辑或组织壁垒等原因导致的数据统计口径不一致，通过协调多方进行解决产生原因采取措施 ▪ 明确定义数据口径和标准执行人数据管家 ▪ 定义、使用黄金数据源数据管家、IT系统开发人员 ▪ 修正系统加工逻辑 IT系统开发人员 ▪ 业务优化采集流程和要求数据管家 ▪ 优化系统链路整合逻辑数据管家、IT系统开发人员 ▪ 根据具体原因，采取培训教育、流程优化、考核惩罚、运动式补救等方式 ▪ 调整整合逻辑和更行链路数据管家数据管家、IT系统开发人员 ▪ 明确数据标准规范 ▪ 采取教育培训和系统强制 ▪ 加强质量控制数据管家 IT系统开发人员数据管家、IT系统开发人员 5252| 项目制的数据治理工作数据质量的日常管理机制5 资料来源：小组分析数据质量日常管理主要工作开展机制 ▪ 全行统一目标和规划的治理工作 – 每年末制定未来一年重点数据治理相关项目和目标(通常伴随业务用例的开展节奏) – 指定业务参与人员，包括数据责任人和数据管家 – 基于目标，确定关键考核指标及评价标准 ▪ BAU数据治理工作 – 日常BAU问题采取标准流程进行收集管理，按照数据重要性划分进行治理和资源分配 ▪ 重点考核全行级治理项目所涉及的目标指标，辅助观测BAU治理动作完成情况年初年中年末规划和目标治理和追踪重点考核（必要）人员和职责 BAU（常态化）数据治理工作数据问题发现识别、分析诊断和治理追踪1 辅助考核（加分） 1 数据治理中心的质量岗会负责对所有黄金数据源的日常质量监控，并针对数据问题进行分析诊断，协同数据管家一同制定修复方案，并追踪治理进度和成果 5353| 数据质量提升的10大关键举措资料来源：联合小组分析 “做什么” “怎么做” 关键问题质量提升关键举措关键数据项 4大治理方法、 4大治理保障  全行数据分级管理，优先治理关键数据： - 建立数据重要性分级机制，梳理全行数据资产，区分关键和非关键数据 - 首批，可以从用例数据需求出发，优先治理~50个关键数据项  统一全行数据标准，建立元数据管理： - 数据治理中心发布全行数据标准规范和政策 - 数据管家参照标准规范定义关键数据项标准、口径，并完善元数据业务定义  定义黄金数据源，集中治理管控，简化数据架构  建立数据质量指标体系，健全数据问题治理机制  建立全行主数据的强管理，从客户主数据开始，逐个纳入  能力建设：建立数据治理培训体系，提供数据治理资质认证，  意愿调动：以数据质量和管控的指标体系作为考核依据，采取部门为主体的奖惩激励机制（参考B8考核激励部分设计）  工具部署：部署3大数据管理工具，包括：元数据、数据质量和数据标准管理系统（参考B工具和系统部分设计）  流程标准化：建立数据治理流程体系框架，优先详细界定7大关键流程（参考B8数据治理流程的设计） 2 3 4 5 7 8 9 6 10 “谁来做” 业务IT双轮驱动  建立全行治理体系，业务IT双轮驱动： - 建立由上至下、科技推动、业务负责的全行治理体系，包括：数据管理委员会、数据治理中心、以及业务的数据域/项管家 - 率先任命首批业务用例方的数据责任人和数据管家 1 5454| 领先银行都会针对企业级主数据建立单独管理平台，提高数据的一致性、完整性，减少数据的冗余资料来源：联合小组分析主数据管理平台要求主数据唯一识别主数据管理组织架构主数据信息共享主数据流程化管理规范化主数据业务规则/ 流程变化业务规范变化部门职能调整总行相关规范发布应用系统新建/变更产生影响和采取行动依照数据模型主品类分类梳理我行主题域管理框架，明确主数据定义和规则对主数据的编码名称等重要属性进行规范和维护主数据责任部门需要明确，并设立专属的主数据负责人主数据在系统间的传输关系需要规范和维护主数据在主数据管理系统及其他系统中的分布和使用需要定义标准化的流程客户信息合约信息产品信息机构信息员工信息押品主数据管理范畴 6 ▪ 通过主数据管理系统，配合数据责任指定和各类规范流程的制定，实现对于全行主数据的统一管理，确保一致性、准确性、规范性 5555| 建议在数据源和数据总线之间建立主数据管理系统层，短期内从客户主数据开始资料来源：联合小组分析数据系统设计建议建立主数据管理系统，直接对接数据源系统，统一集中管理客户主数据，再分发给运营和分析数据仓库详细展开：主数据管理系统网银信用卡柜台基金 ODS (MDS) 数据总线 (ESB/SOA) EDW运营系统 BP系统客户主数据系统实时更新数据应用可视化数据总线 (ESB/SOA) 运营报表 / 分析实时监控数据源数据缓冲存储 / ODS (MDS/OMDS) 运营数据架构数据外部数据历史数据库历史查询实时分析数据湖 ETL 数据服务层非结构化数据区结构化数据区历史数据区数据管控分析数据架构主数据管理数据流向： ▪ 源系统中的客户数据汇入BP系统进行管理（包括重要数据整合、重复数据删除等工作） ▪ BP将管理后的数据通过CDC技术实时更新至客户主数据系统 ▪ 客户主数据系统将更新后的主数据返回源系统设计亮点： ▪ 减轻当前BP系统的负担 – BP不再需要负责去更新源系统 ▪ 之后找到合适契机可以选择将BP的功能逐步转移至主数据管理系统 1 2 3 1 2 3 实时数据库实时数据库存款债券投资手机贷款理财风控 … 6 5656| 数据质量提升的10大关键举措资料来源：联合小组分析 “做什么” “怎么做” 关键问题质量提升关键举措关键数据项 4大治理方法、 4大治理保障  全行数据分级管理，优先治理关键数据： - 建立数据重要性分级机制，梳理全行数据资产，区分关键和非关键数据 - 首批，可以从用例数据需求出发，优先治理~50个关键数据项  统一全行数据标准，建立元数据管理： - 数据治理中心发布全行数据标准规范和政策 - 数据管家参照标准规范定义关键数据项标准、口径，并完善元数据业务定义  定义黄金数据源，集中治理管控，简化数据架构  建立数据质量指标体系，健全数据问题治理机制  建立全行主数据的强管理，从客户主数据开始，逐个纳入  能力建设：建立数据治理培训体系，提供数据治理资质认证，  意愿调动：以数据质量和管控的指标体系作为考核依据，采取部门为主体的奖惩激励机制（参考B8考核激励部分设计）  工具部署：部署3大数据管理工具，包括：元数据、数据质量和数据标准管理系统（参考B工具和系统部分设计）  流程标准化：建立数据治理流程体系框架，优先详细界定7大关键流程（参考B8数据治理流程的设计） 2 3 4 5 7 8 9 6 10 “谁来做” 业务IT双轮驱动  建立全行治理体系，业务IT双轮驱动： - 建立由上至下、科技推动、业务负责的全行治理体系，包括：数据管理委员会、数据治理中心、以及业务的数据域/项管家 - 率先任命首批业务用例方的数据责任人和数据管家 1 5757| 数据治理的理念转变和能力建设，可以通过三纵三横的宣导培训体系进行开展7 资料来源：小组分析行领导部门领导工作层理念宣导工作坊专题培训理念宣导工作坊专题培训针对各层级人员，持续化的数据治理和数据转型的日常理念宣导，包括：海报、宣传视频、奖竞猜、专题讲座等各类形式主要针对部门领导和工作层面的人员，通过工作坊的形式，配合特定工作和项目的发起，在能力建设知识传授的同时实践工作内容主要针对工作层面的人员，通过课程的培训体系和考核，授予相关岗位资质，确保具备岗位所需的必要技能和专业知识 5858| 针对专题培训，需要形成体系化的培训课程，通过授予认证的方式，确保业务方的数据责任人和数据管家具备参与数据治理的知识和能力 7 资料来源：小组分析数据治理中心根据数据项的重要性分配给相应的数据协调人/责任人数据协调人/责任人报送数据管家人选数据治理中心进行管家资格审核和培训数据管理委员会予以资格认证和正式任命关键数据项的筛选、新增和变更主要培训内容大纲和课时估算数据标准业务定义创建和维护数据质量指标业务定义创建维护黄金数据源筛选的流程和方法数据质量治理目标设定元数据的业务定义创建和维护数据质量问题识别、诊断和修复关键数据项其他数据问题和需求的提交管理数据标准统一黄金数据源质量考核追踪其他数据问题 1天 1天天 2天天课程大类课程子类课时预估培训运作机制培训课程开发：  由数据治理中心负责培训课程体系的具体开发和筹备培训组织开展：  纳入全行的课程体系中，由人力资源部统一组织开展  纳入全行培训体系的考核计算中培训认证授予：  培训是否通过的资质审核由数据治理中心进行把关  培训资质的授予由数据管理委员会统一颁布 5959| 数据质量提升的10大关键举措资料来源：联合小组分析 “做什么” “怎么做” 关键问题质量提升关键举措关键数据项 4大治理方法、 4大治理保障  全行数据分级管理，优先治理关键数据： - 建立数据重要性分级机制，梳理全行数据资产，区分关键和非关键数据 - 首批，可以从用例数据需求出发，优先治理~50个关键数据项  统一全行数据标准，建立元数据管理： - 数据治理中心发布全行数据标准规范和政策 - 数据管家参照标准规范定义关键数据项标准、口径，并完善元数据业务定义  定义黄金数据源，集中治理管控，简化数据架构  建立数据质量指标体系，健全数据问题治理机制  建立全行主数据的强管理，从客户主数据开始，逐个纳入  能力建设：建立数据治理培训体系，提供数据治理资质认证，  意愿调动：以数据质量和管控的指标体系作为考核依据，采取部门为主体的奖惩激励机制（参考B8考核激励部分设计）  工具部署：部署3大数据管理工具，包括：元数据、数据质量和数据标准管理系统（参考B工具和系统部分设计）  流程标准化：建立数据治理流程体系框架，优先详细界定7大关键流程（参考B8数据治理流程的设计） 2 3 4 5 7 8 9 6 10 “谁来做” 业务IT双轮驱动  建立全行治理体系，业务IT双轮驱动： - 建立由上至下、科技推动、业务负责的全行治理体系，包括：数据管理委员会、数据治理中心、以及业务的数据域/项管家 - 率先任命首批业务用例方的数据责任人和数据管家 1 6060| 针对业务部门和分行以红线的方式进行奖惩激励，针对全职的关键数据管家和数据治理中心以结果加动作的方式进行考核 8 资料来源：小组分析 KPI考核额外奖惩考核结果考核动作数据治理中心业务部门（红线考核）关键数据管家（全职） 1 2 3 ▪ 针对全职数据治理中心 – 可以通过KPI的方式对中心主任、数据管控主管、数据质量主管、元数据主管进行考核 – 考核指标不仅涉及数据质量结果，也考核过程性动作，如：数据管控进展、元数据维护等 ▪ 针对全职的关键数据管家，可以通过结果和动作的KPI进行考核 ▪ 针对兼职数据责任人和数据管家 – 建议考核整个部门而非个人 – 采取“红线考核”方法，超过目标额外奖励，不达目标进行费用减扣 – 每年预先设定治理目标指标，（可以项目制的形式推进） 1 2 3 数据治理考核3类对象关键设计思路 6161| 数据质量提升的10大关键举措资料来源：联合小组分析 “做什么” “怎么做” 关键问题质量提升关键举措关键数据项 4大治理方法、 4大治理保障  全行数据分级管理，优先治理关键数据： - 建立数据重要性分级机制，梳理全行数据资产，区分关键和非关键数据 - 首批，可以从用例数据需求出发，优先治理~50个关键数据项  统一全行数据标准，建立元数据管理： - 数据治理中心发布全行数据标准规范和政策 - 数据管家参照标准规范定义关键数据项标准、口径，并完善元数据业务定义  定义黄金数据源，集中治理管控，简化数据架构  建立数据质量指标体系，健全数据问题治理机制  建立全行主数据的强管理，从客户主数据开始，逐个纳入  能力建设：建立数据治理培训体系，提供数据治理资质认证，  意愿调动：以数据质量和管控的指标体系作为考核依据，采取部门为主体的奖惩激励机制（参考B8考核激励部分设计）  工具部署：部署3大数据管理工具，包括：元数据、数据质量和数据标准管理系统（参考B工具和系统部分设计）  流程标准化：建立数据治理流程体系框架，优先详细界定7大关键流程（参考B8数据治理流程的设计） 2 3 4 5 7 8 9 6 10 “谁来做” 业务IT双轮驱动  建立全行治理体系，业务IT双轮驱动： - 建立由上至下、科技推动、业务负责的全行治理体系，包括：数据管理委员会、数据治理中心、以及业务的数据域/项管家 - 率先任命首批业务用例方的数据责任人和数据管家 1 6262| 数据管控平台根据元数据管理、数据标准管理和数据质量管理系统里定义的规则在数据链路上各个环节抽取数据并进行监控 9 数据管控平台数据仓库 ETL 数据总线 ODS (MDS / OMDS) 基金理财支付存款贷款风控 … 数据源元数据管理平台企业级数据字典（关联标准和质量平台）数据血缘收集和记录数据标准平台数据质量管控平台规则平台报表平台作业平台数据治理门户（标准、政策、任命等发布） 8大基础标准数据标准的重要性分级关键指标标准详细描述三位一体的数据管控平台由数据标准平台、数据质量管控平台和元数据管理平台共同构建而成，通过与各端系统的对接，统一规范数据标准、监测数据质量、形成数据标准和链路的强管理  数据标准平台：定义数据标准，以文档形式呈现，在数据标准变更时反应到元数据系统中  元数据管理平台：包含数据字典和数据血缘关系两块 - 数据字典：包含数据结构和数据字段定义与数据标准的对应关系，对源头系统在开发和运维过程中形成管理 - 数据血缘：记录数据项在系统间的流转和使用情况，描述数据与数据的关联关系  数据质量管控平台：管理质量规则、生成质量报表、追踪质量问题、集成数据管理门户数据管控平台 6363| 数据质量提升的10大关键举措资料来源：联合小组分析 “做什么” “怎么做” 关键问题质量提升关键举措关键数据项 4大治理方法、 4大治理保障  全行数据分级管理，优先治理关键数据： - 建立数据重要性分级机制，梳理全行数据资产，区分关键和非关键数据 - 首批，可以从用例数据需求出发，优先治理~50个关键数据项  统一全行数据标准，建立元数据管理： - 数据治理中心发布全行数据标准规范和政策 - 数据管家参照标准规范定义关键数据项标准、口径，并完善元数据业务定义  定义黄金数据源，集中治理管控，简化数据架构  建立数据质量指标体系，健全数据问题治理机制  建立全行主数据的强管理，从客户主数据开始，逐个纳入  能力建设：建立数据治理培训体系，提供数据治理资质认证，  意愿调动：以数据质量和管控的指标体系作为考核依据，采取部门为主体的奖惩激励机制（参考B8考核激励部分设计）  工具部署：部署3大数据管理工具，包括：元数据、数据质量和数据标准管理系统（参考B工具和系统部分设计）  流程标准化：建立数据治理流程体系框架，优先详细界定7大关键流程（参考B8数据治理流程的设计） 2 3 4 5 7 8 9 6 10 “谁来做” 业务IT双轮驱动  建立全行治理体系，业务IT双轮驱动： - 建立由上至下、科技推动、业务负责的全行治理体系，包括：数据管理委员会、数据治理中心、以及业务的数据域/项管家 - 率先任命首批业务用例方的数据责任人和数据管家 1 6464| 定义数据治理7大关键流程，实现端到端管理标准化资料来源：小组分析数据治理的7大关键流程数据管控数据质量标准元数据 A D F G E B C 外部数据采购共享管理定义关键数据项管理重复和不一致的指标定义定义和更新黄金数据源外包数据服务采购流程数据标准制定和管理 R 主责 A 审批 I 告知 C 征求 S 协助/支持数据质量问题识别、分析和修复 10 6666| 目录 ▪ 数据质量现状回顾 ▪ 数据质量提升方案 ▪ 数据模型架构 – 定义和作用 – 参考实践和启示 – 建设现状 6767| 企业数据模型对业务概念和逻辑规则进行统一定义，为业务和技术人员提供一致的数据信息视图资料来源：小组分析企业级数据模型定义  企业数据模型EDM（Enterprise Data Model）是用实体、属性及其关系对企业运营和管理过程中涉及的所有业务概念和逻辑规则进行统一定义、命名和编码  反映业务对象及其之间的关系，为企业管理者、业务用户和技术人员提供一致的业务数据信息视图，是业务人员（数据消费者）和IT人员（数据生产者）之间进行沟通的一套统一语言  是集成的、面向主题的、稳定的、历史的、通用的、可扩展的  分为企业逻辑数据模型LDM（Logical Data Model）和物理数据模型PDM（Physical Data Model），此章节重点展开逻辑数据模型 6868| 企业数据模型分三个层面：主题域模型、概念视图、逻辑视图资料来源：、小组主题域模型逻辑视图（包括数据属性）应用逻辑数据模型应用物理数据模型 ▪ 12-20个业务实体。1个图表。每个主题领域的业务实体清单 ▪ 150-300个重要的业务实体及其关系迭代开发 ▪ 为实体增加的基本业务属性也是经过一段时间的迭代开发完成的企业级数据模型 ▪ 用由上至下的推动方法来制定目标数据蓝图并统一关键特性 ▪ 在完成工作的过程中业务部门参与以形成综合观点 ▪ 由应用决定的逻辑数据模型概念视图（不包括数据属性） 6969| 主题域模型将数据对象映射至拥有他们的相关业务领域资料来源：麦肯锡项目 ERP 产品合同/协议抵押品核心银行业务运营客户账户子分类账账户 CRM 风险 BI 资源规划收款支付账户建立风险事件条款及条件欧洲银行示例客户营销主题域概念逻辑 7070| 概念性视图对每个主题域进行展开并确定数据实体之间的主要关系资料来源：麦肯锡项目一对多的关系数据流 ERP 产品客户偏好经验的分析的人口特征关系(基本) 关系(高级) 营销市场营销风险收款监管外部运营报告银行组织合同/协议捆绑个人抵押品子分类账账户事件条款及条件客户账户欧洲银行示例主题域概念逻辑 7171| 逻辑视图提供在属性和关系方面所提供的细节具有更深的层次资料来源：麦肯锡项目欧洲银行示例主题域概念逻辑 7272| 数据模型和架构开发同步进行资料来源：麦肯锡举例: 服务和数据对象说明高层面的架构组件 … 全部整合到统一架构下明确各组件之间的关系细化各组件说明关键的数据标的建立概念数据模型建立逻辑数据模型 ▪ 数据对象与架构组件关联 ▪ 整合后数据对象及服务的完整视图（结合所有元信息的转化 ▪ 说明主要的数据对象并与集群关联 ▪ 说明数据对象并按照可操作，可交生对象加以归类 ▪ 进一步说明数据对象 ▪ 建立逻辑数据模型 ▪ 服务清单与Karinca组件进行对照 ▪ 全面说明各项服务 ▪ 各集群之间统一服务清单，并按照新的服务和反应时间加以延伸 ▪ 说明每个所提供并消费的集群服务 7373| 我们细化了数据模型的主要好处资料来源：麦肯锡未穷尽 … 以及数据模型如何起效数据模型作为关键推手的主要领域 … ▪ 引导IT开发的划分和关键重点▪ 架构开发 ▪ 提供所有数据资产概要，并与应用进行对比分析，以评估目标模式的风险并缓释风险 ▪ 网络安全评估及实施 ▪ 确保数据在整个架构中的使用一致，其覆盖/变更也是一致的 ▪ 数据一致性 ▪ 流程自动化 ▪ 发现事实来源，严格遵守总体数据标准，取消人工核对 ▪ 监管 (比如, BCBS239) ▪ 自动提供黄金来源的位置（权威来源） 7474| 关于企业级数据模型，我们已经梳理出常见的典型问题，并进行了回答资料来源：麦肯锡常见问题答案 ▪ 我们应如何处理工作流数据？ ▪ 工作流仅扮演系统间接口的角色 ▪ 我们是否应该忽略现有软件/应用系统？ ▪ 不应该，现有工具，可以帮助我们抽取数据模型，并管理其接口 ▪ 我们能否仅专注一种存储技术？ ▪ 不能，数据模式应可支持多种存储技术 ▪ 我们能否直接购买一个模型？ ▪ 不能，模型应根据您的需要定制 ▪ 我们是有应将数据模型开发与架构转型相结合？ ▪ 正解，这将有助于您改变物理硬件 7575| 数据模型开发往往与大规模IT转型相伴而行资料来源：麦肯锡客户示例细节土耳其一家大型银行 ▪ 数据模型开发作为整体架构转型的一部分，包含潜在存储方式的转变德国一家大型银行 ▪ 建立了风险及财务部门的数据模型，作为现有IT系统大规模升级以及数据仓库的一部分一家全球性银行 ▪ 建立了IT后台及支付运营的数据模型，作为大型业务转型中，IT系统重构的一部分 7676| 数据转型往往是“万里长征” 资料来源：麦肯锡定义逻辑数据模型 ▪ 定义并精益所有数据实体 ▪ 定义数据完整属性 ▪ 定义全部关系实体执行数据模型 ▪ 根据逻辑数据模型描述，执行所有数据实体 ▪ 在各数据系统间执行已定义的关系定义理念数据模型 ▪ 定义关键数据实体 ▪ 定义数据实体间的主要关系 ▪ 对关键数据实体的所有权及责任制达成一致 1 2 3 2个月 6个月大规模架构转型时间表（2- 5年）外部支持 7777| 目录 ▪ 数据质量现状回顾 ▪ 数据质量提升方案 ▪ 数据模型架构 – 定义和作用 – 参考实践和启示 – 建设现状 7878| 参考案例：某著名企业在构建企业级数据模型之前遇到了一系列的数据问题，如数据不一致、从采集到用户访问延时太长资料来源：参考案例图示主要问题 ▪ 数据冗余比较严重，难以保证数据一致性 ▪ 从数据采集到用户访问的延时太长 ▪ 整个解决方案层次太多，过于复杂。不同层次之间的数据传递都需要进行 ETL处理 ▪ 物理上分离的系统很多，设备投入和维护成本都比较高集中存储区 ODS 交某省市 7979| 参考案例：构建企业级数据模型后可以以最低的成本建立一致的信息视图资料来源：参考案例图示改进后的好处 ▪ 减少了数据冗余，建立一致的信息视图 (Single version of the truth) ▪ 简短了从数据采集到用户访问的延时 ▪ 业务应用灵活且可扩展，可适应日益增加的多类应用需求 ▪ 降低了拥有成本 (total cost of ownership) ▪ 系统容理操作型数据集中的企业级数据模型: 某省市 IT 用户业务用户详细的基础数据(按照第三范式存储) 数据汇总(小结表或视图) 数据转换与缓冲区 ETL处理 8080| 欧洲主要银行举例：众多数据方面的痛点促使银行在一个合适的契机建立了企业数据模型资料来源：麦肯锡项目痛点  不知道在哪些系统里有哪些数据，以及关键数据的黄金数据源在什么地方  对运用哪些数据在哪些分析没有具体的定位，比如： - 流动性风险的计算没有用到信用风险部门的现金流数据  严重的数据质量问题，包括数据的不一致性，比如客户序列号： - 某些系统没有客户序列号 - 其余系统的客户序列号格式不同  加强网络安全的需求建立了企业数据模型物理层次（存储在数据库系统和表格中）概念层次（数据实体和高阶关系）逻辑层次（属性和所有关系）当时银行正在经历一个大型的IT 转型，很多系统在被更新的过程中  合适的契机 8181| 欧洲主要银行举例：针对核心银行业务构建了详细的概念数据模型资料来源：麦肯锡项目客户与客户之间的关系客户零售客户公司客户安排事件子产品抵押品贷款承诺出资额合同定单阻止应用支付存款投资保险箱账户承销应计项目事件与客户之间的关系客户/ 客户与安排之间的关系安排与安排之间的关系事件与安排之间的关系时间详情更新时间详情查询产品现金流客户示例 8282| 欧洲主要银行举例：整个逻辑数据模型需要包括所有属性和关系 SAP Power Designer软件中的客户举例客户示例资料来源：麦肯锡项目 8383| 欧洲主要银行举例：逻辑数据模型中的每个数据实体均需要细化到属性层面客户客户ID 客户编号账户关系状态结束日期起始日期相关账户ID 安排的类型关系的类型账户Id Id 相关安排的类型事件事件ID 兑换代码汇率交换条款业务处理分支机构员工ID 分行ID 账簿账簿类型参考账户的外部索引账户编码 IBAN 账户Id 账户类型Id 其他关键词账号分支机构代码过期时间戳账户位置账户信息姓名关闭渠道关闭员工公开渠道打开员工状态打开日期结束日最后交开始日账户Id 产品Id 账户余额账户编码更新时间戳冻结金额授信额度贷方余额借方余额账簿编码账户Id 货币代码账户类型账户类型Id 账户类型描述账户期限信息账户Id 期初期末期限状态期限更新时间戳账户批量信息账户编码更新时间戳地址利率利率期末期初状态代码期间余额贷方余额借方余额账户Id 可用限额已到期休眠账户账户Id 转账状态余额账户活动客户关系 Id 客户ID 账户ID 类型起始日期结束日期昵称审批类型状态第一账户标记投资标记安排的类型事件代码账户Id 计数器索引计数器账簿类型计数器账簿计数器分支机构ID 客户Id 员工ID 业务处理分支机构发票编号发票分支机构客户说明系统描述交换条款汇率兑换代码货币代码我方所得余额所得余额金额索引参考客户代码计数器账户ID 起息日渠道代码打印机标记贷记/借记标记事件ID 原始交序列号柜员ID Id 时间戳客户示例资料来源：麦肯锡项目 8484| 欧洲主要银行举例：建立企业数据模型可以解决很多数据管控和系统上的痛点，但必须找到一个合适的契机开始项目资料来源：麦肯锡项目对的启示  企业数据模型为此银行解决了之前在数据管控和系统架构上的痛点，包括： - 明确了各个系统清晰的定位以及存有哪些数据 - 提升了数据的一致性和准确性  由于建立企业数据模型非常耗时耗资源，必须找到一个合适的契机（如大型系统转型期间）去建立  一个银行并不是绝对需要企业数据模型，但是在银行到一定规模的时候如果没有企业数据模型，很多数据管控上的问题和痛点必须通过手动解决，比如： - 衡量数据质量的时候（如地址信息）需要从所有存有地址的系统里提取地址信息，在如ODS这样的系统里合并物理表格 8585| 德国主要银行举例：概念数据模型包含主要的数据实体 [1] 业务合作方业务合作方的关系参考数据 §参考数据主数据 §业务合作方 [2] 业务数据主数据 §经营数据 §业务特征额外信息 §回购 §债券 §承诺出资额 §净额结算 §衍生品 §选择权 §其他特征 §事件条款 §兑付条件 §利息条件现金流 §现金流 Salden & Zeitreihen §Beträge §Sonstige Zeitreihen 对冲 [3] 安全性安全 §安全性的主数据 §对象安排的安全性 – 目标安排的安全性 – 业务 [5] 估值 – 相关信息 [6] 类别数据类别数据 §清洁数据 [7] 中心服务表格国家 §国家机构特定信息 §机构特定信息 [8] 交交易 §交易实体集团实体子实体 [5] 外部数据评级 §评级市场数据 §货币汇率 [4] 估值和结果业务成果 §业务成果合作方的结果 §合作方的结果安全性结果 §安全性结果业务/安全性的结果 §业务/安全性的结果合作方的结果 §合作方的结果股权的使用 §股权的使用风险分配客户示例资料来源：麦肯锡项目 8686| 德国主要银行举例：通过逻辑关系强化了实体模型 ……业务合作方的关系主数据业务合作方参考数据参考数据安全性安全 ……安排的安全性 – 业务安全性的主数据对象估值 – 相关信息会议会议市场数据货币汇率中心服务表格国家国家机构特定信息机构特定信息 1 1 1 1 n 1 1 1 1 1 m 1 n n 1 n1 1m 1 1 m n n 业务数据 ……安排的安全性 – 目标 1 1 1 1 1 n n 额外信息选择权事件会议承诺回购其他特征主数据经营数据业务特征数据现金流现金流 n 1 1 1 1 n 1 1 m n 时间和账户信息账户过往记录账户余额条件定价条件利率 …… 对冲 … 估值和结果合作方的结果合作方的结果业务成果业务成果 1 n 业务成果业务成果 n 业务/安全性的结果业务/安全性的结果安全性结果安全性结果股权的使用股权的使用风险分配 n n 类别数据类别数据 1 n 实体集团实体子实体客户示例资料来源：麦肯锡项目 8787| 德国专业性银行举例：完整的逻辑数据图可显示整个银行的复杂程度产品管理营销销售服务产品数据库 MMS 销售渠道企业站点 ATZ MMS 代理合并内容数据库销售管理销售数据的管理内网销售 B2B B2B Lux B2C B2C CH 数据仓库（DWH）条件模型（前端）投诉数据库条件贡献分析数据库市场信息分析数据库 ROLL-OVER 主某省市场数据银行的存款职能部门支付交易企业管理预期数据池（DDP）报告风险管控/合规财务业务处理物流人员资金 FO/MO贷款 IT/组织内审法律外部数据外部数据库讯财务数据数据库标普 SCD （Lupus） Xentis Multifonds Morning Star（晨星）主数据管理数据库市场数据库某省市场数据数据库利率风险管理前端数据库前端数据库前端数据库外汇风险管理前端数据库短期流动性管理 LQR长期流动资金管理前端数据库经济损益的银行账簿前端数据库政策储备基金登记管理和报告贷款 MKF 组合分析分析工具信用监督信用数据信息系统全局格式数据库工具工具工具工具数据库 ADD工具数据库对目标／项目的评价评级系统风险评估借款人文本（模板）贷款申请的编制文本（模板）二次表决文本（模板）贷款决策处理/服务档案文件案件归档 ERP采购数据库运货 Jobtracker岗位管理处理某省市（员工）人力资源数据库研讨会计划时间数据库研讨会管理时间配准 Aris流程管理架构管理系统架构管理集团项目管理项目管理电子化生产发布生产发布对网站过滤统计的评价统计审计 ACL 审计数据信息系统 FileNet Archiv Arche案件归档合规模块反洗基金价格的管控 Fondspreiskontrolle 现金管理数据库对账数据库凭证数据库存款头寸的对账存款数据库股份凭证业务数据库数据库存货数据库数据库收费模块投资的边际测试定价数据合规数据库合规数据库合规数据库合规数据库支付处理数据库数据库支付数据库数据库现金管理数据库往来数据库数据库数据库 WSS （Trema）链接数据库支付数据库支付数据库调查数据库 Incentage 支付执行账户的对账信息传送消息数据 Incentage 数据获取数据提供现金流、事件、合同数据、交、结果数据的获取质量保证、科目汇总、密匙生成、历史记录整理监管报告监管报告监管报告监管报告数据库中心数据管理编制报告数据的核算 /修正市场适当性市场风险地址风险流动性风险市价计值证券回购/贷款限额监控操作风险中心数据存储数据库数据库数据库数据库前端数据库（Risiko）数据库数据库数据库前端数据库前端数据库（风险）数据库针对风险的结果数据层级报告层级风险评估数据的核算/ 修正编制报告外包某省市场场外衍生品衍生产品（外汇）回购债券股份/基金外汇贷款成交结算衍生产品数据库前端数据库 BSP 后续BSP WSS （Trema）前端数据库 MSG Corona Conf. WSS (Trema) 后续Trema WSS （Trema）后续Trema MSG WSS （Trema）后续Trema FMP （Incentage）某著名企业-Alpheus 外币规划档案文件文件查看流动信贷的报告数据库数据库 Coupon 2000 衍生产品数据库前端数据库 BSP 后续BSP Martini （Apex） MSG 衍生产品数据库前端数据库 BSP 后续BSP MSG CCP 衍生产品数据库前端数据库 BSP 后续BSP MSG BSP 后续BSP衍生产品数据库 MSG 衍生产品数据库前端数据库 BSP 后续BSP Corona Cash CCP 信息的业务逻辑清算、结算企业行动组合管理监管通知材料规划单位信息传送控制数据库的管控 Plato Hyperion Hyperion SoPHiA 待定维持履行关系数据的核算、合并和汇总编制报告分类、菱形编队、规范阶段、推导、事件、结果分解、可行性LEG 场外衍生品衍生产品（外汇）回购债券股份/基金贷款某省市场外汇回购贷款前端数据库总账前端数据库总账 WSS （Trema） SAP BA AFI GuD SAP BA AFI Olympic SAP BA AFI WSS （Trema） SAP BA AFI Olympic SAP BA AFI 财务数据库资金管理工具资金管理工具数据库总账数据库总账前端数据库总账衍生产品数据库总账前端数据库总账 RDA 总账衍生产品数据库总账前端数据库总账衍生产品数据库总账数据库总账数据库总账 RWA 总账数据库总账数据库总账信贷数据库总账前端数据库总账数据库总账信贷数据库总账数据库总账数据库总账数据库总账信贷数据库总账数据库总账审计数据对账工具减值工具计算工具数据库价格交付 IAS计算器会计工具利润表编制工具利润表说明分析工具数据库报告控制图例经验在先者承继者目标中包含的应用程序待检测的应用程序待插入的应用程序关闭应用程序尚未检查的应用程序从属应用程序（数据流）应计利息、外汇结果核算、历史记录整理、实际利率的核算/摊销、对冲交算、入账（IFRS、HGB）、存货的形成找出财务报表科目、余额法、HB入账生成 HB存货管理、期末处理、外汇折算、支付处理、入账（IFRS/HGB）编制资产负债表（IFRS/HGB）、利润表（IFRS/HGB）、附注（IFRS/HGB）、银行资产负债表、结果报告、标准报告（IFRS/HGB） AMI 发行和存款业务 FO/MO 基金会计核算报告交库投资者支持资金管理采购投资支持租赁目标的开发/构建措施销售股份价格核算外部管理基金规划租金的会计处理目标的规划/报告会计处理/报告/登记专家支持技术目标的支持某省市财产风险销售工具 FileNet Deka Immo 不动产风险某省市交库 Argo.网站交库某省市交库交库某省市交库某省市通知义务搬迁地址数据库销售渠道数据库奖励养老金订单引擎资金管理数据库支付数据库数据库数据库报告数据仓库短信单证存款服务存款业务的监管/管理存款报告档案文件存货的对账发票管控N计算账簿记录履约费主数据、金融衍生产品 FPR IFRS 数据库驱动 DWH BO 数据仓库数据库数据库单项报告数据仓库巴塞尔 II 资产净值（N）的公布基金报告报告基金报告数据库的管控基金（包括基金的基金）资产管理档案文件报告组合管理订单登记订单管理对账合规数据库事后审查数据库事前审查资产经理对账现金对账顾问对账资产经理数据库研究数据研究数据库数据库订单工具分析工具财务规划数据库数据库资产经理贸库数据的管控风险衡量指标数据库数据库基金/风险的管控数据库数据库资产经理资产经理数据库加载器数据库TA注册资产经理资产经理 FO/MO贸易 MM（包括现金担保品）场外衍生品衍生产品（外汇）股份/基金债券回购外汇贷款路透数据库数据库回购数据库前端数据库讯前端数据库风险管理体系数据库风险管理体系前端数据库风险管理体系数据库风险管理体系数据库数据库基于Web的交程序数据库数据库前端数据库前端数据库前端数据库讯前端数据库前端数据库信贷信贷前端数据库前端数据库前端数据库前端数据库讯前端数据库信贷前端数据库前端数据库前端数据库前端数据库讯前端数据库信贷前端数据库前端数据库前端数据库前端数据库讯前端数据库前端数据库前端数据库前端数据库前端数据库（BWA）前端数据库前端数据库前端数据库前端数据库数据库前端数据库数据库数据仓库数据仓库风险数据库档案文件档案文件风险数据库档案文件档案文件限额系统限额系统前端数据库后续数据库前端数据库后续数据库 LQR 订单自动执行报告指数数据库交订单引擎交易交 HA评估执行/组合管理现金处理 HU评估抵押品市场风险核算市场风险/呈现信用风险的核算评估限额监控外汇风险管理短期流动性风险流动性风险主数据管理票据主数据基金主数据地址主数据数据仓库档案文件 Liquidity DWJ 数据库数据库数据库档案文件流动性数据库风险数据计算工具数据库计算工具计算工具信贷数据风险数据合同管理合同和的管理作业数据库作业的组织事实集合绩效工具绩效数据库数据库订单工具惯常的柜面审查买卖盘传递贸讯数据库数据库数据库衍生品数据库资产经理资产经理资产经理财务数据库财务数据库限额系统限额系统限额系统限额系统限额系统前端数据库WSS （Trema）数据仓库数据仓库客户示例资料来源：麦肯锡项目 8888| 目录 ▪ 数据质量现状回顾 ▪ 数据质量提升方案 ▪ 数据模型架构 – 定义和作用 – 参考实践和启示 – 建设现状 8989| 目前数据仓库模型已经按照企业级数据模型的设计思路进行建设资料来源：小组分析未来改进点 ▪ 建立管理机制，需要全行明确企业数据模型的战略定位、组织架构、建设流程、建设工具等 ▪ 模型需要各条线业务模型做指导，提升业务逻辑有效性和覆盖度 ▪ 需要结合业务用例来验证数据覆盖度、分布合理性、关联有效性、等现有成果 ▪ 按照数据管理知识体系建立了层次模型，包括主题域模型、概念视图模型、逻辑试图模型 ▪ 制定了统一的建设规范 ▪ 运用统一建模工具，如ERWIN、ADMS 9090| 结合业界标杆做法，并根据自身具体需求、数据的定位、来源、用途、组成分层搭建其逻辑数据模型架构资料来源：小组分析定义某省市层 ▪ 面向特定应用主题，支持有特定范围的业务分析与决策，如风险管理、财务管理等 ▪ 大量的非规范化处理公共汇总层 ▪ 基于基础层模型，搭建支持全行所有应用的共性汇总层 ▪ 跨业务条线集中汇总，不面向某特定应用基础模型层 ▪ 整合我行所有运营与管理数据，按照面向业务主题的方式组织数据，通过实体及关系反映业务逻辑 ▪ 历史的、详细的、范式化数据 A B C 9191| 的基础层数据模型包括11大主题、~230个概念视图实体和6000多个逻辑视图模型资料来源：小组分析主题域模型概念视图模型逻辑视图模型 A1 A2 A3 ▪ 将全行业务数据提炼为十一大主题，如当事人、资产、财务、协议等 ▪ 的概念视图模型具有~230个实体，如个人客户、对公客户等 ▪ 的逻辑视图模型具有6000多个实体，如个人客户、当事人关系种类代码等 A 9292| 主题域模型包括客户、产品等十一大主题域资料来源：小组分析图示具体描述事件协议渠道当事人资产财务地址营销活动机构申请产品 ▪ 将全行所关心的分析领域对象数据进行抽象，实现完整、一致的描述，并准确刻画各对象之间的关系 ▪ 将我行运营与管理重要数据进行分析与整合，提炼出覆盖所有业务逻辑的十一大主题 ▪ 每个主题反应特定的业务概念，并按照主题特性进行分类 ▪ 主题间不同的关系反应不同的业务逻辑规则，如一个客户拥有一个或多个帐户、一个帐户可能和一个或多个当事人有关、一个帐户可能与一个或多个交易／事件相关等 A1 9393| 十一大主题域的详细描述资料来源：小组分析主题域名称详细描述当事人指银行作为一个金融机构所服务的任意对象和感兴趣进行分析的各种个人或团体客户、潜在客户、代理机构、雇员等，一个PARTY可以同时是这当中角色产品金融机构销售或提某省市场化的产品、产品包和服务，可以包括竞争对象所提供的产品财务通常指银行各类账务信息，如科目总账协议是金融机构与客户之间针对某种特定产品或服务而签立的契约关系。例如银行的帐户，保险公司的保单等申请指客户在我行的各类申请信息，包括贷款申请、信用卡申请、信用证申请等渠道用户通过渠道向金融机构获取关金融机构或金融机构产品信息以及使用金融产品。金融机构通过渠道向用户销售产品或提供服务事件事件是银行与客户或潜在客户之间的联系或交，它记录了详细的行为和交，包括存取款、收费、计息、咨询投诉、某省市场调查、网上交营销活动营销活动是为了获取、维护、增强银行与客户的关系而开展的一些有组织的活动，的可以是为了把某些产某省市场，也有可能是为了树立某省市场上的形象机构是指金融机构的组织和业务单元，如分行、支行、储蓄所、部门、销售团队等等资产指客户所拥有的各类资产信息，包括在行内做抵质押资产和其它资产地址银行希望关注或考察的任何层次的地理区域和地址，如某省市某省市、县、乡村等，包含“具体地址”、“地区”、“地理位置”等不同层次的信息 A1 9494| 概念视图模型举例：“当事人”主题的展开资料来源：小组分析示例 – “当事人”展开具体描述 ▪ 将每个主题域进行概念分解，得到概念视图模型，是业务重点相关的主题与内可视的、高阶的视角 ▪ 业务实体是每个概念模型的主要组成部分，是熟悉并感兴趣的事物、人员、事件、地点等概念和类别，概念视图模型仅包括基础的和关键的业务实体及其关系，如当事人概念视图包含个人客户、对公客户和虚拟客户的类别实体；当事人积分历史、当事人评分评级历史、当事人财务报表、当事人风险资本计量等重要特性实体；及协议当事人关系历史等与其它主题概念实体之间的关联实体 ▪ 实体间关系种类分为一对一、一对多和多对多关系 ▪ 我行概念视图模型共有~230个业务实体 A2 9595| 逻辑视图模型举例：“当事人”主题的展开资料来源：小组分析示例具体描述 ▪ 逻辑视图模型是数据需求和控制数据质量的业务规则的详细描述 ▪ 是对概念视图模型的进一步拓展和分解，通常采用范式化和抽象化两种技术实现从概念视图模型向逻辑视图模型的转化，转化的结果是： 1）定义实体的主键；2）将数据属性添加到每个实体中； 3）定义属性取值的完整集合即域 ▪ 我行定义逻辑模型实体数量共计6000余个 ▪ 逻辑视图模型构建不是一蹴而就的，需经过不断的迭代开发和完善 A3 9696| 公共汇总层对基础数据进行两次汇总资料来源：小组分析图示存款账户卡贷款借据协议机构产品渠道票据 … 客户交易第一级汇总第二级汇总具体描述 ▪ 支持全行所有应用的共性汇总层，针对常用的统计汇总口径加工进行统一的轻度汇总，作为更有针对性的二次数据加工整理的基础 ▪ 按照不同汇总粒度进行聚合，由细至粗分二级汇总： – 第一级：协议级汇总，包括存款协议级汇总、零售贷款协议级汇总、对公表内业务明细、承兑汇票协议级汇总 – 第二级：产品级、客户级、机构级、渠道级、交，其来源以协议级汇总为主 B 9797| 根据前端应用系统取数需求在某省市层建立某省市资料来源：小组分析图示具体描述  面向特定应用主题或部门  针对特殊设计目标的业务分析与决策，在分析、内容、表现等方面服务于专业用户群体的特殊需求  具有性、可用性、灵活性、可控性特点  通常采用星型结构（一个事实表和多个维表）  包括详细数据和汇总数据  支持我行各类应用分析 C 某省市层支持应用对公CRM应用某省市营销应用高级分析　客户价值某省市营销应用高级分析分析报表风险应用某省市风险应用高级分析分析报表头寸应用某省市决策支持　分析报表人行报送EAST某省市监管报送　　经济资本应用某省市风险应用　　零售分析应用某省市高级分析高级分析分析报表零售信用卡交叉销售某省市营销应用高级分析分析报表小区金融某省市营销应用高级分析分析报表数据挖掘某省市沙盒应用高级分析　通用指标某省市决策支持　　考核应用某省市考核应用　分析报表财务某省市财务应用高级分析分析报表分行某省市　　分析报表