• No results found

Site background

N/A
N/A
Protected

Academic year: 2021

Share "Site background "

Copied!
24
0
0

Bezig met laden.... (Bekijk nu de volledige tekst)

Hele tekst

(1)

Description diagnosis process

In order to describe the actual primary process of solving an unscheduled down a detailed reconstruction of a Long Down Time unscheduled down (LDT) has been performed. A LDT is an unscheduled down that lasts longer than eight hours in a row. Describing a LDT has been done by selecting a relevant and representative LDT and by interviewing the actors of solving the LDT. The customer site Infineon in Dresden has been chosen to conduct this research since many LDT’s occurred at its machine park. It is acknowledged that the selected LDT and customer site may have its own distinctive characteristics.

Some characteristics of this case study, therefore, can not be seen as completely representative for all LDT’s at all customer sites. This issue will be discussed at the end of this appendix. It is believed however that the process of solving the LDT in this case study gives a reasonable insight on how unscheduled downs are solved at other customer sites.

Site background

The man-machine ratio at the Infineon site has been reduced the last two years from effectively three people for eight machines (1:2.5) to effectively one Field Service Engineer (FSE) for nine machines (1:9). The decrease of the man-machine ratio can be explained, because many FSE’s and 2

nd

line engineers went to the XT and fab 36 and no additional engineers were contracted. The man-machine ratio is fixed in the service contract with the customer. Infineon had decided to spend less money on labour costs, which resulted in a decrease of the man-machine ratio. In practice there is only one FSE present in the fab, where two engineers are scheduled (this is due to training, vacations, and illness). The FSE’s work in three shifts (scheduled 6 people a day) and in total there are 10 FSE’s working at the Infineon site. Since one year the preventive maintenance on all machines is done by the customer (see figure A1). The machine park at the Infineon site has two special characteristics. There are two machines on which research is done in daytime, and there is one pilot machine. Pilot machines have relatively more problems due to their technological immaturity.

Next to the fact that the Infineon site has many LDT’s, the site is interesting for another reason. As already mentioned, the site has a man-machine ratio from 1:9, which corresponds with the future target set by the ASML headquarters for all Twinscan sites.

The Infineon site is one of the few sites in the world who already has their man-machine ratio in line with the ASML target. It is interesting to see what difficulties come forward when applying the target man-machine ratio. Furthermore the bottlenecks with regard to solving unscheduled downs are more clearly visible when the man-machine ratio is low (1:9), than when the man-machine ratio is high (1:2).

Case study background

The Long Down Time which is used as a case study in this research is the LDT of the

1250 Twinscan. One important limitation of the description of the LDT is that it was not

possible to interview every FSE who has worked on the LDT. The reason for this is that

the machine went down for approximately eighty hours starting from the early shift on 15

December and ending the late shift of 18 December 2004.

(2)

In the process of solving the LDT four to five different FSE’s have been working on the LDT in eleven shifts of eight hours. Due to the high work pressure the FSE’s were very occupied and did not have much time for interviews. The 1250 Twinscan is a pilot machine and has been installed at the Infineon site since march 2004. A pilot machine means that it has passed the prototype phase (by developers in the headquarters), but it has not yet been put into (mass)-production. A pilot machine is placed at the customer where it is carefully monitored for a specific period and lessons of the machine are used to improve the machine design. The monitoring is done by the New Product Introduction (NPI) department of Customer Support at the headquarters. When a pilot machine is introduced the FSE’s and 2

nd

line engineers are additionally trained, the machine is introduced at the customer site, and additional support is available. Since October the intensive monitoring of the 1250 by the NPI department has been reduced and the machine is managed the same as the rest of the machine park.

A1. Subdivision of total machine time

(3)

The case study will be described by focusing on the role of each type of actor in the total unscheduled down process (see Appendix C). Each actor type has to take various steps that can be subdivided in input, transformation, and output related actions (see figure A2). The steps that each actor type has to take are graphically represented in a so-called Actor Activity Diagram.

A2. Link input, transformation, and output process Infineon

When a machine goes down the first actor who is involved in the unscheduled down solving process is the customer.

