データテンプレート: 購買から支払いまで - 購買オーダー

アクティビティ名とは、発注プロセスにおけるステップやステータスの変更を表すものです。「発注作成済み」、「発注承認済み」、「入荷記録済み」、「請求書受領済み」などが例として挙げられます。それぞれのアクティビティは、プロセスの各行程における明確な時点を示します。

この属性は、アクティビティの流れを視覚的に表現するプロセスマップを構築するために不可欠です。異なるアクティビティの順序と頻度を分析することで、一般的なプロセス経路、逸脱、ボトルネック、そして繰り返される承認や変更イベントなどの手戻りループを特定するのに役立ちます。

プロセスマップの基盤となり、プロセスの流れ、バリエーション、非効率性を可視化・分析できるようにします。

この情報は通常、発注書に関連するトランザクションコード、ステータス変更ログ、イベントテーブル、または変更文書テーブルから派生します。

イベントタイムは、特定のアクティビティが実行された、またはステータス変更が記録された日付と時刻を捉えます。このタイムスタンプは、購買オーダーのライフサイクルにおける各イベントの時間的コンテキストを提供します。

プロセスマイニングでは、タイムスタンプはサイクルタイム、期間、アクティビティ間の待機時間を計算するための基本です。各ケースのイベントを時系列順に並べることで、プロセスパフォーマンスの分析、時間ロスが発生しているボトルネックの特定、サービスレベルアグリーメント（SLA）へのコンプライアンス監視が可能になります。

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

これは通常、イベントログ、変更履歴テーブル、またはトランザクション文書の作成日または転記日フィールドとして見られます。

購買オーダーIDは、各購買オーダーに割り当てられる固有の英数字コードであり、他のどのオーダーとも区別されます。特定の調達トランザクションに関連するすべてのアクティビティ、ドキュメント、コミュニケーションの中心となる参照点として機能します。

プロセスマイニングにおいて、このIDは、作成、承認、入庫、請求など、関連するすべてのイベントを単一のエンドツーエンドのプロセスインスタンス、つまり「ケース」にグループ化するために不可欠です。この識別子でプロセスを分析することで、各購買オーダーの発生から最終的な完了までのライフサイクル全体を再構築し、可視化することが可能になります。

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

これは通常、発注書ヘッダーテーブルまたは文書に見られる主キーフィールドです。

ソースシステム属性は、イベントデータの発生源となる情報システムを特定します。これには、ERP、調達プラットフォーム、レガシーシステムなどが含まれます。これは、購買から支払いまでプロセスが複数の統合されたアプリケーションにまたがる環境において特に重要です。

ソースシステムを把握することは、データ検証、トラブルシューティング、およびシステムに依存する可能性のあるプロセス差異の理解に役立ちます。例えば、電子調達システムから発生したPOは、基幹ERPで手動で作成されたPOとは異なる、より自動化されたパスをたどる可能性があります。

データの発生源に関するコンテキストを提供し、データガバナンス、検証、異なるシステム間でのプロセスバリエーション分析に不可欠です。

これはデータ抽出時に追加される静的な値である場合もあれば、入力システムを示すソーステーブル内のフィールドである場合もあります。

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

この情報は、ユーザーが分析しているデータの鮮度を理解するために不可欠です。これにより、インサイトの関連性を判断し、分析に必要な最新のデータに基づいて意思決定を行うことができます。

