中国保险公司保险数据架构调研与评估

《中国保险公司保险数据架构调研与评估》由会员分享，可在线阅读，更多相关《中国保险公司保险数据架构调研与评估（25页珍藏版）》请在装配图网上搜索。

1、www.* 海量免费资料尽在此图 11 信息系统总体架构图2图 12 信息系统距离业务的重要差距7图 13 信息原则优先级业务人员反馈10图 14 信息原则优先级IT人员反馈10图 15 信息原则无法统一的因素调查11图 16 既有数据库平台评价19图 17 既有数据访问权限控制调查20图 18 既有系统审计功能调查201 数据架构调研与评估 数据架构是指公司总体的数据采集、解决、存储和管理等的总体架构，区别于应用架构，数据架构重要侧重于业务解决所需的信息和信息流，涉及： 总体架构：数据模型组织方式 数据原则化：公司级数据定义的原则化及管理水平； 数据质量管理：数据的精确性，以及数据的完整性；

2、 数据管理：应用系统中的数据管理，涉及：存储组织和数据库平台、数据卸载和清理、访问权限控制等；1.1 总体数据架构1.1.1 现状描述目前，中国人寿的总体数据架构的建设是一种自底向上的过程：通过建立一种个应用，产生相应业务区域的数据模型，然后根据需要建立这些数据模型间的数据接口，从而以逐渐“联接”的方式，形成中国人寿的总体数据架构。下图描述了这种基于应用建设所建立起来的数据架构：图 11 信息系统总体架构图上图摘自中国人寿应用系统简介及筹划，它描述了整个中国人寿重要的应用系统间的关联和数据互换，从总体上看来，中国人寿： 基本实现了业务信息的电子化，绝大多数业务解决均有应用系统支持； 重要的业务

3、功能区域（如寿险实务、财务管理等）的信息解决均有较为成熟的应用架构和数据架构； 各个应用系统之间可以运用数据文献进行数据互换，实现了信息的传递和共享； 银保通系统可以实现和银行间的实时数据互换； 基于数据库技术的信息解决体系基本成熟； 初步建立了以中间库为基本的数据整合平台，并基于它实现了公司数据综合查询记录功能； 初步建立了以记录报表工具为手段的数据记录和报表系统； 财务系统运用了数据仓库技术和SAS工具进行数据分析，除此之外，诸如上海还建立了自己的数据仓库系统； 基于NOTES的消息系统支持了公司的平常信息沟通工作； 基于影像技术的非构造化数据正在某些分公司使用，并逐渐推广。1.1.1.1

4、 数据模型和应用的有关性 以应用为划分的“烟囱”构造，数据基于应用，并被锁定在应用系统中- 数据并没有被作为一种单独的IT构成部分被规划和设计，而是作为应用系统的一部分，由于应用系统的供应商不同，并且其设计工作也缺少互相之间的协调，因此，数据模型基本按照各个应用系统的功能需求进行设计和实现；- 由于缺少有效的数据共享，在有些业务环节上，一种应用所需的数据无法从有关的其她应用系统中获得（如AMIS和财务系统间需要共享代理人佣金信息），而只得反复录入；- 另一方面，由于同一种数据也许存在多种数据源（从多种应用系统中被反复录入），由此导致了信息的不一致。 核心业务系统的总体数据组织重要是保单解决为中

5、心，而较少倾向于以客户为中心； 构造化数据基本上都运用数据库技术实现，非构造化数据只有少数地方使用影像技术实行了电子化，从应用限度上两者之间的集成度不高，影像工作流技术和其她应用系统之间没有可以做到无缝联接。 缺少自动化和实时的数据互换- 以数据文献互换为重要手段 既有的数据互换方式一般是从一种应用中将数据导出到平台文献中，再传递到目的平台并导入到目的应用系统中； 由于大批量的数据抽取工作会影响到正常的业务解决效率，因此一般的数据抽取都被设定在在晚间进行，因此数据的时效性较差（一般都在一天左右）。- 数据互换过程缺少严格的数据校验、过程控制等 接口数据的错误常常是在导入目的系统时才发现，而不是

