revenue-data-governance-strategy

収益データガバナンス戦略

収益データガバナンスの戦略担当者として、すべての収益オブジェクトクラスと指標について、組織全体のポリシーを策定してください。ポリシーでは、以下を定めます。

• どのシステムがデータを作成するか。
• どのシステムを読み取り側の信頼できる情報源とするか。
• 誰がそのデータを所有するか。
• プロデューサーチームをコンシューマーチームにどう紐付けるか。
• 意見の相違をどこで仲裁するか。

成果物は、指定表と、それを実施する運用モデルです。データのクリーンアップでも、ツールの購入でも、単一の CRM 内のフィールドルールでもありません。

システムレベルの視点を保ってください。フィールドレベルのガバナンスは、単一システム内のデータ品質管理の問題です。これはシステム間の統合と権限の問題であり、前者を拡大しても後者には対応できません。

検証ルールによって、商談に ARR 値が必ず設定されるようにすることはできます。しかし、その値を請求サブスクリプションや総勘定元帳の値に一致させることはできません。フィールドの仕組みについては、Reference の関連スキルを参照してください。

基本原則

• 記録のシステムと真実のソースを区別し、システム単位ではなくオブジェクトクラスごとに、それぞれを指定します。SOR はレコードを作成する運用ストア（書き込み経路）であり、SOT は照合済みの派生値で、意思決定が参照する値です（読み取り経路）。1つのシステムに両方の役割を担わせることが、繰り返される設計上の誤りです。2つの経路が求める特性は正反対です（Digna、Nutrient、Kohezion はこの分離で見解が一致しています）。

• ツールを購入する前に、SOR/SOT の指定表を公開します。この1つの成果物によって、「ダッシュボード間の競合」に関する論争のほとんどが解決します。先にツールを購入しても、同じ論争が新しい UI に表示されるだけです。

• 財務部門と営業部門の数値をめぐる対立は、データ品質の問題ではなく、定義の問題として扱います。受注額、請求額、認識収益、ARR/MRR はそれぞれ異なる4つの数値であり、設計上、一致することはありません。Dave Kellogg と Ray Rike は、公開 SaaS 企業の間でも用語の定義が一貫していないと指摘しています。CRM を整理しても分類体系をめぐる論争は解決しません。共有の分類体系によって解決します。

• 成果物は定義に関する合意であり、符号化された成果物は単なるその受領証です。Benn Stancil（「メトリクスレイヤーは誰も見つけられない聖杯です」）と Prukalpa Sankar は、同じ診断に行き着いています。難しいのはテクノロジーではなく、財務、営業、マーケティング部門の合意を得ることです。まず合意を形成し、その後に符号化します。

• データコントラクトは限定的に適用し、組織全体に適用しないでください。コントラクトは、破損すると収益レポートに影響する少数の境界で、自動サーキットブレーカーとして機能します。広範なガバナンスレイヤーとしては機能しません。

• この実践を生み出した実務家たちも、ここでは見解が一致しています。Chad Sanderson と、用語を生み出し、GoCardless で実際の成功を報告しながらも、コントラクトを「大きな文化的変革」と呼ぶ Andrew Jones です。この議論には真に決着がついていません。どちらか一方の立場が確定したかのように示すのではなく、成果物でもその旨を明記してください。

• ウェアハウスから運用ツールに値を同期する場合、そのフィールドの唯一の作成者はウェアハウスでなければなりません。そうでなければ値が再エクスポートされ、リネージが循環し、指し示すべき真実がなくなります。

• 各数値の確度を成果物にも反映してください。

  • オブジェクトクラスの指定表は、実務上の主流パターンであり、正式に公表された標準ではありません。
  • Forrester の RevOps 成熟度ステージの名称は有料公開のため、これらの言い換えは未検証です。Forrester の別の Opportunity Lifecycle フレームワークは公開されており、4つの原則を掲げています（顧客の統一的な視点を得るためのシグナル共有、リードからオポチュニティと購買グループへの移行、マーケティング／営業／カスタマーサクセス間で顧客に即した目標を設定すること、各機能が最も買い手に価値を提供できるタイミングに合わせたエクスペリエンスの設計）。
  • 人員配置比率は、実務家によるベンチマークで、10:1 から 50:1 の範囲です。
  • Atlassian、Figma、Notion、Stripe のような大企業のケーススタディは業界内で語られている情報です。例外は GitLab の公開ハンドブックで、GitLab 自身が全容を記録しています。

  詳細は references/frameworks-and-benchmarks.md を参照してください。

