調達から支払いまで - 申請データテンプレート

アクティビティ名とは、購買申請のライフサイクルにおける単一のステップやステータス変更を記述するものです。「申請提出済み」「承認ステップ開始」「申請却下」などの人間が理解しやすいラベルを提供し、プロセスフローの構成要素となります。

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

プロセスの個々のステップを定義し、これらはプロセスマップの視覚化とプロセスフローの分析に不可欠です。

イベントログ、ステータス変更テーブル、または購買依頼ドキュメントに関連付けられたトランザクションコードから導き出されることが多いです。

イベント時刻はタイムスタンプと呼ばれることが多く、活動が発生した正確な瞬間を記録します。このデータは、イベントを正しく順序付けし、サイクルタイム計算、ボトルネック特定、パフォーマンス監視など、すべての時間ベースのプロセス分析にとって重要です。

プロセスマイニングでは、タイムスタンプを使用して各ケース内の活動を順序付けし、異なるステップ間の期間を測定します。これらの期間を分析することで、遅延を明らかにし、長いサイクルタイムの原因を理解し、サービスレベルアグリーメントが満たされているかどうかを評価できます。正確で完全なタイムスタンプデータは、意味のあるパフォーマンス分析を行うための前提条件です。

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

通常、システム監査証跡、イベントログ、または取引記録の作成日や変更日として記録されます。

購買申請IDは、作成時にすべての申請文書に割り当てられる一意のキーです。これは、作成から完了まで、単一の要求に関連するすべてのアクティビティ、変更、承認の中心的参照点として機能します。

プロセスマイニングにおいて、このIDはケース相関に不可欠です。システムが「申請作成」「承認ステップ承認済み」「購買オーダー作成」のような異なるイベントを一貫したプロセスフローに接続し、各申請のエンドツーエンドのジャーニーを再構築することを可能にします。一貫性のある一意のケース識別子なしでは、プロセスバリアント、サイクルタイム、および結果の分析は不可能です。

これは、申請のライフサイクル全体を追跡するための不可欠なキーであり、すべての関連イベントを単一のプロセスインスタンスに接続することを可能にします。

通常、購買申請取引または文書テーブルのヘッダーデータに見られます。

ソースシステム属性は、プロセスデータの発生源を特定します。中央ERPや専門の電子調達ツールなど、複数のシステムを持つ組織では、このフィールドが異なるソースからのデータを区別するのに役立ちます。

この情報は、データ検証、トラブルシューティング、およびシステムに依存する可能性のあるプロセスバリエーションを理解するために価値があります。例えば、あるシステムで発生した申請は、別のシステムのものよりも異なる承認パスをたどるか、より速いサイクルタイムを持つ可能性があります。ソースシステム別にデータを分析することで、統合の問題やシステム統合の機会を明らかにすることができます。

データソースに関するコンテキストを提供し、これはデータ検証や複数のシステム間のプロセス差異分析にとって不可欠です。

これは多くの場合、データ抽出プロセス中に追加される静的な値であり、または技術的なメタデータフィールドに見つけることができます。

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

この属性は、運用監視と分析が最新情報に基づいていることを保証するために不可欠です。ユーザーが実世界のイベントとプロセスモデルでの表現との潜在的な時間差を理解するのに役立ちます。継続的なオペレーションを追跡するダッシュボードやKPIは、タイムリーで関連性の高い洞察を提供するためにこの情報に依存しています。

データの適時性をユーザーに通知し、分析が関連性が高く最新であることを保証するために重要です。

通常、データ統合またはETL（Extract, Transform, Load）ツールによって、データロードプロセス中に追加されます。

購買オーダーIDは、承認された購買申請から生成される購買オーダー文書の一意の番号です。このフィールドは、申請プロセスをその後の調達および支払いプロセスにリンクさせます。

この属性は、申請から購買オーダーへの変換効率を分析するために不可欠です。これにより、申請が購買オーダーに成功裏に結びついたことを確認し、この変換にかかる時間を測定することができます。どの申請に対応する購買オーダーがあるかを分析することで、企業は事前調達段階の有効性を評価し、承認されたものの決して履行されない申請を特定できます。

購買依頼を後続の調達プロセスにリンクさせ、購買依頼から発注書への変換率と時間の分析を可能にします。

発注書が作成された後の購買依頼ドキュメントデータ、時には関連ドキュメントまたはドキュメントフローテーブルで見つかることがあります。

