6.4.2 Testing second prototype at KLM
The prototype was brought to KLM for demonstration and to perform some tests, the
aim of this trip was also to require additional information to the analysis, just to be
certain that it would be company independent. Also, the testing of the prototype was
focused on checking the consistency of the usability and functional requirements. Only
the requirements that did not involve the rest of the Descartes system would be tested.
The controllers at KLM handles problem concerning the following resources (“The
airline business”, 2001):
§ Fleet size: 97
§ Employees: 30 253
§ Passengers: 16 million
Before leaving for KLM, goal of the tests were prepared and questions to achieve these
goals. The questions to be answered were:
q Is it valuable to always be able to monitor all problems?
q Is it valuable to have graphical presentations of the alarms?
q Is it possible to solve tasks in the traditional way, not using solvers?
q What functionality is missing?
16 Wishes from the crew, e.g. not work on Sundays, or a night stop at a special location on a certain date.
q What information is missing?
The tests were performed three times at the controllers’ desks in the very large and noisy
room that is the KLM Operations Control at Schipol Airport in Holland; one sales
representative at Carmen and one from KLM arranged the visit. The three test persons
consisted of one manager of crew control (former crew controller), one crew controller
and one roster maintenance person. The tests were performed from laptops placed on
the table in front of the test persons.
When the tests were performed, two different designs were shown, to give the test
persons a referential system. Initially a brief explanation of the concept of Descartes was
given, and then the old master thesis project (Armini, Wallenburg, 2000) was shown,
where a problem was demonstrated and solved. The concept was explained fairly quickly,
but still ensured that it was understood. Then the Operations Monitor concept was
explained, and the prototype was presented in detail. Questions came up, and the
answers were to be found by letting the test person try pushing a button to find out what
function it was, and by letting the test person explain what he think it should be. Finally a
scenario was explained verbally, and the test person explained how he would solve the
problem with his existing tools. Then the scenario was demonstrated visually, showing
how a typical problem could be solved in the old way, using the test persons own terms
and definitions to increase the understanding, and then in the new way using Descartes.
The scenario was a delayed flight that involved crew legality, and affected 12 members of
the crew that would miss their connecting flight, an every day problem.
Results
q The controllers find it valuable to be able to monitor the alarms, as long as it is
the problems that concerns them, that they do not have to sort out which are
relevant or not. It would ease the work a lot, if all information about an alarm
were to be found in a click.
q Graphical presentations are mostly valuable when working with scenarios, being
able to move the objects with drag and drop. Since there seems to be a possibility
to include vital information into the graphical objects presenting alarms, like in
the prototype, then it will fulfill its purpose, and even be very satisfying.
q It is possible to solve problems in the traditional way, since all the information
needed, and the functions to support that work is available or possible to add.
q Suggestions to information and functions missing:
§ A shift change report was asked for, to know what has been done during the
previous shift.
§ Information about crew hours and the complicated system of points
connected to these has to be presented in the personal stand by and crew
information.
§ The Gantt chart of the aircraft rotations was used to a minimum extent
today, meaning this could be a sub function to look for during the rare times
when it could be useful.
§ A check in list was considered as vital, which is an updated status report on
the crews, with alarms generated if they are late.
§ All of the test persons asked for the possibility to work with possible
scenarios.
§ A complete stand by list containing information about the licenses,
competences and location of the crew.
The tests were affected by the fact that it is complicated to separate the Operations
Monitor from the rest of the Descartes concept, as well as separating the user interface
from the underlying system. Difficulties came up when explaining Descartes in total
since this was not the purpose of the tests and there was no interest in knowing the test
persons opinions about that, but it became easier when focusing on one detail, solving
problems the traditional way using the Operations Monitor.
Another aspect that have affected the result was the fact that it was impossible to
run the prototype and demonstrate the scenario on the computers used by the
controllers, but on laptops meaning much smaller screens and an environment not
known to the users. There was also a lack in that there were no screen dumps from their
own systems within the prototype, which would have made them more confident with
the system since they would recognize the environment.
The attitude towards the concept of the Operations Monitor was mostly positive,
and when the controllers got used to the prototype, they came up with constructive
feedback, helping us to judge what functions are fundamental and which are not, and
what was missing.
Home again, the results from the workshop as well as from the KLM visit was
immediately discussed. All possible functions were written down on small post-it notes,
and according to the studies, tests, interviews and workshops, the functions were
grouped and classified as main functions or sub functions.
Figure 6-6 Post-it notes for evaluating functions
Bạn đang xem 6. - AIRLINE CREW CONTROL OPERATIONS MONITOR: PART 2