• 以下のランキングは法則ではなく、初期設定として扱います。すでに把握している組織の状況（すでに分析エンジニアリングチームがある、ウェアハウスが稼働している、財務部門が独自の真実の台帳を運用しているなど）に照らしてランキングを見直し、どの事実がどの選択肢の順位を動かしたかを明記してください。

B2B、PLG/B2C、ハイブリッド

アイデンティティの基盤はビジネスモデルによって異なりますが、その他のポリシー要素のほとんどはそのまま適用できます。

• B2Bのアカウントベース： 中核となるアイデンティティ単位は親子階層を持つアカウントです。解決方法は決定論的で、ドメイン照合と企業属性のエンリッチメントを行います。信頼できる唯一の情報源（SOR）はCRMアカウントを中心とし、信頼できる唯一の情報（SOT）はデータウェアハウスで照合した階層を重視します。
• PLG/B2Cのアイデンティティベース： 中核単位はユーザーまたは匿名の訪問者です。解決方法は匿名から既知のアイデンティティへの結合で、決定論的手法と確率論的手法を組み合わせます。SOTの重点はプロダクト分析またはCDPのアイデンティティグラフに移ります。
• ハイブリッド（セルフサービス登録、営業主導の拡大） は最も難しいケースです。データウェアハウスは、ユーザーからワークスペースへのグラフとアカウント階層を照合する必要があり、アイデンティティに関する障害の多くは、まさにこの境界で発生します。登録者をドメインでクラスタリングしてワークスペースにまとめるのが、標準的な橋渡し方法です。
• ビジネスモデルを問わず共通するもの（汎用的な表現のソースから推定したものです。その旨を出力に記載してください）：SOR/SOTの指定表、評議会による連合型のオーナーシップ、指標定義のガバナンス、同期フィールドに対する唯一の作成者ルール。

インタビュー

何かを設計する前に、以下の制約に従って質問してください。

• 1つのメッセージにつき質問は1つ。
• 可能な場合は選択肢形式にする。
• すでに回答済みの項目は省略する。

質問：

• ビジネスモデルは、B2Bの営業主導、PLG／セルフサービス、B2C、ハイブリッドのどれですか？
• 現在、収益データを保持しているシステムはどれですか：CRM、マーケティングオートメーション、請求／サブスクリプションプラットフォーム、プロダクト分析、データウェアハウス、総勘定元帳／ERPですか？また、これらのうち実際に存在するものはどれですか？
• おおよその規模はどのくらいですか：従業員数とARRの範囲は？（運用モデルと人員配置の規模を決めるためです。「ブレインストーミング」を参照してください。）
• 表面化している問題は何ですか：2つのチームでARRの数値が異なる、システム間で結合キーが混乱している、解約イベントがCRMに届かない、ガバナンス評議会が開催されても何も決まらない、または合併によってスタックが倍増した、のどれですか？
• 現在、データ業務のオーナーは誰ですか：RevOps、データ／アナリティクスエンジニアリングチーム、財務、IT、それとも特に決まっていませんか？
• 現在、データウェアハウスからCRMへの書き戻し（reverse-ETL）同期はありますか？また、別の何かも同じフィールドに書き込んでいますか？
• bookings、ARR/MRR、解約、パイプラインについて、文書化された指標定義はどこかにありますか？誰が承認しましたか？
• 2つ目のCRM、請求システム、または分析スタックをもたらしたM&Aを経験していますか？
• 請求方式は、シートベース、使用量ベース、またはその混合ですか？（使用量ベースでは、イベントデータが収益グレードに引き上げられ、データウェアハウスに関する検討の優先度が上がります。）
• ポリシーを定める期限はいつですか：取締役会の開催サイクル、監査、計画策定時期、または特定の期限なしですか？
• 一度限りの論争解決ですか、それともシステムが追加されても継続する、積み重ね型のガバナンス体制ですか？
• 工数の上限はどの程度ですか：RevOpsアナリストの作業時間のみ、データエンジニアリングの対応力、評議会への経営陣の支援、または部門横断的な全面的な委任ですか？

最後の3項目で「ブレインストーミング」と「実施」の優先順位が決まるため、提案を行う前に質問してください。

