Quote to Cash

GitLabのQuote to Cashシステムとプロセス

概要

Quote-to-Cash（O2C）プロセスは顧客アカウント管理、注文処理、請求、売掛金の機能を包括しています。このプロセスの調整はEnterprise Applicationsチームが所有しています。

このページはクロスファンクショナルなページであり、Quote to Cash（Q2C）システムと基盤となるデータシステムおよびプロセスの情報源として機能することを目的としています。

効率的なQuote-to-Cashシステムは、GitLabサブスクリプションの購入、有効化、管理を可能な限り簡単にします。

  • 顧客満足度を向上させ、GoToMarket（GTM）プロセスを合理化し、会社の収益成長を加速させます。
  • すべてのソースシステムにわたる最も重要なビジネスオブジェクト/エンティティのデータ間の一貫性を確保します。
  • すべてのコアビジネスに重要なオブジェクトのマスターデータオブジェクトは、すべてのシステムにわたって同じ定義とデータを持ちます。
  • すべてのデータソースシステム間に適切な調整/同期が存在します。ZuoraとCustomerDot、SFDCとGitLab.comの間、およびZuora Billing Object ModelとCustomersDotの1:1マッピングが含まれます。
  • データ品質を向上させ、有料ネームスペースへの転換の旅、特定のネームスペースの最初の有料サブスクリプション、無料/トライアルから有料への転換分析などを理解するための単一の系譜を確保します。

チーム

Quote-to-Cashシステムのプロジェクトとイニシアチブは、多くの場合、機能やチームをまたぐ密接な連携が必要です。最も頻繁に関与するチームは：Enterprise Applications、Billing Ops、Fulfillment、Field Operations、Support、Data。

システム

Q2Cシステムは、Salesforce、Zuora（CPQ、360、Billing、Revenue）、CustomersDot、NetSuiteなどのいくつかのシステムで構成されています。

Salesforce

  • SalesforceはCRMツールとして、顧客のリード、コンタクト、アカウント、商談、見積もりの管理に使用されています。
  • SalesforceはGitLabのEnterprise Applicationsチームが所有し、プロセスオーナーからの変更を実装します。
  • 見積もりプロセス自体はDeal Deskチームが所有しています。

Zuora CPQ

Zuora 360

  • Zuora 360はZuoraとSalesforce間のストックコネクターで、ZuoraサブスクリプションinformationをSalesforceに転送します。
  • Zuora 360のジョブはEnterprise Applicationsが所有しており、アドオンと更新ディールのためのSalesforceにおけるZuoraサブスクリプションデータの拡張もEnterprise Applicationsが所有しています。
  • アドオンと更新プロセスはDeal Deskチームが所有しています。

Zuora Billing

  • Zuoraは請求と収益ツールとして、顧客サブスクリプション、支払い、請求書の管理に使用されています。
  • ZuoraはGitLabのEnterprise Applicationsチームが所有しています。
  • 請求プロセス自体はBilling Operationsチームが所有しています

Zuora Revenue

  • Zuora Revenueは、新しいASC 606およびIFRS 15収益基準を含む現在および将来の米国GAAPに準拠した自動収益認識アプリケーションです。

CustomersDot（顧客ポータル）

  • CustomersDotは顧客がサブスクリプションを管理するためにログインする際に使用されます
  • GitLabのエンジニアがCustomersDotを作成し、Fulfillmentチームが所有しています
  • CustomersDotはZuoraと統合して、セルフサービスの購入とサブスクリプション管理を可能にします

NetSuite

  • NetSuiteは会社のEnterprise Resource Planning（ERP）システムで、主にFinanceチームが管理しています。
  • このプラットフォームにより、多次元レポートと多通貨・多事業体レポートが可能になります。総勘定元帳がここに存在し、すべての財務活動が最終的に記録されており、会社の財務状況を報告するために重要です。

アーキテクチャ

ltc-landscape

データオブジェクト

同等のデータオブジェクト

この表はシステム間の同等のデータオブジェクトを示しています：

GitLabCustomersDotZuoraSFDC
OrganizationBillingAccountAccountBillingAccount
UserUserContactContact
-OrderOrder商談と主要見積もり
-SubscriptionSubscriptionSubscription
LicenseLicense--
-Cloud Activation--

