JP2006119686A

JP2006119686A - 進捗管理システム

Info

Publication number: JP2006119686A
Application number: JP2004303650A
Authority: JP
Inventors: Akane Nishida; 茜西田; Shinya Tatsuo; 信哉龍尾; Tetsuo Mizuta; 哲郎水田; Satoshi Yasuda; 聡安田
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2004-10-19
Filing date: 2004-10-19
Publication date: 2006-05-11

Abstract

【課題】信頼性の低い調達先と信頼性の高い調達先とを同様に進捗管理している結果、納期遅延が多発し、またはきめ細かい進捗管理を全ての調達先／調達品に行うと管理コストが増大してしまうが、これらを回避するためにトラブル発生を極小化する上で必要な進捗管理を低コストで実施可能とすること。
【解決手段】調達先マスタ４に格納した調達先の信頼度と進捗管理基準６に格納した工程完了報告手段から工程完了報告手段を算出、部品マスタ５に格納した部品の重要度と進捗管理基準６に格納した部品別イベント別管理頻度基準と調達先の遅延度から工程進捗報告日程を算出するだけでなく、遅延時フォローの判定も部品の重要度と調達先の遅延度から算出する。また、実績が進捗管理基準６にフィードバックするので、ナレッジが蓄積・反映されて実情に即した進捗管理の実施を支援できる、使えば使うほど成長するシステムである。
【選択図】図１

Description

本発明は、調達品、調達先の特性に応じて進捗確認の頻度および進捗確認の手段（テキスト、音声、写真、現物）を切り替えることで、必要な進捗管理を低コストで実施する進捗管理システムに関する。

経済の成熟・規制緩和に伴い競合が乱立する市場環境で収益を上げるためには、更なる原価低減を進める必要がある。そのため、企業は今まで内作していた部材を外注化する「調達品範囲を拡大」し、更に安く調達できる調達先を求め、「調達先の広域化／グローバル化」を行っている。

外注化した案件の管理のため、従来、企業から希望催促方法を受け取り、それを希望催促方法・監視条件ＤＢに登録し、希望催促方法・監視条件ＤＢとスケジュールを元に、業務の実施を促す催促方法を作成し、催促方法を催促方法・監視条件に登録し、催促方法・監視条件に基づいて企業に対して催促を実行する技術が提案されている（特許文献１）。

特開２００４−１６４１４８号公報

しかし、上記従来技術においては、催促方法・監視条件をデータベースに格納しているものの、この催促方法の入力を省力化する手段についてまでは配慮されていない。また、きめ細かい進捗管理を調達先／調達品に人為的に行うと管理コストが問題となり得る。

進捗管理手段に関する情報を表示する発注元端末とネットワークを介して通信可能に接続され、部品等の調達先の進捗状況を管理する進捗管理システムにおける進捗管理方法であって、調達される部品の重要度と当該部品を識別する部品識別情報とを対応付けて部品重要度テーブルに格納し、前記部品識別情報と、進捗管理報告を要求する時間間隔を算出するための係数である管理頻度基準とを対応付けて管理頻度基準テーブルに格納し、新たに調達される部品の部品識別情報に対応する部品重要度及び管理頻度基準をそれぞれ前記部品重要度テーブル及び前記管理頻度基準テーブルから読み出し、読み出した部品重要度及び管理頻度基準に基づいて進捗管理間隔を決定することを特徴とする進捗管理方法。

本発明を適用することにより、調達先の進捗管理をする場合における進捗管理が容易になる。

以下、図を参照し、本発明に関わる好適な実施形態を説明する。
図１は、本実施例のシステム全体の構成例である。１は進捗管理システム、２は案件マスタ、３は稼動日マスタ、４は調達先マスタ、５は部品マスタ、６は進捗管理基準、７は進捗管理方法判定プログラム、８は進捗管理計画、９は調達先進捗報告システム、１０は調達先参照プログラム、１１は調達先登録プログラム、１２は調達先端末、１３は進捗管理実績、１４は発注元参照プログラム、１５は発注元端末、１６は発注元登録プログラム、１７は遅延時フォロー判定基準、１８は遅延時フォロー判定プログラム、１９は進捗管理基準メンテナンスプログラムである。

進捗管理システム１は、社内ネットワークを介して案件マスタ２、稼動日マスタ３に接続している。また、社外ネットワークを介して調達先進捗報告システム９と接続している。なお、進捗管理システム１との通信ネットワークは、社内ネットワーク、社外ネットワークに必ずしも拘泥することはなく、進捗管理システム１と通信可能に接続されていればどのような通信回線その他のネットワークでも良い。

案件マスタ２は、発注した案件の基本的データを格納するよう構成されている。ここでいう案件の基本的データとは、プロジェクト名、発注を識別する情報である調達発注ＮＯ、調達先を識別する調達先識別情報、部品を識別する部品名、担当者社員ＮＯ、担当者名、発注日、作業開始日、納品日などのことである。また、この案件マスタは企業内で利用する案件マスタとは区別して、本実施例に適した形で加工して、本システムに組み入れてもよい。

