JP2005182635A - 品質改善システム - Google Patents

Abstract

【課題】品質改善に伴うエンジニアの解析手法をシステム化して、エンジニアの作業効率の向上を図ることができる品質改善システムを提供する。
【解決手段】ナレッジサーバ１２のナレッジＤＢ１５には、エンジニアにより設定された解析手順の定義ファイルが蓄積され、アプリケーションサーバ１３により、その解析手順に従い外部ＤＢ１８から所定のデータが取得されてデータ解析が行われる。その解析結果に対して、クライアントサーバ１４から入力されたリファレンス情報が付加され、ナレッジＤＢ１５に蓄積される。そのリファレンス情報によって重要度が判断され、その重要度の高い解析手順の定義ファイルがナレッジＤＢ１５から抽出される。
【選択図】 図１

Description

本発明は、半導体製造工程で取得された各種の品質データを用いて品質改善のための処理を行う品質改善システムに関するものである。
近年、高度化する半導体製造プロセスにおいて、製造工程数の増大や工程処理技術の複雑化が進んでいる。このことから従来の解析システムでデータ解析を行う場合には長い手番を必要とする。また、エンジニアが解析手法を有効に活用するためには、その解析システムに習熟する必要がある。つまり、品質改善のノウハウについては、エンジニアの個人毎に蓄積されるだけで、システムの有効性は使う側の能力に委ねられている。そのため、エンジニアの思考に沿った解析手法をシステム化して、品質改善のスピードアップを図る技術が要求されている。

従来、半導体製造工程における品質改善については、工程、部門毎にエンジニアが対象の品質データを規定して、該データに関する解析手法をシステム化していた。その結果、製品トータルでの品質改善には、それら工程毎の解析手法、システムの使い分け、組み合わせが必要となり、現状では、エンジニアの思考、判断によりそれら使い分けや組み合わせが行われている。

また、品質改善のための技術として、部分的なデータ解析の自動化や装置レシピの最適化、知識蓄積のシステムなどが開示されている（例えば特許文献１〜３参照）。
特許文献１に開示されているデータ解析システムでは、検査異常に伴う一連のデータ（分析データ、装置メンテナンスデータ）が日付を基準に抽出されている。このシステムは、あくまで欠陥検査の分野に限られ、尚且つデータを抽出する機能のみで、抽出データの活用や解析考察などはシステム化されていない。従って、データの活用や解析考察についてはエンジニアの思考・判断に委ねられている。

また、特許文献２に開示されている自動品質制御装置では、装置の処理条件と処理結果とが収集され、シミュレーションによりシステムで最適な処理条件がコントロールされる。この装置では、１つの工程の中でその結果と製造条件との関連性から条件の最適化が図られるものであり、最終的な製品性能、製品試験に基づく品質改善を行うものではなく、その品質改善には、エンジニアの思考、判断が必要となる。

さらに、特許文献３に開示されている知識処理システムは、知識の整理に特化したシステムであり、既存登録知識に対して新しい知識を付加する際のアルゴリズムに関するもので、エンジニアの解析や思考をシステム化するものではない。

また、既存技術としてエンジニア個別の解析フローをマクロ化する技術がある。この技術により、データ抽出や加工、グラフ化などの作業ステップを部品化し、それを組み合わせるシステムが実現されている。しかし、該システムにおけるフローの形成はユーザに委ねられ、エキスパートが作成した各フローの２次活用に止まっている。
特開平５−３５７４５号公報 特開２００２−１４９２２１号公報 特開平５−１４３３４２号公報

従来では、製造工程で取得された情報（品質データ）を管理する管理系システムとエンジニアによる品質改善に沿ってデータ解析を行う情報処理システムとは互いに独立し、且つ情報処理システムについても、欠陥データの解析、歩留まり解析など、解析の目的別にシステム機能が細かく分散している。つまり、品質改善を行う際のエンジニアの思考に沿ったワークフローを実現するシステムは提唱されておらず、使う側の作業に依存したシステムしか存在していないのが現状であり、結果的にシステムの利用は、単なる作業支援の範囲に止まっていた。

また、品質改善に関するエンジニアの経験知識を蓄積するシステムとしては、トラブルの履歴や技術レポートなどを電子化してデータベースで管理するものがある。そして、エンジニアの経験知識を有効的に活用するには、キーワード検索技術の利用、すなわち、利用者側の操作が必要となり、このシステムも作業支援の範囲に止まっていた。

本発明は上記問題点を解決するためになされたものであって、その目的は、品質改善に伴うエンジニアの解析手法をシステム化して、エンジニアによる解析作業の効率を向上することができる品質改善システムを提供することにある。

本発明の特徴によれば、知識活用処理装置の記憶手段には、解析手順の情報（定義ファイル）が蓄積され、データ加工装置において、その解析手順に従い外部データベースから所定のデータが取得されてデータ解析が行われる。また、データ加工装置の解析結果に対して、入力手段から入力されたリファレンス情報が付加され知識活用処理装置の記憶手段に蓄積される。そのリファレンス情報によって重要度が判断され、その重要度に応じて解析手順の情報が記憶手段から抽出され、その情報を利用して解析が行われる。このようにすれば、別々の外部データベースで管理される品質データを使用して、エンジニアの思考に沿った解析処理を自動で行うことができる。また、過去にエンジニアが行った解析手順や解析結果のコメントをエンジニアのノウハウとして記憶手段に蓄積することができ、重要度の高い解析手順を別のエンジニアが容易に利用することができる。このように、品質改善の手法をシステム化することで、エンジニアの解析作業の効率化を図ることができる。

本発明によれば、エンジニアの解析業務の効率を向上することができる品質改善システムを提供することができる。

以下、本発明を具体化した一実施形態を図面に従って説明する。
図１には本実施形態の品質改善システム１１の概略構成図を示している。
品質改善システム１１は、ナレッジサーバ１２とアプリケーションサーバ１３とから構成される。ナレッジサーバ１２は、Ｗｅｂ／ＡＰＰサーバとして機能するコンピュータであり、エンジニアによって操作されるクライアントサーバ１４とネットワーク（例えば、インターネット）を介して接続されている。

ナレッジサーバ１２は、ナレッジデータベース（ＤＢ）１５とリポジトリデータベース（ＤＢ）１６とを含む。また、ナレッジサーバ１２は、ＩＩＳ（Internet Information Server）としての機能を持ち、Ｗｅｂアプリケーションを動作させることで、ＡＳＰ形式のＷｅｂページを生成したり、ＣＳＶ形成のデータを生成したりする。そして、クライアントサーバ１４からＷｅｂページにアクセスすることで、レポートの閲覧、レポートの作成条件の入力、レポートの作成要求などを実行することができるように構成されている。

