ITAssessmentreport.V1.11.DATA.1124zrh.docVIP

图 11 信息系统总体架构图 2 图 12 信息系统距离业务的主要差距 7 图 13 信息标准优先级－业务人员反馈 10 图 14 信息标准优先级－IT人员反馈 11 图 15 信息标准无法统一的原因调查 11 图 16 现有数据库平台评价 20 图 17 现有数据访问权限控制调查 21 图 18 现有系统审计功能调查 21 数据架构调研与评估 数据架构是指企业总体的数据采集、处理、存储和管理等的总体架构，区别于应用架构，数据架构主要侧重于业务处理所需的信息和信息流，包括： 总体架构：数据模型组织方式； 数据标准化：企业级数据定义的标准化及管理水平； 数据质量管理：数据的准确性，以及数据的完整性； 数据管理：应用系统中的数据管理，包括：存储组织和数据库平台、数据卸载和清理、访问权限控制等； 总体数据架构 现状描述 目前，中国人寿的总体数据架构的建设是一个自底向上的过程：通过建立一个个应用，产生相应业务区域的数据模型，然后根据需要建立这些数据模型间的数据接口，从而以逐步“联接”的方式，形成中国人寿的总体数据架构。 上图（改为引用）描述了这种基于应用建设所建立起来的数据架构： 图 11 信息系统总体架构图 上图（改为引用）摘自《中国人寿应用系统介绍及计划》，它描述了整个中国人寿主要的应用系统间的关联和数据交换，从总体上看来，中国人寿： 基本实现了业务信息的电子化，绝大多数业务处理都有应用系统支持； 主要的业务功能区域（如寿险实务、财务管理帐户管理等）的信息处理都有较为成熟的应用架构和数据架构； 各个主要应用系统之间可以利用数据文件进行数据交换，实现了信息的传递和共享； 银保通系统能够实现和银行间的实时数据交换； 基于数据库技术的信息处理体系基本成熟； 初步建立了以中间库为基础的数据整合平台，并基于它实现了企业数据综合查询统计功能； 初步建立了以统计报表工具为手段的数据统计和报表系统； 财务系统利用了数据仓库技术和SAS工具进行数据分析，但没有广泛应用，除此之外，诸如上海少数公司还建立了自己的数据仓库系统； 基于NOTES的消息邮件系统支持了公司的日常信息沟通工作； 基于影像技术的非结构化数据正在一些分公司使用，这种趋势正在发展并逐步推广。 数据模型和应用的相关性 以应用为划分按应用划分的“烟囱”结构中，数据基于应用，并被锁定在应用系统中 数据并没有被作为一个单独的IT组成部分被规划和设计，而是作为应用系统的一部分，由于应用系统的供应商不同，并且其设计工作也缺乏相互之间的协调，因此，数据模型基本按照各个应用系统的功能需求进行设计和实现； 由于缺乏有效的数据共享，在有些业务环节上，一个应用所需的数据无法很难从相关的其他应用系统中获得（如AMIS和财务系统间需要共享代理人佣金信息），而只好重复录入； 另一方面，由于同一个数据可能存在多个数据源（从多个应用系统中被重复录入），由此导致了信息的不一致。 核心业务系统的总体数据组织主要是以保单处理为中心，而较少倾向于以客户为中心； 结构化数据基本上都利用数据库技术实现，非结构化数据只有少数地方使用影像技术实施了电子化(修改)，从应用程度上看两者之间的集成度不高，影像工作流技术和其他应用系统之间没有能够做到无缝联接。 缺乏自动化和实时的数据交换 以数据文件交换为主要手段 现有的数据交换方式通常是从一个应用中将数据导出到平台格式化文件中，再传递到目标平台并导入到目标应用系统中； 由于大批量的数据抽取工作会影响到正常的业务处理效率，因此通常的数据抽取都被设定在在晚间进行，是所以造成数据的时效性较差的原因之一（通常都在一天左右）。 数据交换过程缺乏严格的数据校验、过程控制等 接口数据的错误经常是在导入目标系统时才发现，而按照不是作为系统数据质量控制的要求一部分，应该预先在源系统中进行合法性校验； 数据交换的过程过于简单，缺乏技术性控制：诸如大批量数据分割、数据传输的校验、重复操作的处理、操作回滚等。 对不同版本或开发商开发的，支撑同一业务应用，缺乏统一规定的应用系统数据外模式 外模式是指系统对外部的数据视图（VIEW），一个系统可能会用各种技术方式和平台来实现，但为了保持不同开发商开发的同一种业务应用的接口一致性，要求其系统中必须能够按照既定的标准格式（包括表/视图，字段，数据类型，长度和精度等）提供系统中的主要数据。即：无论系统开发人员具体如何组织和实现系统的物理数据模型，都要保证任何第三方可以按照标准的数据模型定义获取所要的数据，即整个系统对外提供的数据模型是遵循统一标准的。 例如业务处理系统，总颁系统CBPS和深圳、江苏、上海的系统对外的数据模式和接口都不相同，和其他应用系统（如CLAF）的接口需要各自编写相应的接口软件来实现。