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, and possibly having to fly at a lower altitude, increasing the cost of fuel and the payment of other penalties. Not to mention the inconvenience for passengers who could miss important meetings and who - next time they fly - might choose another airline.

Imagine you are in the process of checking passengers at a busy domestic airport. A message from the supervisor appears on your screen saying that the economy cabin is overbooked; you have to upgrade some passengers to Business or First Class - but which passengers should be chosen? A decision has to be made, but what factors should be considered? The busy check-in officer is not in a position to be able to make this decision. They could be helped by viewing some of the factors they should consider that have been 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.

The table is divided into columns and rows. There are two types of column: 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 information required to find the right row in the Decision Table. Even if all this information were available, an inappropriate 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 they are checking in the passengers; if a particular passenger was entitled to an upgrade, the reservation would have been automatically altered and the upgrade would be visible on the check-in screen. The only thing the Airline Reservation Officer would need to do is provide the welcomed news to the passenger - 'Mr Travelealot we are delighted to provide you with an upgrade to First class on your flight to New York this morning'

It is common for the rules that govern the upgrade decision to change. For example, the marketing department might decide that 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, tested and simulated 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 a training and briefing sessions so as to understand the rules. Many of the implementation engines would also provide a business friendly explanation as to the basis of the decision so the check-in officer could explain to the passenger the reasons for their upgrade.