• 厳格な期限がある場合は、指定表と定義ワークショップを優先します。どちらも数週間で実施でき、コントラクトエンジニアリングは次のサイクルに回します。
• 継続的な取り組みが求められる場合は、評議会、コードとしての定義、コントラクトを優先します。
• データエンジニアリングの対応力がない場合は、CIで強制するコントラクトと、データウェアハウスをハブとする方式を今サイクルの選択肢から外します。
• 経営陣の支援がない場合、評議会は名ばかりのものになります。それは評議会を設けないよりも悪いことなので、その旨を伝えてください。

除外した項目とその理由をすべて成果物に記録してください。

運用モデルのブレインストーミング

インタビューの後、テーブルを作成する前に、明示的なブレインストーミングを行います。トレードオフとともに候補となる運用モデルを2〜3案提示し、1案を推奨して承認を得ます。

• 効率性（エンジニアリング面および政治面の労力あたりに解決できる対立の数で測定）：CRM-centric hub > warehouse-as-hub federated > data-mesh domain ownership。
• 価値：data-mesh domain ownership > warehouse-as-hub federated > CRM-centric hub。
• 労力：CRM セントリック（新たなインフラはほぼ不要）< ウェアハウスをハブとするフェデレーション（モデリングレイヤー、リバース ETL、分析エンジニアが必要）< データメッシュ（複数年にわたる運用モデルの変更。ビジネスチームが「データプロダクト」を所有したことがなく、納得してもらう必要があります）。

1. CRM セントリックハブ - CRM を事実上の SOT とし、請求およびプロダクトのデータは照合せずに参照します。シートベースの課金で ARR が約1,000万ドル未満の場合は十分です（実務者のベンチマークであり、監査済みの調査結果ではありません）。利用イベントや請求照合が重要になった時点で拡張できなくなります。CRM ではイベントログを保持できないためです。
2. ウェアハウスをハブとするフェデレーション - ウェアハウスを SOT とし、各運用システムは自ら作成するデータの SOR であり続けます。リバース ETL でモデル化した値を外部システムに同期し、フェデレーション型の評議会が基準を定め、各部門が実行します。これは成熟したパターンとして収束しているアプローチです（dbt Labs、Alation、Atlan、およびデータメッシュの第4原則が、いずれも独立してこの形に行き着いています）。ARR が約1,000万ドルを超える場合、または従量課金の場合のデフォルトです。
3. データメッシュのドメイン所有 - 各 GTM 部門が契約に基づいて、自らのデータをプロダクトとして所有します。最も高い上限を持ちますが、この順序付けが最も後回しにする段階です。労力が技術面ではなく組織面にかかるため、効率性を競うあらゆるラウンドで不利になります。複数のドメインチームがすでにガバナンスの行き届いたデータセットを作成しており、スポンサーの委任事項がレポートの改善だけでなく、運用モデルの変更まで対象としている場合にのみ、この段階を推奨します。

インタビューで得られた回答のうち、どの回答が判断の決め手になったかを示し、インタビューの内容に合う段階を推奨します。その後、以下の順に成果物の計画をセクションごとに検証し、何かを作成する前に承認を得ます。

1. 指定表。
2. ID スパイン。
3. 指標の定義。
4. 契約。
5. 所有権と評議会。
6. ロールアウト。

ワークフロー

1. インタビューを実施し、モーション、システム、規模、および効率性に関する3つの回答（期限、単発か複利的か、許容できる労力の上限）を明確にします。

2. 「運用モデルのブレインストーミング」を実施し、モデルの承認を得ます。

3. SOR/SOT指定テーブルのドラフトを作成します。対象オブジェクトのクラス（アカウント、連絡先／人物、商談、サブスクリプション／契約、利用イベント、および各収益指標）ごとに1行を設け、作成元システム、参照側での正とするデータ、および担当者を明記します。references/sor-sot-designation.mdの一般的なパターンの表を出発点として調整します。これは一般的な慣行に基づくデフォルトであるため、この組織の実情が異なる箇所は変更します。特に認識収益の行と、従量課金の場合の利用イベントの行については、このリファレンスに、実務者のデフォルトだけでなく、ベンダーが文書化した仕組みも記載されています。いずれかの境界を一から定義する前に、まずこの情報を使います。

4. IDの背骨を設計します。正規アカウントIDを1つ、正規人物IDを1つ定め、各システムのキーをこれらに対応付けるエイリアステーブルを作成します。まず完全一致を使い、曖昧なケースは人によるレビューに回します。解決率は、全トラフィックではなく、紐付け可能な母集団を基準に測定します。アカウントデータは強いキーを持ち、ほぼ解決済みの領域です。一方、匿名の行動データにおけるIDは大半が解決不能であり、そうでないふりをすると、どのツールでも解消できない継ぎ目に多額の予算を費やすことになります。B2B／PLGのセクションから、モーションに合った解決方法を選びます。

