What is the value of business rule engines as part of a software platform?
Generally one can think of rule engines as a way for business users, not programmers, to save time, resources, and money by implementing business rules that are independent of applications. While business users, business analysts, and managers can maintain rules via rule engine UI’s, IT support is generally still required, especially during the initial implementation, but also for regression testing in some cases. However, the business user has the ability to automate routine business decisions, adjust those decisions that change often, and improve productivity results without requiring a development effort or programming knowledge. For example, if you have business rules set up for field sales folks in your company based on zip codes of their territories, and these territories can change over time based on operational level decisions, there is no need for a programmer to create statements for all possible new values. Rather, in a business rule engine UI, the business user can maintain these types of changes on the fly while still maintaining enterprise-wide application workflow standards, and without IT intervention. If you think of the foundation of control flow statements in programming code as being the ‘If……Then….’ statement, this actually carries through to business rule engines, requiring a condition(s) (IF) and action(s) (THEN), to trigger automated functionality.
Below this paragraph you’ll see two small screen shots showing Condition and Action statements, not with programming code, but with attributes and objects within in the form of an easy-to-use SAP CRM Business Rules UI with drop downs, or search pop-ups, for operators, etc. In this case of the screen shots below, a business user can trigger an alert to an SAP CRM Interaction Center agent only if a condition is met, in this case some type of Event occurs, for example, a specific button click. Therefore, if an Interaction Center agent 80% of the time navigates to a Service Ticket (action) after confirming an account and contact (event), then this can be configured to occur automatically using business rules. In other words, with business rules set up by business analysts, if an agent clicks Confirm, the next screen the agent sees is a Service Ticket view without the agent having to navigate automatically, saving the agent clicks and decision time, which is important in a contact center environment.
What do all rule engine applications generally have in common?
Business Rule Engines’, like SAP CRM’s Rule Modeler, decision logic is usually expressed in the form of decision trees within a UI engineered and designed with desirable usability in mind for a business user, therefore complementing the host application, in this case SAP CRM.
Here is a screen shot of an example SAP CRM’s Rule Processing decision tree structure of a sample rule policy:
In general, rules used together are maintained in folders, since there is a procedural logic to how rules are triggered based on the conditions of each rule in a folder (more on this in PART TWO). Furthermore, organizing rules is not an exact science. In fact there are plenty of books and college courses with theories on best practices for business rule implementation. However, for SAP CRM business users, the tool is easy to use and testing is possible before releasing the rules into production.
Which rule engines are used within SAP CRM and how are they accessed?
The Rule Modeler is the UI component within SAP CRM that is accessible by default as part of the IC Manager Role, and houses the main business rule engine capabilities for maintaining rules. In SAP CRM 7.0, the default Work Center (entry on the UI Navigation bar) is now called ‘Process Modeling’. This UI seamlessly shows the major contexts used by SAP CRM applications with regards to rules management. However, under the hood, there is actually more than one engine at work: the older Email Response Management (ERMS) rule engine, and the newer Intent Driven Interaction (IDI) rule engine. Combined, these two rule engines actually provide business rule processing capabilities for multiple ‘Contexts’ within the Rule Modeler (engine names and context names are not necessarily one-to-one), which complement SAP Customer Relationship Management processing.
What do you mean by Contexts? I’ve not heard this term before with regards to Rule Engines. Context is used by SAP to refer to the different scenarios, or Contexts, that an SAP CRM user may need for business rule maintenance. The following are examples of SAP CRM Rule Modeler contexts available for business users using the Rule Modeler:
- Account and Contact Management
- Approval Management
- Bounce Management
- Email Response Management
- Intent Driven Interaction
- Lead Distribution
- Opportunity Distribution
- Order Routing
- Service Order/Complain Dispatch
- Service Request Management
This list should make the meaning of the term ‘context’ clearer with regards to the SAP CRM Rule Modeler tool. Again, the Rule Modeler, also sometimes referred to as Process Modeling, is a UI tool that allows access to these various contexts in one place, even though, depending on the context, only one out of two different rule engines are actually being engaged. To the business user, the number of rule engines, or which rule engine is engaged in the background, does not matter! Here is a screen shot showing the initial Rule Policy Search view. This is used when searching for business rules within the SAP CRM Rule Modeler. Often a search starts with a Rule Policy Name, or of a Context, or both:
In the Search screen of the screen shot, you can see the Search engaged for Rule Policies and Contexts. If you select the drop down box for Context, you would see the aforementioned contexts listed in a scrolling list box:
I’m an SAP CRM Interaction Center user. Which Rule Processing contexts are valid for me?
Although any CRM user may, in theory, be able to benefit from all SAP CRM Business Rule contexts, and there are more than what is listed here (i.e. Loyalty Management which uses a different but similar UI tool and engine), only Email Response Management System (ERMS) and Intent Driven Interaction (IDI) contexts are under the SAP CRM Interaction Center umbrella in a functional sense. But in a technical sense, all contexts are available to all SAP CRM roles depending on specific requirements and project based role maintenance.