保险访谈 - 余亚滨：保险电子商务的挑战与对策
12月1日，第六届
大家下午好！首先感谢能有这样的机会与在座各位领导、行业专家一起分享CSC在过去几年怎么样帮助我们客户进行迎接电子商务的一些挑战。
今天要跟大家谈一个比较老一点的话题：电子商务。虽然话题有一些老，但我们可以有一些新的探索和发现。在今天这个话题之下跟大家一起分享一些在过去几年CSC怎么样帮助我们全球客户实施电子商务的战略。虽然有些项目不是最近一年发生的，但我们经常回顾过去一些项目，会发现里面有一些客户的做法或思路，对我们迎接今天特殊环境下电子商务的挑战仍然有借鉴意义。
从目前数字来看，中国网络保险发展水平与发达国家相比仍旧有比较大的差距。2011年，美国市场网销保费收入已超过全国总保费收入的25%，而与此同时，2011年中国网销保费收入占全年保费收入不到1%，可见差距非常大。但在差距背后看到中国网民数量、规模已经远远超过美国市场，我们在2011年初时，麦肯锡发布了一个报告表明：到2011年6月底时，中国网民规模已经达到4.85亿，而且月收入在2000元以上的网民占比也从过去的33.3%，上升了将近5个百分点，达到37%。网络购物用户规模也达到了1.73亿。在这样一个庞大的网民和网络购物背景之下，相对比来看发现中国保险电子商务，尤其是网络营销发展远远不够。
为什么会有这样的差距？跟我们发展的时间有关，如果我们深入研究的话，会发现从保险公司自身电子商务发展系统、策略来讲，也遇到了一些挑战。接下来看看这些具体挑战都是哪些？
现在各个保险公司都在建自己的网站，逐步在官网上开展电子商务等业务。保险公司自己建的电子商务网站访问量和黏度不够，如果概括性定位国内保险公司自己搭建的这些电子商务网站，发现搭建的水平属于交易型网站，上面组织内容和功能的基本出发点还是为了满足用户的交易需求或购买、后续服务需求，还没有过渡到更高层次，还没有到内容型网站或社区型网站。我们参考其他行业电子商务网站，如果一个电子商务网站有足够大流量的话，还会产生一定比例购买意向，最后形成一定比例的实际签单率。
怎么样提高电子商务网站的流量和黏度，大家可以参考其他行业的一些做法。最基本的出发点是怎么样在你的网站上快速更新内容，利用后台分析系统或工具能够捕捉你的用户在你的网站上停留时产生的一些线索，然后把这些线索转化为一些需求，转化为一些实际消费机会。如何提高网站知名度，怎么样利用外部工具或合作伙伴来提升网站的量，我们可以通过跟搜索引擎、门户网站进行有关的营销。
如何更快速地推出新产品。我们在过去研究中发现，金融机构，包括保险公司在内的一些金融机构如何看待自己和你们客户之间关系时，已经跟你们的客户怎么看待这种关系之间逐渐产生了一些差异，我们很多金融机构，包括保险公司看待保险公司和自己客户之间关系时，更多认为这是我的客户，他在使用我的产品，在使用我的服务；从另外角度，你们客户是如何看待这种关系的，客户都认为自己是独一无二的，他希望金融机构，银行或保险按照他的需求来给他提供服务和产品，能够根据他的需求定制相关的服务和产品，这两种不同的观点中间有细微的不同，因此导致一家保险公司要使自己给客户提供的服务产品迎合客户需要的话，包括你后台服务系统和前台网站都会需要一些转变。
目前保险公司做的一些电子商务网站，在网上销售的都是简单不能再简单的一些保险产品，比如
如何通过优化关键的业务流程来提升客户的体验。一旦你的客户在你的电子商务网站上了解你的产品，下单之后，或者他在你网站上提出理赔请求时，保险公司后台都会面临一系列对业务流程处理，因此这个投保、理赔或其他的请求之后，保险公司后台系统的业务流程处理便捷性和安全性也会影响投保人服务体验的一个关键因素。客户在网上投保或报案或提出其他保全业务请求之后，保险公司后台进行业务处理时，在多长时间内能够完成处理是关键性因素。还有其他问题，流程本身如何进行优化，今天在这里提的问题并不是单个的流程优化，流程到底怎么样，每个保险公司都有自己的判断，没有所谓最优的优化流程，每个保险公司可以根据自己的特点设计最优的优化流程。
怎么样在不同业务流程之间、不同渠道之间，能够共享信息和数据。有一个例子，我前两天到外地，准备在网上购买一个短期意外险，我登陆一家保险公司商务网站，就下单，把所有信息填完以后，付款时导致我无法完成这笔支付，当时很着急，因为已经很晚了，要睡觉，第二天早上要出发，就打这家保险公司的客服电话，我说在网上投保，但没有完成支付，所以请他帮我看看。但是那个客服人员查了信息之后根本不知道我在网上投保的动作，也不知道我填写哪些信息，他说你需要在我的指导下重新做一遍投保过程。这对我来说是不可接受的，我觉得这是非常低级的错误，我倒不是在意你的效率有多高，多一分钟少一分钟都可以接受，最严重的问题是通过一个渠道做了这个业务，另外一个岗位的人居然不知道。这也是之前殷总提到的问题，这个问题不光是保险行业存在，其实在银行行业也同样存在。
之前我有一个朋友遇到一件事情，他有一天接到一家银行的电话，他是这家银行的VIP客户，希望他能够购买这家银行的全新产品，说怎么怎么好，你这个客户对我们银行怎么怎么重要。结果过了几天，我这个朋友要购买一个大的商品，额度不够，打电话给银行信用卡中心，让他们提升额度时，居然告诉他不能给你提升额度，因为从过去记录来看，没有其他信用空间可以提升你的额度。所以我朋友非常生气，他说同样来自一家银行，只是不同部门人员，对于这个客户的定位完全不同。为什么会导致这个问题？最根本的原因是银行不同的展业渠道、不同的展业部门，对于一个客户的信息理解不全面，根本原因是在IT设计时没有把一个客户完整信息集中展示在一个平台上。
如何将电子商务扩展到移动渠道。从目前国内移动互联发展趋势来看，移动互联把我们传统一些的保险活动或业务搬到移动互联网络上，会是很大的趋势。根据麦肯锡公司今年报告，目前在中国通过移动终端上网的网民人数已经达到3亿，在今后两年里还会继续新增1亿通过移动设备上网的用户，预计到2015年将会增加到7.5亿。又有研究表明，通过手机上网的用户和保险的有效客户具有相当大的重叠性，意味着通过手机上网的用户其实可能都能成为我们的潜在客户。我们如何利用出现的这些移动互联技术把我们传统保险业务处理或展业的过程利用到移动互联设备上，对我们来说是一个新的课题。
虽然现在很多保险公司都已经意识到通过移动互联的技术可以有效的帮助我们开展新的业务或降低现在已有业务的风险、提高效率，我们非常清楚知道移动技术能带给我们一些好处，但应用程度非常有限。为什么？我们对一些已经使用移动互联客户和没有使用移动互联客户的调研发现，移动技术对于保险公司来说是一门全新的技术，不光对保险公司，对于世界上其他主要行业来说都是全新的技术，我们很难把我们在传统技术平台上的一些开发或系统设计的思路完整搬到移动设备上，这是不现实的，因为移动设备有很多具体的限制，比如一些移动设备即使不同厂家、型号的智能手机、平板电脑，上面对于标准协议、浏览器的支持都不同。有一个术语叫碎片化，比如你是一家保险公司要开展移动互联应用的话，希望为更多潜在用户下载、使用，但要保证这一点，就必须要在移动应用推出之前，无论是基于web形式，还是手机上应用，都要进行大量测试，要能支持不同型号、不同厂商的产品，这个工作量非常大。而且由于移动设备尺寸、内存、输入方法、电池寿命，尤其是网络连接性，带宽时高时低，这些对于保险公司来说也是一个新的挑战。
案例1：
这个电子商务网站上有一个功能叫“我的苏黎世”，一旦成为苏黎世用户之后，可以进入到这个网站上进行很多业务操作，包括可以进行第二辆车的投保，可以查看现有保单，可以进行一些试算，还可以把这些试算结果保存下来，可以进行事故理赔，查看理赔结果，可以请求一些资料。当然这些功能没有什么好特别的，国内很多保险公司电子商务网站上也能提供这些功能，但关键这个电子商务网站怎么和后台业务处理核心系统、CRM系统集成起来，这才是我今天想要介绍的关键。
典型电子商务环境下交易的流程，一个客户在家里上网，通过电子商务网站提出一个请求，这个请求会被送到后台一个工作流里，收到这个请求以后，把这个请求直接派发给后台对应岗位的业务专员，处理完这个请求之后，比如这个请求刚好要求保险公司要给他发送一个指示文档，后台岗位就可以在这个平台上看到这个请求，然后进行相应的业务操作，就会修改工作状态。接下来客户在家里收到之后，填写相关信息或签名之后，就把文档邮寄回保险公司，保险公司有一个自动化处理，收到文档之后自动扫描，有一个条形码，和原先的工作进行挂钩。接下来又有另外一个工作岗位上的人员能够提取到这个任务，然后完成这个工作任务，最后给这个客户发送一条信息或更新电子商务网站上的信息。用户从提出请求到请求完成，整个是一体化的过程，这个过程把电子商务平台，还有它后台一系列的系统通过这样一个工作流系统完整的集中起来。
无论是后台的工作岗位还是代理人或前台客服岗位，在任何一个时间点，当他登录到这个后台大系统时，都能够看到在什么时间有一个用户通过什么渠道向我这家保险公司提出了什么样的请求，这个请求完成程度如何，最后这个请求都经过哪些过程，当时状态如何，我后续需要对他进行什么样的处理。
通过苏黎世事例，给我们最大的启发是时作为保险公司而言，CRM、电子商务平台、电销平台，包括后续财务支出的系统，怎么样集成起来，从而给予你的客户服务专员或销售人员、电子商务网站的集成，在任何时间都能了解客户当时的状态，客户提出请求服务的状态。通过这样一个集成可以消除之前一家保险公司在多渠道情况下数据的共享。
案例2：安联（德国）。当时有几个销售渠道，一是自己有一个代理人网络，大概超过1万名代理人或代理机构，一共超过3.6万名销售人员。通过AMIS和AMIS在线为代理人员提供支持。二是通过德国本土非常大的一家银行德雷斯登银行做服务，为这家银行专门提供一个AMIS产品门户系统。安联自己建了一个网站，还提供网站直销。由于市场竞争非常激烈，需要经常推出一些新的产品，或对已有一些产品的定价做一些修改，这时候就发现每当推出一个新的产品或对现有产品基本的条款、定价做修改时，不得不修改三个系统，每个系统都要改，这对它来说是一个非常耗时耗力的动作，因为那些系统涉及到不同的平台、技术和供应商，这是很大的问题。最后提出一个概念，要把这些本身埋在不同渠道里的产品信息，包括产品的定价信息等集中到一个地方，称之为“中央产品知识库”，包括保单系统、呼叫中心、财富系统以及所有后台系统和前台系统之间，凡是有关保险产品的资料和信息，包括规则和定价全部集中到一个中央的系统，以后所有这些定价的产品信息都不在其他系统中保留，当它不属于一个新的产品时，只需要在中央产品知识库，把产品有关规则和定价的计算模型部署之后，任何一个外围系统调用这样一个中央产品知识库就可以完成新产品上线。保险新产品上线测试工作量非常大。它的期望是通过实施这样一个中央产品知识库的模型，使它的新产品开发流程能够从过去的系统开发12周缩短到将近5周或者6周。
有这样一个设计思想出来之后，我们根据这样的设计思路提供了一个解决方案，叫VP/MS，专门针对金融行业产品虚拟化和建模的产品。实施这样一个新的产品集中化战略后，通过网上直销平台能达到的效果，实施这个平台之后，网上直销平台，包括其他渠道都能更快部署新的产品或调整现有产品。
客户登陆这个网站之后，需要车险报价时，可以录入相关信息，如果有些信息填错了，网站能够自动告诉用户你哪些信息填的不对。如果所有信息都验证通过的话，这个电子商务网站可以实时给出报价。大家看到这个也觉得没什么稀奇，因为国内很多保险公司电子商务网站都可以提供这些功能，但关键问题在后面，看到整个流程里所有保费计算的规则或对于一些输入字段验证全部在后台核心产品知识库完成，而不是在前台。而国内前台要做很多改动，因为为了支持这个新产品特有的字段或特有的一些数据验证。安联24实施了这个产品技术，所有数据的验证全部在后台中央数据库完成。部署新的产品或调整保险产品费率时，测试工作跟传统保单系统无关，只需要在它的中央产品知识库进行测试，可以事先定义好很多测试案例，然后保存下来，下次再修改某个保险条款或某个费率计算规则时，重新执行这些案例，就可以看到调整后的是否生效。在电子商务网站上部署了一个时间，提升了整个效率。
另外一个案例，这家公司已经做电销网络已经很多年了，随着移动技术的发展，这家保险公司希望能把现有的服务扩展到移动设备上，能够给他的客户，包括他的一些内部客户，比如代理人或经纪人或理赔人员、勘查人员能够通过移动的终端或设备访问后台的服务。这家保险公司有了这个想法之后却无从下手，移动互联的技术和传统的基于PC、服务器的一些技术是完全不一样的。这家保险公司没有像我所见到的很多国内保险公司一样，不是先上来选择一个简单的方案实施，而是先做一个长期的规划。
我接触过国内很多保险公司甚至国内的银行，在实施移动互联应用和技术时一般来说比较着急，希望在现有的技术上线实施，我们发现越是这样的技术实施方式越和后面的移动互联应用和发展带来障碍，因为随着交易量的增加，随着智能手机或者平板电脑设备上的应用，以及操作系统的多样化，如果一开始在没有长足深思熟虑的前提下你就实施这样的移动应用，包括前台和后台的时候你会发现它的后台拓展性更差，不能支持后面业务的发展。
这家保险公司的做法，先对它整个移动发展的策略做了一个为期一个月的彻底规划，通过这个规划得到长期策略发展的路径图，通过这个规划，他知道他要在移动领域要做到什么，要支持哪些设备，要采取哪些后台架构。接下来是实施的过程，我们帮助他实施了前台的应用，也包括后台服务器的体系架构。最关键的是整个一套方案实施下来我们不光提供实施的服务，也包括所有你需要新采购的一堆设备，包括智能手机、平板但是都由CAC提供，我们提供完全外包的模式，这个设备对保险公司是很大的投资，而且这些设备的管理和传统的PC管理和维护是不一样的，这家保险公司觉得他没有能力自己管理这些移动设备，而且他预见到随着几大移动设备厂商的竞争，就是移动设备的更新会非常快，没有比亚自己去买移动设备，买完之后过几年淘汰掉，所以他采取全外包的方式，包括后台移动的体系架构，就是支撑它淘汰移动应用，后台移动应用服务器软件以及前端所有的设备，采取全外包的模式。
我们提供了一个移动应用架构。这个架构非常灵活，它可以支持保险公司已有的IT资产，这是非常重要的，很多保险公司后台IT建设已经非常成熟了，已经有了工作流系统，有了安全管理的系统，有了影像管理系统等等，如果你为了支持一个新的移动应用，支持移动应用的后台必须要全部再采购另外一套或新的系统对以往的IT投资是个浪费。我们设计一个框架，这个框架里任何一个组件，我们提供的是概念性的框架，框架里任何一个组件都是可被替换的，意思是说你可以新采购一个相应的组件，或者利用IT公司已有的组件来实现整个后台框架中某个部分，这样可以最大节省你的IT投资。
移动应用框架可以根据用户所使用移动设备的版本或带宽自动设定要推送的移动内容，当这家保险公司推动移动应用之后，不同的使用用户在不同的移动应用物理环境下，它所访问的带宽和设备本身的型号对你推送的内容和展现形式会得到完全不一样的效果，所以框架里很重要的部分是自适应的模块，根据你访问移动设备本身的特性，能够自动决定推送内容以及推送内容的形式，给你的终端用户最佳的用户体验。
介绍一个非常简单的演示，我们为这家保险公司提供了三个前端移动应用，针对勘查员的，针对代理人的，给普通用户方案的应用。这是在黑莓的平板电脑上（图），当然应用也可以在iPad、iPhone上应用，代理人启动系统之后可以查询所有保单信息，其中可以查询某一个保单具体的信息，或者近期修改或维护的操作，比如修改出账单的模式或方式，可以查看这几个保单到某一天为止的现金价值，做保单贷款或节约的话可以知道它的价值是怎样的。现在查看的保单是投连险的产品，这张保单下它的客户资金是怎么样在股票市场或者购买基金的时候怎么样进行分配的。
谢谢大家！
