RevOpsが失敗する理由: 収益オペレーションを壊す9つの失敗パターン

RevOpsが失敗するのは、チームがダッシュボードを作れないからではありません。

失敗するのは、会社がRevOpsに権限を伴わない責任だけを与えるからです。あるいは、プロセスが明確になる前に自動化から始めるからです。あるいは、すべての部門にそれぞれの定義を維持させ続けるからです。あるいは、RevOpsをチケット処理の窓口にしてしまいながら、それでも収益システムを再設計することを期待するからです。

肩書をつけるのは簡単です。運用上のマンデートを確立するのは難しいのです。

Revenue Operationsとは何かと収益オペレーションフレームワークを読んだ後、この記事を失敗パターンのチェックリストとして活用してください。

Forresterの記述によれば、成功している収益オペレーション体制は、分散型から完全な中央集権型まで幅があるとされています。これは有用な指摘です。RevOpsの失敗は、組織図の選択を誤ったことだけが原因ではありません。多くの場合、運用ルールの弱さが原因です。

押さえておくべき運用上の事実

• RevOpsが失敗する主な原因は、弱いマンデート、不明確な権限、断片化した定義、貧弱なデータガバナンス、そして部門ごとの部分最適です。
• ダッシュボード、自動化、ツールは不明確なプロセスを解決しません。むしろ混乱をより見えやすく、より速く広げてしまうことがよくあります。
• 最も重要な初期対策は、文書化された憲章、RACI、信頼できる情報源モデル、そして運用ケイデンスです。
• 失敗は運用上の症状(意思決定の遅さ、数字の食い違い、引き継ぎの漏れ、フォーキャストへの不信、バックログの過負荷)によって診断すべきです。

1. RevOpsが権限を伴わない責任を負わされている

これは最もよくある失敗です。

RevOpsはデータ品質を改善するよう求められますが、必須フィールドを強制する権限がありません。フォーキャストの精度を改善するよう求められますが、ステージ定義を変更する権限がありません。マーケティングとセールスを連携させるよう求められますが、ライフサイクルのルールを統治する権限がありません。

その仕事は形だけのものになります。RevOpsは、自分ではコントロールできない成果に対して責任を負わされます。

これを直すには、RevOps憲章を書くことです。憲章はスコープ、意思決定権、エスカレーションの経路、そしてRevOpsが各部門のリーダーに確認を取らずに変更できる範囲を定義するべきです。

失敗診断テーブル

症状を使って失敗パターンを特定してください。

このテーブルは、一般論のアドバイスを避けるのに役立ちます。「RevOpsがうまくいっていない」というだけでは、直しようがないほど漠然としています。運用上の症状こそが、最初に直すべきものが権限なのか、定義なのか、ケイデンスなのか、データなのか、オーナーシップなのかを教えてくれます。

2. 会社がダッシュボードから始めてしまう

ダッシュボードは進捗のように見えます。目に見え、共有しやすく、経営層に好まれます。

しかし、不明確なステージや不良なフィールドの上に構築されたダッシュボードは、悪いデータを見やすくするだけです。

「作成されたパイプライン」という言葉がセールスとマーケティングで異なる意味を持つなら、ダッシュボードはその論争を解決しません。商談ステージが主観的なら、フォーキャストダッシュボードはフォーキャストを信頼できるものにはしません。

グラフより先に定義を直してください。ライフサイクルステージ、参入基準、オーナー、信頼できる情報源のルールを定義してください。それからレポーティングを構築してください。

3. Sales OpsがRevOpsに名前だけ変わる

Sales Opsは価値がありますが、名前を変えるだけではクロスファンクショナルな権限は生まれません。

チームが依然としてセールスレポート、セールスステージ、CRM管理だけを所有しているなら、それは肩書が広くなっただけのSales Opsです。RevOpsには、マーケティング、セールス、CS、財務、データ、システムにまたがる権限が必要です。

違いについてはRevOps対Sales Opsをご覧ください。

4. すべてのチームが自分だけの信頼できる情報源を持ち続ける

マーケティングはMAPからレポートします。セールスはCRMからレポートします。CSはカスタマーサクセスプラットフォームからレポートします。財務は請求システムとスプレッドシートからレポートします。

それぞれのシステムは局所的には有用かもしれませんが、会社は4つの矛盾する「真実」から収益を運営することはできません。