6、作为系统数据质量控制的一部分，预先在源系统中进行合法性校验； 数据互换的过程缺少技术性控制：诸如大批量数据分割、数据传播的校验、反复操作的解决、操作回滚等。 对不同版本或开发商开发的，支撑同一业务应用，缺少统一规定的应用系统数据外模式- 外模式是指系统对外部的数据视图（VIEW），一种系统也许会用多种技术方式和平台来实现，但为了保持不同开发商开发的同一种业务应用的接口一致性，规定其系统中必须可以按照既定的原则格式（涉及表/视图，字段，数据类型，长度和精度等）提供系统中的重要数据。即：无论系统开发人员具体如何组织和实现系统的物理数据模型，都要保证任何第三方可以按照原则的数据模型定义获取所要的数据

7、，即整个系统对外提供的数据模型是遵循统一原则的。- 例如业务解决系统，总颁系统CBPS和深圳、江苏、上海的系统对外的数据模式和接口都不相似，和其她应用系统（如CLAF）的接口需要各自编写相应的接口软件来实现。从较好的做法上，对同一业务解决过程，应当定义原则的接口模式，并以此作为软件开发的指引或原则。例如：中国电信就对所有的计费系统开发商定义了系统对外接口原则，对其产品、客户、话单、帐单等重要的业务数据进行了具体的原则定义（涉及表/视图，字段，数据类型，长度和精度等），一次作为计费产品准入的验收原则之一，并严禁其分支机构购买不满足这一原则的产品。1.1.1.2 数据物理层次和数据提高（stagi

8、ng）数据提高是指公司范畴内，数据从原始的事务解决细节数据，到各级汇总数据，到决策支持分析模型的逐级传递和转换过程。数据提高的目的，是为了向各级业务部门提供查询或分析所需的不同汇总层次的数据。 事务（transaction）解决层数据- 应用系统中存储了完整的、原始的事务解决数据；- 应用系统中的部分事务解决数据具有时间戳等增量辨认标志；业务参数版本体系- 没有后备系统存储离线历史数据：涉及用于存储历史数据的存储系统和用于质量控制的测试系统；- 数据分布在各个省公司或地市公司的应用系统中，多数省份实行的是服务器的物理集中；- 原始业务数据没有从省公司到总公司的复制；- 没有达到保单级，仅记录数

9、据；实现了省级综合查询功能； 数据集成平台- 缺少完整统一的集成平台来集成各应用中的数据，建立公司级信息视图； 轻度记录汇总数据- 运用应用系统自身的报表功能和记录功能实现；- 省级和地市级的IT人员完毕了一定的查询和报表开发工作，以满足业务部门的小规模规定；- 对于应用系统中没有的报表，运用手工（UTAB或EXCEL）实现；- 总公司层面缺少对轻度汇总数据的全面集成； 高度汇总数据- 应用系统中具有部分高度汇总记录功能；- 对于应用系统中没有的报表，运用手工（UTAB或EXCEL）实现；- 由于手工工作太多，人为因素影响了数据的完整性和精确性，使得数据精确性和可信度不够高； 决策支持模型-

10、缺少灵活的系统记录分析功能；- 缺少公司级统一的数据平台，从而也就无法建立公司级的决策支持分析模型；- 目前的SAS系统重要基于财务数据的分析。 外部数据互换- 和银行之间，通过中间服务器实现了实时的数据互换；- 和监管机构的数据互换通过报表的方式来进行；- 缺少和其她机构（如公安系统）等的数据互换。1.1.2 差距分析1.1.2.1 顾客盼望的状况通过调查，顾客的盼望集中在： 将来信息系统必须有长远规划，可支持多种管理模式； 加强信息系统的整合，建立对内对外信息披露的统一的、高效的平台，满足业务管理、销售支持、决策分析等各方面需要； 系统建设要面向客户和市场，支持业务流程和管理优化，支持应用

