JP4192937B2 - 生産管理装置 - Google Patents

Description

本発明は、製品の生産数を管理する技術に関する。

従来、営業部門からの製品の追加生産要望に対応できるか否かを判断する場合、製品を構成する個々の部品の在庫数を生産部門が確認し、要望された台数分の製品を生産できるか否かを生産部門が判断して、追加生産に対応することができるか否か応答していた。
しかしながら、このように個々の部品の在庫を調べて追加生産の要望に対応できるか否かを判断するのは非常に手間がかかる作業である。このため、近年、例えば、特許文献１に開示されているように、高速ＭＲＰ（Material Requirements Planning）を用いて、このような判断を支援するシステムが考案されている。
特開２００３−３４５９６９号公報

ところで、ＭＲＰを用いる場合、製品を構成する部品の数が多い場合には、膨大な計算処理を行うこととなる。高速に処理を行うためには、計算機を並列に用い、ＭＲＰ計算を並列に行うことも考えられるが、計算機を並列に用いると、その分、システムが高価となるという問題が生じてしまう。
一方、単体の計算機でＭＲＰ計算を行うと、演算に非常に時間がかかり、営業部門からの追加生産の要望にすぐに応えることができなくなるという問題が生じてしまう。

本発明は、上述した背景の下になされたものであり、その目的は、生産台数の変更に対応できるか否かすぐに回答できるようにすることにある。

上述した課題を解決するために本発明は、部品の発注から納入までの納入リードタイムによって区分された部品グループ毎に、製品が生産される時点を表す生産時点データと、当該生産時点データが示す時点において該部品グループに属する部品を用いて生産することができる製品の生産可能台数とを対応付けて記憶した記憶手段と、ある時点を表す時点データと、製品の台数を示す台数データとを含むメッセージを受信するメッセージ受信手段と、前記メッセージ受信手段にて受信されたメッセージに含まれている時点データが表す時点と同じ時点を表す生産時点データに対応付けられて前記記憶手段に記憶されている各部品グループの生産可能台数と、前記メッセージ受信手段にて受信された台数データが示す台数とを比較し、前記台数データが示す台数が前記各部品グループの生産可能台数以下である場合には、前記台数データが示す台数の製品を生産可能であると判断し、前記台数データが示す台数が前記生産可能台数より多く、且つ、前記メッセージ受信手段により前記メッセージが受信された時点から該受信されたメッセージに含まれている時点データが表す時点までの期間が、前記部品グループに属する部品の納入リードタイム未満となっている場合には、前記台数データが示す台数の製品を生産不可能であると判断し、前記台数データが示す台数が前記生産可能台数より多く、且つ、前記メッセージ受信手段により前記メッセージが受信された時点から該受信されたメッセージに含まれている時点データが表す時点までの期間が、前記部品グループに属する部品の納入リードタイム以上となっている場合には、前記台数データが示す台数の製品を生産可能であると判断する判断手段と、前記判断手段が生産可能であると判断した場合、台数データが示す台数の製品を生産可能であることを通知するメッセージを出力し、前記判断手段が生産不可能であると判断した場合、台数データが示す台数の製品を生産できないことを通知するメッセージを出力するメッセージ出力手段とを有する生産管理装置を提供する。

本発明によれば、生産台数の変更に対応できるか否かを、製品を構成する個々の部品の過不足まで調べずにすぐに回答することができる。

［実施形態の構成］
以下、図面を参照して本発明の実施形態について説明する。図１は、本発明の実施形態に係る生産管理システムの全体構成を例示した図である。図１において、ネットワーク１０は、例えば、ＷＡＮ（Wide Area Network）またはインターネット等の通信ネットワークである。このネットワーク１０には、管理サーバ装置１００と、営業端末２００と、生産端末３００とが接続されており、各装置は、ネットワーク１０を介して互いに通信可能となっている。なお、本実施形態においては、複数の営業端末と複数の生産端末とをネットワーク１０に接続することができるが、図１においては図面が繁雑になるのを防ぐために一つの営業端末２００と、一つの生産端末３００のみを図示している。

営業端末２００は、営業部門が製品の発注や製品の生産台数の確認を行うのに使用する装置である。営業端末２００は、ＣＰＵ、ＲＯＭおよびＲＡＭを備えた制御部と、ハードディスクなどの記憶装置と、ネットワークを介して通信を行う通信インターフェースと、キーボードやマウスと、液晶ディスプレイなどのディスプレイ装置とを備えた、所謂コンピュータ装置である。営業端末２００は、ネットワーク１０に接続された装置とネットワーク１０を介して各種メッセージや各種データの授受を行う。これにより、営業部門においては製品の発注や製品の生産台数の確認を行うことができる。

