IBSEN

The IBSEN products have been developed based on the IBSEN (Insurance Business Engines) concept and architecture of components. Each component supports a certain task of the insurer, from product design to policy management. The various IBSEN components are to a great extend independent of each other. Consequently they can easily be implemented separately and also integration of external components is possible.

IBSEN Concept

The objective of the IBSEN concept is to allow business experts to enter their knowledge into the system in an easy and effective way. This has been realised using the following basic concepts.

Single Point of Definition (SPoD)

The SPOD concept aims at a single and central definition of rules and data, which can be approached and executed by different components.

The following details and rules are centralised:

• environment specifications (e.g. fiscal rules);
• company specifications (e.g. commission systems and profit sharing);
• business rules (e.g. actuarial formulas and calculation rules).

Application of this concept improves the univocality and maintainability of the system.

Power to the Expert

The 'Power to the expert' concept gives business experts the possibility to influence operational information systems directly.

This can be realised by offering the business experts tools by which they can define data and rules in the system fast and efficiently and in a way appropriate for the domain of expertise (e.g. actuarial, insurance technical, marketing, insurance administration). This simplifies the communication between business experts and IT experts and allows the communication to take place in everyone's area of expertise. In this way unnecessary communication problems can be prevented.

IBSEN Architecture of Components

The daily activities of insurers consist to a large extend of information processes. One can distinguish five stages: definition of the work field (define), design of products and processes (design), offering products and services on the various markets (sales), execution of the administration (administration) and the services (services). The following architecture of applications and components is defined in order to support this process chain.

Below you can find a brief description of the various components per 'Office'.

Central Business Office

• BDC (Business Define Component)
  Supports the definition of relevant business rules and business data for the environment in which the company is active.
  
  
• FRC (Fiscal Rules Component)
  Supports the fiscal consequences of the determination of premium or obligation.
  
  
• PDC (Product Design Component)
  Supports - combined with AKS and RDC - the creation, parameterizing and management of specifications, which describe an insurance product.
  
  
• PHC (Policy Handling Component)
  Contains the knowledge and logic for the treatment of policy transactions and pro forma and quotation calculations.
  
  
• AKS (Actuarial Knowledge System)
  Supports the definition and calculation of all actuarial formulas.
  
  
• RDC (Rules Design Component)
  Supports the definition and calculation of all other, not basic actuarial, formulas.
  
  
• BPC (Benefit Projection Component)
  Calculates the benefits given the premium or the premium given the benefits.

Sales Office

• NAA (Need Analysis Application)
  Supports the need determination of a client.
  
  
• QDA (Quotation Delivery Application)
  Supports the drafting, issuing and follow up of quotations for both new and existing contracts.
  
  
• QCA (Quotation Calculation Application)
  Supports the calculation and management of quotations. NAA (Need Analysis Application)

Administration Office

• CPA (Contract Policy Application)
  Supports the drafting and management of insurance contracts, plans and policies.
  
  
• BIA (Billing Application)
  Supports - within the billing procedure - the creation of insurance technical receivables (due date notices and requests for payment) and bookings.
  
  
• CHA (Claims Handling Application)
  Supports - within the claims administration - the determination and registration of insurance technical payables, which have to be paid per beneficiary, as well as the renewal of allowances, domiciling and bookings resulting from this action.
  
  
• DCA (Distribution Channel Application)
  Supports the definition and management of the distribution organisation (distribution channels, commission systems), the management of the distribution agreements and the administration of commissions.

Information & Communication Office

• CRA (Central Relation Application)
  Supports the management of data concerning all relations of the organisation.
  
  
• AAA (Actuarial Analysis Application)
  Supports actuarial reporting, analysis and justification, as well as the settlement for the benefit of the co- and reinsurance.
  
  
• MIA (Management Information Application)
  Supports the delivery of the necessary information needed by the management team to base decisions upon. It concerns both information regarding content (e.g. production figures) and information regarding the process (qualifying period, pressure points).

Software and set up both determine the functioning of the IBSEN components. The set up consists of knowledge tables and business rules, which can be defined or composed by using components in the Central Business Office (e.g. AKS and RDC). Combined, programs and set up basically create an infinite functionality.

The character of the components differs. Differences are situated in:

• Scope: to what extent is a component generic for the whole business, or specific for a country, company, etc.;
  
  Example:

  AKS (Actuarial Knowledge System) is considered generic for the insurance business. In the IBSEN architecture AKS is a standard component. CPA (Contract & Policy Application) on the other hand is a non standard component. Due to the requirements related to the different insurance products and processes, the components in the 'Administration Office' require a framework approach. Practis designs and develops the basic (universal) software. A tailor made solution can be created efficiently by setting up the client specific products and processes.

• User aspects: user aspects: who are the users of the component (e.g. business expert, contract manager, commercial manager, intermediary, client);
  
  
• Functional aspects: which business process the component gives support to;
  
  
• Technical aspects: degree of necessary transferability and (partial) reuse.

In coherence, a complete solution is created for a person insurer, in which the whole variety of insurance products (regarding 'persons') for Front and Back Office processes will be supported. Each insurance company has the possibility to make an optimal choice concerning the width and depth of the IBSEN solution: the situation at the start is different for each insurance company. The IBSEN architecture of components makes it also possible to replace IBSEN components by 'foreign' components with the same functionality.