本文以国内某保险公司的财产险核心系统为例，初窥保险系统设计，供后续设计参考探讨。
如有不甚专业或错漏失当之处，还望不吝批评指正。
业务角度
首先，有两个大的领域，承保领域和理赔领域。
- 承保：所有围绕销售保单而开发的系统，都归在承保领域下。可以简单理解为进钱的业务。
- 理赔：所有围绕报案理赔而开发的系统，都归在理赔领域下。可以简单理解为出钱的业务。
在承保领域，站在市场销售的角度看，可以分为个人保险（个险）和团体保险（团险）两大业务板块，出的单一般可以简称为个单和团单。
在理赔领域，以理赔流程的差异性来看，可以分为车险、财产险、意（外）健（康）险。这里的财产险是狭义，大到海陆货运、建筑物、工业设备，小到家财、手机等。意健险，一般包括一年期的医疗险和意外险。
以下大致列出本人所了解的两个领域下的细分的领域。
|
一级领域
|
二级领域
|
职责简介
|
|---|---|---|
| 承保(Underwriting) | 产品工厂(Product Factory) | 保险产品的管理，包括险种、产品的配置。 |
| 询价(Quotation) | 保险询价，生成询价方案的流程。 | |
| 出单 | 产生保单，下单的流程。 | |
| 核保 | 核保流程，决定是否承保或加条件承保的流程。 | |
| 批单(Endorsement) | 批单流程。 | |
| 再保(Reinsurance) | 将原保单再次保险给其他公司的流程。 | |
| …… | ||
| 理赔(Claim) | 报案（Report） | 客户给保险公司上报险情的流程。 |
| 立案、查勘（初勘、复勘）、定责定损、核责核损、理算等 | 具体的理赔流程，不同险的由不同的环节构成。按是否自动化来分，可以分成自动理赔和人工理赔。 | |
| 支付（Payment） | 理赔款项下发财务的流程。 | |
| …… |
以上未能全部列举完。另外还有其他公共的业务系统，如财务系统、客户信息服务系统等。
技术角度
数据流转方向
- 原则上（同时务必要严格遵守的），承保领域维护保单数据，不处理任何理赔相关数据，同样的，理赔领域维护理赔数据，不处理任何保单数据。
- 在从承保到理赔这个方向，通过“抄单”这一动作来完成数据流转。在报案时，理赔根据保单的标识（保单号、身份证号等）从承保查询并获取保单及批单数据的逻辑，就叫抄单。保单数据加报案时的出险数据共同构成了报案领域的数据。报案数据是理赔后续流程的数据基石。
- 从理赔到承保方向的数据流转，暂无统一定义，但必然是由理赔提供统一的接口来传数据给承保。
业务主键设计
以下表格介绍一些业务主键的设计，供参考
| 源系统 | 业务主键 | 描述 | 参考名称 | 备注 | 举例 |
|---|---|---|---|---|---|
| 产品工厂 | 责任属性编号 | 责任属性的唯一编号 | dutyAttributeNo | 对责任的描述 |
|
| 责任编号 | 责任的唯一编号 | dutyNo | 一个责任可以对应多个责任属性，因为一个责任可以包含多个责任属性 | 住院责任包括上述1和2 | |
| 险种编号 | 险种唯一编号 | planNo | 一个险种可以对应多个责任，因为一种保险可以有多个责任。 |
医疗险H1：住院责任；门诊责任； |
|
| 产品编号 | 保险产品唯一编号 | productNo | 一个产品可以对应多个险种，一般可以有一个主险，零个或多个附加险 |
X万意外健康险产品： 主险：意外险A1 附加险：医疗险H1 |
|
| 询价 | 询价单号 | 询价单的唯一编号 | quotationNo | ||
| 出单 | 保单号 | 保单的唯一编号 | policyNo | ||
| 批单 | 批单号 | 批单的唯一编号 | endorsementNo | 一张保单可以对应多张批单，因为一张保单可以发起多次批改。 | |
| 报案 | 报案号 | 报案的唯一编号 | reportNo | ||
| 理赔 | 赔案号 | 赔案的唯一编号 | claimNo | 一个报案可以对应多个赔案，因为一次报案可以产生多次赔付。 | |
| 支付 | 支付号 | 支付的唯一编号 | paymentNo | ||
| 通知单号 | 通知的唯一编号 | noticeNo | 一张通知单可以对应多个支付号，因为一次下发财务的通知可以合并多条支付。 | ||
| 客户信息 | 客户号 | 客户的唯一编号 | customerNo |