Defining product structure

When you start modelling an insurance product, use products in the PSD to decompose the insurance product into component parts and build a product structure. Identify all the coverages that are included in a product, then analyze the way these coverages are organized into a sellable structure as a marketable product. The goal of this exercise is to focus on the structure, not on the detailed content. Once this step is completed, you have captured the general structure of the product and the different risks it covers.

Identifying product components

Identify two types of products as they form a natural breakdown of an insurance product:

Marketable product: Top level of the product structure; it is what the insurance company sells on the market. This is composed of many coverages that can be grouped according to structure and rules. This also corresponds to the notion of package

Product component: A part of a marketable product and represents a specific characteristic, like a coverage, an obligation, an applicability of insurance. It can also be created as an intermediate component to allow for a better structuring of the product to allow for easier reuse.

A product components may:

Be selectable
The product component can be selected at the agreement level. For example, a physical damage coverage can be an optional component that can be selected by the customer when requesting a new car-insurance policy or a set of coverages can be grouped together as a package and be selected as a separate product option.

Be re-usable
The same product component can be used several times in different products. For example, a Term Life product component can be used in many different complex products.

Have a specific life-cycle
The state of the component can be independent from the rest of the agreement. For example, indexation of a policy can be frozen, active, or terminated depending on life-cycle events.

Have specific eligibility rules
There are specific eligibility rules that have to be applied to a specific part of the product. For example, a Waiver of Premium might have special eligibility conditions, such as the insured does not have any health problems.

Have a separate benefit, premium and risk
However, it is possible that several different sorts of benefit or charge can be related to a single premium, each of these being different at the detailed level. For example, a single premium may be payable for a home insurance package of coverages. In that case, analysis may prove that it is more effective to group these individual coverages under a single product component.

If a coverage is very specific (only very few people are exposed to the risk it covers), it is usually packaged with other coverages. Doing so reduces the risk of adverse selection and increase the potential reuse.

Defining product components tree

Build up a complete insurance product as a tree of product components.

Subsequently, every agreement created for a given product duplicates the structure of the product based on the customer's choice.

Figure 1: Product Specification Diagram: product decomposition — Figure 1. Product Specification Diagram: product decomposition

Use the associations between products to show the composition relationship. The product at the lower of the components tree is a component of the higher level in the same tree.

Do not the inheritance (UML generalization) in the composition tree. The product construct of the PSD can be used to represent at any level in the composition tree of an insurance product.

Defining minimum and maximum cardinalities

Have the appropriate cardinalities in all relationship between products. By default, the minimum cardinality is zero and the maximum cardinality is one. This is the case for an optional component, a component that the customer can select or not.

Composition cardinality constraints indicate the minimum (minimum cardinality) and maximum (maximum cardinality) number of agreement parts (coverages) that must be or can be created every time the product is sold. In the example below, you would be possible to create agreements with between one and eight insured, which can have different coverage dates and different deductibles in one automobile insurance policy.

Figure 2: Product Specification Diagram: example of cardinalities higher than one — Figure 2. Product Specification Diagram: example of cardinalities higher than one

Adding product composition rules

Add product composition rules for some conditions on the agreement structures which cannot be expressed with only cardinality constraints. See more details of product composition rules in the section of rule specification.

Exclusive choice between two (or more) components
Only one component must be selected out of a list of components.

Implicit choice
When one component is selected, another component must also be selected. This kind of relationship is often used for small coverages to avoid adverse selection by the customer.

Introducing intermediate levels in product structure

Introduce intermediate product components if needed: for example, when a set of product components logically belongs together and can be selected by the customer only as a whole.

Creating a reusable combination of product components: For example, if two product components, Automobile nature caused damage coverage and Automobile traffic accident coverage, are often used together, it makes sense to create one more level in the product tree to group them. This additional level makes it possible to re-use the Automobile own damage full package many times in different structures. It will always be composed of Automobile nature caused damage coverage and Automobile traffic accident coverage.

Figure 3. Product Specification Diagram: creating a reusable combination of parts

Making it easier for business users to understand the product structure: If business people recognize a grouping of product components by one name, it is often advisable to introduce a product component to account for that business concept. This makes the communication between system and business people easier.

Creating common features with combination of other PSD constructs: When several PSD constructs have something in common, such as a role or a property, an additional product component can be introduced to support the common features. For example, if a global limit applies to the claims that can be made against a series of coverages, a product component can be created, including all the coverages and holding the limit.

Reusing product components

You may identify the product components that can be reused from previously modelled products.

Do not use the inheritance (UML generalization) because each product component must be able to represent at any level in the composition tree.

A product components can only be shared by different structures if they are identical in both structures. The figure below shows the graphical representation for the reuse of a product component.

Figure 4: Product Specification Diagram: re-use of a product component — Figure 4. Product Specification Diagram: re-use of a product component