作者在《保险趋势分析与数字化转型》文章里提到了保险业务系统中台化后保险商品化和订单化的销售模式，本文主要通过购物车、订单中心、微前端以及产品通道等技术手段，对保险企业实施中台战略后的保险订单化销售模式进行设计，形成可实施的方案。
随着5G技术的应用，人们的消费方式将进一步移动化和线上化。电子商务交易中最重要的维系双方契约的凭据就是订单。订单化销售模式是目前最通用的电商销售模式。而保险由于各种原因，现在主要通过保单的方式进行产品的销售。
随着电子保单的使用，保险公司与客户之间交互的环节将变得更简单。保险流程虽然复杂，但通过保险产品、业务流程和技术方案设计，也可以具备便捷的订单化销售能力，让用户在购买保险产品时也能与购买电子商务商品一样，有一致的体验。
一、为什么保险需要订单化的销售模式？
1、集团化和一体化运营和销售的需要
为充分利用销售资源，实现集团一体化的综拓销售和所有子公司保险产品的一体化交叉销售，集团或子公司前端销售界面如柜台、电子商务网站或者APP，需对所有产品实现无差异的一体化运营和销售，但由于系统边界等原因，客户很难享受到流畅的服务。
以产险为例，承保业务基本上是以车险和非车险产品为边界建设的。由于前端没有统一的销售界面，承保过程中基本都是以某个系统进行竖井式的操作，用户一次只能完成一类产品承保。如果保险产品涉及跨车和非车险时，用户需要分别操作两个系统，才能完成承保流程，并且后端核保、支付等业务也在重复进行。
同一公司内跨车和非车险系统的产品销售尚且存在体验的问题，如果把产、寿、健和养老所有子公司保险产品放在一起统一运营和销售，面临的问题就更复杂了。
使用电子保单后，客户并不关心纸质保单， 保险公司与客户之间的关系也变得更简单。借鉴电商订单化的销售模式，我们可以在保险产品之上增加一个实体，这个实体就是订单。
在前端，订单实体实现所有产品销售的客户统一接触。
在后端，由于客户主要关心订单以及订单所关联的保险商品是否购买成功，并不太关心后端复杂的流程。订单实体可以协同后端承保专属业务中台，异步完成所有的业务流程。原来需要实时处理的业务流程，都可以转化为异步操作，实现系统间彻底解耦，减轻系统的压力。
订单化销售模式可以为跨多个保险产品的集团化或保险商城等销售场景，提供无差异的一体化销售和一致的用户体验，同时还可以通过事件驱动的异步化的模式，实现系统彻底解耦，降低系统压力。
2、用户电商模式购物体验的需要
既然销售要线上化，那就用线上的Style去购买保险商品！
通过订单化的销售模式，让客户以电子商务熟悉的流程和方式购买保险产品，提升用户的体验。
二、微前端、业务中台和产品通道
在本节引入两个新概念：微前端和产品通道。
1、微前端
先来解释一下什么是微前端？微前端是ThoughtWorks2016年提出来的，它将微服务理念扩展到前端开发，在前端同时构建多个可以独立部署、完全自治、松耦合的页面组合，其中每个组合只负责特定的 UI 元素和功能。通过前端页面集成组件（类似门户）根据产品和业务环节动态加载微前端页面，完成全部业务流程。
微前端理念最初的出发点是：中台微服务化后，微服务所对应的前端页面仍然采用单体模式，为了降低前台逻辑的繁杂和臃肿，因此按照一定的规则将前端页面进行拆分。微前端方式除了可以实现前端页面的解耦外，还可实现前端页面逻辑的复用，做到“一次开发，多端复用”，这也与中台的服务共享理念是一脉相承。
做前端设计时可以借鉴微前端设计理念，将可共享的前端页面改造成微前端。如为承保专属中台投保微服务，建立保单录入微前端。保单录入微前端与投保微服务两者协同完成保单录入操作。
适配不同终端的微前端，经过简单配置就可以快速加载到PC端、APP以及智能终端等各个前端集成框架中。集成后端业务逻辑的微前端，无需再次开发即可实现复用。
微前端复用主要包括两类场景
1）单一产品销售场景：同类产品微前端可独立部署，稍加调整即可作为APP或者直接作为web应用进行发布，极快响应单一产品销售场景的业务要求。
2）组合产品销售场景：不同类产品微前端可根据业务路由规则，快速加载到PC、APP、智能终端等前端集成框架，进行多产品组合销售。
微前端设计要点
1）所有微前端有统一的界面风格。
2）微前端可根据保险商品目录中的URL地址加载到前端集成框架的指定区域。
3） 微前端和专属中台微服务由一个团队开发，微前端已与中台微服务集成，两者配合可以独立完成本产品领域内操作。
4）同类产品专属业务中台的投保和保单管理微服务有录单和保单管理微前端，作为录单和保单管理操作界面。
2、产品通道
由于不同的保险产品面向不同的场景，解决的问题不同，在录单要素、业务规则以及流程等方面存在较大的差异，因此不同类的保险产品其领域模型也会存在不同。为了避免不同类产品之间的相互影响和干扰，在进行承保专属业务中台设计时，建议以同类型相似场景的保险产品作为聚合进行承保专属业务中台的建设，而不是简单的以车险和非车险两类产品边界建设。
什么是保险产品通道？保险产品通道是为了后续讲解方便定义的一个新名词。
保险产品通道包括保险产品所在的微前端、承保专属业务中台以及专属业务中台后端对应的收付费、佣金、再保等通用中台和客户统一视图和业务统一视图等数据中台。同类产品在这个通道内完成录单、投保、保单生成、退保、批改以及向后端送数等操作。保险产品通道主要隔离点在微前端和承保专属业务中台。同类产品使用同一个产品通道，不同类产品使用不同的产品通道，所有流程无交叉，功能相互隔离。
借助客户、用户、订单、核保和支付等通道外的通用中心，从录单、投保到保单管理等流程在产品对应的微前端和专属承保中台的通道内自包含完成。保单的后序业务流程根据业务规则自动触发，多个产品通道通过各自专属业务中台的保单管理微服务将数据异步汇集到后端收付费、佣金、再保等通用中台以及客户统一视图和业务统一视图等数据中台（如下图）。不同类产品后端接收数据的中台可能会不一样，如寿险专属业务中台会将数据送到寿险子公司的后端，财险专属业务中台会将数据送到财险子公司的后端，数据传输逻辑已在各自专属业务中台保单管理微服务中完成。
微前端、中台与产品通道
产品通道设计要点
1）承保流程中不同保险产品通道之间无交叉和交互。
2）同类产品承保业务流程在自己专属产品通道内完成。
产品通道的意义
1）业务专一性：领域模型更聚焦，功能更单一，前后端项目团队规模更小，集中办公，更专注于本领域内的业务逻辑和微前端。产品通道业务高度内敛，同类产品录单、流程和规则基本相似，不包含不同类产品的要素，产品之间干扰小，用户体验会更好。
2）职责专一性：由于产品通道完成了从前到后的全部流程，专职于产品中台业务逻辑和微前端页面的实现。因此谁负责产品，谁就负责微前端和专属业务中台全通道业务逻辑的开发。前端集成项目只需完成微前端的集成即可，集成过程甚至都不需要API层面的集成，减轻前端集成压力和界面开发的复杂度。尤其对于集团级跨子公司（主要问题是系统和业务相互不熟悉，接口和集成复杂，沟通成本高）的系统集成会带来极大的好处，降低沟通成本和集成的复杂度。
3）复用性：微前端和业务中台都有高度的复用性。微前端只需在商品目录中完成URL地址配置即可快速加入前端集成框架，或将微前端直接发布到APP等，实现快速发布。某些场景甚至一个微前端就是一个应用，直接可以完成一类产品的出单。
4）隔离性：同类产品的逻辑代码的修改都被控制在一个产品通道内，不会影响任何其他产品通道的业务。不同产品通道内各层代码的发布以及新产品通道的上线相互隔离，通道之间不受影响。
5）响应能力：新型产品只需新增商品目录和添加微前端地址即可快速完成上线。已有产品通道只需要在前端集成框架内加载微前端URL地址就可以完成业务发布。
6）可配置性：商品目录中配置产品微前端地址，前端集成框架根据产品微前端URL路径加载微前端。
7）沟通成本低：一个产品通道由一个项目团队完成，沟通和测试成本低。
3、承保专属业务中台
由于不同保险产品领域模型的差异，建议以同类和相似场景的保险产品（如车险类、意外类、财产类、货运类、寿险类、健康类等）进行功能聚合完成承保专属业务中台建设。承保专属业务中台至少应包含投保和保单管理两个微服务，每个微服务对应一个微前端。
投保微服务主要存储客户接触过程中的投保数据和处理投保业务逻辑。与录单微前端配合完成录单和投保操作，配合核保中心完成核保操作，订单支付完成后，订单触发投保微服务将投保单转成保单，并异步传送保单数据和客户统一视图数据。
保单管理微服务异步接收从投保微服务转保后的保单数据。异步传送后续流程需要的数据，如：佣金、收付费、再保以及客户统一视图库和业务统一视图数据。配合保单管理微前端完成保单批改和退保等操作。
4、前端集成框架
前端集成框架类似门户，集成所有微前端页面，按照正确的逻辑（如根据产品加载对应的录单微前端，完成录单和投保）加载微前端页面，协同配合完成相应的业务流程。
前端集成框架会预先给每一个微前端分配指定的页面区域，前端集成框架须与所有需要加载的微前端的页面风格保持一致。
前端集成框架组合各微前端作为一个整体，为客户提供所有保险产品销售的统一的接触和体验界面，包括商品展示、录单、购物车、订单管理、支付管理以及退保和批改等保单管理操作。
举例说明：前端集成框架根据客户选择的保险产品，从商品目录中获取微前端URL地址，在指定区域加载录单微前端页面，录单微前端与投保微服务配合，在产品通道内完成投保单的录入和生成。根据保险产品加载对应产品的保单管理微前端，与保单管理微服务配合在产品通道内完成保单退保和批改操作。
三、保险商品目录
实现保险订单化销售需要建立标准的保险商品目录，并将商品目录数据前推到前端应用。
1、保险产品需要形成标准的保险商品目录，为客户提供统一的商品展示，保险商品目录信息存储在保险商品配置中心（如Redis），商品目录数据应包含：产品基本信息、条款以及产品微前端URL以及API地址等内容。
2、产品路由信息包括产品对应的投保和保单管理微服务所对应的微前端URL地址和保险产品专属业务中台API地址。选择完产品后，前端集成页面可根据URL地址加载微前端页面URL完成录单。投保单生成后，订单中心可根据产品API路由访问专属业务中台API。
3、保险商品目录信息由产品中心统一配置，推送到所有与产品销售相关的前端应用。
4、保险产品专属业务中台应提供标准统一的API服务，可根据产品自动适配，减少不必要的开发和集成。
四、购物车、订单中心与支付中心
在原有保险应用的基础上，新增两个中台应用：订单中心和支付中心，并在前台应用中增加购物车功能。
购物车主要用于暂存投保单的清单数据，清单数据可存储在前端缓存（如Redis）中。投保单的明细数据存储在投保微服务所在数据库中。
订单中心是前端应用和业务专属中台的桥梁。前端应用、购物车和订单中心一起为客户提供统一的产品销售和接触服务，订单支付完成后由订单实体协同保单实体完成异步流程。
支付中心提供面向订单的统一支付服务，订单支付完成后，通知专属业务中台投保微服务完成转保单操作，转保完成后订单中心将所有与订单关联的保单置为生效状态。订单中心保存保单的清单数据，保单明细数据保存在保单管理微服务数据库中。
五、核心业务流程和设计要点
统一说明：以下时序图暗红色线条为实时操作，蓝色线条为异步操作。
1、保险产品模型和管理
商品目录是订单销售模式一个重要的点，商品目录需提供保准的保险产品描述、条款等基础数据，因此需要设计一个标准的保险产品模型。
借用大家都熟悉的面向对象的设计方法来解释一下保险产品模型。我们在定义一类对象的时候，通常首先需要先定义一个抽象的Class类，这个Class类中定义了这类对象的属性和方法，在执行过程中Class类会实例化成对象，根据不同的对象给属性加载不同的数据，根据不同的数据输入计算出不同的结果。
映射到我们的保险产品体系中，这个Class就是保险产品模型，而对象对应根据保险产品模型加载业务信息后的保险产品。通常保险产品包含：保险的基础信息、条款、报价规则、佣金规则等信息。保险的基础信息和条款等内容属于静态信息，可以认为是Class里对象的属性，而保费计算以及佣金计算等可以认为是Class里对象的方法。为建立标准的保险产品体系，首先需先定义标准的保险产品模型，再针对具体的保险产品赋予相应的属性和业务规则。
为了保证产品领域模型的完整性，产品中心可集中定义产品所有的通用描述信息、条款等属性信息以及通用的保费和佣金等计算规则，实际计算和业务流程可在产品所在业务中台（如报价、佣金等）内完成。
产品中心是一个后端集中的配置中心，产品通用配置数据在产品中心内中完成，个性配置数据可在中台和前端应用自行配置。产品中心不参与实际的业务流程。在完成产品通用信息和规则配置后，将数据异步发送到对应的业务中台和前端应用完成产品相关的业务操作。
产品中心配置数据推送时序图
主要业务流程说明
1）在产品中心完成产品数据配置（含新增以及变更）。
2）产品基础数据和条款等基础配置数据异步发送到商品目录缓存。
3）通用定报价规则和配置数据异步发送到报价中心。
4）通用佣金计算规则和配置数据异步发送到佣金系统。
2、投保单的生成
投保流程涉及到保险商城（由前端集成框架实现）、商品目录、产品通道中的录单微前端和投保微服务、报价中心、购物车以及投保单视图的客户统一视图等几个功能。
投保单生成
主要业务流程说明
1）保险商城从商品目录中加载保险商品清单。
2）客户选择保险商品。
3）保险商城根据客户选择的保险商品，从商品目录中获得该产品的录单微前端URL地址，并加载到保险商城的指定区域。
4）客户在录单微前端完成投保单录入，提交投保单微服务，生成投保单，调用报价中心API完成保费计算。
5）投保单微服务向保险商城返回投保单基础信息和保费数据。
6）客户在保险商城将投保单加入购物车。
7）如需购买其他产品，重复1-6步骤。
设计要点
1）录单微前端URL地址与产品配对，存储在保险商品目录缓存中，前端选择完产品后，由前端集成框架将微前端页面加载至指定区域。
2）投保单清单数据存储在保险商城的应用中用于前端展示。投保单明细数据存储在投保微服务数据库中。
3）投保单生成后，投保单一部分清单数据会异步发送到客户统一视图数据库中，任何渠道都可查询到客户未生成保单的投保数据。
3、核保与订单支付
核保环节涉及到投保微服务和产品对应的核保中心。在购物车中选择多个核保通过的投保单，生成订单，一次完成订单关联的所有投保单保费支付。订单支付环节涉及到订单中心和支付中心。
核保与订单支付
主要业务流程说明
1）客户从购物车中选择多个投保单，一次提交核保，向产品对应的核保中心发起核保申请（包含投保单概要信息）。核保流程也可在投保过程中完成，设计时可根据具体情况考虑。
2）如商品免核保或自动核保，则直接返回核保结果。
3）如需人工核保，核保中心根据商品投保单号，从投保单微服务获取投保详细信息，完成核保，返回核保结果。
4）客户从购物车中选择多个核保通过的投保单，生成订单。
5）提交支付中心，一次完成订单关联的所有投保单支付。
设计要点
1）从保险商城通过队列向核保中心异步提交核保，核保完成后核保中心通过队列向保险商城异步返回核保结果（监听模式）。
2）在商品目录中配置产品对应的核保中心API地址。
3）生成订单后，订单实体需关联所有投保单号，并存储投保单的清单信息，用于前端展示。
4）对于时间较久的订单和投保单，提交支付前前端需要核验所有投保单的保费计算和核保结果是否在有效期内，如果超过有效期，需要重新计算保费和核保后才能支付。
5）所有产品都是在自己的产品通道内并发进行。
4、保单生成和后续内部管理流程
支付完成后的主要流程为异步操作。
保单生成操作主要涉及投保微服务和保单管理微服，保单号在投保微服务中生成，通过事件驱动机制异步将保单数据发送到保单管理微服务。
后续流程涉及到佣金、再保、收付费以及客户统一视图，也主要采用异步方式。
保单生成和后续内部管理流程
主要业务流程说明
1）订单支付完成后，由订单实体通知各产品通道中的投保微服务生成保单。
2）投保微服务收到转保单通知后，将投保单转保单，并关联保单号。转保单后投保微服务有三个异步操作：（1）通知订单中心已完成转保单操作，同时将保单清单数据返回订单中心；（2）将保单明细数据异步发送到保单管理微服务；（3）通知客户统一视图，修改投保单状态（标注已转保），并关联保单号。
3）订单中心收到转保成功和保单基础数据后，将订单实体与所有保单关联，保存保单清单数据用于前端展示。
4）保单管理微服务收到保单明细数据后，将保单数据保存在数据库中，异步发起送佣金、再保、收付费和客户统一视图动作。
设计要点
1）由于后端业务逻辑比较复杂，为了实现解耦，本部分的大部分操作都是采用事件驱动的异步化方式进行的。
2）对于优惠的场景，订单根据整单保费和优惠规则，在订单内对保费进行重新计算和分配，并将重新计算后的保费数据保存到保单中。保单保费信息将有两个字段存储：标准保费和优惠后的保费。
3）如不存在优惠的情况，标准保费和优惠后的保费数据相同。
4）按照优惠后的保费数据完成异步送数。
5） 所有产品都是在自己的产品通道内并发进行。
5、客户一致性服务
客户的一致性体验主要通过客户统一视图来实现。前端应用每生成一份投保单和保单都会与客户ID关联，并分别存储在投保单视角和保单视角的客户统一视图库中。
投保单视角的客户统一视图主要存储跟客户投保相关的所有渠道的投保数据，以客户维度作为分库主键。客户投保时可以看到自己任何渠道产生的未转保的投保单数据，可以以此为基础继续完成投保操作。后续过程中任何渠道投保单如果已转保，都通过异步的方式，修改客户统一视图中的投保单数据，保证数据的一致性。
保单视角的客户统一视图主要存储客户所有渠道的保单数据，以客户维度作为分库主键。客户在通过统一视图可以看到自己在集团内所有子公司各个渠道生成的保单数据。保单视角的客户统一视图数据可以为后续批改、退保和续保等流程提供保单查询服务。保单数据的任何修改都在产品通道的保单管理微服务中进行的，任何渠道对保单数据的修改都需通知客户统一视图修改，保证客户保单数据的一致性。
6、保单管理
保单管理的退保和批改可以从前端订单中发起，通过订单找到关联保单，统一由保单管理微服务完成保单管理业务。
也可以通过客户统一视图或者保单库的查询找到保单后在后端直接发起，统一由保单管理微服务完成。
根据具体的场景选择合适的方式，必须确保所有的操作都在自己的产品通道内完成。详细流程本文不再赘述。
六、写在最后
1、订单化的销售模式有利于集团级的产品无差异的一体化销售，提升客户体验。
2、微前端和产品通道的模式从前端页面到中台服务可以实现全面复用。
3、利用微前端可在前端实现拼图式开发，通过微服务可在中台实现积木式开发。
4、产品通道的模式可实现产品级拼图式快速集成。
5、产品通道的模式可以让前端集成人员不必关心产品技术实现。
网友评论