> 継続的なプロセス改善 > 調達から支払いまで：購買依頼 > SAP Ariba > データテンプレート

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

SAP Ariba

調達から支払いまで：購買依頼の属性 (19) 調達から支払いまで：購買依頼のアクティビティ (13) 抽出ガイド (2)

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

この詳細なデータテンプレートは、調達から支払いまでの購買依頼プロセスを分析するために必要な情報を効率的に収集し、構造化できるよう設計されています。プロセスパフォーマンスを詳しく分析できるイベントログに必要な属性とアクティビティを示しています。さらに、ソースシステムからデータを抽出するための具体的な手順も確認できるため、プロセスマイニングをスムーズに始められます。

詳細な分析に必要な推奨属性
追跡すべき主要なプロセスアクティビティとマイルストーン
システムからデータを抽出するための詳細な手順

イベントログを初めて扱いますか。学ぶプロセスマイニングのイベントログを作成する方法.

テンプレートをダウンロード

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

重要な情報を漏れなく把握するため、調達から支払いまで：購買依頼プロセスを詳細に分析する際に、イベントログに含めることを推奨するデータ項目です。

3 必須 8 推奨 8 任意

	名前	説明
	アクティビティ名 ActivityName	購買依頼のライフサイクルにおいて、ある時点で発生した具体的な業務イベントの名前です。
説明アクティビティ名は、「購買依頼の作成」「承認ステップの承認」「購買依頼のクローズ」など、購買依頼プロセスにおける1つのステップまたはマイルストーンを示します。通常は、SAP Aribaに記録されたイベントログ、ステータス変更、特定のユーザーアクションから取得します。この属性は、アクティビティの流れを視覚的に表すプロセスマップの作成に欠かせません。アクティビティの順序と頻度を分析することで、一般的なプロセス経路、ボトルネック、標準手順からの逸脱、手戻りが発生する箇所を特定できます。あらゆるプロセスマイニング分析の基盤となるデータです。重要な理由プロセスの各ステップを定義し、ボトルネックや逸脱を含む購買依頼ワークフローを可視化・分析できます。入手先 SAP Ariba内のイベントログ、監査証跡、ステータス変更記録から取得します。購買依頼のヘッダーテーブルや明細テーブルに関連付けられていることが一般的です。例購買依頼の提出承認ステップの承認購買依頼の変更発注書の作成
	イベントタイムスタンプ EventTimestamp	アクティビティが発生した正確な日時であり、イベントの順序付けに使う主要なタイムスタンプです。
説明イベントタイムスタンプは、アクティビティが実行された正確な時点を記録します。この精度の高いデータは、ケースごとにイベントを正しく並べ、プロセス内の各ステップ間の所要時間を計算するために欠かせません。分析では、サイクル時間、待機時間、処理時間など、時間に関するすべての計算の基盤になります。「購買依頼の承認サイクル時間」や「承認経路のボトルネック分析」など、パフォーマンスを分析するダッシュボードにも使われます。この項目の正確性は、すべてのパフォーマンス指標の信頼性に直接影響します。重要な理由イベントの時系列を示し、サイクル時間やボトルネックなど、パフォーマンスと所要時間に関するすべての計算の基盤になります。入手先通常は、SAP Aribaの監査証跡またはトランザクションログテーブルにあるアクティビティ記録やステータス変更記録とともに保存されています。例 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:05:00Z
	購買依頼ID PurchaseRequisitionId	購買依頼書を一意に識別する値であり、プロセスの主要なケース識別子として使われます。
説明購買依頼IDは、単一の物品またはサービスの依頼に関連するすべてのアクティビティを結び付ける中心的なキーです。SAP Aribaで作成された各購買依頼には一意のIDが割り当てられ、作成、提出から最終承認、拒否、クローズまで、ライフサイクル全体を通じて同じIDが使われます。プロセスマイニング分析では、この属性がケースを関連付ける基盤になります。各購買依頼の開始から完了までの流れ全体を再構成し、サイクル時間を正確に計算し、プロセスのバリエーションを特定し、手戻りのループを分析できます。この識別子がなければ、異なる購買依頼に属するイベントを区別できません。重要な理由関連するすべてのアクティビティを結び付ける必須のケース識別子です。一意の依頼ごとに、購買依頼プロセス全体を分析できます。入手先 SAP Aribaのデータ構造にある主要な購買依頼ヘッダーテーブルの主キー項目です。例 PR-102345PR-102346PR-102347
	イベントユーザー EventUser	依頼者や承認者など、アクティビティを実行した担当者のユーザーIDまたは名前です。
説明イベントユーザー属性は、特定のプロセスステップを実行した担当者を示します。購買依頼を提出した従業員、承認したマネージャー、処理を担当した調達担当者などが該当します。この属性は、業務量の分析、パフォーマンスの比較、トレーニング機会の特定に欠かせません。ユーザーごとの承認時間を分析できるため、「承認者の業務量とパフォーマンス」ダッシュボードにも使われます。遅延や逸脱の原因を特定の担当者やチームまで追跡する際にも役立ちます。重要な理由業務量の分布、ユーザーのパフォーマンス、リソース配分を分析できます。特定のユーザーやチームが原因となっているボトルネックの特定にも役立ちます。入手先 SAP Aribaのドキュメントを確認してください。通常は監査証跡または履歴テーブルに保存され、ユーザーマスターデータに関連付けられています。例 john.doejane.smithmanager123
	依頼者の所属部門 RequesterDepartment	購買依頼を作成した従業員の所属する業務部門またはコストセンターです。
説明この属性は、どの組織の部門が依頼を開始したかを示し、業務上の背景を把握できます。通常は依頼者のユーザープロファイルから取得するか、購買依頼フォームに直接入力します。分析では、絞り込みや比較に使える重要な切り口です。「購買依頼の承認サイクル時間」や「購買依頼拒否率分析」など、ほぼすべてのダッシュボードで指標を部門別に分解できます。部門ごとのサイクル時間、変更率、コンプライアンスに反する依頼の割合を比較し、対象を絞った改善につなげられます。重要な理由組織内の異なる部門間でプロセスのパフォーマンスを分類・比較し、部門固有の問題や優れた取り組みを明らかにできます。入手先 SAP Aribaのドキュメントを確認してください。通常は購買依頼のヘッダーデータで確認でき、依頼者のユーザープロファイルから参照されることが多い項目です。例マーケティングITオペレーション財務研究開発
	却下理由 RejectionReason	購買依頼または承認ステップが却下された際に、承認者が提示する理由です。
