調達から支払いまで:申請プロセス用データテンプレート
調達から支払いまで:申請プロセス用データテンプレート
- 詳細な分析に向けて収集する推奨属性
- プロセスディスカバリーで追跡する主要アクティビティ
- SAP S/4HANAからデータを抽出するためのガイド
調達から支払いまで:購買依頼の属性
| 名前 | 説明 | ||
|---|---|---|---|
| アクティビティ名 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 | |||
調達から支払いまで:購買依頼のアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
| 承認ステップを完了 | 承認者が購買依頼に対して承認操作を行い、多段階承認ワークフローの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 | |||
抽出ガイド
ステップ
- 前提条件:必要なCDSビューにアクセスできる、適切な権限を持つSAP S/4HANAユーザーを用意します。通常は、S_TABU_NAMなどのオブジェクトに対する権限と、データ表示ツールへのアクセスが必要です。
- システムへのアクセス方法を確認:SQLクエリを実行するために、SAP S/4HANAデータベースへ接続する方法を決めます。SAP HANA Studio、ADT(ABAP Development Tools)を備えたEclipse IDE、SAP HANAデータベースクライアント経由で接続できるDBeaverなどのサードパーティ製SQLクライアントが一般的です。
- SQLクエリを確認:提供されたSQLスクリプトを確認します。このスクリプトでは、共通テーブル式(CTE)を使ってアクティビティごとのデータを収集し、それらを結合して統合されたイベントログを作成します。
- プレースホルダーをカスタマイズ:クエリ内のプレースホルダーを見つけて置き換えます。抽出期間の日付範囲(
[YYYY-MM-DD]形式)と、組織に該当する会社コード([Your Company Code])を設定します。 - クエリを実行:カスタマイズしたSQLクエリ全体をSAP S/4HANAデータベースに対して実行します。データ量と指定した日付範囲によっては、実行に時間がかかる場合があります。
- 初期データを確認:クエリの実行が完了したら、出力結果の先頭数行を確認します。PurchaseRequisitionId、ActivityName、EventTimeなどのすべての列に想定どおり値が入り、データ形式が正しいことを確認します。
- データ変換を確認:提供されたクエリは、プロセスマイニングに適した形式でデータを出力するよう設計されています。
CASTとCONCAT関数を使ってデータ型を統一しています。実行後に大きな変換処理を行う必要はありません。 - イベントログをエクスポート:SQLクライアントから結果セット全体をCSVファイルにエクスポートします。文字化けを防ぐため、ファイルのエンコーディングはUTF-8に設定してください。
- アップロードの準備:プロセスマイニングツールにアップロードする前に、CSVファイルに正しいヘッダー(
PurchaseRequisitionId、ActivityName、EventTimeなど)があり、EventTimeの日付と時刻の形式が一貫していて、対象プラットフォームでサポートされていることを確認します。 - ProcessMindにアップロード:完成したCSVファイルをProcessMindプロジェクトにアップロードします。
PurchaseRequisitionIdをケースID、ActivityNameをアクティビティ、EventTimeをタイムスタンプとしてマッピングします。
設定
- 主要CDSビュー:抽出では主に、申請の基本データに
I_PurchaseRequisitionAPI01、変更とステータス更新の追跡にI_ChangeDocumentおよびI_ChangeDocumentItem、購買発注との関連付けにI_PurchaseOrderItemAPI01を使用します。 - 権限:実行ユーザーには、前述のCDSビューへの読み取りアクセス権が必要です。必要なロールと権限については、SAPセキュリティチームにご確認ください。
- 日付範囲のフィルタリング:データ量を抑えるため、申請作成日(
CreationDate)に日付範囲フィルターを適用することが重要です。初回分析では、3~6か月分のデータを推奨します。 - 組織によるフィルタリング:
CompanyCodeでデータを絞り、正しい事業体のプロセスを分析していることを確認します。PurchaseRequisitionTypeで絞り込み、標準品とサービスなど、特定の調達プロセスに焦点を当てることもできます。 - 変更文書の設定:「申請修正」や各種承認ステップなどのアクティビティを取得するには、SAPシステムで該当フィールドの変更文書ログが有効になっている必要があります。イベントが欠落している場合は、テーブルEBANのシステム設定を確認してください。
- パフォーマンス:数百万件の申請を扱う大規模システムでは、長期間を対象にクエリを実行するとシステムパフォーマンスに影響する場合があります。負荷の低い時間帯、または最新データを反映した非本番環境での実行を検討してください。
a サンプルクエリ sql
WITH REQUISITIONS AS (
SELECT
PurchaseRequisition,
PurchaseRequisitionType,
PurReqnDescription,
CreatedByUser,
CreationDate,
CAST(CONCAT(CreationDate, 'T', LPAD(CreationTime, 6, '0')) AS TIMESTAMP) AS CreationTimestamp,
SourceOfSupplyIsAssigned
FROM I_PurchaseRequisitionAPI01
WHERE CreationDate BETWEEN '[YYYY-MM-DD]' AND '[YYYY-MM-DD]'
AND CompanyCode IN ('[Your Company Code]')
),
CHANGE_DOCS AS (
SELECT
ObjectValue AS PurchaseRequisition,
UserName,
CAST(CONCAT(CreationDate, 'T', LPAD(CreationTime, 6, '0')) AS TIMESTAMP) AS ChangeTimestamp,
FieldName,
ValueNew,
ValueOld
FROM I_ChangeDocument AS H
JOIN I_ChangeDocumentItem AS I
ON H.ChangeDocument = I.ChangeDocument
WHERE H.Objectclass = 'EINKBELEG'
AND H.CreationDate BETWEEN '[YYYY-MM-DD]' AND '[YYYY-MM-DD]'
)
-- 1. Requisition Created
SELECT
R.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Created' AS "ActivityName",
R.CreationTimestamp AS "EventTime",
R.CreatedByUser AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM REQUISITIONS AS R
JOIN I_PurchaseRequisitionItemAPI01 AS I
ON R.PurchaseRequisition = I.PurchaseRequisition
UNION ALL
-- 2. Requisition Submitted For Approval & 5. Approval Step Started
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
CASE
WHEN C.ValueOld = ''
THEN 'Requisition Submitted For Approval'
ELSE 'Approval Step Started'
END AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
R.CreatedByUser AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R
ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I
ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueNew != ''
UNION ALL
-- 3. Requisition Amended
SELECT DISTINCT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Amended' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName IN ('MENGE', 'PREIS', 'MATNR', 'LIFNR', 'INFNR')
AND C.ChangeTimestamp > R.CreationTimestamp
UNION ALL
-- 4. Approval Reset
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Approval Reset' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueOld != '' AND C.ValueNew = ''
UNION ALL
-- 6. Approval Step Completed
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Approval Step Completed' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
NULL AS "UserId",
C.UserName AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueNew IN ('1', '2', '3', '4', '5', '6', '7') -- Adjust release codes as per your config
UNION ALL
-- 7. Requisition Approved
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Approved' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
NULL AS "UserId",
C.UserName AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGKE' AND C.ValueNew = '2' -- Final release indicator '2' is common for approved
UNION ALL
-- 8. Requisition Rejected
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Rejected' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
NULL AS "UserId",
C.UserName AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueNew = 'B' -- 'B' for Blocked/Rejected is a common setting
UNION ALL
-- 9. Requisition Withdrawn
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Withdrawn' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'LOEKZ' AND C.ValueNew = 'X'
UNION ALL
-- 10. Source of Supply Assigned
SELECT DISTINCT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Source of Supply Assigned' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName IN ('LIFNR', 'INFNR') AND C.ValueNew != ''
AND C.ChangeTimestamp > R.CreationTimestamp
UNION ALL
-- 11. Purchase Order Created
SELECT DISTINCT
I.PurchaseRequisition AS "PurchaseRequisitionId",
'Purchase Order Created' AS "ActivityName",
CAST(CONCAT(H.PurchaseOrderDate, 'T', LPAD(H.CreationTime, 6, '0')) AS TIMESTAMP) AS "EventTime",
H.CreatedByUser AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.OrderPriceUnit * I.OrderQuantity AS "RequisitionAmount",
'PO Created' AS "RequisitionStatus"
FROM I_PurchaseOrderItemAPI01 AS I
JOIN I_PurchaseOrderAPI01 AS H
ON I.PurchaseOrder = H.PurchaseOrder
JOIN REQUISITIONS AS R
ON I.PurchaseRequisition = R.PurchaseRequisition
WHERE I.PurchaseRequisition IS NOT NULL AND I.PurchaseRequisition != ''
UNION ALL
-- 12. Requisition Closed
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Closed' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'EBAKZ' AND C.ValueNew = 'X' ステップ
- EBANおよびEBKNを含むSAP HANAスキーマへの直接読み取りアクセスが利用できることを確認し、購買依頼の変更、リリース処理、ソース割り当て、発注書参照、クローズに使用される変更文書オブジェクトと購買伝票オブジェクトをシステム内で特定します。これらのオブジェクトやフィールドはリリースや設定によって異なる場合があるため、クエリ内の角括弧で囲まれた各プレースホルダーを、システムに対応するオブジェクトまたはフィールドに置き換えます。
- SAP GUIでトランザクションSE16Hまたは承認済みのデータベース管理ツールを使用してEBANとEBKNを確認し、購買依頼のキー項目と、日付、時刻、ユーザー、ステータス、削除、リリース、勘定設定、購買伝票参照に関する利用可能なフィールドを確認します。SE11またはSAPデータディクショナリでフィールド定義を確認します。テスト中に本番データを公開しないでください。
- 購買依頼の変更と承認変更に使用される設定済みの変更文書ソースを特定します。クエリでは、購買依頼番号、明細番号、変更フィールド、旧値、新値、変更日、変更時刻、ユーザーを持つ、[Your requisition change document source]という正規化された変更ソースを想定しています。実行前に、このソースをシステム内の関連するSAP変更文書テーブルまたはCDSビューにマッピングします。
- 提出、承認リセット、承認ステップ開始、承認ステップ完了、最終承認、却下に使用される設定済みのワークフローまたはリリースソースを特定します。クエリでは、購買依頼番号、明細番号、イベント種別、リリースコードまたは承認グループ、承認者、イベント日、イベント時刻、ステータスを持つ[Your requisition approval event source]を想定しています。S/4HANAの設定で使用されるリリースまたはワークフローの永続化先にマッピングします。
- ソース割り当て、発注書参照、クローズのソースを特定します。クエリでは、[Your requisition source assignment source]、[Your requisition purchase order reference source]、[Your requisition closure source]を想定しています。これらのプレースホルダーを、システム内の承認済みテーブルまたはビューにマッピングします。発注書の作成は、関連のない購買アクティビティから推測せず、発注明細から購買依頼明細への明示的な参照で表現する必要があります。
- [Start date]と[End date]を使用して抽出期間を設定します。初回実行では、3~6か月の期間を推奨します。データベースの性能とイベント量を検証してから、より広い期間を使用します。クエリでは作成日とイベント日をフィルタリングし、購買依頼識別子をケース識別子として保持します。
- SAP HANAに接続した承認済みのSQLクライアントでクエリを実行します。接続情報以外のクエリ外の設定、日付パラメーター、会社固有のフィルター、明示的に文書化されたソースおよびフィールドのプレースホルダーだけを置き換えます。出力列名はPurchaseRequisitionId、ActivityName、EventTime、UserId、ApproverId、RequisitionType、Department、RequisitionAmount、RequisitionStatusとして正確に保持します。
- 重複イベント、タイムスタンプの精度、タイムゾーンの扱い、明細レベルと伝票レベルの粒度を確認します。クエリは伝票レベルのケース識別子を出力し、内部に明細コンテキストを含めます。複数の明細が同じアクティビティと日時を生成する場合、ProcessMindの設計で重複排除が明示的に必要でない限り、行を分けて保持します。
- 必要なすべてのアクティビティがActivityNameの値として現れること、EventTimeが入力され時系列として妥当であること、必要なケース識別子がNULLでないことを検証します。同じ日付範囲について、SAPレポートまたは承認済みの業務抽出結果と件数を照合します。
- 結果をUTF-8 CSVまたはProcessMindがサポートする別の表形式でエクスポートします。ヘッダー行を含め、ISO互換のタイムスタンプを保持し、NULLは空の値として保持します。PurchaseRequisitionIdをケース識別子、ActivityNameをアクティビティ列、EventTimeをタイムスタンプ列としてファイルをアップロードします。
設定
- ケース識別子:EBANの購買申請伝票番号をPurchaseRequisitionIdとして使用します。プロセスが明細レベルで設定されている場合は、申請番号と明細番号など、文書化された複合キーを使用し、すべてのイベントに同じキーを設定してください。
- 主要ソース:申請明細データにはEBANを使用します。勘定設定と部門または原価センタの補足情報にはEBKNを使用します。実行前に、SAPデータディクショナリで正確なフィールド名とデータ型を確認してください。
- イベントソース:変更、承認、ソース割り当て、購買発注参照、完了の各ソースには、意図的に具体的なプレースホルダーを使用しています。これらのソースは、S/4HANAのリリース、ワークフロー設計、リリース手順、有効化されたビジネス機能、顧客拡張によって異なるためです。
- 日付範囲:まず3~6か月を対象にします。利用できる場合は、インデックスまたはパーティションプルーニングの対象となる日付フィールドで範囲を限定してください。増分ロードでは、後から到着する変更を取得できるよう抽出期間を十分に重複させ、その後、ケース、アクティビティ、タイムスタンプ、明細、ソースイベントキーを使って重複排除します。
- 業務フィルター:[Company code filter]、[Document type filter]、[Purchasing group filter]、[Plant filter]は、該当フィールドが利用でき、その業務上の意味を確認できる場合にのみ設定してください。完全なライフサイクルの取得が目的の場合は、ステータスで絞り込まないでください。
- ステータスマッピング:「承認中」、「最終承認済み」、「却下」、「リセット」、「リリースコード待ち」、「完了」に対応する値は、対象システムのリリース戦略またはワークフロー設定に従って設定してください。SAPクライアント間でステータスコードが共通しているとは限りません。
- 修正のマッピング:数量、価格、品目、納入日、勘定設定など、プロセス上の主要フィールドとして定義した変更を含めます。クエリには一覧にある主要フィールドに対する明示的な条件が含まれており、ソースから変更フィールド名を取得できる必要があります。
- タイムスタンプの処理:イベント日とイベント時刻をデータベースのタイムゾーンで結合し、UTCへの変換がある場合は記録します。ソースに日付しかない場合は、より正確なタイムスタンプが存在しないときに限り午前0時を使用し、その制約を記録してください。
- パフォーマンス:初回抽出では日付と業務範囲を限定し、必要な列だけを選択します。大規模な変更履歴やワークフロー履歴への無制限の結合は避け、HANAの実行計画を確認してください。繰り返し抽出が必要な場合は、正規化したイベントソースをマテリアライズまたはステージングしてください。
- 権限と前提条件:EBAN、EBKN、設定済みの変更およびワークフローソース、ソース割り当てデータ、購買発注参照データ、完了データに対する読み取り権限を取得します。直接データベースアクセスが承認されていること、必要な購買およびワークフロー機能が有効であること、必要なSAP HANAデータベースライセンスまたは管理ツールが利用できることを確認してください。
- セキュリティ:最小権限でアクセスし、ユーザーと承認者の識別子を保護し、購買情報と財務情報の抽出に関する組織のルールに従ってください。
a サンプルクエリ sql
WITH
base_items AS (
SELECT
eban.[Purchase requisition number field] AS PurchaseRequisitionId,
eban.[Purchase requisition item field] AS RequisitionItem,
eban.[Creation date field] AS CreationDate,
eban.[Creation time field] AS CreationTime,
eban.[Created by field] AS CreatedBy,
eban.[Requisition type field] AS RequisitionType,
eban.[Company code field] AS CompanyCode,
eban.[Plant field] AS Plant,
eban.[Purchasing group field] AS PurchasingGroup,
eban.[Quantity field] AS Quantity,
eban.[Net price field] AS NetPrice,
eban.[Currency field] AS Currency,
eban.[Material field] AS Material,
eban.[Deletion indicator field] AS DeletionIndicator,
eban.[Overall release status field] AS OverallReleaseStatus,
eban.[Item processing status field] AS ItemProcessingStatus,
ebkn.[Cost center field] AS CostCenter,
ebkn.[Department field] AS Department,
CAST(eban.[Quantity field] * eban.[Net price field] AS DECIMAL(19,4)) AS RequisitionAmount
FROM [Your SAP schema].EBAN eban
LEFT JOIN [Your SAP schema].EBKN ebkn
ON ebkn.[Purchase requisition number field] = eban.[Purchase requisition number field]
AND ebkn.[Purchase requisition item field] = eban.[Purchase requisition item field]
WHERE eban.[Creation date field] BETWEEN '[Start date]' AND '[End date]'
AND ('[Company code filter]' = '' OR eban.[Company code field] = '[Company code filter]')
AND ('[Document type filter]' = '' OR eban.[Requisition type field] = '[Document type filter]')
AND ('[Purchasing group filter]' = '' OR eban.[Purchasing group field] = '[Purchasing group filter]')
AND ('[Plant filter]' = '' OR eban.[Plant field] = '[Plant filter]')
),
created_events AS (
SELECT
PurchaseRequisitionId,
'Requisition Created' AS ActivityName,
TO_TIMESTAMP(CAST(CreationDate AS NVARCHAR(8)) || LPAD(COALESCE(CAST(CreationTime AS NVARCHAR(6)), '000000'), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CreatedBy AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
RequisitionType,
Department,
RequisitionAmount,
'Created' AS RequisitionStatus
FROM base_items
),
submitted_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Submitted For Approval' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
a.[Requester or submitter field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'SUBMITTED'
OR a.[Status field] = 'In Approval'
),
amended_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Amended' AS ActivityName,
TO_TIMESTAMP(CAST(c.[Change date field] AS NVARCHAR(8)) || LPAD(CAST(c.[Change time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
c.[Change user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
'Amended' AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition change document source] c
ON c.[Purchase requisition number field] = b.PurchaseRequisitionId
AND c.[Purchase requisition item field] = b.RequisitionItem
WHERE c.[Changed field field] IN ('QUANTITY', 'PRICE', 'MATERIAL', 'DELIVERY_DATE', 'ACCOUNT_ASSIGNMENT')
),
reset_events AS (
SELECT
b.PurchaseRequisitionId,
'Approval Reset' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
a.[Event user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'RESET'
OR a.[Status field] = 'Approval Reset'
),
step_started_events AS (
SELECT
b.PurchaseRequisitionId,
'Approval Step Started' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserId,
a.[Approver or approval group field] AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'STEP_STARTED'
OR a.[Status field] = 'Pending Release'
),
step_completed_events AS (
SELECT
b.PurchaseRequisitionId,
'Approval Step Completed' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserId,
a.[Approver or approval group field] AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'STEP_COMPLETED'
OR a.[Status field] = 'Step Approved'
),
approved_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Approved' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserId,
a.[Approver or approval group field] AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'FINAL_APPROVED'
OR a.[Status field] = 'Approved'
),
rejected_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Rejected' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserId,
a.[Approver or approval group field] AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'REJECTED'
OR a.[Status field] = 'Rejected'
),
withdrawn_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Withdrawn' AS ActivityName,
TO_TIMESTAMP(CAST(c.[Change date field] AS NVARCHAR(8)) || LPAD(CAST(c.[Change time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
c.[Change user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
'Withdrawn' AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition change document source] c
ON c.[Purchase requisition number field] = b.PurchaseRequisitionId
AND c.[Purchase requisition item field] = b.RequisitionItem
WHERE c.[Changed field field] = 'DELETION_INDICATOR'
AND c.[New value field] IS NOT NULL
AND c.[New value field] <> ''
),
source_assigned_events AS (
SELECT
b.PurchaseRequisitionId,
'Source of Supply Assigned' AS ActivityName,
TO_TIMESTAMP(CAST(s.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(s.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
s.[Event user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
'Source Assigned' AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition source assignment source] s
ON s.[Purchase requisition number field] = b.PurchaseRequisitionId
AND s.[Purchase requisition item field] = b.RequisitionItem
WHERE s.[Source identifier field] IS NOT NULL
AND s.[Source identifier field] <> ''
),
purchase_order_events AS (
SELECT
b.PurchaseRequisitionId,
'Purchase Order Created' AS ActivityName,
TO_TIMESTAMP(CAST(p.[Purchase order creation date field] AS NVARCHAR(8)) || LPAD(CAST(p.[Purchase order creation time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
p.[Purchase order creator field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
'Purchase Order Created' AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition purchase order reference source] p
ON p.[Purchase requisition number field] = b.PurchaseRequisitionId
AND p.[Purchase requisition item field] = b.RequisitionItem
WHERE p.[Purchase order number field] IS NOT NULL
AND p.[Purchase order number field] <> ''
),
closed_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Closed' AS ActivityName,
TO_TIMESTAMP(CAST(cl.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(cl.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
cl.[Event user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
cl.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition closure source] cl
ON cl.[Purchase requisition number field] = b.PurchaseRequisitionId
AND cl.[Purchase requisition item field] = b.RequisitionItem
WHERE cl.[Event type field] = 'CLOSED'
OR cl.[Status field] = 'Closed'
)
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM created_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM submitted_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM amended_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM reset_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM step_started_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM step_completed_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM approved_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM rejected_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM withdrawn_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM source_assigned_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM purchase_order_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM closed_events
ORDER BY PurchaseRequisitionId, EventTime, ActivityName; 準備はできましたか?
このテンプレートを使ってデータを確実に準備し、調達から支払いまでの申請プロセスにおけるプロセスマイニングの可能性を最大限に引き出してください。今日から効率化に取り組みましょう。
調達から支払いまでの申請遅延を止める:今すぐワークフローを最適化
プロセスを効率化し、リードタイムを短縮して、サイクルタイムを30%削減します。
クレジットカードは不要です。5分で設定できます。