JP4239767B2 - 設計変更支援システムおよび設計変更方法ならびに設計変更支援プログラムおよびそれを記録した記録媒体 - Google Patents

Description

本発明は、複数の部品や材料から構成される製品の設計変更支援技術に関し、特に、製品を構成する部品や材料の変更に起因して発生する設計変更を支援する技術に関する。

背景技術としては、突発的に部品の入庫状況や受注情報の変更が起きた場合に、一時的に破綻した需給バランスを速やかに回復させることを目的とした突発事象対応支援システムが特許文献１に記載されている。この発明は、変更情報に基づくMPSを複数の緊急度に対して各々用意し、MPS毎にMRP計算を行い、各々の部品受払結果を出力し、それらを比較することにより問題の内容とその緊急度を判定するというものである。また、この発明においては、受払のシミュレーションにより仮の対策の救済効果を確認し、実際の対策を立案する。設計変更をしなければならない場合には、PDM等の入力装置から部品表を仮に編集して設計変更案を作成し、設計変更情報をSCMシステムに渡して変更を適用した状態でMRP計算し、出力結果を入力装置に戻し、事前に設計変更の影響を確認するようにしている。

特開2003-242326号公報

生産の現場では、部品や材料（以下、部材）の変更に起因する設計変更が頻繁に生じる。設計変更が生じると、設計変更後の製品の生産を開始する前に、変更部材の全てと、それらを用いて製造する製品についてテストを行う必要がある。

従来から、このような部材の変更に伴う設計変更を支援するため、背景技術で述べたような発明がなされていたが、近年の国際的な環境規制が進む中で、設計変更の機会および変更が必要な部材の数が激増してきている。例えば、EU(欧州連合)においてはRoHS指令により、2006年７月以降、特定の化学物質を含んだ製品は販売できなくなる。そのため、EUおよびEU向けの製品を製造しているメーカでは、特定の化学物質を含まない部材に設計変更する動きが活発になってきている。このような設計変更の機会および変更が必要な部材の増加は、実際の設計開発プロセスの様々な工程で作業負荷を増大させる。特にそれは製品テスト工程およびその前後の工程では顕著に表れる。さらに同時にそれらの工程では部材在庫の過不足問題も顕著に表れる。

また、設計変更部材は、一般的に納期遅延する可能性が高いという特性がある。そのため設計者は、新部材の注文と同時期に、設計変更前に用いていた旧部材も手配をかけることにより納期遅延に対応する。その結果、作業負荷増大と在庫過不足の問題は、さらに増幅されることになる。

本発明は、上記のような課題を解決するためになされたもので、その目的は、部材の設計変更に起因する設計開発工程の負荷を低減し、新部材と旧部材の双方の在庫の過不足問題を解消するとともに、部材切り替え時期の決定、製品テスト工程の決定の支援をすることにある。

上記課題を解決するため、本発明の設計変更支援システムは、入力部、出力部、記憶部、処理部を有し、記憶部には、製品および部材に関する情報を格納したプロファイルデータと、部材について設計変更前の旧部材と設計変更後の新部材との関連を記憶した代替関係データと、各部材の在庫、消費、納入の現状および予定に関するデータが記憶されており、処理部が、プロファイルデータに格納された各部材についての少なくとも調達拠点からの納入リードタイムを読み出し、入力部から製品テスト予定日が入力されると、入力された製品テスト予定日をもとに、該製品テストに必要な部材の注文を行うとともに前記代替関係データを参照して代替部材の消費予定の算出を行い、記憶部に記憶された各部材の納入および在庫状況データおよび代替関係データを用いて製品テスト予定日近辺においてテスト可能な製品の部材構成およびテスト着手日を含むテスト構成案を１つ以上立案して出力部に出力し、入力部よりテスト構成の選択結果を受け付け、入力部から入力された製品テストの結果に基づいて、設計変更が可能と判断された製品の部材構成について、記憶部に保持されている各部材の在庫および消費に関するデータを用いて部材切替の有効性を評価し、１つ以上の部材切替予定日案を立案して出力部に出力し、入力部より部材切替予定日案の選択結果を受け付け、選択された部材切替予定日案において、記憶部の部材の納入および在庫状況に関するデータを用いて部材切替の有効性を評価し、評価結果を前記出力部に出力するようにしたものである。

また、本発明の設計変更支援システムでは、処理がある決められたサイクルで起動され、記憶手段から各種機能を実現するプログラムと、各種データが処理部に読み込まれ、１回以上各種計算処理が実行されるものである。

本発明によれば、製品テスト作業や部材調達作業等を効率化させ、その方法のシステム化によって作業負荷低減を図ることができる。また、新部材と旧部材の双方の在庫の過不足問題を解消するとともに、製品テスト時期の決定、部材切替時期の決定の支援をすることができる。

以下に本発明の実施形態について説明する。
まず、本発明の一実施形態の適用対象として想定している物流・情報流ネットワークモデルについて説明する。
（１）本発明の一実施形態の適用対象として想定している物流・情報流ネットワークモデル
本発明の一実施形態の適用対象として想定している物流・情報流ネットワークモデルを説明する図を図１に示す。
本実施の形態においては以下、製品、部材、半製品、仕掛品、原材料などの総称またはいずれかを指すものとしてアイテムという言葉を用いる。このアイテムという言葉を用いて、例えば製品に対してその製品を構成する部材、半製品、仕掛品、原材料のことを下位アイテム、下位アイテムを組み立てて製造した部材、半製品、仕掛品、製品等を上位アイテムというように表現する。ただし、以下の実施の形態においては、上位アイテムという場合には、主に製品を指す。

