組織開発・タレントプラットフォームのビジネスケース：売るのはソフトウェアではなく意思決定

組織開発やタレントソフトウェアのビジネスケースの多くは、会議の最初の10分で負けており、その理由も同じです。ソフトウェアを説明しているのです。機能、モジュール、連携、マネージャー一人あたりの削減時間。経営陣が聞き取るのは、効果が曖昧で遅れてやって来る新しいコストです。承認されるケースは、逆向きに組み立てられています。経営陣がすでに感じている、高くつき繰り返し起こる一つの組織の問題から始め、その問題のコストを示し、プラットフォームを、そのコストを払い続けるのをやめるための最も安価で信頼できる方法として提示します。そして予算を求める前に、パイロットを求めるのです。

私たちはこの会話の両側に立ってきました。人事や戦略のリーダーがケースを組み立てるのを支援し、それを判断する経営陣の向かいにも座ってきました。私たちが毎回伝える、居心地の悪い助言が一つあります。プラットフォームが変える意思決定を名指しできないなら、買うべきではありません。私たちのプラットフォームを買うことも含めて。

「何ができるかは聞いた。何が変わるかは聞いていない」

従業員約300人のサウジアラビアの企業の人事ディレクターは、タレント・組織開発プラットフォームのビジネスケースを数週間かけて準備しました。30枚のスライドに及ぶものでした。4社のベンダーの機能比較、評価業務とレポーティングで削減される時間の見積もり、ベンダーの数字をもとにしたROI計算。

CFOはそれを約10分で却下しました。人事ディレクターの記憶に残ったのは、その理由です。「何ができるかは聞きました。何が変わるのか、誰がそれを変えるのかは聞いていません。」

2度目の挑戦は1枚のスライドでした。数か月前の経営陣のオフサイトで、CEOは、その年の戦略施策のうち3つが停滞しており、誰がオーナーなのか誰にも言えないと不満を述べていました。新しいケースはその問題を名指しし、3つの施策のうち1つだけの収益遅延を見積もり、リーダーシップチームがプラットフォームを使ってオーナーを割り当て、その3つの施策を追跡する90日間のパイロットを提案し、事前に合意した指標をパイロットが満たした場合にのみ資金を求めました。ケースはその会議の場で承認されました。

ワン・ディシジョン・ビジネスケース

2度目の挑戦の背後にある構造は5つの部分からなり、ソフトウェアに限らず、ほぼあらゆる組織への投資に使えます。

1. 問題。 経営陣がすでに感じている、名指しされた、繰り返し起こる高コストな組織の問題を一つ。できれば経営陣自身の言葉で。停滞した施策、曖昧な意思決定権、重要なチームでの惜しまれる離職、定着しなかった再編。経営陣が問題の存在をまだ信じていないなら、どんなビジネスケースも彼らを説得できません。その場合はそこから始めてください。
2. 何もしないことのコスト。 問題が続いた場合のコストを、経営陣がすでに使っている言葉で、幅をもって見積もります。収益の遅れ、失注、補充コスト、エスカレーションに費やされるマネジメントの時間。控えめで信頼できる数字は、大きくて異論の出る数字に勝ります。
3. 変化。 どの意思決定や行動が変わり、誰がそれを違う形で行うのか。ほとんどのケースが抜かしている部分であり、先の話でCFOが求めていたのもこの部分です。ソフトウェアはそれだけでは何も変えません。人がそれを使って違う決め方をすることが変化を生みます。
4. 証明。 現実の問題を対象とし、意思決定を変えるべき人々が参加し、開始前に合意した指標を持つ、期間を区切った短いパイロット。
5. 要求。 パイロットの結果に連動した段階的なコミットメント。社内の時間を含むフルコストを明記し、うまくいかなかった場合に止める明確な方法を示します。

このように組み立てたケースは、1ページに満たないことがよくあります。それは弱点ではありません。その月に他に40の意思決定を抱えるリーダーシップチームが読めるものにしているのは、まさにその短さです。

ここが常識に反する部分

ROIのパーセンテージから入らないでください。 経営陣がソフトウェアのビジネスケースの中で最も信頼しない部分です。ベンダーから出てきた数字だと知っているからであり、議論が問題から数字の前提へと移ってしまいます。経営陣がすでに信じているコストの控えめな見積もりは、信じてもらうしかない大きなリターンよりもはるかに説得力があります。

