ベンダー提案評価資料の構成

ベンダー提案評価は、多角的かつ総合的に評価し、透明性を確保することが重要です。そのためには、ドキュメント構成をしっかりと整え、社内に納得性のある説明ができるようなストーリーとしておく必要があります。

以下にその構成案を示します。

(構成)
評価項目と配点
提案評価(1-要求機能)
提案評価(2-費用)
提案評価(3-プロジェクト計画)
提案評価(4-実績)
提案評価(5-その他)
提案評価(評価サマリ)

(↓詳細解説はこちら↓)
【提案評価】定量評価と定性評価をどう使いこなしていけばよいか?
 
 

評価項目と配点 サンプル

まず最初に、ベンダー提案に対する「評価項目」を定義します。そして、それらの評価項目に対して「配点」を示します。

この配点は、プロジェクト毎に、システム毎に変わります。

パッケージ機能のFIT率が最も重要かもしれませんし、限りある予算の中で調達しなければいけないケースもあるでしょう。機能差がほとんどないサービスの場合は、実績が重要となるケースもあります。スクラッチ開発の場合は、プロジェクト計画がより重要性が高くなってくるでしょう。

プロジェクトとして、どの項目を重視するかを事前に社内で明確にしておき、それを配点に反映し、最初に宣言します。

(↓詳細解説はこちら↓)
【提案評価その1】要求機能が最重要

 
 

提案評価(1-要求機能) サンプル

ベンダー提案評価の中で最も重要となるのが、この「要求機能」の評価です。

どんなに安くても、どんなに実績があっても、自社が求めている機能がなければ、まったく意味がありません。選定における「前提」といっても差し支えないでしょう。

スクラッチ開発の場合は、ある程度はベンダーの力量に左右されますが、パッケージ導入の場合は、この機能が全てです。

下図のサンプルでは、自社の要求機能に対して、パッケージの「FIT率」をサブシステム毎に評価し、スコアを算出しています。

なお、この表は要求機能評価の「サマリ」であり、別紙として500項目以上の詳細な機能評価をサブシステム単位で積み上げた結果です。

(↓詳細解説はこちら↓)
【提案評価その1】要求機能のFIT率60%をどう考えるか?
 
 

提案評価(2-費用) サンプル

「無い袖は振れない」という言葉があります。

いくら立派なシステムであっても「予算」を大幅に超過する場合は、導入が不可能となってしまいます。費用は、自社のシステム予算に合っているかどうかのを判断する、重要な評価項目となります。

昔は「スクラッチ開発+オンプレミス」で、「初期費用」が膨大な金額となっていました。

ところが、近年は「パッケージ+クラウド」で初期費用がほとんどかからなくなっており、その分は運用、保守、ライセンス、利用料などの「維持費用」が発生する仕組みとなっています。

つまり、導入するシステムの特性により、お金が「最初」にかかるか「後」にかかるか、タイミングの違いだけとも言えます。

そのため、初期費用と維持費用をそれぞれ単独で判定しても意味がなく、それぞれに配点はつけません。初期費用と維持費用を含めた「5年トータル費用」の1項目のみに全てを配点します(年数はシステムの特性によってアレンジしてください)。

下図はパッケージ導入における5年トータル費用の評価サンプルです。

(↓詳細解説はこちら↓)
【提案評価その2】費用は5年トータルで考える

 
 

提案評価(3-プロジェクト計画) サンプル

スクラッチ開発、あるいはパッケージ導入であってもカスタマイズや移行が発生する場合に、プロジェクトの成否を左右するのが「プロジェクト計画」です。

このプロジェクト計画は、ベンダーの力量が如実に現れます。評価項目である「スケジュール」「開発手法」「移行計画」「プロジェクトマネージャー」「プロジェクト体制」「ユーザー教育」はどれも重要で、しっかりとした計画がないとプロジェクトが一気に傾くリスクとなります。

一方でプロジェクト計画の評価は、定量評価がしにくく、定性評価の代表的な項目といえます。その評価をどうスコアリングするか、評価の手腕が問われる項目ともいえます。

