調達から支払いまでの購買依頼向けデータテンプレート

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

この属性は、プロセスの発見と分析の基礎です。アクティビティを順に並べることで、プロセスマイニングツールは実際のプロセスフローを可視化し、標準手順からの逸脱やボトルネック、手戻りのループを特定できます。一貫性があり、意味の明確なアクティビティ名は、理解しやすく改善につながるプロセスモデルを作るうえで重要です。

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

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

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

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

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

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

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

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

購買依頼のライフサイクル全体を追跡するための基本となるキーです。関連するすべてのイベントを1つのプロセスインスタンスに結び付けられます。

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

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

この情報は、データの検証や問題の調査、システムによるプロセスの違いの把握に役立ちます。たとえば、あるシステムから登録された購買依頼は、別のシステムからの依頼と承認経路やサイクルタイムが異なる場合があります。ソースシステム別にデータを分析すると、連携上の問題やシステム統合の可能性が見つかることがあります。

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

多くの場合、データ抽出時に追加される固定値です。技術メタデータの項目から取得できることもあります。

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

この属性は、業務の監視や、最新の情報に基づいて分析するために欠かせません。実際のイベントがプロセスモデルに反映されるまでの遅れを把握するのにも役立ちます。進行中の業務を追跡するダッシュボードや重要業績評価指標（KPI）では、この情報をもとに、適切なタイミングで関連性の高いインサイトを提示します。

データがいつ時点のものかを把握できるため、分析の関連性と最新性を保つうえで役立ちます。

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

依頼者名は、購買依頼を開始した人を示します。通常、物品やサービスを必要とする業務担当者です。

依頼者別にプロセスを分析すると、特定の個人やグループに関する傾向を把握できます。たとえば、特定の依頼者が不備のある依頼やコンプライアンスに沿わない依頼を頻繁に提出し、手戻りが発生しているかどうかを確認できます。この情報をもとに、対象を絞った研修を実施したり、よく使うユーザーグループ向けに購買依頼の手続きを簡素化したりすることで、効率とコンプライアンスの向上につなげられます。

ユーザーごとの行動を把握し、個人やチームに合わせた研修やプロセス改善につなげられます。

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

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

この属性は、購買依頼から発注書への変換効率を分析するうえで重要です。購買依頼が発注書につながったことを確認し、変換にかかった時間を測定できます。発注書に対応する購買依頼を分析すると、調達前の段階がどの程度機能しているかを評価し、承認済みでありながら履行されていない依頼を特定できます。

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

発注書の作成後、購買依頼文書のデータに記録されることがよくあります。関連文書テーブルや文書フローテーブルにある場合もあります。

購買依頼ステータスは、特定の時点での依頼の状態、または最終的な結果を示します。一般的なステータスには、「進行中」「承認待ち」「承認済み」「却下」「クローズ」などがあります。

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

購買依頼の結果を明確に把握でき、却下率などの重要な指標の算出や、業務量の管理に役立ちます。

通常、購買依頼文書のヘッダーにあるステータス項目に記録されています。

購買依頼の種類は、内容や目的に基づいて購買依頼を分類します。一般的な例として、標準資材、サービス、設備投資、特定のカタログからの依頼があります。この分類によって、承認ワークフローや会計処理が決まることがあります。

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

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

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

購買依頼金額は、購買依頼に含まれるすべての品目とサービスの合計金額です。調達プロセス全体で使われる重要な財務指標です。

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

金額に基づく分析が可能になり、高額の購買依頼を優先したり、金額がプロセスに与える影響を把握したりできます。

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

通貨属性は、購買依頼金額の通貨単位を示します。多国籍の組織では、依頼者や仕入先の所在地に応じて、さまざまな通貨で購買依頼が作成されます。

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

財務データの解釈に必要な情報を示し、地域をまたいだ購買依頼金額の正確な解釈と集計を支えます。

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

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

プロセスマイニングでは、部門別のデータ分析がよく行われます。事業部門間のパフォーマンスを比較し、効率の高い部門や支援が必要な部門を特定できます。また、サイクルタイム、承認率、コンプライアンスの違いから、部門ごとの購買傾向や社内プロセスに特有の動きを把握できます。

事業部門間のパフォーマンス比較や費用分析が可能になり、部門ごとのプロセスの傾向がわかります。

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

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

この属性は、リソース分析や自動化分析の基礎となります。異なるユーザー間の引き継ぎを調べることで「複数人による確認」の実施状況を把握できます。また、システムユーザーやバッチユーザーが実行したアクティビティを特定し、自動化率の算出にも利用できます。ユーザー別にアクティビティを分析すると、各ロールがプロセスにどう関わっているかを把握できます。

ユーザー間の引き継ぎや自動化の分析、各プロセスステップを適切な担当者に割り当てるうえで欠かせない属性です。

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

却下理由は、購買依頼が否認された理由を説明するテキストまたはコードです。承認者がこの情報を依頼者に伝え、依頼者は必要に応じて内容を修正し、再提出します。

この属性は、プロセスの失敗原因を分析するうえで非常に役立ちます。却下理由を分類して分析すると、「総勘定元帳コードの誤り」「予算超過」「コンプライアンスに沿わない仕入先」など、よくある問題を特定できます。こうしたインサイトをもとに、依頼者向けの研修、ポリシーの明確な周知、よくある誤りを防ぐシステムの改善など、対象を絞った対策を進められます。

購買依頼が却下される理由を直接把握できるため、原因分析を通じて手戻りを減らし、初回承認率を高められます。

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

必要日は、依頼者が履行期限として指定します。購買依頼の承認から最終納品まで、調達プロセス全体の目標日となります。

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

業務上の期限に対するプロセスの実績を測り、期限どおりに履行できるかを評価するための基準になります。

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

承認者名は、ワークフローの承認または却下のステップを実行した個人、役割、またはグループを示します。依頼者や、ほかのアクティビティを実行する一般ユーザーとは区別されます。

この属性は、承認プロセス自体を分析するうえで重要です。承認者が判断にかける平均時間など、承認者ごとの処理状況を測定できます。また、業務負荷の分布を確認し、特定の承認者がプロセスのボトルネックになっていないかを特定できます。この分析は、承認経路におけるリソース配分やパフォーマンス管理に役立ちます。

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

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

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

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

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

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