数据架构调研与评估报告分析样本

总企业精算系统统括系统总企业精算系统统括系统CLAF统计报表统计报表CLAF银保通精算系统精算系统统计报表CLAFAMISCBPSOBPS保单/用户数据代理人/机构数据收付费数据保单数据收付费数据提取保单数据财务报表统计数据保单及报表基础信息系统业务财务数据保单数据保单及报表财务报表统计数据省企业地市企业准备金准备金准备金总体数据架构现实状况上图摘自《中国人寿应用系统介绍及计划》，它描述了整个中国人寿关键应用系统间关联和数据交换，从总体上看来，中国人寿：基础实现了业务信息电子化，绝大多数业务处理全部有应用系统支持；关键业务功效区域（如寿险实务、财务管理等）信息处理全部有较为成熟应用架构和数据架构；各个应用系统之间能够利用数据文件进行数据交换，实现了信息传输和共享；银保通系统能够实现和银行间实时数据交换；基于数据库技术信息处理体系基础成熟；初步建立了以中间库为基础数据交换平台，并基于它实现了企业数据综合查询统计功效；初步建立了以统计报表工具为手段数据统计和报表系统；财务系统利用了数据仓库技术和SAS工具进行数据分析，除此之外，诸如上海还建立了自己数据仓库系统；基于NOTES消息系统支持了企业日常信息沟通工作；基于影像技术非结构化数据正在部分分企业使用，并逐步推广。数据模型和应用相关性以应用为划分“烟囱”结构，数据基于应用，并被锁定在应用系统中数据并没有被作为一个单独IT组成部分被计划和设计，而是作为应用系统一部分，因为应用系统供给商不一样，而且其设计工作也缺乏相互之间协调，所以，数据模型基础根据各个应用系统功效需求进行设计和实现；因为缺乏有效数据共享，一个应用所需数据无法从相关其它应用系统中取得（如AMIS需要从CBPS获取用户数据），而只好反复录入；其次，因为同一个数据可能存在多个数据源（从多个应用系统中被反复录入），由此造成了信息不一致。结构化数据基础上全部利用数据库技术实现，非结构化数据只有少数地方使用影像技术实施了电子化，从应用程度上二者之间集成度不高，影像工作流技术和其它应用系统之间没有能够做到无缝联接。缺乏自动化和实时数据交换以数据文件交换为关键手段现有数据交换方法通常是从一个应用中将数据导出到平台文件中，再传输到目标平台并并导入到目标应用系统中；因为大批量数据抽取工作会影响到正常业务处理效率，所以通常数据抽取全部被设定在在晚间进行，所以数据时效性较差（通常全部在一天左右）。数据交换过程缺乏严格数据校验、过程控制等接口数据错误常常是在导入目标系统时才发觉，而不是作为系统数据质量控制一部分，预先在源系统中进行正当性校验；数据交换过程缺乏技术性控制：诸如大批量数据分割、数据传输校验、反复操作处理、操作回滚等。对不一样版本或开发商同一应用，缺乏统一要求应用系统数据外模式比如业务处理系统，总颁系统CBPS和深圳、江苏、上海系统对外数据模式和接口全部不相同，和其它应用系统（如CLAF）接口需要各自编写对应接口软件来实现。数据物理层次和数据提升（staging）事务（transaction）处理层数据应用系统中存放了完整、原始事务处理数据；应用系统中关键事务处理数据全部含有时间戳等增量识别标志；没有后备系统存放离线历史数据；数据分布在各个省企业或地市企业应用系统中，多数省份实施是服务器物理集中；数据集成平台缺乏完整统一集成平台来集成各应用中数据，建立企业级信息视图轻度统计汇总数据利用应用系统本身报表功效和统计功效实现；地市级IT人员完成了一定查询和报表开发工作，以满足业务部门小规模要求；对于应用系统中没有报表，利用手工（UTAB或EXCEL）实现；总企业层面缺乏对轻度汇总数据全方面集成；高度汇总数据应用系统中含有部分高度汇总统计功效；对于应用系统中没有报表，利用手工（UTAB或EXCEL）实现；因为手工工作太多，人为原因影响了数据完整性和正确性，使得数据正确性和可信度不够高；决议支持模型缺乏灵活系统统计分析功效；缺乏企业级统一数据平台，从而也就无法建立企业级决议支持分析模型；现在SAS系统关键基于财务数据分析。用户期望未来信息系统必需有长远计划，可支持多个管理模式；加强信息系统整合，建立对内对外信息披露统一、高效平台，满足业务管理、销售支持、决议分析等各方面需要；系统建设要面向用户和市场，支持业务步骤和管理优化，支持应用系统在不一样用户界面或渠道拓展，如Internet、电话、多媒体终端等；充足利用录入原始数据，提供丰富、方便统计查询及分析功效；指导我们管理工作；业务处理和行政管理规范化、自动化、步骤化、无纸化；另外，经过信息系统建立预警机制，加强业务监控；信息系统由封闭走向开放，将职员、用户、员工、代理机构、合作伙伴有机结合起来。用户认为现在信息系统距离业务需求差距（优先级）距业务要求关键差距距业务要求关键差距12149198信息正确性不够可获取信息量不丰富信息录入不方便信息处理效率不高信息查询界面不友好从上图中能够看出，现在应用系统信息处理效率不高是用户反应最多问题，其次是信息量不丰富和正确性不够。所以，上述各项中，建立高效数据处理应用系统和统一集成数据整合平台是用户关键期望。初步差距分析编号ID观察Observation根本原因RootCause影响范围Impact紧急程度Urgency改善提议Action04.1整个信息系统缺乏总体性，数据接口设计、开发、维护、升级等工作复杂没有总体业务信息流定义，从而无法进行总体数据流设计全部应用紧急定义业务处理信息流，在此基础上定义信息系统数据流，统一应用间数据交换定义O4.2企业级总体监控信息难以获取，时效性差没有总体数据架构计划没有建立数据提升系统业务监控、管理和决议紧急分阶段建立企业级统一数据平台（One-View），包含：基础数据平台、各汇总层次数据、决议支持模型04.3信息系统组织和设计是面向业务步骤处理，而不是以用户为中心旧业务管理模式是面向处理步骤全部业务管理和用户服务紧急建立以用户为中心业务管理和用户服务模式，在此基础上根据CRM理念改造现有信息系统数据标准化管理中国人寿数据标准化现实状况基础上全部业务和IT人员全部充足认识到数据标准化对业务关键性，但往往数据标准化被认为是IT部门工作，而忽略了建立数据标准化基础：业务信息定义标准化；但实际上，除了部分代码标准是总企业下发以外，业务部门并没有统一制订业务信息标准定义，所以，IT部门也就缺乏必需、统一依据来制订数据标准；从组织确保上，并没有一个指定团体来负责业务信息乃至数据定义标准化工作；各应用系统开发商不一样，而中国人寿对各供给商在数据标准化上也无法进行有效控制，造成所遵照数据标准不统一；因为总颁应用系统普及面较广，对某一个具体业务应用来讲，使用该应用系统数据标准基础是统一。现有数据标准制订和管理制度数据标准制订由应用系统开发商负责，而不是由一个独立数据计划部门负责；开发商遵照自己数据标准制订步骤进行管理，基础属于开发管理范围，而不是IT管理和计划范围；现行数据管理是面向最终数据结果（如统计报表、精算数据准备等），而忽略了数据定义和处理标准化，各地对同一个名词了解和定义可能全部不相同。用户期望对业务关键性：在对现实状况调研过程中，不管是业务人员还是IT人员，全部受访者全部一致认为信息标准化程度对业务是很关键。业务信息标准化优先级：上图是业务人员对信息标准化优先级反馈统计，而从IT人员反馈来看，唯一区分是她们认为最优先应该是业务操作过程信息：综合业务和IT人员见解，我们能够认为，保单信息、用户信息和业务操作过程信息是目前最迫切标准化需求，也是进行数据整合是实施数据清理关键工作。信息标准无法落实原因：由上图能够看出，几乎全部受访者全部不认为标准化不适应业务需要或会造成工作量增大，而认为标准无法落实原因是没有管理制度；所以，我们初步认为，中国人寿有着很好标准化实施基础，而制订和落实标准化管理制订是这项工作关键突破口。初步差距分析编号ID观察Observation根本原因RootCause影响范围Impact紧急程度Urgency改善提议Action04.1应用间甚至业务功效和部门间信息沟通复杂没有统一数据标准全部紧急建立统一业务信息标准，并在此基础上建立统一数据标准O4.2数据标准落实能力弱缺乏授权步骤制度确保标准落实全部紧急建立数据标准制订、公布、维护步骤，并建立定时审计制度；严格控制应用开发数据标准，将其作为开发项目验收条款一部分数据质量管理现相关键业务支撑系统见应用系统评定部分数据质量控制现有数据质量问题现有数据质量问题关键表现在：相对于新业务应用系统来说，老业务数据不完整，造成系统升级和移植后，数据质量不能达成新应用系统要求；系统校验控制不严谨或BUG造成数据错。管理员为确保业务运行，在取得授权情况下，直接修改数据库后台数据，因为对应用系统熟悉程度差异，造成出现数据不一致；升级和移植过程中数据转换或迁移操作错误，造成数据错；数据质量管理现实状况现行数据质量标准中国人寿没有全企业范围数据质量考评体系，现行数据质量评价关键经过以下几方面进行：业务考评或汇报中，数据统计正确度和完整性；应用系统运行时所实施业务逻辑校验；数据交换时正当性检验；现有数据质量控制方法应用系统所实现校验逻辑和业务规则；数据交换时正当性检验；应用系统间数据对照；现行数据质量管理制度缺乏完善对数据录入人员数据质量考评体系；缺乏对开发过程数据标准化控制；缺乏系统上线步骤中数据迁移管理；缺乏对应用系统运行过程中数据质量审计和考评体系。现行数据质量管理工具现行数据质量管理工具关键是为数据接口所开发校验程序，用于发觉交换数据错误；因为没有企业级统一数据平台，所以，也就没有全司范围数据质量监控和数据自动修正工具。初步差距分析编号ID观察Observation根本原因RootCause影响范围Impact紧急程度Urgency改善提议Action04.1现有历史数据质量无法满足以用户为中心要求因为业务需求和应用逻辑定义不完善，造成历史数据不完整缺乏完善数据质量考评体系全部紧急在建立以用户为中心业务模型基础上，尽可能补齐或修正所需用户信息和相关交易信息；对无法补齐或修正数据，公布数据质量汇报，明确通知最终用户；对于现在后以后产生数据，建立严格数据质量考评体系，加强应用操作，尤其是数据录入监督O4.2系统升级越频繁，数据质量越差系统开发缺乏严格测试，造成BUG引发数据错误系统升级时没有系统地考虑数据地迁移和转换过程系统升级和维护紧急建立需求部门负责把关严格测试体系，对应用系统引入处理方案布署过程（SolutionArchitectureandInfrastructureDesign），确保系统升级过程愈加系统和完善;将系统布署或升级方案作为应用开发验收一部分04.3管理员人为修改造成数据质量下降业务需求定义不完善应用系统不灵活管理员对应用系统处理过程及表之间参考关系不熟悉系统维护通常建立统一数据直接修改步骤，严格控制直接后台修改授权、修改方法和测试过程应用系统数据管理应用系统数据维护CBPS应用系统数据维护描述：业务逻辑控制（数据校验）不许可为空数据强制录入控制业务规则校验改变幅度异常数据现在应用系统中上述方面做比很好，但在以往应用系统因为需求定义不完善原因，存在因为上述控制不完善造成非正常数据。数据扫描和一致性校验应用系统没有错误数据清理工具；没有实施例行检验操作,把正常情况下要到以后某一时刻才反应出问题数据(如接口异常)，再提前找出来处理掉；错误数据清理现在没有应用系统自动错误数据报警和清理功效；错误数据清理仍是相当艰巨工作；部分分企业做了错误数据清理工作；历史数据卸载系统设计时没有考虑历史数据卸载计划、卸载机制；缺乏历史数据卸载这方面知识和经验；直接后台修改系统中存在错误数据，造成前台无法正常操作，需要后台修改。这部分比重相对较大；因为一些功效程序不支持，需要后台修改.；后台修改通常采取会办单形式流转；复杂问题诊疗，较为慎重做法是在测试库上模拟验证；系统升级和迁移系统升级和迁移频繁；升级和迁移时缺乏良好测试，造成出现操作不正常，和数据错误。上海应用系统数据维护描述：业务逻辑控制（数据校验）不许可为空数据强制录入控制现有系统对数据录入控制较严格，现在存在一些数据字段为空原因是因为历史数据缺失，或过去业务需求定义时没有要求强制录入。业务规则校验现在存在业务规则校验问题关键是：历史数据没有满足业务规则，所以移入时就不正确；应用程序中存在BUG，造成业务规则校验没有被100％地实现；改变幅度异常数据现在系统中存在一些数据满足规则但不合理现象，如投保年纪超出条款要求原因，可能是依据业务特批进行操作。数据扫描和一致性校验应用系统后台后台配置有审计程序，定时运行，依据规则搜索异常数据，查找原因并处理。错误数据清理现在对错误数据清理基础是管理员手工实施：假如是生产系统数据有错，尽可能修改；假如缺失没法补，则放弃对该错误修改（立案否？）。历史数据卸载最初系统设计未考虑这个问题。现在准备将部分表按规则拆分，但需要应用系统中部分功效（比如查询作修改？），必需统一考虑。直接后台修改现在应用系统中直接后台修改集中在团险领域，因为团险协商情况较多，系统不能接收。处理方法是：由业务做指示，开发人员写脚本，提交运行人员实施，将数据导入； 系统升级和迁移通常不删除旧表或旧字段。升级时写好脚本，并测试。现有数据库平台基础上，现在全部关键应用系统全部使用Informix作为数据库平台；少许支持性应用（如网站等）使用MSSQLServer，上海采取DB2作为数据仓库平台。用户对数据库平台评价以下图所表示：从上图看到，用户对Informix数据库管理系统综合评价基础处于可接收状态，所以能够认为，现在Informix在中国人寿运行情况较为平稳。从现在使用情况来看，Informix存在以下问题：产品供给商支持能力弱；从发展角度看，因为系统不再更新，技术水平和性能全部将逐步落后；综合上述现实状况和问题，我们初步认为，将系统迁移到其它数据库平台是肯定趋势，因为现在Informix运作正常，整个移植计划周期能够依据IBM对Informix周期来确定，而无须急于立即实施应用系统迁移改造。现有数据访问权限控制权限管理情况综述从上述两个统计图能够看出，现在数据库和应用系统数据访问控制已经能够满足用户需求，总体评价很好。而且含有了部分审计功效。而其次，从应用数据角度，中国人寿缺乏一套完整数据访问审计机制，因为审计和系统效率和管理工作量之间存在矛盾平衡关系，所以需要对审计功效进行总体评定，即从业务风险控制和系统管理角度，划分需要审计操作步骤，并将其作为应用开发和系统管理关键组成部分。CBPS数据访问权限控制描述：基于应用系统访问权限应用系统有独立权限管理功效权限划分通常基于功效进行划分包含到用户部分关键信息控制不是很严，比如帐户信息等。业务上也没有这方面要求和要求管理员权限管理权限管理职责所属部门无