RevOps RACI: Revenue Operationsのオーナーシップマトリクス

RevOpsは、その業務が重要だと全員が同意しても、誰がその意思決定を所有するかで合意できないときに崩れます。

新しいライフサイクルステージを承認するのは誰か。ソースフィールドを所有するのは誰か。リードルーティングルールを変更するかどうかを決めるのは誰か。マーケティングのアトリビューションとファイナンスのレポーティングの対立を解決するのは誰か。

RevOpsのRACIは、これらの問いが政治的になる前に答えを出します。

基本モデルが必要な場合は、RACIマトリクスとRACI対RASCI対DACIを参照してください。

PMIはRACIを、業務がチーム間で漏れないよう責任と説明責任を明確にする方法として説明しています。RevOpsでは、業務がマーケティング、営業、カスタマーサクセス、ファイナンス、データ、システムを横断するため、この明確さが重要になります。

ForresterのRevOps責任モデルは、RevOpsが本質的に広範であることを思い出させてくれる有用な指摘です。RACIは、その広さがあいまいさに転じることを防ぎます。

押さえておくべき運用の要点

• RevOpsのRACIは、プロジェクトタスクだけでなく、繰り返し発生する意思決定をマッピングすべきです。難しい問いは通常、定義、データの所有、システムの変更、予測ルール、引き継ぎ、経営層向けレポーティングに関するものです。
• 各意思決定には一人の説明責任者が必要です。共有のインプットは健全ですが、共有の説明責任はしばしば遅延と政治的なエスカレーションを生み出します。
• RevOpsは、権限を伴わずに成果への説明責任を負わされるべきではありません。RevOpsがデータ品質を所有するなら、フィールドやワークフローの変更を承認、却下、エスカレーションできる必要があります。
• RACIは、採用の使命とセットになって初めて最も機能します。最初のRevOps採用には、オーナーシップマトリクスに沿った意思決定権限が必要です。

RevOpsにおけるRACIの意味

RevOpsは、ローカルな実行に別のチームが責任を負う場合でも、そのシステムに対する説明責任を負わなければならないことがよくあります。

この区別は重要です。営業マネージャーは、担当者に次のステップを入力するようコーチする責任を負うかもしれません。RevOpsは、その次のステップを有用にするステージの定義、必須フィールド、ダッシュボードのルール、点検のリズムに対する説明責任を負うかもしれません。同じ商談データが計画に反映されるため、ファイナンスは相談を受けるかもしれません。

だからこそ、RevOpsのRACI設計には、通常のプロジェクトRACIよりも多くの配慮が必要です。アウトプットは単一のプロジェクトの成果物ではありません。継続的なオペレーティングモデルです。意思決定権限がどこに落ち着くかは、一元型RevOps対埋め込み型RevOpsのどちらを運用しているかにも左右されます。

RevOpsの中核となるRACI

この表は出発点です。自社の組織構成に合わせて調整してください。

RevOpsのRACIを構築する方法

部門ではなく意思決定から始めてください。

弱いRACIは、チームのリストから始めて「各チームは何を所有しているか」を問います。これは通常、既存の政治力学をそのまま反映してしまいます。より強いRACIは、摩擦を生む繰り返しの意思決定から始まります。

• 何が精査済みリードとみなされるか
• 商談はいつステージ3に入れるか
• 誰が新しい必須フィールドを作成できるか
• パイプラインのソース・オブ・トゥルースはどのレポートか
• ルーティングの変更を誰が承認するか
• 予測カテゴリーを誰が決めるか
• 営業からCSに渡すべきデータは何か
• 解約理由の分類を誰が所有するか

意思決定を洗い出したら、役割を割り当ててください。

各意思決定について、一人の説明責任者を選んでください。次に、誰が実際に作業を行い、誰がインプットを提供しなければならず、誰が報告を受ける必要があるかを特定してください。説明責任者が二人いる場合は、そこで立ち止まって解消してください。共有のインプットは問題ありませんが、共有の説明責任は通常、誰も最終判断を下せない状態を生みます。

まず意思決定のインベントリを構築する

最も有用なRevOpsのRACIは、意思決定のインベントリから始まります。

混乱を生む繰り返しの意思決定を洗い出してください。

このインベントリは、理論的な網羅性ではなく実際の摩擦に基づくべきです。直近の四半期から実例を集めてください。対立したレポート、失敗した引き継ぎ、混乱したフィールドの依頼、予測をめぐる意見の相違、ルーティングの例外、ダッシュボードの再構築。これらが、RACIが最初に明確化すべき意思決定です。

インベントリができたら、リスク別に意思決定をグループ化してください。低リスクの意思決定は、RevOpsとシステムオーナーで迅速に進められます。高リスクの意思決定にはファイナンス、機能部門のリーダーシップ、または役員承認が必要です。

