受注から入金までの販売受注処理向けデータテンプレート
受注から入金までの販売受注処理向けデータテンプレート
- 収集を推奨する属性
- 追跡する主なアクティビティ
- Salesforce Sales Cloudからのデータ抽出手順
受注から入金までの販売受注処理の属性
| 名前 | 説明 | ||
|---|---|---|---|
| アクティビティ名 ActivityName | 受注のライフサイクルで発生した、特定の業務イベントまたはタスクの名前です。 | ||
| 説明 アクティビティ名は、「受注作成」「与信審査完了」「請求書送付」など、受注プロセスの各ステップを表します。これらのアクティビティはプロセスマップを構成する要素であり、システムイベント、ステータス変更、タスクの完了状況から導出されます。 アクティビティを分析すると、プロセスフローを可視化し、よく見られる経路(バリアント)を特定して、各ステップの発生頻度と所要時間を測定できます。プロセスで実際に何が起きているかを把握するための基本情報です。 重要な理由 この属性は、プロセスマップの各ステップを定義します。これがないと、プロセスフローを可視化したり、受注が実際にどのように処理されているかを分析したりできません。 入手先 通常は、「Order.Status」項目のステータス変更、関連レコード(例:Invoice)の作成、または受注に関連する「Task」や「Event」レコードの完了状況から導出します。 例 受注作成受注承認商品出荷入金確認 | |||
| イベント時刻 EventTime | アクティビティが発生した正確な日時です。 | ||
| 説明 イベント時刻(タイムスタンプ)は、アクティビティが発生した正確な時点を記録します。イベントを正しい順序に並べ、アクティビティ間の所要時間を算出するために欠かせないデータであり、時間に基づくプロセスマイニング分析の基礎となります。 この属性を使って、ケースごとにアクティビティを並べ、サイクルタイムや待ち時間を算出し、期間ごとのプロセスのパフォーマンスを分析します。タイムスタンプが不正確だったり欠けていたりすると、分析の有用性が大きく損なわれる可能性があります。 重要な理由 タイムスタンプは、イベントを時系列に並べ、サイクルタイムやボトルネックなど、パフォーマンスに関する指標を算出するために欠かせません。 入手先 「Order」オブジェクトや関連レコードの「CreatedDate」や「LastModifiedDate」などの項目に対応します。特定のイベントでは、「Task」レコードの完了日を使う場合もあります。 例 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:00:00Z | |||
| 受注 SalesOrderId | 各受注を一意に識別するIDです。受注から入金までのプロセス全体を追跡する際の主なケース識別子として使います。 | ||
| 説明 受注IDはプロセス分析の基盤となり、顧客の各受注をライフサイクル全体にわたって一意に識別します。作成や承認から履行、入金まで、関連するすべてのアクティビティを結び付けます。 プロセスマイニングでは、特定の受注に関するすべてのイベントをこのIDに関連付けます。これにより、受注の流れをエンドツーエンドで再構成し、個々の受注のサイクルタイム、プロセスのバリエーション、ボトルネックを詳しく分析できます。 重要な理由 この属性を使うと、関連するすべてのイベントを1つのケースにまとめられ、受注ごとのエンドツーエンドのプロセスフローを可視化して分析できます。 入手先 Salesforceの標準「Order」オブジェクトにある「Id」項目です。 例 8018d000000XwPBAA08018d000000Y1qCAAS8018d000000Z3kDAB1 | |||
| ソースシステム SourceSystem | データの抽出元となるシステムを示します。 | ||
| 説明 この属性は、プロセスデータの取得元を示します。この分析では、一貫して「Salesforce Sales Cloud」を指定します。 複数のシステムを使う環境では、データの来歴を追跡し、問題を調査するうえで重要な項目です。単一システムの環境でも、データの取得元に関する重要なメタデータとなります。 重要な理由 データの取得元に関する重要なコンテキストを示します。データガバナンスや、複数のソースシステムからデータを統合する際に役立ちます。 入手先 通常は、データ抽出時にデータセットを識別するための固定値を追加します。 例 Salesforce Sales Cloud | |||
| 最終データ更新 LastDataUpdate | データを最後に抽出または更新した日時を示すタイムスタンプです。 | ||
| 説明 この属性には、ソースシステムからデータを最後に取得した日時が記録されます。分析対象のデータがどの程度新しいかを把握するうえで重要な情報です。 アナリストはこの情報をもとに、最新のプロセスデータを見ているか、分析結果が現在も有効かを確認できます。プロセスマイニングプロジェクトに欠かせないメタデータです。 重要な理由 データの更新時期を利用者に知らせ、分析対象のデータがどの時点のものかを把握できるようにします。 入手先 データの抽出、変換、読み込み(ETL)の過程で生成し、追加するタイムスタンプです。 例 2023-11-01T05:00:00Z | |||
| 受注ステータス OrderStatus | イベント発生時点での受注のステータスです。 | ||
| 説明 この属性には、「下書き」「有効」「出荷済み」「クローズ」など、受注の状態が記録されます。ステータスの変更をもとに、プロセスログのアクティビティを生成することがよくあります。 受注ステータスを分析すると、各イベントのコンテキストを把握でき、受注の進捗を追跡できます。たとえば、「キャンセル」された受注と正常に「クローズ」された受注を識別するなど、ケースの結果を理解するのに役立ちます。 重要な理由 各イベントの重要なコンテキストを示し、アクティビティの定義にもよく使われます。キャンセルなど、ケースの結果を分析するうえでも重要です。 入手先 Salesforceの標準「Order」オブジェクトにある「Status」選択リスト項目です。 例 下書き有効出荷済みクローズキャンセル済み | |||
| 合計サイクルタイム CycleTime | 受注の作成から最終的な完了までにかかった合計時間です。 | ||
| 説明 合計サイクルタイムは、受注プロセスの開始から終了までの所要時間を測る重要業績評価指標(KPI)です。最初のイベント(例:「注文作成」)から最後のイベント(例:「注文完了」)までの時間差として算出します。 「受注のエンドツーエンド・サイクルタイム」ダッシュボードで中心となる指標です。サイクルタイムを分析すると、プロセス全体の非効率を特定し、改善施策の効果を測定できます。国や製品ファミリーなどの属性でデータを分類し、サイクルタイムの違いを調べることもできます。 重要な理由 プロセス全体の効率を測り、組織的な問題の兆候となる処理期間の長い注文を特定するための基本的なKPIです。 入手先 データ変換時に、各「SalesOrderId」の最初のイベントのタイムスタンプを最後のイベントのタイムスタンプから差し引いて算出します。 例 10日4時間25日11時間5日2時間 | |||
| 実行担当者 UserPerformingAction | アクティビティを実行したユーザーまたはシステムエージェントの名前です。 | ||
| 説明 この属性は、プロセスのステップを完了した担当者を識別します。営業担当者、与信アナリスト、自動化されたシステムユーザーなどが該当します。 この属性に基づく分析は、作業負荷の配分、個人のパフォーマンス、自動化の状況を把握するうえで重要です。「手戻りを最も多く処理しているのは誰か」「承認が速いチームはあるか」といった問いに答えるのに役立ちます。また、ソーシャルネットワーク分析にも使われ、担当者間でどのように作業が引き継がれているかを確認できます。 重要な理由 ユーザー、チーム、役割ごとのパフォーマンス分析に役立ち、自動化の機会やトレーニングの必要性を特定できます。 入手先 「Order」オブジェクトの「LastModifiedById」や、「Task」レコードの「OwnerId」などの項目から取得できます。ユーザー名を取得するには、これらのIDを「User」オブジェクトと結合する必要があります。 例 アリス・スミスボブ・ジョンソンシステム自動化与信チーム | |||
| 希望納品日 RequestedDeliveryDate | 顧客が希望する注文品の納品日です。 | ||
| 説明 この属性には、顧客が商品を受け取りたい日付が記録されます。納品パフォーマンスや顧客満足度を測る際の重要な基準です。 この日付は、「納品日遵守状況の追跡」ダッシュボードと「納期遵守率」KPIで直接使われます。実際の納品日(「商品納品」タイムスタンプ)と比較し、注文品が予定どおり、予定より早く、または遅れて納品されたかを判定します。 重要な理由 納期遵守パフォーマンスを測る基本的な基準です。顧客満足度と業務の有効性を示す重要な指標でもあります。 入手先 多くの場合、「Order」オブジェクトにカスタムの日付フィールドとして設定されています。正確なフィールド名は環境によって異なる場合があります。Salesforce Sales Cloudの文書またはスキーマをご確認ください。 例 2023-11-152023-12-012024-01-10 | |||
| 注文総額 TotalOrderAmount | 受注の合計金額です。 | ||
| 説明 この属性は、顧客の注文の合計金額を表します。プロセスの効率化や非効率が事業に与える影響を把握するための重要な指標です。 分析では、注文総額を使ってケースを分類できます。たとえば、高額注文と低額注文で処理方法や遅延の発生状況に違いがあるかを確認できます。また、財務関連の重要業績評価指標(KPI)を算出し、プロセスを通じて扱われる金額を把握するうえでも欠かせません。 重要な理由 注文を金額別に分類してプロセスを財務面から分析できるほか、遅延や手戻りによる金銭的な影響を定量化できます。 入手先 Salesforceの標準「Order」オブジェクトにある「TotalAmount」フィールドです。 例 5400.50125000.00950.75 | |||
| 顧客名 AccountName | 受注した顧客または企業の名前です。 | ||
| 説明 顧客名は、受注に関連付けられた顧客を示します。これにより、顧客を軸にプロセスを分析できます。 この属性を使うと、特定の顧客に絞ってプロセスを確認したり、顧客セグメントごとにパフォーマンスを比較したりできます。また、特定の顧客でプロセス上の問題が繰り返し発生していないかも把握できます。プロセスのパフォーマンスを顧客体験に直接結び付けるための重要な属性です。 重要な理由 プロセスのパフォーマンスを特定の顧客に結び付け、顧客別の分析や分類を通じて傾向や問題を特定できます。 入手先 「Order」オブジェクトには参照フィールド「AccountId」があります。このIDを「Account」オブジェクトと結合すると、「Account.Name」フィールドを取得できます。 例 Global Tech Inc.Innovate Solutions LLCVenture Dynamics | |||
| イベント終了時刻 EventEndTime | アクティビティが完了した正確な日時です。 | ||
| 説明 イベント終了時刻は、アクティビティが完了した時点を示します。多くのプロセスマイニングツールでは、次のアクティビティの開始時刻から終了時刻を推定しますが、終了時刻を明示的に記録すると、特に長時間かかるタスクの所要時間をより正確に把握できます。 この属性を使って、アクティビティの処理時間を正確に算出します。「与信審査完了」や「在庫引当」など、時間のかかるタスクの分析に特に役立ち、実際の処理時間と待ち時間を切り分けられます。 重要な理由 個々のアクティビティの処理時間を正確に算出できます。ボトルネックや多くのリソースを要するステップを特定するうえで重要です。 入手先 同じケース内で後続するイベントの「StartTime」から導出できます。アクティビティによっては、「Task.CompletedDateTime」などの特定の項目を使う場合もあります。 例 2023-10-26T10:05:12Z2023-10-26T15:00:00Z2023-10-27T11:20:30Z | |||
| 与信審査ステータス CreditCheckStatus | 注文の与信審査の結果です。 | ||
| 説明 この属性は、顧客の与信審査の結果を示します。与信審査は、注文プロセスの重要な関門となることがよくあります。値には「承認済み」「却下」「保留中」などがあります。 「与信審査のボトルネック分析」ダッシュボードで重要な属性です。注文が与信審査に入った時点と完了した時点、および最終ステータスを追跡することで、この工程の所要時間や結果を測定し、遅延の原因となっている可能性を特定できます。 重要な理由 与信審査工程の分析に直接役立ち、所要時間や成功率、全体のサイクルタイムへの影響を測定できます。 入手先 「Order」または「Account」オブジェクトに設定されたカスタムフィールドと考えられます。Salesforce Sales Cloudの文書またはスキーマをご確認ください。 例 承認済み却下審査中不要 | |||
| 入金所要時間 PaymentCollectionDuration | 請求書を顧客に送付してから入金を確認するまでの経過時間です。 | ||
| 説明 この計算指標は、受注から入金までのサイクルの最後を担う重要な工程、つまり入金までの効率を測定します。「顧客への請求書送付」アクティビティから「入金確認」アクティビティまでの所要時間です。 この属性は、「入金所要時間」ダッシュボードと「入金実現時間」KPIに直接役立ちます。所要時間を分析すると、財務部門は回収業務のボトルネックや支払い条件の効果を把握し、キャッシュフローを早める方法を見つけられます。 重要な理由 売掛金回収プロセスの効率を測定し、企業のキャッシュフローに直接関わる指標です。 入手先 データ変換時に、各ケースの「入金確認」イベントのタイムスタンプから「顧客への請求書送付」イベントのタイムスタンプを差し引いて算出します。 例 30日15日8時間45日 | |||
| 手戻りの有無 IsRework | アクティビティの繰り返しやプロセスのループなど、受注に手戻りが発生したかどうかを示すフラグです。 | ||
| 説明 この計算属性は、直線的に前へ進むプロセスから外れたケースを特定します。エラーや情報不足、承認の却下などにより、アクティビティが繰り返されたり、プロセスが前の段階に戻ったりすると、手戻りが発生します。 このフラグは、「受注の手戻り率」KPIの算出と「受注の手戻り・エラー率」ダッシュボードに使われます。非効率の発生頻度と影響を定量化し、品質管理の強化やプロセスの明確化が必要な領域を示します。 重要な理由 予定外の追加作業が必要な注文を特定してプロセスの非効率を定量化します。追加作業は、コストとサイクルタイムに直接影響します。 入手先 プロセスマイニングソフトウェア、またはデータ変換時に、ケース内のアクティビティ名の繰り返しやプロセスの逆行を検出して算出します。 例 truefalse | |||
| 注文責任者 OrderOwner | 受注の管理を主に担当するユーザーです。 | ||
| 説明 注文責任者は、注文を主に担当する営業担当者またはアカウントマネージャーです。特定のアクションを実行したユーザーとは異なり、ケース全体の進行に責任を持ちます。 責任者別に分析すると、チームや個人の業務量、担当する注文の管理状況を評価できます。注文が頻繁に停滞したり、手戻りが必要になったりする責任者を特定し、コーチングが必要な領域を見つけることもできます。 重要な理由 注文の成果に責任を持つ担当者を特定し、担当者ごとの業務量やパフォーマンスを分析できます。 入手先 「Order」オブジェクトの「OwnerId」フィールドです。このIDを「User」オブジェクトと結合すると、責任者の名前を取得できます。 例 Jane DoeJohn Smith東部営業チーム | |||
| 納期どおりに納品されたか IsOnTimeDelivery | 顧客の希望納品日までに商品が納品されたかどうかを示すフラグです。 | ||
| 説明 この真偽値属性は、顧客の期待に対する納品パフォーマンスを直接測定します。「商品納品」アクティビティのタイムスタンプと「RequestedDeliveryDate」を比較して算出します。 「納期遵守率」KPIの算出に使われる中心的な指標です。このフラグを分析すると、顧客との約束をどの程度守れているかを把握できます。これは顧客満足度を左右する大きな要因です。他の属性と組み合わせることで、特定の配送方法や地域で納期遵守率が低くなっていないかも確認できます。 重要な理由 顧客との約束に対するパフォーマンスを明確に二分して測定し、納期遵守率KPIの算出に直接役立ちます。 入手先 データ変換時に算出します。ロジックは次のとおりです:IF(「Goods Delivered」EventTime <= 「RequestedDeliveryDate」)THEN true ELSE false。 例 truefalse | |||
| 自動処理かどうか IsAutomated | アクティビティがシステム処理とユーザーのどちらによって実行されたかを示すフラグです。 | ||
| 説明 この真偽値属性は、自動ステータス更新などのシステムによる自動処理と、ユーザーが手動で行った処理を区別します。プロセスの自動化の度合いを把握するための重要な属性です。 この属性を分析すると、自動化が効率や一貫性に与える影響を定量化できます。自動処理と手動処理の経路を比較し、手作業やミスの可能性を減らすために、さらに自動化できる領域を見つけるのにも役立ちます。 重要な理由 システムによる処理とユーザーによる処理を区別し、自動化の分析や手作業を減らせる領域の特定に役立ちます。 入手先 データ変換時に、「UserPerformingAction」が指定されたシステムユーザーかどうかを確認するか、アクティビティの種類に基づくルールを適用して算出します。 例 truefalse | |||
| 製品ファミリー ProductFamily | 注文に含まれる製品のカテゴリまたはファミリーです。 | ||
| 説明 製品ファミリーは、受注に含まれる品目を大まかに分類します。販売する製品の種類に基づいてプロセスを分析できます。 この属性でプロセスを分類すると、製品ファミリーによってプロセスの経路やサイクルタイム、手戻り率に違いがあるかを確認できます。たとえば、複雑で構成を変更できる製品は、標準的な既製品よりも承認や納品の工程が多くなる場合があります。 重要な理由 製品カテゴリ別にプロセスを分析し、製品の種類によってプロセスの効率に違いが生じるかを把握できます。 入手先 「OrderItem」中間オブジェクトを介して「Order」に関連付けられた「Product2」オブジェクトから取得します。Order → OrderItem → PricebookEntry → Product2の順に結合する必要があります。 例 ハードウェアソフトウェアライセンス専門サービスサポート契約 | |||
| 請求書ID InvoiceId | 受注に関連付けられた請求書の一意の識別子です。 | ||
| 説明 請求書IDは、受注と対応する請求書を結び付けます。請求書の作成と送付は、受注から入金までのプロセス後半における重要な節目です。 この属性は、注文の履行から入金までの進捗を追跡するうえで欠かせません。「請求書作成」と「顧客への請求書送付」のアクティビティを正確に測定でき、「入金所要時間」の算出に役立ちます。 重要な理由 受注と請求のサブプロセスを結び付け、財務関連のアクティビティや支払いサイクル時間を正確に追跡できます。 入手先 多くの場合、「Order」オブジェクトに設定されたカスタムの参照フィールドで、標準またはカスタムの「Invoice」オブジェクトを参照します。実装方法は環境によって異なります。 例 INV-001234INV-001235INV-001236 | |||
| 販売チャネル SalesChannel | 「Web」「直接販売」「パートナー」など、受注に使われたチャネルです。 | ||
| 説明 販売チャネル属性は、注文を受注経路ごとに分類します。これにより、チャネル別にプロセスのパフォーマンスを比較できます。 「販売チャネル別パフォーマンス比較」ダッシュボードで重要な属性です。チャネルごとに絞り込んだり比較したりすることで、効率の高いチャネルや手戻りの多いチャネルを特定し、パフォーマンスをそろえるために標準化が必要な領域を把握できます。 重要な理由 事業チャネルごとのパフォーマンスを比較し、効果的な取り組みやプロセスを標準化すべき領域の特定に役立ちます。 入手先 通常、「Order」または「Opportunity」オブジェクトにカスタムの選択リストフィールドとして設定されています。Salesforce Sales Cloudの文書またはスキーマをご確認ください。 例 直接販売ウェブポータルパートナーネットワークインサイドセールス | |||
| 配送先国 ShippingCountry | 受注した商品の配送先の国です。 | ||
| 説明 この属性は、注文品の配送先の国を示します。受注から入金までのプロセスを地理的に分析する際の重要な切り口です。 配送先の国別に分析すると、海外注文の納品に時間がかかる、入金サイクルに差があるといった地域ごとのパフォーマンスの違いが見つかる場合があります。地域別にプロセスを分類することで、その地域特有の課題を把握し、対処できます。 重要な理由 プロセスを地域別に分類し、地域ごとのパフォーマンスの違いやコンプライアンス上の問題、物流上の課題を把握できます。 入手先 Salesforceの標準「Order」オブジェクトにある「ShippingCountry」フィールドです。 例 USAドイツ日本ブラジル | |||
| 配送方法 ShippingMethod | 「通常配送」「速達」「国際配送」など、商品を配送する方法です。 | ||
| 説明 この属性は、注文品の納品に選択された物流サービスのレベルを示します。納期と費用に直接影響します。 「配送方法の効率分析」では、この属性を使って配送方法ごとのパフォーマンスを比較します。速達便が約束した納期を守れているか、また配送方法によって「商品出荷」から「商品納品」までの所要時間がどう変わるかを確認できます。 重要な理由 物流のパフォーマンスを分析し、配送方法ごとの費用と効率を評価できます。 入手先 「Order」オブジェクト、または関連するカスタムの「Shipment」オブジェクトに設定されたカスタムフィールドと考えられます。Salesforce Sales Cloudの文書またはスキーマをご確認ください。 例 通常配送2日速達翌日航空便国際優先配送 | |||
受注から入金までの販売受注処理のアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
| 入金確認 | 顧客からの入金を確認し、消し込みが完了したことを示します。通常、財務システムからSalesforceに情報が連携され、ステータス変更として反映されます。 | ||
| 重要な理由 このイベントは、売上の入金に至る最終ステップです。「請求書送付」からこの時点までの時間を分析することは、キャッシュフローと売上債権回転日数(DSO)の管理に重要です。 入手先 「Invoice」オブジェクトのステータスが「支払済み」または「クローズ」に変更されたことから推定します。会計システムまたは決済処理システムとの連携によって更新されます。 記録 外部の財務システムとの連携による「Invoice」オブジェクトのステータス変更を追跡します。 イベントタイプ inferred | |||
| 受注作成 | システムで受注レコードが初めて作成されたことを示します。Salesforceで新しい「Order」オブジェクトのレコードが初めて保存された時点で、このイベントが明示的に記録されます。 | ||
| 重要な理由 これは、受注から入金までのプロセスにおける主な開始イベントです。この時点から後続のアクティビティまでの時間を分析することは、全体のサイクルタイムを把握するうえで重要です。 入手先 「Order」オブジェクトの作成イベントです。タイムスタンプには、Orderレコードの標準項目「CreatedDate」の値を使用します。 記録 「Order」オブジェクトの「CreatedDate」タイムスタンプを直接使用します。 イベントタイプ explicit | |||
| 受注完了 | 受注が正常に完了し、システム上で最終的にクローズされたことを示します。通常、受注の最終ステータスが更新され、それ以上の対応が不要になったことから推定します。 | ||
| 重要な理由 これは、プロセスの理想経路における主な終了イベントです。このアクティビティまでの合計時間を測定すると、「受注から完了までの平均時間」重要業績評価指標(KPI)を算出できます。 入手先 「Order」オブジェクトの「Status」項目が「クローズ」「完了」「履行済み」などの最終値に変更されたことから推定します。タイムスタンプは項目履歴から確認できます。 記録 「Order」オブジェクトの項目履歴で、ステータスが最終的な完了状態に変更されたことを確認します。 イベントタイプ inferred | |||
| 受注有効化 | 受注が確定し、履行と請求に進める状態になったことを示すSalesforceの標準イベントです。有効化すると、ほとんどの変更ができなくなります。特定のステータス変更によって記録されます。 | ||
| 重要な理由 有効化は、受注の有効性を確認する重要な、取り消しのできない節目です。営業からオペレーションへの正式な引き継ぎであり、営業サイクルタイムの追跡に欠かせません。 入手先 「Order」オブジェクトの標準「Status」項目が「有効」に変更されたことから推定します。タイムスタンプは「Order」項目の履歴に記録されます。 記録 「Order」オブジェクトの項目履歴で、ステータスが「有効」に変更されたことを確認します。 イベントタイプ inferred | |||
| 商品出荷 | 受注品が倉庫から顧客に向けて実際に発送された時点を示します。ほとんどの場合、外部の配送またはERPシステムからSalesforceへの更新によって記録されます。 | ||
| 重要な理由 これは「納期どおりの出荷率」と履行全体の効率を測定するうえで重要な節目です。顧客の購入体験における配送段階の開始を示します。 入手先 「Order」オブジェクト、または関連するカスタム「Shipment」オブジェクトの「出荷日」項目や「追跡番号」項目に値が設定されたことから推定します。データは履行システムから取得します。 記録 出荷日または追跡番号の項目に初めて値が設定された時点のタイムスタンプを使用します。 イベントタイプ inferred | |||
| 商品配達完了 | 配送品が顧客に無事届いたことを示します。配送業者のシステムから情報を取得し、Salesforceに反映します。 | ||
| 重要な理由 このイベントは、「納期どおりの納品率」重要業績評価指標(KPI)の算出と、顧客が実際に経験するサイクルタイムの測定に欠かせません。履行プロセスの完了を確認できます。 入手先 「Order」またはカスタム「Shipment」オブジェクトの「配達日」項目に値が設定されたことから推定します。通常、このデータは配送業者との連携を通じて取得します。 記録 配達日項目に値が設定された時点のタイムスタンプを使用します。 イベントタイプ inferred | |||
| 請求書作成 | 受注に対する請求書が作成されたことを示します。Salesforce Billingで作成された関連する「Invoice」オブジェクト、または連携によって作成されたオブジェクトから記録できます。 | ||
| 重要な理由 この節目から、プロセスの入金に関する段階が始まります。配達から請求までの時間を調べると、キャッシュフローに影響する事務処理上のボトルネックが見つかることがあります。 入手先 「Order」オブジェクトに関連付けられた「Invoice」オブジェクト(標準またはカスタム)の作成日から推定します。 記録 関連するInvoiceレコードの「CreatedDate」を使用します。 イベントタイプ inferred | |||
| 与信審査完了 | 受注に関連付けられた顧客の信用力審査が完了したことを示します。多くの場合、「Credit Check Status」などのカスタム項目が「合格」または「完了」に更新された時点から推定します。 | ||
| 重要な理由 このアクティビティは、大幅な遅延の原因となることがよくあります。所要時間と待ち時間を測定することは、「与信審査のボトルネック分析」ダッシュボードでの分析や、キャッシュフローの改善に役立ちます。 入手先 「Order」または関連する「Account」オブジェクトのカスタム項目のタイムスタンプやステータス変更から推定します。項目の例として、「Credit_Check_Date__c」や「Credit_Status__c」があります。 記録 与信審査の完了を示すカスタム項目の更新を追跡します。 イベントタイプ inferred | |||
| 受注キャンセル | 履行が完了する前に受注がキャンセルされたことを示します。受注レコードの最終ステータス変更から記録します。 | ||
| 重要な理由 これは重要な例外であり、終了イベントです。受注がキャンセルされた理由と時期を分析すると、営業プロセス、商品の在庫状況、または顧客の与信に関する問題が明らかになることがあります。 入手先 「Order」オブジェクトの「Status」項目が「キャンセル」に変更されたことから推定します。タイムスタンプは「Status」項目の履歴で確認できます。 記録 「Order」オブジェクトの項目履歴で、ステータスが「キャンセル」に変更されたことを確認します。 イベントタイプ inferred | |||
| 受注を履行に引き渡し | 有効化された受注を、ピッキングと梱包を行う倉庫または履行システムに引き渡したことを示します。通常、連携によって発生する受注のステータス変更から記録します。 | ||
| 重要な理由 このイベントを境に、プロセスの商取引部分と物流部分が分かれます。有効化からこの時点までの時間を追跡すると、事務処理の遅れと倉庫作業の遅れを切り分けられます。 入手先 「Order」のステータスが「履行に送信済み」や「出荷待ち」などに変更されたことから推定します。このステータス変更は、ERPまたはWMSとの連携によって発生することがよくあります。 記録 「Order」オブジェクトの「Status」項目を確認し、履行への引き渡しを示す値を追跡します。 イベントタイプ inferred | |||
| 受注を承認に申請 | 下書きの受注を正式な承認ワークフローに申請した時点を示します。通常は、受注のステータス変更、またはSalesforceの承認プロセス履歴へのレコード作成から推定します。 | ||
| 重要な理由 申請を追跡すると、受注が承認待ちとなっている時間と、審査プロセス自体の効率を測定できます。承認前のボトルネックも明らかになります。 入手先 「Order」オブジェクトのステータス変更(例:「下書き」から「承認申請済み」)から推定するか、受注に関連付けられた「ProcessInstance」オブジェクトの申請日を追跡します。 記録 ステータス項目の変更を追跡するか、「ProcessInstance」オブジェクトを照会します。 イベントタイプ inferred | |||
| 受注承認 | 必要な関係者全員が受注を正式に承認し、次の段階に進める状態になったことを示します。ワークフローの最終承認ステップ、または対応するステータスの更新を確認して記録します。 | ||
| 重要な理由 これは、履行プロセスに進むための重要な節目です。承認の遅れは、受注から入金までの全体のサイクルタイムに大きく影響する可能性があります。 入手先 「Order」オブジェクトのステータス項目が「承認済み」などに変更されたことから推定します。関連する「ProcessInstance」レコードの完了日から導出することもできます。 記録 「Order」オブジェクトの「Status」項目、または承認プロセス履歴の完了を確認します。 イベントタイプ inferred | |||
| 在庫引当 | 受注の商品が在庫システムで確保されたことを示します。通常、このイベントは外部のERPまたは在庫システムで発生し、項目の変更を通じてSalesforceに反映されます。 | ||
| 重要な理由 このアクティビティは、「在庫引当リードタイム」重要業績評価指標(KPI)の分析に欠かせません。ここでの遅れは、納期どおりに受注品を出荷できるかどうかに直接影響します。 入手先 システムの分析が必要です。「Order」または「OrderItem」オブジェクトのステータス更新、あるいは連携によるカスタム項目「Allocation_Date__c」への値の設定から推定することがよくあります。 記録 ERP連携による「Order」または「OrderItem」オブジェクトのステータス項目や日付項目の変更を追跡します。 イベントタイプ inferred | |||
| 請求書を顧客に送付 | 顧客に支払いを依頼するため、請求書を送付したことを示します。通常、請求書レコードのステータス変更から記録します。 | ||
| 重要な理由 これは「入金までの時間」重要業績評価指標(KPI)の起点となるイベントです。請求書の作成から送付までに遅れがあると、支払期間の開始もその分遅れます。 入手先 「Invoice」オブジェクトのステータスが「送付済み」などに変更されたことから推定します。送信メールのアクティビティログも利用できます。 記録 関連する「Invoice」オブジェクトの「Status」項目を確認するか、メールログのアクティビティを検索します。 イベントタイプ inferred | |||
データ抽出ガイド
ステップ
- 前提条件:項目履歴管理の設定:レポートを作成する前に、Salesforce管理者がOrderオブジェクトの項目履歴管理を有効にしてください。Status項目と、Credit_Check_Status__cやFulfillment_Status__cなど、イベントを示すカスタム項目を追跡対象にします。設定は「設定」>「オブジェクトマネージャー」>「Order」>「項目とリレーション」>「履歴管理の設定」から行います。
- カスタムレポートタイプの作成:受注の詳細と項目変更データをあわせて取得するには、カスタムレポートタイプを作成します。「設定」>「レポートタイプ」に移動し、主オブジェクトをOrdersにして新しいレポートタイプを作成します。次に、Order Historyを関連オブジェクトとして追加します。関連付けの設定は「Aレコードに関連するBレコードが存在する場合と存在しない場合の両方を含める」にします。これにより、履歴のない受注も含めてレポートできます。レポートタイプを「Orders with History」という名前で保存します。
- メインの「Events」レポートの作成:「レポート」タブに移動して「新規レポート」をクリックし、「Orders with History」レポートタイプを選択します。このレポートでは、項目変更に基づくすべてのアクティビティを取得します。
- Eventsレポートの列を設定:次の列を追加します:Order: Order Number(SalesOrderId用)、Edit Date(EventTime用)、User(UserPerformingAction用)、Field/Event(変更された項目)、Original Value、New Value。また、親のOrderオブジェクトからOrder: Total Amount、Account: Account Name、Order: Company Authorized By Date(該当する場合はRequestedDeliveryDateの代替)などの列も追加します。
- Eventsレポートの絞り込み:「表示」フィルターを「すべての受注」に設定し、「日付項目」を「作成日」にして、対象期間(例:過去3か月)を指定します。Field/Event列にもフィルターを追加し、アクティビティに対応する項目変更(例:Status、Credit_Check_Status__c)のみを含めます。
- 「Order Created」レポートの作成:標準のOrdersレポートタイプを使い、受注の作成イベントだけを取得する簡単なレポートをもう1つ作成します。Order Number、Created Date、Created By、Status、Total Amount、Account Nameの列を追加し、希望する期間でCreated Dateを絞り込みます。
- 両方のレポートをエクスポート:両方のレポートを実行し、「エクスポート」を選択します。形式は「詳細のみ」と「カンマ区切り形式の.csv」を選びます。
- データの統合と変換:エクスポートしたCSVファイルをMicrosoft Excelなどの表計算ソフトで開くか、Pythonなどのスクリプト言語を使います。
- 「Events」レポートにActivityName列を新しく作成します。数式またはスクリプトで項目変更データを目的のアクティビティ名に対応付けます。たとえば、Field/Eventが「Status」でNew Valueが「Activated」の場合、ActivityNameを「Order Activated」に設定します。
- 「Order Created」レポートにもActivityName列を追加し、すべての行の値を「Order Created」にします。列名をイベントログのスキーマに合わせて変更します(例:Order Number → SalesOrderId、Created Date → EventTime)。
- 1つのイベントログに統合:変換した「Order Created」データの行を、変換した「Events」データに追加します。これにより、すべてのアクティビティをまとめたイベントログが作成されます。
- アップロード用の仕上げ:残りの必須列を追加します。SourceSystemには固定値「Salesforce Sales Cloud」を、LastDataUpdateには現在のタイムスタンプを設定します。保存前に、すべての列見出しとデータ形式を確認し、アップロードできるCSVファイルとして保存します。
設定
- レポートタイプ:Statusの変更やその他の項目更新を個別のイベントとして取得するには、OrdersとOrder Historyを結合するカスタムレポートタイプが必要です。
- 項目履歴管理:この方法では、データ抽出を始める前にOrderオブジェクトの項目履歴管理を有効にする必要があります。Statusやプロセスのステップを示すカスタム項目など、重要な項目を追跡対象にしてください。
- 期間フィルター:一貫した受注群を分析するため、主なフィルターにはOrderオブジェクトのCreated Dateを使用します。初回の分析では、3~6か月の期間を推奨します。
- データエクスポートサービス:大量データを扱う場合は、代替手段としてデータエクスポートサービスを毎週または毎月実行し、指定したオブジェクト(Order、OrderHistory、Account)の全データをエクスポートできます。取得できるのは生のデータです。外部での結合や処理が多く必要になりますが、対話型レポートビルダーのタイムアウトや行数制限を回避できます。
- 権限:抽出を実行するユーザーには、OrderおよびAccountオブジェクトに対するレポートの実行、レポートのエクスポート、すべてのデータの表示の権限が必要です。データエクスポートサービスの設定には、システム管理者権限が必要です。
- レポート形式:エクスポートと処理を簡単にするため、レポート形式は表形式に設定してください。サマリー形式やマトリックス形式は使用しないでください。
クエリの例 sql
/*
Salesforce Reports are configured through the user interface. This section describes the configuration of the necessary reports and the logic for post-processing. It is not an executable script.
*/
// ======== REPORT 1: Order Creation Events ========
{
"ReportName": "O2C - Order Created",
"ReportType": "Orders",
"Format": "Tabular",
"Filters": [
{
"Field": "Created Date",
"Operator": "equals",
"Value": "[Specify Date Range, e.g., LAST 90 DAYS]"
}
],
"Columns": [
{"SourceField": "Order Number", "OutputAs": "SalesOrderId"},
{"StaticValue": "Order Created", "OutputAs": "ActivityName"},
{"SourceField": 'Created Date', "OutputAs": "EventTime"},
{"SourceField": "Last Modified By: Full Name", "OutputAs": "UserPerformingAction"},
{"SourceField": "Status", "OutputAs": "OrderStatus"},
{"SourceField": "Total Amount", "OutputAs": "TotalOrderAmount"},
{"SourceField": "Account: Account Name", "OutputAs": "AccountName"},
{"SourceField": "[Your Requested Delivery Date Field]", "OutputAs": "RequestedDeliveryDate"}
]
}
// ======== REPORT 2: Order Field Change Events ========
{
"ReportName": "O2C - Order History Events",
"ReportType": "Orders with History (Custom)",
"Format": "Tabular",
"Filters": [
{
"Field": "Order: Created Date",
"Operator": "equals",
"Value": "[Specify Date Range, e.g., LAST 90 DAYS]"
},
{
"Field": "Field/Event",
"Operator": "in",
"Value": ["Status", "[Credit Check Status Field]", "[Inventory Status Field]", "[Fulfillment Status Field]", "[Shipping Status Field]", "[Delivery Status Field]", "[Invoice Status Field]", "[Payment Status Field]"]
}
],
"Columns": [
{"SourceField": "Order: Order Number", "OutputAs": "SalesOrderId"},
{"SourceField": "Edit Date", "OutputAs": "EventTime"},
{"SourceField": "User", "OutputAs": "UserPerformingAction"},
{"SourceField": "Field/Event", "OutputAs": "SourceFieldForActivity"},
{"SourceField": "New Value", "OutputAs": "SourceValueForActivity"},
{"SourceField": "Order: Total Amount", "OutputAs": "TotalOrderAmount"},
{"SourceField": "Account: Account Name", "OutputAs": "AccountName"}
]
}
// ======== EXTERNAL TRANSFORMATION LOGIC (to be applied after export) ========
/*
- Combine the two exported files.
- For the 'Order History Events' data, create the 'ActivityName' and 'OrderStatus' columns based on the following mapping logic:
CASE
WHEN SourceFieldForActivity = 'Status' AND SourceValueForActivity = 'Submitted' THEN 'Order Submitted for Approval'
WHEN SourceFieldForActivity = 'Status' AND SourceValueForActivity = 'Approved' THEN 'Order Approved'
WHEN SourceFieldForActivity = 'Status' AND SourceValueForActivity = 'Activated' THEN 'Order Activated'
WHEN SourceFieldForActivity = '[Fulfillment Status Field]' AND SourceValueForActivity = 'Sent to Fulfillment' THEN 'Order Sent to Fulfillment'
WHEN SourceFieldForActivity = '[Shipping Status Field]' AND SourceValueForActivity = 'Shipped' THEN 'Goods Shipped'
WHEN SourceFieldForActivity = '[Delivery Status Field]' AND SourceValueForActivity = 'Delivered' THEN 'Goods Delivered'
WHEN SourceFieldForActivity = 'Status' AND SourceValueForActivity = 'Closed' THEN 'Order Closed'
WHEN SourceFieldForActivity = 'Status' AND SourceValueForActivity = 'Cancelled' THEN 'Order Cancelled'
WHEN SourceFieldForActivity = '[Credit Check Status Field]' AND SourceValueForActivity = 'Passed' THEN 'Credit Check Performed'
WHEN SourceFieldForActivity = '[Inventory Status Field]' AND SourceValueForActivity = 'Allocated' THEN 'Inventory Allocated'
WHEN SourceFieldForActivity = '[Invoice Status Field]' AND SourceValueForActivity = 'Created' THEN 'Invoice Created'
WHEN SourceFieldForActivity = '[Invoice Status Field]' AND SourceValueForActivity = 'Sent' THEN 'Invoice Sent to Customer'
WHEN SourceFieldForActivity = '[Payment Status Field]' AND SourceValueForActivity = 'Received' THEN 'Payment Received'
ELSE 'Unknown'
END AS ActivityName
- The OrderStatus attribute should be populated with the 'New Value' when the changed field was 'Status'. For other events, you may need to look up the order's status at that point in time, which is a limitation of this method.
- Add 'SourceSystem' and 'LastDataUpdate' columns to the final combined dataset.
*/ 始める準備はできていますか?
このテンプレートを使ってデータを準備し、受注から入金までの販売受注処理の改善を始めましょう。インサイトを得て、業務の効率化とキャッシュフローの改善に役立ててください。
キャッシュフローを改善:販売受注処理を今すぐ最適化
非効率な箇所を特定し、サイクルタイムを30%短縮して、キャッシュフローの改善につなげましょう。
クレジットカード不要 • 数分で利用開始