两难的选择——中国保险业务系统走到十字路口

两难的选择——中国保险业务系统走到十字路口

赵晓涛

目前国内保险市场的热点并不仅仅在于外资保险公司的抢滩登陆，实际上，业务的快速发展，激增的保户才是目前保险业的焦点，由此也引发了激烈的市场竞争。而这种竞争也直接体现在作为背后支持的保险核心业务系统上，现有业务系统能否满足公司的需要？是直接引进还是自主开发？国外的业务系统应该如何引进？如何修改？自主开发又应该如何开发？等等这些问题都是目前困扰保险业的大问题。为此，记者走访了保险业的相关专家，希望能够有所收获。

说起保险业的核心业务系统，大概要从90年代初开始。当时国内保险公司都在用计算机代替手工劳动，以出单系统为主，由手工出单改成电脑出单，实际上，业务系统的直接作用就是能够打印一份比较漂亮保单。再以后，随着保险公司业务的发展，其业务系统也仅仅是对于保全、续期、理赔以及一些统计、人员管理等保险业务流程提供业务支持。而如今，众多外资保险公司纷纷强滩国内市场，保险业竞争空前激烈。在这个阶段，各家保险公司对于新险种开发、业务管理、自身风险管控以及服务水准提升等方面的要求越来越强烈，这就要求其核新业务系统也能够从最初对业务的简单支持，发展到了支撑、分析、管理、决策的层面。甚至可以说，核心业务系统的好坏将从根本上影响到保险公司的核心竞争力。

聚焦：老系统问题多多

我们知道，按照保监会的规定，保险公司的收入必须按照一定比例作为准备金，而对于资金的使用，保监会有严格的限制和规定，以保证保户的利益，降低公司的运营风险。目前，各家保险总公司基本上采用了分公司的运营体系，这要求总公司具有很强的监控能力，如果有分公司违规操作，总公司必须在第一时间进行纠正。在传统的分公司的管理模式下，总公司的风险非常高，以巴林银行倒闭为例，其实质就是总部没能监控好分部的违规操作所造成的。

这种风险同样存在于今天国内的保险行业，其原因就是国内保险公司大多采用分布式的业务系统，这就容易带来自身管控的风险。此外，保单数量激增和需求的增加也使得保险公司原有的核心业务系统不堪重负。以新华人寿为例，这家1997年以前成立的保险公司，原本采用分布式系统，去年以来其保单数量按照300%左右的速度增长，如今总量已超过了300万，已经超出了原有业务系统的支持能力。对于那些历史更长的保险公司而言，问题就越发明显。

要解决这些问题，就必须加强保险公司的内部管理，方法之一就是采用在其他行业颇为流行的集中模式。在集中模式下，由总部直接进行业务管控，分公司不可能私自截流或者隐瞒任何收入。

此外，数据集中之后，也为数据分析、挖掘以及公司决策创造了条件。

不过话说回来，集中的业务系统是不是万无一失的呢？现在有一些保险公司希望做成集中化系统，可是担心网络的稳定和安全。因为集中系统运行的好坏，有些因素是保险公司没办法控制的。此外，对于租用中国电信的公网进行总公司与各个分公司之间的数据传输，有些保险公司也表示出了自己的担忧。例如，有些保险公司在开设分公司的过程中，就遇到了DDN专线租用方面问题，相关租用申请不能够很快落实到位。如果是省内还好一些，一旦要跨省连接，最少也要一个月的时间，这还是在东部发达地区，要是在西部地区搞专线，时间还不止如此。有些新保险公司抱怨电信不重视他们，大公司申请很快，而小公司就要耽搁很久。另外，即使DDN接通了，其通信质量也不能保证，有些保险公司反映，作为备份的ISDN，经常启用。但也有些保险公司对于中国电信的服务质量感觉到满意，并不担心通信的问题。但是无论如何，这些因素都是集中模式要考虑的问题。

