レベニューオペレーションズシステムオブレコード: CRM、ワークフロー、データアーキテクチャ

レベニューオペレーションズシステムオブレコードとは、レベニューの真実のための統制されたアーキテクチャです。

多くの企業にとってCRMが中核です。しかし、すべてのレベニューに関する事実がCRMだけに存在するわけではありません。請求はサブスクリプションデータを所有しているかもしれません。カスタマーサクセスはヘルスデータを所有しているかもしれません。マーケティングオートメーションはキャンペーンの参加情報を所有しているかもしれません。BIは統合されたレポートを所有しているかもしれません。

RevOpsは、それらのシステムがどう連携するかを定義します。

Forresterのレベニューテクノロジー整合性に関する調査は、システムオブレコードの問いが単なるツール選定の問いではないという点で参考になります。それはオペレーティングモデルの問いです。Forresterのオペレーティングモデルに関する調査も、ガバナンスの観点から同じ論点を示しています。所有権、プロセス、意思決定権限が明確なときにのみ、システムは機能するのです。

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

• レベニューオペレーションズシステムオブレコードとは、業務がどこで行われ、真実がどこに存在し、レポートがどうシステムを組み合わせるかを定める統制されたアーキテクチャです。
• CRMは通常、アカウント、コンタクト、案件、所有権、パイプラインの中核ですが、請求、CS、マーケティングオートメーション、BIが他の真実を所有していることもあります。
• システムオブレコードモデルは、読み取り/書き込みのルール、連携の所有権、コンフリクトの扱い、レポート上の留意事項を定義すべきです。
• RevOpsは、どのシステムがワークフローに使われ、どのシステムが真実に使われ、どの層が経営層向け報告に使われるかを文書化すべきです。

アーキテクチャの層

システムオブレコードモデルは、レベニューデータの正とするソースに文書化されるべきです。

ワークフロー vs 真実

人々が実際に作業する場所と、公式な値が存在する場所を分けましょう。

この切り分けにより、一つのシステにすべての役割を担わせることを避けられます。CRMは営業にとってのワークフローシステムかもしれませんが、最終的なレベニュー値は依然として財務が所有しているかもしれません。CSはCSプラットフォームでヘルスを管理し、BIはそのヘルスデータを更新データと組み合わせてリーダーシップに提供するかもしれません。

システムオブレコード vs 正とするソース

これらの用語は関連していますが同一ではありません。

システムオブレコードとは、特定の種類のデータを所有するアプリケーションまたはデータベースです。正とするソースのモデルは、それぞれのビジネス上の問いについてどのシステムが優先されるかを説明するものです。

例えば:

正とするソースのモデルはルールブックです。システムオブレコードはデータが存在する場所です。

なぜ一つのツールでは足りないのか

多くのチームは一つのツールがすべての答えになることを望みますが、それは通常うまくいきません。

CRMはアカウント、コンタクト、案件、所有者、活動、パイプラインについて強みを持ちますが、それは重複レコード管理がそれらのオブジェクトの分裂を防いでいる限りにおいてです。請求書、サブスクリプションのスケジュール、利用状況のテレメトリ、サポートチケット、プロダクトイベント、財務の締め処理データにとって、CRMが最適な場所とは限りません。

RevOpsは、すべての事実をCRMに詰め込もうとすべきではありません。代わりに次を定義すべきです。

• どのシステムがその事実を所有するか
• どのフィールドがワークフローのためにCRMに同期されるか
• どのフィールドがレポートのためにBIに同期されるか
• どのシステムがその値を編集できるか
• どのシステムが読み取り専用か
• コンフリクトはどう解決されるか

これにより、使いやすさと信頼性の両方が守られます。

アーキテクチャ判断のルール

次のルールを使いましょう。

目標は純粋さではありません。目標は信頼できる業務です。

運用の中核としてのCRM

ほとんどのB2Bチームにとって、CRMは運用の中核です。

通常、次を所有します。

