Get a Grip on Operational Business Decisions: Question Charts (Q-Charts™)

An operational business decision has structure that you can’t capture using business process models, use cases, or similar techniques. If you fail to delineate that structure, you completely miss a core part of what makes business processes smart.

The structure of a decision can be diagrammed in top-down, business-friendly fashion using a Question Chart (Q-Chart™ for short). As discussed in this article, Q-Charts involve two fundamental elements: decisions and decision dependencies.Decisions are a commonly overlooked target for business analysis.  Here’s how you can get a grip on decisions and create the groundwork you need to capture important kinds of business rules.

Decision analysis aims toward capturing and encoding the logic used to make decisions. These decisions are always operational business decisions– not programming, personal, strategic, or governance decisions. Operational business decisions are common in business processes. Examples:

• Should an insurance claim be accepted, rejected, or examined for fraud?

• Which resource should be assigned to a task?

• Which service should be used to ship a package?

As these examples suggest, decision analysis involves identifying and analyzing key questions arising repetitively in day-to-day business activity.

Figure 1. Example of a Q-COE

QUESTION CHARTS (Q-CHARTS)

The structure of an operational business decision can be diagrammed using a Question Chart (Q-Chart™ for short). Q-Charts involve two fundamental elements: decisions and decision dependencies.

1. Decisions. An elongated hexagon, called a Q-COE™, stands for an operational business decision. Each Q-COE indicates what question (“Q”) is being asked, and usually one or more of the following: considerations (“C”), outcomes (“O”), and exceptions (“E”).Figure 1 presents a simple example of a Q-COE.

2. Decision Dependencies. A dependency between operational business decisions occurs when one decision is logically a prerequisite for another. Three kinds of decision dependencies as given in Table 1. Each kind of decision dependency is discussed individually below.

Table 1: The Three Kinds of Decision Dependencies in DecisonSpeak™

In Q-Charts, decision dependencies are represented by special connectors. These connectors are always displayed with a vertical orientation. Why? Horizontal connectors might suggest process or flow. Since decision logic should always be developed in declarative fashion, horizontal connectors are avoided.

The decision on the top (the upper decision) is always dependent on the decision below it. If a Q-Chart shows multiple levels of decision dependency (not unusual), the same is true pair-wise at each level below.

As illustrated in the discussion that follows, every depiction of a dependency connection includes a ‘hitch point’ (a solid circle) at the bottom end. The operational business decision on that end is always the one most able to stand on its own – i.e., the lower decision is always the more independent.

RELEVANCE DEPENDENCY

In relevance dependency, one operational business decision depends on the outcome of another operational business decision such that the outcome of the other decision may completely eliminate the need for any outcome from the dependent (upper) decision.

In other words, the dependent operational business decision can be preempted – indeed, made meaningless in certain cases.

In determining eligibility of applicants for auto insurance, for example, if an applicant is not eligible for coverage, there is no need to determine what to charge the applicant as a premium. This relevance dependency between operational business decisions is illustrated in Figure 2 using a dashed connector (with hitch point at bottom). The dashed line extends from the question area of the Q-COE representing the dependent (upper) decision.

Figure 2: Relevance Dependency between Operational Business Decisions

Do processes always have to address the questions involved in a relevance dependency in bottom-to-top sequence? No, but caution should be exercised.

For the questions in Figure 2, for example, a customer-friendly, web-based application might permit price-conscious consumers to ask about the premium before asking about eligibility.

If supported, however, including some disclaimer would probably be appropriate to indicate that securing coverage at the given price is subject to eligibility. An explicit business rule should be written for that purpose. The business rule ensures a disclaimer is given by any process or use case that supports a price-before-eligibility sequence.

CONSIDERATION DEPENDENCY

In consideration dependency, one operational business decision depends on the outcome of another operational business decision such that the outcome of the latter decision provides or supports one of the considerations for the dependent (upper) decision.