此外，对于互联网，国内各个保险公司还没有充分挖掘其潜力。这个问题归结于核心业务系统的多渠道访问，过去一些保险公司不太重视提供访问渠道，尤其是对保险代理人、经纪人提供访问渠道。因为就渠道本身来说，核心系统应当尽量提高保险公司直接与客户交互的能力。以财产险为例，车险市场相对比较混乱一些。从表面上看，混乱很大程度上是代理造成的，但从信息技术角度来说，扩大保险公司和客户直接交互的访问渠道，能够在一定程度上解决这个问题，而这也正是现阶段国内保险市场对IT的需求之一。

所以说，就国内保险公司的现状来看，很多保险公司的核心业务系统都要进行修改、升级甚至是更新，这不仅是从各家保险公司的管理、决策支持、产品上线和风险管控上说的，更多的是从今后国内保险市场进一步发展的层面上考虑的。因为据保监会预测，国内保险市场很可能在几年内出现“井喷”，要是到了那个时候才发现业务系统不能进行支持，或是满足不了越来越成熟的保户的需要而进行修改，那就“为时晚矣”了。

从国外的经验来看，目前先进的核心业务系统必须对新的保险产品进行有效的支持，即全险种。因为保险包罗万象，全险种不仅包括现有的险种，还要包括即将推出的和将来要推出的险种。从管理上讲，先进的核心业务系统应该采用集中化模式，为了对公司内部各个部门进行有效的支撑，必须采用同样的标准、平台和编码，这是建立一个统一、完整的信息系统的基础。只有这样，才能实现一些高层的分析与应用，包括以客户为中心和支持多渠道的访问。先进的核心业务系统应该能够提供非常丰富，或者说是海量的信息，从中进行分析以供决策、管理，然后供客户服务使用。同时，核心业务系统要有内置的管理系统，真正和业务系统、财务系统、分析系统浑然一体，加强监管，减少风险。因为保险公司本来就是把大家的风险集中在一起，如果公司对自己的内部风险不加以监管的话，很容易造成巨大的失误。相比国外先进的核心业务系统，国内保险公司的核心业务系统必须进行修改，以便满足保险公司日益增长的需求。

思考：新系统要怎么做

既然现有的保险业务系统有很多不完善的地方，那么就要进行修改，但前提是保险公司必须知道自己的需求是什么。反之如果保险公司自己都不知道需要什么功能，修改也就成了一句空话。事实上，这的确是目前保险公司所面临的难题。

有位专家举过这样一个例子，他说我们平时上班的时候都在用微软的Office软件，每天用Outlook写很多E-Mail。但是我们买了这个Office以后，从来没有人会觉得它的流程不对，或者说要自己做改造。这是因为在Office软件方面，用户需求已经很明确。微软能够做出这样子一个软件系统，它能够满足绝大多数人的需求。一旦一个应用方面需求已经达到这种明晰的程度，就完全没有必要自己再去写系统。

但是从目前保险核心业务系统来说，很多保险公司没有一个很完整的需求，就是说这个保险核心系统到底应该是一个什么样子，并不确定。特别是一些新公司，进入市场时间短，很难让他们提出明确的需求。

选择一：引进国外系统

设想：巧用“拿来主义”

对于新的保险公司来讲，最直接的方式就是引进国外的核心业务系统。因为在目前国内保险市场不完善的情况下，国内保险公司提出的需求能否满足公司今后发展的需要还有待检验，如果需求出现偏差或者自己开发出现困难，都会给保险公司造成损失。

就国外的保险系统而言，包括CSC、SAP、Oracle这些一揽子的解决方案，总体感觉国外的系统有点像保险业的ERP，包括了保险业80％的方面，基本上反映了一个很通畅的保险面上的需求。以CSC为例，国外保险核心业务系统里边的模块是高度集成的，比如有700个险种存放在一个数据库里，保险公司的财务数据也是在这一个数据库里边，其他一些再保险的信息跟100多家再保险公司的信息还是在这个数据库里边，这对保险公司来说就非常方便。保险公司需要什么数据，直接在任何一个表里边抽取就行了，即便是增加一个险种最多也只需要两三天。如果缺少相应的模板，保险公司的IT人员就可以自己做一个，然后挂接到整个流程的一个环节上去，整个过程也是很快的。此外，国外的系统对于报表的支持更加充分，保险公司要加一个报表，只需要一个小时就可以完成（具体看保险公司的需求），保险公司可以依据保户和公司自己内部的需要来添置，十分的方便。

