ＲＦＰに時間と工数をかけてもシステム選定に失敗するのは何故か

人材・タレントマネジメントシステムを導入するとなった際、RFP（Request for Proposal／提案依頼書）を作成し、複数のシステム提供ベンダーに提案を依頼する企業は少なくありません。この選考プロセスは、まずRFP作成自体に時間がかかりますし、ベンダーからの質問への回答、提出された提案の精査、プレゼンテーションの準備・開催など、かなりの工数を要します。

しかし、そこまで時間と工数をかけ、しっかりと選考したはずなのに、導入に苦労し、やっとリリースしたシステムは、当初期待したような使い勝手ではなく、効果が出せていない、というケースを耳にすることが多くなっています。

例えば、こんな会社の例があります。

●経営層から、タレントマネジメントを強化してほしい、そのためにシステム導入も検討してよいと言われた。
 

●人事に関わる組織や人すべてに、人材・タレントマネジメントのためのシステムに搭載してほしい機能を聞き、要望する機能リストとしてまとめた。
 

●RFP作成の作法がわからないので、全体のまとめは、情報システム部と外部コンサルティング会社に依頼した。
 

●RFI（Request for Information/情報提供依頼書）の回答内容から、４社のベンダーに絞り込み、RFPを渡し、提案を依頼した。提案書作成期間は約1ヵ月。
 

●人事本部長や情報システム部長をなど関係者12人を集めて、1日2社、2時間のプレゼンテーションをしてもらう。2時間の内訳は、1時間半がプレゼンテーション、30分が質疑応答。
 

●提案書内の機能要件のマッチング率をベースに、プレゼンテーションでの評価を加えて関係者で話し合い、最終決定。

さっそく始まった導入プロジェクトは難航、リリースも半年遅れました。そして、リリースされたシステムがうまく使えていない、という状況に陥っています。

このような「正式」なプロセスを踏んだにも関わらず、どうしてこのようなことが起きてしまうのでしょうか。

これまで見てきた失敗例から見えてきた、共通点が以下の3点です。
 

１．「担当者全員」の「望み」をかなえようとする。

２．「公平」であろうとしすぎる。

３．ベンダーが「できない」と言いづらいRFPになっている。

他にも、失敗原因を挙げることはできますが、本稿では、これら3つについて、何が問題なのかを整理し、失敗を回避するためには何を考え、どうしたらいいかをまとめていきたいと思います。

１．「担当者全員」の「望み」をかなえようとする。

【どんな問題が起こるのか】

ここでは、2種類の問題が起きています。

ひとつ目は、「この機会に人事の業務を洗い出そう」と考え、「漏れがないように」と、人事関係者を網羅して話を聞き、その結果システムがカバーする範囲が拡がっていき、「欲しい機能」のカテゴリが増えていくというパターンです。

元々は「自社の人材・タレントマネジメントを強化するため」が、メインの目的であったはずなのに、そこには直接は関係ない業務や仕組みの話が入ってきます。目的達成とそれらの繋がりが明確に見えていれば当初の範囲が拡がることもありですが、実際には、目的達成との繋がりがわからないままに、要望だけが増えていくという状況に陥ります。その結果、そもそものメインの目的の存在が薄れ、目指している方向がバラバラの要望機能が並んだリストができることになります。

ふたつ目は、「誰に聞くべきかが良く考えられていない」、「関係者の意識づけが誤っている、目的が共有できていない」というパターンです。「今、現場でシステムを使っている人」と「新しいシステムを活用して、マネジメントの質を上げるタスクを負っている人」を、無自覚に並列に扱っているケースも珍しくありません。

目的に対して正しい要望を出せるのはどういう人なのかを精査するというプロセスが抜け落ちているのです。

そうなると、出てくる要望内容のレベルの高低がバラバラで、中には、「システムが入れば、そもそも業務として必要なくなるのでは？」といった、単に今欲しいと思っている機能や、「その資料は変化・変更が多いから、手作業として残した方がいいのでは？」という、将来の変化可能性やビジネスへのインパクトとった視点が抜け落ちている要望も紛れ込んできます。しかし、元々の意識合わせができていないので、リスト化されてしまった要望の優先順位づけや、適切な要望の削減を後から行うのは困難です。