生産端末３００は、製品の生産に使用される部品を管理するための装置であり、生産部門に配置されている。生産端末３００は、営業端末２００と同様に、制御部、記憶装置、通信インターフェース、キーボードおよびマウス、ディスプレイ装置等を備えており、この記憶装置には、製品の部品に関する情報を格納した発注管理テーブルＴＢ１が記憶されている。

図２は、発注管理テーブルＴＢ１のフォーマットを例示した図である。図２に示したように、発注管理テーブルＴＢ１は、「製品番号」フィールドと、「週」フィールドと、「部品番号」フィールドと、「数量」フィールドと、「納入リードタイム」フィールドと、「台数」フィールドと、「必要数」フィールドとを有している。このテーブルにおいて、「製品番号」フィールドには製品を一意に特定する番号が格納される。また、「週」フィールドには、製品が生産される週を示すデータが格納され、「部品番号」フィールドには製品を構成する部品を一意に特定する部品番号が格納される。また、「数量」フィールドには一つの製品を構成するのに必要な部品の個数が格納され、「納入リードタイム」フィールドには部品の発注から納入までにかかるリードタイム（以下、納入リードタイムと称する）が格納される。また、「台数」フィールドには、「週」フィールドに格納されている週において、部品番号で特定される部品を用いて生産することができる製品の数が格納される。また、「必要数」フィールドには、「週」フィールドに格納されている週において確保しておく部品の数、即ち、数量フィールドに格納されている値に、台数フィールドに格納されている値を乗じて得られる値が格納される。

管理サーバ装置１００は、製品の生産予定台数を管理する装置であり、例えば、製品の生産計画をたてる生産管理部門に配置されている。図３は、管理サーバ装置のハードウェア構成を示したブロック図である。図３に示したように、管理サーバ装置１００の各部は、バス１０１に接続されており、このバス１０１を介して各部間で通信を行う。

Ｕ／Ｉ（ユーザインターフェース）部１０７は、管理サーバ装置１００を操作するためのキーボードやマウスなどの入力装置を備えている。表示部１０８は、例えば、液晶ディスプレイ等の表示デバイスを有しており、ＣＰＵ１０２の制御の下、管理サーバ装置１００を操作するためのメニュー画面等、各種画面を表示する。通信部１０６は、ネットワーク１０を介して通信を行う通信インターフェースとして機能し、ＣＰＵ１０２の制御の下、ネットワーク１０を介してデータ通信を行う。

記憶部１０５は、データを永続的に記憶するハードディスク等の記憶装置を具備しており、製品の生産予定台数を管理する機能を実現するアプリケーションプログラムを記憶している。このアプリケーションプログラムがＣＰＵ１０２により実行されると、製品の生産予定台数を管理する機能が管理サーバ装置１００において実現する。

また、記憶部１０５は、製品の生産予定台数を格納した生産計画テーブルＴＢ２を記憶している。図４は、記憶部１０５に記憶されている生産計画テーブルＴＢ２のフォーマットを例示した図である。生産計画テーブルＴＢ２は、製品を特定する製品番号が格納される「製品番号」フィールドと、製品が生産される週を示すデータが格納される「週」フィールドと、製品の生産予定台数が格納される「生産予定台数」フィールドとを有している。例えば、図４に示した生産計画テーブルＴＢ２は、製品名が「ＷＥ１２３４」である製品の２００５年第１０週の生産予定台数が「９００台」であることを示している。

また、記憶部１０５は部品管理テーブルＴＢ３を記憶している。図５は、部品管理テーブルＴＢ３のフォーマットを例示した図である。部品管理テーブルＴＢ３には、部品のリードタイムのグループ毎（図５においては、二週間グループ、四週間グループ、六週間グループ）に、グループに属する部品を用いて生産することができる製品の台数が格納される。なお、実際に生産する台数は、様々な理由によって計画した生産予定台数より多くなることがある。このため、各セルに格納される値は、生産予定台数より多い数が格納される。なお、生産予定数に対してどれだけ多くするかについては、各納入リードタイム毎に任意に設定してもよいし、生産予定台数に所定の係数を掛けるようにしてもよい。

