Proposal

团险建议书方案比较

团险建议书是一个全新的模块，其今后主要用户将是团险代理人，而代理人在使用要求和习惯上跟内勤会有很大不同。而建议书的数据量比核心系统新契约要大的多，通常要高出一个数量级。另外，出于安全性的考虑，保险公司中供代理人使用的系统常跟核心系统会进行一定程度的隔离。因此，出于长远考虑，我们要对建议书模块的开发要慎重考虑。我们特提出如下几个方案进行比较，以提供参考。

方案A: 数据库不分离，数据结构复用，代码复用

1.                                     建议书模块放入核心系统中，建议书复用并扩展投保单对象的部分业务逻辑代码，建议书录入将直接使用新契约中初审和预收录入中大部分子窗口页面和代码。

2.                                     建议书跟投保单存储在同一数据库中，建议书在原投保单的表结构上加以扩展， 建议书与投保单通过标志位进行区分。建议书相关子表复用投保单子表的结构。

方案B: 数据库不分离，数据结构复用，少量核心业务逻辑代码复用

1.                                     建议书模块放入核心系统中，建议书复用投保单对象的少数核心业务逻辑代码(投保规则和保费计算)。其他代码和页面保持建议书的独立。

2.                       建议书跟投保单存储在同一数据库中，建议书在原投保单的表结构上加以扩展， 建议书与投保单通过标志位进行区分。建议书相关子表复用投保单子表的结构。（这条同方案A）

 

 

方案A

方案B

与新契约耦合度

建议书与新契约耦合太紧，从表示层到业务逻辑到数据存储都深度耦合。这种耦合限制了将来两个功能的独立发展。

建议书与新契约耦合大幅减小，各自的界面和录入流程互不影响，可以自由的独立变化。

代码可维护，可扩展性

由于建议书用户和新契约用户在使用习惯上的差异，两块功能的差异会越来越多。这样有可能导致当某些页面不能兼容两个功能时，出现较大程度的返工。

建议书拥有自己独立的代码，代码结构清晰，易于维护。

投保单的查询和报表统计的效率

建议书数据和投保单存储在一起。而建议书的数量一般来说会比投保单多上一个数量级。这样当业务量膨胀时，投保单的查询和报表统计的效率将会受到很大的影响。

同A

对原投保单功能的影响

由于建议书数据和投保单存储在一张表中，我们需要加字段以区分建议书和投保单。则投保单的查询和报表统计的程序要相应修改，否则会查询到建议书的数据。这是额外的工作量。但这种修改点可能较难定位。因此发生的数据统计错误也比较隐蔽。

同A

工作量

工作量较小，能较快实施

大概比方案A多出5到6人天的工作量

 

 

 

方案C: 使用同一个数据库实例、不同的Schema

1.         建议书和核心系统使用不同的应用服务器, 可以在同一个物理服务器上建不同的实例。

2.         建议书数据和核心数据存放在同一个数据库中，但在不同的Schema中。如核心系统使用Schema B，而建议书使用Schema A。这样两者可以使用同样的表结构，又是分开存储的。

3.         在Schema A中创建产品信息和代理人信息等只读同意词，在建议书系统可以直接访问，但不能修改；产品建议书，投保单位，被保人等信息在Schema A中建表；

4.                       后期保单转建议书或建议书转投保单等功能需要应用服务器通过RMI/WebService等方式互访， 或者通过plsql接口直接访问数据库；

 

方案D: 数据库分离

1.         基本同方案C, 但数据库完全分离，无法建立同义词。

2.         建议书系统需要访问核心系统的数据如产品信息、代理人信息，在两个系统数据库中都存在。并且需要从核心系统同步到建议书系统。在建议书系统中只读。

3.                       后期保单转建议书或建议书转投保单等功能需要两个AppServer通过RMI/WebService等方式互访，不能直接通过访问plsql 访问数据库；

 

 

 

方案C

方案D

安全性

将供代理人访问的系统从核心系统分隔开，特别是数据分隔开，保障了核心系统和其数据的安全性。

由于数据库彻底分离，核心数据更加安全

性能

核心系统的性能不受代理人系统影响，或者易于排除这种影响。

性能更加互不影响，包括数据库性能

与新契约耦合度

建议书与新契约及投保单完全解耦。

同C

投保单的查询和报表统计的效率

方案A、B中的此效率问题不再存在。

同C

对原投保单功能的影响

方案A、B中的这个问题也不再存在

同C

 

需要多管理一个单独的应用服务。

需要多管理一个单独的应用服务和一个单独的数据库服务。

开发环境

建议书开发前需要准备必要的环境，首先要先从核心系统迁移必要的功能，建立必要数据的同义词。这要花费一些时间。

同C，但不需要同义词

建议书转换

保单转建议书或建议书转投保单等功能需要两个AppServer通过RMI/WebService等方式互访， 或者通过plsql接口直接访问数据库；较方案A、B复杂。

保单转建议书或建议书转投保单等功能需要两个AppServer通过RMI/WebService等方式互访。不能直接通过访问plsql 访问数据库。较方案A、B复杂。

数据同步

无需数据同步

需要保持部分数据的同步

 

综述

方案C、D在数据安全性、以及保障核心系统性能上都明显优于方案A、B，在系统的可维护、可扩展性上明显优于方案A。也避免了方案A、B可能因为建议书数据导致的老程序错误。只是开发前需要一定时间的启动工作（一周左右）。两个系统之间的数据交换较方案A、B 稍微复杂些，但这种建立在低耦合基础上的方式却是系统可扩展性的一个保障。独立的建议书系统也可以作为团险代理人的一个平台，在建议书的基础上扩充其他的代理人需要使用的功能。

方案C较D来说无需额外建立一个数据库，两个系统间数据交换较D更为方便，因为两个系统使用的数据库只是一个数据库中的不同Schema。当一定时候建议书的数据膨胀影响到核心系统数据库的性能、或者建议书系统要开发给更多的外部用户，出于更好的安全性或者性能上的考虑，方案C可以很容易的转换成D。

基于以上各点，我们推荐目前信诚采纳方案C。

 

 

附方案C系统架构图：(这里用Agent Office 表示建议书系统，用Back Office表示核心系统)

 

System Overview