What is a Business Rule - Part 2 Three Cases

Following my earlier blog entry regarding what is a business rule. I thought about elaborating this further by describing three cases of rule development.

1. Case 1 : Sure shot rule

Consider the following requirement:

The Work Allocation of the claims file happens based on the following set of rules.

If the type of Policy is a personal auto with no driver on the policy below 25 years of age and the claim amount if less then $1000 the allocate the claim to a claims rep

If the claim amount > $10,000 allocate the claim file to a supervisor

If the insured vehicle was parked in open parking lot allocate the claim to claims rep and notifying the supervisor. The claim has to be approved by the supervisor

………………
………………


The above set of rules describes allocation of a claims file to a role in the claims organization of the insurance carrier. This is a clearly a business rule set that needs to be in the BRMS tool. These are a set of rules that the business is interested in knowing about, viewing and potentially maintaining. This is a classic case of why someone purchases a rule engine.


2. Case 2 : Grey Area

Consider the following two requirements
a) Verify that the claim number or the policy number entered by the user on the screen is a valid number. If the number is valid then create a Claims file in the system with the information provided. If the claim is invalid then notify the customer to re-enter with a valid number

b) If a customer has as an excluded driver on the policy then shown the driver exclusion screen.

Requirement 2a) above is really business process requirement and describes how the system needs to be implemented. This is a scenario where some business users of the carriers organization might be very interested in knowing about it while others might not care about it at all saying that all that they care is that the claims file should be created and going to detail of error conditions in business process is not their problem.

The rule text could potentially be something like the following if we choose to write this as a rule in BRMS tool.

If
The claim number entered is “valid”
Then
Create a new Claims File
Else
Re-Enter the claim



Case 2b) is a screen navigation rule, generally implemented by the technologies used in developing the screens – example Structs web framework OR Flex based UI tool. But I have also seen cases (in large P&C carriers) where the architect has chosen to implement such rules in the BRMS tool.

In my opinion , these decision’s really boil down to the guidelines I had described in my earlier blog. There is frankly no right or wrong answer in this case. It is joint decision of the organization.


3. Case 3: Not really a business rule

Consider the following functional requirements
a) The Date entered by the user should be in the format dd/mm/yyyy
b) If the premium displayed to customer is less then the current premium paid then display the premium in Bold Green with blinking text.

These are clearly not business rules and should not be maintained in BRMS tool.