Transformation

Input Output

operation engimeer customer

maintenance engineer customer

Noticing machine unscheduled

down

C

Verbal

C

(face to face or by

phone) Register

down?

Collect information

down

Perform fast start-up

C

Describeproblem

verbally (first by phone later face to

face) Register

down?

Figure A3. Infineon process unscheduled down

solving

(4)

Input

When a machine goes down an alarm signal goes off and the Infineon production engineer is informed. Sometimes when a machine goes down it fails to give an alarm signal. This might happen when there is an error on the product itself. In this case it may take for about an hour for the Infineon production engineer to notice that the machine is malfunctioning.

Transformation

When an Infineon production engineer has noticed that a machine is down, he will inform the Infineon maintenance engineer about the unscheduled down. The customer maintenance engineer first collects and stores all the data in an information system called Logfinder in order to get a clear picture of the problem. When the information about a down is not logged properly, performing a fast start-up loses essential information. This is especially the case when the cause of the down is software related. If the logging of information is always done correctly has not become clear in this study. After the data has been collected the maintenance engineer performs a fast start-up. In about 60% of all downs the machine functions normally after a fast start-up has been performed.

Output

All information about the down is stored in Logfinder, which can be accessed on the machine. Furthermore, the customer books the time of the down in the customers’

information system. The reason for this is to determine the performance of how long it takes to solve unscheduled downs. It is not clear how the time of the down is administrated: when the Infineon production engineer discovers the down, or when the Infineon maintenance engineer is informed. There may be a substantial time lag between the time in which the production engineer discovers the down, when the Infineon maintenance engineer is informed, and when the ASML FSE is informed. It may occur that when the ASML FSE is called, the machine is already down for two hours. This may be attributed to the performance of ASML.

When the fast start-up fails the Infineon maintenance engineer escalates the problem to the ASML FSE.

The customer has a rather limited definition on what actions are necessary in order to solve unscheduled downs. Only visible actions on the machine are regarded as productive. Some necessary actions in order to solve the LDT efficiently, such as information gathering, are considered by the customer as unproductive and thus idle time.

Scheduled downs

As already mentioned, the customer performs the preventive maintenance part of the total

process of the ASML-machines since one year. Most customers at other sites do not

perform the maintenance of the machines themselves. Doing the preventive maintenance

on the machines, makes the customer also responsible of the first crucial steps of data

collection and diagnosis of downs. The customer has to collect information and performs

a fast start up. When the maintenance task of the machines has been transferred to the

Infineon maintenance engineers, they had to be additionally trained by ASML. Still the

skill level of the Infineon maintenance engineers is not always sufficient.

(5)

Infineon does not have access to the spare parts, so the maintenance engineers cannot perform spare part swap actions. They only have access to consumables such as filters.

But even here are sometimes problems with installation. At a filter swap action problems occurred because the Infineon maintenance engineer was not skilled enough. In this case the ASML FSE’s are assumed to help the Infineon maintenance engineers to adequately perform the maintenance. In general the ASML FSE’s are obliged to assist and train the Infineon maintenance engineers in maintenance, next to their current work load.

Field Service Engineers

Input

When a down machine cannot be fixed by the Infineon maintenance engineer, the ASML field service engineer (FSE) is involved. This is usually done by calling the FSE on his mobile phone. If an FSE is on duty he can be in the clean room where he performs actions on the machines or he can be in an office at the Infineon site. This office is physically separated from the clean room for about a ten minutes walk. Furthermore, when an FSE travels from the clean room to the office and back, he has to change clothes.

In this office there is an Ethernet connection to the ASML network.

Figure A4. Field Service Engineer process unscheduled down Communicate information by phone and

email

C C1

Communicate progress problem solving

field service engineer AMSL

second line engineer ASML

C

maintenance engineer customer

Diagnose down, run tests, swap

parts

Escallate in ASML-Q &

verbally

C

Describe problem verbally (first by phone later

face to face)

C

C

Run tests &

collect data for 2nd line engineer

Administrate actions

C

(6)

