三津谈保险系统建设（二）：保险业务系统发展变迁

以史为鉴：
我们要设计保险的系统建设架构，闭门造车只会又进入大部分保险公司的“新核心”的建设的轮回中。前文已经说了大部分保险公司的建设方案，我这里主要分享下一些互联网保险的系统建设架构，并附上自己的一些看法，这里很多都不是保险公司，而是大的中介公司，但由于业务的强势已经有了保险核心的雏形，可以借鉴其中值得学习的地方。

其实大部分保险公司的系统建设比较清楚，不管是大型保险公司还是中小型保险公司，无非是复杂度和五脏全不全的差异。保险公司除了办公、财务、人事管理这些比较独立专业性比较强的系统，最重要的系统就是核心业务系统了以及服务于它的外围系统。2015年以前还是大核心为主，核心系统在保险公司的地位不言而喻，IT建设投入也是大头在核心系统建设。现在基本上都是 “瘦核心、大外围” 的建设思路。

为什么会瘦核心？

1. 业务变化：

首先业务发展促使了核心的地位下降，保险业务已经从原先的录单员为主改为了电子单（渠道导入、线上电子单等）为主的模式了。
传统的核心系统更多的业务功能都是沉淀在复杂的线下路单业务流程上，比如之前扫描录入、影像随动、照书下发以及复杂的业务工作流和核保规则流程。应对复杂多变的业务流程，核心系统得心应手（吐槽下：一般都是大量的if语句和循环嵌套中默默实现，这是程序员大展手脚、随心所欲的时代。不受限于任何代码规范，不受限于任何设计模式，只要格式化做的好，别人看不懂你的代码，基本上就是一个合格的程序员了）不是核心系统不好，而是传统核心的设计就是面向复杂的线下业务，由于线下业务业务流程复杂、业务规则繁琐加上分支流程多等特点，加上是ToE的业务系统对并发要求并不高，如果不是有一些保单导入的业务，100Tps都是遥不可及的梦，查多写少也是保险系统的一个重要的特征。

2. 架构变化：

其实架构变化也是业务变化造成的，原先核心系统是一个大家长，基本主要的业务都在核心完成、加工处理。所有的外围系统都围绕着核心系统建设，监管系统、报数系统如果没有核心团队的支持，定制开发的工作量绝对可能会被double，要看核心团队是否配合你了，这也是很多保险公司觉得被ISV绑架的原因。而随着监管对数据要求的标准化和深入，以及渠道的多样化、产品的简单化，业务系统不再依赖复杂的业务处理流程转而对业务的灵活性以及场景的多样性有了强依赖，这就不是传统核心的强项了。外围系统承担了越来越多的业务逻辑，业务前置化成为了大多数保险系统建设的“被迫”选择。随着前置化的增加以及厂商推波助澜，“瘦核心、大外围”的方案也就逐渐🔥了起来。

【瘦核心】
目前很多公司的核心系统只是一个“保单仓库”和处理零星线下业务的流程系统。当然由于是保单的集散地，承担数仓、监管供数的指责也就在所难免了。这也就是目前瘦核心的比较瘦的一种情况了。

【大外围】
由于越来越多的业务前置，外围系统承担了更多的业务逻辑，外围系统的重要度和建设投入自然而然的占了更大的作用，比如电商由原来的接口平台变成了一个小核心。于此同时互联网保险的崛起，让阿里的中台建设逐步渗透到了保险公司的外围系统建设理念中，目前大多数外围系统都是围绕着业务中台的打造的，也就有了如下的架构：

装逼讲故事利器——大数据与AI

当然保险公司的建设必然会被一些大的供应商影响，每年IBM、华为、阿里、腾讯等都会推出一个新的概念，大数据、中台、场景连接、云原生等层出不穷，当然也是为了推广他们的产品和方案打基础，有时甚至一个词换下顺讯用两年，比如保险科技、科技保险😂。有的时候不是供应商的故事多么动听，而是保险公司的IT建设也需要一个故事去体现他的价值，去讲给别人听，所以也就形成了一种行业默契。在这些故事中，最近几年最火的就是大数据和人工智能了。

1. 大数据平台

保险公司纷纷将BI系统更换为了更时髦的大数据平台，只有一些小型保险公司没有足够的资金支撑，还在使用原来的BI系统来解决经营数据需求，随着时间的推移，保险公司赫然发现老的BI系统也是可以支持经营数据的需求的，同时数据管理似乎也不比那些引入的大数据平台的保险公司差多少。造成这个情况的原因还是因为很多保险公司为了引入大数据平台而引入，不是出自自身的业务场景需要而建设。根据别人的故事而建设，当然会出问题 ，一般情况保险公司的大数据平台的团队和业务研发团队通常都是两拨独立的群体，并且抱着老死不相往来的信念工作。