5. 指標定義ワークショップを実施します。Finance、Sales、Marketingの間で、ブッキング、請求額、認識収益、ARR／MRRと、インタビューで明らかになった意見の分かれる指標について、共通の分類体系に合意してもらいます。署名済みの定義はその後に限り、バージョン管理され、レビュー可能な成果物としてコード化します（「一度定義して、あらゆる場所で使う」——Airbnb Minervaのパターン）。認識収益は引き続きFinanceのもとで総勘定元帳により作成します。このスキルで指定するのはその境界であり、収益認識の設計をやり直すことではありません。

6. データ契約レジスターを作成します。破綻すると収益レポーティングが機能しなくなる、主要なプロデューサーとコンシューマーの境界について、それぞれプロデューサー、コンシューマー、契約に含まれる内容（スキーマ、品質チェック、SLA、所有権）、および適用措置を記載します。認識を高めるため、まずコンシューマー側で定義し、実績が証明された境界に限ってプロデューサー側の適用へ移行します。仕組みと記入例はreferences/data-contract-register.mdを参照してください。

7. 連合型のハブ・アンド・スポーク方式で、所有権と裁定の体制を定めます。

   • RevOpsは業務定義とGTMプロセスを担当します。
   • データ／アナリティクスエンジニアリングはモデルとパイプラインを担当します。
   • Financeは認識収益を担当します。
   • ガバナンス評議会が基準を定め、裁定を行います。

   意思決定権限の用語体系（データオーナー／データスチュワード、またはドメインオーナー）を1つ選び、一貫して使用します。用語体系が混在すると、説明責任も混在します。エスカレーションはまず評議会へ、その後CFO／CROへ進めます。最も声の大きい人に委ねてはいけません。ベンチマークのリファレンスを使って、段階に応じた人員を配置します。

8. 以下の適用メニューから適用方法を選び、インタビューで得た3つの回答に照らして優先順位を付け直します。

9. 成果物（出力形式）を一度に1セクションずつ提示し、ユーザーに確認してもらいます。

10. 合格基準を確認し、満たすまで反復します。ハーネスに永続メモリがある場合は、指定テーブル、IDの背骨に関する決定、署名済みの定義、契約レジスターを保存し、後の意見の相違やレビューで参照できるようにします。ない場合は、ポリシー文書を永続的な成果物とし、そのように扱うようユーザーに伝えます。

適用

労力あたりの紛争防止効果が高い順に、ポリシーを実効性のあるものにする方法を示します。

• 効率性：指定テーブル > 利用側が定義する契約チェック > 定義をコードで管理 > 提供側がCI契約を適用
• 価値（防止した障害、解決した紛争）：提供側がCI契約を適用 > 定義をコードで管理 > 指定テーブル > 利用側が定義する契約チェック
• 労力：指定テーブル（半日と署名の取りまとめ） < 利用側が定義するチェック（境界ごとに監視クエリが必要） < 定義をコードで管理（レビューのプロセスと定義を管理する場所が必要） < 提供側がCI契約を適用（提供側のパイプラインに継続的なエンジニアリング上の取り組みが必要）。
• デフォルトの段階：最初のサイクルでは指定テーブルと利用側が定義するチェックを導入し、ワークショップで分類体系に署名した時点で定義をコードで管理する段階を追加します。この順序では、提供側がCI契約を適用する段階が後回しになります。これは、破壊的変更のリリースを事前に防げる唯一の段階であり、効率性の評価では常に最下位になります。障害によって収益レポートが一度でも停止した境界、または同期サイクルが1回古くなるだけでレポートではなくアクションに変化が生じる境界では、この段階に引き上げます。
• 降格ではなく削除：組織全体を対象とする契約カバレッジ。実践の考案者自身による証拠から、広範なカバレッジでは、契約が作成されても適用されないことが分かっています。選択肢から除外したものをメニューの末尾に残すと、スコープとして再び持ち込まれるため、ここには記載しません。
• 権限はあっても適用の仕組みがない評議会は、「税金」になってしまいます（Dataversityの表現）。上記のすべての段階で、契約が発動した際に誰が対応するかを明記する必要があります。そうでなければ、それは適用ではなく報告にすぎません。

出力形式

REVENUE DATA GOVERNANCE POLICY - <company>, <date>
Scope             : motion (B2B / PLG / B2C / hybrid); systems in scope; operating
                    model chosen and why; options deleted by the user's
                    constraints, and which constraint deleted each
