調達から支払いまで：購買申請のデータテンプレート

アクティビティ名は、購買依頼のライフサイクルにおける1つのステップまたはステータス変更を表します。「購買依頼を提出」、「承認ステップを開始」、「購買依頼を却下」などのイベントに、人が理解しやすいラベルを付け、プロセスマップを構成する基本要素になります。

この属性は、プロセスの発見と分析に欠かせません。アクティビティを順序付けることで、プロセスマイニングツールは実際のプロセスフローを可視化し、標準手順からの逸脱やボトルネック、手戻りループを特定できます。一貫性があり意味の明確なアクティビティ名は、理解しやすく改善に役立つプロセスモデルを作成するための鍵です。

プロセスの個々のステップを定義するため、プロセスマップの可視化とプロセスフローの分析に欠かせません。

多くの場合、イベントログ、ステータス変更テーブル、または購買依頼書に関連するトランザクションコードから取得します。

イベント時刻は、タイムスタンプとも呼ばれ、アクティビティが発生した正確な時点を記録します。このデータは、イベントを正しく順序付けるほか、サイクルタイムの計算、ボトルネックの特定、パフォーマンス監視など、時間に基づくプロセス分析全般に欠かせません。

プロセスマイニングでは、タイムスタンプを使ってケース内のアクティビティを並べ、各ステップ間の所要時間を測定します。所要時間を分析すると、遅延を見つけ、サイクルタイムが長くなる原因を把握し、サービスレベル合意が守られているかを評価できます。意味のあるパフォーマンス分析には、正確で完全なタイムスタンプデータが必要です。

イベントの順序付け、サイクルタイムの計算、プロセスのパフォーマンスとボトルネックの分析に欠かせないタイムスタンプです。

通常、システムの監査証跡、イベントログ、またはトランザクションレコードの作成日・変更日に記録されます。

購買依頼IDは、購買依頼書の作成時に各依頼へ割り当てられる一意のキーです。依頼の開始から完了まで、1件の依頼に関連するすべてのアクティビティ、変更、承認を結び付ける中心的な参照情報になります。

プロセスマイニングでは、このIDがケースの関連付けに欠かせません。これにより、システムは各購買依頼のエンドツーエンドの流れを再構築し、「購買依頼を作成」、「承認ステップを承認」、「発注書を作成」といった別々のイベントを、一貫したプロセスフローとして結び付けられます。一貫性のある一意のケース識別子がなければ、プロセスバリアント、サイクルタイム、結果を分析できません。

購買依頼のライフサイクル全体を追跡し、関連するすべてのイベントを1つのプロセスインスタンスに結び付けるために欠かせないキーです。

通常、購買依頼トランザクションのヘッダーデータ、または文書テーブルにあります。

ソースシステム属性は、プロセスデータの出所を示します。中央ERPと専門の電子調達ツールなど、複数のシステムを利用する組織では、この項目によって異なるソースのデータを区別できます。

この情報は、データの検証やトラブルシューティング、システムに依存するプロセスの違いを理解するうえで役立ちます。たとえば、あるシステムから作成された購買依頼は、別のシステムからの依頼と異なる承認経路をたどったり、サイクルタイムが短かったりする場合があります。ソースシステム別にデータを分析すると、統合上の問題やシステム統合の機会を見つけられます。

データの出所を把握できるため、データ検証や複数システム間のプロセスの違いを分析するうえで重要です。

通常、データ抽出時に追加される固定値であるか、技術メタデータの項目にあります。

最終データ更新のタイムスタンプは、分析対象データの鮮度を示します。レコードがソースシステムから最後に抽出され、プロセスマイニング環境に読み込まれた時点を確認できます。

この属性は、業務の監視や、最新情報に基づいて分析できていることを確認するうえで欠かせません。現実のイベントがプロセスモデルに反映されるまでの遅れを把握するのにも役立ちます。継続中の業務を追跡するダッシュボードやKPIでは、適時性のある関連情報を提供するためにこの情報を利用します。

データがどの時点のものかを把握できるため、分析の関連性と最新性を確保するうえで重要です。

通常、データ連携またはETL（Extract、Transform、Load）ツールがデータの読み込み時に追加します。

依頼者名は、購買依頼を開始した人物を識別します。通常、商品やサービスを必要としている業務ユーザーです。

