Go-to-Marketチームにおけるツール乱立の隠れたコスト

Go-to-Marketチームが購入するすべてのツールには二つの価格があります。一つはSaaS請求書に載る金額です。もう一つは、そのツールが後になって要求するすべて――学習にかかる時間、接続する手間、独自の隅に切り分けられてしまう顧客データ、そして販売から奪われる注意力です。ほとんどのレベニューチームにとって、二つ目の価格の方がはるかに大きく、それはほとんど予算レビューには表れません。

ツール乱立とは、その隠れたコストが数年後にどう見えるかを表すものです。誰もスタックを手に負えないものにしようと決めたわけではありません。それは、一度に一チームずつ、合理的な意思決定の積み重ねを通じてじわじわと忍び寄り、気づけば組織は重複する何十ものアプリを運用し、その半分は誰が所有しているのかも分からず、担当者は毎日かなりの時間をあれこれログインし直すことに費やしています。

乱立は症状である

乱立を調達の問題として扱いたくなります。購入が多すぎて監督が足りない、というふうに。しかし乱立は、別のものの下流にあります。GTMツール市場は、個々のチームに狭く専門化された製品を売るように作られているのです。これはなぜレベニュースタックが断片化しているのかの背後にあるのと同じ力です。

すべてのチームが独自に購入でき、すべてのベンダーがワークフローのごく一部を解決するとき、乱立が自然に落ち着く先になります。それを修正するには、まず各ツールがサブスクリプション以外に本当は何を犠牲にしているのかを理解することから始まります。

5つの隠れたコスト

まず認知負荷です。担当者が学び、覚えなければならないすべてのツールは注意力への税であり、コンテキストスイッチはタダではありません。8つのアプリケーションを操る営業担当者は、一日の8分の8を販売に費やしているわけではありません。彼らはその実質的な部分を、状況の把握し直しに失っているのです。

第二にオンボーディングの重さです。新入社員は、あなたの製品、市場、そしてツールエコシステム全体を学ばなければなりません。スタックが大きいほど、フル生産性に達するまでの時間は長くなります。断片化した組織では、立ち上がりまでの期間が数週間から数か月に延び、それが雇用したすべての営業担当者からのレベニューを直接遅らせます。

第三に、データの断片化です。各ツールは、顧客が誰で、何をしてきたかについて、それぞれ独自のバージョンを保持しています。それらのバージョンを突き合わせることはコストがかかり、ミスも起きやすく、その隙間はIT問題ではなくレベニューの問題になります。部分的なデータに基づく意思決定は、悪い意思決定です。

第四に、統合のオーバーヘッドです。自然には協調しないツールはつなぎ合わせなければならず、そのつなぎ合わせは、お金とエンジニアリングの注意力の両面で継続的な請求になります。これがインテグレーション税であり、それはツールの数ではなく接続の数に応じて拡大するため、より厄介です。

そしてライセンスの無駄です。乱立はゾンビ化したサブスクリプションを生み出します。終わることのないパイロット、退職した人に割り当てられたままの席、ほぼ同じことをする二つの製品。ほとんどの組織は、自分たちが所有していることすら忘れている機能に対価を払い続けています。

おおまかな規模の測り方

コンサルティング契約は必要ありません。おおざっぱな概算で十分です。

実際に使われているGTMツールを数えましょう。ITが把握していないシャドーなツールも含めてです。各担当者が、それらの間をナビゲートしたり、再入力したり、突き合わせたりするのに費やしている週あたりの時間を見積もります。それに、フルロードされた営業担当者コストと人員数を掛け合わせます。統合ミドルウェアへの年間支出と、それを稼働させ続けるためのエンジニアリング時間を加えます。そして、新入社員の立ち上がり遅延を、達成が遅れるノルマとして加えます。

出てくる数字は、たいてい驚くべきものです。多くのチームにとって、乱立の隠れたコストは、目に見えるソフトウェア予算よりも大きいのです。担当者がツール間を飛び回るスウィベルチェア問題は、しばしば単独で最大の項目になります。

なぜツールを追加することが前進のように感じられるのか

ツールを購入することは決断的に感じられます。目に見えるギャップに対処し、見栄えの良いデモが付いてきます。しかし新しいツールはそれぞれ、能力よりも速く複雑さが増していくネットワークの一つのノードです。

スタックの価値は、その構成要素同士の連携の質にあり、構成要素の数ではありません。うまく連携する6個のツールを持つチームは、連携しない16個のツールを持つチームに、ほぼ常に勝ります。表面積が大きいほど継ぎ目が増え、継ぎ目こそ価値が漏れ出す場所です。

したがって、乱立への答えが「もっと良いツールを買う」であることはめったにありません。答えは、保持しているツール同士がどう連携するかを変えることです。それは購買の問題というより、オーケストレーションの問題です。

どこから始めるか

乱立がじわじわと忍び寄ってきたなら、小さく具体的なところから始めましょう。

• すべてのGTMチームにわたるツールの棚卸しを実施しましょう。スプレッドシートや非公式なアプリも含めてです。
• 重複をマッピングしましょう。二つ以上のツールが実質的に同じ仕事をしているカテゴリーにフラグを立てます。
• 担当者が最も頻繁にツールを切り替えるワークフローを追跡しましょう。それが最も摩擦の大きい継ぎ目です。
• 実質的にパイプラインを支えているスプレッドシートを見つけましょう。パイプラインをひそかに動かすシャドーシステムは、公式なツールがどこで機能しなくなったかを正確に示してくれます。
• 何かを取り除く前に、調整レイヤーが既存のツールを一つのものとして振る舞わせられないかを検討しましょう。

主なポイント

• サブスクリプション価格は、通常そのツールがあなたに課すコストの中で最も小さいものです。
• 本当のコストは、注意力、立ち上がり時間、断片化したデータ、統合の維持、そして誰も使っていないライセンスです。
• 人員数×時間の簡単な見積もりだけで、隠れたコストがソフトウェア予算全体よりも大きいことが判明することがよくあります。
• 追加されるツール一つひとつが継ぎ目を増やし、継ぎ目は価値が漏れ出す場所です。
• 解決策は、ツールのリストを短くすることだけでなく、保持しているものの間の連携を良くすることです。

自社のGTMスタックがひそかにチームに負担を課しているのではないかと疑うなら、どこで連携が破綻しているかをマッピングすることが良い第一歩です。それこそ、レベニューオーケストレーションが解決するために存在する問題です。