Design the next generation service management platform: Remote diagnostics

Design the next generation service management platform: Remote diagnostics

Boks, M.A.M.

Boersema, T. (mentor)
Van Mourik, F. (mentor)

Industrial Design Engineering

Industrial Design

Design for Interaction

2012-12-19

Introduction: This report describes a graduation project performed at Getinge. Getinge provides complete solutions for, among others disinfection and sterilization departments of hospitals (Chapter 1. Background). The assignment was to build an application that supports their complete service process. This service aims at minimizing or preventing a washer-disinfector or sterilizer from breaking down. A breakdown could cause the cancelation of surgeries relatively quickly, because the necessary instruments are still contaminated. The complete service process was studied during the analysis phase. However due to the tight time schedule of this project, the choice was made to continue only with reactive service. In this type of service, an acute breakdown has to be repaired. Problem: The aim of reactive service is to get a machine back up and running as quickly as possible, therefore the downtime should be minimized as much as possible. However currently there are delays in the repair process (Chapter 2. Analysis). First of all a service rep can only diagnose a problem on site. To do this he has a to run a complete wash (or sterilization) program to regenerate the error. Next he has access to a large amount of data to diagnose an error. He could see the error messages, read manuals, review the service history, see process graphs and data and look up updates. However these resources lack any form of structure, so he has to figure out what is related. Furthermore he has only a limited amount of spare parts in his service van, so when he has diagnosed a cause, it could be that the needed spare part has to be ordered. This could take two to three days. Process changes: Due to the problems mentioned above, it became necessary to change the approach on reactive service (Chapter 3. The idea). All data deriving from the machines can be viewed at the back office, because they are connected to the Internet. Additionally all other resources needed to diagnose an error, are being digitalized at the moment, so it is possible to make a preliminary diagnosis at a distance. This makes it possible to nightly ship the possibly needed spare parts to the service rep and send him the next day to diagnose the error further and subsequently repair the cause. Design process: A flow diagram has been designed in which all resources are connected to each other (Paragraph 3.2). This flow diagram shows that resources can be filtered based on the module. This module belongs to the error message that the user selects as cause. The error message is the reason why a (wash or sterilization) process has been rejected by a machine. The next step was to divide the flow diagram in pieces that are manageable for a user to be displayed in one screen. There are different ways to structure information on a screen. The choice is made to put all parts of the flow diagram with the same meaning together in one screen. Thereafter these “screens” needed to be ordered in a sequence to structure the diagnostics process. This would enable service reps to perform each other’s work faster and more easily. The last step was to design workflows for each screen. These workflows envision the use of the screens. They show what the application needs to do and what input is required from the user. These workflows have been made to understand what each screen should do and to ensure that the user has the final decision. Service reps have the knowledge and experience to perform service and therefore it is demanded that they have the final decision. Graphics: Next the basic layout of the application has been designed (Chapter 4. Graphics). This ensures that the layout is consistent throughout the complete application, which will make it easier for users to learn to use the application. The grid is divided into two parts. The left part will list items of a resource and clicking one item will show its details in the right part. The selected item and its details are visually connected by the use of the same colour and symbol. This colour is the opposite colour in the colour wheel of the other used colours and therefore stands out. The other used colours are grey and blue, colours that derive from Getinge’s logo and are generally used for Getinge’s applications. The “Summary” is added on the right-hand side of the screen. This screens slides out when clicking on it and shows the user his previous findings. In this way the user can easily compare his findings with what he is currently looking at. The previously mentioned workflows are used together with this basic layout to build each screen (Chapter 5. Concept). Evaluation: A prototype has been built in Adobe Flash to test the usability of the design. This has been done in observational research (Chapter 6. Evaluation). Here the five experienced service reps had to imagine a breakdown and use the application to diagnose it. During the study several problems were found. It occurred that the participants could not find functions and missed information. However they were impressed by the application and mentioned some recommendations for further improvements. Ideas haves been created based on these recommendations and the found problems (Chapter 7. Recommendations). These ideas will take the application to the next level. Also recommendations to continue the development after the graduation project ended are given.

Graphical User Interface (GUI)
Usability test
Observational Research
Diagnostics
Service

http://resolver.tudelft.nl/uuid:196c21de-d899-46a8-8558-0daba306ec06

2013-12-19

Campus only

Student theses

master thesis

(c) 2012 Boks, M.A.M.