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

SAP S/4HANA
調達から支払いまでの購買依頼データテンプレート

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

このテンプレートでは、調達から支払いまでの購買依頼プロセスを分析するために必要なデータの収集方法を説明します。SAP S/4HANAに合わせて、記録すべき属性とアクティビティ、およびデータ抽出の手順をまとめています。この資料を使ってイベントログを作成し、プロセスマイニングによる分析を進めてください。
  • 詳細な分析に必要な属性
  • プロセスの発見に必要な主要アクティビティ
  • SAP S/4HANAからのデータ抽出手順
イベントログを初めて作成する方はこちら: プロセスマイニング用イベントログの作成方法.

調達から支払いまでの購買依頼の属性

調達から支払いまでの購買依頼プロセスを詳しく分析するために、イベントログに含めることを推奨するデータ項目です。
3 必須 6 推奨 11 任意
名前 説明
アクティビティ名
ActivityName
購買依頼プロセスの特定の時点で発生した業務アクティビティの名前です。
説明

アクティビティ名は、購買依頼のライフサイクルで発生した特定のイベントやタスクを表します。変更文書やワークフロー履歴などのシステムログから導出され、「購買依頼の作成」「承認ステップの開始」「発注書の作成」など、プロセスの主要な節目を示します。

これらのアクティビティを分析すると、プロセスの流れを可視化し、ボトルネックを特定して、各段階にかかった時間を測定できます。「購買依頼の変更」や「購買依頼の却下」などのアクティビティの順序や頻度を把握することは、プロセスの非効率な箇所や改善点を見つけるうえで重要です。

重要な理由

プロセスの各ステップを定義し、プロセスマップの基盤となります。プロセスの流れ、バリアント、ボトルネックを分析できます。

入手先

変更文書テーブル(CDHDR、CDPOS)やワークフローログ(例:SWWLOGHIST)のデータを解釈して作成する派生属性です。

例
購買依頼の作成承認ステップの完了購買依頼の承認発注書の作成
イベント時刻
EventTime
特定のアクティビティが発生した正確な日時です。
説明

イベント時刻は、アクティビティが発生した日時を記録するタイムスタンプです。ケース内のイベントを時系列に並べるために欠かせないデータであり、プロセスマイニングにおける期間やパフォーマンスの計算の基礎となります。たとえば、「購買依頼の提出」と「購買依頼の承認」の時刻の差から、承認サイクルタイムを算出できます。

正確なタイムスタンプは、プロセスのパフォーマンスを分析し、遅延を特定して、サービスレベル合意の遵守状況を確認するうえで欠かせません。この属性を使うと、サイクルタイムの可視化、処理が滞っている購買依頼の追跡、期間ごとのパフォーマンス比較ができるダッシュボードを作成できます。

重要な理由

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

入手先

通常、変更文書ヘッダー(CDHDR-UDATE、CDHDR-UTIME)またはワークフローイベントログから取得します。

例
2023-04-15T10:05:30Z2023-04-15T14:22:01Z2023-04-16T09:00:15Z
購買依頼ID
PurchaseRequisitionId
購買依頼文書を一意に識別するIDです。
説明

購買依頼IDは、SAP S/4HANAで商品やサービスの各依頼を一意に識別する主キーです。ケースを識別する中心的な項目として、作成から承認、却下、発注書への変換などの最終状態に至るまで、特定の購買依頼に関連するすべてのアクティビティと変更を結び付けます。

プロセスマイニングでは、この属性を使って各購買依頼のライフサイクル全体を再構成します。関連するすべてのイベントを1つの購買依頼IDにまとめることで、分析担当者はサイクルタイムを正確に測定し、ステータスの変化を追跡して、承認プロセスで購買依頼がたどるさまざまな経路を分析できます。

重要な理由

関連するすべてのプロセスステップを結び付ける基本的なケース識別子です。購買依頼のライフサイクル全体を一貫して把握できます。

入手先

EBANテーブルのBANFNフィールドにある購買依頼番号です。

例
100178901001789110017892
ユーザーID
UserId
購買依頼を作成したユーザー、または特定のアクティビティを実行したユーザーの識別子です。
説明

ユーザーIDは、購買依頼のライフサイクルにおける特定のイベントを担当した従業員またはシステムユーザーを識別します。購買依頼を作成した人、承認したマネージャー、変更を加えた担当者などが該当します。自動処理の場合は、システムユーザーやバッチユーザーのIDが記録されることがあります。