［実施形態の動作］
次に本実施形態の動作について説明する。
（生産予定台数を管理サーバ装置１００へ入力した時の動作）
まず、生産管理部門においては、操作者が管理サーバ装置１００のＵ／Ｉ部１０７を操作し、製品番号と、当該製品番号で特定される製品の週毎の生産予定台数の入力を行う。生産端末３００は、製品番号と生産予定台数が入力されると、生産計画テーブルＴＢ２を生成し、この生成した生産計画テーブルＴＢ２を記憶部１０５に記憶する（図６：ステップＳＡ１）。

ＣＰＵ１０２は、生産計画テーブルＴＢ２を記憶部１０５に記憶した後、部品管理テーブルＴＢ３に数値を格納する（ステップＳＡ２）。
具体的には、納入リードタイムのグループ毎に定められたＬＴ（Lead Time）関数に従って数値を部品管理テーブルＴＢ３に格納する。
例えば、二週間グループの部品に関してはＮ１＝ａＸ（式１）というＬＴ関数が定められている。ここで、ａは二週間グループの部品に対して予め定められた係数であり、Ｘは生産予定台数を示している。また、Ｎ１は、部品管理テーブルＴＢ３に格納される値を示している。また、四週間グループの部品に関してはＮ２＝ｂＸ（式２）というＬＴ関数が定められている。ここで、ｂは四週間グループの部品に関して予め定められた係数であり、Ｎ２は、部品管理テーブルＴＢ３に格納される値を示している。また、六週間グループの部品に関してはＮ３＝ｃＸ（式３）というＬＴ関数が定められている。ここで、ｃは六週間グループの部品に関して予め定められた係数であり、Ｎ３は、部品管理テーブルＴＢ３に格納される値を示している。なお、係数ａ，ｂ，ｃの値は任意に定めることができる。

二週間グループの部品について生産予定台数の１.５倍の台数分の部品を用意する場合、式１のａの値が１．５とされる。そして、２００５年第１０週の場合、図４に示したように生産予定台数が９００台であるため、９００×１．５＝１３５０となり、図５に示したように、「二週間グループ」のフィールドの２００５年第１０週の行に「１３５０」が格納される。また、四週間グループの部品について生産予定台数の２倍の台数分の部品を用意する場合、式２のｂの値が２とされる。そして、２００５年第１０週の場合、図４に示したように生産予定台数が９００台であるため、９００×２＝１８００となり、図５に示したように、「四週間グループ」のフィールドの２００５年第１０週の行に「１８００」が格納される。また、六週間グループの部品について生産予定台数の２．５倍の台数分の部品を用意する場合、式３のｃの値が２．５とされる。そして、２００５年第１０週の場合、図４に示したように生産予定台数が９００台であるため、９００×２．５＝２２５０となり、図５に示したように、「六週間グループ」のフィールドの２００５年第１０週の行に「２２５０」が格納される。
このように、納入リードタイムのグループ毎にどれだけ部品在庫に余裕を持たせて、在庫を管理するかはＬＴ関数に従う。ＣＰＵ１０２は、部品管理テーブルＴＢ３の各セルに数値を格納し終えると、通信部１０６を介して生産端末３００と通信を行い、部品管理テーブルＴＢ３を生産端末３００へ送信する（ステップＳＡ３）。

生産端末３００は、管理サーバ装置１００から送信された部品管理テーブルＴＢ３を受信すると、受信した部品管理テーブルＴＢ３を記憶装置に記憶させる（図７；ステップＳＢ１）。そして生産端末３００は、受信した部品管理テーブルＴＢ３に基づいて、発注管理テーブルＴＢ１のセルに数値を格納する。

具体的には、生産端末３００は、部品管理テーブルＴＢ３に格納されている製品番号と同じ製品番号が格納されている部品管理テーブルＴＢ３を、記憶装置に記憶されている複数の部品管理テーブルの中から検索する。生産端末３００は、同じ製品番号が格納されている部品管理テーブルＴＢ３を見つけると、まず、部品管理テーブルＴＢ３に格納されている数値を、検索により見つけた発注管理テーブルＴＢ１の「台数」フィールドに格納する（ステップＳＢ２）。ここで、部品管理テーブルＴＢ３において「二週間グループ」フィールドに格納されている数値は、納入リードタイムが「二週間」となっている部品の「台数」フィールドに格納される。例えば、「二週間グループ」のフィールドにおいて、「２００５年第１０週」の行に格納されている「１３５０」は、発注管理テーブルＴＢ１の「２００５年第１０週」の行において、納入リードタイムが「二週間」となっている行、即ち部品番号「Ｐ１００２」が格納されている行に格納される。また、部品管理テーブルＴＢ３において「四週間グループ」フィールドに格納されている数値は、納入リードタイムが「四週間」となっている行、即ち、部品番号「Ｐ１００１」が格納されている行と、部品番号「Ｐ１００４」が格納されている行に格納され、部品管理テーブルＴＢ３において「六週間グループ」フィールドに格納されている数値は、納入リードタイムが「六週間」となっている行、即ち、部品番号「Ｐ１００２」が格納されている行に格納される。

