Operational business decisions have structure we can examine more or less anatomically.  Let's look at an example of a decision and dissect it.  To make things interesting we'll start with a behavioral business rule and see how it might fit in.  The ultimate goal of this discussion is to answer the question:  What's a "decision" from a business point of view?

Scenario:  A customer places an order.

Behavioral business rule:  A customer that has placed an order must have a service representative.  ("Behavioral" means the rule is an obligation on people, rather than a necessity on knowledge, a.k.a. definitional rule).  The company has deployed this business rule — maybe years ago or maybe just yesterday.  "Deployed" means the business rule was made operational by either of two means (doesn't matter which for this discussion):

• Giving it to some human(s) as a job responsibility.
  
  
• Automating it in a suitable platform — e.g., a business rule engine (BRE).

Motivation:  The reasoning behind the business rule is that the company knows its products are complex, so any customer that buys one should have a point of contact to assist them in using it correctly.  That reasoning is the motivation for the business rule, its pedigree, which should be recorded in the company's rulebook and made available to everyone (assuming they are authorized and capable).  After all, the business rule might need to change in the future, so you want to understand its original purpose.

Violation event:  The particular customer placing the order does not have an assigned service rep.  Some staff person or the BRE realizes that a service rep needs to be assigned.

Detection:  That staff person or BRE did not 'decide' the customer needed a service rep.  No operational business decision is involved here.  A customer without a service rep placing an order simply results in a violation of the business rule.  No 'reasoning' is needed for that.  A good analogy is a radar speed trap.  A motorist going down the street either is, or is not, exceeding the speed limit.  You don't 'decide' about it, the motorist simply is or isn't.  You just use the rule to test perceived reality.

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

Operational business decision:  The need to pick and assign a particular service rep 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 service rep to assign to a customer?  The manager makes a decision and assigns a service rep.  Presumably things move on from there.

The real-time dynamics of the behavioral business rule are fundamentally different from those of the operational business decision.  (I use real time to mean in-line with ongoing business activity to take customer orders.)

• For the operational business decision the central issue is what logic (decision rules) to use to select and assign the best service rep from among alternatives for that customer at the given point in time.  Real-time 'reasoning' is clearly required.
  
  
• For the behavioral rule the central issues are its original motivation, detection of violations, and appropriate response to violations.  No real time reasoning is required to make any choice.  Like any event, a violation of a behavioral rule just happens.  No operational business decision is involved.

Aside:  The actual event is application (testing) of the business rule, not its violation per se.  Sometimes you might want to respond to a non-violation.  For motorists not speeding, for example, a message could be posted on a street-side electronic sign, "Thank you for not speeding today!" (Not very likely, I suppose.)

As discussed below at least three factors can conspire to make situations involving behavioral business rules seem complicated.  Sometimes you have to dig a bit to see the real picture.  I'll illustrate using the radar speed trap example.

1. What the Real Business Rules Are

• The real business rule is probably not the published business rule (the posted speed limit).  It's probably something more like:  A vehicle must not exceed the posted speed limit by more than x miles per hour.
  
  
• Notable exceptions probably apply, for example:  A government vehicle with siren and lights flashing may exceed the speed limit.

2. Response to Violations

The policeperson operating the speed trap (being only flesh and blood) has discretion about how to respond to a violation.  Some possible factors:

• "I'm eating my doughnut and drinking my coffee, and I'm not going to spoil the moment by chasing someone down the street."
  
  
• "I'm behind on my quota, and the sergeant is really cranky today, so I'm going to chase down everybody without mercy."

In other words, choice does come to play in how the policeperson responds to a violation.  The choices might be:  Let the speeder go, chase the speeder, hand the speeder off to another unit down the street.  Real-time choice among alternatives represents a true operational business decision.  Just remember — how to respond to a violation of a business rule is not the same thing as the business rule itself.

Aside:  'Condition-action' and 'event-condition action' syntax for expressing rules badly conflates this fundamental distinction.  I'll discuss that in next month's column.

3. The Decision to Create a Business Rule

Sometime in the past the city government, concerned about public safety, decided a speed limit was needed.  What speed limit should it post?  There were choices, of course, a range of possible speed limits, and it had to choose from among them.  The speed limit posted (deployed) is the one that got selected.  That's the business rule (at least officially).

The creation of a business rule does represent a decision, because it involves selection from among alternatives.  That kind of decision, however, is not real-time to business activity (i.e., motorists driving down streets).  Rather than an operational business decision, the creation of a business rule represents a governance decision.  Extremely important, but not the same thing.

A governance decision is part of the organization's governance process, not part of its operational (real-time) business processes (e.g., day-to-day traffic control).  The governance process is higher-level (governing).

Decision analysis should focus on operational business decisions in operational business processes.  To support the governance process you need tools for developing business strategy, analyzing business rules, and managing the rulebook.

Final Point

Returning to the original service-rep example, let's say several months ago the company decided to automate the assignment decision.  The business analysts undertook decision analysis and created a Question Chart (Q-ChartTM).^[1]  Spending time with the business people, they developed some decision tables.  They faithfully documented the motivation (pedigree) for the decision logic so it could be retained in the rulebook for future reference.  The decision logic was subsequently deployed under a BRE.  Now, instead of the line manager performing the decision task when required, the BRE does it by evaluating the decision tables.

No matter, it's still an operational business decision, a selection among alternatives to be made in real time.  From a business perspective, only these things have changed:  The line manager has been freed up to do other, more demanding work.  Her know-how has been encoded so the company won't lose it should she leave.

References

[1]  Refer to Decision Analysis Using Decision Tables and Business Rules by Ronald G. Ross, a 76-page in-depth white paper available free on http://www.brsolutions.com/b_decision.php

# # #