数据架构调研与评价报告分析

1、1 .数据架构调研与评估省银保通11a_ 一CLAF J统计报表统计报表保单及财务统计报表 )基础信息系统1.1. 总体数据架构现状 上图摘自中国人寿应用系统介绍及计划，它描述了整个中国人寿主要的应用系统间的关联和数据交换，从总体上看来，中国人寿：?基本实现了业务信息的电子化，绝大多数业务处理都 有应用系统支持；?主要的业务功能区域（如寿险实务、财务经管等）的 信息处理都有较为成熟的应用架构和数据架构；?各个应用系统之间可以利用数据文件进行数据交换， 实现了信息的传递和共享；?银保通系统能够实现和银行间的实时数据交换；?基于数据库技术的信息处理体系基本成熟；?初步建立了以中间库为基础的数据交换

2、平台，并基于它实现了企业数据综合查询统计功能；?初步建立了以统计报表工具为手段的数据统计和报表 系统；?财务系统利用了数据仓库技术和SAS工具进行数据分析，除此之外，诸如上海还建立了自己的数据仓库系统；?基于NOTES的消息系统支持了公司的日常信息沟通工作；?基于影像技术的非结构化数据正在一些分公司使用， 并逐步推广。1.1.1, 数据模型和应用的相关性?以应用为划分的“烟囱”结构，数据基于应用，并被锁定在应用系统中- 数据并没有被作为一个单独的IT组成部分被规划和设计，而是作为应用系统的一部分，由于应用系统的供应商不同，并且其设计工作也缺 乏相互之间的协调，因此，数据模型基本按照各个应用系统

3、的功能需求进行设计和实现；- 由于缺乏有效的数据共享，一个应用所需的数据无法从相关的其他应用系统中获得（如AMIS需要从CBPS获取客户数据），而只好重复录入；- 另一方面，由于同一个数据可能存在多个数据源（从多个应用系统中被重复录入），由此导 致了信息的不一致。?结构化数据基本上都利用数据库技术实现，非结构化 数据只有少数地方使用影像技术实施了电子化，从应 用程度上两者之间的集成度不高，影像工作流技术和 其他应用系统之间没有能够做到无缝联接。?缺乏自动化和实时的数据交换- 以数据文件交换为主要手段?现有的数据交换方式通常是从一个应用中 将数据导生到平台文件中，再传递到目标 平台并并导入到目标

4、应用系统中；?由于大批量的数据抽取工作会影响到正常 的业务处理效率，因此通常的数据抽取都 被设定在在晚间进行，所以数据的时效性 较差（通常都在一天左右）。- 数据交换过程缺乏严格的数据校验、过程控制 等?接口数据的错误经常是在导入目标系统时 才发现，而不是作为系统数据质量控制的 一部分，预先在源系统中进行合法性校 验；?数据交换的过程缺乏技术性控制：诸如大 批量数据分割、数据传输的校验、重复操 作的处理、操作回滚等。?对不同版本或开发商的同一应用，缺乏统一规定的应用系统数据外模式- 例如业务处理系统，总颁系统 CBPS和深圳、 江苏、上海的系统对外的数据模式和接口都不相同，和其他应用系统（如

5、CLAF ）的接口需要 各自编写相应的接口软件来实现。1.1.2,数据物理层次和数据提升（staging ）?事务（transaction ）处理层数据- 应用系统中存储了完整的、原始的事务处理数据；- 应用系统中的主要事务处理数据都具备时间戳 等增量识别标志；- 没有后备系统存储离线历史数据；- 数据分布在各个省公司或地市公司的应用系统中，多数省份实施的是服务器的物理集中；?数据集成平台- 缺少完整统一的集成平台来集成各应用中的数 据，建立企业级信息视图?轻度统计汇总数据- 利用应用系统自身的报表功能和统计功能实现；- 地市级的IT人员完成了一定的查询和报表开发 工作，以满足业务部门的小规模

6、要求；- 对于应用系统中没有的报表，利用手工（ UTAB 或EXCEL ）实现；- 总公司层面缺乏对轻度汇总数据的全面集成；?高度汇总数据- 应用系统中具备部分高度汇总统计功能；- 对于应用系统中没有的报表，利用手工（ UTAB 或EXCEL ）实现；- 由于手工工作太多，人为因素影响了数据的完 整性和准确性，使得数据准确性和可信度不够 高；?决策支持模型- 缺乏灵活的系统统计分析功能；-缺乏企业级统一的数据平台，从而也就无法建 立企业级的决策支持分析模型；-目前的SAS系统主要基于财务数据的分析。1.1.3,用户期望?未来信息系统必须有长远规划，可支持多种经管模 式；?加强信息系统的整合，建