生産端末３００は、台数フィールドの各セルに数値を格納し終えると、数量フィールドに格納されている数値に、台数フィールドに格納されている数値を乗じて得られる数値を必要数フィールドに格納する（ステップＳＢ３）。例えば、「２００５年第１０週」の行においては、部品番号が「Ｐ１００１」の行に格納されている数量「１」と台数「１８００」との乗算の結果である「１８００」が必要数フィールドに格納され、部品番号が「Ｐ１００２」の行に格納されている数量「３５」と台数「１３５０」との乗算の結果である「４７２５０」が必要数フィールドに格納される。

発注管理テーブルＴＢ１の各セルへの数値の格納が終了すると、生産部門においては、この格納された数値に基づいて、部品の発注が行われる。例えば、２００５年の第１０週には、四週間グループに属する「Ｐ１００１」の部品を１８００個、二週間グループに属する「Ｐ１００２」の部品を４７２５０個、六週間グループに属する「Ｐ１００３」の部品を２２５０個、四週間グループに属する「Ｐ１００４」の部品を１８００個用意する必要がある。このため、六週間グループに属する部品については、２００５年第１０週の六週間前、即ち、２００５年第４週に発注が行われる。また、四週間グループに属する部品については、２００５年第１０週の四週間前、即ち、２００５年第６週に発注が行われ、二週間グループに属する部品については、２００５年第１０週の二週間前、即ち、２００５年第８週に発注が行われる。

（生産予定台数を確認する時の動作）
次に、営業部門が、製品の生産予定台数の確認や、生産台数の変更確認を行う時の動作について説明する。
まず、ある週における製品の生産予定台数を確認したい場合、営業部門の者は、営業端末２００を操作し、生産予定台数の確認を行うためのメニュー画面（図１０（ａ）参照）を営業端末２００上に表示させる。営業端末の操作者は、図１０（ａ）に例示したメニュー画面が表示された後、製品番号と、生産予定台数を確認したい週を表す文字列とを入力し、入力が終了した後、メニュー画面に表示されている「確認」ボタンをクリックする操作を行う。営業端末２００は、「確認」ボタンをクリックする操作が行われると、入力された製品番号と文字列とを含む予定台数確認メッセージを管理サーバ装置１００へ送信する。例えば、製品番号として「ＷＥ１２３４」が入力され、生産予定台数を確認したい週として「２００５年第１０週」が入力された場合、営業端末２００は、入力された製品番号「ＷＥ１２３４」と、週を表す文字列「２００５年第１０週」とを含む予定台数確認メッセージを管理サーバ装置１００へ送信する。

このメッセージは管理サーバ装置１００の通信部１０６にて受信され、ＣＰＵ１０２へ送られる。ＣＰＵ１０２は、このメッセージを受取ると、メッセージ中に含まれている製品番号と同じ製品番号が格納されている生産計画テーブルＴＢ２を記憶部１０５に記憶されているテーブルの中から検索する（図８：ステップＳＣ１）。ＣＰＵ１０２は、同じ製品番号が格納されている生産計画テーブルＴＢ２を見つけると、生産計画テーブルＴＢ２において、メッセージ中に含まれている文字列「２００５年第１０週」と同じ文字列が格納されている行を検索する。ＣＰＵ１０２は、同じ文字列が格納されている行を見つけると、この行に格納されている生産予定台数「９００」を読み出す（ステップＳＣ２）。そして、読み出した生産予定台数を含む予定台数通知メッセージを、通信部１０６を介して営業端末２００へ送信する（ステップＳＣ３）。このメッセージが営業端末２００にて受信されると、受信したメッセージに含まれている生産予定台数「９００」が営業端末２００に表示され、営業部門は、ある週における製品の生産予定台数を確認することができる。