Next to the office at the customer site there is also an Infineon terminal where emails can be sent and received. The disadvantage is that on this terminal no ASML applications are available. Furthermore, there are a few computer terminals in the Infineon clean room, but these are not always available.

The most important input in the transformation process of unscheduled downs is the FSE who attempts to fix the machines. Their capability to successfully do this depends from two factors: the FSE’s experience and training level. The FSE’s at the Infineon site are considered to be fairly experienced: most FSE’s work in the clean room for two to three years. Since the last reorganisation many experienced FSE’s left or were transferred (for example to the regional office). According to one FSE most problems are tackled by experience.

In order to get a clear picture of the machine down, there are various information sources which the FSE can use. Firstly, he can use Logfinder on the machine to retrieve all background information about the down. Many tests on the machine may also provide information. The information on the machine is said to be the most important source of information for solving unscheduled downs. The FSE can also communicate verbally with the Infineon maintenance engineer in order to get more background information of the situation. Finally, the ASML network databases Coach and Problem Cause Solution (PCS) can assist the FSE in finding information about similar problems and how these may be solved.

It is said that there are difficulties to get Coach-updates in the office at Infineon. This might take up to six hours due to a slow connection. This is an Ethernet-connection, which is able to deliver twice an ISDN speed (256kb). This is considered as too slow by the FSE’s, and in practice Coach is only updated when the FSE’s are in the regional ASML office. Since the FSE’s do not regularly visit the regional office their Coach database is not updated most of the time. In the two days that the case study has been described in the clean room the use of (databases on) laptops has not been observed.

There is a big separation between the FSE’s at the customer site and 2

nd

line engineers in the office. Some FSE’s do not go to the regional office for one and a half month. This might be a problem since they are not fully aware of what goes on in the regional office.

The FSE’s do get emails, which keep them up to date, but due to an information overload not all emails are read.

The description above focused on the process of when a down is first identified. But as

already mentioned in the background of the case study, FSE’s work in shifts and

unscheduled downs may last longer than an eight hour shift. In this case information and

knowledge about a down must be transferred from one FSE to the next FSE. This is done

by organising an overlap in shifts of half an hour. In this half hour the FSE has time to

communicate which machines had what problems, what actions have been taken, and

what actions still have to be done. In order to have a complete picture of what has been

done on the machines the passdown report is used. Every FSE writes a passdown report

at the end of his shift, although this is not always (correctly) done. The basis for the

passdown report is the logbook on the machine. In the logbook all actions and tests on the

machine are administered and this is mainly for internal use.

(7)

Added to the passdown report is an Excel sheet where additional information about the machines is stored, such as Field Change Orders (FCO’s) or patches which need to be installed.

Transformation

With the available information the FSE tries to solve the problem on the machine. Here verbal communication plays an important role. FSE’s estimate that waiting for parts, recovery sequences, and waiting for response from the headquarters consume the most time when solving unscheduled downs. The diagnostics itself is said to consume for about 10%-20% of the total problem solving time. The latter is an interesting remark, since the headquarters assumes that diagnosis consumes for about 50%-60% of all problem solving time. Finally, it seems to be very difficult to give a practical definition of what diagnosis exactly means. For example, is running a test considered to be diagnostics? Is the escalation of an unscheduled down to 2

nd

line engineers considered diagnostic time?

Diplomacy is felt to be an important part of the daily job of an FSE. When a machine is down the customer expects that the FSE is continuously busy with actions on the machine. In reality the FSE sometimes has to wait for diagnostic data from the regional office or headquarters or he has to wait for spare parts to arrive. In order to give the impression that work is being done on a down machine, the FSE sometimes starts up some diagnostic tests.

When multiple machines are down at the same time the FSE has to work on the machine which has the highest priority for the customer. A machine with a lower priority is then down for a considerable time. This is booked as a LDT for ASML.

One explanation by the FSE’s for the long LDT’s is that there is limited support from 2

nd

line engineers and the headquarters at night and in weekends. If a machine goes down at this time, and the FSE on duty does not know how to solve the problem the unscheduled down time increases rapidly. At nights there is 2

nd

line support from the US headquarters in Tempe, but this support is not considered as helpful. There are two reasons for this.

