【保险应用体系架构】IAA实务操作手册IAAOperationGuide

IAA 实务操作手册
IBM中国有限公司
二零零三年二月
目录
1.IAA综述 (4)
1.1 什么是IAA (4)
1.2 如何理解IAA (4)
1.3 如何实施IAA (5)
1.4 IAA的工作范围 (6)
2.业务对象建模BOM (8)
2.1 什么是BOM (8)
2.2 如何理解BOM (8)
2.3 如何使用BOM (8)
2.3.1工作描述 (8)
2.3.2工作流程 (9)
2.3.3成功的关键 (11)
2.3.4经验教训 (12)
2.3.5举例说明 (13)
3.保险产品建模PSD (15)
3.1 什么是PSD (15)
3.2 PSD建模基本方法论 (16)
3.3 建模的六个关键步骤 (17)
3.4 PSD建模各阶段工作指南 (20)
3.4.1产品结构（Product） (20)
3.4.2产品生命周期中的活动（Request） (21)
3.4.3保险角色和对象（Role） (22)
3.4.4业务数据（Property） (23)
3.4.5业务规则（Rule） (23)
3.4.6计算（Calculation） (25)
3.5 PSD建模的心得体会 (26)
3.5.1如何发掘业务规则 (26)
3.5.2如何准确的反映要素间的业务关系 (26)
3.5.3模型的细分与整合 (27)
3.5.4PSD建模与UML的异同 (27)
4.业务流程建模BCB (29)
4.1 什么是BCB (29)
4.2 如何理解BCB (31)
4.3 如何使用BCB (32)
4.3.1工作描述 (32)
4.3.2工作流程 (32)
5.IAA 实施的人员要求 (34)
5.1 IBM专家顾问 (34)
5.2 太保的业务专家和IT人员 (35)
5.3 第三方合作开发商 (35)
5.3.1架构小组： (35)
5.3.2业务小组： (35)
5.3.3数据小组： (36)
6.IAA产品模型和传统设计方法的区别 (37)
1.IAA综述
1.1什么是IAA
当前商业环境的变化日益加速，保险商业环境的变化带来了深刻的变革：从以产品为导向到以顾客为导向，从一个封闭的组织到一个开放的虚拟组织。

在这个虚拟组织中，顾客、中介、服务提供商和再保人都成为保险企业向外延伸的价值链上的一部分。

商业环境变化带来的挑战是需要信息系统发生一个根本性的变化，即从以往的以处理各类业务的事务交易为重点，转向业务集中整合的、企业级的、强调信息作用的系统。

构建灵活的信息系统需要使用企业级的业务需求模型和对象分析模型，以及基于整个企业模型的开发方式，通过这种开发方式，信息系统可以统筹考虑整个业务复杂多变的需求，为每一个构建的应用子系统提供整个企业应用范围内的支持。

IAA是IBM针对保险行业以及相关的金融服务提出的解决方案模型。

它主要包括一系列业务对象模型、数据分析模型以及从需求分析、产品设计到模型管理的一套成熟规范的系统方法。

IAA定义的商业对象模型体系以及相关的设计、开发实现过程是经过多年的行业研究抽象提炼而成，具有指导业务开发和应用框架构建的作用。

但是，IAA并不是一套成型的行业应用软件，不包括任何可直接实现的程序代码，同时，IAA主要以欧洲、北美等地区的金融业务模型为基础，因而在金融、保险领域的模型设计非常全面、系统，同样也是非常复杂和难于理解的，结合到国内保险行业的实际情况，需要进行IAA模型映射定制以及大量的本地化工作。

1.2如何理解IAA
IAA是一个企业级的应用框架，要实现一个保险公司的具体应用，需要有大量的客户化过程，系统最终实现是借鉴IAA模型和它所提供的一系列规范和工具经过代码开发而成。

具体来讲，IAA模型覆盖软件工程中的需求分析、概要设计、详细设计（业务建模、数据建模）几个过程，其技术规范指导着系统开发的每一个过程。

由于IAA定位在高端的保险行业应用解决方案，无论从实施规模、投入、价格等方面都决定了它只适合高端的行业用户，并且是一个以行业顾问＋业务建模＋软件开发的自上而下的系统建设过程。

