ガートナー ジャパン
メインメニュー ホーム リサーチ コンサルティング ベンチマーク エグゼクティブ プログラム イベント 会社情報 メインメニュー
SAMPLE RESEARCH

サンプル・リサーチ

IT調達の最適化:提案評価とベンダーの決定

ITマネジメント (ITM)/ITM-14-03
Research Note
E. Matsubara, S. Yamanoi
掲載日:2014年8月5日/発行日:2014年1月31日

本リサーチ分析レポートのテーマに関心をお持ちの方は、2014年10月28日(火)〜30日(木)に開催する 「Gartner Symposium/ITxpo 2014」 のページを是非ご覧ください。(イベント終了後も開催実績としてご覧いただけます)


IT調達における提案評価とその結果に基づくベンダーの決定は、IT調達の中でも特に難しいプロセスである。これは、通常のIT部門の業務にはない、社内の幅広い関係者の利害を調整するという能力が求められるからである。本リサーチノートでは、IT部門内の調達担当組織が留意すべき、本プロセスに関するベスト・プラクティスを紹介する。



要約

主要な課題

  • 提案書の評価は、社内の関係者の利害が対立する要因を内包しており、評価期間の延長や、関係者の感情的な対立が残るといった恐れがある。
  • IT調達の成熟度を上げないと、発注側に不利な条件をのまざるを得なくなったり、不適切なベンダーを選んだ結果として、開発や運用といった実施工程でトラブルが発生したりする原因となる。
  • どの要件を必須要件とし、どのように希望要件の重み付けをするかを決めないまま提案書の評価に入ると、社内の関係者の利害調整が困難になる。

推奨事項

  • ベンダー選定チームは、IT部門内の調達担当組織を事務局とし、開発プロジェクト・チーム、ユーザー部門、運用部門、全社調達部門、法務部門などからのメンバーで構成する。
  • 社内の関係者の利害を調整するために、必須要件と希望要件の重み付けの決定は提案要請書(RFP)の作成と並行して開始し、少なくともベンダーから提案書を受領する前に、完成させる。
  • 各ベンダーからの提案書は、全体で非常に大きなボリュームになるが、IT部門内の調達担当組織は、全体を把握するために、提出された提案書をすべて読む。
  • 各提案の評価に当たっては、まず必須要件の評価を行い、提案段階でできないと回答している項目があるベンダーを選定対象から外し、残ったベンダーについて必須要件の吟味と希望要件の評価を実施する。
  • 必須要件の評価においては、提案書に書かれた「やります」「できます」をうのみにせず、その根拠を提示させて判断し、判断理由を記録しておく。
  • 必須要件を満足しないと判断したベンダーを外し、希望要件評価の点数が高いベンダーを2〜3社に絞り、最終的なベンダー選定のための最後の交渉を行う。
  • 希望要件評価の点数が低い候補ベンダーの費用が最も安い場合は、最終的なベンダーの決定において、社内関係者の合意形成に注力する。


目次


はじめに


分析

  1. 評価表の作成
    • 必須要件評価項目の決定と、希望要件評価項目の重み付けは、
      提案書と見積もりを受領する前に行う
    • 評価項目はRFPに基づいて作成する
    • 必須項目の決定は、ビジネス上の要件と結び付ける
    • 希望要件の重み付けの決定は、システムの実利用の状況を配慮して行う
  2. 提案内容の確認
    • 提案書のレビューにおいて、IT部門内の調達担当組織は、
      提出された提案書をすべて読む必要がある
    • 提案に対するQ&Aは、窓口を1つにし、やりとりが書面で残るようにする
    • 提案説明会では、実際にプロジェクトを担当するプロジェクト・
      マネージャーに話をさせる
  3. 評価の実施
    • 必須要件の評価では、提案書の内容に対する判断が求められる
    • 希望要件の評価では、絶対評価と相対評価を適切に使い分ける
  4. ベンダーの決定
    • ベンダーを絞った後の交渉は、契約条件獲得の最終チャンスとして活用する
    • 価格交渉も、契約交渉と並行して実施する
    • 最終的なベンダーの決定においては、社内関係者の合意形成に注力する