7、立对内对外信息披露的统一 的、高效的平台，满足业务经管、销售支持、决策分 析等各方面需要；?系统建设要面向客户和市场，支持业务流程和经管优 化，支持应用系统在不同用户界面或渠道的拓展，如 Internet、电话、多媒体终端等；?充分利用录入的原始数据，提供丰富的、方便的统计 查询及分析功能；指导我们的经管工作；业务处理和 行政经管规范化、自动化、流程化、无纸化；另外， 通过信息系统建立预警机制，加强业务监控；?信息系统由封闭走向开放，将员工、客户、业务员、 代理机构、合作伙伴有机结合起来。?用户认为目前信息系统距离业务需求的差距（优先级）从上图中可以看由，目前的应用系统信息处理 效率不高是用户

8、反映最多的问题，其次是信息量不 丰富和准确性不够。因此，上述各项中，建立高效 的数据处理应用系统和统一集成的数据整合平台是 用户的重点期望。1.1.4,初步的差距分析编 号 ID观察Observation根本原因 RootCause影响范 围Impact紧急程 度Urgenc y改进建议Action04.整个信息系没有总体所有应紧急定义业务处理1统缺乏总体的业务信用的信息流，在性，数据接息流的定此基础上定义口设计、开义，从而信息系统的数编 号 ID观察Observation根本原因Root Cause影响范 围Impact紧急程 度Urgenc y改进建议Action发、维护、 升级等工作 复

9、杂无法进行 总体的数 据流设计据流，统一应 用间数据交换 定义O4.企业级总体没有总体业务监紧急分阶段建立企2监控信息难 以获取，时 效性差数据架构 规划没有建立 数据提升 系统控、经 管和决 策业级统一的数 据平台(One- View ), 包 括：基础数据 平台、各汇总 层次数据、决 策支持模型04.信息系统的旧的业务所有业紧急建立以客户为3组织和设计 是面向业务 流程处理 的，而不是 以客户为中 心的经管模式 是面向处 理流程的务经管 和客户 服务中心的业务经 管和客户服务 模式，在此基 础上按照CRM 的理念改造现 有信息系统1.2, 数据规范化经管1.2.1, 中国人寿数据规范化现状

10、?基本上所有的业务和IT人员都充分认识到数据规范化对业务的重要性，但往往数据规范化被认为是IT部门的工作，而忽视了建立数据规范化的基础：业 务信息定义的规范化；?但实际上，除了部分代码规范是总公司下发的以 外，业务部门并没有统一制定业务信息的规范定 义，因此，IT部门也就缺乏必要的、统一的依据来 制定数据规范；?从组织保证上，并没有一个指定的团队来负责业务 信息乃至数据定义的规范化工作；?各应用系统的开发商不同，而中国人寿对各供应商 在数据规范化上也无法进行有效的控制，导致所遵 循的数据规范不统一；?由于总颁应用系统普及面较广，对莫一个具体的业 务应用来讲，使用该应用系统的数据规范基本是统 一

11、的。1.2.2, 现有数据规范制定和经管制度?数据规范的制定由应用系统开发商负责，而不是由一个独立的数据规划部门负责;开发商遵循自己的数据规范制定流程进行经管，基本属于开发经管的范畴，而不是IT经管和规划的范畴；现行的数据经管是面向最终数据结果（如统计报表、精算数据准备等）的，而忽视了数据定义和处 理的规范化，各地对同一个名词的理解和定义可能 都不相同。1.2.3.用户期望?对业务的重要性：在对现状调研的过程中，无论是业务人员还是IT人员，所有的受访者都一致认为信息规范化程度对业务是非常重要的。?业务信息规范化的优先级：上图是业务人员对信息规范化优先级的反馈统计，而从IT人员的反馈来看，唯一的

12、区别是他们认为最优先的应当是业务操作过程信息：综合业务和IT人员的看法，我们可以认为，保单信 息、客户信息和业务操作过程信息是当前最迫切的 规范化需求，也是进行数据整合是实施数据清理的 重点工作。?信息规范无法贯彻的原因:数据标准无法贯彻的原因厂不适应业务需要额外增加工作量，降低 效率没有标准的管理制度来 保证实施一各应用系统供应商不同由上图可以看生，几乎所有的受访者都不认为规范化不 适应业务需要或会导致工作量增大，而认为规范无法贯彻 的原因是没有经管制度；因此，我们初步认为，中国人寿 有着很好的规范化实施基础，而制定和贯彻规范化经管制 定是这项工作的重点突破口。1.2.4,初步的差距分析编