このリスクビューにより、RACIがすべての小さな変更を遅らせることを防げます。また、高インパクトな変更が何気ない依頼を通じて起きることも防げます。

収益ライフサイクル別のRACI

有用なRevOpsのRACIは、ライフサイクル全体でオーナーシップをマッピングします。

このビューは、なぜRevOpsが営業支援機能だけであってはならないのかをリーダーが理解する助けになります。同じオペレーティングシステムがジャーニー全体にまたがっています。

CRMとレポーティングの変更に関するRACI

CRMの変更は、あいまいなオーナーシップが高くつく場面です。

システムの変更には別のRACIを使ってください。

これにより、最もよくある過ち、つまりどこかの部門がローカルなニーズのために共有データ構造を変更してしまうことを防げます。

対立を解決するためのルール

優れたRACIであっても、すべての対立をなくすことはできません。

エスカレーションルールを追加してください。

• 対立が一つの部門にしか影響しない場合、その部門のリーダーが決定する。
• 対立が共有データに影響する場合、RevOpsが決定するか推奨する。
• 対立が予測、計画、取締役会報告に影響する場合、RevOpsとファイナンスは公開前に足並みをそろえなければならない。
• 対立がチームをまたいで顧客体験に影響する場合、CROまたはCOOが決定する。
• 対立が会社レベルのトレードオフに影響する場合、役員スポンサーが決定する。

エスカレーションルールが重要なのは、RevOpsがしばしば正当なニーズを持つ強力なリーダー同士の間に立つからです。RACIは、対立が個人的なものになる前に、意思決定の経路を可視化すべきです。

RACIを使うためのルール

説明責任者は一人。 相談を受ける人が複数いるのは問題ありません。説明責任者が複数いると膠着状態を生みます。

機能部門のリーダーは引き続きパフォーマンスを所有する。 RevOpsはシステムを所有できますが、営業リーダーは引き続き営業パフォーマンスを、CSリーダーは引き続き継続の実行を所有します。

意思決定権限は責任と一致していなければならない。 フィールドガバナンスを強制できないなら、RevOpsをデータ品質に対して説明責任者にしてはいけません。

組織変更後は見直す。 チーム、システム、GTMモーションが変わると、RACIは古くなります。

よくあるRACIの過ち

説明責任者が多すぎる。 これは最もよくある失敗です。二人のリーダーが説明責任を負うなら、どちらもクリーンな使命を持てません。

RevOpsに実行責任はあるが権限がない。 価値の低いフィールドを却下したり、ステージ基準を変更したり、引き継ぎルールを強制したりできないなら、RevOpsをデータ品質に対して説明責任者にしてはいけません。

ファイナンスへの報告が遅すぎる。 ある指標が取締役会報告に登場するなら、定義が変わる前に通常ファイナンスに相談すべきです。

埋め込まれたオプスチームが異なるルールに従っている。 マーケティングオプス、セールスオプス、CSオプスはそれぞれの部門の近くにとどまってよいですが、共有の定義には一つのガバナンスモデルが必要です。

RACIが受付で使われていない。 依頼が依然として「これを作ってもらえますか」という形で届くなら、RevOpsはチケット対応窓口になってしまいます。受付では、その依頼がどの意思決定に影響するか、誰が説明責任を負うかを尋ねるべきです。

レビューのリズム

RevOpsのRACIは四半期ごとに、そして大きな変化の後にはより早く見直してください。

見直しのきっかけには次が含まれます。

• 新しいCRO、CMO、CSリーダー、CFO、またはCOOの着任
• 新しいGTMモーション
• 新しいCRMまたは大規模なシステムの変更
• 買収または事業部門の分割
• 新規ビジネス重視から拡大重視への移行
• 同じオーナーシップ領域をめぐる対立の繰り返し

RACIは静的な文書ではありません。運用上の合意です。リーダーがそれを使わなくなれば、オーナーシップは非公式な力学と繰り返しの議論に逆戻りしてしまいます。

ミーティングモデル

RACIは、フォルダに保管されるのではなく、繰り返し行われる運用ミーティングで使われるべきです。

次のミーティングで使ってください。

• RevOpsロードマップレビュー
• システム変更レビュー
• 予測ガバナンスレビュー
• ファネル定義レビュー
• リード品質レビュー
• 受注後引き継ぎレビュー
• ダッシュボード定義レビュー

各ミーティングは、同じオーナーシップに関する問いに答えるべきです。

• どの意思決定をしようとしているか
• 誰が説明責任を負うか
• 意思決定の前に誰に相談しなければならないか
• 意思決定の後に誰に報告する必要があるか
• どのデータやエビデンスが必要か
• 意思決定の後、システムの何が変わるか