案件マスタ２には案件基本データテーブル８００と新着案件基本データテーブル２９００が格納されている。案件基本データテーブル８００は、進捗管理中も利用されるが、新着案件基本データテーブル２９００は、案件基本データテーブル８００に格納するデータの元となるデータを格納しており、進捗管理方法判定処理２０で利用される。新たに発注した案件は、まず新着基本データテーブル２９００に格納され、その後進捗管理方法判定処理２０の後、案件基本データテーブル８００に格納される。

図２は案件マスタ２の案件基本データテーブル８００のデータ構造の例を示す図である。プロジェクトを識別するプロジェクト名８１、発注に係る案件を識別する発注ＮＯ８２、調達先を識別する情報である調達先８３、部品を識別する情報である部品８４、担当者社員を識別する担当者社員ＮＯ８５、担当者名８６、部品の発注日８７、部品の製造作業を開始した日である作業開始日８８、部品の納品日８９を格納している例である。ここに案件の最低限必要な情報が格納してある。担当者社員ＮＯによって進捗管理実施の際に担当者毎の進捗管理を抽出することができる。

図３は案件マスタ２の新着案件基本データテーブル２９００のデータ構造の例を示す図である。データ項目は案件基本データテーブル２９００と同様である。また、稼動日マスタ３は、発注元がいつ稼動しているかを示す稼働日データを格納する。以下の説明では省略するが、日程の算出において日数を数える場合には稼動しない日は除外して処理する。この稼働日マスタは企業内で利用する稼働日マスタとは区別して、本実施例に適した形で加工して、本システムに組み入れてもよい。

図４は本システムの全体処理を示すフローチャートの一例である。以下、進捗管理方法判定２０、進捗管理報告参照・登録２１、遅延時フォロー判定２２、進捗管理基準メンテナンス２３について、順に説明していく。便宜上フローチャートとして示しているが、必ずしも処理の実行順はこの順の必要はなく、例えば、進捗管理報告参照・登録は繰り返し工程が完了したとき実行されるが、進捗管理方法判定はデータの登録のときに一度だけ行うようにしてもよい。

まず、進捗管理方法判定２０について説明する。
図５は進捗管理方法判定のフローチャートの例である。まず、工程完了イベント予定日の算出２４を行い、次に工程完了報告の手段算出２５、最後に工程進捗報告日程の算出２６を行う。工程完了イベントとは、部品等を製造する過程にある1以上の工程の各工程の終了に対応する処理のことであり、各工程番号で識別される工程について、その工程が完了したことを示す。

図６は、工程完了イベント予定日の算出２４のフローチャートの例である。まず稼働日マスタ３より稼働日を取得する（ステップ２７）。新着案件基本データテーブル２９００の部品２９３から部品の識別情報と納品日（最後の工程の工程完了イベント日に該当）を得て、部品識別情報をキーとして、工程完了報告手段テーブル２２０から最後の工程番号を読み出し、管理頻度基準テーブル２６０からＳＴ（標準時間）を読み出す（ステップ２８）。ＳＴとは一定数の物を製造するのに必要な日数をいう。なおステップ２８においては、管理頻度基準テーブル２６０から最後の工程番号とＳＴとを取得しても良い。

最後の工程番号の工程完了イベント日（ここでは最後の工程なので納品日）から最後の工程番号のST（標準時間）を引いて、最後から２番目の工程完了イベント日を算出する（ステップ２９）。最後から２番目の工程完了イベント日を新たに工程完了イベント日に代入する（ステップ３０）。次に残りの工程完了イベント数を１減らし（ステップ３２）、次の工程完了イベントの工程番号が残っているかの判定をする（ステップ３３）。工程番号が残っている場合は、次の工程番号に移りステップ２９に移行する。次の工程番号においては、次の工程完了イベント日から次の工程のＳＴを引いて、次の次の工程の工程完了イベント日を決定する。このような手順を繰り返し、最後からN番目（N=２〜総工程完了イベント数）の工程完了イベント日が算出できる。

全ての工程番号を処理し終わった場合は、最初の工程番号の工程完了イベント日（スタート日）が本日より前になってないかチェックする（ステップ３４）。最初の工程番号の工程完了イベント日（スタート日）が進捗管理システムを操作している当日より後の場合は、工程完了イベント予定日の算出終了となる。進捗管理システム１は、算出した各工程完了イベント日を案件別進捗管理計画テーブル２３００の工程完了イベントの予定日239に格納する。

図７に案件別進捗管理計画テーブル２３００のデータ構成の一例の図を示す。案件別進捗管理計画テーブル２３００は、発注NO８２、部品８４、調達先８３、工程番号２２３、工程完了イベント２２４、工程完了予定日２３６、工程完了報告手段２２５、工程進捗報告がなされる予定日である工程進捗報告予定日２３８、進捗報告がどれだけ進んだかを示す工程進捗報告度２３９を格納する。