アプリケーションサーバ１３には、解析プログラムやトラブル対応プログラムが組み込まれており、それらのプログラムに従って品質改善に関する各種処理が実行される。アプリケーションサーバ１３のプログラムは、エンジニアによるレポートの作成要求に応じてその都度起動されたり、ナレッジサーバ１２のタスクマネージャによって定期的に起動されたりする。この起動に伴い、ナレッジサーバ１２のリポジトリＤＢ１６からレポート作成情報が取り込まれる。そして、外部データベース（ＤＢ）１８から処理対象のデータが取得された後、品質改善のためのレポートが作成される。アプリケーションサーバ１３で作成されたレポートは、ナレッジＤＢ１５に蓄積される。またこのとき、レポートの作成情報がリポジトリＤＢ１６に登録される。

品質改善システム１１に接続される外部ＤＢ１８としては、工程管理ＤＢ１８ａ、試験管理ＤＢ１８ｂ、欠陥管理ＤＢ１８ｃ、異常連絡ＤＢ１８ｄ、装置保守ＤＢ１８ｅなどがある。それらＤＢには、データを収集するための管理システム（工程管理システム２１、試験管理システム２２、欠陥管理システム２３、異常連絡システム２４、装置保守システム２５）が接続されている。

具体的には、工程管理システム２１において、工程管理業務に従事するオペレータは、上限値と下限値とで設定される所定範囲内で管理データが推移していることをチェックする。試験管理システム２２において、試験管理業務に従事するオペレータは、ウェハに形成される複数チップの不良率などを監視する。欠陥管理システム２３において、欠陥管理業務に従事するオペレータは、ウェハの各チップに形成される回路パターンのレイアウトを確認し、チップ内における欠陥の有無や、欠陥数や欠陥モードを管理する。異常連絡システム２４において、工程処理における装置トラブルや工程トラブル（温度異常やウェハ割れなどの異常）によって装置が停止、又は異常動作した場合に、オペレータは、それに対するコメントの入力などを行う。装置保守システム２５において、オペレータは、装置の定期点検でのトラブルや突発性のトラブルの発生を監視する。

各システム２１〜２５においてトラブルやアラームなどの異常が発生した場合、それぞれの業務を担当しているオペレータからエンジニアにその異常が通知される。このとき、エンジニアは、クライアントサーバ１４を操作して品質改善システム１１にアクセスし、そのトラブルに対する処置を行う。その際に、エンジニアによる品質改善の手法がナレッジＤＢ１５に蓄積される。

図２はナレッジサーバ１２及びアプリケーションサーバ１３の各機能を示す概念図である。
ナレッジサーバ１２は、解析種類やテクノロジ毎にシステムユーザを分類してグループ管理する機能１２ａを持ち、自己学習でナレッジデータベース（ＤＢ）１５を構築する。具体的に、ナレッジサーバ１２は、解析ための条件入力の受付、解析結果の公開、解析結果に対するコメント入力などをグループ毎に管理して、アプリケーションサーバでの処理結果やエンジニアによるコメントなどをナレッジＤＢ１５に蓄積することにより、解析手法やトラブル対応の手法を自己学習する。

アプリケーションサーバ１３には、複数の外部データベース（ＤＢ）１８が接続される。各データベース１８は、工程履歴、工程管理、装置履歴、装置管理、欠陥管理、特性管理、試験管理に関する数値データを格納する数値系データベースと、異常連絡、条件指示、実験管理、解析コメント、イメージ管理に関するデータ（文書データやイメージデータなど）を格納するイベント系データベースとに区分される。

アプリケーションサーバ１３は、各データベース１８からデータを取得して、データソース連携処理、ＳＰＣ（統計的プロセスコントロール）アラーム監視処理、データ解析処理、トラブル対応処理、データ検索処理といった各種処理を実行する機能１３ａ〜１３ｅを持つ。

具体的に、機能１３ａのデータソース連携処理では、データの抽出及び加工処理が行われる。機能１３ｂのＳＰＣアラーム監視処理では、インプロセスにおける製造パラメータ（厚さ、長さ、抵抗などのパラメータ）、電流や電圧特性などの特性、回路動作の試験結果が所定の規格値の範囲内であるか否かが監視される。機能１３ｃのデータ解析処理では、ユーザによる条件入力に応じた解析処理が行われる。機能１３ｄのトラブル対応処理では、ＳＰＣアラーム監視処理で異常判定されたトラブルに対する処理が実行される。機能１３ｅのデータ検索処理では、前記データ解析処理やトラブル対応処理に必要となるデータが検索される。そして、このアプリケーションサーバ１３における処理結果がナレッジサーバ１２のナレッジデータベース１５に蓄積される。

図３は、ナレッジサーバ１２におけるリポジトリ機能の説明図である。
本実施形態の品質改善システム１１では、Ｗｅｂ上のユーザインターフェース３０により、グラフ表示及びコメント入力の設定機能（ｃｏｎｆｉｇ機能）３１とデータ条件（データ抽出と加工）の設定機能（ｃｏｎｆｉｇ機能）３２とが提供される。また、本システム１１では、トレンド図、相関図、管理図などの各種の解析機能ａ〜ｚのテンプレート３３が用意されており、グラフ表示の設定機能により、どのテンプレート３３を使って解析を行うのかが設定される。

具体的には、エンジニアがクライアントサーバ１４を操作して、Ｗｅｂ上にて提供される各設定画面にアクセスし、解析条件の入力や結果コメントなどの入力を一括に行う。その際、各設定画面で入力された各データが、解析手順を示す定義ファイル（ｃｏｎｆｉｇファイル）としてリポジトリＤＢ１６に蓄積される。

また、リポジトリＤＢ１６は、各ｃｏｎｆｉｇ機能３１，３２をテクノロジ毎にグループ管理している。すなわち、リポジトリＤＢ１６では、解析条件を入力したエンジニアの情報とその解析結果とコメントとをテクノロジのグループ毎に管理している。

詳しくは、解析手順のｃｏｎｆｉｇファイルを作成したエンジニア（作成者）によって、解析結果に対してコメントが入力される。その後、そのエンジニアとは別の同一グループのエンジニア（意見者）は、そのｃｏｎｆｉｇファイルを２次利用することができるとともに、解析結果に対してコメントを重ねて追記することができる。またこのｃｏｎｆｉｇファイルの利用については、リポジトリ技術によるユーザ管理が設けられ、解析結果のコメントについて、ｃｏｎｆｉｇファイルの作成者と意見者とを分けて管理され、作成者であるエンジニアの知見に対して、他の複数のエンジニアによる知見が連なる形で管理される。さらに、リポジトリＤＢ１６では、入力されたコメントについて、単語に自動分解され、単語の使用頻度や、コメント追記の順番（各コメントの関連付け）とが管理される。

このように、本実施形態では、上述した２つのｃｏｎｆｉｇ機能３１，３２によって、エンジニアは個々の解析目的に沿った任意のワークフロー（解析手順）を定義し、解析結果の公開と関連部門のエンジニアからの複数の所見を集めることが可能となる。

次に、データ条件設定のｃｏｎｆｉｇ機能３２を用いてワークフロー（解析手順）を作成する方法について説明する。
図４に示すように、本実施形態では、各設定画面３５ａ〜３５ｅがドリルダウン方式で表示され、各設定画面で各種の解析条件が設定され、それに応じた解析手順が定義リスト（ｃｏｎｆｉｇ ｌｉｓｔ）に登録される。