其实，保险公司引进国外系统的初衷就是希望能够带来先进的管理思想。国外的业务系统模型（如IAA、CSC）代表了一个规范，具有一个比较完整的标准定义。因为程序体现的是一种实际的操作过程，这个和保险环境是一致的。国外的业务系统已经把在国外碰到的保险产品、服务类型很详细的建模化了（做标准的参数模型），再遇到类似需求系统可以进行处理。但是这对于国内保险公司来说有一定难度，因为很多情况国内保险公司并没有碰到（新公司更是如此），相似的保险产品也没有接触过，这靠保险公司自己想是想不出来的。这样的话，国内保险公司的核心业务系统有可能不完善。在今后发生这种事情的时候，国内保险公司系统不能处理，不得不进行改造，造成系统维护工作量很大。

记者曾经发现，没有一家国内保险公司的IT人员很清闲，都是忙的不得了，都在应付系统的维护。每家公司都有很大一部分IT人员在做这些事情，各家保险公司客户不同，要求也不一样。关键就是因为保险公司没有一个成熟的、底层的数据模型。所以很多新进入的保险公司和外资保险公司都直接引进了国外的业务系统。这样可以缩短自主开发时间，大大加快公司市场准入的步伐，因为保监会规定只有核心业务系统通过验收，才允许开张营业。

警惕：引进不等于照搬

国外的保险核心业务系统的确有非常多的优点，可是能不能将国外产品直接照搬过来呢？这里边有个例子，说的是美国友邦保险公司进入中国后，发现国内的保单缴付保费90%都是一年一交，其中有很大一部分都是囤交，即一次性交清。但是在国外90%以上比例是每个月交保费的，基本上是没有囤交的情况的。对友邦而言，引进的母公司的业务系统就不能满足国内的需要，因为在国外系统里面，囤交是一个特例，系统支持有限，而原有系统对期交业务的详细支持，白白浪费了大量系统资源。

又比如各家保险公司都会碰到的银行自动转账系统。在外方的核心业务系统当中，严格遵循核心系统的安全性，即BS7799的一个标准条例。在数据加密、传输的过程中，需要有一些特殊的处理。但是国内的银行没有相关的技术来进行接收、转换，这样的先进技术显然派不上用场。

另外，很多保险公司在引进国外系统的时候，非常看重国外系统的集中化处理模式。一般国外系统都有类似用户身份证号码的唯一ID，但在国内就有可能开不通。据4月11日《北京晚报》报道，有些省份发生了身份证重号现象，这将对以身份证为唯一ID的保险核心业务系统造成困扰，将很难解决此问题。所以说，即使集中系统很先进，也可能由于外部问题造成意想不到的错误。

不难看出，直接照搬国外系统肯定是不行的。有专家指出，由于国内的市场环境不一样，对引进系统的保险公司来说，二次开发是必须的。

把握：不要伤筋动骨

说到二次开发，这中间就有一个度的问题。像新华人寿引进CSC的系统，经过差异分析，找出了100多个不同的差异点，这些不同点肯定是需要客户化改造的。但是客户化改造有一个问题，是保持国外系统原有的管理思路和流程，还是适应目前的状态，这中间有一个取舍，或者说是一个平衡的问题。如果保持原样太多了，可能对市场管理是一个比较大的冲击，这样管理层的适应度会弱一些。反过来，如果客户化改造得过多，过于迁就目前的状态，那么通过选择国外的系统来引领自己、通过国外系统的实施来引领自身管理提升的目标，可能也就成为一句空谈。所以说，怎么样来平衡这两项之间的一个关系是二次开发的关键。

