受注から入金までの販売注文処理向けデータテンプレート

アクティビティ名は、「販売注文作成」「与信チェック実施」「商品出荷」など、販売注文のライフサイクルにおける段階や節目を表します。各アクティビティは販売注文に対して行われた個別の処理を示し、プロセスマップを構成する要素となります。

プロセスの流れを可視化し、よくある経路を特定して、標準手順からの逸脱を見つけるには、この属性が欠かせません。アクティビティの順序を分析すると、ボトルネック、手戻りの繰り返し（例：「販売注文変更」の反復）、コンプライアンスに適合しないプロセスのばらつきを特定できます。「プロセス適合性と逸脱」ダッシュボードや、「販売注文の手戻り率」などの重要業績評価指標（KPI）にも欠かせない属性です。

プロセスの各段階を定義する属性です。プロセスマップの可視化、プロセスの流れの分析、手戻りや逸脱の特定に役立ちます。

多くの場合、ソースシステムの販売、出荷、請求モジュールにある文書のステータス変更、イベントログ、取引コードから取得します。

イベント発生時刻は、アクティビティが実行された正確な時点を記録するタイムスタンプです。この属性によってプロセスの時間的な前後関係がわかり、販売注文に関連するすべてのイベントを時系列に並べられます。

時間に基づく分析には欠かせない属性です。任意の2つのアクティビティ間のサイクルタイムや各段階の所要時間を算出し、遅延やボトルネックを特定できます。たとえば、「注文履行サイクルタイム」の重要業績評価指標（KPI）は、最終的な配達アクティビティと最初の注文作成アクティビティのイベント発生時刻の差から算出します。「販売注文サイクルタイムの概要」ダッシュボードも、この属性を基に動作します。

サイクルタイムや所要時間など、ボトルネックの特定に欠かせないパフォーマンス指標の算出に必要なタイムスタンプです。

通常、各取引やステータス更新のレコードに記録され、作成日、変更日、転記日などの項目名が付いています。

販売注文IDは、受注から入金までのプロセスマイニングの基盤となる属性です。各プロセスの開始から完了までを一意に識別し、関連するすべてのアクティビティ、イベント、データ項目を結び付けて、1件の注文の全体像を示します。

分析では、この属性を使って販売注文ごとのライフサイクルを再構成します。イベントの順序を追跡し、アクティビティ間の所要時間を測定し、注文単位で指標を集計できます。たとえば、「注文履行サイクルタイム」の重要業績評価指標（KPI）を算出するには、販売注文IDごとにアクティビティをグループ化し、最初と最後のイベントの時間差を求めます。

個々の注文をプロセス全体で追跡するために欠かせないIDです。ケース単位でサイクルタイム、ボトルネック、逸脱を分析できます。

通常、ソースERPまたはCRMシステムにある販売注文文書のヘッダーテーブルに記録されています。

ソースシステム属性は、イベントデータが生成された記録システムを示します。現代の企業では、受注から入金までのような一連のプロセスが複数のアプリケーションにまたがることがよくあります。たとえば、注文作成にはCRM、注文履行や請求にはERPを使う場合があります。

分析では、この属性を使ってプロセスを支えるシステムの構成を把握できます。システム間の連携箇所や、データの整合性に関する問題の特定にも役立ちます。ソースシステム別にアクティビティを分析すると、実行するシステムによって処理方法や遅延の発生状況に違いがあるかどうかを確認できます。

データの取得元を把握するための情報です。複数のシステムを使う環境で、データの流れを追跡し、システムごとのプロセスの違いを特定する際に役立ちます。

この情報は、データ抽出（ETL）の際に追加されることが多く、データウェアハウスの標準項目として記録される場合もあります。

この属性は、データがプロセスマイニング環境に最後に読み込まれた日時を示します。分析対象データの鮮度を表すもので、業務アクティビティが実際に発生した日時を記録するイベント発生時刻とは異なります。

通常、プロセスの流れを直接分析するためには使いませんが、データガバナンスや分析結果の信頼性を確保するうえで重要です。分析担当者や業務ユーザーは、インサイトがどの時点のデータに基づいているかを確認できます。たとえば、最終データ更新が1週間前であれば、現在のパフォーマンスに関する結論には、その点を踏まえる必要があります。

データの鮮度を示し、最新の情報に基づく分析と、現状に即した結論を支えます。

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

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

