アライアンスマネージャーが語るオーケストレーションの必要性

アライアンスマネジメントは、レベニュー組織の中で最も難しいポジションかもしれません。あなたが担うのは2社にまたがる動きです。あなたに直属していない営業担当者たちに依存しています。CRMではほとんど見えない収益を生み出します。5つのシステムに散らばったデータを使ってプログラムの効果を証明し、あなたとインセンティブが噛み合わない人々を通じて案件に影響を与えることが求められます。責任は大きいのに、コントロールできる部分はごくわずかです。

多くのアライアンスマネージャーは、より一生懸命働くことでこれに対応しようとします。スプレッドシートを増やし、Slackでの催促を増やし、手作業での案件マッチングを増やし、四半期末には貢献度をめぐる議論を増やす。私たちはこれを複数の企業で見てきましたが、結末はいつも同じです。努力はスケールせず、そして英雄的な頑張りは人員査定を生き延びられません。解決策は運営モデルを変えることであり、アライアンスをオーケストレーションの課題として扱うことです。それこそが、成長するアライアンス機能と、優秀な人材を燃え尽きさせてしまうアライアンス機能との違いです。

不利な条件は仕事に組み込まれている

まず、アライアンスマネージャーが同時に直面しているものを見てみましょう。

直接的な権限がない。AE（アカウントエグゼクティブ）にパートナーを案件に呼び込めと指示することはできません。できるのは影響を与え、説得し、やりやすくすることだけです。営業担当者に余分な仕事をさせることに依存する動きは、あなたが後押しをやめた瞬間に衰退します。

データが分断されている。パートナーのシグナルは、必要な場所以外のあらゆる場所に存在します。紹介フォーム、マーケットプレイスのコンソール、パートナーのCRM、Slack Connectのチャンネル、誰かの受信箱です。一貫した全体像を組み立てるのは考古学的な作業であり、それを来四半期にまた一からやり直すことになります。

貢献が見えない。パートナーの関与はCRMにきれいには反映されないことがほとんどなので、プログラムの収益は体系的に過小評価されます。これはパートナー起点の収益がほとんどのCRMで見えなくなっている理由の核心であり、あなたが解決すべき信頼性の問題です。

貢献度が争われる。パートナーが関与した案件が成約すると、そこから議論が始まりますが、あなたはたいてい証拠なしで議論することになります。これはまさに現場で起きているコセルアトリビューションの問題です。

これらはどれも、より一生懸命努力することでは解決しません。構造的な問題であり、プログラムが成長するほど悪化します。パートナーと案件が増えるということは、手作業でのマッチング、散らばったデータ、対立がさらに増えるということです。あなたの努力は線形にしか増えないのに、問題は組み合わせ的に増えていきます。このギャップこそが、多くのアライアンスマネージャーが一握りの看板パートナーで頭打ちになる理由です。

オーケストレーションが変えるもの

オーケストレーションは、アライアンスマネージャーが何をするかではなく、システムが何をするかを変えることで、構造的な問題そのものに切り込みます。3つの転換があります。

手作業でのマッチングが自動的な発見に変わる。あなたがアカウントをしらみつぶしに調べてパートナーが役立つ場所を探す代わりに、システムがそれを行います。この案件はこのパートナーの顧客基盤と重なっているので、紹介を推奨する、というように。マッチングは探し出すものではなく、営業担当者とあなたのもとに届くものになります。これはレベニューシグナルをネクストベストアクションに変えるのと同じ規律を、パートナーデータに適用したものです。

催促が組み込みのワークフローに変わる。パートナーの推奨事項が、それが関連するまさにその瞬間に営業担当者自身のツールの中に現れます。これは私たちが見てきた中で唯一、営業が実際に使うアライアンスモーションを構築する方法です。あなたは人間のリマインダーサービスであることをやめられます。

四半期末の再構築が継続的なキャプチャに変わる。パートナーとの接点は発生した瞬間にタイムスタンプ付きで記録され、案件に紐づけられます。貢献度をめぐる議論は記録に置き換わります。

この3つを貫く一本の糸はこうです。あなたは調整作業を自ら行う立場から、それを行うシステムを設計する立場へと移行します。それこそが、少数の大型パートナーを超えてスケールできる唯一の仕事の形です。

コーディネーターからアーキテクトへ

ここには運用面だけでなく、キャリアの議論もあります。アライアンスマネジメントが手作業の調整である限り、アライアンスマネージャーはボトルネックです。すべてがその人を経由するため、プログラムは一人が押し進められる速さでしか成長しません。これはプログラムのインパクトとマネージャーの影響力を同時に頭打ちにします。

オーケストレーションはこの役割の本質を変えます。アライアンスマネージャーは、個々の案件を手作業でこなす人ではなく、パートナーのシグナルがどう流れ、営業担当者がどう動かされ、貢献度がどう記録されるかを設計する人になります。

これはいくつかの点でアップグレードです。インパクトはスケールします。よく設計された動きは、人員を比例して増やすことなく数百件の案件で機能するからです。信頼性は高まります。継続的なキャプチャとクリーンなアトリビューションのおかげで、営業側が異議を唱える主張ではなく、財務部門が信じる数字を持って経営レビューに臨めるからです。そしてこの役割は戦略的になります。エコシステム全体にまたがるレベニューモーションを設計することは、GTMアーキテクチャの問題であり、再現可能なGTMプレイブックを構築することに近い営みです。それは戦略テーブルの席を意味します。

今後数年でうまくやっていくアライアンスマネージャーは、最も多くのパートナー関係を持つ人ではありません。会社全体がパートナーとの協業による販売を得意になれるようなシステムを構築し、それをデータで証明できる人です。

社内で説得する

この転換に予算をつけようとするなら、経営層がすでに重視している言葉で語りましょう。

効率性。新しいパートナーごとに人員を増やすことなく、アライアンス機能がより多くのパートナー関連パイプラインを生み出す。信頼。継続的でタイムスタンプ付きのアトリビューションが、四半期ごとの貢献度をめぐる争いを、財務部門が承認する数字に置き換える。成長。オーケストレーションされた動きこそが、エコシステム主導の成長を、取締役会資料の期待だけのスライドではなく、実行可能なものにする。

「アライアンスチームに新しいツールを与えてください」と売り込んではいけません。「分断されたシステムと手作業の調整によってパートナー収益を失っており、代わりに複利で積み上がる動きを構築できる」と売り込みましょう。それはレベニューの議論であり、私たちの経験ではCROやRevOpsのリーダーはそれを聞く準備ができています。

主なポイント

• アライアンスの役割には、直接的な権限の欠如、データの分断、見えない貢献、そして争われる貢献度がつきまとう。より一生懸命働いてもどれも解決しない。
• 問題はパートナーと案件の数に対して組み合わせ的にスケールするが、手作業の努力は線形にしかスケールしない。だからプログラムは頭打ちになる。
• オーケストレーションはマッチング、活性化、アトリビューションをシステムに組み込む。自動的な発見、営業担当者のワークフロー内での推奨、そして継続的なキャプチャである。
• この役割はコーディネーターからアーキテクトへと移行する。それはより大きなインパクトであり、より良いキャリアでもある。
• 効率性、信頼、成長を軸に説得し、失われたパートナー収益を取り戻すという枠組みで語る。

自分のインパクトをスケールさせるアライアンスマネージャーは、手作業での調整をやめた人たちです。別の運営モデルを構築する根拠を探しているなら、パートナーの発見・活性化・アトリビューションを一箇所で運用する方法として、Revnewoのようなプラットフォームが参考になります。