図１に示す物流・情報流ネットワークモデルは、上位アイテムの設計やテストなど行う上位アイテム開発拠点α101と、上位アイテム開発拠点α101から、開発した内容に基づき下位アイテムの見積依頼や注文を受けて下位アイテム調達拠点γ103に下位アイテムの見積依頼や注文を出すとともに、下位アイテム調達拠点γ103から納入された下位アイテムの在庫管理を行う下位アイテム在庫拠点β102と、上記見積依頼や注文などを受けて、下位アイテム在庫拠点β102に下位アイテムを納入する調達拠点γ103と、下位アイテム在庫拠点β102から下位アイテムの移管を受けて上位アイテムを生産し、市場εに出荷する上位アイテム生産拠点δ104からなる。

図１に示したこのモデルにおける、アイテムの流れを説明する。以下の三つの流れがある。
一つめは、通常のサプライチェーンの流れである。下位アイテム調達拠点γ103からアイテムが下位アイテム在庫拠点β102に納入され、上位アイテム生産拠点δ104からの指示でその納入されたアイテムが移管され、その移管されたアイテムを基に上位アイテム（製品）を生産し，市場εで販売する。
二つめは、上位アイテムのテスト等を行う流れで、上位アイテム開発拠点αからの指示で下位アイテム在庫拠点β102からアイテムが移管され、その移管されたアイテムを基に上位アイテムのテスト等を行う。
三つめは、下位アイテム在庫拠点β102から下位アイテム処分拠点ζに流れる流れである。なお、下位アイテム処分拠点ζは、下位アイテム在庫拠点β102において処分することとなった下位アイテムの処分先である。
本発明は、このうち主に二つ目の流れにおける上位アイテムのテストと、一つ目の流れにおける下位アイテム在庫拠点β102における下位アイテムの在庫管理に関するものである。

次に、本発明の一実施形態のシステム構成およびハードウェア構成について説明する。
（２）本発明の一実施形態のシステム構成およびハードウェア構成
本発明の一実施形態のシステム構成を図２に示す。
本実施形態においては、設計変更支援システム200は、ネットワークを介して接続された複数のサブシステムで構成され、以下に説明する各種機能はこれら複数のサブシステムのそれぞれにおいて分散処理される。

設計変更支援システム200のサブシステムのうち、マシンα201は上位アイテム開発拠点α101にある情報処理マシンで、設計変更作業の進捗情報などの管理を行う。マシンβ202は下位アイテム在庫拠点β102にある情報処理マシンで、見積依頼履歴、注文履歴および在庫状況などの情報を管理する。マシンγ203は下位アイテム調達拠点γ103にある情報処理マシンで、見積回答履歴や納入予定などの情報を管理する。マシンδは上位アイテム生産拠点δ0104にある情報処理マシンで、アイテムの消費予定などの情報を管理する。マシンηは他のマシンを統合管理する情報処理マシンである。

本発明による設計変更支援システムは、このようにそれぞれのマシンで分散処理する形態に限らず、一つのマシンで集中処理する形態によって実現してもよい。また、それぞれのマシン機能の一部を組み換えたり、小分けにしたり、まとめたりして実現してもよい。また、本実施形態では、設計変更支援システムを独立に構築されるシステムとして説明するが、本発明はこれに限定されるものではない。本発明は他の情報処理システムに組み込まれてそれら一部として機能するように構成することも考えられる。

次に、本発明の一実施形態の設計変更支援システムのハードウェア構成について説明する。
（３）本発明の一実施形態の設計変更支援システムのハードウェア構成
本発明の一実施形態の設計変更支援システムのハードウェア構成を図３に示す。
図２において説明したように、本実施形態の設計変更支援システム200は、複数の情報処理マシンがネットワークを介して接続されて構成される。

各情報処理マシンは、キーボードやマウス等の入力装置301とディスプレイ等の出力装置302と補助記憶装置304と設計変更支援プログラムを実行する処理装置303とを有する。処理装置303はインタフェース3031と中央演算処理装置（以下、ＣＰＵ）3032と主記憶装置3033とを備え、入力装置301出力装置302および補助記憶装置304とインタフェース3031を介して接続されている。

本実施形態では設計変更支援プログラムの処理結果は主記憶装置3033に確保された記憶領域に記憶する。プログラムは補助記憶装置304に予め保持されて主記憶装置3033に読み込まれ、そのプログラムをＣＰＵ3032が実行することにより各種機能を実現する。

また、本実施形態では設計変更支援システムが汎用情報処理装置とソフトウェアで実現される場合を例にとって説明するが、例えば、ハードワイヤードロジックを含むハードウェアや、このようなハードウェアと、予めプログラムされた汎用情報処理装置により実現してもよい。

次に、設計変更支援システムの機能について説明する。
（４）設計変更支援システムの機能と、システムで使用するコード及びデータ
本発明の一実施形態の設計変更支援システム200が有する機能を説明する図を図４に示す。
図４には、ひとつの情報処理マシンが、設計変更支援システム200のすべての機能とデータおよびコードを有する場合の例である。図４に示すような構成は、例えば図２の他の情報処理マシンを統合管理するマシンη205にすべてのプログラムとデータ、コードを格納しておいてここで集中処理を行なうような場合や、各拠点の情報処理マシンが必要に応じてこの統合管理マシンη205にネットワークを介してアクセスし、必要なプログラムや必要なデータを読み出して分散処理するような場合に用いられる。
この他、各拠点の情報処理マシンそれぞれに、全ての機能、データ、コードを持たせる構成にすることも、それぞれに必要な機能だけ持たせる構成にすることも考えられる。

