(57)【要約】【課題】設計側で作成されたデータに加えて、工場側で行われた設計変更のデータを一元的に管理し、設計変更データを、例えば工場毎に確実にトレース可能とする。【解決手段】設計データ管理プログラムは、設計側で作成された設計データを生産側に適するデータ形式に変換して生産側に送るとともに、予め定められた言語で記述されたデータに変換して記憶装置に格納する手順と、その設計データの変更通知を生産側から受けたとき、その変更データを前述の言語で記述されたデータに変換して前述の記憶装置に格納する手順とを計算機に実行させる。【選択図】図１
2007026430.tif 000002
【特許請求の範囲】
【請求項１】
設計側で作成された設計データに基づいて生産側で製品の製造が行われるシステム内の計算機によって用いられるプログラムであって、
設計側で作成された設計データを生産側に適するデータ形式に変換して生産側に送るとともに、該作成された設計データを予め定められた言語で記述されたデータに変換して記憶装置に格納する手順と、
設計側で作成された設計データの変更通知を生産側から受けたとき、該設計変更データを前記予め定められた言語で記述されたデータに変換して前記記憶装置に格納する手順とを計算機に実行させることを特徴とする設計データ管理プログラム。
【請求項２】
前記予め定められた言語がＸＭＬであることを特徴とする請求項１記載の設計データ管理プログラム。
【請求項３】
前記ＸＭＬによって記述されたデータが、製品の個々の部品のコードデータに対して、該部品に関する各種のデータとしてのマスタデータを結合させた形式で前記記憶装置に格納されることを特徴とする請求項２記載の設計データ管理プログラム。
【請求項４】
設計側で作成された設計データに基づいて生産側で製品の製造が行われるシステム内の計算機によって用いられるプログラムであって、
設計側で作成された設計データと、該設計データに対して生産側で行われた設計変更のデータとが、ともに予め定められた言語で記述されたデータに変換されて記憶されている記憶装置からデータを読み出す手順と、
与えられた検索条件にしたがって、該読み出されたデータを検索し、該検索の結果を設計データ変更履歴として表示装置の画面上に表示する手順とを計算機に実行させることを特徴とする設計データトレースプログラム。
【請求項５】
生産側で用いられる部品の購買に関する情報を定められた言語で記述されたデータに変換して購買側から前記記憶装置に格納する手順をさらに有することを特徴とする請求項１記載の設計データ管理プログラム。
【請求項６】
生産側で設計変更の多い部品を特定する第１の手順と、
該部品のサプライヤを特定する第２の手順を有することを特徴とする請求項５記載の設計データ管理プログラム。
【請求項７】
前記生産側で設計変更の多い部品を特定する第１の手順は、
前記記憶装置に記憶された設計変更履歴情報に対して、工場を特定する情報と設計変更起因部門を特定する情報と設計変更理由を特定する情報を指定し、上記特定工場で設計変更の多い部品を特定する情報を取得する手順とからなる請求項６記載の設計データ管理プログラム。
【請求項８】
前記部品のサプライヤを特定する第２の手順は、
前記記憶装置に記憶された生産部品表から、工場を特定する情報と設計変更のある部品を特定する情報を指定して型番を取得する手順と、
前記記憶装置に記憶された購買部門データベースに対して型番を特定する情報を指定してその型番を供給するサプライヤを特定する情報を取得する手順とからなる請求項７記載の設計データ管理プログラム。
【請求項９】
前記設計変更の多いサプライヤから供給される他の部品の生産側での設計変更の回数を検出する第３の手順と、
前記他の部品についての他のサプライヤの設計変更回数を検出する第４の手順と、
当該サプライヤと他のサプライヤとの前記他の部品についての設計変更の回数を比較する第５の手順とからなる請求項６記載の設計データ管理プログラム。
【請求項１０】
前記第３の手順は、
購買部データベースに対して逆に前記設計変更のあるサプライヤを特定する情報を指定し、そのサプライヤの他の型番を特定する情報を取得する第６の手順と、
生産部品を用いて他の型番のうち一つの型番を指定し、部品を特定する情報を取得する第７の手順と、
該生産部品表に、該部品を指定し、その部品に対応する工場毎の部品と型番の対応を取得する第８の手順と、
設計変更履歴に対して、特定のサプライヤの型番を扱う工場の工場番号と部品を指定して、前記同じ部品の型番毎の設計変更回数を取得する第９の手順とからなり、
前記第４の手順は、
前記第９の手順において、前記部品に対応する他のサプライヤの型番を扱う工場番号と前記他の部品を指定して、前記他のサプライヤの前記型番の設計変更回数を取得する第９の手順からなる請求項９記載の設計データ管理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、設計データの管理方式に係り、さらに詳しくは設計側で作成された設計データだけでなく、その設計データに対して生産側、例えば工場で実行された設計変更のデータを予め定められた言語、例えばＸＭＬで記述されたデータとして管理するための設計データ管理プログラム、および外部からの要求に対応して、前述のように管理されているデータを読み出し、与えられた検索条件にしたがって検索を行った結果を設計データ変更履歴として出力するための設計データトレースプログラムに関する。
【背景技術】
【０００２】
近年、設計データの管理方式としてＰＤＭ（プロダクト・データ・マネージメント）やＰＬＭ（プロダクト・ライフサイクル・マネージメント）などの方式を用いて、概念設計から製造全般に渡る各種のエンジニアリングデータを一元的に管理する管理方式が用いられるようになっている。
【０００３】
従来において設計側、すなわち設計システムにおいて、新規設計時、または設計変更時に作成された設計データは生産側、例えば工場の生産管理部門に渡された時点でその役目を終わり、生産管理部門においては、その工場において必要とするデータのみを抽出し、それ以外のデータの保存は行われていなかった。このため、例えば工場側でそれ以外の設計データが必要になった場合には、設計システム側に保持されているデータを参照し、その内容をマニュアルで確認するしか方法がないという問題点があった。
【０００４】
また設計側から送られた設計データに基づいて工場側で生産が行われるが、例えば設計側で設計データの中で使用されるべき部品を指定しても、工場側で必ずしもその部品が使われないこともある。例えば工程上指定されたネジを使用することができない場合には、工場側で別のネジが使用されることになる。さらに指定されたネジを工場側で、例えばＡ、Ｂ、およびＣ社のいずれもから調達することが可能な場合に、どれを使ったかという代替部品情報についても、例えば設計側で知ることができず、このような代替部品情報を含み、工場側で行われた設計変更のデータが一元管理されていないという問題点があった。
【０００５】
すなわちある設計データに基づいて工場側で製品の生産を行う場合に、設計部門で作成された設計データが複数の工場に送られ、複数の工場でその製品を構成する複数のユニットの製造をそれぞれ行うようなときには、それぞれの工場で管理の都合や外注の関係などで設計データに対して各工場独自の変更、修正が加えられることがあるが、それらの設計変更のデータを、例えば工場ごとに設計システム側などで管理することは困難であるという問題点があった。
【０００６】
さらに例えば複数の設計システムによってそれぞれ設計された複数のユニットによって構成される製品を生産するような場合には、複数の設計システムによって作成された設計データを既存のデータベースで一元的に管理するのは困難であるという問題点もあった。さらに、ある製品について不具合があっても不具合の原因と推測される部品を判断できなかった。
【０００７】
また、不具合の原因を推測される部品のサプライヤに問題があるかも判断できなかった。
このような設計データ管理方式に関する従来技術として次のような文献がある。
【０００８】
特許文献１には、構成要素のデータを引用してドキュメントを作成する場合に、どの要素についてどのバージョンのデータを使用したかをキー情報データとして保存することによって、過去のドキュメント作成時点でどのバージョンの構成要素が使用されたかを容易に調査できるエンジニアリング情報保存装置が開示されている。
【０００９】
特許文献２には、設計データを所定の形式で記述された入力データに変換し、その入力データを製造データに変換しやすい形式の統合データ、すなわちＸＭＬによって記述されたデータに変換して管理することによって、設計データから製造データを得るためのデータ変換を容易にすることができる設計製造データ管理システム、およびプログラムが開示されている。
【特許文献１】特開平７−２７１６４２号公報
【特許文献２】特開２０００４−１７８１７０号公報
【００１０】
しかしながらこのような文献に開示されている従来技術を用いても、例えば代替部品情報を含み、各工場でおこなわれた設計変更のデータを一元的に管理することはできないという問題点を解決することはできなかった。
【発明の開示】
【発明が解決しようとする課題】
【００１１】
本発明の課題は、前述の問題点に鑑み、設計側で作成された設計データに加えて、例えば工場側で行われた部品代替の情報を含む設計変更データを一元的に管理し、例えば工場ごとに設計データ、および設計変更データの確実なトレースを可能とすることである。さらに、本発明の課題は製品に不具合が生じたとき、その原因と推測される部品を判断し、さらにサプライヤに問題があるかを判断することを可能とすることである。
【課題を解決するための手段】
【００１２】
図１は、本発明の設計データ管理プログラムの原理的な機能ブロック図である。同図は設計側で作成された設計データに基づいて、生産側で製品の製造が行われるシステム内の計算機によって用いられる設計データ管理プログラムの原理的な機能ブロック図である。
【００１３】
本発明の設計データ管理プログラムは、図１のステップＳ１で設計側で作成された設計データを、生産側に適するデータ形式に変換して生産側に送るとともに、該作成された設計データを、予め定められた言語で記述されたデータに変換して記憶装置に格納する手順と、ステップＳ２で設計側で作成された設計データの変更通知を生産側から受けたとき、その設計変更データを前述の予め定められた言語で記述されたデータに変換して、前述の記憶装置に格納する手順とを計算機に実行させるものである。
【００１４】
発明の実施の形態においては、前述の予め定められた言語がＸＭＬであることもでき、またこのＸＭＬによって記述されたデータが、製品の個々の部品のコードに対して、その部品に関する各種のデータとしてのマスタデータを結合させた形式で前述の記憶装置に格納されることもできる。
【００１５】
次に本発明の設計データトレースプログラムは、前述と同様のシステム内の計算機によって用いられるプログラムであり、設計側で作成された設計データと、その設計データに対して生産側で行われた設計変更のデータとが、ともに予め定められた言語で記述されたデータに変換されて記憶されている記憶装置から格納されているデータを読み出す手順と、読み出されたデータに対して与えられた検索条件に従った検索の結果を、設計データ変更履歴として表示装置の画面上に表示する手順とを計算機に実行させるものであり、発明の実施の形態においては、前述の予め定められた言語がＸＭＬであることもできる。
【００１６】
さらに本発明の他の実施形態によれば生産側で用いられる部品の購買に関する情報を定められた言語で記述されたデータに変換して購買側から前記記憶装置に格納する手順をさらに有することを特徴とする設計データ管理プログラムを提供する。
【００１７】
また、この実施の形態は、生産側で設計変更の多い部品を特定する第１の手順と、該部品のサプライヤを特定する第２の手順を有する。
さらに、この実施の形態は、前記設計変更の多いサプライヤから供給される他の部品の生産側での設計変更の回数を検出する第３の手順と、前記他の部品についての他のサプライヤの設計変更回数を検出する第４の手順と、当該サプライヤと他のサプライヤとの前記他の部品についての設計変更の回数を比較する第５の手順とからなる。
【００１８】
以上のように本発明においては、設計側で作成された設計データに加えて、生産側で行われた設計変更データが一元的に管理され、例えば設計変更データを工場別に変更履歴としてトレースすることができる。また、設計側では、生産側で行われた設計変更データを考慮して次の設計または設計変更を行うことができる。
【発明の効果】
【００１９】
本発明によれば、工場側で変更された設計変更データを含み、設計データや設計変更データの一元的管理、および例えば各工場ごとの設計変更履歴のトレースが可能となる。
また一元的に管理すべきデータをＸＭＬで記述することによって、複数の設計システムの間のデータ形式などの相違に対応することもでき、また設計データにおける将来的なデータ項目の追加があった場合にも、ＸＭＬデータの追加を行うことで対応が可能となり、データベースの再構築の必要をなくすことができる。
【００２０】
さらに、製品に不具合がある場合、その原因と推測される部品を判断できるとともに、その部品を提供するサプライヤ自身について問題があるか判断できる。
【発明を実施するための最良の形態】
【００２１】
図２は、本発明の設計データ管理方式、および設計データトレース方式の全体説明図である。同図において設計業務によって作成された設計部品表などに対応する設計ＢＯＭ（ビル・オブ・マテリアル）は、例えばＸＭＬデータとして設計データの管理と必要な変換を行う製造ＨＵＢに出力される。
【００２２】
このデータは、製品の製造に必要な一般に複数の工場、ここではＡ工場とＢ工場側に、例えば暗号化されてＸＭＬデータとして送られ、それぞれの工場における生産業務において設計ＢＯＭとして製品の製造に用いられるとともに、例えば各工場に直結したＸＭＬ型データベースに格納される。
【００２３】
この時、各工場において設計業務によって作成された設計データに対する変更が必要なときには、その設計変更データもＸＭＬ型データベースに格納されることによって、設計データのトレースを行うトレースサーバが、各工場に直結したＸＭＬ型データベースの格納内容を参照して、工場ごとの設計データの変更履歴をトレースすることが可能となる。
【００２４】
後述する実施例においては、設計業務によって作成された設計データと、各工場側でその設計データに変更が行われた結果としての設計変更データは１つのデータベースに、例えばＨＵＢシステムによって格納され、トレースサーバはそのデータベースの格納内容を検索することによって、例えば各工場ごとの設計変更履歴を出力することが可能となる。この場合、設計業務によって作成された設計データに対して各工場で行われた変更の結果としての設計変更のデータは、各工場からＨＵＢシステムに送られ、その設計変更データはＨＵＢシステムによって、例えばＸＭＬによって記述されたデータに変換されて一元的に管理される。なお例えば図２では設計業務から出力される設計データもＸＭＬデータとされているが、このデータは必ずしもＸＭＬで記述されている必要はない。
【００２５】
図３は本実施形態における設計データや設計変更データの流れの説明図である。同図において、設計データを作成する設計システム１０と、工場側でその設計データを取り込む生産管理システム１１との間に、図２の製造ＨＵＢに相当し、データの転送や変換処理を行うＨＵＢシステム１２が備えられ、またＨＵＢシステム１２によって設計データや設計変更データが格納され、設計変更の履歴を管理する履歴管理部１３が備えられている。
【００２６】
ＨＵＢシステム１２は、基本的には設計システム１０から出力される新規の設計データと、設計変更時の元の設計データとの差分のデータを生産システム１１側に渡すにあたって、データの転送や変換処理を司るサーバとしての処理を実行するものである。そしてこのＨＵＢシステム１２によって、新規設計のデータを含む設計変更のデータが設計変更データとして履歴管理部１３に送られて蓄積される。このデータを蓄積する物理的なメモリは、ＨＵＢシステム１２のローカルデバイスであってもよく、リモートデバイスであってもよい。
【００２７】
図３において設計システム１０によって作成されたデータは、ＸＭＬ−１ファイル１５として、データボックス１６に格納され、データ転送実行部１７によってＨＵＢシステム１２に送られる。
【００２８】
ＨＵＢシステム１２では、設計システム１０から送られたデータはデータボックス１８に格納され、例えばＸＭＬ中間ファイル１９に変換され、データボックス２０に格納される。データボックス２０に格納されたデータは、例えば生産管理システム１１側に適するデータとしてのＸＭＬ−２ファイル２３に変換され、生産管理システム１１に送られる。
【００２９】
生産管理システム１１では、ＨＵＢシステム１２から送られ、データ送受信部２１によって受信されたＸＭＬ−２ファイル２３のデータがデータボックス２２に格納され、そのファイルは例えば工場側に出力される。
【００３０】
またＨＵＢシステム１２側では、例えばＸＭＬ中間ファイル１９の内容としての設計システム１０から送られた設計データ、または設計変更データがデータの一元管理やトレースに適した形式のＸＭＬ中間ファイル１９に変更されてデータボックス２６に格納され、そのデータが履歴管理部１３に送られる。履歴管理部１３側ではＨＵＢシステム１２から送られたデータがデータ受信部２７によって受信され、データボックス２８に格納される。そして設計データ、および設計変更データの履歴を管理するために好適な形式としてのＸＭＬ−３ファイル２９として履歴情報データベース３０に格納される。
【００３１】
一方生産管理システム１１側で、例えば工場におけるデータ管理や部品の調達などの関係で、設計システム１０側から送られた設計データ、すなわちＸＭＬ−２ファイル２３のデータの内容が変更された場合には、その変更データがＸＭＬ−４ファイル２４としてデータボックス２２に格納された後に、データ送受信部２１によってＨＵＢシステム１２に送られる。
【００３２】
ＨＵＢシステム１２側では、この設計変更データはデータボックス１８に格納され、前述の設計システム１０によって作成された設計データ、あるいは設計変更データと同様に、ＸＭＬ中間ファイル１９に変換され、データボックス２６に格納された後に、ＸＭＬ−３ファイル２９に変換されて履歴管理部１３に送られる。そして履歴管理部１３によって、前述と同様に設計変更データがＸＭＬ−３ファイル２９として履歴情報データベース３０に格納される。
【００３３】
これによって設計システム１０から出力された設計データ、設計変更データに加えて、生産管理システム１１側、すなわち各工場において行われた設計変更のデータが、すべて履歴管理部１３の内部の履歴情報データベース３０にＸＭＬ−３ファイル２９として格納されて一元管理されることになる。
【００３４】
図４は、図３の履歴管理データベース３０へのデータ格納形式の説明図である。本実施形態においては、設計データが例えば部品の部品コード、例えばパーツナンバのデータに対して、その部品に関する各種の情報としてのマスタ情報が結合された形式でＸＭＬ型データベースとして管理される。これによって複数のテーブルにデータベースとして正規化してもたせておく必要のある設計データを１つのレコードとして管理することができる。
【００３５】
一般に製品製造のための部品情報は階層的に管理される。すなわちある製品を作るためにどのようなユニットが必要であり、各ユニットに対してどの部品が必要になるかというように、製品を構成する部品情報の構造が階層的に管理される。そしてこの階層構造における親部品（アッパー・パート）と子部品（ロワー・パート）の構造がパーツ・ストラクチャ・テーブルとして管理され、それぞれの部品コード、例えば部品の番号によって指定される部品に関連するマスタ情報がパーツ・マスタ・テーブルとして管理される。
【００３６】
本実施形態においては、図４に示すように図３の履歴情報データベース３０へのＸＭＬデータの格納において、このパーツ・マスタ・テーブルのデータがパーツ・ストラクチャ・テーブルのデータに結合された状態で格納され、必要に応じてログとして出力される。すなわち図４の右側に示すように、パーツ・ストラクチャ・テーブルのデータの中にパーツ・マスタ・テーブルのデータが包含される形式で、履歴情報データベース３０へのデータ格納が行われる。これによって、例えば将来的にデータ項目が追加されるような場合にも、図４の形式で格納されたＸＭＬデータに必要なデータの追加を行うのみで、データ項目の変更などに対応することが可能となり、データ項目の変更に対応するデータベースの構造変更や再構築などは必要がなくなる。例えばボトルとキャップの設計部門に加えて、さらにボトルを支える部品を作るための設計部門を新たに立ち上げても、３つの部品のデータを管理するための新たなデータベースを作る必要はない。
【００３７】
図５は、本実施形態における設計データ管理、およびトレース処理の詳細フローチャートである。このフローチャートにおける処理は、基本的に設計側の処理、ＨＵＢシステム側の処理、生産側の処理、およびトレース処理、すなわち設計変更履歴表示処理に大別される。なお、図で矢印はデータの流れを示し、処理は当然、上から下に順次実行される。
【００３８】
まず設計側で処理が開始されると、ステップＳ１１で新規の設計データ、または設計変更データ送信依頼が作成され、そのデータはＸＭＬ−１ファイル１５として出力される。そしてステップＳ１２で、このＸＭＬ−１ファイル１５を入力としてＨＵＢシステム側へのデータ送信が行われ、処理を終了する。
【００３９】
ＨＵＢシステム側では、ステップＳ１５で設計側からのデータが受信され、ＸＭＬ−１ファイル１５が出力される。ここで、後述するようにステップＳ１５では、生産側から送られる設計変更データとしてのＸＭＬ−４ファイル２４も受信する可能性がある。
【００４０】
設計側から送られたＸＭＬ−１ファイル１５は、ステップＳ１６のデータ変換処理に入力され、その結果は図３の履歴情報データベース３０に格納されるデータ形式、すなわち図４で説明したようにパーツ・ストラクチャ・データにパーツ・マスタ・データが結合された形のＸＭＬ−３ファイル２９として出力され、ステップＳ１７のデータ送信処理に入力される。そして例えばリモートデバイスへのデータ送信が行われ、送信データはステップＳ１８で受信され、履歴情報データベース３０に格納される。
【００４１】
このような処理と並行して、ＨＵＢシステムでは設計側から送られたＸＭＬ−１ファイル１５の内容の生産側への送信処理が行われる。すなわちステップＳ１５で受信されたデータのうち、ＸＭＬ−１ファイル１５のみがステップＳ２０で取り出され、ステップＳ２１のデータ変換処理に入力される。そしてそのデータ形式が生産側の処理に適する形式としてのＸＭＬ−２ファイル２３として出力され、ステップＳ１７のデータ送信処理に入力されてそのデータの生産側への送信が行われる。なお本発明の特許請求の範囲の請求項１における１番目の手順は、ステップＳ２１、Ｓ１７の処理と、ステップＳ１６〜Ｓ１８の処理に相当する。
【００４２】
生産側ではステップＳ２５でこのデータが受信され、ＸＭＬ−２ファイル２３として出力される。そしてこのＸＭＬ−２ファイル２３を入力として、設計側から送られたデータに対して生産側、すなわち工場側で変更が必要か否かがステップＳ２６で判定され、変更が必要ない場合には、ステップＳ２７でこのＸＭＬ−２ファイル２３が生産側のメモリに格納されて処理を終了する。
【００４３】
ステップＳ２６で設計側から送られたデータに対する変更が必要と判定されると、ステップＳ２８で変更データの格納依頼が作成され、その内容はＸＭＬ−４ファイル２４として出力される。そしてこのファイルはステップＳ２９の変更データ送信処理に入力され、ＨＵＢシステム側に送信されて、例えば設計側からのデータとしてのＸＭＬ−２ファイル２３の内容と、生産側での変更データを示すＸＭＬ−４ファイル２４との内容が、ステップＳ２７で生産側のメモリに格納されて処理を終了する。
【００４４】
生産側からＨＵＢシステムに対して送られた設計変更データとしてのＸＭＬ−４ファイルは、ＨＵＢシステム側でステップＳ１５で受信され、前述のＸＭＬ−１ファイル１５と同様にステップＳ１６のデータ変換の処理に対する入力として与えられ、履歴情報データベース３０に格納されるデータ形式としてのＸＭＬ−３ファイル２９に変換されて、ステップＳ１７、Ｓ１８の処理によって履歴情報データベース３０に格納される。なお請求項１における２番目の手順はステップＳ１６〜Ｓ１８の処理に相当する。
【００４５】
次にトレース処理のフローにおいて処理が開始されると、ステップＳ３１で履歴情報データベース３０からのデータの読み込みが行われる。前述のように履歴情報データベース３０は、ＨＵＢシステムのローカルデバイスであってもよく、リモートデバイスであってもよいが、いずれにせよ履歴情報データベース３０からデータが出力され、ステップＳ３２で出力されたデータに対する検索・集計処理が行われ、その処理の結果が設計変更履歴としてトレース画面に表示されて処理を終了する。これによって履歴情報データベース３０に蓄積された設計データ、および設計変更データに対して項目を指定して、あるいは特に項目を指定せずに検索するだけで、例えば工場毎に時系列の設計変更データのトレースを表示することが可能となる。そのトレースをたどることによって過去の部品構成を復元することも可能となる。
【００４６】
図６と図７は、設計変更履歴トレース表示の例である。この設計変更トレースは、ある子部品に対する設計変更履歴を示し、図６はＡ工場における変更結果を、また図７はＢ工場における変更結果を示している。
【００４７】
図６と図７とを比較すると、図７の７行目のデータ、すなわちＢ工場による変更箇所のデータを除いて、図６と図７との内容は同じである。すなわちＡ工場では設計側から指示された設計変更のみを行っているのに対して、Ｂ工場側では設計側から指示された設計変更以外に工場独自に設計データの変更を行い、その結果をＸＭＬ−４ファイル２４としてＨＵＢシステム側に通知したことが示されている。
【００４８】
なお図６と図７における親部品コードは、指定された子部品、すなわちトレース対象とした部品を利用する親部品としてのコードであり、シーケンスＮｏ．は工場側で組み立てる際の工程の順番であり、数量分子／数量分母は必要な部品の数であり、数量単位はこの必要な部品の数の単位であり、開始年月日は工場における設計変更の開始日であり、終了年月日はこの設計の有効期限である。この２つの年月日のデータは、生産管理システムによって行われる部品手配のための部品所要量の計算に大きくかかわるものである。
【００４９】
本実施形態においては、前述のようにすべての設計データと設計変更データが履歴情報データベース３０によって一元的に管理されるために、前述のようにある項目を指定することによって、その項目に該当する設計変更データに対する集計処理を行うことが可能となる。図８と図９は、設計変更理由の集計処理の結果の例である。
【００５０】
図８においては、製品別に設計変更の理由の集計が行われ、図９では、例えばある製品に対して設計変更が行われた回数が月別に集計されている。このような集計結果を利用することによって、製造プロセスの管理も可能となり、実用的に大きな価値がある。
【００５１】
以上において本発明の設計データ管理プログラム、および設計データトレースプログラムなどについてその詳細を説明したが、例えば図３のＨＵＢシステムは当然一般的なコンピュータシステムを基本として構成することが可能である。図１０はそのようなコンピュータシステム、すなわちハードウェア環境の構成ブロック図である。
【００５２】
図１０は本発明の他の実施例のブロック図である。
図３と同一部分は同一符号を付して説明を省略する。
購買システム３５においては各部門からの設計変更依頼のデータ（変更依頼理由、内容、発生元を記載したもの）がＸＭＬ−５ファイル３６としてデータボックス３７に格納される。そしてそのＸＭＬ−５ファイル３６はデータ転送実行部３８を介して購買システム３５からのデータとしてハブシステム１２のデータボックス１８に格納される。そして購買システム３５からのデータは図３に述べたと同様にしてＸＭＬ中間ファイル１９、データボックス２６を介して履歴管理部１３に転送されデータ受信部２７、データボックス２８を介してＸＭＬ−３ファイル２９が最終的には履歴情報データベース３０に格納される。これによりハブシステム１２に対応して設けられた履歴管理部１３の履歴情報データベース３０には設計システム１０のデータ及び生産管理システム１１からのデータに加えて購買システム３５からのデータも記録されているので、以下に説明する処理を行うことができる。
【００５３】
図１１Ａに示すように目標１としてある工場について変更が頻繁に行われている部品のサプライヤを特定する。すなわち、手順（１）において履歴情報データベース３０から設計変更履歴（１）−１を取り出し（１）―２に示すように工場番号、変更起因部門、変更理由を特定することにより（１）−３に示すように例えば工場番号０の製造部門において、強度不良を示す代表部品番号ＡＡＡを３回取得する。この際ビューアには（１）−４に示すように工場番号、代表部品番号、変更起因部門、変更理由のテーブルが表示される。ここで、他の工場番号、変更起因部門、変更理由を指定することと、他の代表部品番号についても、強度不良の部品数を数えて、代表部品番号ＡＡＡの強度不良の部品がより多いと判断する。なお、代表部品番号ＡＡＡの強度不良が多いことは閾値に基づいて判断しても良い。
【００５４】
次に手順（２）において、履歴情報データベース３０から生産側のデータである生産部品表（２）−１を取り出し、（２）−２に示すように工場番号と代表部品番号を特定し、（２）−３に示すようにこれに対応する部品型番ＥＸ００１を取得する。このときビューアには（２）−４に示すように工場番号、型番、代表部品番号のテーブルが表示される。
【００５５】
次に手順（３）において、履歴情報データベース３０の中に記憶されている購買部門データベースからのデータ（３）−１を取り出し（３）−２に示すように部品型番を特定し、（３）−３に示すようにサプライヤコードＥＸ製作を取得する。このときビューアには（３）−４に示すように型番とサプライヤコードのテーブルが表示される。
【００５６】
以上のようにして（１）−２、３に示すように設計変更の多い部品として、代表部品番号ＡＡＡが取得され、（２）−２、３に示すように工場番号０の代表部品番号ＡＡＡの型番ＥＸ００１が取得され、（３）−２、３に示すようにこの型番ＥＸ００１を供給するサプライヤのサプライヤコードＥＸ製作が取得される。したがって変更が多いサプライヤを特定することができる。また、変更の多い部品として、他の代表部品番号も取得されたときは、上述と同様の手順によりそのサプライヤを特定し、どちらのサプライヤの設計変更回数が多いかを比較することができる。
【００５７】
目標２として特定したサプライヤについて、その部品だけが問題なのか、サプライヤ自身に問題があるのかを判断するためのデータを取得する処理を図１１Ｂに従って説明する。
図１１Ｂに、手順（４）において（４）−１で示すように履歴情報データベース３０から購買部門からのデータを取得し、（４）−２に示すように手順３で取得したサプライヤコードを特定して（４）−３に示すように部品型番を取得する。このときビューア（４）−４には型番とサプライヤコードの対応テーブルが表示され特定したサプライヤの他の部品型番ＥＸ００２、ＥＸ００３、ＥＸ００５を取得する。
【００５８】
次に手順（５）において、履歴データベース３０から生産部門部品表（５）−１のデータを取得し、（５）−２に示すように部品型番を特定することにより（５）−３に示すように代表部品番号を取得する。このときビューアには工場番号と型番と代表部品番号の対応テーブルを（５）−４に示すように表示される。そして例えば工場番号０、１、２では型番ＥＸ００５の代表部品番号はＥＥＥであることが取得される。
【００５９】
次に手順（６）において、履歴情報データベース３０から生産部品表（６）−１のデータを取得し、（６）−２に示すように代表部品番号に基づいて（６）−３に示すように工場毎の代表部品番号と型番の対応を取得する。すなわち代表部品番号ＥＥＥに対して、各工場０、１、２、３、４で型番ＥＸ００５、ＡＤＤ００５、ＥＸ００５、ＥＸ００５、ＢＩＧ００５がそれぞれ特定され、この型番によりそれぞれのサプライヤが特定される。このとき、ビューア（６）−４には工場番号、型番、代表部品番号のテーブルを表示する。
【００６０】
次に手順（７）において、（７）−１に示すように、履歴情報データベース３０から設計変更履歴を取得し、（７）−２に示すように工場番号と代表部品番号を特定し、（７）−３に示すように各同じ代表部品番号ＥＥＥに対応する型番ＡＤＤ００５、ＢＩＧ００５、ＥＸ００５すなわちそれぞれの型番に対応したサプライヤの設計変更回数を０回、１回、４回を取得する。（７）−４に示すように型番ＥＸ００５の設計変更回数は４回であるので、型番ＥＸ００５を供給するサプライヤであるＥＸ製作が代表部品番号のＥＥＥの部品については最も不良率が高いことが分かる。
【００６１】
次に手順（８）において、ステップ（８）−１に示すようにステップ（４）−３で取得したサプライヤコードＥＸ製作の他の型番ＥＸ００１、ＥＸ００２、ＥＸ００３を求め、（５）−３に示すように対応する代表部品番号を求め、（６）−３に示すようにその代表部品番号に対応する他のサプライヤの型番を求め、（７）−３に示すようにその型番の設計変更回数を求める。これによりサプライヤコードＥＸ製作所の、型番ＥＸ００１、ＥＸ００２、ＥＸ００３で特定される代表部品番号の他のサプライヤの型番を知ることによりその型番毎の他のサプライヤの設計変更回数が出力される。そして（８）−２に示すようにサプライヤコードＥＸ製作所の部品型番ＥＸ００１、ＥＸ００２、ＥＸ００３、ＥＸ００５の設変回数はそれぞれ４回、０回、４回、４回であるので、この型番に対応した代表部品番号の他のサプライヤの対応する型番の設計変更回数を調べてサプライヤコードＥＸ製作の設変回数が同じ代表部品番号に対して、他のサプライヤの対応する代表部品番号の設変回数より多いか否かを判定する。
【００６２】
これによりサプライヤＥＸ製作の型番ＥＸ００５に対応する代表部品ＥＥＥが設計変更回数が多いだけでなく、そのサプライヤＥＸ製作の他の代表部品番号も設変回数が他のサプライヤと比べて多いか否かを判断することができる。
【００６３】
図１２Ａは図１１Ａ，図１１Ｂに示した目標１及び目標２に対する処理をより具体的に示したものである。図１２Ａから図１２Ｉにおいて図１１Ａ，図１２Ｂと同じところは同一参照番号を付して説明を省略する。
【００６４】
部品調達や設備工程の個々の工場毎に異なるため、問題の発見には工場単位での設計変更履歴の分析が有効である。発見された問題が他の工場でも成り立つことを立証すれば、全社的な取り組み例えば一つのサプライヤが他のサプライヤに各工場において設計変更率の高いものを各種の部品を納入していることが分かれば全社的にそのサプライヤに対する対応が可能になる。
【００６５】
購買部門の改善を目標とした場合に問題となるサプライヤを突き止めることが必要であり、そのためにはまず問題となっている部品を発見しなくてはならない。
手順（１）において、（１）−１に示す設計変更履歴においては、（１）−１−１に示すように工場毎に部品が代表部品番号で管理され、部品と変更起因部門の変更理由の対応情報も管理されている。この情報から「問題のある部品」を特定する。すなわち、（１）−１−１に示すように工場番号として、各工場毎に０、１、２、３、４で示す。代表部品番号として、各部品毎にＡＡＡ、・・・ＡＢＣ、ＢＢＢ、ＢＣＤ、ＣＤＥ・・・で示す。変更起因部門として、製造、購買、販売、設計、・・・が存在する。変更理由として、強度不良、コスト削減、統合不良、仕様変更、デザイン変更、機能修正・・・が存在する。
【００６６】
部品に関する問題は価格や品質など様々なものが考えられるが、例えば品質改善を目標にした場合について述べる。（１）−２に示すように「工場番号＝０」として管理されている工場において代表部品番号ＡＡＡすなわち、（１）−１−１に示すテーブルにおいて、工場番号＝０、代表部品番号ＡＡＡ、変更起因部門「製造」、変更理由「強度不良」、を指定して、「製造部門で実際に使ってみたところ品質に関する問題（強度不良など）により設計変更になった部品」を検索する。そしてビューアには（１）−４のように工場番号０で代表部品番号ＡＡＡに対して変更起因部門が製造であるものにおいて変更理由として強度不良が３回生じていることが検出される。すなわち上記の操作により、一定件数以上設計変更のあった部品として代表部品番号ＡＡＡを取得する。
【００６７】
次に図１２Ｂの手順（２）において、（２）−１−１に示すように生産部品表（２）−１を特定し、すなわち生産部品表で（２）−１−１に示すように工場毎に現時点での代表部品番号と型番の対応を管理している。そのテーブル（２）−１−１に示すように工場番号０，１，２，３，４及び型番ＥＸ００１、ＴＥＣ００１、ＡＤＤ００２、ＳＳＣ００１、ＫＡＷ００１、・・・ＢＩＧ００５、ＥＸ００５、・・・、ＥＸ００３、・・・、ＡＤＤ００５さらにこれらに対応した代表部品番号ＡＡＡ、ＡＢＣ、ＢＢＢ、ＢＣＤ、ＣＤＥ、ＥＥＥ、ＥＥＥ、・・・ＣＣＣ、・・・ＧＧＧのテーブルが存在する。この部品表（２）−１−１で工場番号０と代表部品番号ＡＡＡを指定して検索することにより問題のある部品の型番ＥＸ００１を取得することができる。
【００６８】
同じ部品でも複数の部品調達元が存在する場合があり、それらの区別は型番という形で管理される。そこで（２）−２で示すように代表部品番号と工場番号から型番を特定する必要がある。
【００６９】
次に図１２Ｃの手順（３）に示すように購買部門データ（３）−１はテーブル（３）−１−１として型番ＡＤＤ００１、ＡＤＤ００２、・・・ＡＤＤ０５、ＢＩＧ００１、・・・ＢＩＧ００５、・・・ＣＡＬ００１、・・・ＥＸ００１とサプライヤコードＡＤＤ部品、ＡＤＤ部品、・・・ＡＤＤ部品、・・・ＢＩＧ工具店、ＣＡＬ商店、ＥＸ製作との対応を管理する。問題のある部品の型番が取得できればこのサプライヤを取得することができる。ここで部品型番ＥＸ００１を指定することでサプライヤをＥＸ製作と特定する。
【００７０】
次に図１２Ｄの手順（４）において、購買部門のデータベース（４）−１は（４）−１−１に示すように型番ＡＤＤ００１、・・・ＡＤＤ００５、ＢＩＧ００５、ＥＸ００１、ＥＸ００２、ＥＸ００３、ＥＸ００５とサプライヤコードＡＤＤ部品、ＢＩＧ工具店、ＥＸ製作、ＥＸ製作、ＥＸ製作、ＥＸ製作、という対応を管理する。
【００７１】
上記（３）−１、（３）−２、（３）−３の時点では「ある問題部品のサプライヤ」を特定できた。このサプライヤＥＸ製作所について「ある問題部品」だけに不具合があるのか、それともサプライヤそのものが問題を抱えているのかといった点についても調べることができる。（１）−１〜（３）−３までのサプライヤの特定の手順を逆にたどることで同サプライヤの他の部品について他のサプライヤと比較して問題のある部品かどうかを調べる。この実施例ではサプライヤとしての「ＥＸ製作」を特定したので、このＥＸ製作から購入している他の部品の型番すなわち型番ＥＸ００１以外のＥＸ００２、ＥＸ００３、ＥＸ００５も取得する。
【００７２】
すなわちサプライヤコードＥＸ製作を特定することによりこのサプライヤが納入している部品の型番ＥＸ００１、ＥＸ００２、ＥＸ００３、ＥＸ００５が特定され、ビューアには（４）−４に示すように型番とサプライヤコードの対応テーブルが表示される。
以下の手順では「型番がＥＸ００５」の部品について調べる。
【００７３】
次に図１２Ｅの手順（５）において、生産部品表（５）−１に示すテーブルは（５）−１−１に示すように工場番号０、１、２、３と型番ＥＸ００１、ＴＥＣ００１、ＢＩＧ００１〜ＥＸ００５、・・・ＥＸ００５、・・・ＥＸ００５と代表部品番号ＡＡＡ、ＡＢＣ、ＢＢＢ、・・・ＥＥＥ、・・・ＥＥＥ、・・・ＥＥＥの対応を管理する。そして型番ＥＸ００５から代表部品番号ＥＥＥの情報を取得し、どの工場でどういう規格で使われているかを調べる。これによると「型番ＥＸ００５」は工場０、２、３において「代表部品番号＝ＥＥＥ」として利用される。そしてビューアには（５）−４に示すように工場番号０、２、３と型番ＥＸ００５と代表部品番号ＥＥＥの対応テーブルが表示される。
【００７４】
次に図１２Ｆの手順（６）において、生産部品表（６）−１は（６）−１−１のテーブルに示すように工場番号０、１、２、３、４と型番ＥＸ００１、ＴＥＣ００１、ＢＩＧ００１、・・・ＥＸ００５、・・・ＡＤＤ００５、・・・ＥＸ００５、・・・ＥＸ００５、・・・ＢＩＧ００５と代表部品番号ＡＡＡ、ＡＢＣ、ＢＢＢ、・・・ＤＥＥ、ＥＥＥ、ＥＥＥ、ＥＥＥ、ＥＥＥの対応を管理する。
【００７５】
上記（５）−１、（５）−２、（５）−３までのステップで、生産部品表で「ＥＸ００５」情報を検索することで、「ＥＥＥ」という代表部品番号の規格で使用されていることが特定できた。
【００７６】
最終的な目的は、同じ「ＥＥＥ」という規格について他のサプライヤの部品との不具合件数を比較することなので、ここでもう一度同じく生産部品表内で代表部品番号「ＥＥＥ」を指定してその型番を検索する。その結果他のサプライヤの型番「ＡＤＤ００５」が「工場１」で、型番「ＢＩＧ００１」が「工場４」で、用いられることが解った。なお、ＥＸ製作の型番「ＥＸ００５」は「工場０」「工場２」「工場３」で使用されている。代表部品番号ＥＥＥは、各工場０、１、２、３、４では（６）−４に示すような型番ＥＸ００５、ＡＤＤ００５、ＥＸ００５、ＥＸ００５、ＥＸ００５、ＥＸ００５、ＢＩＧ００５に対応することがビューアに示される。
【００７７】
次に図１２Ｇの手順（７）―（イ）において設計変更履歴データ（７）−１を（７）−１−１に示すように工場番号０、１、２、３、４と、代表部品番号ＡＡＡ、ＡＢＣ,・・・ＥＥＥ・・・と、変更起因部門製造・・・購買・・・製造・・・販売・・・製造と強度不良・・・、コスト削減・・・、強度不良・・・との対応として管理する。設計変更履歴において、代表部品番号ＥＥＥを以下の通り読み替えて、図のステップＳ３２に示すように検索・集計する。
【００７８】
例えばＥＸ００５については「工場番号が０または２または３」という値を取得する。よって、検索条件に「代表部品番号＝ＥＥＥ」に加えて「工場番号が０または２または３」を設定して検索し、出力されたものがＥＸ００５の設計変更回数である。このＥＸ００５の設計変更回数＝４回」の値を保存する。同様にして６で取得した型番ＡＤＤ００５、ＢＩＧ００５全てについて検索を行った後保存していた設計変更回数１回、０回を集計することで、ＥＸ００５が、代表部品ＥＥＥに関して最も問題がある部品であることが分かる。このように、工場０において設変のある部品ＥＸ００１の検索からＥＸ製作というサプイライヤを突き止め、全社範囲でＥＸ製作の製品を調べることでＥＸ００５という製品の問題を発見することが出来た。
【００７９】
次に図１２Ｈの手順（７）−（ロ）において、購買データベース（７）−１は型番（７）−６に示すようにＡＤＤ００１、ＡＤＤ００２、・・・ＡＤＤ００５、・・・ＢＩＧ００５、・・・ＥＸ００５とサプライヤコードＡＤＤ部品、ＡＤＤ部品、・・・ＡＤＤ部品、・・・ＢＩＧ工具店、・・・ＥＸ製作の対応テーブルを管理し、前記（３）と同じ手順で購買データベースから型番に対応するサプライヤを取得する。（７）−４に示す部品型番の設計変更回数から、（７）−５に示すサプライヤの設計変更回数を示す。すなわち、ビューアには、サプライヤコードとして、ＡＤＤ部品、ＢＩＧ工具店、ＥＸ製作を、部品型番としてＡＤＤ００５、ＢＩＧ００５、ＥＸ００５、設計変更回数として１回、０回、４回のそれぞれの対応を表示する。そして、サプライヤＥＸ製作の設計変更回数は４回であり、他のサプライヤＡＤＤ部品、ＢＩＧ工具店よりの設計変更回数、１回、０回よりも多いことが分かる。
【００８０】
次に図１２Ｉの手順（８）において上記（５）ないし（７）の手順により、「ＥＸ製作」の部品の一つである「ＥＸ００５」は同じ規格内で他のサプライヤ製品と比較した時に設計変更回数が多いことが分かった。この手順（５）ないし（７）を「ＥＸ製作」の製品の部品全てにおいて繰り返し「ＥＸ製作」全体について検討する。すなわちＥＸ００５の設計変更回数は４回であるのに対して他の部品型番ＥＸ００１、ＥＸ００２、ＥＸ００３の設計変更回数３回、０回、４回となり、ここでは図示はしていないがそれらの部品型番に対応する他のサプライヤの部品型番の設計変更回数をそれぞれ同じ部品番号について見てみると各型番毎の設計変更回数がそれぞれ型番ＥＸ００１、ＥＸ００２、ＥＸ００３がそれぞれ３回、０回、４回より少ないとする。このときサプライヤＥＸ製作から納入される部品型番ＥＸ００５以外の部品型番ＥＸ００１,ＥＸ００２、ＥＸ００３の設計変更回数も他のサプライヤより多いこととなる。そうすればＥＸ製作からの部品自体に問題があることが分かる。すなわち、ＥＸ製作の部品が他社のサプライヤの部品よりも問題を起こし易いというケースが他の型番においても成り立つ。
【００８１】
このように一つの工場で一つの部品の変更が多いことが気になった場合、その部品についての対処で終わらせるのでなく、サプライヤを特定しそのサプライヤから他の工場に納入される他の部品についても設計変更回数を取得しそれらが部品番号は同じだが部品型番が異なる他社のサプライヤの同じ部品についての設計変更回数と比較して部品型番ＥＸ００１、ＥＸ００２、ＥＸ００３の設計変更回数が多いならばそのサプライヤＥＸ製作からの他の納入製品についても問題があることが分かる。
【００８２】
図１３は図１２Ａの（１）−１−１に対応する設計変更履歴のＸＭＬデータベースとそこから抽出されて統合ビューアに工場番号、代表部品番号、変更起因部門、変更理由がテーブルとして表示されことを示す。ＸＭＬ形式で保管されるデータは統合ビューア上で表形式として出力し統計に利用できる。また、ＸＭＬデータベース内のレコードが表形式における一行に相当する。またこの場合表示する項目及び項目別は任意特定することができそれによる検索速度の変化などはない。
【００８３】
図１４は図５のステップＳ３２における検索処理の基本となる本発明の対応情報取得アルゴリズムを示すフローチャートである。一般にデータベースはｉ＝０、１、２、・・・の複数行からなる各レコードにｎ個の属性が存在するレコード集合からなる。ｎ個の属性のうち一つをインデックス（ｉ）と定義する。対応情報取得アルゴリズムによるデータベースの検索は入力が指定されたとき、その入力の文字列とレコード内の属性の一つであるインデックスiとの比較によって行われる。そしてインデックス（ｉ）を除く他の（ｎ−１）個の属性情報｛Ｃｉ（１）、Ｃｉ（２）、・・・Ｃｉ（ｎ−１）｝から入力とインデックス（ｉ）とが一致する対応情報Ｃｉ（ｋ）、ｋ-＝１、２、・・・ｍを取得することになる。この場合に入力は複数の属性、例えば、｛工場番号、変更起因部門、変更理由｝であるとき、比較対象であるインデックス（ｉ）も同じ数の属性集合、すなわち｛工場番号、変更起因部門、変更理由｝であると仮定する。この場合もレコード内の他の属性集合｛Ｃｉ（１）、Ｃｉ（２）、・・・Ｃｉ（ｎ−１）｝から対応情報［インデックス（ｉ）、Ｃｉ（ｋ）］を取得できるものとする。
【００８４】
ステップＳ１においてｉ＝０としてデータベース検索の開始アドレスを初期化する。ステップＳ２において、入力とレコードｉ内のインデックス（ｉ）との比較を行い、一致しなければインクリメントして次のレコードｉ＋１に進み、一致していれば指定された入力の文字列に対応するレコードiの存在が確認され、ステップＳ３に移る。このとき後の処理のために一致している数を数えておく。ステップＳ３ではインデックス（ｉ）に対応する属性情報｛Ｃｉ（１）、Ｃｉ（２）、・・・Ｃｉ（ｎ−１）｝を読み出す。得られた属性情報を先頭から検索して要求する対応情報を取得するため、ステップＳ４のｋ＝１で初期化し、ステップＳ５において、Ｃｉ（ｋ）が要求するものでなければｋをインクリメントし、レコードiを探索しつづけ、要求するものであればステップＳ６に移る。ステップＳ６では対応情報［インデックス（ｉ）、Ｃｉ（ｋ）］を読みだす。ステップＳ７のｋの終了に関する判断とステップＳ８のｋに関するインクリメント動作、ステップＳ９のｉの終了に関する判断とステップＳ１０のｉに関するインクリメント動作により、要求する全ての対応情報Ｃｉ（ｋ）を取得することができる。
【００８５】
図１２Ａにおいては、入力＝｛工場番号＝０、変更起因部門「製造」、変更理由「強度不良」｝をキーとし、Ｃｉ（ｋ）＝ＡＡＡとする対応情報｛インデックス（０）ＡＡＡ、）｝｛インデックス（１）、ＡＡＡ｝｛インデックス（３）、ＡＡＡ｝をこの対応情報取得アルゴリズムによって取得している。
【００８６】
図１２Ｂにおいては、入力＝｛工場番号＝０、代表部品番号ＡＡＡ｝をキーとして、Ｃ０（１）＝ＥＸ００１である型番をこの対応情報取得アルゴリズムによって取得している。
【００８７】
図１２Ｃにおいては、入力＝｛部品型番＝ＥＸ００１｝をキーとしてｉ＝０〜１７のレコード集合からｉ＝１７においてＣ１７（１）＝ＥＸ製作のサプライヤコードをこの対応情報取得アルゴリズムによって取得している。ここでｉ＝０ないし１７は（３）−１−１の図において上から下へとレコードに番号を付けたものである。
【００８８】
図１２Ｄにおいては、入力＝｛サプライヤコード＝ＥＸ製作｝をキーとして、ｉ＝０〜１７のレコード集合からｉ＝１４、１５、１６、１７にある対応情報｛ＥＸ製作Ｃ１４（１）＝ＥＸ００１｝、｛ＥＸ製作、Ｃ１５（１）＝ＥＸ００２｝、｛ ＥＸ製作、Ｃ１６（１）＝ＥＸ００３｝、｛ＥＸ製作、Ｃ１７（１）＝ＥＸ００５｝をこの対応情報取得アルゴリズムによって取得している。ここでｉ＝０〜２１は（５）−１−１において図の上から下へとレコードに番号を付けたものである。
【００８９】
図１２Ｅにおいては、入力＝｛部品番号＝ＥＸ００５｝をキーとして、ｉ＝０〜２１のレコード集合から｛Ｃ５（１）＝０（工場番号）、Ｃ５（２）＝ＥＥＥ（代表部品番号）｝、｛Ｃ１４（１）＝２（工場番号）、Ｃ１４（２）＝ＥＥＥ（代表部品番号）｝、｛Ｃ１７（１）＝３（工場番号）、Ｃ１７（２）＝ＥＥＥ（代表部品番号）｝をこの対応情報取得アルゴリズムによって取得している。ここでｉ＝０〜２１は（５）−１−１において図の上から下へとレコードに番号を付けたものである。
【００９０】
図１２Ｆでは、入力＝｛代表部品番号＝ＥＥＥ｝をキーとして、ｉ＝０〜２１のレコード集合から、
｛Ｃ５（１）＝０（工場番号）、Ｃ５（２）＝ＥＸ００５（型番）｝
｛Ｃ１０（１）＝１（工場番号）、Ｃ１０（２）＝ＡＤＤ００５（型番）｝
｛Ｃ１４（１）＝２（工場番号）、Ｃ１４（２）＝ＥＸ００５（型番）｝
｛Ｃ１７（１）＝３（工場番号）、Ｃ１７（２）＝ＥＸ００５（型番）｝
｛Ｃ２０（１）＝４（工場番号）、Ｃ２０（２）＝ＢＩＧ００５（型番）｝
を取得する。
【００９１】
なお、図３に示すシステムにおいて、販売部門からＨＵＢシステム１２の記憶装置に、販売に関するデータをＸＭＬ−６ファイルとしてネットワークを介して集積しても良い。
図１５においてコンピュータシステムは中央処理装置（ＣＰＵ）４０、リードオンリメモリ（ＲＯＭ）４１、ランダムアクセスメモリ（ＲＡＭ）４２、通信インタフェース４３、記憶装置４４、入出力装置４５、可搬型記憶媒体の読取り装置４６、およびこれらの全てが接続されたバス４７によって構成されている。
【００９２】
記憶装置４４としてはハードディスク、磁気ディスクなど様々な形式の記憶装置を使用することができ、このような記憶装置４４、またはＲＯＭ４１に図５のフローチャートに示されたプログラムや、本発明の特許請求の範囲の請求項１のプログラムなどが格納され、そのようなプログラムがＣＰＵ４０によって実行されることにより、本実施形態における工場側で行われた設計変更のデータを含む設計データの一元管理、正確な変更履歴のトレースなどが可能となる。
【００９３】
このようなプログラムは、プログラム提供者４８からネットワーク４９、および通信インタフェース４３を介して、例えば記憶装置４４に格納されることも、また市販され、流通している可搬型記憶媒体５０に格納され、読取り装置４６にセットされて、ＣＰＵ４０によって実行されることも可能である。可搬型記憶媒体５０としてはＣＤ−ＲＯＭ、フレキシブルディスク、光ディスク、光磁気ディスク、ＤＶＤなど様々な形式の記憶媒体を使用することができ、このような記憶媒体に格納されたプログラムが読取り装置４６によって読取られることにより、本実施形態における設計データの一元管理などが可能となる。
【００９４】
以上詳細に説明したように、本発明によれば、新規設計のデータや設計変更データを一元的に管理することが可能となり、正しい設計変更履歴のトレースが可能となる。例えば工場側で行われた部品代替のデータも設計変更データとして蓄積されることによって、例えば他の生産部門においてそのデータを参照することも可能となり、従来は部品代替が行われた工場以外に対しては失われていた情報を検索するという新しい業務も生み出すものであり、応用上も大変意義が大きい。さらに、製品に不具合があるとき問題の原因となっている部品を推測し、その部品を供給するサプライヤ自身に問題がないか判断できる。
【００９５】
（付記１）  設計側で作成された設計データに基づいて生産側で製品の製造が行われるシステム内の計算機によって用いられるプログラムであって、
設計側で作成された設計データを生産側に適するデータ形式に変換して生産側に送るとともに、該作成された設計データを予め定められた言語で記述されたデータに変換して記憶装置に格納する手順と、
設計側で作成された設計データの変更通知を生産側から受けたとき、該設計変更データを前記予め定められた言語で記述されたデータに変換して前記記憶装置に格納する手順とを計算機に実行させることを特徴とする設計データ管理プログラム。
（付記２）  前記予め定められた言語がＸＭＬであることを特徴とする付記１記載の設計データ管理プログラム。
（付記３）  前記ＸＭＬによって記述されたデータが、製品の個々の部品のコードデータに対して、該部品に関する各種のデータとしてのマスタデータを結合させた形式で前記記憶装置に格納されることを特徴とする付記２記載の設計データ管理プログラム。
（付記４）  設計側で作成された設計データに基づいて生産側で製品の製造が行われるシステム内の計算機によって用いられるプログラムであって、
設計側で作成された設計データと、該設計データに対して生産側で行われた設計変更のデータとが、ともに予め定められた言語で記述されたデータに変換されて記憶されている記憶装置からデータを読み出す手順と、
与えられた検索条件にしたがって、該読み出されたデータを検索し、該検索の結果を設計データ変更履歴として表示装置の画面上に表示する手順とを計算機に実行させることを特徴とする設計データトレースプログラム。
（付記５）  前記予め定められた言語がＸＭＬであることを特徴とする付記４記載の設計データトレースプログラム。
（付記６）  設計側で作成された設計データに基づいて生産側で製品の製造が行われるシステム内の計算機によって用いられる記憶媒体であって、
設計側で作成された設計データを生産側に適するデータ形式に変換して生産側に送るとともに、該作成された設計データを予め定められた言語で記述されたデータに変換して記憶装置に格納するステップと、
設計側で作成された設計データの変更通知を生産側から受けたとき、該設計変更データを前記予め定められた言語で記述されたデータに変換して前記記憶装置に格納するステップとを計算機に実行させる設計データ管理プログラムを格納した計算機読出し可能可搬型記憶媒体。
（付記７）  設計側で作成された設計データに基づいて生産側で製品の製造が行われるシステム内の計算機によって用いられる記憶媒体であって、
設計側で作成された設計データと、該設計データに対して生産側で行われた設計変更のデータとが、ともに予め定められた言語で記述されたデータに変換されて記憶されている記憶装置からデータを読み出すステップと、
与えられた検索条件にしたがって、該読み出されたデータを検索し、該検索の結果を設計データ変更履歴として表示装置の画面上に表示するステップとを計算機に実行させる設計データトレースプログラムを格納した計算機読出し可能可搬型記憶媒体。
（付記８）  設計側で作成された設計データに基づいて生産側で製品の製造が行われるシステムにおいて用いられる方法であって、
設計側で作成された設計データを生産側に適するデータ形式に変換して生産側に送るとともに、該作成された設計データを予め定められた言語で記述されたデータに変換して記憶装置に格納し、
設計側で作成された設計データの変更通知を生産側から受けたとき、該設計変更データを前記予め定められた言語で記述されたデータに変換して前記記憶装置に格納することを特徴とする設計データ管理方法。
（付記９）  生産側で用いられる部品の購買に関する情報を定められた言語で記述されたデータに変換して購買側から前記記憶装置に格納する手順をさらに有することを特徴とする付記１記載の設計データ管理プログラム。
（付記１０）  生産側で設計変更の多い部品を特定する第１の手順と、
該部品のサプライヤを特定する第２の手順を有することを特徴とする付記９記載の設計データ管理プログラム。
（付記１１）  前記生産側で設計変更の多い部品を特定する第１の手順は、
前記記憶装置に記憶された設計変更履歴情報に対して、工場を特定する情報と設計変更起因部門を特定する情報と設計変更理由を特定する情報を指定し、上記特定工場で設計変更の多い部品を特定する情報を取得する手順とからなる付記１０記載の設計データ管理プログラム。
（付記１２）  前記部品のサプライヤを特定する第２の手順は、
前記記憶装置に記憶された生産部品表から、工場を特定する情報と設計変更のある部品を特定する情報を指定して型番を取得する手順と、
前記記憶装置に記憶された購買部門データベースに対して型番を特定する情報を指定してその型番を供給するサプライヤを特定する情報を取得する手順とからなる付記１０記載の設計データ管理プログラム。
（付記１３）  前記設計変更の多いサプライヤから供給される他の部品の生産側での設計変更の回数を検出する第３の手順と、
前記他の部品についての他のサプライヤの設計変更回数を検出する第４の手順と、
当該サプライヤと他のサプライヤとの前記他の部品についての設計変更の回数を比較する第５の手順とからなる付記９記載の設計データ管理プログラム。
（付記１４）  前記第３の手順は、
購買部データベースに対して逆に前記設計変更のあるサプライヤを特定する情報を指定し、そのサプライヤの他の型番を特定する情報を取得する第６の手順と、
生産部品を用いて他の型番のうち一つの型番を指定し、部品を特定する情報を取得する第７の手順と、
該生産部品表に、該部品を指定し、その部品に対応する工場毎の部品と型番の対応を取得する第８の手順と、
設計変更履歴に対して、特定のサプライヤの型番を扱う工場の工場番号と部品を指定して、前記同じ部品の型番毎の設計変更回数を取得する第９の手順とからなり、
前記第４の手順は、
前記第９の手順において、前記部品に対応する他のサプライヤの型番を扱う工場番号と前記他の部品を指定して、前記他のサプライヤの前記型番の設計変更回数を取得する第１０の手順からなる付記１３記載の設計データ管理プログラム。
（付記１５）  前記設計変更回数の特定は、前記記憶装置に記憶されて設計変更情報に対して工場番号と部品を指定することにより、設計変更起因部門とその設計変更理由を特定することにより行う付記１０及び１３記載の設計データ管理プログラム。
（付記１６）  設計側のシステムと生産側のシステムと購買側のシステムと前記記憶装置が設けられたハブシステムの間でネットワークを介して情報を送受信する手順をさらに含んでなる付記９から１４記載の設計データ管理プログラム。
（付記１７）  設計変更履歴、生産部品表、あるいは購買データベースをＸＭＬ言語で記述し、表形式のビューアで表示する付記９から１４記載の設計データ管理プログラム。
（付記１８）  生産側で用いられる部品の販売に関する情報を定められた言語で記述されたデータに変換して販売側から前記記憶装置に格納する手順をさらに有することを特徴とする付記９記載の設計データ管理プログラム。
【図面の簡単な説明】
【００９６】
【図１】本発明の設計データ管理プログラムの原理的な機能ブロック図である。
【図２】本発明の第１の実施の形態に係る設計データ管理方式、およびトレース方式のシステムの全体構成図である。
【図３】本実施形態における新規設計データ、および設計変更データの流れを説明する図である。
【図４】履歴情報データベースに格納されるデータの形式を説明する図である。
【図５】本実施形態における処理のフローチャートである。
【図６】Ａ工場で行われた設計変更の履歴を示す図である。
【図７】Ｂ工場で行われた設計変更の履歴を示す図である。
【図８】設計変更理由の集計結果を示す図（その１）である。
【図９】設計変更理由の集計結果を示す図（その２）である。
【図１０】本発明の第２の実施の形態に係るシステム構成図である。
【図１１Ａ】ある工場について変更が多い部品のサプライヤを指定するフローチャートである。
【図１１Ｂ】特定したサプライヤについて、その部品だけが問題なのかサプライヤ自身に問題があるかを判断するフローチャートである。
【図１２Ａ】ある工場について変更が多い部品のサプライヤを指定するフローチャートである。
【図１２Ｂ】ある工場について変更が多い部品のサプライヤを指定するフローチャートである。
【図１２Ｃ】ある工場について変更が多い部品のサプライヤを指定するフローチャートである。
【図１２Ｄ】特定したサプライヤについて、その部品だけが問題なのかサプライヤ自身に問題があるかを判断するフローチャートである。
【図１２Ｅ】特定したサプライヤについて、その部品だけが問題なのかサプライヤ自身に問題があるかを判断するフローチャートである。
【図１２Ｆ】特定したサプライヤについて、その部品だけが問題なのかサプライヤ自身に問題があるかを判断するフローチャートである。
【図１２Ｇ】特定したサプライヤについて、その部品だけが問題なのかサプライヤ自身に問題があるかを判断するフローチャートである。
【図１２Ｈ】特定したサプライヤについて、その部品だけが問題なのかサプライヤ自身に問題があるかを判断するフローチャートである。
【図１２Ｉ】特定したサプライヤについて、その部品だけが問題なのかサプライヤ自身に問題があるかを判断するフローチャートである。
【図１３】データベースから表形式にビューアに表示する処理の説明図である。
【図１４】記憶装置から特定の情報を指定して対応情報を取得するフローチャートである。
【図１５】本発明を実現するためのプログラムのコンピュータへのローディングを説明する図である。
【符号の説明】
【００９７】
１０  設計システム
１１  生産管理システム
１２  ＨＵＢシステム
１３  履歴管理部
１５  ＸＭＬ−１ファイル
１６、１８、２０、２２、２６、２８  データボックス
１７  データ転送実行部
１９  ＸＭＬ中間ファイル
２１  データ送受信部
２３  ＸＭＬ−２ファイル
２４  ＸＭＬ−４ファイル
２７  データ受信部
２９  ＸＭＬ−３ファイル
３０  履歴情報データベース
４０  ＣＰＵ
４１  ＲＯＭ
４２  ＲＡＭ
４３  通信インターフェース
４４  記憶装置
４５  入出力装置
４６  読取装置
４７  バス
４８  プログラム提供者
４９  ネットワーク
５０  可搬型記憶媒体
【図１】
2007026430.tif 000003
【図４】
2007026430.tif 000004
【図５】
2007026430.tif 000005
【図１１Ａ】
2007026430.tif 000006
【図１１Ｂ】
2007026430.tif 000007
【図１３】
2007026430.tif 000008
【図１４】
2007026430.tif 000009
【図１５】
2007026430.tif 000010
【図２】
2007026430.tif 000011
【図３】
2007026430.tif 000012
【図６】
2007026430.tif 000013
【図７】
2007026430.tif 000014
【図８】
2007026430.tif 000015
【図９】
2007026430.tif 000016
【図１０】
2007026430.tif 000017
【図１２Ａ】
2007026430.tif 000018
【図１２Ｂ】
2007026430.tif 000019
【図１２Ｃ】
2007026430.tif 000020
【図１２Ｄ】
2007026430.tif 000021
【図１２Ｅ】
2007026430.tif 000022
【図１２Ｆ】
2007026430.tif 000023
【図１２Ｇ】
2007026430.tif 000024
【図１２Ｈ】
2007026430.tif 000025
【図１２Ｉ】
2007026430.tif 000026