データ`の最新性をユーザーに伝え、分析対象期間と分析結果の関連性を確実に理解できるようにします。

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

ユーザー名は、プロセス内のイベントを実行した個人を識別します。これは、購買依頼を作成した人物、発注書を承認した人物、または入荷検収を登録した人物である可能性があります。これにより、プロセスフローに説明責任と人間的な側面がもたらされます。

ユーザー別にアクティビティを分析することは、ワークロード配分の理解、トレーニングニーズの特定、および潜在的なコンプライアンス問題の検出に役立ちます。例えば、特定のユーザーが手戻りや遅延の発生率が高いかどうかを確認したり、職務分掌違反がないかをチェックしたりするために使用できます。

プロセス活動を特定の個人に紐付け、ユーザーレベルでの作業負荷、パフォーマンス、コンプライアンスの分析を可能にします。

通常、トランザクションログや文書ヘッダーの「Created By」、「Changed By」、または「User ID」フィールドに記載されています。

ベンダー名は、発注書に記載された商品またはサービスを提供する契約を結んだ外部企業を識別します。これは、個々のPOに関する取引データに紐づく重要なマスターデータの一部です。

ベンダー別にプロセスを分析することは、供給元パフォーマンス管理にとって極めて重要です。これにより、定時納品率、返品率、PO変更の頻度といった指標に基づいてベンダーを比較できます。これらの洞察は、ソーシング戦略、ベンダーとの交渉、および関係管理に役立つ情報を提供します。

複数のサプライヤー間で納期、品質、プロセス上の摩擦を比較し、ベンダーのパフォーマンスを分析できます。

これはベンダーマスターデータから取得され、発注書にリンクされます。通常、文書ヘッダーに記載されています。

品目カテゴリは、材料グループや購買カテゴリとも呼ばれ、調達する製品やサービスの種類を分類します。この構造化された分類は、調達支出やプロセス挙動の整理と理解に役立ちます。

品目カテゴリごとのプロセス分析により、大きな差異が明らかになります。例えば、複雑なサービスの調達プロセスは、標準的な事務用品のプロセスと比較して、承認サイクルが長く、変更も多くなる可能性があります。このセグメンテーションにより、カテゴリ固有のプロセス最適化と戦略策定が可能になります。

カテゴリごとのプロセスパフォーマンスと支出の分析を可能にし、さまざまなタイプの購買がプロセス効率にどのように影響するかを明らかにします。

この情報は通常、発注書明細レベルで格納されます。

希望納期は、発注書に記載された日付であり、組織が供給元から品目またはサービスを受け取ることを期待する日付です。この日付は、供給元の納品実績を測定するための基準として機能します。

この属性は、「定時納品率」というKPIを算出するために不可欠です。希望納期と実際の入荷日を比較することで、企業は供給元の信頼性を評価できます。逸脱を分析することで、特定の供給元、品目、または出荷場所における慢性的な問題を特定するのに役立ち、パフォーマンスに関する議論のためのデータを提供します。

ベンダーの納期実績を測るベンチマークであり、納期遵守率KPIの算出に不可欠です。

この日付は通常、発注書ヘッダーまたは明細詳細の標準フィールドです。

購買オーダーステータスは、特定の時点でのPOのライフサイクルにおける段階または最終的な処理状況を示します。一般的なステータスには「承認中」、「承認済み」、「ベンダーへ送信済み」、「一部入庫済み」、「クローズ済み」、「キャンセル済み」があります。

この属性は、購買オーダーのサブセットをフィルタリングし、分析するのに役立ちます。例えば、現在のボトルネックを特定するために未処理オーダーのみに分析を限定したり、キャンセル理由を理解するためにキャンセル済みオーダーに焦点を当てることができます。ステータス変更の順序を追跡することは、プロセスモデルにおけるアクティビティを定義する基礎とすることもできます。

ライフサイクルステージに基づいてケースをフィルタリングできるため、オープン、クローズ済み、または問題のあるオーダーに焦点を当てた分析が可能になります。

これは、発注書ヘッダーデータに見られる標準のステータスフィールドです。

購買オーダー金額は、オーダーの総財務コミットメントを表します。これはドキュメント全体レベルまたは個々の明細レベルで分析できます。

この属性は財務分析と優先順位付けに不可欠です。価値に基づいてプロセスをフィルタリングでき、例えば、より複雑な承認ワークフローや大きなビジネスインパクトを持つ高額なPOに焦点を当てることができます。PO金額とサイクルタイムや手戻り率を相関させることで、高額オーダーが低額オーダーよりも効率的に処理されているかどうかを明らかにできます。

プロセスに財務的な側面をもたらし、価値ベースの分析によって改善の優先順位付けやコスト要因の理解を可能にします。

この値は発注ヘッダーデータにあり、多くの場合、すべての明細行金額の合計として計算されます。

部署属性は、購買を担当する組織単位を指定します。これは多くの場合、要求を開始した部署、またはIT、マーケティング、運用などの費用を予算で賄う部署です。

この属性は、ビジネスのさまざまな部門間でプロセスパフォーマンスをセグメント化し、比較するために不可欠です。部署ごとの分析により、最も長いサイクルタイム、最も高い変更率、または最もマベリックバイイングが多い領域が明らかになります。これらのインサイトは、各部署の特定のニーズと行動に合わせて改善イニシアチブを調整するのに役立ちます。

事業単位ごとにプロセス分析をセグメント化できるため、パフォーマンスの比較や、部署固有の問題、あるいはベストプラクティスの特定に役立ちます。

この情報は通常、発注書ヘッダーまたは明細詳細で利用可能であり、多くの場合「コストセンター」または「部門」フィールドとしてリンクされています。

依頼者とは、組織内で購買の必要性を開始した人物であり、多くの場合、先行する購買依頼書を作成します。これは、システムで発注書ドキュメントを作成したユーザー（通常は購買部門に所属）とは異なります。

依頼者別に分析することで、購買行動のパターンを特定するのに役立ちます。例えば、特定の依頼者が常に緊急注文を出したり、頻繁な変更を伴う注文を出したりする傾向があるかもしれません。この情報は、調達ポリシーに関する対象を絞ったトレーニングを提供したり、元の要件定義を改善したりするために活用できます。

購買を開始したビジネスユーザーを特定し、購買行動の分析や要件定義プロセスの改善に役立てます。

この情報は通常、関連する購買要求から取得されるか、発注書自体に「依頼者」フィールドとして格納されます。

終了時刻属性は、アクティビティの完了時刻を記録します。多くのプロセスイベントはアトミックであり開始時刻と終了時刻が同じですが、一部のアクティビティ、特に手動のアクティビティや測定可能な期間を持つアクティビティは、異なる開始タイムスタンプと終了タイムスタンプを持つ場合があります。

終了時刻を持つことで、個々のアクティビティの処理時間を正確に計算できます。これは、どの特定のステップが時間を要しているかを特定し、処理時間（作業が活発に行われている時間）と待機時間（アクティビティ間のアイドル時間）を区別するために非常に貴重です。

アクティビティ処理時間の正確な計算を可能にし、プロセスにおけるアクティブな作業時間とアイドル待機時間を区別するのに役立ちます。

イベントログまたはトランザクションデータ内で見つかり、独立した「終了時刻」または「完了日」フィールドとして存在することもあります。利用できない場合は、イベントタイムと同じ値を設定できます。

購買依頼IDは、調達プロセスを開始した内部文書の識別子であり、依頼とは、部署が購買部門に対し、物品やサービスの調達を正式に要求するものです。

このIDを利用することで、購買オーダープロセスを上流の購買依頼プロセスと連携させることができます。これにより、「依頼からオーダーまで」の広範な分析が可能となり、依頼からPO作成までの所要時間を測定できます。申請者と購買チーム間の引き渡しにおける遅延を特定するのに役立ちます。

発注書をその元となる申請に紐付け、上流の申請から発注までのサイクルタイムを分析できます。

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

通貨属性は、発注金額やその他の財務フィールドで使用される通貨単位を指定します。特に複数の通貨で事業を行う多国籍企業において、財務データを正確に解釈・集計するために不可欠です。

分析において、この属性は財務指標が同じ基準で比較されることを保証します。これは、金銭的価値を含むあらゆるダッシュボードやKPIの前提条件であり、適切な通貨換算とレポート作成を可能にし、調達プロセスの正確な財務ビューを提供します。

すべての金額に必要なコンテキストを提供し、特にグローバルな運用において正確な財務報告と比較を保証します。

このコードは通常、合計金額とともに発注書ヘッダーに格納されます。