説明購買依頼が却下されると、承認者は通常、理由を入力します。自由記述の場合もあれば、あらかじめ定義されたリストから選択する場合もあります。この属性は、その重要なフィードバックを記録します。このデータは、「Requisition Rejection Rate Analysis」ダッシュボードの基盤です。よくある却下理由を分析することで、コードの誤り、説明不足、予算上の問題など、プロセス失敗の根本原因を特定できます。分析結果を依頼者向けのトレーニング改善や初回申請の品質向上に役立てることで、手戻りを減らせます。重要な理由購買依頼が失敗する理由を直接把握できるため、根本原因を分析し、手戻りを減らして初回正解率を高められます。入手先 SAP Aribaのドキュメントを参照してください。この情報は通常、却下イベントに関連付けられたコメントまたは履歴セクションに記録されます。例誤ったGL勘定予算超過根拠の説明不足重複申請
	品目カテゴリ ItemCategory	「ITハードウェア」「オフィス用品」「専門サービス」など、依頼された物品またはサービスの分類です。
説明 Item Categoryは、購入対象の詳細を示します。この分類により、支出パターンを把握し、カテゴリーに応じた調達戦略やポリシーを適用できます。プロセスマイニングでは、この属性は「Requisition Amendment Analysis」ダッシュボードに欠かせません。特定のカテゴリーの商品で変更が発生しやすいかどうかを明らかにし、仕様の不明確さや価格変動の大きさを示すことができます。また、購入タイプごとに承認時間などのプロセスパフォーマンスを比較し、特定のカテゴリーで処理が滞りやすいかどうかを確認できます。重要な理由購入する商品またはサービスのタイプに基づく分析を可能にし、カテゴリー固有のボトルネックやコンプライアンス上の問題を特定できます。入手先 SAP Aribaのドキュメントを参照してください。この情報は通常、購買依頼の明細レベルで確認できます。例 ITハードウェアコンサルティングサービス事務用品マーケティング資料
	承認ワークフロー経路 ApprovalWorkflowPath	購買依頼が従うことを想定した、あらかじめ定義された承認ステップの順序です。
説明この属性は、金額、Item Category、部門などの特性に基づいて、購買依頼が従うべき標準的なプロセスバリアントまたは承認マトリクスを定義します。いわゆる「to-be」または「happy path」のプロセスを表します。これは適合性チェックの基盤となり、「Requisition Compliance Overview」ダッシュボードで使用されます。実際のアクティビティの順序を想定されるApproval Workflow Pathと比較することで、ポリシー違反、権限のない承認ステップ、統制のスキップを自動的に検出できます。内部監査とリスク管理に欠かせない情報です。重要な理由従うべき標準プロセスを定義し、適合性チェックによって逸脱やポリシー違反を自動的に検出できます。入手先 SAP Aribaのドキュメントを参照してください。承認マトリクスの設定、または購買依頼上の特定の項目から導出できる場合があります。例標準IT：10,000ドル超マーケティングサービス：5,000ドル未満CAPEX：100,000ドル超
	緊急度レベル UrgencyLevel	購買依頼の優先度を示す項目です。「Normal」「Urgent」「Critical」などの値があります。
説明 Urgency Levelは、多くの場合、優先度フラグとして表され、迅速な処理が必要な業務上の要請を示します。通常は依頼者が設定し、緊急性の高い要件に速やかに対応できるようにします。この属性は、「Urgent Requisition Process Monitor」ダッシュボードと「Urgent Requisition Proc. Time」KPIの主要な基準です。緊急の購買依頼と通常の購買依頼のサイクルタイムを直接比較し、優先処理が有効かどうかを検証できます。緊急依頼における逸脱や遅延の分析は、業務継続性を確保するうえで重要なユースケースです。重要な理由分析の優先順位付けを可能にし、優先度の高い購買依頼がより速く処理されているかを監視できます。これにより、重要な業務上の要件に確実に対応できます。入手先 SAP Aribaのドキュメントを参照してください。通常は、購買依頼の作成フォームで選択できる項目です。例高中低
	購買依頼の合計金額 TotalRequisitionAmount	購買依頼の金銭的な合計額です。
説明この属性は、依頼全体の金額を記録します。購買依頼を分類し、優先順位を付けるための重要な業務情報です。この金額とプロセス指標を組み合わせて分析すると、重要な傾向を明らかにできます。たとえば、高額な購買依頼では、より厳格な承認経路を通るため、サイクル時間が長くなる場合があります。プロセスの非効率が財務に与える影響を把握し、金額帯ごとに購買依頼を分類して比較するために欠かせない属性です。重要な理由財務面の背景情報を提供し、購買依頼の金額が承認時間やワークフローの複雑さなど、プロセスの動きに与える影響を分析できます。入手先 SAP Aribaのドキュメントを確認してください。購買依頼ヘッダーにある標準項目です。例 1500.0025000.5099.95
	購買依頼状況 RequisitionStatus	購買依頼のライフサイクルにおける現在の状態です。
説明この属性は、「Composing」「Submitted」「Approved」「Denied」「Closed」など、購買依頼のリアルタイムのステータスを示します。データ抽出時点で、各ケースがプロセスのどの位置にあるかを把握できます。プロセスマイニングでは過去のフローを再構成しますが、この属性は業務の監視に欠かせません。「Live Requisition Status Tracker」の主要なデータ項目として、管理者は現在の処理量を確認し、停滞している購買依頼や処理期間が長期化している購買依頼を特定できます。進行中の購買依頼パイプラインを即時に把握し、対応につなげられます。重要な理由購買依頼パイプラインをリアルタイムで監視し、問題化する前に停滞中または長期化している依頼を特定して対応できます。入手先 SAP Aribaのドキュメントを参照してください。購買依頼ヘッダーにある標準的なステータス項目です。例承認済み提出済み否認済み承認中
	ソースシステム SourceSystem	データを抽出した記録元のシステムです。
説明この属性は、プロセスデータの取得元を示します。この画面では一貫して「SAP Ariba」になりますが、複数のシステムからデータを統合する場合は、データの系譜を追跡し、問題を調査するために欠かせません。分析では、データの取得元を確認したり、異なるシステムにまたがるプロセスを絞り込んだり比較したりするために使います。データソースを明確にし、信頼性を確保することで、関係者の理解と合意形成を支えます。重要な理由データの取得元を示します。データガバナンス、問題の調査、分析の前提を正しく理解するために欠かせません。入手先通常は、データの抽出・変換処理の際にデータセットの取得元を示す静的な値として追加します。例 SAP AribaSAP_ARIBA_P2PAribaCloud
	依頼者名 RequesterName	購買依頼を開始した従業員の名前です。
