ソフトウェア乱立の本当のコスト（ライセンス料ではない）

中堅企業のRevOps機能は平均して14〜22種類のツールを運用しており、それらすべてが収益プロセスに関わっています。セールスエンゲージメント、CRM、インテントデータ、コンバセーションインテリジェンス、ディールフォーキャスティング、CPQ、カスタマーサクセス、データエンリッチメント、テリトリープランニング、クォータ管理: それぞれが実際の課題を解決しており、それぞれが当時急務だった誰かによって購入されたものです。

ライセンス費用は可視化されており、予算サイクルのたびに議論されます。しかし、それらのツールすべてを実際に運用するコストは大部分が見えておらず、はるかに大きなものです。

ここに、ソフトウェア乱立が本当に損害をもたらす実態があります。

データ統合税

収益プロセスに関わるツールはすべてデータを生成します。問題は、そのデータが独自のスキーマで、独自の識別子で、独自の更新スケジュールで生成されることです。14種類のツールを運用している場合、顧客データとパイプラインデータが14バージョン存在し、どれも他と完全には一致しません。

CRMは取引先が「交渉中」と示しています。コンバセーションインテリジェンスツールは、最後の通話が23日前であり、主要な担当者がフォローアップに応答していないことを示しています。インテントデータは、その取引先が競合他社を調査していることを示しています。CSMプラットフォームは、アカウントヘルススコアが18ポイント低下したことを示しています。

これらのツールはいずれも間違っていません。しかし、互いに連携していません。そして担当者は、4つの別々のシステムにログインしてシグナルを手動で統合しない限り、全体像を把握する方法がありません。

統合税は2つの形で現れます。まず、データチームまたはRevOps機能が、これらのシステム間でデータを正規化しようとするパイプラインの構築と維持に多大な時間を費やします。この作業は決して完了しません: 新しいツールが追加されるたびに、新しいフィールド、新しいオブジェクト、既存の統合を壊す新しい更新スケジュールが加わります。50〜200人規模のRevOps機能のほとんどでは、この保守負荷が利用可能なキャパシティの20〜30%を消費しており、それは分析と戦略に使えるはずのものです。

次に、より定量化が難しいことですが: 担当者やCSMは全体像を把握するために4つのシステムにログインする手間をかけません。習慣的に確認する1〜2つのツールから作業を行い、それは断片的な情報で業務を進めることを意味します。データ上の統合税は、すべての顧客インタラクションにおける実行上の税をダウンストリームに生み出します。

コンテキスト切り替えコスト

ナレッジワークの生産性研究は、コンテキスト切り替えにコストがかかることを一貫して示しています。タスクを切り替えると生産的な時間の20〜40%が失われ、切り替えるコンテキストが複雑になるほどコストは増大します。

収益チームにとって、ツールの移行はそれぞれが影響を持つコンテキスト切り替えです。電子メールクライアントからCRMへ、セールスエンゲージメントツールへ、コンバセーションインテリジェンスプラットフォームへと移動して事前コール準備を行う担当者は、ナビゲーションの時間を失うだけでなく、結びつけようとしている情報の断片間の認知的な糸を失います。

測定可能な結果は一貫性のない事前コール準備であり、これはディスカバリーの質の低下、異議対応の悪化、そして3つの異なるシステムに存在するデータから予測できたはずの理由で停止するディールとして現れます。

25人規模の営業チームを管理するRevOpsリーダーへ: 各担当者がツール間のコンテキスト切り替えで1日45分を失うとすると、それはチーム全体で毎日18時間以上の営業時間が蒸発していることになります。1つの劇的な原因からではなく、孤立してみれば些細に見えるツール間の何十もの小さな移行から失われているのです。

優秀な人材への不均衡な管理負荷

ソフトウェア乱立は、最も優れたコントリビューターに不均衡な管理負荷を生み出します。

優秀な担当者やCSMは、仕事を適切に行うことを大切にします。それは、複数のシステム間でデータハイジーンを真剣に維持し、記録を同期させ、ディールステージを正確に更新し、活動を一貫して記録することを意味します。彼らは、良いデータが良いインサイトと良いフォーキャストをもたらすことを学んだからこそ、これを行います。

弱いコントリビューターは最も簡単なものだけを更新し、残りは無視します。使用していないツールは古くなります。しかし経営陣はこれを受け入れます。なぜなら集計データが十分に良く見えるからです。

逆説的な結果: ソフトウェア乱立は、最も弱い人材よりも最も優秀な人材により大きな税を課します。最も優れたAEは、弱いAEが行わないシステム間データ保守に週2時間を費やしています。管理作業に割けることを最も惜しい人材に、管理負荷の合計が落ちかかっています。

ツールを統合して保守負荷を軽減すると、生産性の向上は最も優秀なコントリビューターに集中します。追加の営業時間や関係性が最も高い期待値を持つのはそこにいる人材です。

複利で増える運用負債

スタックに追加するツールはすべて設定負債を生み出します。ワークフローを構築する必要があります。フィールドマッピングを設計する必要があります。同期ルールをテストする必要があります。レポートロジックが新しいツールとそのデータを考慮する必要があります。

ツールが新しく問題が緊急だったとき、RevOpsまたはITの誰かがチームのブロックを解除するための最小限の実行可能な設定を構築しました。その設定が長期的な堅牢性を考慮して設計されることはほとんどありません。エッジケースは場当たり的に対処されます。フィールド名はアドホックに作成されます。同期ルールは、誰もが完全には理解していない文書化されていない技術的依存関係を生み出します。