IAA定位在应用顾问和模型规划方面，项目实施IAA需要由本地的对保险行业和IAA都有深入了解的开发商、IAA顾问以及保险公司自己的业务专家、技术专家一起完成。

业务模型的建立由IAA顾问、客户业务主管、软件公司业务框架设计师共同完成，IBM一般只负责商业对象模型的建立和典型应用案例设计等方面的工作，IBM并不参与太多实际的设计、编
码工作，具体的软件开发需要由软件开发商承担，而最终系统的质量也由开发商保证。

1.3如何实施IAA
在实施IAA的过程中，应用实现主要分为以下几个步骤：
1）业务需求分析
基于IAA的业务模型和应用场景模板，通过保险的业务专家和应用顾问，分析用户的管理思想、业务模式、处理流程等，找到IAA与企业结合的基准点，在适当调整、裁剪的基础上用IAA模型覆盖用户的各类业务需求。

在需求分析阶段，IAA提供许多需求调研模板和场景模板，以期完整、准确地描述用户需求，并在借鉴IAA模型和先进商业规则的基础上提出业务重整和优化建议。

2）对象模型设计
基于IAA提供的对象模型体系，将业务需求以业务对象模型（BOM：Business Object Module）的方式进行描述和定义。

主要实现业务建模和数据建模的过程。

IAA 提供了一整套以UML为载体的对象设计模型，详细定义了各类对象的方法、属性、相互关系等，并有大量案例模板，是整个系统设计的核心。

3）系统开发实现
基于对象模型、数据模型、界面模型采用一定的软件工具进行代码开发。

代码开发需要遵循IAA的框架规范，采用XML、EJB的先进的对象实现方案，具体的开发工具可根据实际案例的情况选择。

实施IAA的过程是一项周期长、投资大、风险高的艰苦工作，其中的重点和难点概括如下：
1）理解IAA的业务模型
IAA的对象模型以国外保险行业的业务管理模型为原型，只有了解了相关的管理思想和设计原则才能理解对象模型的设计。

而国外的业务模型并不是通过文档、课程就能理解的，因此在IAA实施初期需要进行系统的学习和实践。

2）如何将IAA模型与国内保险应用的结合
IAA模型并不能完全不作变更的就搬到国内保险企业应用，在实施过程中IAA顾问需要了解国内情况、国内的业务人员和开发人员需要学习IAA的核心思想，这是一个需要充分互动和长期磨合的过程。

3）使用新工具技术和业务背景
IAA对业务的需求分析、模型定义、代码实现提出了有别于国内常规的做法，实
施IAA需要很好的保险业务理解和抽象能力，才能做到对业务模型、管理模型的精确理解和实现。

因此实施IAA的需要深厚的保险应用经验和技术设计能力。

4）系统建设的艰巨性和长期性
实施一个完整的IAA系统通常需要两年以上的时间，参照国外的实施案例，一般IAA每一对象模块实施的时间在3个月左右，而IAA包括了十多个主要的对象模块，因此在投入的资源和项目时间进度上都不是一般独立工程可以比拟。

实施IAA基本上是一个完全客户化的过程，产品特性不强，期望借助相关系统的开发成果基本不可能，因此开发工作量较大。

5）技术平台的迁移，全新技术、平台的引入
对于国内目前大多数的保险业务系统，采用的平台和工具与IAA框架有较大的差异，实施IAA系统必然存在着应用迁移、系统迁移和数据迁移的过程，其工作量和可能的风险比较大。

全新的技术和平台意味着整个IT框架的更新，在人员技术要求、日常管理维护、设备配置都提出了更高的要求，因此需要更高的投入。

通过上面的分析，实施IAA项目需要由本地的对保险行业和IAA都有深入了解的开发商、IAA顾问以及保险公司自己的业务专家、技术专家一起完成。

作为一家从事保险软件开发多年的供应商，菲奈特公司参与本项目具有两大优势：对太保历史和现状的深刻理解、对IAA研究的重视以及围绕IAA制定产品的研发策略。

1.4IAA的工作范围
IAA项目主要是基于IAA产品模型进行业务的各项建模，如数据建模、流程建模、产品建模，等等。

就财险方面来说，IAA项目的工作范围包括：
1.建立整体的业务对象模型或某一类业务的独立对象模型，支持保险公司的业务运作和
业务管理。