説明このケースレベルの属性は、購買依頼の作成者を識別します。依頼の発生元と担当者を把握するための情報です。分析では、この属性でプロセスを絞り込み、依頼者ごとの行動を分析します。たとえば、「Requisition Amendment Analysis」や「Requisition Rejection Rate Analysis」ダッシュボードでは、変更や却下の割合が高く、追加トレーニングが必要な担当者を特定するために使用します。フィードバックや改善施策を個人に合わせて実施できます。重要な理由依頼の作成者を特定し、依頼者ごとにプロセスの行動と品質を分析できます。入手先 SAP Aribaのドキュメントを参照してください。購買依頼ヘッダーにある標準項目で、通常は「Created By」または「Requester」と表示されます。例 Alice WilliamsBob MillerCharles Brown
	修正済みかどうか IsAmended	初回提出後に、購買依頼が少なくとも1回変更されたかどうかを示すブール型フラグです。
説明この計算属性は、「Requisition Amended」アクティビティを少なくとも1回実行したケースを特定します。ライフサイクル中に変更が必要になった購買依頼を簡単にフラグ付けできます。このフラグは「Requisition Amendment Rate」KPIの算出に使用します。フラグがtrueのケース数を数えることで、手戻りの発生頻度を簡単に測定できます。また、「Requester Name」や「Item Category」などの他の属性と関連付け、根本原因を調査できます。重要な理由変更率KPIの算出を簡単にし、手戻りを定量化するとともに、初期仕様をより明確にすべき領域を特定できます。入手先ケースに1つ以上の「Requisition Amended」アクティビティが含まれている場合はtrue、それ以外の場合はfalseとして算出します。例 truefalse
	最終データ更新日時 LastDataUpdate	このレコードのデータがソースシステムから最後に更新された時点を示すタイムスタンプです。
説明この属性は、特定のイベントについて直近のデータ抽出または更新が行われた日時を示します。分析対象データの鮮度を確認できるため、進行中のプロセスを監視する際に特に重要です。分析担当者は、この情報から生成された分析結果がどの程度新しいかを把握できます。「購買依頼のリアルタイムステータス追跡」などのダッシュボードでは、表示情報がどの時点まで更新されているかを利用者に伝えるために欠かせません。データの適時性に関する期待値の調整にも役立ちます。重要な理由データの鮮度を示します。プロセスマイニングの分析結果がどの時点の状況を反映しているか、その適時性と関連性を理解するために欠かせません。入手先通常は、データの取り込み処理中に各レコードへ生成・追加されるタイムスタンプです。例 2024-05-21T02:00:00Z2024-05-22T02:00:00Z
	手戻りかどうか IsRework	却下や複数回の変更など、購買依頼に手戻りが発生したかどうかを示すブール型フラグです。
説明この計算属性は、「IsAmended」より広い範囲で非効率性を測定します。通常は、「Approval Step Rejected」イベントが1つ以上あるケース、または「Requisition Amended」イベントが複数あるケースを、重大な手戻りループが発生したケースとしてフラグ付けします。このフラグは「Requisition Rework Rate」KPIの算出に使用します。プロセスの失敗に伴う見えにくいコストや遅延を定量化できます。手戻りとしてマークされたケースを分析することで、特定の承認者、部門、依頼タイプがプロセスの停滞につながるパターンを明らかにできます。重要な理由却下など、プロセス上の摩擦が大きいケースを特定し、非効率性や遅延の原因を重点的に分析できます。入手先ケースに却下アクティビティが含まれている場合、または変更アクティビティが2つ以上ある場合はtrueとして算出します。例 truefalse
	承認者名 ApproverName	ワークフロー内の特定のステップを承認する担当ユーザーの名前です。
説明この属性は、承認アクティビティを担当する特定の管理者または関係者を識別します。一般的な「Event User」とは異なり、承認タスクに特化した項目です。「Approver Workload and Performance」ダッシュボードの主要な属性です。承認者ごとの処理件数と平均承認時間を追跡できます。個別のボトルネックの特定、業務量の平準化、目標に対するパフォーマンスの評価に役立ちます。重要な理由承認を担当する個人を特定し、承認者の業務量の平準化とパフォーマンスを詳細に分析できます。入手先 SAP Aribaのドキュメントを参照してください。この情報は、購買依頼に関連付けられた承認フローデータに保存されます。例 Sarah JonesDavid ChenMaria Garcia
	発注書ID PurchaseOrderId	承認済みの購買依頼から作成されたPurchase Orderの識別子です。
説明この属性は、購買依頼と後続のドキュメントであるPurchase Order（PO）を関連付けます。値が存在することは、依頼が正常に注文へ変換されたことを示します。購買依頼の段階を超えたエンドツーエンドのプロセス分析に欠かせません。購買依頼の作成イベントとPOの作成イベントを関連付け、「Requisition to PO Lead Time」KPIを算出するために使用します。調達サイクルの前半を含む全体像を把握できます。重要な理由購買依頼を後続の購買注文に関連付け、購買依頼からPOまでのエンドツーエンドのサイクルタイムを測定できます。入手先 SAP Aribaのドキュメントを参照してください。通常は、POの生成後に購買依頼の明細データへ保存されます。例 PO-4500012345PO-4500012346PO-4500012347
	自動処理かどうか IsAutomated	アクティビティがシステムによって実行されたか、人が実行したかを示すブール型フラグです。
説明この属性により、自動承認やシステムによるステータス変更などの自動化されたシステムイベントと、ユーザーが手動で実行したアクティビティを区別できます。プロセスの自動化レベルを把握するうえで重要です。分析では、人による作業量を正確に測定し、さらなる自動化の機会を特定できます。たとえば、手動アクティビティに絞り込むことで、ユーザー中心の処理時間を正確に算出できます。また、プロセス内の自動化ルールが想定どおり機能しているかどうかの検証にも役立ちます。重要な理由人による操作とシステムによる操作を区別し、自動化率の測定や新たな自動化機会の特定に役立ちます。入手先通常は、「Event User」がシステムユーザーまたはバッチユーザーのIDに該当するかどうかを確認して導出します。例 truefalse

必須推奨任意

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

正確なプロセス発見とボトルネック特定のため、イベントログに記録する主要なプロセス手順とマイルストーンです。

6 推奨 7 任意

	アクティビティ	説明
	発注書の作成	承認済みの購買依頼が発注書へ正常に変換されたことを示します。購買依頼を参照する発注書が作成された時点で記録されます。
