(57)【要約】【課題】  マスタ登録が完了しないと、ソフトウエア製品の生産は開始することはできない。このため、納期と生産リードタイムを意識してマスタ登録をスケジューリングしないと、納期遅延を起こしてしまう。【解決手段】  受注手配データの納期と、生産現場の生産リードタイムから、マスタ登録や入庫登録の最遅日程を逆算する。この結果、生産の基点になるマスタ登録日がスケジューリングできる。このとき、受注手配を単位として、生産現場の生産管理データ、ソフトウエア製品の部品構成データ、ソフトウエア製品の開発日程データを参照し、工場出荷日には受注手配を受けた製品すべての生産が終わるようにマスタ登録日をスケジューリングする。【選択図】  図１
2006343897.tif 000002
【特許請求の範囲】
【請求項１】
ソフトウエアの出荷において、マスタ登録状況より、出荷マスタがデータベースに登録されているかどうかを判断し、出荷マスタがデータベースに登録されていない場合に、部品構成データをもとに、生産管理データでリードタイムを算出し、優先的にマスタ登録を行うべき対象製品を選択し、マスタ登録を促すデータを作成することを特徴とする出荷マスタ登録スケジューリングシステム。
【請求項２】
請求項１に示す出荷マスタ登録スケジューリングシステムにおいて、優先的にマスタ登録を行うべき対象製品のマスタ登録の準備作業が完了しているかどうかを工程状況データで判断し、マスタ登録の準備作業が未完の場合に、優先的にマスタ登録の準備作業を行うべき対象製品を選択し、準備作業を促すデータを作成することを特徴とする出荷マスタ登録スケジューリングシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ソフトウエア製品のマスタ登録に関するものである。
【背景技術】
【０００２】
従来のコンピュータによる生産管理システムでは、完成品を構成する部品を、生産上の適切な時期に適切な物量を出庫し、生産現場にすみやかに配置することが目的であった。すなわち、必要な時期に、必要な部品を、必要なだけ出庫できるようにすることである。過剰な在庫は、欠品はおこさないが、在庫の回転率が悪くなり、収益を圧迫する。過小な在庫は、在庫の回転率はいいが、欠品をおこし、完成品の生産を遅らせ、納期遅延を起こす。これらを防ぐため、完成品の生産スケジュールをもとに、生産リードタイムから逆算して部品が必要となる時期や数量を適切になるよう計算し、かつ適正な在庫量を計算する。適正な在庫を常に保持することで、円滑な生産を保証できる。結果として、欠品を起こすこともなく在庫量は適正な水準に保たれ、過剰在庫を防ぐ効果もある。例えば、特許文献１を参照。
【０００３】
一方、ソウトウエアの生産の場合は、ソフトウエアをＣＤ−Ｒなどの適切な媒体に複写することにより完成品がいくらでも生産できることが特徴である。ソフトウエアとハードウエアの生産を比較した場合、ソフトウエアの場合は在庫管理という概念はない。当然、ＣＤ−Ｒ等の媒体はハードウエアであり、顧客への受け渡し手段としては必要であるから、媒体の在庫管理は必要である。しかし、純粋にソフトウエアを考えた場合、生産管理として、在庫管理を主眼としたスケジュール管理は必要ない。
【０００４】
ソフトウエアで必要なスケジュール管理は、ソフトウエアの生産に着手する時点で、ソフトウエアそのものがデータベースに登録されていることを保証することである。ソフトウエアの場合、ソフトウエアの出荷用のマスタを適切な時期にデータベースに登録することが、生産管理の目的になる。このように、出荷用のマスタとなるソフトウエアをデータベースに登録することをマスタ登録という。
【０００５】
開発完了したソフトウエアは、物理的な媒体に格納して保管するか、電子データとしてデータベースに保管する。通常は、開発完了したソフトウエアを原本、すなわち製品マスタとする。この製品マスタから、バックアップマスタ、出荷マスタの２セットを複写し、バックアップマスタは生産拠点と離れた遠隔地に送付し、出荷マスタは生産現場に送付する。生産現場が出荷マスタを受領し、マスタ登録して出荷準備が完了する。
【０００６】
【特許文献１】特開平８−３１５０１８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
特許文献１に示す方法は、ハードウエアの場合であり、マスタ登録の考え方がないため、適用できない。
【０００８】
ソフトウエアの場合、出荷マスタがマスタ登録されていないと、複写が行えず、工程が停止してしまう。通常、ソフトウエア製品の受注手配は複数ソフトウエア製品を同時に手配する。システムの構築のためにいくつかのソフトウエア製品を組み合わせることが必要だからであるが、ひとつでも、こうしたデータベース未登録の製品があると、生産が止まり、欠品や納期遅延を起こしてしまう。欠品や納期遅延を起こすと、顧客の信用を失い、事業の発展を妨げ、業績の悪化にもつながるため、全力をあげて防止しなければならない。
【０００９】
通常は、出荷マスタの登録の順位付けは特に行わず、生産現場への到着順に、先入れ先出し方式で順にマスタ登録する。このため、何も手を打たないと、生産着手日までにマスタ登録ができず、生産が停止してしまうことがある。従って、生産着手日までには、生産対象のソフトウエア製品が確実にマスタ登録完了していることを保証する必要がある。
【００１０】
本発明の目的は、ソフトウエア製品のマスタ登録において、日々の受注手配、開発工程、生産現場の状況、製品構成等を参照し、ソフトウエア製品のマスタ登録順を調整することにより、欠品や納期遅延を回避することである。
【課題を解決するための手段】
【００１１】
受注手配データから納期を読み取り、この納期から製品運搬に必要な輸送所要日数を引くことで、工場出荷日をまず決める。この工場出荷日から、ソフトウエア製品別の生産リードタイムを引くことで、生産開始日を決める。この生産開始日にマスタ登録が完了しているように、スケジューリングする。
【００１２】
このとき、納期遅延を起こさないことが主眼であるから、あくまで受注手配単位に最適なスケジューリングでマスタ登録日を決めるようにする。このために、生産現場の生産管理データ、ソフトウエア製品の部品構成データ、ソフトウエア製品の開発日程データも参照し、工場出荷日には受注手配されたソフトウエア製品すべてが出荷できるように、生産管理を行う。
【発明の効果】
【００１３】
本発明によれば、受注手配単位にマスタ登録のスケジューリングが可能であり、欠品や納期遅延を未然に防ぐことができる。
【発明を実施するための最良の形態】
【００１４】
以下、本発明の実施例を図面に基いて詳細に説明する。
【００１５】
図１は、本発明の一実施例の全体構成を示したシステム構成図である。
【００１６】
営業手配端末１０１は、営業担当者の受注手配入力を受け取るコンピュータであり、ネットワーク１０２を介して日程管理部１０３に接続されている。
【００１７】
日程管理部１０３は、全体制御部１０４と、受注手配ごとのマスタ登録状況を検索する手配検証部１０５と、生産リードタイムを計算するリードタイム計算部１０６と、マスタ登録のスケジュールを計算するスケジュール計算部１０７から構成されている。日程管理部１０３はコンピュータシステムであり、各処理部は同じコンピュータの中にあっても良いし、分散されていても良い。
【００１８】
手配情報データベース１０８は、営業担当者が入力した受注手配データを保管するデータベースである。マスタ登録状況データベース１０９は、ソフトウエア製品の出荷マスタ登録状況を格納するデータベースである。生産管理データベース１１０は、ソフトウエア製品の生産に使用する機械ごとの生産管理情報を格納するデータベースである。部品構成データベース１１１は、ソフトウエア製品を構成する部品情報を格納するデータベースである。工程状況データベース１１２は、開発状況を格納するデータベースである。輸送所要日数データベース１１３は、生産場所から顧客へのソフトウエア製品の輸送に必要な日数を格納するデータベースである。督促データ１１４は、製品マスタ登録や入庫処理を早めるよう促すデータファイルである。
【００１９】
営業手配端末１０１より入力された受注手配データは、ネットワーク１０２を介して日程管理部１０３に送付される。日程管理部１０３の全体制御部１０４は、受注手配データをいったん手配情報データベース１０８に保管する。
【００２０】
全体制御部１０４は、手配情報データベース１０８から受注手配データを読み込み、読み込んだ受注手配データを手配検証部１０５に送り、制御を渡す。
【００２１】
手配検証部１０５は、マスタ登録状況データベース１０９からマスタ登録状況読み込み、受注手配データを参照して、手配されたソフトウエア製品それぞれのマスタ登録状況を検証し、結果を全体制御部１０４に返す。
【００２２】
全体制御部１０４は、未登録のマスタの有無を検証し、未登録のマスタがある場合は、スケジュール計算部１０７に制御を渡す。
【００２３】
スケジュール管理部１０７は、ソフトウエア製品ごとのリードタイムを計算するため、リードタイム計算部１０６に制御を渡す。
【００２４】
リードタイム計算部１０６は、生産機器の稼動状況や処理能力を生産管理データベース１１０から読み込み、ソフトウエア製品を構成する部品情報を部品構成データベース１１１から読み込み、各部品ごとの生産リードタイムを計算する。各部品の生産リードタイムの最遅日を当該ソフトウエア製品の生産リードタイムとして、スケジュール管理部１０７に返す。
【００２５】
スケジュール管理部１０７は、工程状況データベース１１２からソフトウエア製品の工程状況を読み込み、輸送所要日数データベース１１３から輸送に必要な日数を読み込み、納期から逆算してマスタ登録日を計算する。
【００２６】
計算した結果、ソフトウエア製品のマスタ登録や入庫処理を急ぐ必要があることが判明した場合は、督促データ１１４を作成する。
【００２７】
図２、図３、図４を使用して、ソフトウエア製品のマスタ登録の考え方を説明する。
【００２８】
図２は、ソフトウエア製品の生産の流れを示した図である。
【００２９】
ソフトウエア製品の生産の流れは、大きく出荷準備と出荷に分けられる。
【００３０】
まず、出荷準備について説明する。
【００３１】
ソフトウエア製品は、開発が完了すると（２０１）、入庫処理を行う（２０２）。入庫処理では、開発完了したソフトウエア製品の製品マスタから２セット複写する。複写した２セットのうち、１セットは災害対策として生産拠点から離れた場所に別地保管する（２０３）。残り１セットは、出荷マスタとして出荷マスタデータベース（２０６）に登録する（２０５）。製品マスタは原本としてそのまま保管庫に保管する（２０４）。
【００３２】
次に、出荷について説明する。
【００３３】
営業の受注手配を受け（２０７）、生産指示を発行する（２０８）。生産指示に基き、必要なソフトウエア製品を出荷マスタデータベース（２０６）から読み出し、生産し（２０９）、顧客へ出荷する（２１０）。
【００３４】
図３は、ソフトウエア製品のマスタ登録を示す図である。
【００３５】
ソフトウエア製品の開発が完了すると（３０１）、入庫処理（３０２）、出荷マスタ登録（３０３）をへて、マスタ登録される（３０４）。通常は、ソフトウエア製品の開発が完了した順番に先入れ先出し方式で入庫処理およびマスタ登録が行われる。
【００３６】
図４は、ソフトウエア製品のマスタ登録順を変更することを示す図である。
【００３７】
出荷マスタが出荷マスタデータベースに未登録であれば、生産に着手することができない。このため、全体の工程を見直し、未登録の出荷マスタを優先的に登録させ、すこしでも生産リードタイムを確保する必要がある。
【００３８】
例えば、標準の出荷日程に比べて短い日程での受注手配がはいった場合（４０５）、生産指示を行うとともに（４０６）、マスタ登録状況を検証する（４０７）。未登録のマスタがあれば優先的に登録を行わせるため、マスタ登録の順序を変更させる（４０８、４０９、４１０）。
【００３９】
図５は、手配情報データベース１０８に格納されている手配情報テーブルの例である。
【００４０】
手配情報テーブルは、ソフトウエア製品の受注手配を受けた顧客への納期、納入場所、手配製品の構成等の情報を格納する（５０１）。
【００４１】
図６は、マスタ登録状況データベース１０９に格納されているマスタ登録状況テーブルの例である。図５の受注手配がはいった時点である２００５年３月２９日のマスタ登録状況テーブルのデータ格納状況を示している（６０１）。
【００４２】
マスタ登録状況テーブルは、ソフトウエア製品ごとの登録完了日と、ソフトウエア製品を構成する部品ごとの登録完了日を格納する。部品登録が完了しないと、ソフトウエア製品が構成できないため、部品登録完了の最も遅い日付が（６０４、６０５）、ソフトウエア製品の登録完了日になる（６０６）。
【００４３】
図６のマスタ登録状況テーブル（６０１）には２製品が登録されている。図５の手配情報テーブル（５０１）と比較すると、２００５年３月２９日現在のマスタ登録状況は（６０１）、製品Ｐ−Ｃ（５０６）、製品Ｐ−Ｄ（５０７）の２製品のデータが未登録である。これは、この２製品のマスタが未登録であることを示す。
【００４４】
図７は、生産管理データベース１１０に格納されている生産管理テーブルの例である。
【００４５】
生産管理テーブル７０１は、ソフトウエア製品の生産に使用する生産機の号機ごとに、稼動状況や処理能力を管理する。図７の例では、１号機（７０２）はＣＤ−Ｒのダビング装置であり、稼動率は５０％、１分あたり１０ＭＢの処理能力がある。３号機（７０５）は印刷機であり、稼働率は５０％、１分あたり１００枚の紙を印刷できる。稼働率７０３は、機械本来の処理能力に比べて現在の稼動状況がどのくらいかを示すものである。なお、２号機（７０４）は修理中であり、２００５年４月１日にならないと生産ができないことを示している。
【００４６】
図８は部品構成データベース１１１に格納されている部品構成テーブルの例である。
【００４７】
部品構成テーブル８０１は、ソフトウエア製品を構成する部品に関する情報を格納するテーブルである。
【００４８】
図８の例では、例えばソフトウエア製品Ｐ−Ａは、ソフトウエア本体、リリースノート、マニュアルの３部品から構成されている。ソフトウエア本体は、ＣＤ−Ｒ１枚に格納されその容量は２００ＭＢである。同様に、リリースノートは紙１枚、マニュアルは紙１０枚から構成されていることを示す（８０２）。
【００４９】
図９は、輸送所要日数データベース１１３に格納されている輸送所要日数テーブルである。輸送所要日数テーブル９０１は、生産拠点からみて、各納入先への輸送の所要日数を示す。
【００５０】
図９の例では、例えば、本州各地域は生産拠点から１日で輸送できることを示す（９０３）。逆に、工場出荷日から顧客に届けるのに１日かかるということであるから、ソフトウエア製品の工場出荷日は、顧客納期からこの輸送所要日数を差し引いた日数でなければならない。
【００５１】
図１０は工程状況データベース１１２に格納された工程状況テーブルの例である。
【００５２】
工程状況テーブル１００１は、ソフトウエア製品ごとの開発完了からマスタ登録完了までの工程を管理する。図１０の例では、製品Ｐ−Ａ、製品Ｐ−Ｂはマスタ登録まで完了しており、出荷準備は完了している。製品Ｐ−Ｃ（１００３）は、２００５年３月２５日に入庫処理は完了しているが（１００５）、マスタ登録は完了していない（１００６）。また、製品Ｐ−Ｄ（１００４）は、２００５年３月２９日に開発は完了しているが（１００７）、入庫処理が完了していない（１００８）。
【００５３】
図１１は、生産リードタイムテーブルの例である。
【００５４】
手配情報テーブル（５０１）から、手配ＩＤ「ＴＥＨＡＩ１」の手配情報を読み込み、納期、納入場所、手配構成を取得する。この手配構成から、形名、バージョンごとの部品構成の情報を、部品構成テーブル（８０１）から読み込む。この部品構成テーブルから部品ごとの容量を取得し（１１０３）、生産管理テーブル（７０１）の号機ごとの処理能力から、構成部品の生産に必要な時間を計算し、生産時間を格納する（１１０４、１１０５）。
【００５５】
一方、手配ＩＤ「ＴＥＨＡＩ１」の納期（５０４）、納入場所（５０５）から、輸送所要日数テーブル（９０１）を参照して、工場出荷日を決定する。納入場所は神奈川県なので、納期（５０４）から輸送日数１日（９０３）を引いて、工場出荷日を計算する。これが最遅完成日になる（１１０６）。
【００５６】
生産管理テーブル（７０１）の各号機ごとの処理能力と稼働率から、１日で完成できると計算できるため、最遅２００５年３月３０日に着手すればよい（１１０７）。しかし、工程状況テーブル（１００１）では、製品Ｐ−Ｃはマスタ未登録（１００６）、製品Ｐ−Ｄは未入庫である（１００８）。従って、製品Ｐ−Ｃ、製品Ｐ−Ｄに関しては着手可能日が決まらない（１１１１、１１１２）。逆に、この２製品を出荷準備完了にしなければ、ＴＥＨＡＩ１（１１０２）を構成する製品のうち２製品の生産ができないため、ＴＥＨＡＩ１（１１０２）は出荷ができないことになる。
【００５７】
図１２は、督促データ１１４に出力されたマスタ登録督促データの例である。
【００５８】
マスタ登録督促データ１２０１は、ソフトウエア製品ごとのマスタ登録日を強制的に指定するためのデータである。２００５年３月２９日発行（１２０２）の場合、製品Ｐ−Ｃは、３月２９日中に登録完了の指示がでている（１２０３）。一方、製品Ｐ−Ｄの場合は、工程状況テーブル１００１の開発完了日が２００５年３月２９日であり（１００７）、マスタ到着日は２００５年３月３０日である。生産着手日（１２０５）の関係から、到着日には登録完了するように指示されている（１２０６）。ただし、発行日２００５年３月２９日（１２０２）からみて翌日作業になるため、登録作業の優先順位では製品Ｐ−Ｃが優先順位１位になっている（１２０７）。
【００５９】
図１３は、入庫リードタイムテーブルの例である。
【００６０】
生産リードタイムテーブル１１０１から製品Ｐ−Ｄは未入庫であることがわかる（１１１２）。また、この製品Ｐ−Ｄは、マスタ登録督促データ１２０１から、マスタ登録を２００５年３月３０日に完了するように指示されている（１２０６）。
【００６１】
まず部品構成テーブル８０１から、製品Ｐ−Ｄを構成する部品情報を取得する。この部品情報から部品ごとの容量を取得する。入庫の場合、製品マスタを複写して出荷マスタとバックアップマスタの２セットを作成する（１３０３）。生産リードタイムテーブルの計算と同様に、生産機の号機ごとの処理能力から、構成部品の生産に必要な時間を計算し、生産時間を格納する（１３０４）。
【００６２】
一方、マスタ督促データ１２０１から、マスタ登録完了指定日は２００５年３月３０日と指定されている（１２０６、１３０５）。マスタ登録の前日まで入庫処理を終える必要があれば、最遅入庫日は２００５年３月２９日と計算される（１３０６）。ただし、工程状況テーブル１００１の開発完了日が２００５年３月２９日（１００７）であることから、開発完了した製品を入手次第、即入庫処理にはいるように指示されることになる（１３０７）。
【００６３】
図１４は督促データ１１４に出力された入庫督促データの例である。
【００６４】
入庫督促データ１４０１は、ソフトウエア製品ごとの製品マスタ入庫日を強制的に指定するためのデータである。２００５年３月２９日発行（１４０２）の場合、製品Ｐ−Ｄは２００５年３月２９日中に入庫完了の指示がでている（１４０３）。
【００６５】
次に、図１５、図１６、図１７で、登録の優先順位について説明する。
【００６６】
図１５は、手配情報データベース１０８に格納された手配情報テーブルの例である。
【００６７】
ＴＥＨＡＩ２として（１５０２）、製品Ｐ−Ｘの手配を受けたが、手配日が２００５年３月２９日（１５０３）、納期が２００５年３月３１日と短納期である（１５０４）。例えば、この製品Ｐ−Ｘが、製品Ｐ−Ｄの例（１００４）と同様に、製品未入庫、マスタ未登録だった場合を考える。
【００６８】
図１６は、督促データ１１４に出力されたマスタ登録督促データの例である。
【００６９】
ＴＥＨＡＩ２の場合（１５０２）、納入先が北海道であることから（１５０５）、輸送所要日数は２日（９０２）であり、納期（１５０４）から輸送所要日数２日を引いて、工場出荷日は２００５年３月２９日でなければならない。従って、２００５年３月２９日中に、入庫処理、マスタ登録処理、生産、発送までを完了させなければならない。当然作業優先度は高くなる。
【００７０】
マスタ督促データ１６０１の例では、登録完了指定日１６０３では、製品Ｐ−Ｃも製品Ｐ−Ｘも２００５年３月２９日である。生産着手日をみると、製品Ｐ−Ｘの生産着手日１６０２は、２００５年３月２９日である。一方、製品Ｐ−Ｃの生産着手日１６０２は、２００５年３月３０日であり、製品Ｐ−Ｘより１日の余裕がある。このため、出荷マスタ登録の優先順位は、製品Ｐ−Ｘが高く、製品Ｐ−Ｃは低くなる（１６０４）。
【００７１】
図１７は、督促データ１１４に出力された入庫督促データの例である。
【００７２】
入庫督促データ１７０１の例では、製品Ｐ−Ｄと製品Ｐ−Ｘは、同じ２００５年３月２９日に入庫完了指定日を指定されているが（１７０３）、マスタ登録日が、製品Ｐ−Ｘは２００５年３月２９日に対して製品Ｐ−Ｃが２００５年３月３０日であり（１７０２）、１日だけ製品Ｐ−Ｄに余裕がある。このため、入庫処理の優先順位は、製品Ｐ−Ｘが高く、製品Ｐ−Ｄは低くなる（１７０４）。
【００７３】
次に、図１８、図１９で日程管理部のフローを説明する。
【００７４】
図１８はマスタ登録日計算のフローである。
【００７５】
全体制御部１０４は、手配情報データベース１０８から手配情報テーブル５０１を読み込み、次にマスタ登録状況データベース１０９から、マスタ登録状況テーブル６０１を読み込み、手配検証部１０５に制御を渡す（１８０２）。
【００７６】
手配検証部１０５は、手配情報テーブル５０１からソフトウエア製品の形名、バージョンを取り出し、一覧にする。この一覧と、マスタ登録状況テーブル６０１を形名、バージョンをキーにつき合わせ、ソフトウエア製品のマスタ登録状況を検証し、全体制御部１０４に結果を返す。（１８０３）。
【００７７】
全体制御部１０４は、マスタ未登録のソフトウエア製品があった場合、スケジュール管理部１０７に制御を渡す。スケジュール管理部１０７は、生産管理データベース１１０から生産管理テーブル７０１を、部品構成データベース１１１から部品構成テーブル８０１を、工程状況データベース１１２から工程状況テーブル１００１を、輸送所要日数データベース１１３から輸送所要日数テーブル９０１を、それぞれ読み込む（１８０５）。
【００７８】
スケジュール管理部１０７は、リードタイム計算部１０６に制御を渡す。
【００７９】
リードタイム計算部１０６は、生産管理テーブル７０１の号機別の処理能力と、部品構成テーブル８０１のソフトウエア製品を構成する構成部品ごとの容量から生産時間を計算し、これを生産リードタイムとして、生産リードタイムテーブル１１０１に書き込み、スケジュール計算部１０７に制御を返す。
【００８０】
スケジュール計算部１０７は、まず、手配情報テーブル５０１の納入場所５０５と、輸送所要日数テーブル９０１から輸送所要日数を決める。次に、手配情報テーブル５０１の納期５０４から輸送所要日数を引いて工場出荷日を決め、これを最遅完成日として生産リードタイムテーブル１１０１に書き込む。次に、最遅完成日から生産リードタイムを引いて、最遅生産着手日を決め、これを生産リードタイムテーブル１１０１に書き込む。次に、当日のマスタの到着状況をみて、マスタが到着していれば当日をマスタ登録指定日とする。未着であれば、例えば入庫完了指定日の翌日を登録完了指定日とする（１８０６）。
【００８１】
次に、スケジュール管理部１０７は、マスタが未入庫であれば、入庫日計算を行う（１８０８）。入庫日計算は図１５で説明する。
【００８２】
入庫済みだがマスタ未登録の製品があれば、マスタ登録督促データ１２０１を督促データ１１４に出力する（１８０９）。
【００８３】
これを手配情報テーブルの全ソフトウエア製品について繰り返す（１８１０）。
【００８４】
図１９は、入庫日計算のフローである。
【００８５】
スケジュール管理部１０７は、リードタイム計算部１０６に制御を渡す。
【００８６】
リードタイム計算部１０６は、まず、未入庫の製品について、読み込み済みの生産管理テーブル７０１から号機別の処理能力と、部品構成テーブル８０１から当該製品の構成部品の容量から、生産時間を計算し、これを入庫リードタイムとして入庫リードタイムテーブル１３０１に書き込み、スケジュール管理部に制御を返す（１９０２）。
【００８７】
スケジュール管理部１０７は、マスタ登録督促データ１２０１のマスタ登録完了指定日を最遅登録日として入庫リードタイムテーブル１３０１に書き込み。次に、最遅登録日から入庫リードタイムを引いて最遅入庫日を決め、入庫リードタイムテーブル１３０１に書き込む（１９０３）。
【００８８】
次に、スケジュール管理部１０７は、工程状況テーブル１００１を参照して入庫待ち製品が開発完了しているかどうかを検証する（１９０４）。
【００８９】
開発が完了していなければ、営業に納期調整をお願いするための依頼表を発行する（１９０６）。
【００９０】
開発が完了し、入庫待ちであれば、入庫督促データ１４０１を督促データ１１４に出力する（１９０５）。
【図面の簡単な説明】
【００９１】
【図１】本発明の一実施例の全体構成を示したシステム構成図である。
【図２】ソフトウエア製品の出荷までの流れを示した図である。
【図３】ソフトウエア製品のマスタ登録の流れを示した図である。
【図４】ソフトウエア製品のマスタ登録順の入れ替えを示した図である。
【図５】手配情報テーブルである。
【図６】マスタ登録状況テーブルである。
【図７】生産管理テーブルである。
【図８】部品構成テーブルである。
【図９】輸送所要日数テーブルである。
【図１０】工程状況テーブルである。
【図１１】生産リードタイムテーブルである。
【図１２】マスタ登録督促データである。
【図１３】入庫リードタイムテーブルである。
【図１４】入庫督促データである。
【図１５】手配情報テーブルである。
【図１６】マスタ登録督促データである。
【図１７】入庫督促データである。
【図１８】マスタ登録日計算を示すフローチャートである。
【図１９】入庫日計算を示すフローチャートである。
【符号の説明】
【００９２】
１０１…営業手配端末、１０２…ネットワーク、１０３…日程管理部、１０４…全体制御部、１０５…手配検証部、１０６…リードタイム計算部、１０７…スケジュール計算部、１０８…手配情報データベース、１０９…マスタ登録状況データベース、１１０…生産管理データベース、１１１…部品構成データベース、１１２…工程状況データベース、１１３…輸送所要日数データベース、１１４…督促データ。
【図１】
2006343897.tif 000003
【図２】
2006343897.tif 000004
【図３】
2006343897.tif 000005
【図４】
2006343897.tif 000006
【図５】
2006343897.tif 000007
【図６】
2006343897.tif 000008
【図７】
2006343897.tif 000009
【図８】
2006343897.tif 000010
【図９】
2006343897.tif 000011
【図１０】
2006343897.tif 000012
【図１１】
2006343897.tif 000013
【図１２】
2006343897.tif 000014
【図１３】
2006343897.tif 000015
【図１４】
2006343897.tif 000016
【図１５】
2006343897.tif 000017
【図１６】
2006343897.tif 000018
【図１７】
2006343897.tif 000019
【図１８】
2006343897.tif 000020
【図１９】
2006343897.tif 000021