第29話：立派すぎるRFPが失敗する本当の原因とは？

しっかりと書かれたRFPがうまくいかない

「自分たちでRFPを作って進めたのですがうまくいかなくて・・・」

最近、このようなご相談が非常に増えています。

ユーザー企業内でもRFPが浸透していて、情シス部門・IT部門・業務部門が自分たちでRFPを作ります。

その後、ベンダーにRFPを提示するまでは順調に行きます。しかし、その後から問題が起きるようです。

「うまくいかなかったRFP」を拝見すると、実はどのRFPもびっくりするほど、しっかりと書かれています。

「プロのコンサルが書いたのですか？」

とつい、聞いてしまうほどです。

しかし、残念ながらRFPを見た瞬間にうまくいかない原因も分かってしまいます。

これらのRFPの共通点は何でしょうか？

スクラッチ経験が豊富な人の落とし穴

システムの再構築の現場には、昔から黄金ルールがありました。

「As-Is（現状）」→「To-Be（あるべき姿）」

を作ること。

この考え方は正しいのですが、あるケースにおいては足を引っ張ることになります。

それはどんなケースでしょうか？

「パッケージによる業務標準化」

です。

パッケージ機能は、いろんな会社のベストプラクティスを集めて、汎用的な作りになっています。このパッケージに業務を合わせて（寄せて）、標準化を図る。実に合理的な手法です。

ところが、RFPで「To-Be」を作り込みすぎるとどうなるでしょうか？

パッケージに寄せるのではなく、自分たちが描いた「To-Be」に寄せてしまうのです。その後、次のような「失敗」が起きてしまいます。

作り込みすぎた「To-Be」はカスタマイズを呼び込み、パッケージの良さが消えてしまうのです。

では、パッケージ向けのRFPはどう作れば良いのでしょうか？

「As-Is」をしっかり定義する

ということです。その上で、「To-Be」は、

• 手作業でやっていること
• Excelでやっていること
• 転記していること

などをシステム化するぐらいに留めます。

言い換えると、業務内容は変わらず、「手」でやるか「システム」でやるかが変わるだけです。それ以上に「To-Be」を作り込むと、戻れなくなってしまいます。

例えば、業務フローの「To-Be」を細かく作ったとしても、選んだパッケージに合わせて、業務フローは作り直しになります。それならば、必ず修正が入る「To-Be」よりも、しっかりと「As-Is」を書きあげた方が最短距離で進めるのです。

時間をかけて、夢を語り合って、「To-Be」を作るのは大いに結構です。しかし、それがパッケージで実現できないと言われた時に、引っ込めることができるでしょうか？熱く夢を語っていたユーザーを説得できるのでしょうか？

その結果、「カスタマイズ」というカードを切ることになります。パッケージに詰まった「英知」を見ずに蓋をしてしまうのです。

これが、パッケージ導入における失敗の本質です。

RFPの書き方を使い分ける

「To-Be」には2つあります。

弊社では「スクラッチTo-Be」と「パッケージTo-Be」と呼んでいます。

「スクラッチTo-Be」では、従来通り、時間をかけて「あるべき姿」を議論してきます。

一方で「パッケージTo-Be」は、パッケージに業務を寄せた場合にどうBPR（業務改革）できるかを議論します。特に標準化が求められる基幹業務は、今までのやり方に固執せず、外部のやり方を積極的に取り入れる姿勢が求められます。

現在、貴社が作っているRFPは「パッケージ用」と「スクラッチ用」のどちらでしょうか？