最初の工程番号の工程完了イベント日（スタート日）が進捗管理システムを操作している当日より前の場合、工程の調整に移る（ステップ３５）。調整においては、発注元端末１８の画面に、十分な時間がなく調整が必要である旨を表示し、調整後の日程の入力を受付け、案件別進捗管理計画テーブル２３００の工程完了イベントの予定日239に格納する。

このように最後の工程番号に対応する工程完了イベント日から、各工程のSTを順次引くことを繰り返すことにより、部品等を製造するする過程にある各工程に対応する各完了イベント予定日が求められる。

図８は工程完了報告の手段決定処理２５のフローチャートの例である。まず、新着案件基本データテーブル２９０から調達先８３と部品８４とを読み出し、読み出した調達先８３をキーに、事前に設定した調達先マスタの調達先信頼度テーブル２１０から信頼度２１４を読み出す（ステップ３６）。ステップ３６で読み出した調達先８３と部品８４とをキーに、事前に設定した進捗管理基準データベース６に格納している工程完了報告手段テーブルから工程完了イベントの完了報告手段を決定する（ステップ３７）。次に工程完了イベントの完了報告手段をまだ決定していない工程が工程完了報告手段テーブルにまだ残っているかどうかの判定をし（ステップ３８）、残っていれば次の工程完了イベントに移る（ステップ３９）。残っていなければ工程完了報告の手段決定処理の終了となる。

図９は調達先マスタ４の調達先信頼度テーブルのデータ構成の一例を示す図である。調達先マスタ４の調達先信頼度テーブルには例として、調達先８３、品質２１２、発注元との関係の深さ/正直な対応２１３、品質及び発注元との関係の深さ/正直な対応より設定される信頼度２１４が格納してある。

図１０は進捗管理基準データベース６の工程完了報告手段テーブルのデータ構成の一例を示す図である。進捗管理基準データベース６の工程完了報告手段テーブルは、例として、部品を識別する情報である部品８３、調達先の信頼度２１４、工程を識別する工程番号２２３、工程の完了を意味するイベントである工程完了イベントを識別する工程完了イベント２２４、工程完了をどのような手段で報告するかを示す工程完了報告手段２２５を格納する。

以上のように、調達先の信頼度及び部品に応じて工程完了報告の手段を切り替えることができる。

図１１は工程進捗報告日程の算出２６のフローチャートの例である。まず新着案件基本データテーブル２９０から作業開始日２９８と、最後の工程完了報告日（ここでは納品日２９９）を読み出す（ステップ４０）。次に進捗管理の間隔である進捗報告間隔を算出（ステップ４１（図１２を用いて後述））し、前工程完了報告日+間隔で進捗報告日を算出する（ステップ４２）。進捗報告日と次工程完了報告日の先後を判断することにより、進捗報告日がまだ必要かどうかの判定をし（ステップ４３）、進捗報告日が次工程完了報告日より後日にならない場合（ステップ４３：ＮＯ）、進捗報告日が確定し（ステップ４４）、次の進捗報告日に移る（ステップ４５）。前進捗報告日+間隔で進捗報告日を算出し（ステップ４６）、再び進捗報告日がまだ必要かどうかの判定（ステップ４３）に移行する。

進捗報告日が次工程完了報告日より後日になる場合（ステップ４３：ＹＥＳ）、その工程内での進捗報告日は終了したと判断し、今度は進捗報告日が最後の工程を超えていないか進捗報告日と納期を比較して判定する（ステップ４７）。ＮＯの場合はまだ工程が残っていると判定して次の工程に移る（ステップ４８）。ＹＥＳの場合は全ての工程の進捗報告日の算出が終了したと判定して、全工程進捗報告に対し、1工程中で既にした進捗報告の数を同一工程中の全進捗報告数で除して100を乗じる処理で工程進捗報告度（％）を算出して（ステップ４９）、工程進捗報告日程の算出２６が終了する。

図１２は、ステップ４１の進捗報告の間隔の算出処理４１のフローチャートの例である。1／MAX頻度で最小の進捗報告の間隔を算出し（ステップ５０）、1／（（部品別イベント別管理頻度基準）× （部品重要度）×（調達先別部品別遅延率/部品別遅延率））でその進捗管理報告内における採用度合いを算出する（ステップ５１）。ステップ５０で算出した最小の進捗報告の間隔とステップ５１で算出した採用度合いを掛けて、このイベントでの間隔を算出して、終了する。MAX頻度とは、ここでは事前に設定した、単位時間当たりの報告要求回数で最大のものをいう。