2.对财险IAA模型进行针对国内保险业务的客户化工作，通过IAA的多模型映射器
Multi-Model-Mapper (MMM)完成新IAA模型的定制和储存。

同时包括扩展使用IAA 的对象模型，IBM的IAA专家提供模型扩展的指导和审核。

3.运用IAA特有的方法，支持以保险产品为驱动的需求分析。

开发险种的产品模型，
包括：详细的原始数据模型、映射到IAA的数据模型、险种的组件对象模型，通过分析保险产品的基本规则/信息需求/计算方法/产品构成，用产品规格图PSD的方式记录产品分析的结果，为险种应用系统的设计开发提供基础。

4.将主要的业务流程执行组件建模，基于IBM的业务组件蓝图（BCB），开发组件模型。

5.针对具体的业务和险种，就国内的业务需求与国际最佳范例进行差距分析。

此主要是
利用IAA模型、IBM保险知识产权和IAA专家的保险行业经验，来改进和扩充国内保险的业务需求。

2.业务对象建模BOM
2.1什么是BOM
IAA提供的对象模型体系，将业务需求以业务对象模型（Business Object Module）的方式进行描述和定义，简称BOM。

BOM以Rational ROSE为载体，详细定义了各类对象的方法、属性、相互关系等。

IAA的主要对象模型有：
Party类（对象角色类）：定义了与保险业务相关的客户、机构、代理等，对象具有角色（保险人、被保险人）、上下关系（业务员、部门经理）、联系方式（电话、地址、E-MAIL）等属性，方法包括可以对以上属性的变更，以及因为变更所产生的关联关系的改变；
Product类（产品类）：产品属性包括各类基本信息、组成条款、费率等，方法包括费率计算、组合销售、提升销售等；
Agreement类（合同契约）：Agreement类包括以下几个层次关系：合同/契约、保单、条款、责任。

它可以从产品类继承，并派生出每个合同的特殊属性。

Claim类（赔案）：通过与角色、标的、保险契约、财务类的关联，详细准确地描述和实现了赔案的发生、发展、结束的每一个过程。

Finance类（财务）：各类业务处理过程中的应收、应付和实收实付，以及基于财务及时帐务的各类统计、核算功能。

2.2如何理解BOM
IAA 的保险业务对象模型(BOM) 提供企业级的、通用和灵活的保险业务模型，而且保证业务人员可以方便使用。

它独立于具体的保险业务和保险机构，通过模型的本地化和客户化，来满足某个具体的保险企业的使用。

这些业务对象模型也与技术手段相脱离，专注为业务建模和业务分析提供一个稳定可用的基础平台。

2.3如何使用BOM
2.3.1工作描述
指导方法
基于太保车险系统需求说明书、机动车辆险实务操作手册、投保单等资料挖掘业务数据需求， 给出这些数据需求明确的业务定义， 在需求模型中使用原有数据
元素或定义新的数据元素和主题区域来表现业务需求， 然后在BOM中寻找相关的映
射并定义进MMM，最终交付Spread Sheet以及MMM。

参与人员
¾IAA专家
¾CPIC业务人员
¾CPIC IT人员
¾合作开发商的IT人员
使用文档
¾2002版机动车辆保险实务操作手册
¾太保旧车险系统改造软件需求说明书
¾2002版机动车辆综合险条款
¾费率规章（综合险）/
¾费率表例样(综合险)
使用工具
¾IAA Hyperlink
¾Rational Rose + IAA BOM
¾MMM
2.3.2工作流程
1）先在原有的需求模型（Requirement Model）中查找可能与数据需求相对应的项目，可以使用现成的工具如hyperlinks navigator， MMM， ROSE中BOM模型。

根据数据
需求的定义，找出其中的关键字，然后可以使用hyperlinks navigator中的索引找到
这些关键字。

2）在需求模型中找到候选数据元素(data element)以后，需要仔细查看这些数据元素的定义，哪一个和我们的数据要素定义一样。

3）如果在原有的需求模型中没有包括我们的数据需求，则我们可以在MMM需求模型中新增一个数据元素(data element)。

如果需要的话，我们将会在MMM中新增一
个subject area。