ユーザーIDで分析すると、ユーザーごとの行動、業務負荷の分布、パフォーマンスを把握できます。研修が必要な領域や高い成果を上げている担当者を特定し、プロセスの責任の所在を明確にするうえでも役立ちます。ユーザーマスターデータと組み合わせると、部門ごとのパフォーマンス分析にも利用できます。

重要な理由

ユーザーごとのパフォーマンス、業務負荷の分布、プロセスのコンプライアンスを分析できます。研修の機会やリソース面のボトルネックを特定するうえでも重要です。

入手先

作成者のIDはEBAN-ERNAMにあります。以降の変更についてはCDHDR-USERNAMEに、承認についてはワークフローログに記録されています。

例
JSMITHRROEWF-BATCH
承認者ID
ApproverId
承認または却下のステップを実行したユーザーの識別子です。
説明

承認者IDは、承認または却下のアクティビティを完了したユーザーを特定します。一般的なユーザーIDとは異なり、承認ワークフローで判断を下す担当者に絞った情報です。この情報を記録すると、承認プロセスを詳細に分析できます。

この属性を使うと、承認に時間がかかるマネージャーや、購買依頼を頻繁に却下する担当者など、承認時の傾向を分析できます。承認ステップのサイクルタイムやワークフローのボトルネックを分析するダッシュボードの基礎となり、遅延の原因となっている個人やロールを特定できます。

重要な理由

承認ステップで判断を下した担当者を特定し、個人またはロールごとに承認サイクルタイムやボトルネックを詳しく分析できます。

入手先

通常、SAP Business WorkflowのSWW_WI2OBJやSWWLOGHISTなどのテーブルから取得します。これらのテーブルでは、作業項目と完了したユーザーが関連付けられています。

例
MJOHNSONCWILLIAMSLBLACK
購買依頼ステータス
RequisitionStatus
購買依頼の現在の処理状況または承認状況です。
説明

購買依頼ステータスは、ライフサイクルにおける購買依頼の現在の状態を示します。SAPでは、リリース指標で表されることが多く、ブロック中、承認中、一部承認済み、承認済みなどの状態を確認できます。購買依頼がワークフローを進むにつれて、ステータスも変化します。

ステータスを時系列で追跡することは、プロセスの流れを理解するうえで欠かせません。購買依頼がどこで、どのくらい滞留しているかを特定できます。ステータス間の遷移を分析すると、承認プロセスとそのバリアントを詳しく把握できます。

重要な理由

購買依頼の現在の状態を示します。進捗の追跡、ボトルネックの特定、プロセスの流れの分析に欠かせません。

入手先

リリースステータスは、通常、EBANテーブルのFRGZUフィールドにあるリリース指標から判定します。

例
B1S
購買依頼タイプ
RequisitionType
購買依頼を分類するコードです。標準品、サービス、設備投資などを区別します。
説明

購買依頼タイプは、SAPでは文書タイプとも呼ばれる重要な設定項目です。購買依頼を分類し、タイプごとに異なる承認ワークフローやフィールド設定を適用できます。また、標準在庫品、外部サービス、資産購入など、用途に応じた分類にも使われます。

購買依頼タイプ別にプロセスを分析すると、依頼の種類ごとの処理方法を把握できます。カテゴリ間でパフォーマンス、サイクルタイム、承認経路を比較することで、特定のタイプの効率が低いかどうかを確認し、状況に応じたプロセス改善につなげられます。

重要な理由

購買依頼を分類して比較分析を可能にし、依頼の種類によるプロセスの流れ、ボトルネック、サイクルタイムの違いを把握できます。

入手先

EBANテーブルのBSARTフィールドにある文書タイプです。

例
NBFORV
購買依頼金額
RequisitionAmount
購買依頼の合計金額です。
説明

購買依頼金額は、依頼された商品やサービスの見積総額を示します。この金額は承認ワークフローの複雑さや所要時間を左右する要因となることが多く、高額な購買依頼ほど多くの承認段階が必要になる傾向があります。

この属性を使うと、金額別にプロセスを分析できます。たとえば、「高額な購買依頼は承認に時間がかかるか」「頻繁に却下される購買依頼の金額はいくらか」といった問いに答えられます。プロセスの非効率が財務に与える影響を把握するうえで重要な分析軸です。