なお、プロジェクト計画は提案書の机上評価だけでは限界があるため、ベンダーのプレゼンの際に、対面にて詳細を確認して、評価を更新する必要があります。

(↓詳細解説はこちら↓)
【提案評価その4】プロジェクト計画の6つの評価項目とは?
【提案評価その4】プロジェクト計画「①スケジュール」をどう読み解くか?
【提案評価その4】プロジェクト計画「②開発手法」をどう読み解くか?
【提案評価その4】プロジェクト計画「③移行計画」をどう読み解くか?
【提案評価その4】プロジェクト計画「④プロジェクトマネージャー」をどう読み解くか?
【提案評価その4】プロジェクト計画「⑤プロジェクト体制」をどう読み解くか?
【提案評価その4】プロジェクト計画「⑥ユーザー教育」をどう読み解くか?

 
 

提案評価(4-実績) サンプル

ベンダーのシステムやサービスの「信頼性」を測るのが、「実績評価」です。

いくら安くて高機能であっても、実績がゼロであれば、その内容が疑わしいものとなります。他社でも成功している実績があるからこそ、安心してそのベンダーに任せることができます。

この実績については、「数」と「質」の両方が大事です。

実績が3社しかないのと1万社あるのでは、まったく信頼度が変わってきます。また、導入先が自社と全く異なる業界しかない実績よりも、自社と同じ業界で同じ規模の企業に導入している実績があれば、安心感も増してきます。

また、可能であれば既に導入している企業を紹介してもらい、その企業に実際に会いにいって話しを聞いてくることも有効です。

実績評価は、単純な評価項目ではありません。実績を掘り下げ、多角的に評価することで、ベンダーの信頼性をより正確に可視化することができます。

(↓詳細解説はこちら↓)
【提案評価その3】実績は数と質の両方をみる
ベンダー選定で決め手に欠く場合の最後の一手とは?

 
 

提案評価(5-その他) サンプル

上記の主な評価項目に含まれなかったものは、「その他」で評価していきます。

その他は、システムやプロジェクトの特性によって異なってきます。あまりにもニッチな業界のシステムであれば、ベンダーも小規模な企業が多くなるため、企業の規模や与信を評価する必要があるでしょう。もともと要求はしていなかった機能でも、魅力的な「付加価値」があるのであれば、ここに含めて評価に反映させることもできます。

なお、以前は「非機能要求」は主な評価項目でしたが、クラウドが主流になり、あまり差がつかなくなったため、現在はその他評価に含めることが多くなっています。しかし、社会的なインフラを担うシステムやECサイトのようにシステムの安定稼働が必須な場合は、その他に含めるのではなく独立した評価項目にすべきでしょう。

(↓詳細解説はこちら↓)
【提案評価その5】その他項目を評価し、バランスをとる

 
 

提案評価(評価サマリ) サンプル

最後に各評価項目のスコアを積み上げ、1ページに集約した「評価サマリ」を作成します。ここで、どのベンダーがもっとも良いのか、プロジェクトとしての「結論」を示します。

パッと見てどのベンダーが優れているのかが一目瞭然となるよう、わかりやすく表現することが重要です。

 
 

なお、実際の資料は、上記の基本形に対して、評価の裏付けとなるAppendix(参考ページ)を大量に追加します。経営層から質問がきた際、すぐにAppendixで示せれば、評価の信頼性が上がり、経営層も承認しやすくなります。

 
 

*****
 
 

(↓ベンダー評価・選定に関するコラムはこちら↓)
ベンダー選定のノウハウはどこに溜めるべきか
ベンダー選定におけるマルチベンダー提案は避けた方がよい?
ベンダー選定の手順を合理的にアレンジしていく
 
 

*****
 
 
※ 弊社で公開しているサンプルについては、基本的に画像のみの提供とさせていただいております。ファイルデータのダウンロードを可能とすると、内容の吟味をせずにそのまま流用し、トラブルに発展する可能性があるためです。画像データから文字起こしを行う過程で、それぞれのプロジェクトの状況に合わせてアレンジしていただければ幸いです。