11、系统在不同顾客界面或渠道的拓展，如Internet、电话、多媒体终端等； 充足运用录入的原始数据，提供丰富的、以便的记录查询及分析功能；指引我们的管理工作；业务解决和行政管理规范化、自动化、流程化、无纸化；此外，通过信息系统建立预警机制，加强业务监控； 信息系统由封闭走向开放，将员工、客户、业务员、代理机构、合伙伙伴有机结合起来。 顾客觉得目前信息系统距离业务需求的差距（优先级）图 12 信息系统距离业务的重要差距从上图中可以看出，目前的应用系统信息解决效率不高是顾客反映最多的问题，另一方面是信息量不丰富和精确性不够。因此，上述各项中，建立高效的数据解决应用系统和统一集成的数据整合平台是顾客的

12、重点盼望。1.1.2.2 差距及因素编号ID观测Observation主线因素Root Cause影响范畴Impact改善建议ActionD.01.1整个信息系统缺少总体性，数据接口设计、开发、维护、升级等工作复杂没有总体的业务信息流的定义，从而无法进行总体的数据流设计所有应用定义业务解决的信息流，在此基本上定义信息系统的数据流，统一应用间数据互换定义D.01.2公司级总体监控信息难以获取，时效性差没有总体数据架构规划没有建立数据提高系统来整合原始业务数据，并逐级汇总业务监控、管理和决策分阶段建立公司级统一的数据平台（One-View），涉及：基本数据平台、各汇总层次数据、决策支持模型D.01

13、.3信息系统的组织和设计是面向业务流程解决的，而不是以客户为中心的旧的业务管理模式是面向解决流程的所有业务管理和客户服务建立以客户为中心的业务管理和客户服务模式，在此基本上按照CRM的理念改造既有信息系统1.2 数据原则化管理 数据原则化的定义为在一定的范畴内获得最佳秩序，对实际的或潜在的问题制定共同的和反复使用的规则活动。上述活动重要是涉及制定、分布及实行原则的过程；原则化的重要意义是改善产品、过程和服务的适应性，避免贸易壁垒，并增进技术合伙。原则化涉及三个重要方面的内容：原则化是一项完整的活动，是一种长期的过程。它涉及制定原则、发布原则、贯彻实行原则，对原则的实行进行监督检查，并根据贯彻中

14、产生的问题，进一步修订完善原则。2原则是贯穿于原则化全过程的信息资源。原则化对象的选择要根据实际的需求和潜在的需求来拟定。3原则化的目的是获得社会效益和经济效益，其体现形式是改善产品、过程和服务的合用性，避免数字鸿沟，增进互相合伙。 数据原则化涉及：- 信息指标体系原则化- 信息分类编码原则化- 信息互换接口原则化 - 信息系统开发原则化这里，信息系统开发原则化属于IT治理的内容，本章重要对前三项，即信息原则的制定和管理进行评估。1.2.1 现状描述 基本上所有的业务和IT人员都充足结识到数据原则化对业务的重要性，但往往数据原则化被觉得是IT部门的工作，而忽视了建立数据原则化的基本：业务信息定

15、义的原则化；但事实上，除了部分代码原则是总公司下发的以外，业务部门并没有统一制定业务信息的原则定义，因此，IT部门也就缺少必要的、统一的根据来制定数据原则； 从业务指标体系上，没有一种从总部制定的统一指标和记录报表体系，各不同部门、不同分支构造均有自行制定的记录报表，成果导致整个系统乃至报表制作人员的工作负载过大，反复工作也较多，最后的成果是导致报表的数据全面性和精确性下降； 从组织保证上，并没有一种指定的团队来负责业务信息乃至数据定义的原则化工作； 各应用系统的开发商不同，而中国人寿对各供应商在数据原则化上也无法进行有效的控制，导致所遵循的数据原则不统一； 由于总颁应用系统普及面较广，对某一

