集中型RevOps vs 組み込み型RevOps：自社に合ったオペレーティングモデルはどちらか

集中型RevOpsと組み込み型RevOpsは、それぞれ異なる課題を解決します。

集中型RevOpsは標準を守ります。組み込み型RevOpsは文脈を守ります。ハイブリッド型RevOpsはその両方を維持しようとします。

選択を誤ると、ガバナンスの遅さか、あるいは実行の分断のどちらかを招くことになります。

より広い組織構造については、RevOpsチーム構造から始めてください。

ForresterによるRevOpsの組織設計に関する調査は、RevOpsの設計を単なるレポートラインの決定ではなく、部門横断的な選択として捉えています。Forresterによるテクノロジーアライメントに関する調査も、オペレーティングモデルとツールを切り離して考えられない理由を示しています。

組織モデルによって、標準がどのように設定されるか、オペレーターが業務にどれだけ近い場所にいるか、そして共有データを壊さずに会社がどれだけ迅速に変化できるかが決まります。

運用上の重要事項

• 集中型RevOpsは、共有される標準、信頼できる情報源、部門横断的なガバナンスを守ります。
• 組み込み型RevOpsは、スピード、現場の文脈、機能部門への定着を守ります。
• ハイブリッド型RevOpsは、意思決定権限が明確であれば機能します。共有される定義やシステムには中央のガバナンスを、現場のワークフローには組み込み型のサポートを充てるという形です。
• 最適なモデルは現在の運用リスクによって決まります。定義やダッシュボードが分断されているなら、より集中化してください。中央のRevOpsが遅すぎてチームが回避策を作っているなら、より多くの文脈を組み込んでください。

3つのモデル

ほとんどの企業は複数のモデルを経て変化していきます。創業者主導の営業チームは、1人のゼネラリストから始めるかもしれません。成長段階の企業は、信頼できる情報源の問題を解決するために集中化することがあります。より大きな企業は、中央のガバナンスを維持しながら各機能部門の近くに専門家を配置することがあります。

よくある間違いは、モデルをアイデンティティとして扱ってしまうことです。モデルは、会社の現在の運用リスクへの対応であるべきです。

まず運用リスクを診断する

モデルが解決すべき課題から始めてください。

この診断により、組織設計がイデオロギー的なものになることを防げます。集中型がデフォルトでより成熟しているわけではありません。組み込み型がデフォルトでより機敏なわけでもありません。どちらも、解決すべき課題次第でうまく機能することもあれば、失敗することもあります。

誤ったモデルは、通常は行動として現れます。過度に集中化されたモデルでは、チームは裏でスプレッドシートや個人的なワークフローを作ります。過度に組み込み型のモデルでは、経営陣は矛盾する定義や重複したツールを目にします。弱いハイブリッドモデルでは、誰もが「共同オーナーシップ」と言いながら、誰も決定権を持っていません。

集中型RevOps

集中型RevOpsは、会社が1つの収益オペレーティングシステムを必要とする場合にうまく機能します。

以下の場合に最も強みを発揮します。

• ダッシュボードの数字が一致しない。
• ツールが増殖している。
• データ品質が一貫していない。
• マーケティング、営業、CSが共有ガバナンスを必要としている。
• 財務が1つの信頼できる収益ビューを必要としている。

リスクは応答性です。すべてのリクエストが中央のキューを通る場合、各チームはRevOpsを迂回して回避策を作るかもしれません。それがシャドーシステムを生み出します。

実践における集中型モデル

集中型モデルには通常、1人のRevOpsリーダーと共有の専門家がいます。

• CRMとシステム
• 分析とダッシュボード
• プロセスとガバナンス
• フォーキャストオペレーション
• ライフサイクルと引き継ぎの設計

リクエストは中央のロードマップに流れ込みます。RevOpsは、単なる機能部門ごとの緊急度ではなく、会社全体へのインパクトに基づいて優先順位を付けます。

このモデルは、リーダーが1つの信頼できる情報源を必要としている場合に強力です。各チームが独自のフィールド、ダッシュボード、ワークフロー、定義を作ってしまうことを防ぐのに役立ちます。

しかし、集中型RevOpsは日々の業務から遠くなりすぎることがあります。営業マネージャーがRevOpsは営業担当者のワークフローを理解していないと感じれば、裏でスプレッドシートを作るでしょう。マーケティングがキャンペーンの文脈が失われていると感じれば、独自のレポーティングを作るでしょう。CSが更新プロセスが軽視されていると感じれば、独自のツールでリスクを管理するでしょう。

集中型RevOpsには、構造化された傾聴の仕組みが必要です。

• 機能部門向けのオフィスアワー
• マネージャーからの定期的な現場フィードバック
• GTMリーダーとの四半期ロードマップレビュー
• 明確な受付ルール
• よくあるリクエストに対する公表済みのサービスレベル