• アカウントとコンタクトのレコード
• 案件レコード
• 所有者とテリトリー
• パイプラインステージ
• 予測カテゴリー
• 活動とタスク
• リードルーティングとセールス引き継ぎ
• クローズドウォン引き継ぎの文脈

これは、CRMがすべてのレベニューの真実を所有するという意味ではありません。CRMは、多くのチームがアクションを調整する場だという意味です。

ワークフロー層

ワークフローは、多くのシステムオブレコードモデルが破綻する場所です。

あるフィールドは請求が所有しているかもしれませんが、営業は更新前にそれを見る必要があるかもしれません。あるヘルスシグナルはCSが所有しているかもしれませんが、財務はプランニングのためにそれを必要とするかもしれません。あるキャンペーンフィールドはマーケティングオートメーションが所有しているかもしれませんが、営業はソースの文脈のためにそれを必要とします。

RevOpsは、どの事実がワークフローシステムにコピーまたは表示され、どれが元のシステムに留まるかを定義すべきです。

BIとレポート層

BIは統合レポートに最適な場所であることが多いですが、統制されない正とするソースになってはいけません。

RevOpsと財務は次を定義すべきです。

• どの指標をBIで計算するか
• どのフィールドを各システムからインポートするか
• どの変換を承認するか
• どのダッシュボードが経営層向けの正とするソースか
• レポートにどの留意事項を表示するか

BIのロジックがCRMダッシュボードと文書化なしに異なっているなら、信頼は下がります。

連携ガバナンス

連携はデータのコンフリクトを生む可能性があります。

次を統制しましょう。

• 書き込みの方向
• 同期頻度
• フィールドマッピング
• コンフリクトルール
• エラー処理
• 同期失敗時の所有者
• 変更承認

例えば、マーケティングオートメーションとCRMの両方がリードソースを編集できる場合、会社はどちらの値を優先するかのルールが必要です。請求とCRMの両方が契約金額を保存している場合、財務はプランニング用の値を定義する必要があります。

Reworkにおける文脈

Reworkのような CRM兼ワークフロープラットフォームは、ライフサイクルステージ、ルーティング、タスク、所有権、顧客の文脈が一つの運用面で統制されているとき、RevOpsを支えることができます。それでもアーキテクチャは、明確なプロセスとデータルールに依存します。

チームがそのように使う場合、Reworkは顧客とレベニューモーションのための作業面として扱われるべきです。しかしRevOpsは、請求、マーケティング、CS、財務、またはBIがその恒久的な事実を所有している場合、どのデータがどこから来るのかを引き続き定義する必要があります。

よくある間違い

すべてにおいてCRMを正とするソースと呼んでしまう。 これは財務、請求、プロダクト利用データにとって不適合を生みます。

BIが指標を密かに再定義することを許してしまう。 レポートがワークフローシステムから乖離してしまいます。

コンフリクトルールがない。 二つのシステムが異なる値を書き込み、チームは自分の主張を支持する方を選んでしまいます。

連携の所有者がいない。 同期エラーが、レポートが壊れるまで見えないままになります。

データ辞書がない。 人々が最新の定義を見つけられません。

実装プラン

重要なレベニューの問いから始めましょう。

1. アカウントの所有権はどこに存在するか。
2. 案件のステージはどこに存在するか。
3. 予測カテゴリーはどこに存在するか。
4. サブスクリプション金額はどこに存在するか。
5. 顧客ヘルスはどこに存在するか。
6. リードソースはどこに存在するか。
7. 取締役会向け報告はどこに存在するか。

それぞれの問いを、システム、所有者、編集ルール、レポートに対応付けましょう。

準備チェックリスト

モデルを公開する前に:

• 重要なデータ要素がマッピングされている。
• 編集権限が明確である。
• コンフリクトルールが文書化されている。
• BIの変換が文書化されている。
• 財務が財務上の定義を承認している。
• RevOpsが変更ガバナンスを所有している。
• チームがどこで真実を点検すべきか知っている。

システムオブレコードが機能しているのは、チームがどのシステムを信じるべきか決めるためにデータをエクスポートすることをやめたときです。