こうした問題をはらんで出来上がった「要求機能」を「機能要件一覧」として一律に並べ、その実現可能性を○△×等で回答してもらい、マッチング率を計算。その数字が高いベンダーの提案が、「自社に合っている」と判断されていくことになります。もちろん、他の要素も加味されるでしょうが、例えば、90％と65％という数字が並んだとき、この差をひっくり返すことは容易ではありません。

本来の目的から考えれば絶対に外してはいけない機能と、本来の目的とのリンクが薄い機能や、担当者の「あったら嬉しい」というレベルの機能が、すべて1として数えられ、無味無臭の数字に置き換えられてしまい、その高低によって評価されてしまっているわけです。リリース後に「どうも最初に期待していた効果が出せてない」と感じるようになるのは、決して不思議なことでありません。

【こうした問題を回避するにはどうしたらいいのか】

こうした失敗を回避するために、以下のプロセスを踏むことをお薦めします。
 

１．まず、高いレベルのメインとなる目的、今回のシステム化で達成すべきことは何か、を明確にして、すべての判断の基礎とする。
 

２．大きな目的達成のために、具体的にシステムが担うべきことを整理する。

＜例＞通常、以下のような３つの役割が挙げられてきます。

◇「業務の効率化・業務の質の均一化」

◇「意思決定・人材・組織マネジメントの質の向上」

◇「好ましい行動の促進・好ましい文化の醸成・現場マネジメントの強化」

３．上記を踏まえて、誰に何を伝えて要望を聞くのかを整理する。要望を聞く人には、上記１、２を理解してもらう。

４．集まった要望を、中目的毎に整理し、大目的達成に対する重要性と照らし合わせて優先順位をつける。また、本当にシステム化が必要かどうか、重要度、起こる頻度などから判断する。
 

◇リストに挙がってきた機能は、２で挙げた役割のどのカテゴリを担うのか。その役割は目的達成とどのような繋がりがあるのかないのかを整理することが肝要です。（この点についての詳細は、「人事がシステムに期待すべき効果と、優先順位について考える」にて解説をしています。：近日公開予定）
 

◇「本当に今システム化が必要なのか」「システム化の効果はどれほど期待できるのか」
上記１の目的と照らして、優先順をつけたり、リストからはずしたりします。

５．優先順位の高いものを確実に実現できるかどうかにフォーカスして、要望機能をまとめます。

２．「公平」であろうとしすぎる。

【どんな問題が起こるのか】

RFPを受け取ると、「『公平』を期するために、ここから先のご質問、連絡はすべてExcelに記載してメールでお送りいただきます。そして、そこに記載されるやり取りは、提案に参加しているすべてのベンダーに共有します」「プレゼンテーションまでは、担当者たちと直接コンタクトすることはご遠慮ください」と言われることが珍しくありません。また、時に「公平」であるために、人事担当者はプレゼンテーションまでベンダーと一切接触せず、情報システム部と外部コンサルティング企業が取りまとめるといった企業もあります。そして、基本的に提案書とプレゼンテーションの内容で決定していきます。

そうしたやり方をすることで見落とされてしまうリスクがあるのが、プロジェクトに関わる人材や組織の「問題を共に解決していく力」です。

純粋に、製品やサービスの質や適合性のみを判断したいので、ベンダーの影響を排除したい、というタイプの選考を考えているのであれば、上記のような選考の進め方は合理的です。

しかし、人材のデータを一元化し、有効に活用していこうとするようなシステム導入は、会社の規模によりますが、最低でも数カ月、規模が大きくカバー範囲が広くなれば、半年から1年、更にはフェーズを分けて、数年がかりのプロジェクトになることもあります。そしてほとんどの場合、自社担当チームとベンダーの合同プロジェクトです。

また、これまでなかった新しいエリアでシステムを構築するプロジェクトであるかぎり、想定しきれていなかった問題や課題がまったく出てこないということは、ほぼありません。多くの場合、壁にぶつかったり、思ったようにいかなかったりすることを乗り越えていくことになります。そうした際には、システム導入プロジェクトに関わる「人」「組織」も重要な要素です。そうした点を見極めていくのに、
 

●Excel上での質疑応答

●Excelに列記された機能要件に対する○△×（マッチング率）

●パワーポイントの提案書

●多人数の前で行われるプレゼンテーションと限られた時間の質疑応答
 

だけでは、システム導入を依頼しようとしている人たちや会社が、共に困難や高いハードルを越えていける人・組織なのか、その本質を見抜くことはかなり困難なはずです。日常生活でも、困難を伴うことを長時間一緒に取り組む仲間を、テキストのやりとりのみ、相手からのプレゼンテーションだけで、自信をもって決めることができるかどうか、考えてみるとわかりやすいでしょう。