具体的に、エンジニアは、クライアントサーバ１４を操作して、Ｗｅｂ上に掲載されている解析グループのページにアクセスし、予め決められたユーザアカウントでログインする。その後、各設定画面３５ａ〜３５ｅにおいて、解析グループの選択、解析データの選択、データ結合＆加工の選択、加工詳細条件の選択が行われる。その結果、選択情報に対応する解析手順がユーザ別にリスト表示される。

このように、解析条件の設定画面３５ａ〜３５ｅをドリルダウンで順次表示させるナビゲート機能により、解析手順の情報を含む定義ファイル（ｃｏｎｆｉｇファイル）が作成され、リポジトリＤＢ１６に蓄積される。この定義ファイルは、条件設定の入力情報と解析目的のコメントの情報を含み、アプリケーションサーバ１３では、その定義ファイルの解析条件に従って、所定の解析処理が実施される。

また、図５に示すように、定義リスト（ｃｏｎｆｉｇ ｌｉｓｔ）Ｌ１に登録されている所定の解析手順を選択すると、それに対応する解析結果リストＬ２が表示される。この解析結果リストＬ２には、解析手順の登録時にエンジニア（作業者）が入力した解析目的のコメントが記載されている。また、この解析結果リストＬ２とは別の画面で解析グラフが表示され、それを見た関連部門の複数のエンジニアにより解析結果が判断される。そして、解析結果リストＬ２には、作成書とは別のエンジニアによるコメントが書き込まれる。ここで、他のエンジニアによるコメントの書き込み頻度により、その解析の定義ファイルの重要度が判断されて、各定義ファイルの優先付けが行われる。

このように、本実施形態の品質改善システム１１では、一人のエンジニアによる解析結果のコメントに対して、関連する複数のエンジニアのコメント（所見・意見）を連ねることができる。そして、コメントの書き込み頻度から自己学習でナレッジＤＢ１５が構築され、ニューラルネットワークとシナプスと同様の効果を得ることが可能となる。また、ナレッジＤＢ１５において、コメントの書き込み頻度以外に、書き込み順（関連付け）を管理することで、複数のエンジニアの思考による関連付けに応じて、解析手順の定義ファイルの検索が可能になる。また、解析結果の有効性に関する情報として、コメント中に得点付けを行うようにし、それを管理することで、解析手順の定義ファイルをリスト表示する際の優先付けが行われる。

次に、本実施形態における品質改善システム１１の動作について図６及び図７を用いて説明する。
先ず、図６の解析処理について説明する。なお、この処理は、エンジニアがクライアントサーバ１４を操作して、Ｗｅｂ上に掲載されているシステム１１のメインメニューにアクセスし、データ解析の項目を選択したときに開始される。

ステップ１００において、ナレッジサーバ１２は、エンジニアによりナビゲート機能が選択されたか否かを判定し、ナビゲート機能が選択された場合は、ステップ１１０に移行する。ここで、ナレッジサーバ１２は、所定のページデータを送信し、クライアントサーバ１４に解析条件の設定画面を表示させる（図４参照）。ナレッジサーバ１２は、その設定画面で設定された解析条件の各項目（品種、データの種類、単位など）のデータを取り込む。続く、ステップ１２０において、ナレッジサーバ１２は、所定のページデータを送信し、クライアントサーバ１４に解析目的のコメント入力のための入力画面を表示させ、その入力画面にて入力された目的（文書データ）を取り込む。

その後、ステップ１３０において、ナレッジサーバ１２は、ナレッジＤＢ１５に蓄積されている複数の定義ファイル（ｃｏｎｆｉｇファイル）について、前記設定条件と目的とに一致するファイルをチェックし、そのチェック結果と使用頻度と解析結果から所定のｃｏｎｆｉｇファイルを自動選択する。

ステップ１４０において、ナレッジサーバ１２は、選択したｃｏｎｆｉｇファイルに対応する解析プログラムをアプリケーションサーバ１３に実行させ、その解析結果を取得する。そして、ナレッジサーバ１２は、その解析結果をナレッジＤＢ１５に蓄積するとともに、解析結果のグラフと目的のコメントを含むレポートをＷｅｂ上に公開する。

このレポートを見たエンジニアが解析結果の有効性を判断して、その有効性に関するデータをクライアントサーバ１４から入力する。ステップ１５０において、ナレッジサーバ１２は、その有効性に関するデータを取得して、解析結果が有効であるか否かを判断する。そして、ナレッジサーバ１２は、解析結果が有効であると判断した場合にはステップ１６０に移行して、所定のページデータを送信し、クライアントサーバ１４にコメント入力のための入力画面を表示させ、その入力画面で入力された作成者のコメントを取り込み、ナレッジＤＢ１５に蓄積する。また、ナレッジサーバ１２は、ステップ１７０において、入力された他のエンジニアのコメントを取り込み、ナレッジＤＢ１５に蓄積した後、本処理を終了する。

ステップ１００にてナビゲート機能が選択されなかった場合、ステップ１５０にて解析結果が有効でないと判断した場合に、ナレッジサーバ１２はステップ１８０に移行する。ここで、ナレッジサーバ１２は、クライアントサーバ１４に解析条件の設定画面を表示させ、その設定画面で設定された解析条件の各項目（品種、データの種類、単位など）のデータを取り込む。続く、ステップ１９０において、ナレッジサーバ１２は、クライアントサーバ１４にて解析目的のコメント入力のための入力画面を表示させ、その入力画面で入力された目的を取り込む。その後、ステップ２００において、ナレッジサーバ１２は、ナレッジＤＢ１５における過去のＣｏｎｆｉｇファイルをチェックするか否かを判定する。ここで、設定条件や目的に対応するＣｏｎｆｉｇファイルがある場合には、過去の使用頻度、解析効果が大きかったｃｏｎｆｉｇファイルをリストアップした後、ステップ２１０に移行する。なおここで、各ファイルは、過去の使用頻度、効果大などの重要度に応じた順次でリストアップされる。

そして、エンジニアがクライアントサーバ１４を操作して、リストアップされたｃｏｎｆｉｇファイルのいずれかを選択すると、ナレッジサーバ１２は、ステップ２２０に移行して、選択されたｃｏｎｆｉｇファイルに対応する解析プログラムをアプリケーションサーバ１３に実行させ、解析結果を取得する。ナレッジサーバ１２は、この解析結果をナレッジＤＢ１５に蓄積するとともに、解析結果のグラフと目的のコメントを含むレポートをＷｅｂ上に公開する。

続くステップ２３０において、ナレッジサーバ１２は、有効性に関するデータを取得して、解析結果が有効であるか否かを判断する。そして、ナレッジサーバ１２は、解析結果が有効であると判断した場合にはステップ１６０に移行する。一方、解析結果が有効でないと判断した場合には、ステップ１８０に戻り、ステップ１８０以降の処理を再度実行する。