依頼者別にプロセスを分析すると、特定の個人やグループに関する傾向を把握できます。たとえば、特定の依頼者が不完全な依頼やコンプライアンスに適合しない依頼を頻繁に提出し、手戻りが発生しているかを確認できます。この情報を使って対象を絞ったトレーニングを実施したり、よく利用するユーザーグループ向けに購買依頼プロセスを簡素化したりすることで、効率とコンプライアンスを高められます。

ユーザーごとの行動を把握できるため、個人やチームを対象としたトレーニングとプロセス改善に役立ちます。

購買依頼のヘッダーデータにあり、従業員マスターデータと関連付けられていることがよくあります。

発注書IDは、承認済みの購買依頼から生成された発注書の一意の番号です。この項目によって、購買依頼プロセスと、その後の調達・支払いプロセスを結び付けられます。

この属性は、購買依頼から発注書への変換効率を分析するうえで欠かせません。購買依頼が正常に発注書へつながったことを確認し、変換にかかった時間を測定できます。対応する発注書がある購買依頼を分析することで、調達前段階の有効性を評価し、承認されたものの履行されていない購買依頼を特定できます。

購買依頼を後続の調達プロセスに結び付け、購買依頼から発注書への変換率と所要時間を分析できます。

通常、発注書の作成後に購買依頼書のデータに記録され、関連文書テーブルまたは文書フローテーブルにある場合もあります。

購買依頼ステータスは、特定時点での依頼の状態、または最終結果を示します。一般的なステータスには、「In Progress」、「Pending Approval」、「Approved」、「Rejected」、「Closed」などがあります。

この属性は、結果分析と業務監視に欠かせません。最終状態に基づいて購買依頼を絞り込み、却下率や発注書への変換率などの指標を計算できます。業務の現場では、承認待ちの購買依頼数など現在の作業量を把握し、作業の優先順位付けやリソース管理に役立てられます。

購買依頼の結果を明確に把握できるため、却下率などの主要指標を計算し、業務の作業量を管理できます。

通常、購買依頼書のヘッダーにあるステータス項目にあります。

購買依頼タイプは、性質や目的に基づいて購買依頼を分類します。標準資材、サービス、資本的支出、特定カタログからの依頼などが例です。この分類によって、承認ワークフローや会計処理が決まることがあります。

購買依頼タイプ別にプロセスを分析すると、依頼の種類によって異なる経路をたどるか、効率に違いがあるかを把握できます。たとえば、資本的支出の購買依頼は承認層が多いためサイクルタイムが長くなる一方、標準カタログ品の依頼は高度に自動化されている場合があります。この分析は、タイプ別のプロセスバリアントの設計と最適化に役立ちます。

購買依頼の種類によって必要な承認ワークフローや複雑さが決まることが多いため、異なるプロセス経路を分析できます。

通常、購買依頼のヘッダーデータに文書タイプまたはカテゴリコードとして保存されます。

購買依頼金額は、購買依頼で要求されたすべての商品とサービスの合計金額を表します。調達プロセス全体で使用される主要な財務指標です。

プロセス分析では、金額に基づく絞り込みや分析に欠かせない属性です。購買依頼を高額と低額などに分類できます。これらは承認ワークフローやリスク特性が異なることがよくあります。購買依頼金額別にサイクルタイムや却下率を分析すると、高額な依頼は承認に大幅な時間がかかる、または却下されやすいといった傾向が明らかになり、プロセス改善の出発点になります。

金額に基づく分析が可能になり、高額な購買依頼の優先順位付けや、金額がプロセスの動きに与える影響の把握に役立ちます。

通常、購買依頼トランザクションのヘッダーデータ、または文書テーブルにあります。

通貨属性は、購買依頼金額の通貨単位を示します。多国籍組織では、依頼者やサプライヤーの所在地に応じて、さまざまな通貨で購買依頼が作成される場合があります。

この項目は、正確な財務報告と分析に欠かせません。金額を正しく解釈し、地域をまたいでデータを集計する際に適切な換算を行えるようにします。購買依頼金額を分析する場合は、異なる通貨単位をそのまま比較しないよう、通貨を考慮する必要があります。

財務データを正しく解釈するための前提となり、地域をまたいだ購買依頼金額の正確な解釈と集計を可能にします。

通常、金額項目とともに購買依頼トランザクションのヘッダーデータにあります。

部門属性は、購買を担当する組織単位を表します。「マーケティング」、「IT」、「財務」などが該当します。予算管理やコスト配賦に使われる重要な財務・組織データです。