これがなければ、集中化は文脈を伴わない統制になってしまいます。

組み込み型RevOps

組み込み型オペレーションは、チームがスピードと文脈を必要としている場合にうまく機能します。

マーケティングオペレーションのパートナーはキャンペーンを深く理解しています。セールスオペレーションのパートナーはテリトリー、クォータ、営業担当者のワークフローを理解しています。CSオペレーションのパートナーはオンボーディングと更新のパターンを理解しています。

リスクは分断です。各機能部門が局所的に最適化し、共有の収益システムを損なう可能性があります。

組み込み型RevOpsには、ライフサイクル定義、フィールド、ダッシュボード、システム変更に関する中央の標準が必要です。

実践における組み込み型モデル

組み込み型モデルでは、オペレーターを各機能部門の内部に配置します。

• マーケティング内のマーケティングオペレーション
• 営業内のセールスオペレーション
• カスタマーサクセス内のCSオペレーション
• 経営陣または財務に近い収益分析

その利点はスピードです。オペレーターは現場の詳細を理解しています。セールスオペレーションのパートナーは、営業担当者が実際にどう働いているかを見ることができます。マーケティングオペレーションのパートナーは、キャンペーンワークフローを素早く調整できます。CSオペレーションのパートナーは、更新に関する会話に基づいてヘルスシグナルを調整できます。

リスクは局所的な最適化です。

マーケティングは財務がブッキングの一貫性を必要としている一方で、キャンペーンレポーティング用のソースフィールドを独自に定義するかもしれません。営業は、担当者がデータ入力に抵抗する中でマネージャーの確認作業用にフィールドを追加するかもしれません。CSは、フォーキャストや拡大パイプラインとつながらないヘルスカテゴリーを構築するかもしれません。

組み込み型チームには、共有のRevOpsガバナンスレイヤーが必要です。

• 共通のライフサイクル定義
• 共有データディクショナリー
• 信頼できる情報源のレポーティングルール
• システム変更プロセス
• 部門横断的なRACI
• エグゼクティブへのエスカレーション経路

このレイヤーがなければ、組み込み型RevOpsは実質的にRevOpsではありません。それは現代風のラベルを付けた別々の機能部門オペレーションにすぎません。

ハイブリッド型RevOps

ハイブリッドは通常、ミッドマーケット企業にとって最良のモデルです。

中央RevOpsは以下を所有します。

• レベニューライフサイクル
• データディクショナリー
• 信頼できる情報源
• システムガバナンス
• エグゼクティブダッシュボード
• 運用リズム

機能部門のパートナーは以下を所有します。

• マーケティングオペレーションの実行
• セールスオペレーションの実行
• CSオペレーションの実行
• 現場のワークフロー詳細
• 機能部門のレポーティングニーズ

このモデルは、意思決定権限がRevOps RACIとして文書化されている場合にのみ機能します。

実践におけるハイブリッドモデル

ハイブリッドRevOpsは、標準と文脈の両方を必要とする複雑性を持つに至った企業にとって、しばしば最も強力なモデルとなります。

中央RevOpsはオペレーティングアーキテクチャを所有します。

• ライフサイクルモデル
• データディクショナリー
• ガバナンスケイデンス
• エグゼクティブダッシュボード
• フォーキャストプロセス
• システム変更管理
• 部門横断的なロードマップ

組み込み型パートナーは現場の実行を所有します。

• キャンペーンオペレーション
• テリトリーとクォータのサポート
• 営業ワークフローの詳細
• CSのオンボーディングと更新ワークフロー
• 機能部門のレポーティングニーズ
• 現場での定着に関するフィードバック

このモデルは、どの意思決定が現場のもので、どれが共有のものかを全員が把握している場合に機能します。

例えば、マーケティングは社内利用のキャンペーン命名規則を決められますが、収益レポーティングに供給されるソースフィールドはRevOpsがガバナンスすべきです。営業は担当者のワークフローを管理できますが、ステージ定義と予測カテゴリールールはRevOpsがガバナンスすべきです。CSはヘルスプレイブックを管理できますが、どの更新・拡大シグナルを収益レポーティングに反映させるかはRevOpsがガバナンスすべきです。

選び方

信頼と標準化が主な課題であれば、集中型を選んでください。

スピードと機能面でのニュアンスが主な課題であれば、組み込み型を選んでください。

すべての現場のリクエストを中央のキューの背後で待たせることなく標準化が必要な場合は、ハイブリッド型を選んでください。

現在のモデルを診断する方法

以下の問いを立ててください。

