某银行数据治理以及平台建设概述.pptx

上传人:wj 文档编号:13411214 上传时间:2023-06-13 格式:PPTX 页数:87 大小:3.66MB
下载 相关 举报
某银行数据治理以及平台建设概述.pptx_第1页
第1页 / 共87页
某银行数据治理以及平台建设概述.pptx_第2页
第2页 / 共87页
某银行数据治理以及平台建设概述.pptx_第3页
第3页 / 共87页
某银行数据治理以及平台建设概述.pptx_第4页
第4页 / 共87页
某银行数据治理以及平台建设概述.pptx_第5页
第5页 / 共87页
某银行数据治理以及平台建设概述.pptx_第6页
第6页 / 共87页
某银行数据治理以及平台建设概述.pptx_第7页
第7页 / 共87页
某银行数据治理以及平台建设概述.pptx_第8页
第8页 / 共87页
某银行数据治理以及平台建设概述.pptx_第9页
第9页 / 共87页
某银行数据治理以及平台建设概述.pptx_第10页
第10页 / 共87页
某银行数据治理以及平台建设概述.pptx_第11页
第11页 / 共87页
某银行数据治理以及平台建设概述.pptx_第12页
第12页 / 共87页
某银行数据治理以及平台建设概述.pptx_第13页
第13页 / 共87页
某银行数据治理以及平台建设概述.pptx_第14页
第14页 / 共87页
某银行数据治理以及平台建设概述.pptx_第15页
第15页 / 共87页
某银行数据治理以及平台建设概述.pptx_第16页
第16页 / 共87页
某银行数据治理以及平台建设概述.pptx_第17页
第17页 / 共87页
某银行数据治理以及平台建设概述.pptx_第18页
第18页 / 共87页
某银行数据治理以及平台建设概述.pptx_第19页
第19页 / 共87页
某银行数据治理以及平台建设概述.pptx_第20页
第20页 / 共87页
亲,该文档总共87页,到这儿已超出免费预览范围,如果喜欢就下载吧!
下载资源
资源描述

某银行数据治理以及平台建设概述.pptx

《某银行数据治理以及平台建设概述.pptx》由会员分享,可在线阅读,更多相关《某银行数据治理以及平台建设概述.pptx(87页珍藏版)》请在冰点文库上搜索。

某银行数据治理以及平台建设概述.pptx

,银行数据治理及平台建设经验交流讨论,目录,数据治理概述,某行数据现状及问题,数据治理阶段目标,成效和特点,数据管理系统建设情况,第一部分,数据治理意义、作用和价值,数据战略,数据应用与服务,数据管理,保障机制,促进,支撑,实现,支撑,数据战略与规划,数据组织与职责,数据制度与管理流程,数据服务管理,数据需求管理,应用系统建设,数据服务,数据架构与模型管理,数据标准管理,数据质量管理,元数据管理,主数据管理,数据保留与归档管理,数据安全管理,内容管理,数据治理框架,数据调度与处理,大数据平台,数据结构化转换,大数据分析计算,分布式数据库,分布式文件系统,数据生命周期管理,数据平台,数据传输,数据服务,数据集市,数据质量检核,元数据管理,数据管理平台,数据应用,统计报表,基础数据平台,贴源层,整合层,汇总层,数据切分,数据源,业务系统,物联网,互联网,数据交换平台,内部数据,外部数据,其他系统,数据接口,数据架构,数据挖掘,高管驾驶舱,一、应用(需求)驱动主导数据平台的实现,加强业务的关注和参与,二、初期能够快速见效并体现建设价值,不盲目投入,三、借鉴同业的成功经验和成果,选择成熟技术架构和解决方案,四、重视内部人员培养,建设配套运营制度和管理体系,应用是展现数据总线建设效果的门户,因此需要建设业务人员最紧迫和最关注的需求和应用,让业务部门最快参与数据总线的建设当中。

实施周期不易过长,规模不易过大,能够快速的见到数据总线带来的效果和价值。

尽量参考同行业、同规模、同类型企业行的建设经验,适当创新。

