
前回、RFI(Requet For Information)におけるベンダーコミュニケーションの注意点を取り上げました。上から目線の「情報くれくれ」では期待する結果を得られないばかりか、これから付き合っていくであろうベンダーからの信頼も失いかねないという話でした。今回はRFIの次にベンダーへ示すことになるRFPとその選定基準の作り方を取り上げます。ベンダーとの関係性構築の中で、最も重要な要素であるため、少しボリュームを増やして解説していきます。
RFPは、自社とベンダーの責任関係を決めるインプットになる文書
さて、自分たちがやりたいことを実現する参考情報は前回のRFIによって集めることができました。そして、集めた情報を基にして、ロングリストからショートリストの絞り込みができています。次にやることは、自分たちが提案してほしいことを具体的な内容で資料にまとめあげ、それをショートリストに名前が残っているベンダーへ送ることです。このとき、ベンダーへ送る資料のことを提案依頼書、またはRFP(Request For Proposal)と呼びます。
RFPはシステムの実装内容だけでなく、自社とベンダーの責任関係を決めるインプットになる文書であり、曖昧な表現や適切性に欠ける責任関係を記してしまえば、そのまま契約内容に跳ね返ってきます。私が知っているあるITシステム開発のプロジェクトでは、システム稼働後の責任範囲が曖昧だったために想定外の費用増をユーザー企業は強いられましたし、別のアウトソーシングプロジェクトでは、逆にユーザー企業が曖昧な契約を盾にしてベンダー側が大赤字になる程の要員追加を余儀なくされていました。
こうした痛みをユーザー側とベンダー側の双方が経験しなくても済むには、委託範囲をお互いがよく理解していなければなりません。また、何がベンダーからユーザーへ引き継がれ、どういった体制・スケジュールの下でそれが行われるかも明確にする必要があります。
その他、提案にあたってのルールを明記し、それらが提案依頼事項としてベンダーへ提示されているなら、あなたが期待した形でベンダーは提案することができるでしょう。
結論として、RFPには次のような章構成を含めましょう。
- 1章:委託範囲
- 2章:納品成果物
- 3章:体制・役割分担
- 4章:スケジュール
- 5章:前提条件
- 6章:応札要件
- 7章:費用
- 8章:提案手続き
サンプルとして、ITコーディネーター協会が発行する開発と運用保守RFPを参照すると良いかと思います。ベンダーはこのフォーマットに慣れ親しんでいますから、似たような形でRFPを示すことでベンダー側の提案負荷を減らすこともできますし、検討漏れを未然に防ぐことも期待できます。
■RFPドキュメント見本
開発編( http://www.itc.or.jp/foritc/useful/rfpsla/dlfiles/kaihaturfp_v10e.pdf )
運用保守編( http://www.itc.or.jp/foritc/useful/rfpsla/dlfiles/unyourfp_v10c.pdf )
ここからは各内容を見ていきます。
この記事は参考になりましたか?
- 超入門!ベンダー管理の基本連載記事一覧
-
- 調達時:工数費用の妥当性判断―「根拠なし」で値切っても費用は下がらない(第4回)
- 調達時:RFPとベンダー選定の基準作り―あいまいな基準から納得できる結論は出ない!(第3回...
- 調達時:RFIの出し方―「情報を出せ」では決してうまくいかない(第2回)
- この記事の著者
-
吉澤 準特(ヨシザワ ジュントク)
外資系コンサルティングファーム勤務。ビジネスからシステムまで幅広くコンサルティングを行う。専門分野はシステム運用改善をはじめとするインフラ領域だが、クライアントとの折衝経験も多く、ファシリテーションやコーチングにも造詣が深い。まぐまぐにてメールマガジン「IT業界の裏話」を発行中。著書に「最新会議運営...
※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です
この記事は参考になりましたか?
この記事をシェア