この失敗は経営会議で表面化します。マーケティングはあるキャンペーンが商談に影響したと言います。セールスは商談のソースはアウトバウンドだと言います。財務はどちらの数字も受注レポートと一致しないと言います。会議は意思決定ではなくデータの突き合わせになってしまいます。

これを直すには、収益データの信頼できる情報源と収益データ辞書を使ってください。

5. 自動化が壊れたプロセスを拡大してしまう

自動化は運用設計の代わりにはなりません。

リード資格判定のルールが不明確なら、自動ルーティングはより速く混乱を生みます。ステージ基準が弱いなら、自動化されたフォーキャストスコアリングは自信満々のノイズを生み出します。引き継ぎデータが不完全なら、ワークフロー自動化は不完全なレコードをより速く送り出すだけです。

良い自動化は明確なルールを強制します。悪い自動化は不明確なルールを覆い隠します。

まずワークフローを直し、自動化は後回しにしてください。フルファネルSLAモデル、ステージ退出基準、RevOps自動化から始めてください。

6. RevOpsがチケット処理の窓口になってしまう

フィールドの依頼。レポートの依頼。ダッシュボードの依頼。インポートの依頼。連携の依頼。

そうした作業はすべて必要かもしれませんが、それがキャパシティのすべてを消費してしまうなら、RevOpsはシステムを改善できません。ヘルプデスクになってしまいます。

その症状は、毎週忙しいのに構造的には何も良くならないという形で表れます。同じデータの問題が繰り返し起こります。同じ引き継ぎの問題が繰り返し起こります。同じ会議が同じ苦情を生み出します。

主体的に動けるキャパシティを守ってください。健全なRevOpsのロードマップには、依頼対応だけでなく、ガバナンス、プロセス改善、データ品質、ケイデンスの仕事も含まれるべきです。

7. ケイデンスが会議と混同される

会議を増やしても、運用上の規律は生まれません。

収益のケイデンスには、目的、データパケット、意思決定のオーナー、フォローアップの経路が必要です。フォーキャストの会議は収益リスクを点検するべきです。ファネルレビューはコンバージョンと速度を点検するべきです。システムガバナンスのレビューは変更を承認または却下するべきです。

会議が意思決定、オーナー、行動の変化なしに終わるなら、それはケイデンスではありません。単なる議論です。

会議の乱立を直すには、収益ケイデンスを設計してください。

8. データ品質がクリーンアップ作業として扱われる

不良なCRMデータは四半期ごとのクリーンアップの問題ではありません。継続的な運用上の問題です。

Salesforceの調査によると、営業担当者は自分の時間の大部分を非セールス業務に費やしていることがわかっています。データ入力の負担が大きすぎるか、ガバナンスが弱いなら、CRMはクリーンアップのたびに再び劣化していきます。

入力プロセス、必須フィールド、重複ルール、定着モデルを直してください。CRMデータ衛生、CRM定着オペレーティングモデル、必須フィールド対有用フィールドをご覧ください。

9. RevOpsがアウトプットだけで評価される

RevOpsが出荷したレポート数やクローズしたチケット数で評価されると、チームは活動量を最適化するようになります。

より良い評価指標には、フォーキャストの精度、ステージの衛生状態、SLA遵守率、引き継ぎの完全性、ソースから収益までの可視性、フィールドの完全性、手作業レポーティングの削減量などがあります。

これらの指標を定義するには、RevOpsメトリクスを使ってください。

失敗のパターン

ほとんどのRevOpsの失敗は、同じ流れをたどります。

1. 経営陣がクロスファンクショナルな収益の摩擦に気づく。
2. RevOps担当者またはチームが割り当てられる。
3. そのチームは、レポートとシステムを素早く直すよう求められる。
4. 意思決定権は不明確なままである。
5. 各部門は共有すべき定義に対する局所的なコントロールを維持し続ける。
6. RevOpsが依頼処理の窓口になる。
7. ダッシュボードは改善するが、オペレーティングシステムは改善しない。

対処法は、もっと頑張ることではありません。マンデートをリセットすることです。

失敗を早期に察知する方法

RevOpsの失敗は通常、経営層がそれを名指しする前に表面化します。

以下のシグナルに注意してください。