13、号ID观察Observatio n根本原因Root Cause影响范 围Impact紧急程 度Urgenc y改进建议Action04.1应用间甚至 业务功能和 部门间信息 沟通复杂没有统一 数据规范所有紧急建立统一的业 务信息规范， 并在此基础上 建立统一的数 据规范O4.2数据规范的 贯彻能力弱缺乏授权 的流程的所有紧急建立数据规范 的制定、发编 号ID观察Observatio n根本原因Root Cause影响范 围Impact紧急程 度Urgenc y改进建议Action制度保证 规范的贯 彻布、维护流 程，并建立定 期审计制度； 严格控制应用 开发的数据规 范，将其作为 开发工程验收

14、 条款的一部分1.3, 数据质量经管1.3.1, 现有主要业务支撑系统见应用系统评估部分1.3.2, 数据质量控制1.3.2.1, 现有数据质量问题现有的数据质量问题主要表现在：?相对于新的业务应用系统来说，老业务数据不完整，导致系统升级和移植后，数据质量不能达到新应用系统的要求；?系统校验控制不严谨或 BUG导致的数据错?经管员为保证业务的运行，在取得授权的情况下， 直接修改数据库后台数据，由于对应用系统的熟悉 程度的差异，导致由现数据不一致；?升级和移植过程中数据转换或迁移操作错误，导致 的数据错；1.3.2.2, 数据质量经管现状?现行的数据质量规范- 中国人寿没有全公司范围的数据质量考

15、核体系，现行的数据质量评价主要通过以下几方面进行：?业务考核或报告中，数据统计的准确度和 完整性；?应用系统运行时所执行的业务逻辑校验；?数据交换时的合法性检查；?现有的数据质量控制方法- 应用系统所实现的校验逻辑和业务规则；- 数据交换时的合法性检查；- 应用系统间的数据对照；?现行的数据质量经管制度缺乏完善的对数据录入人员的数据质量考核体系；- 缺乏对开发过程的数据规范化控制；- 缺乏系统上线流程中的数据迁移经管；- 缺乏对应用系统运行过程中的数据质量审计和 考核体系。?现行的数据质量经管工具- 现行的数据质量经管工具主要是为数据接口所 开发的校验程序，用于发现交换数据的错误；- 由于没有

16、企业级统一的数据平台，因此，也就 没有全司范围的数据质量监控和数据自动修正 工具。1.3.3,初步的差距分析编 号ID观察Observat ion根本原因Root Cause影响 范围 Impact紧急 程度 Urgency改进建议Action04 ,1现有历史 数据质量 无法满足 以客户为由于业务 需求和应 用逻辑定 义不完所有紧急在建立以客户为中心 的业务模型的基础 上，尽量补齐或修正 所需的客户信息和相编 号 ID观察Observat ion根本原因 RootCause影响 范围 Impact紧急 程度 Urgency改进建议Action中心的要 求善，导致 历史数据 不完整缺乏完善 的

17、数据质 量考核体 系关交易信息；对无法补齐或修正的 数据，发布数据质量 报告，明确告知最终 用户；对于现在后今后产生 的数据，建立严格的 数据质量考核体系， 加强应用操作，尤其 是数据录入的监督O4 .2系统升级 越频繁， 数据质量 越差系统开发 缺乏严格 的测试， 导致BUG 引发的数 据错误 系统升级 时没有系 统地考虑 数据地迁 移和转换系统 升级 和维 护紧急建立需求部门负责把 关的严格的测试体 系，对应用系统 引入解决技术方案部 署过程(Solution ArchitectureandInfrastructureDesign ),保证系统 升级过程更加系统和 完善。将系统的部署或升级

18、 技术方案作为应用开 发验收的一部分04 .3经管员人 为修改导 致数据质 量下降业务需求 定义不完 善应用系统 不灵活经管员对系统 维护建立统一的数据直接 修改流程，严格控制 直接后台修改的授 权、修改方法和测试编 号ID观察Observat ion根本原因Root Cause影响 范围 Impact紧急 程度 Urgency改进建议Action应用系统 处理过程 及表之间 的参照关 系不熟悉1.4, 应用系统数据经管1.4.1, 应用系统数据维护1.4.1.1. CBPS应用系统数据维护描述：?业务逻辑控制（数据校验）- 不允许为空数据的强制录入控制- 业务规则校验- 变化幅度异常的数据目