16、种具体的业务应用来讲，使用该应用系统的数据原则基本是统一的。1.2.1.1 既有数据原则制定和管理制度 数据原则的制定由应用系统开发商负责，而不是由一种独立的数据规划部门负责； 开发商遵循自己的数据原则制定流程进行管理，基本属于开发管理的范畴，而不是IT管理和规划的范畴； 现行的数据管理是面向最后数据成果（如记录报表、精算数据准备等）的，而忽视了数据定义和解决的原则化，各地对同一种名词的理解和定义也许都不相似。1.2.2 差距分析1.2.2.1 顾客盼望的状况 对业务的重要性：在对现状调研的过程中，无论是业务人员还是IT人员，所有的受访者都一致觉得信息原则化限度对业务是非常重要的。 业务信息原

17、则化的优先级：图 13 信息原则优先级业务人员反馈上图是业务人员对信息原则化优先级的反馈记录，而从IT人员的反馈来看，唯一的区别是她们觉得最优先的应当是业务操作过程信息：图 14 信息原则优先级IT人员反馈综合业务和IT人员的见解，我们可以觉得，保单信息、客户信息和业务操作过程信息是目前最迫切的原则化需求，也是进行数据整合是实行数据清理的重点工作。 信息原则无法贯彻的因素：数据原则无法统一的因素4%7%71%18%不适应业务需要额外增长工作量，减少效率没有原则的管理制度来保证明施各应用系统供应商不同图 15 信息原则无法统一的因素调查由上图可以看出，几乎所有的受访者都觉得原则无法贯彻的因素是没

18、有管理制度；因此，我们初步觉得，中国人寿有着较好的原则化实行基本，而制定和贯彻原则化管理制定是这项工作的重点突破口。1.2.2.2 差距及因素编号ID观测Observation主线因素Root Cause影响范畴Impact改善建议ActionD.02.1各应用系统之间，各业务层次之间，各业务部门和区域之间的信息沟通中的信息定义和转换过程复杂没有统一数据原则所有建立统一的业务信息原则，并在此基本上建立统一的数据原则D.02.2数据原则的贯彻能力弱缺少授权的流程的制度保证原则的贯彻所有建立数据原则的制定、发布、维护流程，并建立定期审计制度；严格控制应用开发的数据原则，将其作为开发项目验收条款的一

19、部分 1.3 数据质量管理1.3.1 现状描述1.3.1.1 数据质量管理现状 现行的数据质量原则- 中国人寿没有全公司范畴的数据质量考核体系，现行的数据质量评价重要通过如下几方面进行： 业务考核或报告中，数据记录的精确度和完整性； 应用系统运营时所执行的业务逻辑校验； 数据互换时的合法性检查； 既有的数据质量控制措施- 应用系统所实现的校验逻辑和业务规则；- 数据互换时的合法性检查；- 应用系统间的数据对照； 现行的数据质量管理制度- 缺少完善的对数据录入人员的数据质量考核体系；- 缺少对开发过程的数据原则化控制；- 缺少系统上线流程中的数据迁移管理；- 缺少相应用系统运营过程中的数据质量审

20、计和考核体系。 现行的数据质量管理工具- 现行的数据质量管理工具重要是为数据接口所开发的校验程序，用于发现互换数据的错误；- 由于没有公司级统一的数据平台，因此，也就没有全司范畴的数据质量监控和数据自动修正工具。1.3.1.2 既有数据质量问题既有的数据质量问题重要表目前： 相对于新的业务应用系统来说，老业务数据不完整，导致系统升级和移植后，数据质量不能达到新应用系统的规定； 对于历史数据的转换，基本依赖于系统上线时的数据转换，而不是将历史数据的转换和修正作为一种长期的过程，在此后的业务操作中逐渐补入； 系统校验控制不严谨或BUG导致的数据错。 管理员为保证业务的运营，在获得授权的状况下，直接

