次生代寿险公司的系统需求 - 金融行业 - ITPUB论坛－专业的IT技术社区

wangjia

自加入之日起，全面开放再保险业务，但中外直接保险公司需向中国再保险公司承担分保比例，第一年20％，次年15％，第三年5％，第四年取消。
非寿险比寿险开放幅度大，但健康险、团体险和养老金/ 年金险开放较晚， 承诺三年内开放。
自加入之日起允许外国非寿险公司设持股51％合资公司，可从事统括保单的大型商业险。入世两年内，可独资，并从事个人险。
自加入时起允许外国寿险公司设外资占50％合资企业。
自加入时起，将允许外国保险公司在上海、广州、大连、深圳和佛山提供服务。入世两年内，地域放开至北京、成都、重庆、福州、苏州、厦门、宁波、沈阳、武汉和天津。入世三年内取消地域限制。
另，对外国保险公司有资格限制。
中国于2001 12 11 正式入世，按照中国对外承诺的开放的时间表，在每一个限制取消之前保监会都会新审批一批内资的寿险公司和既有的寿险公司的分支机构以壮大内资保险的力量。所以在中国入世对外承诺的限制取消时间点前后会有一批寿险公司集中获批开业。这样按照入世的时间节奏，从开业时间上来看目前的寿险公司层次分明的分成了两个梯队 01～02年左右开业的寿险公司和05年左右开业的寿险公司。从寿险公司展业模式和实现盈利的过程来看开业时间不同的寿险公司也有着不同的业务目标，从这个层面上我把2000年以后开业的寿险公司分为了两个组，姑且叫做次生代寿险公司和新生代寿险公司。其中次生代寿险公司是以太平人寿、合众人寿为代表的在01－02年真正开展业务的寿险公司。
如前所述寿险公司有自己独特的业务模式和实现盈利的方式，一般的寿险公司从开业到实现盈利会经历7－8年的时间；也就是说一个寿险公司从开业的大概第七年左右公司的经营侧重点可能开始发生一些变化，从而催生一些新的系统需求。
IT永远是为业务服务的，会因为业务的改变而改变，会因为业务的侧重点发生变化而发生侧重点的变化。所以我们需要寻本溯源，去考察一下在实现盈利阶段的寿险公司最注重的是什么东西。
根据个人从网上得来的信息和一些战略咨询公司发布的白皮书的内容我对次生代寿险公司的特点给予以下概括：
1、全国分支机构、网点铺设基本完成，展业的重点由区域拓展转为渠道拓展，新业务渠道成为公司业务的新增长点。
2、战略重心在传统渠道间、传统产品形态之间转移。由于业务规模的拓展对于这个时期的寿险公司来说不再是唯一重要的目标，公司多了实现盈利这样重要的目标，所以在战略重心上面会有银保渠道向个险渠道转移，趸交产品向期交产品转移，储蓄型产品向保障型产品和投资型产品转移的倾向。
3、如何识别、甄选、服务好既有客户成为公司工作的重点，如何从老客户身上发觉新的业务成为业务员展业的重中之重。
4、运营职能的微调，与运营压力的增加。由于次生代的寿险公司一般而言在市场上已经具备一定的规模，相对于新生代寿险公司生存压力会小一些，所以这些公司的契约、核保部门会由原来的最大限度支持业务转变并回归为其原本的职能：做好风险选择，筛选优质客户。由于保单存量的不断阶梯状上升运营流程的后端保全、理赔、续期的工作压力会不断加大。由于需要实现盈利的要求而反应到死差和费差的压力也促使保全、理赔部门必须提高自己的风险管控水平和工作效率。
5、由于业务和实现盈利的双重压力也促使产品设计部门需要设计出易于代理人销售同时又是可以预期盈利的寿险产品，原本在创业初期比较广泛的非常易于销售但盈利预期很低或者预期为负盈利的“敲门砖”类产品会逐渐缩小范围。
根据以上对次生代寿险公司业务层面的特点分析，我预测这类公司在拥有了相对来说比较完善的核心业务系统和ERP系统这些基础性系统之后还会有以下系统层面的需求：
1、新渠道业务支持系统，和为了支持这些系统而需要改进的核心系统的渠道管理模块。这里新渠道业务支持系统的典型的例子是网销系统——这里可能会有朋友用PA18的失败例子来反驳我，我用在长江MBA创业示范课程上听来的一句名言来回答：“领先一步是先驱，领先两步是先烈。”在网上支付手段已经很成熟的今天，在网银账户所有人已经过亿的今天，在网络普通商品销售渠道平台已经很成熟的今天，网络销售平台发展的客观条件已经比较成熟。
2、基于优质客户甄选、客户忠诚度培养的数据挖掘技术和与此相关的客户关系管理系统。目前多数人认为寿险公司的CRM＝呼叫中心，个人觉得这是很片面的看法，在呼叫中心技术日益成熟的今天CRM的执行层面的内容已经不可以让寿险公司展现出任何相对于其它公司的差异化的内容，也不能形成任何的竞争优势；而真正的呼叫的优势应该体现在打通率、到场率，采用什么样的方法把最优质的客户分配给最有经验的人力，呼叫后的结果分析上面。对于CRM系统来说，最为重要的是实现各个角度与层面的“CRM Process Integration”；CRM系统与核心、财务、人管系统的集成（Business Integration），与客户信息、数据挖掘结果、数据仓库等信息的集成（Customer Infomation Integration），与呼叫中心、手机服务、电子邮件等的集成（Touch Point Infrastructure Integration）。
3、以提升寿险公司盈利能力为目的的数据挖掘技术与相关咨询服务，以及基于前者的应用于理赔、保全、新契约、产品设计等部门的风险管控系统或者组件。
4、构建适合保险行业特点的企业服务总线，统筹各个系统的运作，实现系统间数据的统一交互，为SOA奠定基础。例如服务商A为寿险公司T提供了“以提升寿险公司盈利能力为目的的数据挖掘技术与相关咨询服务”这个结果需要通过统一的数据交互渠道“企业服务总线”来应用到理赔、保全、新契约、产品设计等部门的风险管控系统或者组件中去才可以真正的发挥作用。而这个挖掘结果结果的影响范围，以及影响程度、其它部门做出某些决定的时候对这个结果的依存程度是要统一的通过企业服务总线来控制的，企业服务总线不但应该承担数据传输、协同各个系统、组件工作的职能，更应该成为SOA构架下寿险公司统一IT系统视图的控制器。
5、向SOA的战略转型。我在这里敲上这三个字母绝不是追逐潮流的表现，而是基于自己亲身看到的一些寿险公司或寿险系统供应商真正碰到的问题。例如eBao的产品主表T_Product_Life，一共58个外键，400多个字段；牵一发、动全身；最后产品主表成了谁都不敢修改的核心中的核心。这里（至少我看到的V2产品是这样）没有能够形成对内高度内聚、对外松散耦合的产品组件；产品主表的耦合性过高使得修改这里的东西变得风险极高，并需要极为完备的知识。所以我们下一代的核心系统的数据模型不应是雪片模型，而是若干个松散耦合的星形模型。当然，SOA这个话题太大了，需要周密的计划和跨越性的发展才可以实现，这需要公司高层的胆识和决断的力量来推动才可以实现。
********************************************************************************************************************
[ 本帖最后由 hackjack 于 2008-8-14 21:52 编辑 ]
在加上两点
1.对性能的要求，随着业务规模扩大，支持的保单和客户极具增长，性能极具下降，用户满意度很差
如何解决性能问题，是目前个大保险公司，特别是大集中的保险公司的核心问题
2.业务规则和流程如何才能实现定制化，这是个恒久的话题，
IT系统如何才能灵活应变，满足业务需求，而不是一次次的去hard code ....
当然，在这个过程中，一定会把模块化的思路上升到SOA的高度来做
原帖由 zyzdy 于 2008-8-17 22:11 发表

ebao不是早说有3.0版了么?国内还在卖2.X
国内的都是2.X版的，没办法，国内的公司都没有钱……
目前公司之间的竞争还是在销售渠道上，IT比银行业的更边缘，这样的规划对这些保险公司的c-level的人基本没吸引力。当论文看看而已。
我个人认为ebao v3 还不适合国内的保险公司，很多作业太复杂，操作很不方便。
估计需要很多改进从能有国内的保险公司愿意接受
原帖由 wangym100 于 2008-8-18 15:16 发表

我个人认为ebao v3 还不适合国内的保险公司，很多作业太复杂，操作很不方便。
估计需要很多改进从能有国内的保险公司愿意接受
这个我个人非常赞同，因为目前国内运营层面除了新契约环节，工作的重点都是在不犯错误的情况下如何尽快的“搞定”一个客户。
至于V3，哎……那次R D 展示的他们的“最新力作”让我格外的无奈，一个Cube 在漂亮的星空中转啊转，Cube每一个面上都有若干个菜单项目，操作的时候需要等到立方体转到自己需要的项目的时候点击……
往深里面说这里反应一个深层次的问题，那些R D的人脱离开实际的项目太长时间了，并不清楚项目上面实际的需求应该是怎么样的……