重要な理由

金額の影響に応じてプロセスを分類できます。承認の複雑さやサイクルタイムとの関連を把握し、金額別のプロセス分析に役立てられます。

入手先

合計金額はEBANテーブルのGFWERTフィールドにあります。明細ごとの金額はEBAN-PREISにあります。

例
1500.0075000.50250.75
部門
Department
購買依頼の費用が計上される部門または原価センタです。
説明

部門属性は、SAPでは原価センタで表されることが多く、依頼された購入を担当する事業部門を識別します。購買依頼の明細レベルに割り当てられる、財務および組織に関する重要な情報です。

プロセスマイニングでは、部門ごとのパフォーマンス分析に欠かせない属性です。サイクルタイム、変更率、却下率などの主要指標を部門間で比較するダッシュボードを作成できます。成果の高い部門の取り組みを他部門に広げたり、追加の研修やプロセス支援が必要な部門を特定したりできます。

重要な理由

事業部門間のパフォーマンスを比較し、サイクルタイムや却下率の違いを把握できます。優れた取り組みや改善点の特定に役立ちます。

入手先

通常、勘定設定テーブルEBKNのKOSTLフィールドにある原価センタです。

例
FIN-1001IT-2005MKT-3010
ソースシステム
SourceSystem
データの抽出元となった特定のSAP S/4HANAインスタンスを識別します。
説明

ソースシステム属性は、プロセスデータが生成されたシステムを示します。開発、品質保証、本番環境で異なるシステムを使う場合や、地域ごとに別のシステムを使う場合など、複数のSAPインスタンスがある組織では、データガバナンスとコンテキストの把握に欠かせない項目です。

データの出所を区別できるため、異なるソースのデータが誤って集計されるのを防ぎ、システムごとの分析が可能になります。また、データリネージを維持し、プロセスデータの追跡可能性を確保するために必須の属性です。

重要な理由

複数のシステムがある環境で、データの出所やガバナンスに必要なコンテキストを示し、データの追跡可能性を確保します。

入手先

通常はSAPシステムID(SID)です。システム変数または設定テーブルから取得できます。

例
S4PECCS4H_PROD_01
最終データ更新
LastDataUpdate
このレコードのデータがソースシステムから最後に更新された日時を示すタイムスタンプです。
説明

この属性には、ソースシステムからデータを最後に抽出または更新した日時が記録されます。分析対象のデータがどれだけ新しいかを把握するための重要なメタデータです。分析担当者や業務ユーザーは、このタイムスタンプを確認して、プロセスデータが業務の最新状況を反映しているかを判断できます。

プロセスを分析する際、データがいつ時点のものかを把握することは、適切な判断を下すうえで欠かせません。この属性によってユーザーの期待値を調整し、分析の目的に必要な鮮度を満たすデータに基づいて結論を導けます。

重要な理由

データの鮮度を示します。分析結果への信頼を高め、適切なタイミングで業務上の判断を下すうえで重要です。

入手先

データの抽出、変換、ロード(ETL)の処理中に生成され、追加されるタイムスタンプです。

例
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
却下理由
RejectionReason
購買依頼が却下された際に示される理由です。
説明

却下理由は、承認者が購買依頼を却下した理由を示します。予算超過、情報の誤り、方針への不適合、他の依頼との重複などが考えられます。この情報は、プロセスが完了しなかった原因を理解するうえで重要なコンテキストとなります。

却下理由を分析すると、プロセスの非効率や手戻りの根本原因を特定できます。たとえば、「原価センタの誤り」がよくある理由であれば、ユーザー研修の強化やシステムでの入力チェックが必要だと分かります。この属性は、購買依頼の却下分析ダッシュボードの基礎となり、対象を絞ったプロセス改善に欠かせません。

重要な理由

プロセスが完了しなかった根本原因を把握し、手戻りを減らして購買依頼の初回正解率を高めるための改善につなげられます。

入手先

標準フィールドではないことが多く、ワークフローのコンテナ要素、購買依頼に関連付けられた長文テキスト、またはカスタムフィールドに記録される場合があります。

例
予算超過仕入先の誤り依頼の重複
必要日
RequiredByDate
申請者が商品やサービスを必要とする日付です。
説明