図４に示すように、設計支援システム200においては、補助記憶装置304に記憶した各種情報に基づき、処理装置303においてプログラムを実行することにより、アイテムプロファイル管理機能、設計変更進捗管理機能、アイテムツリー構造管理機能、代替アイテム構造管理機能、アイテムテスト予定日設定機能、代替アイテム消費制御機能、在庫推移算出機能、アイテムテスト構成立案機能、アイテム切替予定日立案機能、アイテム切替判定機能などの機能を実現する。これらの各機能を実現する処理内容の詳細については処理フローの説明の中で順を追って説明する。

本実施の形態では、補助記憶装置304にはコード記憶部とデータ記憶部とを設けている。コード記憶部には、各種機能を実現する処理プログラム、アイテムツリー構造コード、代替アイテム構造コード、在庫容量コード、アラーム容量コード等、内容の変更の頻度が低い、基本的なデータを保持している。一方データ記憶部には、アイテムプロファイルデータ、設計変更進捗データ、切替リードタイムデータ、稼働日カレンダデータ、ユーザリストデータ、図面データ、納入検査リードタイムデータ、消費予定データ、納入予定データ、在庫実績データ、アイテムテスト構成データ等、各種処理やデータ入力等によりデータの書き換え頻度が比較的高いものを保持する。

ここで、補助記憶装置304のコード記憶部とデータ記憶部に格納されているコードおよびデータのいくつかについて説明を補足する。
まず、アイテムツリー構造コード、代替アイテム構造コードについて説明する。
（４．１）アイテムツリー構造コード
本実施形態でのアイテムツリー構造のイメージ図および格納データの構成を図６に示す。アイテムXおよびアイテムYは最上位のアイテム（製品）である。アイテムa0などのそれ以外のアイテムは最上位アイテムを構成するためのアイテム（部材）である。アイテムツリー構造データは、上位アイテム毎に、下位アイテムとその下位アイテムの上位アイテムに対する員数などが格納されている。
（４．２）代替アイテム構造コード
本実施形態における代替アイテム構造のイメージ図および格納データの構成を図７に示す。この図で、アイテムa0とアイテムa1は代替関係にある。アイテムatはアイテムa0とアイテムa1の共通名である。また、アイテムa01とアイテムa11も代替関係にあり、アイテムat1はアイテムa01とアイテムa11の共通名である。共通名アイテムat、アイテムat1は、代替関係にあるアイテムを総合して在庫管理を行う場合等に用いられるものである。

次に、在庫容量コードとアラーム容量コードについて説明する。
（４．３）在庫容量コードとアラーム容量コード
本実施形態での在庫容量コードとアラーム容量コードを図８に示す。アラーム容量とは、アラームを発報する在庫下位限界量で、アイテム毎に設定されている。在庫容量とは、それ以上在庫を補充できない上限値に相当する。図８に示す例では、アイテムそれぞれの在庫容量はアイテムc01が１００個、アイテムc02が２００個、アイテムc03が３００個である。また、アラーム容量は、アイテムc01が１０個、アイテムc02が１００個、アイテムc03が３０個である。

次に、補助記憶装置304に記憶されている在庫実績データのテーブル構造について説明する。
（４．４）在庫実績データ
本実施形態において在庫状況を示す在庫実績データのテーブル構造を図９に示す。テーブルには、拠点カラム、アイテム番号カラム、在庫数量カラム、単位カラムなどを備える。拠点カラムには、在庫管理をしている拠点名が保持される。開発拠点α101の場合は「α」、在庫拠点β102の場合は「β」、調達拠点γ0103の場合は「γ」、生産拠点δ104の場合は「δ」が保持される。アイテム番号カラムにはアイテムの番号が保持される。在庫数量カラムにはアイテムの在庫数量が保持される。単位カラムには在庫をカウントする際の単位が保持される。例えば、在庫拠点β102のアイテムc11の単位は「個」である。

次に、補助記憶装置304に記憶される消費予定データのテーブル構造ついて説明する。
（４．５）消費予定データ
本実施形態での消費予定データのテーブル構造を図９に示す。テーブルには、アイテム番号カラムと、消費予定カラムなどを備える。アイテム番号カラムには、アイテム番号が保持される。例えば、ｃ01、ｃ02、c03などが保持される。消費予定カラムには、現在より未来にわたって発生する消費予定量が保持される。例えば、アイテム番号ｃ01では、４月21日に０個、４月22日に４個、４月23日に５個、・・・が保持されている。

次に、設計変更支援システムの処理シーケンスについて説明する。
（５）設計変更工程
本発明の一実施形態における設計変更支援システムが用いられる設計変更工程を示す図を図５に示す。ここでは特に処理拠点を分けずに、設計変更工程を一本のシーケンスで示している。このシーケンスは、設計変更を計画する日（本実施の形態では2004年1月16日と設定している）から、変更後のアイテムの仕様を登録し（2004/03/01）、必要な部材の見積もりをし（2003/03/05）、テストの計画を立案し（2004/03/31）、テストに着手し（2004/04/25）、その結果を受けて部材の切り替えを行い（2004/05/30）、アイテムをリリース（2004/07/01）するまでの工程の流れを示すものである。
本実施の形態で説明する設計変更は、製品のある部材の仕様変更と新規部材の追加という２点の変更に伴う設計変更を例にとって説明する。

まず、設計変更計画日に行う処理である設計変更計画ステップ501について説明する。
（５．１）設計変更計画ステップ
設計変更ステップ501は、アイテムYという製品のリリース予定日の設定、アイテムY構成の設定、アイテムYを設計する担当者の設定などを行うステップである。なお、本実施形態ではそれらの設定を行う設計変更計画日を2004年１月16日と設定している。このステップ501の処理内容を、図10ないし図14を用いて説明する。図10ないし図14は、画面の出力イメージを追いながら、その画面出力を得るために起動される機能、およびその機能を実行する際に読み出されるデータを図示し、ステップ501の処理内容を説明する図である。