その結果、プロジェクトを進める中で想定外のことや困難なことが起きたりしたときに、「そういう話は聞いていませんので対応できません」とか「それはできません」といったスタンスを取られてしまい、大変苦労したり、一部のことを諦めざるをえなかったりすることすらあります。

【こうした問題を回避するにはどうしたらいいのか】

そもそも、システム選考で「公平」が大事にされてきた背景は、以下のようなことを避けるためです。

●特定のベンダーとの関係が強くなりすぎて、価格競争の機会を持たなくなり、高い価格でサービスを購入することになってしまう。
 

●自社担当者とベンダー営業の間に癒着が起き、コンプライアンス上の問題が起こる。
 

●一部の担当者の「好み」や「限られた知識」「イメージ」といったものだけで選考が進み、自社に最も合っているサービスを選択することができなくなる。

これらを避けようとすることは当然ですし、ここで必要とされる「公平」さは、これからも追求するべきです。

一方で、ベンダー間の「公平」はどうでしょうか？
 

●Ａ社にはすべての情報を渡しているが、B社・C社には半分の情報しか渡さない。
 

かなりの時間がかかる提案書を準備してもらうよう依頼するわけですから、こうした不公平は、ビジネス倫理上あるべきではありません。しかし、ここから先の「公平」について、よく考えてみる必要があります。

市場でビジネスをしている会社が、自社で生み出した利益を使って、将来のビジネスの成功のために投資をするのです。一般的に担保すべき｢公平｣を実現したとしたら、後は、自社にもっとも適した、投資効果が望める製品、サービスを選ぶことを優先させるべきではないでしょうか。最適なものを選ぶことの障害になるものは排除すべきでしょうし、最適なものを選ぶためにできる限りのことを考え、実行すべきだと思います。

例えば、「ベンダーからの質問とそれに対する回答はすべて公開します」という慣行。大前提として、基本的な情報は、既にすべての参加ベンダーに公平に渡されています。その先、「何が課題か」「確認しないと問題になる点は何か」といった事柄に、どこまで広く深く気がつけるかは、実はベンダーの質を見分けるひとつの重要な要素です。他ベンダーの経験や知見から出てきた情報を、それらに気がつくことができなかったベンダーにもすべて渡すことが、「最適な製品・ベンダーを選ぶため」に必要なことなのでしょうか。

釣り上げた魚（整った回答）を確認するだけではなく、その魚を自力で釣ることができる技術やノウハウを持っていること（課題発見能力）を確認することも重要なのではないか。そう考えると、「質問」「確認事項」をどう扱うのがよいのか、変わってくる可能性があります。一部の提案に漏れが出ることを懸念するのであれば、全社に知っておいてもらいたいことを取捨選択して伝えることでカバーできるでじょう。この案には、おそらく議論・反論が多数出そうですが、少なくとも、今のやり方（「お作法と言われるもの」を、客観的に見直すひとつのポイントになるはずです。

検討をお薦めするのは、プレゼンテーションではなく、ワークショップの実施です。

できれば、無償で依頼するのではなく、小額でもいいので有償でワークショップを行ってもらうのが理想です。有償にする理由は、サービスとしてではなく正式な仕事として取り組んでもらうためです。実際にプロジェクトに携わる予定となっている担当者の時間を半日2回ほど押さえ、RFPに対しての印象や解釈、実際の機能実現について、ディカッションをするのです。そこまですれば、難しい局面になったときに「聞いていない」「そうは思っていなかった」といった対応をするアプローチなのか、逆に新しい発想を出してハードルを乗り越える意識と実行力があるのかどうか、わかるはずだからです。（これは次の「ベンダーが『できない』と言いづらいRFPになっている」から生まれる失敗を回避するためにも重要なポイントですので、そちらに続けて説明をしていきます。）

もし、そこまではできないとしても、Excelでのやり取りだけではなく、RFPを精査してもらった後に、それぞれのベンダーと直接、膝を突き合わせて質疑応答する機会を持つというだけでも、得るものが多いでしょう。Excelやメールだけでのやり取り、他のベンダーの目があるところでの発言では見えてこない要素が、見えてくるはずです。

３．ベンダーが「できない」と言いづらいRFPになっている。

