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

アクティビティ名は、「販売受注作成」、「与信チェック実施」、「商品出荷済み」など、販売受注のライフサイクルにおけるステップやマイルストーンを表します。各アクティビティは販売受注に対して実行された個別の操作であり、プロセスマップを構成する基本要素です。

分析では、この属性を使ってプロセスフローを可視化し、一般的な経路を特定し、標準手順からの逸脱を見つけます。アクティビティの順序を分析すると、ボトルネック、手戻りループ（「販売受注変更」の繰り返しなど）、コンプライアンスに反するプロセスの変化を特定できます。「プロセス適合性と逸脱」ダッシュボードや、「販売受注手戻り率」KPIの基盤となる属性です。

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

通常は、元のシステムの販売、配送、請求モジュールにおける伝票ステータスの変更、イベントログ、取引コードから生成します。

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

時間に基づく分析には欠かせない属性です。任意の2つのアクティビティ間のサイクルタイムの計算、特定ステップの所要時間の把握、遅延やボトルネックの特定に使用します。たとえば、「受注処理サイクルタイム」KPIは、最終配送アクティビティのイベント時刻と、最初の受注作成アクティビティのイベント時刻の差分として計算します。「販売受注サイクルタイム概要」ダッシュボードも、この属性を前提として機能します。

このタイムスタンプは、サイクルタイムや所要時間など、ボトルネックの特定に欠かせないすべてのパフォーマンス指標を計算するために重要です。

通常は各取引またはステータス更新のレコードとともに保存され、作成日、変更日、転記日などの名称が付けられています。

販売受注IDは、受注からクローズまでの各プロセスインスタンスを一意に識別する、受注から入金までのプロセスマイニングの基盤です。関連するすべてのアクティビティ、イベント、データ項目を結び付ける主キーとして機能し、1件の受注についてエンドツーエンドの流れを構成します。

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

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

通常は、元のERPまたはCRMシステムにある販売受注伝票のヘッダーテーブルに含まれています。

ソースシステム属性は、イベントデータが生成された記録システムを示します。現在の企業では、受注から入金までのエンドツーエンドのプロセスが複数のアプリケーションにまたがることが多く、たとえば受注作成にはCRM、出荷処理と請求にはERPを使います。

分析では、この属性によってプロセスを支えるシステム環境を把握できます。統合ポイントや、システム間でデータの整合性に問題が生じる可能性のある箇所の特定にも役立ちます。ソースシステム別にアクティビティを分析すると、特定のステップがシステムによって異なる方法で処理されていないか、また実行するシステムによって遅延が増えていないかを確認できます。

データの出所に関する情報を提供します。複数のシステムが存在する環境で、データの系譜を追跡し、システム固有のプロセスの違いを特定するために重要です。

通常はデータ抽出（ETL）プロセスで追加されるか、データウェアハウスの標準項目として保持されます。

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

通常、プロセスフローを直接分析するためには使いませんが、データガバナンスと分析結果の信頼性を確保するうえで重要です。アナリストや業務ユーザーは、生成された分析結果がどの時点の情報に基づくものかを把握できます。たとえば、最終データ更新が1週間前であれば、現在のパフォーマンスについて導いた結論には、その事実を踏まえた注意書きが必要です。

データの鮮度を示し、最新の情報に基づいて分析できることと、導いた結論が現在の状況に適用できることを確認します。

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

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

この属性によって、プロセスを人の視点から分析できます。作業負荷の分布の分析、チームや個人間のパフォーマンス比較、トレーニング機会の特定に利用します。また、コンプライアンスと監査証跡の観点でも重要です。ユーザー別にアクティビティを分析すると、手戻りループやコンプライアンスに反する行動に関与した担当者を特定でき、「手動介入率」KPIの計算にも欠かせません。

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

通常は取引ログまたは伝票変更履歴に含まれ、「Created By」や「Changed By」などの名称が付けられています。

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

この属性は、金額に基づくプロセス分析に役立ちます。高額受注に焦点を当てることで、問題への対応に優先順位を付けられます。たとえば、高額受注のほうが低額受注よりサイクルタイムが長いか、手戻りが多いかを調査できます。特定のボトルネックによって遅延した受注の総額など、プロセスの非効率による財務影響の計算にも使います。これにより、プロセス改善施策の必要性を具体的な金額で示せます。

金額に基づく分析が可能になり、高額受注に焦点を当ててプロセス改善の優先順位を付け、遅延による財務影響を定量化できます。

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

商品識別子は、品目番号やSKUなど、販売対象を示します。販売受注には複数の商品を含められますが、この属性は主要商品を表すか、高レベルの分析向けに商品カテゴリーへ集約されることがあります。

この属性によって、受注から入金までのプロセスを商品中心に分析できます。特定の商品が長い出荷処理時間、配送問題の多発、キャンセル率の高さと関連していないかを確認できます。この情報は、サプライチェーン計画、在庫管理、商品ポートフォリオ戦略に役立ちます。たとえば、特定の商品ラインで「倉庫処理へリリース済み」ステップの遅延が継続していることが分かれば、在庫水準や倉庫内の配置を調査するきっかけになります。

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

販売受注の明細レベルに含まれます。ケース単位で分析する場合は、最も重要な明細や、導出した商品カテゴリーで表すことがあります。

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