• 収益部門のリーダーが、ダッシュボードを信用していないために同じレポートを繰り返し求める。
• マーケティングとセールスが、ファネルレビューのたびに定義について議論する。
• 財務が別のフォーキャストファイルを維持している。
• CSが、顧客引き継ぎの問題は「セールスの規律の問題だ」と言うが、ワークフローは何も変わらない。
• RevOpsが週の半分以上を単発の依頼対応に費やしている。
• CRMのフィールドが、廃止されるより速いペースで追加されている。
• 誰も文書化していないワークフローに自動化が追加されている。
• 経営陣がRevOpsの活動を称賛するが、どの収益プロセスが改善したのかを言えない。

これらのシグナルは、チームが悪いという意味ではありません。オペレーティングモデルが弱いという意味です。

リーダーがすべき違う対応

経営層は、意図せずRevOpsの失敗を引き起こしていることがよくあります。

彼らは定義よりも先にダッシュボードを求めます。引き継ぎについて合意する前に自動化を求めます。すべての部門にフィールドの変更を許可しながら、RevOpsにデータ品質の責任を負わせます。RevOpsを戦略的だと呼びながら、あらゆる緊急のレポート依頼を同じチームに回します。

経営層側の対処はシンプルですが、居心地の悪いものです。RevOpsに本当の意思決定権を与えることです。

それには、次のように言う権利も含まれます。

• オーナーのいないフィールドには「ノー」と言う。
• 不明確な定義に基づくダッシュボードには「ノー」と言う。
• プロセス設計より先の自動化には「ノー」と言う。
• 共有レポーティングを壊すシステム変更には「ノー」と言う。
• ガバナンスのケイデンスに乗せるべき緊急の依頼には「ノー」と言う。

RevOpsは、収益運用の質を担うオーナーであると同時に、無制限のサービスデスクであることはできません。リーダーは、どちらの役割をより重視するかを選ばなければなりません。

再建の例

フォーキャストが信頼されていない会社を考えてみましょう。

弱い対応は、RevOpsにより良いフォーキャストダッシュボードを求めることです。より強い対応は、なぜフォーキャストが弱いのかを診断することです。

• ステージは根拠に基づいていますか?
• クローズ予定日は古くなっていませんか?
• コミット基準は明確ですか?
• マネージャーは次のステップを点検していますか?
• 必須フィールドは完全に埋まっていますか?
• 財務はフォーキャストカテゴリーに同意していますか?

対処法には、フォーキャストガバナンス、コミット基準、パイプライン点検ケイデンスが関わってくるかもしれません。ダッシュボードは、運用ルールの後に来るものです。

企業ステージ別の失敗パターン

RevOpsは、ステージによって異なる形で失敗します。

対処法はステージに合わせるべきです。アーリーステージの企業は、ガバナンスよりも明確さをより必要とするかもしれません。成熟した企業は、より強い変更管理と、より優れた申請の規律を必要とするかもしれません。

健全なRevOpsはどのような姿か

健全なRevOpsには、いくつかの観察可能な特徴があります。

• リーダーが同じ収益の定義を使っている。
• フォーキャストの会議がリスクについてであり、単なる整理作業ではない。
• 引き継ぎにオーナーと必須データが設定されている。
• ダッシュボードが意思決定に結び付いている。
• CRMの変更にガバナンスの経路がある。
• RevOpsが毎月ロードマップに割けるキャパシティを持っている。
• 各部門が、いつ局所的に動いてよく、いつ承認が必要かを理解している。

最もシンプルなテストは、チーム間で何かが壊れたときに、誰が修正を担うのか全員が知っているかどうかです。もし知らないなら、RevOpsにはまだ必要な権限や明確さが欠けています。

再建の過程で測定すべきこと

活動量で再建を測ってはいけません。

オペレーティングシステムが健全になっているかどうかを追跡してください。

• 必須フィールドの完全性が改善している。
• MQL却下理由が一貫して記録されている。
• フォーキャストのクリーンアップ時間が減っている。
• 受注後の引き継ぎの完全性が上がっている。
• 重複レコードの発生率が下がっている。
• 手作業の突き合わせを必要とするレポートが減っている。
• 収益に関する会議が、データ論争ではなく意思決定を生んでいる。