First, it is felt that Tempe gives priority to escalations from the US. Second, the quality of support is seen as insufficient. The feedback from Tempe is seen as useful for getting ideas about the problem, though. When Tempe is contacted this is mostly done when everything else has failed. In order to overcome the lack of support, 2

nd

line engineers sometimes create an action plan that FSE’s can follow when a machine is down. The advantage of this is that the FSE can analyse, isolate, and possibly solve a problem when no 2

nd

line engineers are available.

Output

The main output of the unscheduled down are a passdown report and call-id in ASML-Q

when the unscheduled down is escalated. The passdown reports are the input for the

performance co-ordinator at the regional office. In interviews the performance co-

ordinator has complained about the quality of the output of the FSE’s. For example, the

passdown reports often do not contain all actions that are taken, the times of the actions,

and sometimes the passdown reports are not sent. The administration of the times of the

actions in the passdown reports is subjective.

(8)

Regional office

The actors in the regional office are next to the 2

nd

line engineers also for example a performance co-ordinator who monitors machine performance, and a customer support supervisor who operationally manages the FSE’s and the 2

nd

line engineers.

Input

When the problem is escalated to the 2

nd

line engineers the data about the down will be transferred in a call-id. Next to this official escalation, the FSE on duty will informally call to the regional office in order to make sure that they are aware of the unscheduled down.

The sources of information for the regional office are as follows. The first source of information is the FSE. The FSE gives information about the down usually by mobile phone. Another important source of information for the 2

nd

line engineers is the machine itself. The 2

nd

line engineers sometimes have a direct connection to the machine in order to remotely run tests and download data. Further sources of information about a down are the results of tests on the machine that can be collected by FSE’s by instruction of the 2

nd

line engineer. The event log viewer collects all the machine data on the machine which can be assessed by the customer and the FSE’s in the clean room. The event logs are also uploaded at nights to the database of the headquarters where it can be remotely and easily accessed and downloaded by all engineers. Other information about unscheduled downs can be collected from the logbook and the Call Identification Number (CID) in ASML-Q.

When the performance co-ordinator has analysed the data of an unscheduled down, this is passed on to the responsible 2

nd

line engineer.

Figure A5. regional office process unscheduled down solving

Escallate in ASML-Q &

verbally Communicate

information by phone and email

C field service

engineer AMSL

second line engineer

ASML

third line engineer ASML

C

Diagnose down on site:

run tests, swap parts (possible with

FSE) Diagnose

down at office: if necessary return to C1

C C

C

C Communicate

progress problem solving maintenance

engineer customer

(9)

Transformation

As came forward from the research, all unscheduled downs that are escalated to the regional office should first be handled by the performance co-ordinator. If there is a long down the performance co-ordinator will analyse the data of the down. After this he will check in PCS if it is a known problem. Sometimes he gives procedures from the PCS to FSE’s by phone. When a problem is located to a specific subsystem, the problem is passed on to the responsible 2

nd

line engineer. It is not clear, if the FSE on duty always calls the performance co-ordinator or that he directly calls a 2

nd

line engineer. The same is true when a 2

nd

line engineer is already in the clean room when a machine goes down.

When a down is escalated to the regional office, the relevant people (such as customer support supervisor) are informally informed in an early stadium.

When an unscheduled down is escalated to the 2

nd

line engineer, the background information about the down is transferred mainly by communication by phone. The next step is that the 2

nd

line engineer asks for additional information from the FSE such as the call-id and results from tests of the machine. The 2

nd

line engineers feel that not always all necessary data has been (properly) collected. When this is the case the 2

nd

line engineer must wait until the FSE has collected the data or he has to collect the data himself. When the necessary data is collected the 2

nd

line engineer may send a procedure, which has to be followed by the FSE in order to determine the root cause of the problem.

Small procedures are usually passed on by phone and more complicated procedures are sent by email. When this is done and the machine is still down the 2

nd

line engineer may go into the customer site. He can do this in an earlier stage when he feels that this is necessary.

When the 2

nd

line engineer is on site working on the unscheduled down, the FSE is not always involved. For example, when a 2