推奨リサーチ

 

はじめに

IT調達プロセスの全体像については、「IT調達の最適化:調達プロセスのステップと体制の整理」(ITM-13-07、2013年2月25日付)で説明している。本リサーチノートでは、IT調達において最も重要なプロセスである、候補ベンダーに対してRFPを送付してから提案書を受領し、ベンダーを決定するまでを説明する。IT部門内の調達担当組織は、このプロセスの各ステップに習熟し、実行能力を高めて最適な調達がでるようにすべきである。提案評価の細かいステップとしては、評価表の作成、提案内容の確認、評価の実施、ベンダーの決定がある。以下、順に各ステップにおけるベスト・プラクティスを解説する。


分析

1. 評価表の作成

提案の評価では、ベンダー各社の提案を評価表に従って評価する。評価表でどの項目を必須要件とし、希望要件の重み付けをどのようにするかは、ベンダー選定において、極めて重要である。

必須要件評価項目の決定と、希望要件評価項目の重み付けは、提案書と見積もりを受領する前に行う

提案の評価においては、見積価格が最も安くても、その項目を満足していなければ提案者を選定対象から外すという必須要件の決定は重要である。なぜならば、これによって社内の関係者の利害が異なることが鮮明になるからである。例えば、開発プロジェクト・チームは見積価格が高くても安心な既存ベンダーを好むのに対し、全社の調達部門はとにかく価格の安いベンダーを好むというように、社 内の関係者の利害は異なる。したがって、各ベンダーの提案書と見積価格を見てからこの利害調整を行い、評価項目の決定と重み付けをすることは大変難しくなる。

推奨事項:

社内の関係者の利害を調整するために、評価項目と重み付けの決定はRFPの作成と並行して開始し、少なくともベンダーから提案書を受領する前に、完成させる。

評価項目はRFPに基づいて作成する

ベンダーの提案は、ユーザー企業が送付したRFPとその後のQ&Aに基づいて作成される。したがって、評価項目はRFPに記載された要件から抜き出して作成できるはずである。もちろん、現行システムの機能強化や更新の場合、現行システムの保守を委託しているベンダーはRFP以上の情報を持っているが、それ以外のベンダーが提案に必要な情報はRFPに盛り込んである。したがって、RFPに記載されていない項目は、評価項目として出てこないはずである。なお、RFP送付とその後のQ&Aについては、「IT 調達の最適化:RFP作成における7つの留意点」(ITM-13-08、2013年2月25日付) を参照されたい。

推奨事項:

評価項目は、RFPの要件から抜き出して作成する。この過程で、RFPに記載のない項目が必要なことが分かった場合は、RFPに対するQ&Aの中で、ベンダーに対して要件の追加を行うべきである。

必須項目の決定は、ビジネス上の要件と結び付ける

前述のように、必須項目として何を取り上げるかは、社内の関係者の利害が鮮明になるポイントなので、合意形成が非常に難しい。こういった場合は原点に立ち返って、発注者側として各評価項目が、どのビジネス上の要件とつながりがあるかを考える。つまり、その項目が実現できなかった場合、ビジネス上大きな悪影響を受けるものを必須要件とすることで、関係者のコンセンサスを得る。例えば、2014年4月からの消費税増税への対応であれば、4月1日に間に合うようにシステムが完成するのは、企業としてのコンプライアンスの点から必須要件である。あるいは、業務改革の目玉となる販売管理のある機能について、それがなければ業務改革の目的が達成されないのであれば、その機能の実現は必須要件である。一方、既存システムの更改の場合、現行システムのすべての機能の実現を無条件に必須要件とせずに、将来の業務プロセスに基づいて必要な機能の確認をすべきである。

推奨事項:

各評価項目について、その項目が実現できなかった場合にビジネスに与えるインパクトを考える。実現できないとそのIT調達にかかるプロジェクトの目的が達成できなくなる場合、その項目を必須要件とする。一般的には、スケジュールの遵守、中核機能の実装、性能要件、発注側で必要な作業量やスキル、契約類型などが必須要件となる。