アーキテクチャの例

実践的なミッドマーケット企業向けアーキテクチャは、次のようになるかもしれません。

このアーキテクチャは、各システムに役割があり、引き継ぎが統制されているときに機能します。

運用上の統制

RevOpsは、アーキテクチャに関する統制を維持すべきです。

• フィールドの所有権
• 連携の所有権
• 書き込み権限
• 変更承認
• 同期の監視
• エラー処理
• レポートの所有権
• データ辞書の更新

これらの統制は、緩やかな劣化を防ぎます。ほとんどのシステムオブレコードの問題は、一つの大きな失敗から生まれるわけではありません。それらは、管理されない小さな変化の積み重ねから生まれます。ここでフィールドが一つ追加され、あそこでワークフローが変更され、数週間無視された同期エラーが積み重なるのです。

システムオブレコードカタログ

カタログを作成しましょう。

このカタログは、新しく着任したRevOps、システム、財務のリーダーがアーキテクチャをすばやく理解する助けになります。

障害シナリオ

よくあるシナリオ:

CRMと請求がARRについて食い違う。 財務は、プランニングにどちらの数値を使うか、そしてCRMがどう更新された商業上の文脈を受け取るかを定義すべきです。

マーケティングオートメーションがソースを上書きしてしまう。 RevOpsは元々のソースをロックするか、厳格な更新ルールを作るべきです。

CSのヘルスがレベニューレポートの外に存在してしまう。 更新リスクと拡大プランニングが顧客の実態を見逃してしまいます。

BIが文書化なしに指標を変換してしまう。 経営層向け報告が業務ダッシュボードと照合しにくくなります。

連携エラーが監視されていない。 チームは取締役会向け報告の際にデータのギャップを発見することになります。

ガバナンス会議

レベニューデータに影響する変更について、月次でシステムガバナンスレビューを実施しましょう。

• 新しいフィールド
• 新しいワークフロー
• 連携の変更
• ダッシュボード定義の変更
• ツールの追加
• 書き込み権限の変更
• データ品質の問題

これはツール申請の会議ではありません。アーキテクチャを守るための会議です。

展開の手順

モデルを構築するには:

1. システムを棚卸しする。
2. 重要なレベニューの問いをマッピングする。
3. システムオブレコードの所有権を割り当てる。
4. 書き込みのコンフリクトを特定する。
5. 連携を文書化する。
6. データ辞書にエントリーを追加する。
7. 財務とRevOpsでレポートルールをすり合わせる。
8. モデルを公開する。
9. 月次でレビューする。

展開の原則

システムオブレコードモデルは、業務を楽にすべきであり、遅くすべきではありません。チームは、どこにデータを入力すべきか、どこで真実を点検すべきか、どこにコンフリクトをエスカレーションすべきかを知っているべきです。モデルがアーキテクチャ図の中だけに存在しているなら、行動は変わりません。

所有権マトリクス

システムオブレコードモデルには、所有権マトリクスを含めるべきです。

このマトリクスは、よくある問題を避けます。すなわち、誰もがそのシステムを使っているのに、誰もその品質を所有していないという問題です。

CRMに属すべきもの

CRMは、レベニューワークフローに必要なデータを保持すべきです。

• アカウント所有者
• 案件所有者
• ライフサイクルステージ
• パイプラインステージ
• 予測カテゴリー
• 次のステップ
• クローズ予定日
• 案件リスク
• クローズドウォン引き継ぎフィールド
• 更新所有者または更新の可視性

必ずしも、すべてのプロダクト利用イベント、請求書の明細、サポートチケット、財務の締め調整を保持する必要はありません。それらは他の場所に属し、要約された文脈のみをCRMに同期すればよいのです。

CRMの外に属すべきもの

一部のデータは、専門システムに留まるべきです。

• 請求スケジュール
• 請求書のステータス
• プロダクト利用ログ
• サポートケースの履歴
• 契約書類
• 財務の締めデータ
• 詳細なキャンペーンエンゲージメント

