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

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

SAP Ariba

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

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

このデータテンプレートでは、調達から支払いまでの購買依頼プロセスを分析するために必要な情報を、効率よく収集・整理できます。イベントログの作成に必要な属性とアクティビティをまとめており、プロセスのパフォーマンスを詳しく分析できます。また、ソースシステムからデータを抽出する手順も紹介しているため、プロセスマイニングをスムーズに始められます。

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

イベントログを初めて作成する方はこちら：プロセスマイニング用イベントログの作成方法.

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

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

調達から支払いまでの購買依頼プロセスを詳しく分析するために、イベントログに含めることを推奨するデータフィールドです。重要な情報を漏れなく記録できます。

3 必須 8 推奨 8 任意

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

必須推奨任意

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

プロセスを正確に把握し、ボトルネックを特定するために、イベントログに記録する主要なステップとマイルストーンです。

6 推奨 7 任意

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

推奨任意

データ抽出ガイド

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

ステップ

SAP Aribaにログイン：分析レポートの作成と実行に必要な権限を持つユーザーアカウントで、SAP Ariba環境にアクセスします。「レポートアナリスト」などのロールが必要です。
分析レポートに移動：メインのダッシュボードからレポート画面に移動します。通常、「レポート」「分析」などのメニュー、または「管理」＞「分析レポート」から開けます。
新しいレポートを作成：新しい分析レポートの作成を開始します。主となるデータ領域（「ファクト」と呼ばれることがあります）を選択する画面が表示されます。「［購買依頼］」など、依頼に関連するファクトを選択してください。名称はAribaの設定によって異なる場合があります。
データフィールドを追加：レポート作成画面で、レポートに列を追加します。必要な情報をすべて取得するには、複数のデータソース（ファクト）を結合します。一般的には、依頼IDをキーとして「［購買依頼ファクト］」「［承認履歴ファクト］」「［発注書ファクト］」を結合します。クエリ設定に記載されたフィールドをすべて追加し、承認履歴の作成日、提出日、承認日、操作日など、関連するタイムスタンプも含めてください。
フィルターを設定：データの範囲を絞り込むフィルターを設定します。特に重要なのは日付範囲です。たとえば、対象期間の「依頼作成日」を過去3～6か月に設定します。必要に応じて、特定の会社コードやレルムなどのフィルターも追加してください。
レポートを実行して生データをエクスポート：レポートを実行します。完了したら、結果をCSVまたはExcelファイルにエクスポートします。最初のエクスポートは横持ち形式で、依頼または承認エントリごとに1行、日付やユーザー操作ごとに複数の列が含まれます。
イベントログ形式にデータを変換：この作業はオフラインで行います。Microsoft ExcelのPower Query、Pythonスクリプト、その他のデータ準備ツールを使い、横持ちデータを縦持ち形式に変換します。エクスポートした各タイムスタンプ列（「作成日」「提出日」「承認日」など）について、最終的なイベントログに個別の行を作成します。この処理は「ピボット解除」または「メルト」と呼ばれることがあります。
アクティビティと属性を対応付け：変換時に、ActivityName列とEventTimestamp列を作成します。たとえば、「提出日」列を処理する際は、ActivityNameが「依頼提出済み」、EventTimestampが「提出日」列の値となる行を作成します。
データを統合して整える：すべてのタイムスタンプ列からピボット解除したデータを1つのファイルにまとめます。各行のPurchaseRequisitionId、ActivityName、EventTimestamp列に正しい値が入っていることを確認し、空の行や書式の問題を取り除きます。
最終版をCSVで保存：変換後のイベントログをUTF-8エンコードのCSVファイルとして保存します。これでプロセスマイニングツールにアップロードする準備が整います。

設定

レポートの種類：標準のAribaレポート画面を使った分析レポート。
主要なデータファクト：「［購買依頼ファクト］」「［承認履歴ファクト］」「［発注書ファクト］」など、複数のファクトのデータを組み合わせます。正確な名称はAribaのデータモデルによって異なる場合があります。
日付範囲：運用しやすい期間として、依頼の「作成日」を過去3～6か月に絞り込むことを推奨します。初回のテストでは、1週間など短い期間を指定してください。
主なフィルター：必ず日付範囲を指定してください。また、対象データを業務範囲に絞り、レポートの処理性能を高めるため、「会社コード」や「購買組織」での絞り込みも検討してください。
前提条件：レポートを実行するユーザーには、分析レポートモジュールと、購買依頼、承認、発注書に関するデータファクトへのアクセス権限が必要です。

クエリの例 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スクリプトを開きます。先頭にあるARIBA_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」になると、スクリプトがデータをダウンロードします。通常、ダウンロードされるZIPファイルにはCSVファイルが1つ含まれています。
データの処理と変換：スクリプトでファイルを解凍し、生のデータをpandasのDataFrameに読み込みます。次に、重要な変換処理として、1つの申請につき1行で日付列が複数ある横長形式のデータを、1つの申請につき複数行で各アクティビティを記録するイベントログ形式に変換します。
イベントログの作成：変換後のDataFrameは、PurchaseRequisitionId、ActivityName、EventTimestampなどの列を持つイベントログとして、スクリプトと同じディレクトリにariba_requisition_event_log.csvという名前で保存されます。
アップロードの準備：作成したCSVファイルをProcessMindにアップロードできます。列見出しがProcessMindプロジェクトで設定したマッピングと一致していることを確認してください。

設定

APIエンドポイントURL：スクリプトには、AribaインスタンスのAPIベースURLが必要です。通常はhttps://[your-realm].api.ariba.com/api/operationalreporting/v2/の形式です。[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ユーザーが必要です。レポートジョブを実行するアプリケーションには、「Operational Reporting API User」ロールが必要です。

クエリの例 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でエクスポート

ステップ

設定

クエリの例 config

オペレーショナルレポーティングAPIを使ったPythonスクリプトによる抽出

ステップ

設定

クエリの例 python

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

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