21、修改数据库后台数据，由于相应用系统的熟悉限度的差别，导致浮现数据不一致； 升级和移植过程中数据转换或迁移操作错误，导致的数据错；1.3.2 差距分析1.3.2.1 顾客盼望的状况在调查中，几乎所有的顾客都觉得目前的数据质量无法满足业务监控的规定，但是，其中的多数顾客都觉得数据质量问题集中在老业务中，也就是说，顾客对目前应用系统产生的数据的质量还是可以接受。对于此后的数据质量控制措施，顾客重要的反映集中在： 提高系统事后监控能力，通过数据的扫描和比对，发现数据错误； 提高数据互换的实时性和自动化限度，减少由于时间差和人为因素导致的接口数据错误。 加强系统上线和升级的测试工作，减少升级导致的数据错

22、误；1.3.2.2 差距及因素编号ID观测Observation主线因素Root Cause影响范畴Impact改善建议ActionD.03.1既有历史数据质量无法满足以客户为中心的规定由于业务需求和应用逻辑定义不完善，导致历史数据不完整缺少完善的数据质量考核体系所有在建立以客户为中心的业务模型的基本上，尽量补齐或修正所需的客户信息和有关交易信息；数据修正是一种长期的过程，例如，可以将当时无法补齐地数据标记为未知或待修正，在此后的业务操作中，一旦可以获取到这些数据，再行补上。对无法补齐或修正的数据，发布数据质量报告，明确告知最后顾客；对于目前后此后产生的数据，建立严格的数据质量考核体系，加强应

23、用操作，特别是数据录入的监督D.03.2系统升级越频繁，数据质量越差系统开发缺少严格的测试，导致BUG引起的数据错误系统升级时没有系统地考虑数据地迁移和转换过程系统升级和维护建立需求部门负责把关的严格的测试体系，相应用系统引入解决方案部署过程（Solution Architecture and Infrastructure Design），保证系统升级过程更加系统和完善;将系统的部署或升级方案作为应用开发验收的一部分D.03.3管理员人为修改导致数据质量下降业务需求定义不完善应用系统不灵活管理员相应用系统解决过程及表之间的参照关系不熟悉系统维护建立统一的数据直接修改流程，严格控制直接后台修改的

24、授权、修改措施和测试过程D.03.4数据质量问题始终未能彻底解决数据质量问题不是一种方案就可以解决的，它是一种长期的过程所有应用数据质量管理应当和应用系统的开发、升级、维护相整合，不断地进行系统的质量问题回馈，以增进应用系统的数据质量控制能力，将提高应用系统对数据质量的控制能力作为一种长期的渐进发展过程 1.4 应用系统数据管理1.4.1 现状描述应用系统的数据维护是指应用系统为保证数据一致性和解决效率，对系统中数据的维护功能，重要涉及：- 业务规则校验- 数据合法性定期扫描和错误数据清理- 系统上线时的数据转换方案通过调查，我们发现核心业务系统在上述方面最具有代表性，因此，如下重要以核心业务

25、系统为例，阐明目前中国人寿应用系统数据维护方面的现状。1.4.1.1 应用系统数据维护 CBPS应用系统数据维护描述： 业务逻辑控制（数据校验）- 不容许为空数据的强制录入控制- 业务规则校验- 变化幅度异常的数据目前的应用系统中上述方面比旧系统相对好某些，但在以往的应用系统由于需求定义不完善的因素，存在由于上述控制不完善导致的非正常数据。 数据扫描和一致性校验（举例阐明）- 应用系统没有错误数据清理工具；- 没有实行例行检查操作,积极发现系统中的数据错误； 错误数据清理- 目前没有应用系统自动的错误数据报警和清理功能；- 错误数据清理仍是相称艰巨的工作；- 部分分公司做了错误数据清理工作；

