調達から支払いまで:申請プロセス用データテンプレート

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は、承認または却下のアクティビティを完了したユーザーを特定します。一般的なユーザー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インスタンスを持つ組織では、この項目がデータガバナンスとコンテキストの把握に欠かせません。

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

重要な理由

データの出所とガバナンスに必要なコンテキストを提供します。特に複数のシステムで構成された環境で、データの追跡可能性を確保できます。

入手先

通常は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
申請後の修正など、アクティビティが手戻りに該当するかどうかを示すフラグです。
説明

「手戻りかどうか」は、付加価値のない作業や繰り返し作業に該当するアクティビティを特定する計算済みのブール型フラグです。このプロセスでは、承認申請の提出後に「申請修正」アクティビティが発生し、承認プロセスが最初からやり直しになるケースが典型例です。

この属性は、プロセス内の手戻り量と全体のサイクルタイムへの影響を定量化するうえで重要です。申請修正・手戻り率ダッシュボードでは、このフラグを使ってプロセスの非効率を明らかにします。手戻りを減らすことは、時間と労力の削減に直結するため、プロセス改善の主な目標となることが多いです。

重要な理由

無駄な作業や繰り返しを示し、手戻り量とプロセス効率への影響を直接測定できます。

入手先

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

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

承認ステップ名は、「マネージャー承認」や「財務担当副社長承認」など、承認ワークフロー内の特定の段階を人が理解しやすい形で示します。一般的な「承認ステップ完了」アクティビティよりも具体的な情報です。

この属性は、承認ステップのサイクルタイムとワークフローのボトルネック分析ダッシュボードに欠かせません。承認プロセスを細かく確認できるため、どの承認段階で大きな遅延が発生し、どこに作業が滞留しているかを正確に特定できます。承認経路を対象を絞って改善するには、このレベルの詳細が必要です。

重要な理由

承認段階を詳細に把握でき、多段階の承認ワークフロー内にあるボトルネックを正確に特定できます。

入手先

ワークフロータスクの説明から取得します。ワークフローログをT528Tなどのタスク定義テーブルに結び付けることで確認できます。

マネージャー承認ディレクター承認財務担当副社長承認
終了時刻
EndTime
特定のアクティビティが完了した正確な日時です。
説明

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

EndTimeを個別に保持すると、実際の処理時間と待機時間をより正確に測定できます。StartTimeと組み合わせてProcessingTimeメトリクスを計算します。これにより、手動タスクにおけるリソース利用状況と効率をより詳細に分析できます。

重要な理由

アクティビティの完了を示し、実際の処理時間の計算とタスク所要時間の詳細な把握を可能にします。

入手先

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

2023-04-15T10:20:30Z2023-04-15T14:25:01Z2023-04-16T11:00:45Z
緊急度
UrgencyLevel
申請の緊急度を分類したもので、処理の優先順位に影響する場合があります。
説明

緊急度は、購買申請の優先順位を示します。専用の標準フィールドではありませんが、組織によっては要件追跡番号などのフィールドにこの情報を記録します。これにより、申請者は迅速な処理が必要な重要案件を示せます。

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

重要な理由

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

入手先

標準の緊急度フィールドはありません。企業によっては、要件追跡番号(EBAN-BEDAR)をこの目的で使用します。カスタムフィールドが使われる場合もあります。

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

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

この属性は、申請プロセスの自動化レベルを測定し、「自動承認率」KPIを計算するうえで重要です。自動ステップと手動ステップを分けて分析すると、効率を比較し、処理時間と手作業を減らすためのさらなる自動化の機会を特定できます。

重要な理由

人によるアクティビティとシステムによるアクティビティを区別し、自動化率の測定や手動タスクを自動化する機会の特定に役立ちます。

入手先

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

truefalse
購買発注番号
PurchaseOrderNumber
申請から作成された購買発注の番号です。
説明

購買発注番号は、承認済みの申請から作成された正式な購買書類の識別子です。購買発注の作成は、申請がサプライヤーへの正式な発注に変換されたことを示す、申請プロセスの最終的な成功結果となることが多いです。

