調達から支払いまでの購買依頼データテンプレート
調達から支払いまでの購買依頼データテンプレート
- 詳細な分析に必要な属性
- プロセスの発見に必要な主要アクティビティ
- 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とは異なり、承認ワークフローで判断を下す担当者に絞った情報です。この情報を記録すると、承認プロセスを詳細に分析できます。 この属性を使うと、承認に時間がかかるマネージャーや、購買依頼を頻繁に却下する担当者など、承認時の傾向を分析できます。承認ステップのサイクルタイムやワークフローのボトルネックを分析するダッシュボードの基礎となり、遅延の原因となっている個人やロールを特定できます。 重要な理由 承認ステップで判断を下した担当者を特定し、個人またはロールごとに承認サイクルタイムやボトルネックを詳しく分析できます。 入手先 通常、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 | |||
調達から支払いまでの購買依頼のアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
| 承認ステップの完了 | 承認者が購買依頼を承認し、多段階の承認ワークフローの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 | |||
データ抽出ガイド
ステップ
- 前提条件:必要な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)を使って各アクティビティのデータを収集し、結合して1つのイベントログを作成します。
- プレースホルダーの設定:クエリ内のプレースホルダーを探して置き換えます。抽出期間の日付範囲(
[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に関するシステム設定を確認してください。
- パフォーマンス:購買依頼が数百万件ある大規模システムで長期間のクエリを実行すると、システムのパフォーマンスに影響する場合があります。アクセスが少ない時間帯に実行するか、データを最新の状態に更新した非本番環境で実行してください。
クエリの例 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ビューに対応付けてください。
- 申請、承認のリセット、承認ステップの開始と完了、最終承認、却下に使用する、設定済みのワークフローまたはリリースソースを特定します。クエリでは、ステータスまたはリリースの遷移ごとに1行を持ち、購買依頼番号、明細番号、イベントタイプ、リリースコードまたは承認グループ、承認者、イベント日、イベント時刻、ステータスの各フィールドを含む[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か月分を推奨します。データベースのパフォーマンスとイベント量を確認してから、期間を広げてください。クエリでは作成日とイベント日で絞り込み、購買依頼IDはケースIDとして保持します。
- SAP HANAに接続した承認済みのSQLクライアントでクエリを実行します。クエリの外部にある接続情報、日付パラメーター、会社固有のフィルター、および明示的に記載されたソースとフィールドのプレースホルダーのみを置き換えてください。出力列名はPurchaseRequisitionId、ActivityName、EventTime、UserId、ApproverId、RequisitionType、Department、RequisitionAmount、RequisitionStatusのまま変更しないでください。
- イベントの重複、タイムスタンプの精度、タイムゾーンの扱い、明細単位か伝票単位かを確認します。クエリは伝票単位のケースIDを出力し、内部では明細の情報も含みます。複数の明細で同じアクティビティとタイムスタンプが発生した場合、ProcessMindの設計で重複排除が明示的に必要とされていない限り、行を分けて保持してください。
- 必要なすべてのアクティビティがActivityNameの値として含まれていること、EventTimeに値があり時系列として妥当であること、必須のケースIDがNULLでないことを確認します。同じ日付範囲を対象とするSAPレポートまたは承認済みの業務データ抽出と件数を照合してください。
- 結果をUTF-8のCSVまたはProcessMindがサポートする別の表形式でエクスポートします。ヘッダー行を含め、ISO形式に対応したタイムスタンプを保持し、NULL値は空欄として保存してください。ファイルをアップロードする際は、PurchaseRequisitionIdをケースID、ActivityNameをアクティビティ列、EventTimeをタイムスタンプ列に指定します。
設定
- ケースID: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データベースライセンスまたは管理ツールを利用できることも確認してください。
- セキュリティ:最小権限の原則に従い、ユーザーIDと承認者IDを保護し、購買情報や財務情報の抽出に関する組織の規則を守ってください。
クエリの例 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分で設定できます。