コラム

前回のコラムでは「海外拠点情報システム導入RFP（提案依頼書）」と題して、RFPサンプルを交えながら、日本本社の要件と海外拠点の要件の両方を上手に盛り込む必要性があることを説明しました。
海外拠点へのシステム導入の場合、どうしても日本本社と海外拠点の要件にギャップが出てしまいます。ギャップを解決するにあたり、その要件が本社の必須要件として「やるべきこと」なのか、現場の希望要件として「やりたいこと」なのか、オープンな議論を行い、お互いのことをきちんと理解し、重要性の判断をすることが必要だと理解していただけたかと思います。
今回のコラムでは、紆余曲折を経て作成したRFPに対し、システムベンダーから提出されてきた提案書を評価するポイントを説明します。

1次評価（書類審査）ステップ

システムベンダーにRFPを提出後、一般的な1次評価ステップとして、以下の手順で進めます。

(1)評価シートの作成
提案の評価では、各システムベンダーの提案書を横並びにして、比較をします。そのため同じ指標で見るために評価シートが必要になりますが、どの項目が重要で、どの項目が重要で無いのか、といった項目に対して重み付けをすることで、システムベンダー比較をした際に定量的に優劣を把握することができます。
この重み付けは必ずシステムベンダーからの提案書を受領する前に作成する必要があります。仮に提案書受領後に比較表を作成すると、各ベンダーからの提案内容を基に評価基準を作ってしまい、自分たちが本当に求めている重要な要件を正しく評価できず、最良のシステムベンダーの選択ができなくなる恐れがあります。
また、評価項目はRFPに基づいて作成することが重要です。
RFPに書かれていることが今回システムを導入する上で必要な要件となるので、その要件に合わせた提案を正しく評価する必要性があります。時々、営業活動を通じて自社の状況を良く知っているシステムベンダーがRFPに書かれていないことに対し、得意気に提案するケースがありますが、提案書を評価する上では余り意味がないことを評価する側も意識しておかなければなりません。

(2)システムベンダーとのRFP質疑応答
RFPは、提案を依頼する側が作成したものなので、システムベンダーから必ず色々な質問が来ます。RFP内に対応窓口と対応方法、質問のルールなどを記載（第四回の海外拠点情報システム導入RFP（提案依頼書）サンプル参照のこと）しますが、システムベンダーの中には、受注したいという気持ちが強すぎてルールを逸脱するシステムベンダーもいます。これは、導入プロジェクトが始まってからもルールを厳守しない可能性があるということを示唆させてしまい、マイナス評価に繋がります。 また、RFPに対するQ&Aは窓口を1つにし、そのやりとりがドキュメントとして残るようにします。窓口を1つにすることで、情報の拡散を防ぎ、他のシステムベンダーに対しても有益と考えた質問に関しては、公開することで重複質問を避け、RFPの内容をより理解してもらい、より良い提案をしてもらうための情報とすることができます。また、システムベンダーの中には、質問の内容が全く的外れであったり、全く質問してこないシステムベンダーもいます。そのようなベンダーの多くはRFPの読み込みが甘く、その後提出される提案書の内容は薄い場合が多くなります。このように、質問内容からもシステムベンダーの力量を評価することもできます。

(3)システムベンダーから提案書を受領する
RFPに記載した提案手続き・スケジュール（第四回の海外拠点情報システム導入RFP（提案依頼書）サンプル参照のこと）に合わせて、システムベンダーから提案書を受領します。 多くのシステムベンダーは最後まで提案内容を練り上げているので、期限間近に提出してきます。稀にスケジュールをオーバーして提出されるケースもありますが、ルール厳守という点においては、これもマイナス評価に繋がります。 提案書は社内で簡単に共有できるよう電子データで入手することをお勧めします。

(4)システムベンダーからの提案書をもとに1次評価（書類審査）、合否連絡
各システムベンダーから提案書が出そろった時点で評価をしていきます。 審査し、合否連絡というと、どうしても複数の中からいくつか落とさないといけないイメージがありますがそうではなく、1次評価（書類審査）では、RFPの読み込みを充分しているか、そのシステムベンダーの強みはどこなのかなどをピックアップして、なるべく次のステップ（デモンストレーション）で詳しく聞いてみたいポイントを探すことを意識し評価します。
この時点で、一番良いものを選定するということはしませんが、逆にRFPと提案内容にあまりにも乖離が大きい場合は1次評価で落とすケースもあります。
提案書は100ページを超えるものもあり、RFPを10社送り、10社から提案書が来た場合は、全体で1000ページを超えるケースも出てきます。
全てを読むことは非常に時間がかかりますが、概要図がイメージしているものに近い、なんとなくこの案でできそうといった曖昧な答えを出してしまうと、今までの苦労が水の泡となります。コストやスケジュールの確認はもちろんですが、最終的に必要な「要件機能一覧」（第四回の海外拠点情報システム導入RFP（提案依頼書）サンプル参照のこと）を満たしているかが非常に重要になってくるので、細部に渡るまで提出された提案書は全て読み込む必要があります。

