(57)【要約】【課題】製品ごとに自社生産品か購入品かといった属性を意識しながら発注を作成する必要がある。【解決手段】一括して受け付けた依頼に対して、各製品形名ごとに自社生産品か購入品かを切り分け、それぞれ自社生産品であれば生産計画部署、自社以外の購入品であれば購買部署に受諾の可否回答を展開し、一括した回答としてまとめ、顧客に電子メール等の手段で回答を返す。発注に問題がなく受諾できる場合は、そのまま出荷指示に展開する。【選択図】　図１
2004046660.tif 000002
【特許請求の範囲】
【請求項１】
送られてきた発注依頼に含まれる自社生産品と購入品とを分割し、それぞれの納期を計算し、それぞれ計算された納期を一括して依頼元へ送る製品の納期回答方法。
【請求項２】
送られてきた発注依頼に含まれる自社生産品と購入品とを分割し、自社生産品については生産機ごとの生産計画から納期を求め、購入品については納入が予定されている納期を求め、それぞれ求めた納期から依頼元への回答を生成する製品の納期回答方法。
【請求項３】
送られてきた発注依頼に含まれる製品の納期を求めて依頼元へ納期の情報を送るコンピュータにより実行されるプログラムであって、
送られてきた発注依頼に含まれる自社生産品と購入品とを分割し、自社生産品については生産機ごとの生産計画から納期を求め、購入品については納入が予定されている納期を求め、それぞれ求めた納期から依頼元への回答を生成することを特徴とするコンピュータにより実行されるプログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、自社生産品と購入品に関する発注を一括して受け、納期計算を行ない、納期回答及び受諾の可否回答を行ない、出荷を行なう方法に関する。
【０００２】
【従来の技術】
従来の生産と購買を融合させた技術としては、特開２００２−６９３３号公報記載のように、自社生産品工程と自社生産品を構成する部品調達工程の融合までであり、自社以外の製品を購入して何の加工も加えずに購入したままの形態で出荷する方法と、自社生産品を出荷する方法とをあわせ持ち、一回の発注で購入品と自社生産品の両方を同時に発注できるシステムへの配慮がなされていない。このため、例えば、発注を自社生産品と購入品に分割し、自社生産品は生産工場へ、購入品は購買管理や在庫管理している購買部門へと問合わせが分割され、迅速かつ一括した納期回答や受諾の可否が回答できなかった。
【０００３】
【発明が解決しようとする課題】
上記技術では、顧客は、発注時に製品個別に自社生産品か購入品かを区別して発注の依頼を行なう必要があるが、顧客は発注先会社の事情を考慮しながら発注することはなく、実際は営業部門が、製品個別に自社生産品か購入品かを切り分け、それぞれの回答可能な部署へ依頼を展開するしかなかった。
【０００４】
本発明の目的は、顧客は、自社生産品か購入品かといった製品個別の属性を意識することなく、セットとして一括して発注すれば、自動的にシステム側で自社生産品か購入品かを切り分け、納期回答あるいは受託の可否回答を返すことにある。
【０００５】
【課題を解決するための手段】
上記目的を達成するために、本発明は、一括して受け付けた発注に対して、各製品ごとに自社生産品か購入品かを自動的に切り分け、自社生産品であれば生産計画部署、購入品であれば購買部署に納期回答依頼を展開し、それぞれの納期回答や受諾の可否をまとめ、一括した回答として顧客に電子メール等の手段で回答を返す。また、発注を受諾できる場合は、そのまま出荷指示として生産システムに展開する。
【０００６】
【発明の実施の形態】
以下、本発明の実施の形態を図面によって説明する。
【０００７】
図１は、発注依頼処理システムの構成を示した図である。本システムは、発注を依頼する複数のユーザコンピュータ１１９、からの発注依頼に応じる受注支援装置１０１、発注依頼に基づいて納期を求める製造出荷装置とを有している。
【０００８】
ユーザコンピュータ１１９は、ユーザによって利用され、ユーザが利用して発注依頼を行い、発注依頼に対する回答をユーザコンピュータ１１９の画面に表示して確認を行う。
【０００９】
受注支援装置１０１は、ユーザコンピュータ１１９からの発注依頼を受け取り、発注依頼の構成を確認して製造出荷装置１０４に回答依頼を送信する。受注支援装置１０１は、製造出荷装置１０４から回答を受け取るとユーザコンピュータ１１９にその回答を送る。受注支援装置１０１は、情報受発信部１０２と発注構成確認部１０３とを有している。情報受発信部１０２は、ユーザコンピュータ１１９からの発注依頼を受信する機能と、発注依頼に対する回答をユーザコンピュータ１１９に送る機能とを有する。発注構成確認部１０３は、情報受発信部１０２が受けた発注依頼における製品の構成の前提条件を確認し、構成に不足がないか検証する。
【００１０】
製造出荷装置１０４は、受注支援装置１０１から送られてきた回答依頼を受け、受注支援装置１０１に回答を送るものであり、受注解析部１０６、製造工程管理部１０７、購入品管理部１１２、出荷管理部１１７とを有している。また製造出荷装置１０４は、受注支援データベース１０５、原本監視データベース１１０、工程監視データベース１１１、在庫監視データベース１１５、購買監視データベース１１６とを有している。
【００１１】
受注解析部１０６は、受注支援装置１０１から送られてきた発注依頼を解析して自社生産品と購入品に切り分け、それぞれ製造工程管理部１０７、購入品管理部１１２に回答を依頼する機能と、それぞれの回答を受け、依頼のあった製品構成全体としての納期回答を作成し、受注支援装置１０１に送る機能と、発注依頼に基づく出荷を出荷管理部１１７に指示する機能とを有する。製造工程管理部１０７は、自社生産品に関する工程管理、原本管理を行なうものであり、工程管理部１０８、原本管理部１０９とを有している。工程管理部１０８は、製造工程全般の生産計画を管理する。原本管理部１０９は、自社生産品製造のための生産マスタとなる原本を管理する。購入品管理部１１２は、自社生産品以外の購入品について、在庫引き当て状況と、在庫がない場合の発注状況とを監視するものであり、在庫引き当て管理部１１３、購買管理部１１４とを有している。在庫引き当て管理部１１３は、購入品の在庫状況を監視するものである。購買管理部１１４は、購入品の発注状況を監視するものである。出荷管理部１１７は、受注解析部１０６からの出荷指示を受け、生産及び取り揃えを行なうものである。
【００１２】
受注支援データベース１０５は、製品の前提条件、自社生産品か購入品かの区別、といった発注依頼の妥当性を検証するためのデータを蓄積したデータベースである。原本監視データベース１１０は、原本の入庫状況、開発状況を蓄積するデータベースである。工程監視データベース１１１は、製造工程の生産計画に関する情報を蓄積するデータベースである。購買監視データベース１１５は、購買状況の情報を蓄積するデータベースである。在庫監視データベース１１６は、在庫状況の情報を蓄積するデータベースである。以下、各データベースに登録されているデータについて説明する。
【００１３】
まず、受注支援データベース１０５に登録されている受注支援データと、納入実績データについて説明する。
【００１４】
図２は、受注支援データの一例を示したものである。受注支援データ２０１は、製品形名２０２、バージョン２０３、自社品区分２０４、稼動前提２０５、稼動前提のバージョン２０６とを有し、製品形名ごとに自社生産品か購入品か、稼動の前提プログラムは何か、といった属性が登録されたものである。図２の例では、製品形名「Ｐ−Ｂ」は「自社生産品」であり、「０１―００以上のバージョン」の製品形名「Ｐ−Ａ」が稼動前提となっている。このため、顧客が製品形名「Ｐ−Ｂ」を依頼するときは、製品形名「Ｐ−Ａ」も同時に依頼する必要があることが分かる。ただし、製品形名「Ｐ−Ａ」がすでに納入済であれば問題はない。
【００１５】
図３は、納入実績データの一例を示したものである。納入実績データ３０１は、顧客名３０２、納入製品形名３０３、バージョン３０４、数量３０５とが登録されており、顧客への製品の納入実績を管理する表である。図３の例では、顧客「Ｘ社」には、製品形名「Ｐ−Ａ」のバージョン「０１−００」を、２００１年１月１日に１本納入したことがわかる。
【００１６】
次に原本監視データベース１１０に登録されている開発工程テーブル、型名別部品展開テーブル、媒体別展開テーブルについて説明する。
【００１７】
図４は開発工程状況テーブルの一例を示したものである。これは製品型名「Ｐ−Ｂ」の開発工程状況テーブルである。開発工程状況テーブル４０１は、製品の元（原本）となる製品の工程を管理するものであり、区分４０２、基本設計４０３、構造設計４０４などの工程、完成日４０５、入庫日４０６から構成されており、各製品形名ごとに開発工程の進捗状況を示している。それぞれの日付データは開発者により入力されたり、工程を管理するコンピュータにより入力されたりする。区分は、予定、実績、遅れ、見込みに分かれている。図４の例では、製品形名Ｐ−Ｂの開発工程は、基本設計の工程では予定２００１年１０月３１日に対して実績が２００１年１０月３１日で予定通りの進捗であるが、途中の工程遅延により、完成日では、予定２００２年１月３１日に対して実績が２００２年２月１０日になっており、１０日の遅れとなっている。このため、入庫日は、遅れを入庫予定日に加算して、入庫見込みを予定２００２年２月５日に対して、２００２年２月１５日となる。
【００１８】
図５は、形名別部品展開テーブルの一例を示したものである。製品形名別部品展開テーブル５０１は、製品形名５０２、プログラム提供媒体種５０３、プログラム提供媒体種の原本数量５０４、マニュアル提供媒体種５０５、マニュアル提供媒体種の原本数量５０６から構成されており、各製品形名がどういう部品から構成されているかを示している。図５の例では、製品形名Ｐ−Ａは、プログラム提供媒体種ＭＯ１枚と、マニュアル提供媒体種紙１０枚から１製品が構成されることを示している。
【００１９】
図６は、媒体別展開テーブルの一例を示したものである。これは、発注依頼に基づいて生成されるものである。媒体別展開テーブル６０１は、媒体６０２、製品形名６０３、バージョン６０４、手配数量６０５、原本番号６０６、生産数量６０７、生産開始可能日６０８、生産完了日６０９、納期６１０から構成され、媒体別に生産枚数をまとめた表である。図６の例では、媒体ＭＯは、製品形名Ｐ−Ａ及び製品形名Ｐ−Ｂの出荷用媒体である。製品形名Ｐ−Ａでは、納期２００２年２月５日に対しては原本番号Ａ１に対して発注数量１００セットであり、生産枚数は１００枚になる。生産開始は２００２年２月１日であり、納期２００２年２月５日を見込んだ生産完了日は２００２年２月４日を予定している。製品形名ごとの発注数量は、後述する顧客から送られてくる発注依頼シートを参照する。生産開始可能日は、開発工程状況テーブル４０１の入庫日４０６を参照する。生産完了日は、発注依頼シートの納期と、後述する移動時間テーブルから移動の所要日数を引いて算出する。納期は発注依頼シートの納期を参照する。
【００２０】
次に、工程監視データベース１１０に登録されている生産機別展開テーブル、シフト尺度テーブル、移動時間テーブルについて説明する。
【００２１】
図７は、生産機別展開テーブルの一例を示したものである。この生産計画も発注依頼に基づいて生成される。生産機別展開テーブル７０１は、媒体７０２、号機７０３、稼動状況７０４、生産能力７０５、日別生産計画７０６、７０７、７０８、７０９から構成され、各生産機ごとの生産計画を示すものである。図７の例では、媒体ＭＯは、２台の生産機＃１及び＃２（７０３）で生産する。それぞれの号機は正常稼動しており、生産能力は＃１で１日１００枚、＃２で１日５０枚である。この性能をもつ生産機に、２００２年２月の日別に生産枚数を割り振ったのが生産計画（７０６、７０７、７０８、７０９）である。２月１日の＃１は、１日１００枚の生産能力に対して５０枚の生産計画であるが、２月１６日の＃２は、１日５０枚の生産能力に対して１００枚を割り当てている。計算上は稼働率２００％ということであり、シフト尺度８０１を利用して人員シフトなどの手段をとる必要があることを示す。
【００２２】
図８は、シフト尺度テーブルの一例を示したものである。シフト尺度テーブル８０１は、稼働率８０２、勤務形態８０３、残業８０４で構成され、生産機の稼働率に応じて人員シフトの形態をあらかじめ定めたものである。図８の例では、稼働率１００％未満であれば勤務は１シフトで残業なしであるが、稼働率２０１〜２９９％の場合は、勤務は２シフトで、残業する必要が有ることを示している。２シフトとは、作業開始時間と終了時間が、例えば０時から８時までの組と８時から１６時までの２組に、作業員をグループ分けすることである。
【００２３】
図９は、移動時間テーブルの一例を示したものである。これは、輸送に必要な日数を示したものであり、配送地区９０２、所要日数９０３、基本手段９０４から構成され、配送地区ごとに輸送にかかる所要日数と輸送手段とが登録されている。図９の例では、配送地区が北海道９０２では、運輸手段は航空便と陸送の組み合わせ（９０４）であり、２日間（９０３）かかることを示している。所要日数は、顧客向けに製品を出荷する場所を基点とする。
【００２４】
次に、在庫監視データベース１１５に登録されている在庫管理テーブルについて説明する。
【００２５】
図１０は、在庫管理テーブルの一例を示したものである。在庫管理テーブル１００１は、製品形名１００２、全数量１００３、在庫引当て済数量１００４、在庫数量１００５、納入リードタイム１００６から構成され、製品形名ごとの在庫数量を示す表である。図１０の例では、製品形名Ｐ−Ｃは、全数量は１００個あるが、そのうち９５個は引当て済であり、新規の顧客に引き当てられる在庫数量は５個である。また、発注から納入までのリードタイムは、１０日間である。
【００２６】
次に、購買監視データベース１１６に登録されている在庫引当テーブルについて説明する。
【００２７】
図１１は、在庫引当テーブルの一例を示したものである。在庫引当テーブル１１０１は、在庫番号１１０２、引当顧客１１０３、納期１１０４から構成され、各製品形名ごとの在庫がどの顧客に引き当てられているかを示す表である。図１１の例では、製品形名Ｐ−Ｃは在庫番号＃１から＃６まで６個の在庫をもち、＃１は納期２００２年２月１日でＡ社、＃５は納期２００３年１月１日でＤ社に引き当てられている。
【００２８】
図１２は、在庫引当テーブルの一例を示したものである。この在庫引当管理テーブル（付け替え後）１２０１は、在庫番号１２０２、引当て顧客１２０３、納期１２０４、追加発注１２０５、検収予定１２０６から構成され、引当てられた在庫を別の顧客に引当てる、という引当て変更を管理する表であり、図１１の在庫引当て表から派生する。図１２の例では、製品形名Ｐ−Ｃを２００２年２月１５日にＸ社あて２個、という発注がはいり、、＃５、＃６はそれぞれＤ社、Ｅ社からＸ社に引き当て先が変更になり、かわりに２個追加発注（１２０５）を行ない、その２個の検収予定はともに２００２年２月２８日であることを示す。製品形名Ｐ−Ｃは、納入リードタイム１０日であり（１２０６）、在庫番号＃５は納期が２００３年、＃６は納期が２００５年なので＃５及び＃６をＸ社に引当て直しても、Ｄ社及びＥ社の納期までには在庫の補充ができると判定し、引き当て先を変更する。同時に補充分の発注を行ない（１２０５）、検収予定日を登録する（１２０６）。
【００２９】
次に顧客から送られてくる発注依頼シート、顧客へ送る納期回答シートについて説明する。
【００３０】
図１３は発注依頼シートの一例を示したものである。発注依頼シート１３０１は、発注番号、発注日、顧客名、送付先住所、送付先責任者、お問い合わせ電話番号、納期、備考、発注構成１３０２、製品形名１３０３、バージョン１３０４、数量１３０５から構成され、顧客から製品の発注を受けるための製品注文用シートである。
【００３１】
図１４は、納期回答シートの一例を示したものである。納期回答シート１４０１は、製品形名１４０２、バージョン１４０３、数量１４０４、自社生産品・購入品の区分１４０５、納入の可否１４０６、理由等１４０７、メッセージ１４０８から構成され、顧客からの発注に対して発注の受諾の可否を報告するシートである。図１４の例では、製品形名Ｐ−Ｃ（１４０２）のバージョン０２−００（１４０３）は、数量１００の発注を受けている（１４０４）が、購入品（１４０５）であり、在庫切れで在庫補充は２月２８日のために納期３月１日に変更が必要であり（１４０７）、納期どおりの納入は不可（１４０６）となっている。このため、発注全体として納期変更のお願いを顧客に回答として返す（１４０８）。
【００３２】
次に、本システムの動作について説明する。
【００３３】
図１５は、受注支援装置１０１の処理を示したものである。顧客は、ユーザコンピュータ１１９を使用して、発注依頼シート１３０１にいつ、どこへ、何を納入するか、という必要事項を記載して、受注支援装置１０１に送る。受注支援装置１０１は、発注依頼シートを受け取ると処理を開始する。まず、発注依頼シート１３０１の発注構成１３０２の検証を行う（１５０１）。具体的には、受注支援データベース１０５に格納された受注支援データ２０１、納入実績データ３０１を検索し、稼動前提条件を満たしているかを検証する。まず、発注依頼シート１３０１の発注構成１３０２と受注支援データ２０１とを参照して稼動前提となる製品を特定する。次に納入実績データ３０１を参照して、稼動前提となる製品がすでに顧客へ納入済かを検証する。例えば、型名Ｐ−Ｂといった製品の発注依頼がある場合、受注支援データ２０１より型名Ｐ−Ａの製品が稼動前提となる。この場合、納入実績データ３０１を参照して既に納入済みであるかどうかを決定する。その結果、発注構成に問題がない場合、つまり顧客へ納入済みであり、顧客が既に所有している場合は（処理１５０２で「Ｙ」）、製造出荷装置１０４へ納期確認を行なう（１５０３）。製造出荷装置から納期確認の結果が記載された納期回答シート１４０１を受け取ると回答を補足するメッセージ１４０８を作成し（１５０４）、ユーザコンピュータ１１９に送る（１５０５）。一方、問題がある場合、つまり顧客が所有していることを確認できない場合は（処理１５０２で「Ｎ」）、稼動前提となる製品を所有しているかどうか確認できない旨のメッセージを生成し（１５０４）、顧客に対してメッセージを送る（１５０５）。
【００３４】
図１６は、製造出荷装置１０４の処理を示したものである。
【００３５】
受注支援装置１０４から納期確認の依頼を受け取ると処理を開始する。まず、受注支援データ２０１を参照し、発注構成１３０２の製品形名（１３０３）と受注支援データの製品形名（２０２）を１製品形名ごとに突き合わせ、自社生産品か購入品かの区分（２０３）を参照して、区分リストを作成する（１６０１）。この区分リストは、自社品の区分に属する型名、バージョン、数量からなるリストと、購入品の区分に属する型名、バージョン、数量からなるリストである。この区分リストを、自社生産品であれば（処理１６０２で「Ｙ」）、製造工程管理部１０７へ渡し、購入品であれば（処理１６０２で「Ｎ」）、購入品管理部１１２へ渡し納期確認を行なう（１６０３、１６０４）。それぞれの納期確認結果が記載された区分リストを統合して納期回答シート１４０１を作成する（１６０５）。また、納期を含めて発注内容に問題がない場合は（処理１６０６で「Ｙ」）、そのまま出荷管理部１１７へ出荷指示を出す（１６０７）。次に、受注支援装置１０１へ、納期回答シートを送る（１６０８）。
【００３６】
図１７は、製造工程管理部の処理を示したものである。製造工程管理部１０７は納期確認依頼を受け取ると処理を開始する。まず原本を引き当てる（１７０１）。原本がない場合は（処理１７０２で「Ｎ」）、開発工程状況テーブル４０１から当該製品の原本の工程状況を参照し、入庫見込みの日程を読み出す（１７０３）。次に各製品形名ごとの生産着手可能日を決める（１７０４）。既に原本がある場合には、依頼を受付けた次の日を生産着手可能日とし、原本がない場合には入庫見込みの次の日を生産着手可能日とする。次に、生産計画に媒体生産量を当てはめ、生産機ごとの生産計画を決める（１７０５）。まず、製品形名別部品展開テーブル５０１から、製品形名ごとの出荷品の物理的な部品構成を参照し、各製品形名ごとに何を生産するかを決める。次に、発注構成１３０２と、製品形名別展開テーブル５０１から、媒体別展開テーブル６０１を作成し、媒体ごとの生産量を決める。次に、他の発注依頼による生産機別展開テーブルがあれば、その生産機別展開テーブルを参照して製品型名ごとの生産着手可能日を決める。次に、顧客の要求する納期１３０６から配送地区別に輸送にかる所要日数９０３を差し引いて、生産完了日６０９を決める。この生産完了日に向けて生産機を効率よく稼動させるため、生産機ごとの生産計画に展開し、生産機別展開テーブル７０１を作成する。生産能力を超える生産を要する場合は、シフト尺度テーブル８０１から、残業でこなすか交代制シフトを組むかを決める。ここでは、（決定された１日の生産量）／（生産機の一日の生産量）により稼働率を求め、この稼働率とシフト尺度により勤務形態を決定する。生産能力以下の発注の場合は、シフトを組めば納期通り製品を顧客に納入できるため、顧客の要求納期を区分リストに記載する。シフトを組んでもこなせない、生産能力以上の発注依頼が来た場合は、稼働率を最大にあげた生産完了日に所要日数９０３を加えた日を最短納期とし、稼働率１００％を維持した場合の生産完了日に所要日数９０３を加えた日を標準納期として区分リストに記載する（１７０６）。リストの全件が終了すれば（処理１７０７で「Ｙ」）、処理を終了する。
【００３７】
図１８は、購入品管理部の処理を示したものである。購入品管理部１１２は、納期確認依頼を受け取り処理を開始する。在庫引き当てを行なう（１８０１）。在庫管理テーブル１００１を参照し、製品形名１００２ごとに、まだ別の顧客の発注に引当てられていない在庫数量１００５と、発注された製品形名の数量１３０５とを比較し、発注数量より在庫数量が少なければ、不足分を発注する（１８０５）。このとき、在庫の引き当ての付け替えを行なう（１８０４）。在庫管理テーブル１００１には、各製品形名ごとに購買先への発注から検収までの納入リードタイム１００６が定義されている。また、各製品形名の在庫番号１１０２ごとに、納入予定の顧客が引当てられており（１１０３）、顧客への納期も定義されている（１１０４）。発注シート１３０１における顧客への納期１３０６と在庫引当テーブル１１０１の納期１１０４と納入リードタイム１００６を比較し、引当てられている顧客への納期より納入リードタイムが短い場合は、現在引当てられている在庫番号を別の顧客に引当て直し（１２０４）、同時に不足分を発注する（１２０５、１２０６）。在庫がある場合は、そのまま顧客の発注に引当てる（１８０３）。以上の状況を区分リストに登録する（１８０６）。リストの全件が終了すれば（１８０７）、処理を終了する。
【００３８】
尚、図１で示したシステムは受注支援装置１０１と製造出荷装置１０４とが別々の装置で構成されていたが、これらが一つの装置で構成されていてもよい。その場合、受注支援装置１０１へ受注支援データベースの内容を送らなくて済む。
【００３９】
また、本システムを構成する各部は、ソフトウェアプログラムによって実現することが可能である。
【００４０】
【発明の効果】
本発明によれば、顧客は製品が自社生産品か購入品かを意識することなく発注の依頼を行なうことができる。
【図面の簡単な説明】
【図１】システムの構成の一例を示した図である。
【図２】受注支援データの一例を示した図である。
【図３】納入実績データの一例を示した図である。
【図４】開発工程状況テーブルの一例を示した図である。
【図５】製品形名別展開テーブルの一例を示した図である。
【図６】媒体別展開テーブルの一例を示した図である。
【図７】生産機別展開テーブルの一例を示した図である。
【図８】シフト尺度テーブルの一例を示した図である。
【図９】移動時間テーブルの一例を示した図である。
【図１０】在庫管理テーブルの一例を示した図である。
【図１１】在庫引当テーブルの一例を示した図である。
【図１２】在庫引当テーブル（付け替え後）の一例を示した図である。
【図１３】発注依頼シートの一例を示した図である。
【図１４】納期回答シートの一例を示した図である。
【図１５】受注支援装置の動作を示すフォローチャートである。
【図１６】製造出荷装置の動作を示すフローチャートである。
【図１７】製造工程管理部の動作を示すフローチャートである。
【図１８】購入品管理部の動作を示すフローチャートである。
【符号の説明】
１０１　受注支援装置
１０２　情報受発信部
１０３　発注構成確認部
１０４　製造出荷装置
１０５　受注支援データベース
１０６　受注解析部
１０７　製造工程管理部
１０８　工程管理部
１０９　原本管理部
１１０　原本監視データベース
１１１　工程監視データベース
１１２　購入品管理部
１１３　在庫引き当て管理部
１１４　購買管理部
１１５　在庫監視データベース
１１６　購買監視データベース
１１７　出荷管理部
１１９　ユーザコンピュータ
【図１】
2004046660.tif 000003
【図２】
2004046660.tif 000004
【図３】
2004046660.tif 000005
【図４】
2004046660.tif 000006
【図５】
2004046660.tif 000007
【図６】
2004046660.tif 000008
【図７】
2004046660.tif 000009
【図８】
2004046660.tif 000010
【図９】
2004046660.tif 000011
【図１０】
2004046660.tif 000012
【図１１】
2004046660.tif 000013
【図１２】
2004046660.tif 000014
【図１３】
2004046660.tif 000015
【図１４】
2004046660.tif 000016
【図１５】
2004046660.tif 000017
【図１６】
2004046660.tif 000018
【図１７】
2004046660.tif 000019
【図１８】
2004046660.tif 000020