前期让公司内IT人员尽量更多、更深入的参与到数据总线的建设中,后期角色以管理为主,尽量与合作伙伴共同建设二期以上。

配套的管理规范、技术规范、运营体系。

数据平台建设原则,第二部分,数据应用现状分析-总体情况,行领导,?

综合业务系统,信贷管理,国际业务系统,债券管理系统,数据交换平台,综合报表平台,财务会计部,信贷管理部,国际业务部,资金计划部,.,业务职能不清晰或相互重叠,观察数据视角不尽相同,缺少数据标准与业务统一定义,语轨不一致,IT架构中中都是以部门级应用为主(如计财、资金计划部等),缺乏从大的管理职能(财务、风险、运营等)综合方面的数据整合、数据标准和统一业务定义,缺乏数据梳理,造成行领导看到的数据相互冲突和矛盾,由于业务系统输入的随意性,导致部分关键业务数据质量较差,业务人员,X?

567,数据应用现状分析-数据架构方面,由于全行的数据散落在各个业务系统中,没有进行有效整合,形成竖井式架构,造成多个信息孤岛,整体架构缺少一个稳定的、抗源变化的保存最细粒度历史数据的数据层。

无法支撑未来共享性应用。

集市层,客户风险,客户一部,中间业务,汇总数据层,主题层,报表应用共用主题数据,客户风险报表,客户一部报表,中间业务报表,支付报表,支付业务,ODS层,DEP层,BDS层,其它报表,业务表现信息孤岛数据冗余共享性差历史数据缺失问题数据分散,难以管理没有一个稳定的,抗源变化的数据层,综合业务,信贷管理,国际结算,债券核算,源系统,竖井式架构,造成信息孤岛,缺少一个稳定的、抗源变化的数据层,客户管理,绩效考核,没有进行整合,无法共享,不能支持如客户管理等共享性应用,数据应用现状分析-数据应用难题,业务表现各集市系统指标存在重复各集市系统在保有存量的同时,不断产生新的指标(增量)集市指标派生无法实现指标逻辑视图(指标分类)不一致问题重复投入数据不一致指标设计、口径不一致指标难以共享,客户风险集市,客户一部集市,资金计划部,借据号,期末余额,。

借据编号,期末贷款余额,总资产,用户,我想看本期贷款余额,看哪个呢?

主营业务收入,负债总额,活期存款流水采集单,G21流动性期限缺口统计表,。

我想看客户经营情况信息,有哪些呢?

用户,活期存款指标数据怎么不一致呢?

活期存款,缺少统一的应用分析标准,数据应用现状分析-数据应用难题,业务表现各系统存在冗余数据各系统存在业务含义一致,名称定义不一致的属性各系统存在含义不一致,名称定义一致的情况业务代码定义混乱问题重复投入数据不一致、不准确难以利用和管理各系统数据难以共享,缺少统一的基础数据标准,核心贷款分户账表,贷款主档代码,贷款余额,。

五级分类标志,计息方式,信贷管理借据表,贷款账号,贷款余额,。

5级分类标志,借据计息周期,业务含义一致,名称定义不一致,数据冗余,相同业务代码定义不一致,数据应用现状分析-数据质量方面,没有归纳并总结数据质量问题,缺少反馈机制,导致长期存在各类数据质量问题。

业务表现指标难以共享数据不一致、不准确问题部分关键业务数据缺失源系统校验关系缺失及业务人员操作随意,13,非现场监管报表,统计各省分支机构每笔借据的五级分类,信贷管理源系统操作错误,贷款质量五级分类情况简表,信贷管理客户表,核心客户表,由于信贷管理系统业务人员没有填写或填写错误借据的五级分类信息,导致报表数据不准确,需要手工补录修改,不同系统相同客户号对应的客户简称不一致,数据应用现状分析-总结,随着业务的不断发展和信息化的不断深入,需建设的业务系统越来越多,随着业务系统的数据种类不断丰富完善,数据量的不断增大,如果不采取有效手段解决数据架构、数据标准、数据质量问题,随着信息化建设的深入,这些问题将像雪球一样越滚越大,越积越多。

