稽核接口程序改造文思创新v.doc

保监稽核检查系统 产品方案 作者： 日期： 审批： 日期： 目录 1 概述 3 1.1 背景 3 1.2 系统实现原则 3 1.3 目标读者及用途 4 1.4 名词解释 4 2 用户及需求分析 5 2.1 系统建设目标 5 2.2 用户 5 2.3 需求分析 5 3 系统架构设计 7 3.1 功能架构 7 3.1.1 基础配置检查 7 3.1.2 稽核数据抽取设置 10 3.1.3 运行监控 10 3.1.4 稽核数据校验 11 3.1.5 质量报告检查 14 3.1.6 查看稽核文件生成 14 3.2 逻辑架构 14 3.2.1 数据源层 15 3.2.2 数据集中 15 3.2.3 数据加工层 15 3.2.4 质量报告检查 15 3.2.5 生成稽核报送数据设置 15 3.3 技术架构 16 3.4 物理架构 17 3.4.1 存储分析 17 3.4.2 性能分析 17 3.4.3 物理架构图 17 4 系统安全性设计 19 4.1 网络安全 19 4.2 系统安全 19 4.3 数据安全 20 4.4 用户权限 21 5 系统备份策略 23 5.1 备份与恢复的范围 23 5.2 备份和恢复策略 23 5.3 完备的备份及恢复机制 24 5.3.1 备份与恢复的范围 24 5.3.2 数据库备份和恢复策略 25 5.3.3 系统备份和恢复策略 27 5.3.4 灾难备份和恢复 28 5.3.5 数据同步 29 6 系统配置 33 6.1 硬件配置 33 7 项目实施 34 7.1 硬件及系统软件费用 34 7.2 实施费用 35 7.3 实施计划 35 概述 背景 为进一步提高保险稽核效率，切实加强数据真实性检查，着力规范保险市场秩序，保监会在2006年保险稽核系统开发使用的基础上，正在开发新一代保险稽核系统，并将于2009年全国现场检查中投入使用。为确保各公司能够按照要求准确提供相关稽核数据，做好现场检查的数据准备工作，各公司应开发相应的接口程序，应满足相关稽核检查的要求. 系统实现原则 业务逻辑的集成原则 任何通用的业务逻辑都只应编写一次 每个ETL处理过程都应考虑到意外情况的处理 松散耦合原则 体系中的组件相互之间也应是松散耦合的，这样有利于组件的扩展 处理过程和数据的归属应有清晰的界定 应用系统的集成应采用标准化的接口来实现 确保数据质量，尤其要充分认识到数据校验的重要性，并有良好的例外处理机制 可扩展原则 系统的每一个步骤都应考虑到将来的发展 定义组件时，应尽可能保证可重用和可扩展 可重用原则 组件化、层次化架构原则 目标读者及用途 本文档将发布给以下人员： 新华人寿保险股份有限公司相关人员 文思创新相关人员 针对目前稽核系统数据质量问题频出，取数效率不高，为之后能提供一个高数据质量的系统，有效的为各公司取数人员及时提供无数据质量问题上报数据编写本文档。本文档旨在解决目前所暴露出的所以数据质量及通过深度测试隐藏的问题，并优化取数效率。通过本次完善与优化达到除业务系统数据本身问题外无其他数据问题，业务系统本身数据原因造成的数据错误有明确的解释文档 名词解释 用户及需求分析 系统建设目标 为了更好、更有效满足各地保监局稽核监管的要求，结合重庆稽核存在的问题，决定启动稽核系统改造工作，同时，对稽核系统提出了更高的目标要求： 平台化：系统设计适应业务发展及公司IT系统不断发展的需要，便于系统扩充，并提供与其他业务系统的应用连接和数据共享同时，功能齐全、方便、实用、形象、操作方便、界面友好采用了参数化和自定义设计的方式，当业务发生变化和改动时，只需对系统参数进行调整即可适用于新的需求提供一个能够让业务部门自行使用的成熟IT系统，形成数据采集、审计监控、问题纠正、数据报送等一套完整稽核流程，避免手工处理工作 总公司：审计部、IT部 分公司： 负责报送的相关人员 需求分析 根据检验程序检验出的数据及以前上报中出现的数据问题对数据提取程序进行完善，目标为除因系统本身数据原因造成的数据质量问题外不再有其他数据错误问题。 因目前核心业务，财务，单证等系统本身的功能的限制,数据结构与保监局要求的数据格式存在差异，达不到上报要求的数据问题，目前无法通过系统改造解决，提供明确详细的解释文档。 总结以往数据错误，做好分类和划分，针对类别快速解决数据错误，提前预备解决方案和解释文档 程序架构：程序架构清晰，具有良好的扩展性和数据错误排查机制。 程序处理效率：采用较先进的数据处理方式，具有较高的系统效率，能够完成1000万级数据的处理。 程序的健壮性：有良好的错误跟踪机制，遇到错误能够生成错误日志，并可以提醒运维人员进行维护。 文档的完善性：有比较好的程序文档，可以对开发和运维进行指导。 对分公司的支持：业务用户