調達から支払いまで:発注書のデータテンプレート
調達から支払いまで:発注書のデータテンプレート
- 推奨されるデータ属性
- 主なプロセスアクティビティ
- Coupaからのデータ抽出手順
調達から支払いまで:発注書の属性
| 名前 | 説明 | ||
|---|---|---|---|
|
アクティビティ
ActivityName
|
発注書のライフサイクルにおいて、特定の時点で発生したイベントまたはタスクの名前です。 | ||
|
説明
アクティビティ名は、発注書の承認や入荷の計上など、調達から支払いまでのプロセスにおける個々のステップを表します。これらのアクティビティの順序が、発注書ごとのプロセスフローを構成します。 この属性は、プロセスマイニングの基礎となります。プロセスマップの作成、プロセスのバリアントの発見、イベントの発生頻度や順序の分析に使われます。ボトルネック、手戻りのループ、標準的なプロセスフローからの逸脱を特定するのに役立ちます。たとえば、発注書の変更が発生する順序を分析すると、注文内容の正確性に関する非効率な点を明らかにできます。
重要な理由
プロセスの各ステップを示し、プロセスフローの可視化や、ボトルネック、手戻り、逸脱の特定に役立ちます。
入手先
Coupaの発注書オブジェクトに関連付けられたイベントログ、監査証跡、またはステータス変更記録から取得します。
例
購買依頼を承認発注書を申請入荷を計上発注書に対する請求書を受領
|
|||
|
発注書
PurchaseOrderNumber
|
発注書を一意に識別する番号で、プロセスの主要なケース識別子として使われます。 | ||
|
説明
発注書番号は、最初の依頼から商品またはサービスの受領確認まで、すべてのアクティビティを結び付ける中心的なケース識別子です。一意の発注書番号ごとに、調達プロセスの1つの実行を表します。 プロセスマイニング分析では、この属性を使って各購買の流れを最初から最後まで追跡します。プロセスマップの可視化、バリアントの特定、注文ごとのサイクルタイムなどの重要業績評価指標(KPI)の算出が可能になります。すべてのイベントと関連データをこの識別子にまとめることで、プロセス全体を一貫して把握できます。
重要な理由
購買のライフサイクル全体を追跡するうえで欠かせません。個々のプロセスの実行を再構成し、詳しく分析できます。
入手先
Coupaの発注書オブジェクトにある、標準的な主キーのフィールドです。
例
発注書-2023-00123発注書-2023-00456発注書-2023-00789
|
|||
|
開始時刻
EventTime
|
アクティビティまたはイベントが発生した正確な日時です。 | ||
|
説明
イベント時刻には、特定のアクティビティが実行された日時が記録されます。プロセス内の各アクティビティに、その発生時点を示すタイムスタンプがあります。 この属性は、プロセスマイニングで時間に基づく分析を行ううえで欠かせません。アクティビティ間のサイクルタイムの算出、プロセス所要時間の測定、遅延の特定に使われます。たとえば、発注書の下書き作成と発注書の承認のタイムスタンプの差から、発注承認のサイクルタイムを算出します。
重要な理由
各イベントの時間的な背景を示します。サイクルタイムの算出、実績の分析、ボトルネックの検出に欠かせません。
入手先
Coupaのイベントログまたは監査証跡にあり、通常は発注書に対する各ステータス変更や操作に関連付けられています。
例
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
|
|||
|
ユーザー
User
|
承認者や依頼者など、アクティビティを実行した人のユーザーIDまたは名前です。 | ||
|
説明
この属性は、プロセス内の特定のイベントを実行した担当者を示します。発注書の下書きを作成した人、承認したマネージャー、入荷を計上した担当者などが該当します。 ユーザーごとの実績を分析すると、トレーニングの必要性、実績の高い担当者、業務負荷の分布を把握できます。たとえば、発注承認のサイクルタイム実績ダッシュボードでは、この属性を使って承認者ごとの所要時間を比較し、プロセスのボトルネックとなっている可能性のある担当者を特定します。
重要な理由
個人または役割ごとにプロセスの実績を分析できます。ボトルネック、トレーニングの機会、リソース配分の問題を特定するのに役立ちます。
入手先
Coupaの発注書の監査証跡または履歴ログにある各イベントに関連付けられています。「作成者」「承認者」「更新者」などのフィールドが一般的な情報源です。
例
山田太郎a.smithm.jones
|
|||
|
仕入先名
VendorName
|
商品やサービスの購入先となる仕入先の名前です。 | ||
|
説明
仕入先名は、発注書に記載された商品を供給する外部の取引先を示します。調達分析の基本となる情報です。 仕入先別にプロセスの実績を分析することは、仕入先との関係管理に欠かせません。「仕入先リードタイムの実績」の評価、「入庫プロセスの遅延」の特定、そして「返品率」による仕入先品質の評価に役立ちます。また、「非優先仕入先への支出比率」という重要業績評価指標(KPI)の算出にも使われます。
重要な理由
仕入先の実績を分析し、仕入先の選定や条件交渉の改善、実績の高い仕入先と低い仕入先の特定に役立ちます。
入手先
Coupaの発注書ヘッダーにある標準項目で、仕入先マスターデータに関連付けられています。
例
グローバルオフィス用品テックソリューションズ社アドバンスト・インダストリアル・パーツクリエイティブ・マーケティング・エージェンシー
|
|||
|
発注総額
TotalOrderAmount
|
発注書の合計金額です。 | ||
|
説明
この属性は、発注書に記載されたすべての商品とサービスの合計金額を、特定の通貨で表します。注文全体に適用されるケースレベルの属性です。 この財務データは、支出分析やプロセス改善の優先順位付けに欠かせません。金額の大きい注文には、より慎重な確認や別の承認経路が必要になる場合があります。「購入カテゴリ別支出分析」ダッシュボードで直接使われるほか、「非優先仕入先への支出比率」という重要業績評価指標(KPI)の算出にも使われます。
重要な理由
購入ごとの財務状況を把握できるため、支出分析や高額注文の優先順位付け、財務への影響の評価に役立ちます。
入手先
Coupaの発注書ヘッダーにあり、通常は「合計」または「総合計」と表示されます。
例
1500.00250.7512500.50
|
|||
|
購入カテゴリ
PurchaseCategory
|
購入する商品やサービスの分類です。たとえば、ITハードウェアや専門サービスなどがあります。 | ||
|
説明
購入カテゴリは、商品分類や品目グループとも呼ばれ、種類の近い購入をまとめるための分類です。この構造化データを使うと、支出や調達プロセスを体系的に分析できます。 プロセスマイニングでは、分析対象の絞り込みや分類に役立つディメンションです。「購入カテゴリ別支出分析」ダッシュボードでは、この属性を使って支出傾向を分類します。また、複雑なサービスなどのカテゴリで、一般的なオフィス用品などと比べてサイクルタイムや変更率が高くなっていないかを確認できます。
重要な理由
カテゴリ別に支出やプロセスを分析し、調達の傾向を把握できます。仕入先との交渉や、カテゴリに応じたプロセス管理にも役立ちます。
入手先
通常、Coupaの発注書明細にあり、品目コードや購買カタログに関連付けられています。
例
ITハードウェアオフィス用品専門サービスマーケティング資料
|
|||
|
部門
Department
|
発注書の費用が計上される事業部門またはコストセンターです。 | ||
|
説明
部門属性は、購入を開始した組織単位、または費用を負担する組織単位を示します。多くの場合、発注書の明細に記載された依頼者やコストセンターの情報に関連付けられています。 このディメンションは、プロセス分析や重要業績評価指標(KPI)を分類するうえで欠かせません。部門ごとにプロセスの効率性、コンプライアンス、支出傾向を比較できます。たとえば、「購入カテゴリ別支出分析」ダッシュボードでは、部門を使って各事業部門の予算の支出状況を確認できます。
重要な理由
事業部門ごとにプロセスや支出の分析対象を絞り込んで比較できるため、効率性やコンプライアンスの違いを把握できます。
入手先
Coupaの発注書ヘッダーまたは明細にあり、コストセンターや組織単位に関連付けられていることが一般的です。
例
マーケティング情報技術オペレーション財務
|
|||
|
依頼者名
RequesterName
|
商品やサービスを最初に依頼した人の名前です。 | ||
|
説明
この属性は、発注書につながる購買依頼を作成した従業員を示します。依頼者は購入の必要性を感じている業務担当者であり、購買担当者や承認者とは異なる場合があります。 依頼者別にプロセスの動きを分析すると、特定のユーザーや部門に関する傾向を把握できます。「発注書変更分析」ダッシュボードでは、依頼者によって注文の変更頻度に差があるかを確認できます。変更頻度が高い場合は、仕様要件に関するトレーニングの見直しが必要な可能性があります。
重要な理由
購入の発生元となった業務部門を特定し、依頼者ごとの調達行動や依頼内容の正確性を分析できます。
入手先
通常、元の購買依頼に記録され、Coupaで発注書に引き継がれます。
例
アリス・クーパーボブ・ディランチャーリー・パーカー
|
|||
|
優先仕入先かどうか
IsPreferredVendor
|
優先仕入先または戦略的仕入先から購入したかどうかを示す真偽値です。 | ||
|
説明
このフラグは、発注書の仕入先が事前承認済みの戦略的仕入先リストに含まれているかを示します。通常、仕入先名またはIDを優先仕入先のマスターリストと照合して判定します。 この属性は、戦略的な調達や支出管理の取り組みに欠かせません。「非優先仕入先への支出比率」という重要業績評価指標(KPI)の算出に使われます。この指標により、組織は規定外の購買を監視・抑制し、主要な取引先に支出を集約して、数量割引やより有利な条件につなげることができます。
重要な理由
優先仕入先と非優先仕入先への支出を追跡し、調達方針のコンプライアンスと戦略的調達の目標を確認できます。
入手先
Coupaの標準項目ではないことが多く、発注書(PO)の仕入先IDを外部の優先仕入先リストと照合して算出します。
例
truefalse
|
|||
|
初回承認かどうか
IsFirstPassApproval
|
下書きの作成後、変更なしで発注書が承認された場合にtrueとなる計算フラグです。 | ||
|
説明
発注書が「発注書下書き」から「発注書承認」へ進む間に、「発注書変更」や「発注書却下」のアクティビティがなければ、この真偽値フラグにtrueが設定されます。 この属性は、「発注書初回承認率」という重要業績評価指標(KPI)を直接測定します。数値が高い場合、初回処理が効率的かつ正確であることを示します。このフラグがfalseのケースを分析すると、手戻りの原因を特定し、発注書の初期データ品質を高めるのに役立ちます。
重要な理由
作成から承認までの初回処理の効率を直接測定し、手戻りなく進んだ注文の割合を把握できます。
入手先
データ変換時に、各PurchaseOrderNumberのイベント順序を分析して算出します。
例
truefalse
|
|||
|
却下理由
RejectionReason
|
承認段階で購買依頼または発注書が却下された際に記録される理由です。 | ||
|
説明
承認者が発注書を却下する際、理由を記載することがあります。この属性には、「予算コードが正しくない」「支出上限を超えている」などの説明が記録されます。 却下理由を分析すると、手戻りやプロセス上の問題の根本原因を直接把握できます。この定性的なデータから、購買依頼でよくある誤りを特定し、対象を絞ったトレーニングやシステムの改善につなげられます。これにより、却下の再発を防ぎ、初回承認率の向上を目指せます。
重要な理由
発注書が却下される理由を具体的に把握し、手戻りや遅延の根本原因への対策に役立てられます。
入手先
通常、Coupaの承認ワークフローにある「発注書却下」または「購買依頼却下」アクティビティに関連付けられたコメントやメモに記録されます。
例
依頼の重複予算が未承認仕入先の選択誤り
|
|||
|
変更理由
ChangeReason
|
発注書の作成後に変更が行われた理由です。 | ||
|
説明
この属性には、「数量を更新」「価格を修正」など、発注書を変更した理由が記録されます。ユーザーが「発注書変更」アクティビティを実行した際、監査証跡に記録されることがよくあります。 注文が変更された理由を把握することは、「発注書変更分析」ダッシュボードでの分析に欠かせません。仕入先の在庫不足など避けられない変更と、初回入力の誤りなど防止できる変更を区別できます。これにより、注文内容の正確性を高め、「発注書変更率」という重要業績評価指標(KPI)を下げるための取り組みを進められます。
重要な理由
発注書の変更原因を把握し、初回注文の正確性向上や手戻りの削減に向けた対策を講じられます。
入手先
Coupaの発注書に関する変更イベントの監査ログやコメントに記録されていることがよくあります。
例
仕入先による価格改定納品日の変更品目コードの修正
|
|||
|
希望納品日
RequestedDeliveryDate
|
依頼者が商品やサービスの納品を希望する日付です。 | ||
|
説明
この属性は、購買依頼の作成時に業務担当者が指定した目標納品日です。注文がいつまでに納品されるべきかという業務上の期待を示します。 この日付は、仕入先と社内の実績を測る重要な基準です。実際の「入庫計上」日と比較し、「仕入先納品日の遵守率」という重要業績評価指標(KPI)の算出に直接使われます。「納品日の差異と返品」ダッシュボードでは、希望日と実際の納品日の差を可視化し、期待値の管理や予測の改善に役立てます。
重要な理由
仕入先の納期遵守状況と社内の入庫処理の効率を測るための基準となります。
入手先
Coupaの発注書明細にある標準項目です。
例
2023-11-152023-12-012024-01-10
|
|||
|
手戻りの有無
IsRework
|
発注書に変更アクティビティがあったかを示す計算フラグです。 | ||
|
説明
この真偽値フラグは、履歴に「発注書変更」イベントが1件以上ある発注書にtrueが設定されます。イベントログから算出されるケースレベルの属性です。 この属性を使うと、「発注書変更率」などの重要業績評価指標(KPI)を簡単に算出できます。データを絞り込んで分類し、手戻りのある注文とない注文のプロセスを比較することで、変更がサイクルタイムやコストに与える影響を定量化できます。「発注書変更分析」ダッシュボードの主要な構成要素です。
重要な理由
一度でも変更された発注書を簡単に絞り込み、集計できるため、手戻りの分析が容易になります。
入手先
データ変換時に、各PurchaseOrderNumberについて「発注書変更」アクティビティの有無を確認して算出します。
例
truefalse
|
|||
|
納品先
ReceivingLocation
|
商品を納品する倉庫やオフィスなどの所在地です。 | ||
|
説明
納品先は、発注書(PO)に記載された商品の納入場所を示します。特定の倉庫、工場、オフィスの住所などが該当します。 この属性を使って、拠点ごとの物流や入庫処理の実績を分析できます。「入庫プロセスの遅延」ダッシュボードでこの属性を指定すると、入荷処理に時間がかかっている拠点を特定できます。特定拠点の業務効率やリソースの制約を把握するのに役立ちます。
重要な理由
納品先ごとに入庫プロセスを分析し、倉庫、工場、オフィス間の実績の違いを把握できます。
入手先
Coupaの発注書にある「納品先」住所の一部です。
例
倉庫A-シカゴビル5-ロンドンオフィスフランクフルト工場
|
|||
|
納期どおりに納品されたか
IsDeliveryOnTime
|
希望納品日までに商品が入庫したかを示す計算フラグです。 | ||
|
説明
この真偽値属性は、「入庫計上」イベントのタイムスタンプと「希望納品日」を比較して算出します。入庫日が希望納品日と同日またはそれ以前の場合、trueが設定されます。 このフラグは、「仕入先納品日の遵守率」という重要業績評価指標(KPI)と「納品日の差異と返品」ダッシュボードを直接支えます。納期どおりに納品されたかを明確な二値で示すため、集計や可視化が容易です。仕入先や社内の入庫プロセスに関する問題をすばやく特定できます。
重要な理由
納品実績を明確な二値で示し、納期遵守に関する重要業績評価指標(KPI)の算出や推移分析を簡単にします。
入手先
データ変換時に、「希望納品日」と「入庫計上」アクティビティのタイムスタンプを比較して算出します。
例
truefalse
|
|||
|
購買依頼番号
PurchaseRequisitionNumber
|
発注書の作成元となった購買依頼を識別する一意の番号です。 | ||
|
説明
この属性は、発注書とその作成元の購買依頼を関連付けます。1件の購買依頼から、複数の発注書が作成される場合もあります。 この関連付けは、「依頼から発注まで」のサイクルタイムを分析するうえで欠かせません。購買依頼の作成イベントを発注書の作成・送信イベントと結び付けることで、依頼から納品まで、調達開始から完了までの効率を測定できます。
重要な理由
プロセスの依頼段階と発注段階を結び付け、依頼から発注までのサイクルタイムや転換率を分析できます。
入手先
通常、Coupaの発注書明細にある参照項目で、元の購買依頼に関連付けられています。
例
PR-2023-00098PR-2023-00152PR-2023-00341
|
|||
|
通貨
Currency
|
発注書の金額に使われている通貨コードです。 | ||
|
説明
この属性は、発注総額の通貨(USD、EUR、GBPなど)を示します。グローバルに事業を展開する組織で、財務データを正しく解釈するために欠かせません。 多国籍企業では、通貨を考慮せずに支出を分析すると、誤った判断につながるおそれがあります。この属性を使うことで、適切な通貨換算とダッシュボード上での一貫した財務報告が可能になり、同じ基準で金額を比較できます。
重要な理由
通貨換算に必要な情報を提供し、多国籍の事業環境でも正確な財務分析と報告を支えます。
入手先
Coupaの発注書ヘッダーにある標準項目です。
例
USDEURGBPJPY
|
|||
調達から支払いまで:発注書のアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
|
入荷を計上
|
商品を受領し、検査して、受け入れたことを正式に確認するイベントです。在庫記録が更新され、この納品に関するサプライヤーの義務が果たされたことを示します。 | ||
|
重要な理由
この重要なマイルストーンは、サプライヤーのリードタイムの終了を示し、納期の遵守状況を測定するために使われます。入荷計上が遅れると、実際の在庫状況を把握しにくくなる場合があります。
入手先
Coupaの入荷オブジェクトに記録される主要な取引です。入荷のステータスが「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の購買依頼オブジェクトまたはテーブルに記録された作成履歴に対応します。タイムスタンプは、「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の請求書文書の作成タイムスタンプから取得します。請求書は、対応する発注書番号と照合されます。
記録
発注書に関連付けられた請求書レコードの作成時に記録されます。
イベントタイプ
explicit
|
|||
|
発注書の下書きを作成
|
このイベントは、通常、承認済みの購買依頼をもとに、システムで発注書を初めて作成したことを示します。この段階では発注書は社内用の下書きであり、承認申請もサプライヤーへの送付もまだ行われていません。 | ||
|
重要な理由
このアクティビティを起点に、発注承認のサイクルタイムを測定します。発注書のライフサイクルにおける最初の正式なステップです。
入手先
Coupaの発注書レコードの作成タイムスタンプに対応します。通常、「created_at」などのフィールドで確認できます。
記録
発注書レコードのシステム生成の作成タイムスタンプから取得します。
イベントタイプ
explicit
|
|||
|
発注書を却下
|
承認ワークフロー中に承認者が発注書を却下したときに発生するアクティビティです。通常、発注書は修正または取り消しのため、作成者に差し戻されます。 | ||
|
重要な理由
却下を分析すると、データ品質の問題、方針違反、トレーニング不足などを明らかにできます。また、大幅な遅延につながる手戻りのループも把握できます。
入手先
Coupaの発注書の承認履歴ログに明示的なイベントとして記録されます。ログには、対応するタイムスタンプとともに「Reject」操作が表示されます。
記録
「Reject」ステータスとして承認履歴に記録されます。
イベントタイプ
explicit
|
|||
|
発注書を変更
|
このイベントは、発注書の最初の下書き作成後に行われた変更を示します。Coupaでは、発注書のバージョン管理を通じて変更が記録されることがよくあります。 | ||
|
重要な理由
発注書変更率や規定外発注率などの重要業績評価指標(KPI)を把握するには、変更の追跡が欠かせません。頻繁な変更は、プロセスの不安定さや初期依頼の不正確さを示している可能性があります。
入手先
発注書の異なるバージョンを追跡して推定できます。最初のバージョンより大きい新しいバージョン番号は、それぞれ変更を示します。新しいバージョンの作成日時をイベントのタイムスタンプとして使用します。
記録
新しい発注書バージョンの作成タイムスタンプから推定します。
イベントタイプ
inferred
|
|||
|
発注書を申請
|
発注書の下書きを作成した後、正式に承認ワークフローへ申請します。これはユーザーによる独立した操作で、発注書の状態を下書きから承認待ちへ変更します。 | ||
|
重要な理由
このイベントにより、下書きの作成時間と発注書が実際に承認待ちになった時間を区別できます。ユーザーの行動やプロセスの引き継ぎを、より明確に把握できます。
入手先
発注書オブジェクトのステータス変更から推定します。たとえば、「draft」から「pending approval」への変更が該当します。このステータス変更のタイムスタンプを使用します。
記録
「pending approval」へのステータス変更のタイムスタンプから算出します。
イベントタイプ
inferred
|
|||
|
購買依頼を承認
|
購買依頼は、発注書に変換される前に承認ワークフローを経ます。このイベントは依頼の最終承認を示し、発注できる状態になったことを表します。 | ||
|
重要な理由
購買依頼の承認状況を追跡すると、発注前の段階にあるボトルネックを特定できます。この段階での遅れは、発注書を発行できる時期に直接影響します。
入手先
通常、Coupaの購買依頼オブジェクトにある承認履歴から取得します。最終承認の操作には、対応するタイムスタンプとユーザーが記録されます。
記録
最終承認者が操作した時点で、承認履歴に記録されます。
イベントタイプ
explicit
|
|||
データ抽出ガイド
始める準備はできましたか?
このテンプレートを使ってプロセスマイニング用のデータを準備し、具体的な改善案を見つけましょう。調達から支払いまでの発注書プロセスの最適化を、今すぐ始めてください。
調達から支払いまでの発注書プロセスを最適化し、今すぐ効率を高めましょう
調達から支払いまでのサイクルタイムを30%短縮し、すぐに効果を確認しましょう。
クレジットカードは不要です。数分で設定できます。