A First Example

Imagine you are an Airline reservation officer working at the check-in counter for a busy domestic airline. Getting the aircraft off on-time is critical as delays can result in fees applied by the airport controllers, needing to fly at a lower altitude increasing the cost of fuel, and other penalties.

A message from the supervisor appears on your screen saying that the economy cabin is overbooked you will need to upgrade some passengers to Business or First Class - but which passengers should be chosen and which cabin should they be upgraded to? A decision needs to be made but what factors should be considered? This can be recorded in a Decision Model using a Decision Requirements Diagram.

This is helpful but the busy check-in officer would still need to weigh up all the factors and make an unbiased decision. Should a disgruntled passenger be given priority over a Gold level frequent flyer, or should the fact that a particular passenger is connecting to an international flight take precedence. These 'rules' can all be recorded in a decision table making it clear which passengers should get an upgrade and to which cabin: Business or First class. This will make it much easier to make the decision and the rules can be formulated, agreed upon and checked for consistency back at head office. In this example we have kept it simple and used two factors: firstly the number of flights the passenger has made in the last month and secondly how overbooked the cabin is.

The table is divided into columns and rows. There are two types of columns: inputs that are required to make the decision and outputs that are the result of applying the rules.

This is very helpful but still requires the busy check-in officer to be able to source all the required information required to find the right row in the decision table. Even if all this information were available a wrong decision could still result from human error in selecting the wrong row in the table

Fortunately the Decision Models can be automated and generated to programming code that can be executed by an application. So our busy check-in officer would not need to do anything or make any decisions, as she was checking in the passengers if a particular passenger was entitled to an upgrade it would be visible on the computer screen. In the diagram below the model has been simulated so that the business and technical staff can agree that the model has been defined correctly. Any number of user defined data sets can be used to test the model before generating out the programming code that will run in the check-in system and display the result to the end user.

When developing the models a business or technical user can step through the simulation and the system will show the user which row in the decision table was fired to determine the output. This is very helpful in models that are made up of multiple decisions.

It is common for the rules that govern the upgrade decision to change. For example the marketing department may decide they want to reward passengers that travel on long-haul flights. The Decision Requirements Diagram can be altered to include the new input, the Decision Table modified, and the programming code regenerated. Once the changes have been pushed through to the airport systems magically the right passengers will be upgraded. The check-in officer could still view the decision tables during training and briefing session so as to understand the rules.