コンサルタントの秘伝帖　「業務変革の王道メソッド」　第18回
「RFPだけでは足りないベストパートナー選びの勘所」

コンサルタントの秘伝帖
「業務変革の王道メソッド」
第18回
　

「RFPだけでは足りない
　ベストパートナー選びの勘所」
　
　
「システム導入に失敗しないための勘所」第7回、「ベンダー選定フェーズの勘所」の最終回です。
前回は、これからシステム構築の苦楽を共にするパートナーとなってくれそうなベンダーの見極め基準として「適正かつ必要十分な見積価格を提示できるか」「こちらの意図を汲んだパッケージデモをしてくれるか」「やる気、覚悟が感じられるか」などを重視すべき、そのためには「丸投げRFP」ではいけない、とお伝えしました。
　
今回は、提示したRFPに対して提案および見積をしてくれたベンダーの中から、どうすれば納得感を持ってパートナーを選定することができるのか、ケンブリッジがベンダー選定を支援する際に重視するポイントはどこなのか、をお伝えします。
　

1.点数をつけないと納得感は生まれない

　
納得感のある選定に欠かせないのは、ユーザーと作る定量的な評価基準です。
評価基準は「評価項目」と「点数配分」の2つから構成されます。点数配分とは、例えば100点満点でベンダーを評価するとして、それぞれの評価項目を何点満点にするのか、ということです。点数配分がうまくいかないと「ベンダーA社とB社は直感的に点数差が大きいはずだが、実際に評価してみるとあまり差がない」ということにもなりかねません。ですから、将来のシステムを使うユーザーと、自分たちの将来の姿をイメージしながら、どの項目を重点的に評価したいか、を議論し、点数配分を決めてゆきます。

以下は評価基準のサンプルです。
　
　
点数配分のコツとしては、まずベンダーの優劣をドラスティックに把握したい評価項目には多くの点数を配分します（通常は「機能の実現性」）。その上で、他の項目のどれを重視するか、を議論して決めます。例えば、マルチベンダーによる複数領域のシステム構築をビッグバン・アプローチで進めたい、というのであれば「導入アプローチ」を重要視しますし、自社の情報システム部の体制の厚みによって「運用保守コスト」の点数配分は変わるでしょう。

評価基準を決めるタイミングは、RFPを作成する前が望ましいです。
ベンダーの提案からバイアスを受ける前に、「自分たちが何を大事にしたいか」を言語化し、チーム内のコンセンサスを得ておくことは極めて重要です。また、RFP作成前に評価基準を決めておけば、ベンダー選定後に「あのベンダーを勝たせるために、恣意的にこの評価基準にしたのでは」のような「あらぬ疑い」をかけられる心配もありません。
RFPの具体的な中身が決まっていない中で評価の基準を作るのは難しいですが、後で直感と評点のずれをなくすために点数配分を微調整することはできますから、まずは「自分たちが何を大切にしたいか」を言語化して、評価基準のドラフトを作りましょう。

評価基準がまとまれば、ユーザーがベンダーを評価する際のスコアシートを作ります。以下は、そのサンプルです。
　

　

2.ベンダーPMに「こちらが見たいデモ」をやってもらえ

　
提案書を見るだけでは、なかなかスコアリングをやりきることはできません。例えば、実際のパッケージの使い勝手、質疑応答を通じたRFPへの理解度の高さ、安心してお任せできそうなプロジェクト・マネージャーか、などを確認するために、ユーザーとベンダーが直接対面するプレゼンやデモの機会を必ず設けましょう。ユーザーにはスコアシートを持ってその場に参加し、時間をおかずにベンダーを評価してもらいます。

