データテンプレート: 受注から入金まで - 受注処理

アクティビティ名は、受注ライフサイクルにおける具体的なステップや節目（例：「Sales Order Created」「Credit Check Performed」「Goods Shipped」）を表します。各アクティビティは受注に対して行われた個別の行為であり、プロセスマップの基本要素です。

分析の中核となる属性です。プロセスの流れを可視化し、よくある経路の把握や標準手順からの逸脱の発見に役立ちます。アクティビティの並びを追うことで、ボトルネック、手戻りループ（例：「Sales Order Changed」の繰り返し）、標準から外れたバリエーションを特定できます。ダッシュボード「Process Conformance and Deviations」やKPI「Sales Order Rework Rate」の基盤となります。

プロセス内のステップを定義し、プロセスマップの可視化、プロセスフローの分析、そして手戻りや逸脱の特定を可能にします。

ソースシステムの販売、配送、請求モジュール内のドキュメントステータス変更、イベントログ、またはトランザクションコードから導出されることがよくあります。

Event Timeは、アクティビティが発生した正確な瞬間を記録するタイムスタンプです。プロセスに時間的な文脈を与え、受注に紐づく全イベントを時系列で並べることを可能にします。

このタイムスタンプは、時間に基づくあらゆる分析の要です。任意の2つのアクティビティ間のサイクルタイム計算、各ステップの所要時間の把握、遅延やボトルネックの特定に用います。たとえばKPI「Order Fulfillment Cycle Time」は、最終の納品アクティビティのEvent Timeと、最初の受注作成アクティビティのEvent Timeの差で計算します。ダッシュボード「Sales Order Cycle Time Overview」は、この属性に全面的に依存しています。

このタイムスタンプは、ボトルネックを特定するために不可欠な、サイクルタイムや期間などの全てのパフォーマンス指標を計算する上で極めて重要です。

通常、各トランザクションまたはステータス更新記録とともに見られ、作成日、変更日、または計上日としてラベル付けされていることがよくあります。

Sales Order IDは、Order to Cashにおけるプロセスマイニングの要で、受注が作成されてからクローズされるまでの各インスタンスを一意に識別します。関連する全アクティビティ、イベント、データポイントを結びつけ、1件の受注のエンドツーエンドの軌跡を形成する主キーです。

分析では、この属性により各受注のライフサイクルを再構築します。イベントの順序を追跡し、アクティビティ間の所要時間を測定し、受注単位でメトリクスを集計します。たとえばKPI「Order Fulfillment Cycle Time」を計算するには、Sales Order IDごとにアクティビティをグループ化し、最初と最後のイベントの時間差を求めます。

このIDは、プロセス全体で個々の受注を追跡するために不可欠であり、サイクルタイム、ボトルネック、逸脱のケースレベル分析を可能にします。

通常、ソースERPまたはCRMシステムにおける受注伝票のヘッダーテーブルで見られます。

Source System属性は、イベントデータが生成された記録元システムを示します。現代の企業では、Order to Cashのようなエンドツーエンドのプロセスが複数のアプリケーションにまたがるのが一般的で、たとえば受注作成はCRM、フルフィルメントと請求はERPが担います。

分析では、プロセスのシステム全体像を理解するのに有用です。システム間の連携ポイントやデータ整合性の課題を特定できます。ソースシステム別にアクティビティを分析すると、実行システムによって工程の扱いが異なったり、遅延が起きやすいステップを明らかにできます。

データの発生元に関するコンテキストを提供します。これは、複数のシステムが存在する環境でデータの系統を追跡し、システム固有のプロセスバリエーションを特定するために不可欠です。

この情報は、多くの場合、データ抽出（ETL）プロセス中に追加されるか、データウェアハウスの標準フィールドである場合があります。

この属性は、データが最後にプロセスマイニング環境にロードされた際のタイムスタンプを提供します。これは、分析対象データの鮮度を反映するものであり、実際のビジネスアクティビティ発生時刻を記録するイベント時間とは異なります。

通常、直接的なプロセスフロー分析には使用されませんが、この情報はデータガバナンスと分析結果の信頼性確保のために不可欠です。これにより、アナリストとビジネスユーザーは、生成された洞察の適時性を理解できます。たとえば、最終データ更新が1週間前であった場合、現在のパフォーマンスについて導き出された結論は、この事実を考慮して解釈される必要があります。

これはデータの鮮度を示しており、分析が最新の情報に基づいて行われ、結論が適切であることを保証します。

これは通常、データ取り込み時にデータ抽出（ETL）ツールまたはプロセスマイニングプラットフォームによって生成・保存されます。

ユーザー名属性は、特定のアクティビティを実行した担当者または自動エージェントを識別します。受注を作成した営業担当、承認した与信担当、自動で入金処理を行ったシステムユーザーなどが該当します。

この属性により、人に着目した分析が可能になります。業務負荷の分布、チームや個人間のパフォーマンス比較、教育・トレーニングの機会の発見に役立ちます。コンプライアンスや監査証跡の観点でも重要です。ユーザー別にアクティビティを分析すると、手戻りループや標準から外れた行動に関与している主体を明らかにでき、KPI「Manual Intervention Rate」の算出にも不可欠です。