また、ステップ２００にて設定条件や目的に対応するＣｏｎｆｉｇファイルがないと判断した場合、ステップ２１０にてリストアップされたファイルを使用しないと判断した場合、ナレッジサーバ１２はステップ２４０に移行して、その設定条件や目的に対応する新規のＣｏｎｆｉｇファイルとしてナレッジＤＢ１５に登録する。また、ステップ２５０では、リポジトリ機能により、Ｃｏｎｆｉｇファイルの情報が整理される。つまり、Ｃｏｎｆｉｇファイルの設定条件や目的のコメントについて、エンジニアのグループ毎に整理される。その後、ナレッジサーバ１２はステップ２２０に移行して、解析結果の出力とＷｅｂ公開のための処理を実行した後、ステップ２３０以降の処理を同様に行う。

次に、図７のトラブル対応処理について説明する。なお、この処理は、半導体製造工程での異常（アラーム）の発生時に、オペレータがシステム１１のメインメニューにアクセスし、トラブル対応の項目を選択した場合に開始される。

先ず、ステップ３００において、ナレッジサーバ１２は、所定のページデータを送信し、クライアントサーバ１４に目的（トラブルがあった工程名、装置名、トラブル状況など）の入力画面を表示させ、その入力画面で入力された目的を取り込む。続く、ステップ３１０において、ナレッジサーバ１２は、その目的の入力情報の中からキーワードの切り出し（文節分けや単語化）を行う。

その後、ステップ３２０に移行して、ナレッジサーバ１２は、ナレッジＤＢ１５を参照し、キーワードに対応する過去事例のうちの対処結果が成功であった過去事例の有無をチェックする。ここで、成功した過去事例がないと判断した場合、ナレッジサーバ１２は、ステップ３３０に移行して、エンジニアにトラブル対応の指示を要求するためのメールを配信しエンジニアを呼び出す。そのエンジニアにより、新規トラブルの対処方法がナレッジサーバ１２に入力される。ナレッジサーバ１２は、ステップ３４０において、入力された対処方法を工場のオペレータ（工場のシステム端末）に通知する。オペレータは、通知された対処方法に従ってトラブルを解消するための処置を行った後、指示された対処方法でトラブルが解消されたか否かといった対処結果を入力する。

ステップ３５０において、ナレッジサーバ１２は、入力された新規のトラブル内容、対処方法、対処結果といった対処情報を過去事例としてナレッジＤＢ１５に蓄積する。また、ステップ３６０において、ナレッジサーバ１２は、他のエンジニアが入力したコメントを取り込み、新規トラブルに関するコメントとして対処情報に追記した後、本処理を終了する。

また、ステップ３２０において、過去事例があると判断した場合は、ナレッジサーバ１２は、ナレッジＤＢ１５から対処情報の候補を抽出（ピックアップ）する。その後、ステップ３７０に移行して、その対処候補のいずれかをオペレータが選択したか否かを判定する。ここで、リスト表示された対処候補の中から効果が大きい過去事例をオペレータが選択すると、ナレッジサーバ１２はステップ３８０に移行して、選択された過去事例の対処方法を指示し、オペレータにより工程や装置への対処を実施させる。

その後、オペレータにより、トラブルが解消されたか否かといった対処結果やコメントが入力される。そして、ステップ３９０にて、ナレッジサーバ１２は、それら対処結果やコメントをナレッジＤＢ１５に蓄積する。

また、ナレッジサーバ１２は、ステップ４００において、オペレータにより入力された対処結果がＯＫ（成功）であるか否かを判定し、ＯＫである場合、ステップ４１０に移行する。そして、Ｗｅｂ上でトラブルの対処結果を確認したエンジニアによるコメントを取り込み、そのコメントをトラブルの対処情報としてナレッジＤＢ１５に蓄積する。これにより、トラブル対応に関する経験が強化されたかたちでナレッジＤＢ１５が構築される。

また、ステップ３７０にて過去事例を選択しないと判断した場合、ステップ４００にて対処結果がＮＧであると判定した場合、ナレッジサーバ１２はステップ４２０に移行する。そして、ナレッジサーバ１２は、エンジニアにトラブル対応の指示を要求するためのメールを配信しエンジニアを呼び出す。

このとき、ナレッジサーバ１２は、過去事例の対処候補をリスト表示して、該対処候補をエンジニアにチェックさせる（対処内容の適用を検討させる）。なおここで、対処候補は、過去の使用頻度、効果大などの重要度に応じた順次でリストアップされる。そして、エンジニアが対処候補のいずれかを選択すると、ナレッジサーバ１２は、ステップ４３０において対処候補の選択有りと判断してステップ４４０に移行する。

そして、ステップ４４０では、選択された対処方法を工場のオペレータ（システム端末）に通知し、オペレータにその対処方法に従って工程、装置への対処を実施させる。その後、オペレータにより、トラブルが解消されたか否かといった対処結果やコメントが入力される。ステップ４５０にて、ナレッジサーバ１２は、それら対処結果やコメントをナレッジＤＢ１５に蓄積するとともに、ステップ４６０に移行して、対処結果がＯＫ（成功）であるか否かを判定する。ここで、対処結果がＯＫである場合、ナレッジサーバ１２は、ステップ４７０に移行して、トラブルの対処結果を確認した他のエンジニアによるコメントを取り込み、そのコメントをトラブルの対処情報としてナレッジＤＢ１５に蓄積した後、本処理を終了する。

一方、ステップ４３０にて対処候補が選択されなかった場合、ステップ４６０にて対処結果がＮＧであった場合は、ナレッジサーバ１２は、ステップ４８０に移行する。ここでは、エンジニアによって、新規トラブルの対処方法がナレッジサーバ１２に入力される。そして、ナレッジサーバ１２は、入力された対処方法を工場のオペレータ（システム端末）に通知する。オペレータは、通知された対処方法に従ってトラブルを解消するための処置を行った後、トラブルが解消されたか否かといった対処結果を入力する。

ナレッジサーバ１２は、ステップ４９０において、新規トラブルの内容、対処方法、対処結果といった対処情報をナレッジＤＢ１５に蓄積する。また、ステップ５００において、ナレッジサーバ１２は、新規トラブルの対処結果を確認したエンジニアによるコメントを取り込み、新規トラブルに関するコメントとしてナレッジＤＢ１５に蓄積した後本処理を終了する。

次に、ナレッジＤＢ１５での学習機能について説明する。図８は従来のナレッジシステムを示す説明図であり、図９は本実施形態のナレッジシステムを示す説明図である。
図８に示すように、従来のナレッジシステムでは、個々の解析結果について、エンジニアが入力端末（クライアントサーバ１４）を操作して個別にコメントを入力する。ナレッジサーバ１２は、各入力端末からの入力情報を、テクノロジ、解析テーマ、解析手法、結果に応じて分類し、キーワード化してデータベース１５に蓄積する。このデータベース１５への入力情報は、重み付けされることなく、コメントの入力順番に基づいて並列に蓄積される。そして、このシステムでは、コメントに含まれるキーワードの出現頻度などに基づいて入力情報がデータベース１５から抽出される。

