51觅元素网 一文看懂产品工厂

发布日期:2020-01-11 17:08:26    浏览次数: 1814

51觅元素网 一文看懂产品工厂

51觅元素网,产品,大家都听过;产品工厂,你知道是什么吗?

保险公司和其他行业一样,都有自己对外销售的产品,一款保险产品是一系列计划、险种、责任、条款、费率等等属性的合集。

保险公司需要将产品对应的上述信息结构化地定义在核心系统(后台系统)中,以支持对应渠道销售、投保核保承保、保全批单、理赔、财务资金、再保险等等后续流程。

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

而传统保险公司后台coding一款产品往往牵扯几乎所有系统同步配合改造,需要大量人力排期,且有大量的沟通协调成本、容易出错。因此产品工厂应运而生,其快速响应、前后打通的能力受到各家公司的青睐。

虽然产品工厂已经不是一个新概念,但目前市场上的产品工厂之间可以说是天差地别。

从业务需求角度出发,基础的产品工厂至少支持以下业务规则的定义:

进阶的产品工厂,也是大产品工厂一般支持如下功能:

同时,进阶产品工厂在基础版的功能细节上需要更加完善:

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

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

其他的稳定性、性能、操作便捷性、用户体验,则是不论什么阶段都要注意的,因为产品工厂本来就非常复杂,若经常报错、卡顿,会对使用者有较大影响。

作为产品工厂自身而言,自然是越强大越灵活越好。但是在具体公司生产中,要因地制宜。例如一些专业险公司,产品线单一,并不需要特别灵活的产品结构和数据字典,只需要固定的产品结构即可。

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

但是对于大的财产险公司,特别是千差万别的非车险,往往就需要较为强大的产品工厂。

对于没有产品工厂/想要更换产品工厂的公司,采购、联合开发是比较快捷的方式。

一款新产品涉及公司各个部门制定运营规则, 最终产品落地的时候往往只有产品部的对应人员使用产品工厂。这样带来一个较大的问题就是,运营规则最终没有落地到产品工厂,产品工厂在满足了出单销售的需求之后就无人跟进。

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

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

产品工厂的每个模块都是一个大话题,这篇文章就抛砖引玉地介绍一下保险产品工厂,有同业的小伙伴欢迎交流。

本文由 @咩咩 原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自 unsplash,基于 cc0 协议

 
 
 
相关内容:

 
推荐图文
推荐新闻
点击排行