RFI/RFPを書くということ
http://www.ekimae-it.com/maido/2006/03/rfirfp.html
2006/03/07
ITコーディネーターの活躍の結果なのか世間の潮流なのかわからないが、最近システムベンダーの立場で、RFP/RFI（提案依頼書、情報提供依頼書）を受け取って提案書を書く機会が増えた。複雑なシステムの場合には、RFPを受け取ったシステムベンダーから「このパートに、おたくの製品使えそうだから、そこのところを書いて欲しい」といった孫受け依頼や、「とりあえず名乗りは上げたんだけど、うちじゃできないので、考えてみて！」と丸投げのような依頼もある。
逆にお客様サイドに立って、RFP/RFIのような位置付けの資料を書いてベンダーに渡すことも増えた。
こういった資料は書くのに結構骨が折れる。システムの内容がわかっていたとしてもそれを文章に表現することはなかなか難しい。実際のシステム案件で書いたり読んだりしてゆかないと、書くセンスというか要領はなかなか身についてゆかないものである。他のシステム開発技術と同様に、RFP/RFIの作成技量というのも徐々にシビアになってゆくのだろう。
最近ちょっと困り者なのが、RFP/RFIを名目に、ノウハウを全部吐き出せと言わんばかりの無責任な提案依頼書だ。RFP/RFIを発行する最大の目的は、ユーザーニーズを書面にあらわして、複数のベンダーから意識のズレの少ない提案を貰うというところにある。次に、副次的な要素として、ユーザーが知らない画期的な手法や製品があった場合にそれを積極的に活用する為にベンダーに対して情報を求め、知見を得るという目的がある。
したがって、ユーザーニーズとベンダー各社が持つ技術や製品、ソリューションとのフィット＆ギャップを見るのが重要なはずなのだが、時折「あなたが持っているIT技術を使って、私たちのビジネスモデルをどう変えることができるのかを示してください」とか「そのシステムのデータベース設計図、スキーマ構造図、エンティティ設計書を出してください」などと堂々と依頼してRFP/RFIに出会うことがある。たいていは、どこかのシステムベンダー等がユーザーの代理で作成した資料だ。
こういうRFP/RFIを受け取ると、提案する側の私のテンションは一気に冷めてしまう。
ITコーディネータのプロセスガイドラインの中では、RFP/RFIの発行は、経営戦略・ビジネスモデルに関する社内コミットメントが済んだ後に、それを実現するための手法リサーチや協業ベンダーの発掘のために行うことになている。ところが、情報収集といいながらビジネスモデルの検証や有効性を問うというのはどういうことだろうか。
エンティティ設計書を提出して、はたしてそれを評価する人材がユーザーや、ユーザーの代理となっているシステムベンダーに居るのだろうか。もちろん居る場合もあるのだろうが、実際には少ない。短い時間の中で、そんな資料をしっかり理解する時間は無いはずだ。むしろ、システムベンダーからすれば知財の流出に他ならない。
提出した資料はユーザーの手に渡り、秘密保持契約を締結しているとはいえ、ユーザが関与している他のシステムベンダーが閲覧することは間違いない。
もちろん、こちらとしては仕事が欲しいから、できるだけの情報は提供しようと思うのだが、１週間とか１０日といった限られた提案時間の中で、大量の資料を提出させるのははたして意味があるのかと感じることがある。
もうひとつ、「腹立たしいRFP」がある。こちらは書かれていることにではなく、書かれていないことにである。その会社のIT経営の成熟度に関する情報が非常に少ないということがある。たとえば、導入後のサポートやシステム運用等について沢山記述するよう要請される場合があるのだが、ユーザーのIT経営成熟度がわからないと、なかなか提案しづらい場合がある。
たとえばRFPでも、ある程度ターゲット製品が予想されている場合、その製品と自社の開発要件との適合性を見る場合や、その製品の販売代理店として確かな力量があるのかを見極める場合のRFPと、世間にどんな製品があるのかを把握したい場合になげるRFPとは、書き方も変えてゆかなければならない。
後者の場合などは、運用体制や会社の情報化がどのように浸透しているのかがわからないと、提案は非常にブレたものになる。これが書きにくいというのであれば、いきなりRFPをどーんと発行するのではなく、数回にわたってRFIを発行し、消化できる程度の整理された情報を得つつ、競合各社の営業ともある程度仲良くなってゆきながら最終的にRFPを発行するようなやりかたも考えるべきであろう。
今は未だ世間にRFPを書きなれたエンジニアやアナリストは少ない。
多くのRFPに接する機会を持っているITコーディネータは、良いRFP、悪いRFPを世に問うてゆくのも責任の一部ではないかと感じている。
ITコーディネータ／太田垣博嗣
RFIとRFPの違い
http://blogs.itmedia.co.jp/knowledge/2009/06/rfirfp-8024.html
2009/06/05コンサルティング
ブログに書くイザ！newsingはてなブックマークlivedoor クリップBuzzurlBuzzurlTwitterでつぶやく
このところ提案書や企画書を書いたり、書かせたり、評価したりという仕事がいくつか続いている。その中で後輩からRFIとRFPの違いについて聞かれたのでそのときに自分なりに答えた事をここに整理しておく。
RFI（Requset For Informattion）とは、入札や調達の事前準備として、ベンダーに保有製品や提供可能なサービスの概要、あるいはその組合せや実績などの情報を提供してもらうための情報提供依頼書。したがってRFIへの回答は基本的にはできあいの製品カタログやパンフレット、事例集といったもので構成され、価格も精緻な見積もりではなく標準価格や参考価格。だからRFIの場合回答期限は１～２週間と短めになる。
そしてRFP（Requset For Proposal）は、ベンダーにシステムの提案を作成してもらうための提案依頼書。したがってRFPの場合は、提案の範囲や提案に骨子となる要件、そしてなによりも提案者が必ず守らないといけない項目は明確に定義されている。実は提案依頼書の場合、逆にベンダーから自由に提案して貰う部分は限定的になる。基本はやって欲しい事が明確にRFPに書かれていて、そのやり方とコスト等が回答としての提案書に記載されるという話になるはずだ。当然見積金額も精緻で正確なものが必要になる。
RFPの場合、提案書の提出を要求するからには、提出された提案書の評価ポイントも予め決めておく必要がある。必須項目の充足度が足きりになるのは当然として、提示価格と提案内容の質や加点項目の評価バランスをどうするかを決めておかないと出てきた提案を評価/選択出来なくなる。
RFIやRFPを扱うときはこういう違いをちゃんと理解しておこう。RFIなのに「正確な見積もりをください」とかRFPなのに「書いてある事は無視して自由に提案してください」というと相手に笑われてしまう。
RFPの場合は特に自由に提案して欲しい部分や項目はあらかじめ定義しておかないと、ベンダーの勝手な思いが入って出てくる内容がバラバラになる。質も内容もバラバラの提案書を集めて金額を含めた比較表を作ってもどうしようもない。
もしそうなりそうなときは、事前にRFIを発行しまず選択肢や仕様、要件の絞り込みを行うと良い。
===参考リンク
===関連しような過去記事
0 件のコメント:
コメントを投稿