nd

line engineer was working on the unscheduled down, he did not involve the FSE about his actions. The FSE felt that he was able to perform some actions on the machine, but the 2

nd

line engineer chose to not involve him.

In another situation the FSE was working on another machine, when the 2

nd

line engineer performed diagnostics on a LDT. It is unclear why the FSE sometimes is not involved. In the daytime FSE’s are very busy with working on other machines. Also 2

nd

line engineers are not always able to share knowledge. Sometimes specific procedures have to be followed and it may take a long time to explain these to the FSE’s. Because the FSE is not involved in the diagnostic actions important learning opportunities are missed.

Output

When a down has to be escalated to the headquarters, the 2

nd

line engineers have to collect al the necessary data and information, fill in ASML-Q, and verbally communicate the problem to colleagues and the customer.

When an unscheduled down is solved it has to be administered so it can be presented to

the customer and analysed. First, it has to be reported in ASML-Q. Due to the high

workload and a low priority this is sometimes done two weeks after the down has

occurred. The customer support supervisor creates the Field Service reports (FSR: is

created after each down) and Long Down Time reports (LDT: is created after a down of

longer than four hours).

(10)

In the FSR the distribution of the man-hours for each sub-task of the problem solving is administrated. This subdivision is subjective, since the subdivision is mainly based on often-incomplete passdown reports.

Every three weeks a knowledge transfer meeting is organised at the local office where 2

nd

line engineers and FSE’s come together to exchange knowledge about important parts of the job. Here, knowledge about solving unscheduled downs can be transferred. These meetings are not visited often by FSE’s.

In a weekly customer interface meeting with the customer the most important topics with unscheduled downs and reliability issues are discussed. The FSR, LDT and particularly Post Mortem Analysis are the main inputs for these meetings. Here the problems with the machines are analysed and improvement and prevention plans are constructed. For the Infineon customer in Dresden this meeting is prepared at the office with multiple actors:

the customer support supervisor, the performance co-ordinator, the lead engineer, and involved 2

nd

line engineers.

Training

Almost all FSE’s are level three trained with some specific level four training. Training level 1 to 3 is a minimum in order to be allowed to work on the system. Based on a global estimation the FSE’s at Infineon Dresden are trained 15 days per year. The training package is based on the shift team. When there are three people in the shift, the complete training package can be spread over three people. Due to the decrease in people the same amount of training now has to be done by two people. The decrease of the man-machine ratio has thus resulted in an effective increase of training effort of 50% per FSE. The supervisor determines who has to do which training programs and hereby he focuses on the training programs that have a relationship on the most problematic topics.

(11)

Input

Return fized machine

Communicate information by

email machine father

customer

C C

field service engineer

AMSL

second line engineer

ASML

third line engineer ASML

Diagnose down at office

Communicate solution by verbally of by

email C C

Diagnose down on site

Diagnose down on site:

run tests, swap parts

(with 2nd liner)

C C

C

C Communicate

progress problem solving

Administrate solution in ASML-Q and

write LTD Communicate information by

email Diagnose down at office

Escallate in ASML-Q &

verbally

Request for more information

C C

C C

C C

Run tests &

collect data for 3rd line

engineer

Diagnose down at office

Figure A6 Third line engineer process unscheduled down

Third line engineer

operation engineer customer

D D

(12)

When the LDT cannot be solved regionally (when the 2

nd

line engineer is ‘out of ideas’) it is escalated to the headquarters. Officially the problem has to be escalated to the headquarters after 24 hours, and has to be decided after 48 hours if a 3

rd

line engineer has to come on site. However, this procedure is not always followed in practice. A 3

rd

line engineer can be contacted by composing an ASML-Q with all necessary information and asking for 3

rd

line support. Previously 3

rd

line support was given less formally: 3

rd

line engineers could be called informally and could be asked for a brief consultation. Today 3

rd

line support is only possible by formally asking for support. The regional office feels that this procedure is bureaucratic and that the headquarters is less inclined to give support than before. At the headquarters a 3

rd

line engineer is assigned to the LDT and he requests additional information from the local competence engineer.

