2022
5/13
RFPを出した後
RFPを提示後は約2～3週間、「嵐の前の静けさ」となります。
RFPの作成や調整でバタバタしていたプロジェクトメンバーには、つかの間の休息が訪れます。いつも残業していたので早めに帰ったり、取れなかった休暇を取ったりするならこのタイミングです。この後、ベンダーから提案書が返ってきたら、その後はシステムをリリースするまで「ノンストップ」で忙しくなってしまうからです。
ただ、全くやることがないかといえば、そんな事はありません。
プロジェクトスケジュールは基本的に「タイト」です。この2～3週間を上手く使えるかどうかで、今後のプロジェクトに「ゆとり」を持たせることができるかが決まってきます。
この期間に何をやるべきでしょうか？
前述した「休息をとる」以外に、主に3つあります。
① ベンダーのQA対応
② 提案評価シートの作成
③ 社内BPR
① ベンダーのQA対応
RFPを発出する際に、合わせて白紙の「QA表」を渡しておきます。ベンダーが書き込めるように、エクセルのまま渡します。ベンダーは何か質問があったら、このQA表に記載して、メール等で受け取ります。
重要なのは「電話では受け付けない」ということです。電話にしてしまうと、ベンダーに与える情報に偏りが生じてしまうからです。伝えるべき情報は全てのベンダーに平等に伝え、提案条件を揃える必要があります。口頭だと、どうしてもニュアンスや文書化していない情報などが、そのベンダーにだけ伝わってしまいます。そのため、RFPにも明記していますが、基本的に「電話NG」を前提とします。
このベンダーへの回答スタンスは「2パターン」しかありません。
基本的には「RFPに記載の通りです。この前提で提案をお願いします」と具体的な回答を避けます。RFPには、あえてファジーに書いて、提案内容を限定させない目的もあります。
例えば、昔は「オンプレサーバーの構成はXXXでスペックはYYYで～」といった具体的な指定をしていました。しかし、今はクラウドの時代。システム構成も含めて提案してほしいのです。どこのクラウドサービスを使うかも指定しません。むしろ、そこから提案を求めているのです。
要求を具体的に指定しまうことで、ベンダーの「良さ」が消えてしまうことが何よりも怖い。ベンダーには想像力を働かせてもらい、ベンダーの「強み」をもった提案を求めるのが基本スタンスとなります。
一方で、RFPの「記載ミス」に対する指摘なら、それはもう全力で素早く修正します。そしてQA表の回答と共に、RFPの差し替え版を送付します。これは横展開し、問い合わせが来なかったベンダーにも送ります。
また、間違いではないですが「考慮漏れ」だったり「誤解されないための補足」が必要と判断した場合には、QAに回答し、その内容も横展開します。
ちなみに、ベンダーの回答状況によって、私はある程度の結果が読めるようになってきました。
経験上、まったく質問をしてこないベンダーが選ばれることは、まずありません。顧客に効果的な提案をするためには、RFPの読み込みが不可欠です。RFPはユーザーの要求は網羅していますが、ベンダーが知りたいことが100%書かれているわけではありません。必ず質問は発生します。RFPを読めば読むほど、確認したいことは出てきます。
事前に提案書のテンプレートがあったとしても、パラメーターを埋める必要があります。ある程度の予測はできたとしても、提案書の精度を上げるために「念のため確認」も含めて、必ず質問は発生します。
提案書のテンプレートは立派でも、顧客にアジャストできなければ、刺さらない提案書になります。その結果、選ばれなくなります。
では、質問が多ければ多いほど良いか？といわれると、そうでもないのが難しいところです。熱心な担当者がアピールとして多く質問をしてくるケースもあります。しかし、質問のレベルが低く、「これ聞く？」「いやいや、そこは考えてよ」「書かなくても分かるよね？」という内容だったりします。この場合も、選ばれる可能性はかなり低くなります。
じゃあ、当選するベンダーはどのような傾向か？
提案に慣れているので、無駄な質問はしてきません。提案書の矛盾をついた質問や、提案に必要なパラメーターをピンポイントに聞いてきます。数にして数件程度ですが、その質問センスに提案力の高さを感じてしまいます。
もちろん、評価は「提案内容」に対して行いますが、このようなベンダーの回答状況を見ながら進めていくと、プロジェクト内では盛り上がります。ベンダーの「理解度」や「提案姿勢」などをプロジェクトメンバーと意見交換するのは楽しいものです。ベンダーのQAを通じて、プロジェクト内の雰囲気を高めていきましょう。
② 提案評価シートの作成
RFPを出した時点で、ベンダー決定までのスケジュールは確定しています。
提案書を受け取ってから、評価シートを作っていては遅いのです。むりやりスケジュールを間に合わせたとしても、提案書の「読み込み」と「評価」に十分な時間を避けなくなります。
そのため、ベンダーから提案書がきた瞬間に評価に取りかかれるよう、この期間に準備をしておきます。
具体的には、RFPに連動した「提案評価シート」をこの時点で作ります。後からベンダーの提案書がきたら、すぐにコピー＆ペーストで完成させます。そして、すみやかにプロジェクト内に比較結果を展開し、評価にとりかかります。ここまでを最速で行うためには、段取りが重要です。
③ 社内BPR
RFPを完成させる過程で「課題一覧」が作られます。各関係者にヒアリングした中で出てきた課題が一覧化されており、それら課題に対する解決方法が検討されます。
この「課題一覧」を作ったことのある人は分かると思いますが、その解決方法の大半が「新システムで対応する」となります。現場では「現行システムで出来なくて困っている」という、目の前の課題を多く出してきます。そして、それらはRFPのシステム要求として検討していくことになります。これらの課題は、新システムで解決するので「塩漬け」にしておけばいい。
一方で、新システムとは関係のない軸での課題も上がっているはずです。
・FAXをなくしたい
・営業のトークスクリプトが整備されていない
・社員に配布しているパソコンのスペックが低すぎる
・イレギュラーに対する社内ルールが決まっていない
・特定顧客のイレギュラーな契約を見直したい
・紙で保管された書類を探すのに時間がかかる
・共有サーバーのフォルダ構成がグチャグチャ
・情報共有ルールが統一されていない（メール、チャット、掲示板等）
・業務体制や役割があいまいで特定の人に集中している
課題の大きさもピンキリですが、こういった「システム外」の課題は、いつでも着手できます。いつでも着手できてしまうから、実際はプロジェクトの忙しさにかまけて、後回しになりがちです。
一息ついている今こそ、「システム外」の課題を拾い上げ、集中的に対応していく絶好のチャンスです。
システム導入のプロジェクトにおいて、効果がでるのは当然ながら「システム導入後」です。しかし、こうした「システム外」の課題は取り組みさえすれば、すぐに効果が出せるものも多くあります。プロジェクトを社内的に認めてもらい、プロジェクトに「はずみ」をつける意味でも、まずは早期に効果を出したいところです。
プロジェクトマネージャーやPMOは、「課題一覧」から早期に効果が見込める課題にターゲットを絞っていきます。その課題解決で成果を出し、社内にアピールすべきです。
それが認められれば、今まで「聖域」として手が出せなかった大きな課題にも取り組みやすくなります。社内的な改革の機運が高まれば、システム導入における大きなBPRも実現性が高まってきます。
プロジェクトの成果が大きく変わってくる
RFPを出した後は少しリラックスした中で、休みをとりつつも、集中した濃い時間を過ごすこともできます。このタイミングで取り組んだことは、後で必ず効果が出てきます。
プロジェクトの遅延を防いだり、システムの品質が上がったり、業務改革で大きな成果を上げたり、そのための布石を打てるタイミングでもあります。後手に回るのではなく、先手を打つからこその成果といえます。
慢性的に忙しいプロジェクトにおいて、この時期は「緊急度の高いタスク」ではなく「重要度の高いタスク」をさばく、数少ないチャンスです。このチャンスを生かして、プロジェクトの成果を「最大化」できるかどうかは、プロジェクトマネージャーとPMOの姿勢にかかっています。
＊＊＊
（↓RFPの詳細説明はこちら↓）
RFPとは何か？
RFIとRFPの違いは？
RFPの5大メリット
RFPを提示する前にNDAを交わす
RFPを出した後に何をやるのか？
（↓RFPのサンプルはこちら↓）
RFP（提案依頼書）の目次の作り方（サンプル付き）
RFP（提案依頼書）とRFP別紙の作り方（サンプル画像付き）
（↓RFPに関するコラムはこちら↓）
RFPのジレンマ ～ 詳しく書きすぎると高額になる ～
RFP後のベンダー提案プレゼンで話しているのは誰？
なぜそのRFPはベンダー見積もりが10億円を超えてしまうのか？
立派すぎるRFPが失敗する本当の原因とは？
RFPの非機能要求は情シス／IT部門が合意に責任を持つ
RFPなど上流工程におけるIT部門／情シスの「受領資料を読まない病」を克服する
