(57)【要約】【課題】商品やサービスを取引する業者に対して、取引の意思決定を支援する方法を提供する。【解決手段】発注業者が提示する発注データに対して受注業者が提示する受注データについて、それらの評価指標を計算し、これを発注業者に対して提示する。また、受注業者が提示する受注データの見積もり内容が妥当であるか否かを判定し、その判定結果を業者に提示する。【選択図】  図３
2004326477.tif 000002
【特許請求の範囲】
【請求項１】
発注対象となるリソースの名称と当該リソースについて要求されるスペックとを有する発注データを格納する第一のテーブルと、前記発注データに対して受注業者の計算機から送信される受注データに含まれる故障率についての基準となる閾値を、前記リソースの名称と対応付けて格納する第二のテーブルとを保持する第一の計算機と、
前記第一の計算機と通信可能に接続され、前記発注データを格納する第三のテーブルと、前記発注データを識別する発注データ識別情報と当該発注データに対する前記受注データとを各々対応付けて格納する第四のテーブルとを保持する第二の計算機とを用いた取引支援方法であって、
前記第一の計算機は、前記発注データを、前記第二の計算機に送信し、
前記第二の計算機は、送信された前記発注データを、前記第三のテーブルに格納し、
前記第二の計算機は、前記発注データ識別情報と受注業者を識別する受注業者識別データと受注対象となるリソースの名称と当該リソースの販売価格と故障率とを有する受注データを受けつけ、当該受注データを、当該受注データに含まれる前記発注データ識別情報と対応付けて、前記第四のテーブルに格納し、
前記第二の計算機は、前記第四のテーブルに格納されている前記受注データ内、一の発注データ識別情報と対応付けられている受注データを前記第一の計算機に送信し、
前記第一の計算機は、送信された前記受注データに含まれる価格と故障率と性能とに基づいて当該受注データに対する評価を表す評価値を計算し、
前記第一の計算機は、前記受注データに含まれる前記リソースの名称と対応付けられて前記第二のテーブルに格納されている前記閾値を抽出し、
前記第一の計算機は、前記受注データに含まれる故障率が前記閾値よりも小さいか否か示す情報を、前記受注データに含まれる前記受注業者識別データ及び前記評価値と対応付けて表示することを特徴とする取引支援方法。
【請求項２】
発注対象となるリソースの名称と当該リソースについて要求されるスペックと当該リソースに対する受注申し込みの締め切り日時とを有する発注データを格納する第一のテーブルと、前記発注データに対して受注業者の計算機から送信される受注データに含まれる故障率についての基準となる閾値を、前記リソースの名称と対応付けて格納する第二のテーブルとを保持する第一の計算機と、前記第一の計算機と通信可能に接続され、前記発注データを格納する第三のテーブルを保持する第二の計算機とを用いた取引支援方法であって、
前記第一の計算機は、前記発注データを前記第二の計算機に送信し、
前記第二の計算機は、送信された前記発注データを、前記第三のテーブルに格納し、
前記第二の計算機は、受注業者を識別する受注業者識別データと受注対象となるリソースの名称と当該リソースの販売価格とスペックと故障率とを有する受注データを受けつけ、当該受注データを、前記第三のテーブルに格納されている発注データの内、当該受注データに含まれる前記リソース名称を含む一の発注データと対応付けて第四のテーブルに格納し、
前記第二の計算機は、前記一の発注データに含まれる前記締め切り日時が到来した場合に、前記一の発注データと対応付けられている前記受注データを前記第一の計算機に送信し、
前記第一の計算機は、送信された前記受注データに含まれる価格と故障率と性能とに基づいて当該受注データについての評価を表す評価値を計算し、
前記第一の計算機は、前記第二のテーブルから、送信された前記受注データに含まれるリソースの名称と対応付けられている前記閾値を抽出し、
前記第一の計算機は、送信された前記受注データの内から、抽出した前記閾値よりも大きな故障率を有する受注データを抽出し、
前記第一の計算機は、抽出した前記受注データの内から、当該受注データについて計算した前記評価値が最大である第一の受注データを抽出し、
前記第一の計算機は、送信された前記受注データの内から、前記第一の受注データについて計算された前記評価値よりも大きい評価値を有する第二の受注データを抽出し、
前記第一の計算機は、前記第二の受注データに含まれる前記受注業者識別データを前記第二の計算機に送信し、
前記第一の計算機は、前記第一の受注データと前記第二の受注データについての前記評価値を、当該各受注データに含まれる前記受注業者識別データと対応付けて表示することを特徴とする取引支援方法。
【請求項３】
発注対象となるリソースの名称と当該リソースについて要求されるスペックと当該リソースに対する受注申し込みの締め切り日時とを有する発注データを格納した第一のテーブルと前記発注データに対して受注業者の計算機から送信される受注データに含まれる故障率についての基準となる閾値を、前記リソースの名称と対応付けて格納する第二のテーブルと、発注を実行したリソースの名称と当該リソースの性能測定値を対応付けて管理する第五のテーブルと、前記各受注業者を識別する受注業者識別データと当該受注業者についての信頼度とを対応付けて格納する第六のテーブルとを保持する第一の計算機と、前記第一の計算機と通信可能に接続され、前記発注データを格納する第三のテーブルを保持する第二の計算機とを用いた取引支援方法であって、
前記第一の計算機は、前記発注データを前記第二の計算機に送信し、
前記第二の計算機は、送信された前記発注データを、前記第三のテーブルに格納し、
前記第二の計算機は、前記受注業者識別データと受注対象となるリソースの名称と当該リソースの販売価格とスペックと故障率とを有する受注データを受けつけ、当該受注データを、前記第三のテーブルに格納されている発注データの内、当該受注データに含まれる前記リソース名称を含む一の発注データと対応付けて第四のテーブルに格納し、
前記第二の計算機は、前記一の発注データに含まれる前記締め切り日時が到来した場合に、前記一の発注データと対応付けられている前記受注データを前記第一の計算機に送信し、
前記第一の計算機は、送信された前記受注データに含まれる価格と故障率と性能及び、前記受注データに含まれる前記受注業者識別データと対応付けられている前記信頼度とに基づいて当該受注データについての評価を表す評価値を計算し、前記第一の計算機は、計算した前記評価値を送信された前記受注データに含まれる前記リソースの名称及び前記受注業者識別データと対応付けて表示し、
前記第一の計算機は、対応付けられて表示された前記受注業者識別データ及び前記リソースの名称の内の一の受注業者識別データ及びリソースの名称を前記第五のテーブルに格納し、
前記第一の計算機は、前記第五のテーブルの内から、前記一のリソースの名称を抽出し、
前記第一の計算機は、前記一のリソースの名称と対応付けられている前記受注業者識別データを抽出し、抽出した前記受注業者識別データと対応付けられている前記信頼度を、前記一のリソースの名称と対応付けて前記第五のテーブルに格納されている前記性能測定値に基づいて変更することを特徴とする取引支援方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
発注業者と受注業者との間での商品やサービス等の取引を支援する方法、装置及びプログラムに関する。
【０００２】
【従来の技術】
発注者と受注者の間の取引きを支援するシステムとしては、従来、発注者から購入要求と見積もり要求を収集して受注者に情報提供し、それに対する受注者からの見積もり回答を収集して発注者に情報提供するということを繰り返すことにより、両者が歩み寄っていくことを支援することを特徴とする受発注取引き支援システムが提案されている（例えば、特許文献１参照。）。
【０００３】
【特許文献１】
特開２００２−７７６４号公報
【０００４】
【発明が解決しようとする課題】
従来の技術では、受注者と発注者の間で提示される情報を提供しあうことで、受発注の取引が円滑に行われることが可能とはなっているが、その発注内容が妥当なものであることかを検証した上で、発注内容を数値的に評価するものではなかった。本発明は、上記課題に鑑みてなされたものであり、発注業者、受注業者に対して、取引における有用な指標を提供することを目的とする。
【０００５】
【課題を解決するための手段】
上記課題を解決するため、本発明は、発注業者が提示する発注データに対して受注業者が提示する受注データについて、それらの評価指標を計算し、これを発注業者に対して提示する。また、受注業者が提示する受注データの見積もり内容が妥当であるか否かを判定し、その判定結果を業者に提示する。
【０００６】
【発明の実施の形態】
本発明の一実施例を、以下図面に従って説明する。
【０００７】
図１は本発明に係る取引支援システムの全体構成図である。
ネットワーク上には一又は複数の発注側サーバ（１０１）と一又は複数の受注側サーバ（１０２）が接続されており、双方からアクセス可能である場所に受発注データ管理サーバ（１０３）が存在する。ここで、各サーバは、ＵＮＩＸ（登録商標）等のＯＳで動作するパソコンやワークステーション等の計算機から構成されるものとする。また、図１では、受発注データ管理サーバは、発注側サーバと別の計算機として構成されているが、両者の機能を一つの計算機内にもたせる構成としてもよい。
【０００８】
受発注データ管理サーバにはＤＢ（１０４）が存在し、このＤＢには発注側から提供される発注内容に関する情報を格納した発注データ管理テーブル（１０５）と、受注側から提供される発注に対する見積もり回答に関する情報を格納した受注データ管理テーブル（１０６）が格納されている。ＤＢは、ハードディスク装置等により構成される。また、図１ではＤＢと発注側サーバは別筐体のものとして記載されているが、ＤＢは発注側サーバの計算機内にあってもよい。
【０００９】
また発注側サーバ（１０１）にはハードディスク装置等により構成され、発注内容の評価に関する情報を格納する評価ＤＢ（１０７）が存在し、評価ＤＢには発注内容を数値的に評価計算するために使用されるデータを格納した評価データテーブル（１０８）と、評価計算結果に関する情報を格納した評価結果格納テーブル（１０９）及び、発注を実行した発注対象毎に、当該発注対象の発注先等を対応付けて格納した発注先管理テーブル（１１０）が存在する。ここでも、ＤＢは受発注データ管理サーバ内にあるものとしてもよい。
【００１０】
図２は発注側サーバの内部の詳細構成図である。発注側サーバは、発注情報として、何のリソースをいつまでに必要かを記載した発注テーブルを、受発注データ管理サーバ内のＤＢに送信したり、発注の評価値を評価結果格納テーブルとして発注側サーバに接続された評価ＤＢに送信するデータ送信部（２０１）と、発注テーブルを見て受注側サーバから受注情報として何のリソースをどのような価格、品質で提供できるかを記載した受注テーブルや、発注側サーバに接続されている評価ＤＢに格納されている評価値計算用のデータが記載されている評価結果格納テーブルに関する情報を取得するデータ取得部（２０２）と、取得したデータを元にして、発注の評価値を数値的に計算する評価値計算部（２０３）と、発注したリソース内容で稼動が円滑に実施されているかを診断する発注状況診断部（２０４）と、評価値計算の結果や、発注状況診断の結果を画面に表示する画面表示部（２０５）から構成される。これらの、各部（評価値計算部等）の機能は、メモリ等に格納されたプログラムがＣＰＵなどの演算装置において実行されることにより実現されるものとすることができる。
【００１１】
次に、本発明に係る取引支援システムにおける処理の流れの概要を説明する。発注側サーバ（１０１）で、発注物、要求スペック等の発注依頼内容が決まると、図６の（１）に記載した形式で発注テーブルを作成する。発注テーブルの作成が完了すると、本テーブルは受発注データ管理サーバ（１０３）に送信される。受発注データ管理サーバでは、発注テーブルを受信すると、図６の（２）に記載した形式に発注テーブルを変換してＤＢ（１０４）に格納し（１０５）、通知先として記載された会社に対して、発注が実施されたことを通知する。ＤＢに格納された発注テーブルは受注側サーバ（１０２）から参照できる状態で格納される。ここで、通知先とは、図６の（１）の６０５の欄に登録されている業者のことをさす。このように、発注側が、発注データを通知すべき業者を指定できるようにすることで、従前の受注実績等に照らして特に望ましいと（発注側が）評価する業者に対しては、確実に当該発注がなされたことを了知せしめることが可能となる。通知先は、発注側が人手によって入力することにしてもよいし、図８の会社信頼度評価テーブルに基づいて信頼度が上位である数社を自動的に選択することとしてもよい。
【００１２】
受注側サーバでは受発注データ管理サーバのＤＢに格納された発注テーブルを参照し、図７の（１）に記載した形式で、提供できるリソースの情報を記載した受注テーブルを作成する。受注テーブルの作成が完了すると、本テーブルは受発注データ管理サーバに送信される。受発注データ管理サーバでは、受注テーブルを受信すると、図７の（２）に記載した形式に受注テーブルを変換してＤＢに格納する（１０６）。
【００１３】
受発注データ管理サーバでは、発注テーブルに記載された申し込み〆切り日になると、受注テーブルが格納されていることを発注側サーバに通知する。この通知は、申し込み〆切り日まで待たずに、受注側サーバから受注テーブルを受信するたびに発注側サーバに通知することとしてもよいし、申し込み〆切日までの任意のタイミングで通知することとしてもよい。この通知を受けると、（受発注データ管理サーバから未だ受注テーブルがおくられていない場合には）発注側サーバでは受発注データ管理サーバに格納された受注テーブルを取得し、発注評価値の計算を行う。なお、受注テーブルは、受発注データ管理サーバが発注側サーバに通知を行う際にこれと併せて送信することとしてもよい。発注評価値計算のフローチャートは図３に記載する。
【００１４】
発注評価値の計算が完了すると、発注側サーバでは評価結果を図９に記載した形式で評価結果格納テーブルとして格納し、発注者に対して図１１に記載した形式で発注先の候補となる受注業者を画面表示する。受注業者の画面表示を実施するフローチャートを図５に示す。
【００１５】
発注評価値に基づき発注先が決定されると、発注側サーバでは図１０に記載した形式で、発注物と発注先を管理する発注先管理テーブルが作成される。このテーブルを参照することにより、現在発注している運用中のシステムがあるかが判定され、ある場合には性能問題なく運用されているかが、発注側サーバの発注状況診断部により、定期的に診断される。発注状況診断のフローチャートは図４に記載する。
【００１６】
図３は発注評価値計算が実行される際の、発注側サーバにおける評価値計算部のフローチャートである。
発注評価値の計算が要求されると、発注側サーバの評価値計算部は受注テーブルのスペックの値をコストの値で除算することにより、単位コストを計算する（３０１）。
単位コストが極端に低い場合は、見積もりにミスがあることを懸念する必要があるため、単位コストを市場価格や既存の常識的数値からあらかじめ定めた閾値（図８（２）の８１６）と比較して（３０２）、閾値よりも小さい値である場合は、単位コストの再検討要否フラグを立て（３０３）、本情報に対する信憑性に関して注意を喚起する。
【００１７】
次に受発注データ管理サーバのＤＢに格納された受注テーブルの情報から得た故障率に関しても、単位コストと同様に極端に低い場合は、見積もりにミスがあることを懸念する必要があるため、故障率も既存の常識的数値からあらかじめ定めた閾値（図８（２）の８１７）と比較して（３０４）、閾値よりも小さい値である場合は、故障率の再検討要否フラグを立てる（３０５）。
【００１８】
この後、評価値を計算する（３０６）。評価値の計算式は、上記の「単位コスト」、「故障率」の他に、発注側サーバの評価ＤＢに格納された評価データテーブル内のデータである「会社信頼度」を含めた３つのパラメータに対する評価値を、同テーブルに格納された評価案分率を考慮して以下の計算式で計算する。なお、会社信頼度は図８（１）の会社信頼度評価テーブルで、評価按分率は図８（２）の発注情報テーブルで、単位コスト評価値、故障率評価値、会社信頼度評価値は、図９の評価値査定テーブルによって計算される。例えば、ＣＰＵについての単位コストが３２０である場合には、図９において、発注物（８２１）が“ＣＰＵ”、評価要因（８２２）が“単位コスト”に対応する列を参照し、単位コストの値が３００〜５００の評価値が３であることが判る。
【００１９】
Ｗ＝（単位コスト評価値）×（単位コスト評価按分率（図８（２）の８１２））
＋（故障率評価値）×（故障率評価按分率（図８（２）の８１３））
＋（会社信頼度評価値）×（会社信頼度評価按分率（図８（２）の８１４））最後に上記計算式によって計算した評価値と単位コスト、故障率に関する再検討要否フラグに関するデータを発注側サーバの評価ＤＢ中に評価結果格納テーブル（図１０）として格納する（３０７）。
【００２０】
次に図４のフローチャートを用いて、リソース発注後に、発注した内容で稼動が円滑に行われているかどうか発注状況診断が実施される時の処理を説明する。本フローチャートは、発注側サーバの発注状況診断部（図２の２０４）の処理フローを表す。
【００２１】
図１１は、発注したリソースについて、いずれの受注業者に発注したか等を管理する、発注先管理テーブルであり、発注側サーバのハードディスク装置等に保持されている（図１の１１０）。リソースの発注が実行された際に、当該リソースの名称（図１１の１００３）とその発注先である受注業者（図１１の１００４）とが対応付けられて、本テーブルに登録される。登録は、発注業者が人手で入力するものとしてもよいし、リソースの発注処理が発注側サーバにおける入力によってなされるような場合には、当該入力をうけつけたサーバが自動的に行うものとしてもよい。
【００２２】
発注状況診断部は発注物と発注先を管理するテーブルを参照して、発注依頼した運用中のシステムが存在するかどうかを判定し（４０１）、存在する場合には前回の発注状況診断時から閾値を超えた日数が経過しているかを判定する（４０２）。ここで、システムは、一又は複数のリソースの集合のことをいい、図１の注番（図１１の１００１）によって識別されるものとする。また、経過日数が閾値を越えたか否かの判定は、発注側サーバを構成する計算機上のＯＳ等により提供される日付機能から判る現在の日付と、前回測定日（図１１の１００８）とから計算される経過日数を予め定められた閾値と比較することによって行う事が出来る。（４０１）と（４０２）の判定結果が双方ともに真であった場合には、発注状況診断を実施する必要ありと判断する。
【００２３】
この場合、運用中のシステムの性能を、実際の運用システムでテストプログラムを実行することによって測定する。性能測定は、図１０に記載した発注側サーバのもつ発注先管理テーブルに記載された、依頼システム管理サーバ（１００２）によって行われるため、当該依頼システム管理サーバに対する性能測定依頼通知を送信する（４０３）。依頼システム管理サーバによって測定された性能測定値は発注側サーバに送信され、発注先管理テーブル（図１１）の性能測定値の欄（１００６）に登録される。性能測定値は、他のプログラムの稼動状況等、測定時の細かい環境により誤差が発生するため、性能測定値を目標性能値と比較する（４０４）。性能測定値が目標性能値を下回った場合は、性能問題が発生していることを受発注サーバに対して通知する（４０５）。
【００２４】
性能測定値が、性能目標値を何度も下回った場合は、提供先の図８（１）に記載した会社信頼度評価テーブルの値を小さいものに書き換える。また、目標性能を何度も上回った場合は、会社信頼度評価テーブルの値を大きいものに書き換える。この際、前回以前に測定した性能測定値が性能目標値を下回った（又は、上回った）回数等が、図１１の過去測定結果（１００７）に登録される。このように、発注対象（例えばリソース）を実際に使用してみた結果を、その発注対象の受注業者の信頼度に反映させることで、評価値の算出の際に用いる信頼度としてより適切な値を用いることが可能となる。
【００２５】
図５は発注評価値の計算結果に基づき、画面表示部（図２の２０５）が受注業者をＧＵＩ画面に表示する時のフローチャートである。
評価値計算部により作成された評価結果格納テーブルを参照することにより、評価値最大となったデータに単位コスト、および故障率の再検討フラグが立っているかが判別される（５０１）、再検討フラグが立っていない場合は、このデータを発注先候補としてＧＵＩ画面に表示する（５０４）。発注先候補表示画面の表示形式を図１２（１）に示す。このように、いずれの項目についても再検討要否が否である受注業者がある場合には、評価値の点においても、受注データの値が極端に低すぎないという意味で見積もりミスの懸念がないという点においても、良好な受注業者を発注業者に知らしめることが可能となる。
【００２６】
再検討フラグが立っている場合には、再検討フラグが立っていないデータの中で評価値が最大のものを算出し（５０２）、再検討フラグが立っているデータの中で、（５０２）で算出したデータの評価値よりも大きい評価値を有する受注業者を抽出し、抽出した各受注業者に対し、再検討フラグが立っている項目に関して再見積もり要求を出し（５０３）、評価値最大となったデータと、再見積もり要求を出したデータを発注先候補として画面に表示する（５０４）。
【００２７】
この画面の様子を図１２（２）に示す。図において、発注物はＣＰＵであり、当該発注物に対する受注データの内、再検討要否が“否”であり、かつ評価値が最大のものが、受注業者Ｚの受注データであることが示されている。また、Ｚの評価値よりも大きな評価値を有する発注先候補Ａ，Ｂ，Ｃについて、再検討要のフラグが立てられた項目について再見積もり依頼中であることが示されている。このように、いずれかの再検討要否フラグが要である発注先候補に対して、当該発注先候補が提示した受注データについての再見積もりの依頼を通知することにより、発注先候補である受注業者は自ら提示した受注データの内容の適否を再検討し、より適切な受注データを提示することが可能となる（これによって、受注できる機会を得やすくなる）。また、発注業者にとっては、見積もりミスが懸念される業者についても、再見積もりの機会を与えることによって、見積もりミスのないより妥当な受注データに対して発注する機会の確保が可能となる。また、再見積もり依頼を通知し、図１２（２）に表示する発注先候補として、再検討要否フラグが全ての項目について否である発注先候補よりも評価値が大きいものだけを選定することにより、再見積もり依頼の通知を伝達するネットワークに対する負荷の軽減を図ることが可能となり、また、発注業者が発注先として考慮すべき発注先候補についてのみ表示することが可能となる（図１２（２）の画面を表示する計算機の処理負荷の軽減と、当該画面を見ながら発注先を選別するユーザの利便性に資する。）。すなわち、再検討要否フラグが全ての項目について否である発注先候補（図１２（２）のＺ）の評価値よりも小さな評価値を有する発注先候補については、再見積もりを依頼して、受注データが別のものとなったとしても、Ｚの評価値よりも大きな評価値を有することになる可能性はないので、再見積もりを依頼するまでもない。他方、Ｚよりも大きな評価値を有する発注先候補については、再見積もりを依頼して新たな受注データが提示されることにより、再検討要否フラグが全て否で、かつ評価値がＺのそれよりも大きなものとなる可能性があるため、再見積もり依頼を通知することで、発注業者にとってより適切な発注先候補を獲得する機会の確保が可能となるものである。
【００２８】
図６は発注サーバと受発注データ管理サーバのＤＢに格納される発注テーブルである。
（１）は発注サーバ側に格納される発注テーブルであり、テーブルには注番（６０１）、発注物（６０２）、要求するスペック（６０３）、申込〆切（６０４）、発注が実施されたことを通知する通知先（６０５）が記載される。
（２）は受発注データ管理サーバ側に格納される発注テーブルであり、テーブルには項番（６１１）、発注物（６１２）、要求するスペック（６１３）、申込〆切（６１４）、発注が実施されたことを通知する通知先（６１５）、発注を実施した発注元会社（６１６）が記載される。本テーブルは受注側サーバから参照できる形で格納される。
【００２９】
図７は受注サーバと受発注データ管理サーバのＤＢに格納される受注テーブルである。
（１）は受注サーバ側に格納される受注テーブルであり、テーブルには注番（７０１）、提供物（７０２）、提供するスペック（７０３）、提供価格（７０４）、故障率（７０５）、提供する会社名（７０６）が記載される。
（２）は受発注データ管理サーバ側に格納される受注テーブルであり、テーブルには項番（７１１）、提供物（７１２）、提供するスペック（７１３）、提供価格（７１４）、故障率（７１５）、提供する会社名（７１６）が記載される。本テーブルのデータは、受発注データ管理サーバのＤＢに格納されている発注テーブルのデータに基づき、受注側として発注要求されているリソースに対する各項目の見積もり結果を記載する形式で、発注側サーバから参照できる形で格納される。
【００３０】
図８は発注側サーバの評価ＤＢに格納される評価データテーブルである。評価データテーブルは構成要素として、以下の（１）、（２）の２種類のテーブルを持っている。
（１）は各受注先会社名（８０１）とその会社の信頼度（８０２）を対応表にした会社信頼度評価テーブルである。
（２）は発注物（８１１）ごとに「単位コスト」（８１２）、「故障率」（８１３）、「会社信頼度」（８１４）の３つの評価項目に対して、どの評価項目を重要視して評価を決定するかを示す評価按分率（８１５）と、「単位コスト」に対して、既存の常識から考えて、異常値として判定する必要がある限界値を最小しきい値（８１６）として定義し、「故障率」に対して、既存の常識から考えて、異常値として判定する必要がある限界値を最小しきい値（８１７）として定義して対応表とした、発注情報テーブルである。
【００３１】
図９は発注物（８２１）の「単位コスト」「故障率」「会社信頼度」の３つの評価要因（８２２）に対する評価値（８２３）を査定する評価値査定テーブルである。
会社信頼度評価テーブル、発注情報テーブル、評価値査定テーブルに記載された数値は、図３で示されている発注評価値計算を行う際に使用される。
【００３２】
図１０は発注側サーバの評価ＤＢに格納される評価結果格納テーブルである。評価結果格納テーブルでは、受注先会社名（９０１）、発注物（９０２）に対して、図３で示したフローチャートに従って計算した「評価値」（９０３）、「単位コスト再検討要フラグの有無」（９０４）、「故障率再検討要フラグの有無」（９０５）が記載される。
発注者は本テーブルを発注先を決定する情報として活用する。単位コストに対しても、故障率に対しても再検討要フラグが立っていない場合は、評価値が高いものを発注先の候補として検討する。
単位コストまたは、故障率に対して再検討要のフラグが立っている場合に関しては、評価値が高くても発注先の候補として妥当であるかの再検討を実施する。
【００３３】
図１１は発注側サーバが現在発注しているシステムの、発注情報を管理するためにもつ、発注先管理テーブルである。
発注先管理テーブルには、注番（１００１）、発注依頼したシステムにおける、依頼システム管理サーバ名（１００２）、発注したリソース（１００３）、発注先（１００４）、システムの性能目標値（１００５）、性能の実際の測定値（１００６）、過去にシステム性能測定を実施したときの測定結果（１００７）、前回の測定日が記載される。
【００３４】
図１２は発注評価値の計算結果に基づき、発注先候補をＧＵＩ画面に表示するときの発注先候補表示画面の様子を表す図である。
図１２の（１）の画面には、発注対象であるＣＰＵ、発注先候補である会社名Ａ、Ａが提示した受注データについての評価値が表示される。
図１２（２）の発注先候補画面には、発注物（１１０１）、発注先の会社（１１０２）、発注の評価値（１１０３）、単位コスト検討要フラグ（１１０４）、故障率再検討要フラグ（１１０５）、再見積もり実施状況（１１０６）が記載される。
【００３５】
【発明の効果】
本発明によれば、発注者側が提示した発注データに対して、複数の受注業者が提示する見積もり結果を評価することにより、発注内容が妥当なものであるものかを検証した上で発注を実施することを可能とする。
【図面の簡単な説明】
【図１】リソース発注システムに対する本発明の全体の構成を示した図である。
【図２】発注側サーバの詳細な内部構成図である
【図３】発注評価値計算が実行される際の、発注側サーバにおける評価値計算部が行う処理のフローを示す図である。
【図４】リソース発注後に、発注状況診断が実施される際の、発注側サーバにおける発注状況診断部が行う処理のフローを示す図である。
【図５】発注評価値が計算された後、発注先候補をＧＵＩ画面に表示するときに画面表示部が行う処理のフローを示す図である。
【図６】発注サーバ、および受発注データ管理サーバのＤＢに格納される発注テーブルを示す図である。
【図７】受注サーバ、および受発注データ管理サーバのＤＢに格納される受注テーブルを示す図である。
【図８】発注側サーバの評価ＤＢに格納される評価データテーブルを示す図である。
【図９】発注側サーバの評価ＤＢに格納される評価データテーブルを示す図である。
【図１０】発注側サーバの評価ＤＢに格納される評価結果格納テーブルを示す図である。
【図１１】発注側サーバが、発注先を管理するためにもっている、発注先管理テーブルである。
【図１２】発注評価値の計算結果に基づき、発注先候補をＧＵＩ画面に表示するときの発注先候補画面表示テーブルである。
【図１】
2004326477.tif 000003
【図２】
2004326477.tif 000004
【図３】
2004326477.tif 000005
【図４】
2004326477.tif 000006
【図５】
2004326477.tif 000007
【図６】
2004326477.tif 000008
【図７】
2004326477.tif 000009
【図８】
2004326477.tif 000010
【図９】
2004326477.tif 000011
【図１０】
2004326477.tif 000012
【図１１】
2004326477.tif 000013
【図１２】
2004326477.tif 000014