（生産予定台数の変更が可能であるか確認する時の動作）
次に、ある週における生産予定台数の変更を行うことが可能であるか確認する時の動作について説明する。
まず、ある週の生産予定台数の変更が可能であるかを確認する場合、営業部門の者は、営業端末２００を操作し、生産予定台数の変更確認を行うためのメニュー画面（図１０（ｂ）参照）を営業端末２００上に表示させる。図１０（ｂ）に例示したメニュー画面が表示された後、営業端末の操作者は、製品番号と、生産希望台数と、生産台数の変更を希望する週を表す文字列とを入力し、入力が終了した後、メニュー画面に表示されている「確認」ボタンをクリックする操作を行う。営業端末２００は、「確認」ボタンをクリックする操作が行われると、入力された製品番号と、生産希望台数と、生産台数の変更を希望する週を表す文字列とを含む台数変更確認メッセージを管理サーバ装置１００へ送信する。例えば、製品番号として「ＷＥ１２３４」が入力され、生産希望台数として「１５００」が入力され、生産台数の変更を希望する週として「２００５年第１０週」が入力された場合（２００５年第１０週当初の生産予定台数は９００台）、営業端末２００は、入力された製品番号「ＷＥ１２３４」と、生産希望台数「１５００」と、週を表す文字列「２００５年第１０週」とを含む台数変更確認メッセージを管理サーバ装置１００へ送信する。

このメッセージは管理サーバ装置１００の通信部１０６にて受信され、ＣＰＵ１０２へ送られる。ＣＰＵ１０２は、このメッセージを受取ると、メッセージ中に含まれている製品番号と同じ製品番号が格納されている部品管理テーブルＴＢ３を記憶部１０５に記憶されているテーブルの中から検索する（図９：ステップＳＤ１）。ＣＰＵ１０２は、同じ製品番号が格納されている部品管理テーブルＴＢ３を見つけると、部品管理テーブルＴＢ３において、メッセージ中に文字列「２００５年第１０週」と同じ文字列が格納されている行を検索する。そしてＣＰＵ１０２は、同じ文字列が格納されている行を見つけると、この行に格納されている数値と、メッセージ中に含まれている生産希望台数とを比較し、メッセージ中に含まれている文字列で特定される週の生産台数を変更できるか否かを判断する（ステップＳＤ２）。

例えば、管理サーバ装置１００が、「２００５年第１０週」の３週間前、即ち、「２００５年第７週」に台数変更確認メッセージを受信した場合、図１１に示したように、四週間グループの部品については１８００台分の発注が行われ、六週間グループの部品に関しては２２５０台分の発注が行われているので、これらの部品については、２００５年第１０週に納入される部品の数を「２００５年第７週」の時点で変更することができない。しかし、これらの部品については、１５００台分以上の部品が発注されているため、２００５年第１０週の生産台数が１５００台に変更されたとしても、生産可能であると判断する。また、二週間グループの部品については、台数変更確認メッセージを受信した時点が生産の二週間前になっておらず、発注予定数は１３５０台分となっているが、部品の発注が行われていないため、発注数の変更を行えば１５００台の製品を生産することが可能であると判断する。
このように、納入リードタイムのグループ毎にＬＴ関数で設定した部品在庫を有し、生産台数の変更確認を受けた時点で生産希望台数の製品を生産できるか否か判断し、生産希望台数分の生産が可能であると判断した場合、生産台数の変更が可能であることを通知する変更可能メッセージを営業端末２００へ送信する（ステップＳＤ３）。このメッセージが営業端末２００にて受信されると、生産台数の変更が可能であることが営業端末２００により操作者へ報知される。

一方、管理サーバ装置１００が、「２００５年第１０週」の１週間前、即ち、「２００５年第９週」に台数変更確認メッセージを受信した場合、図１１に示したように、四週間グループの部品については１８００台分の発注が行われ、六週間グループの部品に関しては２２５０台分の発注が行われているので、これらの部品については、２００５年第１０週に納入される部品の数を「２００５年第９週」の時点で変更することができない。しかし、これらの部品については、１５００台分以上の部品が発注されているため、２００５年第１０週の生産台数が１５００台に変更されたとしても、生産可能であると判断する。
しかしながら、二週間グループの部品については、発注予定数は１３５０台分となっており、この二週間グループの部品については、発注から納入まで二週間かかり、この時点で追加分の発注を行っても「２００５年第１０週」には間に合わないため、１５００台の製品を生産することが台数変更確認メッセージを受信した時点では不可能であると判断する。
このように、生産希望台数分の生産が不可能であると判断した場合、管理サーバ装置１００は、生産台数の変更が不可能であることを通知する変更不可メッセージを営業端末２００へ送信する（ステップＳＤ４）。このメッセージが営業端末２００にて受信されると、生産台数の変更が不可能であることが営業端末２００により操作者へ報知される。