これに対し、本実施形態のナレッジシステムでは、図９に示すように、エンジニアが第１の入力端末を操作してコメントを入力した解析結果に対して、第２の入力装置から別のエンジニアによりコメントが追加される。ナレッジサーバ１２は、各入力端末からの入力情報を、テクノロジ、解析テーマ、解析手法、結果に応じて分類し、キーワード化してデータベース１５に蓄積する。この場合、複数のエンジニアの知見によるコメントが入力情報として付加され、重要性の重み付けされた情報としてデータベース１５に優先的に（ランク付けされて）登録される。そして、このシステムにおいて、重み有（エンジニアによる意識付け有）の情報は、刺激された情報として管理され、その情報が優先的に抽出される。このようにすれば、複数のエンジニアの思考により入力情報の関連付けがなされ、その関連付けによって、キーワードによって各情報を分類する前にその情報の重要度が事前に学習される。この関連付けの処理を繰り返すことで、複数のエンジニアの知見からコメントのランク付けを成熟させ、システムのナレッジ化が実現される。

次に、欠陥検査工程でのアラームの要因調査を行う場合のエンジニアの思考フローについて図１０を用いて説明する。ここで、エンジニアは、欠陥検査工程におけるＤｅｆｅｃｔカウント数（欠陥個数）と工程処理履歴との相関性を解析する。

半導体製造工程では、複数枚（例えば１０枚）のウェハを１ロットとし、所定の処理装置での処理結果がロット単位で管理される。また、欠陥検査工程では、ウェハに形成される複数チップについての欠陥個数がウェハ毎にカウントされる。従って、Ｄｅｆｅｃｔカウント数（欠陥個数）と工程処理履歴との相関解析をする場合には、それぞれ異なる単位のデータを結合して解析を行う。

具体的に、エンジニアは、先ず、欠陥検査工程におけるウェハ単位でのデータ推移をチェックする（ステップ６００）。そして、ウェハ単位のＤｅｆｅｃｔカウント数とロット単位の工程処理履歴とをロット番号（ＬＯＴＮＯ）をキーに結合する（ステップ６１０）。またこの場合、データ結合の際の基準を、データ単位が小さいウェハ単位とし、そのウェハ単位でＤｅｆｅｃｔカウント数を扱う。つまり、Ｄｅｆｅｃｔカウント数として、ロット毎の合計値を求める（ロットサマリを行う）のではなく、ウェハ単位のカウント数とする（ステップ６２０）。この解析時において、ロット単位での合計値としてウェハ毎のＤｅｆｅｃｔカウント数がまるめられてしまうと、そのウェハ単位でのデータ推移が判断できなくなる。本実施形態では、Ｄｅｆｅｃｔカウント数がウェハ単位で扱われることにより、ウェハ単位での欠陥傾向が確認される。

図１１にはそのデータ結合結果の一例を示す。図１１において、所定ロット（ロット番号ＬＯＴＮＯ＝ａａａａａａａ−ａａ）に関する処理日、処理工程、処理装置、検査工程が、ウェハ番号ＷＦＮＯ＝２０，５毎に記載されるとともに、欠陥検査結果として、各ウェハのＤｅｆｅｃｔカウント数が記載される。

次に、本実施形態の品質改善システム１１におけるデータ結合処理について図１２を用いて説明する。
先ず、ナレッジサーバ１２は、ステップ６５０において、クライアントサーバ１４に所定のページデータを送信し、欠陥解析のためのメニュー画面を表示させる。ここで、エンジニアは、そのメニュー画面における処理履歴と相関解析の項目を選択する。

ステップ６６０において、ナレッジサーバ１２は、その相関解析のための条件設定画面を表示させ、その設定画面でエンジニアが設定した各種の解析条件（検査工程、処理工程など）に対応する設定データを取り込む。

ステップ６７０において、ナレッジサーバ１２は、設定データをアプリケーションサーバ１３に通知し、該サーバ１３にて設定条件に対応する解析プログラムを起動させる。この解析プログラムにより、欠陥検査工程におけるウェハ単位でのデータ推移がチェックされ、ウェハ単位のＤｅｆｅｃｔカウント数とロット単位の工程処理履歴とがロット番号（ＬＯＴＮＯ）をキーに結合される。

より詳しくは、アプリケーションサーバ１３は、解析対象となるデータについて、工程、装置、レシピ、ウェハ（ＷＦ）構成情報といった各種情報を読み取り、それら情報に基づいて、解析のデータ単位を自動判断する。すなわち、図１３に示すように、アプリケーションサーバ１３は、欠陥解析のデータ条件として、処理工程＝工程Ａ、処理装置＝ＳＯＵＩＴ１、レシピ＝検査レシピ１、ＷＦ構成情報＝ｗｆｎｏ１検査を読み取る（ステップ７１０）。そして、アプリケーションサーバ１３は、その欠陥データの条件からデータ単位をＷＦ単位と判断する。またこのとき、アプリケーションサーバ１３は、データ種からサマリ（集計）無しと判断する（ステップ７２０）。

また、アプリケーションサーバ１３は、処理履歴のデータ条件として、処理工程＝工程Ｂ、処理装置＝ＳＯＵＩＴ２、レシピ＝処理レシピ１、ＷＦ構成情報＝全数処理を読み取る（ステップ７３０）。そして、アプリケーションサーバ１３は、その履歴データの条件からデータ単位をロット（ＬＯＴ）単位と判断する（ステップ７４０）。その後、アプリケーションサーバ１３は、ステップ７２０とステップ７４０との判断結果に基づいて、データ単位の基準をウェハ（ＷＦ）単位に合わせて結合する（ステップ７５０）。

このように、データ結合を行うことにより、図１４の解析グラフを表示するためのレポートデータが作成される。なお、この解析グラフでは、処理装置別のＤｅｆｅｃｔカウント数が工程処理順に表示されるため、処理履歴に応じたＤｅｆｅｃｔカウント数のトレンドを確認できる。

図１２の説明に戻り、ナレッジサーバ１２は、ステップ６８０において、解析グラフやコメントを含む解析結果のレポートデータをアプリケーションサーバ１３から取得し、ナレッジＤＢ１５に蓄積する。また、ナレッジサーバ１２は、そのレポートデータに基づいて解析グラフやコメントを含むレポートをＷｅｂ上で公開する。さらに、ナレッジサーバ１２は、その解析に用いた解析データ（Ｄｅｆｅｃｔカウント数や処理履歴のデータなど）をユーザの要望に応じてクライアントサーバ１４側に提供したり、必要なレポートをプリンタから印刷したりする。

このように、本実施形態の品質改善システム１１では、別の外部ＤＢ１８で管理される複数工程の品質データについて、抽出・加工するデータとして処理工程と検査工程との工程名を指定することで、任意の処理工程における装置別、処理順のトレンドフラグが作成される。

