情報システム部門・IT部門が強くなるためのプラットフォーム

攻めの情シス研究所

情シスにノウハウを。
情シスが会社を強くします。

RFPのジレンマ ~ 詳しく書きすぎると高額になる ~

2020

6/02

RFPのジレンマ ~ 詳しく書きすぎると高額になる ~

ベンダーから高額の見積もりがきた

「RFPで細かく要求しすぎたのは失敗だったのでしょうか?」

ある情シスメンバーから相談を受けました。

基幹システムのリプレイスで、要求を細かく定義し、RFPとして提案したところ、各ベンダーから軒並み高額のカスタマイズ費用を提示されたそうです。

実は、RFP作成においては「超あるある話」で、特に販売管理パッケージの場合は、日常的に見られる光景です。

RFPでは、提案金額を抑えるために、細かく要求しない方が良いのでしょうか?

この状況をどう捉えるか

まず、RFPを書く上では、現行調査をしっかりと行うことが必要です。

なぜなら、現状をしっかり把握しないと、後になって考慮漏れが発覚するからです。特にシステム外でエクセル管理していたり、CSVファイルを手作業で他システムに取り込んでいたりする場合、システムだけを見ていると抜け落ちます。

また、現場のユーザーからは「細かく聞いてくれなかった」とシコリを残すことにもなります。現状の課題を伝えたくても、伝える場がなければ、プロジェクトに対して冷めてしまいます。

ユーザーと信頼関係を築き、現場をプロジェクトに巻き込む意味でも、しっかりとした現行調査のプロセスは重要です。

では、その調査結果をもとに、RFPで要求を細かく書きすぎるとどうなるでしょうか?

はい、ベンダーの提案金額が「ありえない程に高額」になります。パッケージがカスタマイズだらけになるからです。

だからといって、要求を概要だけにとどめて、細かく書かない方が良いのでしょうか?

いえ、そういうわけにもいきません。

細かい要求調整を後回しにすると、ベンダーと後のフェーズで「仕様変更」という扱いになります。そして結局は請求され、大きく揉めます(苦笑)

この時になると、ベンダーに吹っ掛けられても「ロックオン」されているため、ベンダーを変えることはできません。選定前ならば、競争原理が働き、吹っ掛けられることはありません。

よって、細かい要求整理は先か後か?

と聞かれれば、迷わず先となります。ベンダーを決める前に、細かい要求整理と、それにかかる金額を把握しておくべきです。その上で

高額提示を受けた後に、どう動くか?

ここが重要です。

単純に金額だけを見て切り捨ててしまうのか、RFPの書き方が間違っていたと非難するのか、プロジェクトを止めてしまうのか。

そうではありません。

これはチャンス!BPRをするチャンス!

と捉えるべきです。

「カスタマイズだらけ」ということは、それだけ市場パッケージにはない「独自のやり方」が多すぎる証拠でもあります。

社内だけでどれだけBPRをやろうとしても、小手先のムダを改善する程度しかできません。大きく変えようとしても、担当者に「絶対に必要」と言い張られてしまうと、誰も反論できないからです。

一方で、ベンダーからの「他社ではやっていない」という「外部評価」と、予算内に収めないといけないという「プロジェクト制約」を前面に出した方が、BPRは進めやすくなります。

内部で敵対せずに、外部に「共通の敵」を作れるからです。

カスタマイズ部分(GAPリスト)をテコにして、BPRを進める。そして細かい要求も加味して、最もFITするパッケージを選ぶ。

これがパッケージによる「標準化」を成功させるポイントになります。

ラストスパートが勝負を決する

冒頭の情シスメンバーは、GAPリストをもとに、次々と行動に移していきました。

・GAPの代替運用を検討し、要求を極限まで取り下げ
・ベンダーとカスタマイズ金額を減らす調整
・調整後に再見積もりをとり、再評価を実施

特に、ベンダー調整では「松竹梅の梅で金額を減らす」「不明点は質問攻め」「見積もりの内訳をしつこく確認」「ベンダーから削減案を出してもらう」等、あらゆる手をつくしました。これをベンダーの数だけやったので、その労力は凄まじいものでした。

その結果、予算は少しオーバーしたものの、経営層も納得する金額に収まることになりました。

「RFPの後の方がメチャクチャ忙しかった」

と情シスの方は振り返っていました。

RFPは、提案書をもらってからが本当の勝負です。

プレゼンまで指をくわえて待っているか、直前まで内部調整とベンダー交渉をやり切るのか。

RFP作成まで大変な労力がかかりますが、気を抜くのはもう少し後です。ベンダー決定までの最後のツメを誤ると、今までの苦労が台無しになってしまいます。

貴社の情報システム部門・IT部門は、ベンダーから提案書をもらった後に、どのように動いていますか?

関連コラム

御社のシステム発注は、なぜ「ベンダー選び」で失敗するのか

情シスコンサルタント
田村 昇平

情シス(IT部門、情報システム部門)を支援するコンサルタント。

支援した情シスは20社以上、プロジェクト数は60以上に及ぶ。ITベンダー側で10年、ユーザー企業側で13年のITプロジェクト経験を経て、情シスコンサルティング株式会社を設立。

多くの現場経験をもとに、プロジェクトの全工程を網羅した業界初のユーザー企業側ノウハウ集『システム発注から導入までを成功させる90の鉄則』を上梓、好評を得る。同書は多くの情シスで研修教材にもなっている。

また、プロジェクトの膨大な課題を悶絶しながらさばいていくうちに、失敗する原因は「上流工程」にあるとの結論にたどり着く。そのため、ベンダー選定までの上流工程のノウハウを編み出し『御社のシステム発注は、なぜ「ベンダー選び」で失敗するのか』を上梓し、情シスにインストールするようになる。

「情シスが会社を強くする」という信念のもと、情シスの現場を日々奔走している。

著書の詳細は、こちらをご覧ください。