What is a Business Decision

A business decision is any choice made by a business professional based on a set of input factors that results in the creation of some outputs. Such a decision may be entirely manual or entirely automated or a mixture of both.

At the very simplest level a decision is represented by this diagram:

From a practical point of view the name of the decision should reflect its purpose and the output box should specify what is being determined by the decision. For example:

The input box should contain the factors that need to be considered in order to make the decision. For example:

The decision box in between represents a mapping from the input(s) to the output(s). This is usually referred to as "the business rules". Often these rules exist in the heads of the business experts or they may have been written down in some documentation. For example, here are some rules for determining price based on color, size and shape:

• red toys are $5
• large, square toys are $10
• round, green toys are $15

These rules can be represented by a table inside the decision:

In this example there is only one decision table but in a more complex decision there could be many tables. Each table specifies its required inputs and the output it produces.

Here is the decision table corresponding to the rules (which are represented by vertical columns):

If preferred, the rules can also be represented horizontally:

Once the rules are represented in table format we can apply some verification checks to see if the rules are complete and consistent.

For example what is the price of a small red square? Is it $5 (rule 1) or is it $10 (rule 2)? In this case the rules are ambiguous and need to be updated to resolve the inconsistency.

We might do this by modifying rule 1 slightly so that small red toys are $5

.

But we also need to check that the rules cover all possibilities.

For example what is the price of a large round red toy or a small green square toy?

Again we need to update the rules to cover all the possibilities.

For example:

Note: This table makes the assumption that colors are red or green, sizes are small or large and shapes are square or round.

If at some point blue toys are allowed then we need to add rules to cover blue toys. We might also consider adding rules to reject any toys with invalid color, size or shape. Most likely that would be done in a separate "data validation" table though it could also be done in the pricing table.

Whether we add tables to handle invalid data or not depends a lot on how much we "trust" the data. If it is raw data being typed on a keyboard then it could be anything. But if its data that has already gone through some previous validation processing then we may not need to repeat those checks in our decision table.

When a decision makes some assumptions about the quality of the inputs we can specify those using "constraints". Any inputs not meeting those constraints will not be processed by the decision.