なお、図１４の解析グラフでは、縦軸にＤｅｆｅｃｔカウント数をとるものであったが、ステップ６６０の解析条件において、Ｄｅｆｅｃｔカウント数に代えて、歩留まり、モニタ特性、装置点検結果、工程管理など製造履歴で発生する技術データ項目を設定することにより、解析グラフの縦軸をそれらに切り替えて表示させることができる。

次に、欠陥検査工程でのアラームの要因調査において、３項目のデータ（上述したＤｅｆｅｃｔカウント数と工程処理履歴のデータに加え、メンテナンスデータ）の相関性を解析する場合の思考フローについて図１５を用いて説明する。

エンジニアは、先ず、欠陥検査工程におけるウェハ単位でのデータ推移、ロット単位での工程処理履歴、処理装置及び処理日単位での保守履歴をチェックする（ステップ８００）。

図１６に示すように、欠陥データ（Ｄｅｆｅｃｔカウント数）は、ロット番号（ＬＯＴＮＯ）、ウェハ番号（ＷＦＮＯ）、検査装置、検査レシピ、検査工程、検査日を軸として、欠陥管理ＤＢ１８ｃで管理されている。また、ロット単位の工程処理履歴（ＬＯＴ履歴）は、ロット番号（ＬＯＴＮＯ）、ウェハ番号（ＷＦＮＯ）、処理装置、処理レシピ、処理工程、処理日を軸として、工程管理ＤＢ１８ａで管理されている。さらに、装置の保守履歴は、処理装置、処理日、保守イベントを軸として装置保守ＤＢ１８ｅで管理されている。

そのため、ウェハ単位のＤｅｆｅｃｔカウント数（欠陥データ）とロット単位の処理履歴（ＬＯＴ履歴）とをロット番号（ＬＯＴＮＯ）をキーに結合する（ステップ８１０）。またこの場合、データ結合の際の基準をウェハ単位とし、Ｄｅｆｅｃｔカウント数は、ロット毎の合計値（ロットサマリ）を求めるのではなく、ウェハ単位のカウント数とする（ステップ８２０）。

さらに、処理装置毎に、処理日を基準にメンテナンスデータ（保守履歴）を結合する（ステップ８３０）。この場合も、データ結合の際の基準をウェハ単位とし、Ｄｅｆｅｃｔカウント数は、ロット毎の合計値を求めるのではなく、ウェハ単位のカウント数とする（ステップ８４０）。

図１７にはそのデータ結合結果の一例を示す。図１７において、所定ロット（ロット番号ＬＯＴＮＯ＝ａａａａａａａ−ａａ）に関する処理日、処理工程、処理装置が、ウェハ番号ＷＦＮＯ＝２０，５毎に記載されるとともに、欠陥検査結果として、各ウェハのＤｅｆｅｃｔカウント数が記載される。さらに、処理装置のメンテナンス情報が記載される。

本実施形態の品質改善システム１１では、上述した３項目のデータ（Ｄｅｆｅｃｔカウント数、工程処理履歴、及び保守履歴）の相関解析をするために、図１２の解析処理と同様の処理（ステップ６５０〜ステップ６８０の処理）が実施される。但し、ステップ６５０にて、解析条件の設定項目として保守履歴が追加され、ステップ６７０では、それに応じた解析プログラムをアプリケーションサーバ１３に起動させる。

具体的には、アプリケーションサーバ１３は、図１８に示すように、検査工程と処理工程とを指定し、ウェハ単位のＤｅｆｅｃｔカウント数とロット単位の工程処理履歴とをロット番号（ＬＯＴＮＯ）をキーに結合する（ステップ８５０）。その後、アプリケーションサーバ１３は、処理装置と処理日とを検索し、その処理装置と処理日のデータをキーにロット単位のメンテナンスデータ（保守履歴）を結合する（ステップ８６０）。

その結果、図１９の解析グラフを表示するためのレポートデータが作成される。なお、この解析グラフでは、処理装置別のＤｅｆｅｃｔカウント数が工程処理順に表示されるため、処理履歴に応じたＤｅｆｅｃｔカウント数のトレンドを確認できる。さらに、処理日と処理装置のメンテナンス情報とが同期して表示される。これにより、保守履歴（メンテナンス情報）に対応した欠陥データのトレンドを確認することが可能となる。なお、図１９の解析グラフにおいても、縦軸のＤｅｆｅｃｔカウント数に代えて、歩留まり、モニタ特性、装置点検結果、工程管理など製造履歴で発生する技術データに切り替えて表示させることができる。

因みに、従来システムでは、図２０に示すように、検査処理順と欠陥データとの関係を示すトレンドグラフと、ロットの処理履歴の帳票と、装置の保守履歴の帳票を、それぞれの管理システムで個別に出力する。そして、エンジニアがそれら１つのグラフと２つ帳票を確認し、それらをエンジニアの思考で合成することで、品質改善のための解析を行うようにしていた。これに対し、本実施形態の品質改善システムでは、図２１に示すように、欠陥検査データ、ロットの処理履歴、装置の保守履歴が１つのグラフで表示されるので、品質改善に関する考察を容易に行うことが可能となる。

図２２には、ロットの試験結果を示すための解析リストの一例を示す。具体的に、この解析リストとして、ロット番号（ＬＯＴＮＯ）＝ａａａａａ−ａａ、試験結果＝歩留まり２０％、異常連絡の工程＝ａａａ工程、欠陥検査分布＝ａａａ工程、ｂｂｂ工程が表示される。本実施形態の品質改善システム１１では、この解析リストの各項目から、試験結果グラフ、異常連絡表、写真イメージなどを連携抽出できるようにその手順がナレッジＤＢ１５に登録されている。

具体的には、解析リストの試験結果の項目が選択されると、試験結果のデータが試験管理ＤＢ１８ｂから抽出され、カテゴリ毎に集計した試験結果グラフ、ロット内のトレンドグラフ、ウェハ内の分布ＭＡＰなどが表示される。また、異常連絡の項目が選択されると、異常連絡に関するデータが異常連絡ＤＢ１８ｄから抽出され、欠陥検査の異常連絡表や、エンジニアのコメントを含むレポートが表示される。さらに、欠陥検査分布の項目が選択されると、ロットの欠陥情報が欠陥管理ＤＢ１８ｃから抽出され、欠陥ＭＡＰや欠陥写真のイメージ（画像のデータ）が表示される。このように、ナレッジＤＢ１５に登録された手順に従って、品質データに含まれる数値とグラフと画像のデータの中から任意のデータを選択して加工することができる。

以上記述したように、本実施の形態によれば、以下の効果を奏する。
（１）別々の外部ＤＢ１８で管理されている品質データを使用して、エンジニアの思考に沿った解析処理を自動で行うことができる。また、過去にエンジニアが行った解析手順や解析結果などのコメントをエンジニアのノウハウとしてナレッジＤＢ１５に蓄積することができる。そして、解析結果に付加されるコメント（リファレンス情報）の頻度と該コメントに含まれる単語の出現頻度や重要度に関するデータとに基づいて解析手順の情報が抽出される。従って、重要度の高い解析手順を別のエンジニアが容易に利用することができる。このように、品質改善の手法をシステム化することで、エンジニアのスキル差をなくし、エンジニアの解析作業の効率化を図ることができる。

