0571-22931819
在这一篇文章中，我们将介绍在多数现代保险系统中可以看到的、依据保险价值链而存在的顶层子系统。保险系统中一个非常重要的产品部件就是所谓的产品服务器。典型情况下，作为一个产品服务器，它存在一个用于处理产品规则的规则系统。
模式1：保险价值链
例子
你被分配去为新的保险办公系统设计结构。在现在的系统中，你找到一个一个根据产品分类的系统分支，如人寿保险，财产保险，汽车保险。你发现，这些现存系统中存在大量交叉重复功能，尤其在申报处理系统和政策处理系统。你也发现要增加一个新的产品需要做的工作十分繁琐冗长，它以每年增加两个新产品的速率进行着。这样低效的原因源自于系统管理政策部分和管理申报处理部分的产品知识混乱，更多其他的产品知识还存在于系统其它部分。
问题
对一个保险办公系统中的大部分商务功能和商务对象来说，什么是一个好的领域构架呢？
约束
系统应该这样来构造，它必须能支持你的竞争战略。我们已经讨论了工作中的市场约束。
方案
根据保险中的价值链构架领域结构。产品－政策－申报处理－销售和市场－客户服务，再加上帮助系统，比如伙伴子系统，保险对象子系统，进出支付系统。
结构
图1 依据保险价值链的保险系统结构图
类似于Porter的价值链模型，这种结构被保险业所采用。
过子系统来进行价值链建模：
· 产品开发和定义子系统：产品为其他子系统所使用前必须给予定义。产品开发和定义子系统负责为其它系统提供产品定义。产品定义由系统其它部分解释。
· 政策参数子系统：负责存储政策参数，支持所有开展商务活动的用例。
· 销售和市场子系统：处理面向客户的产品销售
· 客户服务子系统：有助于向你的客户提供你期望的额外服务，这些服务是在投诉系统所规定的服务之外的。
要建模好所有的商务功能，你需要像下面一样的帮助子系统：
· 伙伴子系统：存储你公司所有合作伙伴的信息。
· 被保对象子系统：存储有关被保和投保对象的信息。
· 支付子系统：处理收入和支出的现金流。
通常你会发现还有好多系统，比如通用名册保持（general bookkeeping），管理信息系统和数据仓库，人力资源系统等等，这些系统不单是针对保险系统，而是普遍存在的，所以我们这里不再进一步讲述。
结论
并非只要采用保险价值链模型就能得到一个灵活柔性的系统和缩短的市场开发时间，你还需要使用更多类似产品服务器、产品实例参数这样的模式来帮助你实现目标。
采用模式你可以建立一个满足所有产品类的系统，但是不能一步到位，多数情况下你需要先从一部分产品类开始，然后逐渐扩充系统以便从遗留系统迁移过来。如果这样，你就避免了重复投资，从而减缩开发费用。
上述结构是为内勤系统设计的。它并不会单独影响你在服务上的态度。
采用上述结构并不意味着能减少通讯的层次，节省开支。要想达到这个目的，你需要启动业务过程重组并采用工作流系统。
实现
保险价值链是一个领域构架模式，要实现一个现实系统你需要一个应用构架。目前，多数领域系统都通过一个树状层次构架来建造。工作流系统也经常用到。通常，你无法在一个地方一下子实现整个系统，或者一下子实现虚拟的单个系统。目前的网络带宽和性能还不如人意，基于这些考虑，你不得不把系统分成内勤和保险销售两个系统。
变种
你常常会发现产品系统和政策参数系统联合工作方式的差异。将要谈到的产品服务器模式与上述两者都不同，而其它像UDP之类的框架，没有提供两子系统之间的子系统边界，但是却把政策参数当着产品实例，并且贴切地耦合了两个系统
相关模式
一般，产品子系统被当作产品服务器来实现。
一个政策参数子系统通常采用用户定义的产品框架来实现，这样可以充分利用组件模式和Type Object模式的优势。通常，你可以把政策参数当成产品实例。
已知应用
上述构架在保险业几个领域构架，比如Phoenix构架，IAA--IBM的保险应用构架或者VAA(VAA95)有更详细的描述。
尽管保险市场巨大，但是有关保险系统的资料还很少，在这一点与其它市场领域相反。有关基于价值链构架的基本概念和原料产品的相关概念可以参阅《Innovative Gestaltung von Versicherungsprodukten》。以上的已知应用有大量的文档，描述了相近的领域构架。来自IBM的IAA也是一个巨大的领域构架，但是它已经注册，不向公众公开。
模式2：产品服务器
假设你想建立一个产品驱动的保险系统，这个系统一般具有一个后勤系统，用以处理提议，管理政策参数，应付投诉。另一方面，你还需要为用于销售的个人电脑，诸如内部供给或者保险经纪人支持等其它系统提供产品定义。
图2 多个系统需要明确的产品定义
问题
何处定义你的产品知识以及怎样发布？
约束
除了上面提到的，还有几个因素也需要考虑：
标签：
保险
