- SAP Managed Tags:
Often we were asked to explain which business scenarios can be covered by the FS.PM Group Insurance Addon GIA. In the following blog I want to give you some insight about 3 different scenarios which ar covered by GIA.
We will start with ta simple representation of a group.
Scenario 1: The Master Agreement Group
Scenraio 1 is often used if individuals belongs to a specific group like a company, a worker group, members of a community etc.
In the master policy level the group owner defines an agreement with the insurance company usig special conditions, discounts but also can limit the maximum sum of coverages. So the master agreement will restrict or enhance a given insurance company sales product.
Common examples can be found in health insurance, P&C with discounts for specific groups.
A collective/group contract has individual participants where the individual participant is the premium payer and policy holder.
The participant is fully responsible to maintain his policy within the rules of the collective agreement. There are no dependencies between different individual policies other than that they make use of the same master agreement. In a quotation process only the premium for the individual participant is relevant.
This indicates a classic group business. As soon as a new business will be created for an individual policy holder, directly in the creation process the link to the existing master policy will be established. All maintained default values from the master policy will be defaulted to the new individual policy.
With the GIA feateares Move-In and Move-Out, at any time slave policies can leave the group and will be continued under the same policy number. Insurance company can decide if master agreement conditions remain untouched or have to be changed. Aso in a move-in business process, the policy can be changed using the new master agreements. GIA offeres a bunch of mass BTX capabilities to support any kind of mass changes.
Scenario 2: Real Group Insurance
Scenario 1 can be seen as a pure bracket of a huge number of individual policies. In scenario 2 the benefits of GIA will be moved into the processing focus.
This type of insurance products is often described as a pension plan for employees or also can be used for car fleets.
This sounds strange from a first view, but GIA a a generic concept to work with a master-slave concept.
Examples of Business Requirements:
- A collective master policy contract with individual participants where the participant has his own policy and can be premium payer (full or partial premium).
- The contractor of the collectivity (e.g. the employer, key account) also has a (collective) policy and can also be premium payer (partial premium) (e.g. a pension agreement, fleet discount).
- The dependency over the policies goes further than in scenario 1.
- The total premium is part of the agreement and is administrated on the collective policy. In the quotation process we can calculate the total premium (this is the sum of the premium of all individual participants) at once.
GIA will implement the above requirements with the following solution approach:
Create a sample application with an explicit name that indicated the master agreement. The sample application will be maintained in full. This includes all discounts, surcharges etc that is needed to be proposed in new business for individual participant policies. In case you want to create a pension group, just create a sample application for your sales product "Pension"
As a next step you create a master policy. Select the a master policy template that will influence the design and features of the master policy level. At the beginning please use the default values GIA offers in setup. Later on you can change the features.
As soon as you are in the master policy, you will be able to define settings that influence the master policy in their behavior.
- Supress Correspondence
- Deactivate risk assessments
- Default policy holder
- etc
Furthermore from the master policy level you can trigger a mass correspondence. But the most important step is assigning a valid policy holder /
policy contractor for the whole group. This will have an impacton collection process.
Up to now we have just some high level configurations made for the master policy. From a logical point of you, you can directly start assigning slave policies to the master policy. But There was a reason to have created the sample application at the beginning.
In the view "Sample application" you will be able to assign as many sample applications as you need.
In our example we have only one sample application for a pension product of the members SAP employees. This sound like a "Plan". Plans ofen used in insurance business and indicates a special agreement for a special insured object attribute.
We recommend here to define as many sample applications as you have logical "plans"
e.g. define different pension plans for
- employees
- managers
- employees with family
- etc
You will have full flexibility and freedom to design your master policy and the correpsonding special policy attributes
The sample applications were designed to save you time in mainteance of policy. It shall not be used to define hierachy grouping aspects. Every sample application must have a difference.
An alternative to this implementation approach is using a complete IFBC sales product. In most cases you wull have only one sales product for pensions. If you want to create a differentiator for a key account, it can be covered with sample applications. In case the difference is so huge, you can copy the sales product in IFBC from "Pension Common" to "Pension for Key Account 1". In the past this was a horrible effort of work.
This problem is solved using the new "Simplified product Deployment" tool (SPD) thats able to copy full sales products in a fancy way.
Premium payer distribution is also a special functionality of GIA. It resues a core functionality of FS-CD to make the collection possible.
For every master policy you define a "Broker" bsuiness partner and a Broker Insurance Object. This might be crazy but behind is a real nice feature to resue the FS-CD broker cpollection feature in a master policy behavior. On master policy level you define also a distribution of premium payer. In the given example the Company/Key account pays 40% of the premium and the individual policy holder the remaining 60%. At the moment we offer a distribution of percentage level to establish the feature. Any other distribution schema might be possible.
Correspondence will be managed centrally on master policy.
All other processes like the creation of new business remains untouched. This is the man key benefit of GIA to avoid any impact on as is user experience and data processing but adding a bunch of convinience feature around.
We know that group business is a mass business and often managed with excle spreadsheets. GIA offers a list of APIs to make processes mass enabled.
There are some sample repoirts with excel file upload capabilities to leverage the as is process flow from excel upload to final slave policies.
Scenario 2: Subcase: Salary Increase and impact on existing pension contracts
Let assume you have a working master policy with hindreds of slave policies already created. You key account repirts you a salary increase of 2% for a subset of employees. How are you able to handle it?
Based on the fact the premium depends on the salary, with the help of a mass selection you will be able to find all premiums with a given old value and you can create a "GIA Result Set" A result set is a subset of policies under a given master policy with free selected attributes.
Execute now a masschange for a master policy and reuse the prevously defined result set. In the next step execute the mass BTX Benefit/Premium offered as a GIA feature.
And add the new premium value with an increase e.g by 2%. Save and execute and all salve policies will be updated in background.
Of course simulation etc as a usual FS-PM feature is possible.
Scenario 3: The company pays my premium
This is a very common insurance scenario ingroup business. Often a company offers for all employees an accidential, medical surgery, travel, baggage or job loss insurance. The best thing here is, the employee is not involved in the whoile process and in most cases the employee has not tp pay any premium. In health business sometime a medical checkup is needed. But let's focus on the common view.
- A collective contract where the individual participants are only insured (premium relevant) objects.
- The participants don’t pay premium and don’t have their own policy (in a functional way, in a technical way the have their on policy, so a claim per participant is possible).
- The insured persons are only informed for being a part of the collective contract as an insured person (e.g. collective disability insurance).
- In the quotation process we can also calculate the premium with all the participants as insured objects, at once!
So the fact is we have named insured objects. GIA is representing this scenario as the common scenario with special setting on the master policy level. In most areas it is the same as the scenario 2.
We will start using a sample application or an own IFBC product for a key account.
In the creation process of the master policy there are some remarkable changes to be made.
- Supress of correspondence is activated. So the individual policies will not receive any documents
- The policy holder of the master poolicy is default as owner of the individual policies
- Broker Collection is active with 100% on policy holder
and finally this will result in the following implementation on the slave policies.
- Policyholder is the employer/key account/company
- Premium payer will be the employer/key account/company
- Insured object/person will be the employee
Conclusion:
Group Insurance Addon 1.0 offers all function features to cover all group related business on a simple and impact free way of integration.
Avoid customer specific enhancements and trim your processes to be flexible in the future.
GIA was designed to make a disruptive change how group products from pension to fleet can be implemented without the need to re-implement any legacy insurance solution.
GIA 1.1 is planned to be released in April 2017 with great new features, new capabilities and lesson learned from ongoing implementations.
Group Insurance Addon is one of the first products of the Next Generation Insurance Platform leveraging the goals simplicity, smart insurance and digitalization.