購買依頼タイプとは、購買依頼をその性質または目的に基づいて分類するものです。例としては、標準資材、サービス、設備投資、または特定のカタログからの依頼などが含まれます。この分類は、多くの場合、承認ワークフローと会計処理を決定します。

購買依頼タイプ別にプロセスを分析することで、異なるタイプの依頼が異なるパスをたどるのか、あるいは異なるレベルの効率性を経験するのかを理解するのに役立ちます。例えば、設備投資の購買依頼は追加の承認層があるためサイクルタイムが長くなる可能性があり、標準カタログ品目の依頼は高度に自動化されている可能性があります。この分析は、タイプ固有のプロセスバリアントを設計および最適化するのに役立ちます。

購買依頼のタイプが、必要な承認ワークフローと複雑さを決定することが多いため、異なるプロセスパスの分析を可能にします。

この情報は通常、申請ヘッダーデータに文書タイプまたはカテゴリコードとして保存されます。

依頼者名とは、購買依頼を開始した個人を特定するものです。通常、この人物は商品やサービスを必要とするビジネスユーザーです。

依頼者別にプロセスを分析することで、特定の個人やグループに関連するパターンを特定できます。例えば、特定の依頼者が頻繁に不完全またはコンプライアンス違反の購買依頼を提出し、手戻りが必要になるかどうかを明らかにできます。この情報は、的を絞ったトレーニングを提供したり、一般的なユーザーグループ向けの購買依頼プロセスを簡素化したりするために使用でき、最終的に効率性とコンプライアンスを向上させます。

ユーザー固有の行動を特定するのに役立ち、個人またはチームに対する的を絞ったトレーニングとプロセス改善を可能にします。

購買依頼のヘッダーデータで見つかり、多くの場合、従業員マスターデータにリンクされています。

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

この属性は、結果分析および運用監視にとって不可欠です。アナリストは最終状態に基づいて購買依頼をフィルタリングし、却下率や発注書変換率などの指標を計算できます。運用上のコンテキストでは、承認待ちの購買依頼数など、現在のワークロードをチームが理解するのに役立ち、作業の優先順位付けとリソースの効果的な管理を可能にします。

購買依頼の結果を明確に可視化し、却下率などの主要な指標の計算を可能にし、運用ワークロード管理をサポートします。

通常、購買申請文書のヘッダーのステータスフィールドに見られます。

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

プロセス分析において、この属性は価値ベースのフィルタリングと分析に不可欠です。これにより、購買依頼を高価値と低価値などのカテゴリにセグメント化することができ、これらはしばしば異なる承認ワークフローとリスクプロファイルを持っています。購買依頼金額に基づいてサイクルタイムや却下率を分析することで、高価値の依頼が承認に著しく長い時間がかかったり、より頻繁に却下されたりすることが明らかになり、プロセス改善の出発点となります。

価値ベースの分析を可能にし、高価値の購買依頼の優先順位付けや、財務価値がプロセス行動にどのように影響するかを理解するのに役立ちます。

通常、購買申請取引または文書テーブルのヘッダーデータに見られます。

通貨属性は、申請金額の通貨単位を特定します。多国籍企業では、申請者やサプライヤーの所在地に応じて、様々な通貨で申請が作成される場合があります。

このフィールドは、正確な財務報告と分析に不可欠です。これにより、金額が正しく解釈され、異なる地域間でデータを集計する際に適切な換算が可能になります。申請金額に関する分析を行う際には、異なる通貨単位を直接比較することを避けるため、通貨を考慮する必要があります。

財務データに必要なコンテキストを提供し、地域全体の購買依頼金額の正確な解釈と集計を保証します。

通常、購買申請取引のヘッダーデータに、金額フィールドと並んで配置されます。

部門属性は、「マーケティング」「IT」「財務」など、購買を担当する組織単位を表します。これは、予算編成やコスト配分に使用される財務および組織データの重要な要素です。

プロセスマイニングにおいて、部門別にデータを分析することは一般的で強力な手法です。これにより、異なる事業単位間のパフォーマンスを比較し、どの部門が最も効率的であるか、どの部門が支援を必要とするかを特定するのに役立ちます。この分析は、部門の購買習慣や内部プロセスに固有のサイクルタイム、承認率、コンプライアンスの差異を明らかにすることができます。

異なる事業部門間のパフォーマンスベンチマークとコスト分析を可能にし、部門固有のプロセス行動を明らかにします。

