調達から支払いまで：発注書のデータテンプレート

アクティビティ名は、発注書プロセスにおけるステップまたはステータス変更を示します。例として、「発注書を作成」、「発注書を承認」、「入荷を計上」、「請求書を受領」などがあります。各アクティビティは、プロセスの流れにおける個別の時点を表します。

この属性は、アクティビティの流れを視覚的に表すプロセスマップの作成に欠かせません。さまざまなアクティビティの順序と頻度を分析すると、一般的なプロセス経路、逸脱、ボトルネック、承認や変更の繰り返しといった手戻りループを特定できます。

プロセスマップの基盤となり、プロセスの流れ、ばらつき、非効率な箇所を可視化・分析できます。

通常は、発注書に関連付けられた取引コード、ステータス変更ログ、イベントテーブル、または変更文書テーブルから取得します。

イベント時刻は、特定のアクティビティが実行された日時、またはステータス変更が記録された日時を示します。このタイムスタンプにより、発注書のライフサイクルにおける各イベントの時間的な位置付けを把握できます。

プロセスマイニングでは、タイムスタンプがサイクル時間、所要時間、アクティビティ間の待ち時間を計算する基礎となります。ケースごとにイベントを時系列に並べることで、プロセスのパフォーマンスを分析し、時間が失われているボトルネックを特定し、サービスレベル合意（SLA）への準拠を監視できます。

サイクル時間の計算、ボトルネックの特定、基準値に対するパフォーマンスの監視など、時間に基づくすべての分析を可能にします。

通常は、イベントログ、変更履歴テーブル、または取引文書の作成日や計上日フィールドに記録されています。

発注書IDは、各発注書に割り当てられる一意の英数字コードで、他の発注書と区別するために使われます。特定の調達取引に関連するすべてのアクティビティ、文書、通信の中心的な参照情報となります。

プロセスマイニングでは、このIDが、作成、承認、入荷、請求などの関連イベントを、1つのエンドツーエンドのプロセスインスタンス、つまり「ケース」にまとめるうえで重要です。この識別子でプロセスを分析すると、各発注書の開始から最終クローズまでのライフサイクル全体を再構成し、可視化できます。

関連するすべてのイベントを1つのプロセスケースに結び付ける基本的な属性であり、発注書のライフサイクルをエンドツーエンドで分析できるようにします。

通常は、発注書のヘッダーテーブルまたは文書にある主キー項目です。

ソースシステム属性は、イベントデータの元となった情報システムを示します。ERP、調達プラットフォーム、レガシーシステムなどが該当します。発注から支払いまでのプロセスが複数の連携アプリケーションにまたがる環境では、特に重要です。

ソースシステムを把握すると、データの検証やトラブルシューティングに役立ち、システムに依存するプロセスの違いも理解できます。たとえば、電子調達システムから作成された発注書は、基幹ERPで手動作成された発注書よりも、自動化された異なる経路をたどる場合があります。

データの出所に関する文脈を提供します。これは、データガバナンス、検証、異なるシステム間のプロセスのばらつきの分析に欠かせません。

データ抽出時に追加する固定値、または入力元のシステムを示すソーステーブル内の項目を使用できます。

ソースシステムからデータを最後にロードまたは更新した日時を記録する属性です。単一のイベントではなく、データセット全体に適用されるメタデータ項目です。

この情報は、分析対象のデータがどの程度新しいかを把握するうえで重要です。分析結果の関連性を判断し、必要な範囲で最新のデータに基づいて意思決定できるようにします。

データの適時性を示し、分析対象の期間と分析結果の関連性を把握できるようにします。

通常は、データ抽出・変換（ETL）ツールまたはプロセスによって生成・保存されます。

ユーザー名は、プロセス内のイベントを実行した担当者を識別します。購買依頼を作成した担当者、発注書を承認した担当者、入庫を計上した担当者などが該当します。プロセスフローに責任の所在と担当者の情報を加える属性です。

ユーザー別にアクティビティを分析すると、業務量の分布やトレーニングの必要性を把握し、コンプライアンス上の問題を見つけやすくなります。たとえば、特定のユーザーに手戻りや遅延が集中していないか、職務分掌の違反がないかを確認できます。

プロセスのアクティビティを特定の担当者に関連付け、ユーザー単位で業務量、パフォーマンス、コンプライアンスを分析できます。

通常は、取引ログや文書ヘッダーの「Created By」、「Changed By」、「User ID」フィールドに記録されています。

仕入先名は、発注書に記載された商品またはサービスを提供する契約先を識別します。取引データである発注書データに関連付けられた主要なマスターデータです。

仕入先別のプロセス分析は、仕入先パフォーマンスの管理に欠かせません。納期遵守率、返品率、発注書の変更頻度などの指標で仕入先を比較できます。分析結果は、調達戦略、仕入先との交渉、関係管理に役立ちます。

仕入先ごとの納期、品質、プロセス上の滞りを比較し、仕入先パフォーマンスを分析できます。

仕入先マスターデータから取得し、通常は文書ヘッダーで発注書に関連付けます。

品目カテゴリは、品目グループまたは購買カテゴリとも呼ばれ、調達する製品やサービスの種類を分類します。この構造化された分類により、調達支出とプロセスの動きを整理し、把握しやすくなります。

品目カテゴリ別にプロセスを分析すると、大きな違いが見えてきます。たとえば、複雑なサービスの調達では、標準的なオフィス用品に比べて承認サイクルが長く、変更も多い場合があります。このように分けて分析することで、カテゴリごとのプロセス改善や戦略策定が可能になります。

カテゴリ別にプロセスパフォーマンスと支出を分析し、購入の種類がプロセス効率に与える影響を把握できます。