今、2年後、そのツールはスタックに組み込まれています。設定を構築した人は去りました。ビジネス要件は変わりました。そして統合を更新したりツールを再設定しようとする試みは、もはや誰も完全には理解していないダウンストリームの何かを壊すリスクを持ちます。

それが運用負債であり、金融負債とまったく同じように複利で増えます。持ち続けるほど、管理コストは上がります。スタックに追加するすべての新しいツールは、将来運用負債になる新しい設定面を生み出します。スタックからツールを合理化することで取り除くすべてのツールは、将来の義務を排除します。

RevOpsの成熟度モデルの多くはこのトレードオフの管理に関するものです: 成熟したチームは、どのツールを追加するかについて意図的な選択をし、最初から統合を正しく構築し、設定を文書化し、ビジネス価値よりも速く運用負債を生み出しているツールを排除するために定期的にオーディットを行います。

ツール合理化の取り組みで実際に明らかになること

ツール合理化の取り組みを真剣に実施したRevOpsリーダーのほとんどは、予想していなかった2つのことを発見します。

まず、支払いはしているが使用されていないツールを見つけます。「最適に活用されていない」のではなく、文字通り使用されていないものです。40席分購入されたライセンスに8人のアクティブユーザーがいます。3四半期前に自動更新されたが、チームがとっくに乗り換えたツールの契約があります。これは、誰かが実際に支出に対する使用状況を監査したときにのみ見える直接的なコスト削減です。

次に、集中的に使用されているが負のROIをもたらしているツールを見つけます。ツールが悪いからではなく、そのツールが別のスタックのツールが原因で存在する問題を解決しているからです。データエンリッチメントツールは、CRMが見込み客データをうまく取得できないという事実を補完するために存在します。CRMが見込み客データをうまく取得できないのは、セールスエンゲージメントツールがCRMと双方向に同期しないからです。同期を修正すれば、データエンリッチメントツールを排除できるかもしれません。少なくとも必要な席数を減らせるでしょう。

この相互依存の連鎖は、データフローを明示的にマッピングするまで通常は見えません。そうすると、ツール支出の30〜40%が実際のビジネス問題ではなく、スタック内の別のツールが生み出した問題に対処していることがほとんどの場合わかります。

組織的コスト: 断片化した責任

ソフトウェア乱立は、文化的問題になるガバナンス問題を生み出します。

各部門が自分の予算でツールを購入できる場合、収益プロセス全体ではなく、購入した機能に最適化するツールを手に入れます。マーケティングは、セールス開発ワークフローとすっきりと統合されない形式でリードを生成するツールを購入します。セールスオプスは、CRMが生成するデータが整合しないフォーキャスティングツールを購入します。カスタマーサクセスは、CRMとは異なるアカウント識別子を使用するヘルススコアリングプラットフォームを購入します。

各購入は孤立して正当化できます。累積効果は、エンドツーエンドでデータがどのように流れる必要があるかについての共有ビューなしに異なる予算保有者によって購入されたツールが、機能するために重大な手動調整を必要とする収益プロセスです。

ソフトウェア乱立を生み出す責任の断片化は、RevOpsを難しくする同じ断片化です。強力で集中化されたRevOps機能を持つ組織が、より小さく、より統合されたテックスタックを持つ傾向があることは偶然ではありません。ツールの乱立を防ぐ同じガバナンス能力が、一貫したパイプライン管理、正確なフォーキャスティング、効果的なGTM実行を可能にする能力でもあります。

どこから始めるか

最初の有益なステップはプラットフォームオーディットではありません。ワークフローオーディットです。

3〜5つのコアワークフローをマッピングします: 担当者、SDR、またはCSMが高頻度のタスクを完了するために実際に取る手順です。リードのフォローアップ。商談の作成と検証。更新の準備。彼らが触れるすべてのツール、手動で踏むすべてのステップ、あるシステムから別のシステムにデータを転送したり、全体像を得るために複数のシステムで情報を参照したりする場所すべてをマッピングします。

摩擦をすぐに発見するでしょう。そして、摩擦がツール間の統合ポイントに集中していることがわかります。1つのツールの内部ではなく。そこがコンソリデーションが最も即座にROIをもたらす場所です: ツールを排除することによってではなく、ツール間の縫い目を排除することによって。

ツールの合理化はそのワークフローマッピングから自然に続きます。一部のツールは存続します。一部は置き換えられます。一部は、その機能が現在スタック内の既存ツールによって処理されており、ただ十分に活用されていないために排除されます。

関連リソース

• RevOps成熟度モデル: リアクティブから戦略的へ - ツールガバナンスが成熟度の発展においてどこに位置するか
• アトリビューションは壊れている。代わりに何を測定すべきか - データの断片化がアトリビューションを信頼できないものにするとき
• CAC回収: SaaSの存続を本当に予測する指標 - スタックコストはEBITDAに現れる前にCACに現れる
• パイプラインハイジーン: データ問題ではなく文化的実践として - ツールの乱立がパイプラインデータの質を低下させる方法
• CRMデータハイジーン - マルチツールデータ断片化のダウンストリーム影響
• CRM導入運用モデル - 合理化されたスタック全体で導入を構築する