このように、本実施形態においては、管理サーバ装置１００は、製品の生産に要する部品を納入リードタイムでグループ分けし、需要を満たすために余分に持つ部品の在庫数をＬＴ関数によってグループ単位で管理するため、需要を満たすために余分に持つ部品の在庫数の管理が容易となる。また、需要を満たすために余分に持つ部品の在庫数の管理が容易となるため、営業部門からの生産台数変更の問い合わせに対して時間をかけることなく、すぐに回答することができる。また、変動する需要に対し、頑強性があり、且つ、過剰な在庫を持つことなく、在庫を極小化することができる。

［変形例］
以上、本発明の実施形態について説明したが、本発明は上述した実施形態に限定されることなく、他の様々な形態で実施可能である。例えば、上述の実施形態を以下のように変形して本発明を実施してもよい。

管理サーバ装置１００においては、Ｕ／Ｉ部１０７を操作して数値を入力し、この入力された数値を部品管理テーブルＴＢ３に格納するようにしてもよい。

上述した実施形態においては、週単位で生産台数や部品在庫数を管理しているが、週単位に限定されるものではなく、日単位や月単位で管理するようにしてもよい。また、上述した実施形態においては、ＬＴ関数の計算式は生産台数に所定の係数を乗じるものであるが、ＬＴ関数は他の計算式であってもよい。

本発明の実施形態に係る生産管理システムの全体構成を示す図である。 発注管理テーブルＴＢ１のフォーマットを例示した図である。 管理サーバ装置１００のハードウェア構成を例示したブロック図である。 生産計画テーブルＴＢ２のフォーマットを例示した図である。 部品管理テーブルＴＢ３のフォーマットを例示した図である。 製品番号と生産予定台数が入力された時に管理サーバ装置１００が行う処理の流れを例示したフローチャートである。 生産端末３００が行う処理の流れを例示したフローチャートである。 予定台数確認メッセージを受信した時に管理サーバ装置１００が行う処理の流れを例示したフローチャートである。 台数変更確認メッセージを受信した時に管理サーバ装置１００が行う処理の流れを例示したフローチャートである。 営業端末２００に表示されるメニュー画面を例示した図である。 管理サーバ装置１００の動作を説明するための図である。

符号の説明

１００・・・管理サーバ装置、１０２・・・ＣＰＵ、１０３・・・ＲＯＭ、１０４・・・ＲＡＭ、１０５・・・記憶部、１０６・・・通信部、１０７・・・Ｕ／Ｉ部、１０８・・・表示部、２００・・・営業端末、３００・・・生産端末。

Claims (1)

1. 部品の発注から納入までの納入リードタイムによって区分された部品グループ毎に、製品が生産される時点を表す生産時点データと、当該生産時点データが示す時点において該部品グループに属する部品を用いて生産することができる製品の生産可能台数とを対応付けて記憶した記憶手段と、
   ある時点を表す時点データと、製品の台数を示す台数データとを含むメッセージを受信するメッセージ受信手段と、
   前記メッセージ受信手段にて受信されたメッセージに含まれている時点データが表す時点と同じ時点を表す生産時点データに対応付けられて前記記憶手段に記憶されている各部品グループの生産可能台数と、前記メッセージ受信手段にて受信された台数データが示す台数とを比較し、前記台数データが示す台数が前記各部品グループの生産可能台数以下である場合には、前記台数データが示す台数の製品を生産可能であると判断し、
   前記台数データが示す台数が前記生産可能台数より多く、且つ、前記メッセージ受信手段により前記メッセージが受信された時点から該受信されたメッセージに含まれている時点データが表す時点までの期間が、前記部品グループに属する部品の納入リードタイム未満となっている場合には、前記台数データが示す台数の製品を生産不可能であると判断し、
   前記台数データが示す台数が前記生産可能台数より多く、且つ、前記メッセージ受信手段により前記メッセージが受信された時点から該受信されたメッセージに含まれている時点データが表す時点までの期間が、前記部品グループに属する部品の納入リードタイム以上となっている場合には、前記台数データが示す台数の製品を生産可能であると判断する判断手段と、
   前記判断手段が生産可能であると判断した場合、台数データが示す台数の製品を生産可能であることを通知するメッセージを出力し、前記判断手段が生産不可能であると判断した場合、台数データが示す台数の製品を生産できないことを通知するメッセージを出力するメッセージ出力手段と
   を有する生産管理装置。

Images