保险公司和其他行业一样，都有自己对外销售的产品，一款保险产品是一系列计划、险种、责任、条款、费率等等属性的合集。
保险公司需要将产品对应的上述信息结构化地定义在核心系统（后台系统）中，以支持对应渠道销售、投保核保承保、保全批单、理赔、财务资金、再保险等等后续流程。
一方面，市场竞争激烈，保险公司需要推陈出新；另一方面，保险是强监管的金融行业，当监管条款变更等情况发生时，公司往往面临着几十上百个产品批量集中整顿调整，且有严格的整改完毕日期。
而传统保险公司后台coding一款产品往往牵扯几乎所有系统同步配合改造，需要大量人力排期，且有大量的沟通协调成本、容易出错。因此产品工厂应运而生，其快速响应、前后打通的能力受到各家公司的青睐。
虽然产品工厂已经不是一个新概念，但目前市场上的产品工厂之间可以说是天差地别。
基础功能
从业务需求角度出发，基础的产品工厂至少支持以下业务规则的定义：
产品结构定义：应该支持产品、计划、险种、责任大项、责任明细的层级框架；
销售计划定义：支持在产品各个层级的销售计划定义，例如一个计划包含哪些险种责任等；
费率定义：支持费率表定义，能快速响应费率试算；
保单条款属性定义：支持产品、险种、责任层级各个属性的定义，例如责任的可赔付范围、保额赔付比例等各类数据。这要求产品工厂有大量的业务字段，并且和前后各个系统打通；
产品版本管理之发布产品：产品配置项很多，容易发生错漏，一般会有预发布和正式发布的管理模块。
进阶功能
产品版本管理：支持停售（生效区间）、升级、转保、复制功能；没有此功能，则将每个产品都当作是一个全新的产品处理。
数据字典：支持固定字段（例如保额）和产品特殊字段设置，由此可进一步结构化定义保单特别约定；没有专门的数据字典则需要通过开发建表、建字段的流程管理；
理赔规则配置：支持产品对应的可赔付事故类型、费用类型、理算规则等配置，部分公司也将此放在理赔系统，但对应产品工厂就应该在条款属性定义中充分考虑理赔需求；
核保规则配置：支持产品的核保规则配置，及规则触发路径等，部分公司也将此放在核保系统；
一个基本衡量标准就是，支持尽可能细化的产品属性、规则定义。但同时，考虑投产比和效率，过于特殊的规则仍建议coding支持，因此产品工厂需能与后台代码分流规则很好地结合。所以，产品工厂的产品结构、字典管理非常重要，后续所有的规则都需与这二者强关联。
此外，与下游系统对接是至关重要的，许多产品工厂只考虑承保出单，后端理赔等环节‘不管了’，导致下游系统仍需做大量的硬代码或额外的配置。
其他的稳定性、性能、操作便捷性、用户体验，则是不论什么阶段都要注意的，因为产品工厂本来就非常复杂，若经常报错、卡顿，会对使用者有较大影响。
一些特殊情况
作为产品工厂自身而言，自然是越强大越灵活越好。但是在具体公司生产中，要因地制宜。例如一些专业险公司，产品线单一，并不需要特别灵活的产品结构和数据字典，只需要固定的产品结构即可。
此外，在国内，许多个人产品的费率都是向监管报备、固定的，不需要非常灵活的费率计算引擎，实际上读取精算报备的费率表即可。
但是对于大的财产险公司，特别是千差万别的非车险，往往就需要较为强大的产品工厂。
对于没有产品工厂/想要更换产品工厂的公司，采购、联合开发是比较快捷的方式。
一款新产品涉及公司各个部门制定运营规则， 最终产品落地的时候往往只有产品部的对应人员使用产品工厂。这样带来一个较大的问题就是，运营规则最终没有落地到产品工厂，产品工厂在满足了出单销售的需求之后就无人跟进。
因此在初期落地产品工厂时，需要将各个业务部门及对应模块的IT纳入项目，并让其充分参与，且建立上线后定期检视机制。
这样做是为了避免产品工厂变成契约平台，其余各个模块的规则都在各个模块自行coding落地，从而弱化了产品工厂的价值。例如：医疗险可保范围是中国大陆地区就诊，而产品工厂没有定义这些属性，那么为了防止赔付海外就医行为，就需要理赔系统做特殊处理。久而久之，理赔会对不同产品定义不同的配置表，形成一个体外的小产品工厂。
最后