在这方面，美国友邦保险公司的经验值得国内公司借鉴。友邦认为，二次开发一定不要涉及对引进系统伤筋动骨的改造，即改变它原来的基础设计，否则会造成意想不到的后果。因为今天为适应管理的需要对系统进行了修改，可能应付今天看到的东西，但是日后会带来很多看不到的影响。有可能一些应付今后需要的潜在功能、设计，会被不经意的修改掉。

为了防止伤筋动骨的改造，国内保险公司必须明确那些可以改，哪些是系统的核心，不能动。友邦将系统核心划分为四类：即产品设计架构、客户资料存储结构、营业员制度和财帐处理。在进行引进系统的二次开发过程中，这四块是万万不可碰的。

这是因为，从产品设计来看，国外的核心业务系统对产品的分析比国内保险公司自己开发的系统做得好。国外系统很清楚世界上一共有多少保险产品，每一种产品有多少个变异，在一个产品大类里边有多少个产品小类，每一个产品小类可以发生哪些变化，可以由那些不同的组合来做。这点由于受到国内市场环境的限制，国内保险公司开发的系统很难面面俱到。另外，国外系统对客户资料的保存，即应该保存多少的客户资料，有十分规范的定义。因为有可能一张保险合同涉及到好几个客户，有的是付钱的，有的是被保险人的，有的是受益人的，等等。如何对这些客户资料进行有效的利用，首先就是将资料保存在系统中，而且有一个好的存储结构，可以让保险公司以后从各个角度能够得到想要得到的信息。此外，营业员制度，即营业员的结构跟营业员管理，包括付佣金、奖金、升级等一套奖励的东西，这也是比较复杂的结构。还有一些财务总账的做法，包括了不同的产品、不同类的帐目处理，这些结构都是有内在联系的，修改一个很可能造成连锁反应，致使系统功能出现变化。

现实：应该改什么

如果非要对系统架构进行修改，保险公司也不要自己动手，最好和系统的供应商合作，不过改动的成本就成了问题。这时候国外系统的解决方案就会非常非常的贵，有可能原有系统售价100万，但改动费用收1000万。原因很简单，设计是要钱的，一旦架构改变，系统提供商要有风险，势必造成多花钱。但是这个费用很快就会在保险公司财务的折旧费用上出现，势必对费差造成负向贡献（财务贷方）。

另外，很多国外的保险系统在业务流与财务流的衔接上没有弹性。这就是说，保险业务系统不能同时处理采用不同方式支付的保险费。即保户不能一部分用现金，而另一部分用支票来付保险费。更重要的是，为了满足保险公司管理部门和财务部门的要求，引进国外核新业务系统的同时必须做一些接口上的修改。因为满足这两个部门处理需要的前提就是，业务处理和保险费的收取已经完成。但是在现有国外业务系统上，这两个前提都是手工处理的。这就意味着保险公司不得不先去“寻找”保费在那里，然后再去做管理、决策。所以说，在国外的系统投入使用以前，所有这些细节问题都需要被有经验的用户或者专业的保险分析公司发现并修改。

其实这个问题的关键就是国外与国内的需求不一样。目前国内的保险公司在引进国外系统的时候，出于各方面的考虑，大多都是引进一些小型的系统。这些系统支持的用户数都比较少，但是每张单子的费用可以很大。这就决定了系统里面手工操作的环节很多（降低系统开发成本），如果用户量不是很大的话，这并不是问题。但是中国的市场环境正好相反，保户数量大但是每张保单的数额小，如果手工处理多的话势必造成系统效率低下。

也有专家认为，对系统的修改可以停留在一些外围方面，比如对界面的修改，让广大的业务人员适应。但记者在这里有一些不同意见。记者认为，这些修改工作不应该由公司的IT人员来完成。因为从利用率的角度分析，保险公司IT人员的成本普遍高于业务人员，IT人员的应该有更加重要的工作去做。这些东西既然外国人可以适应，国内保险公司的业务人员也可以适应。记者认为在这点上，保险公司应该向银行学习，加强公司的CIO机制。以招商银行为例，招商银行的电脑系统是国内银行中最好的，关键原因就是他们有完善的CIO制度，据招行行长讲，“我们行很多事情都是IT人员说了算，IT部门负责设计业务流程，业务部门必须服从”。所以说，一个完善的CIO机制，也是国内保险公司引进国外业务系统的关键因素。