ステップ５１をより詳細に説明する。ステップ３６で読み出した部品の識別情報及び調達先の識別情報をキーとして予め格納したデータを読み出すことで部品別イベント別管理頻度基準、部品重要度、調達先別部品別遅延率、部品別遅延率を取得し、上述の採用度合いを算出する。具体的には、部品別イベント別管理頻度基準は、部品の識別情報をキーに管理基準テーブルから得られる。部品重要度は、部品の識別情報をキーに部品重要度テーブルから得られる。調達先別部品別遅延率は、調達先の識別情報をキーに調達先別部品別遅延率テーブルから得られる。部品別遅延率は、部品別遅延率テーブルから、部品の識別情報をキーに得られる。

図１３は、管理頻度基準テーブル２６０のデータ構成の一例を示す図である。管理頻度基準テーブル２６０は、部品を識別する情報である部品８３、工程を識別する工程番号２６２、工程完了イベントを識別する工程完了イベント２６３、各工程の標準時間であるＳＴ２６４、進捗管理報告を要求する時間間隔を部品別イベント別に算出するための係数である管理頻度基準２６５を対応付けて格納する。

図１４は、部品重要度テーブル２７０のデータ構成の一例を示す図である。部品重要度テーブル２７０は、部品８３、パーツの重要性を表すキーパーツ度２７２、その部品を製造することの難易度を示す製造難易度２７３、その部品を在庫として保持することの難易度を示す在庫保持難易度２７４、及び、キーパーツ度２７２と製造難易度２７３と在庫保持難易度２７４とから算出される重要度２７５を格納する。

図１５は、調達先別部品別遅延率テーブル２４０のデータ構成の一例を示す図である。調達先別部品別遅延率テーブル２４０は、調達先８３、部品８４、遅延率２４３を対応付けて格納する。

図１６は、部品別遅延率テーブル２５０のデータ構成の一例を示す図である。部品別遅延率テーブル２５０は、部品８４と遅延率２５２を対応付けて格納する。

以上のように工程進捗報告日程の算出は、部品の重要度と調達先の遅延度によって算出する。

ここでの例では進捗報告のMAX頻度との比較でどのくらいの値を採用するかによって進捗報告の間隔を算出し、その間隔は、工程内で等しく分配する。なお、その他考えられる進捗報告日程の算出方法としては、企業によってステップ４６の進捗報告日＝前進捗報告日+間隔の他にバリエーションを保持することが考えられる。

バリエーションとしては、１．工程内の前半に重みを持つ特徴がある場合、工程内の前半に進捗報告日を重点化して設定する。２．工程内の後半に重みを持つ特徴がある場合、工程内の後半に進捗報告日を重点化して設定する、などが例としてあげられる。どのバリエーションせよ、調達先の遅延度と部品の重要度が設定されていれば、案件毎に適切な工程進捗報告日程が設定される。

図１７は工程完了報告の手段決定処理２５に関わるデータの例を示す図である。例として案件マスタ２の新着案件基本データテーブル２９、調達先マスタ４の調達先信頼度テーブル２１０、進捗管理基準データベース６の工程完了報告手段テーブル２２０より工程完了報告の手段を読み出し、進捗管理計画８の案件別進捗管理計画テーブルに格納する。工程完了報告の手段決定に必要な項目の例は、案件マスタ２の案件基本データテーブルの調達先、部品名、調達先マスタ４の調達先信頼度テーブルの信頼度、進捗管理基準データベース６の工程完了報告手段テーブルの調達先の信頼度毎の工程完了報告手段である。

調達先信頼度が変化しても工程完了イベントの増減はなく固定であり、調達先の信頼度の影響は工程完了イベントの工程完了報告手段に反映する。よって同じ部品であっても調達先の信頼度に応じて工程完了報告手段が切り替わる。

図１８は工程進捗報告日程の算出２６の情報項目と処理のデータ構造の例を示す図である。例として案件マスタ２の案件基本データテーブル、部品マスタ５の部品重要度テーブル、進捗管理基準データベース６の管理頻度基準テーブル２６０、進捗管理基準データベース６の調達先部品別遅延度テーブル２４０、進捗管理基準データベース６の部品別遅延率テーブル２５０より工程進捗報告日程を算出し、進捗管理計画８の案件別進捗管理計画テーブルに格納する。

工程進捗報告日程の算出に必要な項目の例は、案件マスタ２の新着案件基本データテーブル２９０の調達先、部品名、部品マスタ５の部品重要度テーブルの部品の重要度、進捗管理基準データベース６の管理頻度基準テーブルの部品毎、工程イベント毎のＳＴと部品別イベント別管理頻度基準（％）、進捗管理基準データベース６の調達先部品別遅延度テーブルの調達先毎、部品毎の遅延度、進捗管理基準データベース６の部品別遅延率テーブルの部品毎の遅延率である。

進捗管理頻度は部品の重要度と調達先の信頼度によって変わる。よって同じ部品であっても調達先の信頼度に応じて進捗報告頻度が切り替わり、同じ調達先であっても発注した部品の遅延度によって進捗報告頻度は切り替わる。