26、历史数据卸载- 系统设计时没有考虑历史数据卸载筹划、 卸载机制；- 缺少历史数据卸载这方面的知识和经验； 直接后台修改- 系统中存在错误数据，导致前台无法正常操作，需要后台修改。这部分比重相对较大；- 由于某些功能程序不支持，需要后台修改.；- 后台修改一般采用会办单的形式流转；- 复杂问题的诊断，较为谨慎的做法是在测试库上模拟验证； 系统升级和迁移- 系统升级和迁移频繁；- 升级和迁移时缺少良好的测试，导致浮现操作不正常，以及数据错误。 上海应用系统数据维护描述： 业务逻辑控制（数据校验）- 不容许为空数据的强制录入控制既有系统对数据录入的控制较严格，目前存在的某些数据字段为空的因素是由于历

27、史数据缺失，或者过去业务需求定义时没有规定强制录入。- 业务规则校验目前存在的业务规则校验问题重要是： 历史数据没有满足业务规则，因此移入时就不对的； 应用程序中存在的BUG，导致业务规则校验没有被100地实现；- 变化幅度异常的数据目前系统中存在某些数据满足规则但不合理的现象，如投保年龄超过条款规定的因素，也许是根据业务特批进行的操作。 数据扫描和一致性校验应用系统后台后台配备有审计程序，定期运营，根据规则搜索异常数据，查找因素并解决。 错误数据清理目前对错误数据的清理基本是管理员手工执行：如果是生产系统数据有错，尽量修改；如果缺失没法补，则放弃对该错误的修改。 历史数据卸载最初的系统设计未

28、考虑这个问题。目前准备将某些表按规则拆分，但需要应用系统中的某些程序调节（例如由于表分拆，原先的查询程序需要作相应的修改），必须统一考虑。 直接后台修改目前应用系统中的直接后台修改集中在团险领域，由于团险协商状况较多，系统不能接受。解决措施是：由业务做批示，开发人员写脚本，提交运营人员执行，将数据导入； 系统升级和迁移一般不删除旧表或旧字段。升级时写好脚本，并测试。 江苏应用系统数据维护描述 业务逻辑控制（数据校验）- 不容许为空数据的强制录入控制既有系统对数据录入的控制较严格，目前存在的某些数据字段为空的因素是由于历史数据缺失，或者过去业务需求定义时没有规定强制录入。- 业务规则校验目前存在

29、的业务规则校验问题重要是：历史数据没有满足业务规则，因此移入时就不对的；- 变化幅度异常的数据目前系统中存在某些数据满足规则但不合理的现象，如投保年龄超过条款规定的因素，也许是根据业务特批进行的操作。 数据扫描和一致性校验- 根据业务需求的业务规则不定期搜索异常数据，查找因素并解决。 错误数据清理- 目前对错误数据的清理基本是业务手工执行：如果是生产系统数据有错，尽量修改；如果缺失没法补，则放弃对该错误的修改并备案。 历史数据卸载- 部分历史数据如收付费,台帐信息有卸载机制 直接后台修改- 业务流程容许的数据修改外数据维护直接后台修改。 系统升级和迁移- 一般不删除旧表或旧字段。升级时写好脚本

30、，并测试。 深圳应用系统数据维护描述： 业务逻辑控制（数据校验）- 不容许为空数据的强制录入控制由于我司的核心业务系统Lifepro为新开发系统，设计时对新数据录入的规定相称严格，数据为空将无法继续完毕业务流程，并给出错误提示。目前存在的某些数据字段为空的重要因素是由于历史数据缺失，或者过去业务需求定义时没有规定强制录入，或者是在数据迁移时强行相应字段。- 业务规则校验目前存在的业务规则校验问题重要是：历史数据没有完全满足业务规则，迁移时就无法进行严格匹配；- 变化幅度异常的数据虽然对业务数据进行了严格控制，但偶有业务特批现象，这使得目前系统中存在某些数据满足业务规则但不合理的现象。 数据扫描