Designation table : object class -> SOR (authors) | SOT (decisions read) | named owner
Identity spine    : canonical account + person IDs; alias-table plan; resolution
                    method per motion; coverage target vs the linkable population
Metric governance : signed taxonomy (bookings / billings / recognized / ARR-MRR
                    + contested metrics); definitional home; change-review process
Contract register : boundary | producer | consumer | bundle (schema, quality,
                    SLA, ownership) | enforcement action | defined by whom
Ownership & council: decision-rights vocabulary; RevOps / data eng / Finance
                    split; council membership, cadence, decision rights;
                    escalation path to CFO/CRO
Enforcement       : rung per policy element + why it beat the rung below
Rollout & staffing: sequence with dates; staffing gap vs stage benchmarks
KPIs              : baseline captured; targets; first review date

合格基準

• 対象範囲内のすべてのオブジェクトクラスと収益指標について、指定されたSOR、指定されたSOT、担当者がそれぞれ1つだけ定められています。SORとSOTが同じシステムの場合は、それが意図的である理由がテーブルに記載されています。
• QBRテスト：2つのチームが、矛盾するARRの数値をそれぞれ提示し、どちらも正当化できる状態になっていないこと。そうした状態が可能なら、指定テーブルは存在していても適用されていないため、ドキュメントがどれだけ完全でもポリシーは不合格です。
• 同期して戻される各フィールドでは、データウェアハウス（またはそのSOT）が唯一の書き込み元として指定されています。宣言された優先順位のない複数の書き込み元を持つ管理対象の値はありません。
• 契約登録簿には、名前が付けられた収益上重要な境界のみが記載され、それぞれに提供側、利用側、適用時のアクションが定められています。「すべてのパイプライン」を対象とする一律の契約はありません。
• Finance、Sales、Marketingが署名した分類体系があり、差分を確認できる場所に保管され、変更レビューのプロセスが設けられています。
• 評議会はカレンダーに予定され、メンバーが明記され、意思決定権が文書化され、エスカレーション経路が定められています。会議の定期的な開催予定がないポリシー文書は、この基準を満たさないものとします。

6項目すべてを満たすまで反復します。この実行で署名の取りまとめや評議会の規約を完了できない場合は、日付を添えて保留中と記載します。署名が保留中であることは合格ですが、署名者が明記されていない場合は合格になりません。

よくある失敗パターン

欠陥	結果	対策
SOT の主張が競合する（営業は CRM、財務は GL、プロダクトはアナリティクスを主張）	どのダッシュボードにも根拠があるが、権威あるものはありません	オブジェクトクラスごとに SOR/SOT を指定して責任者を明記し、QBR テストを適用状況の確認に使います
「信頼できる唯一の情報源」をシステムごとに宣言し、オブジェクトごとには宣言しない	1 つのシステムに作成と照合の両方を担わせることになり、どちらの作業もうまくいきません	オブジェクトクラスごとに SOR と SOT を別々に指定します
CRM、請求、アナリティクス間で結合キーが一致しない	解約が請求システムで検知されても、アカウントレコードには反映されません	正規 ID とエイリアステーブルを用意し、まず完全一致を試し、あいまい一致はレビューに回します
すべてのトラフィックを基準に ID カバレッジを測定する	どの解決率指標も失敗を示し、解決不能な対象に予算を費やします	リンク可能な対象集団を基準に測定し、匿名 ID は大部分が解決不能であることを受け入れます
財務と営業の数値の食い違いをデータ品質の問題として扱う	CRM のクリーンアップが延々と続き、食い違いは解消されません	受注、請求、認識済み売上、ARR の分類を文書化して合意します。これは定義の問題です
定義に合意する前にセマンティックレイヤーツールを購入する	同じ食い違いが、今度は YAML で表現されます	まず定義のワークショップを実施し、その後にコード化します
協議会は開催されるが、決定が徹底されない	中央チームが「負担」と見なされ、ポリシーが形骸化します	意思決定権、強制措置、CFO/CRO へのエスカレーションを憲章に明記します
組織全体にわたる契約の導入	契約は作成されても徹底されず、四半期以内に古くなります	売上に不可欠な境界だけに絞った台帳を作成します
リバース ETL による真実の循環	データウェアハウスの値が再エクスポートされ続け、データリネージがループします	同期するすべてのフィールドの唯一の作成元をデータウェアハウスにします
M&A によるスタックの拡大がガバナンスを上回る	SOR が増え続け、台帳への集約が追いつきません	指定の見直しを M&A 統合プロセスの恒常的な手順にします
ツール間で指標がずれる	同じ指標でも、ダッシュボードごとに数値が異なります	レビューを伴うコードとしての定義を導入し、「一度定義し、どこでも使う」を徹底します

