調達から支払いまで:発注書のデータテンプレート
調達から支払いまで:発注書のデータテンプレート
- 推奨されるデータ属性
- 主要なプロセスアクティビティ
- Coupaからのデータ抽出手順
調達から支払いまで:発注書の属性
| 名前 | 説明 | ||
|---|---|---|---|
|
アクティビティ
ActivityName
|
Purchase Orderのライフサイクルにおいて、特定の時点で発生したイベントまたはタスクの名称です。 | ||
|
説明
Activity Nameは、「Purchase Order Approved」や「Goods Receipt Posted」など、調達から支払いまでのプロセスにおける1つのステップを表します。これらのアクティビティの連続が、各Purchase Orderのプロセスフローを形成します。 この属性は、プロセスマイニングの基盤となる項目です。プロセスマップの作成、プロセスバリアントの発見、イベントの発生頻度と順序の分析に使用されます。ボトルネック、手戻りのループ、標準プロセスフローからの逸脱を特定するのにも役立ちます。たとえば、「Purchase Order Changed」アクティビティの順序を分析すると、注文内容の正確性に関する非効率を明らかにできます。
重要な理由
プロセスの各ステップを定義し、プロセスフローの可視化や、ボトルネック、手戻り、逸脱の特定を可能にします。
入手先
CoupaのPurchase Orderオブジェクトに関連付けられたイベントログ、監査証跡、またはステータス変更記録から取得されます。
例
購買申請を承認発注書を提出入荷を計上発注書に対する請求書を受領
|
|||
|
発注書
PurchaseOrderNumber
|
発注書を一意に識別する番号であり、プロセスの主要なケース識別子として機能します。 | ||
|
説明
発注書番号は、最初の依頼から商品またはサービスの受領確認まで、すべてのアクティビティをつなぐ中心的なケース識別子です。一意の発注書番号はそれぞれ、調達プロセスの1つのインスタンスを表します。 プロセスマイニング分析では、この属性が各購買のエンドツーエンドの流れを追跡するうえで重要です。分析担当者は、プロセスマップを可視化し、バリアントを特定し、発注書の総サイクルタイムなどケース単位のKPIを計算できます。すべてのイベントと関連データはこの識別子の下に集約され、プロセスを一貫して把握できます。
重要な理由
各購買のライフサイクル全体を追跡し、詳細な分析に向けて個々のプロセスインスタンスを再構成するために欠かせません。
入手先
CoupaのPurchase Orderオブジェクトにおける、標準的な主キー項目です。
例
PO-2023-00123PO-2023-00456PO-2023-00789
|
|||
|
開始時刻
EventTime
|
アクティビティまたはイベントが発生した正確な日時を示すタイムスタンプです。 | ||
|
説明
Event Timeは、特定のアクティビティが実行された日時を記録します。プロセス内の各アクティビティには、その発生時点を示す対応するタイムスタンプがあります。 この属性は、プロセスマイニングにおける時間ベースの分析全般に欠かせません。アクティビティ間のサイクルタイムの計算、プロセス期間の測定、遅延の特定に使用されます。たとえば、「Purchase Order Drafted」と「Purchase Order Approved」のタイムスタンプの差から、PO承認サイクルタイムKPIを算出します。
重要な理由
各イベントの時間的な背景を示します。サイクルタイムの計算、パフォーマンス分析、ボトルネックの検出に欠かせない情報です。
入手先
Coupaのイベントログまたは監査証跡にあり、通常はPurchase Orderの各ステータス変更や実行されたアクションに関連付けられています。
例
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z
|
|||
|
ソースシステム
SourceSystem
|
プロセスデータの抽出元となったシステムです。 | ||
|
説明
イベントデータが記録された元の情報システムを識別する属性です。このプロセスでは、値は一貫して「Coupa」になります。 企業環境では、Coupaを調達に、別のERPを請求に使うなど、複数のシステムからデータを取得する場合があります。この属性によりデータソースを区別できます。データの系譜を明確にし、特定のシステムから見たプロセスに絞って分析する際にも利用できます。
重要な理由
データの出所に関する重要な背景情報を提供し、追跡可能性を確保します。特に複数のシステムが存在する環境で、適切なデータガバナンスを可能にします。
入手先
通常、データの抽出・変換処理でデータセットを識別するために付与される固定値です。
例
Coupa
|
|||
|
最終データ更新日時
LastDataUpdate
|
このプロセスのデータが最後に更新された日時を示すタイムスタンプです。 | ||
|
説明
ソースシステムからデータセットが最後に更新された日時を記録します。個々のイベントではなく、データセット全体に適用されるメタデータ項目です。 分析用のダッシュボードでは、表示されているデータがどの程度新しいかを把握するために、このタイムスタンプが欠かせません。最新の情報に基づく分析結果であることを確認でき、データの更新状況に対する利用者の認識をそろえるのにも役立ちます。通常、ダッシュボード上で目立つ位置に表示されます。
重要な理由
データの更新時点を利用者に伝え、プロセス分析とKPIがどの時点の情報に基づくものかを明確にします。
入手先
ETLパイプラインの実行時に生成され、保存されるタイムスタンプです。
例
2023-11-01T05:00:00Z
|
|||
|
ベンダー名
VendorName
|
商品またはサービスを購入する相手であるサプライヤーまたはベンダーの名称です。 | ||
|
説明
Vendor Nameは、Purchase Orderに記載された商品を供給する外部企業を識別します。調達分析の基盤となる情報です。 ベンダー別にプロセスパフォーマンスを分析することは、サプライヤーとの関係管理に欠かせません。「Supplier Lead Time Performance」の評価、「Goods Receipt Process Delays」における遅延の特定、「Goods Return Rate」によるサプライヤー品質の評価に役立ちます。また、「Spend by Non-Preferred Vendor Ratio」KPIの計算にも使用されます。
重要な理由
サプライヤーのパフォーマンス分析を可能にし、サプライヤーの選定、より有利な条件の交渉、パフォーマンスの高いまたは低いベンダーの特定に役立ちます。
入手先
CoupaのPurchase Orderヘッダーにある標準項目で、Supplier Master Dataと関連付けられています。
例
グローバルオフィス用品Tech Solutions Inc.Advanced Industrial PartsCreative Marketing Agency
|
|||
|
ユーザー
User
|
承認者や依頼者など、アクティビティを実行した担当者のユーザーIDまたは氏名です。 | ||
|
説明
プロセス内の特定のイベントを実行した担当者を識別する属性です。注文を作成した担当者、承認したマネージャー、入荷を記録した担当者などが該当します。 ユーザー別にパフォーマンスを分析すると、トレーニングの必要性、パフォーマンスの高い担当者、業務量の分布を把握できます。たとえば、「PO Approval Cycle Time Performance」ダッシュボードでは、この属性を使って承認者別に承認時間を分解し、プロセス上のボトルネックとなっている可能性のある担当者を特定できます。
重要な理由
個人または役割ごとのプロセスパフォーマンスを分析でき、ボトルネック、トレーニングの機会、リソース配分の課題を特定するのに役立ちます。
入手先
CoupaのPurchase Orderの監査証跡または履歴ログにある各イベントに関連付けられています。「Created By」、「Approved By」、「Updated By」などの項目が一般的な取得元です。
例
j.doea.smithm.jones
|
|||
|
注文総額
TotalOrderAmount
|
Purchase Orderの金銭的な総額です。 | ||
|
説明
Purchase Orderに記載されたすべての商品とサービスの合計金額を、特定の通貨で表した属性です。注文全体に適用されるケースレベルの属性です。 この財務データは、支出分析やプロセス改善の優先順位付けに欠かせません。高額な注文には、より厳格な確認や異なる承認経路が必要になる場合があります。「Spend Analysis by Purchase Category」ダッシュボードで直接使用されるほか、「Spend by Non-Preferred Vendor Ratio」KPIの計算要素にもなります。
重要な理由
各購入の財務的な背景を示し、支出分析、高額注文の優先順位付け、財務的影響の評価を可能にします。
入手先
CoupaのPurchase Orderヘッダーにあり、通常は「Total」または「Grand Total」として表示されます。
例
1500.00250.7512500.50
|
|||
|
購買カテゴリ
PurchaseCategory
|
購入する商品またはサービスの分類です。IT HardwareやProfessional Servicesなどが該当します。 | ||
|
説明
Purchase Categoryは、CommodityまたはMaterial Groupとも呼ばれ、類似する購入品をまとめるための分類です。この構造化データにより、支出と調達プロセスを体系的に分析できます。 プロセスマイニングでは、フィルタリングとセグメント化に使える有効なディメンションです。「Spend Analysis by Purchase Category」ダッシュボードでは、支出パターンを分類して表示するために使用されます。また、複雑なサービスなどのカテゴリで、標準的なオフィス用品などのカテゴリよりサイクルタイムが長い、または変更率が高いといった傾向を明らかにできます。
重要な理由
カテゴリ別の支出とプロセスの分析を可能にし、調達パターンの特定、ベンダーとの交渉、プロセス管理の調整に役立ちます。
入手先
通常、CoupaのPurchase Order明細レベルにあり、Commodity Codeまたは購買カタログと関連付けられています。
例
ITハードウェアオフィス用品専門サービスマーケティング資料
|
|||
|
部門
Department
|
Purchase Orderの費用が計上される事業部門またはコストセンターです。 | ||
|
説明
Department属性は、購入を開始した組織単位、または費用を負担する組織単位を示します。通常、Purchase Orderの明細にある依頼者またはコストセンターの情報と関連付けられています。 このディメンションは、プロセス分析とKPIを分割するうえで欠かせません。組織内の各部門について、プロセス効率、コンプライアンス、支出パターンを比較できます。たとえば、「Spend Analysis by Purchase Category」ダッシュボードでは、Departmentを使って各事業部門の予算の使い方を表示します。
重要な理由
部門ごとにプロセスと支出の分析を絞り込み、比較できます。効率やコンプライアンスの違いを明らかにするのに役立ちます。
入手先
CoupaのPurchase Orderヘッダーまたは明細にあり、通常はCost Centerまたは組織単位と関連付けられています。
例
マーケティング情報技術業務財務
|
|||
|
依頼者名
RequesterName
|
商品またはサービスを最初に依頼した担当者の氏名です。 | ||
|
説明
Purchase Orderにつながる購買依頼を作成した従業員を識別する属性です。依頼者はニーズを持つ業務部門のユーザーであり、購買担当者や承認者とは異なる場合があります。 依頼者別にプロセスの動きを分析すると、特定のユーザーや部門に関するパターンを把握できます。「Purchase Order Change Analysis」ダッシュボードでは、依頼者によって注文変更の頻度に違いがあるかを確認できます。頻度が高い場合は、仕様要件に関するトレーニングの改善が必要である可能性があります。
重要な理由
購入の業務上の起点を特定し、依頼者単位で調達行動と内容の正確性を分析できます。
入手先
通常、元のPurchase Requisitionに保存され、CoupaでPurchase Orderに引き継がれます。
例
Alice CooperBob DylanCharlie Parker
|
|||
|
優先ベンダーかどうか
IsPreferredVendor
|
優先または戦略的なベンダーから購入したかどうかを示すブール型フラグです。 | ||
|
説明
Purchase Orderのベンダーが、事前承認された戦略的サプライヤーのリストに含まれているかどうかを示すフラグです。通常、ベンダー名またはIDを優先ベンダーのマスターリストと照合して判定します。 この属性は、戦略的ソーシングと支出管理の取り組みに欠かせません。「Spend by Non-Preferred Vendor Ratio」KPIの計算に使用され、優先ベンダー以外からの購入を監視・管理し、主要パートナーへの支出を集約して数量割引や有利な条件につなげるのに役立ちます。
重要な理由
優先サプライヤーとそれ以外のサプライヤーへの支出を追跡し、調達ポリシーのコンプライアンスと戦略的ソーシングの目標を監視できます。
入手先
Coupaの標準項目ではないことが多く、POのVendor IDを外部の優先ベンダーリストと比較して算出されます。
例
truefalse
|
|||
|
初回承認かどうか
IsFirstPassApproval
|
POの作成後、変更なしで承認された場合にtrueとなる計算フラグです。 | ||
|
説明
「Purchase Order Drafted」から「Purchase Order Approved」までの過程に、「Purchase Order Changed」または「Purchase Order Rejected」アクティビティが含まれていない場合、ブール型フラグをtrueに設定します。 この属性は、「First-Pass PO Approval Rate」KPIを直接測定します。割合が高いほど、初回処理が効率的かつ正確であることを示します。フラグがfalseとなったケースを分析すると、手戻りの理由を明らかにし、Purchase Orderの初期データ品質を改善できます。
重要な理由
作成から初回承認までのプロセス効率を直接測定し、手戻りなく処理された注文の割合を明らかにします。
入手先
データ変換時に、各PurchaseOrderNumberのイベント順序を分析して算出されます。
例
truefalse
|
|||
|
却下理由
RejectionReason
|
承認ステップで購買依頼またはPurchase Orderが却下された際に記録される理由です。 | ||
|
説明
承認者がPurchase Orderを却下する際、通常は理由を記載します。この属性には、「Incorrect budget code」や「Exceeds spending limit」などの説明文が保存されます。 却下理由を分析すると、手戻りやプロセス上の失敗の根本原因を直接把握できます。この定性的なデータから購買依頼プロセスにおけるよくある誤りを特定し、対象を絞ったトレーニングやシステム改善につなげられます。これにより、却下の再発を防ぎ、初回承認率を高めることができます。
重要な理由
Purchase Orderが却下される理由を具体的に把握し、プロセスの手戻りや遅延の根本原因に対処できます。
入手先
通常、Coupaの承認ワークフローにある「Purchase Order Rejected」または「Purchase Requisition Rejected」アクティビティに関連付けられたコメントまたはメモ項目に記録されます。
例
重複した申請予算未承認誤った仕入先を選択
|
|||
|
変更理由
ChangeReason
|
Purchase Orderの初回作成後に変更を加えた理由です。 | ||
|
説明
Purchase Orderを変更した理由を記録する属性です。「Quantity updated」や「Price correction」などが該当します。通常、ユーザーが「Purchase Order Changed」アクティビティを実行した際に、監査証跡へ記録されます。 注文変更の理由を把握することは、「Purchase Order Change Analysis」ダッシュボードの分析に欠かせません。サプライヤーの在庫問題など避けられない変更と、初回入力の誤りなど防止可能な変更を区別できます。これにより、注文内容の正確性を高め、「Purchase Order Change Rate」KPIを低減する取り組みを進められます。
重要な理由
PO変更の根本原因を明らかにし、初回から正確な注文を作成するための対策や、プロセスの手戻り削減につなげられます。
入手先
CoupaのPurchase Orderに関する変更イベントの監査ログまたはコメントに記録されていることが多い項目です。
例
仕入先による価格更新納期を調整品目コードを修正
|
|||
|
希望納入日
RequestedDeliveryDate
|
依頼者が商品またはサービスの納入を希望する日付です。 | ||
|
説明
購買依頼の作成時に業務ユーザーが指定する目標納入日です。注文をいつまでに履行してほしいかという、業務上の期待を表します。 この日付は、サプライヤーと社内のパフォーマンスを測定する重要な基準です。「Goods Receipt Posted」の実績日と比較して、「Supplier Delivery Date Adherence」KPIを直接算出します。「Delivery Date Variance and Returns」ダッシュボードでは、希望納入日と実際の納入日の差を可視化し、期待値の管理と予測精度の向上に役立てます。
重要な理由
ベンダーの納期遵守と社内の入荷処理の効率を測定するための、重要なパフォーマンス基準になります。
入手先
CoupaのPurchase Order明細にある標準項目です。
例
2023-11-152023-12-012024-01-10
|
|||
|
手戻りかどうか
IsRework
|
Purchase Orderに変更アクティビティが発生したかどうかを識別する計算フラグです。 | ||
|
説明
履歴に少なくとも1件の「Purchase Order Changed」イベントがあるPurchase Orderに対して、ブール型フラグをtrueに設定します。イベントログから算出されるケースレベルの属性です。 この属性により、「Purchase Order Change Rate」などのKPIを簡単に計算できます。手戻りのある注文とない注文を比較するためのフィルタリングやセグメント化も容易になり、変更がサイクルタイムやコストに与える影響を定量化できます。「Purchase Order Change Analysis」ダッシュボードの主要な構成要素です。
重要な理由
一度でも変更されたすべてのPurchase Orderを簡単に絞り込み、集計できるため、手戻りの分析を簡素化します。
入手先
データ変換時に、各PurchaseOrderNumberに「Purchase Order Changed」アクティビティが存在するかを確認して算出されます。
例
truefalse
|
|||
|
納入先
ReceivingLocation
|
商品を納入する倉庫やオフィスなどの物理的な場所です。 | ||
|
説明
Receiving Locationは、POで注文した商品の納入先を示します。特定の倉庫、工場、オフィスの住所などが該当します。 この属性を使うと、拠点ごとに物流と入荷処理のパフォーマンスを分析できます。「Goods Receipt Process Delays」ダッシュボードをこの属性で絞り込むことで、特定の拠点で入荷処理に時間がかかっているかを確認し、業務上の非効率やリソース不足の特定に役立てられます。
重要な理由
納入先別に入荷プロセスを分析し、倉庫、工場、オフィス間のパフォーマンスの違いを明らかにできます。
入手先
CoupaのPurchase Orderにある「Ship-To」住所の一部です。
例
倉庫A:シカゴ5号館:ロンドンオフィスフランクフルト工場
|
|||
|
納期どおりかどうか
IsDeliveryOnTime
|
商品が希望納入日以前に受領されたかどうかを示す計算フラグです。 | ||
|
説明
「Goods Receipt Posted」イベントのタイムスタンプと「RequestedDeliveryDate」を比較して算出するブール型属性です。受領日が希望納入日以前であればtrueになります。 このフラグは、「Supplier Delivery Date Adherence」KPIと「Delivery Date Variance and Returns」ダッシュボードを直接支えます。納期遵守の結果を明確な二値で示し、集計と可視化を容易にします。ベンダーや社内の入荷処理に関するパフォーマンス上の問題をすばやく特定できます。
重要な理由
納入パフォーマンスを明確な二値指標で示し、納期遵守KPIの計算と傾向分析を簡素化します。
入手先
データ変換時に、「RequestedDeliveryDate」と「Goods Receipt Posted」アクティビティのタイムスタンプを比較して算出されます。
例
truefalse
|
|||
|
購買依頼番号
PurchaseRequisitionNumber
|
Purchase Orderに先行する購買依頼を一意に識別する番号です。 | ||
|
説明
Purchase Orderを元の購買依頼に関連付ける属性です。1件の購買依頼から、1件以上のPurchase Orderが作成される場合があります。 この関連付けは、「Requisition-to-Order」サイクルタイム全体を分析するうえで欠かせません。購買依頼の作成イベントとPurchase Orderの作成・送信イベントを結び付けることで、依頼から履行まで、調達開始プロセス全体の効率を測定できます。
重要な理由
依頼フェーズと発注フェーズをつなぎ、購買依頼から発注までのサイクルタイムと変換率を分析できます。
入手先
通常、CoupaのPurchase Order明細にある参照項目で、元の購買依頼に関連付けられています。
例
PR-2023-00098PR-2023-00152PR-2023-00341
|
|||
|
通貨
Currency
|
Purchase Orderの金額に使用される通貨コードです。 | ||
|
説明
Total Order Amountがどの通貨(USD、EUR、GBPなど)で表示されているかを示す属性です。グローバルな組織で財務データを正しく解釈するために欠かせません。 多国籍企業では、通貨を考慮せずに支出を分析すると、誤った結論につながる可能性があります。この属性により、適切な通貨換算とダッシュボード内での一貫した財務レポートが可能になり、金額を同じ基準で比較できます。
重要な理由
通貨換算に必要な情報を提供し、多国籍環境での正確な財務分析とレポート作成を可能にします。
入手先
CoupaのPurchase Orderヘッダーにある標準項目です。
例
USDEURGBPJPY
|
|||
調達から支払いまで:発注書のアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
|
入荷を計上
|
商品を受け取り、検査し、受領したことを正式に確認するイベントです。在庫記録を更新し、この納品に関する仕入先の義務が果たされたことを示します。 | ||
|
重要な理由
仕入先のリードタイムの終了を示し、納期遵守を測定するために使用する重要なマイルストーンです。入荷計上の遅延は、実際の在庫水準の把握を妨げる可能性があります。
入手先
CoupaのReceiptオブジェクトに記録される主要な取引です。入荷のステータスが「Posted」または「Received」になった時刻からイベントを取得します。
取得
入荷取引がシステム上で確定した際に記録されます。
イベントタイプ
explicit
|
|||
|
発注書をキャンセル
|
発注書が完了する前にキャンセルされたことを示すアクティビティです。依頼が不要になった場合や、発注書を誤って作成した場合など、さまざまな段階でキャンセルが発生します。 | ||
|
重要な理由
プロセスの別の終了パターンとして、キャンセルを追跡することは、プロセスから脱落した案件を把握し、放棄された購買依頼の理由を特定するうえで重要です。
入手先
発注書オブジェクトのステータスが「Canceled」に変更されたことから推定します。このステータス変更の時刻をイベント時刻として使用します。
取得
ステータスが「Canceled」に変更された時刻から算出します。
イベントタイプ
inferred
|
|||
|
発注書をクローズ
|
発注書が完了したことを示す最後のアクティビティです。商品をすべて受領し、請求書もすべて処理され、今後の取引が見込まれない状態になると、発注書はクローズされたとみなされます。 | ||
|
重要な理由
発注書のライフサイクルを正式に終了するアクティビティです。クローズまでの時間を分析することで、最終照合や記録管理における非効率を明らかにできます。
入手先
発注書オブジェクトのステータスが「Closed」に変更されたことから推定します。このステータスは、受領と請求の許容差に関する業務ルールに基づき、Coupaが自動的に設定することがよくあります。
取得
ステータスが「Closed」に変更された時刻から算出します。
イベントタイプ
inferred
|
|||
|
発注書を仕入先へ送付
|
承認済みの発注書を仕入先へ正式に送信した時点を示すアクティビティです。たとえば、メールやCoupa Supplier Portalを通じて送信します。このイベントにより、発注書は社内文書から社外に対する確約へ移行します。 | ||
|
重要な理由
社内の申請から発注までのサイクルを終え、仕入先のリードタイムを開始する重要なマイルストーンです。社内の効率と仕入先のパフォーマンスを測定するうえで欠かせません。
入手先
多くの場合、発注書のステータスが「Ordered」または「Sent」に変更されたことから推定します。Coupaの発注書レコードに「last_exported_at」または「sent_to_supplier_at」という専用のタイムスタンプがある場合もあります。
取得
ステータスが「Ordered」に変更された時刻、または専用の送信タイムスタンプフィールドから算出します。
イベントタイプ
inferred
|
|||
|
発注書を承認
|
このマイルストーンは、発注書が社内の承認ワークフローを完了し、仕入先への発行が承認されたことを示します。通常は、複数のステップで構成されるプロセスの最終承認です。 | ||
|
重要な理由
発注書の承認サイクルタイムを計算し、承認のボトルネックを特定するうえで重要なマイルストーンです。コンプライアンスを確認する重要なチェックポイントでもあります。
入手先
Coupaの発注書の承認履歴ログから取得します。最終承認操作のタイムスタンプがイベント時刻になります。
取得
最終承認者がタスクを完了した際に、承認履歴へ記録されます。
イベントタイプ
explicit
|
|||
|
購買申請を作成
|
このアクティビティは、発注書に先立つ商品またはサービスの正式な依頼である購買申請の作成を示します。Coupaでは、ユーザーが新しい申請書を保存して送信した際に記録される明示的なイベントです。 | ||
|
重要な理由
調達プロセスの一般的な開始点となるこのアクティビティは、申請から発注までのサイクルタイム全体を測定し、上流プロセスの効率を把握するうえで欠かせません。
入手先
このイベントは、CoupaのPurchase Requisitionsオブジェクトまたはテーブルにおける作成記録に対応します。タイムスタンプは、「created_at」または同等のシステム生成の作成日フィールドで確認できます。
取得
新しい申請レコードの作成時に直接記録されます。
イベントタイプ
explicit
|
|||
|
サービス確認を入力
|
サービスに関する発注書では、商品入荷に相当するアクティビティです。発注書の条件に従ってサービスが提供されたことを確認します。 | ||
|
重要な理由
サービス確認を追跡することは、サービスへの支出を管理し、完了を確認した作業に対してのみ支払いが行われるようにするうえで欠かせません。
入手先
Coupaで発注書に関連付けられたサービス受領書またはサービスエントリーシートの作成または承認から取得します。
取得
サービスエントリーシートの作成および承認時に記録されます。
イベントタイプ
explicit
|
|||
|
仕入先が発注を確認
|
仕入先が発注書を受け取り、確認したことを示すイベントです。この確認は、Coupa Supplier Portal(CSP)のような仕入先ポータルを通じて電子的に記録されることがよくあります。 | ||
|
重要な理由
仕入先による確認により、発注が処理されていることを確実に把握でき、納品予測の精度向上とサプライチェーンの不確実性の低減につながります。
入手先
通常、仕入先がCoupa Supplier Portalで「Acknowledge」操作を行った場合、発注書にこの情報が記録されます。この操作のタイムスタンプを使用します。
取得
仕入先が仕入先ポータルで「Acknowledge」操作を行った際に記録されます。
イベントタイプ
explicit
|
|||
|
入荷処理を開始
|
入荷処理の開始を示すアクティビティです。たとえば、商品が実際に到着した際にCoupaで入荷伝票を作成する場合が該当します。商品はまだ正式に在庫へ計上されておらず、受領確認も完了していません。 | ||
|
重要な理由
入荷処理時間KPIの測定開始点となるイベントです。商品が荷受け場で待機している時間と、システム上の処理にかかる時間を区別できます。
入手先
「Draft」または「Pending」ステータスの入荷伝票の作成タイムスタンプから推定できます。入荷の最終計上より前に発生します。
取得
未計上状態にある入荷レコードの作成タイムスタンプから算出します。
イベントタイプ
inferred
|
|||
|
品質検査を実施
|
受け取った品目が品質検査を受け、合格したことを示すイベントです。会社のプロセスによっては、入荷計上後の独立したステップになる場合があります。 | ||
|
重要な理由
品質管理プロセスの効率を測定するうえで重要なアクティビティです。ここでの遅延は、入荷から使用可能になるまでの間にボトルネックを生む可能性があります。
入手先
入荷明細のステータス変更、またはCoupaの独立した検査オブジェクトに記録される場合があります。品質モジュールまたはカスタムワークフローを使用しているかどうかによって、利用できる情報は異なります。
取得
入荷のステータス変更、または関連する検査レコードのタイムスタンプから推定します。
イベントタイプ
inferred
|
|||
|
商品を返品
|
受領済みの商品を仕入先へ返送した際に記録されるアクティビティです。通常は、品質上の問題、破損、誤納品などが原因です。 | ||
|
重要な理由
返品を追跡することは、返品率の計算や、仕入先の品質または発注の正確性に関する問題の特定に欠かせません。返品率が高い場合、コストの大きいプロセス上の問題が潜んでいることがよくあります。
入手先
Coupaの「Return to Supplier」取引またはマイナスの入荷取引から取得します。この取引のタイムスタンプをイベント時刻として使用します。
取得
元の発注書または入荷に関連付けられた返品取引が作成された際に記録されます。
イベントタイプ
explicit
|
|||
|
発注書に対する請求書を受領
|
発注書を参照する仕入先請求書を受領し、登録したことを示すイベントです。調達から支払いまでのサイクルにおける、請求書処理と支払いの段階の開始点となります。 | ||
|
重要な理由
買掛金プロセスの一部ですが、請求書の受領と発注書を関連付けることで、取引ライフサイクルをエンドツーエンドで把握し、納品から請求までの間隔を分析できます。
入手先
CoupaのInvoice文書の作成タイムスタンプから取得します。請求書は対応する発注書番号と照合されます。
取得
発注書に関連付けられた請求書レコードの作成時に記録されます。
イベントタイプ
explicit
|
|||
|
発注書を作成
|
このイベントは、通常は承認済みの購買申請から、システム上で発注書文書を初めて作成したことを示します。この段階では、発注書は社内用の下書きであり、承認に提出されたり、仕入先へ送付されたりしていません。 | ||
|
重要な理由
このアクティビティを起点として、発注書承認サイクルタイムのKPIを測定します。発注書自体のライフサイクルにおける最初の正式なステップです。
入手先
Coupaにおける発注書レコードの作成タイムスタンプに対応します。通常は「created_at」のようなフィールドで確認できます。
取得
発注書レコードのシステム生成の作成タイムスタンプから取得します。
イベントタイプ
explicit
|
|||
|
発注書を却下
|
承認者が承認ワークフロー中に発注書を却下した際に発生するアクティビティです。通常、発注書は作成者に差し戻され、修正またはキャンセルが行われます。 | ||
|
重要な理由
却下を分析することで、データ品質の問題、ポリシー違反、トレーニング不足を明らかにできます。プロセスに大きな遅延を生む手戻りのループも把握できます。
入手先
Coupaの発注書の承認履歴ログに記録される明示的なイベントです。ログには、対応するタイムスタンプとともに「Reject」操作が表示されます。
取得
「Reject」ステータスとして承認履歴に記録されます。
イベントタイプ
explicit
|
|||
|
発注書を変更
|
このイベントは、発注書を最初に作成した後に行われた変更を示します。Coupaでは、発注書文書のバージョン管理によって変更を追跡することがよくあります。 | ||
|
重要な理由
変更を追跡することは、発注書変更率や不適合発注書率などのKPIに欠かせません。変更が頻繁に発生する場合、プロセスが安定していない、または初回の依頼が正確でない可能性があります。
入手先
発注書の異なるバージョンを追跡することで推定できます。最初のバージョンより大きいバージョン番号が新たに付与されている場合は変更を示し、新しいバージョンの作成日をイベントのタイムスタンプとして使用します。
取得
新しい発注書バージョンの作成タイムスタンプから推定します。
イベントタイプ
inferred
|
|||
|
発注書を提出
|
発注書を作成した後、正式に承認ワークフローへ提出します。これは、発注書を下書き状態から承認待ち状態へ移行させる、独立したユーザー操作です。 | ||
|
重要な理由
このイベントにより、下書きの作成時間と、発注書が実際に承認待ちになった時間を区別できます。ユーザーの行動とプロセス間の引き継ぎを、より正確に把握できます。
入手先
発注書オブジェクトのステータス変更から推定します。たとえば「draft」から「pending approval」への変更です。このステータス変更が発生した時刻を使用します。
取得
ステータスが「pending approval」に変更された時刻から算出します。
イベントタイプ
inferred
|
|||
|
購買申請を承認
|
購買申請は、発注書に変換する前に承認ワークフローを経ます。このイベントは申請の最終承認を示し、発注できる状態になったことを意味します。 | ||
|
重要な理由
申請の承認を追跡することで、発注前の段階にあるボトルネックを特定できます。ここでの遅延は、発注書を発行できるまでの時間に直接影響します。
入手先
通常は、Coupaの申請オブジェクトにある承認履歴から取得します。最終承認の操作には、対応するタイムスタンプとユーザー情報が記録されます。
取得
最終承認者が操作を行った際に、承認履歴へ記録されます。
イベントタイプ
explicit
|
|||
抽出ガイド
準備はできましたか?
このテンプレートを使ってデータを準備し、プロセスマイニングに利用できる状態にしてください。具体的な改善案を見つけ出し、調達から支払いまで:発注書プロセスの最適化を今日から始められます。
調達から支払いまでの発注書を最適化し、今日から効率を向上
調達から支払いまでのサイクルタイムを30%短縮し、早期に成果を確認できます。
クレジットカードは不要です。数分で設定できます。