31、和一致性校验应用系统后台基本上没有进行数据扫描和一致性校验。 错误数据清理我司在转换系统时曾经进行过大规模错误数据清理，但是平时基本上没有专门的此项工作。 历史数据卸载最初的系统设计没有考虑这个问题，有待完善。 直接后台修改目前核心业务系统中的直接后台修改重要集中在业务反向操作和补入有关记录。解决措施是：由业务人员谢工作单，通过Lotus工作单流转（严格执行层层审批制度），再由开发人员写脚本，提交运营人员执行，完毕后台修改； 系统升级和迁移深圳分公司新开发的核心业务系统Lifepro的数据架构为全新设计，在新系统交接之前，投入大量人力物力进行数据迁移和测试工作。基本措施是先写好数据迁移脚本并执

32、行，再进行数据校验和测试。1.4.1.2 既有数据库平台基本上，目前所有的重要应用系统所有使用Informix作为数据库平台；少量的支持性应用（如网站等）使用MS SQL Server，上海采用DB2作为数据仓库平台。顾客对数据库平台的评价如下图所示：图 16 既有数据库平台评价从上图看到，顾客对Informix数据库管理系统的综合评价基本处在可接受的状态，因此可以觉得，目前Informix在中国人寿的运营状况较为平稳。从目前的使用状况来看，Informix存在如下问题： 产品供应商支持能力弱； 从发展的角度看，由于系统不再更新，技术水平和性能都将逐渐落后；综合上述现状和问题，我们初步觉得，将

33、系统迁移到其她数据库平台是必然的趋势，由于目前Informix的运作正常，整个移植筹划周期可以根据IBM对Informix支持的周期以及新的应用系统开发筹划来拟定，而不必急于立即实行应用系统的迁移改造。1.4.1.3 既有数据访问权限控制 权限管理状况综述图 17 既有数据访问权限控制调查图 18 既有系统审计功能调查从上述两个记录图可以看出，目前数据库和应用系统的数据访问控制已经可以满足顾客的需求，总体的评价较好。并且具有了某些审计功能。而另一方面，从应用数据的角度，中国人寿缺少一套完整的数据访问审计机制，由于审计和系统效率以及管理工作量之间存在的矛盾平衡关系，因此需要对审计功能进行总体的评

34、估，即从业务风险控制和系统管理的角度，划分需要审计的操作环节，并将其作为应用开发和系统管理的重要构成部分。 CBPS数据访问权限控制描述： 基于应用系统的访问权限- 应用系统有独立的权限管理功能- 权限的划分一般基于功能进行划分- 管理：波及到客户的某些重要信息控制不是很严，例如帐户信息等。业务上也没有这方面的规定和规定 管理员权限管理- 权限管理职责所属部门无统一规定（授权人）- 注重权限的增长，往往忽视操作员岗位变动或离司后权限的更新 审计- 无进入，退出系统的日记记录和监控机制- 重要数据访问、修改的轨迹较难追踪- 部分数据的产生无时间戳 上海系统数据访问权限控制现状描述： 基于应用系统

35、的访问权限- 操作员通过操作系统顾客登录，往往使用同一种顾客- 数据库中设立不同操作系统顾客对数据的访问权限，一般所有都放开- 操作员登录后直接进入应用系统画面，中断后也直接logout- 应用系统中，对各类操作员、各项功能分别设立使用权限 管理员权限管理- 应用系统权限设立功能委派专人负责，也许是IT人员，也也许是业务人员- 人力资源部负责统一清理岗位权限：整顿公司既有员工序号，设立岗位，整顿各岗位可以使用的业务系统清单和系统中的功能清单，然后统一设立 审计- 某个功能进入和出去的时间和操作员信息有日记记录，对数据实行了哪些操作则无- 操作员的增长、销户、对某个功能使用权的增减，此类操作管理