アクティビティを実行する担当者やシステムを特定し、ワークロード、チームのパフォーマンス、自動化レベル、コンプライアンスの分析を可能にします。

取引ログやドキュメント変更履歴によく見られ、しばしば「作成者」または「変更者」としてラベル付けされます。

Order Value（受注金額）は、販売受注の総経済的価値を表します。これは、各ケースインスタンスの規模を定量化する重要な財務メトリックです。

この属性は、価値ベースのプロセス分析において非常に貴重です。高額なオーダーに焦点を当てることで、問題の優先順位付けが可能になります。例えば、アナリストは、高額なオーダーが低額なオーダーよりも長いcycle timeや多くの手戻りを経験しているかどうかを調査できます。また、特定のボトルネックによって遅延したオーダーの総額など、プロセスの非効率性による財務的影響を計算するためにも使用されます。これにより、プロセス改善イニシアチブの強力なビジネスケースが作成されます。

価値ベースの分析を可能にし、高価値な受注に焦点を当てることでプロセス改善の優先順位付けを支援し、遅延による財務的影響を定量化します。

受注ヘッダーデータで利用可能で、多くの場合、全ての明細項目ネット金額の合計として計算されます。

製品識別子（品目コードやSKUなど）は、何を販売しているかを示します。受注には複数製品を含む場合がありますが、分析では主要製品、または製品カテゴリに集約して扱うことが一般的です。

この属性により、Order to Cashを製品軸で俯瞰できます。ある製品にフルフィルメントが長引く、配送トラブルが多い、キャンセル率が高いといった偏りがないかを明らかにできます。これはサプライチェーン計画、在庫管理、製品ポートフォリオ戦略に重要な示唆です。例えば、特定の製品ラインが「Released To Warehouse」工程で恒常的に遅延しているなら、在庫水準や倉庫内配置の見直しを検討すべきです。

これにより、異なる製品や製品グループごとのプロセスパフォーマンスを分析でき、製品固有のボトルネックや問題を特定するのに役立ちます。

受注伝票の明細レベルで確認できます。ケースレベル分析の場合、最も重要な明細項目、または派生した製品カテゴリで表現されることがあります。

販売チャネルは、受注がどこから・どの手段で入ってきたかを示します。オンラインポータル、直販チーム、パートナーとのEDI、店舗などが該当します。

チャネル別にプロセスを分析すると、効率や遵守状況の差が明確になります。たとえばWebチャネルは自動化が進み処理が速い一方、直販は手作業の変更や承認が多くリードタイムが長くなりがちです。こうした分析は、チャネル固有のワークフロー最適化やリソース配分の最適化に役立ちます。ダッシュボード「Order Fulfillment Bottlenecks」における重要な分析軸にもなります。

異なるチャネル間のプロセスパフォーマンスを比較し、効率性、自動化、適合性におけるばらつきを明らかにすることができます。

この情報は通常、販売受注ヘッダーデータに保存され、受注入力時に必須フィールドであることがよくあります。

この属性は、販売受注の処理対象となる外部パーティを特定します。これは、固有の顧客番号、会社名、または顧客を区別する別のキーである場合があります。

プロセスマイニングにおいて、顧客識別子はデータをセグメント化するための強力なディメンションです。アナリストは、特定の顧客に対してプロセスがどのように動作するかを確認するためにプロセスマップをフィルタリングしたり、戦略的アカウントと単発購入者など、異なる顧客グループ間のプロセスフローを比較したりできます。これにより、カスタマイズされたプロセスが明らかになったり、頻繁にプロセスの逸脱や遅延を引き起こす顧客が特定されたりし、顧客関係管理に価値ある洞察を提供します。

異なる顧客や顧客グループ間でプロセスをフィルタリング・比較することで、カスタマイズされたプロセスや問題のあるアカウントを特定することができます。

受注ヘッダーデータで確認でき、ソースとなるERPまたはCRMシステム内の顧客マスターデータにリンクされています。

販売注文がキャンセルされたり、品目が拒否されたりした場合、拒否理由（Rejection Reason）は、このネガティブな結果に対するビジネス上の背景情報を提供します。理由は「顧客都合によるキャンセル」、「価格間違い」、「在庫切れ」など多岐にわたります。

この属性は、プロセス失敗の根本原因分析に不可欠です。異なる拒否理由の頻度を分析することで、企業はシステム的な問題を特定できます。例えば、「価格間違い」によるキャンセルが多い場合、それは見積もりまたはマスターデータ管理プロセスに問題がある可能性を示唆しています。この分析は、「初回から正しい（First-Time Right）率」の向上とプロセス上の無駄の削減に向けた取り組みを直接サポートします。

受注が失敗する理由を説明し、価格設定、在庫、または顧客とのコミュニケーションにおける根本的な問題に対処するための根本原因分析を可能にします。