CRMには要約、リンク、またはステータスが必要かもしれませんが、データセット全体は不要です。

データ移動のルール

すべての連携について、次を文書化しましょう。

• ソースオブジェクト
• ターゲットオブジェクト
• フィールドマッピング
• 同期の方向
• 同期頻度
• エラーの所有者
• コンフリクトルール
• 同期失敗時のビジネスへの影響

これにより、連携の所有権が属人的な知識になることを防げます。

データ移動ルールの運用例

CSのヘルスが高リスクに変わった場合、営業と財務が把握できるようCRMに更新リスクのフラグが必要かもしれません。CSはヘルスモデルの所有者であり続けますが、CRMにはそのワークフローシグナルが必要です。

請求がサブスクリプション金額を更新した場合、財務は商業上の真実の所有者であり続けます。CRMはアカウントプランニングのために更新されたARRを必要とするかもしれませんが、それを最終的な財務システムとして扱うわけではありません。

マーケティングが元々のソースを取得する場合、アトリビューションと予算の意思決定がそれに依存するため、RevOpsはその値を不用意な編集から守るべきです。

データ移動チェックリスト

展開前に:

• システムカタログが存在する。
• 重要なフィールドに所有者がいる。
• 書き込みの方向が明確である。
• コンフリクトルールが文書化されている。
• 同期エラーに所有者がいる。
• BIの計算式が可視化されている。
• CRMユーザーが何を入力すべきか知っている。
• 財務がどの数値が公式かを知っている。

システムオブレコードモデルが成熟しているのは、RevOpsが繰り返しリマインドするからではなく、それが楽だからという理由でチームが正しいシステムを使っているときです。

実務上の注意

図面だけからアーキテクチャを再設計しないでください。実際に業務がどう行われているかを点検しましょう。担当者はどこで案件を更新するか。CSはどこでリスクを記録するか。財務はどこで契約金額を信頼するか。リーダーシップはどこでパフォーマンスを点検するか。

アーキテクチャは、恒久的な所有権と実際のワークフローに沿うべきです。モデルが見た目にはきれいでも、チームに不自然な回避策を強いるなら、それは失敗するでしょう。

リスクチェックリスト

アーキテクチャが完成したと言う前に、すべての重要なレベニューの問いに答えがあることを確認しましょう。

• その値はどこで入力されるか。
• 誰がそれを編集できるか。
• どのシステムが優先されるか。
• ワークフローのどこに現れるか。
• レポートのどこに現れるか。
• 壊れたとき誰が修正するか。

これらの答えのいずれかが不明確なら、そのシステムオブレコードモデルは、スケールさせるにはまだ十分に完成していません。

このモデルは、オンボーディング時にもテストされるべきです。新しく着任したレベニューリーダーが、5つの異なるチームに尋ねることなく、パイプライン、請求、顧客ヘルス、ソースデータ、経営層向け報告をどのシステムが所有しているかを理解できるべきです。オンボーディングがいまだに属人的な知識に依存しているなら、アーキテクチャにはより明確な文書化が必要です。

アーキテクチャ判断パケット

レベニューシステムオブレコードを変更する前に、簡潔なパケットを準備しましょう。

このパケットは、連携を追加する前、CRMフィールドを変更する前、あるいはレベニューデータを新しいプラットフォームに移す前にレビューされるべきです。システムオブレコードの決定は、単なる技術的な選択ではありません。それは、チームがレベニューデータをどう信頼し、編集し、それに基づいて行動するかを変えるものです。

よくある質問

CRMはレベニューのシステムオブレコードですか?

パイプラインと案件データについては、多くの場合そうです。しかし請求、CS、マーケティングオートメーション、BIが、レベニューの真実の他の部分を所有していることもあります。

システムオブレコードモデルは誰が所有すべきですか?

RevOpsが、財務、IT、マーケティング、営業、CSの意見を取り入れながら所有すべきです。

関連記事

• レベニューテックスタック
• レベニューデータ辞書
• CRMフィールドガバナンス