前回(「第7回 RFIの作り方~製品情報を収集する千載一遇のチャンスを逃すな」)では、RFI(情報提供依頼)の目的と、作成にあたってのポイントを解説した。ベンダーの情報開示が十分とはいえないIT業界において、RFIは製品の様々な情報が入手できる千載一遇のチャンスであり、RFIに無償協力するベンダーに対して敬意を払いつつ、有効に活用すべきであると述べた。
今回は、RFP(提案依頼書)の重要性と作成のポイントについて解説する。なお、本連載における「製品」とは、IT製品のことであり、ハードウエア、パッケージソフトウエア、サービスなど、ベンダーから販売されているIT製品やサービス全般のことを指している。
RFPの真の目的は何か?
RFPが(Request for Proposal、提案依頼書)の略であることを知らないIT部門やベンダーは、まずいないだろう。製品ベンダーやインテグレーターは、ユーザー企業からのRFPに対する提案作成のために日々奔走していると言っても過言ではない。
メインフレームが主流だった時代には、RFPを使わずメインフレーム・ベンダーからの様々な提案をユーザー企業のIT部門が評価した上で、製品の採用可否を決定する例が多かった。だが、その後オープン化が進み、ベンダー(製品ベンダーのこと)やパートナー(SIer、NIer、販売代理店など)や製品の選択肢が急速に多様化したために、何らかの基準を設けて、複数の提案を客観的に評価することが必要になってきた。これが、RFPが広く認知され常用されるようになった背景である。
それでは、RFPを使うのはどのような場面だろうか?主なものを下に列挙する。
1.複数の候補から製品を選定するケース
2.複数の製品候補、および複数のパートナー候補による提案から、製品/パートナーの組み合わせを決定するケース
3.製品はRFIなどで既に選定済みであり、その製品を使ったシステム構築/運用を手がけるパートナーを選定するケース
4.製品候補も絞り込めておらず、複数のパートナー候補の提案から製品/パートナーの組み合わせを決定するケース
筆者は本コラムで、パートナーやベンダーの選定よりもテクノロジやアーキテクチャに基づく製品選定が重要であると述べてきた。その観点からは、ケース4は推奨できるものではないが、現実にはこのケースが最も多いだろう。