図１９は進捗管理報告参照・登録処理２１の一例を表すフローチャートである。まずネットワークを通じて調達先端末１２が発注元から送られてきた進捗報告予定を表示し（ステップ５３）、確認を促す。調達先端末１２は調達先における作業の進捗状況を工程進捗報告と工程完了報告のタイミングで、進捗管理システム１に送信し登録する（ステップ５４）。発注元端末５は調達先から送られてきた工程進捗報告もしくは工程完了報告を表示し（ステップ５５）、確認を発注元端末操作者に促し、承認を受付ける（ステップ５６）。その後承認されたデータを実績として進捗管理実績データベース１３にデータ蓄積する（ステップ５７）。また、進捗が遅れ、工程完了報告予定日に工程完了イベントが間に合わなかった場合、次以降の工程完了報告予定日が順次ずれるので、工程完了報告予定日を再設定し、または再設定の受付をする。受け付けた再設定日は進捗管理計画テーブルの再設定予定日に格納する。進捗管理報告参照・登録処理２１は終了する。なお、遅延による予定日の再設定が生じない場合にはもともとの進捗報告予定日が再設定予定日にセットされている。

ここでは調達先が発注元から送られてきた進捗報告予定を参照・確認・登録し、発注元は調達先から送られてきた進捗報告を参照・確認・承認することにより、発注先と調達先のリアルタイムの進捗管理が可能となる。

図２０は進捗管理報告参照・登録２１の情報項目と処理とデータ構造の例を示す図である。実績は例として進捗管理実績データベース１３の進捗管理実績テーブルに格納する。進捗管理実績データベース１３の進捗管理実績テーブルには例として発注ＮＯ８２、部品８４、調達先８３、工程番号２２３、工程完了イベント２２４、工程完了報告予定日、再設定予定日、実績（工程完了報告実施日）、実績（工程完了報告緊急報告）、実績（コメント）、工程完了報告手段、実績（工程完了報告手段）、実績（工程完了報告承認）、工程進捗報告予定日、工程進捗報告度、実績（工程進捗報告度）、実績（工程進捗報告緊急報告）、実績（コメント）、実績（工程進捗報告承認）を格納する。

調達先が登録する例としては実績（工程完了報告実施日）、実績（工程完了報告緊急報告）、実績（コメント）、実績（工程完了報告手段）である。発注元が登録する例としては実績（工程完了報告承認）、実績（工程進捗報告承認）である。

次の処理例として、登録した実績（工程完了報告実施日）から、実績（LT）、実績（遵守／遅延日数）、実績（遅延度％）を算出して、登録した実績（工程進捗報告度％）から実績（遅延度％）を算出し、進捗管理実績データベース１３の進捗管理実績テーブルに格納する。

図２１は遅延時フォロー判定２２のフローチャートの例である。まず進捗管理計画８、進捗管理実績データベース１３を取得し（ステップ５８）、進捗管理計画８から本日が工程完了報告予定日、進捗報告日であるかどうかの判定をする（ステップ５９）。ＮＯならば遅延とは判断せず終了する。ＹＥＳならば進捗管理計画８と進捗管理実績データベース１３の差分により工程完了報告の報告遅延の判定と遅延度を算出し（ステップ６０（図２２を用いて後述））、フォロー判定（ステップ６１（図２３を用いて後述））を行う。フォローが必要であれば、発注元端末にフォロー案件表示画面を表示させるべく表示データを生成し、発注元端末に送信する（ステップ６１５）。フォロー案件表示画面には案件にういてのデータを表示させるが例えば担当者に関しては案件基本データテーブルを参照して担当者を特定する。再度進捗管理計画８、進捗管理実績データベース１３を取得し（ステップ６２）、進捗管理計画８から完了報告を承認（フォロー終了）しているか判定し（ステップ６３）、ＮＯなら、再度再度進捗管理計画８、進捗管理実績データベース１３を取得（ステップ６２）に移行する。ＹＥＳなら完了報告を承認してフォローが終了したと判断し、進捗管理実績データベース１３にデータを蓄積する（ステップ６４）。

ここでは、調達先の報告を受け、実績として格納して、そこから遅延率を算出することで、人的な判断など個人のスキルに依存しない実情に基づいた調達先の信頼度を図るための支援資料を取得できる。

図２２は工程完了報告の報告遅延判定、遅延度算出６０のフローチャートの例である。まず工程完了報告を遵守しているか遅延なのかを判定をする（ステップ６５）。工程完了報告実施日が再設定予定日を超えているＹＥＳの場合は遅延と判定し（ステップ６６）、（TODAY−再設定工程完了報告予定日）／工程完了日数で報告遅延度を算出し格納して（ステップ６７）、工程完了報告の報告遅延判定、遅延度算出が終了する。工程完了報告実施日が再設定予定日を超えていないＮＯの場合は遵守と判定して（ステップ６８）、報告遅延度が０と算出し格納して（ステップ６９）、工程完了報告の報告遅延判定、遅延度算出が終了する。