注意：SFDCでは、SFDC BillingAccountはSFDC Accountと同じではありません。SFDC AccountはBillingAccountを複数持つことができます。

注意：CustomersDotのOrderオブジェクトはZuoraのOrderオブジェクトと同じではなく、定義が異なります。CustomerDotのOrderはZuoraのOrderよりも、ZuoraのSubscriptionに近いです。CustomersDotのOrderオブジェクトについては、さらなるアーキテクチャと定義の作業が必要です。

CustomerDotオブジェクトモデル

以下は新しく提案されたデータアーキテクチャのデータベースERDの焦点を絞ったビューです。

erDiagram
  CustomersDotUser ||--o{ CustomersDotBillingAccountMembership : "has many"
  CustomersDotUser ||--o{ ZuoraContact : "has many"
  CustomersDotBillingAccount ||--o{ CustomersDotBillingAccountMembership : "has many"
  CustomersDotBillingAccount ||--o{ CustomersDotCloudActivation : "has many"
  CustomersDotBillingAccount ||--o{ CustomersDotLicense : "has many"
  CustomersDotBillingAccount ||--o{ CustomersDotOrder : "has many"
  CustomersDotBillingAccount ||--|| GitLabOrganization : "has one"
  CustomersDotCloudActivation ||--o{ GitLabCloudActivation : "has many"
  CustomersDotLicense ||--o{ GitLabLicense : "has many"
  CustomersDotUser ||--|| GitLabUser : "has one"
  CustomersDotOrder ||--o{ CustomersDotSubscription : "has many"
  CustomersDotSubscription ||--|| ZuoraSubscription : "has one"
  GitLabUser ||--o{ GitLabMember : "has many"
  GitLabOrganization ||--o{ GitLabMember : "has many"
  GitLabOrganization ||--o{ GitLabLicense : "has many"
  GitLabOrganization ||--o{ GitLabCloudActivation : "has many"
  ZuoraAccount ||--o{ ZuoraContact : "has many"
  ZuoraAccount ||--o{ ZuoraPaymentMethod : "has many"
  ZuoraAccount ||--o{ ZuoraOrder : "has many"
  ZuoraAccount ||--o{ ZuoraSubscription : "has many"
  ZuoraOrder ||--o{ ZuoraSubscription : "has many"
  ZuoraAccount ||--|| CustomersDotBillingAccount : "has one"
  SFDCAccount ||--o{ ZuoraAccount : "has many"
  SFDCAccount ||--o{ CustomersDotBillingAccount : "has many"

  CustomersDotBillingAccount {
    bigint id
    string zuora_account_id
    string zuora_account_name
    string zuora_account_number
    string zuora_account_entity
    string zuora_account_vat_id
    string salesforce_account_id
    timestamp created_at
    timestamp updated_at
  }
  CustomersDotBillingAccountMembership {
    bigint id
    bigint user_id
    bigint billing_account_id
    timestamp created_at
    timestamp updated_at
  }
  CustomersDotUser {
    int id
    string first_name
    string last_name
    datetime created_at
    datetime updated_at
    string email
    string encrypted_password
    string reset_password_token
    datetime reset_password_sent_at
    datetime remember_created_at
    integer sign_in_count
    datetime current_sign_in_at
    datetime last_sign_in_at
    inet current_sign_in_ip
    inet last_sign_in_ip
    string provider
    string uid
    string country
    string state
    string city
    string zip_code
    string vat_code
    string company
    boolean billable
    string access_token
    string confirmation_token
    datetime confirmed_at
    datetime confirmation_sent_at
    string unconfirmed_email
    string address_1
    string address_2
    string company_size
    string authentication_token
    string phone_number
    boolean login_activated
    string refresh_token
    datetime_with_timezone access_token_expires_at
    datetime_with_timezone token_refresh_last_attempted_at
  }
  CustomersDotCloudActivation {
    bigint id
    bigint billing_account_id
    string activation_code
    string subscription_name
    boolean super_sonics_aware
    datetime seat_utilization_reminder_sent_at
    timestamp created_at
    timestamp updated_at
  }
  CustomersDotLicense {
    bigint id
    bigint billing_account_id
    uuid license_file_md5
    bigint creator_id
    datetime_with_timezone created_at
    datetime_with_timezone updated_at
    datetime_with_timezone last_synced_at
    datetime_with_timezone next_sync_at
    integer users_count
    integer previous_users_count
    integer trueup_quantity
    date expires_at
    date starts_at
    date trueup_from
    date trueup_to
    boolean trial
    boolean cloud_licensing_enabled
    string plan_code
    string plan_name
    string zuora_subscription_id
    string email
    string name
    string company
    string zuora_subscription_name
    text notes
    text license_file
    datetime_with_timezone activated_at
    boolean auto_renew_enabled
    boolean seat_reconciliation_enabled
    boolean operational_metrics_enabled
    boolean reconciliation_completed
    boolean offline_cloud_licensing_enabled
  }
  CustomersDotOrder {
    int id
    bigint billing_account_id
    string zuora_product_rate_plan_id
    string zuora_subscription_id
    string zuora_subscription_name
    date start_date
    date end_date
    integer quantity
    datetime created_at
    datetime updated_at
    string gl_namespace_id
    string gl_namespace_name
    string amendment_type
    boolean trial
    datetime last_extra_ci_minutes_sync_at
    string zuora_account_id
    datetime increased_billing_rate_notified_at
    boolean reconciliation_accepted
    integer trial_extension_type
    string source
    datetime_with_timezone seat_overage_notified_at
    datetime_with_timezone auto_renew_error_notified_at
  }
  CustomersDotSubscription {
  }
  ZuoraAccount {
    string crm_id
  }
  ZuoraContact {
  }
  ZuoraSubscription {
  }
  ZuoraPaymentMethod {
  }
  SFDCAccount {
  }
  GitLabLicense {
  }
  GitLabCloudActivation {
  }
  GitLabOrganization {
  }
  GitLabMember {
  }
  GitLabUser {
  }

Zuora Billing Object Model

ZuoraはZuoraのビリングオブジェクトモデルの関係図を提供しています。

Zuora Billing Object Model

システム間のデータ問題を減らすため、ZuoraビリングオブジェクトモデルとCustomersDotの1:1マッピングを確保することを目標としています。

ZuoraとSalesforceの統合オブジェクトモデル

Zuora CPQはZuoraとSalesforceを接続するために使用されます。

Zuora Salesforce ERD

請求アカウントマスターデータオブジェクト

BillingAccountは、支払い顧客の最も重要なアカウント情報（連絡先情報、支払い条件、支払い方法など）を保持するコアビジネスエンティティです。この情報は、サブスクリプション、修正、請求書や支払いなどのトランザクションを追跡するために使用されます。このマスターデータオブジェクトのデータは、有料顧客の請求情報をよりよく理解するため、いくつかのGTM、製品使用状況、データサイエンスの傾向モデルで積極的に使用されています。

まず、BillingAccount EntityのConformed Dimensionを開発するために、ZuoraビリングアカウントとCDotビリングアカウントのデータアーキテクチャの整合性の向上に焦点を当てました。

CDotのCustomerモデルには、個人ユーザー（Contact）と組織（Account）の両方を表す既知の設計上の欠陥があります。このエピックの調査はこのSpikeIssueに記載されています。

プロジェクト

以下は、Quote to Cashチームがシステムをより適切に整合させるために実施しているアーキテクチャプロジェクトです。

Fulfillmentデータアーキテクチャ計画

FulfillmentチームはQuote 2 Cashシステム、特にCustomersDotを、より高い信頼性、持続可能性、柔軟性を促進する方法で再アーキテクチャを進めています。このハンドブックページは、機能部門ページとアーティファクトへのリンクを持つQ2CシステムのSSOTとして機能します。

  1. Fulfillment SSOTプラン: data_architecture
  2. Central Data Team SSOTプラン: data_architecture
  3. Sales Systems SSOTプラン: 追加予定
  4. Enterprise Apps SSOTプラン: data_architecture

Zuoraはサブスクリプションが購入された後のZuora AccountとZuora Contactデータのソースオブトゥルースとして機能します。購入前には、ユーザーがCDotに登録し、CustomersDotBillingAccount（まだ存在しないため）に関連付けられていないCustomersDotUserレコードが作成されます。購入後、CustomersDotBillingAccountレコードが関連するCustomersDotBillingAccountMembershipとともに作成されます。

CustomersDotUser/ZuoraContactおよびCustomersDotBillingAccount/ZuoraAccount情報は、ユーザーが直接CDotやZuora（あるいはSFDCを通じて間接的に）で編集できるため、CDotとZuora間でのデータ同期に注意が必要です。特に、ZuoraコールアウトをCDotとZuora間のCustomersDotBillingAccountとCustomersDotUserレコードの同期に使用できない場合、Zuoraカスタムイベントを検討します。

CDotのCustomersDotUserレコードは1つのメールアドレスに紐付けられています。このメールアドレスは複数のZuoraAccountに関連付けられており、したがって複数のZuoraContactを持つことができます。各ZuoraContactは独立して変更できます。例えば、請求管理者が米国の請求エンティティのContact Aのアドレスを変更したいと思うかもしれませんが、同じメールアドレスに関連付けられたContact B（欧州の請求エンティティ用）のアドレスは変更しないかもしれません。この理由から、コンタクトメタデータは最終的にCustomersDotBillingAccountMembershipモデルに格納される可能性がありますが、スコープを減らすためにまずは軽量に保ちます。最初はZuoraからこのデータを取得します。

CustomersDot BillingAccount管理

CustomersDot BillingAccountの導入

背景

このエピックでは、ZuoraBillingAccountsとの整合性を高めるためのCustomersDotのデータアーキテクチャの改善に焦点を当てています。CDotのCustomerモデルには、ZuoraContactual（個人ユーザー）とZuoraAccount（組織）の両方を表す既知の設計上の欠陥があります。

問題

現在のCustomersDot（CDot）は、いくつかの異なる機能を果たすデータオブジェクトCustomer（例：customers DBテーブル）を持っています：

  • CustomersDotにログインできるメールアドレスを持つユーザー
  • 名前、メール、住所などのメタデータを持つ会社内の特定の人物に関連する連絡先情報
  • 会社名を含むZuoraアカウントに関連付けられた会社情報

Zuoraアカウントは、多くのユーザーやコンタクトを持つことができる会社/顧客アカウントにマッピングされることに注意することが重要です。特定の1人のユーザーにマッピングすべきではありません。現在のアーキテクチャでは、zuora_account_idは複数のCustomerと共有できますが、これは理想的ではありません。Zuoraのデータ構造とビジネスモデルを正確に反映するアーキテクチャが必要です。CustomersDotでは、ZuoraのBillingオブジェクトモデルを正確に反映するデータアーキテクチャが必要です。

これから恩恵を受けるIssueの例

  1. CDot Issue #3626
  2. GL Issue #332236
  3. Epic #2160
  4. CDot Issue #242
  5. CDot Issue #695
  6. GL Issue #338546

計画

Zuoraのデータ構造をより反映させるために、CustomersDotのデータアーキテクチャにいくつかの新しいモデルを追加することをお勧めします。

最も重要なのは、CDotにはCustomersDotBillingAccount（別名「会社」/「請求エンティティ」）のモデルがないことです。このモデルを追加することで、現在のCustomersDotCustomerモデルにあるBillingAccountレベルに属するデータを分離できます（以下の例を参照）。また、現在の命名がSalesforceのSalesforce Customerの定義とは異なるため混乱を招くことから、CustomersDotCustomerモデルをCustomersDotUserに名称変更します。

  • zuora_account_id
  • company_name
  • vat_code
  • salesforce_account_id

さらに、CustomersDotBillingAccountとCustomersDotUserモデル間に結合テーブル（例：billing_account_membershipsテーブル）を追加することで、CustomersDotBillingAccountが複数のCustomersDotUserを持てるようになります。同様に、CustomersDotUserは多くのCustomersDotBillingAccountに関連付けることができます。

このデータ構造で、CDotはCustomersDotBillingAccountとCustomersDotUserのデータ構造を、CDotのユーザーがZuoraAccountのサブスクリプションを表示/管理するためのアクセス権を持つべきかどうかを判断する方法として考慮する必要があります。CDotはZuoraに依存して、ZuoraAccountのコンタクトが誰であるか、およびそのメタデータ（名前、住所など）のソースオブトゥルースを提供することができます。

現在、CDotはサブスクリプションアカウントに関連するSoldToコンタクト用のCustomersDotUserレコードを作成します。このエピックでは、同じサブスクリプションアカウントのBillToコンタクト用にもCustomersDotUserレコードを作成することができますが、これは要件ではありません。これにより、両方のタイプのコンタクトがCDotにログインしてアカウントのサブスクリプションを管理できるようになります。

CustomersDot UserをなぜCustomersDot BillingAccountと多数関連付けられるようにするのか？

CustomersDotUserを単一のCustomersDotBillingAccountにのみ関連付けることを検討しましたが、以下の理由から多対多マッピング機能を構築すべきと判断しました：

  1. Zuoraは現在、1人のユーザーが複数の請求アカウントにマッピングできることを許可しています。
  2. 本番環境ではこれがすでに起きている例が見られます（Zuoraでは現在1800人以上のユーザーアカウントが複数のBillingAccountにマッピングされています）。

これを有効にすることで、CustomersDotとZuoraの間でパリティが実現します。

更新：CDotはZuoraビリングモデルに整合させるためにBillingAccount、BillingAccountMembership、BillingAccountContactモデルを追加しました。

ソースオブトゥルース

Zuoraはサブスクリプションが購入された後のZuoraAccountとZuoraContactデータのソースオブトゥルースとして機能します。購入前には、ユーザーがCDotに登録し、CustomersDotBillingAccount（まだ存在しないため）に関連付けられていないCustomersDotUserレコードが作成されます。購入後、CustomersDotBillingAccountレコードが関連するCustomersDotBillingAccountMembershipとともに作成されます。

CustomersDotUser/ZuoraContactおよびCustomersDotBillingAccount/ZuoraAccount情報は、ユーザーが直接CDotやZuora（あるいはSFDCを通じて間接的に）で編集できるため、CDotとZuora間でのデータ同期に注意が必要です。特に、ZuoraコールアウトをCDotとZuora間のCustomersDotBillingAccountとCustomersDotUserレコードの同期に使用できない場合、Zuoraカスタムイベントを検討します。

CDotのCustomersDotUserレコードは1つのメールアドレスに紐付けられています。このメールアドレスは複数のZuoraAccountに関連付けられており、したがって複数のZuoraContactを持つことができます。各ZuoraContactは独立して変更できます。例えば、請求管理者が米国の請求エンティティのContact Aのアドレスを変更したいと思うかもしれませんが、同じメールアドレスに関連付けられたContact B（欧州の請求エンティティ用）のアドレスは変更しないかもしれません。この理由から、コンタクトメタデータは最終的にCustomersDotBillingAccountMembershipモデルに格納される可能性がありますが、スコープを減らすためにまずは軽量に保ちます。最初はZuoraからこのデータを取得します。

CustomersDotのサインインオプションとしてGitLab.com SSOのみを使用

CustomersDotの唯一のサインインオプションとしてGitLab.com SSOを使用することで、レガシーのサインアップ（メールとパスワード）を排除し、将来的なサードパーティのeコマースプロバイダーとの統合のためにCDotを準備できます。 私たちの目標は、サブスクリプション情報へのアクセス方法において、SaaS/Self-ManagedとWeb直販/Sales Assisted顧客間のエクスペリエンスを合理化することです。

全体的に、これによりCDotでの顧客のためのより安全な環境が実現され、CDot顧客とGitLab.comアカウントの1:1関係を確立できます。

GitLab.com SSOをCustomersDotの唯一のサインアップオプションとして

CustomersDotのOrderをZuoraのOrderに整合させる

この作業は、CustomersDotOrderテーブルを分割し、ZuoraSubscriptionsテーブルをより代表するデータ構造に向かうことに焦点を当てています。

詳細はアーキテクチャブループリントを参照してください。

CustomersDotのOrderをZuoraオブジェクトに整合させる

SnowflakeデータウェアハウスとDbt（data build tool）

Quote to CashシステムからSnowflakeへデータを抽出し、dbtを使用してレポートと分析のためのデータモデルに変換します。

データアーキテクチャ計画

FulfillmentチームはQuote 2 Cashシステム、特にCustomersDotを、より高い信頼性、持続可能性、柔軟性を促進する方法で再アーキテクチャを進めています。新しいアーキテクチャの重要な成果の1つは、CustomerDot、Zuora、Salesforce間で同じ顧客定義を持つことです。この定義はZuoraのBillingAccountに基づいており、顧客のキーはbilling_account_idです。CustomersDotデータテーブルに顧客定義を整合させるために、Snowflakeとdbtのデータモデルを再アーキテクチャする必要があります。ZuoraとSalesforceシステムをモデル化して構築されたデータモデルは正しい顧客定義を持っており、現時点ではそれらのモデルの再アーキテクチャは不要です。

統合Q2Cデータモデルにおける顧客定義の重要な注意事項：

  1. 統合顧客キーはBilling_Account_Idであり、システムを結合します。Billing_Account_IdはQ2Cシステムに以下のように存在します：
    1. Zuora.Account.Account_Id
    2. CustomersDot.Billing_Accounts.Billing_Account_Id
    3. Salesforce.Billing_Account.Billing_Account_Id
    4. ドラフト: GitLab_Dotcom.Organization.Billing_Account_Id Organization Entity ObjectはGitLab_Dotcomにまだ作成されておらず、検証プロセスの途中です。Billing Account Id外部キーはまだ決定されていません。
  2. billing_account_idのソースIDデータ（データが発生してSSOTとみなされる場所）はZuoraにあります。
  3. 顧客定義は、ZuoraとSalesforceにある請求アカウントに対してのみ統合されており、一般的に有料・過去に有料であった顧客とEdu/OSSの顧客に限定されます。
  4. トライアルの目標状態はZuoraに入れることです。その時点で、CustomersDot、Salesforce、ZuoraにわたるトライアルToPaidアクティビティについての統一された顧客定義を持つことができます。
  5. Q2CシステムをまたいだFree顧客の顧客定義の統一方法の目標状態はまだ決定されていません。無料ユーザーの数は、SalesforceとZuoraに入れることに課題を提示します。この領域についてはさらに探索が必要です。
  6. SalesforceのAccountオブジェクトは、請求アカウントを持つ顧客または請求アカウントを持たない見込み顧客アカウントを持つことができます。

Q2Cの再アーキテクチャは、各フェーズの予想される成果と成果物について対象者と他のクロスファンクショナルチームへの明確なコミュニケーションとともに、さまざまなフェーズで実施されます。

整合次元（Conformed Dimensions）

整合次元は、エンタープライズ全体で一貫したレポートを確保しながら、複数のファクトやデータマート間で同じ方法でファクトと指標を分類・記述することを可能にします。

整合次元はマスターデータに対応し、あらゆるデータウェアハウジング環境の重要な構成要素です。

以下のマスターデータオブジェクトがコアビジネスエンティティのために作成され、組織全体のさまざまなアプリケーションで使用でき、関連するメタデータ、属性、定義、ロール、接続、タクソノミーも含まれます。

  • BillingAccount
  • Customer/User
  • Organization
  • Order
  • Lead
  • License

SnowflakeとDbtでのマスターデータオブジェクト開発作業は、次の2つのEpicで追跡されています：BillingAccount、Orders、RampsとCustomers、Contacts/Users、Leads。

以下はSnowflakeにおける再アーキテクチャされたデータモデルのEntity Relationship Diagramです。Target Stateタブには、CustomersDot、Zuora、Salesforce、GitLab.comソースシステムから抽出したビジネスエンティティが互いにどのように接続するかが示されています。

コアビジネスオブジェクトの整合次元設計

BillingAccountマスターデータオブジェクト/エンティティ（整合次元設計）
Orderマスターデータオブジェクト/エンティティ（整合次元設計）
Customer/Userマスターデータオブジェクト/エンティティ（整合次元設計）
最終更新 May 6, 2026: Merge pull request #100 from kyama0/fix/upload-images-tolerate-upstream-missing (70970e1a)
ページのソースコードを見る - ページの編集 - please contribute. Creative Commons License