プロセスマイニングでは、部門別のデータ分析が一般的で効果的です。異なる事業部門のパフォーマンスを比較し、効率の高い部門と支援が必要な部門を特定できます。この分析により、部門ごとの購買習慣や社内プロセスに起因するサイクルタイム、承認率、コンプライアンスの違いを明らかにできます。

異なる事業部門間のパフォーマンス比較とコスト分析が可能になり、部門固有のプロセス上の傾向を把握できます。

通常、購買依頼のヘッダーデータまたは明細データにあり、会社の組織構造と関連付けられています。

ユーザー名は、プロセスログ内の各アクティビティの担当者を示します。申請者、編集者、承認者など、購買申請に関わるユーザーを記録できる汎用的な属性です。

この属性は、リソース分析や自動化分析に欠かせません。異なるユーザー間の引き継ぎである「四つの目の原則」を把握したり、システムユーザーやバッチユーザーが実行したアクティビティを特定して自動化率を算出したりできます。ユーザー別にアクティビティを分析することで、さまざまな役割がプロセスにどのように関わっているかを把握できます。

この属性は、ユーザー間の引き継ぎの把握、自動化の分析、各プロセスステップの正しい担当者への割り当てに欠かせません。

各取引の監査証跡またはイベントログデータに記録されます。多くの場合、ユーザーIDとして保存されます。

却下理由は、購買依頼が否認された理由を説明するテキスト項目またはコードです。承認者が依頼者へのフィードバックとして入力し、依頼者は依頼を修正して再提出する場合があります。

この属性は、プロセスの失敗原因を分析するうえで非常に役立ちます。却下理由を分類・分析すると、「GLコードの誤り」、「予算超過」、「コンプライアンスに適合しないサプライヤー」など、よくある問題を特定できます。こうした結果をもとに、依頼者向けトレーニングの改善、ポリシーの明確化、よくある誤りを防ぐシステム改善など、対象を絞った対策を実施できます。

購買依頼が失敗した理由を直接把握できるため、根本原因分析を行い、手戻りを減らして初回承認率を高められます。

通常、「Rejected」アクティビティまたはステータス変更に関連付けられたコメント項目やメモ項目に記録されます。

必要日は、履行期限を示すために申請者が指定します。この日付は、購買申請の承認から最終納入まで、調達プロセス全体の目標となります。

この属性は、プロセスの適時性と業務上の要件との整合性を分析するうえで重要です。必要日と実際の発注書作成日または納入日を比較することで、組織が社内のサービスレベル合意をどの程度満たせているかを測定できます。調達プロセスが業務上の期限に間に合う速さで進んでいるか、といった重要な問いにも答えられます。

業務上の期限に対するプロセスパフォーマンスを測定し、期限どおりに履行できる能力を評価するための基準になります。

通常、購買申請の作成時にユーザーが入力し、申請ヘッダーまたは明細項目の詳細に保存されます。

承認者名は、ワークフローで承認または却下のステップを実行した個人、役割、またはグループを識別します。依頼者や、その他のアクティビティを実行する一般ユーザーとは異なります。

この属性は、承認プロセス自体を分析するための重要な情報です。承認者が判断を下すまでの平均時間など、承認者のパフォーマンスを測定できます。また、作業量の偏りを把握し、特定の承認者がプロセスのボトルネックになっていないかを確認できます。この分析は、承認経路におけるリソース配分とパフォーマンス管理の改善に役立ちます。

承認者の作業量やパフォーマンス、ボトルネックの特定など、承認ワークフローを詳細に分析できます。

承認関連のアクティビティについて、イベントログまたは監査ログに記録されます。従業員マスターデータとの結合が必要になる場合があります。

緊急度は、優先度とも呼ばれ、要求した商品やサービスがどの程度早く必要かを依頼者が示す項目です。この分類は、調達チームや承認者による購買依頼の振り分けと優先順位付けに影響します。

緊急度別にプロセスのパフォーマンスを分析すると、業務ニーズに応じてプロセスが対応できているかを確認できます。たとえば、「High」の依頼が「Low」の依頼より実際に早く処理されているかを検証できます。そうでない場合は、ボトルネックや優先順位付けの仕組みが機能していない可能性があります。

緊急の依頼が適切に優先されているか、申告された緊急度と実際の処理速度が一致しているかを評価できます。

通常、購買依頼の作成フォームにある任意または必須の項目で、購買依頼のヘッダーに保存されます。