これによりRACIは実践的になります。リーダーは文書を暗記する必要はありません。収益システムが変わるときにオーナーシップの言葉を使う習慣が必要なだけです。

例: リードルーティングの変更

営業がエンタープライズリードをシニアAEに直接ルーティングしたいと考える一方、マーケティングは見極めのためにまずSDRにルーティングしたいと考えているとします。

RACIがなければ、これは好みをめぐる議論になります。

RACIがあれば次のようになります。

• RevOpsはルーティングロジックとSLAへの影響のマッピングに実行責任を負う。
• CROは収益ワークフローの意思決定に説明責任を負う。
• マーケティング、SDRリーダーシップ、営業マネージャー、ファイナンスが相談を受ける。
• SDR、AE、マーケティングキャンペーンのオーナーは変更後に報告を受ける。

RevOpsはその後、応答時間、受け入れ率、コンバージョン率、オーナーのキャパシティ、レポーティングへの影響といった運用上のインパクトをテストできます。RACIは戦略を決めるものではありませんが、意思決定の経路をクリーンにします。

例: 新しい必須フィールド

必須フィールドは摩擦のよくある原因です。

営業はフィールドが担当者のワークフローを遅らせるため抵抗するかもしれません。マーケティングはより多くのセグメンテーションデータを望むかもしれません。CSは引き継ぎの文脈を必要とするかもしれません。ファイナンスはよりクリーンなレポーティングを必要とするかもしれません。

RACIは、フィールドの価値とフィールドのオーナーシップを切り分ける助けになります。

• 依頼元のチームは、そのフィールドが支える意思決定を説明する実行責任を負う。
• RevOpsはフィールドガバナンスに説明責任を負う。
• システムは設定に実行責任を負う。
• 影響を受けるマネージャーは相談を受ける。
• ユーザーは明確な展開ノートとともに報告を受ける。

RevOpsは、そのフィールドが実際の意思決定やワークフローを支える場合にのみ承認すべきです。単発の好奇心にしか役立たないなら、任意のままにするか、別の入力ポイントに移すべきです。

権限は説明責任と一致していなければならない

RACIは紙の上ではきれいに見えても、権限が欠けていれば失敗し得ます。

よくある不一致:

マトリクスを公開する前に、この権限のギャップを修正してください。RevOpsがガバナンスに説明責任を負うなら、リーダーはRevOpsが価値の低い依頼を保留し、定義を要求し、対立をエスカレーションできることを受け入れなければなりません。機能部門のリーダーが行動を所有するなら、自分のチーム内でそれを点検しなければなりません。ファイナンスが計画指標について相談を受けるなら、その指標が公開される後ではなく前に発言の場が必要です。

RACIはまた、説明責任者が決定しない場合に何が起きるかを明記すべきです。例えば、ライフサイクルをめぐる対立が2週間以上レポーティングをブロックする場合、CROまたはCOOが最終判断を下す必要があるかもしれません。エスカレーションがなければ、RACIはオーナーシップを名付けるだけで、停滞した意思決定を解決できません。

RACIは憲章とどうつながるか

RevOps憲章は使命を定義します。RACIは、その使命の中で誰が行動するかを定義します。

「これはRevOpsの範囲か」に答えるには憲章を使ってください。

「誰が決め、誰が作業を行い、誰がインプットを与え、誰が通知を受けるか」に答えるにはRACIを使ってください。

両者が組み合わさることで、運用上の規律が生まれます。別々では弱くなります。RACIのない憲章は広すぎます。憲章のないRACIはタスクを明確にしても、その機能の目的を見失うかもしれません。

小規模チーム向けの軽量版

小規模な会社に巨大なオーナーシップマトリクスは必要ありません。

次の5つの意思決定から始めてください。

• ライフサイクルの定義
• リードルーティング
• 商談ステージのルール
• 予測カテゴリー
• 受注後引き継ぎの要件

それぞれについて、一人の説明責任者と一つのRevOpsの役割を指名してください。それだけで、会社のスピードを落とさずに混乱を減らすのに十分です。

会社がセグメント、モーション、システム、オプス専門家を追加するにつれ、RACIを拡張してください。モデルは複雑さとともに成長すべきです。

RACI準備状況チェックリスト

マトリクスを公開する前に、最近の対立に照らしてテストしてください。

直近の四半期から3つの実例を選んでください。

• 争いになったリードの定義
• 予測ルールの変更
• ダッシュボード指標をめぐる意見の相違
• 必須フィールドの依頼
• 受注後引き継ぎの失敗
• ルーティングのエスカレーション

各例について、RACIが意思決定の経路を明らかにしているかどうかを問うてください。リーダーが依然として誰が説明責任を負うか分からないなら、そのマトリクスはまだ準備できていません。

