ベンダーとの確認手段は正しい？

事前検討の結果をベンダーに伝える方法として一般的に使われているのが「RFP」です。
RFPは「request for proposal」の略で、システムで実現して欲しい要求（request）を纏めておき、その内容に対して「提案（proposal）してください」とベンダーへ依頼するための資料です。

ベンダーは入手したRFPを元に提案書を作成し、どのようなシステムを提供するかプレゼンテーションしてくれます。

プレゼンテーションの内容は、完成するシステムのイメージからはじまりベンダー独自の提案、開発スケジュール、見積りなどで構成されます。

提案書の記載方法・内容・ボリュームはベンダーごとにいろいろです。
そして、この「RFP ⇔ 提案書」のやり取りを複数ベンダーと行う事で、ベンダーをコンペさせる事ができます。

簡単に言うと「ベンダーの力を使いシステムイメージを固め、ベンダー間で競合させる」という方法です。もちろんベンダー１社だけを相手にする場合にも要求を早い段階で伝える手段として有効です。

この作業での注意点は、「自社で作成したRFPの内容に対して、枝葉がついた提案書が返ってくる」という事です。
ということは、もしRFPに記載した要求に間違いがあった場合、間違いが拡大してしまう恐れがあるということになります。
例えば、システム化要求の中には全く現実味が無く、業務改善どころか業務改悪になるものも多くあります。
もしベンダーが親切であれば、業務改悪にならないよう正しい方向へ導きながら提案してくれる場合もあります。しかしコンペという状況下では、たとえ業務改悪につながるようなRFPであってもそれを指摘し辛いのがベンダー側の心情です。
ベンダーとしては発注者のRFPを否定して失注の危険を冒すよりも、豪華で見栄えの良い完成予想図を作り、とにかく発注者に気に入ってもらった方がよっぽど良いのです。

このような観点からも、しっかりとしたRFPを作る事は本当に大切です。

RFPを作る場合、「独自に作成する」か「コンサルタントと協力しながら作成する」かの2つの方法があります。

もしRFPを独自に作成しなければならない場合は、少なくとも書籍などで勉強をする必要があります。できればシステムに関する知識のある方を巻き込んだ方がいいでしょう。何故なら、システムの知識が少ない方が作成するRFPは要点がブレやすく、それを見たベンダーは「要求を予想しながら」提案を考えなければならなくなるからです。
そうなると各ベンダーが提案する機能や金額がバラバラになりコンペの意味が薄れてしまいます。
RFPの作り直しができればいいのですが、ベンダーにとって「要求を変更する発注者」は最も危険であり避けるべき存在です。ベンダーからの信用を失うと、その後の見積額を大幅にアップされてしまったり提案書の作成にも真剣な対応をしてもらえなくなります。RFPの大幅な追加・変更にはそれなりの損失が伴いますので注意が必要です。

また、RFPに対して作成された提案の機能内容や見積金額が妥当であるかどうか判断する場面にもシステム知識は重要です。
更に、もし各機能に対する見積金額が妥当であっても予算を超えている場合もあります。そのようなな時に発注者自ら代替手段や機能の取捨選択を逆提案できなければなりません。
それができない発注者は、仕様決定の段階から全てベンダーの言いなりになるしかなくなってしまいます。

不必要な高性能マシンを買わされたり、数分でできる運用作業に毎月数十万を請求されているケースをよく見るのですが、それらの大部分は発注者の知識不足につけこまれた結果です。

さて、このような話しを聞くと当然疑心暗鬼になりますが、とにかくベンダーは疑ってかかった方が良いのでしょうか？

もちろんそうではありません。知識無しにベンダーを疑う事は逆に問題があります。
疑い過ぎは無駄な確認作業に互いの時間や気力を消耗し、ベンダーからの付加サービスや積極的な提案を期待できなくなります。
誠実なベンダーであればあるほど、疑われるとモチベーションが下がるものです。結果として良いベンダーから敬遠され、お金だけが目当てのベンダーしか振り向いてくれなくなってしまいます。

これらを考えると、RFPの作成にはやはりシステム関連知識のある方を手配し、ベンダーと良い関係を築きつつ的確な交渉を行う事が重要だと言えます。

«PREVIOUS | TOP | NEXT»