希望要件の重み付けの決定は、システムの実利用の状況を配慮して行う

必須要件を満足した提案については、各希望要件の評価を行う。希望要件の評価項目は、RFPの要件から取りまとめ、必須要件とした項目も含めて決定する。必須要件の評価がその要件を満足するか否かの〇×評価であるのに対し、希望要件の評価では、満足度のレベルとその評価項目の重みを掛けて点数を算出する。レベルについては、1〜5のように細かくし過ぎると、評価自体が難しくなる。

推奨事項:

希望要件評価のレベル分けは、3段階程度にとどめ、レベル判断を容易にしておく。また、希望要件の重み付けは、システムの実利用において、その項目に関係する状況の発生頻度や、関係する業務に対する影響を考慮して決定する。例えば、年に1度しか発生しないような例外処理であれば、その重み付けは小さくする。


2. 提案内容の確認

ベンダー選定チームは、IT部門内の調達担当組織を事務局とし、開発プロジェクト・チーム、ユーザー部門、運用部門、全社調達部門、法務部門などからのメンバーで構成する。このチームで、提案の内容を確認し、その評価を行う。

提案書のレビューにおいて、IT部門内の調達担当組織は、提出された提案書をすべて読む必要がある

各ベンダーからの提案書は、調達案件の規模にもよるが、数百ページにも及ぶ場合がある。そして、RFPを5社に送付していれば、全体で1,000ページを超える場合もある。したがって、各社の提案書の性能面については開発プロジェクト・チームがレビューするといったように、評価項目のグループごとに、各社の提案を分担して横断的にレビューを実施することになる。このときに、提案書評価での漏れや勘違いをなくすためには、各項目について複数の視点でレビューすることも必要である。一方、各社の提案を全体的に評価するためには、提案の全体に目を通す人間も必要である。

推奨事項:

各ベンダーからの提案書は、非常に大きなボリュームになるが、IT部門内の調達担当組織は、全体を把握するために、提出された提案書をすべて読む。

提案に対するQ&Aは、窓口を1つにし、やりとりが書面で残るようにする

提案書のレビュー開始から、ベンダー選定の終了までの間、選定候補ベンダーとの間で、提案内容の確認方法を確立する必要がある。これは、選定チーム内の異なる要員からベンダーに類似の質問がに出されたり、選定側の意図が間違って取られたりするのを防ぐことが重要なためである。また、提案の評価における回答内容は、契約書や仕様書に反映する必要があるので、やりとりを漏れなく記録し、後で契約書や仕様書とチェックできるようにしておくべきである。

推奨事項:

提案に対するQ&Aでは、その窓口をIT部門内の調達担当組織に置き、すべてのQ&Aは必ずここを通してやりとりする。また、窓口の要員は質問を出す前に内容を確認し、前に出した質問と重複していないか、内容が矛盾していないかのチェックを行う。また、Q&Aのやりとりは必ず文書(電子メールを含む)で行い、やりとりが書面で残るようにする。

提案説明会では、実際にプロジェクトを担当するプロジェクト・マネージャーに話をさせる

同じような提案書であっても、実際に担当するプロジェクト・マネージャーの力量によって、プロジェクトの成功と失敗が分かれるのは、開発でも運用でも同じである。このプロジェクト・マネージャーの力量を評価するには、提案書に記載される過去の実績だけでは不十分で、対面での話し合いを加える必要がある。特に、こちらからの質問への対応を見ることで、適切な評価が可能となる。

推奨事項:

提案書のレビューがある程度終わった段階で、ベンダーごとの提案説明会を開催する。これは、各ベンダーで実際に担当するプロジェクト・マネージャーやリーダーの力量を評価する絶好の機会となる(「IT調達の最適化:調達プロセスのステップと体制の整理」ITM-13-07、2013年2月25日付参照)。したがって、提案説明会には、実際にプロジェクトを担当するプロジェクト・マネージャーやリーダーに必ず出席してもらい、その場で出た質問に対してどのような回答をするかにより、RFPで出した要件をどれだけ正確に理解しているか、これまでの実績としてどのようなプロジェクトを手掛けてきたか、プロジェクトにおけるリスクを認識しているかに関する重要な情報が得られる。また、提案説明会での質疑応答の内容は、提案に対するQ&Aの仕組みを使って書面で残るようにしておくことが重要である。


3. 評価の実施

各社からの提案の評価に当たっては、まず必須要件の評価を行い、提案段階でできないと回答している項目があるベンダーを選定対象から外し、残ったベンダーについて、必須要件の吟味と希望要件の評価を実施する。また、見積価格は、必須要件評価、希望要件評価にバイアスを与えないように、評価が終わった時点で開封する。

必須要件の評価では、提案書の内容に対する判断が求められる

スケジュールの遵守、中核機能の実装、性能要件、発注側で必要な作業分担、契約類型などの必須要件については、一般的に提案書では「やります」「できます」と書かれているものである。しかし、そう書かれているからといって実際にそのベンダーが「やれる」「できる」とは限らない。たとえ請負の契約類型でベンダー側に完成責任があったとしても、実際のプロジェクトでトラブルが発生した 際にその責任を問われるのはIT部門である。こうした状況を防ぐためには、ベンダーに対して「やります」「できます」と回答した根拠を提示させ、それを吟味する必要がある。例えば、スケジュールであれば、その期間を算定した根拠としてのプロジェクトの体制と、各作業工程の工数見積もりから、スケジュールの妥当性を判断する。そして、各提案の必須要件の評価について、その判断理由を取りまとめておく。

推奨事項:

必須要件の評価は、1つでも満足していない項目があれば、そのベンダーを対象から外すという強い条件なので、提案書に書かれた「やります」「できます」をうのみにせず、その根拠を提示させて判断し、判断理由を記録しておく。

希望要件の評価では、絶対評価と相対評価を適切に使い分ける

必須要件の評価が満足するか否かの〇×評価であるのに対し、希望要件の評価は1〜3の3段階評価となる。したがって必須要件では、例えば「90パーセンタイルのレスポンスタイムが3秒以内」というように、数値的な目標が明示される。一方、希望要件の評価では、例えば2.9秒以内は「1」、2.7秒以内は「2」、2.5秒以内は「3」のように数値の範囲を決めておく必要がある。さらに、ある機能の充足度といった評価項目は数値的な設定が難しいので、各社の提案を比較して相対評価を行う。

推奨事項:

希望要件の評価では、絶対評価としてあらかじめ数値の範囲を決定できる項目もあるが、そのほかの項目については、各社の提案を横並びに比較することで、相対的な評価を行う。そして、各希望要件項目の評価と重みを掛けた総得点を算出する。この場合も、必須要件の評価と同様に、各項目の評価の判断基準を記録しておく。


4. ベンダーの決定

必須要件を満足しないと判断したベンダーを外し、希望要件の評価の点数が高いベンダーを2〜3社に絞って、最終的なベンダー選定のための最後の交渉を行う。

ベンダーを絞った後の交渉は、契約条件獲得の最終チャンスとして活用する

選定対象から外れたベンダーに不採用を通知し、2〜3社に絞った対象ベンダーと、最後の交渉を開始する。一般的に、対象ベンダーは、この時点で最終選考に残ったことを分かっているので、営業担当者の当該案件を是非受注したいという意欲が非常に高まるタイミングである。これは、ユーザーとベンダーの交渉力の観点からすると、ユーザーの相対的な交渉力がピークになるタイミングである。こ のタイミングで行う契約交渉については、「IT調達の最適化:契約交渉における留意点」(ITM-13-09、2013年2月25日付)で詳しく解説しているので参照されたい。

推奨事項:

ユーザー企業がベンダーとの契約において自社に有利な条件を獲得するには、ベンダーに対する相対的な交渉力がピークとなるこのタイミングを活用する。特に、一般的に契約条項で問題になりがちな、損害賠償責任、著作権の帰属、瑕疵担保期間、保守対応期間といった条件については、契約書の文面ではなくとも、自社にとって有利な回答を文書で引き出しておく最後のチャンスである。

価格交渉も、契約交渉と並行して実施する

ユーザー企業として契約条件と並んで重要なのは、価格である。この価格には、ベンダーの見積書に提示される初期導入費用に加え、毎年の保守料等の費用をシステム・ライフ期間(最低でも5年間)に応じて加算する必要がある。さらに、ベンダーを決定する際には、ベンダーへの支払い価格に加えてその他の必要な費用も考慮する必要がある。例えば、アプリケーション再構築の案件では、採用するベンダーによって、自社に必要となる作業量に違いが生じる。これは、既存のアプリケーションの保守をしているベンダーに比べて、新規ベンダーに対してはユーザー企業側からの業務に関する説明が余計に必要となるからである。そのための作業量は、コストとして全体の費用に加算する必要がある。もちろん、この作業量がユーザー企業側から提供できる限度を超えていれば、必須要件を満たすことにはならないので、選定対象から除外されているはずである。

推奨事項:

上述したように、このタイミングはユーザー企業の相対的な交渉力のピークであり、候補ベンダーとしても、最も良い価格を提示するはずである。したがって、契約条件の交渉にある程度のめどがついた段階で、候補ベンダーに対して二次見積もりを依頼し、最終的なベンダー決定に進む。

最終的なベンダーの決定においては、社内関係者の合意形成に注力する

一般的に、最終的に2〜3社に絞った対象ベンダーは、必須要件をすべて満たしており、希望要件の評価でもそれなりの点数を獲得している。その上で、そのベンダーを採用した場合の費用を加味して、最終的にベンダーを決定する。希望要件の評価が最も高いベンダーの費用が最も安ければ簡単にそのベンダーに決定できるが、希望要件の評価が低いベンダーの費用が最も安いということも起きる。こ の場合、各提案の費用の差と希望要件評価の総得点を考慮して決定する。

推奨事項:

希望要件の評価が低い候補ベンダーの費用が最も安い場合は、最終的なベンダーの決定において、社内関係者の合意形成が大変難しくなる。これを突破するには、選定チーム内でオープンな議論を徹底的に行い、チーム内の合意形成を図り、その上でチーム・メンバーの出身組織に根回しをする。また、この段階になると、候補ベンダーがトップセールスをかけてくることも想定されるので、自社とベンダーの取引額も押えておく。

社内関係者の合意形成においては、希望要件評価の総得点の差と、そのベンダーを採用した場合の社内人件費を含めた総費用の比較を行う。このとき単に、「点差が何十点あるから」「総費用の差がいくら以内であったら総得点の高いベンダーを採用する」といった議論は、根拠が曖昧なため、いくら議論しても合意形成に至らない可能性が高い。有効な議論にするためには、希望要件の評価の点差が 大きい項目について、項目別にビジネス上のインパクトを議論する。例えば、A社とB社の提案は、双方とも納期の必須要件を満足しているが、これまでの実績や体制を考えると、A社の方がより確実であるといった場合に、両者における納期遅延発生率の差がどのくらいであり、発生した場合の自社に対するダメージが費用の差と比べてどの程度であるかについてを議論する。



推奨リサーチ

  • 「IT調達の最適化:調達プロセスのステップと体制の整理」(ITM-13-07、2013年2月25日付)
  • 「IT調達の最適化:RFP作成における7つの留意点」(ITM-13-08、2013年2月25日付)
  • 「IT調達の最適化:契約交渉における留意点」(ITM-13-09、2013年2月25日付)
  • 「アウトソーシング・アドバイザリ:ベンダー評価と選定フェーズのベスト・プラクティス」
    (SOR-13-17、2013年3月15日付)


ITM: ITM-14-03

※本レポートの無断転載を禁じます。

←INDEXに戻る

 

gartner.com
TOP OF PAGE
Copyright