Transformation

When the 3

rd

line engineer receives the necessary data he starts diagnosing and the problem is discussed with his colleagues in order to get a clear picture of the problem. In this process he mainly has contact by phone or email with the assigned 2

nd

line engineer.

When the 3

rd

line engineer is busy diagnosing, the customer support supervisor is already organising for the 3

rd

line engineer to come on site if necessary. In co-operation with the customer a meeting has been organised in which would be decided if a 3

rd

line engineer had to come on site. In cooperation with the customer it was agreed that a 3

rd

line engineer would go to the fabrication site. The visit of the 3

rd

line engineer to the site was an open end stay: the 3

rd

line engineer had to stay as long as the machine was down. In the mean time that a 3

rd

line engineer is travelling from the headquarters to the customer site, another 3

rd

line engineer temporarily takes over and assists with the unscheduled down so that the 3

rd

line support is continued.

When the 3

rd

line engineer arrived, it took one hour for him to get from the airport to the machine. He subsequently had to be administered, to get clean room clothes, to get dressed (here the problem was already explained to him), before he could actually work on the machine. Each customer site has its own administrative access procedures. Arrived at the machine the 3

rd

line engineer rapidly asked many high level analytical questions in order to get a clear picture of the problem. The communication was mainly between the responsible 2

nd

line engineer and the 3

rd

line engineer. The FSE was not involved in the problem solving process. Instead he started to work on other machines. The 3

rd

line engineer first globally checked the hardware, after turning to the software. All this is done in close co-operation and communication with the 2

nd

line engineer. The 3

rd

line engineer took the initiative to collect data on the machine and 2

nd

line engineer mainly assisted. It seemed that the third engineer had a somewhat different approach of diagnosing than the seconds line engineer. Where the FSE’s and 2

nd

line engineers mainly focused on the hardware, the 3

rd

line engineer focused mainly on the data and tests on the machine.

After the problem was relatively well isolated but it was clear that the problem would be

difficult to be found, a mass-swap action was proclaimed. This means that the most

essential spare parts of the isolated problem would be ordered and replaced. The cause of

the problem was found by coincidence: the 2

nd

line engineer accidentally opened the

wrong side of the machine, and saw that a cable was damaged.

(13)

After the problem was found, the third and 2

nd

line engineer reasoned back that this had to be the source of the malfunctioning of the machine. When the cable was fixed, some tests were performed and the machine performed normally.

Output

For the 3

rd

line engineer the output of the transformation is a fixed machine. Next to this he analyses the LDT in reports, which can be done in two ways. When the root cause of the LDT is a structural problem, such as an patch or an FCO, an Improvement Proposal (IP) is written and escalated to the fourth line engineers (developers). If the root cause of the LDT is not structural a technical post mortem is constructed, which may lead to improvements of the procedure or the construction of an PCS. The 2

nd

line engineer makes the ASML-Q report and the LDT-report for the customer.

The added value of a 3

rd

line engineer on site is big. Firstly, the customer feels that his problem is taken seriously, since a 3

rd

line engineer from the headquarters is on site.

Secondly, a 3

rd

line engineer has more specialised (software) tools to his disposal. He has support from his colleague 3

rd

liner engineers at the headquarters and he is also able to contact 4

th

line engineers (developers) at the headquarters. Finally, the problem solving is much easier when 3

rd

line engineer is on site than when he is at the headquarters.

When there is no 3

rd

line engineer on site (see I in figure A7), the 2

nd

line engineer must diagnose according to directions by phone or email, and he must find ways to email data to the headquarters. When a 3

rd

line engineer is on site (see II in figure A7), he can diagnose himself in co-operation with the 2

nd

line engineer. This face-to-face communication is very effective and it goes very fast. The 3

rd

line engineer also has easy contacts by phone and email with third and fourth line engineers.

A7. Difference between remote and on site support 3

rd

line engineer

Note: this description of the primary process is a personal interpretation based on unstructured interviews and observations in a period of ten days. This description of the case study has been given to key respondents for feedback. Feedback from a 2

nd

line engineer and a 3

rd