（２）検査工程の欠陥データと、その検査工程とは別のデータベースで管理される処理工程の履歴データとを利用して品質データのトレンドグラフが作成される。この場合、処理工程を跨いだ相互関係を確認することができるため、検査異常の原因となった処理工程での挙動を的確に確認することができる。

（３）アプリケーションサーバ１３において、抽出・加工するデータのデータ単位が自動判断されて、データ単位が小さい方にそろえてデータが結合される。この場合、エンジニアの思考による判断手法と同様に、抽出・加工するデータの単位を決定することができ、データが丸められることなく詳細なデータ推移の検証が可能となる。また、品質データのトレンドグラフは、処理順、処理工程、処理装置のいずれかを基準として表示することができる。

（４）ドリルダウン方式の条件設定画面を用いて解析手順の情報を含む定義ファイルが作成されるので、該定義ファイルを容易に作成することができる。
（５）複数のエンジニアが重要と判断した解析結果に対しては、コメントが集中して書き込まれるため、コメントの積み重ね（頻度）の大きさやコメントの順番（関連付け）を管理することにより、解析結果の重要度を判断してナレッジＤＢ１５に蓄積することができる。また、結果内容の成功例と失敗例とを選別しながら解析結果をナレッジＤＢ１５に蓄積することができる。このため、コメントの頻度や効果が大きな結果に対応する処理手順を優先的にナレッジＤＢ１５から抽出することができる。このように、コメントの書き込み頻度、コメントの順番、結果内容を管理することにより、エンジニアの知見を集約させたナレッジＤＢを自己学習で構築することができる。

（６）本実施形態では、品質改善のための解析結果が目的別にナレッジＤＢ１５に蓄積され、品質改善のためのエンジニアのノウハウをナレッジ化することにより、該目的別に品質改善のための処理手順（解析手法やトラブル対応手法）をナビゲートすることができる。

（７）工程や装置のトラブルについて、過去事例がある既存のトラブルであれば、システム側が自動でそのトラブルに対する指示を行うことができる。また、新規のトラブルが発生した場合には、そのトラブルがエンジニアに通知されるので、エンジニアはトラブルが新規である場合に、そのトラブル対応に集中することができる。これにより、エンジニアの作業効率を向上することができ、ロットのリリースや処理装置のリリースを短時間で行うことが可能となる。その結果、エンジニアのリソース（解析時間や人員）を有効活用することができる。

（８）本実施形態の品質改善システム１１では、過去事例の解析処理やトラブル対応を経験則として確実に有効活用できるため、複数のエンジニアにて同じ解析の検討が２重に行われることを回避することができる。

尚、上記各実施の形態は、以下の態様で実施してもよい。
・図２３に示すように、解析結果の相関度合に基づいて、解析結果に対するコメント入力を行うようにしてもよい。具体的に、ナレッジサーバ１２は、ステップ９００において、解析結果のグラフにおけるＸ軸とＹ軸とのデータ間の相関係数が、所定値（例えば、０．３）よりも高いか否かを判断する。ここで、相関係数が所定値よりも高ければ、ステップ９１０に移行して、解析結果の相関性が高く重要度が大きい解析結果であると判断してエンジニアによるコメントの入力を要求する。一方、相関係数が所定値以下であれば、重要度が小さい解析結果である判断して、ステップ９１０の処理を迂回する。なお、相関係数以外の係数（例えば、相関係数を２乗して有られる決定係数）を用いて、解析結果の重要度を自動で判断して、エンジニアにコメントを要求するか否かを決定するように構成してもよい。

・図２４に示すように、解析対象のデータの大小関係に基づいて、解析結果のランク付けを行い、そのランクに応じてコメント欄を分けてコメントの要求を行うようにする。例えば、解析対象データが歩留まりである場合、歩留まりの高（＝７０％〜１００％）、中（＝４０％〜６０％）、小（＝０％〜３０％）で３ランクに分けてコメントを要求する。また、解析対象データが欠陥数である場合、欠陥個数の大（＝３０個以上）、中（＝１０個以上３０個未満）、小（＝１０個未満）で３ランクに分けてコメントを要求する。さらに、解析対象データがモニタ特性（しきい値電圧Ｖｔｈ）である場合、しきい値電圧Ｖｔｈの高（＝０．５Ｖ以上）、中（＝０．３Ｖ以上０．５Ｖ未満）、小（＝０．３Ｖ未満）で３ランクに分けてコメントを要求する。これらランク付けに応じて解析結果を管理し、過去の事例として利用する際に、ランク付けに基づいて、解析リストをリストアップする。このように構成すれば、ランク付けに応じた的確な解析結果を抽出することができ、実用上好ましいものとなる。