第三部分,数据平台逻辑架构,数据调度与处理,元数据管理,数据传输,数据生命周期管理,非现场报表,财会报表,客户风险报表,.,机构客户账户.,非现场监管集市财会报表集市风险报表集市高管驾驶舱集市.,数据仓库,源数据,数据应用,贴源层,整合层,汇总层,集市层,数据管理系统,综合业务系统,CM2006,国际结算系统,债券管理系统,ETL,ETL,数据切分,作业调度,作业调度,作业调度,ETL,CBS,CM2006,EE,BOND,PE,FES,MCS,数据平台部署架构,数据平台项目建设目标,目标建设方法-发现数据质量问题,建设内容,分析源系统表数据,从及时性、完整性、准确性、有效性、一致性方面对源系统数据进行数据校验,发现并记录数据质量问题,生成数据质量问题报告,建设数据质量检核系统,对源系统基础业务数据的进行全面的数据质量检查,并实现重要业务数据质量的周期性动态检查,对发现的数据质量问题生成数据质量报告,反馈给业务部门,目标建设方法-发现数据质量问题,源系统分析阶段,全面分析主要源业务系统,数据质量问题检查阶段,根据制定的检查规则编写程序,对源系统数据进行检查,数据质量问题分析阶段,分析有质量问题数据对现有应用的影响;提出解决措施,1,2,3,工作阶段,源系统分析阶段,产出物,源系统表结构,包括主键、外键、唯一性约束源系统表间关系源系统字段长度和类型,数据质量检查阶段,数据质量分析阶段,数据质量反馈系统概述,建设目标,对业务数据进行数据质量检核,准确掌握业务系统各种数据质量问题,促进基础业务数据质量的提高,建设内容,质量检查规则定制实现质量检查规则的灵活定制数据质量检查系统按照预定义的数据质量检查规则,对数据的准确性、有效性、关联性、一致性、及时性进行检查,生成并保存的数据质量检查信息。

数据质量分析报告生成不同类型的数据质量检查报表,对不同的数据质量问题进行分析和展示,架构和功能,系统架构,数据质量检核与反馈系统,检核对象管理导入、查询、修改、删除检查对象,检核规则管理新增、删除、修改检核规则,检查频度管理制定检查周期和时间,权限管理,用户建立,权限管理,问题报告问题查询规则查询打包下载.,问题管理维护并管理发现的数据质量问题,日志查询,报告管理,系统功能,调度管理,整合层,汇总层,集市层,贴源层,数据质量检查及反馈系统界面,数据质量管理建议,通过逐套的解决报表数据质量问题,以数据标准为依据,来切实解决基层手工修改报表的问题,源头负责制,谁录入谁修改,操作层面,数据纠错,管理层面,形成数据质量管理的机制:

发现问题,定位问题,解决问题的管理流程,IT系统建设层面,将数据质量问题检查规则固化到系统中,形成数据质量台账,为解决数据质量问题和考核提供依据,数据平台项目建设目标,数据标准梳理及归纳,基础数据标准,指标数据标准,数据标准梳理及归纳,对我行日常业务开展过程中所产生基础性数据,从业务方面、技术方面、管理三个方面,对数据的业务表达、数据格式、数据关系等方面进行一致约定,从而规范数据在全行内外共享和使用中的一致性和准确性,对数据的管理、应用过程进行统一和规范,明确数据的定义、格式、规则以及数据与数据间的关系为系统开发实施提供全行统一的规范准则为数据加工和应用提供统一来源和依据,作用,定义,定义,通过对我行经营管理资料的分析,并参考同业的类似成果以及监管部门要求,梳理和筛选出直接反映我行业务经营管理状态的重要指标,并对指标的业务含义、业务规则、统计口径等内容进行标准化定义,形成全行一致的指标数据标准,作用,统一全行对各项经营指标的理解和认识,促进各项经营指标在经营管理决策中的运用;统一全行指标标准的业务含义、计算口径等内容,从而解决我行取数口径不一致、业务含义不清晰、指标分类不清晰的情况,促进部门间数据共享,目标建设方法-数据标准解决的问题,数据孤岛数据质量,制定了全行统一的标准,实现了业务数据信息统一定义,统一命名、统一来源,对于数据质量造成的数据准确性、一致性等问题,找出造成这些问题的原因,违背业务和约束的数据不进入标准体系中,举例,例如:

在标准制定过程当中,对于业务数据之间关联不上的问题,首先要找出关联不上的原因,之后通过和业务人员的有效沟通,制定出以哪一类数据为准的标准,比如信贷管理系统的贷款余额和核心系统的贷款余额不一致,在制定“协议金额”标准的过程当中,必须明确以那个系统的贷款余额为准,且以此贷款余额制定全行标准,从而解决此类问题。

例如:

不同部门的贷款余额由于取数来源不同而造成差异,通过建立完整的分析数据标准体系后,统一了业务定义和取数口径,有利于全行范围内重复利用,杜绝出现各业务部门多次重复定义类似的指标,并且因为标准的权威性和标准的严格管理,有效防止指标定义和口径的二义性。

目标建设方法-数据标准-建设步骤,基础数据标准,指标数据标准,分析数据标准发布执行,标准映射,数据源和基础标准数据映射,数据源和分析标准数据映射,标准执行,标准定义,数据标准,基础数据标准发布执行,业务定义、业务规则、业务含义、计算口径,业务含义、业务规则、业务描述、数据来源,目标建设方法-数据标准-建设内容,目前存在问题业务访谈系统调研结合最佳实践分析、诊断,形成标准化定义初稿和框架对定义初稿征求意见和讨论根据意见反馈和讨论结果和修正并形成数据标准,确定映射的系统范围制定源系统与标准的映射规则根据数据验证映射规则,提出标准在未来各影响面执行的遵循原则就标准与现状的实际差异给出具体的执行建议,目标建设方法-数据标准-基础数据标准调研,调研分析,业务字段,源业务系统,分析调研记录,实体属性,模型匹配整合,1、名称不同,业务含义相同,2、名称相同,业务相同,3、名称相同,业务含义不相同,目标建设方法-数据标准-基础数据标准框架梳理,基础数据标准框架梳理,参考补充,分析调研记录,标准分类,标准主题,参考:

1、同业标准体系框架2、TD模型的结构与分类,目标建设方法-数据标准-基础数据标准定义及确认,标准分类,标准中文名称,标准信息类,业务规则,业务描述,数据类型,长度,标准依据,相关标准,标准英文名称,业务含义,源系统,标准管理部门,数据格式,技术人员,业务人员,沟通.确认,基础数据标准化方案,目标建设方法-基础标准-制定框架,基础数据标准框架属性参考人民银行标准规范文档和他行标准,由3部分22个属性项组成,分别为业务属性、技术属性、管理属性。

目标建设方法-基础标准-指标标准建设思路,目标建设方法-基础标准-指标标准筛选方法,经营管理资料:

行领导讲话我行各业务部门的业务经营分析报告我行的各类管理报表筛选原则:

反映我行规模、风险、盈利、业务增长等各方面业务状况的典型指标口径稳定不易变化的指标,外部资料:

同业相关建设资料城商行银行国有银行建设银行人民银行、银监会监管指标要求筛选原则:

监管部门有强制监管要求的指标同业用到,与我行业务有关的指标,筛选、确认方式:

项目组内部讨论筛选外部需求调研,进行补充和确认,目标建设方法-基础标准-指标标准框架制定方法,设计依据:

指标的业务共性的归纳及提炼参考行内资料我行业务分类源业务系统操作手册及业务简介文档统计集中系统指标分类参考外部资料监管部门的管指标及指标分同业相关资料的指标分类设计原则分类体系覆盖筛选出的所有业务指标,并能为每个指标确定唯一的分类易于根据业务和指标变化进行扩展,设计依据:

人民银行JRT0105-2014银行数据标准定义规范外部资料设计原则:

