Field Service Corrective Maintenance

Allura Xper systems are complex systems that can malfunction during their lifetime and in such situations customers complain when faults occur during the operation of the systems. In such cases, the FSE is required to x the problem within the system in the hospital. Depending on the type of problem, the eld service process can consist of the following corrective actions:

• Conguration: hardware/software reconguration

• Calibration: correction of abnormal settings according to standards

• Field Replaceable Unit (FRU) Replacement: replace the detected faulty FRU with a new one

In general, the maintenance of the systems by FSEs consists of either Installation Activities, Planned Maintenance (PM), Corrective Maintenance (CM), and Field Change Order (FCO). Installation activities consists of hardware/software congu-ration of the system in the hospital, when the customer buys the equipment. PM is an arranged maintenance carried out at regular time intervals and consists of ac-tivities such as calibration of the X-Ray tube. CM handles the complaints of the customers when a system malfunctioned and usually is associated with the replace-ment of a FRU.

There exists a job sheet database, called Customer Support Data Warehouse (CS-DWH), that records repair-relevant information like all customer complaints, cus-tomer call open/close date, replaced FRUs, call type (PM, CM, etc.), maintenance hours, etc.

Due to the complexity of system architecture and the exibility of system use, the diagnostic procedure is not always easy and eorts are needed to help FSEs during corrective maintenance cases:

1.2. Product Line Allura Xper 11

Figure 1.8: Corrective Maintenance case

• Sometimes FSEs cannot x the problems correctly on the rst time, and the system will continue to behave abnormally in an intermittent manner and the FSE will have to pay additional visits to the customer. For example, the

rst-time-correct-x-rate is quite low for some components.

• Sometimes FSEs replace wrong FRUs. The reason for that is either that they are not able to pinpoint the root cause of the problem, or that there was pressure from the customer to x the problem quickly. The time spent to solve the problem might be too long for the customer to bear. In these situations, FSEs don not have enough time to diagnose the problem thoroughly and they replace all potentially faulty parts.

• Some FRUs have high variation in CM hours spent during diagnosis, which implies that some of the cases are not easy to diagnose. Figure 1.8 depicts the CM hours spent on a system for the replacement of the part Converter Velara 8E. The FSE spent 4 hours in the fault isolation step, to identify the cause failure, then 1.5 hours on repairing the system (i.e., the actual replacement of the part), 0.5 hours on calibrating and conguring the system and 0.5 hours on verication of the system functionality. Thus, the duration of a CM case is dened as the time spent in fault isolation, repair, conguration & calibration and verication. Typically, the last three steps (i.e., repair, conguration &

calibration, and verication) have a low variability and mainly are predened steps related to the procedure of part replacement, while the fault isolation time as well as the activities performed during this step, vary a lot from case to case.

The actions performed by the an FSE during diagnosis (maintenance) are expected to be manifested in event logs. The malfunction of a certain system is indicated in the job sheet records (the customer complaint and the FRU replacements). Having both data sources available, viz., event logs and customer complaints, there is an opportunity to link them.

With the availability of event logs and correlating them with the job sheet database we can use process mining techniques to get insights into the work of FSE. In Figure 1.7 examples are given for a log le and a job sheet.

The motivation for this project arise out of the necessity to understand the work of the FSE and identify the bottlenecks in the process (discover which activities take more time), check if all mandatory activities are performed, etc., in order to help the organization better understand the workow of FSE and identify means to reduce the repair time. The ultimate objective is to help improve customer service quality and to reduce costs, and more importantly to improve customer satisfaction.

1.3.1 Problem Identication

The goal of this thesis is to better understand the workow of the Field Service En-gineer in Philips Healthcare. The FSE performs activities like installation, update, conguration and other administrative activities for the maintenance of the Philips Healthcare X-Ray systems. Currently, there are certain issues and questions about the activities performed by the FSE. Time spent on maintenance of systems varies a lot and sometimes is very high, wrong replacements of FRUs are not uncommon.

It is unclear for domain experts what the causes of these problems are. So there is a need to understand the way how engineers work. The main requirement is to discover the workow from the log les and better understand what the FSE does in the eld during diagnosis.

Traditionally, process mining has been focusing on discovery, i.e. deriving informa-tion about the original process model, the organizainforma-tional context, and the execuinforma-tion properties from enactment logs [19]. Traditional discovery algorithms have problems dealing with unstructured processes and result in process models which are hard to comprehend. Multiple activities in the event log are composed by a number of sub-activities. Considering these activities in isolation contributes to the spaghettiness

of process models. There is a need for abstractions by discovering common patterns of activities, that can help in improving the discovery of process models and assist in dening the conceptual relationship between activities. Constructing hierarchical process models can provide dierent views on a process model, hiding irrelevant content from users but with the possibility to uncover comprehensible models with a seamless zoom in/out facility.

In real life event logs, the granularity at which events are logged is typically dif-ferent from the desired granularity. For example in Philips case there are over 500 commands FSEs can execute and these commands are stored in event logs. Con-structing a process model from these event logs (at the level of commands) can result in complex process models which are hard to comprehend, due to the exibility of the system use. Moreover, the perspective of analysis diers according to the role of the analyst, for example, a manager may prefer a high level view on processes while a specialist may be interested in detailed aspects [16]. The perspective from which the management in Philips is interested in understanding the work of the FSE is at the level of procedures that engineers are executing and not at the level of commands.

Apart from discovering process models at dierent hierarchical levels, process mining

1.3. Problem Denition 13