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

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

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

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

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

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

プロセスマイニングでは、サイクルタイム、所要時間、アクティビティ間の待ち時間を計算するうえで、タイムスタンプが欠かせません。ケースごとにイベントを時系列に並べることで、プロセスのパフォーマンスを分析し、時間が失われているボトルネックを特定し、サービスレベル合意（SLA）の遵守状況を確認できます。

サイクルタイムの計算、ボトルネックの特定、ベンチマークに対するパフォーマンスの監視など、時間に基づくあらゆる分析に必要です。

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

発注書IDは、各発注書に割り当てられる一意の英数字コードで、ほかの発注書と区別するために使われます。特定の調達取引に関するすべてのアクティビティ、文書、連絡を結び付ける基準となります。

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

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

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

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

ソースシステムを把握すると、データの検証や問題の調査に役立ち、システムによって異なるプロセスの流れも理解しやすくなります。たとえば、電子調達システムから作成された発注書は、基幹ERPで手動作成された発注書よりも、自動化された経路をたどる場合があります。

データの取得元を把握できるため、データガバナンスや検証、システム間のプロセスのばらつきの分析に役立ちます。

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

この属性には、ソースシステムからデータを最後に読み込んだ、または更新した日時が記録されます。個々のイベントではなく、データセット全体に適用されるメタデータ項目です。

分析対象のデータがどの程度新しいかを把握するうえで重要な情報です。インサイトが現在も参考になるかを判断し、分析に必要な最新のデータに基づいて意思決定できるようにします。

データの更新時期を把握できるため、分析対象期間と結果の妥当性を確認できます。

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

ユーザー名は、プロセス内のイベントを実行した担当者を示します。購買依頼の作成者、発注書の承認者、入庫の計上者などが該当します。これにより、プロセスフローの責任の所在が明確になります。

ユーザー別にアクティビティを分析すると、業務負荷の分布や研修の必要性を把握し、コンプライアンス上の問題を検出できます。たとえば、手戻りや遅延が多いユーザーを特定したり、職務分掌の違反がないか確認したりできます。

プロセスのアクティビティを個々の担当者に結び付け、ユーザー単位で業務負荷、パフォーマンス、コンプライアンスを分析できます。

通常、トランザクションログや文書のヘッダーにある「作成者」、「変更者」、「ユーザーID」などのフィールドに記録されています。

仕入先名は、発注書に記載された商品やサービスを提供する契約先を示します。トランザクションの発注書データに関連付けられた、主要なマスターデータの1つです。

仕入先別のプロセス分析は、仕入先のパフォーマンス管理に欠かせません。納期遵守率、返品率、発注書の変更頻度などの指標を使って仕入先を比較できます。こうしたインサイトは、調達先の選定、仕入先との交渉、取引関係の管理に役立ちます。

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

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

品目カテゴリは、品目グループまたは購買カテゴリとも呼ばれ、調達する商品やサービスの種類を分類します。この体系的な分類により、調達支出やプロセスの傾向を整理して把握できます。

品目カテゴリ別にプロセスを分析すると、大きな違いが見つかることがあります。たとえば、複雑なサービスの調達では、一般的なオフィス用品の調達より承認に時間がかかり、変更も多くなる場合があります。カテゴリごとに分けて分析することで、それぞれに合ったプロセス改善や戦略の策定が可能になります。

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

通常、発注書の明細単位で記録されています。

希望納品日は、組織が仕入先から商品やサービスを受け取る予定日として、発注書に指定する日付です。仕入先の納品実績を測る際のベースラインとなります。

この属性は、「納期遵守率」の重要業績評価指標（KPI）を算出するうえで欠かせません。希望納品日と実際の入庫日を比較することで、仕入先の信頼性を評価できます。日付のずれを分析すると、特定の仕入先、品目、出荷場所に繰り返し発生する問題を特定でき、パフォーマンスに関する協議のためのデータが得られます。

仕入先の納品実績を測る基準となり、納期遵守率の重要業績評価指標（KPI）を算出するうえで欠かせません。

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

発注書のステータスは、特定の時点におけるライフサイクル上の段階、または最終的な状態を示します。一般的なステータスには、「承認中」、「承認済み」、「仕入先に送信済み」、「一部入庫済み」、「クローズ」、「キャンセル」などがあります。

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

ライフサイクルの段階でケースを絞り込み、オープン、クローズ、または問題のある発注書に焦点を当てて分析できます。

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

発注金額は、発注に伴う金銭的な負担の合計を示します。文書全体、または個々の明細単位で分析できます。

この属性は、財務分析や優先順位付けの基本となります。金額を基準にプロセスを絞り込み、承認ワークフローが複雑になりやすい、または事業への影響が大きい高額の発注書に注目できます。発注金額とサイクルタイムや手戻り率を照らし合わせると、高額の発注が低額の発注より非効率に処理されていないかを確認できます。

プロセスを金額の観点から分析できるため、改善の優先順位付けやコスト要因の把握に役立ちます。

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

部門属性は、購買を担当する組織単位を示します。多くの場合、依頼を開始した部門、または費用を負担する予算を持つ部門を指し、「IT」、「マーケティング」、「業務」などが該当します。

この属性は、事業の各部門におけるプロセスのパフォーマンスを分けて比較するうえで欠かせません。部門別の分析により、サイクルタイムが最も長い領域、変更率が最も高い領域、規定外の購買が最も多い領域を特定できます。こうしたインサイトをもとに、各部門のニーズや業務の進め方に合わせた改善策を検討できます。

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

通常、発注書のヘッダーまたは明細にあり、「コストセンター」や「部門」フィールドとして記録されています。

依頼者は、購買依頼の作成などを通じて、組織内で購買の必要性を最初に伝えた担当者です。システムで発注書を作成したユーザーとは異なり、発注書の作成者は通常、購買部門の担当者です。

依頼者別の分析は、購買行動の傾向を把握するのに役立ちます。たとえば、特定の依頼者が緊急の発注を繰り返していたり、頻繁な変更が必要な発注を行っていたりする場合があります。この情報をもとに、調達方針に関する対象を絞った研修を行ったり、依頼時の要件を明確にしたりできます。

購買を開始した事業部門の担当者を特定し、購買行動の分析や要件の明確化に役立てられます。

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

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

終了時刻があれば、個々のアクティビティの処理時間を正確に算出できます。時間のかかる具体的な工程を特定し、作業を実際に行っている処理時間と、アクティビティ間に作業が行われていない待機時間を区別するうえで役立ちます。

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

イベントログやトランザクションデータにあり、「終了時刻」や「完了日」といった独立したフィールドとして記録されている場合があります。利用できない場合は、イベント時刻と同じ値を設定できます。

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

このIDを使うと、発注書のプロセスを、その前段階にある購買依頼のプロセスに結び付けられます。これにより、依頼から発注書の作成までにかかる時間を測定する、より広い範囲の「依頼から発注まで」の分析が可能になります。依頼者から購買チームへの引き継ぎに生じる遅延の特定にも役立ちます。

発注書を元の依頼に結び付け、前段階の購買依頼から発注までのサイクルタイムを分析できます。

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

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

分析では、この属性によって財務指標を同じ基準で比較できます。金額を含むダッシュボードや重要業績評価指標（KPI）を作成する際の前提となり、適切な通貨換算とレポート作成を通じて、調達プロセスの財務状況を正確に把握できます。

すべての金額を正しく把握し、財務報告や比較の精度を保つために必要な情報です。特に、グローバルな業務で役立ちます。

通常、発注書のヘッダーに合計金額とともに記録されています。