大数据团队： 大数据团队还是抱着原来的BI团队思维，业务系统把数据结构告诉我就行了，你们这帮写if-else的土鳖懂个屁啊，一个实体七八种模型，真不知道系统是怎么跑的，数据建模和经营分析就靠我了。
业务研发团队：这帮提数的换了个地方写sql而已，写sql的都是代码写不好的才去干的。 自己去看模型吧，别来烦我！给你们讲业务你们也不懂，将我讲关系，关系哪是那么好理的？你们的那些提数sql还不都是衍生自老子原先的写的提数sql脚本？

所以很多公司大数据平台的引入既没有解决数据治理的问题，同时还好成为了需要治理的对象之一，新增了一套数据规范和字典。数据中台的概念是继承了阿里的数据中台思想，但其实完全走的是两条路：解决业务需求之路和装逼遭雷劈之路。
大数据已经讲了很多年，真正把大数据平台用的比较好的似乎不多，一些大的保险公司因为有实际需求场景和数据规模，应用会比中小保险公司要好一些，不过大多也是聚焦在几个场景，大的公司自然关系复杂，流程复杂，很难将大数据建设的理念整体推行。

2. 人工智能

人工智能就是又一个讲故事的大杀器，随着大数据概念被人们所习惯，AI已经成为了新的宠儿，应该是当下最火的一个概念，你的方案和产品要是不扯上点AI就说明没什么技术含量似的。AI是否智能主要取决于2点，一个是模型，一个是数据，没有足够的数据样本支撑，一般都是人工智障平台。在蚂蚁的时候，因为有足够的数据样本，但人工智能的表现也是不如专家法则的，一般都是通过专家法则去修正AI算法，让AI算法贴近于专家的判断结果，当然这是有足够的数据样本支持、完善的AB能力和数据分析能力的前提下做到的，保险公司要做到这种程度确实难度不小。
保险人工智能刚刚起步时，这些有“痔”之士觉得自己终于拿到了一把屠龙刀，不革命下社会怎么对的起自己手工的刀。基本上都是奔着替代人的目标推出的一系列AI产品，虽然保险公司发现这些智能产品有些智障后，AI团队开始纷纷指责是因为数据标本的质量不行、数量不够导致，经过了多年的行业抽打，终于面对现实，纷纷从“替代人”变成了“辅助人”，反而取得了一些不错的成果。目前保险的人工智能主要体现在以下几个领域：

• 智能核保（辅助）
• 智能理赔（辅助）
• 售前辅助
• 营销推荐 人脸识别、影像识别、NLP、ASR等
• 业务流程智能化（目前多为规则引擎以来固定规则实现，很少有真正的智能优化）

营销推荐场景比较适合有大流量的保险公司或者平台，多位蚂蚁、众安、微保等平台应用，目前对一般保险公司业务意义不大。售前辅助反而是一般保险公司用的比较多的场景，保险公司多数还是要依赖人去服务客户，售前辅助可以极大的降低员工的要求和培养周期，同时增加员工的服务人数和质量。售前辅助一般都是智能应答、智能推荐答案、智能质检等。
至于智能核保和智能理赔，我就只能呵呵了。说实话意义不大，即使是蚂蚁保险这种公司这种业务规模也做不到智能定损，一般的保险公司就没必要尝试了，不如借助个视频平台完成智能勘查比较靠谱。至于智能核保嘛有闲钱的可以尝试下，也是个鸡肋产品。有人说可以达到90%的准确率，确实是可以，但这是基于大量的训练优化的场景下达到的，而10%的错误率并不能让保险公司节省人力，对比原来的规则建设的核保平台业务提升真的有限。

引入大数据和AI后，加上阿里的中台建设方案，最后就成了这个样子：

最后在说下监管，随着中保信的快速发展，银保监对行业的数字化建设要求和监管力度的加强，监管的建设已经成为保险IT建设的重要考虑因素。监管功能也从原来的抽数平台逐步变成了一系列系统组成的监管平台。除非是实时性要求比较高的监管拱数场景，大部分监管系统都是在数据中台的基础之上建设的， 这也是后来数据中台发展的重要业务方向之一，最终成为了如下架构：