寿险保全BPO业务系统方案的讨论 - 金融行业 - ITPUB论坛－专业的IT技术社区

wangjia

名词解释： 保全（customer service），寿险公司对于已经承保的保单各项变更和生存给付类责任的履行。由于团险的保全操作量较小且多以批处理形式操作，外包意义不大，所以我们这里只是讨论个险和银代的保全。
次生代寿险公司，泛指已经成立4－7年的寿险公司。 中国于2001 12 11 正式入世，按照中国对外承诺的开放的时间表，在每一个限制取消之前保监会都会新审批一批内资的寿险公司和既有的寿险公司的分支机构以壮大内资保险的力量。所以在中国入世对外承诺的限制取消时间点前后会有一批寿险公司集中获批开业。这样按照入世的时间节奏，从开业时间上来看目前的寿险公司层次分明的分成了两个梯队 01～02年左右开业的寿险公司和05年左右开业的寿险公司。从寿险公司展业模式和实现盈利的过程来看开业时间不同的寿险公司也有着不同的业务目标，从这个层面上我把2000年以后开业的寿险公司分为了两个组，姑且叫做次生代寿险公司和新生代寿险公司。其中次生代寿险公司是以太平人寿、合众人寿为代表的在01－02年真正开展业务的寿险公司。
保全业务BPO的前景的讨论：
笔者的观点:一句话前途非常光明。
从寿险公司的需求角度来看，保全业务的外包将会是继新契约业务外包以后的寿险公司（超大型寿险公司除外）的必然的选择。寿险公司的每年的保单存量是依赖与前一年的新契约业务量程阶梯状增长的，寿险公司在追逐和陶醉于首期业务的高速增长的同时不可避免的导致了其保单存量的逐年骤增，相应也就引起了保全业务量按年的阶梯状增长。于此同时逐渐走入成熟的次生代寿险公司又面临这巨大的成本压力，根据保全业务量的增长比例来配给客服部门的人力变得不现实，这就要求寿险公司将这块工作内容交给成本更低的外包合作伙伴来处理。保全BPO业务需求的主要来源应该为次生代寿险公司。这一类公司有规模、有成本压力，如果需要进一步的成长必须通过一系列的革新来实现。 从BPO公司的供给层面来看，对于成熟的寿险BPO公司（如笔者的老东家）基本上已经和目前的寿险公司里面有实施BPO想法的公司就新契约BPO业务签约完毕，接下来必须寻找新的利润增长点——人们很容易就想到了运营业务流程上的另外的两个重要环节：保全和理赔。保全和理赔的BPO笔者都实施过，个人的观点是保全业务的门槛更低，实施风险更小。理赔BPO目前做得更多的是医疗单证的处理、无历史赔付额的简单理算。这里面临这4个棘手的问题：A、各个地区社保政策不统一导致各个地区理算逻辑不一致，这导致了系统实现层面的一些困难；B、各个医院的医疗单证格式不统一，造成无法对理赔单据像新契约和保全那样做精确的光标定位，这导致了录入速度和准确性的降低；C、对ICD－10库录入的处理人员要求非常高，一般要有医学背景，能否组织起一只有基本医学背景的录入队伍是一个非常大的挑战；D、中国的团险有太多的通融赔付，而这些是不可能做到集约化大规模处理的，导致了在实施了BPO之后寿险公司的理赔审核人员仍然有很多的工作要做，留给他们的感觉是BPO并没有给他们的工作压力带来明显的改观，造成了BPO项目有可能的推动不利。……鉴于以上原因BPO公司可能在新契约之后更倾向于提供保全BPO服务。
这里解释一下为什么超大型寿险公司（如中国人寿、平安）不需要或者需求意愿相对较低：BPO初始阶段最吸引寿险公司的地方是它的低成本，它的低成本主要两个经济学里面的重要理论的实践：规模经济效益和比较优势理论。金融BPO公司就是通过服务与多家寿险客户来达到规模经济效益的，这样做的前提是接受服务的单个寿险公司自身的规模达不到规模经济效益。然而超大型寿险公司自身的规模足以大道规模经济效益，所以国寿和平安都选择了构建自身的后援中心来解决这些问题而不是选择BPO公司做为合作伙伴。另外BPO公司自身也不是特别希望有超大型寿险公司加入自己的客户列表，因为它们的业务量太大了，这样的“大块头”的存在使得BPO公司的峰值业务量不再可以用极大似然估计法来估计，经常出现没有征兆的业务量的突然增大使得BPO公司运营交付能力不足。同时有了如此大的业务量也有可能使得BPO公司走向另一个极端规模不经济。
实施保全BPO业务系统的前提条件（针对寿险公司）
保全业务的全影像化、操作流程的统一和标准化核心业务系统的数据集中完成
理想的保全BPO系统模式
以保全项目为单位分析、设计、开发并推广。个人认为无论从系统开发层面还是成个BPO项目的实施层面来说保全BPO都应该一个保全项目一个保全项目的推广。原因很简单虽然保险公司的风格不尽相同，所用的生产系统不同，对风险管控的要求也不同，但是目前的保险公司的保全项目大同小异。多数的保全项目我们可以从中抽取出公共的处理方法来统一处理，这样我们就可以从不同的客户的实施经验上面取长补短。另外不同的保全项目很可能有不同的时效要求，有的项目可能要求的是即时回传（2－3分钟以内） ，有的时效要求则没有那么高。我们需要根据不同的保全项目来定制不同的程序处理流程。根据保全项目的不同特点动态生成录入任务，实现流程级别的程序复用。如果要真正的实现动态的生成录单任务，则我们在录入之前的某个时点一定要从客户那里得到该任务是何种保全项目的信息。得到这些信息一般有两种途径，一个是通过影像文件的命名，一个是在传输影像文件的同时一并转过一个录单任务信息的文件（推荐为XML格式）。笔者更倾向与后者，因为后者对客户实施方的核心系统的改造相对较小，更容易为客户所接受。另外要注意从不同公司的保全项目中抽象出相同的子流程以实现流程级别的复用——这里就这样简单说说吧，如果要完全说明白那就是一个完整的解决方案了……另外这里在BPO业务系统流程设计方面一定一定一定要处理好两个细节问题：A、同一张变更申请书申请了多个保全项目，那么这多个保全项目的处理顺序问题——因为处理顺序错了非常有可能得到完全不同的结果。B、同一张变更申请书申请了一个保全项目，而这个保全项目要影响以某个客户为中心的多张保单——这里要看客户的核心系统的锁机制是否完善，否则很可能因为其中某一张保单因其它原因被锁定而导致整个保全项目交易操作失败。以规则引擎实现事前限制性校验和事后标记性校验相结合的规则控制。从系统层面上说保全规则是比投保规则更为复杂的规则。如果还是一条规则一条规则的Decode，这将是一个吐血的工作量，而且很难保证效率和后期需求变更的敏捷性。所以这里我们最好的选择是借助某个成形的产品来帮助我们处理这部分东西，这也就很容易想到了规则引擎。实际目前的一些开源的规则引擎是完全可以满足现在寿险公司BPO业务系统甚至核心系统对于规则的要求的，个人认为比较好的开源产品是Drools。虽然Drools采用的是相对来说比较别扭的“正向推理”，但是它比较完美的实现了“Rete”算法、真正实现了逻辑与数据相分离、知识（抽象规则）的集中化、用业务语言来编写规则——这就足够了。这一部分内容也有两点重要但又非常可能做不好的地方：A、业务规则的识别——什么算一条规则？举个简单例子：X险种可以接受的投保范围是5－65周岁，X险种与附加险Y的比例限制为1：10——虽然前者可能白纸黑字写在客户提供的投保规则里面，但是把前者的业务逻辑放到规则引擎去实现是一个显然的错误，后者才是一条真正要在规则引擎里面的规则。具体原因就不解释了相信大家都理解，我并不是要写教材：）B、如何去组织并抽象规则，规则一定要用分组的方式来管理的，否则很难管理，但是如何分组是一个非常值得研究的事情。另外值得研究的问题是对规则的适度抽象——此处绝对不是越抽象越好，因为根据笔者的过往经验，过渡抽象会引起设计人员和规则开发人员的沟通困难，并且过度抽象会引起实际开发中的把抽象规则实例化的工作量的增加。
保全BPO系统实施所面临的潜在竞争——网上保全
没有比让客户自主完成保全变更更好理想的保全解决方案了；而且信用卡网银的功能里面有的功能是和简单的寿险保全类似的，似乎是可以借鉴的成功经验。但是网上保全也面临这一些问题：
减小了业务员与客户接触的机会，也就减少了二次展业的机会，这也就是说至少不能获得来自业务部门的支持（很可能是反对）。由于不能面对面交流所可能引发的一系列问题，如因为误解而造成的投诉的增长等。目前尚缺少有公信力而且廉价的CA（认证）机制，有可能引发纠纷。
考虑到这些问题，尤其是第一个问题——由网上保全本身引发的问题，很难完美解决，所以个人认为寿险保全BPO业务，以及其业务系统是非常有前途的。
[ 本帖最后由 hackjack 于 2008-8-29 16:03 编辑 ]
目前很多公司都实现了新契约BPO的方式，不过仅仅把录入、复核等非逻辑的部分由BPO的方式进行；关于保全方面，做BPO，个人认为也和目前新契约这块类似，仅仅能做到非逻辑的。 如果按照楼主所说的，很多逻辑放给BPO做，相对来说，就是做了一个整个的保全系统，个人认为不太可能。保全的业务逻辑是保险核心系统中最复杂的一块。
原帖由 hankunook 于 2008-9-1 17:07 发表