また、説明責任者が行動する権限を持っているかもテストしてください。権限を伴わずに説明責任を割り当てるRACIはフラストレーションを生みます。RevOpsがフィールドガバナンスに説明責任を負うなら、フィールドの変更を承認、却下、エスカレーションできる必要があります。営業がステージの正確性に説明責任を負うなら、マネージャーには点検のリズムと衛生管理不良への結果が必要です。

最後のテストは使いやすさです。RACIは数ページに収まり、一目で把握できるべきです。マトリクスがあまりに詳細で誰も使わないなら、より小さく始めて、最も収益上の摩擦を生む意思決定に焦点を当ててください。

マトリクスが稼働したら、意味のあるシステムやプロセスの変更のたびにそれを参照してください。その繰り返しの利用こそが、オーナーシップを文書から運用上の行動に変え、繰り返しの議論を減らします。

RACIを軽量に保つ方法

RACIは対立を解決するのに十分詳細でありながら、誰も開かないほど詳細であってはいけません。

3つのレベルを使ってください。

この階層モデルは、小規模な会社が過剰なプロセスを避けながら、大規模なチームには十分な統制を与える助けになります。軽微なレポートの整理に運営委員会は必要ありません。予測カテゴリーの定義変更がチケットの中で起きるべきでもありません。

RACIがうまく機能している最良のサインは、人々がそれを頻繁に引用することではありません。全員がすでに経路を知っているために停滞する意思決定が減ることです。

RACI受付の質問

依頼がRevOpsに入ってきた瞬間にRACIを使ってください。

「何を作ってほしいですか」とだけ尋ねるのではなく、受付では次を尋ねるべきです。

• この依頼はどのビジネス上の意思決定に影響するか
• どのフィールド、ワークフロー、ダッシュボード、または引き継ぎが変わるか
• ビジネス上の成果に誰が説明責任を負うか
• 実装前に誰に相談する必要があるか
• 公開後にどのチームに報告する必要があるか
• ファイナンスはその定義をレビューする必要があるか
• その変更は経営層向けレポーティングや予測に影響するか
• 依頼が却下または遅延した場合どうなるか

これらの質問は、弱い依頼がシステム作業になる前に減速させます。新しいダッシュボードを求めるチームには指標の定義がないかもしれません。必須フィールドを求めるリーダーは、その値を誰が所有するか知らないかもしれません。ルーティングの例外を求めるマネージャーは、キャパシティやレポーティングへの影響を考慮していないかもしれません。

受付プロセスは重くあるべきではありません。RevOpsのバックログの中にある短いフォームやチェックリストで構いません。重要なのは、意味のあるすべての依頼が説明責任者と意思決定の経路に結びついていることです。

これはRevOpsのキャパシティも守ります。受付の規律がなければ、チームは共有の複雑さを生むローカルな修正の構築に時間を費やしてしまいます。RACIに基づく受付があれば、RevOpsはなぜ一部の依頼は速く進み、一部は相談が必要で、一部は構築すべきでないのかを説明できます。

RACIが機能している兆候

行動の変化に注目してください。

• フィールドの依頼が、オーナー、定義、ビジネス上の理由とともに届く。
• ダッシュボードをめぐる対立が、合意されたソース・オブ・トゥルースのルールを通じて解決される。
• 予測ルールの変更が、公開前に営業、ファイナンス、RevOpsを含む。
• 引き継ぎの失敗が、注意喚起だけでなくオーナーシップの変更につながる。
• ミーティングが始まる前に、誰が決めるかをチームが知っている。
• RevOpsが繰り返しの議論の仲裁に費やす時間が減る。

RACIが成功しているのは、意思決定がより速く、より明確になったときです。ミーティングの時間を減らし、手戻りを減らし、エスカレーションを個人的なものにしなくするはずです。

RACI意思決定パケット

オーナーシップが争われているときは、意思決定パケットを使ってください。

これにより、RACIが静的な文書になることを防げます。リーダーが実際の運用上の意思決定を解決するためにそれを使うとき、有用なものになります。

FAQ

RevOpsにRACIは必要か

はい。複数のチームが同じ収益システムに依存するようになったら必要です。RACIがなければ、引き継ぎとデータのオーナーシップは非公式なものになります。

予測精度に誰が説明責任を負うべきか

通常、営業リーダーシップが予測の結果を所有します。RevOpsは予測プロセス、定義、データ品質、点検のリズムを所有します。ファイナンスは重要な相談先パートナーです。

意思決定にはRACIで十分か

場合によります。リスクの高い意思決定では、意思決定のドライバーと承認者を明示的に定義するDACIの方が適していることがあります。

関連記事

• RevOps憲章
• RevOpsとファイナンス
• 予測ガバナンス
• マーケティング・営業連携グロッサリー