これらの指標は、RevOpsが根本原因を直せているかどうかを示します。チームは多くのチケットをクローズしながら、それでもシステムを弱いままにしておくことができます。再建の取り組みは、現在のバックログを片付けるだけでなく、将来の作業を楽にするものであるべきです。

これらの指標をCRO、財務、各部門のリーダーと共に毎月レビューしてください。四半期を経ても指標が改善しないなら、その再建計画はおそらく症状だけを対処しています。そのときこそ、同じRevOpsチームにもっと速く働くよう求めるのではなく、意思決定権、報告ライン、申請ルールを見直すべきタイミングです。

このレビューは率直であるべきです。リーダーが共有された定義を弱める局所的な例外を承認し続けるなら、RevOpsは再建されません。すべての緊急ダッシュボード依頼がガバナンスを回避し続けるなら、レポートの質は改善しません。再建には、RevOpsだけでなく、会社全体のリーダーシップの行動が変わることが必要です。

それこそが本当のテストです。

再建計画

RevOpsがすでに失敗しているなら、新しいダッシュボードやツールから始めないでください。

ここから始めてください。

この順序によって、これ以上の作業を追加する前に、RevOpsに必要な権限と焦点が与えられます。

再建計画のまとめ

RevOpsが失敗するのは、通常、アイデアが弱いからではなく、運用上の理由からです。この機能には、マンデート、意思決定権、明確な優先順位付け、そしてデータ、プロセス、システム、経営層のケイデンスを結び付ける明確な方法が必要です。

それらの要素なしには、RevOpsは、改善することを期待されているシステムに対する権限を持たない、便利なチームになってしまいます。失敗しているRevOps機能は、まずオーナーシップを明確にし、次に最も漏れの大きい引き継ぎと信頼できる情報源の問題を直すことで修復すべきです。

その修復作業は目に見える形にしなければなりません。

リーダーは、どのオーナーシップの決定が変わったのか、どの引き継ぎが改善したのか、どのレポートが再び信頼されるようになったのかを見る必要があります。

月曜日から始める再建アクション

RevOpsがすでに苦戦しているなら、少数の目に見えるアクションから始めてください。

これらのアクションは全面的な変革ではありません。本当の問題を見るのに十分なコントロールを生み出すものです。

再建の順序付け

すべてのツールとダッシュボードを一度に作り直すことで再建しようとしないでください。

この順序を使ってください。

1. マンデートとスポンサーを明確にする。
2. 価値の低い依頼受付を止める。
3. ライフサイクルの定義を直す。
4. 最もリスクの高い引き継ぎを安定させる。
5. 信頼される経営層向けダッシュボードを一つ選ぶ。
6. システムの変更管理を追加する。
7. ケイデンスを意思決定を中心に再構築する。
8. 信頼が改善した後にのみロードマップを拡大する。

この順序が機能するのは、RevOpsの失敗が通常、積み重なって起きるからです。弱い権限は貧弱な受付を生みます。貧弱な受付はプロセス作業を妨げます。弱いプロセスはダッシュボードへの不信を生みます。不信されたダッシュボードはさらなる手作業の依頼を生みます。再建は、そのループを断ち切らなければなりません。

よくある質問

なぜRevOpsチームは失敗するのですか?

ほとんどの失敗は、マンデートが不明確なことが原因です。定義、データ、システム、引き継ぎを統治する権限がないまま、クロスファンクショナルな収益パフォーマンスの改善を求められています。

RevOpsが失敗している最初の兆候は何ですか?

最初の兆候は通常、信頼の崩壊です。リーダーがダッシュボードを信用しなくなり、各チームがシャドースプレッドシートを使い始め、会議が意思決定ではなくデータをめぐる言い争いになります。

失敗しているRevOps機能をどう直しますか?

憲章を書き直し、意思決定権を明確にし、ライフサイクルの定義を簡素化し、コアとなるデータモデルを整理し、主体的なシステム作業のためにRevOpsのキャパシティを守ってください。

RevOpsの失敗は、通常は人の問題ですか?

通常はそうではありません。むしろ、不明確なオーナーシップ、弱いガバナンス、貧弱なデータ、あるいは権限を伴わずに責任だけをRevOpsに負わせる報告ラインといった、運用モデルの問題であることのほうが多いです。

さらに詳しく

• 収益オペレーションフレームワーク
• RevOps RACI
• CRMフィールドガバナンス
• フォーキャストガバナンス