通常、購買申請のヘッダーまたは明細データで利用可能であり、会社の組織構造にリンクされています。

ユーザー名は、プロセスログ内の任意のアクティビティを担当する個人を特定します。これは、申請者、編集者、承認者、または申請とやり取りする他の誰かを捕捉できる一般的な属性です。

この属性は、リソースおよび自動化分析の基本です。「四つの目原則」（異なるユーザー間の引き渡し）の理解に役立ち、システムユーザーまたはバッチユーザーによって実行されたアクティビティを特定することで自動化率を計算できます。ユーザー別のアクティビティ分析は、異なる役割がプロセスとどのようにやり取りするかを理解するのに役立ちます。

この属性は、ユーザー間の引き渡しを理解し、自動化を分析し、特定のプロセスステップを正しい担当者に帰属させるために不可欠です。

各トランザクションの監査証跡またはイベントログデータで見つかり、しばしばユーザーIDとして保存されます。

却下理由は、申請が拒否された理由を説明するテキストフィールドまたはコードです。承認者はこの情報を提供して申請者にフィードバックし、申請者は要求を修正して再提出する必要がある場合があります。

この属性は、プロセス障害の根本原因分析に非常に貴重です。却下理由を分類・分析することで、組織は「不正確な勘定科目コード」「予算超過」「コンプライアンス違反のサプライヤー」などの共通の問題を特定できます。これらの洞察は、申請者へのより良いトレーニング、より明確な方針伝達、または一般的なエラーを防ぐためのシステム強化など、ターゲットを絞った改善を推進することができます。

購買依頼が失敗する理由への直接的な洞察を提供し、手戻りを減らし、初回承認率を向上させるための根本原因分析を可能にします。

通常、「却下」アクティビティまたはステータス変更に関連付けられたコメントまたはメモフィールドにキャプチャされます。

納期希望日は、申請者が履行期限を示すために指定する日付です。この日付は、申請承認から最終納品までの調達プロセス全体の目標として機能します。

この属性は、プロセスの適時性とビジネスニーズとの整合性を分析するために重要です。納期希望日を実際の購買オーダー作成日または納品日と比較することで、組織は内部サービスレベル契約（SLA）を満たす能力を測定できます。これにより、調達プロセスがビジネスの期限を満たすのに十分速いかどうかなど、重要な質問に答えるのに役立ちます。

ビジネスの期限に対するプロセスパフォーマンスを測定し、期日通りの達成能力を評価するためのベンチマークを提供します。

通常、申請作成時にユーザーによって入力され、申請ヘッダーまたは明細詳細に保存されます。

承認者名とは、ワークフローにおいて承認または却下ステップを実行した個人、役割、またはグループを特定するものです。これは、依頼者や他の活動を行う可能性のある一般ユーザーとは異なります。

この属性は、承認プロセス自体を分析する上で重要です。承認者が決定を下すまでの平均時間など、承認者のパフォーマンスを測定するのに役立ちます。また、特定の承認者がプロセスにおけるボトルネックになっているかどうかを示すワークロードの分散を特定することもできます。この分析は、承認チェーン内でのより良いリソース配分とパフォーマンス管理をサポートします。

承認者のワークロード、パフォーマンス、ボトルネックの特定など、承認ワークフローの詳細な分析を可能にします。

承認関連活動のイベントログまたは監査ログに記録されます。従業員マスターデータとの結合が必要になる場合があります。

緊急度レベル（時には「優先度」とも呼ばれます）は、申請者が要求された物品やサービスがどのくらい迅速に必要かを示すために使用するフィールドです。この分類は、申請が調達チームや承認者によってどのようにルーティングされ、優先順位が付けられるかに影響を与える可能性があります。

緊急度レベル別にプロセスパフォーマンスを分析することは、プロセスがビジネスニーズに対応しているかどうかを判断するのに役立ちます。例えば、「高」緊急度の要求が「低」緊急度のものより実際に速く処理されているかどうかを確認できます。そうでない場合、ボトルネックや優先順位付けメカニズムの失敗を示唆している可能性があり、対処が必要です。

プロセスが緊急の依頼を効果的に優先しているか、また、明示された緊急性が実際の処理速度と一致しているかを評価するのに役立ちます。

通常、申請作成フォームのオプションまたは必須フィールドであり、申請ヘッダーに保存されます。