选择二：自主开发后劲足

创新：开发“自立更生”

引进国外产品的确有很多好处，但缺点也是明显的。首先，成本问题，国外系统的高成本是不能不考虑的，因为这个成本不只是一次性投入，二次开发、今后每年系统的升级、改造都需要大量的金钱。其次，对于一些新公司来讲，国外系统上线几乎可以说是在一张白纸上进行的，可对于一些老公司来说，由于具有大量的保单，在新老系统交替的时候会带来很大的转换工作，这有可能是需要好几年才能完成的。在目前的市场环境下，显然是不现实的。为此，很多保险公司在升级系统时都采用了完全的自主开发模式。

自主开发模式的基本策略就是，能自己做的就不要买。因为开发模式是见仁见智的东西，无论是引进国外的产品还是自己开发，方法都是可以的，关键是对保险公司是否合适。能做的就要自己做，而一点都不会的，也没必要浪费时间。

记者了解到，目前像平安、太平人寿、太平洋安泰等保险公司都采用了自主开发的模式。有专家指出，目前很多保险公司的系统是在自己开发不下去的时候才去引进的，但其前提就是IT人员对自己公司的需要不是很了解，这样最好引进，因为没有什么比直接拿来一个东西更简单的了，一般合资公司都是这样的，但关键是引进的系统是否用的好呢？

保险公司的核心业务系统往小了说是IT平台，可以理解为公司运行体系的一个IT实现。这就是说业务系统实际上是已经把该做什么事情、该怎么做、如何做都设置好了。如果是一个新公司，找一个现成的系统，就不用考虑说是这项业务该怎么做，那项业务该怎么做。从新公司的角度来说，使用一个现成的系统就是省事。问题的焦点在于，很多公司是以此为理由引进的。另外一种情况是，IT人员知道理想中的系统是什么，并且希望按照自己的想法去做，这就要靠自己来保证业务思路。所以说，一种模式就是引进，最好是现成的东西，因为不仅仅是系统，而是一套管理办法，这在系统的操作手册中都写进去了；另一种模式就是自己做，或者是完全按照自己的思路做系统（外包编码工作），这要冒一定开发风险，毕竟要对业务了解得很清楚，要让公司的员工都能看懂。

这就象我们思考问题的时候，需要瞪大眼睛看周围的新东西。国外系统做了很多年，国内则很短，这是事实。但是，这并不是说当我们要得到它的时候，就要去买一个现成的来，其间还有很多考虑的东西，比如通常的成本上的考虑。实际上对于保险公司来讲，所谓的系统实际上代表了一个公司的运营能力（详见本报第6期《IT，原来不是这么简单》）。IT人员就是要使保险公司获得这个能力，但更重要的是持续地发展这个能力。这就是说，购买一个现成的系统，一下子就可以获取提高公司运营水平的能力（记者认为，实际上是否能提高，本身还是一个问号），但将来如何才能继续获得这种能力呢？（看来还要再花钱买）

自主开发所要做的，就是要对这种运营能力的获得和发展进行有效的挖掘。但有专家认为，很多保险公司的CEO不考虑这个问题。因为CEO主要关注的是市场，是为了获得市场而去买IT产品，但产品实施仍然要IT经理来负责。所以很多时候就是因为讨论引进还是自主开发的问题就已经丧失了很多市场机会（还是缺乏CIO机制）。但其实引进的代价是很高的，因为不是说今年公司买了一个系统，以后就可以高枕无忧了。事实上，由于中国保险市场变化很快，核心业务系统是一个动态发展的过程，不断地进行系统升级、更新是不可避免的。所以当引进国外产品的时候，一旦问题考虑得不全面，就等于花了很大一笔钱爽了一把，等到明年市场变了，到时候还要再花一笔钱。所以说引进的产品只是针对公司目前的需求而言的，并不是针对公司所有问题的解决方案。

