(57)【要約】【課題】本発明は、管理者にとってわかり易く簡単な操作で部品を管理することができる部品管理装置を提供する。【解決手段】本発明では、１又は複数の部品から構成される組立品を１又は複数用いて構成される製品を生産するために、前記部品を管理する部品管理装置１において、前記部品を管理するための部品管理情報を記憶する記憶部１１を備え、前記部品管理情報には、前記部品を特定し識別するための識別子である部品コードと、前記製品の生産計画上において一括りにされる集合であるグループを特定し識別するための識別子であるグループコードとが含まれることを特徴とする。【選択図】図２
2008071091.tif 000002
【特許請求の範囲】
【請求項１】
１又は複数の部品から構成される組立品を１又は複数用いて構成される製品を生産するために、前記部品を管理する部品管理装置において、
前記部品を管理するための部品管理情報を記憶する第１記憶部を備え、
前記部品管理情報には、前記部品を特定し識別するための識別子である部品コードと、
前記製品の生産計画上において一括りにされる集合であるグループを特定し識別するための識別子であるグループコードとが含まれること
を特徴とする部品管理装置。
【請求項２】
前記部品管理情報には、一の生産計画における前記組立品を組立てる場合に必要となる前記部品の所要数と、前記組立品を組立てる場合に必要となる部品を取り揃えておくべき日付である出庫日とが含まれ、
集計キーに対応する部品の所要数を集計する第１処理部を備え、
前記集計キーには、前記部品コードと前記グループコードと前記出庫日とが含まれること
を特徴とする請求項１に記載の部品管理装置。
【請求項３】
前記部品管理情報には、一の生産計画における前記製品を生産する場合に、納品されている部品であって当該部品を使用する組立品が決まっていない部品の個数であるフリー在庫数と、注文されているが納品されていない部品であって当該部品を使用する組立品が決まっていない部品の個数であるフリー注文残数と、注文すべき部品の個数を計画する計画購入数とがさらに含まれ、
これらのフリー在庫数と、フリー注文残数と、計画購入数の情報と、前記部品コード及び前記部品の所要数とが含まれる情報を記憶する第２記憶部を備え、
前記第２記憶部に記憶されている前記フリー在庫数及び前記フリー注文残数に基づいて、前記第１処理部で集計された前記部品の所要数が充当可能なフリー在庫数及びフリー注文残数となるように計画購入数を計算する第２処理部とをさらに備えること
を特徴とする請求項２に記載の部品管理装置。
【請求項４】
１又は複数の部品から構成される組立品を１又は複数用いて構成される製品を生産するために、前記部品を管理する部品管理装置において、
前記部品を特定し識別するための識別子である部品コードと、前記部品コードに対応する部品の現時点までのフリー在庫数及びフリー注文残数と、該部品の出庫日が現時点から予め設定した将来の日付までの部品の所要数及び注文残数と、第１及び第２充当残のうちの少なくとも１つとを記憶する記憶部を備え、
前記第１充当残は、前記部品のフリー在庫数から前記部品の所要数を充当した後において予測されるフリー在庫数であり、
前記第２充当残は、該第１充当残が負数になった以降に、前記部品の注文残数から前記部品の所要数を充当した後において予測されるフリー注文残数であり、
前記フリー在庫数は、納品されている部品であって当該部品を使用する組立品が決まっていない部品の個数であり、
前記フリー注文残数は、注文されているが納品されていない部品であって当該部品を使用する組立品が決まっていない部品の個数であること
を特徴とする部品管理装置。
【請求項５】
前記部品コードと、前記部品コードに対応する部品の現時点までのフリー在庫数及びフリー注文残数と、該部品の出庫日が現時点から予め設定した将来の日付までの部品の所要数及び注文残数とを記憶すると共に、前記部品のフリー在庫数から前記部品の所要数を充当した後において予測されるフリー在庫数である第１充当残、及び、該第１充当残が負数になった以降に、前記部品の注文残から前記部品の所要数を充当した後において予測されるフリー注文残数である第２充当残のうちの少なくとも１つを記憶する第３記憶部を備えること
を特徴とする請求項１乃至請求項３の何れか１項に記載の部品管理装置。
【請求項６】
１又は複数の部品から構成される組立品を１又は複数用いて構成される製品を生産するために、前記部品を管理する部品管理装置において、
前記部品を管理するための部品管理情報を記憶する記憶部を備え、
前記部品管理情報には、前記部品を特定し識別するための識別子である部品コードと、
組立場所において組立品を組立てるために必要な部品の所要数と、倉庫から単位数で出庫した部品の部品数である出庫数と、該出庫数から、該出庫数の部品コードに対応する部品の前記所要数を減算した値である出庫先在庫予定数とが含まれること
を特徴とする部品管理装置。
【請求項７】
前記部品管理情報には、前記組立場所において組立品を組立てた後に余剰となった部品を倉庫に引き揚げたか否かを示す引揚フラグがさらに含まれ、
前記倉庫には、現在保管している部品の個数である現在在庫数と、引揚数とを記憶する記憶部を備え、
前記組立場所において組立品を組立てた後に余剰となった部品を、前記倉庫に引き揚げたこと示す引揚フラグが付された出庫先在庫予定数を、前記余剰となった部品を前記倉庫の記憶部に備えた引揚数に前記余剰となった部品の部品コードに対応して記憶させた後、前記引揚フラグの付された出庫先在庫予定数を０とする処理部をさらに備えること
を特徴とする請求項６に記載の部品管理装置。
【請求項８】
前記部品を管理するための第２部品管理情報を記憶する第４記憶部を備え、
前記部品には、倉庫から必要数だけ出庫する部品と単位数で出庫する部品とが含まれ、
前記第２部品管理情報には、前記部品コードと、前記部品コードに対応して現在保管されている部品の個数である現在在庫数と、組立場所において組立品を組立てた後に余剰となって引き揚げた部品について、該引き揚げた部品の部品コードに対応した部品の部品数である引揚数とが含まれること
を特徴とする請求項１、請求項２、請求項３及び請求項５の何れか１項に記載の部品管理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、部品を管理する部品管理装置に関する。
【背景技術】
【０００２】
製造企業の活動は、通常、資材の調達、開発、生産、販売及びアフターサービスの循環過程で行われる。この生産では、製品を構成する各部品が生産計画に応じて部品メーカから調達されて倉庫に保管され、必要な時期に必要数だけ製造工場へ倉庫から出庫される。また、アフターサービスでも、保守に必要な部品が先行的に部品メーカから調達されて倉庫に保管され、必要な時期に必要数だけサービス拠点へ倉庫から出庫される。このような製造企業の活動を支障無く円滑に行うためには、部品の所要数管理、発注管理及び入出庫管理等の各部品を適切に管理する必要がある。
【０００３】
製品には、顧客からの受注に応じて生産計画（受注生産計画）が計画されて製造される製品や、市場の需要予測等に基づいて生産計画（予測生産計画）が予め計画されて製造される製品等の様々な形態がある。また、部品には、当該部品が使用される製品は未定であるけれども先行的に調達される部品や、リール品等の様々な形態がある。従来、所要数管理、発注管理、受入れ管理及び在庫管理等の部品の管理は、このような各形態に区分けされて行われていた。
【０００４】
なお、部品を管理する技術に関し、例えば、特許文献１の在庫管理装置がある。この特許文献１に記載の、製品又は半製品を構成する部品の在庫管理装置は、前記製品又は半製品の生産計画情報及び前記部品の在庫情報に基づいて、前記部品を入庫する数量及び時期を演算する第１演算手段と、該第１演算手段の演算とは別の時期に、前記生産計画情報に基づいて前記部品を出庫する数量及び時期を演算する第２演算手段とを備える。このような構成により、特許文献１の在庫管理装置は、製品又は半製品に設計変更等があったとしても部品を適切に管理することができる。
【特許文献１】特開２００１−００５５１２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
ところで、部品管理は、各形態に区分けされて行われていたので、各形態に応じて行われる必要があることから、煩雑なものとなっていた。そのため、部品を管理する管理者には、複雑な管理が強要されていた。
【０００６】
本発明は、上述の事情に鑑みて為された発明であり、管理者にとって簡単且つ判り易い操作によって部品を管理することができる部品管理装置を提供することを目的とする。
【課題を解決するための手段】
【０００７】
本発明者は、種々検討した結果、上記目的は、以下の本発明により達成されることを見出した。即ち、本発明に係る一態様では、１又は複数の部品から構成される組立品を１又は複数用いて構成される製品を生産するために、前記部品を管理する部品管理装置において、前記部品を管理するための部品管理情報を記憶する第１記憶部を備え、前記部品管理情報には、前記部品を特定し識別するための識別子である部品コードと、前記製品の生産計画上において一括りにされる集合であるグループを特定し識別するための識別子であるグループコードとが含まれることを特徴とする。
【０００８】
生産は、生産計画に沿って実行され、また、生産計画は、例えば受注状況の変化や市場動向の変化等の生産計画を計画する上で考慮される要因の変更によって、しばしば、変更される。上記構成によれば、グループコードが部品管理情報に含まれるので、グループコードをキーに部品管理情報から様々な部品に関する情報を検索することができるから、管理者にとって簡単且つ判り易い操作で部品を管理することができる。例えば、一の生産計画に必要な部品やその個数を集計したい場合に、当該生産計画に対応するグループコードをキーに部品管理情報を検索することによって、当該生産計画に必要な部品やその個数を検索することができ、この検索結果における個数を合算することによって、当該生産計画に必要な部品の個数を集計することができる。そして、その集計された個数を参考に部品を注文することができる。また例えば、一の生産計画に変更が生じた場合に、当該生産計画に対応するグループコードをキーに部品管理情報を検索することによって、当該生産計画に必要な部品に関する情報を検索することができ、この検索結果における部品に関する情報を変更や削除や追加等することによって、当該生産計画の変更に対応することができる。
【０００９】
そして、上述の部品管理装置において、前記部品管理情報には、一の生産計画における前記組立品を組立てる場合に必要となる前記部品の所要数と、前記組立品を組立てる場合に必要となる部品を取り揃えておくべき日付である出庫日とが含まれ、集計キーに対応する部品の所要数を集計する第１処理部を備え、前記集計キーには、前記部品コードと前記グループコードと前記出庫日とが含まれることを特徴とする。
【００１０】
また、上述の部品管理装置において、前記部品管理情報には、一の生産計画における前記製品を生産する場合に、納品されている部品であって当該部品を使用する組立品が決まっていない部品の個数であるフリー在庫数と、注文されているが納品されていない部品であって当該部品を使用する組立品が決まっていない部品の個数であるフリー注文残数と、注文すべき部品の個数を計画する計画購入数とがさらに含まれ、これらのフリー在庫数と、フリー注文残数と、計画購入数の情報と、前記部品コード及び前記部品の所要数とが含まれる情報を記憶する第２記憶部を備え、前記第２記憶部に記憶されている前記フリー在庫数及び前記フリー注文残数に基づいて、前記第１処理部で集計された前記部品の所要数が充当可能なフリー在庫数及びフリー注文残数となるように計画購入数を計算する第２処理部とをさらに備えることを特徴とする。
【００１１】
この構成によれば、第２処理部によって部品の所要数に充当可能なフリー在庫数及びフリー注文残数が計算されるので、これら部品の所要数とフリー在庫数とフリー注文残数とを例えば部品管理装置の出力部やネットワークを介して通信可能に接続された端末装置の出力部に出力させ、管理者は、部品の所要数とフリー在庫数とフリー注文残数とを相互に比較することによって、部品の所要数をフリー在庫数やフリー注文残数で充当可能か否かを判断することができ、充当できない場合には、注文（発注）すべき部品の個数を判断することができる。
【００１２】
そして、本発明に係る他の一態様では、１又は複数の部品から構成される組立品を１又は複数用いて構成される製品を生産するために、前記部品を管理する部品管理装置において、前記部品を特定し識別するための識別子である部品コードと、前記部品コードに対応する部品の現時点までのフリー在庫数及びフリー注文残数と、該部品の出庫日が現時点から予め設定した将来の日付までの部品の所要数及び注文残数と、第１及び第２充当残のうちの少なくとも１つとを記憶する記憶部を備え、前記第１充当残は、前記部品のフリー在庫数から前記部品の所要数を充当した後において予測されるフリー在庫数であり、前記第２充当残は、該第１充当残が負数になった以降に、前記部品の注文残数から前記部品の所要数を充当した後において予測されるフリー注文残数であり、前記フリー在庫数は、納品されている部品であって当該部品を使用する組立品が決まっていない部品の個数であり、前記フリー注文残数は、注文されているが納品されていない部品であって当該部品を使用する組立品が決まっていない部品の個数であることを特徴とする。
【００１３】
また、これら上述の部品管理装置において、前記部品コードと、前記部品コードに対応する部品の現時点までのフリー在庫数及びフリー注文残数と、該部品の出庫日が現時点から予め設定した将来の日付までの部品の所要数及び注文残数とを記憶すると共に、前記部品のフリー在庫数から前記部品の所要数を充当した後において予測されるフリー在庫数である第１充当残、及び、該第１充当残が負数になった以降に、前記部品の注文残から前記部品の所要数を充当した後において予測されるフリー注文残数である第２充当残のうちの少なくとも１つを記憶する第３記憶部を備えることを特徴とする。
【００１４】
この構成によれば、部品コードと、部品コードに対応する部品の現時点までのフリー在庫数及びフリー注文残数と、該部品の出庫日が現時点から予め設定した将来の日付までの各部品の所要数及び注文残数と、該部品のフリー在庫数から部品の所要数を順次充当した後において予測される各フリー在庫数である第１充当残と、該第１充当残が負数なった以降に、各部品の注文残数から各部品の所要数を順次充当した後におけるフリー注文残数である第２充当残が含まれるので、これ等の情報を例えば部品管理装置の出力部やネットワークを介して通信可能に接続された端末装置の出力部に出力させ、部品管理を行う管理者（以下ユーザと記述する）は、第１充当残及び第２充当残を参照することによって、当該部品が充当可能か否かを判断することができる。また、ユーザは、当該部品が充当可能である場合に、第１及び第２充当残を参照することによって、フリー在庫数で充当されるのか、あるいは、注文残数で充当されるのかを知ることができる。一方、ユーザは、当該部品が充当不可能である場合には、第１充当残及び第２充当残数を参照することによって、不足が予測される部品の個数を緊急に注文すべきか、あるいは納期が遅れた部品注文残数の納品を督促すべきか、納期の前倒し納品を交渉すべきかの判断が事前にできる。
【００１５】
そして、本発明に係る他の一態様では、１又は複数の部品から構成される組立品を１又は複数用いて構成される製品を生産するために、前記部品を管理する部品管理装置において、前記部品を管理するための部品管理情報を記憶する記憶部を備え、前記部品管理情報には、前記部品を特定し識別するための識別子である部品コードと、組立場所において組立品を組立てるために必要な部品の所要数と、倉庫から単位数で出庫した部品の部品数である出庫数と、該出庫数から、該出庫数の部品コードに対応する部品の前記所要数を減算した値である出庫先在庫予定数とが含まれることを特徴とする。
【００１６】
また、上述の部品管理装置おいて、前記部品管理情報には、前記組立場所において組立品を組立てた後に余剰となった部品を倉庫に引き揚げたか否かを示す引揚フラグがさらに含まれ、前記倉庫には、現在保管している部品の個数である現在在庫数と、引揚数とを記憶する記憶部を備え、前記組立場所において組立品を組立てた後に余剰となった部品を、前記倉庫に引き揚げたこと示す引揚フラグが付された出庫先在庫予定数を、前記余剰となった部品を前記倉庫の記憶部に備えた引揚数に前記余剰となった部品の部品コードに対応して記憶させた後、前記引揚フラグの付された出庫先在庫予定数を０とする処理部をさらに備えることを特徴とする。
【００１７】
この構成によれば、引揚フラグが部品管理情報に含まれるため、組立場所において組立品を組立てた後に剰余となった部品を倉庫に引き揚げたか否かを管理することができる。また、引揚フラグが組立場所において組立品を組立てた後に剰余となった部品を倉庫に引き揚げたことを示す場合に、前記剰余となった部品である出庫先在庫予定数を前記倉庫に備えた引揚数に記憶させた後、前記出庫先在庫予定数を０とする。剰余となった部品の引き揚げ有無、現在在庫数と引揚数の加算するなら、引き揚げた部品についての倉庫における部品在庫の総数が管理できる。
【００１８】
そして、本発明に係る他の一態様では、１又は複数の部品から構成される組立品を１又は複数用いて構成される製品を生産するために、前記部品を管理するための第２部品管理情報を記憶する第４記憶部を備え、前記部品には、倉庫から必要数だけ出庫する部品と単位数で出庫する部品とが含まれ、前記第２部品管理情報には、前記部品コードと、前記部品コードに対応して現在保管されている部品の個数である現在在庫数と、組立場所において組立品を組立てた後に余剰となって引き揚げた部品について、該引き揚げた部品の部品コードに対応した部品の部品数である引揚数とが含まれることを特徴とする。
【００１９】
この構成によれば、部品管理装置には部品管理情報（第２部品管理情報）として、現在在庫数と引揚数が含まれるため、例えばリール品のような単位数で出庫する部品の部品管理と必要数だけ出庫する部品の部品管理とを区別して管理する必要がなく、単位数で出庫する部品が組立場所で組立品の組立後に余剰となり、倉庫に引き揚げた場合の部品の部品数が部品管理情報（第２部品管理情報）に含まれるため、引き揚げた部品につては現在在庫と引揚数を加算したものが、実際に倉庫に保管されている当該部品の総数として管理することができる。
【発明の効果】
【００２０】
本発明に係る部品管理装置に、グループコードが部品管理情報に含まれるため、製品の生産形態が種々雑多な状況に対して唯一のグループコードの概念だけで対処でき、管理者にとって簡単且つ判り易い操作で製造に必要な部品が管理できる。
【００２１】
そして、本発明に係る部品管理装置では、欠品予測情報には、部品コードと、部品の所要数と、実施形態で説明した第１充当残と、前記第２充当残とを用いると、この欠品予測情報を例えば出力部に出力させ、管理者は、所要数、第１充当残及び第２充当残を参照することによって、当該部品が充当可能であるのか否かを判断することができ、また、当該部品が充当可能である場合には、フリー在庫数又は注文残数で充当されるのか、あるいは、一方、当該部品が充当不可能である場合には、いつ充当できなくなるのか、充当可能にするには納期遅れの督促か、部品の前倒納入の交渉か、緊急に部品注文（発注）すべきかなど、必要な部品の個数と共に判断できる。
【００２２】
さらに、本発明に係る部品管理装置では、部品管理情報（第２部品管理情報）に現在在庫数と引揚数が含まれるので、例えばリール品のような単位数で出庫する部品の部品管理と必要数だけ出庫する部品の部品管理とを区別して管理する必要がなく、両者を部品管理情報（第２部品管理情報）により管理可能となる。また、集計の必要に応じて現在在庫数と引揚数を加算すれば、実際に倉庫に保管されている部品の総数も管理できると共に、組立場所おいて単位数で出庫する部品が余剰となっていると予想される部品数、組立場所の余剰品を引き揚げたかどうか、さらに単位数の部品が端数となっている状況を含め、部品の極めて詳細な情報が把握できるため、単位数で出庫する部品を組立場所ごとに管理する必要性が全くない。
【発明を実施するための最良の形態】
【００２３】
以下、本発明に係る実施形態を図面に基づいて説明する。なお、各図において同一の符号を付した構成は、同一の構成であることを示し、その説明を省略する。
（実施形態の構成）
図１は、実施形態における部品管理システムの構成を示す図である。図２は、実施形態における部品管理装置の構成を示すブロック図である。
【００２４】
図１において、部品管理システムＰＭＳは、部品を管理する部品管理装置１と、１又は複数の端末装置２とを備え、部品管理装置１と１又は複数の端末装置２とは、ネットワークＮＴで通信可能に接続される。部品管理システムＰＭＳは、いわゆるクライアント・サーバ・システムを構成しており、部品管理装置１は、いわゆるサーバコンピュータとして機能し、端末装置２は、いわゆるクライアントコンピュータとして機能する。
【００２５】
ネットワークＮＴは、有線又は無線の伝送路及び中継装置等を備えて構成される通信網であり、例えば、固定電話網、移動体通信網、ディジタル通信網及び無線通信網等である。ネットワークＮＴには、所定の通信プロトコルが用いられてデータが伝送される。通信プロトコルには、例えば、ＨＴＴＰ（Hyper Text Transfer Protocol）、ＦＴＰ（File Transfer Protocol）及びＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol）等のインターネットプロトコル群が用いられる。なお、ネットワークＮＴは、いわゆるローカル・エリア・ネットワーク（ＬＡＮ）でもよい。
【００２６】
端末装置２は、ネットワークＮＴを介して通信を行う端末側の通信インタフェース部と、この端末側の通信インタフェース部で受信した通信信号に収容されている情報を出力する端末側の出力部と、ユーザの操作を受付ける端末側の入力部と、これら端末側の通信部、出力部及び入力部を当該機能に応じてそれぞれ制御する端末側の演算処理部と、当該端末装置２を機能させる上で必要なプログラムやデータ等を記憶すると共に演算処理部のいわゆるワーキングメモリとなる端末側の記憶部とを備え、ネットワークＮＴを介して部品管理装置１と通信可能に接続されることによって、部品管理装置１との間で部品管理に関する情報をやり取りする。端末装置２は、実施形態では部品管理装置１がウェブサーバであることから、ウェブブラウザ等のアプリケーションソフトウェアを備えた通信機能付きのコンピュータ（携帯電話を含む）によって構成可能である。
【００２７】
部品管理装置１は、データベース管理機能を備え、ネットワークＮＴを介して部品管理装置１と通信可能に接続されることによって、端末装置２から部品管理に関する情報を受信して受け付けると共に端末装置２からの要求に応じて部品管理に関する情報を端末装置２へ送信して提供する。
【００２８】
部品管理装置１と端末装置２とは、ネットワークＮＴを介して通信信号を送受信して情報の交換を行うが、以下の説明ではネットワークＮＴを介する旨の記載を省略する。
【００２９】
部品管理装置１は、例えば、図２に示すように、演算処理部１０と、記憶部１１と、通信インタフェース部１２と、バス１３とを備えて構成される。
【００３０】
通信インタフェース部１２は、ネットワークＮＴに接続され、このネットワークＮＴを介して端末装置２との間で通信信号を送受信するためのインタフェース回路であり、演算処理部１０からのデータに基づいてネットワークＮＴの通信プロトコルに従った通信信号を作成すると共にネットワークＮＴからの通信信号を演算処理部１０が処理可能な形式のデータに変換する。
【００３１】
記憶部１１は、マスタ情報を記憶するマスタ情報記憶部１１１と、製品別組立品情報を記憶する製品別組立品情報記憶部１１２と、組立品別部品情報を記憶する組立品別部品情報記憶部１１３と、部品別所要数情報を記憶する部品別所要数情報記憶部１１４と、部品別所要数集計情報を記憶する部品別所要数集計情報記憶部１１５と、部品購買計画支援情報を記憶する部品購買計画支援情報記憶部１１６と、部品の注文情報を記憶する部品注文情報記憶部１１７と、注文した部品が納品受入された部品受入情報を記憶する部品受入情報記憶部１１８と、時期別部品保管情報を記憶する時期別部品保管情報記憶部１１９と、欠品予測状況情報を記憶する欠品予測情報記憶部１２０と、在庫数情報を記憶する在庫数情報記憶部１２１と、組立場所別出庫数情報を記憶する組立場所別出庫数情報記憶部１２２とを機能的に備え、部品管理を行う部品管理プログラム等の各種プログラム、及び、各種プログラムの実行に必要なデータやその実行中に生じるデータ等の各種データを記憶する。記憶部１１は、例えば、演算処理部１０のいわゆるワーキングメモリとなるＲＡＭ（Random Access Memory）等の揮発性の記憶素子、ＲＯＭ（Read Only Memory）や書換え可能なＥＥＰＲＯＭ（Electrically Erasable Programmable Read Only Memory）等の不揮発性の記憶素子、及び、比較的容量の大きいデータを記憶するハードディスク等を備えて構成される。
【００３２】
図３は、グループ、製品、組立品及び部品の相互関係を説明するための図である。図４は、実施形態における製品別組立品テーブルの構成を示す図である。図５は、実施形態における組立品別部品テーブルの構成を示す図である。
【００３３】
マスタ情報は、個々の製品、個々の組立品及び個々の部品に関する時々しか変化しない基本的な情報である。製品は、１又は複数の組立品を備え、１又は複数の組立品が当該製品の機能を実現するように相互に連携可能に組立てられて構成される。組立品は、１又は複数の部品を備え、１又は複数の部品が当該組立品の機能を実現するように相互に連携可能に組立てられて構成される。例えば、図３に示すように、第１製品１７１は、第１乃至第３組立品１７１１、１７１２、１７１３を備えて構成される。第１組立品１７１１は、第１乃至第３部品１７１１１、１７１１２、１７１１３を備えて構成される。
【００３４】
実施形態では、製品と組立品と部品との間にこのような関係があるため、例えば、製品に関するマスタ情報は、製品を生産するために必要となる情報であり、例えば、製品別組立品情報マスタは、製品を特定し識別するための識別子である製品コード、１個の当該製品を生産するために必要な1又は複数の組立品コード、１個の当該製品を生産するために必要な各組立品の個数である組立品員数、及び、製品を生産する場所（製品の組立場所）である出庫先等の各情報である。また例えば、組立品に関するマスタ情報は、組立品を組立てるために必要となる情報であり、例えば、組立品別部品情報マスタは、組立品を特定し識別するための識別子である組立品コード、１個の当該組立品を組立てるために必要な１又は複数の部品コード、１個の当該組立品を組立てるために必要な各部品の個数である部品員数、及び、組立品を組立てる場所（組立品の組立場所）である出庫先等の情報である。製品別組立品情報マスタと組立品別部品情報マスタの情報は、互いに組立品コードにより関連付け（リレーショナル）られている。
【００３５】
また例えば、部品に関するマスタ情報は、部品を注文（発注）するために必要となる情報であり、例えば、部品情報マスタは部品名、部品コード、部品型式（部品コードの代わりに利用してもよい）、ロット、リール単位数、部品のメーカ名、部品の注文先名、リール品識別記号、リードタイム、安全在庫数などの各情報である。組立品別部品情報マスタと部品情報マスタの情報は互いに部品コードにより関連付けられている。
【００３６】
ロットは、部品の購入単位である。部品情報マスタは製品の生産に使用する全部品を網羅し、例えば、テーブル形式でマスタ情報記憶部１１１に記憶される。
【００３７】
製品別組立品情報は、実施形態では、製品の生産計画が決定した時点で製品別組立品情報マスタに基づく情報（製品コード、組立品コード、組立品員数、出庫先）のほかに、一の生産計画において必要な製品の個数である製品計画数、製品計画数の製品を得るために必要な組立品の個数である組立品所要数、製品計画数の製品を生産するための組立品を組立てる場合に必要となる部品を取り揃えておくべき日付である出庫日の情報が追加される。
【００３８】
そして、注目すべきは、製品別組立品情報は、これら各情報に加えてさらに、グループを特定し識別するための識別子であるグループコードを含んでいる。グループは、製品の生産計画上において一括りにされる集合であり、一の生産計画が計画された場合に部品管理装置１によって自動的にあるいはユーザにより手動で付与される。生産計画は、例えば、受注に応じて計画された受注生産計画や市場動向に基づいた製品の需要予測に応じて計画された予測生産計画等の生産計画、及び、製品の販売目標を達成するために計画された販売計画等に応じて計画される。そして、生産計画に基づいて部品の購買計画が作成される。図３に示す例では、第１乃至第６製品１７１〜１７３、１８１、１８２、１９１が生産を計画されている。そして、この例では、第１乃至第３製品１７１〜１７３は、一の生産計画によって生産されるように計画されており、これら第１乃至第３製品１７１〜１７３を一括りにするために、第１グループが割り当てられている。第４及び第５製品１８１、１８２は、別の生産計画によって生産されるように計画されており、これら第４及び第５製品１８１、１８２を一括りにするために、第２グループが割り当てられている。そして、第６製品１９１は、さらに別の生産計画によって生産されるように計画されており、この第６製品１９１を一括りにするために、第３グループが割り当てられている。第６製品１９１は、実在の製品ではなく仮想の製品である。部品管理を行う上で、この仮想の製品を導入して仮想の製品を実在の製品と同様に部品管理装置１が取り扱うことによって、特に使用される製品を特定せずに先行的に生産する組立品も当該部品管理装置１によって管理可能となる。更に仮想の組立品にすれば単なる部品先行注文が可能となる。
【００３９】
グループコード、製品コード、組立品コード及び部品コードは、文字、数字及びこれらの組み合わせ等の１又は複数の符号によって構成される。図３に示す例では、第１乃至第３グループ１７、１８、１９には、それぞれＧ１〜Ｇ３がグループコードとして割り振られている。第１乃至第６製品１７１〜１７３、１８１、１８２、１９１には、それぞれＥ１〜Ｅ６が製品コードとして割り振られている。第１乃至第５組立品、第７乃至第１０組立品及び第１２組立品１７１１〜１７１３、１７２１、１７２２、１７３２、１８１１、１８２１〜１８２２、１９１１には、それぞれＡ１〜Ａ５、Ａ７〜Ａ１０、Ａ１２が組立品コードとして割り振られている。第１乃至第１２部品には、それぞれＰ１〜Ｐ１２が部品コードとして割り振られている。図３から分かるように、例えば、部品コードＰ２の部品が第１組立品１７１２、第４組立品１７２１、第６組立品１７３１、第８組立品１８１１及び第１０組立品１８２２に用いられているように、同一の部品は、異なる組立品でも用いられる。また同一の組立品も異なる製品で用いられる。例えば、第１製品１７１の第１組立品１７１１と第３製品１７３の第６組立品１７３１とは、同一の組立品コードを有する同一の組立品である。また例えば、第３製品１７３の第７組立品１７３２と第５製品１８２の第１１組立品１８２３も、同一の組立品コードを有する同一の組立品である。また部品コードも、グループ、製品及び組立品に無関係に同一の部品に対しては、同一の部品コードが割り振られている。
【００４０】
以下の説明において、グループ、製品、組立品及び部品に付される符号に代えて、グループコード、製品コード、組立品コード及び部品コードを各々付して説明する。
【００４１】
製品別組立品情報の各情報は、テーブル形式で製品別組立品情報記憶部１１２に記憶されており、例えば、図４に示すように、グループコードを登録するグループコードフィールド２１１、製品コードを登録する製品コードフィールド２１２、製品計画数を登録する製品計画数フィールド２１３、組立品コードを登録する組立品コードフィールド２１４、組立品員数を登録する組立品員数フィールド２１５、組立品所要数を登録する組立品所要数フィールド２１６、出庫日を登録する出庫日フィールド２１７、及び、出庫先を登録する出庫先フィールド２１８の各フィールドを備え、組立品コードごとにレコードが作成される製品別組立品テーブル２１にそれぞれ登録される。グループコード、製品コード、製品計画数及び出庫日は、例えば、端末装置２から受信されることによって製品別組立品テーブル２１に登録される。あるいは、グループコード、製品コード、製品計画数及び出庫日等の各情報を備える生産計画情報から抽出されることによって製品別組立品テーブル２１に登録される。組立品コード、組立品員数及び出庫先は、例えば製品コードを検索キーとして製品別組立品マスタから抽出され製品別組立品テーブル２１に登録される。組立品所要数は、製品計画数に組立品員数を乗算することによって求められ（（組立品所要数）＝（製品計画数）×（組立品員数））、製品別組立品テーブル２１に登録される。出庫日は、図４に示す例では、西暦の末尾２桁と、月と、日付とによって表記されている。例えば、０６０７１２は、２００６年７月１２日を表している。
【００４２】
なお、後述のグループコードフィールド２２１、２３１、２４１、２５１もグループコードフィールド２１１と同様にグループコードを登録するためのフィールドである。後述の製品コードフィールド２２２、２３２、３２１も製品コードフィールド２１２と同様に製品コードを登録するためのフィールドである。後述の組立品コードフィールド２２３、２３３、３２２も組立品コードフィールド２１４と同様に組立品コードを登録するためのフィールドである。後述の出庫日フィールド２２８、２３６、３１３、３２４も出庫日フィールド２１７と同様に出庫日を登録するためのフィールドである。
【００４３】
組立品別部品情報は、実施形態では、製品別組立品情報が得られた時点で組立品別部品マスタに基づく情報（組立品コード、部品コード、部品員数）のほかに、グループコード、製品コード、組立品所要数、組立品所要数の組立品を組立てるために必要な部品の個数である部品所要数、及び、出庫日の情報が追加される。部品コードは、実施形態では、部品が通常その型式によって注文されることから部品を注文する際の便宜のために、部品の型式を利用する。出庫日は、組立品を組立てるために必要な部品を取り揃えておくべき日付である。
【００４４】
組立品別部品情報の各情報は、テーブル形式で組立品別部品情報記憶部１１３に記憶されており、例えば、図５に示すように、グループコードフィールド２２１、製品コードフィールド２２２、組立品コードフィールド２２３、組立品所要数を登録する組立品所要数フィールド２２４、部品の型式を登録する部品型式フィールド２２５、部品員数を登録する部品員数フィールド２２６、部品所要数を登録する部品所要数フィールド２２７、及び、出庫日フィールド２２８の各フィールドを備え、組立品別であって部品ごとにレコードが作成される組立品別部品テーブル２２にそれぞれ登録される。グループコード、製品コード、組立品コード、組立品所要数及び出庫日は、製品別組立品テーブル２１から、例えば組立品コードを検索キーとして抽出され組立品別部品テーブル２２に登録される。また部品型式及び部品員数は、組立品コードを検索キーとして組立品別部品マスタから抽出され組立品別部品テーブル２２に登録される。部品所要数は、組立品所要数に部品員数を乗算することによって求められ（（部品所要数）＝（組立品所要数）×（部品員数））、組立品別部品テーブル２２に登録される。
【００４５】
なお、部品別所要数情報、部品別所要数集計情報、部品購買計画支援情報、時期別部品保管情報、欠品予測状況情報、在庫数情報及び組立場所別出庫数情報については、後述する。また、後述の部品型式フィールド２３４、２４２、２５２、３１１も部品型式フィールド２２５と同様に部品型式を登録するためのフィールドである。後述の部品所要数フィールド２３５、２４３、２５３、３１２、３２３も部品所要数フィールド２２７と同様に部品所要数を登録するためのフィールドである。
【００４６】
演算処理部１０は、例えば、マイクロプロセッサ及びその周辺回路等を備えて構成され、機能的に、ウェブサーバ部１０１と、部品の所要数を集計する情報処理を行う部品所要数集計処理部１０２と、部品の購買計画を支援する情報処理を行う部品購買計画支援処理部１０３と、欠品の予測や欠品状況を調べる情報処理を行う欠品予測処理部１０４と、部品の在庫を管理する情報処理を行う組立場所別出庫数処理部１０５とを備えると共に、制御プログラムに従い記憶部１１及び通信インタフェース部１２を当該機能に応じてそれぞれ制御する。ウェブサーバ部１０１は、端末装置２のウェブブラウザからデータを受信してこのデータに応じた情報処理を行うと共に、必要に応じて情報処理の結果のデータを送信する。
【００４７】
これら演算処理部１０、記憶部１１及び通信インタフェース部１２は、データを相互に交換することができるようにバス１３でそれぞれ接続される。
【００４８】
なお、必要に応じて、部品管理装置１は、図２に破線で示すように、入力部１４、出力部１５及び／又は外部記憶部１６をさらに備えてもよい。入力部１４は、部品購入計画の実行開始を指示する部品購入計画開始コマンド、及び、欠品予測の実行開始を指示する欠品予測開始コマンド等の各種コマンド、並びに、グループコード、製品コード、組立品コード、部品型式、製品計画数、組立品員数、出庫日及び部品員数等の部品管理に関する各種データ等を部品管理装置１に入力する機器であり、例えば、キーボードやマウスやタッチパネル等である。出力部１５は、入力部１４から入力されたコマンドやデータを出力する機器であり、例えばＣＲＴディスプレイ、ＬＣＤ（液晶ディスプレイ）、有機ＥＬディスプレイ又はプラズマディスプレイ等の表示装置やプリンタ等の印字装置等である。
【００４９】
このように部品管理装置１は、入力部１４及び出力部１５をさらに備え、かつ、ウェブブラウザ等のアプリケーションソフトウェアを備えることによって、端末装置２と同様に機能するように構成されてもよい。
【００５０】
外部記憶部１６は、例えば、フレキシブルディスク、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Compact Disc Recordable）及びＤＶＤ−Ｒ（Digital Versatile Disc Recordable）等の記録媒体との間でデータを読み込み及び／又は書き込みを行う装置であり、例えば、フレキシブルディスクドライブ、ＣＤ−ＲＯＭドライブ、ＣＤ−Ｒドライブ及びＤＶＤ−Ｒドライブ等である。
【００５１】
ここで、部品管理プログラム等の各プログラム及び部品管理に関する各種データ等の各データが格納されていない場合には、各プログラムや各データがこれらを記録した記録媒体から外部記憶部１６を介して記憶部１１にインストールされるように、部品管理装置１が構成されてもよく、また、これら各プログラムや各データを管理するサーバ（不図示）からネットワークＮＴを介して各プログラムや各データがダウンロードされるように、部品管理装置１が構成されてもよい。
【００５２】
次に、実施形態の動作について説明する。
（部品所要数集計及び部品購買計画支援）
生産は、生産計画に沿って実行され、生産計画は、受注や市場動向等の要因に応じて所定の期間、例えば１ヶ月ごとに計画され、要因の変化に応じて再計画される。従って、このような生産活動を支障無く円滑に行うためには、一の生産計画に必要な部品及び部品所要数を適切に把握し、部品を購入する期日と数量とを示す購買計画を立てる必要がある。実施形態では、一の生産計画ごとにグループコードが割り振られているので、これを部品の所要数を集計するための集計キーに利用することによって、一の生産計画に必要な部品の集計を簡単な操作で容易に実行することができる。そして、部品の所要数を集計した後に、これを時系列順に並べることによって、部品の購買計画を容易に計画することができる。
【００５３】
図６は、実施形態における部品別所要数を集計する動作を示すシーケンス図である。図７は、実施形態における部品別所要数テーブルの構成を示す図である。図８は、実施形態における部品別所要数集計テーブルの構成を示す図である。図９は、実施形態における部品購買計画を支援する動作を示すシーケンス図である。図１０は、実施形態における部品購買計画支援テーブルの構成を示す図である。
【００５４】
図６において、例えば、部品管理を行う立場等にあるユーザ（管理者）は、一の生産計画における部品別所要数を調べるために、端末装置２からウェブブラウザを用いて部品管理装置１にアクセスして、部品の所要数を集計する集計キーを端末側の入力部から端末装置２に入力する。集計キーが入力されると、端末装置２は、集計キーを部品管理装置１に送信する（Ｓ１１）。集計キーは、グループ（一の生産計画）ごとに、そして、部品ごとに部品所要数を集計するために、グループコードと部品コードとを組み合わせて構成される。実施形態では、さらに月ごとに部品所要数を集計するために、さらに年月が組み合わされ、集計キーは、「グループコード」＋「年月」＋「部品コード（部品型式）」で構成される。例えば、集計キーＧ１＋０６０７＋Ｐ２は、グループコードＧ１のグループで２００６年７月に必要となる部品コードＰ２の部品の所要数を集計するために用いられる。なお、集計キーにおける「グループコード」、「年月」及び「部品コード」の並び順は、任意でよい。
【００５５】
部品管理装置１は、ウェブサーバ部１０１によって集計キーを受信すると（Ｓ１２）、演算処理部１０の部品所要数集計処理部１０２によって、この受信した集計キーに応じた部品別所要数情報を生成する（Ｓ１３）。
【００５６】
部品別所要数情報は、この受信した集計キーに対応する部品の情報を組立品別部品情報から抽出したものである。部品別所要数情報は、実施形態では、グループコード、製品コード、組立品コード、部品型式、部品所要数、出庫日及び集計キーである。部品別所要数情報の各情報は、テーブル形式で部品別所要数情報記憶部１１４に記憶され、例えば、図７に示すように、グループコードフィールド２３１、製品コードフィールド２３２、組立品コードフィールド２３３、部品型式フィールド２３４、部品所要数フィールド２３５、出庫日フィールド２３６、及び、上記受信した集計キーを登録する集計キーフィールド２３７の各フィールドを備え、組立品ごとにレコードが作成される部品別所要数テーブル２３にそれぞれ登録される。
【００５７】
このような部品別所要数テーブル２３は、部品所要数集計処理部１０２によって、集計キーに含まれるグループコードがグループコードフィールド２２１に登録されており、集計キーに含まれる年月が出庫日フィールド２２８に登録されており、そして、集計キーに含まれる部品型式が部品型式フィールド２２５に登録されているレコードを組立品別部品テーブル２２から抽出することによって生成される。図７に示す例では、集計キーＧ１＋０６０７＋Ｐ２、Ｇ１＋０６０８＋Ｐ２、Ｇ２＋０６０７＋Ｐ２によって組立品別部品テーブル２２から抽出された各レコードの各情報に基づいて部品別所要数テーブル２３が生成されている。
【００５８】
ここでは、集計キーに含まれる出庫日を、集計キー＝グループコード＋出庫年月＋部品型式としたが、出庫日通りの出庫年月日としてもよいし、集計キー＝グループコード＋出庫区切日＋部品型式（または部品コード）としてもよい。本記述例の出庫年月の場合は７月の出庫日に該当する部品型式Ｐ２の全ての所要数を３０日間単位で集計することを意味する。出庫区切日とは、月２回の１５日間集計とか月３回の１０日間集計、月４回の約７日間集計にすることを意味する。例えば出庫区切日は、月２回集計とするなら、出庫日が２００６年７月１日から７月１５日のものは、出庫区切日は０６０７０１とし、同じく出庫日が７月１６日から７月３１日のものは出庫区切日を０６０７１６とする。すなわち集計キーに出庫区切日を用いる場合は、出庫年月と出庫日を区切ったその区切の通常は、初日を用いてもよいし、初日に限定しなくてもよい。
【００５９】
なお、後述の集計キーフィールド２４４、２５４、３１４も集計キーフィールド２３７と同様に集計キーを登録するためのフィールドである。
【００６０】
そして、部品管理装置１は、演算処理部１０の部品所要数集計処理部１０２によって、一の生産計画に必要な部品及び部品所要数を示す部品別所要数集計情報を部品別所要数情報から生成する（Ｓ１４）。より具体的には、部品所要数集計処理部１０２は、同一の集計キーが集計キーフィールド２３７に登録されているレコードを総て抽出する。次に、部品所要数集計処理部１０２は、この抽出した総てのレコードの部品所要数フィールド２３５に登録されている部品所要数の和（総和）を演算する。これによって集計キーに対応する部品の部品所要数が集計される。次に、部品所要数集計処理部１０２は、例えば、図８に示すように、グループコードフィールド２４１、部品型式フィールド２４２、部品所要数フィールド２４３及び集計キーフィールド２４４の各フィールドを備え、集計キーごとにレコードが作成される部品別所要数集計テーブル２４を作成する。部品所要数フィールド２４３には、集計された部品所要数が登録される。例えば、図７に示す例では、第１行目のレコードにおける集計キーフィールド２３７に登録されている集計キーと、第２行目のレコードにおける集計キーフィールド２３７に登録されている集計キーとは、Ｇ１＋０６０７＋Ｐ２で同一であり、これらレコードにおける部品所要数フィールド２３５に登録されている２０及び３０の和が演算され、図８に示すように集計キーフィールド２４４にＧ１＋０６０７＋Ｐ２が登録されているレコード（第１行目）における部品所要数フィールド２４３にその演算結果である５０が登録される。同様に、第４行目のレコードにおける集計キーフィールド２３７に登録されている集計キーと、第５行目のレコードにおける集計キーフィールド２３７に登録されている集計キーとは、Ｇ２＋０６０７＋Ｐ２で同一であり、これらレコードにおける部品所要数フィールド２３５に登録されている２０及び４０の和が演算され、図８に示すように集計キーフィールド２４４にＧ２＋０６０７＋Ｐ２が登録されているレコード（第３行目）における部品所要数フィールド２４３にその演算結果である６０が登録される。
【００６１】
そして、部品別所要数集計情報が生成されると、部品管理装置１は、ウェブサーバ部１０１によって部品別所要数集計情報を送信する（Ｓ１５）。部品別所要数集計情報を受信すると（Ｓ１６）、端末装置２は、ウェブブラウザによって部品別所要数集計情報を端末側の出力部に出力する（Ｓ１７）。例えば、図８に示すようにテーブル形式で部品別所要数集計情報がウェブブラウザによって端末装置２の出力部に出力され、例えば表示される。
【００６２】
このように動作することによってユーザが指定したグループコードを含む集計キーごとに部品の部品所要数が集計され、出力される。このため、ユーザは、グループコードを含む集計キーを指定するというわかり易い簡単な操作で容易に、一の生産計画ごとにさらに実施形態では年月ごとに、部品の部品所要数を調べることができる。
【００６３】
続いて、ユーザは、部品の購買計画を計画すべく、購買計画の計画開始の指示を端末側の入力部から端末装置２に入力する。購買計画の計画開始が入力されると、端末装置２は、購買計画の計画開始を部品管理装置１に送信する（Ｓ２１）。
【００６４】
部品管理装置１は、ウェブサーバ部１０１によって購買計画の計画開始を受信すると（Ｓ２２）、演算処理部１０の部品購買計画支援処理部１０３によって部品購買計画支援情報を生成する（Ｓ２３）。
【００６５】
部品購買計画支援情報は、部品の購買計画を計画するに当たってその支援を行うための情報である。部品購買計画支援情報は、実施形態では、グループコード、部品コード（部品型式）、部品所要数、集計キー、フリー在庫の部品数であるフリー在庫数、フリー注文残の部品数であるフリー注文残数、ロット、及び、購入を予定する部品数である計画購入数である。部品購買計画支援情報の各情報は、テーブル形式で部品購買計画支援情報記憶部１１６に記憶され、例えば、図１０に示すように、グループコードフィールド２５１、部品型式コードフィールド２５２、部品所要数フィールド２５３、上記処理Ｓ１２で受信した集計キーを登録する集計キーフィールド２５４、フリー在庫数を登録するフリー在庫数フィールド２５５、フリー注文残数を登録するフリー注文残数フィールド２５６、ロットを登録するロットフィールド２５７、及び、計画購入数を登録する計画購入数フィールド２５８の各フィールドを備え、集計キーごとにレコードが作成される部品購買計画支援テーブル２５に各々登録される。
【００６６】
処理Ｓ２３をより具体的に説明すると、部品購買計画支援処理部１０３は、まず、上記処理Ｓ１５で生成した部品別所要数集計テーブル２４の集計キーフィールド２４４に登録されている集計キーにおける「年月」に基づいて、部品別所要数集計テーブル２４の各レコードを時系列順に並べる。
【００６７】
次に、部品購買計画支援処理部１０３は、時系列順に並び替えた部品別所要数集計テーブル２４におけるグループコードフィールド２４１、部品型式コードフィールド２４２、部品所要数フィールド２４３及び集計キーフィールド２４４に登録されている各情報をレコードごとに順に部品購買計画支援テーブル２５におけるグループコードフィールド２５１、部品型式コードフィールド２５２、部品所要数フィールド２５３及び集計キーフィールド２５４に各々登録する。
【００６８】
次に、部品購買計画支援処理部１０３は、集計キーにおける「部品コード（部品型式）」に対応するロットを部品情報マスタから抽出し、部品購買計画支援テーブル２５の各レコードにおけるロットフィールド２５７に登録する。
【００６９】
次に、部品購買計画支援処理部１０３は、集計キーにおける「部品コード（部品型式）」に対応する部品のフリー在庫数及びフリー注文残数を部品購買計画支援テーブル２５の第１行目のレコードにおけるフリー在庫数フィールド２５５及びフリー注文残数フィールド２５６にそれぞれ登録する。このように動作することによって、例えば、図１０（Ａ）に示す部品購買計画支援テーブル２５が生成される。この図１０（Ａ）で示す例は、フリー在庫数が８であり、フリー注文残数が１５である場合を示している。
【００７０】
実施形態において、組立品別部品情報には組立品を組立てるために必要な部品所要数が含まれているため、出庫完了日などの情報を追加すれば出庫情報となり、出庫が必要な部品型式の出庫完了、出庫未完了の情報が取得できる。現時点（本日とする）までのフリー在庫数とは、組立品別部品情報から出庫日が本日までに出庫未完了の部品を部品型式ごとに集計する。この当該部品型式の集計数は、組立に必要な所要数であり組立引当数と呼称する。本日の現在在庫数は、在庫数情報記憶部１２１に記憶している。部品型式Ｐ２の現在在庫数が例えば６０とし、組立引当数が５２とする。自由に使用できるＰ２は８＝６０−５２、すなわちフリー在庫数８となる。次に部品注文情報記憶部１１７から抽出した本日までの注文残数が例えば１５とすれば、組立に必要な所要数は現在在庫数から充当されるので、この注文残数１５は自由に使用できる。すなわち注文残数がフリー注文残数１５となる。もし前述で集計した組立引当数が６６なら、現在在庫数６０を充当しても６不足し、フリー在庫数は０となる。この不足分６は、注文残数１５から充当することになり、フリー注文残数は９＝１５−６となる。
【００７１】
これを数式化すると、（フリー在庫数）＝（現在在庫数）−（組立引当数）、（フリー在庫数）＞０なら（注文残数）＝（フリー注文残数）となる。（フリー在庫数）＜０なら（フリー在庫数）＝０、（フリー注文残数）＝（注文残数）＋（フリー在庫数）、フリー在庫数が負数ならフリー注文残数は、注文残数とフリー在庫数の代数和となる。これが部品購買計画支援テーブル２５に例示する現在までのフリー在庫数８とフリー注文残数１５の算出根拠である。
【００７２】
そして、部品購買計画支援情報が生成されると、部品管理装置１は、ウェブサーバ部１０１によって部品購買計画支援情報を送信する（Ｓ２４）。部品購買計画支援情報を受信すると（Ｓ２５）、端末装置２は、ウェブブラウザによって部品購買計画支援情報を端末側の出力部に出力する（Ｓ２６）。例えば、図１０（Ａ）に示すようにテーブル形式で部品購買計画支援情報がウェブブラウザによって端末装置２の出力部に出力され、例えば表示される。
【００７３】
ユーザは、端末側の出力部に出力された図１０（Ａ）の部品購買計画支援テーブル２５を参照することによって、第１行目の部品所要数がフリー在庫数及びフリー注文残数によって充足するか否かを判断する。図１０（Ａ）に示す例では、第１行目の部品所要数が５０であり、一方、フリー在庫数及びフリー注文残数の和が２３であることから、２７個不足し、ユーザは、第１行目の部品所要数がフリー在庫数及びフリー注文残数によって充足していないと判断することができる。なお、部品管理装置１が部品購買計画支援テーブル２５を生成する際に、第１行目の部品所要数がフリー在庫数及びフリー注文残数によって充足するか否かを判断し、この判断の結果、充足していない場合には、その旨を示す情報を部品購買計画支援情報と併せてウェブサーバ部１０１によって端末装置２へ送信してもよい。そして、端末装置２は、この充足していない旨の情報を端末側の出力部に出力する。これは、例えばメッセージの表示や部品購買計画支援テーブル２５第１行目の反転表示等の表示によって行われる。
【００７４】
ユーザは、この２７個の不足を充足すべく、第１行目の計画購入数として少なくともこの不足を充足可能な個数、例えば１ロットの３０を端末側の入力部から端末装置２に入力する。なお、常に在庫として保有すべき安全在庫等も考慮して計画購入数を決定してもよい。第１行目の計画購入数が入力されると、端末装置２は、第１行目の計画購入数を部品管理装置１に送信する（Ｓ２７−１）。
【００７５】
部品管理装置１は、ウェブサーバ部１０１によって第１行目の計画購入数を受信すると（Ｓ２８−１）、演算処理部１０の部品購買計画支援処理部１０３によってこの第１行目の計画購入数に応じて部品購買計画支援情報を再生成する（Ｓ２９−１）。
【００７６】
より具体的には、部品購買計画支援処理部１０３は、まず、この処理Ｓ３０で受信した第１行目の計画購入数を第１行目のレコードにおける計画購入数フィールド２５８に登録する。次に、部品購買計画支援処理部１０３は、この処理Ｓ３０で受信した第１行目の計画購入数に基づいたフリー在庫数及びフリー注文残数を計算する。フリー在庫数は、第１行目のフリー在庫数から部品所要数を減算することによって計算される。なお、計算の結果、フリー在庫数が負となる場合には、フリー在庫数は、０とされる。フリー注文残数は、第１行目のフリー在庫数、フリー注文残数及び計画購入数の和から部品所要数を減算することによって計算される。そして、部品購買計画支援処理部１０３は、第２行目のレコードにおけるフリー在庫数フィールド２５５及びフリー注文残数フィールド２５６にこの計算結果のフリー在庫数及びフリー注文残数をそれぞれ登録する。図１０（Ａ）に示す例では、フリー在庫数は、８−５０＝−４２→０と計算され、フリー注文残数は、８＋１５＋３０−５０＝３と計算される。このように動作することによって、例えば、図１０（Ｂ）に示す部品購買計画支援テーブル２５が再生成される。
【００７７】
このように部品購買計画支援テーブル２５の再生成では、まず、受信した第ｎ−１行目の計画購入数が第ｎ−１行目のレコードにおける計画購入数フィールド２５８に登録される。次に、受信した第ｎ−１行目の計画購入数に基づいた第ｎ行目のレコードにおけるフリー在庫数及びフリー注文残数が計算される。第ｎ行目のレコードにおけるフリー在庫数は、第ｎ−１行目のフリー在庫数から第ｎ−１行目の部品所要数を減算することによって計算される。第ｎ行目のレコードにおけるフリー注文残数は、第ｎ−１行目のレコードにおけるフリー在庫数、フリー注文残数及び計画購入数の和から第ｎ−１行目のレコードにおける部品所要数を減算することによって計算される。そして、第ｎ行目のレコードにおけるフリー在庫数フィールド２５５及びフリー注文残数フィールド２５６にこの計算結果のフリー在庫数及びフリー注文残数がそれぞれ登録される。こうして部品購買計画支援テーブル２５が再生成される。
【００７８】
そして、部品購買計画支援情報が再生成されると、部品管理装置１は、ウェブサーバ部１０１によってこの再生成された部品購買計画支援情報を送信する（Ｓ３０−１）。再生成の部品購買計画支援情報を受信すると（Ｓ３１−１）、端末装置２は、ウェブブラウザによって再生成の部品購買計画支援情報を端末側の出力部に出力する（Ｓ３２−１）。
【００７９】
ユーザは、端末側の出力部に出力された図１０（Ｂ）の部品購買計画支援テーブル２５を参照することによって、第２行目の部品所要数がフリー在庫数及びフリー注文残数によって充足するか否かを判断する。図１０（Ｂ）に示す例では第２行目の部品所要数が７０であり、一方、フリー在庫数及びフリー注文残数の和が３であることから、６７個不足し、ユーザは、第２行目の部品所要数がフリー在庫数及びフリー注文残数によって充足していないと判断することができる。
【００８０】
ユーザは、この６７個の不足を充足すべく、第２行目の計画購入数として少なくともこの不足を充足可能な個数、例えば３ロットの９０を端末側の入力部から端末装置２に入力する。第２行目の計画購入数が入力されると、端末装置２は、第２行目の計画購入数を部品管理装置１に送信する（Ｓ２７−２）。
【００８１】
部品管理装置１は、ウェブサーバ部１０１によって第２行目の計画購入数を受信すると（Ｓ２８−２）、演算処理部１０の部品購買計画支援処理部１０３によってこの第２行目の計画購入数に応じて部品購買計画支援情報を再生成する（Ｓ２９−２）。そして、部品購買計画支援情報が再生成されると、部品管理装置１は、ウェブサーバ部１０１によってこの再生成された部品購買計画支援情報を送信する（Ｓ３０−２）。再生成の部品購買計画支援情報を受信すると（Ｓ３１−２）、端末装置２は、ウェブブラウザによって再生成の部品購買計画支援情報を端末側の出力部に出力する（Ｓ３２−２）。
【００８２】
ユーザは、端末側の出力部に表示された図１０（Ｃ）の部品購買計画支援テーブル２５を参照することによって、第３行目の部品所要数がフリー在庫数及びフリー注文残数によって充足するか否かを判断する。図１０（Ｃ）に示す例では、第３行目の部品所要数が１６であり、一方、フリー在庫数及びフリー注文残数の和が２３であることから、充足していると判断することができる。
【００８３】
ユーザは、充足しているので、第３行目の計画購入数として０を端末側の入力部から端末装置２に入力する。第３行目の計画購入数が入力されると、端末装置２は、第３行目の計画購入数を部品管理装置１に送信する（Ｓ２７−３）。
【００８４】
以下同様に、部品管理装置１による部品購買計画支援テーブル２５の再生成とユーザによる計画購入数の入力とが部品購買計画支援テーブル２５の最終行まで順次に実行される。部品購買計画支援テーブル２５の最終行まで実行されると、部品購買計画支援テーブル２５の再生成が終了され、部品購買計画支援テーブル２５が完成する（Ｓ２９−ｎ、Ｓ３３）。そして、部品購買計画支援情報が完成されると、部品管理装置１は、ウェブサーバ部１０１によってこの完成された部品購買計画支援情報を送信する（Ｓ３４）。完成された部品購買計画支援情報を受信すると（Ｓ３５）、端末装置２は、ウェブブラウザによってこの部品購買計画支援情報を端末側の出力部に出力する（Ｓ３６）。
【００８５】
このように動作することによってユーザは、部品購買計画支援テーブル２５を参照することによって、指定したグループコードを含む集計キーごとに順次に計画購入数を決定することができる。このため、ユーザは、グループコードを含む集計キーを指定するというわかり易い簡単な操作で容易に、部品の計画購入数を決定することができる。そして、ユーザは、決定した部品の計画購入数に従って集計キーごとに購買計画が決定できる。
【００８６】
実施形態では、集計キーは、「グループコード」、「年月」及び「部品コード（部品型式）」によって構成されているので、部品購買計画支援テーブル２５を参照することによって、ユーザは、どのグループコード（生産計画）に対して何時までにどの部品をいくつ購買すべきかを知ることができる。注文（発注）は、注文してから納品されるまでの期間であるリードタイムを考慮した上で、出庫日に基づいて行われる。即ち、注文日は、出庫日からリードタイムだけ遡った日以前の日である。注文は、集計キーごとに行われてもよいし、グループ別に行われてもよいし、あるいは、複数の集計キーを纏めて行われてもよいし、複数のグループを纏めて行われてもよい。例えば、図１０（Ｃ）に示す例では、各行ごとの計画購入数で注文が為されてもよいし、第１行目と第２行目との計画購入数を纏めて２００６年７月分として注文してもよい。
【００８７】
ユーザは、購買計画に従って部品を注文する。注文する部品の注文先は、購買計画支援情報記憶部１１６とマスタ情報記憶部１１１の部品情報マスタに各々記憶されている部品型式と関連付けて知ることができる。そして、注文を行った場合には、ユーザは、注文情報を端末側の入力部から端末装置２に入力する。注文情報が入力されると、端末装置２は、注文情報を部品管理装置１に送信する。部品管理装置１は、注文情報を受信すると、注文情報をテーブル形式で記憶部１１の部品注文情報記憶部１１７に記憶する。注文情報は、例えば、注文を特定し識別するために注文ごとに割り振られる注文番号、注文した部品の部品型式、注文した部品の個数である注文数、注文を行った日付である注文日、納品の予定日である納期、及び、先行部品注文であるか否かを示す情報等である。先行部品注文は、使用する組立品が決まっていない部品の注文である。
【００８８】
一方、注文した部品が納品されると、ユーザは、納品情報を端末側の入力部から端末装置２に入力する。納品情報が入力されると、端末装置２は、納品情報を部品管理装置１に送信する。部品管理装置１は、納品情報を受信すると、納品情報をテーブル形式で記憶部１１の部品受入情報記憶部１１８に記憶すると共に、納品情報に応じて、納品された部品の注文情報を記憶部１１の部品注文情報記憶部１１７から削除すると共に、在庫情報記憶部１２１の入庫数と現在在庫数の情報が更新される。納品情報は、例えば、注文番号、納品された部品の部品型式、納品された部品の個数である納品数、及び、納品された日付である納品日等である。納品された部品の注文情報が部品注文情報記憶部１１７から削除されるので、部品注文情報記憶部１１７には、注文したが納品されていない部品の注文（注文残）が記憶されていることになる。
【００８９】
通常、生産計画は、計画した後に、市場動向の変化、受注数量の変化、生産設備のトラブル及び生産に必要な部品の納品遅れ等の様々な要因によって変更を余儀なくされるケースがある。このようなケースでは、実施形態では、一の生産計画には、グループコードが割り振られているので、グループコードを指定して、当該生産計画に係る情報が部品管理装置１から一括での削除が可能である。そして、変更後の生産計画で新たなグループコードを割り振って製品別組立品情報の生成から始まる一連の動作により、部品所要数の集計や購買計画を新たに決定することができる。
【００９０】
このように実施形態の部品管理装置１ではグループコードを用いるために、ユーザは判り易く簡単な操作で部品を管理することができる。
【００９１】
グループコードを利用すると、これを比喩的に述べるなら、バラで荷積みにするか、コンテナに纏めて荷積みするかの違いほどにその利便性が向上する。
【００９２】
なお、図９の部品管理装置と端末装置の通信は、大半が自動処理される。
【００９３】
自動処理を要約すると、テーブル２５の1行目−２３＝（８＋１５−５０）となり、部品所要数を２３だけ充当できないため、計画購入数３０となる。これは購入単位（ロット）が３０のため２３の注文はできないためである。２行目は、１行目３＝（８＋１５＋３０−５０）計画購入数３０を計画したため、フリー注文残数３となる。且つ１行目のフリー在庫数は−４２＝（８−５０）、１行目の部品所要数に充当し負数となるため、２行目のフリー在庫数は０となる。２行目の部品所数７０は充当できないため計画購入数９０を必要とする。２３＝（３＋９０−７０）となり、３行目のフリー注文残数は２３となる。７＝（２３−１６）となり、４行目のフリー注文残数７となる。これが図１０（Ａ）、図１０（Ｂ）、図１０（Ｃ）の経過であり、これらは１行目のフリー在庫数８、フリー注文残数１５を含め、フリー在庫フィールド２５５、フリー注文残数フィールド２５６、計画購入数フィールド２５８は、プログラム処理で各々登録される。フィールド２５１〜２５４のレコードも集計キーを用いて自動的に生成されることも当然である。通信と手動操作が介在するのは、これら数値を確認しながら注文する場合であり、注文すればその結果は、注文番号、納期等などの注文情報を付加して部品注文情報記憶部１１７に記憶される。
【００９４】
（欠品予測）
このような動作によって部品の所要数が集計され、部品の購買計画が計画され、部品の注文が行われたとしても、所要数の部品が出庫日までに総て取り揃えられていなければ、生産活動を支障無く円滑に行うことができなくなる。特に、実世界では、製造期間の短縮、飛び入りによる製品の生産、部品購買納期の遅延等がしばしば生じ、生産計画の通りに製品を生産することができない場合が多い。このため、ユーザにより指定され予め設定した将来の日付（以下将来の日付と記述する）まで、部品の所要数が足りているか否かを予測することが重要となる。
【００９５】
図１１は、実施形態における欠品予測の動作を示すシーケンス図である。図１２は、実施形態における時期別部品保管テーブルの構成を示す図である。図１３は、実施形態における欠品予測テーブルの構成を示す図である。
【００９６】
ユーザは、将来における欠品を予測するために、端末装置２からウェブブラウザを用いて部品管理装置１にアクセスして、将来の日付（例えば欠品予測する本日からＮ日後の日付）を指定して欠品予測の開始指示を端末側の入力部から端末装置２に入力する。
【００９７】
図１１において、将来の日付及び欠品予測の開始指示が入力されると、端末装置２は、これらを部品管理装置１に送信する（Ｓ４１）。部品管理装置１は、ウェブサーバ部１０１によって将来の日付及び欠品予測の開始指示を受信すると（Ｓ４２）、演算処理部１０の欠品予測処理部１０４によって、この受信した将来の日付に応じた時期別部品保管情報を生成する（Ｓ４３）。
【００９８】
時期別部品保管情報は、将来の日付までにおける部品の保管状況を表す情報である。時期別部品保管情報は、実施形態では、例えば、部品型式、部品所要数、出庫日、集計キー、在庫数、現在残数、将来残数、及び納期である。時期別部品保管情報の各情報は、記憶部１１の時期別部品保管情報記憶部１１９にテーブル形式で記憶され、例えば、図１２に示すように、部品型式フィールド３１１、部品所要数フィールド３１２、出庫日フィールド３１３、集計キーフィールド３１４、在庫数を登録する在庫数フィールド３１５、現在残数を登録する現在残数フィールド３１６、将来残数を登録する将来残数フィールド３１７、及び、納期を登録する納期フィールド３１８の各フィールドを備え、集計キーごとにレコードが作成される時期別部品保管テーブル３１にそれぞれ登録される。
【００９９】
このような時期別部品保管テーブル３１は、例えば、組立品別部品テーブル２２、完成後の部品購買計画支援テーブル２５、部品注文情報記憶部１１７（テーブル図略）の注文情報、在庫数情報記憶部１２１の在庫数情報に基づいて生成され得る。より具体的には、演算処理部１０の欠品予測処理部１０４は、まず、「出庫年月日＋部品型式」を集計キーとして、部品別所要数テーブル２３の生成と同様な一連の処理を行うと全ての部品型式の部品所要数が集計できる。この場合の出庫年月日は、現時点から将来の日付までの範囲である。これにより部品型式、部品所要数、出庫日が決定される。欠品予測処理部１０４は、これら各情報を時期別部品保管テーブル３１における部品型式フィールド３１１、部品所要数フィールド３１２、出庫日フィールド３１３及び集計キーフィールド３１４にそれぞれ登録する。次に、欠品予測処理部１０４は、各部品型式ごとに現時点までのフリー在庫数及び現時点までのフリー注文残数を集計し、この集計したフリー在庫数及びフリー注文残数（本例ではフリー在庫数＞０のため、現時点までの注文残数が全てフリー注文残数である。この意味と集計方法は、処理Ｓ２３の説明の処で前述している）を時期別部品保管テーブル３１の在庫数フィールド３１５及び現在残数フィールド３１６に各々登録する。そして、欠品予測処理部１０４は、各部品型式ごとに部品注文情報記憶部１１７に記憶する情報により現時点から将来の日付までの全ての注文残数と当該注文残数の納期を抽出し、時期別部品保管テーブル３１の将来残数フィールド３１７に注文残数、納期フィールド３１８に納期を登録する。これにより時期別部品保管テーブル３１が生成される。
【０１００】
次に、部品管理装置１は、欠品予測処理部１０４によって、将来の日付までに欠品の虞ある部品を時期別部品保管情報から抽出する（Ｓ４４）。この抽出は、次の式１乃至式３を用いて実行する。
(在庫数−部品所要数)＞０                                          ・・・（式１）
フリー在庫数から部品所要数が充当できるため欠品の虞ない。
（在庫数＋将来残数−部品所要数）＞０                              ・・・（式２）
フリー在庫数と出庫日までの注文残数を用いて充当できるため欠品の虞ない。
（在庫数＋現在残数＋将来残数−部品所要数）＜０                    ・・・（式３）
フリー在庫数と出庫日までの注文残数を用いても充当できないため欠品の虞ある。
式２、式３では、（将来残数の納期）＜（部品所要数の出庫日）を満たす将来残数とする。
また式１から式３までの順に判定を行う。
【０１０１】
図１２に示す例では、１行目の部品型式Ｐ１は、（１０＋５＋３０−５０）＜０となり式３が成立し欠品の虞がある。２行目の部品型式Ｐ２は、（３０−２０）＞０となり式１が成立し欠品の虞がない。３行目の部品型式Ｐ３は、（３０＋２０＋６０−１００）＞０となり式３が成立せず欠品の虞がない。４行目の部品型式Ｐ３は、｛（３０＋２０＋６０）−（１００＋８０）｝＜０となり式３が成立し欠品の虞がある。
【０１０２】
４行目は、同じ部品型式Ｐ３の注文残数が納期を異にして複数行存在ケースでは、現時点までのフリー在庫数およびフリー注文残数を在庫数３１５と現在残数３１６の最初の行（テーブル３１の3行目、３０と２０）に登録する。且つフリー注文残数も納期を異にして複数存在することもあるが、これは現時点までのフリー注文残数として集計し１つの残数にする。この残数の納期は現時点までを集計しているため、現時点から将来の日付までの納期の注文残数を登録している将来残数の納期より必ず早い納期である。またフリー在庫数は当然ながら1行に登録できる1つの数である。部品所要数は出庫日の順に並んでいるものとする。
【０１０３】
さて以上の前提では、部品型式Ｐｎが複数行存在する２行目以降のｎ行目は、ｎ行目の出庫日より早い将来残数の合計と複数行１行目の在庫数と現在残数とを加算し、当該１行目から当該ｎ行目までの部品所要数を合計し、その充当の可否を判断する。これは式３による判断である。現在残数が加算できるのは、必ず早い納期であるとの前述の前提による。
【０１０４】
以上のように時期別部品保管情報から欠品の虞ある部品が抽出されると、部品管理装置１は、欠品の虞ある部品一覧である欠品部品情報をウェブサーバ部１０１によって端末装置２に送信する（Ｓ４５）。欠品部品情報は、例えば、将来の日付までに欠品の虞ある部品の部品型式などを含む。欠品部品情報を受信すると（Ｓ４６）、端末装置２は、ウェブブラウザによって欠品部品情報を端末側の出力部に出力(表示)する（Ｓ４７）。
【０１０５】
ユーザは、欠品部品情報を参照することによって、将来の日付までに欠品の虞ある部品を知ることができる。欠品の虞ある部品の詳細状況を知りたい場合には、欠品部品情報中からユーザが部品型式を指定する。部品型式の指定は例えば部品型式を端末側の入力部から端末装置２に入力する。あるいはマウスによりクリックする。部品型式が指定されると、端末装置２は、部品型式及び欠品予測状況情報の生成を指示する生成開始情報を部品管理装置１に送信する（Ｓ４８）。部品管理装置１は、ウェブサーバ部１０１によって部品型式及び欠品予測状況情報の生成開始情報を受信すると（Ｓ４９）、演算処理部１０の欠品予測処理部１０４によって、この受信した部品型式に応じた欠品予測状況情報を生成する（Ｓ５０）。
【０１０６】
欠品予測状況情報は、ユーザにより指定され予め設定した将来の日付（以下将来の日付と記述する）までの部品の欠品状況を表す情報である。
【０１０７】
欠品予測状況情報は、実施形態では、例えば、ユーザにより指定された部品型式の現時点までのフリー在庫数及びフリー注文残数と、該部品の現時点から将来の日付までの製品コード、組立品コード、部品所要数、出庫日、注文残数、納期、注文番号と、フリー在庫数から部品所要数を順次充当した後において予測されるフリー在庫数である第１充当残、第１充当残が負数になった場合に、注文残数から部品所要数を順次充当した後において予測されるフリー注文残数である第２充当残である。欠品予測状況情報の各情報は、記憶部１１の欠品予測情報記憶部１１８にテーブル形式で記憶され、例えば、図１３に示すように、製品コードフィールド３２１、組立品コードフィールド３２２、部品所要数フィールド３２３、出庫日フィールド３２４、第１充当残数を登録する第１充当残フィールド３２５、第２充当残数を登録する第２充当残フィールド３２６、注文残数を登録する注文残数フィールド３２７、当該注文残数の納期を登録する納期フィールド３２８、及び、当該注文残数の注文番号を登録する注文番号フィールド３２９の各フィールドを備える欠品予測テーブル３２に各々登録される。欠品予測テーブル３２は、ユーザにより指定された部品型式ごとに生成する。
【０１０８】
このような欠品予測テーブル３２は、より具体的には、演算処理部１０の欠品予測処理部１０４は、まず、「ユーザが指定した部品型式Ｐ４＋出庫年月日＋製品コード＋組立品コード」を集計キーとして、部品別所要数テーブル２３の生成と同様な一連の処理を行うと部品型式Ｐ４の部品所要数が集計できる。次に、欠品予測処理部１０４により生成した部品別所要数テーブル２３における製品コードフィールド２３２、組立品コードフィールド２３３、部品所要数フィールド２３５及び出庫日フィールド２３６に登録されている製品コード、組立品コード、部品所要数及び出庫日を、欠品予測テーブル３２の２行目以降における製品コードフィールド３２１、組立品コードフィールド３２２、部品所要数フィールド３２３及び出庫日フィールド３２４に各々登録する。次に、欠品予測処理部１０４は、出庫日順に各レコードを並び替える。次に、欠品予測処理部１０４は、ユーザにより将来の日付までの注文残数、納期及び注文番号を部品注文情報記憶部１１７から抽出し、この各情報を欠品予測テーブル３２の２行目以降における注文残数フィールド３２７、納期フィールド３２８及び注文番号フィールド３２９に各々登録する。次に、欠品予測処理部１０４は、ユーザにより指定された部品型式と該部品型式の現時点までのフリー在庫数及びフリー注文残数を集計し抽出し、欠品予測テーブル３２の1行目の第１充当残フィールド３２５にフリー在庫数を、同じ1行目の注文残数フィールド３２７にフリー注文残数を登録する。そして、欠品予測処理部１０４は、２行目以降に、第１充当残及び第２充当残を各々計算し、各計算結果を第１充当残フィールド３２５及び第２充当残フィールド３２６に各々登録する。第１充当残の２行目は１行目のフリー在庫数から２行目の部品所要数を充当した残り（減算した結果）を登録する。
【０１０９】
例えば、図１３に示す例では第１充当残の２行目は１３０＝（２３０−１００）、３行目は１１０＝（１３０−２０）４行目は−１０＝（１１０−１２０）となる。
【０１１０】
欠品予測テーブル３２の１行目注文残数フィールド３２７には、現時点までのフリー注文残数は集計し登録しているため、納期フィールド３２８の最も早い納期より以前の納期である。第２充当残は、第１充当残が負数になった行を1行目とし、（テーブル３２の４行目）は、出庫日０６０７１２＞納期０６０７０８となっている注文残数１００とフリー注文残数１２（テーブル３２の１行目）を加算し、１０２＝１１２−１０となる。これは第１充当数の不足数−１０が注文残数の１１２から充当されることを意味する。２行目（テーブル３２の５行目）は９２＝（１０２＋４０−５０）、３行目（テーブル３２の６行目）は−３８＝（９２−１３０）となる。
【０１１１】
第１充当残の２行目は、１行目のフリー在庫数から２行目の部品所要数を減算した結果を登録する。以下第１充当残のｎ行目は、ｎ−１行目の第１充当残からｎ行目の部品所要数を減算した結果を登録する。第１充当残が負数になった行で計算を終了する。次に第２充当残は、第１充当残が負数となった行を１行目とする。この１行目は、１行目の出庫日より早い納期となっている注文残数の合計とフリー注文残数（テーブル３２の１行目）を加算し、第１充当数との代数和を登録する。ｎ行目はｎ行目の出庫日と（ｎ−１）行目の出庫日の間にある納期の注文残数の集計値と（ｎ−１）行目の第２充当残との合計からｎ行目の部品所要数を減算し、その結果をｎ行目に登録する。第２充当残が負数となった行で終了する。又は最終行まで続行してもよい。このように動作させて欠品予測テーブル３２を生成する。
【０１１２】
そして、欠品予測状況情報が生成されると、部品管理装置１は、ウェブサーバ部１０１によってこの生成された欠品予測状況情報を送信する（Ｓ５１）。この欠品予測状況情報を受信すると（Ｓ５２）、端末装置２は、ウェブブラウザによって欠品予測状況情報を端末側の出力部に出力する（Ｓ５３）。例えば、図１３に示すようにテーブル形式で欠品予測状況情報がウェブブラウザによって端末装置２の出力部に出力され、例えば表示される。
【０１１３】
ユーザは、端末側の出力部に出力された図１３の欠品予測テーブル３２を参照することにより、欠品を予防するに充分な情報が取得できる。すなわち実施形態では、欠品予測状況情報として、どの製品のどの組立品に如何なる部品型式の部品が何日に何個が欠品する虞ありや否や、欠品の虞ありでは注文残数により充当できるや否や、且つその注文番号は何かなどが判明する。その状況が納期遅れなら納品を督促し、あるいは注文残数の前倒し納品を交渉すべきか、部品が注文不足なら緊急に注文すべきかの判断が事前にできる。欠品予測は、計算上では欠品の虞なしの部品であっても、怪しいと直感する部品型式を指定すれば、当該部品の充当残の状況をも知り得るため、製造業にとって致命的な欠品を予防する絶大な効果を発揮する。
【０１１４】
なお、実施形態では欠品予測状況情報の有用性は、このように欠品の予防に必要且つ充分な情報が一括して生成されることにあるが、如何なる部品型式の部品が何日に何個の欠品の虞あるか最低限の情報でもよい。すなわちフリー在庫数から充当による第１充当残と、注文残からの充当による第２充当残の情報を生成する。
【０１１５】
あるいは１つの充当残を設け、現時点までのフリー在庫数が存在する場合はフリー在庫数から充当し、フリー在庫数の充当が負数になった時点から注文残数から充当する如く、引続き１つの充当残に情報を生成してもよい。実施形態では実用上の判り易さを考慮し第１及び第２の２つの充当残を設けて説明した。
【０１１６】
また欠品予測状況情報の生成の手段は実施形態に依らなくてよいし、極端な場合、充当残は○、Ｘの登録であってもよい。
【０１１７】
（リール品を含む部品在庫管理）
部品には、必要数だけ出庫する部品と、リール品のように例えば数百から数千個等の複数個単位を出庫される部品とがある。前者の部品は、組立場所に必要数だけ倉庫から出庫可能であるが、後者の部品は、組立場所が必要とする数を超えて出庫する必要が生じる。例えば、あるリール品について１０００個が１つのリール単位数になっている場合、組立場所において、該リール品３００個しか必要としなくても１つのリール単位数で出庫することが往々に行われる。通常、製品の生産に必要な部品は組立場所ごとに出庫するため、複数の組立場所が存在する場合、組立場所ごとの所要数に応じてリール単位数の整数倍の出庫が必要となる。単位数で出庫する部品は部品の数のみで管理すると所要数総量では充当されても、リール単位数では欠品が生じ生産に支障が生じる。欠品予測の手段もなく、欠品を防ぐには組立場所別に注文し、在庫管理し、出庫管理するのが最善策である。
【０１１８】
しかしながら、組立場所別の管理は大変煩雑になるばかりでなく、無視できない余分な在庫の保有を余儀なくされる。
【０１１９】
本発明は、必要数だけ出庫する部品と単位数で出庫する部品の出庫管理は区別して行うが、他は全て両者を区別せずに管理し、組立場所別管理の欠点を解消することが目的である。
【０１２０】
なお、リール品は、単位数で出庫する部品の典型であるが、他の部品でも差し支えない。
【０１２１】
図１４は、実施形態における在庫数テーブルの構成を示す図である。図１５は、実施形態における組立場所別出庫数テーブルの構成を示す図である。図１６は、実施形態における出庫数入力動作を示すシーケンス図である。
【０１２２】
実施形態における在庫管理は、倉庫に保管されている部品の個数の状況を表す在庫数情報と、倉庫から出庫された部品の個数の状況を組立場所別に表す組立場所別出庫数情報とから行われる。
【０１２３】
在庫数情報は、必要数だけ出庫する部品と単位数で出庫する部品も含み、製品の生産に使用する全部品を網羅している。実施形態では、例えば、部品コード（部品型式）、前日の在庫数を表す前日在庫数、倉庫から搬出された部品の個数を表す出庫数、倉庫へ搬入された部品の個数を表す入庫数、現在の在庫数を表す現在在庫数、及び、組立品の組立後に余剰となった部品を組立場所から倉庫に引き揚げたことを表す引揚数である。在庫数情報の各情報は、記憶部１１の在庫数情報記憶部１２２にテーブル形式で記憶され、例えば、図１４に示すように、部品型式フィールド４１１、前日在庫数を登録する前日在庫数フィールド４１２、出庫数を登録する出庫数フィールド４１３、入庫数を登録する入庫数フィールド４１４、現在在庫数を登録する現在在庫数フィールド４１５、及び、引揚数を登録する引揚数フィールド４１６の各フィールドを備え、部品型式ごとにレコードが作成される在庫数テーブル４１に各々登録される。
【０１２４】
このような在庫数情報は、ユーザが部品を出庫又は入庫するごとに、端末側の入力部から部品の出庫数又は入庫数を端末装置２へ入力することによって生成可能である。端末装置２に部品の出庫数又は入庫数が入力されると、端末装置２は、この部品の出庫数又は入庫数を部品管理装置１へ送信する。部品の出庫数又は入庫数が受信されると、部品管理装置１は、演算処理部１０の組立場所別出庫数処理部１０５によって、この受信した部品の出庫数又は入庫数で在庫数情報における当該部品の出庫数又は入庫数を更新すると共に、この受信した部品の出庫数又は入庫数で現在在庫数を計算し、在庫数情報における現在在庫数をこの計算後の現在在庫数で更新する。そして、部品管理装置１は、組立場所別出庫数処理部１０５によって、日が改まると、例えば午前０時に在庫数情報の現在在庫数で前日在庫数を更新する。このように動作して在庫数情報が生成される。
【０１２５】
組立場所別出庫数情報は、実施形態では、例えば、部品コード（部品型式）、出庫数、組立場所で組立品の組立に必要な部品の個数である出庫先所要数、当該組立場所で組立品の組立後に余剰になると予想される部品の個数である出庫先在庫予定数、１リールの部品数であるリール単位数、及び、当該組立場所に残る部品を倉庫に引き揚げたか否かを表す引揚フラグである。在庫組立場所別出庫数情報の各情報は、記憶部１１の組立場所別出庫数情報記憶部１２２にテーブル形式で記憶され、例えば、図１５に示すように、部品型式フィールド４２１、出庫数を登録する出庫数フィールド４２２、出庫先所要数を登録する出庫先所要数フィールド４２３、出庫先在庫予定数を登録する出庫先在庫予定数フィールド４２４、１リールの部品数を登録するリール単位数フィールド４２５、及び、引揚フラグを登録する引揚フラグフィールド４２６の各フィールドを備え、部品型式ごとにレコードが作成される組立場所別出庫数テーブル４２に各々登録される。
【０１２６】
引揚フラグは、当該組立場所で余剰となった部品を倉庫に引き揚げたか否かの２状態を表示可能な符号であり、実施形態では、例えば、当該組立場所で余剰となった部品を倉庫に引き揚げた場合が１で表され、当該組立場所で余剰となった部品を倉庫に引き揚げていない場合が０で表される。部品管理装置１は、引揚フラグによって、組立品の組立後に組立場所に残った部品を倉庫に引き揚げたか否かを管理することができる。
【０１２７】
組立場所別出庫数情報は、組立品別部品情報から単位数で出庫する部品を出庫先別に抽出して生成する。組立品別部品情報は、必要数だけ出庫する部品と単位数で出庫する部品が含まれ、製品別組立品情報の出庫先と関連付ける出庫先別の出庫情報となる。さらに部品情報マスタのリール品識別記号と関連付けて単位数で出庫する部品だけを出庫先別に抽出すれば、リール品だけの出庫先別出庫数情報が得られる。この得られた出庫先別出庫数情報から同一出庫先、同一部品型式について、例えば出庫日は７月のものとか７月１日から７月１５日までの部品所要数を集計すれば、組立場所別出庫数情報が完成する。このように集計するのは個々の組立品の組立に必要な数だけ出庫できないためである。部品管理装置１は、演算処理部１０の組立場所別出庫数処理部１０５により組立場所別出庫数情報の完成までの一連の処理を行う。
【０１２８】
より具体的には、組立品別部品テーブル２２における部品型式フィールド２２５の部品型式を組立場所別出庫数テーブル４２の部品型式フィールド４２１に登録し、テーブル２２の部品所要数フィールド２２７の部品所要数（前述のように出庫日が任意の範囲で部品型式ごとに部品所要数を集計している）をテーブル４２の出庫先所要数フィールド４２３に登録し、リール単位数フィールド４２５に部品情報マスタのリール単位数フィールドか
ら部品型式に対応するリール単位数を登録する。次に、例えばプリントされたテーブル４２を見ながら倉庫の作業者は各部品型式の出庫作業を行いその出庫数を記入する。テーブル４２は最低限のフィールドであるが、実用的には出庫完了日、所要数を集計した出庫日範囲、作業者名等など必要なフィールドが追加される。また組立品の組立後に余剰となった部品を必ずしも倉庫に引き揚げない倉庫管理を行う場合には、前回出庫先在庫数フィールドも追加される。この場合には前回出庫先在庫数と出庫数を加算した部品数が、出庫先所要数を充当できるように出庫数が決められるが、この余剰となっている前回出庫先在庫数（又は引揚数）は、単位数ではなく端数になっている。この端数が単位数に比して極めて少ないと利用できないこともある。この点も実際の出庫作業では考慮して出庫数を決めるのであって、単位数で出庫する部品はいつも必ず単位数で出庫するのではない。
【０１２９】
図１６のシーケンスは、テーブル４２について全ての部品の出庫が完了した後に、端末装置２は出庫数入力要求送信する（Ｓ６１）。これを部品管理装置１が受信（Ｓ６２）すると、出庫数入力画面の準備（Ｓ６３）し、出庫数入力画面を送信する（Ｓ６４）。端末装置は、この画面を受信（Ｓ６５）して、出庫数が入力される（Ｓ６６）と、出庫数入力結果を送信する（Ｓ６７）。部品管理装置１は、この結果を受信する（Ｓ６８）。
【０１３０】
そして、部品管理装置１の組立場所別出庫数処理部１０５によって、組立場所別出庫数テーブル４２の出庫数フィールド４２２の出庫数から出庫先所要数フィールドの出庫先所要数を各行ごとに減算し、その結果を部品型式フィールド４２１の出庫先在庫予定数フィールド４２４に登録する。さらに前記出庫数は前記部品型式に対応して在庫数テーブル４１の出庫数フィールド４１３の出庫数に加算して登録する。加算した結果は、テーブル４１の出庫数フィールド４１３の１行目９００、２行目３０００、４行目８００となる。
【０１３１】
さて、組立場所において組立品の組立が終わった後に残る出庫先在庫予定数フィールド４２４の出庫先在庫予定数を組立場所から倉庫へ引き揚げる（搬出）と、ユーザは、端末側の入力部から引き揚げた部品型式に対応する引揚フィールド４２６の引揚フラグを１に登録する。この場合、組立場所から全ての部品を引き揚げるなら１回の入力で全行の引揚フラグを１に登録できる。又は引き揚げた部品だけに引揚フラグを１に登録できるものとする。引揚フラグが１の部品型式に対応して、在庫数テーブル４１の引揚数フィールド４１６の引揚数にテーブル４２の出庫先在庫予定数フィールド４２５の出庫先在庫予定数を加算し、その結果を引揚数フィールド４１６に登録する。加算した結果は、テーブル４１の引揚数フィールド４１６の１行目４５０、２行目２３００、４行目２８０となる。
【０１３２】
加算した後にテーブル４２の前記出庫先在庫予定数の全行を０にする。あるいは引揚フラグが１の行に限り出庫先在庫予定数を０にする。
【０１３３】
なお、部品受入情報記憶部１１８は納品され受入された部品の個数を記憶すると共に、該部品の部品型式に対応して在庫数テーブル４１の入庫数フィールド４１４の入庫数に、該部品の個数を加算し、その結果を入庫数フィールド４１４に登録する。テーブル４１において入庫数の増加は現在在庫数の増加となり、出庫数の増加は現在在庫数の減少となる如く加減算が行われる。
【０１３４】
以上の説明した動作によって在庫数テーブル４１は、必要数だけ出庫する部品と単位数で出庫する部品と区別することなく、刻々と変化する在庫数情報を管理している。現在在庫数に引揚数を加算する、又はテーブル４１の現在在庫数とテーブル４２の出庫先在庫予定数を加算すると総在庫数が把握できる。部品購買計画支援テーブル２５を生成するためにフリー在庫数を算出する場合は、各部品型式ごとに総在庫数を集計し、総在庫数−組立引当数を用いるが、リール品が単位数に比して出庫先在庫予定数、引揚数が非常に小さい（例えばリール単位数１０００に対して余剰になった部品数１０数個など）場合には、現在在庫数に引揚数や出庫先在庫数を加算して総在庫数を算出しない、また安全在庫を考慮し、組立場所別に単位数での出庫が確保できるよう処理を行うなど、本発明は臨機応変な処理の実施するに充分な部品情報を取り揃えている。このようにテーブル４１とテーブル４２を活用し、目的に応じて各数値を適切に加工すれば、単位数で出庫する部品を組立場所別に管理する必要は全くない。
【０１３５】
なお、実施形態では、部品管理装置１は、ネットワークＮＴを介して通信可能に複数の端末装置２と接続され、部品管理システムＰＭＳの一構成要素として例示されているが、入力部１４、出力部１５及びウェブブラウザを備えることによって単独で、いわゆるスタンド・アローン型で用いられてもよい。特に、事業規模の小さい企業にとっては、コスト的にスタンド・アローン型が好適である。
【０１３６】
また、実施形態では、部品管理装置１は、ウェブサーバの機能とデータベースの機能とを兼ね備えて一体で構成されているが、ウェブサーバの機能を備えるコンピュータとデータベースの機能を備えるコンピュータとで別体で構成されてもよい。部品管理装置と端末装置の通信は、端末装置にブラウザのみを保有するウェブ形式でもよいし、端末装置に専用ソフトを保有する形式でもよい。
【０１３７】
さらに、実施形態では、部品を管理するための部品管理情報は、マスタ情報、製品別組立品情報、組立品別部品情報、部品別所要数情報、部品別所要数集計情報、部品購買計画支援情報、部品注文情報、部品受入情報、時期別部品保管情報、欠品予測状況情報、在庫数情報及び組立場所別出庫数情報等の複数の情報から構成されたが、例えば製品別組立品情報と組立品別部品情報とを組み合わせた情報や、在庫数情報と組立場所別出庫数情報とを組み合わせた情報のように、これらのうちの複数を組み合わせた情報から構成してもよく、また、これら情報をさらに複数に分けた情報から構成してもよいなど、いわゆるデータベースのリレーショナルシップを活用して、これらの情報を構成してもよい。また実施形態での各テーブルは、説明に必要な最小限のフィールドであるが、実用上ではフィールドの追加が生じるのは当然である。
【０１３８】
本発明を表現するために、上述において図面を参照しながら実施形態を通して本発明を適切且つ充分に説明したが、当業者であれば上述の実施形態を変更及び／又は改良することは容易に為し得ることであると認識すべきである。従って、当業者が実施する変更形態又は改良形態が、請求の範囲に記載された請求項の権利範囲を離脱するレベルのものでない限り、当該変更形態又は当該改良形態は、当該請求項の権利範囲に包括されると解釈される。
【図面の簡単な説明】
【０１３９】
【図１】実施形態における部品管理システムの構成を示す図である。
【図２】実施形態における部品管理装置の構成を示すブロック図である。
【図３】グループ、製品、組立品及び部品の相互関係を説明するための図である。
【図４】実施形態における製品別組立品テーブルの構成を示す図である。
【図５】実施形態における製品別組立品構成部品テーブルの構成を示す図である。
【図６】実施形態における部品別所要数を集計する動作を示すシーケンス図である。
【図７】実施形態における部品別所要数テーブルの構成を示す図である。
【図８】実施形態における部品別所要数集計テーブルの構成を示す図である。
【図９】、実施形態における部品購買計画を支援する動作を示すシーケンス図である。
【図１０】実施形態における部品購買計画支援テーブルの構成を示す図である。
【図１１】実施形態における欠品予測の動作を示すシーケンス図である。
【図１２】実施形態における時期別部品保管テーブルの構成を示す図である。
【図１３】実施形態における欠品予測テーブルの構成を示す図である。
【図１４】実施形態における在庫数テーブルの構成を示す図である。
【図１５】実施形態における組立場所別出庫数テーブルの構成を示す図である。
【図１６】実施形態における出庫数入力動作を示すシーケンス図である。
【符号の説明】
【０１４０】
Ｇ１  グループコード                ：Ｅ１〜Ｅ６  製品コード
Ａ１〜Ａ１２  組立品コード          ：Ｐ１〜Ｐ１２  部品コード（部品型式）
ＰＭＳ  部品管理システム            ：１  部品管理装置
２  端末装置                        ：１０  演算処理部
１１  記憶部                        ：１４  入力部
１５  出力部                        ：１６  外部記憶部
２１  製品別組立品テーブル          ：２２  組立品別部品テーブル
２３  部品別所要数テーブル          ：２４  部品別所要数集計テーブル
２５  部品購買計画支援テーブル      ：３１  時期別部品保管テーブル
３２  欠品予測テーブル              ：４１  在庫数テーブル
４２  組立場所別出庫数テーブル      ：４３  在庫状況テーブル
１０１  ウェブサーバ部              ：１０２  部品所要数集計処理部
１０３  部品購買計画支援処理部      ：１０４  欠品予測処理部
１０５  組立場所別出庫数処理部      ：１１１  マスタ情報記憶部
１１２  製品別組立品情報記憶部      ：１１３  組立品別部品情報記憶部
１１４  部品別所要数情報記憶部      ：１１５  部品別所要数集計情報記憶部
１１６  部品購買計画支援情報記憶部  ：１１７  時期別部品保管情報記憶部
１１８  部品注文情報記憶部          ：１１９  部品受入情報記憶部
１２０  欠品予測情報記憶部          ：１２１  在庫数情報記憶部
１２２  組立場所別出庫数情報記憶部
２１１、２１１、２３１、２４１、２５１  グループコードフィールド
２１７、２２８、２３６、３１３、３２４  出庫日フィールド
２２５、２３４、２４２、２５２、３１１、４１１、４２１  部品型式フィールド
２２７、２３５、２４３、２５３、３１２、３２３  部品所要数フィールド
２３７、２４４、２５４、３１４  集計キーフィールド
２５５  フリー在庫数フィールド      ：２５６  フリー注文残数フィールド
２５８  計画購入数フィールド        ：３１５  在庫数フィールド
３１６  現在残数フィールド          ：３１７  将来残数フィールド
３１８、３２８  納期フィールド      ：３２５  第１充当残フィールド
３２６  第２充当残フィールド        ：３２７  注文残フィールド
４１５  現在在庫数フィールド        ：４２４  出庫先在庫予定数フィールド
４２６  引揚フラグフィールド
【図１】
2008071091.tif 000003
【図２】
2008071091.tif 000004
【図３】
2008071091.tif 000005
【図４】
2008071091.tif 000006
【図５】
2008071091.tif 000007
【図６】
2008071091.tif 000008
【図７】
2008071091.tif 000009
【図８】
2008071091.tif 000010
【図９】
2008071091.tif 000011
【図１０】
2008071091.tif 000012
【図１１】
2008071091.tif 000013
【図１２】
2008071091.tif 000014
【図１３】
2008071091.tif 000015
【図１４】
2008071091.tif 000016
【図１５】
2008071091.tif 000017
【図１６】
2008071091.tif 000018