まず、アイテムプロファイル管理機能が起動され、データ記憶部に記憶されたアイテムプロファイルを読み出す、続いて設計変更進捗管理機能が起動され、データ記憶部から設計変更進捗データを読み出し、それらのデータを画面に表示する。アイテムプロファイルは、画面表示イメージの1001に示すように、設計変更案件毎に設定された設計変更番号、設計変更の対象製品名称、その製品のリリース予定日、設計責任者、アイテムテストの予定日などが保持されているデータである。設計変更進捗データの内容はここには図示していないが、設計変更番号ごとにその設計変更案件に関する情報（その製品を構成する下位アイテムの名称やその担当者、各下位アイテムの進捗情報等）が保持され、それらの情報を基に、予め決めておいた計算方法で総合的な進捗を計算し、100分率で表しているのが図10の1002である。

次に、画面1000の新規作成ボタンをクリックすると、設計変更進捗管理機能により新しい設計変更案件を登録するための画面が表示される(1010)。登録画面1010には、新しい設計変更案件の対象製品の製品構成を表示するための領域1011と（まだ製品構成は登録されていないので空欄）製品リリース予定を登録するための領域1012が表示される。製品リリース予定を登録するための領域1012には、現在の日付けが表示されている。

これに続く処理内容を、図11を用いて説明する。図11の画面表示イメージ1010は、図10の画面表示イメージ1010と同一である。領域1011の参照ボタンをクリックすると、アイテムプロファイル管理機能が起動され、データ記憶部のアイテムプロファイルを参照し既に登録されているアイテムのプロファイルが表示される（1100）。表示されたアイテムのうちあるアイテム（ここではアイテムX）を選択すると、アイテムツリー構造管理機能はコード記憶部のアイテムツリー構造を参照しアイテムXのツリー構造を表示する（1111）。コード記憶部のアイテムツリー構造コードには、アイテム毎にそのアイテムの下位アイテム名と各下位アイテムの設計担当者などが保持されていて、画面上にそれらの情報を表示する。

図12に移り、今回の設計変更は、新規アイテムの追加とアイテムの変更であるので、まず追加するアイテムの上位のアイテムであるアイテムXをクリックする。するとアイテムツリー構造管理機能が起動され、構成編集領域1201が表示される。ここで、構成編集領域のアイテム追加ボタンをクリックすると、アイテム追加登録領域が表示される。ここに追加する子アイテムの名称、そのアイテムの設計担当者、追加理由等を入力した後、追加ボタンをクリックすると、アイテムツリー構造管理機能が起動され、下位アイテムの追加後の製品構成が表示される。次に、更新するアイテムであるアイテムc0をクリックする。すると同様に、アイテムツリー構造管理機能が起動され、構成編集領域1201が表示される。ここでアイテム更新ボタンをクリックすると、アイテム更新領域が表示される。ここに更新内容を入力した後、更新ボタンをクリックすると、アイテムツリー構造管理機能が起動され、下位アイテムの更新後の製品構成が表示される。下位アイテムの追加、変更後の部材構成を図12の1210に示す。図12の1210は、先に行ったアイテムd1およびアイテムc1の追加、更新の他に、アイテムa1およびアイテムb1の更新も行った後の画面である。

図13に移り、アイテムXの下位アイテムを追加変更したアイテムの登録を行う。登録ボタンをクリックすると、設計変更計画登録領域1301が表示される。ここで、設計変更後の新しい製品の製品名称、製品リリース日、設計責任者等を入力する。登録ボタンをクリックすると、設計変更進捗管理機能が起動され、設計変更進捗データに新たな設計変更計画として設計変更番号が付与されて登録されるとともに、コード記憶部のアイテムの切替のリードタイムおよび各拠点の稼働日カレンダを参照し、製品リリース予定日から逆算して最終切替着手日を算出する。算出された最終切替着手日は設計変更進捗データに保持される。また、アイテムツリー構造管理機能、代替アイテム構造管理機能により、アイテムツリー構造コードにアイテムが追加され、代替アイテム構造コードに代替関係が登録される。さらに登録内容を受けて、アイテムプロファイル管理機能によりアイテムプロファイルが更新される。そして、設計変更番号、登録後のアイテム名称（アイテムY）、最終切替着手日、アイテムリリース予定日を表示する。

そして、図14に移り、製品リリース予定領域1312の送信ボタンをクリックすると設計変更進捗管理機能によりデータ記憶部のユーザリストを参照して関係先の各拠点のマシンにアイテムYの製品のリリース予定日の設定、構成の設定、設計担当者の設定などの情報を送信する。そして、設定情報を共有するとともに必要に応じて関係拠点において審査、承認を行った場合その結果を受けて設計変更計画処理が完了したとしてデータ記憶部の設計変更進捗データを更新し、更新後の進捗を100分率で表し、画面に表示する。（1400）
次に、アイテムYの下位アイテムの仕様を登録する処理について説明する。
（５．２）アイテム仕様登録ステップ
アイテム仕様登録ステップ502は、アイテムYの下位アイテムの仕様をマシンに登録するステップ（図５ 502）である。本実施形態ではこのアイテム仕様登録日を2004年３月１日と設定している。このステップ502の処理内容を図15ないし図18を用いて説明する。このステップは、ステップ501の処理結果を受信した拠点（開発拠点）において、そのアイテムの担当者が担当するアイテムの仕様を入力し、その入力を受けて行われるステップである。