KPI

• 追跡する項目：
  • 経営レビューサイクルごとの数値不一致インシデント数（目標はゼロ、QBR テストで毎サイクル実施）。
  • 対象範囲のオブジェクトクラスのうち、指定された SOR、SOT、およびオーナーがあるものの割合。
  • リンク可能な母集団に対するアイデンティティ解決のカバレッジ。
  • プロデューサー側で検出された契約違反と、下流で発見された契約違反の比率（この比率がシフトレフトの指標です）。
  • 評議会を通じて、ドメイン横断のデータ論争を解決するまでの時間。
  • レビューを経た指標定義の変更と、レビューを迂回した変更の数。
• 「契約を作成した」や「定義を文書化した」ことを成功として報告してはいけません。どちらも成果物の数を数えているだけであり、このドメイン全体で問題となるのは、成果物があっても強制力がないことです。
• M&A のたびに、またスタックに新しいシステムが加わるたびに、QBR テストを再実施してください。指定テーブルは、次の SOR が登場するまでしか最新ではありません。

呼び出し例

• 「Finance と Sales がまた取締役会に異なる ARR 数値を提示しました。どちらか一方を正式な値とするガバナンスポリシーを設定してください。」
• 「Salesforce、請求プラットフォーム、プロダクト分析、データウェアハウスがありますが、何についてどのシステムを優先するのか、誰も書き残したことがありません。信頼できる情報源のマップを作成してください。」
• 「セルフサービスのサインアップが、Sales が対応するアカウントとまったく一致しません。PLG 側とセールス主導側にまたがるアイデンティティおよびオーナーシップのポリシーを設計してください。」

参考資料

• 指定テーブルまたはアイデンティティスパインを作成する際は、references/sor-sot-designation.md を読んでください。SOR/SOT の定義、オブジェクトクラスごとの一般的なパターンとその信頼性の範囲、認識済み収益に関するベンダー文書記載の CRM／請求／RevRec／GL パイプライン、名称が明記された利用量計測ベンダーの仕組み、データウェアハウスをハブとする仕組み、適切な例と不適切な例を示した記入済みテーブルが記載されています。
• 契約レジスターを作成する際は、references/data-contract-register.md を読んでください。契約に含まれる要素、適用手段の選択肢、実務者間で結論が出ていない議論を両方の立場から示した内容、本番環境ですでに適用されている実際の利用量計測契約、記入済みのレジスター項目と否定的な例が記載されています。
• フレームワーク、成熟度モデル、人員比率、またはケーススタディを引用する前に、references/frameworks-and-benchmarks.md を読んでください。名称が示されたフレームワークの表、検証済み／有料公開／伝聞のラベル、セマンティックレイヤーガバナンスを「AI コンテキストレイヤー」として捉え直す内容、ステージ別の人員配置ベンチマーク、GitLab のテンプレートが記載されています。
• CRM 内のフィールドレベルのルール（各フィールドのオーナー、書き込みの優先順位、鮮度の SLA）については、mbfinotti/revops-skills@crm-data-governance を参照してください。このスキルはオブジェクトクラスごとに優先されるシステムを指定し、そちらは優先されるシステム内のフィールドを管理します。
• スタックに残すツールを決める際は、mbfinotti/revops-skills@revops-stack-rationalization を参照してください。そちらはツールのオーナーシップを判断し、このスキルはデータの権限を扱います。そちらで統合する場合も、ここに記載された指定テーブルに従う必要があります。
• どの組織レベルでどの指標が重要か、またそれらをどう集計するかを選ぶ際は、mbfinotti/revops-skills@revenue-kpi-framework を参照してください。このスキルは指標定義の保管場所、承認者、変更方法を管理し、そちらは指標セット自体を設計します。
• ガバナンスの対象となる数値を基に作成する経営レポートについては、mbfinotti/revops-skills@revenue-reporting を参照してください。そちらは、このスキルで承認を得た分類体系を利用します。
• 問題がファネル内での金額消失である場合は、mbfinotti/revops-skills@revenue-leakage を参照してください。データの欠落や引き継ぎに起因すると特定された漏れは、このポリシーに反映します。このスキルでは漏れの原因を追跡しません。