データテンプレート: 受注から入金まで - 受注処理
貴社の受注から入金までの受注処理データテンプレート
- 収集を推奨する項目
- 追跡すべき主要アクティビティ
- Salesforce Sales Cloudからのデータ抽出ガイド
受注から入金まで - 販売受注処理属性
| 名前 | 説明 | ||
|---|---|---|---|
アクティビティ名 ActivityName | 販売受注のライフサイクル内で発生した特定のビジネス「イベント」または「タスク」名です。 | ||
説明 「アクティビティ名」は、「販売受注プロセス」における「受注作成」、「信用審査実行」、「請求書送付」などのステップを表します。これらの「アクティビティ」は、「プロセスマップ」の構成要素であり、「システムイベント」、「ステータス変更」、または「タスク完了」から導き出されます。 これらの「アクティビティ」を分析することで、「プロセスフロー」の可視化、共通の経路(「バリアント」)の特定、各ステップの頻度と期間の測定が可能になります。これは、「プロセス」内で何が起きているかを理解するための基本です。 その重要性 この属性は、プロセスマップにおける各ステップを定義します。これがなければ、プロセスフローを可視化したり、受注が実際にどのように処理されているかを分析したりすることはできません。 取得元 通常は、「Order.Status」フィールドでのステータス変更、関連レコード(例: Invoice)の作成、またはOrderに関連する完了済みの「Task」や「Event」レコードから取得されます。 例 注文作成注文承認済み商品出荷済み入金済み | |||
イベント日時 EventTime | アクティビティが発生した正確な日時。 | ||
説明 イベントタイム、つまりタイムスタンプは、アクティビティが発生した正確な時刻を記録します。このデータは、イベントを正しく順序付けし、アクティビティ間の期間を計算するために不可欠であり、あらゆる時間軸に基づいたプロセスマイニング分析の基盤となります。 この属性は、各ケースのアクティビティを並べ替え、サイクルタイムを計算し、待機時間を特定し、異なる期間におけるプロセスパフォーマンスを分析するために使用されます。不正確または欠落したタイムスタンプは、分析の有用性を著しく制限する可能性があります。 その重要性 タイムスタンプは、イベントを時系列に並べ、サイクルタイムやボトルネックなど、すべてのパフォーマンスメトリクスを計算するために不可欠です。 取得元 'Order'オブジェクトの'CreatedDate'や'LastModifiedDate'、または関連レコードのフィールドに対応します。特定のイベントについては、'Task'レコードの完了日から取得される場合があります。 例 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:00:00Z | |||
受注 SalesOrderId | 各「販売受注」の一意の識別子であり、「受注から入金までのプロセス」全体を追跡するための主要な「ケース」として機能します。 | ||
説明 「販売受注ID」は、「プロセス分析」の要であり、各顧客の「受注」がそのライフサイクルを通じて進行する際に、一意に識別します。作成や承認から履行、支払いまで、関連するすべての「アクティビティ」をリンクします。 プロセスマイニングでは、特定の「受注」に関連するすべての「イベント」がこのIDに紐付けられます。これにより、「受注」のジャーニーをエンドツーエンドで再構築することができ、個々の「受注」に関する「サイクルタイム」、「プロセスバリエーション」、および「ボトルネック」の詳細な分析が可能になります。 その重要性 この属性は、関連するすべてのイベントを単一のケースにグループ化するために不可欠です。これにより、各受注のエンドツーエンドのプロセスフローを可視化し、分析することが可能になります。 取得元 これは、標準SalesforceのOrderオブジェクトの「Id」項目です。 例 8018d000000XwPBAA08018d000000Y1qCAAS8018d000000Z3kDAB1 | |||
ソースシステム SourceSystem | データが抽出されたシステムを特定します。 | ||
説明 この属性は、プロセスデータの発生源を指定します。この分析では、一貫して「Salesforce Sales Cloud」となります。 複数のシステムが存在する環境では、この項目はデータリネージとトラブルシューティングにとって重要です。単一システム環境においても、データの出所に関する重要なメタデータを提供します。 その重要性 データの発生源に関する不可欠なコンテキストを提供し、データガバナンスや複数のソースシステムからのデータ統合時に重要です。 取得元 これは通常、データ抽出プロセス中にデータセットにラベルを付けるために追加される固定値です。 例 Salesforce Sales Cloud | |||
最終データ更新 LastDataUpdate | 「データ」が最後に抽出または更新された時期を示す「タイムスタンプ」です。 | ||
説明 この属性は、ソースシステムからデータが最後に抽出された日時を記録します。これは、分析対象のデータの鮮度に関する重要なコンテキストを提供します。 アナリストは、この情報を使用して、現在表示しているプロセスデータが最新であるかを確認し、分析結果の関連性を評価します。これは、あらゆるプロセスマイニングプロジェクトにとって重要なメタデータの一部です。 その重要性 ユーザーにデータの鮮度を伝え、分析がどの程度最新であるかを確実に理解してもらえます。 取得元 これは、データ抽出、変換、ロード(ETL)プロセス中に生成および追加されるタイムスタンプです。 例 2023-11-01T05:00:00Z | |||
アクションを実行するユーザー UserPerformingAction | 「アクティビティ」を実行したユーザーまたはシステムエージェントの名前です。 | ||
説明 この属性は、プロセスステップを完了する担当者を特定します。これは、営業担当者、信用アナリスト、または自動化システム利用者である可能性があります。 このユーザーに基づいた分析は、ワークロード配分、個人のパフォーマンス、自動化レベルを理解するために不可欠です。これにより、「どのユーザーが最も手戻りを処理しているか?」や「特定のチームは承認が速いのか?」といった疑問に答えることができます。また、これはソーシャルネットワーク分析にも使用され、個人間でどのように作業が引き継がれているかを把握するのに役立ちます。 その重要性 ユーザー、チーム、またはロールごとのパフォーマンス分析を可能にし、自動化の機会やトレーニングニーズを特定するのに役立ちます。 取得元 'Order'オブジェクトの'LastModifiedById'や'OwnerId'などのフィールドで見つかります。これらのIDは、ユーザー名を取得するために'User'オブジェクトと結合する必要があります。 例 Alice SmithBob Johnsonシステム自動化与信チーム | |||
取引先名 AccountName | 販売受注を行った顧客または会社名です。 | ||
説明 「アカウント名」は、販売受注に関連する顧客を特定します。これにより、顧客中心の視点から「プロセス分析」を行うことが可能になります。 この「属性」を使用することで、アナリストは特定の顧客に絞って「プロセス」をフィルタリングしたり、異なる顧客セグメント間で「プロセスパフォーマンス」を比較したり、特定の顧客が「プロセス」上の問題を継続的に経験していないかを特定できます。「プロセスパフォーマンス」と「顧客体験」を直接結びつける重要な要素です。 その重要性 プロセスパフォーマンスを特定の顧客と関連付け、顧客固有の分析とセグメンテーションを通じてパターンや問題を特定できます。 取得元 Orderオブジェクトには、AccountIdというルックアップ項目があります。このIDをAccountオブジェクトと結合することで、Account.Name項目を取得できます。 例 Global Tech Inc.Innovate Solutions LLCベンチャー・ダイナミクス | |||
受注ステータス OrderStatus | 「イベント」発生時点での「販売受注」のステータスです。 | ||
説明 この「属性」は、「下書き」、「有効化済み」、「出荷済み」、「クローズ済み」など、「販売受注」の「ステータス」を捕捉します。「ステータス変更」は、「プロセスログ」内の「アクティビティ」を生成するソースとなることがよくあります。 「受注ステータス」を分析することは、各「イベント」にコンテキストを提供し、「受注」の進捗を追跡するために不可欠です。例えば、「キャンセル」された「受注」と、「正常にクローズ」された「受注」を識別するなど、「ケース」の結果を理解するのに役立ちます。 その重要性 各イベントの重要なコンテキストを提供し、多くの場合アクティビティを定義する基礎となります。また、キャンセルなどのケース結果を分析する上でも鍵となります。 取得元 これは標準Salesforceの「Order」オブジェクトにある「Status」選択リストです。 例 下書き有効化済み出荷済みクローズ取り消し済み | |||
合計受注金額 TotalOrderAmount | 販売受注の総金額です。 | ||
説明 この属性は、顧客の注文の合計金額を表します。これは、プロセスの効率性や非効率性がビジネスに与える影響を理解するための重要な指標です。 分析では、注文合計金額を用いてケースをセグメント化し、例えば、高額な注文が低額な注文とは異なる処理を受けるか、またはより多くの遅延を経験するかどうかを確認できます。また、財務KPIの算出や、プロセスを通じて流れる価値を理解するためにも不可欠です。 その重要性 プロセスの財務分析を可能にし、注文を金額でセグメント化したり、遅延や手戻りの金銭的影響を定量化したりすることができます。 取得元 これは標準Salesforceの「Order」オブジェクトにある「TotalAmount」フィールドです。 例 5400.50125000.00950.75 | |||
希望納期 RequestedDeliveryDate | 顧客から要求された、受注品の配送日です。 | ||
説明 この属性は、顧客が商品を受け取る希望配送日を保存します。これは、配送パフォーマンスと顧客満足度を測定するための重要なベンチマークとして機能します。 この日付は、「納期遵守トラッキング」ダッシュボードや「定時配送率」KPIで直接使用されます。実際の配送日(「配送完了」タイムスタンプ)と比較され、注文が定時に、早期に、または遅延して配送されたかを判断します。 その重要性 これは、顧客満足度と業務の有効性を示す主要な指標である定時配送パフォーマンスを測定するための主要なベンチマークです。 取得元 これは、多くの場合、Orderオブジェクトのカスタム日付項目です。正確な名称は異なる場合があります。Salesforce Sales Cloudのドキュメントまたはスキーマを参照してください。 例 2023-11-152023-12-012024-01-10 | |||
総サイクルタイム CycleTime | 販売受注の作成から最終的な完了までの総経過時間です。 | ||
説明 総サイクルタイムは、販売受注プロセスのエンドツーエンドの期間を測定する主要なパフォーマンス指標です。最初のイベント(例:「受注作成」)と最後のイベント(例:「受注完了」)の時間差として算出されます。 このメトリクスは、「販売受注エンドツーエンドサイクルタイム」ダッシュボードの主要な焦点です。サイクルタイムを分析することで、全体的なプロセスの非効率性を特定し、改善イニシアティブの効果を測定できます。サイクルタイムのバリエーションは、国や製品ファミリーなどの他の属性でデータをスライスすることで調査可能です。 その重要性 これは、全体的なプロセス効率を測定し、システム上の問題を示唆する可能性のある長期間処理中の注文を特定するための基本的なKPIです。 取得元 データ変換中に、各'SalesOrderId'について最後のイベントのタイムスタンプから最初のイベントのタイムスタンプを差し引くことで計算されます。 例 10日4時間25日11時間5日2時間 | |||
イベントの終了時刻 EventEndTime | 「アクティビティ」が完了した正確な日時です。 | ||
説明 「イベント終了時刻」は、「アクティビティ」の完了を示します。多くのプロセスマイニングツールは次の「アクティビティ」の開始時刻からこれを推測しますが、明示的に取得することで、特に「長期実行タスク」において、より正確な「アクティビティ期間」を提供できます。 この「属性」は、「アクティビティ」の正確な処理時間を計算するために使用されます。「信用審査実行」や「在庫割り当て」のような、かなりの期間を要する「タスク」の分析に特に有効であり、実処理時間とアイドル待機時間を区別するのに役立ちます。 その重要性 個々のアクティビティ処理時間を正確に計算できます。これは、ボトルネックやリソースを多く消費するステップを特定するために不可欠です。 取得元 特定のケースのシーケンスにおける後続イベントの'StartTime'から派生できます。一部のアクティビティでは、'Task.CompletedDateTime'のような特定のフィールドである場合があります。 例 2023-10-26T10:05:12Z2023-10-26T15:00:00Z2023-10-27T11:20:30Z | |||
与信チェックステータス CreditCheckStatus | その受注に対する「信用審査プロセス」の結果です。 | ||
説明 この属性は、顧客の信用評価の結果を示します。これは、注文プロセスにおける重要な関門となることがよくあります。一般的な値には、「承認済み」、「却下済み」、「審査中」などがあります。 これは、「信用審査ボトルネック分析」ダッシュボードにとって不可欠です。注文が信用審査フェーズに入ったタイミングと完了したタイミング、およびその最終ステータスを追跡することで、組織はこのステップの期間と結果を測定し、遅延の潜在的原因として特定することができます。 その重要性 与信チェックステップの分析を直接サポートし、その期間、成功率、および全体的なサイクルタイムへの影響を測定するのに役立ちます。 取得元 これは、OrderオブジェクトまたはAccountオブジェクトのカスタム項目である可能性が高いです。Salesforce Sales Cloudのドキュメントまたはスキーマを参照してください。 例 承認済み却下審査中不要 | |||
処理時間 ProcessingTime | 個々の「アクティビティ」の「期間」であり、実作業時間を表します。 | ||
説明 処理時間とは、タスクに積極的に費やされた時間であり、アクティビティの終了時間と開始時間の差として算出されます。これは、アクティビティ間のアイドル時間である待機時間とは異なります。 この指標は、「Credit Check Performed」アクティビティのようなボトルネック分析にとって不可欠です。アクティブな処理時間を切り分けて分析することで、遅延がタスク自体の非効率な作業によるものなのか、あるいはタスク開始前の長い待機列によるものなのかを判断できます。 その重要性 特定のタスクにおけるアクティブな作業時間を特定し、非効率な活動と長い待機時間を区別するのに役立ちます。 取得元 データ変換中に、'EventEndTime'から'EventTime'('StartTime')を差し引くことで計算されます。 例 5分2時間15分45秒 | |||
出荷国 ShippingCountry | 販売受注の出荷先国です。 | ||
説明 この属性は、注文が発送される国を指定します。これは、受注から入金までのプロセスの地域分析における重要なディメンションです。 発送国別に分析することで、国際注文における配送時間の延長や支払回収サイクルの変動など、プロセスパフォーマンスにおける地域差を明らかにすることができます。これにより、プロセスをセグメント化し、地域固有の課題を理解して対処することが可能になります。 その重要性 プロセスの地理的セグメンテーションを可能にし、これにより、地域ごとのパフォーマンスの違い、コンプライアンス問題、または物流上の課題を浮き彫りにすることができます。 取得元 これは標準Salesforceの「Order」オブジェクトにある「ShippingCountry」フィールドです。 例 米国ドイツ日本ブラジル | |||
出荷方法 ShippingMethod | 「標準陸上輸送」、「速達」、「国際便」など、商品の配送に選択された方法です。 | ||
説明 この属性は、注文の配送に選択された物流サービスレベルを示します。これは配送期間とコストに直接影響します。 「配送方法効率分析」ダッシュボードでは、この属性を用いて異なる配送オプションのパフォーマンスを比較します。これにより、速達便が納期を満たしているか、また、異なる方法が全体の「出荷済み」から「配送完了」までの期間にどのように影響するかを判断するのに役立ちます。 その重要性 ロジスティクスのパフォーマンス分析を可能にし、さまざまな配送オプションのコストと効率を評価するのに役立ちます。 取得元 これは、Orderオブジェクト、または関連するカスタムShipmentオブジェクトのカスタム項目である可能性が高いです。Salesforce Sales Cloudのドキュメントまたはスキーマを参照してください。 例 標準陸上輸送2日エクスプレス翌日航空便国際優先便 | |||
手戻り IsRework | 営業注文が、繰り返しのActivityやプロセス内のループなどの手戻りを経たかどうかを示すフラグです。 | ||
説明 この算出属性は、線形かつ順方向への進行から逸脱するケースを特定します。手戻りは、アクティビティが繰り返される場合や、プロセスが以前の段階にループバックする場合に発生し、これは多くの場合、エラー、情報不足、または却下された承認が原因です。 このフラグは、「受注手戻り率」KPIを算出し、「受注手戻りおよびエラー率」ダッシュボードの基盤となります。これにより、非効率性の頻度と影響を定量化し、より良い品質管理やプロセスの明確化が必要な領域を特定するのに役立ちます。 その重要性 余分な、計画外の作業を必要とする注文にフラグを立てることで、プロセスの非効率性を定量化し、コストとサイクルタイムに直接影響を与えます。 取得元 プロセスマイニングソフトウェア、またはデータ変換中に、特定のケースにおける繰り返されるアクティビティ名や逆行するプロセスフローを検出することで計算されます。 例 truefalse | |||
支払回収期間 PaymentCollectionDuration | 顧客への請求書送付から支払い受領までの経過時間です。 | ||
説明 この算出メトリクスは、受注から入金までのサイクルにおける最終的かつ重要な段階、つまり支払いの効率性を測定します。これは、「顧客への請求書送付」アクティビティと「入金」アクティビティの間の期間です。 この属性は、「支払回収期間」ダッシュボードおよび「支払い実現時間」KPIを直接サポートします。この期間を分析することで、財務部門は回収におけるボトルネックを特定し、支払条件の有効性を評価し、キャッシュフローを加速する機会を見つけることができます。 その重要性 売掛金プロセスの効率を測定し、会社のキャッシュフローに直接影響を与えます。 取得元 データ変換中に、各ケースについて'Payment Received' イベントのタイムスタンプから'Invoice Sent to Customer' イベントのタイムスタンプを差し引くことで計算されます。 例 30日間15日8時間45日間 | |||
注文所有者 OrderOwner | 販売受注の管理に責任を持つ主要なユーザーです。 | ||
説明 「受注担当者」は、「受注」に対して主要な責任を持つ「営業担当者」または「アカウントマネージャー」を指します。特定の「アクション」を実行するユーザーとは異なり、この担当者は「ケース」全体の進行に責任を負います。 「担当者」別に分析することで、チームまたは個人の「ワークロード」や「受注」ポートフォリオ管理におけるパフォーマンスを評価するのに役立ちます。どの担当者が担当する「受注」が頻繁に滞ったり、「手戻り」が発生したりしているかを明確にし、潜在的な指導の機会を示すことができます。 その重要性 受注の成功に責任を持つ担当者を特定し、担当者レベルでのワークロードとパフォーマンスの分析に役立ちます。 取得元 「Order」オブジェクトの「OwnerId」フィールドです。このIDを「User」オブジェクトと結合することで、所有者の名前を取得できます。 例 ジェーン・ドウJohn Smith東日本営業チーム | |||
納期内配送 IsOnTimeDelivery | 商品が顧客の希望納期までに配送されたかどうかを示すフラグです。 | ||
説明 この真偽値属性は、顧客の期待に対する配送パフォーマンスの直接的な測定基準です。「商品配送完了」アクティビティのタイムスタンプと「希望配送日」を比較することで算出されます。 これは、「定時配送率」KPIの主要な計算となります。このフラグを分析することで、組織は信頼性とコミットメントへの遵守を理解できます。これらは顧客満足度の主要な推進要因です。他の属性と組み合わせることで、特定の配送方法や地域で定時配送率が低いかどうかを明らかにできます。 その重要性 顧客との約束に対するパフォーマンスを明確かつ二値的に測定する指標であり、オンタイムデリバリー率KPIを直接的に支援します。 取得元 データ変換中に計算されます。ロジックは次のとおりです:IF ('Goods Delivered' EventTime <= 'RequestedDeliveryDate') THEN true ELSE false。 例 truefalse | |||
自動化 IsAutomated | そのActivityがシステムプロセスによって実行されたか、人間のユーザーによって実行されたかを示すフラグです。 | ||
説明 この真偽値属性は、自動ステータス更新などのシステムの自動化によってトリガーされるイベントと、ユーザーが手動で実行するイベントを区別します。これは、プロセスにおける自動化のレベルを理解する上で重要です。 この属性を分析することで、自動化が効率性と一貫性に与える影響を定量化できます。自動化された経路と手動の経路を比較でき、手作業の削減やエラーの可能性を減らすためのさらなる自動化の機会を浮き彫りにすることが可能です。 その重要性 システムとユーザーのアクションを区別するのに役立ち、自動化分析や手作業を削減するための機会を特定する上で不可欠です。 取得元 データ変換中に、'UserPerformingAction'が指定されたシステムユーザーであるかをチェックするか、またはアクティビティタイプに基づいたルールによって派生されます。 例 truefalse | |||
製品ファミリー ProductFamily | 受注に含まれる製品が属するカテゴリまたはファミリーです。 | ||
説明 「製品ファミリー」は、販売受注に含まれる品目の上位レベルでの分類を提供します。これにより、販売される製品の種類に基づいた「プロセス分析」が可能になります。 この「属性」は、「プロセス」をセグメント化し、特定の「製品ファミリー」が異なる「プロセスパス」、「より長いサイクルタイム」、または「より高い手戻り率」を持つかどうかを判断するために使用できます。例えば、複雑で設定可能な製品は、標準的な既製製品よりも詳細な承認および履行「プロセス」をたどる可能性があります。 その重要性 製品カテゴリ別にセグメント化されたプロセス分析を可能にし、製品の種類によってプロセス効率に変動が生じるかどうかを明らかにします。 取得元 「Product2」オブジェクトから取得されます。これは「OrderItem」ジャンクションオブジェクトを介して「Order」にリンクされており、Order -> OrderItem -> PricebookEntry -> Product2の結合が必要です。 例 Hardwareソフトウェアライセンスプロフェッショナルサービスサポート契約 | |||
請求書ID InvoiceId | 「販売受注」に関連付けられた「請求書」の一意の識別子です。 | ||
説明 「請求書ID」は、「販売受注」とそれに対応する「財務請求書」をリンクします。この請求書の作成と送付は、「受注から入金までのプロセス」の後半における主要なマイルストーンです。 この「属性」は、受注品の履行から支払いまでの「プロセス」を追跡するために不可欠です。「請求書作成」および「顧客への請求書送付」の「アクティビティ」を正確に測定することを可能にし、これは「支払い回収期間」の算出に必要となります。 その重要性 受注を請求サブプロセスと連携させ、財務活動や支払サイクルタイムを正確に追跡できます。 取得元 これは、多くの場合、Orderオブジェクト上のカスタムルックアップ項目であり、標準またはカスタムのInvoiceオブジェクトを指します。正確な実装は異なります。 例 INV-001234INV-001235INV-001236 | |||
販売チャネル SalesChannel | 「Web」、「直販」、「パートナー」など、販売受注が行われた「チャネル」です。 | ||
説明 「販売チャネル」属性は、「受注」をその発生源に基づいて分類します。これにより、異なる「チャネル」間での「プロセスパフォーマンス」の比較分析が可能になります。 これは、「販売チャネル別パフォーマンス比較」ダッシュボードにとって不可欠です。「チャネル」でフィルタリングまたは比較することで、企業はどの「チャネル」が最も効率的か、どの「チャネル」で最も「手戻り」が多いか、そしてパフォーマンスを合わせるためにどの「標準化」努力が必要かを特定できます。 その重要性 異なるビジネスチャネル間でのパフォーマンス比較を可能にし、ベストプラクティスとプロセス調和の領域を特定するのに役立ちます。 取得元 これは通常、「Order」または「Opportunity」オブジェクト上のカスタム選択リストです。Salesforce Sales Cloudのドキュメントまたはスキーマを参照してください。 例 直販Webポータルパートナーネットワークインサイドセールス | |||
受注から入金まで - 販売受注処理アクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
入金済み | 顧客からの支払いが受領され、照合済みであることが確認されたことを示します。この情報は通常、ステータス変更として財務システムからSalesforceに更新されます。 | ||
その重要性 このイベントは、売上からの現金を回収する最終ステップです。「請求書送付」からこの時点までの時間を分析することは、キャッシュフローと売掛金回収日数(DSO)の管理にとって重要です。 取得元 Invoiceオブジェクトのステータスが「Paid」または「Closed」に変更されたことから推測されます。この更新は、会計または支払処理システムとの連携によって行われます。 取得 外部財務システム連携からの「Invoice」オブジェクトにおけるステータス変更を追跡します。 イベントタイプ inferred | |||
商品出荷済み | 注文が倉庫から顧客へ物理的に発送された瞬間を示します。このイベントは、ほとんどの場合、外部の出荷システムまたはERPシステムからSalesforceへの更新によって捕捉されます。 | ||
その重要性 これは、「定時出荷率」と全体的なフルフィルメント効率を測定するための重要なマイルストーンです。これは、カスタマージャーニーにおける配送フェーズの開始を示します。 取得元 Orderオブジェクトまたは関連するカスタムShipmentオブジェクトのShipped DateフィールドまたはTracking Numberフィールドの入力から推測されます。このデータはフルフィルメントシステムから発生します。 取得 出荷日付または追跡番号フィールドが最初に入力されたときのタイムスタンプを使用します。 イベントタイプ inferred | |||
商品配送済み | 出荷が顧客に正常に配達されたことを示します。この情報は運送会社のシステムから提供され、Salesforceに更新されます。 | ||
その重要性 このイベントは、「定時配送率」KPIの算出と実際の顧客向けサイクルタイムの測定に不可欠です。これにより、フルフィルメントプロセスが完了したことを確認できます。 取得元 OrderまたはカスタムShipmentオブジェクトのDelivery Dateフィールドの入力から推測されます。このデータは通常、輸送ロジスティクスプロバイダーとの連携を通じて提供されます。 取得 配送日付フィールドが入力されたときのタイムスタンプを使用します。 イベントタイプ inferred | |||
注文作成 | システム内で受注レコードが最初に作成されたことを示します。このイベントは、新しいOrderオブジェクトのインスタンスがSalesforceに初めて保存されたときに明示的に捕捉されます。 | ||
その重要性 これは受注から入金までのプロセスの主要な開始イベントです。この時点から後続のアクティビティまでの時間を分析することは、全体的なサイクルタイムを理解する上で不可欠です。 取得元 Orderオブジェクトの作成「イベント」です。「タイムスタンプ」は、Orderレコードの標準CreatedDateフィールドの値となります。 取得 'Order'オブジェクトの'CreatedDate' タイムスタンプから直接取得されます。 イベントタイプ explicit | |||
注文完了 | システム内での受注の正常な完了と最終的なクローズを示します。これは、注文の最終ステータス更新から推論され、それ以上の活動が不要であることを示します。 | ||
その重要性 これはプロセスの主要な「ハッピーパス」の終了イベントです。このアクティビティまでの合計時間を測定することで、「平均受注から完了までの時間」KPIが算出されます。 取得元 OrderオブジェクトのStatusフィールドが、「Closed」、「Completed」、「Fulfilled」のような最終値に変更されたことから推測されます。タイムスタンプは、フィールド履歴トラッキングを通じて利用できます。 取得 Orderオブジェクトの項目履歴で、最終的な完了ステータスへの変更を監視します。 イベントタイプ inferred | |||
注文有効化済み | Salesforceの標準的なイベントで、注文が最終化され、履行および請求に進むことができることを示します。有効化により、ほとんどの変更から注文がロックされ、特定のStatus変更によって捕捉されます。 | ||
その重要性 有効化は、注文の有効性を確認する重要で元に戻せないマイルストーンです。これは営業から運用への公式な引き渡しであり、営業サイクルタイムを追跡するための主要なコンポーネントです。 取得元 標準のOrderオブジェクトのStatus項目がActivatedに変更されたことに基づいて推測されます。タイムスタンプはOrderの項目履歴追跡に記録されます。 取得 Orderオブジェクトの項目履歴で、Activatedへのステータス変更を監視します。 イベントタイプ inferred | |||
請求書作成 | 受注に対する請求書の生成を示します。これは、Salesforce Billingによるネイティブな方法、または連携を通じて、関連する「Invoice」オブジェクトの作成によって捕捉できます。 | ||
その重要性 このマイルストーンは、プロセスの資金回収フェーズの開始を示します。配送から請求書発行までの時間は、キャッシュフローに影響を与える管理上のボトルネックを明らかにする可能性があります。 取得元 OrderオブジェクトにリンクされたInvoiceオブジェクト(標準またはカスタム)の作成日から推測されます。 取得 関連するInvoiceレコードの「CreatedDate」を使用します。 イベントタイプ inferred | |||
フルフィルメントへ注文送付済み | 有効化された注文がピッキングと梱包のために倉庫またはフルフィルメントシステムに引き渡されたことを示します。これは通常、統合によってトリガーされる注文ステータスの変更として捕捉されます。 | ||
その重要性 このイベントは、プロセスの商業面と物流面を分離します。アクティベーションからこの時点までの時間を追跡することで、管理上の遅延を倉庫処理の遅延から特定するのに役立ちます。 取得元 Orderステータスが、「Sent to Fulfillment」や「Awaiting Shipment」のような値に変更されたことから推測されます。このステータス変更は、多くの場合、ERP/WMSとの連携によってトリガーされます。 取得 OrderオブジェクトのStatus項目で、フルフィルメントへの引き渡しを示す特定の値を監視します。 イベントタイプ inferred | |||
与信審査実施 | 注文に関連する顧客の信用照会が完了したことを示します。これはしばしば推論されるイベントであり、「Credit Check Status」などのカスタムフィールドが「Passed」または「Completed」に更新されたときに捕捉されます。 | ||
その重要性 この「アクティビティ」は、しばしば大幅な遅延の原因となります。その「期間」と「待機時間」を測定することは、「信用審査ボトルネック分析」ダッシュボードに対処し、「キャッシュフロー」を改善するための鍵となります。 取得元 Orderまたは関連するAccountオブジェクトのカスタムフィールド(例:Credit_Check_Date__cやCredit_Status__c)におけるタイムスタンプまたはステータス変更から推測されます。 取得 信用照会の完了を示すカスタムフィールドへの更新を追跡します。 イベントタイプ inferred | |||
受注キャンセル | 履行が完了する前に注文がキャンセルされたことを示します。これは、注文レコードの最終ステータス変更によって捕捉されます。 | ||
その重要性 これは重要な例外かつ終了イベントです。注文がキャンセルされる理由とタイミングを分析することで、販売プロセス、製品の可用性、または顧客の信用における問題を明らかにすることができます。 取得元 OrderオブジェクトのStatusフィールドが「Cancelled」に変更されたことから推測されます。タイムスタンプは、Statusフィールドのフィールド履歴で確認できます。 取得 Orderオブジェクトの項目履歴で、Cancelledステータスへの変更を監視します。 イベントタイプ inferred | |||
在庫割り当て済み | 注文の製品が在庫管理システムで予約されたことを示します。このイベントは通常、外部ERPまたは在庫システムで発生し、フィールド変更を通じてSalesforceを更新します。 | ||
その重要性 この「アクティビティ」は、「在庫割り当てリードタイム」KPIの分析にとって極めて重要です。ここでの遅延は、「受注品」を期日通りに出荷する能力に直接影響します。 取得元 システム分析が必要です。多くの場合、「Order」または「OrderItem」オブジェクトのステータス更新、または連携によって駆動されるカスタム「Allocation_Date__c」フィールドの入力から推論されます。 取得 ERP連携からのOrderまたはOrderItemオブジェクトにおけるステータスまたは日付フィールドの変更を追跡します。 イベントタイプ inferred | |||
承認のために注文提出済み | 下書き状態の注文が正式な承認ワークフローに提出される時点を示します。これは通常、注文のステータス変更、またはSalesforceの承認プロセス履歴にレコードが作成されることによって推論されます。 | ||
その重要性 提出を追跡することで、受注が承認待ちにかかる時間や審査プロセス自体の効率を測定できます。これにより、承認前のボトルネックが浮き彫りになります。 取得元 Orderオブジェクトのステータス変更(例:「Draft」から「Submitted for Approval」へ)または、注文に関連するProcessInstanceオブジェクト内の提出日を追跡することで推測されます。 取得 ステータスフィールドの変更を追跡するか、「ProcessInstance」オブジェクトをクエリします。 イベントタイプ inferred | |||
注文承認済み | 受注がすべての関係者によって正式に承認され、次の段階に進むことができることを示します。これは、ワークフローにおける最終承認ステップまたは対応するステータスの更新を観察することで捕捉されます。 | ||
その重要性 これは、フルフィルメントプロセスを開始させる重要なマイルストーンです。承認の遅延は、全体的な受注から入金までのサイクルタイムに大きく影響する可能性があります。 取得元 Orderオブジェクトのステータスフィールドが「Approved」のような値に変更されたことから推測されます。これは、関連するProcessInstanceレコードの完了日からも導出できます。 取得 OrderオブジェクトのStatus項目、または承認プロセスの完了を監視します。 イベントタイプ inferred | |||
顧客へ請求書送付済み | 請求書が顧客に支払いのため発送されたことを示します。これは通常、請求書レコードのステータス変更として捕捉されます。 | ||
その重要性 これは「入金までの時間」KPIのトリガーイベントです。請求書作成から送付までの遅延は、支払期間の開始を直接遅らせることになります。 取得元 Invoiceオブジェクトのステータスが「Sent」または類似の値に変更されたことから推測されます。送信済みメールのアクティビティログエントリも使用できます。 取得 関連するInvoiceオブジェクトのStatus項目を監視するか、メールログ活動を調べます。 イベントタイプ inferred | |||
抽出ガイド
ステップ
- 前提条件: フィールド履歴トラッキングの設定: レポートを作成する前に、Salesforceの管理者はOrderオブジェクトに対してフィールド履歴トラッキングが有効になっていることを確認する必要があります。具体的には、Statusフィールドや、Credit_Check_Status__c、Fulfillment_Status__cなどのイベントを示すために使用されるカスタムフィールドを追跡します。これは、設定 > オブジェクトマネージャー > Order > 項目とリレーション > 履歴の追跡を設定で行います。
- カスタムレポートタイプの作成: 注文の詳細とともにフィールド変更データにアクセスするには、カスタムレポートタイプを作成します。設定 > レポートタイプに移動します。主オブジェクトとしてOrdersを使用して新しいレポートタイプを作成します。次に、副オブジェクトとしてOrder Historyを関連付けます。リレーションシップが「"A" レコードには関連する "B" レコードがある場合とない場合があります」に設定されていることを確認してください。これにより、履歴がまだない注文も含むすべての注文をレポートできます。このレポートタイプを「履歴付き注文」として保存します。
- メインの「イベント」レポートの作成: レポートタブに移動し、新規レポートをクリックします。「履歴付き注文」レポートタイプを選択します。このレポートは、フィールド変更に基づいたすべてのActivityを捕捉します。
- イベントレポートの列の設定: 次の列を追加します: 注文: 注文番号(SalesOrderId用)、編集日付(EventTime用)、ユーザー(UserPerformingAction用)、項目/イベント(変更されたフィールド)、元の値、新しい値。Order親オブジェクトから、注文: 合計金額、取引先: 取引先名、注文: 会社承認日付(該当する場合はRequestedDeliveryDateのプロキシとして)などの他の列も追加します。
- イベントレポートのフィルタリング: 表示フィルターをすべての注文に、日付項目を作成日に、希望の範囲(例: 過去3ヶ月)で設定します。項目/イベント列にフィルターを追加し、Activityに対応する特定のフィールド変更(例: Status、Credit_Check_Status__c)のみを含めるようにします。
- 「注文作成」レポートの作成: 標準のOrdersレポートタイプを使用して、2番目のよりシンプルなレポートを作成します。このレポートの目標は、作成イベントのみを捕捉することです。注文番号、作成日、作成者、Status、合計金額、取引先名の列を追加します。希望の期間で作成日をフィルターします。
- 両方のレポートのエクスポート: 両方のレポートを実行し、エクスポートオプションを使用します。フォーマットは詳細のみ、ファイル形式はコンマ区切り.csvを選択します。
- データの結合と変換: エクスポートされたCSVファイルをMicrosoft Excelのようなスプレッドシートプログラム、またはPythonのようなスクリプト言語で開きます。
- 「イベント」レポートの場合、新しいActivityName列を作成します。数式またはスクリプトを使用して、フィールド変更データを希望のActivity名にマッピングします。例えば、項目/イベントがStatusで新しい値がActivatedの場合、ActivityNameを「注文有効化」に設定します。
- 「注文作成」レポートの場合、ActivityNameという名前の新しい列を追加し、すべての行に「注文作成」という値を設定します。列名をイベントログのスキーマに一致するように変更します(例: 注文番号 -> SalesOrderId、作成日 -> EventTime)。
- 単一のイベントログへのマージ: 変換された「注文作成」データの行を、変換された「イベント」データに追加します。これにより、すべてのActivityの単一の統合リストが作成されます。
- アップロードのための最終化: 残りの必須列を追加します: SourceSystem(Salesforce Sales Cloudという静的な値)とLastDataUpdate(現在のタイムスタンプ)。最終ファイルをCSVとして保存する前に、すべての列ヘッダーとデータ形式を確認し、アップロードの準備をします。
設定
- レポートタイプ:OrdersとOrder Historyを結合するカスタムレポートタイプは、ステータス変更やその他の項目更新を個別のイベントとして捕捉するために不可欠です。
- 項目履歴管理:このデータ抽出方法を適用するには、抽出を開始する前に、Orderオブジェクトの項目履歴管理を有効にしておく必要があります。Statusなどの主要項目や、プロセスステップを表すカスタム項目はすべて追跡される必要があります。
- 日付範囲フィルター:一貫した注文群を分析するために、OrderオブジェクトのCreated Dateを主要なフィルターとして使用します。初期分析には3〜6ヶ月の範囲が推奨されます。
- データエクスポートサービス:大量データ環境における代替手段として、データエクスポートサービスを(週次または月次で)スケジュール設定し、指定されたオブジェクト(Order、OrderHistory、Account)のすべてのデータを出力できます。このサービスを利用すると、より多くの外部処理やデータ結合が必要となる生データが得られるものの、対話型レポートビルダーで発生するタイムアウトや行制限を回避できます。
- 権限:抽出を実行するユーザーは、OrderオブジェクトおよびAccountオブジェクトに対してRun Reports、Export Reports、View All Dataの権限が必要です。データエクスポートサービスの設定にはSystem Administratorの権限が必要です。
- レポート構造:レポートは、最も簡単なエクスポートと処理のためにTabular Formatに設定する必要があります。サマリー形式やマトリックス形式は避けてください。
a クエリ例 config
/*
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.
*/