まず、仕様を入力する対象の設計変更案件の番号をクリックすると、アイテムツリー構造管理機能が起動されアイテムツリー構造コードを参照して選択された設計変更番号のアイテムYを部品展開する。続いて設計変更進捗管理機能により設計変更進捗データを参照してアイテムYを構成する各下位アイテムについて担当者、進捗状況の情報を表示する。本実施の形態においては、開発拠点において仕様の入力を行う担当者は、アイテムc1の担当者（倉谷）であるとして説明する。

まず、担当者がアイテムc1をクリックすると、アイテムツリー構造管理機能、代替アイテム構造管理機能が起動される。アイテムツリー構造管理機能、代替アイテム構造管理機能はアイテムツリー構造、代替アイテム構造を参照して処理を行う。続いてアイテムプロファイル管理機能、設計変更進捗管理機能が起動される。アイテムプロファイル管理機能、設計変更進捗管理機能は、データ記憶部のアイテムプロファイル、設計変更進捗を参照して処理を行う。そして、アイテム仕様一覧画面として、アイテムc1のアイテムプロファイルデータ、アイテムc1と代替関係にあるアイテムc0のプロファイルデータ、設計変更進捗から読み出した進捗等を表示する。アイテムc1のプロファイルデータは、これから登録するので各項目は空欄となっている。

図17に移り、アイテムc1のプロファイルデータの登録処理について説明を続ける。ここで、アイテムc1のプロファイルデータを登録する際、代替関係にあるアイテムc0のプロファイルデータを雛型として参照しながら入力しようと、参照ボタンをクリックしたとする。すると、アイテムプロファイル管理機能によりデータ記憶部のアイテムプロファイルが参照されて旧アイテムプロファイル画面として、アイテムc0の子アイテムのリストが領域1701に表示される。領域1701においてアイテムc01を選択すると、アイテムプロファイル管理機能によりデータ記憶部の画面データ等を参照し、選択したアイテムc01が旧アイテムとして表示され、その内容のコピーが新アイテム欄に表示される。アイテムc01のアイテムプロファイルを雛型として表示されたアイテムc11のプロファイルデータを必要に応じて修正する。また、図面の読み込みボタンをクリックすることで図面番号11cの図面をアイテムc11に対応付けられる。

図18に移り、登録ボタンをクリックするとアイテムプロファイル管理機能によりこの内容がアイテムプロファイルに登録され、アイテムツリー構造管理機能、代替アイテム構造管理機能により、アイテムツリー構造、代替アイテム構造にアイテムc11およびアイテムc01との関係が登録される。そして、このアイテム登録処理結果は、設計変更進捗管理機能によりデータ記憶部のユーザリストを参照して関係拠点のマシンに送信される。必要に応じで審査承認を受け、その結果を受けてアイテム仕様登録処理が完了したとして設計変更進捗の更新が行われる。そして、更新後の進捗データが画面に表示される。

次に、登録されたアイテムの見積依頼書を発行する処理について説明する。
（５．３）見積依頼書発行ステップ
見積依頼書発行ステップ503は、登録されたアイテム仕様を基に担当者が入力したそのアイテムを調達する調達先に対し、見積依頼書を発行するための処理を行うステップである。本実施形態ではこの見積依頼日を2004年３月５日と設定している。
このステップ503の処理内容を、図19および図20を用いて説明する。

先ず、設計変更進捗画面を表示する。アイテムc1の進捗は、仕様設計が終わった段階であり、次の処理は見積依頼である。ここで見積依頼書一覧ボタンをクリックすると、アイテムプロファイル管理機能により、データ記憶部のアイテムプロファイルを参照し、見積依頼書一覧にアイテムプロファイルから取得したデータを表示する。この見積依頼書一覧には、調達先という欄があるが、このステップではこの調達先の選定を受けて処理を行う。見積依頼書一覧のアイテムc11を選択すると、アイテムプロファイル管理機能により見積申請書画面が表示される。図20に移り、ここで調達先としてγを入力し、登録をクリックすると選定された調達拠点をアイテムc11のアイテムプロファイルに保持する。それとともに見積申請情報を、ユーザリストを参照して、関係拠点のマシンに送信する。必要に応じて審査承認を経た後、見積依頼書発行処理まで完了したとして設計変更進捗データが更新される。

次に、アイテムのテスト計画の設定処理について説明する。
（５．４）アイテムテスト計画設定ステップ
アイテムテスト計画設定ステップ504は、アイテムのテスト予定日の設定と、テストに必要な下位アイテムの注文処理を行うステップである。また、ステップ504は設計変更部材などの新部材は一般的に納期遅延しやすいことを考慮して、それを代替する現行の下位アイテムも新部材の注文と同時に消費予定として登録処理するステップでもある。本実施形態ではこのアイテムテスト計画日を2004年３月31日と設定している。このステップ0504の処理内容を図21ないし図23を用いて説明する。

３月５日にステップ503において発行した見積依頼に対し、見積依頼を受けた下位アイテム調達拠点からは、納入リードタイム、納入ロットサイズ、単価等の回答が送信されてきて、アイテムプロファイルに保持されている。それらの回答内容を確認し、アイテムテスト計画の設定処理を行うために、まず、該当するアイテムの設計変更進捗画面を表示する。この画面において、アイテムテスト予定日設定ボタンをクリックすると、アイテムプロファイル管理機能と設計変更進捗管理機能が起動される。アイテムプロファイル管理機能と設計変更進捗管理機能によりデータ記憶部のアイテムプロファイルと設計変更進捗データが参照され、アイテムテスト予定日設定画面が画面上に表示される。このアイテムテスト予定部設定画面には、設計変更番号S0002 の各アイテムの納入リードタイム、アイテム切替予定日、製品リリース予定日、製品リリース日が一覧表示される。

