Siebel Business Rules Administration Guide > About Business Rules >

About Siebel Business Rules Benefits

Changes in your business strategies result from changes in factors such as business conditions, inventory levels, seasons, and changes in personnel. Your CRM applications must adapt quickly to these changes and promptly reflect the changes in business priorities.

You can implement HaleyAuthority natural language business rules to automate decisions declaratively, instead of implementing those decisions programatically. By replacing scripts that can be difficult to develop and maintain with business rules that can be created and modified directly by business managers, the overall cost of maintenance and configuration of Siebel applications is minimized.

Some of the applicability of rules configurations in Siebel applications include:

• Dynamic business processes. Business processes are frequently dynamic; that is, their requirements and parameters can change on a regular basis. For example, insurance application approval, credit card approval, and insurance claim processing prerequisites can change over time. Siebel Business Rules allow such business process changes to be deployed declaratively in a natural language context, without the need for rewriting script logic or reconfiguring Siebel objects, and then recompiling the Siebel Repository.
• Complex business processes. Business processes, such as those you implement with Oracle's Siebel Workflow or Oracle's Siebel Task UI, frequently contain decision branching that depends on results of earlier steps. Rules allow more complex processing of data in order to generate more refined input values for decision-making. Changes to the business logic governing the input is maintained declaratively, instead of relying on entirely scripted solutions.
• Field validations. Besides easier implementation and maintenance during the life of a Siebel release, the basic field validations that are implemented with a rules engine are more easily and directly maintained across a Siebel upgrade than scripts that are used to do validations.
• Auto-populating field values. You can declaratively populate fields that depend on other field values. Rules allow changing the logic without having to recompile the Siebel Repository, and without having to modify script.

Implementing HaleyAuthority rules from a single source that is external to Siebel applications provides the following benefits:

• Groups of rules, or modules, for different purposes and applications can be developed and deployed separately:
  • Versioned objects can easily revert to previous versions.
  • Access levels to modules can be used to define who may modify particular rules and modules.
• Logic is more understandable when it exists as rules in natural language. Thus, participants other than software developers, such as business analysts and business managers, can create and modify the logic. The HaleyAuthority authoring tool provides visual cues to validate rules and parts of rules as they are written.
• A single rules engine allows you to maintain business logic in a single place for use with various Siebel applications and functionalities.
• When Siebel objects are imported to HaleyAuthority, all the necessary HaleyAuthority metadata constructs (concepts, relations, and phrasings) are created automatically. You can immediately begin writing rules to reflect your business logic.
• The HaleyAuthority test harness allows you to simulate rules execution before deployment or for doing regression testing.
• Rules are implemented as a proxy business service, and can be invoked with the following mechanisms:
  • Runtime events
  • Siebel workflows
  • Siebel Task-based UI
  • Business services

    NOTE:  The same business logic (rule module) can be reused in any of these contexts.

• Rules can invoke:
  • Siebel business component methods
  • Application methods
• Siebel object model changes in the Siebel Repository and the imported HaleyAuthority constructs are synchronized on demand.