調達から支払いまで:発注書のデータテンプレート
調達から支払いまで:発注書のデータテンプレート
- 収集を推奨する属性
- 追跡すべき主要アクティビティ
- NetSuiteからの抽出方法
調達から支払いまで:発注書の属性
| 名前 | 説明 | ||
|---|---|---|---|
|
アクティビティ名
ActivityName
|
Purchase Orderプロセス内で発生した、特定の業務イベントまたはステップの名称です。 | ||
|
説明
この属性は、Purchase Orderのライフサイクルにおける具体的なアクションやステータス変更を表します。たとえば、「Purchase Order Created」、「Purchase Order Approved」、「Bill Payment Made」などです。これらのアクティビティがプロセスマップのノードになります。 これらのアクティビティの順序と頻度を分析することが、プロセスマイニングの中心です。プロセスフローを可視化し、一般的な経路とまれな経路(バリアント)を特定するとともに、ボトルネックや標準手順からの逸脱を明らかにできます。
重要な理由
プロセスマップ上のステップを定義し、プロセスフロー、バリアント、適合状況を可視化・分析できるようにします。
入手先
通常、取引タイプとステータスフィールド(例:「Order Status」)の組み合わせ、またはNetSuiteのシステム監査証跡ログから生成されます。
例
Purchase Orderの作成Purchase Orderの承認Item Receiptの作成Purchase OrderからのBill作成
|
|||
|
イベント時刻
EventTime
|
アクティビティが発生した正確な日時です。 | ||
|
説明
このタイムスタンプは、特定のアクティビティが実行された正確な時点を示します。プロセスマイニングにおけるパフォーマンスと所要時間の分析すべての時間的基盤です。 イベント時刻を使って、ケース内のアクティビティを時系列に並べ、ステップ間の所要時間を算出し、ケース全体のサイクル時間を測定します。ボトルネックの特定、待ち時間の測定、サービスレベル合意に対するパフォーマンスの分析に欠かせないデータです。
重要な理由
サイクル時間や所要時間など、時間に基づくすべての指標を算出するために欠かせない属性です。プロセスの遅延を特定する基盤になります。
入手先
各取引またはステータス変更に紐付くタイムスタンプです。NetSuiteでは、「Date Created」などのフィールドやシステム監査証跡ログに記録されています。
例
2023-10-26T09:00:00Z2023-10-26T11:30:00Z2023-10-27T14:45:00Z
|
|||
|
発注書
PurchaseOrder
|
調達ライフサイクルを追跡するための、Purchase Order固有の識別子です。主要なケースIDとして使用されます。 | ||
|
説明
Purchase Order番号は、最初の作成から最終的な支払いとクローズまで、関連するすべてのアクティビティを結び付ける中心的な識別子です。それぞれ異なるPurchase Order番号が、調達プロセスの1つのインスタンスを表します。 プロセスマイニングでは、この属性を使って関連するすべてのイベントを1つのケースにまとめます。各Purchase Orderの経過を分析することで、エンドツーエンドのプロセスを明確に把握し、バリアントを特定し、ケース単位の総サイクル時間などの指標を算出できます。
重要な理由
個々のPurchase Orderのライフサイクル全体を再構築し、分析するために欠かせないケース識別子です。
入手先
通常、NetSuiteのPurchase Orderレコードにある主要な取引識別子です。「Transaction ID」または「PO #」と呼ばれることもあります。
例
PO-001254PO-001299PO-001357
|
|||
|
ソースシステム
SourceSystem
|
データを抽出したシステムです。 | ||
|
説明
プロセスデータの取得元を示す属性です。このビューでは、値は常に「NetSuite」になります。 複数のシステムからデータを統合する大規模なプロセスマイニングでは、データの系譜、トラブルシューティング、システム固有の動作を理解するうえで重要なフィールドです。各データがどこから取得されたかを明確にできます。
重要な理由
プロセスデータの取得元を明確にする重要なデータ系譜情報を提供します。特に、複数の統合システムがある環境で役立ちます。
入手先
データの抽出・変換処理中に追加される固定値(「NetSuite」)です。
例
NetSuite
|
|||
|
最終データ更新日時
LastDataUpdate
|
このイベントのデータがソースシステムから最後に更新された時点を示すタイムスタンプです。 | ||
|
説明
データが最後に抽出または更新された日時を記録する属性です。分析対象データの鮮度を把握するための情報になります。 最終更新時刻を把握することは、生成された分析結果の適時性を理解するうえで重要です。アナリストや業務ユーザーは、最新のプロセスデータを確認しているかどうかを判断できます。特に、業務監視用のダッシュボードでは欠かせません。
重要な理由
データの鮮度を示します。分析やダッシュボードが最新情報に基づいていることを確認するうえで重要です。
入手先
データの抽出、変換、ロード(ETL)処理中に生成・追加されるタイムスタンプです。
例
2024-05-21T02:00:00Z
|
|||
|
Purchase Orderのステータス
PurchaseOrderStatus
|
Purchase Orderの現在または最終的なステータスです。 | ||
|
説明
Purchase Orderが特定の時点でどの状態にあるかを示す属性です。「Pending Approval」、「Fully Billed」、「Closed」などが該当します。概念上の「ActivityName」の多くは、この属性から生成されます。 ステータス別に分析すると、却下されたPurchase Orderと承認されたPurchase Orderの件数や、未完了のPurchase Orderの件数など、発注の結果を把握できます。「PO承認失敗率」などのKPIや、完了状態に基づくケースのフィルタリングにも役立ちます。
重要な理由
POの状態をスナップショットとして提供し、却下やクローズなどの結果を分析できます。承認失敗に関するKPIにも役立ちます。
入手先
NetSuiteのPurchase Order取引レコードにある「Status」フィールドです。
例
上長承認待ち受領待ち全額請求済みクローズ済み却下済み
|
|||
|
ユーザー名
UserName
|
アクティビティを実行したユーザーの名前です。 | ||
|
説明
Purchase Orderの承認やBillの作成など、特定のプロセスステップを実行した従業員またはシステムユーザーを示す属性です。プロセスにおける人またはシステムのリソース情報を提供します。 ユーザー別にアクティビティを分析すると、業務負荷の分布やトレーニングの必要性を把握し、不規則な処理を見つけられます。また、POの変更や承認など、重要なアクションを誰が実行したかを追跡できるため、コンプライアンスの監視にも欠かせません。
重要な理由
アクティビティを特定のユーザーに紐付け、業務負荷、パフォーマンス、権限ポリシーの遵守状況を分析できます。
入手先
取引レコードの「System Notes」または監査証跡サブタブで確認できます。変更を行ったユーザーが記録されています。
例
Alice JohnsonBob Williamsシステム自動処理
|
|||
|
仕入先名
VendorName
|
商品またはサービスの購入先である仕入先の名前です。 | ||
|
説明
Purchase Orderの外部仕入先を示す属性です。仕入先との関係とパフォーマンスを分析するための重要な切り口になります。 仕入先名は、「仕入先納品パフォーマンス」ダッシュボードと関連KPIに欠かせません。仕入先ごとにプロセスを分け、リードタイム、納期遵守率、品質検査の結果を比較できます。信頼性の高い仕入先とパフォーマンスに課題のある仕入先の特定にも役立ちます。
重要な理由
仕入先ごとのパフォーマンスを分析できます。納期や信頼性を把握できるため、サプライチェーンの最適化に役立ちます。
入手先
NetSuiteのPurchase Orderレコードのメインタブにある「Vendor」または「Supplier」フィールドに対応します。
例
グローバルオフィス用品Tech Solutions Inc.Creative Marketing Agency
|
|||
|
合計金額
TotalAmount
|
Purchase Orderの金銭的な合計金額です。 | ||
|
説明
Purchase Orderに含まれるすべての商品とサービスの合計コストを表す属性です。調達分析における基本的な財務指標です。 合計金額別にプロセス指標を分析すると、高額なPOほど承認に時間がかかる、変更が多いといった重要な傾向を把握できます。プロセスの非効率が財務に与える影響を理解し、改善施策の優先順位を付けるうえで欠かせません。
重要な理由
調達プロセスを財務面から分析し、発注書金額がサイクルタイム、承認経路、コンプライアンスに与える影響の特定に役立ちます。
入手先
NetSuiteの発注書レコードの概要セクションにある「Total」フィールドに対応します。
例
500.001250.7515000.00
|
|||
|
購買カテゴリ
PurchaseCategory
|
購入する商品またはサービスの分類です。ITハードウェア、マーケティングサービス、オフィス用品などがあります。 | ||
|
説明
この属性は発注書の明細を分類し、支出の種類ごとにグループ化して分析できるようにします。NetSuiteでは、カスタム分類フィールドまたはセグメントとして実装されることが一般的です。 購買カテゴリ別の分析は、「購買カテゴリ効率」ダッシュボードに欠かせません。特定の購入タイプでサイクルタイムが長い、変更率が高い、またはコンプライアンス上の問題が多いかどうかを明らかにし、支出領域ごとの改善を可能にします。
重要な理由
支出カテゴリ別にプロセス効率を分析し、非効率またはコンプライアンス違反が多い購入タイプの特定に役立ちます。
入手先
カスタムフィールドの場合もあれば、「Class」のような標準分類セグメント、または発注書のヘッダーや明細レベルに適用されたカスタムセグメントの場合もあります。詳しくはNetSuiteのドキュメントをご確認ください。
例
ITハードウェア専門サービスオフィス用品ソフトウェアライセンス
|
|||
|
部門名
DepartmentName
|
Purchase Orderに関連付けられた部門の名前です。 | ||
|
説明
購買を開始した、または購買に対して財務上の責任を持つ業務部門またはコストセンターを表す属性です。組織構造に基づいてプロセスデータをフィルタリングし、セグメント化できます。 部門別にプロセスを分析することで、部門ごとのボトルネックを特定し、異なる事業部門間の効率を比較し、支出パターンを把握できます。「部門別ボトルネック分析」などのダッシュボードを直接支援します。
重要な理由
部門別のプロセス分析を可能にし、部門固有のボトルネック、非効率、支出パターンの特定に役立ちます。
入手先
NetSuiteのPurchase Orderレコードのヘッダーまたは明細にある標準フィールドです。
例
財務ITサービスマーケティング業務
|
|||
|
イベント終了時刻
EventEndTime
|
アクティビティが完了した正確な日時です。 | ||
|
説明
このタイムスタンプは、アクティビティの完了時点を示します。Start Timeと組み合わせることで、イベントの処理時間を定義できます。瞬時に完了するイベントでは、End TimeがStart Timeと同じになる場合があります。 この属性は、特定のタスクにかかった正確な時間、つまり処理時間を算出するために欠かせません。タスクを実際に処理していた時間と、次のステップを待っていた時間を区別できるため、詳細なボトルネック分析に役立ちます。
重要な理由
アクティビティの正確な処理時間を算出し、実作業時間と待機時間を区別できます。
入手先
測定可能な所要時間があるアクティビティでは、別のフィールドに記録されるか、監査ログから算出されます。推定が必要な場合や、Start Timeと同じ値になる場合もあります。
例
2023-10-26T09:05:12Z2023-10-26T11:30:45Z2023-10-27T15:00:00Z
|
|||
|
却下理由
RejectionReason
|
承認プロセス中に発注書が却下された理由です。 | ||
|
説明
発注書が却下された場合、この属性には「予算超過」「仕入先の誤り」「ポリシー違反」など、却下の具体的な理由が示されます。この情報は、承認に失敗した原因を把握するうえで重要です。 この属性は、「発注書の却下・再申請率」ダッシュボードに直接利用できます。却下理由を分析することで、トレーニング不足やポリシーの不明確さなど、発注書作成時にエラーが発生する主な原因を特定し、却下に伴う手戻りを減らすための是正措置を講じられます。
重要な理由
発注書が承認されない理由を明らかにし、却下率の低減と初回承認率の向上に向けた対策を可能にします。
入手先
この情報は通常、承認ワークフローの一環として、却下イベントのメモ欄またはカスタムの「却下理由」フィールドに記録されます。NetSuiteのドキュメントをご確認ください。
例
部門予算を超過優先仕入先以外を選択明細の説明が不完全
|
|||
|
変更理由
ChangeReason
|
作成後に発注書が変更された理由です。 | ||
|
説明
この属性は、発注書の変更理由を記録します。たとえば、「価格更新」、「数量変更」、「納期変更」などです。変更の背景を把握するうえで重要であり、再作業の要因を分析できます。 「発注書変更分析」ダッシュボードの重要な属性です。変更理由ごとの発生頻度を分析すると、初期要件の不正確さや仕入先価格の変動など、プロセスが不安定になる根本原因を特定できます。
重要な理由
発注書が変更された理由を把握するための重要な情報を提供し、発注書の変更率全体を下げる根本原因分析に役立ちます。
入手先
承認済みの発注書をユーザーが編集する際に入力を必須とするカスタムフィールド、または変更イベントの「Memo」フィールドである可能性があります。NetSuiteのドキュメントを確認してください。
例
品目数量が不正確仕入先による価格変更納品要件を更新
|
|||
|
希望納入日
RequestedDeliveryDate
|
事業部門が仕入先に商品またはサービスの納入を希望する日付です。 | ||
|
説明
購買プロセスで設定された納入目標日です。実際の納入実績を測定する基準になります。 「仕入先納入遵守率」KPIの算出に欠かせません。「希望納入日」と実際の「入荷登録日時」を比較することで、仕入先が納入約束を守っているかを分析できます。この結果は、「仕入先納入実績」ダッシュボードの重要な入力情報になります。
重要な理由
仕入先の納期遵守実績を測定する基準となります。サプライチェーン管理における重要なKPIです。
入手先
カスタムフィールドの場合もあれば、発注書の明細にある「Expected Receipt Date」の場合もあります。詳しくはNetSuiteのドキュメントをご確認ください。
例
2023-11-152023-12-012024-01-10
|
|||
|
手戻りあり
IsRework
|
却下後の2回目の承認など、アクティビティが手戻りに該当するかどうかを示すフラグです。 | ||
|
説明
この計算された真偽値の属性は、プロセスのループや同じ手順の繰り返しを示すアクティビティでtrueになります。たとえば、同じケース内で「発注書却下」アクティビティの後に「発注書承認」アクティビティが発生した場合、「発注書承認」は手戻りとしてフラグ付けされます。 この属性は、プロセス上の摩擦や非効率を定量化するうえで欠かせません。手戻りループを簡単に分析できるため、「発注書の却下・再申請率」を測定し、初回で正しく完了していないプロセスを明らかにできます。
重要な理由
手戻りループに含まれるアクティビティを明示的にフラグ付けし、プロセスの非効率を定量化しやすくします。これにより、問題の分析と対策を進められます。
入手先
このフラグは、ケース内のアクティビティの順序を分析し、データ変換時に計算されます。
例
truefalse
|
|||
|
納入場所
DeliveryLocation
|
商品を納品する物理的な場所または住所です。 | ||
|
説明
この属性は、発注書で注文した商品の納品先を示します。具体的な倉庫、オフィス、工場などを指定できます。地域や拠点に基づいてプロセスを分けて分析できます。 「入荷処理時間」ダッシュボードの主要なディメンションです。場所ごとに入荷時間を分析すると、人員不足や入荷プロセスの非効率が生じている拠点を特定し、対象を絞った業務改善につなげられます。
重要な理由
場所ごとにプロセスのパフォーマンスを分析できます。入荷などのアクティビティにおける拠点固有のボトルネックを特定するのに役立ちます。
入手先
NetSuiteのPurchase Orderレコードにある「Ship To」住所または「Location」フィールドに該当します。
例
中央倉庫:搬入口A本社:15階西海岸配送センター
|
|||
|
納期遅延あり
IsLateDelivery
|
商品が指定された納品日より後に受領されたかどうかを示すフラグです。 | ||
|
説明
これは計算によって求められる真偽値の属性です。発注書に指定された「希望納品日」より後に「商品受領作成」アクティビティが発生した場合、trueになります。納期遵守状況を簡潔かつ明確に示します。 この属性により、仕入先パフォーマンスのダッシュボードやKPIを簡単に作成できます。フィルタリングと集計を行うことで、「仕入先納期遵守率」を算出し、納期を継続的に守れない仕入先を特定できます。
重要な理由
納期どおりに納品されたかをtrue/falseで示すため、仕入先管理におけるパフォーマンス分析とKPI計算を簡単に行えます。
入手先
計算フィールドです。ロジックは次のとおりです:(「商品受領作成」のタイムスタンプ)>(「RequestedDeliveryDate」)。
例
truefalse
|
|||
|
規定外購買あり
IsMaverickBuy
|
先行する購買依頼なしに発注書が作成されたかどうかを示すフラグです。 | ||
|
説明
これは計算によって求められる真偽値の属性です。プロセスの最初のアクティビティが「購買依頼作成」ではなく「発注書作成」の場合、ケースレベルでtrueに設定されます。標準手順に従わない購買を直接示します。 この属性は、「調達コンプライアンスモニター」の主要KPIである「直接発注率」の計算に使われます。組織は、規定外購買をすばやく特定して定量化できます。規定外購買は、コスト増加やリスクの上昇につながる可能性があります。
重要な理由
コンプライアンスに反する購買行動を直接示すため、組織は規定外購買を簡単に監視し、減らせます。
入手先
計算属性です。ロジックは次のとおりです:(ケース内の最初のアクティビティ=「発注書作成」)AND(「購買依頼」がリンクされていない)。
例
truefalse
|
|||
|
購買依頼
PurchaseRequisition
|
発注書に先行する購買依頼の識別子です。 | ||
|
説明
この属性は、発注書を起点となった購買依頼に関連付けます。このリンクがない場合、標準プロセスから逸脱している可能性があります。 コンプライアンスの監視や、承認を経ない購買の特定に欠かせないフィールドです。「直接発注率」KPIは、関連付けられた購買依頼がないかどうかを確認して算出します。これにより、標準の承認ワークフロー外で行われた購入を把握できます。
重要な理由
承認済みの購買依頼なしに発注書が作成される、いわゆる規定外購買を特定できるため、コンプライアンス分析に欠かせません。
入手先
発注書レコードでは、通常「Related Records」サブタブまたは「Created From」フィールドに記載されています。
例
PR-00582PR-00610PR-00715
|
|||
|
通貨
Currency
|
取引金額の通貨コードです。 | ||
|
説明
この属性は、発注書の合計金額がどの通貨で表示されるかを指定します。例として、USD、EUR、GBPなどがあります。金額を扱う際に欠かせない情報です。 国際的に事業を展開する組織では、正確な財務報告と分析に欠かせない属性です。地域をまたいだ発注書金額の正確な集計と比較を可能にし、金額に関するKPIを正しく解釈できるようにします。
重要な理由
金額を扱うために必要な情報を提供し、複数通貨の環境における正確な財務分析と報告を支えます。
入手先
発注書レコードの「Currency」フィールドに対応します。多くの場合、選択した仕入先の設定の影響を受けます。
例
USDEURGBP
|
|||
調達から支払いまで:発注書のアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
|
Item Receiptの作成
|
このアクティビティは、Purchase Orderで発注した商品を実際に受け取ったことを示します。NetSuiteでは、「Item Receipt」取引が作成され、特定のPurchase Order明細に紐付けられた時点で明示的に記録されます。 | ||
|
重要な理由
仕入先の納品サイクルの終了を示す重要なマイルストーンです。仕入先の納期遵守率と全体のリードタイムを算出するうえで欠かせません。
入手先
Item Receiptの取引レコードの作成日から記録されます。レコードには、元のPurchase Orderへのリンクが含まれます。
取得
Item Receiptの取引レコードの作成タイムスタンプを追跡します。
イベントタイプ
explicit
|
|||
|
Purchase OrderからのBill作成
|
仕入先からの請求書を受け取り、Purchase Orderに紐付けてNetSuiteに登録した状態です。受け取った商品またはサービスに対する債務を正式に記録する明示的な取引です。 | ||
|
重要な理由
このアクティビティは、調達プロセスから買掛金プロセスへの移行を示します。入荷から請求までの時間を分析することで、財務処理における潜在的な遅延を把握できます。
入手先
Vendor Billの取引レコードの作成日から記録されます。Billは、元のPurchase Orderに直接紐付けられます。
取得
Vendor Billの取引レコードの作成タイムスタンプを追跡します。
イベントタイプ
explicit
|
|||
|
Purchase Orderのクローズ
|
Purchase Orderが正式にクローズされ、これ以上の入荷やBillが予定されていない状態です。Purchase Orderのステータスが「Closed」に変更された時点で推定されます。全額の請求と入荷が完了した後に自動で変更される場合と、手動で変更される場合があります。 | ||
|
重要な理由
Purchase Orderのライフサイクルにおける業務上の終了点を示します。発注が完全に履行・処理されたことを確認できるため、サイクル時間分析の明確な終点になります。
入手先
Purchase Orderレコードの「Status」フィールドが「Closed」に変更されたことから推定されます。
取得
Purchase Orderの「Status」フィールドが「Closed」に変更されたことを検出します。
イベントタイプ
inferred
|
|||
|
Purchase Orderの作成
|
このアクティビティは、正式なPurchase Order文書の作成を示します。Purchase Orderは、この分析における中心的なケースです。NetSuiteでは、Purchase Orderの取引レコードが手動で作成された場合、または承認済みの購買依頼から作成された場合に記録されます。 | ||
|
重要な理由
依頼が正式な発注コミットメントに変わる重要なステップです。主要なマイルストーンであり、直接発注するPOではプロセスの開始点にもなります。コンプライアンスの監視においても重要です。
入手先
Purchase Orderの取引レコードにあるシステムフィールド「Date Created」から記録されます。
取得
Purchase Orderの取引レコードの作成タイムスタンプを使用します。
イベントタイプ
explicit
|
|||
|
Purchase Orderの承認
|
Purchase Orderが最終的に正式承認され、仕入先へ送付できる状態になったことを示します。Purchase Orderの「Approval Status」フィールドが「Approved」に更新された時点で記録される重要なマイルストーンです。 | ||
|
重要な理由
承認サイクル時間の算出と承認経路のボトルネック特定に欠かせないマイルストーンです。ここでの遅延は、調達のリードタイムに直接影響します。
入手先
Purchase Orderレコードの「Approval Status」フィールドが「Approved」に変更されたことを記録したシステムノートまたはワークフロー履歴から推定されます。
取得
Purchase Orderの「Approval Status」フィールドが「Approved」に変更されたことを検出します。
イベントタイプ
inferred
|
|||
|
Purchase Requisitionの作成
|
このアクティビティは、商品またはサービスの正式な依頼を示し、調達プロセスを開始します。NetSuiteでは、新しいPurchase Requisitionの取引レコードが作成・保存された時点で記録されます。 | ||
|
重要な理由
通常、プロセスの開始点となるこのアクティビティは、エンドツーエンドのサイクル時間を分析するうえで欠かせません。また、このアクティビティが省略されている場合は、承認を経ない購買の特定にも役立ちます。
入手先
このイベントは、Purchase Requisitionの取引レコードの作成日に基づいて記録されます。レコードは後続のPurchase Orderに紐付けられます。
取得
Purchase Requisitionの取引レコードの作成タイムスタンプを追跡します。
イベントタイプ
explicit
|
|||
|
Billの承認
|
仕入先からのBillが確認され、支払いが承認された状態です。Purchase Orderと同様に、Vendor Billレコードの「Approval Status」フィールドの変更から記録されます。 | ||
|
重要な理由
Billの承認は支払いプロセスの重要なステップです。所要時間を追跡することで、買掛金業務のボトルネックを特定できます。これらは支払い遅延や早期支払割引の適用漏れにつながる可能性があります。
入手先
Vendor Billレコードの「Approval Status」フィールドが「Approved」に変更されたことを記録したシステムノートまたはワークフロー履歴から推定されます。
取得
Vendor Billの「Approval Status」フィールドが「Approved」に変更されたことを検出します。
イベントタイプ
inferred
|
|||
|
Billの支払い
|
請求金額が仕入先に支払われた状態です。「Vendor Payment」取引が作成され、Vendor Billに適用された時点で記録されます。 | ||
|
重要な理由
このアクティビティは、Purchase Orderに関する金銭的義務の完了を示します。支払期日遵守のパフォーマンスとキャッシュフローを分析するうえで重要です。
入手先
Vendor Billに適用されたVendor Paymentの取引レコードの作成日から記録されます。
取得
Billに適用されたVendor Payment取引の作成タイムスタンプを追跡します。
イベントタイプ
explicit
|
|||
|
Purchase Orderの仕入先への送付
|
承認済みのPurchase Orderが仕入先へ送信された状態です。NetSuiteでは、「To Be Emailed」チェックボックスなどの通信フラグが更新されたこと、または送信済みを示すステータスへの変更から推定されることが多いです。 | ||
|
重要な理由
このアクティビティは仕入先のリードタイムの開始点です。この時点から入荷までの時間を測定することは、仕入先の納品パフォーマンスを評価するうえで欠かせません。
入手先
「To Be Emailed」または「To Be Faxed」フラグが解除された時点のタイムスタンプ、またはPurchase Orderに紐付く通信履歴の記録から推定されます。
取得
POに紐付く通信イベント(例:送信済みメール)のタイムスタンプを追跡します。
イベントタイプ
inferred
|
|||
|
Purchase Orderの却下
|
承認者がPurchase Orderを却下したため、修正して再提出する必要がある状態です。Purchase Orderの「Approval Status」フィールドが「Rejected」に変更された時点で推定されます。 | ||
|
重要な理由
却下を追跡することで、手戻りのループを特定し、承認に至らなかった理由を把握できます。また、最初に提出するPOの品質改善にも役立ちます。
入手先
Purchase Orderレコードの「Approval Status」フィールドが「Rejected」に変更されたことを記録したシステムノートまたはワークフロー履歴から推定されます。
取得
Purchase Orderの「Approval Status」フィールドが「Rejected」に変更されたことを検出します。
イベントタイプ
inferred
|
|||
|
Purchase Orderの変更
|
初回の作成後または承認後にPurchase Orderが変更されたことを示します。「Last Modified Date」を「Date Created」または別の承認日と比較することで推定できます。 | ||
|
重要な理由
頻繁な変更は、非効率、初期計画の不備、またはスコープの拡大を示している可能性があります。変更がいつ、なぜ発生したかを分析することで、プロセスを効率化し、エラーを減らせます。
入手先
Purchase Orderレコードの「Last Modified Date」を作成または承認のタイムスタンプと比較して推定します。具体的に変更されたフィールドの詳細は、システムノートのログで確認できます。
取得
「Last Modified Date」を作成日または承認日と比較し、システムによる更新を除外します。
イベントタイプ
inferred
|
|||
|
Purchase Orderの提出
|
Purchase Orderが確定され、承認ワークフローに提出された状態です。通常は、Purchase Orderレコードのステータスが「Pending Supervisor Approval」のような下書き状態から、審査中の状態に変更されたことで記録されます。 | ||
|
重要な理由
このイベントは承認サイクルの開始を示します。この時点から「Purchase Order Approved」までの時間を測定することで、承認の効率を分析し、遅延を特定できます。
入手先
Purchase Orderレコードの「Approval Status」フィールドの変更から推定されます。たとえば、「Pending Approval」またはカスタムの下書きステータスからの変更です。
取得
POの「Approval Status」フィールドが審査中の状態に変更されたことを検出します。
イベントタイプ
inferred
|
|||
|
Purchase Requisitionの承認
|
商品またはサービスの依頼が正式に承認され、Purchase Orderの作成が許可されたことを示します。このイベントは、Purchase Requisitionレコードの「Approval Status」フィールドが「Pending Approval」から「Approved」に変更されたことから推定されます。 | ||
|
重要な理由
購買前の段階でボトルネックを特定し、社内での依頼確認の効率を測定するには、購買依頼の承認状況を追跡します。
入手先
Purchase Requisitionレコードの「Approval Status」フィールドの変更を記録したシステムノートまたはワークフロー履歴から推定されます。
取得
Purchase Requisitionの「Approval Status」フィールドが「Approved」に変更されたことを検出します。
イベントタイプ
inferred
|
|||
|
品質検査の実施
|
入荷した商品に品質検査が実施された状態です。これはNetSuiteの標準取引ではなく、通常はカスタムフィールドの更新、カスタムレコード、またはItem Receiptのステータス変更から推定されます。 | ||
|
重要な理由
品質管理プロセスのサイクル時間を測定するのに役立ちます。検査の遅延は、商品の受け入れから使用可能になるまでの間にボトルネックを生む可能性があります。
入手先
カスタマイズへの依存度が高い項目です。Item Receiptのカスタム「QA Status」フィールド、または「Quality Inspection」用の別のカスタムレコードから記録される場合があります。
取得
品質検査に関連するカスタムフィールドの更新またはカスタムレコードの作成を追跡します。
イベントタイプ
inferred
|
|||
抽出ガイド
準備はできましたか?
このテンプレートは、調達から支払いまでの発注書プロセスの可能性を最大限に引き出すための第一歩です。今日からデータの準備を始め、効率化の機会を見つけ、改善を進めてください。
発注書を効率化:今すぐNetSuiteの業務効率を向上
ProcessMindで発注書の処理時間を30%短縮し、ボトルネックを解消できます。
クレジットカードは不要です。今日から最適化を始められます。