重要な理由購買依頼プロセスにおける主な成功結果です。「購買依頼から発注書までのリードタイム」KPIを測定するうえで欠かせません。入手先明示的なイベントです。元の購買依頼IDへの直接リンクまたは参照を含む発注書の作成時刻を使用します。取得発注書ヘッダーテーブルから購買依頼に関連付けられた発注書を見つけ、その作成時刻を使用します。イベントタイプ explicit
	購買依頼のクローズ	発注や受領など、関連するすべての処理が完了した後に購買依頼を管理上最終的にクローズすることです。最終的な「クローズ済み」へのステータス変更によって記録されます。
重要な理由購買依頼ライフサイクル全体の明確な終了を示します。発注書の作成からクローズまでの時間を分析することで、後続の受領や請求プロセスにおけるボトルネックを明らかにできます。入手先購買依頼のステータスが「クローズ済み」に変わったことを記録する、Aribaの文書履歴から推定します。取得購買依頼のステータスフィールドが「クローズ済み」に変わった時点のタイムスタンプを特定します。イベントタイプ inferred
	購買依頼の作成	ユーザーが購買依頼書を最初に作成したことを示します。購買依頼が「作成中」または下書きの状態で初めて保存された時点で記録されます。
重要な理由購買依頼ライフサイクルの開始点です。作成から提出までの時間を分析することで、ユーザーの処理効率を測定し、トレーニングの必要性を特定できます。入手先 SAP Aribaで購買依頼オブジェクトが作成された時点のタイムスタンプから取得します。購買依頼書のヘッダーデータに記録され、明示的な作成イベントを示します。取得購買依頼書のヘッダーテーブルにある「CreateTime」または同等のタイムスタンプを使用します。イベントタイプ explicit
	購買依頼の承認	購買依頼がワークフローのすべてのステップを正常に通過した後、最終承認されたことを示します。「承認済み」へのステータス変更によって記録されます。
重要な理由承認フェーズの終了を示す重要なマイルストーンです。「購買依頼の平均承認時間」を測定する終点であり、発注書を作成できる状態になったことを示します。入手先購買依頼の最終ステータスが「承認済み」に変わったことを記録する、Aribaの文書履歴から推定します。取得購買依頼のステータスフィールドが「承認済み」に変わった時点のタイムスタンプを特定します。イベントタイプ inferred
	購買依頼の拒否	審査後に購買依頼が最終的に拒否されたことを示します。プロセスの終了状態であり、「拒否済み」へのステータス変更によって記録されます。
重要な理由プロセスにおける重要な失敗の終点です。拒否された購買依頼を分析することで、「購買依頼拒否率」KPIのパターンを特定し、依頼の品質を改善できます。入手先購買依頼の最終ステータスが「拒否済み」に変わったことを記録する、Aribaの文書履歴から推定します。取得購買依頼のステータスフィールドが「拒否済み」に変わった時点のタイムスタンプを特定します。イベントタイプ inferred
	購買依頼の提出	依頼者が購買依頼を承認ワークフローへ正式に提出したことを示します。「作成中」から「提出済み」へのステータス変更によって記録されます。
重要な理由承認プロセスを開始する重要なマイルストーンです。「購買依頼の承認サイクル時間」と「購買依頼の作成リードタイム」の測定に欠かせません。入手先購買依頼のステータスが「提出済み」に変わったことと、その変更時刻を記録するAribaの文書履歴または監査ログから推定します。取得購買依頼のステータスフィールドが初めて「提出済み」に変わった時点のタイムスタンプを特定します。イベントタイプ inferred
	承認ステップの却下	承認者が購買依頼を却下し、通常は変更のために差し戻したという、承認ステップの否定的な結果を示します。「拒否」アクションとして明示的に記録されます。
重要な理由手戻りとプロセス遅延の主な原因を明らかにします。これらのイベントを分析することは、「購買依頼手戻り率」や却下理由を把握するうえで重要です。入手先 Aribaの承認フローテーブルから取得します。承認者が担当タスクで「拒否」または「却下」アクションを実行した時刻とともに記録されます。取得特定のステップについて、承認履歴に記録された「拒否」アクションのタイムスタンプを使用します。イベントタイプ explicit
	承認ステップの承認	承認者が担当する購買依頼の部分を承認したという、承認ステップの肯定的な結果を示します。承認アクションとして明示的に記録されます。
重要な理由承認者ごとの処理時間を測定します。「承認ステップの平均所要時間」の計算や、承認者の業務量の評価に欠かせないデータです。入手先 Aribaの承認フローテーブルから取得します。承認者が割り当てられたタスクで「承認」アクションを実行した時刻とともに記録されます。取得特定のステップについて、承認履歴に記録された「承認」アクションのタイムスタンプを使用します。イベントタイプ explicit
	承認ステップの開始	購買依頼が承認者または承認キューへ回付され、対応を待っている状態を示します。承認依頼が生成され、割り当てられた時点で記録されます。
重要な理由承認ワークフローを詳細に把握できます。キューでの待機時間の計算や、「承認経路のボトルネック分析」でボトルネックとなっている具体的なステップの特定に欠かせません。入手先購買依頼に関連する個々の承認タスクの作成と割り当てを記録する、Aribaの承認フローテーブルから取得します。取得購買依頼と特定の承認ステップに関連付けられた承認依頼レコードの作成時刻を使用します。イベントタイプ explicit
	購買依頼の取り下げ	元の依頼者が、購買依頼の承認完了前に提出済みの購買依頼を取り消したときに発生します。「取り下げ済み」または「キャンセル済み」へのステータス変更によって記録されます。
重要な理由ユーザーが開始したプロセスの終了を示します。購買依頼が取り下げられた理由を分析することで、変化する業務要件や長い承認時間に関する問題を明らかにできます。入手先購買依頼のステータスが「取り下げ済み」に変わったことを記録する、Aribaの文書履歴または監査ログから推定します。取得購買依頼のステータスフィールドが「取り下げ済み」に変わった時点のタイムスタンプを特定します。イベントタイプ inferred
	購買依頼の変更	提出後の購買依頼をユーザーが変更したときに発生します。却下や問い合わせへの対応として行われることが多く、文書の編集と再提出によって記録されます。
重要な理由手戻りとプロセスの非効率を追跡します。変更頻度が高い場合、初期要件やポリシーが不明確である可能性があり、「購買依頼変更率」KPIに影響します。入手先 Aribaのバージョン情報から推定します。変更のたびに購買依頼書の新しいバージョンが作成されます。バージョンが1を超えている場合は、変更が行われたことを示します。取得初回の「提出済み」ステータス後に新しい購買依頼のバージョンが作成されたかを確認します。新しいバージョンの作成時刻がイベント時刻になります。イベントタイプ inferred
	購買依頼をソーシングへ送信	承認済みの購買依頼がソーシング部門へ回付され、発注書の作成前にRFQなどのソーシングイベントが実施されるときに発生します。たとえば「ソーシング」へのステータス変更によって記録されます。