• 各チームは同じライフサイクル定義を使っているか
• 財務は営業リーダーシップと同じダッシュボードを信頼しているか
• 現場のオペレーションチームは部門横断的なレビューなしにCRMフィールドを変更できるか
• マネージャーはシステム変更をどこに依頼すればよいか把握しているか
• 組み込み型オペレーターは機能面でのスピードだけで評価されているか
• 中央RevOpsは日々のワークフローを理解しているか
• ツールの意思決定は下流への影響についてレビューされているか

標準が弱いなら、より多くの権限を中央RevOpsに移してください。

実行が遅く、チームが回避策を作っているなら、より多くの文脈を機能部門の近くに移してください。

両方とも当てはまるなら、会社にはおそらく、より明確な意思決定権限を持つハイブリッドモデルが必要です。

フェーズ別モデル

モデルは会社の変化に合わせて変化すべきです。従業員50名でうまく機能した構造が、200名では失敗することがあります。

意思決定権限の比較

モデル間の本質的な違いは意思決定権限にあります。

この表がこの選択の核心です。レポートラインよりも、誰が共有される運用資産を変更できるかの方が重要です。

アンチパターン

チケットキューとしての集中型RevOps。 チームは過負荷になり、距離が生まれます。機能部門は回避策を作ります。

標準のない組み込み型RevOps。 各機能部門は速く動きますが、会社は共有される収益ビューを失います。

RACIのないハイブリッド型RevOps。 全員がハイブリッドモデルだと言いますが、誰も決定権を持っていません。

レポートラインをオペレーティングモデルと誤解すること。 RevOpsはCRO、COO、財務のいずれに報告していても、集中型、組み込み型、ハイブリッド型のいずれでも運用できます。

財務の関与がない。 レポーティングと計画の定義が運用ダッシュボードから乖離していきます。

正しいモデルは摩擦を減らすべきであり、単に組織図を描き直すだけのものであってはなりません。

移行計画

モデルを変更する必要がある場合は、段階的に進めてください。

1. 定義、ダッシュボード、フィールド、ワークフローが一致していない箇所を監査する。
2. どの資産を中央でガバナンスすべきか決定する。
3. どのチームが組み込み型サポートを必要としているか特定する。
4. RevOpsの憲章とRACIを文書化する。
5. 受付とロードマップレビューを共有のケイデンスに組み込む。
6. オペレーターが現場でのサービスと共有システムの健全性の両方で評価されるようスコアカードを更新する。

先に組織再編を行い、後からオーナーシップを定義するようなことはしないでください。それは数か月にわたる混乱を生みます。

モデル別スコアカード

そのモデルが解決すべき課題に基づいて評価してください。

集中型RevOpsについては、以下を追跡してください。

• ダッシュボードへの信頼
• 重複レポーティングの削減
• データ品質の改善
• システム変更のサイクルタイム
• フォーキャストプロセスの一貫性
• 部門横断的なロードマップの完了状況

組み込み型RevOpsについては、以下を追跡してください。

• 機能部門からのリクエストの対応時間
• 現場のワークフローの定着
• マネージャーの満足度
• 現場でのプロセス改善
• 中央の定義への準拠
• システム外で作られた回避策の数

ハイブリッド型RevOpsについては、両方を追跡してください。

• 共有定義の遵守
• 機能面でのスピード
• 中央ロードマップの実施状況
• 現場での定着
• エスカレーション件数
• 部門横断的な意見対立の解決時間

集中型チームが信頼されているが遅すぎる場合、そのモデルにはより多くの組み込み型サポートが必要です。組み込み型チームが速いが定義がずれてきている場合、そのモデルにはより強力な中央ガバナンスが必要です。ハイブリッドチームが混乱している場合、通常の原因は意思決定権限です。

レポートラインとオペレーティングモデル

レポートラインとオペレーティングモデルを混同しないでください。

RevOpsは以下に報告できます。

• CRO
• COO
• CFO
• CEO
• チーフカスタマーオフィサー

マンデートが明確であれば、いずれでも機能し得ます。

オペレーティングモデルは別の問いに答えるものです。RevOpsは日々どのように事業に貢献するのか、というものです。

あるチームはCROに報告しながらも、マーケティング、営業、CS、財務にまたがって集中的に運用できます。あるチームはCOOに報告しながらも、各機能部門に専門家を組み込むことができます。あるチームは財務に報告しながらも、レポーティングを超えた運用ガバナンスを所有できます。

危険なのは、レポートラインが静かにマンデートを狭めてしまうことです。RevOpsが営業に報告し、すべての決定が共有データ品質よりも営業のスピードを優先するのであれば、マーケティング、CS、財務はその機能を信頼しなくなるでしょう。RevOpsが財務に報告し、レポーティング統制だけに焦点を当てるのであれば、営業とマーケティングはそれをコンプライアンスチームと見なすかもしれません。