必要日は、SAPでは納品日とも呼ばれ、購買依頼明細の商品やサービスが必要となる日を示します。申請者が設定し、調達プロセス全体の目標日として使われます。

この属性は、「購買依頼の期限内完了率」の重要業績評価指標(KPI)を算出するうえで欠かせません。必要日と最終承認日または発注書の作成日を比較すると、組織内のサービスレベルや業務上のニーズを満たせているかを測定できます。この日付に間に合わなかった購買依頼を分析すると、調達プロセスにおける恒常的な遅延が明らかになることがあります。

重要な理由

依頼の完了目標日を定め、期限内の納品と社内サービスレベルの遵守状況を測定できます。

入手先

EBANテーブルの明細レベルにあるLFDATフィールドの納品日です。

例
2023-11-152023-12-012024-01-20
手戻りかどうか
IsRework
申請後の修正など、アクティビティが手戻りに該当するかどうかを示すフラグです。
説明

Is Reworkは、付加価値のない作業や繰り返し作業に該当するアクティビティを特定する計算済みのブール値です。このプロセスでは、購買依頼が承認に回された後に「購買依頼を修正」アクティビティが発生し、承認プロセスを最初からやり直すケースが典型例です。

この属性を使うと、プロセス内の手戻りの量と、全体のサイクルタイムへの影響を定量化できます。「購買依頼の修正と手戻り率」ダッシュボードでは、このフラグを使ってプロセスの非効率な箇所を確認できます。手戻りを減らすことは、時間と労力の削減に直結するため、プロセス改善の主な目標となることがよくあります。

重要な理由

無駄な作業や繰り返し作業に該当するアクティビティを特定し、手戻りの量とプロセス効率への影響を直接測定できます。

入手先

これは計算属性です。通常は、最初の「購買依頼を承認申請」アクティビティの後に発生した「購買依頼を修正」アクティビティを手戻りとして判定します。

例
truefalse
承認ステップ名
ApprovalStepName
ワークフロー内の承認ステップを示す具体的な名前または説明です。
説明

承認ステップ名は、承認ワークフローの各段階を「マネージャー承認」や「財務担当副社長の承認」のように分かりやすく示します。「承認ステップ完了」のような一般的なアクティビティよりも具体的です。

この属性は、「承認ステップのサイクルタイム」や「ワークフローのボトルネック分析」ダッシュボードで使います。承認プロセスを細かく確認し、どの段階で大幅な遅延や滞留が発生しているかを特定できます。承認フローを的確に改善するには、この詳細な情報が必要です。

重要な理由

承認の各段階を詳しく把握し、複数段階にわたる承認ワークフローのボトルネックを正確に特定できます。

入手先

この情報はワークフロータスクの説明から取得します。ワークフローログをT528Tなどのタスク定義テーブルと結合して確認できます。

例
マネージャー承認ディレクター承認財務担当副社長の承認
発注書番号
PurchaseOrderNumber
購買依頼から作成された発注書の番号です。
説明

発注書番号は、承認済みの購買依頼から作成された正式な購買文書の識別子です。発注書の作成は、購買依頼が仕入先への正式な注文に変換されたことを示し、購買依頼プロセスの最終的な成果となることが多いです。

この属性は、購買依頼から発注書へのリードタイムに関する重要業績評価指標(KPI)や、全体の変換率を測定するうえで重要です。購買依頼プロセスと後続の調達プロセスを結び付け、調達から支払いまでのサイクル全体をエンドツーエンドで把握できます。

重要な理由

購買依頼を後続の調達文書に結び付け、購買依頼から発注書への変換率とリードタイムを測定できます。

入手先

購買依頼明細から発注書が作成されると、EBANテーブルのEBELNフィールドに記録されます。

例
450001789045000178914500017892
終了時刻
EndTime
特定のアクティビティが完了した日時です。
説明

EndTimeは、アクティビティが終了した時刻を記録するタイムスタンプです。システムが生成するイベントの多くは瞬時に発生するため、StartTimeとEndTimeが同じになります。一方、承認などの人が行うタスクでは、開始時刻と終了時刻が異なる場合があります。このタイムスタンプは、作業の完了時刻を示します。