ここでは工程完了報告実施日が予定日予定通りに行われているかを判定し工程完了報告の報告遅延判定と遅延度算出をすることで、遅延に対する確実な情報を数値で取得できる機能を保有する。

図２３はフォロー判定６１のフローチャートの例である。まず進捗管理実績データベース１３の進捗管理実績テーブルより進捗報告の間隔を取得し（ステップ７０）、進捗報告の間隔×Ｎ（フォロー定数）でフォロー間隔を算出する（ステップ７１）。この場合、Ｎは事前に企業が設定するフォロー定数である。算出したフォロー間隔を進捗管理方法計画8の案件別進捗管理計画テーブルに書き込み（ステップ７２）、前フォロー日+間隔でフォロー日を算出する（ステップ７３）。ここではフォロー日の設定の限界を次工程の完了予定日としているので、フォロー日が次工程の完了予定日を超えていないかどうかを判定する（ステップ７４）。超えていなければＹＥＳでフォロー判定は終了する。超えていなければＮＯと判定して、前フォロー日+間隔でフォロー日の算出（ステップ７３）へ移行する。

ここでは工程完了報告に遅延が起こった場合に、工程完了報告の予定日とフォロー間隔よりフォロー日を算出することで、人的に行うと手間のかかる遅延時のフォローを支援できる機能を保有する。
以上のように、遅延時のフォローにも、調達先の遅延度と部品の重要度を使用する。調達先の信頼度と部品の重要度を事前に設定するだけでシステムが自動で進捗管理を支援するという思想はここでも一貫する。

図２４はフォロー判定６１の情報項目と処理例データ構造の例を示す図である。例として、進捗管理実績データベース１３の進捗管理実績テーブル、遅延時フォロー判定基準１７のフォロー定数テーブルがある。フォロー判定に必要な項目の例は進捗管理実績データベース１３の進捗管理実績テーブルの工程毎の進捗報告の間隔、遅延時フォロー判定基準１７のフォロー定数テーブルのフォロー定数である。フォロー判定で算出する項目の例は進捗管理実績データベース１３の進捗管理実績テーブルのフォロー日程間隔（間隔/定数）、フォロー日程である。

ここでは、遅延時のフォロー判定を自動ですることによって、人がきめ細やかなチェックをしなくても部品の重要度、調達先の遅延度といった適切なパラメータでチェックできる。

図２５は進捗管理基準メンテナンス２３のフローチャートの例である。まず信頼性のある統計のために集計有効範囲を算出し信頼性のあるデータ数の範囲で部品別イベント別遅延率を集計し蓄積する（ステップ７５（図２６を用いて後述））。次に部品別イベント別管理頻度基準を決定しデータを蓄積した（ステップ７６（図２７を用いて後述））後、STのメンテナンス判定（ステップ７７（図２８を用いて後述））を行う。

ここでは集計有効範囲を算出してその範囲で部品別イベント別遅延率を集計・蓄積し、STのメンテナンス判定を行うことで、信頼性のあるデータ範囲でST自体を疑う必要性があるか否かの支援ができる機能を保有する。

以上のように、実績を自動で進捗管理基準にフィードバックすることで、より実情に近い進捗管理方法の決定と遅延時のフォロー判定がリーズナブルに実施可能となる。また、あまりに遅延が発生した場合には、元のＳＴの設定を疑う必要性が出てくるため、そのメンテナンスのアラーム判定も本システムで行える。

図２６は集計有効範囲の算出・部品別イベント別遅延率集計・蓄積７５のフローチャートの例である。まず同一部品内イベント別データ数が規定値を超えているか判定し（ステップ７８）、超えていれば（ステップ７８：Ｙ）信頼性のあるデータ数が確保できたとみなし、部品内レベルで部品別イベント別の遅延率を集計し（ステップ７９）、集計有効範囲の算出・部品別イベント別遅延率集計・蓄積は終了する。同一部品内イベント別データ数が規定値を超えていない場合（ステップ７８：Ｎ）は、信頼性のあるデータ数が集まるまで集計範囲を広げる。同一部品内で不可能と判定した場合は、同一中分類で判定する。同一中分類イベント別データ数が規定値を超えているかの判定をして（ステップ８０）、超えていれば（ステップ８０：Ｙ）信頼性のあるデータ数が確保できたとみなし中分類レベルで部品別イベント別の遅延率を集計して（ステップ８１）、集計有効範囲の算出・部品別イベント別遅延率集計・蓄積は終了する。同一中分類で不可能と判定した場合（ステップ８０：Ｎ）は、同一大分類で部品別イベント別の遅延率を集計して（ステップ８２）、集計有効範囲の算出・部品別イベント別遅延率集計・蓄積は終了する。

