人事情報システム基礎講座

（２）パッケージ選定フェーズ

　３）提案依頼と提案書説明会

　①　ＲＦＰ説明会

　提案依頼書の説明会は必ず開かなくてはならないものではありません。ＲＦＰ（提案依頼書）を送りつけておしまいという手もあります。しかしながら、文書だけでなく依頼する側と提案する側が直接、会ってお話をすることも無駄とはいえません。率直な「依頼」、つまり、真摯な提案を期待する姿勢を見せることは、良い提案書が提供される確度を上げることになるかもしれないからです。

　ベンダーとしてもＲＦＰの説明会があれば、どういう会社に提案を依頼しているのか理解することにつながります。この時点で、毎回競っている製品もあれば、初めて顔を見るというベンダーも出てきます。意外なところに提案依頼していると気が付くこともあり、クライアントの意図も理解する一助になることがあるのです。また他社の本気度が分かることがあるから怖いかもしれません。

　説明会では、その場で簡単な質問を受け付けることもあります。ここで経験の浅い営業担当者がつまらない質問をして失笑を買うこともあるので、ベンダーとしては出席者に注意が必要かもしれません。いずれにしても、まずはスタートラインに立っていただくという意味でも、開催してみてはどうでしょうか。

　②　提案会の実施

　提案書を提出して、書類だけで検討する場合もありますが、提案書の説明会を開催することをお薦めします。その場合、１社だいたい２時間というのが相場です。９０分程度でプレゼンテーションを行い、その後質疑応答を行うのが普通です。ここでデモなどを行うのは最小限にした方が良いと思います。画面イメージや操作性等について伝えるデモは、既に終了しておくのが良いでしょう。提案説明会は、単なる提案書を読み上げるものではなく、ベンダーのコンセプトやドキュメントに現れない熱意などを聞く場でもあります。

　この場は、依頼する側の特殊事情に対して、どう提案してくるかを見たいのであって、提案を求めている顧客の課題に対して、それをどう理解して、解決策を提示しているのか、何に力点をおいて説明してくるかを注意してみるべきで、製品の見栄えの良い部分だけをみて納得していては勿体ないのです。

　また提案説明会では、話のうまい、今後とも自社のプロジェクトには永久に出てこないセールスコンサルにプレゼンをやらせてしまわないよう、条件をつけるべきです。
　では誰に話させれば良いのでしょうか。それはプロジェクトマネジャです。
立て板に水というＰＭもいますし、朴訥に話をするＰＭもいます。しかしセールストークのうまいＰＭが、プロジェクトを成功させることができるかというと、必ずしもそうではありません。いずれ様々なトラブルや困難なども発生するでしょう。やはりプロジェクトマネジメントをうまく回すことができるのは、どうみてもスマートで胡散くさい話をペラペラする人物ではないようです。人をみる目が確かな人事部さんが、選球眼があることを期待します。

　説明会で重要なのはプレゼンではなく、質疑応答だとも言われています。プレゼンはまじめなところは予行練習もし、穴のないよう配慮したものであることが多いのですが、質疑応答ではすぐ化けの皮がはがれてしまいます。少し意地悪な質問も用意しておくのが良いかもしれません。どう反応してくるのか、人間性がよく出る場面です。また理解力のテストにもなります。プロジェクト管理ではコミュニケーション能力は重要です。相手の質問の意図を正しく理解し、はぐらかすことなく、言いにくいことでも率直に対応してくれるかどうかを見逃さないようにしてください。

　内容がない提案ほど参加人数が多いというのもひとつの傾向です。一度も発言しない人をぞろぞろ連れてくるのはコストの無駄使いだし、そんなことで大事にされていると思うユーザもいないでしょう。始めから２～３名と条件をつけるのも良いと思います。スコープが広く、どうしてもモジュール毎に必要だというベンダーもありますが、全体を総括的に説明ができないのは、プロジェクト全体を把握できない疑いがあります。

　③　評価判定会議