図22に移り、担当者は、画面に表示された各アイテムの納入リードタイムおよびアイテム切替予定日、製品リリース日を考慮して、アイテムテスト予定日を入力する。アイテムテスト予定日の入力後、登録ボタンがクリックするとアイテムテスト予定日設定登録機能により、コード記憶部の納入検査リードタイムおよび稼動日カレンダを参照してアイテムテスト予定日から納期を逆算し、データ記憶部のアイテムプロファイルに保持する。このようにアイテムテスト予定日を設定しておいて、さらに本発明においてはテスト対象のアイテムに納入遅れが発生する可能性を考慮し、テスト対象のアイテムの発注と並行して、代替アイテムの消費制御を行う。具体的には、本実施の形態で例にとっているc11については、その代替関係にあるアイテムであるc01についても消費予定の算出を行い、c11とc01の消費予定を関連付けしてデータ記憶部の消費予定に組み込まれる。画面上には、注文書一覧が表示され、納入検査リードタイムおよび稼動日カレンダを参照してアイテムテスト予定日から逆算された納期も表示されて、注文ボタンがクリックされるとアイテムテスト予定に合わせて設定された納期でアイテムの自動発注が行われる。

また、この時点（３月31日時点）で、アイテム仕様一覧画面を表示してアイテムを指定すると、在庫推移算出機能により、コード記憶部の在庫容量、アラーム容量、データ記憶部の納入予定、消費予定、在庫実績等に基づいて指定されたアイテムの在庫推移を算出して、画面に表示する。この画面により在庫状況を把握することができる。

次に、アイテムテスト構成の立案処理について説明する。
（５．５）アイテムテスト構成立案ステップ
アイテムテスト構成立案ステップ505は、システムが、アイテムテスト計画日（３月31日）に設定したアイテムテストの構成を、アイテムの納入状況や在庫状況などを鑑みて有効性を評価し、それらのテスト構成案を１つ以上立案する処理と、そのテスト構成案をユーザに提示し、アイテムテスト構成の登録を受け付け処理するステップである。また、このステップ505は、アイテムテスト構成の登録を受けて、下位アイテム在庫拠点βに対して、下位アイテム在庫拠点βから上位アイテム開発拠点αにアイテムを移管するアイテム移管指示書を発行するステップでもある。なお、本実施形態ではこのテスト着手判定日を2004年４月24日と設定している。このステップ505の処理内容を図24および図25を用いて説明する。

図24において、まず、設計変更進捗画面を表示し、アイテムテスト構成一覧ボタンをクリックする。すると、アイテムテスト構成立案機能が起動されて、データ記憶部のアイテムプロファイル、在庫実績、納入予定およびコード記憶部のアイテムツリー構造、代替アイテム構造を参照し、それらのデータおよびコードに基づいて、アイテムテスト計画日に設定したアイテムテスト予定日近辺においてテスト可能なアイテム構成案およびその構成案でのテスト可能日案を１つ以上算出して提示する。

図25に移り、提示されたアイテムテスト構成案に対して担当者が採用・不採用の判断結果を入力する。アイテムテスト着手日の欄には、その判断結果の入力に基づいて、テスト着手日が自動的に表示される。採用・不採用の判断結果の入力後、登録ボタンをクリックすると、アイテムテスト構成立案機能によりその採用されたアイテムテスト構成がデータ記憶部に登録され、設計変更進捗管理機能により、決定内容が関係拠点のマシンに送信されて情報共有される。そして必要に応じて審査承認の処理が行われた後、設計変更進捗度が計算されて更新されデータ記憶部に記憶される。この例では、アイテムテスト構成立案処理まで完了したことを受け、設計変更進捗度60％となっている。
（５．６）アイテムテストの実施ステップ
アイテムテストを実施するステップ506は、テスト着手判定日に選択したアイテムテスト日およびアイテムテスト構成によってアイテムテストを実施するステップである。なお、本実施形態では、このテスト着手日を2004年４月25日と設定している。

次に、アイテムテスト結果の登録処理について説明する。
（５．７）テスト結果登録ステップ
テスト結果登録ステップ507はテスト結果の登録を受付処理するステップである。また、ステップ507は、成功したテスト結果に従ってアイテムの一部切替を行う場合に、切替予定日の設定と、切替後に必要な下位アイテムの注文処理を行うステップでもある。また、ステップ507は先のステップ504にて登録処理された現行の下位アイテムの消費予定を修正するステップでもある。なお、本実施形態では、このアイテム切替計画日を2004年４月26日と設定している。このステップ507の処理内容を図26ないし図28を用いて説明する。

先ず図26に示すように、アイテムテストの終了後、設計変更進捗画面においてアイテム切替予定日立案ボタンをクリックすると、アイテムテスト構成立案機能により４月24日に登録されたデータ記憶部のアイテムテスト構成が読み出され、表示される。テスト日経過後なので、画面上にはテスト結果を入力するためのボタンが表示される。ここでテスト結果を入力するための選択肢として「成功 アイテム切替する」「成功 アイテム切替しない」「失敗」の3通りが表示されている。

図27に移り、本実施の形態においては、「成功 アイテム切替」を選択し、登録ボタンをクリックすると、アイテム切替予定日立案機能により、まずこの案１の情報をコード記憶部のアイテムツリー構造とデータ記憶部のアイテムプロファイルに記憶し、さらにデータ記憶部の納入予定、消費予定、在庫実績、アイテムプロファイル、コード記憶部の在庫容量に基づいて１つ以上のアイテム切替日案を求めるとともに、それぞれのアイテム切替日案について、アイテムリリース時期の早遅、アイテム切替に伴う死蔵在庫リスク、在庫容量オーバリスク、欠品リスクの大小等を計算して表示する。