特に現物（パッケージ）のデモは極めて重要です。RFPへの回答を見ただけでは、果たして本当に回答どおりのことができるのか、本当に「簡単にカスタマイズ可能」なのか、それはどういう画面で、どういうフローになるのか、容易にはイメージできないものです。
デモを成功させるために大事なことは、ベンダーがやりたいデモをするのではなく、発注者側が見たいデモを実施することです。
ベンダーに「パッケージのデモをやってください」とだけ伝えると、セールストークに長けた営業担当者から、そのパッケージの強み、特長だけがギッシリ詰まった「キラキラデモ」を見せられてしまいます。それだと選定のインプットになりませんし、ベンダー間の比較ができません。
ですからきちんと「発注者側が見たいデモ」をベンダーにあらかじめ伝える必要があります。そのために、RFP作成と並行してデモシナリオを作成します。ここで活躍するのが、メルマガ第13号でお伝えした「将来業務のプロセス」です。とはいえ全ての業務プロセスに対するデモを見ることはできませんから、自分たちの業務におけるメインプロセス、自社の特徴的なプロセス、今のシステムで苦労しているプロセスなど、重要な部分に絞ってシナリオを作りましょう。また、デモは、プロジェクト・マネージャーになる予定の方にしてもらいましょう。説明のわかりやすさ、質問への切り返し方などから、これから一緒にやっていけそうな人物か、を見極めることができます。
　
　
3.大切なのはパッケージではなくソリューション
　
かつてのシステム構築では、ひとつの重厚長大なパッケージを選定し、そのパッケージを担ぐベンダーに、自分たちの要求に合わせてカスタマイズやアドオンをするよう依頼する、という手法が主流でした。しかしこの手法は、しばしばベンダーに本来の得意領域ではない部分までお願いすることにつながり、その結果「本来やりたいことが実現できない」「実現するためにプロジェクトが遅延する」などの事態を引き起こしてきました。
しかし昨今、特定の領域でエッジの効いたSaaSが増えてきたこともあり、領域ごとにパッケージやベンダーを整理し補完しあうような組合せを検討することが可能になりました。様々な組合せを丁寧に読み解いていけば、こちらの要求事項をクールに満たせるようなソリューションを選び取ることができます。大切なのはパッケージではなくソリューションである、という考え方です。
　
　
例えば、上の図では、ソリューションの組合せのパターンはざっと考えるだけでも8通りあります。
　
(1) A社（パッケージA、一部スクラッチ開発）＋C社（パッケージC1）
(2) A社（パッケージA）＋C社（パッケージC1）＋B社（パッケージB2）
(3) A社（パッケージA）＋C社（パッケージC1、パッケージC2）
(4) A社（パッケージA）＋C社（パッケージC1）＋D社（パッケージD）
(5) B社（パッケージB1、パッケージB2）
(6) B社（パッケージB1）＋A社（スクラッチ開発）
(7) B社（パッケージB1）＋C社（パッケージC2）
(8) B社（パッケージB1）＋D社（パッケージD）
　
ベンダー1社で賄える(5)が一見よさそうに見えますが、機能要求に対するパッケージのFit率が低い場合は要注意です。逆に、機能要求に対するFit率が高いパッケージを組合せたマルチベンダー体制にするのであれば、プロジェクト全体に責任を負うプライムベンダーを置くのか、それとも自社で責任を負うのか、などをあらかじめはっきりさせておく必要があります。どのベンダーからも提案のなかった領域やタスク（データ移行タスクなど）が必須であるならば、各ベンダーへの再交渉や新規ベンダーへの声掛けも必要になるでしょう。
各ベンダーを定量的に評価しつつ、こうした様々な要因を整理して、考えうる組合せのパターンの中から、我々の要求に対するベストのソリューションを導き出す必要があることがお分かりでしょうか。
　
ケンブリッジも最近は、プロジェクトによっては（システム導入領域が広い、など）マルチベンダー体制になる可能性を考慮し、RFPプロセスを最低でも2回まわせるようなスケジュールを組むことがあります。
・いったんRFPに対する提案を受けて各ベンダーやパッケージの特徴を把握し、ソリューションのバリエーションを作る
・その中で、A社で上がった課題を解決するためにB社に再提案を依頼する、といった交渉を粘り強く繰り返す
・各ソリューションの実現性を見極めながら絞り込んでいく
といった一連の活動の時間を確保するためには、RFPプロセス1回分の時間では不足しているからです。
　
　
　
もちろん、マルチベンダーだからといって、ベースになるのはユーザーによる各ベンダーの定量評価です。ここがおろそかになると、ソリューションの見極めの土台が崩れてしまいます。まずは納得感のある評価基準を作り、ユーザー自身がデモを見て自分たちの将来像をイメージしながら採点できるように進めましょう。