line engineer has been incorporated.

Time delay

Low detail

REMOTE ON SITE

2 3

4 3 3

I

2 3

4 3 3

II

(14)

Generalise-ability case study

The findings of how unscheduled downs are solved at Infineon Dresden cannot be completely generalised to all the other ASML sites in the world. This is because not all customer fabrication sites are identical. For instance, customer fabs can differ in their size (from small to large), ASML system (mature PAS technology versus maturing Twinscan technology), purpose (from research fab to production fab), product types (DRAM, processors, and logic). Also customer sites can differ in their performance, their man- machine ratio, the average level of training, and so forth.

Although customer sites can differ substantially, the results of the description of the case

study may be generalised under the following conditions. The first classification is the

distinction between PAS and Twinscan systems. These systems differ substantially with

regard to their technology maturity. The PAS system technology can be typified as

mature, whereas the Twinscan technology can be labelled as not yet mature. The solving

of unscheduled downs on Twinscan machines is more difficult, because much less

problems are known. Since the research has been conducted at a Twinscan site it is

assumed that the results can only be generalized to other Twinscan sites. Another variable

that has to be kept in mind, is the man-machine ratio. The Infineon site has an

extraordinary low man-machine ratio, which has resulted in a high workload. The man-

machine ratio at other sites is often lower. With regard to the training and experience

level of the FSE’s and 2

nd

line engineers this seems to be fairly in line with other sites in

the world. A final characteristic of the case study is the management of the FSE’s. The

FSE’s seem to have much freedom in performing their task and seem to be only limitedly

managed by their customer support supervisor. The case study results may only be

generalized when the FSE’s are similarly managed. Since the research has been

conducted at a German site, the results of this research may only be generalise-able to

sites with similar cultures, such as the so-called western cultures.

(15)

APPENDIX B AAD PROCESS UNSCHEDULED DOWN SOLVING

Actor activity diagram process unscheduled down solving, sheet I

Based on observations and interviews LDT 1250XT

operation engimeer customer

maintenance engineer customer

Noticing machine unplanned

down

C Verbal C

(face to face or by

phone) Register

down?

Collect information

down

Perform fast start-up

C Register

down?

Communicate progress

problem solving

C

Diagnose down, run tests, swap parts C

C Describe

problem verbally (first by phone later

face to face)

third line engineer ASML field service

engineer AMSL

second line engineer

ASML

Run tests

& collect data for 2nd line engineer

Administrate Escallate in

ASML-Q &

verbally

C1

C

maintenance engineer customer

(16)

Actor activity diagram process unscheduled down solving, sheet II

maintenance engimeer customer

machine father customer operation

engimeer customer

Communicate information by phone and email field service

engineer AMSL

second line engineer

ASML

third line engineer ASML

C C

Diagnose down on site:

run tests, swap parts (possible with

FSE) Diagnose

down at office: if necessary return to C1

C

C

Communicate

progress problem solving

Communicate information by

email Diagnose down at office

Escallate in ASML-Q &

verbally

Request for more information

C C

C C

C C

Run tests &

collect data for 3rd line engineer

Diagnose down at office

(17)

Actor activity diagram process unscheduled down solving, sheet III

operation engimeer customer

Communicate information by

email machine father

customer

C C

field service engineer

AMSL

second line engineer

ASML

third line engineer ASML

Diagnose down at office

Communicate solution by verbally of by

email

C C

Diagnose down on site

Diagnose down on site:

run tests, swap parts

(with 2nd liner)

C

C

Communicate

progress problem

solving Administrate

solution in ASML-Q and

write LTD

D D

Return fixed machine

(18)

APPENDIX C SUPPORT ORGANIZATION ESCALATION PROCESS

(19)

APPENDIX D ABC-SCHEDULE

Rooterror finding (5 to 10 min)

Recovery (30 to 60 min)

Error History and recovery File (Currently the logbook)

Return system to customer

Check if problem is

“known”

Follow PCS & check

ASL-Q

Return system to customer

Max 2 hours before you escalate to a higher level

A

B

C

Fast start up if nok reset all processor perform a full start up if NOK initialize via ADT Observe and write