ここでは信頼性のあるデータ数を確保できるまで集計範囲を上位の分類に拡大し、集計有効範囲で部品別イベント別遅延率を集計・蓄積することで、信頼性のあるデータ範囲での集計を可能にするため、新製品が投入された場合等個々の製品単位で十分なデータ数が無い場合でも柔軟に判断指標を提供できる。

図２７は部品別イベント別管理頻度基準の決定・蓄積７６のフローチャートの例である。事前に企業内で設定した、部品別イベント別遅延率xと部品別イベント別管理基準yの関係式y=f(x)と部品別イベント別遅延率の入力を受け付ける（ステップ８３）。次に部品別イベント別遅延率をy=f(x)の式に入れ、部品別イベント別管理頻度基準を算出した（ステップ８４）後、ステップ８４で算出した部品別イベント別管理頻度基準を最新の部品別イベント別管理頻度基準として管理頻度基準テーブルに入力し（ステップ８５）、部品別イベント別管理頻度基準の決定・蓄積が終了する。

納期に遅延が生じた場合、管理頻度基準が大きすぎた結果として進捗管理間隔が長すぎていることが考えられるため、管理頻度基準を減少させるように変更することで進捗管理間隔を短くする。

ここでは部品別イベント別遅延度から部品別イベント別管理頻度基準をメンテナンスして最新の部品別イベント別管理頻度基準を蓄積することで、常に最新の情報が反映されて実情に即した進捗管理方法を支援できる機能を保有する。

なお、y=f(x)の式と部品別イベント別遅延度の入力において、使用する計算式y=f(x)に企業毎の特徴を活かしたバリエーションを持たせ、管理頻度基準テーブルを切り替えることでより現実に即した進捗管理方法を決定できる。バリエーションのひとつとしては、遅延度の傾向値（ばらつきや平均値）を人が判断してもよい。

図２８はSTのメンテナンス判定７７のフローチャートの例である。まず部品別イベント別遅延率が一定数値を超えているかどうかの判定をし（ステップ８６）、超えていなければSTのメンテナンス判定は終了する。超えていた場合、今度は平均LT／STの乖離が一定数値を超えているかどうかの判定をする（ステップ８７）。超えていなければSTのメンテナンス判定は終了する。超えていれば、元のＳＴの設定を疑う必要性が出てくるため、アラーミングし（ステップ８８）、乖離したデータを示すリストを表示して（ステップ８９）STのメンテナンス判定は終了する。
ここでは部品別イベント別遅延率と平均LT／STの乖離具合からＳＴの設定を疑う必要性を判断し、必要があればアラーミングして乖離したデータを示すリストを表示することで、STそのものが実情の進捗管理に適応しているかの判断を支援できる。

本システム全体構成の一例を示す図案件マスタの案件基本データテーブルのデータ構造の例を示す図案件マスタの新着案件基本データテーブルのデータ構造の例を示す図本システムの全体処理の一例を示すフローチャート進捗管理方法判定の一例を示すフローチャート工程完了イベント予定日の算出の一例のフローチャート案件別進捗管理計画テーブルのデータ構成の例を示す図工程完了報告の手段算出の一例のフローチャート調達先信頼度テーブルのデータ構成の例を示す図工程完了報告手段テーブルのデータ構成の例を示す図工程進捗報告日程の決定処理の一例のフローチャート工程の間隔の算出処理の一例のフローチャート管理頻度基準テーブルのデータ構成の一例を示す図部品重要度テーブルのデータ構成の一例を示す図調達先別部品別遅延率テーブルのデータ構成の一例を示す図部品別遅延率テーブルのデータ構成の一例を示す図工程完了報告の手段算出の情報項目と処理のデータ構造の例を示す図工程進捗報告日程の算出の情報項目と処理のデータ構造の例を示す図進捗管理報告参照・登録処理の一例フローチャート進捗管理報告参照・登録の情報項目と処理とデータ構造の例を示す図遅延時フォロー判定処理の一例のフローチャート工程完了報告の報告遅延判定処理、遅延度算出処理の一例のフローチャートフォロー判定の一例のフローチャートフォロー判定の情報項目と処理のデータ構造の例を示す図進捗管理基準メンテナンス処理の一例のフローチャート集計有効範囲の算出・部品別イベント別遅延率集計・蓄積処理の一例のフローチャート部品別イベント別管理頻度基準の決定・蓄積処理の一例のフローチャート STのメンテナンス判定処理の一例のフローチャート

符号の説明

１進捗管理システム、２案件マスタ、３稼動日マスタ、４調達先マスタ、５部品マスタ、６進捗管理基準、７進捗管理方法判定プログラム、８進捗管理計画、９調達先進捗報告システム、１０調達先参照プログラム、１１調達先登録プログラム、１２調達先端末、１３進捗管理実績、１４発注元参照プログラム、１５発注元端末、１６発注元登録プログラム、１７遅延時フォロー判定基準、１８遅延時フォロー判定プログラム、１９進捗管理基準メンテナンスプログラム