EndTimeを個別に記録すると、実際の処理時間と待機時間をより正確に測定できます。StartTimeと組み合わせてProcessingTime指標の算出に使います。こうした詳細な情報により、手作業におけるリソースの利用状況や効率を詳しく分析できます。

重要な理由

アクティビティの完了時刻を記録し、実際の処理時間を算出できます。タスクの所要時間も詳しく把握できます。

入手先

作業項目の作成時刻(StartTime)と完了時刻(EndTime)の両方を記録するワークフローログから取得します。

例
2023-04-15T10:20:30Z2023-04-15T14:25:01Z2023-04-16T11:00:45Z
緊急度
UrgencyLevel
購買依頼の緊急度を分類する属性です。処理の優先順位に影響する場合があります。
説明

緊急度は、購買依頼の優先順位を示します。専用の標準フィールドはありませんが、組織によってはRequirement Tracking Numberなどのフィールドにこの情報を記録しています。依頼者はこの情報を使って、迅速な処理が必要な重要案件を示せます。

緊急度がプロセスに与える影響を分析することで、重要な依頼が適切に優先されているかを評価できます。「緊急度の影響分析」ダッシュボードでは、この属性を使って緊急の購買依頼と通常の購買依頼のサイクルタイムや承認率を比較し、優先処理が意図どおりに機能しているかを確認できます。

重要な理由

優先度の高い依頼でプロセスのパフォーマンスがどう異なるかを分析し、緊急案件が実際に迅速に処理されているかを確認できます。

入手先

標準の緊急度フィールドはありません。この目的でRequirement Tracking Number(EBAN-BEDAR)を使う企業もあります。カスタムフィールドが使われている場合もあります。

例
高中低
自動処理かどうか
IsAutomated
アクティビティが人ではなくシステムユーザーによって実行されたかどうかを示すフラグです。
説明

Is Automated属性は、アクティビティがシステムユーザーまたはバッチユーザーによって実行された場合にtrueとなるブール値です。ワークフローの処理で使われる「WF-BATCH」などが該当します。この属性により、プロセス内の手作業と自動処理を区別できます。

この属性は、購買依頼プロセスの自動化レベルの測定や、「自動承認率」KPIの算出に欠かせません。自動処理と手作業を分けて分析することで、効率を比較し、処理時間や手作業を減らすために自動化できる箇所を特定できます。

重要な理由

人が行うアクティビティとシステムによるアクティビティを区別できます。自動化率の測定や、手作業を自動化できる箇所の特定に役立ちます。

入手先

これは派生属性です。通常は、イベントのUser IDが既知のシステムユーザーまたはバッチユーザーの一覧に含まれているかどうかを確認するルールに基づいて設定します。

例
truefalse
通貨
Currency
購買依頼金額の通貨コードです。
説明

この属性は、購買依頼金額の通貨(USD、EUR、JPYなど)を示します。複数の通貨を扱う多国籍組織では、購買依頼金額を正しく理解するために必要な情報です。

正確な財務分析やレポーティングには、通貨を考慮する必要があります。購買依頼の金額を集計または比較する場合は、意味のある結果を得るために、すべての金額を共通通貨に換算します。この属性は、その換算に必要です。

重要な理由

購買依頼金額の通貨を示し、複数通貨を扱う環境で正確な財務分析や比較を可能にします。

入手先

EBANテーブルのWAERSフィールドにあります。

例
USDEURGBP
必須 推奨 任意

調達から支払いまでの購買依頼のアクティビティ

プロセスを正確に把握するために、イベントログに記録する主要なステップとマイルストーンです。
6 推奨 6 任意
アクティビティ 説明
承認ステップの完了
承認者が購買依頼を承認し、多段階の承認ワークフローの1つのステップが完了したときに発生します。購買依頼のリリースステータスの変化から推定します。
重要な理由

このアクティビティを使うと、承認ワークフローを詳細に分析し、各ステップにかかった時間を測定できます。処理の速い承認者や、プロセスのボトルネックを特定するのに役立ちます。

入手先

EBANテーブルの変更文書(CDHDR/CDPOS)から推定します。特定のリリースコードについて、リリースステータス(例:FRGZU)が未リリースからリリース済みに変わると、このイベントに該当します。

記録

リリース方針で定義された各リリースコードについて、EBANのリリースステータスフィールドの変更を追跡します。

