Excerpted with permission from Building Business Solutions:  Business Analysis with Business Rules, by Ronald G. Ross with Gladys S.W. Lam, An IIBA® Sponsored Handbook, Business Rule Solutions, LLC, October 2011, 304 pp.  URL:.  http://www.brsolutions.com/bbs

Business analysis with business rules focuses on capturing, encoding, and managing a specific kind of knowledge — operational business know-how.  (We call it know-how for short.)  Know-how is represented in the form of business rules based on a structured business vocabulary (fact model).  In many respects the fact model, with its business terms and definitions, is the most fundamental know-how of all.

Decision analysis, a special area of business analysis with business rules, focuses on developing decision rules.^[1]  Your organization undoubtedly has a great many decision rules, but it also has a great many behavioral rules.

Behavioral rules govern the conduct of on-going business activity by 'watching' for violations.  Example of a behavioral rule:  A student with a failing grade must not be an active member of a sports team.

This business rule is not about selecting the most appropriate sports team for a student, nor does it apply only at a single point of determination (e.g., when a case of a student wanting to join a team comes up).  Instead, the business rule is meant to be enforced continuously — for example, if a student who is already active on some sports team should let his or her grades fall.  In other words, the business rule is about shaping (governing) the conduct of on-going business activity.

Understanding how behavioral rules work is essential in creating true-to-life business models, which we call know-how models.  Table 1 identifies fundamental differences between behavioral rules and decision rules.

Flash Points

As mentioned above, behavioral rules generally need to be applied at various points in time.  What are these points in time?  How can you find them?  Why are they important for Business Analysts?

Each of the various points in time when a behavioral rule needs to be evaluated represents an operational business event.  Such events can arise in either business processes or ad hoc business activity.

How do you find these operational business events?  Consider the behavioral rule:  A customer must be assigned to an agent if the customer has placed an order.   Figure 1 shows the relevant terms and wordings for this business rule.

Figure 1.  Terms and Wordings for the Agent-Assignment Business Rule

The business rule has been expressed in declarative manner.  This means, in part, that it does not indicate any particular process, procedure, or other means to enforce or apply it.  It is simply a business rule — nothing more, nothing less.

The business rule makes no reference to any event where it potentially could be violated or needs to be evaluated.  The business rule does not say, for example, "When a customer places an order, then …."

This observation is extremely important for the following reason.  "When a customer places an order" is not the only event when the business rule could potentially be violated and therefore needs to be evaluated.

Actually, there is another event when this business rule could be violated:  "When an agent leaves our company…."  The business rule needs to be evaluated when this event occurs too since the event could pose a violation under the following circumstances:  (a) The agent is assigned to a customer, and (b) that customer has placed at least one order.

In other words, the business rule could potentially be violated during two quite distinct kinds of operational business event.  The first — "When a customer places an order ..." — is rather obvious.  The second — "When an agent leaves our company ..." — might be much less so.  Both events are nonetheless important because either could produce a violation of the business rule.

This example is not atypical or unusual in any way.  In general, every business rule produces two or more kinds of operational business events where it could potentially be violated or needs to be evaluated.  (We mean produces here in the sense of can be analyzed to discover.)

These operational business events are called the business rule's flash points.  Business rules do exist that are specific to an individual event, but they represent a small minority.  Two quick notes in passing:

• Expressing each business rule in declarative form helps ensure none of its flash points is exempted inadvertently.
  
  
• Discovering and analyzing flash points for business rules can also prove useful in validating business rules with business people.  Important (and sometimes surprising) business policy questions often crop up.

How to Assemble a Know-How Model:  Case Study

Let's walk through a case study to understand how behavioral rules, flash points, and operational business decisions should relate in a business model.

Scenario:  A customer places an order.

Flash point:  The operational business event "when a customer places an order" is a flash point for some behavioral rule(s).

Behavioral rule:  A customer must be assigned to an agent if the customer has placed an order.

Motivation:  The business thinking behind the business rule is briefly:

The company's products are complex, expensive, and available in a large variety of configurations.  Customization is often warranted.  Assigning an agent helps customers identify the best solution for their particular circumstances.  Assisted acquisition also ensures the highest chance of customer success and reduces returns and replacements.

This business thinking is the motivation for the business rule — its pedigree.  The motivation should be recorded (as part of rulebook management) and accessible to everyone properly authorized.  Never assume the original motivation for a business rule will be remembered and properly understood by all.  Document it!

Violation event:  The particular customer placing the order does not have an assigned agent.

Detection of the violation:  Some staff person, business rules engine (BRE), or other platform recognizes that an agent needs to be assigned.  That staff person, BRE, or other platform did not 'decide' the customer needed an agent.  No operational business decision or choice among alternatives is needed to recognize the violation.  An order being placed by a customer without an agent simply results in a violation of the business rule.

Response to the violation:  Something must be done to assign an agent to the customer.  When the business rule was created, the company decided the best violation response would be to hand the case over to a line manager and let her handle the situation.  Presumably, she's in the best position to know which agent is optimal to assign to any given customer.

Operational business decision:  The need to pick and assign a particular agent from among alternatives for the given customer at the given point in time does represent an operational business decision.  The business is trying to answer the question Which is the best agent to assign to a customer?  The manager decides and assigns an agent for the given case.  Business activity moves on from there.

Potential decision analysis:  The operational business decision has been identified and included in a list of possible targets for future decision analysis.

As illustrated by this case study, the dynamics of behavioral rules are fundamentally different from those of decision rules.  The differences are summarized in Table 2.

