PR

RFP(提案依頼書)を受け取る際に、SIerが注意しなければいけない点は何だろうか。ひょっとしてRFPを額面通りに理解していないだろうか。うっかりしていると、RFP説明会の際にリカバリー不能の失敗に陥ってしまうかもしれない。今回はRFPを受け渡す際のユーザー企業のチェックポイントを解説する。

 前回はRFP(提案依頼書)を受領する前までになすべきことを書いたが、今回はRFP受領時での対応について注意すべき点、あるいは依頼側の顧客がチェックしているポイントについて述べていきたい。この連載では、ユーザー企業からのRFP提供やSIerによる提案書の提出などを一連の“業務プロセス”と見なす。そのプロセスをいくつかのフェーズに分けて解説していくが、前回の話は“商談の夜明け前”といえるステージ0の段階であり、今回はいよいよ本格的な商談がスタートするステージⅠでの注意点である(図1)。

図1●ステージ別に見た提案の“業務プロセス”
図1●ステージ別に見た提案の“業務プロセス”

RFPを額面通り受け取ってはいけない

 まず話の前提として、顧客側から出すRFPそのものの“品質”について触れておく。注意しなければならないことは、RFPは必ずしも網羅的に前提条件を社内で議論した結果が書かれているわけではないということだ。ユーザー企業の側にもさまざまな事情があって、RFPの作成に十分な時間を常に確保しているとは言い難い現実があるからだ。

 ユーザー企業の思惑も働く。そのRFPが個社単独のシステム化案件であり、それほど戦略性の無いシステム化案件であれば、記載されている要件・条件などは、かなり信ぴょう性が高い。逆に、戦略性が高くユーザー企業にとって経営戦略面で極めて重要な案件は、あえて業務仕様・前提条件をぼかして記述し、あいまいさを残しておくことで、SIerから質問を誘発させる仕掛けになっているものもある。いわば“落とし穴つきRFP”であり、質問内容などによってSIerを評価することが目的だ(図2)。

図2●RFPの“品質”によって対応を変える必要がある
図2●RFPの“品質”によって対応を変える必要がある
特にランクAのRFPは細心の注意が求められる

 経験の浅いSIerの営業担当者やSEは、RFPの記載内容を額面通りに理解しようとしたり、内容面で確認すべきような事柄について勝手に解釈したりして、顧客の意向とは180度異なるものを提案している場合が多い。こうした“勝手解釈”がうまく当たり、提案書の作成を省力化できて成約に結び付けば、これほどハッピーなことはない。しかし、そんな甘いRFPは無いと思っていた方がよい。なぜなら、ユーザー企業はRFP記載事項だけで、“満足の得る提案書”を受け取ろうなどとは、思ってもいないからだ。

 昨今、企業経営にはアカウンタビリティ(説明責任)が不可欠になってきたことより、情報システムにおいても提案の採用理由を明確にして透明性の高いものにすることが要請されている。RFPなど見たことも聞いたこともない時代なら、SIerの提案がそのまま採用されることがあったかもしれない。しかし、最近のシステムプロジェクトの承認・決裁プロセスにおいては、どのようなRFPを出して、どのような提案を受けて、どのように判断したか、そのことを経営レベルで把握し、説明することが求められている。

 このようにITガバナンスを厳しく問われる状況下では、ユーザー企業はRFPを戦術的に煮詰めて作成しているものなのだ。それゆえに「RFPには罠がある」とまではいかないまでも、「RFPには裏がある」程度の認識は持っておくべきである。そんな引っ掛けみたいなRFPは見たことがないと言うSIerの皆さんは、今まで“楽なお仕事”をしてきたのか、それとも惨めな結果となった理由がよく理解できなかったかのどちらかであると言ったら言い過ぎだろうか。