イベントタイプ inferred
発注書の作成
購買依頼明細を参照する発注書が作成されたことを示します。購買依頼と後続の調達文書を結び付ける、システム上の明示的なイベントです。
重要な理由

これは購買依頼プロセスの重要な節目であり、望ましい成果です。購買依頼の承認から発注書の作成までの時間は、調達効率を測る重要業績評価指標(KPI)です。

入手先

発注書明細が作成されたときに明示的に記録されます。購買依頼番号(BANFN)と明細番号(BNFPO)を含むEKPOテーブル(発注書明細)に、購買依頼との関連が保存されます。

記録

購買依頼番号と明細番号を使って、EKPOテーブルをEBANテーブルに結合します。発注書明細の作成日がイベントの日時となります。

イベントタイプ explicit
購買依頼の作成
システムで購買依頼文書が最初に作成されたことを示します。ユーザーが新しい購買依頼を初めて保存した時点でイベントが記録され、作成日時が保存されます。
重要な理由

このアクティビティは、購買依頼のライフサイクル分析における主な開始点です。最初のニーズの特定から最終承認、または発注書への変換まで、エンドツーエンドのサイクルタイムを測定するうえで欠かせません。

入手先

EBANテーブルの作成日(ERDAT)と作成時刻(ERZEIT)を使用して、対象の購買依頼番号(BANFN)に対する明示的なイベントとして記録されます。

記録

EBANテーブルから、各購買依頼(BANFN)の作成日時フィールド(ERDAT、ERZEIT)を使用します。

イベントタイプ explicit
購買依頼の却下
承認者が購買依頼を最終的に却下し、プロセスが停止したことを示します。却下を示す特定のステータス更新によって記録されます。
重要な理由

このアクティビティは、プロセスが完了に至らなかったことを示す終了点です。却下の頻度、理由、発生箇所を分析すると、方針への適合性、予算、依頼内容の品質に関する問題を特定できます。

入手先

EBANテーブルのステータス変更から推定します。処理ステータス(PROCSTAT)またはリリース指標が、「却下」を明示する値に設定された場合に該当します。

記録

変更文書を使って、EBANの全体ステータスが「却下」に更新された日時を特定します。

イベントタイプ inferred
購買依頼の完了
購買依頼明細の処理が完了し、そこから新たな発注書を作成できない状態を示します。通常、依頼数量の全量が発注されると、このステータスが自動的に設定されます。
重要な理由

このアクティビティは、購買依頼明細のライフサイクルが正常に完了したことを示します。業務上のニーズが調達注文に反映されたことを確認できます。

入手先

EBANテーブルから推定します。「完了」指標(EBAKZ)が設定されたときに該当します。通常、発注書の発注数量が購買依頼の数量と一致した場合に設定されます。

記録

変更文書を使って、EBANテーブルで「完了」指標(EBAKZ)が設定されたイベントを特定します。

イベントタイプ inferred
購買依頼の承認
購買依頼が最終承認され、発注書に変換できる状態になったことを示します。全体のリリースステータスが最終承認状態に達した時点から推定します。
重要な理由

これは重要な完了の節目であり、サイクルタイム分析でよく使われる終了点です。購買依頼がすべての確認を通過し、調達部門が処理できる状態になったことを示します。

入手先

EBANテーブルのステータス変更から推定します。具体的には、全体のリリース指標(FRGZU)または処理ステータス(PROCSTAT)が最終的な「承認済み」の値に更新されたときに該当します。

記録

最終リリースコードが適用された日時、または購買依頼の全体ステータスが「承認済み」に変わった日時を特定します。

イベントタイプ inferred
供給元の割り当て
購買担当者が、承認済みの購買依頼明細に特定の仕入先、契約、または情報レコードを割り当てる操作を示します。購買依頼から発注書を作成するための重要なステップです。
重要な理由

このアクティビティは、承認から発注までをつなぐステップです。供給元の割り当てにかかる時間を測定すると、購買担当者の業務負荷や調達効率に関する遅延を特定できます。

入手先

EBANテーブルの供給元関連フィールド(固定仕入先(LIFNR)、情報レコード(INFNR)、契約(KONNR)など)に値が入力されたことから推定します。

記録

変更文書を使って、EBANテーブルのLIFNR、INFNR、KONNRなどのフィールドに値が入力されたことを追跡します。