販売チャネル別にプロセスを分析すると、効率や適合性の大きな違いを明らかにできます。たとえば、Webチャネルの受注は自動化が進み処理が速い一方、直販の受注では手動変更が多く、承認サイクルが長くなる場合があります。この分析によって、各チャネルに適したプロセスフローを改善し、リソースをより適切に配分できます。「受注処理のボトルネック」ダッシュボードなどでも重要な分析軸になります。

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

通常は販売受注ヘッダーデータに保存され、受注入力時の必須項目になっています。

この属性は、販売受注の処理対象となる外部の取引先を識別します。顧客番号、会社名、その他の顧客を区別するキーなどが該当します。

プロセスマイニングでは、顧客識別子を使ってデータを分割して分析できます。特定の顧客に対するプロセスの動きをプロセスマップで確認したり、戦略顧客と一時的な購入者など、顧客グループ間でプロセスフローを比較したりできます。これにより、個別対応のプロセスや、プロセスの逸脱や遅延を頻繁に引き起こす顧客を特定し、顧客関係管理に役立つ情報を得られます。

顧客または顧客グループごとにプロセスを絞り込み、比較できます。個別対応のプロセスや問題のある顧客を特定するのに役立ちます。

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

販売注文がキャンセルされた場合や明細が却下された場合、却下理由によって、その結果に至った業務上の背景を把握できます。理由には「顧客によるキャンセル」「価格誤り」「在庫切れ」などがあります。

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

注文が失敗した理由を明らかにし、価格設定、在庫、顧客とのコミュニケーションにおける根本原因の分析を可能にします。

通常は販売注文の明細行レベルに設定され、明細をキャンセルする際に、あらかじめ定義されたコード一覧から選択します。

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

アクティビティの順序から詳細なプロセスマップを作成できる一方、受注ステータスを使うと、プロセスを簡略化した高レベルのビューを作成できます。たとえば、現在「与信保留中」のすべての注文を抽出できます。各ステータスで費やした時間を分析すれば、「承認待ち」ステータスに長くとどまる注文など、ボトルネックも明らかになります。

注文の状態を高レベルで要約します。フィルタリングやステータス分析、特定の段階で滞留している注文の特定に役立ちます。

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

実際の納品日は、商品が顧客へ正常に納品されたことを記録するタイムスタンプです。通常は、配送業者が発行する納品証明に基づきます。

この属性は、履行の成否を測る確定的な指標です。指定納品日および確定納品日と比較して「納期遵守率」を算出する際に使われる、最終的なデータポイントでもあります。「商品出荷」アクティビティから実際の納品日までの時間差を分析すると、物流パートナーや配送方法のパフォーマンスも把握できます。

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

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

この日付は、顧客が希望する配送時期を表します。プロセスの開始時点で取得する重要な情報であり、納期に関する顧客満足度を測る基準になります。

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

顧客が期待する納期を示し、納期遵守パフォーマンスと顧客満足度を測定する基準になります。

通常は販売受注ヘッダーまたは明細の詳細にあり、受注作成時に入力されます。

支払期日は、請求書の日付と顧客と合意した支払条件に基づいて算出されます。期限内の支払いにおける締切日となり、売掛金プロセスの重要な要素です。

この属性は、受注から入金までの財務部分を分析するうえで欠かせません。支払いが期限内だったかどうかを判定する基準となり、「期限内支払率」KPIの直接的な入力値になります。「請求書から支払いまでのサイクル」ダッシュボードでは、この日付を基準に支払行動を分析し、運転資本を適切に管理します。請求書の作成から支払いまでの遅延をこの日付と比較することで、支払いの遅い顧客を特定できます。

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

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

在庫と生産スケジュールを確認した後、会社は確定納期を提示します。これは顧客に対する組織の約束であり、出荷処理パフォーマンスを測る社内基準になります。

この属性は、社内の業務効率を評価するうえで重要です。「納期遵守率」KPIでは実納期と比較し、会社が自らの約束を守れたかどうかを判定します。多くの受注で希望納期と確定納期に大きな差がある場合、ATP計算やキャパシティ計画に構造的な問題がある可能性を示します。

顧客に対する会社の約束を示し、納期遵守と出荷処理の信頼性を測る社内基準になります。

販売受注のスケジュール明細データに含まれ、通常は可用性チェックまたは生産計画の実行後に更新されます。

この真偽値属性は、人が実行したタスクと、バックグラウンドジョブ、API、RPAボットなどのシステム自動化によって実行されたタスクを区別します。たとえば、与信チェックは自動処理、与信ブロックの解除は通常手動処理です。

自動化の観点からプロセスを分析することは、デジタルトランスフォーメーションの取り組みにおいて重要です。このフラグは「手動介入率」KPIを算出する主要なデータポイントです。プロセスのどの部分が高度に自動化され、どの部分が依然として手作業に依存しているかを特定できます。この分析により、コスト削減、エラー抑制、サイクルタイム短縮に向けた、さらなる自動化の機会が明らかになります。

手動タスクと自動タスクを区別します。自動化の水準を測定し、プロセス改善の機会を特定するうえで重要です。

「ユーザー名」属性から、たとえば「BATCH_USER」のようなシステムユーザーを特定して導出できます。また、イベントログ内で実行コンテキストを記録する専用フィールドから取得することもできます。