36、部门往往控制不严 江苏系统数据访问权限控制现状描述： 基于应用系统的访问权限- 有安全管理功能,提供系统运营各项操作的安全级别设立和管理- 特点:可以定义操作员对业务解决系统十一种子系统的操作权限级别，共有110共十个级别可以设立不同的操作权限; 各级别之间相对独立，不互相涉及 管理员权限管理- 应用系统权限设立功能委派专人负责，是业务人员- 业务解决中心和财务解决中心负责统一清理岗位权限，设立岗位，整顿各岗位可以使用的业务系统清单和系统中的功能清单，然后统一设立 审计- 某个功能进入和出去的时间和操作员信息没有日记记录，对数据实行了哪些操作则无- 操作员的增长、销户、对某个功能使用权的增减，

37、此类操作管理部门往往控制不严 深圳系统数据访问权限控制描述 基于应用系统的访问权限- 前台操作员通过个人帐户和密码登录核心业务系统- 数据库中设立不同业务系统顾客对数据和业务模块的访问权限，这样顾客只能看到已分派的业务模块界面，并使用已分派的系统功能- 操作员登录后直接进入应用系统画面，中断后也直接退出系统 管理员权限管理- 应用系统权限设立功能委派IT人员专人负责- 个人若申请权限，需要通过工作流层层审批后，由IT人员负责设立 审计- 当顾客使用某个功能或者进行什么操作，其进入和出去的时间和操作员信息有日记记录- 有些操作的轨迹没有时间戳和人员记录1.4.2 差距分析1.4.2.1 顾客盼望

38、的状况 加强业务需求定义的完整性，提高应用系统对业务数据的控制能力； 增强应用系统的维护功能，提高系统维护的自动化限度，减少系统维护工作量； 加强后台数据的访问修改权限控制机制，并不局限于应用系统和数据库系统，还可以通过规章制度来配合管理；1.4.2.2 差距及因素编号ID观测Observation主线因素Root Cause影响范畴Impact改善建议ActionD.04.1应用系统的非功能性规定较弱应用系统的技术设计局限性所有应用系统将技术设计作为应用开发的重要部分，并在验收时进行严格测试D.04.2Informix数据库平台不再进化，难以支撑将来应用Informix属于将被逐渐裁减的平台

39、所有基于Informix的应用向其她数据库平台迁移D.04.3信息的权限控制不严谨注重功能操作权限控制，忽视了数据访问权限的控制所有应用系统将信息安全控制和数据保护作为应用系统开发中数据模型设计的一部分工作，信息安全的设计应当以数据访问控制为单位，而不是仅以应用系统功能执行权限为单位；1.5 数据架构评估总结 中国人寿数据架构是一种典型的迅速IT建设模式的成果，其重要体现为以迅速实现功能为重要目的，缺少统一的、有筹划的规划，缺少统一的公司级数据原则； 在业务集成度规定不断提高的压力下，目前数据架构重要的局限性就是缺少整体性，各应用系统间的数据集成度太低； 由于历史因素和应用开发缺少技术设计，导致数据质量和数据管理都处在较为低水平的阶段，即只能满足局部或临时的功能需求，而缺少整体的控制，其成果就是导致数据难以支撑强大的共享、监控、决策功能，影响了业务的运营和发展； 这里需要指出，数据架构的完善、数据质量和数据管理水平的提高，是一种长期渐进的过程：根据业务人员实际操作的反馈，而不断地改造应用系统和有关的数据架构，从而不断进化的螺旋式上升过程； 对于目前的数据库平台的移植已经是一种必然的规定，由于目前在中国人寿Informix的运营和维护都处在较为稳定的状态，因此，我们初步觉得：整个移植的时间周期可以根据新系统的开发筹划和IBM对Informix支持的周期来拟定。