　提案説明会には、事前に用意した評価表をもって臨むのが良いと思います。実際に提案の説明を受けながら、忘れないようにメモを取ることが大事です。その場合、判定の際に評価しやすいように、定量的な評点をつけることをお薦めします。勿論、定性的なコメントや指摘点などは漏らさず記しておくことが必要です。

　評価は、事前に提出された機能表の〇×や、自社の課題などに対する提案内容を評価した情報が主になります。ケースによっては膨大な量になりますので、評価判定会議までに提案企業ごとに比較のできる資料にまとめなければなりません。このプロセスをどこかのコンサル会社に依頼すれば簡単なのですが、自分でやろうとすれば、かなりの時間を取られることを覚悟しておかなくてはなりません。

　ＲＦＰには、単純な業務機能に対する適合表的な情報もあれば、経営テーマをどう解消してくるのか等の高度な問題もあります。当然、機械的に点数をつけられるものは事務的に処理できても、高度な話は提案会などで直接提案者に聞かなければなりません。その会話が参加者全員に理解できていれば問題ないのですが、実は参加者のほとんどが理解できていないテーマがあったするのもよくある話です。

　また評価判定会議は、提案書の回答内容や提案会の評価表や印象などを語って終わりというわけではありません。機械的にまとられる情報はデータであり、誰がみても解答はひとつということになります。しかし判定会議で揉めるのは、勘のようなものが動かし難い壁のように存在する場合です。具体的に言えば、機能や性能は次点だが、あのＰＭ候補に是非仕事をやらせたいとか、あの人物なら安心してＰＪを任せられるという事情に出くわした時です。

　その場合、もう一度このパッケージ導入プロジェクトにはどういう特性があるかを考えてみると良いでしょう。つまり、アドオンが多くなり、パッケージコンサルタントでは手に負えないシステムインテグレーション的な色が濃いプロジェクトになるのか、はたまた標準化を指向する、ＢＰＲや意識改革が大きな意味を持つプロジェクトなのか等を考慮することです。これを間違えると頓挫するリスクが大きくなってしまいます。
　実は選ぶパッケージの特性によって、それを導入するプロジェクトマネジャに期待される特質が異なるのです。精密にキチっと「開発」を含めたシステムの環境構築を着々と進められるパーソナリティを求めるのか、プロジェクトオーナーと標準化方針を揺るぎなく共有し、パッケージの持つ特性を活かしつつ、ユーザとコミュニケーションを図りながら導入を進められる人物を期待するのか。そういった様々な観点が要求されるのです。

　企画担当者は、決定に大きな影響をもつプロジェクトオーナたる人事担当役員や、人事部長に、この機微を伝えておく必要があります。判定会議前にやるべきことは実は多いのです。

　④　結果と通知（次点ベンダー）

　判定会議の結果、１社だけに絞るのはあまり賛成できません。うまく契約がまとまらない場合は、次点のベンダーとも協議する旨を伝えた方が良いでしょう。仮にトップと次点の差が大きく、これ以外ないという場合でも、次点を決めておくべきです。契約の場の交渉のレバレッジが違ってくるからです。ベンダーに対しても油断を与えてはいけません。

　決定したベンダーには、満点でなかったこと、契約の前にこれだけの解決課題があることをしっかりと伝える必要もあります。また次点のベンダーとの差が、僅差であった場合、決定的なポイントについて改善の可能性があるのであれば、２社で一騎討ちをしていただくこともあり得るかもしれません。

　クライアントとして一番やっていけないのは、提案に関してベンダーが知りたい情報をほとんど伝えないということです。言えないことがあったとしても、真摯な感謝と決定理由を伝えましょう。選考に落ちた会社に通知しないなどということは、社会常識上あり得ないことです。コストをかけて提案していただいたことに対しては、感謝の念を示していただきたいというのが大事なポイントです。次にいつなんどきお世話になるか分かりません。担当者や会社の評価を落とすことのないよう、注意を払っていただきたいとお願いいたします。