イベントタイプ inferred
承認ステップの開始
特定の承認者または承認グループによる対応を待っている購買依頼を示します。購買依頼のステータスが、特定のリリースコードの処理待ちを示す場合に推定します。
重要な理由

このアクティビティは、承認経路のボトルネックを特定するうえで欠かせません。この状態が続く時間を分析すると、処理が滞っている購買依頼や、業務が集中している承認者を把握できます。

入手先

EBANテーブルのリリースステータスフィールド(例:FRGZU)と、関連するリリース方針の設定から推定します。特定のリリースコードが次の処理対象になった時点でイベントが開始します。

記録

ワークフローログまたはステータスフィールドを基に、特定のリリースコードの承認待ち状態に購買依頼が入った時点を特定します。

イベントタイプ inferred
承認のリセット
承認ワークフロー全体がリセットされたことを示します。多くの場合、購買依頼に大幅な変更があったために発生し、承認プロセスは最初のレベルからやり直しになります。
重要な理由

このアクティビティから、サイクルタイムに大きく影響する手戻りを把握できます。承認がリセットされる原因を特定することは、プロセスの効率化と遅延の削減につながります。

入手先

EBANテーブルの変更文書(CDHDR/CDPOS)から推定します。リリースステータスのフィールド(FRGKZやFRGZUなど)が、一部またはすべて設定された後にクリアされた場合に検出されます。

記録

変更ログで、リリースステータスがリリース済みから未リリースに戻った箇所を確認します。

イベントタイプ inferred
購買依頼の取り下げ
元の申請者が、処理の完了前に購買依頼を取り消すか削除したときに発生します。通常は明示的な操作で、購買依頼の明細に削除フラグが設定されます。
重要な理由

取り下げを追跡すると、需要の変動や取り消しの理由を把握できます。取り下げは購買依頼の終了状態を示し、それ以降の処理は行われません。

入手先

EBANテーブルの購買依頼明細に削除指標(LOEKZ)が設定されたときに明示的に記録されます。この変更はCDHDR/CDPOSに記録されます。

記録

EBANテーブルで削除指標(LOEKZ)が「L」に設定されたイベントを特定します。

イベントタイプ explicit
購買依頼の変更
購買依頼の作成後に、ユーザーが数量、価格、品目などの主要フィールドを変更したときに発生します。この操作は、SAPの変更文書システムに明示的に記録されます。
重要な理由

変更を追跡すると、手戻りの発生箇所とサイクルタイムへの影響を特定できます。変更が頻繁に発生している場合は、データ品質や要件の変化に問題がある可能性があり、プロセス改善に向けて確認すべき点となります。

入手先

EBANテーブルに対する変更は、SAPの変更文書テーブル(CDHDR、CDPOS)に明示的に記録されます。追跡対象のフィールドが変更されるたびにエントリが作成されます。

記録

購買依頼のオブジェクトクラスがBANFであるCDHDR/CDPOSから、変更イベントを抽出します。

イベントタイプ explicit
購買依頼の承認申請
申請者が購買依頼を正式に提出し、承認ワークフローが開始された時点を示します。通常、購買依頼のリリース方針が決定され、ステータスが「承認中」に変わった時点から推定します。
重要な理由

承認サイクルタイムの重要業績評価指標(KPI)の計測開始点となる重要な節目です。作成から提出までの時間を分析すると、購買依頼の準備段階で発生している遅延を把握できます。

入手先

EBANテーブルの変更文書(CDHDR/CDPOS)から推定します。具体的には、リリース方針のフィールド(例:FRGST)が入力されたとき、または全体ステータス(PROCSTAT)が承認中を示す状態に変わったときに該当します。

記録

承認ワークフローの開始、またはステータスが「承認中」に変わったことを示す最初の変更文書エントリを特定します。

イベントタイプ inferred
推奨 任意

データ抽出ガイド

SAP S/4HANAからデータを取得する方法

始める準備はできましたか?

このテンプレートを使ってデータを準備し、調達から支払いまでの購買依頼プロセスにプロセスマイニングを取り入れてください。今すぐ効率化に取り組みましょう。

購買依頼の遅延を減らす:ワークフローを今すぐ最適化

プロセスを効率化し、リードタイムを短縮。サイクルタイムを30%削減できます。

無料トライアルを開始

クレジットカードは不要です。5分で設定できます。