重要な理由高額品目や標準外品目に関する重要な分岐を特定します。ソーシング部門がリードタイムに与える影響を分析するのに役立ちます。入手先購買依頼のステータスが、ソーシングへ送信されたことを示す値に変わったことから推定します。Ariba BuyingとAriba Sourcingを連携している場合によく見られます。取得購買依頼のステータスフィールドが「ソーシング」または同様のカスタムステータスに変わった時点のタイムスタンプを特定します。イベントタイプ inferred
	購買依頼明細の発注	購買依頼の個別明細が発注書に含まれた後、「発注済み」に変わったことを示します。ヘッダーレベルで発注書を作成した場合よりも詳細に追跡できます。
重要な理由ヘッダーだけでは見えない、明細単位での一部発注や遅延を分析できます。複数の明細が異なる発注書で処理される購買依頼に役立ちます。入手先購買依頼明細オブジェクトのステータス変更から推定します。明細の発注書が作成されると、明細のステータスが「発注済み」に更新されます。取得購買依頼明細のステータスフィールドが「発注済み」に変わった時点のタイムスタンプを特定します。イベントタイプ inferred

推奨任意

抽出ガイド

SAP Aribaからデータを取得する方法

ステップ

SAP Aribaにログイン：分析レポートを作成・実行する権限を持つユーザーアカウント（「Reporting Analyst」ロールなど）でSAP Ariba環境にアクセスします。
分析レポートへ移動：メインのダッシュボードからレポート領域へ移動します。通常は「Reporting」「Analytics」、または「Manage」＞「Analytical Reports」などのメニューにあります。
新しいレポートを作成：新しい分析レポートの作成を開始します。最初に主要なデータ領域（通常は「Fact」と呼ばれます）の選択を求められます。購買依頼に関連するFact（「[Requisition]」など、Aribaの設定に応じた名称）を選択します。
データ項目を追加：レポートビルダーでレポートに列を追加します。必要な情報をすべて取得するには、複数のデータソース（Fact）を結合する必要があります。一般的なレポートでは、Requisition IDをキーとして「[Requisition Fact]」を「[Approval History Fact]」および「[Purchase Order Fact]」と結合します。クエリ設定に記載されたすべての項目を追加し、承認履歴からCreated Date、Submitted Date、Approved Date、Action Dateなどの関連するタイムスタンプも含めます。
フィルターを設定：データ範囲を限定するフィルターを設定します。最も重要なのは日付範囲です。たとえば、対象期間の「Requisition Created Date」に過去3～6か月を指定します。必要に応じて、特定のCompany CodeやRealmなどのフィルターも追加します。
生のレポートを実行してエクスポート：レポートを実行します。完了したら、結果をCSVまたはExcelファイルへエクスポートします。最初のエクスポートは、購買依頼または承認エントリごとに1行を持ち、日付やユーザー操作ごとに多数の列がある「ワイド」形式です。
データをイベントログ形式に変換：これはオフラインで行う重要なステップです。Microsoft ExcelのPower Query、Pythonスクリプト、その他のデータ準備ツールを使い、ワイド形式のデータをロング形式へ変換します。エクスポートした各タイムスタンプ列（例：「Created Date」「Submitted Date」「Approved Date」）について、最終的なイベントログに個別の行を作成します。この処理は「アンピボット」または「メルティング」と呼ばれることがあります。
アクティビティと属性をマッピング：変換時にActivityName列とEventTimestamp列を作成します。たとえば「Submitted Date」列を処理する場合、ActivityNameが「Requisition Submitted」、EventTimestampが「Submitted Date」列の値となる行を作成します。
データを統合してクリーンアップ：すべてのタイムスタンプ列からアンピボットしたデータを1つのファイルにまとめます。各行でPurchaseRequisitionId、ActivityName、EventTimestamp列が正しく入力されていることを確認します。空の行や書式上の問題も修正します。
最終CSVとして保存：変換後のイベントログをUTF-8エンコーディングのCSVファイルとして保存します。これで、プロセスマイニングツールへアップロードできる状態になります。

設定

レポートタイプ：標準のAribaレポートインターフェースを使用する分析レポートです。
主要なデータFact：通常は「[Requisition Fact]」「[Approval History Fact]」「[Purchase Order Fact]」など、複数のFactのデータを結合する必要があります。正確な名称は、Aribaのデータモデルによって異なる場合があります。
日付範囲：「Requisition Created Date」で、3～6か月など管理しやすい期間に絞り込むことを推奨します。初回テストでは、1週間など短い期間を指定してください。
主要なフィルター：必ず特定の日付範囲で絞り込んでください。また、「Company Code」や「Purchasing Organization」で絞り込み、対象となる業務範囲にデータセットを限定すると、レポートのパフォーマンスを高められます。
前提条件：レポートを実行するユーザーには、分析レポートモジュールと、購買依頼、承認、購買注文に関する基盤データFactへアクセスする権限を持つロールが必要です。

a サンプルクエリ config

REPORT CONFIGURATION for SAP Ariba Analytical Reporting

REPORT TYPE: Analytical Report

PRIMARY DATA SOURCE (FACT):
*   [Requisition Fact]

JOINED DATA SOURCES (FACTS):
*   [Approval History Fact] on Requisition ID
*   [Purchase Order Fact] on Requisition ID
*   [Requisition Line Item Fact] on Requisition ID

REPORT FIELDS (COLUMNS TO EXPORT for subsequent transformation):

// Case and General Attributes
*   Requisition.Requisition ID (as PurchaseRequisitionId)
*   Requisition.Status (as RequisitionStatus)
*   Requisition.Requester.Department (as RequesterDepartment)
*   Requisition.Total Cost.Amount (as TotalRequisitionAmount)
*   Requisition.Line Items.Category (as ItemCategory)
*   Requisition.Is Urgent (as UrgencyLevel)
*   Requisition.Approval Flow Name (as ApprovalWorkflowPath)

// Fields for 'Requisition Created'
*   Requisition.Created Date (Timestamp)
*   Requisition.Requester.User ID (User)

// Fields for 'Requisition Submitted'
*   Requisition.Submitted Date (Timestamp)
*   Requisition.Submitter.User ID (User)

// Fields for 'Requisition Amended'
*   Requisition.Last Modified Date (Timestamp) - Note: Requires logic to isolate true amendment events
*   Requisition.Last Modified By.User ID (User)

