软件工程论文

您当前的位置:学术堂 > 计算机论文 > 软件工程论文 >

保险软件系统整体性和数据一致性研究

来源:学术堂 作者:周老师
发布于:2015-05-26 共3334字
摘要

 我们中国传统文化在思维方式上强调整体性、和谐性和统一性,向来认为整个世界就是一体的,是一个整体,从先秦所说的无限性的所谓天人合一,到宋明的万物一体论都始终如是。像我们的中医理论基本特点就是整体观念,绝非如西医注重局部细节构造,分科细致的头痛医头、脚痛医脚。如我们的古典小说《红楼梦》的整体架构,才能做到草蛇灰线,伏延千里。我们的文化是总到分、大到小、虚到实的,如我们的日期表述是年/月/日,而西方是日/月/年。我们的文化具有很强的扩展性、延伸性、贯通性和包容性,成就我们在世界上唯一延续不断的文明。
 
  而我们各保险公司的软件系统大多如西医,分N多个系统,无论是数据问题还是程序实现或算法问题常常是再保有问题改再保系统、佣金有问题改佣金系统,往往缺乏整体性,用户体验较差,经常需要不断切换页面,且扩展性、延伸性、贯通性和包容性也都相对较差,导致升级频繁(为适应业务或监管变化和新需求,每季度都要大版本升级,每月都有各种补丁包)。
 
  1 从整体性要求来看我们的系统架构和数据一致性
 
  整体性是系统最基本的特性,系统的整体性指系统是作为一个由诸多要素结合而成的有机整体存在并发挥作用的,简单讲就是系统具有其部分在孤立状态下所没有的整体特性。
 
  而我们保险软件系统似乎一体化体系结构还是有些欠缺,虽然核心系统做了集成,整个架构也用SOA面向服务的体系,可是核心不小、外延不大,导致业务处理效率的提高遇到瓶颈。比如简单开发独立的互联网电商应用,然后再做清分,既造成数据冗余,又导致存在总分一致性差异,再花大量人力、物力做一致性差异比对和分析,然后再清分再解决。而随着移动终端的普及,如智能手机和ipad等的应用似乎都在开发或使用中,但基本还是独立的应用系统,让人觉得整体的应用软件参考系统的规划和整体架构设计都做的不够到位。还有就是后续的统计分析明显不足以满足需求,因此全国各分支机构都各显神通,或自行研发,或外包等,做了五花八门的各类分析、考核和决策、预测等相关系统,明显造成重复劳动和资源资金的浪费。
 
  2 数据一致性问题成因
 
  保险的统计报表、财务报表、再保系统、准备金系统、佣金系统等相同口径的东西都金额往往不一。目前保险的软件系统有上百个系统,而各系统大多都存在各自的接口表来相关联,也一样是既造成数据冗余又导致存在一致性差异,然后再花大量人力、物力做一致性差异比对、分析和解释。主要是以下原因导致数据不一:
 
  (1)存在漏、错、重复送接口表的问题(有可能是算法、流程或源代码或网络稳定性等错误导致);(2)电网销、通赔等总分业务也存在漏、错、重复清分的问题;(3)批改算法是否顾及所有系统;(4)数据修正(含修正工具)是否顾及所有系统。而用户常常把数据修正当作是万能的,但这其实是体现我们系统在设计和实现方面的缺陷问题,同时也容易再次导致一致性问题(不可能所有的数据修正软件人员能熟悉上百个系统的数据流程和数据结构)。
 
  3 解决一致性问题及信息整合共享的设想
 
  2014年初为加强保险业公共基础设施建设,全面提升行业经营管理的信息化水平,经国务院批准,中国保险信息技术管理有限责任公司(简称中国保信)成立。
 
  该公司主要业务是建设、运营和管理行业统一的保险信息共享平台,通过信息技术手段,采集保险经营管理数据,建立标准化、系统性的数据体系,为保险业发展和监管提供基础性的网络支持和信息服务。这是一大利好,可以使信息资源能充分整合和共享,减少信息不对称,增加透明度,降低全行业成本,能更准确评估和防范风险,提高业务处理效率和经营管理水平。
 
  个人以为若是由该公司和保监局及保险协会统一一个齐全的最底层维度的数据结构的承保台账表(含手续费和批改),理赔台账表,实收付表和再保分出、摊回表等,然后各保险公司的承保、理赔、出纳和再保等系统往这些全行业统一表写数据(相当于全行业统一的标准的系统性的数据仓库和标准化接口),所有的统计分析及后续的再保、财务、准备金等系统都可从统一表得到数据,这样数据源统一出处,无论公司内部还是全行业都方便分析统计且保证一致性,无论新开发的任何承保、理赔、出纳和再保等相关系统和应用也一样往此数据仓库写数据;而后续的再保、收付费、佣金和再保等系统的承保或理赔信息都可从此采集,无需各自设接口表;等再保、收付费、佣金等系统对承保或理赔处理后再把相关再保和实收付信息的回写该数据仓库和标准化接口。注意该统一数据仓库和标准化接口只可新增不可修改和删除,这样保证同一口径数据在任何时间统计结果都相同,即使用一个中央数据仓库确定特定数据元素的唯一可靠数据源,且要保持非规范化数据的一致性和同步性(当然还要注意日益膨胀导致存储失控的可能)。
 
  再有各种类型的批改若有两种模式,一种面对客户需求或错误导致的外部批改,一种是保险公司内部原因或监管整改导致的内部批改,比如联共保信息的变更或由于保险公司自身问题导致的修正批改,再比如监管整改要求的渠道修正等,这样就无需数据修正,所有的内因修正都走内部批改。这样也能保证以上所说的全行业统一标准数据仓库和标准化接口的准确一致(即不可删除和修改)。
 
  4 小核心大外延的SOA面向服务体系架构设想
 
  其实近十年来我们保险公司IT人员都是在疲于应付,经常加班加点甚至通宵,干得昏天黑地,基本个个早生白发,为适应业务或监管变化和新需求,急于推动各系统的更新换代,执行力超强,各新系统说上线就上线,需求调研、设计、开发和测试、验证等周期都短,整体架构和一体化设计似乎都欠仔细考虑,仓促上线自然导致如上所说升级频繁和大量数据修正。
 
  我们应该努力做到既保证前台交易(用户交互)高响应度(即模型尽量简单,且能应付量大的情况),又要尽量保证后台数据的齐全、完整、真实、准确、可用和一致性(统计和分析等)。我们还应该尽可能实现全组织、全核算和小核心、大外延,这就要求系统之间都是松耦合的,而SOA面向服务的体系结构就是凭借其松耦合的特性,使得我们可以按照模块化的方式来添加新服务或更新现有服务,以解决新的业务需要,提供选择从而可以通过不同的渠道提供服务,并可以把我们现有的或已有的应用作为服务,从而保护了现有的IT基础建设投资。我们应该仔细归纳和整合我们的现有各系统,把它认真划分成哪些是核心系统、哪些是外延系统。然后利用以上所说的标准一体化数据仓库和标准化接口为基础来构建小核心(也就是业务交易核心层)以及大外延(公共服务层和后援服务层)。而现有的业务核心系统往往还包含非常复杂的规则引擎和各种审批流程等,甚至还包含多样的各种查询统计分析计算,这样自然不算小核心,交易速度提高难度大,应该把这些剥离出来,放到大外延的公共服务层或后援服务层,然后通过一些流程总线进行调度。这样就容易通过一些流程配置和调整来实现业务和监管的新需求,大大提高系统的可扩展性和延伸性。
 
  5 现有技术对设想实现的支持
 
  虽然随着经济的发展使保险的复杂度和规模不断上升,互联网和移动终端(如智能手机和ipad等)的普及增加了保险的交易方式和销售渠道,使保险IT复杂度也不断上升,但是大数据、云计算、存储的横向扩展(scale out)等新IT技术发展更是日新月异、突飞猛进,使以上构想有实现的可能,因为大数据非常符合保险数据需求的特性,大数据的特性5V就是数量(海量数据规模)、速度(快速的数据流程和动态的数据体系)、多样性(种类和类型的多样化)、价值和真实性,而我们保险数据就是要如此,也应该呈现完整、真实、透明、一致、永久和公开的特征。而云计算和存储的横向扩展可使海量数据进行高效率获取、存储、挖掘与分析,我们就可cf 内部数据保证数量和质量(可用性和一致性),外部数据尽量多采集和整合,然后内外数据再整合到一起,做到所有数据可管理、分析、分享、可视化。
 
  以上是本人对保险软件系统的整体感和数据的一致性的一些思考,以供同行相关工作者共同探讨。
 
  参考文献
 
  [1] 王和。大数据时代保险变革研究[M].北京:中国金融出版社,2014.
 
  [2] 杨杉,何跃。数据仓库和数据挖掘技术在保险公司中的应用[J].计算机技术与发展,2011,(6)。
 
  [3] 吴晓辉,王新文。信息技术视角下的保险数据真实性管控分析[A].中国保险学会首届学术年会论文集[C].2009.
 
  [4] 夏侯建兵。中国保险业信息化向知识化发展研究[D].厦门大学,2008.
相关内容推荐
相关标签:
返回:软件工程论文