平均的なB2Bレベニューチームは実際に何個のツールを使っているのか？

営業担当VPに、チームがいくつのツールを使っているか尋ねると、一つの数字が返ってきます。同じ質問を担当者にすると、より長いリストが返ってきて、そのあと間があり、「あ、それとスプレッドシートも」と続きます。この二つの答えが近いことはめったにありません。正直な数は、経営層が想定しているよりもほぼ常に多く、レベニューチームの日々の苦労の大部分は、その差の中に存在しています。

私たちがこの数字を気にするのは、それがより測定しにくいもの、すなわち調整負荷の代理指標だからです。アプリケーションが一つ増えるごとに、データモデルが一つ増え、ログインが一つ増え、引き継ぎがひそかに失敗しうる場所が一つ増えます。断片化の問題の規模を測る前に、調達システムの数字ではなく、本当の数を把握する必要があります。

公式な数字は常に低すぎる

ITは会社が対価を払っているものの一覧を保持しています。そのリストは、実際に使われているものを過小に数えています。理由はいくつかあります。

チームは承認しきい値以下でツールを経費計上するため、中央の在庫リストには決して現れません。担当者が別々のツールとして体験しているものの多くは、実際にはより大きなプラットフォーム内の機能です。ここにシーケンサー、あそこにエンリッチメントのアドオン。調達部門から見えるのは一つのベンダーですが、担当者からは三つのワークフローに見えます。

そしてスプレッドシートがあります。多くのチームにとって、最も重要な運用ツールは誰も追跡していないワークブックであり、それが「本当の」パイプラインやテリトリーモデルを保持しています。こうしたパイプラインをひそかに動かすシャドーシステムは、どんなソフトウェア棚卸しにも決して現れず、しばしば人々が最も守ろうとするツールでもあります。

それらすべてを足し戻すと、数は公式な数字をはるかに上回ります。過小カウントはまた、誰にも気づかれないまま乱立が拡大し続ける理由でもあり、なぜレベニュースタックが断片化しているのかの大きな一因です。

現在のスタックはどのような姿か

一つの見出し数字よりも、フルファネルのモーションがいくつのカテゴリーにまたがっているかを見る方が有用です。典型的なミッドマーケットまたはエンタープライズのB2Bチームは、以下のほとんどに何らかの形で触れています。

• CRM、記録システム(通常は一つ、時に誤って二つ)
• マーケティングオートメーションとメール
• セールスエンゲージメント：シーケンシング、ダイヤリング、ケイデンス
• プロスペクティングとエンリッチメント、しばしば重複する2つか3つのベンダー
• 会話インテリジェンス
• スケジューリングとミーティングツール
• 提案書、見積もり、契約管理
• アトリビューションと分析、しばしば複数存在し、めったに一致しない
• カスタマーサクセスとオンボーディングプラットフォーム
• イネーブルメントとコンテンツ管理
• データウェアハウス、BI、レポーティング
• それらすべてをつなぎとめる統合とワークフローのミドルウェア

各バケットの中の個別アプリケーションを数えれば、あっという間に数十に達します。すべてを使う営業担当者は一人もいません。しかし組織はそのすべてに依存しており、それらが互いに協調することにも依存しています。これはまったく別の、より難しいことです。

数そのものより調整の方が重要

同じ数のツールを運用していても、まったく異なる体験をしている企業が二つあり得ます。一方では、データがシステム間を移動し、担当者は一貫した流れの中で作業します。もう一方では、すべてのツールが孤立した島であり、人間が手作業でつなぎ合わせています。メモをコピーし、ステージを更新し、リンクを貼り付け、それを繰り返す。これがスウィベルチェア問題であり、どんなサブスクリプションの請求項目よりもコストがかかります。

パフォーマンスを低下させるのは、調整されていないツールの数です。真のオーケストレーションが背後にあれば、多い数でも問題なく機能します。調整がまったくなければ、ほどほどの数でも混沌になります。したがって、より良い問いは「いくつのツールを持っているか」ではなく、「そのうちいくつが実際に互いに会話しているか」です。

その問いは、そのまま統合対オーケストレーションの議論につながります。数を減らすことが役に立つのは、その裏側の配管も同時に修正した場合だけです。私たちの経験では、それをせずに統合したチームは、アーキテクチャのスライド上のロゴの数は減っても、同じ量の手作業によるつなぎ合わせを抱え続けることになります。

正直な数を把握する

自分のチームの本当の数字が知りたいなら、軽量な監査でそのほとんどを把握できます。

請求書ではなく、人に尋ねましょう。担当者やCSMのサンプルに、通常の一週間で開くすべてのツールとすべてのスプレッドシートをリストアップしてもらいます。次に、一つのワークフローに密着しましょう。一つの案件やキャンペーンを最初から最後まで追跡し、それが通過するすべてのアプリケーションを記録します。調査では誰も言及しなかったものが見つかるはずです。なぜなら、何年も前からそれに気づかなくなっているからです。

そのリストを財務が支払っているものと照合しましょう。その差分は、無駄(お金を払っているのに使われていない)とシャドー支出(使われているのに中央で承認されていない)の両方を示します。ついでに、二つのツールがほぼ同じ仕事をしているすべての箇所にフラグを立てましょう。それらが統合の候補です。

想定していたよりも多くのものが見つかるはずです。それは正常なことです。重要なのは、その数字について誰かを恥じ入らせることではなく、それが表す調整の負荷を理解し、それについて何をするかを決めることです。

主なポイント

• IT在庫は常に過小カウントです。シャドー購入、埋め込まれた機能、スプレッドシートが欠けているピースです。
• フルレベニューモーションはおよそ十数個のカテゴリーにまたがり、ほとんどのカテゴリーは複数の製品を隠しています。
• 害を及ぼすのは調整されていないツールです。単純な数はその弱い代理指標にすぎません。
• 本当の数を知りたいなら、実際に働いている人に尋ね、一つの案件がスタックの中をどう通過するかを追いましょう。

自分のレベニューチームが本当に頼っているツールを数えたことがないなら、それは目を見開かされる午後になるでしょう。また、それらを一つのシステムのように振る舞わせる方法を決める前の、自然な第一歩でもあります。