Claims

進捗管理手段に関する情報を表示する発注元端末とネットワークを介して通信可能に接続され、部品等の調達先の進捗状況を管理する進捗管理システムにおける進捗管理方法であって、
調達される部品の重要度と当該部品を識別する部品識別情報とを対応付けて部品重要度テーブルに格納し、
前記部品識別情報と、進捗管理報告を要求する時間間隔を算出するための係数である管理頻度基準とを対応付けて管理頻度基準テーブルに格納し、
新たに調達される部品の部品識別情報に対応する部品重要度及び管理頻度基準をそれぞれ前記部品重要度テーブル及び前記管理頻度基準テーブルから読み出し、
読み出した部品重要度及び管理頻度基準に基づいて進捗管理間隔を決定することを特徴とする進捗管理方法。
請求項１に記載した進捗管理方法であって、
前記進捗管理システムは、前記管理頻度基準テーブルに格納された管理頻度基準を、前記部品の納入が遅れた場合に変更することで、前記決定される進捗管理間隔を短くすることを特徴とする進捗管理方法。
請求項２記載の進捗管理方法であって、
前記管理頻度基準テーブルは、前記調達される部品の製造等の工程の完了を意味する工程完了イベントを識別するイベント識別情報を対応付けて更に格納し、
前記読み出した管理頻度基準は、新たに調達される部品の工程におけるイベントのイベント識別情報と前記調達される部品の部品識別情報とに対応する管理頻度基準であって、
前記進捗管理システムは、当該管理頻度基準と前記読み出した部品重要度に基づいて進捗管理間隔を決定することを特徴とする進捗管理方法。
請求項１記載の進捗管理方法であって、
前記進捗管理システムは、
前記調達先を識別する調達先識別情報と、当該調達先と発注元との関係の深さ等によって設定される信頼度情報とを対応付けて調達先信頼度テーブルに格納し、
前記部品識別情報と前記信頼度情報と進捗報告手段の情報を対応付けて工程完了報告手段テーブルに格納し、
進捗管理方法を決定する場合、前記調達先の調達先識別情報に対応する信頼度を前記調達先信頼度テーブルから読み出し、
前記調達される部品の部品識別情報及び前記読み出した信頼度情報に対応する工程完了報告手段情報を前記工程完了報告手段テーブルから読み出し、
読み出した工程完了報告手段情報を表示する画面に関する情報を前記発注元端末に送信することを特徴とする進捗管理方法。
進捗管理手段を表示する発注元端末とネットワークを介して通信可能に接続され、部品等の調達先の進捗状況を管理する進捗管理システムであって、
調達される部品の重要度と当該部品を識別する部品識別情報とを対応付けて格納する部品重要度テーブルと、
前記部品識別情報と、進捗管理報告を要求する時間間隔を算出するための係数である管理頻度基準とを対応付けて格納する管理頻度基準テーブルとを備え、
進捗管理間隔を算出される部品の部品識別情報に対応する部品重要度及び管理頻度基準をそれぞれ前記部品重要度テーブル及び前記管理頻度基準テーブルから読み出し、読み出した部品重要度及び管理頻度基準に基づいて進捗管理間隔を決定することを特徴とする進捗管理システム。
請求項５記載の進捗管理システムであって、
前記管理頻度基準テーブルは、前記調達される部品の工程の完了を意味する工程完了イベントを識別するイベント識別情報も対応付けて格納し、
前記管理頻度基準の読み出しにおいては、進捗管理間隔が算出される部品の工程におけるイベントのイベント識別情報と前記入力された部品識別情報に対応する管理頻度基準を読み出すことを特徴とする進捗管理システム。
請求項６に記載した進捗管理システムであって、
前記管理頻度基準テーブルに格納された管理頻度基準を、前記部品の納入が遅れた場合に変更することで、前記決定される進捗管理間隔を短くすることを特徴とする進捗管理システム。
請求項５記載の前記進捗管理システムは、
前記調達先を識別する調達先識別情報と、当該調達先と発注元との関係の深さ等によって設定される信頼度情報とを対応付けて格納する調達先信頼度テーブルと、
前記部品識別情報と前記信頼度情報と前記調達先における工程完了を知らせる手段に関する工程完了報告手段情報を対応付けて格納する工程完了報告手段テーブルとをさらに備え、
部品識別情報と調達先識別情報との入力を受け付け、入力された調達先識別情報に対応する信頼度を前記調達先信頼度テーブルから読み出し、入力された部品識別情報及び前記読み出した信頼度情報に対応する工程完了報告手段情報を前記工程完了報告手段テーブルから読み出し、読み出した工程完了報告手段情報を基づいて前記調達先における前記部品に係る工程の進捗管理をする特徴とする進捗管理システム。