必要な額より少なく求めてください。 パイロットを伴う段階的なコミットメントは、大きな年間契約よりも承認しやすく、経営陣が答える問いを「これはその金額に見合うか」から「これは90日に見合うか」へと変えます。パイロットがうまくいけば、2度目の承認は、最初にすべてを求めた場合よりずっと容易になります。

隠れたコストは自分で書き入れてください。 組織プラットフォームで最大のコストがライセンスであることはまれです。最大なのはリーダーの時間であり、その次が構造や役割に関する現在のデータを準備する作業と、人々が実際にそれを使うようになるために必要な変革です。これらを省いたビジネスケースは、説得力が増すわけではありません。経営陣はどのみちそれを考えますし、省いたことで書き手は信頼を失います。

なぜこれが効くのか

その理由は、意思決定研究で十分に裏づけられています。Samuelson と Zeckhauser は1980年代後半に現状維持バイアスを示しました。現状を維持するか変えるかを選ぶとき、人は正当化される以上に現状を好む、というものです。したがってビジネスケースは、現状を中立的な既定値としてではなく、それ自体にコストを伴う一つの選択として見えるようにしなければなりません。それを担うのが、何もしないことのコストのセクションです。

Kahneman と Tversky のプロスペクト理論は、内容だけでなくフレーミングが重要な理由を説明します。損失は同等の利得よりも大きく感じられるため、経営陣がすでに払っている問題は、得られるかもしれない便益よりも重く量られます。John Kotter は Leading Change で同じ点を組織の言葉で述べました。あらゆる変革の第一歩は危機感を醸成することであり、危機感を無から生み出さなければならないビジネスケースは、坂を上りながら戦っているのです。

最後に、これはこうしたプラットフォームから価値を得ている組織で私たちが目にしていることと一致します。価値がソフトウェア単体から生まれることはほとんどありません。必要な構造、オーナーシップ、指標がようやく一か所で見えるようになったことで、リーダーシップチームが違う決め方をすることから生まれます。戦略実行が失敗する理由と意思決定のドリフトの記事では、その可視性に対価を払う価値を生む問題を描いています。

実務チェックリスト

• 経営陣自身の言葉で問題を見つける。 オフサイトのメモ、取締役会での議論、CEOが繰り返し口にする不満。
• 問題の1件あたりのコストを見積もる。 控えめに、幅をもって、人事の言葉ではなくビジネスの言葉で。
• 何が、誰によって違う形で決められるのかを一文で書く。 書けないなら、立ち止まって購入を考え直してください。
• 現実の問題でパイロットを設計する。 期間を区切り、意思決定者を巻き込み、指標を事前に合意する。
• フルコストを列挙する。 リーダーの時間、データ準備、設定、トレーニング、変革支援を含めて。
• パイロットの結果に連動した段階的なコミットメントを求め、どう止めるかも含める。
• 提案する前に適合性を正直に確かめる。 Green Apple が誰のために作られているかと他のプラットフォームとの比較のガイドは、私たちを候補に入れるためだけでなく、外すためにも役立つよう書かれています。

自問してみてください

• 経営陣が今年すでに2回以上不満を述べた組織の問題はどれでしょうか。
• その問題の直近の1件は、CFOが認める言葉で言うと、おおよそいくらのコストだったでしょうか。
• このプラットフォームがあれば誰がどの意思決定を違う形で下すのか、そして私たちはその人たちに尋ねたでしょうか。
• 90日間のパイロットのどんな結果なら拡大を確信でき、どんな結果なら中止を確信できるでしょうか。
• 私たちがこれを買うのは問題を解決するためでしょうか、それとも似た会社が持っているからでしょうか。

要点

経営陣はソフトウェアに資金を出すのではありません。すでにコストを払っている問題を終わらせることに資金を出すのです。その問題を経営陣自身の言葉で名指しし、コストを正直に見積もり、誰が違う決め方をするのかを述べ、合意した結果に照らして測る短いパイロットで証明し、段階的なコミットメントを求めてください。プラットフォームが変える意思決定を名指しできないなら、最も信頼できるビジネスケースは、提出しないビジネスケースです。