Previous | Table of Contents | Next |
1. | Fill kettle |
2. | Switch on kettle |
3. | Get out cups |
4. | Put tea bag in cup |
5. | Wait for water to boil |
6. | Poor water in cup |
7. | Get out milk |
8. | Remove tea bag |
9. | Add milk |
10. | Add sugar |
11. | Stir |
1. Boil kettle |
1.1 Add water to kettle |
1.2 Remove water from kettle |
1.3 Switch on kettle |
1.3.1 Plug in kettle |
Plan: 1.3.1. if not already |
Plan: 1.1 OR 1.2 as necessary then 1.3 |
2. Prepare cup/tea |
2.1 Get cup |
2.2 Get tea bag |
2.3 Put tea bag in cup |
Plan: 2.1 and 2.2 in any order than 2.3 |
3. Poor water on tea bag |
4. Add milk |
5. Add sugar |
6. Stir |
Plan: 1. and 2. in parallel then 3; 4. 5. and 6. as necessary |
(HTA) |
(Have a cup of tea) |
1. Have tea bag and boiling water in cup |
1.1. Have boiling water |
1.1.1. Have right amount of water in kettle |
1.1.2. Kettle heating water |
1.2. Have cup |
1.3. Have tea bag |
2. Have milk and sugar to taste |
2.1. Have milk |
2.2. Have sugar |
2.3. Tea stirred |
A comparison of Tables 5.2 and 5.3 illustrates how different representations of the same thing can make different information explicit. It may seem a small change to redescribe the process boil kettle as the state of the world have boiling water but in our experience it can lead to significant insights concerning how procedures can be redesigned. Stretching this example a little, one can see how formulating the objective have tea bag and boiling water in cup might lead one to think of alternative methods of boiling the water such as boiling the water with a heating element placed directly in the cup. Without the restriction to write down the objective of each step it is too easy simply to use the name given to the process in the old procedure without really thinking about what that process is for.
4.2. WHAT IT LOOKS LIKE
Table 5.4 is the WOD generated to reason about the design of a computer system for logging goods in and out of the cold storage facility described above. The objectives 1.1, 1.2, 1.3, and 1.4 come from the rich picture. Note that the top level objectives 2 and 3 are not expanded. This is because it was not anticipated that the design would be concerned with this part of the operation. The analysis suggested possible changes to 1.1 and 1.2. The delivery note (see objective 1.1) could be obtained from the supplier in electronic form. It could be sent by e-mail or carried on magnetic media by the driver. If this were not possible various short cuts could be provided for entering the data. Quantities (see objective 1.2) were currently agreed by the warehouseman shouting them through a window. This process could potentially be simplified if the information in the tally card were on a portable data recorder.
1. Delivery logged |
1.1. Delivery note recorded in system |
1.1.1. Have delivery note obtained from driver |
1.1.2. Gate house record number entered |
1.1.3. Supplier details entered |
1.1.4. Products entered with quantities |
1.1.5. Printing of tally cards requested |
1.1.6. Warehouse men have tally cards |
1.2. Delivery note validated |
1.2.1. Quantities agree |
1.2.2. Printing of confirmation of delivery requested |
1.2.3. Driver has confirmation of delivery |
1.3. Locations of delivery logged |
1.3.1. Locations entered |
1.4. Delivery record sent to DMS for allocation to stores |
2. Goods allocated to stores [normally accomplished by DMS] |
3. Picking notes generated |
Previous | Table of Contents | Next |