この属性は、「申請から購買発注までのリードタイム」KPIと全体の変換率を測定するうえで重要です。申請プロセスと後続の調達プロセスを結び付け、調達から支払いまでのサイクルをエンドツーエンドで把握できます。

重要な理由

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

入手先

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

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

購買依頼金額がどの通貨で表示されているかを示します。たとえば、USD、EUR、JPYなどです。複数の通貨を扱う多国籍組織では、購買依頼金額の属性を解釈するために必要な情報です。

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

重要な理由

購買依頼金額を解釈するための情報を提供し、複数通貨の環境で正確な財務分析と比較を可能にします。

入手先

EBANテーブルのWAERS項目にあります。

USDEURGBP
必須 推奨 任意

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

正確なプロセスディスカバリーのために、イベントログで取得すべき主要なプロセスステップとマイルストーンです。
6 推奨 6 任意
アクティビティ 説明
承認ステップを完了
承認者が購買依頼に対して承認操作を行い、多段階承認ワークフローの1つのステップを完了したときに発生します。通常は、購買依頼のリリースステータスの変更から推定します。
重要な理由

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

入手先

EBANテーブルに関する変更文書(CDHDR/CDPOS)から推定します。特定のリリースコードについて、リリースステータス(FRGZUなど)が未リリースからリリース済みに変わった場合、このイベントを示します。

取得

戦略で定義された各リリースコードについて、EBANのリリースステータス項目の変更を追跡します。

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

これは重要なマイルストーンであり、購買依頼プロセスが成功した結果です。購買依頼の承認から発注書作成までの時間は、調達効率を測定する重要なKPIです。

入手先

発注書項目が作成された時点で明示的に記録されます。関連付けはEKPOテーブル(発注書項目)に保存され、そこには元の購買依頼番号(BANFN)と項目番号(BNFPO)が含まれます。

取得

EKPOテーブルを購買依頼番号と項目番号でEBANに結合します。発注書項目の作成日がイベントを示します。

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

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

入手先

これはEBANテーブルから取得する明示的なイベントです。対象の購買依頼番号(BANFN)について、作成日(ERDAT)と作成時刻(ERZEIT)の項目を使用します。

取得

各購買依頼(BANFN)について、EBANテーブルの作成日時項目(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
購買依頼を修正
初回作成後に、ユーザーが数量、価格、品目など、購買依頼の主要項目を変更したときに発生します。この操作は、SAPの変更文書システムに明示的に記録されます。
重要な理由

修正を追跡することは、手戻りのループとサイクル時間への影響を特定するうえで重要です。修正頻度が高い場合、データ品質や要件の変化に問題がある可能性があり、プロセス改善の重要な対象になります。

入手先

SAPの変更文書テーブル(CDHDRおよびCDPOS)に、EBANテーブルへの変更として明示的に記録されます。追跡対象の項目を変更するたびに、エントリが作成されます。

取得

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

イベントタイプ explicit
購買依頼を取り下げ
元の依頼者が、購買依頼の処理が完了する前にキャンセルまたは削除したときに発生します。通常は、購買依頼項目に削除フラグを設定する明示的な操作です。
重要な理由

取り下げを追跡することで、需要の変動やキャンセル理由を把握できます。これは購買依頼の終端状態であり、それ以降の処理を停止します。

入手先

EBANテーブルの購買依頼項目について、削除インジケーター(LOEKZ)が設定された時点で明示的に記録されます。この変更はCDHDR/CDPOSに記録されます。

取得

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

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

これは、承認サイクル時間のKPI計測を開始する重要なマイルストーンです。作成から提出までの時間を分析すると、購買依頼の準備段階における遅延を明らかにできます。

入手先

EBANテーブルに関する変更文書(CDHDR/CDPOS)から推定します。具体的には、リリース戦略項目(例:FRGST)に値が設定された時点、または全体ステータス(PROCSTAT)が承認中を示す状態に変わった時点を確認します。

取得

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

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

抽出ガイド

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

準備はできましたか?

このテンプレートを使ってデータを確実に準備し、調達から支払いまでの申請プロセスにおけるプロセスマイニングの可能性を最大限に引き出してください。今日から効率化に取り組みましょう。

調達から支払いまでの申請遅延を止める:今すぐワークフローを最適化

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

無料トライアルを開始

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