// Fields for 'Approval Step' activities
*   Approval History.Approval Request Date (Timestamp for 'Approval Step Started')
*   Approval History.Action Date (Timestamp for 'Approval Step Approved'/'Approval Step Rejected')
*   Approval History.Action (Value: 'Approve'/'Deny')
*   Approval History.Approver.User ID (User)
*   Approval History.Comments (for RejectionReason)

// Fields for final status activities
*   Requisition.Approved Date (Timestamp for 'Requisition Approved')
*   Requisition.Denied Date (Timestamp for 'Requisition Denied')
*   Requisition.Withdrawn Date (Timestamp for 'Requisition Withdrawn')
*   Requisition.Closed Date (Timestamp for 'Requisition Closed')

// Fields for downstream activities
*   Requisition.Sourcing Status Date (Timestamp for 'Requisition Sent To Sourcing')
*   Purchase Order.Created Date (Timestamp for 'Purchase Order Created')
*   Purchase Order.Creator.User ID (User for 'Purchase Order Created')
*   Requisition Line Item.Ordered Date (Timestamp for 'Requisition Line Item Ordered')

FILTERS:
*   Requisition.Created Date BETWEEN [Start Date] AND [End Date]
*   Company Code IN ([Your Company Codes])

ステップ

Python環境を設定：Python 3.6以降がインストールされていることを確認します。pipで必要なライブラリをインストールします：pip install requests pandas。
APIアクセスを設定：SAP Ariba Developer Portalで新しいアプリケーションを登録します。「Operational Reporting API for Requisitions」をサブスクライブし、OAuth認証情報を取得します。必要な情報は、Application Key（API Key）、OAuth Client Secret、[your_api_key]:[your_client_secret]をBase64エンコードした文字列です。
Pythonスクリプトをカスタマイズ：提供されたPythonスクリプトを開きます。先頭にあるプレースホルダー変数（ARIBА_REALM、BASE_URL、API_KEY、BASE64_CREDSなど）を入力します。また、データ抽出期間のSTART_DATEとEND_DATEを設定します。
レポートペイロードを定義：スクリプト内のreport_payload JSONオブジェクトを確認します。ここで実行するレポートを定義します。スクリプトは、RequisitionFactSystemViewを使用し、必要なアクティビティと属性に関連する項目を選択するよう、あらかじめ設定されています。必要に応じて項目やフィルターを追加できます。
スクリプトを実行：ターミナルでpython your_script_name.pyを実行します。スクリプトはまずAribaで認証し、アクセストークンを取得します。
レポートジョブを送信して監視：スクリプトがレポートリクエストをAriba APIへ自動的に送信します。ジョブは非同期で実行されるため、その後は60秒ごとにAriba APIへポーリングし、ジョブのステータスを確認します。
レポートデータをダウンロード：Ariba APIがジョブのステータスを「COMPLETED」と報告したら、スクリプトが結果データをダウンロードします。通常は、1つのCSVファイルを含むZIPファイルです。
データを処理して変換：スクリプトがファイルを解凍し、生のデータをpandas DataFrameに読み込みます。その後、ワイド形式（購買依頼ごとに1行で、多数の日付列を持つ形式）から、ロング形式のイベントログ（購買依頼ごとに複数行で、アクティビティごとに1行の形式）へ変換します。
イベントログを生成：変換後のDataFrameは、PurchaseRequisitionId、ActivityName、EventTimestampなどの列を持つ正しいイベントログとして、スクリプトと同じディレクトリにariba_requisition_event_log.csvという名前で保存されます。
アップロードの準備：生成されたCSVファイルはProcessMindへアップロードできます。列ヘッダーがProcessMindプロジェクトで設定したマッピングと一致していることを確認してください。

設定

APIエンドポイントURL：スクリプトの実行には、通常 https://[your-realm].api.ariba.com/api/operationalreporting/v2/ の形式で指定する、AribaインスタンスのAPIベースURLが必要です。[your-realm]を、お客様の会社に固有のAribaレルム名に置き換えてください。
認証：データの抽出にはOAuth 2.0を使用します。Ariba Developer Portalに登録したアプリケーションから取得した、有効な apiKey、clientSecret、base64EncodedCredentials 文字列を指定してください。
ビューのテンプレート：スクリプトは RequisitionFactSystemView を使用するように設定されています。これは標準的なAribaビューですが、お客様の環境で有効になっていること、およびAPIユーザーにアクセス権限があることを確認してください。
日付範囲フィルター：レポートのペイロードに含まれる creationDate フィルターは、データ量を制御するうえで重要です。初回の抽出では、3～6か月の期間を指定することを推奨します。大規模な組織では、月単位など、より小さな単位でデータを抽出してください。
増分ロード：2回目以降の抽出では、START_DATE と END_DATE を調整し、新規または更新されたレコードだけを取得してください。スクリプトは増分処理を自動で管理しないため、実行ごとに日付範囲を手動で設定する必要があります。
前提条件：アプリケーションと認証情報を作成するには、「Developer Portal Access」の権限を持つSAP Aribaユーザーが必要です。APIアプリケーション自体には、レポートジョブを実行するための「Operational Reporting API User」ロールが必要です。

a サンプルクエリ python

import requests
import json
import pandas as pd
import time
import zipfile
import io

class=class="hl-string">"hl-comment"># --- Configuration --- 
class=class="hl-string">"hl-comment"># Replace with your SAP Ariba realm, datacenter-specific URL, and credentials
ARIBA_REALM = class="hl-string">"[Your Ariba Realm]"
BASE_URL = fclass="hl-string">"https://{ARIBA_REALM}.api.ariba.com/api/operationalreporting/v2/"
TOKEN_URL = class="hl-string">"https://api.ariba.com/v2/oauth/token"
API_KEY = class="hl-string">"[Your Application Key]"
BASE64_CREDS = class="hl-string">"[Your Base64-encoded ClientID:ClientSecret]"

class=class="hl-string">"hl-comment"># --- Report Parameters ---
class=class="hl-string">"hl-comment"># Set the date range for the extraction
START_DATE = class="hl-string">"2023-01-01T00:00:00Z"
END_DATE = class="hl-string">"2023-06-30T23:59:59Z"

