在庫管理データテンプレート
在庫管理データテンプレート
- 収集を推奨する属性
- プロセスディスカバリーで追跡する主要アクティビティ
- Oracle Fusion SCMからデータを抽出する方法
在庫管理の属性
| 名前 | 説明 | ||
|---|---|---|---|
|
アクティビティ名
ActivityName
|
実行された特定の在庫管理アクティビティの名称です。 | ||
|
説明
アクティビティ名は、特定のバッチまたはロットに関する在庫管理プロセス内で発生した1つのステップまたはイベントを表します。これらのイベントがプロセスフローの順序を構成します。 アクティビティの例には、「入庫記録」、「品質検査実施」、「在庫社内移動」、「出庫記録」などがあります。これらのアクティビティの順序と頻度を分析することは、プロセスマイニングの中核です。プロセスマップの可視化、逸脱の特定、ステップ間の遷移時間の分析が可能になります。
重要な理由
在庫ライフサイクルを構成する個別のステップとイベントを定義するため、プロセスマップの作成に欠かせない属性です。
入手先
通常は、ソーステーブル(例:INV_MATERIAL_TXNS)の取引タイプやイベントコードを、利用者に分かりやすいアクティビティ名に対応付けて作成します。
例
入荷記録棚入れの完了在庫差異の調整ピッキングの開始
|
|||
|
イベント開始時刻
EventStartTime
|
在庫アクティビティが開始された時点を示すタイムスタンプです。 | ||
|
説明
アクティビティが開始された正確な日時を記録する属性です。イベントを時系列に並べ、プロセスフローを構築するための主要な時間情報となります。 分析では、イベント開始時刻がアクティビティ間の所要時間や待ち時間の算出に使われます。ボトルネックの特定、「平均棚入れサイクルタイム」などのKPIにおけるサイクルタイムの測定、シフト・日・月など異なる期間でのプロセスパフォーマンス分析が可能になります。
重要な理由
イベントの順序付け、サイクルタイムと待ち時間の算出、プロセスのボトルネックの把握に欠かせないタイムスタンプです。
入手先
通常は、INV_MATERIAL_TXNSのTRANSACTION_DATEなど、在庫取引テーブルの取引日または作成日フィールドから取得します。
例
2023-10-01T08:05:21Z2023-11-15T14:30:00Z2024-01-20T21:00:15Z
|
|||
|
在庫バッチ/ロット
InventoryBatchLot
|
在庫品の特定のバッチまたはロットを一意に識別する番号であり、そのライフサイクルを追跡するためのケースIDとして機能します。 | ||
|
説明
在庫バッチまたはロット番号は、特定数量の製品に関連するすべてのアクティビティをまとめる主要なケース識別子です。これにより、在庫への入庫から、さまざまな移動、最終的な出庫または消費に至るまで、特定の在庫数量のライフサイクル全体を追跡できます。 プロセスマイニング分析では、この属性が基盤となります。入庫、品質検査、社内移動、出庫など、個別に記録されたイベントを、1つの一貫したプロセスインスタンスに結び付けます。在庫バッチ/ロット単位でプロセスを分析すると、エンドツーエンドのサイクルタイムを算出し、一般的な経路を特定し、特定の在庫グループに影響するボトルネックを見つけ出せます。
重要な理由
関連するすべての在庫アクティビティを結び付ける基本的なケース識別子です。これにより、在庫バッチの入庫から出庫までの全行程を追跡できます。
入手先
通常は、ロットまたはバッチ管理の詳細情報と関連付けられたINV_MATERIAL_TXNSなどの在庫取引テーブルに記録されています。
例
LOT2024-A01134BATCH-US-00582LPN-493820-202405
|
|||
|
ソースシステム
SourceSystem
|
データの抽出元となったシステムを識別します。 | ||
|
説明
在庫取引が記録されたソースアプリケーションを指定する属性です。大規模な企業では、在庫データが複数のシステムやモジュールから発生する場合があります。 ソースシステムの指定は、データガバナンスとデータの背景を理解するうえで重要です。データ抽出の問題を調査する際に役立つほか、異なるシステムやインスタンスにまたがるプロセスの比較にも利用できます。たとえば、地域ごとに異なるERPの在庫管理プロセスを比較できます。
重要な理由
データの出所に関する重要な背景情報を提供します。データ検証、ガバナンス、複数のシステムにまたがるプロセスの分析に役立ちます。
入手先
通常は、データの抽出・変換処理で追加される固定値で、データの出所を示すために使われます。
例
Oracle Fusion SCMOracle SCM Cloud-PRODFusion-ERP-US
|
|||
|
最終データ更新日時
LastDataUpdate
|
このレコードのデータがソースシステムから最後に更新された時点を示すタイムスタンプです。 | ||
|
説明
データがソースシステムから最後に抽出され、プロセスマイニングツールに読み込まれた日時を記録する属性です。分析対象データの鮮度を示します。 このタイムスタンプは、プロセス分析結果がどの時点の情報に基づくものかを把握するうえで重要です。ほぼリアルタイムのデータを見ているのか、過去の期間のスナップショットを見ているのかを確認できるため、適切なタイミングで判断するために役立ちます。
重要な理由
データの鮮度を示し、プロセス分析がどの程度最新の状態か、次回のデータ更新がいつ予定されているかを把握できるようにします。
入手先
データの抽出・変換・ロード(ETL)処理で生成されるメタデータフィールドです。
例
2024-05-21T02:00:00Z2024-05-20T02:00:00Z2024-05-19T02:00:00Z
|
|||
|
イベント終了時刻
EventEndTime
|
在庫アクティビティが完了した時点を示すタイムスタンプです。 | ||
|
説明
イベント終了時刻は、アクティビティの完了を示します。在庫取引の多くは一時点のイベントとして記録されますが、「品質検査」や「ピッキング」など、明確な所要時間を持つアクティビティもあります。瞬時に完了するイベントでは、終了時刻が開始時刻と同じになることがよくあります。 この属性はイベント開始時刻と組み合わせて、個々のアクティビティの処理時間を算出します。パフォーマンス分析、リソース利用状況の調査、想定以上に時間がかかり、プロセス全体の遅延につながるアクティビティの特定に役立ちます。
重要な理由
個々のアクティビティの処理時間を算出できるため、時間のかかっている具体的なステップを特定できます。
入手先
瞬時に完了する取引では、開始時刻と同じ場合があります。所要時間のあるアクティビティでは、該当するソーステーブルの別の完了タイムスタンプフィールドが使われます。
例
2023-10-01T08:05:21Z2023-11-15T15:00:00Z2024-01-20T21:05:45Z
|
|||
|
倉庫ロケーション
WarehouseLocation
|
アクティビティが発生した倉庫内の具体的な場所です。棚番やゾーンなどが該当します。 | ||
|
説明
在庫取引に関連する倉庫内の物理的な場所を指定する属性です。通路、ラック、棚番など、在庫が保管または移動された場所を詳細に把握できます。 倉庫ロケーション単位で分析すると、物流上の非効率を特定できます。たとえば、「社内在庫移動のリードタイム」ダッシュボードで、特定のゾーン間の移動が継続的に遅れているかを確認できます。特定のロケーションで在庫差異が発生しやすいかどうかも把握できます。
重要な理由
倉庫内の位置情報を提供し、移動効率や、ボトルネックや頻繁な調整などロケーション固有の問題を分析できます。
入手先
在庫取引テーブルのLOCATOR_IDなどのフィールドから取得し、ロケーションマスターデータ(INV_ITEM_LOCATIONS)と結合して表示名を取得できます。
例
A1-R4-S3-B2入荷ドック-01品質検査エリア
|
|||
|
品目番号
ItemNumber
|
取り扱う製品または資材を一意に識別する番号です。 | ||
|
説明
品目番号は、SKU(Stock Keeping Unit)とも呼ばれ、在庫取引の対象となる特定の製品を識別します。製品単位で分析を絞り込んだり、分類したりできます。 プロセスマイニングでは、製品を軸にした分析に欠かせない属性です。「棚入れに最も時間がかかる製品はどれか」「調整が最も頻繁に行われる品目はどれか」といった問いに答えられます。製品ラインやカテゴリごとに改善策を検討できます。
重要な理由
特定の製品単位での絞り込みと分析が可能になり、プロセスの遅延や問題に関連する品目を特定できます。
入手先
在庫取引テーブルの主要フィールドで、通常はINVENTORY_ITEM_IDという名称です。詳細情報を持つ品目マスターテーブル(EGP_SYSTEM_ITEMS_B)に関連付けられます。
例
AS54888CPU-INT-i9MEM-DDR5-32GB
|
|||
|
操作実行ユーザー
UserPerformingAction
|
在庫取引を実行した担当者のユーザーIDまたは氏名です。 | ||
|
説明
棚入れを完了した倉庫作業者や、在庫調整を承認した在庫管理者など、特定のアクティビティを実行した担当者を識別する属性です。 ユーザー単位の分析は、業務量の分配、トレーニングの必要性、コンプライアンスの状況を把握するうえで重要です。たとえば、「在庫調整の頻度と理由」ダッシュボードでは、この属性を使って調整を最も多く実行している担当者を確認できます。優れた実績を持つ担当者や、在庫管理手順について追加のトレーニングが必要な担当者を特定するのに役立ちます。
重要な理由
操作を特定の担当者に関連付けることで、ユーザーのパフォーマンス、業務量、トレーニングの必要性、プロセスのコンプライアンスを分析できます。
入手先
通常は、INV_MATERIAL_TXNSのCREATED_BYなど、取引テーブルの「USER_ID」または「CREATED_BY」フィールドに記録されています。
例
JSMITHAMARTINWAREHOUSE.OPERATOR
|
|||
|
移動理由コード
MovementReasonCode
|
在庫の移動または調整が行われた業務上の理由を示すコードです。 | ||
|
説明
在庫取引が行われた理由を示す属性です。廃棄、棚卸調整、返品など、標準外の移動では特に重要です。 根本原因分析に欠かせない属性でもあります。たとえば、「在庫調整の頻度と理由」ダッシュボードでは、このコードで調整を分類し、破損、盗難、入力ミスなどを区別できます。理由を分析することで、影響の大きい問題に改善活動を集中できます。
重要な理由
在庫の調整や移動が行われた理由を説明します。差異や廃棄などの問題を根本原因から分析するうえで重要です。
入手先
取引テーブルの理由コードフィールドに記録されます。たとえば、INV_MATERIAL_TXNSのREASON_IDから理由コードのマスターデータテーブルに関連付けられます。
例
輸送中の破損棚卸調整期限切れ在庫
|
|||
|
SKUカテゴリ
SKUCategory
|
製品(SKU)が属するカテゴリまたは製品群です。 | ||
|
説明
SKUカテゴリは、類似する製品をまとめるための分類です。「電子機器」「原材料」「完成品」や、価値に基づくA・B・C品目などが例として挙げられます。 この属性により、製品グループ単位で上位レベルの分析ができます。数千の個別品目を調べるよりも、傾向を把握しやすい場合があります。「廃棄・陳腐化率分析」ダッシュボードなどで、廃棄されやすい製品カテゴリを特定し、在庫方針や需要予測の改善に役立てられます。
重要な理由
製品グループごとにプロセスパフォーマンスを集計・比較できます。個別品目のレベルでは見えにくい傾向も把握できます。
入手先
通常は品目マスターデータ(EGP_SYSTEM_ITEMS_B)に保存され、取引データと結合して取得します。
例
高回転品高額品予備部品
|
|||
|
保管場所コード
SubinventoryCode
|
在庫組織を構成する区分で、特定の保管エリアまたは保管タイプを表します。 | ||
|
説明
保管場所は、より大きな在庫組織(例:倉庫)内で品目を論理的または物理的にまとめた区分です。「入庫」「完成品」「品質保留」「不良品」などが例として挙げられます。 この属性を使うと、特定の棚番よりも上位のロケーション単位で分析できます。品質検査後に「入庫」保管場所から「完成品」保管場所へ品目が移動するまでの時間など、異なる機能エリア間の資材の流れを追跡する際に役立ちます。
重要な理由
倉庫内の入庫、品質管理、主要保管エリアなど、異なる機能エリア間の在庫移動と滞留時間を分析できます。
入手先
在庫テーブルの標準フィールドで、通常はSUBINVENTORY_CODEという名称です。
例
入荷FGI保管品
|
|||
|
取引タイプ
TransactionType
|
システムで定義された在庫取引のタイプです。 | ||
|
説明
在庫イベントをシステムレベルで分類した生の属性です。「発注入庫」「保管場所間移動」「棚卸調整」などが該当します。多くの場合、ここから利用者向けのアクティビティ名が作成されます。 アクティビティ名が上位レベルのプロセスマップに使われるのに対し、取引タイプは詳細な技術分析や、アクティビティへの対応付けの検証に役立ちます。1つのアクティビティにまとめられた特定のサブプロセスやシステム動作を特定できます。
重要な理由
イベントのシステム上の分類をそのまま提供します。詳細分析や「アクティビティ名」の作成方法の検証に役立ちます。
入手先
在庫取引テーブルの標準フィールドで、通常はMTL_TRANSACTION_TYPESなどの取引タイプマスターテーブルから結合して取得します。
例
発注入荷サブインベントリ移送仕掛品コンポーネント払出
|
|||
|
品目ステータス
ItemStatus
|
有効、無効、廃止など、在庫品目の現在のステータスを示します。 | ||
|
説明
製品自体のライフサイクル段階を示します。通常の取引が可能な「有効」、品質確認中の「保留」、使用されなくなった「廃止」などがあります。 この属性は、特定のアクティビティを分析する際の背景情報になります。たとえば、「廃止」品目の廃棄率が高いことは想定されますが、「有効」品目の廃棄は重大な問題を示している可能性があります。分析対象を関連性の高い有効な在庫に絞り込む際にも役立ちます。
重要な理由
製品ライフサイクルの背景情報を提供し、廃止品目の廃棄など想定される処理と、想定外のプロセス上の問題を区別できます。
入手先
品目マスターテーブル(例:EGP_SYSTEM_ITEMS_B)から取得し、取引データと結合します。
例
有効無効廃止
|
|||
|
在庫保有日数
InventoryHoldingDays
|
在庫バッチが最初に入庫されてから、最終的に出庫または廃棄されるまで在庫として保管される合計時間です。 | ||
|
説明
特定の在庫バッチまたはロットが保管される合計期間を算出するケース単位のKPIです。ケース内の最初の「入庫記録」アクティビティのタイムスタンプから、最後の「出庫記録」または「在庫廃棄」アクティビティのタイムスタンプまでを測定します。 この指標は、運転資本と保管コストの管理に欠かせません。在庫保有日数が長い場合、在庫の動きが遅く、コストの増加、陳腐化リスク、倉庫スペースの非効率な利用につながる可能性があります。このKPIを分析することで、在庫水準の最適化と在庫回転率の改善に役立ちます。
重要な理由
財務面と業務面の効率を測る重要なKPIです。資本が在庫に拘束される期間を測定し、動きの遅い在庫を特定できます。
入手先
最後の関連イベントと最初の関連イベントのタイムスタンプの差分を取り、プロセスマイニングツール内でケース単位の指標として算出します。
例
30日10:05:0095日04:00:0015日12:30:00
|
|||
|
在庫取引ID
InventoryTransactionId
|
1件の在庫イベントを一意に識別する、システム生成の識別子です。 | ||
|
説明
在庫取引IDは、ソースシステムにおける単一の在庫取引レコードの主キーです。イベントログの各行は、このIDのいずれかに対応します。 通常、上位レベルのプロセスマップで直接使うことはありませんが、データ検証、監査、ドリルダウン分析に役立ちます。Oracle Fusion SCMの特定レコードに直接戻れるため、分析担当者はソースシステム上で異常や個別イベントを調査できます。
重要な理由
各イベントに一意のキーを付与します。データ検証、追跡可能性、ソースシステムのレコードへのドリルダウンに欠かせません。
入手先
主要な在庫取引テーブルの主キーで、通常はINV_MATERIAL_TXNSのTRANSACTION_IDです。
例
987654321123456789555444333
|
|||
|
在庫組織
InventoryOrganization
|
在庫が保管されている特定の組織です。倉庫や製造工場などが該当します。 | ||
|
説明
在庫組織は、配送センターや工場など、在庫を保有する独立した施設または事業体を表します。Oracle Fusion SCMにおける主要な組織データ要素です。 この属性を使って、異なる物理拠点のプロセスを絞り込み、比較できます。「棚入れが最も速い倉庫はどこか」「欧州拠点と北米拠点では在庫差異率に違いがあるか」といった問いに答えられます。拠点間のベンチマークやベストプラクティスの共有にも役立ちます。
重要な理由
倉庫や工場など異なる拠点間でプロセスを比較し、ベンチマークできます。拠点固有のパフォーマンスを特定するのに役立ちます。
入手先
取引テーブルの主要フィールドで、ORGANIZATION_IDなどが該当します。組織名を取得するため、組織マスターデータテーブルに関連付けられます。
例
US1配送センターシアトル製造拠点EU中央倉庫
|
|||
|
数量
Quantity
|
取引の対象となった品目の数量です。 | ||
|
説明
移動、調整、棚卸、その他の取引が行われた品目の単位数を表す属性です。各イベントの規模を測定できます。 数量は多くの分析で使われる基本指標です。処理した商品の量、在庫差異の規模、廃棄量の算出に利用できます。コストデータと組み合わせることで、プロセスの非効率による財務的影響を定量化できます。これは「棚卸差異分析」ダッシュボードなどで確認できます。
重要な理由
各取引の量を数値化し、処理量、差異の規模、在庫アクティビティによる財務的影響を分析できます。
入手先
在庫取引テーブルの標準フィールドで、INV_MATERIAL_TXNSのPRIMARY_QUANTITYやTRANSACTION_QUANTITYなどが該当します。
例
100-105000
|
|||
|
数量単位
UnitOfMeasure
|
取引数量の単位です(例:個、kg、箱)。 | ||
|
説明
数量単位(UOM)は「数量」属性の意味を補足し、数値が何を表すかを指定します。たとえば、「10」という数量が10個、10箱、10kgのいずれを意味するのかを示します。 数量に基づく分析を正しく解釈するために欠かせない属性です。数量単位がなければ、異なる品目の取引を比較したり、数量を正確に集計したりできません。分析を一貫した意味のある基準で行えるようにします。
重要な理由
「数量」属性の意味を補足し、値を正しく解釈して有意義に比較できるようにします。
入手先
通常は、INV_MATERIAL_TXNSのTRANSACTION_UOMなど、取引テーブルの数量フィールドと併せて記録されています。
例
EAKGBOX
|
|||
|
棚卸調整かどうか
IsCycleCountAdjustment
|
棚卸アクティビティの直後に在庫調整が行われた場合にtrueとなるブール型フラグです。 | ||
|
説明
同じ品目とロケーションで「棚卸実施」アクティビティの直後に発生した「在庫差異調整」アクティビティを識別する、派生属性です。棚卸の結果として直接行われた調整を切り分けられます。 このフラグは「棚卸後調整率」KPIに使われます。棚卸によって調整が必要になった頻度を示し、棚卸プログラムの有効性を測定できます。この調整率が高い場合、在庫記録の正確性に関する構造的な問題が考えられます。
重要な理由
実地棚卸の結果として直接行われた調整を切り分け、棚卸プロセスの有効性を測定できます。
入手先
特定の品目またはバッチにおけるアクティビティの順序を確認し、データ変換時に作成する派生属性です。
例
truefalse
|
|||
在庫管理アクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
|
ピッキングの完了
|
在庫ロットが保管場所から実際にピッキングされ、仮置きエリアへ移動されたことを示します。ピッカーがシステム上でピッキングタスクの完了を確認する明示的な取引です。 | ||
|
重要な理由
これは受注処理における重要な節目です。「Picking Initiated」からこのイベントまでの時間によって、ピッカーの効率とピッキングプロセスのパフォーマンスを測定できます。
入手先
ピッキング確認取引によって取得します。この取引により、移動注文明細または倉庫タスクのステータスが「Completed」に更新されるか、INV_MATERIAL_TXNSで「Subinventory Transfer」取引が発生します。
取得
ユーザーがシステム上でピッキング取引を確認した時点で記録されます。多くの場合、モバイルRF端末を使って行われます。
イベントタイプ
explicit
|
|||
|
入荷記録
|
通常は発注書または返品承認に基づき、在庫のバッチまたはロットが倉庫に物理的に到着したことを示します。商品を受け取った時点でシステムに記録される明示的な取引であり、在庫ロットに関する最初の記録が作成されます。 | ||
|
重要な理由
このアクティビティは、在庫ライフサイクル分析の主な開始点です。このイベントから棚入れや品質検査などのイベントまでの時間を追跡することは、入荷業務の効率を測定するうえで重要です。
入手先
INV_MATERIAL_TXNSテーブルに資材取引として記録されます。取引タイプには、「PO Receipt」、「RMA Receipt」、「Intransit Shipment Receipt」などがあります。この取引の作成日がイベント時刻になります。
取得
入荷取引の実行時にイベントが記録されます。
イベントタイプ
explicit
|
|||
|
出庫記録
|
出荷による顧客への引き渡し、生産指示への払い出し、別施設への移送などにより、在庫ロットが倉庫から最終的に出たことを示します。在庫を減少させる、明確で明示的な資材取引です。 | ||
|
重要な理由
これは在庫ライフサイクルの主な終了点であり、在庫回転と保有日数の計算に欠かせません。特定のロットに対する需要が満たされたことを確認できます。
入手先
INV_MATERIAL_TXNSに資材取引として記録されます。取引タイプには「Sales Order Issue」、「WIP Component Issue」、「Transfer Order Shipment」などがあります。
取得
出荷確認または部品払い出し取引が処理された時点で記録されます。
イベントタイプ
explicit
|
|||
|
品質検査の実施
|
品質検査プロセスが完了し、在庫ロットを受け入れるか拒否するかの判断が行われたことを示します。通常は、品質検査レコードの最終ステータス更新から推定します。 | ||
|
重要な理由
これは、後続プロセスで在庫を利用できるかどうかを決める重要な節目です。検査結果と所要時間を分析することで、品質管理とサプライヤーのパフォーマンスを改善できます。
入手先
QA_RESULTSの品質検査レコードが「Accepted」や「Rejected」などの最終ステータスに更新された時刻、またはロットの資材ステータスが「QA」から「Active」に変更された時刻から推定します。
取得
在庫ロットに関連する品質検査レコードの完了日から取得します。
イベントタイプ
inferred
|
|||
|
在庫の廃棄・処分
|
期限切れ、破損、陳腐化、その他の理由で使用できなくなった在庫ロットを、在庫から正式に除外したことを示します。在庫価値を償却する明示的な取引です。 | ||
|
重要な理由
販売も使用もされない在庫の終点です。廃棄を追跡することで、在庫の滞留、需要予測、取り扱いプロセスの問題を特定できます。財務にも直接影響します。
入手先
INV_MATERIAL_TXNSに資材取引として記録されます。通常は「Miscellaneous Issue」または特定の「Scrap」取引タイプで、廃棄専用の勘定科目と理由コードに関連付けられます。
取得
廃棄取引が実行され、承認された時点で記録されます。
イベントタイプ
explicit
|
|||
|
在庫差異の調整
|
在庫ロットのシステム上の手持ち数量を実棚数量に合わせたり、破損などの差異を反映したりするための明示的な取引です。この取引によって、在庫の増加または減少が正式に認識されます。 | ||
|
重要な理由
調整の頻度と理由を追跡することは、盗難、破損、プロセスエラーなど、在庫精度が低下する根本原因を特定するうえで重要です。財務記録と在庫の信頼性にも直接影響します。
入手先
INV_MATERIAL_TXNSに資材取引として記録されます。取引タイプには「Cycle Count Adjustment」や「Miscellaneous Issue/Receipt」などがあり、理由コードを伴うことがよくあります。
取得
在庫調整取引が承認され、計上された時点で記録されます。
イベントタイプ
explicit
|
|||
|
棚入れの完了
|
在庫ロットを指定された保管棚またはサブインベントリへ移動し、正式に利用可能な在庫にしたことを示します。通常は、ロットの場所を荷受け場所から保管場所へ更新する明示的な資材取引によって記録されます。 | ||
|
重要な理由
この節目は入荷プロセスの終了を示します。「Goods Receipt Recorded」からこのイベントまでのサイクルタイムは、棚入れ効率を測定する主要なKPIです。
入手先
INV_MATERIAL_TXNSテーブルに、通常は「Subinventory Transfer」または「Put Away」として資材取引に記録されます。この取引により、ロットが荷受け用サブインベントリから保管用サブインベントリへ移動します。
取得
保管場所への移動を確認する取引が完了した時点でイベントが記録されます。
イベントタイプ
explicit
|
|||
|
ピッキングの開始
|
販売注文、作業指示、移送のために、保管場所から在庫ロットをピッキングするタスクが作成され、受注処理が始まったことを示します。通常は、ピックウェーブまたは移動注文明細の作成から推定します。 | ||
|
重要な理由
このイベントからピッキングサイクルタイムの計測が始まります。注文の引当からピッキング開始までの遅延により、受注処理や倉庫タスクの割り当てにおけるボトルネックが明らかになります。
入手先
ピッキングタスクに関するWMSテーブルのレコード作成時刻、または移動注文明細(例:Mtl_Txn_Request_Lines)のステータスが「Released to Warehouse」に更新された時刻から推定します。
取得
在庫ロットに関連するピッキングタスクまたは移動注文の作成によって特定します。
イベントタイプ
inferred
|
|||
|
品目ステータスの変更
|
在庫ロットの使用可否または制限ステータスが変更されたことを示します。たとえば、保留にする、販売を制限する、制限を解除するなどです。通常は、ロットのステータス属性の変更から推定します。 | ||
|
重要な理由
ステータスの変更を監視することで、在庫の利用可能性と管理状況を把握できます。保留が頻繁に発生する場合は品質上の問題が考えられ、解除を追跡することはプロセスフローの把握に役立ちます。
入手先
INV_LOT_NUMBERSなどの在庫テーブルで、「LOT_STATUS_CODE」または同様のフィールドの変更を追跡して推定します。変更時刻を取得するには、監査履歴またはデータベースログが必要になる場合があります。
取得
時間の経過に沿ってロットステータスフィールドの現在値と以前の値を比較して取得します。
イベントタイプ
inferred
|
|||
|
品質検査の開始
|
在庫ロットを使用可能にする前に、品質管理の検査対象として指定した時点を示します。通常は、受け取ったロットに関連する検査計画レコードの作成、またはロットを「QA」保留ステータスに変更したことから推定します。 | ||
|
重要な理由
品質保証プロセスの開始を特定します。このイベントから「Quality Inspection Performed」までの時間によって、品質管理部門のリードタイムと潜在的なボトルネックが明らかになります。
入手先
Quality Managementモジュールで品質検査レコード(例:QA_RESULTS)が作成されたこと、またはロットの資材ステータスが指定の検査ステータスに変更されたことから推定します。
取得
品質検査計画の作成時刻、またはロットステータスが「Awaiting Inspection」に変更された時刻から推定します。
イベントタイプ
inferred
|
|||
|
在庫の社内移動
|
同じ倉庫内で、棚やサブインベントリなど異なる保管場所の間を在庫ロットが移動したことを記録します。通常は、補充や集約などを目的とした明示的な資材取引として記録されます。 | ||
|
重要な理由
社内移動を分析することで、非効率な倉庫レイアウト、過剰な取り扱い、在庫配置を最適化できる箇所を特定できます。頻度が高い場合は、最初の棚入れロジックに問題がある可能性があります。
入手先
INV_MATERIAL_TXNSに資材取引として記録されます。取引タイプには「Subinventory Transfer」や「Locator Transfer」などがあり、外部の当事者は関与しません。
取得
社内移送取引の完了時に記録されます。
イベントタイプ
explicit
|
|||
|
循環棚卸の実施
|
循環棚卸または実地棚卸の一環として、在庫ロットを実際に数えたことを示します。ユーザーが実数をシステムに入力する明示的なアクションです。 | ||
|
重要な理由
このアクティビティは、在庫精度の管理プログラムを分析する中心的な要素です。差異を特定し、棚卸プロセスの効果を測定する基盤になります。
入手先
ユーザーが棚卸数量を入力して保存した時点で、INV_CYCLE_COUNT_ENTRIESテーブルに記録されます。棚卸入力の時刻がイベント時刻になります。
取得
ユーザーが循環棚卸タスクで特定の商品とロットの棚卸結果を送信した時点で記録されます。
イベントタイプ
explicit
|
|||
|
梱包の完了
|
ピッキングしたロットを出荷容器に入れ、容器を封印する梱包プロセスが完了したことを示します。梱包ステーションでの明示的なスキャン、または出荷ステータスの変更から取得できます。 | ||
|
重要な理由
出荷前の倉庫内での物理的な処理が終了したことを示します。ピッキングから梱包までの時間を分析することで、梱包ステーションの非効率な箇所を特定できます。
入手先
配送明細または出荷レコード(例:WSH_DELIVERY_DETAILS)のステータスが「Packed」に変更されたことから推定します。設定によっては、梱包ステーションでの明示的な取引になる場合もあります。
取得
出荷ステータス更新のタイムスタンプ、または特定の梱包取引ログから取得します。
イベントタイプ
inferred
|
|||
|
棚入れの開始
|
入荷した商品を荷受けエリアまたは仮置きエリアから最終保管場所へ移動するプロセスの開始を示します。通常は、棚入れ操作に対してシステムが作成したタスクまたは移動依頼から推定します。 | ||
|
重要な理由
棚入れを速やかに開始することは、荷受け場を空け、在庫を利用可能にするうえで重要です。このイベントにより、入荷から棚入れアクティビティの開始までの遅延を測定できます。
入手先
受け取ったロットに関連するWarehouse Management System(WMS)モジュールの移動依頼または倉庫タスクの作成時刻から推定します。
取得
在庫取引またはロットに関連する棚入れタスクの作成によって特定します。
イベントタイプ
inferred
|
|||
|
返品商品の処理
|
返品承認(RMA)を通じて顧客から返送された在庫ロットの受け取りと処理を記録します。このアクティビティによってロットが在庫システムに戻され、検査や処置のプロセスが開始されることがあります。 | ||
|
重要な理由
返品プロセスを分析することは、製品品質の問題を理解し、リバースロジスティクスの効率を高めるうえで重要です。独立した返品サブプロセスの開始点にもなります。
入手先
INV_MATERIAL_TXNSテーブルに「RMA Receipt」資材取引として記録されます。取引の詳細から、元の販売注文と顧客を参照できます。
取得
システムでRMA入荷取引が実行された時点で記録されます。
イベントタイプ
explicit
|
|||
抽出ガイド
始める準備はできていますか
このテンプレートを使ってデータ準備を効率化し、在庫プロセスに関する重要な発見を始めましょう。今すぐ業務の最適化に取り組めます。
在庫管理を変革:今すぐ最適化を開始
非効率を特定し、在庫サイクルタイムを30%短縮します。
クレジットカードは必要ありません。数分で始められます。