この属性を使うと、人を軸にプロセスを分析できます。業務負荷の分布やチーム・担当者間のパフォーマンスを比較し、トレーニングの必要性を特定できます。コンプライアンスや監査証跡の確認にも欠かせません。ユーザー別にアクティビティを分析すると、手戻りの繰り返しやコンプライアンスに適合しない処理に関わる担当者を把握できます。また、「手作業による介入率」の重要業績評価指標（KPI）の算出にも使われます。

アクティビティを実行した担当者やシステムを特定し、業務負荷、チームのパフォーマンス、自動化の度合い、コンプライアンスを分析できます。

通常、取引ログや文書の変更履歴に記録され、「作成者」や「変更者」などの項目名が付いています。

注文金額は、販売注文の合計金額を表します。各ケースの規模を金額で示す重要な財務指標です。

金額を基準にプロセスを分析する際に役立ちます。高額注文に注目して、問題への対応に優先順位を付けられます。たとえば、高額注文は低額注文よりサイクルタイムが長いか、手戻りが多いかを調べられます。また、特定のボトルネックによって遅延した注文の合計金額など、プロセスの非効率性が財務に与える影響の算出にも使えます。こうした分析は、プロセス改善の取り組みを進める根拠になります。

高額注文に注目した分析や遅延による財務影響の算出を通じて、プロセス改善の優先順位付けに役立ちます。

販売注文ヘッダーデータに記録されています。通常、すべての明細の正味金額を合計して算出します。

製品識別子は、品目番号やSKUなど、販売対象を示します。販売注文に複数の製品が含まれる場合でも、この属性には主な製品を指定するか、概要分析用に製品カテゴリを設定します。

この属性を使うと、受注から入金までのプロセスを製品別に分析できます。特定の製品で履行に時間がかかる、配送上の問題が頻繁に起きる、キャンセル率が高いといった傾向を把握できます。サプライチェーン計画、在庫管理、製品ポートフォリオの検討に役立ちます。たとえば、特定の製品ラインで「倉庫への出庫指示」段階の遅延が続いているとわかれば、在庫数や倉庫内の配置を調査できます。

製品や製品グループごとのプロセスのパフォーマンスを分析し、製品固有のボトルネックや問題を特定できます。

販売注文の明細レベルに記録されています。ケース単位で分析する場合は、最も重要な明細や、そこから導出した製品カテゴリで表すことがあります。

販売チャネルは、注文が行われた経路や方法を示します。オンラインポータル、直販チーム、パートナーとのEDI接続、小売店舗などが該当します。

販売チャネル別にプロセスを分析すると、効率や適合性の違いが明らかになります。たとえば、ウェブ経由の注文は自動化が進み処理が速い一方、直販の注文では手作業による変更が多く、承認に時間がかかる場合があります。チャネルごとのプロセスの流れを見直し、リソースをより適切に配分できます。「注文履行のボトルネック」などのダッシュボードで使う重要な分析軸です。

チャネルごとのプロセスのパフォーマンスを比較し、効率、自動化、適合性の違いを把握できます。

通常、販売注文ヘッダーデータに保存され、注文入力時の必須項目となっていることが多い情報です。

この属性は、販売注文の処理対象となる顧客を特定します。一意の顧客番号、会社名など、顧客を区別できる情報を指定します。

プロセスマイニングでは、顧客識別子を使ってデータを分類できます。特定の顧客に対するプロセスの動きをプロセスマップで確認したり、主要顧客と一時的な購入者など、顧客グループ間でプロセスの流れを比較したりできます。顧客ごとの個別対応を明らかにしたり、プロセスの逸脱や遅延が頻繁に発生する顧客を特定したりできるため、顧客関係の管理に役立ちます。

顧客や顧客グループごとにプロセスを絞り込んで比較し、個別対応の有無や問題のある顧客を特定できます。

ソースERPまたはCRMシステムの顧客マスターデータに関連付けられた、販売注文ヘッダーデータに記録されています。

実際の納品日は、商品が顧客に正常に届けられた日時を記録します。配送業者からの配達証明に基づくことがよくあります。

注文履行の成否を判断するための確定的な指標です。希望納品日と確定納品日の両方と比較し、「納期遵守率」の算出に使います。「商品出荷」アクティビティから実際の納品日までの時間差を分析すると、物流パートナーや配送方法のパフォーマンスも把握できます。

注文履行の最終的な証拠となり、納期遵守率と注文履行サイクルタイムを正確に算出するために欠かせません。

外部の物流システムや配送システムから取得し、ERPに連携することがよくあります。「商品配達」アクティビティのタイムスタンプから導出する場合もあります。

この日付は、顧客が希望する納品時期を示します。プロセスの開始時に記録され、納期に関する顧客満足度を測る主な基準となります。