19、前的应用系统中上述方面做的比较好，但在以 往的应用系统由于需求定义不完善的原因，存在由于 上述控制不完善导致的非正常数据。?数据扫描和一致性校验-应用系统没有的错误数据清理工具；-没有实施例行检查操作，把正常情况下要到今后莫一时刻才反映由问题的数据（如接口异常），再提前找由来处理掉；?错误数据清理-目前没有应用系统自动的错误数据报警和清理功能；-错误数据清理仍是相当艰巨的工作；-部分分公司做了错误数据清理工作；?历史数据卸载-系统设计时没有考虑历史数据卸载计划、卸载机制；-缺乏历史数据卸载这方面的知识和经验；?直接后台修改-系统中存在错误数据，导致前台无法正常操作，需要后台修改。这部分比重相对

20、较大；-由于莫些功能程序不支持，需要后台修改.；-后台修改一般采用会办单的形式流转；- 复杂问题的诊断，较为慎重的做法是在测试库 上模拟验证；?系统升级和迁移- 系统升级和迁移频繁；- 升级和迁移时缺乏良好的测试，导致由现操作 不正常，以及数据错误。1.4.1.2,上海应用系统数据维护描述：?业务逻辑控制（数据校验）- 不允许为空数据的强制录入控制现有系统对数据录入的控制较严格，目前存 在的莫些数据字段为空的原因是由于历史数 据缺失，或者过去业务需求定义时没有要求 强制录入。- 业务规则校验目前存在的业务规则校验问题主要是：I.历史数据没有满足业务规则，所以移 入时就不正确；II.应用程序中存

21、在的 BUG ,导致业务规则校验没有被100 %地实现;- 变化幅度异常的数据目前系统中存在莫些数据满足规则但不合理的现象，如投保年龄超过条款规定的原因，可能是依据业务特批进行的操作。?数据扫描和一致性校验应用系统后台后台配备有审计程序，定时运行，根据规则搜索异常数据，查找原因并处理。?错误数据清理目前对错误数据的清理基本是经管员手工执行：如果是生产系统数据有错，尽量修改；如果缺失没法补，则放弃对该错误的修改（备案否？）。?历史数据卸载最初的系统设计未考虑这个问题。目前准备将 一些表按规则拆分，但需要应用系统中的一些功能（比如查询作修改？），必须统一考虑。?直接后台修改目前应用系统中的直接后台

22、修改集中在团险领域，由于团险协商情况较多，系统不能接收。处理方法是：由业务做批示，开发人员写脚本，提交运行人员执行，将数据导入；? 系统升级和迁移一般不删除旧表或旧字段。升级时写好脚本，并测试。1.4.2,现有数据库平台基本上，目前所有的主要应用系统全部使用Informix作为数据库平台；少量的支持性应用（如网站等）使用MSSQL Server ,上海采用DB2作为数据仓库平台用户对数据库平台的评价如下图所示：数据库平台评价140120映 反16141001780161440203口易开发易管理口稳定性执行效率n易开发口易管理稳定性口执行效率很好1719一般不好较差从上图看到，用户对 Info

23、rmix数据库经管系统的综合评价基本处于可接受的状态，因此可以认为，目前 Informix 在中国人寿的运行状况较为平稳。从目前的使用情况来看，Informix存在如下问题：?产品供应商支持能力弱；?从发展的角度看，由于系统不再更新，技术水平 和性能都将逐渐落后；综合上述现状和问题，我们初步认为，将系统迁移到其他数据库平台是必然的趋势，由于目前Informix的运作正常，整个移植计划周期可以根据 旧M对Informix的周期来 确定，而不必急于立刻实施应用系统的迁移改造。1.4.3.现有数据访问权限控制1.4.3.1. 权限经管状况综述数据访问权限控制审计完善有部分没有口对数据备份和保存的记录

24、口对数据共享和传递的追踪记录对数据修改的追踪记录口对数据访问的追踪记录从上述两个统计图可以看由，目前数据库和应用系统的数据访问控制已经可以满足用户的需求，总体的评价较 好。并且具备了一些审计功能而另一方面，从应用数据的角度，中国人寿缺少一套完 整的数据访问审计机制，由于审计和系统效率以及经管工 作量之间存在的矛盾平衡关系，因此需要对审计功能进行 总体的评估，即从业务风险控制和系统经管的角度，划分 需要审计的操作环节，并将其作为应用开发和系统经管的 重要组成部分。1.4.3.2. CBPS数据访问权限控制描述：?基于应用系统的访问权限- 应用系统有独立的权限经管功能- 权限的划分一般基于功能进行划分- 涉及到客户的一些重要信息控制不是很严，比 如帐户信息等。业务上也没有这方面的要求和 规定?经管员权限经管- 权限经管职责所属部门无统一规定- 注重权限的增加，往往忽视操作员岗位变动或 离司后权限的更新?审计无进入