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