プロセス分析では、希望納品日を確定納品日や実際の納品日などの主要な日付と比較し、サービス水準を測定します。「納期遵守パフォーマンス」ダッシュボードの入力データとして使われ、顧客の視点から納期を守れたかどうかを算出します。希望日と確定日の差を分析すると、計画やスケジュール設定の問題も明らかになります。

顧客が希望する納品日を示し、納期遵守状況や顧客満足度を測る基準となります。

通常、販売注文のヘッダーまたは明細に記録され、注文の作成時に入力されます。

受注がキャンセルされた場合や明細が拒否された場合、拒否理由から、その結果に至った業務上の背景を把握できます。理由には、「顧客都合のキャンセル」「価格の誤り」「在庫切れ」などがあります。

この属性は、プロセス上の問題の根本原因を分析するうえで欠かせません。拒否理由ごとの発生頻度を分析すると、組織的な問題を特定できます。たとえば、「価格の誤り」によるキャンセルが多い場合、見積もりやマスターデータのプロセスに問題がある可能性があります。この分析は、「初回正解率」の向上とプロセスの無駄の削減に役立ちます。

受注が成立しない理由を明らかにし、価格設定、在庫、顧客とのコミュニケーションに関する根本原因の分析に役立ちます。

通常は受注明細に設定され、明細のキャンセル時に定義済みのコード一覧から選択します。

支払期日は、請求日と顧客との合意に基づく支払条件から算出します。期限内の支払いを判断する基準であり、売掛金プロセスの重要な要素です。

受注から入金までの財務面を分析するうえで欠かせない属性です。支払いが期限内に行われたかを判断する基準となり、「期限内支払率」の重要業績評価指標（KPI）の算出に使われます。「請求から入金までのサイクル」ダッシュボードでは、この日付を基に支払いの傾向を分析し、運転資本を管理します。請求書の作成から入金までの遅れを支払期日と照らし合わせると、支払いが遅い顧客を特定できます。

財務分析に欠かせない日付です。期限内支払率の算出や売掛金の管理に使う基準となります。

通常、顧客向け請求書に記載されています。請求日と、顧客マスターデータまたは販売注文に指定された支払条件から算出します。

注文ステータスは、特定の時点で販売注文がライフサイクルのどの段階にあるかを示します。注文の現在の状態を要約する分類ラベルです。

アクティビティの順序から詳細なプロセスマップを作成できますが、注文ステータス属性を使うと、プロセスの概要を簡潔に把握できます。たとえば、「与信保留中」の注文をすべて絞り込めます。各ステータスにとどまる時間を分析すると、「承認待ち」の状態が長く続く注文など、ボトルネックも特定できます。

注文の状態を概要レベルで示します。絞り込みやステータス分析、特定の段階で滞留している注文の特定に役立ちます。

ERPやCRMシステムの多くで、販売注文文書のヘッダーに標準項目として記録されています。

在庫や生産スケジュールを確認した後、会社は確定納品日を顧客に提示します。この日付は顧客への約束を示し、注文履行のパフォーマンスを測る社内基準となります。

この属性は、社内業務の効率を評価するうえで重要です。「納期遵守率」の重要業績評価指標（KPI）では、確定納品日と実際の納品日を比較し、会社が約束を守れたかを確認します。多くの注文で希望納品日と確定納品日に大きな差がある場合、引当可能在庫（ATP）の計算やキャパシティ計画に組織的な問題がある可能性があります。

顧客への約束を示す日付で、納期遵守状況や注文履行の信頼性を測る社内基準となります。

販売注文の納期明細データに記録されています。在庫確認や生産計画の実行後に更新されることがよくあります。

この真偽値属性により、ユーザーが実行したタスクと、バックグラウンドジョブ、API、RPAボットなどによる自動処理を区別できます。たとえば、与信チェックは自動処理の場合がありますが、与信ブロックの解除は通常、手動で行われます。

自動化の観点からプロセスを分析することは、デジタルトランスフォーメーションの取り組みに欠かせません。このフラグは、「手動介入率」という重要業績評価指標（KPI）の算出に使う主要なデータです。プロセスのうち自動化が進んでいる部分と、手作業に依存している部分を特定できます。この分析から、コストやエラーを減らし、処理時間を短縮するために、さらに自動化できる領域を見つけられます。

手動タスクと自動タスクを区別します。自動化の度合いの測定や、プロセス改善の機会の特定に役立ちます。

「ユーザー名」属性から特定できます（例：「BATCH_USER」などのシステムユーザーを識別）。または、イベントログ内で実行コンテキストを記録する専用フィールドから取得できます。