エグゼクティブスポンサーは中立性を守るべきです。RevOpsには、共有システムをガバナンスできるだけの距離と、業務を理解できるだけの近さの両方が必要です。

実践的な推奨事項

従業員50名から500名の多くのB2B SaaSやサービス企業にとって、軽量なハイブリッドモデルが最良の出発点です。

これは通常、以下を意味します。

• 中央RevOpsオーナーを1名置く
• 明確なライフサイクルとデータガバナンス
• マーケティング、営業、CS、財務との緊密なパートナーシップ
• 最初はフル組み込み型チームではなく、指名された機能部門の窓口担当者
• 月次のシステム・レポーティングガバナンスケイデンス
• 四半期ごとのRevOpsロードマップ

規模が拡大するにつれて、会社は組み込み型パートナーを追加できます。マーケティングには専任のオペレーションパートナーがつくかもしれません。営業にはテリトリー、報酬、イネーブルメントのオペレーションがつくかもしれません。CSにはヘルス、更新、拡大ワークフロー用のCSオペレーションがつくかもしれません。しかし、そのすべてが1つの収益オペレーティングモデルに従うべきです。

これにより、早すぎる段階での過剰構築を防ぎつつ、各チームが独自に問題を解決することで生じる分断も防げます。

導入準備チェックリスト

モデルを変更する前に、リーダーが以下について合意しているかを確認してください。

• どの収益定義が共有されるか
• どのリクエストが現場で処理できるか
• どの変更が中央レビューを必要とするか
• どのダッシュボードが信頼できる情報源か
• どの機能部門がより緊密なサポートを必要としているか
• どのエグゼクティブスポンサーがトレードオフを解決するか

これらの問いに答えが出ていなければ、組織図の箱を描き直しても運用上の課題は解決しません。

移行のリスク

RevOpsモデルを変更すると、意思決定権限を移す前に人を移してしまうことでリスクが生まれます。

よくある移行のリスク:

移行は3つの成果物、憲章、RACI、ロードマップで管理してください。憲章はマンデートを説明します。RACIは誰が決定するかを説明します。ロードマップは、そのモデルがまず解決する共有課題を示します。

短期的なリクエスト対応スピードだけで新しいモデルを判断しないでください。集中化への移行は、共有レポーティングへの信頼を高める一方で、最初は現場のリクエスト対応を遅くするかもしれません。組み込み型サポートへの移行は、現場のスピードを高める一方で、分断を防ぐためのより強力なガバナンスを必要とするかもしれません。運用指標は、その変更の理由と一致させるべきです。

モデル選定ワークショップ

モデルを変更する前に、短いワークショップを実施してください。

アジェンダ:

1. 直近四半期で繰り返し発生したRevOps関連の対立を一覧化する。
2. 各対立を、標準の問題、文脈の問題、キャパシティの問題、意思決定権限の問題のいずれかに分類する。
3. どの資産を中央でガバナンスすべきか特定する。
4. どのワークフローがより緊密な機能部門のサポートを必要としているか特定する。
5. どの意思決定を現場に任せ、どれを中央承認が必要とするか決定する。
6. 憲章、RACI、ロードマップ、受付プロセスを更新する。

このワークショップにより、組織設計をエビデンスに基づいたものにできます。主な課題が矛盾するダッシュボード、重複フィールド、財務の不信であれば、答えはより多くの組み込み型の自律性ではありません。主な課題が遅いサポート、マネージャーの定着不足、中央RevOpsがワークフローの文脈を欠いていることであれば、答えはより多くの中央統制ではありません。

モデルは、リーダーが想定している摩擦ではなく、実際の摩擦を解決すべきものです。

モデル変更のトリガー

他社が異なる構造を使っているという理由だけでRevOpsモデルを変更しないでください。

運用上のエビデンスが明確な場合にモデルを変更してください。

モデルは特定の運用上の失敗を解決するために変更すべきです。失敗が不明確であれば、まず憲章と受付を修正してください。

FAQ

集中型RevOpsの方が優れていますか?

必ずしもそうではありません。ガバナンスと信頼できる情報源の課題には優れています。チームがボトルネックになれば、スピードの面では劣ることがあります。

組み込み型RevOpsは本当にRevOpsと言えますか?

組み込み型のオペレーターが共有のRevOpsガバナンスに従っているなら、そう言えます。共有ガバナンスがなければ、それは通常、別々の機能部門オペレーションです。

100名規模のB2B企業にはどのモデルが適していますか?

通常は軽量なハイブリッド型です。1人のRevOpsオーナーが、マーケティング、営業、CSと緊密な機能連携を取る形です。

学びを深める

• RevOps憲章
• RevOps最初の採用
• RevOps vs マーケティングオペレーション vs セールスオペレーション
• RACIマトリクス