For example it might not be possible to decide what coat to wear unless you decide whether it is cold. Deciding whether it is cold might have considerations all its own. This consideration dependency is illustrated in Figure 2 using a solid-line connector (with hitch point at bottom).

The consideration cold? in the dependent (upper) decision is conditional. Whether or not it is cold depends on the three considerations of the lower decision: temperature, wind and humidity.

If a consideration is not conditional in that sense (i.e., not based on other considerations), a consideration dependency is not needed. For example, suppose you can say "Yes, it’s cold." or "No, it’s not cold." without needing to know anything about the temperature, wind and humidity. Then the lower decision Is it cold? is not needed.

OUTCOME DEPENDENCY

In outcome dependency, one operational business decision is dependent on the outcome of another decision such that the outcome of this other (lower) decision dictates some outcome(s) of the dependent (upper) decision. Two essential rules always apply to outcome dependencies:

• Both decisions must have the same kind of outcome.

• The set of considerations of the less dependent (lower) decision must be the same as, or a subset of, the set of considerations of the more dependent (upper) decision.

Figure 4 illustrates an outcome dependency using a dashed connector (with hitch point at bottom). The dashed line extends from the outcome area of the Q-COE for the dependent (upper) decision.

Observations:

• The lower (independent) Q-COE represents the question "What set charges are there for shipping an order?" and has the outcome fixed shipping charge.

• The upper (dependent) Q-COE represents the question "What should be charged for shipping an order?" and has the outcome shipping cost.

• The structured business vocabulary (concept model, not shown) must indicate fixed shipping charge and shipping cost to be the same kind of thing.

• The lower Q-COE uses the considerations zip code and season, a proper subset of the four considerations for the upper (dependent) Q-COE.

• The net effect is that the lower Q-COE will dictate (“set”) some (but presumably not all) outcomes for the upper (dependent) Q-COE. For example, if the zip code is in Alaska, and the season is winter, all shipping costs might be $250, regardless of weight or kind of package. This business rule might be just one of many that dictate (“set”) shipping cost for multiple cases.

RELEVANCE DEPENDENCY VS. OUTCOME DEPENDENCY

Relevance dependencies and outcome dependencies are alike in one important way – they both represent dependencies that can eliminate the need to ask the question for the upper (dependent) decision. Because of this similarity, a dashed line is used to represent both.

Relevance dependencies and outcome dependencies are different, however, in the following fundamental way:

• For relevance dependencies, the outcome from the lower (independent) decision makes any outcome from the upper (dependent) decision meaningless in certain cases. In other words the upper (dependent) decision simply cannot produce any valid outcome for those cases.

• For outcome dependencies, the outcome from the lower (independent) decision dictates the outcome for the upper (dependent) decision in certain cases. That outcome is the only one the upper (dependent) decision can produce for those cases.

Relevance dependencies and outcome dependencies are always distinguishable by the form of the question specified for the lower (independent) decision. In other words, the question is always worded distinctly.

• A relevance dependency always asks a yes/no question (e.g., eligible/ineligible?).

• An outcome dependency always asks about a fixed or set outcome (e.g., fixed shipping charge).

Here’s yet another example that if you ask the right questions in the right ways about decisions, the answers (and in this case the business rules) will always follow naturally.

Author: Ronald G. Ross is recognized internationally as the ‘father of business rules.’ He is Co-founder and Principal of Business Rule Solutions, LLC, where he is active in consulting services, publications, the Proteus® methodology, and RuleSpeak®. Mr. Ross serves as Executive Editor of BRCommunity.com and as Chair of the Business Rules Forum Conference. He is the author of nine professional books, including his latest, Building Business Solutions: Business Analysis with Business Rules with Gladys S.W. Lam (2011, http://www.brsolutions.com/bbs), and the authoritative Business Rule Concepts, now in its third edition (2009, http://www.brsolutions.com/b_concepts.php). Mr. Ross speaks and gives popular public seminars across the globe. His blog: http://www.ronross.info/blog/ . Twitter: Ronald_G_Ross