Generated by Jive on 2015-02-25+01:001

How does FS-CM (SAP for claimsmanagement) work: a Consultants note

SAP modules work on the concept of modularization and abstraction, concepts inherited from object oriented

programming. In claims management too these concepts have been exploited to achieve the objectives. FS-

CM has been designed to work in a standalone manner.

From a laymans point of view, the all-important concepts in claims management are: policy,coverage, incident (cause of loss), reserves, loss items/amount, payment, salvage andsubrogation. At the root of FS-CM architecture are these objects. For each of such objects wehave a type defined as part of configuration activity. E.g. if a user wants to replicate a coveragein the claims system, a consultant has to first define such a coverage type as one time exercise,same is the case for any other claim object for that matter.FS-CM object types come together in a certain designed way and with minimal user input achieves the entire

disposal of a real world claim case. The idea revolves around two sets of data: process data (e.g. policy

product, ICT, LoB etc.) and transaction data (these are mainly user input from the front end at the time of claim

processing). First of all we create a policy product, business wise this is a replica of policy defined in the policy

system. In order to define a policy we also need to define coverage types as decided in the business offering.

So the most crucial and basic configuration in CM is: define a line of business (LoB), under this line of business

define a policy product and assign the appropriate coverage to it. Notably, here we assign only those coverage

types which have been also offered in the policy side. This configuration tries to create a parallel policy product

in claims system as there is one in policy system.

Next comes the linking between the process data and the transaction data. The trigger for anyclaim is the incident that led to the covered loss. In CM we mimic this incident again as one ofthe object types (namely incident type) and define in configuration as one time activity. From anend user point of view if one has a policy number and an incident has occurred, he/she should beable to log a claim with the insurer. The same has been achieved in FS-CM in following manner:Input policy number date of loss and select an incident type and press create button, the claimis created. The in between steps (e.g. policy and coverage check, fetching policy details, anddeciding the nature of newly created claim per se) are taken care by the system automatically.Let us decode the in between steps in terms of process data and transaction data. On the basis ofpolicy number, system should be able to fetch the policy detail. In CM this is achieved via policysystem integration. As soon as user enters a valid policy number, CM makes remote/local call andretrieves all the policy detail and stores it in CM as something called Policy Snapshot. As partof policy snapshot system captures following details: policy holder, available coverage and itsvalidity period, limits, deductibles, and other product terms and conditions. Once the user inputsincident type (and policy number) the system is able to create a claim. Here comes the biggestchallenge: how to control the nature of the claim per se? In order to rule the game, FS-CM has anall-important object called internal claim type (ICT). The ICT is the central object to which most ofthe other objects as attached to. ICT controls the entire nature and processing manner of a claim.

How does FS-CM (SAP for claims management) work: a Consultants note

Generated by Jive on 2015-02-25+01:002

Let us understand the ICT and its utility in detail. The nature of the claim can depend only on two things: the

policy itself and the incident type (loss incident). In order to mimic this, the ICT is determined by following

formula: this formula is configured in policy product.

Policy product + Incident Type = Internal Claim Type (ICT)

In order to create an ICT, first we define a type of ICT (as we do for other claims objects). Then we enable the

ICT with features so that it is capable of disposing a claim in a real business scenario. E.g.1. As a framework for a claim, an ICT should be able to decide which incoming/outgoing documents are

required for a claim. Hence we define permitted document types in ICT. 2. If it is a health claim, the system should be able to store a valid diagnostic catalog for such type of claim.

To meet this, we can define permitted diagnostic catalog in an ICT.3. Most insurance companies have rather complex way of allocating reserves. FS-CM can handle them by

different reserve types and different reserving methods: configured in ICT.

So far we have captured coverage details (as part of policy snapshot) but never used it.Essentially FS-CM disposes a claim for each of the coverage separately. This helps achieve to notonly capture greater detail of loss, but also speedy disposal of a claim. In order to dispose a claimfor each of the coverage separately, FS-CM has a concept of Sub-claim. FS-CM defines a sub-claim as a combination of coverage and a claimant. Aptly first we define sub-claim types andthen assign it to an ICT. Thus which types of sub-claim can be created for a particular claim caseis determined by the ICT. If a policy is offering five covers and the insured has bought only 3 ofthem, then the system will allow to create sub-claim only for them and not for the other two.Thus far we created a claim, captured policy details and created sub-claim. Now we need tocapture the loss items (e.g. a damaged amount for fire extinguisher in a fire claim) in as muchdetail as possible. To achieve this FS-CM has a concept of claim items. Claim items can be createdeither at claim level or at sub-claim level. Here again we define something called benefit typeand each claim item is an instance of this benefit type. Business allows only a certain set of lossitems to be created for a particular coverage. E.g. in an auto accident cover, user must not claimfor bodily injury. In order to achieve this FS-CM has a concept called benefit type tree. We definea relevant set of benefit types and assign them to a benefit type tree (BTT). Further we attachthis BTT to the relevant coverage, thus restricting the types of claim items that can be created fora cover. Limits and deductibles can also be modelled as benefit types and attached to the BTT.Once a claim handler (CH) has captured all the loss items, the system should be able to calculatethe final payout (applying all the limits and deductibles, if any) automatically. It should alsoallocate reserve as per business requirement and detect any fraud or lacuna in the processingof the claim. All the above requirements can be handled in FS-CM. Automatic calculation ofpayout happens in the process called Compensation calculation. The system display of payoutcalculation is visual treat. It clearly shows how much have been claimed against which item, whatlimits/deductibles have been applied and what is the final payout, in a hierarchical manner. Herethe hierarchy mimics the hierarchy of benefit types defined in the BTT. Reserve requirementscan also be met. In usual business cases reserve is allocated in proportion of claimed amount. Tomatch this FS-CM has compensation calculation method of reserving. With the help of BRFPLUSFS-CM can also achieve fraud detection. Cases like frequent claims, claim too soon or at the endof the life of the policy etc. can be detected by simple business rules.

How does FS-CM (SAP for claims management) work: a Consultants note

Generated by Jive on 2015-02-25+01:003

Other features like capturing case details via structured facts capture (SFC), automatic assignment of claim

or other tasks to claim department personnel via role based performer (RBP), automatic creation of tasks

via activity management, integration with outside vendor (e.g. appraisal, loss adjuster, supplier) via external

service integration etc. makes FS-CM really powerful module in the SAP for insurance landscape.