・上記実施形態では、データ結合を行う際のデータ単位の基準をウェハ単位としてが、それ以外に、Ｎ枚おきのチャンバ単位やバッチ（ＤＩＳＫ，炉）単位としてもよい。
上記実施形態から把握できる技術的思想を以下に記載する。
（付記１）半導体製造工程で取得された各種の品質データを蓄積する複数の外部データベースが接続され、該各品質データを用いて品質改善のための処理を行う品質改善システムにおいて、
解析手順の情報を記憶手段に蓄積する知識活用処理装置と、
前記解析手順に従い、前記外部データベースから所定のデータを取得してデータ解析を行うデータ加工装置と
を備え、
前記知識活用処理装置は、前記データ加工装置の解析結果に対して、入力手段から入力されたリファレンス情報を付加して記憶手段に蓄積する機能と、前記リファレンス情報により重要度を判断し、その重要度に応じて前記記憶手段から解析手順の情報を抽出する機能とを有することを特徴とする品質改善システム。
（付記２）前記知識活用処理装置は、前記解析結果に付加される前記リファレンス情報の頻度と該リファレンス情報に含まれる単語の出現頻度や重要度に関するデータとに基づいて、前記解析手順の情報を抽出することを特徴とする付記１に記載の品質改善システム。
（付記３）前記データ加工装置は、別の外部データベースで管理される複数工程の品質データについて、抽出・加工するデータとして処理工程と検査工程との工程名が指定されることにより、任意の処理工程における装置別、処理順のトレンドグラフを作成する機能を有することを特徴とする付記１又は２に記載の品質改善システム。
（付記４）前記データ加工装置は、前記抽出・加工するデータについて、データ単位を自動判断し、各データのうちでデータ単位が小さいデータを基準としてデータ結合することを特徴とする付記３に記載の品質改善システム。
（付記５）前記データ加工装置は、処理順、処理工程、処理装置のいずれかを基準とし、前記品質データのトレンドグラフを表示させるための機能を有することを特徴とする付記１に記載の品質改善システム。
（付記６）前記知識活用処理装置は、前記記憶手段に登録された手順に従って、前記品質データとしての数値とグラフと画像のデータの中から任意に選んで加工することを特徴とする付記１に記載の品質改善システム。
（付記７）前記入力手段は、ドリルダウン方式の条件設定画面を用いて前記解析手順の定義ファイルを作成することを特徴とする付記１に記載の品質改善システム。
（付記８）前記知識活用処理装置は、前記解析結果やトラブルの対応結果に対するコメントを前記記憶手段に蓄積し、そのコメントの頻度や効果が大きな結果に対応する処理手順を優先的に抽出するようにしたことを特徴とする付記１に記載の品質改善システム。
（付記９）前記知識活用処理装置は、前記解析結果に対するコメントの書き込み頻度、コメントの順番、コメントに含まれる結果内容を管理して蓄積することにより、前記記憶手段としてのナレッジデータベースを構築することを特徴とする付記１に記載の品質改善システム。
（付記１０）前記知識活用処理装置は、品質改善のための解析結果を目的別に前記ナレッジデータベースに蓄積し、該目的別に品質改善のための処理手順のナビゲートを行うことを特徴とする付記９に記載の品質改善システム。
（付記１１）前記知識活用処理装置の蓄積情報に基づいて、前記品質改善のための解析処理とトラブル対応処理とを自動で行うようにしたことを特徴とする付記１に記載の品質改善システム。
（付記１２）前記データ加工装置は、データの抽出・加工を行うためのプログラムを実行するアプリケーションサーバであり、
前記知識活用処理装置は、解析の条件入力と解析結果とをＷｅｂ上に公開し、その結果に対するコメントを蓄積して自己学習でデータベースを構築するナレッジサーバであることを特徴とする付記１に記載の品質改善システム。
（付記１３）前記ナレッジサーバは、前記データベースの蓄積情報について、解析の種類やテクノロジ毎にシステムユーザのグループ管理をする機能を有することを特徴とする付記１２に記載の品質改善システム。
（付記１４）前記ナレッジサーバは、前記リファレンス情報に含まれる単語の出現頻度と重要度に関するデータとを参照するリポジトリデータベースを含むことを特徴とする付記１２に記載の品質改善システム。
（付記１５）半導体製造工程で取得された各種の品質データを蓄積する複数の外部データベースが接続され、該各品質データを用いた品質改善方法において、品質データを解析するプログラムを有したナレッジサーバが、外部データベースにリファレンス情報を付加して蓄積されたリポジトリデータベースを参照して自己学習することを特徴とする品質改善方法。
（付記１６）前記ナレッジサーバが、前記品質データを解析した結果をさらに前記リポジトリデータベースへ蓄積するようにして自己学習することを特徴とする付記１５に記載の品質改善方法。
（付記１７）前記リファレンス情報には重要度の重み付けが含まれることを特徴とする付記１５に記載の品質改善方法。

一実施形態の品質改善システムを示す概略構成図である。 各機能を示す概念図である。 ナレッジサーバにおけるリポジトリ機能の説明図である。 ワークフローの定義方法を示す説明図である。 コメント入力を示す説明図である。 解析処理を示すフローチャートである。 トラブル対応処理を示すフローチャートである。 従来のナレッジシステムの説明図である。 本実施形態のナレッジシステムの説明図である。 欠陥検査工程でのアラームの要因調査を行う場合の思考フローを示す説明図である。 データ結合結果を示す説明図である。 データ結合処理を示すフローチャートである。 データ単位の自動判断処理を示す説明図である。 解析グラフの一例を示す説明図である。 陥検査工程でのアラームの要因調査を行う場合の思考フローを示す説明図である。 データの結合方法を示す説明図である。 データ結合結果を示す説明図である。 データ結合処理を示すフローチャートである。 解析グラフの一例を示す説明図である。 従来システムでのデータ解析を説明する説明図である。 本実施形態でのデータ解析を説明する説明図である。 解析リストの一例を示す説明図である。 別例のコメント入力を示す説明図である。 別例のコメント入力を示す説明図である。

符号の説明

１１ 品質改善システム
１２ 知識活用処理装置としてのナレッジサーバ
１３ データ加工装置としてのアプリケーションサーバ
１４ 入力手段としてのクライアントサーバ
１５ 記憶手段としてのナレッジデータベース
１８，１８ａ〜１８ｅ 外部データベース

Claims (10)

1. 半導体製造工程で取得された各種の品質データを蓄積する複数の外部データベースが接続され、該各品質データを用いて品質改善のための処理を行う品質改善システムにおいて、
   解析手順の情報を記憶手段に蓄積する知識活用処理装置と、
   前記解析手順に従い、前記外部データベースから所定のデータを取得してデータ解析を行うデータ加工装置と
   を備え、
   前記知識活用処理装置は、前記データ加工装置の解析結果に対して、入力手段から入力されたリファレンス情報を付加して記憶手段に蓄積する機能と、前記リファレンス情報により重要度を判断し、その重要度に応じて前記記憶手段から解析手順の情報を抽出する機能とを有することを特徴とする品質改善システム。
2. 前記知識活用処理装置は、前記解析結果に付加される前記リファレンス情報の頻度と該リファレンス情報に含まれる単語の出現頻度や重要度に関するデータとに基づいて、前記解析手順の情報を抽出することを特徴とする請求項１に記載の品質改善システム。
3. 前記データ加工装置は、別の外部データベースで管理される複数工程の品質データについて、抽出・加工するデータとして処理工程と検査工程との工程名が指定されることにより、任意の処理工程における装置別、処理順のトレンドグラフを作成する機能を有することを特徴とする請求項１又は２に記載の品質改善システム。
4. 前記データ加工装置は、前記抽出・加工するデータについて、データ単位を自動判断し、各データのうちでデータ単位が小さいデータを基準としてデータ結合することを特徴とする請求項３に記載の品質改善システム。
5. 前記データ加工装置は、処理順、処理工程、処理装置のいずれかを基準とし、前記品質データのトレンドグラフを表示させるための機能を有することを特徴とする請求項１に記載の品質改善システム。
6. 前記知識活用処理装置は、前記記憶手段に登録された手順に従って、前記品質データとしての数値とグラフと画像のデータの中から任意に選んで加工することを特徴とする請求項１に記載の品質改善システム。
7. 前記入力手段は、ドリルダウン方式の条件設定画面を用いて前記解析手順の定義ファイルを作成することを特徴とする請求項１に記載の品質改善システム。
8. 前記知識活用処理装置は、前記解析結果やトラブルの対応結果に対するコメントを前記記憶手段に蓄積し、そのコメントの頻度や効果が大きな結果に対応する処理手順を優先的に抽出するようにしたことを特徴とする請求項１に記載の品質改善システム。
9. 前記知識活用処理装置は、前記解析結果に対するコメントの書き込み頻度、コメントの順番、コメントに含まれる結果内容を管理して蓄積することにより、前記記憶手段としてのナレッジデータベースを構築することを特徴とする請求項１に記載の品質改善システム。
10. 前記知識活用処理装置は、品質改善のための解析結果を目的別に前記ナレッジデータベースに蓄積し、該目的別に品質改善のための処理手順のナビゲートを行うことを特徴とする請求項９に記載の品質改善システム。

Images