図28に、アイテム切替予定日案の案２を選択した場合を示す。案２を選択し、登録ボタンをクリックすると、まずアイテム切替予定日立案機能によりアイテムプロファイルに切替予定日を保持する。続いて設計変更進捗管理機能によりデータ記憶部のユーザリストを参照して、関係拠点のマシンに対し登録されたアイテム切替予定日案の案２の情報を送信して共有する。それとともに必要に応じて審査承認を受けた後、設計変更進捗データを更新する。図28には、設計変更進捗データの更新の結果、番号S0002の設計変更の進捗が、アイテム切替予定日の登録まで完了し、80％となったことを示している。

次に、アイテム切替計画日を確定する処理について説明する。
（５．８）アイテム切替判定ステップ
アイテム切替判定ステップ508は、アイテム切替計画日に設定したアイテム切替日とアイテムの切替範囲について、システムがアイテムの納入状況や在庫状況などの情報に基づいて有効性の評価を行い、その評価結果に基づいて、担当者がアイテム切替確定日の登録処理を行なうステップである。また、アイテム切替判定ステップ508は、その選択により、下位アイテム在庫拠点βから上位アイテム生産拠点δへのアイテム移管指示書を、上位アイテム生産拠点δが下位アイテム在庫拠点βに対して発行するステップでもある。なお、本実施形態ではこのアイテム切替判定日を2004年５月29日と設定している。このステップ508の処理内容を図29および図30を用いて説明する。

まず、図29に示す設計変更進捗画面において、アイテム切替判定ボタンをクリックすると、アイテム切替判定機能が起動される。アイテム切替判定機能により、データ記憶部の納入予定、消費予定、在庫実績、アイテムプロファイル、アイテムテスト構成、コード記憶部のアイテムツリー構造、在庫容量、切替リードタイム、稼働日カレンダを参照し、それらのデータおよびコードに基づいて、アイテムリリース日、死蔵在庫リスクや在庫容量オーバリスク、欠品リスクを計算してアイテム切替判定画面に表示する。このアイテム切替判定画面には、該当のアイテムリリース構成の場合に、下位アイテムの生産ライン変更の有無ついてもこれらのデータおよびコードから求めて表示される。

図30に移り、これらの判定内容の確認後、アイテム切替確定日（本実施形態においては2004/05/30）を入力し、登録ボタンをクリックすると、アイテム切替判定機能により、入力されたアイテム切替確定日をデータ記憶部のアイテムプロファイルに保持する。続いて設計変更進捗管理機能によりユーザリストを参照して、アイテム切替確定日の情報を関係拠点のマシンに送信する。これにより、関係拠点における情報の共有ができる。アイテム切替確定日の登録処理は、必要に応じて審査承認を経た後、完了したとして設計変更進捗データを更新する。図30においては、設計変更進捗データが更新され進捗が90％となっていることを示している。

設計変更処理は、この後、アイテムの一部切替ステップ509、アイテムの全部切替ステップ510、アイテムのリリース処理ステップ511と進む。
（５．９）一部アイテム切替ステップ
一部アイテム切替ステップ509は、アイテム切替判定日に選択したアイテム切替日および切替範囲に従ってアイテムの一部を切り替える。なお、本実施形態ではこのアイテム切替判定日を2004年５月30日と設定している。
（５．１０）全アイテム切替完了ステップ
全アイテム切替完了ステップ510は、すべてアイテムの切替が完了するための処理が行われるステップである。なお、本実施形態ではこの最終切替着手日を2004年6月28日と設定している。
（５．１１）アイテムのリリース処理ステップ
アイテムのリリース処理ステップ511はアイテムYをリリースするための処理が行われるステップである。なお、本実施形態ではこのアイテムYリリース日を2004年７月１日と設定している。

以上に述べた本実施の形態によれば、複数の製品テストや部材の見積依頼・注文などの作業を集約するとともに関係者間で情報共有する方法によって、設計開発プロセスの様々な作業を効率化させ、その方法のシステム化によって作業負荷低減を図ることができる。さらに、リアルタイムに変化する部材納入状況、在庫状況、消費予定のデータを用いて製品テスト時期、テスト構成、製品切替時期等を調節する方法によって、部材在庫の過不足の発生を抑止することができる。

本発明の一実施形態の物流・情報流ネットワークモデルを説明する図である。 本発明の一実施形態のシステム構成を説明する図である。 本発明の一実施形態のハードウェア構成を説明する図である。 本発明の一実施形態のシステムが有する機能を説明する図である。 設計変更工程の流れを説明する図である。 本発明の一実施形態のアイテムツリー構造を説明する図である。 本発明の一実施形態の代替アイテム構造を説明する図である。 本発明の一実施形態の在庫容量とアラーム容量を説明する図である。 在庫実績データと消費予定データのテーブル構造を説明する図である。 処理ステップ501を説明する図である。 処理ステップ501を説明する図である。 処理ステップ501を説明する図である。 処理ステップ501を説明する図である。 処理ステップ501を説明する図である。 処理ステップ502を説明する図である。 処理ステップ502を説明する図である。 処理ステップ502を説明する図である。 処理ステップ502を説明する図である。 処理ステップ503を説明する図である。 処理ステップ503を説明する図である。 処理ステップ504を説明する図である。 処理ステップ504を説明する図である。 処理ステップ504を説明する図である。 処理ステップ505を説明する図である。 処理ステップ505を説明する図である。 処理ステップ507を説明する図である。 処理ステップ507を説明する図である。 処理ステップ507を説明する図である。 処理ステップ508を説明する図である。 処理ステップ508を説明する図である。

符号の説明