通常は、発注書の明細レベルに保存されています。

希望納入日は、仕入先から商品やサービスを受け取る日として、組織が発注書に指定する日付です。仕入先の納入パフォーマンスを測定する基準になります。

この属性は、「納期遵守率」KPIの計算に欠かせません。希望納入日と実際の入庫日を比較することで、仕入先の信頼性を評価できます。差異を分析すると、特定の仕入先、品目、出荷拠点で慢性的な問題が発生していないかを把握でき、パフォーマンスに関する協議に役立つデータを得られます。

仕入先の納入パフォーマンスを測定する基準であり、納期遵守率KPIの計算に欠かせません。

通常は、発注書のヘッダーまたは明細にある標準フィールドです。

発注書ステータスは、特定時点でのライフサイクル上の段階、または最終的な処理結果を示します。一般的なステータスには、「In Approval」、「Approved」、「Sent to Vendor」、「Partially Received」、「Closed」、「Canceled」などがあります。

この属性を使って、発注書を絞り込み、対象を分けて分析できます。たとえば、オープン中の発注書だけを分析して現在のボトルネックを見つけたり、キャンセルされた発注書を分析してキャンセル理由を把握したりできます。ステータス変更の順序を追跡すれば、プロセスモデルのアクティビティを定義する基礎にもなります。

ライフサイクル上の段階でケースを絞り込み、オープン中、完了済み、問題のある発注書を対象に分析できます。

通常は、発注書のヘッダーデータにある標準的なステータスフィールドです。

発注金額は、発注に伴う合計の金銭的コミットメントを示します。文書全体のレベルでも、個々の明細レベルでも分析できます。

この属性は、財務分析と優先順位付けの基礎となります。たとえば、高額な発注書に絞り込み、より複雑な承認ワークフローや大きな事業影響がある発注を分析できます。発注金額とサイクルタイムや手戻り率を関連付けることで、高額な発注が低額な発注より非効率に処理されていないかを確認できます。

プロセスに金額の視点を加え、金額に基づく分析によって改善の優先順位付けやコスト要因の把握ができます。

通常は発注書のヘッダーデータにあり、すべての明細金額の合計として計算されます。

部門属性は、購買を担当する組織単位を示します。多くの場合、依頼を開始した部門、または費用を負担する予算を持つ部門です。「IT」、「Marketing」、「Operations」などが該当します。

この属性は、組織内の各部門におけるプロセスパフォーマンスを分けて比較するために欠かせません。部門別に分析すると、サイクルタイムが最も長い領域、変更率が高い領域、非公式な購買が多い領域を把握できます。こうした結果をもとに、各部門のニーズや業務の進め方に合わせて改善施策を設計できます。

事業単位ごとにプロセスを分けて分析できるため、パフォーマンスを比較し、部門固有の問題や優れた取り組みを見つけられます。

通常は、発注書のヘッダーまたは明細に「Cost Center」や「Department」フィールドとして記録されています。

依頼者は、購買の必要性を開始した組織内の担当者です。多くの場合、先行する購買依頼を作成した担当者が該当します。システム上で発注書を作成したユーザーとは異なり、発注書の作成者は通常、購買部門の担当者です。

依頼者別に分析すると、購買行動の傾向を把握できます。たとえば、特定の依頼者に緊急発注や頻繁な変更を伴う発注が集中している場合があります。この情報をもとに、調達方針に関する対象を絞ったトレーニングを行ったり、依頼段階で要件の記載方法を改善したりできます。

購買を開始した業務担当者を識別し、購買行動の分析や要件定義プロセスの改善に役立ちます。

通常は、関連する購買依頼から取得するか、発注書自体の「Requester」フィールドに保存されています。

終了時刻属性は、アクティビティの完了日時を記録します。多くのプロセスイベントは単一時点で発生するため、開始時刻と終了時刻が同じです。一方、手動作業など、所要時間を測定できるアクティビティでは、開始時刻と終了時刻が異なる場合があります。

終了時刻があると、個々のアクティビティの処理時間を正確に計算できます。どのステップに時間がかかっているかを特定し、実際に作業している処理時間と、アクティビティ間に発生する待機時間を区別するうえで役立ちます。

アクティビティの処理時間を正確に計算できるため、プロセスにおける実作業時間と待機時間を区別できます。

イベントログまたは取引データに記録されています。「終了時刻」や「完了日」などの個別フィールドとして存在する場合もあります。利用できない場合は、イベント時刻と同じ値を設定できます。

購買依頼IDは、調達プロセスを開始した社内文書の識別子です。購買依頼は、商品やサービスの調達を購買部門に正式に依頼する文書です。

このIDにより、発注書プロセスと上流の購買依頼プロセスをつなげられます。「依頼から発注まで」の分析を行い、依頼から発注書作成までにかかった時間を測定できます。また、依頼者と購買チームの引き継ぎで発生する遅延も見つけやすくなります。

発注書を元の依頼に関連付け、上流の依頼から発注までのサイクルタイムを分析できます。

通常は、発注書のヘッダーまたは明細データの参照フィールドとして保存されています。

通貨属性は、発注金額やその他の財務項目で使用する通貨単位を示します。複数の通貨を扱う多国籍組織では、財務データを正しく解釈し集計するために欠かせません。

分析では、財務指標を同じ基準で比較するために使用します。金額を含むダッシュボードやKPIでは、正確な財務状況を把握できるよう、通貨換算とレポート作成を適切に行うための前提となります。

すべての金額を解釈するために必要な情報を提供し、特にグローバルな業務における正確な財務報告と比較を支えます。

通常は、合計金額とともに発注書のヘッダーに保存されます。