把该数据元素(data element)filter字段置上模型客户化标记，表示
把该data element纳入我们项目范围中去。

新增的数据元素名字前应该标上* ，表
示它是新定义的。

原则上数据元素名字第一位应该是大写字母，以后的字母都为
小写字母，但是对于新增项目来说，因为第一位是*号，故随后的字母都为小写。

如某个subject area中已有新增的数据元素，则该subject area名字前应加上&(修改标
志)，同样第一位字母改成小写。

4）如果在需求模型中找到完全符合我们定义的数据元素，如果我们尚未把它包括进我们项目范围中即filter字段没有被置上模型客户化标记。

则我们只要在MMM需求
模型中把那个元素的filter字段置为模型客户化标记。

同时必须注意的是不仅要把
该数据元素的filter字段置上，还要保证其所在的subject area的filter字段被置上模
型客户化标记即包括进项目的范围中来。

5）如果在需求模型中找到与我们定义的数据要素相类似的data element，并且我们决定使用该data element ，但我们会对其定义进行相应的修改使它更符合我们的业务
需求，并在其名字前加上&标志，以示修改。

当然其filter字段置为模型客户化标
记，并且还要保证其所在的subject area的filter字段被置上模型客户化标记，且该subject area名字前也应加&，以示修改。

6）我们除了对业务需求给出明确的定义，同时还需给出一些有意义的例子，以便更好的理解该业务需求。

需要注意的是对MMM中原有数据元素增添一些例子，并不用把在数据元素名字之前加&标志，因为这并不是修改。

7）如果在MMM需求模型中描述数据元素时，要使用需求模型中其他已经存在的数据元素时，请用< >把这些数据元素的名字包括起来，这样可以避免重复定义，而且也可以使MMM在生成hyperlink navigator时把这些用<>包括起来的数据元素作为一个链接，双击它即可轻松地联到那些数据元素，查看他们的定义。

请记住<>的使用，它的使用可以依此类推。

8）在需求模型中定义完相关数据元素以后，我们开始进入映射到BOM的工作。

同样可以使用现成的工具如hyperlinks navigator，MMM，ROSE中BOM模型。

根据数据需求的定义，找出其中的关键字，然后可以使用hyperlinks navigator中的索引找到这些关键字。

9）查看这些关键字所对应的类或类中的属性，如果对某一业务需求，刚才你在需求模型中定义部分使用的是原有的data element 的话，那么完全可以利用hyperlink navigator的可追溯性找到BOM中原来IAA就已经对应起来的类或类中属性。

10）对于那些新增项目，要找到BOM中的映射，最好还是使用hyperlinks navigator 中的索引找到这些关键字。

然后逐一筛选，最终找到最适合的类或类中属性。

11）当然对有些数据需求，的确找不到相应的数据需求，可能是一些我们公司独有的业务需求。

你当然也可在BOM中增加相应的类或属性。

注意同样的需要在MMM 输入时在这些类或属性前加上*标志，以示区分。

12）对有些数据需求，只能在BOM中找到相类似的映射，其定义并不完全符合我们的需求，则我们也可以对原来BOM中的类或属性作相应的修改。

注意同样的需要在MMM输入时在这些类或属性前加上&标志，以示修改。

13）找到相映射的对象后，往往需要体现如何到达该对象的路径。

这就需要定义navigation path。

举个例子，对“事故发生地”这个数据需求，我们最终映射到place 类，但它不是泛指的地点，而是特指事故发生地，因此当然要体现place类和accident 类的关联关系，这就靠navigation path来体现。

需要注意的是，如果该业务需求有相应的navigation path，则在MMM的BOM中需把navigation path中所涉及的一切类和关联关系(association )的filter字段置成模型客户化标记，以便最终生成专属于自己的模型。

Navigation path 的标准格式如下: Starting Object name/Association name ( / Intermediate object name / Association name /…) Ending object name。

14）如果该数据元素的navigation path较为复杂，你也可以画出相应的collaboration
diagram 来体现复杂的关联关系，帮助业务人员理解。

15）在MMM的Business Model中，找到该映射对象或属性，在MAPPING菜单中把它与requirement model中的相关需求进行映射，同时把navigation path添加到相
应的字段中去。

可能在BOM中的某个属性可与数个需求项建立映射。

