Tokyo Electron

Tokyo Electron Ltd (TEL) is currently the second largest supplier of production equipment to the semiconductor manufacturing industry, selling state-of-the-art equipment to the major microchip makers worldwide. As part of a joint development agreement with a European R&D center, TEL engineers are developing a new high-k semiconductor process based around the company’s TELFORMULA vertical mini-batch furnace using 12-inch silicon wafers. The experimental process was tested in Japan and transferred to the customer site’s machine—one of a handful of similar tools worldwide.

CHALLENGE: After initial success, the product from the customer tool began to exhibit poor thickness repeatability. This was blamed on tool-to-tool variances and addressed by tuning the process. When this did not fully resolve the problem, a specialist was flown from Japan to assist in finding the cause. While he was able to address some minor issues, the thickness problem remained unresolved. Eighteen months after installation, the tool was still unreliable.

SOLUTION: At this time, TEL production specialists in Europe were being trained in KT Problem Solving & Decision Making as part of a global initiative to improve customer support. After training, Dr. Darren Hill recognized the TELFORMULA issue as a good application of KT processes. Using KT Problem Analysis, he created an initial problem statement and then specified the problem by asking what, where, when, and the extent of the variation, using the tool on the customer site as the IS (what is, where is, etc.) and the mother tool in Japan as the IS NOT. A key distinction identified a problem in the pressure control system as the cause of the thickness variation.

He then initiated a second Problem Analysis to identify the cause of the cause by analyzing the pressure control system problem. This led to additional testing and data collection both in Europe and Japan. The systematic logic of rational process uncovered two different issues with the mother tool in Japan that had caused the deviation, the customer tool have been proven to be working entirely correctly. A new BKMKM (best known method) was issued for the process and the problem has not recurred.

RESULTS: Using KT rational process, an 18-month old problem was resolved in two months, full confidence in the state-of-the-art tool was restored, and the relationship between TEL and the client was strengthened. Today this Problem Analysis is used in engineer education and it is credited with opening new lines of global communication.

During this same period at the R&D lab, ongoing problems with a competitor’s tool were never resolved and the tool was abandoned by the competitor. When the customer’s new technology is eventually adopted, TEL is poised to provide more new tools—each with a multi-million dollar price tag.

Summary of the Problblem Analysis Process:

Describe Problem

State the problem
What has the deviation? What is the deviation? What do we see, hear, feel, taste, or smell that tells us there is a deviation?

Specify the problem
WHAT   has the deviation?   could have, but does not?

is the specific deviation? 

is the object? 

is the deviation on the object?  

other possible deviations but are not?

else could the object be, but is not?

else could it be on the object, but is not?


was the deviation first observed?   

since that time has it been seen (pattern)?

in the object’s history or life cycle seen first?

else could it have been first observed, but was not?

since could it have been observed, but was not?

else could it have been observed, but was not?


How many objects have the deviation? 

What is the size of a single deviation? 

How many deviations are on each object?

What is the trend?  

How many objects have the deviation?           

What size could it be, but is not?

How many deviations could we have, but are not?

What could be the trend, but is not?

Identify Possible Causes

Use knowledge and experience to develop possible cause statements (often beneficial to examine distinctions and changes first)
Use distinctions and changes to develop possible cause statements (not necessary for “Extent”)

Evaluate Possible Causes

Test possible causes against the IS and IS NOT specification (record “Only if” qualifiers)
Determine the most probable cause

Confirm True Cause