需要补充一句的是，自主开发的前提是有一个高度集权的管理体制，或者说是一种CIO机制。这方面平安保险公司做的就比较好。平安主张开发的业务系统不管好用不好用，总公司都会要求各个分公司先用着。记者发现平安的模式和招商银行相似。招商银行的IT系统是最好的，但整套系统是自己开发的。平安的核心业务系统也是自己做的，可能他们要经历一个相当痛苦的过程之后才会获得成功，可能很多东西不如直接买来的好，但是平安锻炼了一支队伍，队伍保证了持续发展能力的获得。

关键：业务人员要参与

专家认为，保险公司自己开发业务系统，应当让相关用户（业务部门、合作伙伴）尽早地参与，特别是一些资深的用户，这对于业务流程的设计以及新系统的推广是十分有必要的。

记者了解过太平洋安泰保险公司的开发模式，他们做的就非常好。太平洋安泰进入上海后，花了将近两年的时间进行开发，其中用了一年的时间讨论业务流程，半年的时间去设计数据库，最后半年做编码工作。太平洋安泰从开发之初就强调了要让业务人员参与进来，在系统开发的第一年甚至没有要求IT人员参加，完全是业务部门配合部分系统分析师做业务流程的分析。这样做的目的就是系统做出来以后，先让业务人员满意，让他们觉得好用、爱用。

不难看出，太平洋安泰的开发思路就是先把整个一家保险公司该有哪些流程做了一个仔细的归纳跟整理，然后再把国内保险市场的特性加入到系统中去，比如针对国内保险市场每张保单费用低但数量大的特点，系统的核心设计思想就是必须要能够支持大量用户单位，而且还不能够丧失系统的效率。而这些特点的挖掘，正是用户参与的结果。

正如专家所强调的，核心业务系统的运作与开发，跟业务流程之间会产生不可避免的碰撞。因为业务流程是不断完善的过程，而核心业务系统也在这样一个循序渐进的过程中，等流程相对稳定以后，有可能IT这边又有新的技术出来了。这个新兴技术能否帮助现有的业务系统来提高它的工作效率，这是需要用户来检验的。

在这方面，平安保险公司也同意让用户积极参与开发过程。平安认为，用户介入得越早，介入得越深，后面的开发工作越顺利。平安把用户的范围扩大到了总部、机构，甚至是业务员级的人。平安认为，用户会在新系统的推动过程中，给开发部门很多的帮助。因为用户知道系统要变了，也知道要变成什么样子，用户会慢慢的接受。否则的话，事到临头说给你一个东西用去吧，那估计十有八九还得给用户一个季度到半年的时间去实验。

记者认为，让用户参与开发过程的做法其实是非常明智的，因为在任何业务系统的转换过程中，都会遇到阻力，刚开始肯定会有很多人说新系统“不好”。这个不好不是说系统不好，而是说用户不习惯，因为用户不知道系统这么快就变了。所以保险公司在系统开发或者更新的时候尽早让用户介入，这样新系统推广时就会容易很多。

记者的话

其实说了这么多，问题只有一个，正如专家所指出的，保险核心业务系统的开发模式是见仁见智的东西，但关键是必须保证保险公司能够获得所需要的运营能力。因为无论是引进国外的产品还是自己开发，方法都是可以的，关键是对保险公司是否合适，能否满足保险公司的需求，这种需求是从业务、管理到今后发展的各个方面的。另外，采取适合的开发模式也是新系统推广的条件。

对于文章中提到的一些新问题，比如电信的服务水准、CIO机制的建立和完善以及身份证重号带来的困扰等等，都属于社会、市场大环境方面，在目前国内保险市场还不成熟的条件下，保险公司开发核心业务系统的时候，这些因素是不可以忽视的。总之，无论是自主开发，还是引进以后的二次开发，阵痛都是难免的，但只要符合公司的发展需要，就都是可行的，都会对保险公司的发展起到积极的推动作用。

本文原载于计算机世界