【どんな問題が起こるのか】

IT業界では、RFPにおける機能要件の「マッチング率」が重要な意味を持つと認識されています。機能のひとつにでも×がつくと不利になるという認識ですから、多くのベンダーは、様々な解釈を駆使して、できるかぎり多くの○をつけていきます。その結果、ほとんどのベンダーのマッチング率は高くなり、中でも高いマッチング率をはじき出したベンダーの提案が選ばれる可能性が非常に高くなります。これまで書いてきたように、ほとんどの場合、プレゼンテーションというフォーマルな場以外の直接の接触がないため、提出された書類、中でも人によって判断が分かれない「数字」が大きな意味を持つことになるからです。

既に確定したルールやプロセスをそのままシステム化するタイプのシステム導入であれば、「マッチング率」をベースにした選考は大変合理的です。しかし、人材・タレントマネジメントのエリアは、ほとんどの企業で制度やプロセスが確定していません。ある程度確定したものがあったとしても、ビジネス・労働市場が変化すれば、それに合わせて変えていくことが求められる世界です。また、個社の要件が必ず出てくる戦略の世界でもあります。そうした性質を持つ人材・タレントマネジメントに対して、「パッケージ」という枠組み中で提供される機能だけで、すべての希望に対応できるということはないといっていいでしょう。

しかし、RFPでは×が多くなってしまうと選ばれないという認識が、できないこと、できないかもしれないことを覆い隠してしまいます。そして、そのことが分かるのは、実際のプロジェクトが始まってから、ということになるのです。

【こうした問題を回避するにはどうしたらいいのか】

繰り返しになりますが、パッケージソリューションをベースに、自社の戦略に関わるエリアをシステムでサポートしようと考えたとき、列記した要求機能にすべて○ということは、精緻に誠実に考えれば、ほぼありえません。ですから、もし回答がすべて○だったら、「おかしい」と疑ってかかった方がいいでしょう。「ユーザーの視点で考えれば△かもしれないし、×かもしれない」と率直に伝え、「確かにこの文言をそのままであれば△や×だけれど、こうすれば解決可能」、「こうした機能の組合せで対応できる」など、しっかりと対応策を提示してくれるベンダーの方が信頼できます。

要望が実現できるか否かを確認することも重要ですが、「できない」ことがあったとき、どのように対応し、解決していってくれるのかを知ることも、同様に重要なのです。その点を認識し、それを確認する方法を探すことをお薦めします。例えば、

「マッチング率も重要な参考情報の一つですが、すべてが○ということもないと理解しています。是非、素直に△・×である機能を教えてください。それに対して、＜どうしてその機能を持っていないのか＞という貴社のシステムに対する考えや、＜他社ではそうしたことを、ＸＸＸＸのような方法で行っている＞という解決策などを教えてください。その情報を、選考の重要な要素として精査させていただきます」

と伝えてみてはどうでしょうか。

その上で、「『公平』であろうとしすぎる」でも書いたように、そのことを話し合えるワークショップを開催できればベストでしょう。ここでは、実際にプロジェクトに関わる人に参加してもらうことが肝要です。そして目の前には、具体的に△・Ｘという、具体的な困難・課題・ハードルが提示されていますから、それについて、どのように解決をしていくのかを提案してもらい、ユーザーとして納得できるか否かを吟味し、具体的な落し所を探っていくプロセスを経験してみるのです。ここまで話し合いをすれば、長く困難が伴うプロジェクトを共に乗り切れる人や組織なのかがわかりますし、システムに期待できることについて、後から「聞いていたことと違う」「話が違う」という落とし穴に落ちる可能性を大幅に減らすことができるでしょう。

RFPは、「人事はシステムのことがわからないから」ということで、選考は情報システム部にまかせるというケースも少なくありません。専門家にまかせるメリットも大きいですが、様々なタイプのシステムを扱っている情報システム部では、 システム選び＝RFP＝これまでのお作法に則る、と、一律に扱われてしまう可能性もあります。是非、今回ご紹介した3つの落とし穴に落ちないよう、「お作法」を押さえつつも、「自社に最適なシステム、サービス、そしてプロジェクトの仲間を選ぶ」ためには、どういった方法が適しているのかを真剣に考えていただければと思います。

※インフォテクノスコンサルティング株式会社 Rosic人材マネジメントシステムサイトからの転載（オリジナル：2018年7月9日掲載）