通常、受注明細レベルで見られ、品目がキャンセルされた際に事前定義されたコードリストから選択されます。

受注ステータスは、特定時点における受注の進捗を示すスナップショットで、現在の状態を要約するカテゴリです。

アクティビティの時系列は詳細なプロセスマップを与えますが、受注ステータスはよりシンプルで俯瞰的な可視化に有効です。たとえば「On Credit Hold（与信保留）」の受注だけを抽出するなど、フィルタリングに使えます。各ステータスに滞留している時間を分析すれば、「Waiting for Approval（承認待ち）」が長いなどのボトルネックも明らかになります。

注文の状態に関する大まかな概要を提供し、フィルタリング、ステータス分析、特定の段階で停滞している注文の特定に役立ちます。

多くのERPやCRMシステムにおける受注伝票のヘッダーにある標準的なフィールドです。

実際の納品日は、顧客への納品が完了した瞬間を記録するタイムスタンプです。多くの場合、配送業者の配送完了の証明に基づきます。

この属性はフルフィルメント成功の最終的な判定指標です。要求納期・確約納期と照合して「オンタイム納品率」を算出するための基準となるデータです。さらに「Goods Shipped」アクティビティから実際の納品日までの時間差を分析することで、物流パートナーや配送方法のパフォーマンスも評価できます。

これは履行の最終証明であり、定時配送率と受注履行サイクルタイム合計を正確に算出するために不可欠です。

外部のロジスティクスまたは配送システムから提供され、ERPに統合されることがよくあります。「品物配送済み」アクティビティのタイムスタンプから導出される場合もあります。

この日付は、顧客の希望する配送期限を表しています。これは、プロセスの開始時に取得される重要な情報であり、配送の適時性に関する顧客満足度の主要なベンチマークとして機能します。

プロセス分析では、要求された配送日は、確認済みおよび実際の配送日などの他の主要な日付と比較され、サービスレベルを測定します。これは「納期遵守率」ダッシュボードの主要な入力であり、顧客の視点から配送が納期内であったかどうかを計算するために使用されます。要求された日付と確認済みの日付間のギャップを分析することは、計画およびスケジュールの問題を浮き彫りにすることもあります。

顧客の納期への期待値として機能し、納期遵守の実績と顧客満足度を測定するための基準となります。

通常、受注作成プロセス中に受注ヘッダーまたは明細データに入力されます。

支払期日は、請求書発行日と顧客と合意した支払条件に基づいて計算される、適時支払いの期限です。売掛金管理の中核要素となります。

この属性は、Order to Cash（O2C）の財務側面を分析する上で不可欠です。期日内支払いかどうかの基準となり、KPI「On-Time Payment Rate」に直結します。ダッシュボード「Invoice to Payment Cycle」はこの日付を軸に、支払い行動を分析し運転資本の最適化に役立てます。請求書作成から入金までの遅延はこの期日と比較することで、支払いの遅い顧客を特定できます。

財務分析に不可欠なこの日付は、期限内支払率の計算や売掛金の管理における基準となります。

通常、顧客請求書に記載されており、請求書日付と、顧客マスタデータまたは受注に指定された支払い条件から導出されます。

企業は在庫と生産スケジュールを確認した後、確定納期を顧客に提示します。これは組織の顧客に対するコミットメントであり、履行パフォーマンスを測定するための内部ベンチマークとなります。

この属性は、内部運用効率を評価する上で極めて重要です。これは「納期遵守率」KPIで使用され、自社のコミットメントを達成したかどうかを判断するために実績納期と比較されます。多くの受注において、要求納期と確定納期の間に大きな差異がある場合、ATP計算や生産能力計画におけるシステム的な問題を示唆している可能性があります。

これは顧客に対する企業のコミットメントを表し、納期厳守と履行の信頼性を測るための社内ベンチマークとなります。

受注伝票のスケジュール行データで確認でき、多くの場合、在庫確認または生産計画実行後に更新されます。

このブール属性は、人間のユーザーによって実行されるタスクと、バックグラウンドジョブ、API、またはRPAボットなどのシステム自動化によって実行されるタスクを区別します。たとえば、信用チェックは自動化されたステップである可能性がありますが、信用ブロックの解決は通常、手動で行われます。

自動化の観点からプロセスを分析することは、デジタル変革のイニシアチブにとって不可欠です。このフラグは、「手動介入率」KPIを計算するための主要なデータポイントです。プロセスのどの部分が高度に自動化されており、どの部分が依然として手動作業に依存しているかを特定するのに役立ちます。この分析は、コスト削減、エラーの最小化、サイクルタイム短縮のためのさらなる自動化の機会を浮き彫りにすることができます。

手動タスクと自動化されたタスクを区別することは、自動化レベルを測定し、プロセス改善の機会を特定するための鍵となります。

この情報は、ユーザー名アトリビュート（例: 「BATCH_USER」のようなシステムユーザーの識別子）または、実行コンテキストを追跡するイベントログ内の特定のフィールドから導き出すことができます。