保险系统的部分模式03

约束

系统应该这样来构造，它必须能支持你的竞争战略。我们已经讨论了工作中的市场约束。

方案

根据保险中的价值链构架领域结构。产品－政策－申报处理－销售和市场－客户服务，再加上帮助系统，比如伙伴子系统，保险对象子系统，进出支付系统。

结构

图 2 依据保险价值链的保险系统结构图。

类似于Porter 的价值链模型，这种结构被保险业所采用。

通过子系统来进行价值链建模：

产品开发和定义子系统：产品为其他子系统所使用前必须给予定义。产品开发和定义子系统负责为其它系统提供产品定义。产品定义由系统其它部分解释。

政策参数子系统：负责存储政策参数，支持所有开展商务活动的用例。

销售和市场子系统：处理面向客户的产品销售

客户服务子系统：有助于向你的客户提供你期望的额外服务，这些服务是在投诉系统所规定的服务之外的。

要建模好所有的商务功能，你需要像下面一样的帮助子系统：

伙伴子系统：存储你公司所有合作伙伴的信息。

被保对象子系统：存储有关被保和投保对象的信息。

支付子系统：处理收入和支出的现金流。

通常你会发现还有好多系统，比如通用名册保持（general bookkeeping），管理信息系统和数据仓库，人力资源系统等等，这些系统不单是针对保险系统，而是普遍存在的，所以我们这里不再进一步讲述。

结论

并非只要采用保险价值链模型就能得到一个灵活柔性的系统和缩短的市场开发时间，你还需要使用更多类似产品服务器、产品实例参数这样的模式来帮助你实现目标。

采用模式你可以建立一个满足所有产品类的系统，但是不能一步到位，多数情况下你需要先从一部分产品类开始，然后逐渐扩充系统以便从遗留系统迁移过来。如果这样，你就避免了重复投资，从而减缩开发费用。

上述结构是为内勤系统设计的。它并不会单独影响你在服务上的态度。

采用上述结构并不意味着能减少通讯的层次，节省开支。要想达到这个目的，你需要启动业务过程重组并采用工作流系统。

实现

保险价值链是一个领域构架模式，要实现一个现实系统你需要一个应用构架。目前，多数领域系统都通过一个树状层次构架来建造。工作流系统也经常用到。通常，你无法在一个地方一下子实现整个系统，或者一下子实现虚拟的单个系统。目前的网络带宽和性能还不如人意，基于这些考虑，你不得不把系统分成内勤和保险销售两个系统。

变种

你常常会发现产品系统和政策参数系统联合工作方式的差异。将要谈到的产品服务器模式与上述两者都不同，而其它像UDP 之类的框架，没有提供两子系统之间的子系统边界，但是却把政策参数当着产品实例，并且贴切地耦合了两个系统

相关模式

一般，产品子系统被当作产品服务器来实现。

一个政策参数子系统通常采用用户定义的产品框架来实现，这样可以充分利用组件模式和Type Object 模式的优势。通常，你可以把政策参数当成产品实例。

已知应用

上述构架在保险业几个领域构架，比如Phoenix 构架，IAA--IBM 的保险应用构架或者VAA(VAA95)有更详细的描述。

进一步阅读

尽管保险市场巨大，但是有关保险系统的资料还很少，在这一点与其它市场领域相反。有关基于价值链构架的基本概念和原料产品的相关概念可以参阅《Innovative Gestaltung von Versicherungsprodukten》。以上的已知应用有大量的文档，描述了相近的领域构架。来自IBM 的IAA 也是一个巨大的领域构架，但是它已经注册，不向公众公开。