惠普中国人寿保险数据架构调研与评估Word格式.docx
《惠普中国人寿保险数据架构调研与评估Word格式.docx》由会员分享，可在线阅读，更多相关《惠普中国人寿保险数据架构调研与评估Word格式.docx（24页珍藏版）》请在冰豆网上搜索。
∙以应用为划分的〝烟囱〞结构，数据基于应用，并被锁定在应用系统中
-数据并没有被作为一个单独的IT组成部分被规划和设计，而是作为应用系统的一部分，由于应用系统的供应商不同，同时其设计工作也缺乏相互之间的和谐，因此，数据模型差不多按照各个应用系统的功能需求进行设计和实现；
-由于缺乏有效的数据共享，在有些业务环节上，一个应用所需的数据无法从相关的其他应用系统中获得〔如AMIS和财务系统间需要共享代理人佣金信息〕，而只好重复录入；
-另一方面，由于同一个数据可能存在多个数据源〔从多个应用系统中被重复录入〕，由此导致了信息的不一致。
∙核心业务系统的总体数据组织要紧是保单处理为中心，而较少倾向于以客户为中心；
∙结构化数据差不多上都利用数据库技术实现，非结构化数据只有少数地点使用影像技术实施了电子化，从应用程度上两者之间的集成度不高，影像工作流技术和其他应用系统之间没有能够做到无缝联接。
∙缺乏自动化和实时的数据交换
-以数据文件交换为要紧手段
▪现有的数据交换方式通常是从一个应用中将数据导出到平台文件中，再传递到目标平台并导入到目标应用系统中；
▪由于大批量的数据抽取工作会阻碍到正常的业务处理效率，因此通常的数据抽取都被设定在在晚间进行，因此数据的时效性较差〔通常都在一天左右〕。
-数据交换过程缺乏严格的数据校验、过程操纵等
▪接口数据的错误经常是在导入目标系统时才发觉，而不是作为系统数据质量操纵的一部分，预先在源系统中进行合法性校验；
▪数据交换的过程缺乏技术性操纵：
诸如大批量数据分割、数据传输的校验、重复操作的处理、操作回滚等。
∙对不同版本或开发商开发的，支撑同一业务应用，缺乏统一规定的应用系统数据外模式
-外模式是指系统对外部的数据视图〔VIEW〕，一个系统可能会用各种技术方式和平台来实现，但为了保持不同开发商开发的同一种业务应用的接口一致性，要求其系统中必须能够按照既定的标准格式〔包括表/视图，字段，数据类型，长度和精度等〕提供系统中的要紧数据。
即：
不管系统开发人员具体如何组织和实现系统的物理数据模型，都要保证任何第三方能够按照标准的数据模型定义猎取所要的数据，即整个系统对外提供的数据模型是遵循统一标准的。
-例如业务处理系统，总颁系统CBPS和深圳、江苏、上海的系统对外的数据模式和接口都不相同，和其他应用系统〔如CLAF〕的接口需要各自编写相应的接口软件来实现。
从较好的做法上，对同一业务处理过程，应当定义标准的接口模式，并以此作为软件开发的指导或标准。
例如：
中国电信就对所有的计费系统开发商定义了系统对外接口标准，对其产品、客户、话单、帐单等要紧的业务数据进行了详细的标准定义〔包括表/视图，字段，数据类型，长度和精度等〕，一次作为计费产品准入的验收标准之一，并禁止其分支机构购买不满足这一标准的产品。
1.1.1.2数据物理层次和数据提升〔staging〕
数据提升是指企业范畴内，数据从原始的事务处理细节数据，到各级汇总数据，到决策支持分析模型的逐层传递和转换过程。
数据提升的目的，是为了向各级业务部门提供查询或分析所需的不同汇总层次的数据。
∙事务〔transaction〕处理层数据
-应用系统中储备了完整的、原始的事务处理数据；
-应用系统中的部分事务处理数据具备时刻戳等增量识别标志；
业务参数版本体系
-没有后备系统储备离线历史数据：
包括用于储备历史数据的储备系统和用于质量操纵的测试系统；
-数据分布在各个省公司或地市公司的应用系统中，多数省份实施的是服务器的物理集中；
-原始业务数据没有从省公司到总公司的复制；
-没有达到保单级，仅统计数据；
实现了省级综合查询功能；
∙数据集成平台
-缺少完整统一的集成平台来集成各应用中的数据，建立企业级信息视图；
∙轻度统计汇总数据
-利用应用系统自身的报表功能和统计功能实现；
-省级和地市级的IT人员完成了一定的查询和报表开发工作，以满足业务部门的小规模要求；
-关于应用系统中没有的报表，利用手工〔UTAB或EXCEL〕实现；
-总公司层面缺乏对轻度汇总数据的全面集成；
∙高度汇总数据
-应用系统中具备部分高度汇总统计功能；
-由于手工工作太多，人为因素阻碍了数据的完整性和准确性，使得数据准确性和可信度不够高；
∙决策支持模型
-缺乏灵活的系统统计分析功能；
-缺乏企业级统一的数据平台，从而也就无法建立企业级的决策支持分析模型；
-目前的SAS系统要紧基于财务数据的分析。
∙外部数据交换
-和银行之间，通过中间服务器实现了实时的数据交换；
-和监管机构的数据交换通过报表的方式来进行；
-缺乏和其他机构〔如公安系统〕等的数据交换。
1.1.2差距分析
1.1.2.1用户期望的状况
通过调查，用户的期望集中在：
∙以后信息系统必须有长远规划，可支持多种治理模式；
∙加强信息系统的整合，建立对内对外信息披露的统一的、高效的平台，满足业务治理、销售支持、决策分析等各方面需要；
∙系统建设要面向客户和市场，支持业务流程和治理优化，支持应用系统在不同用户界面或渠道的拓展，如Internet、、多媒体终端等；
∙充分利用录入的原始数据，提供丰富的、方便的统计查询及分析功能；
指导我们的治理工作；
业务处理和行政治理规范化、自动化、流程化、无纸化；
另外，通过信息系统建立预警机制，加强业务监控；
∙信息系统由封闭走向开放，将职员、客户、业务员、代理机构、合作伙伴有机结合起来。
∙用户认为目前信息系统距离业务需求的差距〔优先级〕
图12信息系统距离业务的要紧差距
从上图中能够看出，目前的应用系统信息处理效率不高是用户反映最多的问题，其次是信息量不丰富和准确性不够。
因此，上述各项中，建立高效的数据处理应用系统和统一集成的数据整合平台是用户的重点期望。
1.1.2.2差距及缘故
编号
ID
观看
Observation
全然缘故
RootCause
阻碍范畴
Impact
改进建议
Action
D.01.1
整个信息系统缺乏总体性，数据接口设计、开发、爱护、升级等工作复杂
没有总体的业务信息流的定义，从而无法进行总体的数据流设计
所有应用
定义业务处理的信息流，在此基础上定义信息系统的数据流，统一应用间数据交换定义
D.01.2
企业级总体监控信息难以猎取，时效性差
没有总体数据架构规划
没有建立数据提升系统来整合原始业务数据，并逐级汇总
业务监控、治理和决策
分时期建立企业级统一的数据平台〔One-View〕，包括：
基础数据平台、各汇总层次数据、决策支持模型
D.01.3
信息系统的组织和设计是面向业务流程处理的，而不是以客户为中心的
旧的业务治理模式是面向处理流程的
所有业务治理和客户服务
建立以客户为中心的业务治理和客户服务模式，在此基础上按照CRM的理念改造现有信息系统
1.2数据标准化治理
∙数据标准化的定义
为在一定的范畴内获得最正确秩序，对实际的或潜在的问题制定共同的和重复使用的规那么活动。
上述活动要紧是包括制定、分布及实施标准的过程；
标准化的要紧意义是改进产品、过程和服务的适应性，防止贸易壁垒，并促进技术合作。
标准化包括三个要紧方面的内容：
标准化是一项完整的活动，是一个长期的过程。
它包括制定标准、公布标准、贯彻实施标准，对标准的实施进行监督检查，并依照贯彻中产生的问题，进一步修订完善标准。
2．标准是贯穿于标准化全过程的信息资源。
标准化对象的选择要依照实际的需求和潜在的需求来确定。
3．标准化的目的是取得社会效益和经济效益，其表达形式是改进产品、过程和服务的适用性，防止数字鸿沟，促进相互合作。
∙数据标准化包括：
-信息指标体系标准化
-信息分类编码标准化
-信息交换接口标准化
-信息系统开发标准化
那个地点，信息系统开发标准化属于IT治理的内容，本章要紧对前三项，即信息标准的制定和治理进行评估。
1.2.1现状描述
∙差不多上所有的业务和IT人员都充分认识到数据标准化对业务的重要性，但往往数据标准化被认为是IT部门的工作，而忽视了建立数据标准化的基础：
业务信息定义的标准化；
但实际上，除了部分代码标准是总公司下发的以外，业务部门并没有统一制定业务信息的标准定义，因此，IT部门也就缺乏必要的、统一的依据来制定数据标准；
∙从业务指标体系上，没有一个从总部制定的统一指标和统计报表体系，各不同部门、不同分支结构都有自行制定的统计报表，结果导致整个系统乃至报表制作人员的工作负载过大，重复工作也较多，最终的结果是导致报表的数据全面性和准确性下降；
∙从组织保证上，并没有一个指定的团队来负责业务信息乃至数据定义的标准化工作；
∙各应用系统的开发商不同，而中国人寿对各供应商在数据标准化上也无法进行有效的操纵，导致所遵循的数据标准不统一；
∙由于总颁应用系统普及面较广，对某一个具体的业务应用来讲，使用该应用系统的数据标准差不多是统一的。
1.2.1.1现有数据标准制定和治理制度
∙数据标准的制定由应用系统开发商负责，而不是由一个独立的数据规划部门负责；
∙开发商遵循自己的数据标准制定流程进行治理，差不多属于开发治理的范畴，而不是IT治理和规划的范畴；
∙现行的数据治理是面向最终数据结果〔如统计报表、精算数据预备等〕的，而忽视了数据定义和处理的标准化，各地对同一个名词的明白得和定义可能都不相同。
1.2.2差距分析
1.2.2.1用户期望的状况
∙对业务的重要性：
在对现状调研的过程中，不管是业务人员依旧IT人员，所有的受访者都一致认为信息标准化程度对业务是专门重要的。
∙业务信息标准化的优先级：
图13信息标准优先级－业务人员反馈
上图是业务人员对信息标准化优先级的反馈统计，而从IT人员的反馈来看，唯独的区别是他们认为最优先的应当是业务操作过程信息：
图14信息标准优先级－IT人员反馈
综合业务和IT人员的看法，我们能够认为，保单信息、客户信息和业务操作过程信息是当前最迫切的标准化需求，也是进行数据整合是实施数据清理的重点工作。
∙信息标准无法贯彻的缘故：
图15信息标准无法统一的缘故调查
由上图能够看出，几乎所有的受访者都认为标准无法贯彻的缘故是没有治理制度；
因此，我们初步认为，中国人寿有着专门好的标准化实施基础，而制定和贯彻标准化治理制定是这项工作的重点突破口。
1.2.2.2差距及缘故
D.02.1
各应用系统之间，各业务层次之间，各业务部门和区域之间的信息沟通中的信息定义和转换过程复杂
没有统一数据标准
所有
建立统一的业务信息标准，并在此基础上建立统一的数据标准
D.02.2
数据标准的贯彻能力弱
缺乏授权的流程的制度保证标准的贯彻
建立数据标准的制定、公布、爱护流程，并建立定期审计制度；
严格操纵应用开发的数据标准，将其作为开发项目验收条款的一部分
1.3数据质量治理
1.3.1现状描述
1.3.1.1数据质量治理现状
∙现行的数据质量标准
-中国人寿没有全公司范畴的数据质量考核体系，现行的数据质量评判要紧通过以下几方面进行：
▪业务考核或报告中，数据统计的准确度和完整性；
▪应用系统运行时所执行的业务逻辑校验；
▪数据交换时的合法性检查；
∙现有的数据质量操纵方法
-应用系统所实现的校验逻辑和业务规那么；
-数据交换时的合法性检查；
-应用系统间的数据对比；
∙现行的数据质量治理制度
-缺乏完善的对数据录入人员的数据质量考核体系；
-缺乏对开发过程的数据标准化操纵；
-缺乏系统上线流程中的数据迁移治理；
-缺乏对应用系统运行过程中的数据质量审计和考核体系。
∙现行的数据质量治理工具
-现行的数据质量治理工具要紧是为数据接口所开发的校验程序，用于发觉交换数据的错误；
-由于没有企业级统一的数据平台，因此，也就没有全司范畴的数据质量监控和数据自动修正工具。
1.3.1.2现有数据质量问题
现有的数据质量问题要紧表现在：
∙相关于新的业务应用系统来说，老业务数据不完整，导致系统升级和移植后，数据质量不能达到新应用系统的要求；
∙关于历史数据的转换，差不多依靠于系统上线时的数据转换，而不是将历史数据的转换和修正作为一个长期的过程，在今后的业务操作中逐步补入；
∙系统校验操纵不严谨或BUG导致的数据错。
∙治理员为保证业务的运行，在取得授权的情形下，直截了当修改数据库后台数据，由于对应用系统的熟悉程度的差异，导致显现数据不一致；
∙升级和移植过程中数据转换或迁移操作错误，导致的数据错；
1.3.2差距分析
1.3.2.1用户期望的状况
在调查中，几乎所有的用户都认为目前的数据质量无法满足业务监控的要求，然而，其中的多数用户都认为数据质量问题集中在老业务中，也确实是说，用户对目前应用系统产生的数据的质量依旧能够同意。
关于今后的数据质量操纵措施，用户要紧的反映集中在：
∙提高系统事后监控能力，通过数据的扫描和比对，发觉数据错误；
∙提高数据交换的实时性和自动化程度，减少由于时刻差和人为因素导致的接口数据错误。
∙加强系统上线和升级的测试工作，减少升级导致的数据错误；
1.3.2.2差距及缘故
D.03.1
现有历史数据质量无法满足以客户为中心的要求
由于业务需求和应用逻辑定义不完善，导致历史数据不完整
缺乏完善的数据质量考核体系
在建立以客户为中心的业务模型的基础上，尽量补齐或修正所需的客户信息和相关交易信息；
数据修正是一个长期的过程，例如，能够将当时无法补齐地数据标记为‘未知’或‘待修正’，在今后的业务操作中，一旦能够猎取到这些数据，再行补上。
对无法补齐或修正的数据，公布数据质量报告，明确告知最终用户；
关于现在后今后产生的数据，建立严格的数据质量考核体系，加强应用操作，专门是数据录入的监督
D.03.2
系统升级越频繁，数据质量越差
系统开发缺乏严格的测试，导致BUG引发的数据错误
系统升级时没有系统地考虑数据地迁移和转换过程
系统升级和爱护
建立需求部门负责把关的严格的测试体系，对应用系统
引入解决方案部署过程〔SolutionArchitectureandInfrastructureDesign〕，保证系统升级过程更加系统和完善;
将系统的部署或升级方案作为应用开发验收的一部分
D.03.3
治理员人为修改导致数据质量下降
业务需求定义不完善
应用系统不灵活
治理员对应用系统处理过程及表之间的参照关系不熟悉
系统爱护
建立统一的数据直截了当修改流程，严格操纵直截了当后台修改的授权、修改方法和测试过程
D.03.4
数据质量问题一直未能完全解决
数据质量问题不是一个方案就能够解决的，它是一个长期的过程
全部应用
数据质量治理应当和应用系统的开发、升级、爱护相整合，不断地进行系统的质量问题回馈，以促进应用系统的数据质量操纵能力，将提高应用系统对数据质量的操纵能力作为一个长期的渐进进展过程
1.4应用系统数据治理
1.4.1现状描述
应用系统的数据爱护是指应用系统为保证数据一致性和处理效率，对系统中数据的爱护功能，要紧包括：
-业务规那么校验
-数据合法性定期扫描和错误数据清理
-系统上线时的数据转换方案
通过调查，我们发觉核心业务系统在上述方面最具备代表性，因此，以下要紧以核心业务系统为例，说明目前中国人寿应用系统数据爱护方面的现状。
1.4.1.1应用系统数据爱护
CBPS应用系统数据爱护描述：
∙业务逻辑操纵〔数据校验〕
-不承诺为空数据的强制录入操纵
-变化幅度专门的数据
目前的应用系统中上述方面比旧系统相对好一些，但在以往的应用系统由于需求定义不完善的缘故，存在由于上述操纵不完善导致的非正常数据。
∙数据扫描和一致性校验〔举例说明〕
-应用系统没有错误数据清理工具；
-没有实施例行检查操作,主动发觉系统中的数据错误；
∙错误数据清理
-目前没有应用系统自动的错误数据报警和清理功能；
-错误数据清理仍是相当艰巨的工作；
-部分分公司做了错误数据清理工作；
∙历史数据卸载
-系统设计时没有考虑历史数据卸载打算、卸载机制；
-缺乏历史数据卸载这方面的知识和体会；
∙直截了当后台修改
-系统中存在错误数据，导致前台无法正常操作，需要后台修改。
这部分比重相对较大；
-由于某些功能程序不支持，需要后台修改.；
-后台修改一样采纳会办单的形式流转；
-复杂问题的诊断，较为慎重的做法是在测试库上模拟验证；
∙系统升级和迁移
-系统升级和迁移频繁；
-升级和迁移时缺乏良好的测试，导致显现操作不正常，以及数据错误。
上海应用系统数据爱护描述：
现有系统对数据录入的操纵较严格，目前存在的某些数据字段为空的缘故是由于历史数据缺失，或者过去业务需求定义时没有要求强制录入。
目前存在的业务规那么校验问题要紧是：
▪历史数据没有满足业务规那么，因此移入时就不正确；
▪应用程序中存在的BUG，导致业务规那么校验没有被100％地实现；
目前系统中存在某些数据满足规那么但不合理的现象，如投保年龄超过条款规定的缘故，可能是依据业务特批进行的操作。
∙数据扫描和一致性校验
应用系统后台后台配备有审计程序，定时运行，依照规那么搜索专门数据，查找缘故并处理。
目前对错误数据的清理差不多是治理员手工执行：
假如是生产系统数据有错，尽量修改；
假如缺失没法补，那么舍弃对该错误的修改。
最初的系统设计未考虑那个问题。
目前预备将一些表按规那么拆分，但需要应用系统中的一些程序调整〔比如由于表分拆，原先的查询程序需要作相应的修改〕，必须统一考虑。
目前应用系统中的直截了当后台修改集中在团险领域，由于团险协商情形较多，系统不能接收。
处理方法是：
由业务做批示，开发人员写脚本，提交运行人员执行，将数据导入；
∙系统升级和迁移
一样不删除旧表或旧字段。
升级时写好脚本，并测试。
江苏应用系统数据爱护描述
历史数据没有满足业务规那么，因此移入时就不正确；
-依照业务需求的业务规那么不定期搜索专门数据，查找缘故并处理。
-目前对错误数据的清理差不多是业务手工执行：
假如缺失没法补，那么舍弃对该错误的修改并备案。
-部分历史数据如收付费,台帐信息有卸载机制
-业务流程承诺的数据修改外数据爱护直截了当后台修改。
-一样不删除旧表或旧字段。
深圳应用系统数据爱护描述：
由于我司的核心业务系统Lifepro为新开发系统，设计时对新数据录入的要求相当严格，数据为空将无法连续完成业务流程，并给出错误提示。
目前存在的某些数据字段为空的要紧缘故是由于历史数据缺失，或者过去业务需求定义时没有要求强制录入，或者是在数据迁移时强行对应字段。
历史数据没有完全满足业务规那么，迁移时就无法进行严格匹配；
尽管对业务数据进行了严格操纵，但偶有业务特批现象，这使得目前系统中存在某些数据满足业务规那么但不合理的现象。
应用系统后台差不多上没有进行数据扫描和一致性校验。
我司在转换系统时曾经进行过大规模错误数据清理，然而平常差不多上没有专门的此项工作。
最初的系统设计没有考虑那个问题，有待完善。
目前核心业务系统中的直截了当后台修改要紧集中在业务反向操作和补入相关记录。
由业务人员谢工作单，通过Lotus工作单流转〔严格执行层层审批制度〕，再由开发人员写脚本，提交运行人员执行，完成后台修改；
深圳分公司新开发的核心业务系统Lifepro的数据架构为全新设计，在新系统交接之前，投入大量人力物力进行数据迁移和测试工作。
差不多方法是先写好数据迁移脚本并执行，再进行数据校验和测试。
1.4.1.2现有数据库平台
差不多上，目前所有的要紧应用系统全部使用Informix作为数据库平台；
少量的支持性应用〔如网站等〕使用MSSQLServer，上海采纳DB2作为数据仓库平台。
用户对数据库平台的评判如以下图所示：
图16现有数据库平台评判
从上图看到，用户对Informix数据库治理系统
升级会员 