システム導入を発注側から支援する株式会社インフィニットコンサルティング

COLUMN | コラム詳細

公開日 : 2019年9月19日
テーマ : 情シスコンサルタントの提言
第29話:立派すぎるRFPが失敗する本当の原因とは?

●しっかりと書かれたRFPがうまくいかない
「自分たちでRFPを作って進めたのですがうまくいかなくて・・・」
 
最近、このようなご相談が非常に増えています。
 
ユーザー企業内でもRFPが浸透していて、情シス部門・IT部門・業務部門が自分たちでRFPを作ります。
 
その後、ベンダーにRFPを提示するまでは順調に行きます。しかし、その後から問題が起きるようです。
 
「うまくいかなかったRFP」を拝見すると、実はどのRFPもびっくりするほど、しっかりと書かれています。
 
「プロのコンサルが書いたのですか?」
 
とつい、聞いてしまうほどです。
 
しかし、残念ながらRFPを見た瞬間にうまくいかない原因も分かってしまいます。
 
これらのRFPの共通点は何でしょうか?
 
 
●スクラッチ経験が豊富な人の落とし穴
システムの再構築の現場には、昔から黄金ルールがありました。
 
「As-Is(現状)」→「To-Be(あるべき姿)」
 
を作ること。
 
この考え方は正しいのですが、あるケースにおいては足を引っ張ることになります。
 
それはどんなケースでしょうか?
 
「パッケージによる業務標準化」
 
です。
 
パッケージ機能は、いろんな会社のベストプラクティスを集めて、汎用的な作りになっています。このパッケージに業務を合わせて(寄せて)、標準化を図る。実に合理的な手法です。
 
ところが、RFPで「To-Be」を作り込みすぎるとどうなるでしょうか?
 
パッケージに寄せるのではなく、自分たちが描いた「To-Be」に寄せてしまうのです。その後、次のような「失敗」が起きてしまいます。
 

<RFP失敗例>
① ベンダーの見積金額が数倍に跳ね上がる
② Fitするパッケージが見つからなくなる
③ ベンダーが次々と撤退する
④ 大手1社にロックオンされ、足元をみられる
⑤ 夢をみたユーザーが譲れなくなる
⑥ カスタマイズで障害が多発する
⑦ カスタマイズの保守費用が高騰する
⑧ 無駄にスクラッチに方針転換となる

 
作り込みすぎた「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は「パッケージ用」と「スクラッチ用」のどちらでしょうか?
 
 
*************
 
<関連コラム>
第22話:RFPの非機能要求は情シス/IT部門が合意に責任を持つ
 
第21話:RFPなど上流工程におけるIT部門/情シスの「受領資料を読まない病」を克服する
 
*************
 
⇒RFP作成支援サービスはこちら

★コラム更新情報をメールでお知らせします。ぜひこちらからご登録ください。
情シスコンサルタント 田村昇平
IT部門の育成・強化を専門とするコンサルタント。ITプロジェクトの企画から導入・保守までの全工程に精通し、そのノウハウを著書「システム発注から導入までを成功させる90の鉄則」(技術評論社)で公開している。

page top