返品・返金処理のデータテンプレート
返品・返金処理のデータテンプレート
- 収集を推奨する属性
- プロセス分析で追跡する主要なアクティビティ
- Oracle Fusion SCMからのデータ抽出手順
返品・返金処理の属性
| 名前 | 説明 | ||
|---|---|---|---|
|
アクティビティ
ActivityName
|
返品・返金プロセスで発生した、特定の業務ステップまたはイベントの名称です。 | ||
|
説明
この属性は、「RMA作成」「商品検品完了」「返金処理完了」など、返品のライフサイクルにおける個々のステップや節目を表します。各アクティビティは、システムのイベントログに記録されたプロセス上の特定の時点を示します。 アクティビティの順序や所要時間の分析は、プロセスマイニングの中核です。プロセスマップの可視化、ステップ間のボトルネックの特定、アクティビティごとのリードタイムの算出に役立ちます。プロセスの流れや手戻り、標準業務手順への適合性を把握するうえで欠かせないデータです。
重要な理由
アクティビティはプロセスマップの基盤となり、プロセスの流れやばらつき、ボトルネックの可視化と分析を可能にします。
入手先
Order ManagementやInventory Managementなど、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でイベント単位のデータをまとめることで、一貫したプロセスの全体像を確認できます。
重要な理由
関連するすべてのイベントを1つのプロセスインスタンスにまとめるための基本キーであり、プロセス全体の分析を可能にします。
入手先
通常、返品申請の開始時にOracle Order ManagementまたはServiceモジュールで生成されます。
例
RMA-2023-00123RMA-2023-00456RMA-2023-00789
|
|||
|
ソースシステム
SourceSystem
|
データの抽出元となるシステムです。 | ||
|
説明
イベントデータが記録された元の情報システムを示す属性です。このプロセスでは、通常「Oracle Fusion SCM」が該当します。 複数のシステムを連携している環境では、データの来歴確認や問題の調査に欠かせないフィールドです。データの出所を確認できるほか、特定のシステムからのイベントに絞って分析する際にも使えます。これにより、データ品質とコンテキストを維持できます。
重要な理由
データの出所に関する重要なコンテキストを示します。複数のシステムを使う環境で、データを検証・分析するうえで欠かせません。
入手先
通常、データの抽出、変換、読み込み(ETL)の際に、データセットの出所を示す固定値として追加します。
例
Oracle Fusion SCMOracle SCM Cloud
|
|||
|
最終データ更新
LastDataUpdate
|
ソースシステムからデータを最後に更新または抽出した時刻を示すタイムスタンプです。 | ||
|
説明
この属性は、データセットが最後に更新された時刻を示します。個々のイベントではなく、データセット全体の鮮度を示す日付です。 最終データ更新時刻を把握することは、分析データの新しさを理解するうえで重要です。ダッシュボードや重要業績評価指標(KPI)を正しく読み取るために、リアルタイムの情報なのか、数時間または数日前のデータなのかを確認できます。プロセスマイニングプロジェクトに欠かせないメタデータです。
重要な理由
データの新しさを示し、分析のコンテキストや適時性を正しく理解できるようにします。
入手先
このタイムスタンプは、データの抽出、変換、読み込み(ETL)の際に生成・追加されます。
例
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
|
顧客に実際に返金処理された最終的な金額です。 | ||
|
説明
この属性は、検査、調整、手数料の適用後に顧客へ返金された、確定済みの最終金額を示します。返品案件における実際の金銭的な結果を表します。 「返金希望額と実際の返金額」ダッシュボードで使用する重要な財務データです。希望額と比較することで、「返金額の差異率」KPIを算出し、返品ポリシー、商品の状態、処理時の調整が財務に与える影響を把握できます。
重要な理由
返品による実際の金銭的な結果を示し、差異分析や財務報告に役立ちます。
入手先
Oracle Fusion Financialsで返品案件に紐づくクレジットメモまたは買掛金取引の記録から取得できると考えられます。
例
129.9940.000.00
|
|||
|
終了時刻
EndTime
|
アクティビティが完了した時刻を示すタイムスタンプです。 | ||
|
説明
終了時刻は、アクティビティが完了した時点を示します。StartTimeがイベントの開始時刻を示すのに対し、終了時刻はそのイベントの実際の処理時間を算出するために必要です。瞬時に完了するイベントでは、StartTimeと終了時刻が同じ場合があります。 分析では、終了時刻とStartTimeの差から、アクティビティの「処理時間」を算出します。ステップ間の待ち時間ではなく、どのステップ自体に時間がかかっているかを特定するうえで重要です。詳細なボトルネック分析やリソース効率の算出にも欠かせません。
重要な理由
個々のアクティビティの実際の処理時間を算出するために必要な属性です。実作業の時間と待ち時間を区別できます。
入手先
ソースシステムのログに独立したフィールドとして記録されている場合と、後続アクティビティのStartTimeから算出する場合があります。
例
2023-10-26T10:05:00Z2023-10-26T15:00:10Z2023-10-27T11:30:00Z
|
|||
|
返品ステータス
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
|
|||
|
返金希望額
RequestedRefundAmount
|
返品時に顧客が当初希望した返金額です。 | ||
|
説明
この属性には、プロセス開始時に顧客が希望した返金額が記録されます。最終的な返金額と比較するための基準額です。 このデータは、「返金希望額と実際の返金額」ダッシュボードと「返金額の差異率」KPIに欠かせません。希望額と実際の返金額の差を分析すると、返品商品の誤り、再入庫手数料、ポリシーの調整などの問題を特定でき、金額の正確性や顧客満足度の把握に役立ちます。
重要な理由
財務分析の基準となり、返金額の差異を算出して潜在的な問題を明らかにします。
入手先
この値は、Oracle Fusion SCMのRMAまたは返品依頼のヘッダーに保存されます。Order Managementモジュールに格納されている可能性があります。
例
129.9945.501200.00
|
|||
|
RMA番号
RmaNumber
|
返品商品承認取引を一意に識別する番号です。 | ||
|
説明
RMA番号は、顧客が製品を返品するための正式な承認番号です。返品案件IDと同じ場合が多いものの、システムによっては別の先行IDとして管理されます。 この属性は、社内の担当者と顧客の双方にとってわかりやすい、主要な業務参照番号です。案件の検索や絞り込みに使用でき、返品に関する連絡で主に使われる番号でもあります。
重要な理由
業務上の主要な参照番号として、処理状況の追跡や顧客との連絡に役立ちます。
入手先
Oracle Order Managementの返品商品承認オブジェクトに設定されている主要な識別子です。
例
789001789002789003
|
|||
|
SLA遵守状況
IsSlaCompliant
|
返金が定められたSLA目標内に処理されたかどうかを示す真偽値です。 | ||
|
説明
この計算属性は、各返品案件のSLA適合状況を真または偽で示します。「RefundSlaTargetDate」と実際の返金完了タイムスタンプを比較して判定します。 このフラグは、コンプライアンス率の測定や可視化に役立ちます。「返金ポリシーのSLA遵守状況」ダッシュボードで使用され、「返金SLA適合率」KPIの算出も簡単になります。条件で絞り込んで根本原因を分析し、SLAを満たせなかった案件の理由をすばやく調べられます。
重要な理由
日付の比較結果を単純な真偽値にすることで、SLAの監視や報告を簡単にします。
入手先
計算項目です。「Refund Processed」のタイムスタンプが「RefundSlaTargetDate」以前であれば真、それ以外は偽です。
例
truefalse
|
|||
|
倉庫ID
WarehouseId
|
返品された商品を受け取った倉庫または施設のIDです。 | ||
|
説明
この属性は、顧客から返品された商品を受け取り、処理した配送センターや倉庫などの物理的な場所を示します。 倉庫ごとの分析は、拠点固有のパフォーマンス上の問題を特定するうえで重要です。施設間で検査時間、処分結果、全体のサイクルタイムを比較できます。特定の拠点における業務の非効率、人員配置の問題、トレーニングの必要性を明らかにできます。
重要な理由
場所ごとのパフォーマンスを分析し、地域や施設に固有のボトルネックや非効率を特定できます。
入手先
「ORGANIZATION_ID」と呼ばれることが多いこの項目は、Oracle Inventory Managementの受入取引に紐づいています。
例
WH-US-WESTWH-EU-CENTRALDC-01
|
|||
|
処分コード
DispositionCode
|
返品された現物を最終的にどのように処理したかを示すコードです。 | ||
|
説明
処分コードは、検査後に返品された製品をどのように扱ったかを示します。たとえば、在庫に戻した、廃棄した、再生処理に回した、仕入先に返却した、といった内容です。 この情報は、返品が財務や業務に与える影響の分析に役立ちます。処分コードを分析すると、再販売できない商品のコストを把握し、再生処理の改善機会を特定できます。返品プロセスと在庫・財務上の結果を結びつける情報です。
重要な理由
返品プロセスを在庫上の処理結果と結びつけ、回収率やコストの把握に役立ちます。
入手先
検査アクティビティの完了後、Oracle Inventory ManagementまたはWarehouse Managementモジュールに記録されます。
例
RETURN_TO_STOCKSCRAPREFURBISHRETURN_TO_VENDOR
|
|||
|
手戻りの有無
IsRework
|
アクティビティが手戻りループの一部かどうかを示す真偽値です。 | ||
|
説明
このフラグは、同じ案件内で前の手順が繰り返されたアクティビティを特定し、プロセスのループや手戻りを示します。たとえば、検査に不合格となった商品を再検査する場合、2回目の検査イベントに手戻りのフラグが付きます。 この属性は、プロセスの非効率を定量化するうえで欠かせません。「返品処理の手戻り率」ダッシュボードで使用され、「返品の手戻りイベント頻度」KPIの算出にも使われます。手戻りの量や原因を特定することは、プロセスマイニングの主な目的の1つです。無駄な作業、遅延、コスト増加を直接把握できます。
重要な理由
プロセスの非効率やループを直接示し、手戻りの量や原因を簡単に分析できます。
入手先
プロセスマイニングソフトウェアが、1つの案件内で繰り返されたアクティビティを検出して算出する属性です。
例
truefalse
|
|||
|
製品ID
ProductId
|
返品対象の製品を一意に識別するIDです。 | ||
|
説明
この属性は、返品対象の製品を特定するSKUや品目番号などの一意のIDです。返品プロセスと製品カタログを紐づけます。 製品単位の分析は、問題のある商品を特定するうえで欠かせません。製品IDでプロセス分析を絞り込んだり、分析軸として設定したりすると、返品率が高い商品、検査に時間がかかる商品、特定の不良パターンがある商品を特定できます。この情報は、品質管理、サプライチェーン管理、製品開発に役立ちます。
重要な理由
返品プロセスを個々の製品に紐づけ、製品の品質や返品傾向を分析できます。
入手先
Oracle Order ManagementまたはInventoryモジュールのRMA明細にある「INVENTORY_ITEM_ID」などの項目が該当します。
例
PROD-5540-ASKU-98765ITEM-001-B
|
|||
|
返品種別
ReturnType
|
返金、交換、修理など、想定される対応内容に基づいて返品を分類します。 | ||
|
説明
この属性は、処理対象の返品の種類を分類します。顧客への返金、代替品の提供、修理品の返却のいずれかによって、プロセスの流れや必要な手順は大きく異なります。 返品種別ごとの分析は、プロセスの違いを把握するうえで欠かせません。返金と交換のプロセスマップを分けて作成し、それぞれの経路に固有のボトルネックやパフォーマンスの特徴を特定できます。この分類は、対象を絞ったプロセス改善に役立ちます。
重要な理由
交換と返金では手順が異なることが多いため、プロセス経路ごとに分析を分けられます。
入手先
通常、Oracle Order ManagementのRMAヘッダーまたは明細にあるカテゴリ項目や種別項目が該当します。
例
返金交換修理
|
|||
|
返金額の差異
RefundAmountDiscrepancy
|
返金希望額と実際の返金額の差を算出した値です。 | ||
|
説明
顧客の希望額と実際の返金額との差を金額で示す指標です。「RequestedRefundAmount」から「ActualRefundAmount」を差し引いて算出します。 この計算値は、「返金額の差異率」KPIの基礎となります。値が0でない場合、処理中に金額が調整されたことを示します。再入庫手数料や破損による控除など、差異の理由を分析すると、ポリシーの有効性や顧客への説明方法を見直す手がかりになります。
重要な理由
返金処理における金額調整を定量化し、ポリシーや検査結果の影響を分析できます。
入手先
計算項目:「RequestedRefundAmount」-「ActualRefundAmount」。
例
0.005.50-10.00
|
|||
|
顧客ID
CustomerId
|
返品を開始した顧客を一意に識別するIDです。 | ||
|
説明
この属性は、返品案件に関連する顧客を特定する一意のIDです。返品プロセスと顧客データベースを紐づけます。 顧客の視点から返品を分析すると、重要な傾向が見えてきます。たとえば、返品頻度が異常に高い顧客を特定し、満足度の問題や不正の可能性を調べることができます。また、顧客セグメントごとの分析により、グループによって返品行動に違いがあるかを把握できます。
重要な理由
顧客を軸に分析できるため、返品を繰り返す顧客やセグメントごとの傾向、不正の可能性を特定できます。
入手先
Oracle Order Managementで、元の販売注文または返品依頼のヘッダーにある顧客IDまたは取引先IDから取得できます。
例
CUST-100589743ACC-54321
|
|||
返品・返金処理のアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
|
RMA作成
|
このアクティビティは、Oracle Fusion SCMで返品承認(RMA)が作成され、返品プロセスが正式に始まったことを示します。通常、ユーザーまたは自動処理によって新しいRMA販売オーダーのレコードが作成された際に、イベントとして明示的に記録されます。 | ||
|
重要な理由
返品プロセス全体の主な開始イベントです。このアクティビティから後続のアクティビティまでの時間を分析すると、プロセス全体の所要時間を把握し、初期段階の遅延を特定できます。
入手先
Oracle Fusion Order Managementの返品オーダーヘッダーに記録された作成タイムスタンプから取得します。このイベントは、RMA文書を最初に保存した時点に該当します。
記録
返品オーダーヘッダーレコードの作成日を記録します。
イベントタイプ
explicit
|
|||
|
RMA承認
|
返品申請が業務ルールに基づいて確認・承認されたことを示す重要な節目です。通常、RMAのステータス変更から判断し、顧客への出荷など後続のプロセスに進める状態になったことを表します。 | ||
|
重要な理由
承認はプロセスの重要なゲートウェイです。ここでの遅延は返品の総サイクルタイムと顧客満足度に直接影響します。承認に関するボトルネックの分析に欠かせないアクティビティです。
入手先
RMAオーダーヘッダーまたは明細のステータスが「承認済み」または「入荷待ち」に変わったタイムスタンプから判断します。
記録
RMAのステータスが承認済みに更新されたタイムスタンプを記録します。
イベントタイプ
inferred
|
|||
|
クレジットメモ作成
|
顧客への返金を承認するため、売掛金管理でクレジットメモを作成する財務アクティビティです。Order Managementの返品プロセスによって発生するイベントとして明示的に記録されます。 | ||
|
重要な理由
クレジットメモの作成は、顧客への返金を会社が確定したことを示す節目です。プロセスのうち、財務決済に関わる一連の処理を開始します。
入手先
Oracle Accounts Receivableに明示的に記録される取引です。クレジットメモの販売オーダー参照を使って、元のRMAと関連付けられます。
記録
ARでのクレジットメモ取引の作成日を使用します。
イベントタイプ
explicit
|
|||
|
商品受領
|
返品商品が倉庫または処理センターに物理的に到着したことを示します。Oracle Fusion Inventory Managementで商品をスキャンし、RMAに対する受領として記録した際に、イベントとして明示的に取得されます。 | ||
|
重要な理由
商品の受領は、その後の検品や処理を開始する重要な節目です。「RMA承認」から「商品受領」までの時間を測定すると、物流や配送の状況を分析できます。
入手先
Oracle Inventory Managementに明示的に記録される取引です。このイベントは、RMA受領の取引日に該当します。
記録
Inventoryに記録されたRMA受領の取引タイムスタンプを使用します。
イベントタイプ
explicit
|
|||
|
商品検品完了
|
商品の検品が完了し、品質評価が記録されたことを示します。通常、Oracle Inventory ManagementまたはQuality Managementで明示的に取引として記録され、RMAのステータスが更新されます。 | ||
|
重要な理由
検品結果は、返金の承認や却下など、その後の対応に直接影響します。検品アクティビティ自体にかかる時間は、倉庫業務の効率を測る重要な指標です。
入手先
Oracle InventoryまたはQuality Managementで、検査担当者がRMA受領品の検品タスクを完了した際の取引タイムスタンプから取得します。
記録
検品取引の完了タイムスタンプを使用します。
イベントタイプ
explicit
|
|||
|
返品案件クローズ
|
RMAに関する受領、処置、財務決済など、すべての対応が完了したことを示す最終アクティビティです。通常、RMAオーダーの最終ステータスが「クローズ」になったことから判断します。 | ||
|
重要な理由
プロセスの明確な終点となるイベントです。全体のサイクルタイムを算出し、案件がいつまでも未完了のまま残らないようにするうえで重要です。
入手先
Oracle Order Managementで、RMAオーダーヘッダーとすべての明細の最終ステータスが「クローズ」になったタイムスタンプから判断します。
記録
RMAヘッダーまたは明細のステータスが「クローズ」に変わった最後のタイムスタンプを記録します。
イベントタイプ
inferred
|
|||
|
返金処理完了
|
顧客への返金支払いが完了したことを示します。Oracle Financialsに支払いの消込取引が記録された際に、イベントとして明示的に取得されます。 | ||
|
重要な理由
顧客の視点から返金の総サイクルタイムを測るうえで、重要な終点となるイベントです。顧客に対する金銭的な債務が履行されたことを確認できます。
入手先
クレジットメモを決済する支払い取引について、Oracle Accounts PayableまたはTreasuryに記録された会計日または消込日から取得します。
記録
クレジットメモを決済する支払い取引の消込日を使用します。
イベントタイプ
explicit
|
|||
|
RMA却下
|
顧客の返品申請を却下する最終判断を示します。通常、承認段階でRMAのステータスが「却下」または「キャンセル」に変わったことから判断します。 | ||
|
重要な理由
これは重要な例外経路です。却下の頻度や理由を分析すると、返品ポリシー、顧客の期待、不正行為の試みに関する問題が明らかになることがあります。
入手先
RMAオーダーヘッダーまたは明細のステータスが「却下」または同等の最終状態に変わったタイムスタンプから判断します。
記録
ステータスが「却下」または「キャンセル」に変わったタイムスタンプを特定します。
イベントタイプ
inferred
|
|||
|
RMA承認申請
|
作成したRMAを社内の確認・承認に回した時点を示します。多くの場合、RMAのステータスが下書きまたは入力中から承認待ちに変わったことから判断します。 | ||
|
重要な理由
この時点を記録すると、承認前の所要時間を測定できます。データ入力にかかった時間と、承認者の対応を待つ時間を分けて把握できます。
入手先
Order Managementの承認ワークフローで、RMAオーダーヘッダーまたは明細のステータスが「承認待ち」または同等の状態に変わったタイムスタンプから判断します。
記録
ステータスが「承認待ち」に変わったタイムスタンプを特定します。
イベントタイプ
inferred
|
|||
|
交換オーダー作成
|
顧客が返金ではなく交換を希望した場合に発生するアクティビティです。通常、元のRMAに関連付けられた新しい販売オーダーが作成されたイベントとして明示的に記録されます。 | ||
|
重要な理由
このアクティビティは、重要なプロセスバリアントを特定します。各経路のサイクルタイムを正確に分析するには、交換と返金のプロセスを分けて把握する必要があります。
入手先
Order Managementで新しい販売オーダー文書を作成したイベントとして明示的に記録されます。参照フィールドを使ってRMAと関連付ける必要があります。
記録
RMAに関連付けられた新しい販売オーダーの作成日を使用します。
イベントタイプ
explicit
|
|||
|
商品検品開始
|
返品商品の状態を確認するため、実物の検品を開始したことを示します。倉庫管理モジュールで商品の場所やステータスが変わったことから判断する場合と、スキャンで明示的に記録する場合があります。 | ||
|
重要な理由
商品の受領から検品開始までの時間を測定すると、よくあるボトルネックである検品場所での待ち時間を把握できます。
入手先
Oracle Inventory Managementで、受領明細のステータス変更や、商品を検品場所へ移動する取引から取得できる場合があります。明示的に記録するには、個別の設定が必要になることがあります。
記録
ステータス変更、または検品エリアへの在庫移動のタイムスタンプ。
イベントタイプ
inferred
|
|||
|
返品商品の処置決定
|
検品後、返品商品を「在庫に戻す」か「廃棄する」かなど、商品の処置を決定するアクティビティです。商品を最終的な保管先へ移動する在庫取引として明示的に記録されます。 | ||
|
重要な理由
このステップは、在庫の正確性と財務照合に欠かせません。処置内容を分析すると、返品理由や製品品質の問題を把握できます。
入手先
検品後、サブ在庫間の移動や商品のステータス更新などの取引としてOracle Inventory Managementに記録されます。
記録
処置を実行した在庫取引のタイムスタンプを記録します。
イベントタイプ
explicit
|
|||
|
返金処理開始
|
返金の支払い処理が始まったことを示します。多くの場合、クレジットメモのステータスが未処理から支払い処理中を示す状態に変わったことから判断します。 | ||
|
重要な理由
このアクティビティにより、クレジットメモの承認・作成と実際の支払い処理を分けて把握できます。支払い処理は別のチームやシステムが担当する場合があり、遅延の原因となることもあります。
入手先
Accounts Receivableでのクレジットメモのステータス変更、またはクレジットメモを参照するAccounts Payableの支払いレコードの作成から判断します。
記録
クレジットメモのステータスが「支払い待ち」または同等の状態に変わったタイムスタンプを特定します。
イベントタイプ
inferred
|
|||
|
顧客による返品商品の発送
|
顧客が返品商品を会社へ送り返すアクティビティです。このイベントはOracle SCMに直接記録されないことが多く、配送業者との連携データや手動更新から判断する場合があります。 | ||
|
重要な理由
このアクティビティから、顧客の行動や商品の輸送にかかる時間を把握できます。社内処理の遅延と配送による遅延を区別するのに役立ちます。
入手先
RMAに関連付けられた配送データから判断するか、Oracle SCMでステータスを手動更新して記録します。連携がない場合、このイベントを取得できないことがあります。
記録
連携された配送業者APIのタイムスタンプ、または手動入力されたデータ。
イベントタイプ
inferred
|
|||
|
顧客への通知
|
返金の処理完了や交換品の発送など、返品案件の解決内容を顧客に伝えたことを示します。通常、連絡記録や案件のステータス更新から取得します。 | ||
|
重要な理由
顧客満足度を高めるには、適切なタイミングで連絡することが欠かせません。このアクティビティを分析すると、連絡に関するサービスレベル合意を遵守できているか確認できます。
入手先
システムの確認が必要です。連携されたCRMやコミュニケーションプラットフォームに記録される場合と、RMAまたは関連するサービスリクエストのステータスを手動で更新する場合があります。
記録
外部のコミュニケーションシステムのタイムスタンプ、または手動更新の記録。
イベントタイプ
inferred
|
|||
データ抽出ガイド
始める準備はできましたか?
このテンプレートを使ってデータ収集を効率化し、返品・返金処理に関するインサイトを得ましょう。今すぐプロセスの最適化を始めてください。
ボトルネックを解消し、返品・返金処理を今すぐ最適化
Oracle Fusion SCMで非効率な箇所を特定し、サイクルタイムを30%短縮します。
クレジットカードは不要です。5分以内に設定できます。