Previous | Table of Contents | Next |
4.3. HOW TO DO IT
Start from the rich picture. You may have to return to some of your informants to check on details. Like the rich picture, the WOD should stand on its own and will only need minimal supportive text. You will need to create a WOD for each user role. The following instructions may be used. As with the rich picture you will probably need to prepare before and after WODs, though sometimes the objectives will remain the same even though the processes have changed.
Some developers with a mathematical training may find the above process arbitrary and informal. It is. The WOD is not a formal notation and the method specified above will result in different representations when it is applied by different people. This is not a problem. Design is a creative craft and this analysis is a part of that creative process. The representations described here are better thought of as artists materials than engineering tools. The representations make it possible for the developer to create something new and useful by taking a new view on an old problem.
5. PROBLEMS AND INTERRUPTIONS THE EXCEPTIONS LIST
5.1. WHAT IT IS FOR
The WOD is an idealized view of the task. It needs to be supplemented by what might go wrong, the exceptions list. Application exceptions are things that can go wrong for the system; user exceptions are things that can go wrong for the user. Engineers are used to anticipating application exceptions, such as power failure or the system being unable to recognize a password. They are less used to thinking about user exceptions.
User exceptions are usefully categorized as interruptions and problems/mistakes. An example of an interruption in the cup of tea example would be being called away while the tea was mashing. Interruptions imply the need to save work. If this problem were serious one might think of some way of automatically removing the tea bag and keeping the tea warm. Problems/mistakes imply the need to undo something. Adding sugar when it was not wanted would be an example of a mistake, though it is difficult to see how this could be undone.
5.2. WHAT IT LOOKS LIKE
Table 5.5 is the exceptions list for the warehouse case study. All the exceptions listed were mentioned as being disruptive to the flow of work by the operatives questioned. Most particularly, the current system did not allow the operator to save the work if interrupted while entering the details from a delivery note. This commonly happened when they were working on a delivery note of goods for the ambient storage and then a delivery for the cold storage arrived and began to defrost on the unloading bay. Naturally, the cold storage took precedence in such a situation and the former work was abandoned and hence lost.
Application exceptions |
Queries from DMS in 2 |
Invalid Gate House Record No., Supplier details or Product in 1.1 |
Printer off-line at 1.1.5., 1.2.2, or 3 |
User exception interruptions |
Interrupted in 1 to do 1.1 or 1.2 for more urgent new delivery |
Wait for warehouse man to return with new count in 1.2.1 |
User exceptions problems/mistakes |
Allocation by hand in 2 |
Notice error in data during 1.1.2 to 1.1.4 |
Quantities changed during 1.2.1 |
Repeat printing of Tally Cards at any point |
Repeat printing of COD at any point |
Repeat printing of Picking notes at any point |
Previous | Table of Contents | Next |