101…上位アイテム開発拠点α、102…下位アイテム在庫拠点β、103…下位アイテム調達拠点γ、104…上位アイテム生産拠点δ、200…設計変更支援システム、201…マシンα、202…マシンβ、203…マシンγ、204…マシンδ、205…マシンη、301…入力装置、302…出力装置、303…処理装置、304…補助記憶装置、3031…インタフェース、3032…中央演算処理装置（ＣＰＵ）、3033…主記憶装置。

Claims (7)

1. 製品を構成する部材の変更に起因して発生する製品テストおよび部材切替の計画実行を支援する設計変更支援システムであって、
   該設計変更支援システムは、入力部、出力部、記憶部、処理部を有し、
   前記記憶部には、該製品および部材に関する情報を格納したプロファイルデータと、該部材について設計変更前の旧部材と設計変更後の新部材との関連を記憶した代替関係データと、各部材の在庫、消費、納入の現状および予定に関するデータが記憶され、
   前記処理部は、
   前記プロファイルデータに格納された各部材についての少なくとも調達拠点からの納入リードタイムを読み出して前記出力部に出力し、
   前記入力部から入力された製品テスト予定日をもとに、該製品テストに必要な部材の注文を行うとともに前記代替関係データを参照して代替部材の消費予定の算出を行い、
   前記記憶部に記憶された各部材の納入および在庫状況データおよび代替関係データを用いて該製品テスト予定日近辺においてテスト可能な製品の部材構成およびテスト着手日を含むテスト構成案を1つ以上立案して前記出力部に出力し、入力部よりテスト構成の選択結果を受け付け、
   前記入力部から入力された製品テストの結果に基づいて、設計変更が可能と判断された製品の部材構成について、前記記憶部に保持されている各部材の在庫および消費に関するデータを用いて部材切替の有効性を評価し、１つ以上の部材切替予定日案を立案して出力部に出力し、
   入力部より部材切替予定日案の選択結果を受け付け、該選択された部材切替予定日案において、前記記憶部の部材の納入および在庫状況に関するデータを用いて部材切替の有効性を評価し、評価結果を前記出力部に出力する
   ことを特徴とする設計変更支援システム。
2. 請求項１に記載された設計変更支援システムであって、
   前記処理部は、
   前記テスト予定日のテスト予定構成に含まれる部材について、前記記憶部に記憶された代替関係データと各部材の納入、消費、在庫に関するデータを用いて代替関係にある部材の消費予定を算出して前記記憶部に記憶し、
   前記記憶部に記憶された前記選択された部材切替予定日案を用いて、前記算出した消費予定を修正し、前記記憶手段に記憶することを特徴とする設計変更支援システム。
3. 請求項１に記載された設計変更支援システムであって、
   前記処理部は、旧製品のプロファイルデータを基に新製品プロファイルデータの雛型を作成し、前記入力部から入力された情報に基づいて新製品のプロファイルデータを作成して前記記憶部に記憶することを特徴とする設計変更支援システム。
4. 請求項１に記載された設計変更支援システムであって、
   前記処理部は、
   前記１つ以上のテスト構成案および前記選択されたテスト構成案と、前記１つ以上の部材切替予定日案および前記選択された部材切替予定日案とを前記記憶手段に記憶することを特徴とする設計変更支援システム。
5. 製品(アイテム)を構成する部材(下位アイテム)の変更に起因して発生する製品テストおよび部材切替の計画実行を支援する設計変更支援方法であって、
   該製品および部材に関する情報を格納したプロファイルデータと、該部材について設計変更前の旧部材と設計変更後の新部材との関連を記憶した代替関係データと、各部材の在庫、消費、納入の現状および予定に関するデータとを記憶しておき、
   ユーザへ登録されたアイテムのプロファイルデータの一覧を表示して、新たな設計変更対象のアイテムの選択を入力して、該選択されたアイテムの製品構成情報を提示し、
   前記提示されたアイテムの製品構成情報に対して、ユーザより下位アイテムの更新、または追加の選択指示を受付け、該更新、または追加の選択指示に対応した下位アイテムの仕様入力画面を提示して、前記下位アイテムと代替関係にあるアイテムのプロファイルデータをユーザへ補助提示して、ユーザによる前記下位アイテムの仕様データ入力を受付けて前記プロファイルデータを更新し、
   前記下位アイテムに関する見積依頼書発行に応じて、調達拠点からの回答を前記プロファイルデータに登録して、前記プロファイルデータに格納された各部材についての少なくとも調達拠点からの納入リードタイムを読み出し、
   ユーザへアイテムテスト予定日設定画面を提示して、前記下位アイテム、および代替関係にあるアイテムの納入リードタイム、部材切替予定日、製品リリース予定日を表示して、ユーザより製品テスト予定日の入力を受付け、
   前記入力された製品テスト予定日をもとに、前記製品テストに必要な部材の注文を行うとともに前記代替関係データを参照して代替部材の消費予定の算出を行い、
   各部材の納入および在庫状況データおよび代替関係データを用いて前記製品テスト予定日近辺においてテスト可能な製品の部材構成およびテスト着手日を含むテスト構成案を１つ以上立案して提示し、
   前記テスト構成案の提示画面において、製品テスト結果のユーザ入力に従って、設計変更が可能と判断された製品の部材構成について、部材の納入予定、消費予定、在庫実績、プロファイルデータを用いて部材切替の有効性を評価し、１つ以上の部材切替日案を作成して提示して、ユーザによる部材切替日の確定を支援することを特徴とする設計変更支援方法。
6. 請求項５に記載の設計変更支援方法の手順をコンピュータに実行させるためのプログラム。
7. 請求項５に記載の設計変更支援方法の手順をコンピュータに実行させるためのプログラムを記録した記録媒体。

Images