目前很多公司都实现了新契约BPO的方式，不过仅仅把录入、复核等非逻辑的部分由BPO的方式进行；关于保全方面，做BPO，个人认为也和目前新契约这块类似，仅仅能做到非逻辑的。 如果按照楼主所说的，很多逻辑放给BPO做，相对来说，就是做了一个整个的保全系统，个人认为不太可能。保全的业务逻辑是保险核心系统中最复杂的一块。
首先我必须明确的告诉您，把录入、复核成为非逻辑部分我个人认为是不恰当的，我们做新契约的BPO业务需求分析的时候光校验逻辑就写了40多页文档，里面包含了大量的处理逻辑，只不过这些逻辑由于一阶逻辑和断言逻辑较多所以相对比较简单。
另外保全BPO也绝不是要重做一个保全系统，而是把核心系统中的保全业务流程的一部分拿出来做。保全BPO的确实现起来很困难，因为保全不像个险新契约那样主业务流程是一个单线流程，把保全各个环节之间的相关性很强，要把某一个环节剥离很困难，但并不是做不到。我离开老东家的时候我们已经上线了两家的保全BPO。
如果bpo之后还有一个核心保全系统的话，那么保全BPO是没有问题。只要把BPO的保全数据导入即可。对于风险部分做深化处理。
   其实要严格的说的话，什么是核心系统？ 从功能上说，bpo的部分功能有可能超越核心系统。
    所以核心系统只是指那些是保险公司自己的内勤人员才能使用的保险业务系统。
其实BPO并不简单是一个系统的问题，或者一家想俺老东家那样的一家大型企业的主营业务问题，而是一个复杂的商业问题。
如果要成功的实现BPO不是说一放的努力可以达到的，需要甲乙双方的推动，尤其甲方的业务流程重组尤为重要。这里也就需要乙方里面又一个业务、技术兼通的“达人”来参与到甲方的业务重构之中，也就是产品经理或者流程经理这样的职位。这个职位需要非常动业务，懂到什么程度？需要兼备宏观和微观的知识，下到一线可以操作，知道寿险公司一线操作人员的疾苦；上到流程与风险管控方面，知道寿险公司总公司运营总关心的是什么，需要的是什么。技术方面需要至少理解需求，做过设计（个人觉得是否写代码倒不是很重要），其中对于需求的理解是重中之重——因为这个直接和业务相关。
但是现在市面上这样的人越来越少了……俺的老东家在BPO行业也算是No1了，可说实话，光是能达到对业务理解的要求的不超过3个。
也正是这样的人越来越少了才造成保全BPO流程的重构的不成功，也造成了BPO推动的不利。
楼主的东西很受用，我公司也正在实施新华的新契约承保BPO业务，对于保全业务，还请楼主多多指教。