一文看懂产品工厂

保险产品和产品工厂简介

保险公司和其他行业一样，都有自己对外发卖的产品，一款保险产品是一系列操持、险种、任务、条款、费率等等属性的合集。

保险公司须要将产品对应的上述信息构造化地定义在核心系统（后台系统）中，以支持对应渠道发卖、投保核保承保、保全批单、理赔、财务资金、再保险等等后续流程。

一方面，市场竞争激烈，保险公司须要推陈出新；另一方面，保险是强监管的金融行业，当监管条款变更等情形发生时，公司每每面临着几十上百个产品批量集中整顿调度，且有严格的整改完毕日期。

而传统保险公司后台coding一款产品每每牵扯险些所有系统同步合营改造，须要大量人力排期，且有大量的沟通折衷本钱、随意马虎出错。
因此产品工厂应运而生，其快速相应、前后打通的能力受到各家公司的青睐。

虽然产品工厂已经不是一个新观点，但目前市场上的产品工厂之间可以说是大相径庭。

什么是好的产品工厂？根本功能

从业务需求角度出发，根本的产品工厂至少支持以下业务规则的定义：

产品构造定义：该当支持产品、操持、险种、任务大项、任务明细的层级框架；发卖操持定义：支持在产品各个层级的发卖操持定义，例如一个操持包含哪些险种任务等；费率定义：支持费率表定义，能快速相应费率试算；保单条款属性定义：支持产品、险种、任务层级各个属性的定义，例如任务的可赔付范围、保额赔付比例等各种数据。
这哀求产品工厂有大量的业务字段，并且和前后各个别系打通；产品版本管理之发布产品：产品配置项很多，随意马虎发生错漏，一样平常会有预发布和正式发布的管理模块。

进阶功能

进阶的产品工厂，也是大产品工厂一样平常支持如下功能：

产品版本管理：支持停售（生效区间）、升级、转保、复制功能；没有此功能，则将每个产品都当作是一个全新的产品处理。
数据字典：支持固定字段（例如保额）和产品分外字段设置，由此可进一步构造化定义保单特殊约定；没有专门的数据字典则须要通过开拓建表、建字段的流程管理；理赔规则配置：支持产品对应的可赔付事件类型、用度类型、理算规则等配置，部分公司也将此放在理赔系统，但对应产品工厂就该当在条款属性定义中充分考虑理赔需求；核保规则配置：支持产品的核保规则配置，及规则触发路径等，部分公司也将此放在核保系统；页面配置：一些产品工厂已经支持后台出单页面的配置化。

同时，进阶产品工厂在根本版的功能细节上须要更加完善：

一个基本衡量标准便是，支持尽可能细化的产品属性、规则定义。
但同时，考虑投产比和效率，过于分外的规则仍建议coding支持，因此产品工厂需能与后台代码分流规则很好地结合。
以是，产品工厂的产品构造、字典管理非常主要，后续所有的规则都需与这二者强关联。

此外，与下贱系统对接是至关主要的，许多产品工厂只考虑承保出单，后端理赔等环节‘不管了’，导致下贱系统仍需做大量的硬代码或额外的配置。

其他的稳定性、性能、操作便捷性、用户体验，则是不论什么阶段都要把稳的，由于产品工厂本来就非常繁芜，若常常报错、卡顿，会对利用者有较大影响。

一些分外情形

作为产品工厂自身而言，自然是越强大越灵巧越好。
但是在详细公司生产中，要因时制宜。
例如一些专业险公司，产品线单一，并不须要特殊灵巧的产品构造和数据字典，只须要固定的产品构造即可。

此外，在海内，许多个人产品的费率都是向监管报备、固定的，不须要非常灵巧的费率打算引擎，实际上读取精算报备的费率表即可。

但是对付大的财产险公司，特殊是千差万别的非车险，每每就须要较为强大的产品工厂。

最大化发挥产品工厂的浸染产品工厂落地

对付没有产品工厂/想要改换产品工厂的公司，采购、联合开拓是比较快捷的办法。

建立产品工厂掩护制度

一款新产品涉及公司各个部门制订运营规则， 终极产品落地的时候每每只有产品部的对应职员利用产品工厂。
这样带来一个较大的问题便是，运营规则终极没有落地到产品工厂，产品工厂在知足了出单发卖的需求之后就无人跟进。

因此在初期落地产品工厂时，须要将各个业务部门及对应模块的IT纳入项目，并让其充分参与，且建立上线后定期检视机制。

这样做是为了避免产品工厂变成左券平台，别的各个模块的规则都在各个模块自行coding落地，从而弱化了产品工厂的代价。
例如：医疗险可保范围是中国大陆地区就诊，而产品工厂没有定义这些属性，那么为了防止赔付外洋就医行为，就须要理赔系统做分外处理。
久而久之，理赔会对不同产品定义不同的配置表，形成一个体外的小产品工厂。

末了

产品工厂的每个模块都是一个大话题，这篇文章就抛砖引玉地先容一下保险产品工厂，有同行的小伙伴欢迎互换。

本文由 @咩咩 原创发布于大家都是产品经理。
未经容许，禁止转载。

题图来自 Unsplash，基于 CC0 协议