应把所有数据
需求相映射的类或类中属性的filter字段置成模型客户化标记。

2.3.3成功的关键
1）定义业务需求是非常重要的，我们往往混淆定义和描述之间的区别。

我们在定义一个业务需求的时候，要了解该数据元素什么时候使用，和谁有关，其存在的意义和
作用是什么。

我们应该和业务人员进行充分的沟通，真正搞清楚业务定义。

这一步
是后续工作的基础，实际的经验教训告诉我们只有做好这一步，才能迅速准确的找
到映射对象，避免走弯路。

2）熟悉BOM，这不是一句空话。

虽然我们可以利用定义中的关键字搜索hyperlink navigator的方法，但很多情况都还是凭个人的灵感，而灵感来自于经验和对模型的
熟悉。

因此全面的理解BOM中各个包、包中的各个类，以及相互的关联关系非常重
要。

只有熟悉模型，才有可能在看到业务需求时，知道大约该到哪里去查找，把握
大方向。

3）熟练应用工具，hyperlink是一个很好的工具，具有强大的搜索机制，具有各模型之间可相互追溯的优点，通过搜索和比较能够帮助你进一步搞清楚需求，也能启发你
的思维，帮助你最终找到映射对象。

ROSE包括了反映各种类之间相互关系的图，
这些较为直观的视图帮助你更好的理解，尤其在查找navigation path过程中，使用
ROSE的这些图是非常有效的方法。

4）业务部门提供的需求报告是整个项目的基础，需求报告中所涵盖的需求范围和需求描述详细与否，直接影响了项目的进程和效果。

IAA实施的第一步Business Model 和
Requirement Model 的映射实施的基础就是由CPIC所提供的需求报告为蓝本，所有
的IAA中的基础数据由此而挖掘出来的，详细的需求描述为后续项目的开展铺垫了
道路。

5）每一阶段的工作实施之初，需预先制定相应的规则，规则包括此阶段实施的流程、注意事项、术语规范、统一执行准则以及各小组领导、小组成员之间的衔接和沟通
方法，规则的明确制定能最大限度地避免项目可能发生的差错，以保证项目每一阶
段的顺利完成。

6）在BOM与需求模型映射的过程中，Spreadsheet（Excel）整理表格和根据Spreadsheet 对MMM的输入操作是必不可少的两个步骤，但它们并不是并行操作的，MMM的
输入工作是基于Spreadsheet的无误完成，Spreadsheet中包含的要素及这些要素的准
确映射将被对应地输入MMM，所有在MMM中发现的问题最终将返回到Spreadsheet
核查。

所以，在Spreadsheet未最终确定之前，最好不要进行MMM的输入工作。

2.3.4经验教训
1）对于某一数据需求，在BOM中找到对应的class，但需与该class从父类继承过来的属性相映射，则在Spreadsheet中可以将需求映射到父类的对应属性上，但需在
navigation path中包含到子类。

在MMM定义的时候，根据spreadsheet所写映射
到其父类的那个属性上去，但是要把子类包含在CPIC模型的范围中来，决不可以
在MMM中，往该子类添加本可以继承过来的属性，并与其相映射。

比如对驾驶证
号这个数据需求，我们在BOM找到Driving license与之相对应，并与其External
reference属性进行映射，该属性是从父类Registration 那里继承过来。

故我们在
spreadsheet 中可以写将该需求映射到<Registration>:external reference并注明其子类。

在MMM中输入时，需到registration 的external reference属性的mapping菜单中，
与驾驶证号这个数据元素进行映射，但同时应把Driving license包含在模型范围中。

决不可以在Driving license中新增一个名为external reference 的属性，并与该数据元
素相映射。

2）我们做数据元素定义和映射工作往往分成几个小组完成，这就存在一致性校验的问题。

需要校验各组有无相同定义的数据元素，如有的话需合并为同一个数据元素，
同时需校验各数据元素之间有无定义重复或冲突的地方。

我们建议小组领导在确定
Spreadsheet 数据元素时能共同商讨，在业务人员配合的基础上完成，这样能最大
限度避免要素的重复性，同时每天对当天完成的需求模型定义进行校验，及时发现
问题。

3）记录spread sheet的规则:
所有的item必须和MMM中相同，单词必须分开写。

