なぜ自社のレベニュースタックは分断しているのか、そしてそのコストとは

CROに、Go-to-Marketチームが1週間に何個のツールに触れているか尋ねてみれば、間があり、大まかな推測があり、そして緊張した笑いが返ってくるでしょう。正直な答えはたいてい「思っているより多く、リストアップすることもできない」というものです。その不確かさこそが症状です。その根底にある病状は、それぞれが狭い問題を解決し、集合的にはるかに大きな問題を作り出している、何十もの断絶したポイントソリューションへと静かに分裂したスタックです。

誰も分断することを選びません。それは蓄積していきます。ここにプロスペクティングツール、あそこに会話インテリジェンスプラットフォーム、あるチームが強く求めたエンリッチメントベンダー、いつの間にか荷重を支える構造物になってしまったスプレッドシート。それぞれの購入は、単独では理にかなっているように見えました。合わせると、データが流れず、チームが噛み合わず、リーダーが目の前の数字を信頼できないレベニューエンジンになります。

誰も選ばないのにどう起きるのか

GTMソフトウェアは部門レベルで販売されます。セールスオプスは営業のために買います。マーケティングオプスはマーケティングのために買います。CSは自分たちのプラットフォームを選びます。RevOpsはその結果を何であれ引き継ぎます。購買権限が分散しているため、アーキテクチャも分散し、誰も全体を所有していません。

そのサイクルはほぼどこでも同じように見えます。特定の痛みが現れます。レップが活動をログに記録していない、あるいはマーケティングがパイプラインを帰属できない、といったものです。その痛みをまさに解決するために専門ベンダーが買われ、通常は独自のデータモデルを伴います。そのツールは単体では問題なく機能しますが、他の何とも状態を共有しません。そこで回避策が現れます。手作業のエクスポート、Zapierのフロー、夜間の同期、あるいは最もよくあるのはスプレッドシートです。その回避策は恒久化し、次のツールが同じ問題を引き継ぎます。

このループを3つか4つのチームにわたって3年か4年続ければ、積み重なりによる乱立が生まれます。誰も複雑さを選んだわけではありません。誰もが、一度に1つの購入ずつ、利便性を選んだのです。私たちはツール乱立の隠れたコストや、平均的なB2Bレベニューチームが実際に使っているツールの数について書いており、その数字はほとんどのリーダーが推測するよりも悪いものです。

請求書には決して現れない4つのコスト

分断には代償があります。ただそれは単一の項目としては届きません。

生産性のコスト。システムが会話しないとき、人間が統合レイヤーになります。レップはタブ間でデータをコピーし、メモを再入力し、食い違うレコードを照合します。それがスイベルチェア問題であり、誰も予算に組み込むことなく、あなたが抱えるすべての売り手に毎日税金をかけています。

データのコスト。断絶したツールはそれぞれ、真実の一部分だけを保持しています。CRMはあることを言い、エンゲージメントプラットフォームは別のことを言い、請求システムは第三のことを言います。どの数字が本物かリーダーが合意できないとき、意思決定は遅くなるか、最も声の大きい意見で決められます。これが、データサイロがITの問題になるはるか前にレベニューの問題である理由です。

インテグレーションのコスト。ツールを縫い合わせることは決して無料ではありません。ミドルウェアのライセンス、エンジニアリングの時間、そして最悪のタイミングで壊れる同期が積み重なって、あなたが永遠に払い続けるインテグレーション税になります。

俊敏性のコスト。断片化したスタックは変更が困難です。新しいモーションをテストしたい、あるセグメントを再ルーティングしたい、アトリビューションを調整したい？あらゆる変更が十数個の疎結合されたシステムに波及し、本来数日で終わるはずの実験が四半期かかります。そしてそれは結局起きません。

ベストオブブリードは機能しなくなった

10年間、支配的な哲学は「それぞれの仕事に最適なツールを買う」でした。それは、インテグレーションがシンプルで、カテゴリーが一握りしかなかった頃には理にかなっていました。しかしカテゴリーの数が爆発的に増え、算数が逆転しました。データモデルを共有しない12のカテゴリーリーダーは、それぞれの最良のものをあなたに与えてはくれません。それは12個すべてのオーバーヘッドをあなたに与えます。

こうしてベストオブブリードはワーストオブカオスになるのです。すべてのツールが個別には優れているのに、全体としては支離滅裂です。そしてツール間のギャップは、静かにあなたのパイプラインを運営しているシャドーシステムとスプレッドシートで埋められていきます。多くのレベニューチームにおいて、そのスプレッドシートこそが実際のオペレーティングシステムであり、どのベンダーもそれをサポートしていません。

内側からどう感じられるか

これを診断するのに監査は必要ありません。それは日々の中に現れます。

• フォーキャストコールの半分の時間が、誰の数字が正しいかをめぐる議論に費やされる。
• 新入社員が数カ月かけてようやくランプアップする。なぜなら「私たちのやり方」が5つのツールと3人の頭の中に住んでいるからだ。
• RevOpsチームが、何かを改善するよりも配管の保守により多くの時間を費やす。
• マーケティングと営業が異なるダッシュボードを指さして、同じ案件のクレジットを主張したり、否定したりする。
• ある幹部が「今四半期を動かしているのは何か」と尋ね、答えを3日間待つ。

問題はツールではありません。それらを連携させるべき、欠けているレイヤーです。

ツールを減らすことがすべての答えではない

直感的な修正策は統合です。ツールを取り除き、スイートに標準化する。それが役立つこともあります。私たちの経験では、それはより多くの場合、乱立を硬直性と引き換えているにすぎません。本当の問題は、ずっと連携にあったからです。ほとんどのチームが実際に必要としているのは、オーケストレーションレイヤーです。データを統一し、残ったどのツールを使っていてもそれらを横断してアクションを連携させる何かであり、それによってスタックは、それが1つの製品でなくても1つのシステムのように振る舞います。統合とオーケストレーションの違いは、契約に手を付ける前に理解する価値があり、それは製品カテゴリーというよりも運用モデルとしてのレベニューオーケストレーションというより広い考え方につながっています。

主なポイント

• 分断は部門レベルの購買から、一度に1つの理にかなった購入として生まれる。誰もそれをしようと決めたわけではない。
• そのコストは生産性、データ、インテグレーション、俊敏性の中に隠れており、そのどれも単一の請求書には現れない。
• ベストオブブリードは、ツールがデータモデルを共有しなくなった瞬間に崩壊する。人間とスプレッドシートがそのギャップを埋める。
• それは感覚で見分けられる。フォーキャストをめぐる議論、遅いランプアップ、配管しかしないRevOpsチーム。
• ツールを削ることは少し役立つ。それらを連携させることこそが、実際にそれを修正する。

もしあなたのチームが、案件をクロージングするよりもシステムを照合することにより多くのエネルギーを費やしているなら、そのスタックをポイントソリューションの山としてではなく、1つのオーケストレーションされたエンジンとして考え直すべき時かもしれません。それこそ、Revnewoがレベニューオーケストレーションを行う背後にあるアプローチです。