調達から支払いまで:申請データテンプレート
調達から支払いまで:申請データテンプレート
- 収集を推奨する属性
- プロセスディスカバリーで追跡すべき主要アクティビティ
- データ抽出の手順
調達から支払いまで:購買依頼の属性
| 名前 | 説明 | ||
|---|---|---|---|
|
アクティビティ名
ActivityName
|
購買依頼のライフサイクル内で発生した、特定の業務イベントまたはタスクの名称です。 | ||
|
説明
Activity Nameは、「Requisition Created」、「Approval Step Approved」、「Purchase Order Created」など、購買依頼プロセスにおける個別のステップを表します。これらのアクティビティは、実行された作業を示すプロセスマップの構成要素です。 アクティビティを分析すると、プロセスの流れを可視化し、ボトルネックを特定し、各段階にかかった時間を測定できます。特定のPurchase Requisition IDにおけるアクティビティの順序が、その購買依頼の経路を定義します。この経路を標準手順と比較することで、逸脱や非効率な箇所を特定できます。
重要な理由
プロセスのステップを定義し、プロセスマップの可視化、プロセスバリアントの分析、ボトルネックの特定を可能にします。
入手先
通常は、NetSuite内の取引ステータス、システムログのエントリ、ワークフロー履歴、またはカスタムイベント追跡を組み合わせて導出します。
例
申請作成承認ステップ承認申請変更発注書作成
|
|||
|
イベント時刻
EventTime
|
アクティビティが発生した正確な日時です。 | ||
|
説明
イベント時刻、つまりタイムスタンプは、アクティビティが実行された正確な時点を記録します。この時間データは、申請プロセスの期間、イベントの順序、実行タイミングなど、その動きを把握するうえで欠かせません。 プロセス分析では、タイムスタンプを使ってサイクルタイム、アクティビティ間の待機時間、サービスレベル合意の遵守状況を計算します。時間に基づく分析の基盤となるため、「申請承認サイクルタイム」のダッシュボードや、「申請平均サイクルタイム」などのKPIを作成できます。信頼性の高いプロセスモデルには、正確なタイムスタンプが欠かせません。
重要な理由
このタイムスタンプは、サイクルタイムの計算、遅延の特定、プロセス効率の測定など、パフォーマンスに関するあらゆる分析の基盤となります。
入手先
この情報は、「Date Created」などのシステム生成フィールドや、各取引のSystem Notesまたはワークフロー実行ログに記録されたタイムスタンプから取得します。
例
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z
|
|||
|
購買依頼ID
PurchaseRequisitionId
|
各購買依頼を一意に識別し、プロセス分析における主要なケースIDとして機能します。 | ||
|
説明
Purchase Requisition IDは、特定の物品またはサービスの申請に関連するすべてのアクティビティとイベントを結び付ける中心的な識別子です。NetSuiteで購買依頼を作成すると一意のIDが割り当てられ、ライフサイクル全体を通じて変わりません。 プロセスマイニングでは、この属性がケースを関連付けるための基本情報になります。初回作成からすべての承認ステップ、修正、承認・却下・Purchase Orderへの変換といった最終結果まで、各購買依頼の一連の流れを再構成できます。このID単位でプロセスを分析することは、ライフサイクルの所要時間を計算し、ステータス変更を追跡し、プロセス経路のばらつきを特定するうえで欠かせません。
重要な理由
単一の購買依頼のライフサイクル全体を追跡するための基本キーであり、プロセスの流れを分析してケース単位の指標を計算できます。
入手先
NetSuiteのPurchase Requisitionレコードにおける内部IDまたは取引番号です。通常、取引の「tranid」フィールドで確認できます。
例
PR-001254PR-001255PR-001256
|
|||
|
合計金額
TotalAmount
|
購買申請の金銭的な合計額です。 | ||
|
説明
この属性は、購買申請に記載されたすべての品目の合計コストを記録します。金額のしきい値に応じて異なる承認ワークフローを開始するなど、プロセス自体に影響する重要な財務データです。 合計金額を分析すると、支出パターンと財務上の影響を把握できます。金額で申請を絞り込んだり、プロセスの逸脱と高額申請の関係を調べたり、財務的に重要なケースを優先して分析したりできます。財務またはコンプライアンスに関するプロセス分析には欠かせない基本属性です。
重要な理由
金額に基づく分析を可能にし、承認経路や業務上の優先度を左右する財務的なコンテキストを提供します。
入手先
購買申請レコードの標準フィールドで、通常は「Total」または類似の名称です。
例
500.001250.7525000.00
|
|||
|
申請ステータス
RequisitionStatus
|
申請のライフサイクルにおける現在の状態を示します。 | ||
|
説明
申請ステータスは、購買申請がその時点でプロセスのどの段階にあるかを示します。一般的なステータスには、「Pending Approval」、「Fully Approved」、「Rejected」、「Closed」などがあります。 この属性は、処理中の申請と現在の状態にとどまっている期間を追跡する「申請ステータスと滞留期間」などのダッシュボードを作成する際に欠かせません。ステータスの遷移を分析すると、標準的な経路と例外の両方を把握でき、プロセスディスカバリーに役立ちます。また、ケースの最終結果を判定するためにも使われます。
重要な理由
ケースの進捗状況を把握できるため、滞留している申請の分析や、ケースが止まっている箇所の特定に役立ちます。
入手先
購買申請の取引ヘッダーにある「Status」または「Approval Status」フィールドです。
例
承認待ち承認完了却下済みクローズ済み
|
|||
|
申請者
Requester
|
購買申請を作成し、提出した従業員です。 | ||
|
説明
申請者は、購買申請を作成して調達プロセスを開始する担当者です。通常は、業務に必要な商品やサービスを申請する従業員を指します。 申請者別にデータを分析すると、ユーザー行動の傾向を把握できます。却下率が高い担当者や、修正を頻繁に行う担当者を特定し、「申請者のパフォーマンスとトレーニングの必要性」などのダッシュボードを作成できます。追加のトレーニングやガイドラインの明確化によって、初回提出時の品質とプロセス全体の効率を改善できる領域を特定できます。
重要な理由
プロセスの開始者を特定します。ユーザー行動、申請者別の却下率、トレーニングの必要性を分析するうえで重要です。
入手先
通常は、購買申請の取引レコードにある「Employee」または「Created By」フィールドです。
例
John SmithJane DoePeter Jones
|
|||
|
部門
Department
|
申請または申請者が所属する事業部門です。 | ||
|
説明
部門属性は、購買申請に関連付けられた組織単位を示します。通常は申請者の所属部門です。この情報により、組織の観点からプロセスを分類して分析できます。 部門間で承認サイクルタイムを比較したり、支出パターンを把握したり、却下率が高い部門を特定したりする際の重要な分析軸です。こうした分類により、管理者はリソースを配分し、トレーニングを調整し、各事業部門に合わせてワークフローを効率化できます。
重要な理由
プロセスデータを詳細に分類し、異なる事業部門間でパフォーマンス、コスト、コンプライアンスを比較できます。
入手先
通常は申請者の従業員レコードに関連付けられているか、購買申請の取引ヘッダーに直接設定されています。
例
マーケティングIT財務オペレーション
|
|||
|
サイクルタイム
CycleTime
|
申請の作成から最終的な解決までに経過した合計時間です。 | ||
|
説明
サイクルタイムは、1件のケースにおける購買申請プロセス全体の所要時間を測定する計算指標です。通常は、最初のアクティビティ(例:「申請作成」)から最後の終了アクティビティ(例:「申請の最終承認」または「申請の最終却下」)までの時間差として計算します。 プロセス全体の効率を測る主要なKPIです。「申請平均サイクルタイム」KPIの計算に使われ、傾向、外れ値、プロセス改善施策の影響を特定するのに役立ちます。サイクルタイムの分布を分析すると、平均パフォーマンスを大きく引き下げる長時間の申請を見つけられます。
重要な理由
プロセスのエンドツーエンドの効率を直接測定します。遅延の特定や全体的なパフォーマンス評価に欠かせない指標です。
入手先
計算属性です。各「PurchaseRequisitionId」について、最初のイベントのタイムスタンプから最後のイベントのタイムスタンプを差し引いて算出します。
例
25920060480086400
|
|||
|
ソースシステム
SourceSystem
|
データを抽出したソースシステムを特定します。 | ||
|
説明
この属性は、プロセスデータの発生元システムを示します。この場合はNetSuiteです。複数のシステムのデータを統合して、プロセス全体を把握する環境で特に役立ちます。 単一システムの分析では固定値に見える場合がありますが、データガバナンスと追跡可能性を確保するうえで欠かせないコンテキストを提供します。データの発生元を確認し、分析時にシステム固有のロジックや変換を正しく理解できるようにします。
重要な理由
データの発生元に関する重要なコンテキストを提供し、特に複数システムの環境で、明確な管理と適切なガバナンスを支えます。
入手先
データの抽出・変換プロセスで追加する「NetSuite」という固定値です。
例
NetSuiteNetSuite SuitePeopleNetSuite ERP
|
|||
|
ベンダー名
VendorName
|
申請で指定された推奨または優先ベンダーの名前です。 | ||
|
説明
ベンダー名属性は、商品またはサービスの購入先となるサプライヤーを特定します。申請は社内文書ですが、優先ベンダーが指定されることは少なくありません。 この属性を分析すると、サプライヤー管理に関する傾向を把握できます。申請頻度の高いベンダー、特定ベンダーに関する申請の承認時間、優先サプライヤー契約への準拠状況を確認できます。戦略的ソーシングやベンダーとの関係管理にも役立つ情報です。
重要な理由
サプライヤー別の調達パターンを分析し、優先ベンダーリストへの準拠状況やベンダー固有のプロセス差異を確認できます。
入手先
購買申請レコードのヘッダーレベルにある「Vendor」フィールド、または明細行に指定された値です。
例
Dell Inc.StaplesMcKinsey & Company
|
|||
|
再作業あり
IsRework
|
申請が却下され、再提出されるサイクルを経たかどうかを示すブール型フラグです。 | ||
|
説明
再作業ありは、購買申請が途中で却下され、その後に修正または再提出されて承認に進んだ場合にtrueとなる派生ブール属性です。標準的な「ハッピーパス」以外に追加の作業や処理が必要だったケースを特定します。 この属性により、プロセスの非効率性を簡単に分析できます。「承認却下サイクル数」KPIの計算に使われ、却下がプロセス全体に与える影響を定量化できます。再作業ありがtrueのケースに絞り込むことで、問題のあるプロセスバリアントを特定し、データ品質の低さやポリシーの誤解など、最初の却下につながった根本原因を調査できます。
重要な理由
再作業ループの頻度と影響を定量化できます。再作業ループは、プロセスの非効率性と遅延の主な原因です。
入手先
計算属性です。同じケースで、「承認のための申請提出」アクティビティの後に「承認ステップ却下」アクティビティが発生しているかどうかを確認します。
例
truefalse
|
|||
|
最終データ更新日時
LastDataUpdate
|
ソースシステムからデータを最後に抽出または更新した日時を示すタイムスタンプです。 | ||
|
説明
この属性は、NetSuiteから直近にデータを取得した日時を記録します。プロセスマイニングのダッシュボードや分析に欠かせないメタデータです。 このタイムスタンプにより、データがどの程度新しいかを把握できます。リアルタイムの情報を見ているのか、特定時点のスナップショットを見ているのかを確認できます。また、データの検証や、プロセス分析から得られた結果の最新性を関係者に伝える際にも役立ちます。
重要な理由
データの最新性を示し、プロセス分析の結果がどの時点の情報に基づくものかを把握できるようにします。
入手先
このタイムスタンプは、データの抽出・変換・ロード(ETL)プロセスで生成され、追加されます。
例
2024-05-21T08:00:00Z2024-05-20T08:00:00Z
|
|||
|
却下理由
RejectionReason
|
申請を却下した承認者が記載する説明です。 | ||
|
説明
却下理由は、購買申請が承認要件を満たさなかった理由を承認者が記載するテキスト属性です。「承認ステップ却下」アクティビティに関する定性的なコンテキストを提供します。 根本原因分析に非常に役立つ情報です。「申請却下率分析」などのダッシュボードで、却下された件数だけでなく、その理由も確認できます。一般的な理由には、「GL勘定科目の誤り」、「予算超過」、「詳細不足」などがあります。理由を分析することで、組織的な問題を特定し、ユーザートレーニングを改善し、再作業と却下率を減らすために申請ガイドラインを見直せます。
重要な理由
却下が発生する理由を把握できるため、根本原因分析を通じて将来の却下率を下げ、初回提出時の品質を改善できます。
入手先
通常は、却下処理の際に入力する「Memo」フィールド、または承認ワークフローに追加したカスタムフィールドに記録されます。System Notesから確認できる場合もあります。
例
予算超過誤った仕入先の選択品目詳細の不足重複申請
|
|||
|
品目カテゴリ
ItemCategory
|
申請された商品またはサービスのカテゴリです。 | ||
|
説明
品目カテゴリは、購買申請の品目を「ITハードウェア」、「オフィス用品」、「専門サービス」などの論理的なグループに分類します。申請の明細行に関連付けられた品目レコードから取得できます。 この属性により、申請プロセスをより細かく分析できます。「ITハードウェアの申請は、オフィス用品の申請より承認に時間がかかるか」といった問いに答えられます。品目カテゴリ別にプロセスを分類することで、カテゴリ固有のボトルネックを見つけ、カテゴリ別の支出を分析し、調達戦略を調整できます。
重要な理由
購入対象に基づくプロセス分析を可能にし、カテゴリ固有のボトルネックやコンプライアンス上の問題を特定できます。
入手先
購買申請の明細行レベルで関連付けられた「Item」レコードから取得します。カテゴリ自体は、Itemレコードの標準フィールドまたはカスタムフィールドである場合があります。
例
ITハードウェアソフトウェアライセンス事務用品マーケティングサービス
|
|||
|
承認ワークフロー経路
ApprovalWorkflowPath
|
申請が通過した承認ステップの順序を表します。 | ||
|
説明
承認ワークフロー経路は、申請ごとの承認アクティビティまたはステータスの順序を連結して作成する派生属性です。たとえば、「提出 → マネージャー承認 → 財務承認」のように表します。これにより、各ケースがたどった経路を一意に表せます。 この属性は、適合性チェックとバリアント分析の基盤です。「コンプライアンス違反の申請経路」や「承認ワークフロー経路のコンプライアンス」ダッシュボードで、実際のプロセスフローに基づいてケースを簡単に絞り込み、グループ化できます。実際の経路をあらかじめ定めた標準経路と比較することで、準拠状況を定量化し、逸脱の根本原因を調査できます。
重要な理由
各ケースの承認ステップの正確な順序を要約し、詳細なバリアント分析と適合性チェックを可能にします。
入手先
派生属性です。各「PurchaseRequisitionId」について、「ActivityName」の値を時系列順に連結して計算します。
例
作成 > 提出 > 承認作成 > 提出 > 却下 > 変更 > 提出 > 承認作成 > 提出 > 承認 > 取り下げ
|
|||
|
承認者
Approver
|
承認ステップの承認または却下を担当する従業員またはユーザーです。 | ||
|
説明
承認者は、承認ワークフローの特定の段階で購買申請を確認し、処理する担当者です。1件の申請に複数の承認者が設定され、それぞれ異なる承認アクティビティを担当する場合があります。 この属性は、承認プロセス自体のパフォーマンスを分析するうえで欠かせません。「承認ステップのサイクルタイム分布」などのダッシュボードを作成し、個人またはグループ単位のボトルネックを特定できます。承認を行った担当者を追跡することで、説明責任を確保し、業務量を調整し、特定の承認者による遅延を特定できます。
重要な理由
承認タスクを実行したユーザーを特定します。承認者のパフォーマンス、業務量、ボトルネックを分析するうえで重要です。
入手先
通常は、承認ステータスの変更に関連付けられたワークフロー実行ログまたはSystem Notesに記録されています。承認ワークフローに関連するカスタムレコードフィールドに保存される場合もあります。
例
Sarah JenkinsDavid Chen財務承認グループ
|
|||
|
緊急度
UrgencyLevel
|
「標準」や「緊急」など、申請の優先度を分類したものです。 | ||
|
説明
緊急度は、購買申請の業務上の優先度を示すカテゴリ属性です。重要な業務上の理由で迅速な処理が必要な申請に、従業員が目印を付けられます。 「緊急申請処理パフォーマンス」ダッシュボードや、「緊急申請処理時間」KPIを支えるための属性です。この属性でプロセスデータを絞り込むと、緊急申請と標準申請のサイクルタイムやプロセス経路を比較し、優先処理が機能しているか、ボトルネックによる遅延が残っているかを確認できます。
重要な理由
優先度の高い申請と標準申請のプロセスパフォーマンスを比較し、重要なニーズに効率よく対応できるようにします。
入手先
通常は、購買申請フォームに設定するカスタム取引ボディフィールドです。
例
高中低
|
|||
|
購買注文ID
PurchaseOrderId
|
承認済みの申請から作成された購買注文の識別子です。 | ||
|
説明
購買注文IDは、承認済みの申請から生成された購買注文を一意に識別します。この属性は、申請プロセスと、その後の調達アクティビティをつなぐ重要なリンクです。 プロセス分析では、エンドツーエンドのP2P分析に欠かせません。申請の承認から購買注文の作成までの時間を測定し、「PO作成リードタイム」KPIを計算できます。また、「申請から購買注文への変換率」の計算にも役立ち、申請が実際の注文にどの程度つながっているかを把握できます。
重要な理由
申請と作成された購買注文を関連付け、PO作成リードタイムの測定とエンドツーエンドのプロセス分析を可能にします。
入手先
購買申請レコードに記録されています。通常は関連レコードのサブタブ、または購買注文自体にある「Created From」リンクから確認できます。
例
PO-005432PO-005433PO-005434
|
|||
|
通貨
Currency
|
申請の合計金額に使用される通貨コードです。 | ||
|
説明
通貨属性は、申請の金額がどの通貨で表示されているかを示します。USD、EUR、GBPなどが該当します。複数の通貨を扱う多国籍組織では特に重要です。 このフィールドにより、財務データを正しく解釈できます。プロセスマイニングでは、すべての金額を単一の基準通貨に換算したり、通貨別に分析を分類したりして、金額を正しく集計・比較できます。財務報告の誤りを防ぎ、グローバルな業務における明確性を確保します。
重要な理由
多国籍組織で正確な財務分析を行うために欠かせません。金額を正しく解釈し、集計できます。
入手先
購買申請の取引レコードにある標準の「Currency」フィールドです。複数通貨に対応したNetSuite環境で特に使用されます。
例
USDEURGBP
|
|||
調達から支払いまで:購買依頼のアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
|
申請クローズ
|
購買依頼が正式にクローズされ、それ以上の対応が予定されていない状態になります。通常は、リンクされたPurchase Orderによって購買依頼の数量がすべて発注された後に自動的に発生します。 | ||
|
重要な理由
このアクティビティは、購買依頼のライフサイクルが確定的に終了したことを示します。業務上のニーズが満たされ、レコードが確定したことを確認できます。
入手先
System Notesサブタブで、明細レベルまたはヘッダーレベルの「Status」フィールドが「Closed」に更新されたTimestampを特定して推定します。
取得
「Status」フィールドが「Closed」に変わったTimestamp。
イベントタイプ
inferred
|
|||
|
申請の最終却下
|
購買依頼が最終的に却下され、それ以上処理されない状態になります。購買依頼の最終的な「Approval Status」が「Rejected」に更新された時点から推定します。 | ||
|
重要な理由
このアクティビティは、承認に至らなかった購買依頼の重要な終点です。購買依頼が最終的に却下された理由と時期を把握すると、ポリシーへの準拠状況や予算上の問題を分析できます。
入手先
System Notesサブタブで、「Approval Status」フィールドが最終的な「Rejected」状態に設定されたTimestampを特定して推定します。
取得
「Approval Status」が「Rejected」に変わったTimestamp。
イベントタイプ
inferred
|
|||
|
申請の最終承認
|
購買依頼が承認ワークフローで必要なすべてのステップを正常に完了します。レコードの最終的な「Approval Status」が「Approved」に変わった時点から推定します。 | ||
|
重要な理由
これは、購買依頼をPurchase Orderに変換できる状態になったことを示す大きな節目です。承認サイクルの終了と、調達・履行フェーズの開始を示します。
入手先
System Notesサブタブで、「Approval Status」フィールドが最終的な「Approved」状態に設定されたTimestampを特定して推定します。
取得
「Approval Status」が「Approved」に変わったTimestamp。
イベントタイプ
inferred
|
|||
|
申請作成
|
ユーザーが新しい購買依頼レコードを作成して保存し、調達プロセスを開始します。これは購買依頼のライフサイクルにおける最初のイベントであり、NetSuiteで取引レコードが初めて保存された時点で記録されます。 | ||
|
重要な理由
このアクティビティは、特定のニーズに対する調達プロセスの正式な開始を示します。作成から提出までの時間を分析すると、データ入力や初期申請の作成における遅延を明らかにできます。
入手先
このイベントは、Purchase Requisition取引レコードの作成日時のTimestampから取得します。レコードのメインヘッダー、または「Create」アクションを記録するSystem Notesサブタブで確認できます。
取得
Purchase Requisitionレコードの「Date Created」フィールドを使用します。
イベントタイプ
explicit
|
|||
|
発注書作成
|
完全に承認された購買依頼からPurchase Orderが生成され、サプライヤーへの支出が正式に確定します。これは、元の購買依頼にリンクされた新しいPurchase Order取引が作成されたことによって記録される明示的なイベントです。 | ||
|
重要な理由
これは購買依頼が正常に完了した主な成果であり、Purchase to Payプロセスにおける重要な引き継ぎです。承認からPurchase Order作成までの時間は、調達効率を測る重要なKPIです。
入手先
「Created From」または同様のリンク項目がPurchase Requisition IDを参照しているPurchase Orderレコードを見つけて特定します。そのPurchase Orderの作成日が、このアクティビティのTimestampになります。
取得
「Created From」フィールドがRequisition IDと一致するPurchase Orderを見つけ、「Date Created」を使用します。
イベントタイプ
explicit
|
|||
|
承認ステップ却下
|
承認者が割り当てられたステップを却下し、通常は購買依頼を修正のため申請者に差し戻します。この操作はSuiteApprovalsワークフローエンジンに明示的に記録されます。 | ||
|
重要な理由
このイベントは、手戻りとプロセスの非効率性を示す重要な指標です。却下された箇所を分析すると、ポリシー違反やデータの誤りなど、失敗の一般的な理由を特定できます。
入手先
却下操作、却下したユーザー、Timestampを記録するSuiteApprovalsログまたはSystem Notesサブタブから取得します。
取得
SuiteApprovalsログまたはSystem Notesで却下操作を特定します。
イベントタイプ
explicit
|
|||
|
承認ステップ承認
|
権限を持つユーザーがワークフローで割り当てられたステップを承認し、購買依頼を最終承認に近づけます。NetSuiteのSuiteApprovalsプラットフォームには、この操作がユーザーとTimestampの詳細とともに明示的に記録されます。 | ||
|
重要な理由
このアクティビティは、承認チェーンが前進したことを示します。承認ステップ間の時間を分析すると、ワークフローと個々の承認者の効率を把握できます。
入手先
承認操作、承認者、イベントの正確なTimestampを記録するSuiteApprovalsログまたはSystem Notesサブタブから取得します。
取得
SuiteApprovalsログまたはSystem Notesで承認操作を特定します。
イベントタイプ
explicit
|
|||
|
承認ステップ開始
|
購買依頼が承認ワークフローの特定の段階に入り、指定された承認者またはグループの対応を待ちます。通常は、ワークフローによって購買依頼が次の承認者に割り当てられた時点から推定します。 | ||
|
重要な理由
このアクティビティは、個々の承認ステップにおける待機時間の開始を示します。承認階層内のボトルネックを特定し、対応の遅い承認者を把握するうえで欠かせません。
入手先
ワークフロー実行ログ、または「Current Approver」フィールドやワークフロー状態フィールドの変更から推定します。SuiteApprovalsプラットフォームがアクティブな承認ステップを追跡します。
取得
ワークフローログ、またはレコードが新しい承認者に割り当てられた時点から推定します。
イベントタイプ
inferred
|
|||
|
承認申請を提出
|
申請者が完成した購買依頼を指定の承認ワークフローに正式に提出します。通常は、購買依頼レコードのステータスが「Draft」または「Pending Submission」から「Pending Approval」へ変わったことから推定します。 | ||
|
重要な理由
このアクティビティが承認サイクルを開始し、承認リードタイムを測定する重要な起点になります。正式な承認プロセスが始まるまで、購買依頼がどのくらい待機しているかを特定できます。
入手先
System Notesサブタブで、「Approval Status」フィールドが初めて「Pending Approval」などの値に変わったTimestampを特定して推定します。
取得
「Approval Status」フィールドが「Pending Approval」に変わった最初のTimestampを特定します。
イベントタイプ
inferred
|
|||
|
申請取り下げ
|
元の申請者または管理者が、購買依頼の最終承認またはPurchase Orderへの変換前に申請を取り消します。通常は、ステータスが「Cancelled」または「Withdrawn」に変わったことから推定します。 | ||
|
重要な理由
このアクティビティは、申請者が開始したプロセスの例外または終了を示します。取り下げを分析すると、業務ニーズの変化や、もはや有効でない購買依頼を明らかにできます。
入手先
System Notesサブタブで、「Approval Status」フィールドが「Cancelled」などの値、またはカスタムの取り下げステータスに更新されたTimestampを追跡して推定します。
取得
「Approval Status」が「Cancelled」または「Withdrawn」に変わったTimestamp。
イベントタイプ
inferred
|
|||
|
申請変更
|
ユーザーが購買依頼の初回作成後にいずれかのフィールドを変更します。却下への対応や要件変更を受けて行われることが多く、このイベントはNetSuiteの監査証跡機能から直接取得できます。 | ||
|
重要な理由
修正を追跡することは、手戻りのループやデータ品質の問題を特定するうえで重要です。修正頻度が高い場合、初期要件が不明確である、または申請者への研修が必要である可能性があります。
入手先
Purchase RequisitionレコードのSystem Notesサブタブから取得します。関連フィールドに対する「Type」が「Change」または「Edit」の各エントリが、修正を表します。
取得
System Notesログで「Change」タイプのエントリごとにイベントを記録します。
イベントタイプ
explicit
|
|||
抽出ガイド
準備はできましたか?
このテンプレートを使ってプロセスマイニングを始め、NetSuiteの調達から支払いまでの購買依頼プロセスに関する価値ある情報を見つけ出してください。今すぐプロセスを最適化し、承認を迅速化しましょう。
調達から支払いまでの購買依頼プロセスを最適化:今すぐ始めましょう
購買依頼の承認を30%迅速化し、ボトルネックを解消します。
クレジットカードは不要です。今すぐプロセスの最適化を始められます。