<Claimview>:PerspectiveOnClaimDescription ---错
<Claimview>:Perspective On Claim Description ---对
<Claim>/<physicalobjectinvolvedinclaim>/<PhysicalObject> ---错
<Claim>/<physical object involved in claim>/<Physical Object> ---对 "*"和"&"符号必须按规定写，如果是requirement model中新增的<subject area>，其下属的<atomic data element>也应该加上"*"。

<*special case investigation >:Interviewer ---错
<*special case investigation >:*Interviewer ---对
4）MMM中Obect Type使用规则:
Requirement Model中，<subject area> 是 <Atomic Subject Area>，Property 是 <Atomic Data Element>
Business Model 中，<type> 是<Type>，Property 是<Attribute>， <association>是<Association>
5）MMM中Filter使用规则:
如果property的filter被置成模型客户化标记，那么它所属的<atomic subject area>或<type>也应该置成模型客户化标记。

如果是association的filter被置成模型客户化标记，那么它连接的两个<type>也应该置成模型客户化标记。

如果子类的filter被置成模型客户化标记，那么它的所有父类(直到最上层的BMO类)也置成模型客户化标记。

特别是子类用了从父类继承的association，
它的父类一定要置成模型客户化标记。

<navigation path>中所有用到的<type>和<association>必须把filter置成模型客户化标记。

<business model object> ，<category>，<type>和所有下属的<attribute>的filter必须把filter置成all，使得从MMM导出时可以把这些类包及其类
输出到客户化的CPIC模型中去。

2.3.5举例说明
1）浮动前保费，我们首先向业务人员了解详细定义，搞清楚在这里浮动前保费是由哪几项元素组成，最后了解每个险别（coverage）的浮动前保费的计算方法不一样，举
例来说车损险的浮动前保费是：基本保费＋保额×费率（基本保费从费率表中直接
取得），而三责险的年保费直接从费率表中取得固定保费，了解了业务定义以后，我
们开始进行分析，因为浮动前保费虽然根据不同的coverage有着不同的算法，但是
其definition是完全一致的，当然你可以在描述中写上这几种不同的保费算法，因此
我们在requirement model 的premium 这个subject area中只定义了一个atomic data
element名为premium before floating ，而没有在premium 这个subject area中为每个
coverage定义一个premium before floating 的data element。

结束了需求模型的定义，
我们就接着思考在BOM中的映射，我们认为不管是base premium 还是premium
before floating都是和money有关，而且都有确定的金额，故我们认为particluar money
provision 所包含的money provision element 的base amount 属性较为符合，可以这
样理解base premium 是一个particluar money provision，preimum before floating 也
是一个particluar money provision，两者之间有的based on关联关系，而且 premium before floating这个particluar money provision是由generic money provision 来定义的，应用了rate 类，费率即为rate类中的base rate属性。

分析完以后，我们即在MMM
中选择business model 的money provision element 中的base amount 字段，并把它与
requirement model中premium subject area 的 base premium 和premium before floating 两个data element 进行映射。

同时在做映射之前我们找了其到coverage之间
的映射，<CoverageCmponent>/<Coveragepremium>/<ParticualMoneyProvision>/
<Moneyprovisioncomposition>/<MoneyProvisionElement>，并在做映射时把它写入
MMM中，以便以后生成hyperlink时能够显示出来。

2）浮动率，我们从业务人员那里了解到浮动率是应用在浮动前保费上计算实际应收保费的，故根据这层定义，我们迅速找到了adjustment 类的factor属性，它对 money provision element 有adjustment 的关联关系，非常符合业务定义，因此我们就做了相应的映射。

3）医院名称，我们进行分析医院是一个机构，它的名称肯定是party name，然后我们试图找寻其相应的关联关系，我们从定义中了解到此元素主要是指在事故中受伤的人员所治疗的医院名称，找出关键字：事故，治疗，据此我们缩小查找的范围，集中查看 activity 包（因为治疗是一种行为）、party包（涉及人的包）以及event 包（事故属于该包的范畴），通过Rose中的类关联关系图，我们挖掘出定义中隐含的关系类medical condition。

至此我们就可以画出相对应的collaboration diagram（如下图）体现该数据元素所反映的关系图。