「システム導入に失敗しないための勘所」第6回です。
前回より、これから苦楽を共にするパートナーとして我々のシステム要求に応えてくれるベンダーを選定するフェーズの勘所についてお伝えしています。

前回は、ベンダーを価格だけで選ぶとなぜヤバいのか、をお伝えしました。ベンダーは依頼内容から構築ボリュームを見極めて、見積金額を算定します。そこで「他より安い」からといって安直に飛びついてはいけない、ベンダー側の見極めが甘いケースもある、というお話しでした。

では、見積金額の高低以外にどのような基準でベンダーを選定すればいいのか、どうベンダー選定を進めればよいのか。今回はこれらについてお伝えします。

　

　

飲食店でたまに「お任せで」とオーダーする人を見かけます。
代金がいくらになるのかわからないのに、なぜ「お任せ」にできるのか。それは「お任せにしても目玉が飛び出るような額にはならないはず」と顧客が思っているからでしょう。つまり顧客は、事前に店側がどれくらいのグレードの料理を提供するのか、それが自分の懐事情とフィットしているか、を判断してから入店しているわけです。
一方、店側は、初めての顧客からいきなり「お任せで」と言われると困ってしまいます。その人は何を好んで食べるのか、苦手なものはないのか、どれくらいのボリュームの料理を用意すればいいのか、などの情報がなければ、その人の期待値を満たす、あるいは超える料理を提供することはできません（メルマガ14号「成果を出せば相手を満足させられる、という幻想」参照）。
　
つまるところ「顧客のニーズとその対価について、事前に顧客と提供者が認識し納得していること」が前提になければ「お任せ」は成立しないのです。
　
ですから、これまで一緒に仕事をしたことのないベンダー、作ったことのないITシステムには「お任せ」は通用しません。前回も述べたように、ITシステムはテレビなどの既製品と異なり、見積依頼のタイミングでは必要なスペックが完全には決まっておらず、プロジェクトを通じて、顧客のニーズとパートナーのソリューションをすり合わせながら、スペックを詰めていくものだからです。飲食店でいえば、何軒かのお気に入りのお店の中から「一生に一度の結婚式パーティ」をする店を選び、その店のシェフと一緒に詳細を詰めていくようなイメージでしょうか。
こちらのニーズもろくに伝えもせず「（プロなんだから）お任せで」というなら、それはもはや「お任せ」ではなく「丸投げ」といえるでしょう。
　
ベンダー選定において「丸投げ」にしないためのアイテム、それが「提案依頼書（Request for Proposal、以下RFP）」です。RFPは簡単に言ってしまえば、ベンダーに対しITソリューションに係わる具体的な提案を依頼する文書です。

多くの場合、
　
　・ベンダーにRFPを提示する
　・ベンダーがRFPを見ながら提案書と見積書を作成する
　・ベンダーが顧客に対して、提案内容とパッケージデモをプレゼンする
　
という流れで顧客とベンダーがやり取りをします。
　
ケンブリッジが見る限り、多くのRFPが「丸投げ」状態になっています。
「ちゃんとRFPを投げてベンダー選定をしたが、システム導入で失敗した」とおっしゃるお客様に共通するのは、以下のようなポイントです。
　
　・自分たちのあるべき将来像がはっきりしていないのに、パッケージを決め打ちした。
　・とりあえずパッケージのデモを見て、何でもできると思って選んだ。
　・パッケージだけを評価し、ベンダーの力量を見極めなかった。
　
これらはすべて「丸投げRFP」を作ってしまったがための失敗といえるでしょう。
　
では、RFPに何が入っていれば「丸投げ」にならないのか。ケンブリッジでは、以下を必ずいれるべき、とお伝えしています。
　
　・会社としての経営課題
　・（経営課題を受けての）プロジェクトのビジョン、ゴール
　・（プロジェクトのゴールを達成する上での）将来の業務プロセス
　・（将来の業務プロセスをもとにした）将来のシステム機能要求
　　　・ファンクショナリティ・マトリクス
　　　・機能詳細記述書
　
見てお気づきの通り、これらは「業務改革の王道メソッド」として「必ず作るべし」とお伝えしてきたことばかりです。つまり、RFPはこれまでプロジェクトで検討してきたことのアウトプットの集大成といえます。

　

　

上記のような項目をRFPに盛り込むことで、以下のような効果が得られます。

　・変革の重要性や熱量を示せるため、ベンダーのやる気、覚悟を引き出すことができる。
　・RFPを受け取ったベンダーに「ちゃんと提案しないと太刀打ちできない」と思ってもらえることで、ベンダー選定の主導権を握ることができる。
　・ベンダーに機能の要否を精緻に伝えられる。ベンダーは、パッケージの標準機能として提供できるものと、追加開発が必要なものを切り分けできる。
　・将来の業務プロセスに基づいたパッケージデモを見ることができる。
　・ベンダーによっては、将来の業務プロセスを読み解いて「であれば、こういう機能が有効」とクールな提案を受けられる。
　・オプション機能をレコメンドされても、それが会社の将来に不要なものであれば、余計な買い物をせずに済む。
　・結果、各社横並びで見積比較することができ、選定結果に納得感が生まれる。

こうした効果を踏まえ、ケンブリッジが考えるベンダーの「あるべき選定基準」は以下のとおりです。

　・将来の機能要求を読み込み、適正かつ必要十分な見積価格を提示できるか
　・将来の業務プロセスを読み込み、こちらの期待を上回る提案をしてくれるか
　・こちらの意図を汲んだパッケージデモをしてくれるか
　・やる気、覚悟が感じられるか

これなら「丸投げRFP」に比べて、システム導入に失敗する確率がグッと下がりそうです。

その他、一般的に「RFPに入れるべき」とされる情報やドキュメントについては、ITコーディネータ協会が公開している見本等をご参照ください。

　

　

ケンブリッジが作成を支援するRFPは、文字通り「プロジェクトの血と汗の結晶」で、時として電話帳のようなボリュームになります。従って、ベンダーがきちんと中身を咀嚼してから提案書・見積書を作成できるよう、十分な検討期間を設ける必要があります。
　
検討期間を長引かせないコツとして、RFPをいきなり投げるのではなく、情報提供依頼（Reqest fo Information、以下RFI）を提示するのが有効です。ケンブリッジの組織・業務改革プロセスでいう「現状分析フェーズ」の後半、改善施策の抽出が完了した時点で、ベンダー選定方針を決め、改善施策に見合ったベンダーを調査してリスト化し、RFIを提示するのです。

　

RFIには、そこまでの検討経緯（経営課題、プロジェクトゴール、改善施策）を記載しましょう。これにより情報を先出しできますから、RFPを提示するベンダーについては検討期間を短縮することができます。
　
RFIでは、およそ以下のような項目について情報提供を依頼します。
　
　・ベンダーの企業情報
　・ソリューションに関する情報
　・標準機能概要、一覧
　・他社事例
　・パッケージのデモ
　・想定開発期間
　・概算見積り金額
　
RFI回答をもって、自分たちの身の丈に合いそうなベンダー数社に絞っていきます。