class=class="hl-string">"hl-comment"># The main function to orchestrate the extraction process
def main():
    print(class="hl-string">"1. Acquiring access token...")
    access_token = get_access_token()
    if not access_token:
        return

    print(class="hl-string">"2. Creating asynchronous report job...")
    job_id = create_report_job(access_token)
    if not job_id:
        return

    print(fclass="hl-string">"Job created with ID: {job_id}. Polling for completion...")
    status = poll_job_status(access_token, job_id)

    if status == class="hl-string">'COMPLETED':
        print(class="hl-string">"3. Job completed. Downloading report data...")
        raw_data = download_report(access_token, job_id)
        if raw_data:
            print(class="hl-string">"4. Processing raw data into event log...")
            event_log = process_data(raw_data)
            output_filename = class="hl-string">'ariba_requisition_event_log.csv'
            event_log.to_csv(output_filename, index=False)
            print(fclass="hl-string">"5. Success! Event log saved to {output_filename}")
    else:
        print(fclass="hl-string">"Job failed or timed out with status: {status}")

def get_access_token():
    headers = {
        class="hl-string">'Authorization': fclass="hl-string">'Basic {BASE64_CREDS}',
        class="hl-string">'Content-Type': class="hl-string">'application/x-www-form-urlencoded',
    }
    data = {class="hl-string">'grant_type': class="hl-string">'client_credentials'}
    try:
        response = requests.post(TOKEN_URL, headers=headers, data=data)
        response.raise_for_status()
        return response.json().get(class="hl-string">'access_token')
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Error getting access token: {e}")
        return None

def create_report_job(token):
    headers = {
        class="hl-string">'Authorization': fclass="hl-string">'Bearer {token}',
        class="hl-string">'apiKey': API_KEY,
        class="hl-string">'Content-Type': class="hl-string">'application/json'
    }
    report_payload = {
        class="hl-string">"name": class="hl-string">"ProcessMind Requisition Extraction",
        class="hl-string">"viewTemplateName": class="hl-string">"RequisitionFactSystemView",
        class="hl-string">"outputFormat": class="hl-string">"CSV",
        class="hl-string">"filters": {
            class="hl-string">"creationDate": {
                class="hl-string">"from": START_DATE,
                class="hl-string">"to": END_DATE
            }
        },
        class="hl-string">"select": [
            class="hl-string">"RequisitionId", class="hl-string">"StatusString", class="hl-string">"SubmitDate", class="hl-string">"ApprovedState.TimeUpdated",
            class="hl-string">"DeniedState.TimeUpdated", class="hl-string">"SourcingState.TimeUpdated", class="hl-string">"ClosedState.TimeUpdated",
            class="hl-string">"WithdrawnState.TimeUpdated", class="hl-string">"Requester.Name", class="hl-string">"Requester.Department",
            class="hl-string">"TotalCost.Amount", class="hl-string">"LineItems.Category.Name", class="hl-string">"IsUrgent", class="hl-string">"ApprovalFlow.Name",
            class="hl-string">"RequisitionVersion", class="hl-string">"TimeCreated", class="hl-string">"LineItems.OrderedState.TimeUpdated", class="hl-string">"POInfo.POId"
        ]
    }
    try:
        response = requests.post(fclass="hl-string">"{BASE_URL}jobs", headers=headers, json=report_payload)
        response.raise_for_status()
        return response.json().get(class="hl-string">'jobId')
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Error creating report job: {e}")
        return None

def poll_job_status(token, job_id):
    headers = {class="hl-string">'Authorization': fclass="hl-string">'Bearer {token}', class="hl-string">'apiKey': API_KEY}
    while True:
        try:
            response = requests.get(fclass="hl-string">"{BASE_URL}jobs('{job_id}')", headers=headers)
            response.raise_for_status()
            status = response.json().get(class="hl-string">'status')
            print(fclass="hl-string">"Current job status: {status}")
            if status in [class="hl-string">'COMPLETED', class="hl-string">'FAILED', class="hl-string">'CANCELLED']:
                return status
            time.sleep(60) class=class="hl-string">"hl-comment"># Wait 60 seconds before polling again
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error polling job status: {e}")
            return class="hl-string">'FAILED'

def download_report(token, job_id):
    headers = {class="hl-string">'Authorization': fclass="hl-string">'Bearer {token}', class="hl-string">'apiKey': API_KEY}
    try:
        response = requests.get(fclass="hl-string">"{BASE_URL}jobs('{job_id}')/result", headers=headers, stream=True)
        response.raise_for_status()
        return response.content
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Error downloading report: {e}")
        return None

