返品・返金処理データテンプレート
返品・返金処理データテンプレート
- 収集を推奨する項目
- プロセス分析のために追跡すべき主要アクティビティ
- Oracle Fusion SCM向けステップバイステップ抽出ガイド
返品・返金処理属性
| 名前 | 説明 | ||
|---|---|---|---|
|
アクティビティ
ActivityName
|
返品・返金プロセス内で発生した特定のビジネスステップまたはイベントの名称。 | ||
|
説明
この属性は、返品ライフサイクルにおける単一のステップまたはマイルストーンを記述します。例えば、「RMA作成済み」、「商品検査済み」、「返金処理済み」などです。各活動は、システムイベントログに捕捉されたプロセス内の明確なポイントを表します。 これらの活動の順序と期間を分析することは、プロセスマイニングの核となります。これにより、プロセスマップの可視化、ステップ間のボトルネックの特定、および活動固有のリードタイムの計算が可能になります。このデータは、プロセスフロー、手戻りループ、および標準作業手順へのコンプライアンスを理解するために不可欠です。
その重要性
アクティビティは、プロセスマップの基盤を形成し、プロセスフロー、そのバリエーション、およびボトルネックの可視化と分析を可能にします。
取得元
Oracle Fusion SCMのオーダー管理や在庫管理などのモジュール内のイベントログ、ステータス変更、または特定のトランザクション記録から導出されます。
例
RMA作成済み品目受領済みクレジットメモ作成返金処理済み
|
|||
|
イベント日時
EventTime
|
特定のアクティビティまたはイベントが発生した時刻を示すタイムスタンプ。 | ||
|
説明
イベントタイム(開始時間)は、ソースシステムにアクティビティが記録された正確な日時です。これはプロセスのすべてのステップの時間的コンテキストを提供します。 このタイムスタンプは、すべての時間ベースの分析に不可欠です。イベントを正しく順序付け、アクティビティ間のサイクルタイムを計算し、ケースの総期間を測定し、サービスレベル契約(SLA)に対するパフォーマンスを評価するために使用されます。正確なタイムスタンプがなければ、プロセス効率の分析、遅延の特定、プロセスダイナミクスの理解は不可能です。
その重要性
この属性は、すべての期間ベースの指標を計算し、プロセスボトルネックを発見するための基礎となるイベントの時系列順序を提供します。
取得元
この情報は通常、Oracle Fusion SCMのトランザクションまたはステータスレコードに関連付けられた「作成日」、「タイムスタンプ」、または「最終更新日」フィールドとして見つかります。
例
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:00:00Z
|
|||
|
返品ケースID
ReturnCaseId
|
特定の顧客返品または返金リクエストに関連するすべての活動をリンクする主要な識別子。 | ||
|
説明
「返品ケースID」は、返品・返金プロセス全体のユニークなケース識別子として機能します。初期の返品承認(RMA)作成から最終的な返金処理、ケースクローズまで、すべてのイベントを結びつけます。 プロセスマイニング分析において、この属性は各返品のエンドツーエンドのジャーニーを再構築するための基本です。アナリストはこれにより、完全なライフサイクルを追跡し、総サイクル時間を測定し、異なる返品がどのように処理されるかのバリエーションを理解できます。他のすべてのイベントレベルのデータは、このIDでグループ化され、一貫したプロセスビューを形成します。
その重要性
これは、関連するすべてのイベントを単一のプロセスインスタンスにまとめ、エンドツーエンドの分析を可能にするための不可欠な鍵です。
取得元
この識別子は通常、返品リクエストが開始されたときにOracle Order ManagementまたはServiceモジュール内で生成されます。
例
RMA-2023-00123RMA-2023-00456RMA-2023-00789
|
|||
|
ソースシステム
SourceSystem
|
データを抽出した元システム。 | ||
|
説明
この属性は、イベントデータが記録された元の情報システムを識別します。このプロセスの場合、通常は「Oracle Fusion SCM」です。 複数の統合システムがある環境では、このフィールドはデータリネージとトラブルシューティングにとって重要です。データの出所を確認するのに役立ち、特定のシステムからのイベントを分析するためにフィルタリングすることで、データ品質とコンテキストが維持されます。
その重要性
これはデータ発信元に関する重要なコンテキストを提供し、マルチシステム環境でのデータ検証と分析に不可欠です。
取得元
これは多くの場合、データセットの出所をラベル付けするために、データ抽出、変換、ロード(ETL)プロセス中に加えられる静的な値です。
例
Oracle Fusion SCMOracle SCM Cloud
|
|||
|
最終データ更新
LastDataUpdate
|
データが最後に更新されたか、ソースシステムから抽出された時点のタイムスタンプ。 | ||
|
説明
この属性は、データセットが最後に更新された最新の時刻を示します。個々のイベントではなく、データセット全体の「鮮度」の日付を提供します。 最終データ更新時刻を知ることは、ユーザーが分析の適時性を理解するために不可欠です。これにより、リアルタイムの情報を見ているのか、数時間または数日前のデータを見ているのかを把握し、ダッシュボードやKPIを正しく解釈するのに役立ちます。これは、あらゆるプロセスマイニングプロジェクトにとって重要なメタデータの一部です。
その重要性
データの新しさをユーザーに通知し、分析のコンテキストとタイムリーさを理解できるようにします。
取得元
この
例
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
|
|||
|
処理担当者
ProcessingAgent
|
返品プロセスにおける特定の活動の実行を担当するユーザーまたは担当者。 | ||
|
説明
この属性は、RMAの承認や返金処理など、特定のタスクを実行した従業員またはシステムユーザーを識別します。個別の割り当てが追跡されていない場合は、チームまたは部署を指すこともあります。 担当者ごとのパフォーマンス分析は、運用管理にとって重要です。この属性により、「返品処理担当者パフォーマンス」ダッシュボードが有効になり、異なる担当者間の作業負荷、活動期間、手戻り率を比較できます。これらの洞察は、トレーニングニーズを浮き彫りにし、トップパフォーマーを特定し、より良いリソース配分に役立ちます。
その重要性
ユーザーまたはチームごとのパフォーマンス分析を可能にし、高パフォーマンス人材、トレーニング機会、およびワークロードの不均衡を特定するのに役立ちます。
取得元
通常、Oracle Fusion SCM内のトランザクションログにある「USER_ID」、「PROCESSED_BY」、または「AGENT_NAME」のようなフィールドで見つかります。
例
j.doea.smithm.jones
|
|||
|
実際の返金額
ActualRefundAmount
|
顧客に実際に処理され、返金された最終的な金額。 | ||
|
説明
この属性は、すべての検査、調整、手数料が適用された後、顧客に実際に返金された最終的な確認済みの金額を表します。この値は、返品ケースの真の財務結果を反映します。 これは、「要求された返金額 vs 実際の返金額」ダッシュボードで使用される重要な財務データポイントです。この金額を要求された金額と比較することは、「返金額差異率」KPIの計算や、返品ポリシー、商品状態、処理調整の財務的影響を理解するために不可欠です。
その重要性
返品の真の財務結果を表し、差異分析と財務報告を可能にします。
取得元
この情報は、Oracle Fusion Financialsの返品ケースにリンクされたクレジットメモまたは買掛金トランザクション記録から得られる可能性が高いです。
例
129.9940.000.00
|
|||
|
終了日時
EndTime
|
アクティビティの完了時刻を示すタイムスタンプ。 | ||
|
説明
終了時刻は活動の完了を示します。開始時刻がイベントの開始を示しますが、終了時刻はその特定のイベントの実際の処理時間を計算するために必要です。瞬時のイベントの場合、開始時刻と終了時刻は同じになることがあります。 分析において、終了時刻と開始時刻の差は、活動の「処理時間」を提供します。これは、ステップ間の待機時間ではなく、どの特定のステップに時間がかかっているかを特定するために重要です。詳細なボトルネック分析とリソース効率計算には不可欠です。
その重要性
この属性は、個々の活動の真の処理時間を計算するために必要であり、実際の作業時間と待機時間を区別するのに役立ちます。
取得元
これはソースシステムログ内の個別のフィールドであるか、後続の活動の開始時刻から派生させることができます。
例
2023-10-26T10:05:00Z2023-10-26T15:00:10Z2023-10-27T11:30:00Z
|
|||
|
要求された返金額
RequestedRefundAmount
|
顧客が返品のために最初に要求した金額。 | ||
|
説明
この属性は、プロセスの開始時に顧客が要求した返金額を捕捉します。これは、最終返金額と比較される基準額です。 このデータポイントは、「要求された返金額 vs 実際の返金額」ダッシュボードおよび「返金額差異率」KPIにとって不可欠です。要求された金額と実際の金額の差を分析することで、不正確な商品返品、返品手数料、またはポリシー調整などの問題を明らかにし、財務の正確性と顧客満足度に関する貴重な洞察を提供できます。
その重要性
財務分析の基準として、返金差異の計算を可能にし、潜在的な問題を浮き彫りにします。
取得元
この値は、Oracle Fusion SCMのRMAまたは返品リクエストヘッダーに保存されるべきであり、おそらくOrder Managementモジュールにあります。
例
129.9945.501200.00
|
|||
|
返品ステータス
ReturnStatus
|
返品ケースの現在または最終ステータス。 | ||
|
説明
この属性は、特定の時点における返品ケースの全体的なステータス、または最終的な結果(例:「クローズ済み - 返金済み」、「クローズ済み - 却下済み」、「進行中」など)を示します。 返品ステータスは、結果分析と監視にとって重要です。これにより、結果に基づいてケースをフィルタリングしたり、承認済みと却下済みの返品のプロセスフローを比較したり、「現在の返品ケースステータスダッシュボード」を動かしたりすることができます。結果の分布を理解することは、プロセス有効性を測定するために不可欠です。
その重要性
ケースの結果を提供し、フィルタリング、比較分析、プロセス成功率の理解に不可欠です。
取得元
通常、Oracle Order Managementの主要な返品またはRMAヘッダーレコードのステータスフィールドとして利用可能です。
例
受領待ち検査完了クローズ済み - 返金済みクローズ - 却下
|
|||
|
返品理由
ReturnReason
|
顧客が商品を返品する際に提供した理由。 | ||
|
説明
この属性には、返品理由が含まれており、通常は「欠陥品」、「サイズ間違い」、「不要になった」などの定義済みリストから顧客が選択します。 返品理由を分析することは、製品品質、販売プロセスの正確性、顧客行動に関する強力な洞察を提供します。このデータは、欠陥率の高い製品を特定したり、製品説明を改善して誤った注文を減らしたり、返品の根本原因を理解したりするために使用できます。この分析は、返品全体の量を減らす戦略的改善を推進することができます。
その重要性
返品が発生する理由に関する重要な洞察を提供し、製品や販売プロセスの改善を推進するために利用できます。
取得元
通常、Oracle Order ManagementのRMA明細項目にコードまたはテキストフィールドとして保存されます。
例
欠陥品誤品出荷到着遅延より良い価格の利用可能性
|
|||
|
返金SLA目標日
RefundSlaTargetDate
|
サービスレベル契約に従って、返金が完了する予定日。 | ||
|
説明
この属性は、特定のケースの返金プロセスを完了するための期限を定義します。SLA目標は、多くの場合、会社の方針、顧客層、または返品理由によって決定されます。 この日付は、適時性とコンプライアンスを測定するためのベンチマークです。「返金ポリシーSLAコンプライアンス」ダッシュボードで直接使用され、「返金SLA達成率」KPIの計算に不可欠です。実際の返金完了日をこの目標と比較することで、SLA違反を特定し、遅延リスクのあるケースを優先順位付けするのに役立ちます。
その重要性
定時パフォーマンスを測定するためのベンチマークを提供し、SLAコンプライアンスKPIの計算に不可欠です。
取得元
これは返品ケース上の特定の日付フィールドであるか、返品開始日に所定の期間(例:14日)を加算することで導き出す必要がある場合があります。
例
2023-11-10T23:59:59Z2023-11-15T23:59:59Z2023-11-20T23:59:59Z
|
|||
|
RMA番号
RmaNumber
|
返品承認(RMA)トランザクションのユニークな識別子。 | ||
|
説明
RMA番号は、顧客が商品を返品するための正式な承認です。これは返品ケースIDと同じであることが多いですが、一部のシステムでは、それ以前の別の識別子となる場合があります。 この属性は、社内ユーザーと顧客の両方にとって馴染みのある主要なビジネス参照番号として機能します。ケースの検索やフィルタリングに使用でき、返品に関するコミュニケーションにおいて主要な番号として利用されることがよくあります。
その重要性
主要なビジネス参照番号として機能し、運用追跡や顧客とのコミュニケーションに不可欠です。
取得元
これは、Oracle Order Management内の返品承認(RMA)オブジェクトの主要な識別子です。
例
789001789002789003
|
|||
|
SLA準拠
IsSlaCompliant
|
返金が定義されたSLA目標内で処理されたかどうかを示すブールフラグです。 | ||
|
説明
この計算属性は、各返品ケースのSLA適合性を示すシンプルな真偽インジケーターを提供します。これは、実際の返金完了タイムスタンプを「RefundSlaTargetDate」と比較することで決定されます。 このフラグは、コンプライアンス率を簡単に測定し、視覚化するために不可欠です。「返金ポリシーSLAコンプライアンス」ダッシュボードを動かし、「返金SLA達成率」KPIの計算を簡素化します。特定のケースがSLAを満たさない理由を理解するための迅速なフィルタリングと根本原因分析を可能にします。
その重要性
日付比較をシンプルなブール値の指標に変換することで、SLAの監視とレポート作成を簡素化します。
取得元
算出フィールドです。「Refund Processed」のタイムスタンプが「RefundSlaTargetDate」以前であれば真、そうでなければ偽となります。
例
truefalse
|
|||
|
エンドツーエンド返金時間
EndToEndRefundTime
|
返品リクエストの開始から返金の最終処理までの経過時間。 | ||
|
説明
この指標は、顧客視点から見た返金プロセスの全期間を測定します。これは、最初のイベント(例:「RMA作成済み」)のタイムスタンプと、返金完了イベント(例:「返金処理済み」)のタイムスタンプの差として計算されます。 主要なKPIとして、この計算は「全体の返金処理サイクルタイム」ダッシュボードや顧客体験の監視にとって重要です。平均時間が長いことは、対処すべきシステム上の非効率性を示しています。この値の分布を分析することは、外れ値を特定し、高いレベルでのプロセスパフォーマンスを理解するのに役立ちます。
その重要性
これは、プロセス全体の効率と顧客満足度への影響を直接測定する主要業績評価指標(KPI)です。
取得元
各返品ケースIDについて、「Refund Processed」アクティビティのStartTimeから最初のアクティビティのStartTimeを差し引くことで計算されます。
例
10日4時間21日8時間5日0時間
|
|||
|
倉庫ID
WarehouseId
|
返品された商品を受け取った倉庫または施設の識別子。 | ||
|
説明
この属性は、顧客から返品された商品が受領・処理された特定の物理的な場所(配送センターや倉庫など)を示します。 倉庫ごとにプロセスを分析することは、場所固有のパフォーマンス問題を特定するために重要です。これにより、異なる施設間での検査時間、処分結果、および全体的なサイクルタイムの比較が可能になります。特定の拠点における運用非効率性、人員配置の問題、またはトレーニングニーズを浮き彫りにすることができます。
その重要性
場所ごとのパフォーマンス分析を可能にし、地域や施設固有のボトルネックや非効率性を特定するのに役立ちます。
取得元
このフィールドは、しばしば「ORGANIZATION_ID」と呼ばれ、Oracle Inventory Managementにおける受領トランザクションに関連付けられています。
例
WH-US-WESTWH-EU-CENTRALDC-01
|
|||
|
手戻り
IsRework
|
アクティビティが手戻りループの一部であるかを示すブール値フラグです。 | ||
|
説明
このフラグは、同一ケース内の以前のステップの繰り返しである活動を識別し、プロセスループまたは手戻りを示します。例えば、商品が検査に不合格となり再検査が必要な場合、2回目の検査イベントは手戻りとしてフラグ付けされます。 この属性は、プロセス非効率性を定量化するための基本です。「返品処理手戻り率」ダッシュボードで使用され、「返品手戻りイベント頻度」KPIの計算に用いられます。手戻りの量と原因を特定することはプロセスマイニングの主要な目標であり、無駄な労力、遅延、コスト増に直接関連します。
その重要性
プロセスの非効率性やループを直接特定し、手戻りの原因を定量化して分析することを容易にします。
取得元
これは、単一ケース内で繰り返される活動を検出するプロセスマイニングソフトウェアのアルゴリズムによって識別される計算属性です。
例
truefalse
|
|||
|
製品ID
ProductId
|
返品される製品のユニークな識別子。 | ||
|
説明
この属性は、返品に関わる特定の製品のSKUや品目番号のようなユニークな識別子です。返品プロセスを製品カタログにリンクします。 製品レベルの分析は、問題のある品目を特定するために重要です。製品IDでプロセス分析をフィルタリングまたはディメンション化することで、企業は返品率が高い製品、検査時間が長い製品、または特定の欠陥パターンを持つ製品を正確に特定できます。この情報は、品質管理、サプライチェーン管理、および製品開発にとって不可欠です。
その重要性
返品プロセスを特定の製品にリンクさせ、製品品質と返品パターンの分析を可能にします。
取得元
これは、Oracle Order ManagementまたはInventoryモジュールのRMA明細項目にある「INVENTORY_ITEM_ID」または類似のフィールドになります。
例
PROD-5540-ASKU-98765ITEM-001-B
|
|||
|
返品タイプ
ReturnType
|
返金を、返金、交換、修理といった期待される結果に基づいて分類します。 | ||
|
説明
この属性は、処理されている返品のタイプを分類します。プロセスフローと必要な手順は、顧客が金銭的な返金を受けるのか、代替品を受け取るのか、修理された商品を受け取るのかによって大きく異なります。 返品タイプごとにプロセスを分析することは、プロセスバリエーションを理解するために不可欠です。これにより、返金と交換の個別のプロセスをマッピングし、それぞれのパス固有のボトルネックとパフォーマンス特性を特定するのに役立ちます。このセグメンテーションは、ターゲットを絞ったプロセス改善努力の鍵となります。
その重要性
交換と返金は異なるプロセスパスをたどることが多いため、様々なプロセスパスに基づいて分析をセグメント化できます。
取得元
これは通常、Oracle Order ManagementのRMAヘッダーまたは明細項目上のカテゴリまたはタイプフィールドです。
例
返金交換修理
|
|||
|
返金額の差異
RefundAmountDiscrepancy
|
要求された返金額と実際の返金額との計算上の差額。 | ||
|
説明
この指標は、顧客が要求した金額と実際に受け取った金額との金銭的な差を定量化します。これは、「実際の返金額」を「要求された返金額」から差し引くことによって計算されます。 この計算値は、「返金額差異率」KPIの基礎となります。ゼロ以外の値は、プロセス中に調整が行われたことを示します。返品手数料や損害控除など、これらの差異の理由を分析することで、ポリシーの有効性や顧客コミュニケーションに関する洞察が得られます。
その重要性
返金プロセスにおける財務調整を定量化し、ポリシーや検査結果の影響を分析するのに役立ちます。
取得元
算出フィールド:「RequestedRefundAmount」-「ActualRefundAmount」
例
0.005.50-10.00
|
|||
|
退院区分コード
DispositionCode
|
返品された物理的な品目の最終的な取り扱いを示すコードです。 | ||
|
説明
処分コードは、検査後に返品された製品がどうなったか(例:在庫に戻された、廃棄された、修理のために送られた、ベンダーに返品されたなど)を特定します。 この情報は、返品の財務的および運用上の影響を分析する上で貴重です。処分コードを分析することで、企業は再販不能な商品に関連するコストを把握し、修理プロセスを改善する機会を特定できます。これにより、返品プロセスが在庫と財務結果に結びつけられます。
その重要性
返品プロセスを在庫における物理的な結果と結びつけ、回収率とコストに関する洞察を提供します。
取得元
この情報は、検査活動が完了した後、Oracle Inventory ManagementまたはWarehouse Managementモジュールで捕捉されます。
例
在庫へ戻す廃棄再生ベンダーへ返品
|
|||
|
顧客ID
CustomerId
|
返品を開始した顧客を特定するためのユニークな識別子です。 | ||
|
説明
この属性は、返品ケースに関連付けられた顧客を識別するユニークなIDです。返品プロセスを顧客データベースにリンクします。 顧客中心の視点から返品を分析することで、重要なパターンが明らかになることがあります。例えば、異常に高い返品頻度を持つ顧客を特定するのに役立ち、これは満足度の問題や潜在的な不正を示す可能性があります。また、顧客セグメントに基づいた分析も可能にし、特定のグループが異なる返品行動を示すかどうかを理解するのに役立ちます。
その重要性
顧客中心の分析を可能にし、リピート返品者、行動セグメント、潜在的な詐欺を特定するのに役立ちます。
取得元
Oracle Order Managementの元の販売注文または返品リクエストのヘッダーにある顧客または当事者IDとして見つかります。
例
CUST-100589743ACC-54321
|
|||
返品・返金処理アクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
|
RMA作成済み
|
この活動は、返品プロセスが正式に開始されることを示し、Oracle Fusion SCMで返品承認(RMA)が作成されます。このイベントは通常、ユーザーまたは自動プロセスが新しいRMA販売オーダー記録を生成した際に明示的に捕捉されます。 | ||
|
その重要性
これは、返品プロセス全体の主要な開始イベントです。この活動から他の活動までの時間を分析することで、全体のプロセス期間が明らかになり、初期の遅延を特定するのに役立ちます。
取得元
これは、Oracle Fusion Order Managementにおける返品オーダーヘッダーの作成タイムスタンプから捕捉されます。このイベントはRMA文書の初期保存に対応します。
取得
返品オーダーヘッダー記録の作成日を追跡します。
イベントタイプ
explicit
|
|||
|
RMA承認済み
|
この重要なマイルストーンは、返品リクエストがビジネスルールに従って検証され、承認されたことを示します。これは通常、RMAのステータス変更から推測され、顧客への出荷などの後続のプロセスステップを解除します。 | ||
|
その重要性
承認はプロセスの重要なゲートウェイです。ここでの遅延は、返品の総サイクルタイムと顧客満足度に直接影響します。このアクティビティは、承認のボトルネックを分析するために不可欠です。
取得元
RMAオーダーヘッダーまたは明細のステータスが「Approved」または「Awaiting Receiving」状態に移行したタイムスタンプから推測されます。
取得
RMAステータスが承認済みの状態に更新された際のタイムスタンプをキャプチャします。
イベントタイプ
inferred
|
|||
|
クレジットメモ作成
|
これは、顧客への返金を承認するためにAccounts Receivableでクレジットメモが生成される財務活動です。これはOrder Managementの返品プロセスによってトリガーされる明示的なイベントです。 | ||
|
その重要性
クレジットメモの作成は、企業が顧客に返金する意思を示す決定的な節目です。これはプロセス全体の財務決済部分のトリガーとなります。
取得元
これはOracle Accounts Receivableにおける明示的なトランザクションです。このイベントは、クレジットメモ上の販売オーダー参照を介して元のRMAにリンクし直すことができます。
取得
ARにおけるクレジットメモトランザクションの作成日を使用します。
イベントタイプ
explicit
|
|||
|
品目受領済み
|
この活動は、返品された商品が倉庫または処理センターで物理的に受領されたことを示します。Oracle Fusion Inventory Managementにおいて、RMAに対して商品がスキャンされ、受領済みとして記録された際に捕捉される明示的なイベントです。 | ||
|
その重要性
品目の受領は、その後の検査および処理ステップをトリガーする重要なマイルストーンです。「RMA Approved」から「Item Received」までの時間を測定することで、ロジスティクスおよび出荷パフォーマンスの分析に役立ちます。
取得元
これはOracle Inventory Managementに記録された明示的なトランザクションです。このイベントはRMA受領のトランザクション日付に対応します。
取得
InventoryにおけるRMA受領のトランザクションタイムスタンプを使用します。
イベントタイプ
explicit
|
|||
|
品目検査済み
|
この活動は、品質評価が記録される商品検査プロセスの完了を示します。これは通常、Oracle Inventory ManagementまたはQuality ManagementにおけるRMAステータスを更新する明示的なトランザクションです。 | ||
|
その重要性
検査の結果は、返金承認や却下といった次のステップに直接影響します。検査活動自体の期間は、倉庫効率の主要業績評価指標(KPI)です。
取得元
Oracle InventoryまたはQuality Managementで検査員がRMA受領に対する検査タスクを完了した際の取引タイムスタンプからキャプチャされます。
取得
検査トランザクションの完了タイムスタンプを使用します。
イベントタイプ
explicit
|
|||
|
返品ケースクローズ済み
|
これは最終活動であり、受領、処分、財務決済を含むRMAに関連するすべての行動が完了したことを示します。これはRMAオーダーの最終的な「クローズ済み」ステータスから推測されます。 | ||
|
その重要性
このイベントはプロセスの決定的な終了として機能し、エンドツーエンドのサイクルタイムを計算し、ケースが際限なく未解決のままになるのを防ぐ上で不可欠です。
取得元
Oracle Order ManagementでRMAオーダーヘッダーとそのすべての明細が最終的な「Closed」ステータスに達したタイムスタンプから推測されます。
取得
RMAヘッダーまたは明細のステータスが「Closed」に変更された最後のタイムスタンプをキャプチャします。
イベントタイプ
inferred
|
|||
|
返金処理済み
|
この活動は、顧客への返金支払いの完了を示します。Oracle Financialsで支払い決済トランザクションが記録された際に捕捉される明示的なイベントです。 | ||
|
その重要性
これは、顧客視点からの総返金サイクル時間を測定する上で重要な終点です。顧客への財務上の義務が果たされたことを確認します。
取得元
このイベントは、クレジットメモを決済するOracle Accounts PayableまたはTreasuryにおける支払いトランザクションの会計日または決済日から捕捉されます。
取得
クレジットメモを決済する支払いトランザクションの決済日を使用します。
イベントタイプ
explicit
|
|||
|
RMA却下済み
|
顧客の返品リクエストを拒否するという最終決定を表します。これは通常、承認フェーズ中にRMAのステータスが「Rejected」または「Cancelled」に変更されることから推測されます。 | ||
|
その重要性
これは重要な例外パスです。却下の頻度と理由を分析することで、返品ポリシー、顧客の期待、または不正行為の試みに関する問題を明らかにできます。
取得元
RMAオーダーヘッダーまたは明細のステータスが「Rejected」または同等の最終ステータスに変更されたタイムスタンプから推測されます。
取得
ステータスが「Rejected」または「Cancelled」に変更されたタイムスタンプを特定します。
イベントタイプ
inferred
|
|||
|
RMA承認申請済み
|
これは、作成されたRMAが内部レビューおよび承認のために提出される時点を表します。これは多くの場合、RMAのステータス変更から推測され、RMAがドラフトまたは入力状態から承認待ち状態に移行したことを示します。 | ||
|
その重要性
これを追跡することは、承認前フェーズの期間を測定するのに役立ちます。データ入力時間と、承認者が行動を起こすのを待つ実際の時間を区別します。
取得元
RMAオーダーヘッダーまたは明細のステータスが、オーダー管理承認ワークフロー内で「Pending Approval」または同等のステータスに変更されたタイムスタンプから推測されます。
取得
ステータスが「Pending Approval」に変更されたタイムスタンプを特定します。
イベントタイプ
inferred
|
|||
|
交換オーダー作成済み
|
この活動は、顧客が返金ではなく交換を要求した場合に発生します。これは、新しい販売オーダーが生成される明示的なイベントであり、多くの場合、元のRMAにリンクされています。 | ||
|
その重要性
この活動は重要なプロセスバリアントを特定します。交換プロセスを返金プロセスから分離することは、各パスの正確なサイクルタイム分析の鍵となります。
取得元
これは明示的なイベントであり、Order Managementにおける新しい販売オーダー文書の作成です。参照フィールドを介してRMAにリンクし直す必要があります。
取得
RMAにリンクされた新しい販売オーダーの作成日を使用します。
イベントタイプ
explicit
|
|||
|
品目検査開始
|
返品された品目の状態を評価するための物理的な検査の開始を示します。これは、倉庫管理モジュール内での品目の場所やステータスの変更から推測されるか、明示的なスキャンである可能性があります。 | ||
|
その重要性
品目受領から検査開始までの時間を測定することで、検査ステーションでのキューイング遅延(一般的なボトルネック)が浮き彫りになります。
取得元
これは、受領明細行のステータス変更、またはOracle Inventory Managementで商品を検査場所に移動するトランザクションによって捕捉される可能性があります。明示的に捕捉するには、カスタム構成が必要となる場合があります。
取得
ステータス変更または検査エリアへの在庫転送のタイムスタンプ。
イベントタイプ
inferred
|
|||
|
返品処分決定済み
|
検査後、このアクティビティは、返品された品目をどうするか、例えば「在庫に戻す」または「廃棄する」といった決定を表します。これは、品目を最終目的地に移動させる明示的な在庫トランザクションを通じて記録されます。 | ||
|
その重要性
このステップは在庫精度と財務照合にとって重要です。処分を分析することは、返品理由と製品品質の問題を理解するのに役立ちます。
取得元
検査後、Oracle Inventory Managementでサブインベントリ転送や品目ステータス更新などのトランザクションとして記録されます。
取得
処分を実行する在庫トランザクションのタイムスタンプを追跡します。
イベントタイプ
explicit
|
|||
|
返金開始
|
この活動は、返金の支払いプロセスが開始されたことを示します。これは多くの場合、クレジットメモのステータス変更、つまり未処理の状態から支払い処理中を示す状態への移行から推測されます。 | ||
|
その重要性
この活動は、クレジットメモの承認と作成を実際の支払い処理から切り離すのに役立ちます。支払い処理は別のチームやシステムによって行われる可能性があり、遅延の原因となることがあります。
取得元
売掛金管理におけるクレジットメモのステータス変更、またはクレジットメモを参照する買掛金管理における支払い記録の作成から推測されます。
取得
クレジットメモのステータスが「Pending Payment」またはそれに類似するものに変更されたタイムスタンプを特定します。
イベントタイプ
inferred
|
|||
|
顧客による品目発送済み
|
顧客が返品品を会社に返送する行動を表します。このイベントはOracle SCMで直接捕捉されないことが多いですが、運送業者連携データまたは手動更新から推測される場合があります。 | ||
|
その重要性
この活動は、顧客行動と商品の輸送にかかる時間に関する洞察を提供します。これにより、内部処理の遅延と出荷による遅延を区別するのに役立ちます。
取得元
これは、RMAにリンクされたキャリア出荷データに基づく推論イベントであるか、Oracle SCMでの手動ステータス更新である可能性があります。統合が存在しない場合、このイベントは利用できない場合があります。
取得
統合されたキャリアAPIからのタイムスタンプまたは手動データ入力フィールド。
イベントタイプ
inferred
|
|||
|
顧客通知済み
|
これは、返金処理済みや交換品発送済みなど、返品ケースの解決を顧客に確認するために送信される通信を表します。これは多くの場合、通信ログまたはケースのステータス更新から捕捉されます。 | ||
|
その重要性
タイムリーな顧客コミュニケーションは満足度にとって不可欠です。これを分析することで、コミュニケーションに関するサービスレベル契約が満たされていることを確認するのに役立ちます。
取得元
システム分析が必要です。これは統合されたCRMまたはコミュニケーションプラットフォームによってログに記録されるか、RMAまたは関連するサービスリクエストの手動ステータス更新である可能性があります。
取得
外部通信システムからのタイムスタンプまたは手動更新。
イベントタイプ
inferred
|
|||