Enforcement of behavioral rules involves three things:  enforcement level, guidance message, and violation response.^[5]  Each behavioral rule should be examined along those three lines in creating true-to-life business models.

Decision Analysis and Know-How Models

Returning to the agent-assignment rule, let's say the company recently decided to automate the operational business decision:  Which is the best agent to assign to a customer?  The Business Analysts will have:

• Undertaken decision analysis and created a Q-Chart.
  
  
• Developed decision tables, spending time with business leads to get the decision logic right.

Then the decision logic is deployed under a business rule engine (BRE).  Now, instead of the line manager performing the decision task 'manually' as each case arises, the BRE does it automatically by evaluating the decision tables.  No matter, it's still an operational business decision — a selection or choice among alternatives to be made in real time.  Note that the decision logic can be evaluated as a violation response for the original behavioral rule:  A customer must be assigned to an agent if the customer has placed an order.

From a business perspective, automation of the operational business decision changed only two things, both for the better:

1. The line manager has been freed up to do other (perhaps more challenging) work.
   
   
2. Her know-how has been encoded so the company won't lose it should she leave.  Decision logic, like all business rules, is inherently about know-how retention.

When Operational Business Decisions Should Be Made

In the know-how model described above, the decision logic for the operational business decision, Which is the best agent to assign to a customer?, can be invoked as a violation response for the behavioral rule.  Do decision rules have flash points too?  Yes, but the implicit assumption in decision analysis is that evaluation of decision rules need not be based on their own flash points.

In general, the default point of determination for decision rules is case-based.  In other words, an operational business decision is made for a case simply because either the particular case is ready for the decision or the related circumstances demand it.

Example:  An order has been filled and packaged and is ready to be shipped to the customer.  All behavioral rules have been satisfied.  Now the correct or optimal delivery method for shipping the package needs to be selected (an operational business decision).  The correct or optimal answer is determined by evaluating the decision rules.  Afterwards, things move along as per the business process (e.g., the package is shipped).

Reversible Decisions

Sometimes, as in this example, once a decision is made for a case there is no practical way of turning back.  In other words, barring some unforeseen scenario, the operational business decision is final (irreversible).

Not all operational business decisions have that degree of finality.  In essence some decisions can be reversed or improved, at least for a period of time.  Indeed, not revisiting such decisions can prove counter-productive, wasteful, or even dangerous.

Example:  An agent needs to be assigned to a customer.  Unfortunately, all the agents most highly qualified for that customer are currently unavailable or overloaded with work.  The best approach might be to assign an interim agent, then revisit the case later.  You never know, a highly qualified agent might suddenly shake loose in the next little while.

As this example suggests, a reversible decision can be revisited by introducing time-based criteria (some business rule(s)) to re-evaluate selected cases after a certain period of time, perhaps repeatedly.  The possibility of significant over-time improvement in reversible decisions is always worth exploring.

Could you achieve the same result in a business process model?  Adding business task(s) downstream in a business process model for the purpose of improving earlier decisions is usually not recommended (too complex).  A better approach, especially for last-chance improvement opportunities, is to include some appropriate business milestone(s) in a business milestone model.^[6]

Available Resources in Short Supply?

Some operational business decisions are characterized by a potential shortfall in resources relative to demand.  For example, a car rental agency at an airport might not have enough rental cars of the right models to satisfy all outstanding reservations.

The best approach in such circumstances is generally to wait as long as you can to make any decision.  During the delay, you save up a 'batch' of incoming cases, then make decisions for the whole batch at once.  This approach ensures the best possible match-ups for higher-priority cases.^[7]

Example:  Reservations from high-status customers might come in at the beginning of the delay period, but rental cars of the requested models might become available only toward the very end.  Had you assigned rental cars in real-time (i.e., as each reservation is received), your aggregate solution would be suboptimal for the time period.  In plain English, suboptimal means your best customers are needlessly unhappy.

The trick, of course, is determining how long a delay in making the decisions is too long.  Answering that question involves analyzing trade-offs among your business goals.  Remember, we're not modeling know-how for the sake of the know-how.  We're modeling it for the sake of deploying the best-possible business solution!

Summary

Operational business know-how is complex, involving both behavioral rules and decision rules.  Understanding their intertwined roles is key to creating high-quality, true-to-life business models and, from them, effective business operation systems.  Treating business rules as a first-class citizen also shifts your focus toward operational business events, especially flash points.

Business Analysts should not work down to business rules in use cases or other system models; business rules should be a primary focus in creating a business model.  The resulting know-how model will be unbeatable in its support for business agility and knowledge retention.

References

[1]  BRS In-Depth White Paper:  Decision Analysis Using Decision Tables and Business Rules.  Available free on www.BRSolutions.com

[2]  Refer to Chapters 5, 7, 9, 11, and 15 in Building Business Solutions:  Business Analysis with Business Rules, http://www.brsolutions.com/bbs

[3]  Ronald G. Ross, "Introducing Question Charts (Q-Charts™) for Analyzing Operational Business Decisions:  A New Technique for Getting at Business Rules," Business Rules Journal, Vol. 11, No. 12 (Dec. 2010), URL:  http://www.BRCommunity.com/a2010/b567.html

[4]  See www.RuleSpeak.com (free).

[5]  Refer to Chapter 15 in Building Business Solutions:  Business Analysis with Business Rules, http://www.brsolutions.com/bbs

[6]  See Chapters 10 and 11 in Building Business Solutions:  Business Analysis with Business Rules, http://www.brsolutions.com/bbs

[7]  Sometimes call pattern matching by business rule management systems (BRMS).

# # #