def process_data(zip_content):
    try:
        with zipfile.ZipFile(io.BytesIO(zip_content)) as z:
            class=class="hl-string">"hl-comment"># Assuming the first file in the zip is the CSV we need
            csv_filename = z.namelist()[0]
            with z.open(csv_filename) as f:
                df = pd.read_csv(f)
    except Exception as e:
        print(fclass="hl-string">"Error reading zipped CSV: {e}")
        return pd.DataFrame()

    class=class="hl-string">"hl-comment"># Rename columns for clarity
    df.rename(columns={
        class="hl-string">'RequisitionId': class="hl-string">'PurchaseRequisitionId',
        class="hl-string">'TimeCreated': class="hl-string">'Timestamp_Created',
        class="hl-string">'SubmitDate': class="hl-string">'Timestamp_Submitted',
        class="hl-string">'ApprovedState.TimeUpdated': class="hl-string">'Timestamp_Approved',
        class="hl-string">'DeniedState.TimeUpdated': class="hl-string">'Timestamp_Denied',
        class="hl-string">'SourcingState.TimeUpdated': class="hl-string">'Timestamp_SentToSourcing',
        class="hl-string">'ClosedState.TimeUpdated': class="hl-string">'Timestamp_Closed',
        class="hl-string">'WithdrawnState.TimeUpdated': class="hl-string">'Timestamp_Withdrawn',
        class="hl-string">'LineItems.OrderedState.TimeUpdated': class="hl-string">'Timestamp_LineItemOrdered',
        class="hl-string">'POInfo.POId': class="hl-string">'POId',
        class="hl-string">'Requester.Name': class="hl-string">'EventUser',
        class="hl-string">'Requester.Department': class="hl-string">'RequesterDepartment',
        class="hl-string">'TotalCost.Amount': class="hl-string">'TotalRequisitionAmount',
        class="hl-string">'LineItems.Category.Name': class="hl-string">'ItemCategory',
        class="hl-string">'IsUrgent': class="hl-string">'UrgencyLevel',
        class="hl-string">'ApprovalFlow.Name': class="hl-string">'ApprovalWorkflowPath',
        class="hl-string">'StatusString': class="hl-string">'RequisitionStatus'
    }, inplace=True)
    
    class=class="hl-string">"hl-comment"># Create a base dataframe for melting
    id_vars = [
        class="hl-string">'PurchaseRequisitionId', class="hl-string">'EventUser', class="hl-string">'RequesterDepartment', class="hl-string">'TotalRequisitionAmount',
        class="hl-string">'ItemCategory', class="hl-string">'UrgencyLevel', class="hl-string">'ApprovalWorkflowPath', class="hl-string">'RequisitionStatus', class="hl-string">'RequisitionVersion', class="hl-string">'POId'
    ]
    
    timestamp_cols = [col for col in df.columns if col.startswith(class="hl-string">'Timestamp_')]
    
    class=class="hl-string">"hl-comment"># Melt the dataframe to turn timestamp columns into rows
    event_log = pd.melt(df, id_vars=id_vars, value_vars=timestamp_cols, var_name=class="hl-string">'ActivityName', value_name=class="hl-string">'EventTimestamp')
    
    class=class="hl-string">"hl-comment"># Clean up and format
    event_log.dropna(subset=[class="hl-string">'EventTimestamp'], inplace=True)
    event_log[class="hl-string">'ActivityName'] = event_log[class="hl-string">'ActivityName'].str.replace(class="hl-string">'Timestamp_', class="hl-string">'Requisition ')
    event_log[class="hl-string">'EventTimestamp'] = pd.to_datetime(event_log[class="hl-string">'EventTimestamp'])

    class=class="hl-string">"hl-comment"># --- Handle specific/derived activities ---
    class=class="hl-string">"hl-comment"># Requisition Amended
    amended_df = df[df[class="hl-string">'RequisitionVersion'] > 1].copy()
    if not amended_df.empty:
        amended_df[class="hl-string">'ActivityName'] = class="hl-string">'Requisition Amended'
        amended_df[class="hl-string">'EventTimestamp'] = pd.to_datetime(amended_df[class="hl-string">'Timestamp_Submitted'])
        event_log = pd.concat([event_log, amended_df[event_log.columns]], ignore_index=True)

    class=class="hl-string">"hl-comment"># Purchase Order Created (use the timestamp of the first line item ordered as a proxy)
    po_created_df = df[df[class="hl-string">'POId'].notna() & df[class="hl-string">'Timestamp_LineItemOrdered'].notna()].copy()
    if not po_created_df.empty:
        po_created_df[class="hl-string">'ActivityName'] = class="hl-string">'Purchase Order Created'
        po_created_df[class="hl-string">'EventTimestamp'] = pd.to_datetime(po_created_df[class="hl-string">'Timestamp_LineItemOrdered'])
        event_log = pd.concat([event_log, po_created_df[event_log.columns]], ignore_index=True)
    
    class=class="hl-string">"hl-comment"># Placeholder for Approval Steps - requires parsing ApprovalRecords not included in this basic script
    class=class="hl-string">"hl-comment"># For now, we only have the final class="hl-string">'Approved' status. This logic can be expanded.
    class=class="hl-string">"hl-comment"># Creating dummy class="hl-string">'Approval Step Started/Approved' for demonstration.
    approval_df = df[df[class="hl-string">'Timestamp_Approved'].notna()].copy()
    if not approval_df.empty:
        approval_started = approval_df.copy()
        approval_started[class="hl-string">'ActivityName'] = class="hl-string">'Approval Step Started'
        class=class="hl-string">"hl-comment"># Approximate start time as submit time
        approval_started[class="hl-string">'EventTimestamp'] = pd.to_datetime(approval_started[class="hl-string">'Timestamp_Submitted'])
        
        approval_approved = approval_df.copy()
        approval_approved[class="hl-string">'ActivityName'] = class="hl-string">'Approval Step Approved'
        approval_approved[class="hl-string">'EventTimestamp'] = pd.to_datetime(approval_approved[class="hl-string">'Timestamp_Approved'])
        approval_approved[class="hl-string">'RejectionReason'] = None class=class="hl-string">"hl-comment"># Add column for consistency
        
        event_log = pd.concat([event_log, approval_started[event_log.columns], approval_approved[event_log.columns.tolist() + [class="hl-string">'RejectionReason']]], ignore_index=True)

    class=class="hl-string">"hl-comment"># Add placeholder for RejectionReason, as it's not directly in this view
    if class="hl-string">'RejectionReason' not in event_log.columns:
        event_log[class="hl-string">'RejectionReason'] = None

    class=class="hl-string">"hl-comment"># Final sorting and cleanup
    event_log = event_log.sort_values(by=[class="hl-string">'PurchaseRequisitionId', class="hl-string">'EventTimestamp']).reset_index(drop=True)
    
    class=class="hl-string">"hl-comment"># Rename class="hl-string">'Requisition LineItemOrdered' to class="hl-string">'Requisition Line Item Ordered'
    event_log[class="hl-string">'ActivityName'] = event_log[class="hl-string">'ActivityName'].replace({class="hl-string">'Requisition LineItemOrdered': class="hl-string">'Requisition Line Item Ordered'})

    class=class="hl-string">"hl-comment"># Final column selection
    final_columns = [
        class="hl-string">'PurchaseRequisitionId', class="hl-string">'ActivityName', class="hl-string">'EventTimestamp', class="hl-string">'EventUser',
        class="hl-string">'RequesterDepartment', class="hl-string">'TotalRequisitionAmount', class="hl-string">'ItemCategory', class="hl-string">'UrgencyLevel',
        class="hl-string">'ApprovalWorkflowPath', class="hl-string">'RejectionReason', class="hl-string">'RequisitionStatus'
    ]
    event_log = event_log[final_columns]

    return event_log

if __name__ == class="hl-string">"__main__":
    main()

今すぐ始めませんか

このテンプレートを使ってデータ準備を効率化し、調達から支払いまでの購買依頼プロセスを詳しく把握してください。今日から業務の改善を始められます。

改善ガイドに戻るテンプレートをダウンロード

遅延を止める：調達から支払いまでの購買依頼プロセスを改善

SAP Aribaの非効率な箇所を特定し、サイクルタイムを30％短縮します。

無料トライアルを開始

クレジットカードは不要で、すぐに簡単に設定できます。

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

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

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

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

抽出ガイド

SAP Aribaの分析レポートをCSV／Excelへエクスポート

ステップ

設定

a サンプルクエリ config

Operational Reporting APIを使用したPythonスクリプトによる抽出

ステップ

設定

a サンプルクエリ python

今すぐ始めませんか

遅延を止める：調達から支払いまでの購買依頼プロセスを改善

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

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

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

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

抽出ガイド

SAP Aribaの分析レポートをCSV／Excelへエクスポート

ステップ

設定

a サンプルクエリ config

Operational Reporting APIを使用したPythonスクリプトによる抽出

ステップ

設定

a サンプルクエリ python

今すぐ始めませんか

遅延を止める：調達から支払いまでの購買依頼プロセスを改善

プライバシーを大切にしています