可以从业务、技术、管理不同角度对标准进行全面定义对指标标准必须清晰、明确满足未来对满足标准进行管理的需要,目标建设方法-基础标准-指标数据标准框架,指标数据标准框架,业务属性,技术属性,管理属性,指标中文名称,指标英文名称,指标范围类别,计算公式,业务规则,相关指标标准,是否手工录入,显示精度,指标落地系统,数据来源系统,数据源表,数据格式,度量单位,取值范围,归口业务部门,业务负责人,技术负责人,反馈结果描述,指标编码,指标别名,指标定义,指标大类,指标小类,指标来源,口径明细,取数口径,相关基础类数据标准,指标生成频度,取值精度,指标应用-高管驾驶舱,从经营概况到具体指标分析,今日快报全行7项核心业务指标的展现和分析最重要3项监管指标进行展现和分析,指标总览按分类展现全部指标的本期值及与往期的比较值的列表,经营概览对某一具体指标进行比较、结构、趋势等方面的分析,专项分析从业务角度对一组反映类似业务的指标进行分析,热点地图显示全国地图,可以展示各一级分行重要的经营简报数据,我的指标,规模分析,利润分析,风险分析,主驾驶舱选取13个行领导重点关注的指标展示,我的指标根据用户对指标的重视程度,实现指标的个性化定制,功能简介,指标应用-高管驾驶舱-界面截图,数据平台项目建设目标,数据仓库层次架构,主题,逻辑视图,实体,属性,共性提炼分类分层,数据仓库层次架构,风险评级,内部机构,对公客户,对公客户信息,对公客户管理信息,不良贷款信息,对公客户领导信息,对公客户资本金构成,财务信息,机构信息,数据仓库模型设计方法,模型映射,目标的建设方法-数据仓库模型框架,整合层模型设计-基础模型(业务匹配)基础模型是TD模型在我行进行初步客户化后的产物。

将TD模型的主题和实体,与我行的实际业务行的实际业务进行对比分析,根据匹配结果对TD模型进行裁剪、合并和扩充,形成匹配我行实际业务的情况的模型框架。

营销主题,当事人主题,Teradata金融模型10.0,当事人资产主题,产品主题,事件主题,协议主题,地址主题,渠道主题,内部组织主题,财务主题,基础模型,我行无关业务,我行现有关务,我行未来关务,我行现有业务,我行无关业务,我行未来业务,对公客户,合同,机构,个人业务,营销活动,保险投资,合并,当事人主题,当事人主题,保留,内部组织主题,营销主题,保留,增加,代码主题,数据质量反馈,业务匹配,目标的建设方法-数据仓库模型框架,整合层模型设计-属性匹配对源业务系统的字段进行梳理分析,筛选出具体业务价格的字段,将业务字段与基础模型的主题、实体和属性进行匹配分析,根据匹配结果对基础模型的实体、属性进行增删。

实体属性,基础模型,源业务系统,业务字段,分析匹配,?

新增属性,实体属性,保留(整合)并映射,新增并映射,?

未来业务相关则逻辑化保留,未来业务无关则删除,数据仓库模型,逻辑模型设计-主题划分,当事人,逻辑模型设计-当事人主题,当事人是一个独立的人或者一组人组成的机构、团体等,主要分为个人、机构和家庭,他们是和我行有往来或者出于营销、管理等各种需要希望关心和分析的个体或人群。

从模型角度考虑,应该包括以下当事人信息:

在我行登记注册开立账户的对公普通客户;我行担保客户和我行有业务往来的其他金融机构;机构的内部组织(如分支机构、部门等);机构的员工(含我行柜员、员工等);,协议,地址,产品,当事人,渠道,反馈域,财务,事件,当事人资产,代码,逻辑模型,逻辑模型设计-代码主题,代码:

是指将源业务系统所涉及到的所有代码进行整合,在整合层模型中统一存储,依据前端应用需求的需要,将代码主题的整合分为两大类:

简单代码表和复杂代码表,简单代码表指的是只需要关注代码值和代码值业务含义描述;复杂代码表指的应用需求除关注代码值和代码值业务含义描述外,该代码表的其他属性也有应用需求,同样需要关注,这样的码表将作为普通的数据表对待;自定义代码,是属于简单码表的一种。