down the error situation

Follow PTCL (DATA collection)

Escalate to 2nd or 3 rd line

Perform action

plan When problem

is

“unknown”

Return system to customer

Make LDT Report When standard recovery

fails, determine if problem seen before or not . Use PCS in Coach

When problem is unknown gather all required information as listed in the PTCL and escalate

Availability focus of Working supervisor, Fab team leader, reliability coordinator

(20)

APPENDIX E SYSTEM BOARDER RESEARCH

(21)

appendix F Formal Task tree diagnostic at the machine

(22)
(23)
(24)

APPENDIX G SMART PROJECT MANAGEMENT

SMART project management exists from five keywords (specific, measurable, attainable, realistic, and tangible) which all will be elaborated below.

Specific - A specific goal has a much greater chance of being accomplished than a general goal.

To set a specific goal you must answer the six "W" questions:

*Who: Who is involved?

*What: What do I want to accomplish?

*Where: Identify a location.

*When: Establish a time frame.

*Which: Identify requirements and constraints.

*Why: Specific reasons, purpose or benefits of accomplishing the goal.

Measurable - Establish concrete criteria for measuring progress toward the attainment of each goal you set. When you measure your progress, you stay on track, reach your

target dates, and experience the exhilaration of achievement that spurs you on to continued effort required to reach your goal.

Attainable - When you identify goals that are most important to you, you begin to figure out ways you can make them come true. You develop the attitudes, abilities, skills, and financial capacity to reach them. You begin seeing previously overlooked opportunities to bring yourself closer to the achievement of your goals.

You can attain most any goal you set when you plan your steps wisely and establish a time frame that allows you to carry out those steps. Goals that may have seemed far away and out of reach eventually move closer and become attainable, not because your goals shrink, but because you grow and expand to match them. When you list your goals you build your self-image. You see yourself as worthy of these goals, and develop the traits and personality that allow you to possess them.

Realistic - To be realistic, a goal must represent an objective toward which you are both willing and able to work. A goal can be both high and realistic; you are the only one who can decide just how high your goal should be. But be sure that every goal represents substantial progress. A high goal is frequently easier to reach than a low one because a low goal exerts low motivational force.

Some of the hardest jobs you ever accomplished actually seem easy simply because they were a labour of love.

Your goal is probably realistic if you truly believe that it can be accomplished. Additional ways to know if your goal is realistic is to determine if you have accomplished anything similar in the past or ask yourself what conditions would have to exist to accomplish this goal.

Tangible - A goal is tangible when you can experience it with one of the senses, that is, taste, touch, smell, sight or hearing. When your goal is tangible, or when you tie an tangible goal to a intangible goal, you have a better chance of making it specific and measurable and thus attainable.

Intangible goals are your goals for the internal changes required reaching more tangible goals.

They are the personality characteristics and the behaviour patterns you must develop to pave the

way to success in your career or for reaching some other long-term goal. Since intangible goals

are vital for improving your effectiveness, give close attention to tangible ways for measuring

them.

Referenties

GERELATEERDE DOCUMENTEN

With respect to hypothesis 4b, formulated as: Given the fact that a headquarters is present in a particular city, a high presence of related companies increases the amount

Koninklijke Bibliotheek – National Library of the

The results showed that VWO students had higher levels of English proficiency than HAVO students; this difference was not only due to the differences in school type,

We analyze the content of 283 known delisted links, devise data-driven attacks to uncover previously-unknown delisted links, and use Twitter and Google Trends data to

The results show that the cultural variables, power distance, assertiveness, in-group collectivism and uncertainty avoidance do not have a significant effect on the richness of the

Chapter 3 then gives the outcomes of the quantitative research, accompanied by an inventory of the custodial penalties imposed for murder and manslaughter from 1 February 2006

In the Netherlands, online patient-monitoring of side effects is a new phenomenon, for which a web application known as BijKanker (‘AlongsideCancer’) has been designed and built.

( 2007 ) sample spectrum were unambiguously detected and indi- cated that the wavelength scale is very accurate, i.e. a possible shift is smaller than the statistical uncertainties