提案書を読み込む際の注意点

前述の通り提案書は、提案依頼側の依頼要件をスムーズかつ正確に実現できるよう、各要件にマッチングした解決策が記載され、体制やスケジュールが信頼でき、コストも予算内に収まるものを目指して評価します。しかし、提案書の中には見た目が綺麗でパッと見、良く出来ていそうな提案書なのですが、読み込んでみると、中身が伴っていないものも多数あります。
以下に提案書を読み込む際に注意しなければならない点を記述します。

(1)要件に対する回答ではなく、自社のツールの特徴や方法論を強調する提案書
提案依頼した内容とは別（または提案書冒頭）に、膨大な紙面を使って自社のPRや主張を中心とした一方的提案内容が記載されている提案書は、要注意です。同じ条件で提案依頼した他システムベンダーと比較できないばかりか、このような提案姿勢は、今後、プロジェクトが開始された後も顧客要望とギャップが生まれ、円滑に進まない恐れがあります。

(2)抽象的な表現が多い提案書
機能要件に対して解決方法の記載がなかったり、曖昧な解決方法が記載されている場合は、要注意です。今後、プロジェクトが開始された後も、課題解決が曖昧になったり、先送りになる恐れがあります。最悪の場合、「動かないシステム」になってしまいます。

(3)提案書式が統一されておらず、体制において責任の所在が不明瞭になっている提案書
先にも記述しましたが、最近は業務内容が複雑化しており、システムベンダー1社体制の提案が少なくなっています。そのため複数社での合同提案が増えていますが、複数ベンダー間のコミュニケーションが不足することによる提案書式の不統一が見えたら要注意です。さすがに最近、明らかにバラバラの提案書を無理やり1つにしただけというものは見かけませんが、読み込んでいくうちに機能分担が重複していたり、データ連携の整合性がとれていなかったり、プロジェクト体制図を見ても、どこが中心となってプロジェクトを推進しているか不明瞭な提案書がまだまだあります。これら重複や不整合、体制の不明瞭点は、プロジェクトを推進する上で、大きな障害になってきます。

「提案書を読み込む際の注意点」として（1）から（3）を記述しましたが、逆にこれらをクリアしている提案書であれば、良い提案書ということになり、プロジェクトがうまく行く可能性が高いといえます。
提案書からプロジェクト進行を予測して、それらを道路を走る車に例えるならば、

(1)要件に対する回答ではなく、自社のツールの特徴や方法論を強調する提案書
　　　（⇔反対）顧客要件に対し、誠実かつ正確に回答する提案書
　　　（例えると）交通ルールを守り、安全運転ができる

(2)抽象的な表現が多い提案書
　　　（⇔反対）具体的に説得力のある解決方法が記載してある提案書
　　　（例えると）的確な判断ができ実行できるスキルや経験を持っている運転手がいる

(3)提案書式が統一されておらず、体制において責任の所在が不明瞭になっている提案書
　　　（⇔反対）役割分担及び責任の所在が明確なプロジェクトチームを提案している
　　　（例えると）エンジン、タイヤ、アクセル、ブレーキが適切な役割を持ち、
　　　　機能することによって的確に目的地に到着できる車（チーム）であるといえます

提案書が最初で、システム導入プロジェクト完了が最後、と考えた場合、最初のボタンを掛け間違えると、最後まで洋服を正しく着られない状態になり、プロジェクトは成功しません。ボリュームが多いからといいって、手抜きすることなく、「提案書を読み込む際の注意点」を確認しながら、最後まで根気よく提案書を読み込むことにより、目指していた目的地に安全に到着することができます。

次回は1次評価（書類審査）を通過した提案のプレゼンテーションとデモンストレーションを見て、最終的にシステムベンダーを1社に確定する進め方をご紹介します。

第6回コラム『プレゼンとデモを見て最終評価し、システムベンダーを1社に確定する』に続く