公共类代码表,协议类代码表,分类模式编码表,协议,地址,产品,当事人,渠道,反馈域,财务,事件,当事人资产,代码,逻辑模型,逻辑模型设计-协议主题,协议,地址,产品,当事人,渠道,反馈域,财务,事件,当事人资产,代码,协议是指金融机构与当事人之间针对某种特定产品或服务而签立的契约关系,如账户、客户和银行签订的合同等。

当金融机构与客户之间针对某种产品或服务的条款和条件达成协议时,一个协议(Agreement)就会被开立,因此协议是客户和银行往来的重要载体,我行模型包括以下协议信息:

我行涉及金额、期限、利率等的具体协议细项的金融账户我行与当事人之间针对某种特定产品或服务而签立的金融合约我行在支付结算业务中使用到的各种银行票据:

汇票,逻辑模型,抵质押合同,贷款借据,项目额度申请,贷款申请,项目贷款,贷款合同,抵质押合同押品信息,借据还款计划,逻辑模型设计-事件主题,事件:

可以记录各种与银行相关的活动的详细情况。

既可以与资金相关,也可以与资金无关;既可以有客户参与,也可以没有客户参与;既可以与帐户相关,也可以与帐户无关;可以由客户发起,也可以由银行发起。

总之它可以记录的范围非常广泛,包括交易数据,比如存款、提款、付款、收取信用卡年费、计算利息和费用、投诉、查询产品、查询地址、查询余额、网上交易等。

我行模型包括以下事件信息:

存款信息、贷款信息;库存管理、现金管理、账户管理、资产管理;资金调拨、支付结算、现代化支付;报文清算、国际业务;外汇、票据、市场交易、十二级分类、核心账务。

商品棉贷款信息采集,粮油库存核查,同业定期存款汇入,同业定期存款汇出,新棉收购进度采集,棉花农资库存变动,协议,地址,产品,当事人,渠道,反馈域,财务,事件,当事人资产,代码,逻辑模型,逻辑模型设计-财务主题,财务:

主要包括银行的总账信息,是描述科目组织、控制、内部核算等银行核心科目账务以及预算管理有关的内容。

该主题抽象地描述了银行内部账务的组织模式,能够适应不同的科目组织体系。

我行模型包括以下财务信息:

总账(分户)总账明细科目/科目组/科目类:

对于科目的层次级别设置和管理财务预算,总账日旬余额,总账月余额,协议,地址,产品,当事人,渠道,反馈域,财务,事件,当事人资产,代码,逻辑模型,逻辑模型设计-当事人资产主题,当事人资产:

描述当事人的所有资产,该主题包含两大类的资产,既包含我行自有资产又包含客户所拥有的资产。

一个资产可以被多个当事人所拥有,一个当事人可以与多个资产有关。

资产可分为实物资产、金融资产与无形资产。

客户资产信息的来源很多情况下是在客户申请贷款时所提供的各种担保品信息、抵质押品信息等。

我行模型包括以下资产信息:

银行自有资产,具体又细分为:

银行自有无形资产、固定资产、经营性租赁资产、其他资产等;客户自有资产,具体又细分为:

客户抵债资产、客户担保资产、金融资产、实物资产、无形资产等。

客户担保资产,金融资产,客户抵债资产,实物资产,抵质资产房产信息,交通运输设备,协议,地址,产品,当事人,渠道,反馈域,财务,事件,当事人资产,代码,逻辑模型,数据映射和ETL开发,源表,映射文件,目标表,开发规范,合并,拆分,复制,ETL,业务含义不同,名称相同,进行拆分,业务含义相同、名称不同,进行合并业务含义相同、名称相同,进行合并,转换,生成新键值代码值转换数据类型转换值域转换值转换,ETL开发人员按照映射文件中规定的映射逻辑要求,结合开发规范,编写作业,通过数据源分析,制定加载策略,开发JOB调度,直接拷贝,加载策略,数据源分析,常量,赋固定值,1,表间关联/单表操作(LeftJoin,InnerJoin,FullJoin,Union),映射文件,通过映射文件,确定表间关系,数据映射和ETL开发,定义源:

配置作业源表的表名、表结构等信息创建映射:

根据作业详细设计中表与表之间及字段之间的映射关系,使用相应的组件实现其数据转换逻辑定义目标:

配置作业目标表的表名、表结构、加载方式等信息,定义源,创建映射,定义目标,项目提交物(总共108项交付文档),目标的建设方法-数据仓库模型框架(4),整合层模型建设对应用的支撑,整合层的稳定性,整合层提供全行统一的业务视图,整合层的数据全面性,整合层提供明细的数据,整合层保留完整的历史数据,保证模型对未来业务的业务支持的快速响应,不需要随业务的变化而频繁调整整合层模型,形成明确业务含义和数据来源,确保字段业务定义的唯一性,形成全行统一的业务视图,保留了业务系统中最细粒度的业务数据,保证整合层可以支持明细级的数据查询和分析应用,整合层涵盖我行主要源业务系统的业务信息,提供全面的业务数据,可以为客户、风险、绩效等各类分析应,整合层中可以完整保留业务系统的历史数据,保证了对历史类查询分析的支持,客户360度统一视图通过整合层模型落地,ETL,60,客户360度统一视图,客户额度信息,联系人/关联信息,客户大事记,交易信息,理财产品信息,产品/账户信息,国际结算信息,资本构成/股权投资,客户财务信息,客户基本信息,客户合作协议,其它信息,整合层模型对客户营销的支持,当事人主题,协议主题,事件主题,CRM-客户贡献度分析,核心,信贷管理,对公客户表,客户表,存款账户表,存款交易明细表,客户号,客户名称,存款余额,借据表,贷款余额,季度存款交易量,。

债项评级,。

五级分类,同一客户信息整合,整合层模型,营销策略-客户贡献度分类:

存款余额大于xx万,贷款余额大于xxxx万,并且属于正常贷款,且季度存款交易量大于xxx条的为A客户;存款余额大于xx万,贷款余额大于xxxx万,并且属于正常贷款,且季度存款交易量大于xxx条的为B客户;存款余额大于xx万,贷款余额大于xxxx万,并且属于次级贷款,且季度存款交易量大于xxx条的为C客户;通过客户贡献度的分类,制定营销策略,比如贡献度为A的客户,可进行贷款利率上的优惠或存款利率的上浮的方式稳定此利润点,客户贡献度分类,整合层模型对客户营销的支持,当事人主题,协议主题,事件主题,核心,信贷管理,对公客户表,客户表,存款账户表,存款交易明细表,借据表,。

债项评级,。

同一客户信息整合,整合层模型,营销,CRM-客户忠诚度分析,客户号,客户名称,是否基本户,账户日均余额,贷款期限,贷款金额,现金流量是否异常,账户睡眠时间,业务量是否异常,客户忠诚度分类,营销策略-客户忠诚度分类:

通过客户忠诚度的分类,忠诚度越大、则是我行重点的目标客户,可作为战略重点客户。

如果忠诚度不大,则要进行重点客户关系维护,即精准营销,汇总层目标与定位,作为整合层和集市层的衔接,从业务的视角出发,提炼出对数据仓库具有共性的数据访问需求,抽取出公共指标,形成由维度和指标组成的维度模型,对符合要求的数据进行预汇总和预加工。

为集市层统一提供规范的、准确的数据。

完成整个汇总层的逻辑模型、物理模型的设计并全部实现物理化。

并根据业务性质将业务数据,划分为以下七大类主题分类存放和管理,建设阶段和步骤,2.2参考模型到数据源的匹配,2.1数据源到参考模型的匹配,1.2当前用到的属性分析,1.1参考模型设计,3.1物理模型设计,一、逻辑模型初步设计,二、逻辑模型具体设计,三、开发实现,2.3应用驱动模型完善,业务驱动循环,客户需求调研,逻辑模型设计,3.2数据映射,3.3ETL,个人、存款、

展开阅读全文
相关资源
猜你喜欢
相关搜索
资源标签

当前位置:首页 > 农林牧渔 > 林学

copyright@ 2008-2023 冰点文库 网站版权所有

经营许可证编号:鄂ICP备19020893号-2