倉庫管理データテンプレート
倉庫管理データテンプレート
- 収集を推奨する属性
- プロセスで追跡する主なアクティビティ
- データ抽出の手順
倉庫管理の属性
| 名前 | 説明 | ||
|---|---|---|---|
|
アクティビティ名
ActivityName
|
「商品ピッキング」や「出荷発送」など、倉庫管理プロセスで発生した特定の業務イベントまたはタスクの名称です。 | ||
|
説明
アクティビティ名は、倉庫オーダーのライフサイクルにおける個々のステップや節目を表します。これらのアクティビティがプロセスマップ上の順序付きノードとなり、プロセスの流れを可視化して分析できます。各アクティビティにはタイムスタンプが付与され、パフォーマンスやボトルネックを分析する基礎となります。 プロセスマイニングでは、この属性を使ってプロセスモデルを構築します。アクティビティの発生頻度や経路、ステップ間の所要時間を分析できます。「品質検査実施」や「ピッキングタスク作成」などのアクティビティがどのような順序で発生するかを把握することは、リソース配分の最適化やサイクルタイムの短縮に役立ちます。
重要な理由
この属性によってプロセスマップの各ステップを定義し、倉庫のワークフローを可視化、分析、最適化できます。
入手先
通常、Oracle WMS Cloudのイベントログ、タスクステータステーブル、またはプロセスの節目を記録するトランザクションレコードから取得します。
例
商品が到着ピッキングタスクを作成商品を梱包出荷を完了
|
|||
|
イベント開始時刻
EventStartTime
|
倉庫内の特定のアクティビティまたはイベントが開始した時刻を示すタイムスタンプです。 | ||
|
説明
イベント開始時刻は、アクティビティの開始日時を正確に示します。プロセスマイニングでは、イベントを時系列に並べ、所要時間やサイクルタイムを計算するための主要な時間属性です。このタイムスタンプは、実際に発生したプロセスの流れを正確に再現するうえで欠かせません。 イベント開始時刻に基づく分析は、パフォーマンスの監視に重要です。アクティビティ間の時間、ケース全体の所要時間、サービスレベル合意の遵守状況などを算出できます。「入庫から棚入れまでのサイクルタイム」のようにサイクルタイムを可視化するダッシュボードでは、遅延箇所の特定にこの属性を使用します。
重要な理由
イベントを正しい順序に並べ、サイクルタイムやボトルネックなど、時間に基づくパフォーマンス指標を算出するために必要です。
入手先
通常、Oracle WMS Cloudのトランザクションテーブルにあるタスクまたはイベントレコードの作成時刻や開始時刻のフィールドです。
例
2023-10-26T09:00:00Z2023-10-26T10:30:15Z2023-10-27T11:05:00Z
|
|||
|
倉庫オーダー
WarehouseOrder
|
倉庫オーダーを一意に識別するIDです。関連するすべての物流アクティビティを開始から完了まで追跡する際の主要なケースIDとして機能します。 | ||
|
説明
倉庫オーダーは、入荷や出荷など、倉庫内の1つの物流タスクに関連するすべてのイベントとアクティビティをまとめる中心的な識別子です。プロセスマイニングではケースIDとして機能し、個々のオーダーについて倉庫プロセスの全体を端から端まで分析できます。 倉庫オーダー単位でプロセスを分析すると、作成から完了またはキャンセルまでの一連の流れを可視化できます。よく見られるプロセス経路、ボトルネック、逸脱、手戻りの発生箇所を特定し、倉庫業務の効率に影響する要因を把握できます。この視点は、さまざまな種類のオーダーについて、全体的なパフォーマンスや標準手順への適合状況を理解するうえで重要です。
重要な理由
倉庫内の関連アクティビティをすべて結び付ける重要なケースIDです。物流オーダーごとに、プロセス全体を端から端まで把握できます。
入手先
通常、Oracle WMS Cloudの倉庫オーダーテーブルのヘッダーレベルにあります。OrdersやTasksなどのモジュールで確認できます。
例
WO-0054321ORD-9876543SHIP-2024-1001
|
|||
|
ソースシステム
SourceSystem
|
倉庫管理データの抽出元となるシステムです。 | ||
|
説明
この属性はデータの取得元を示します。この場合はOracle WMS Cloudです。一見変化しない値ですが、データガバナンスや追跡可能性を確保するうえで重要です。複数のシステムのデータを統合して分析する場合にも役立ちます。 プロセスマイニングでは、関係者がデータを信頼し、その背景を理解するための手掛かりになります。倉庫ごとに異なるシステムを使用している場合、このフィールドを使ってプロセスのパフォーマンスを倉庫間で分類、比較できます。
重要な理由
データの取得元とガバナンスに関するコンテキストを示し、追跡可能性を確保するとともに、複数システムにまたがる分析を可能にします。
入手先
通常、データ変換時にデータセットの取得元を示すために追加される固定値です。
例
Oracle WMS CloudOracle Fusion WMS
|
|||
|
最終データ更新日時
LastDataUpdate
|
このイベントのデータをソースシステムから最後に抽出または更新した時刻を示すタイムスタンプです。 | ||
|
説明
最終データ更新日時は、Oracle WMS Cloudからデータを取得した日時を示します。分析対象のデータがどの程度新しいかを把握し、最新の情報に基づいて判断するために重要なメタデータです。 プロセスマイニングのダッシュボードでは、このタイムスタンプによって表示データの更新時期を確認できます。分析がリアルタイムの業務を反映しているのか、過去の時点のスナップショットなのかを把握できるため、業務の監視に役立ちます。
重要な理由
データの更新状況を示すため、プロセス分析がどの程度最新の情報に基づいているかを把握できます。
入手先
データの抽出、変換、読み込み(ETL)処理の際に生成され、追加されるタイムスタンプです。
例
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
|
|||
|
SLAステータス
SLAState
|
希望完了日を基準に、倉庫オーダーが期限どおりに完了したか、遅延したか、期限に間に合わないリスクがあるかを示す計算済みステータスです。 | ||
|
説明
SLAステータスは、オーダーの期限に対するパフォーマンスを分類して示す派生属性です。完了アクティビティ(例:「出荷発送」)のタイムスタンプと「RequestedCompletionDate」を比較して算出します。「期限どおり」「遅延」のほか、未完了で期限が近いオーダーには「リスクあり」と表示することもできます。 「倉庫オーダーのSLA遵守状況」ダッシュボード向けに設計された属性です。複雑な日付の比較結果を分かりやすいステータスで示すため、パフォーマンスをすばやく視覚的に確認できます。遅延したオーダーに絞り込み、サービスレベル合意を達成できなかった原因を分析する際にも使えます。
重要な理由
SLAの遵守状況をひと目で確認でき、納期どおりの処理状況を簡単に追跡、分析できます。
入手先
最終アクティビティのタイムスタンプをRequestedCompletionDateと比較して算出します。
例
期限どおり遅延リスクあり
|
|||
|
イベント終了時刻
EventEndTime
|
倉庫内の特定のアクティビティまたはイベントが完了した時刻を示すタイムスタンプです。 | ||
|
説明
イベント終了時刻は、アクティビティが終了した日時を正確に示します。この情報があれば、次のアクティビティの開始時刻から推定するよりも正確に所要時間を測定できます。「梱包」や「品質検査」など、処理時間を測定できるタスクで特に役立ちます。 開始時刻と終了時刻の両方があれば、アクティビティの処理時間を正確に算出できます。タスクを実際に処理していた時間と、次のステップが始まるまでの待ち時間を区別できるため、リソースの利用状況や効率を分析するうえで役立ちます。
重要な理由
個々のアクティビティの所要時間を正確に算出し、実際の処理時間と待ち時間を区別できます。
入手先
通常、Oracle WMS Cloudのタスクまたはイベントレコードにある完了時刻または終了時刻のフィールドです。
例
2023-10-26T09:15:00Z2023-10-26T11:00:45Z2023-10-27T11:20:00Z
|
|||
|
ユーザー/作業者ID
UserOperatorId
|
倉庫内のアクティビティを実行したユーザー、作業者、または従業員を識別するIDです。 | ||
|
説明
この属性は、ピッキング、梱包、棚入れなどの特定のタスクを担当した人を識別します。人員のパフォーマンス、作業負荷の配分、標準作業手順の遵守状況を分析する際に重要な切り口です。 ユーザー/作業者IDでプロセスを分析すると、パフォーマンスの高い従業員や追加のトレーニングが必要な従業員、チーム内の作業負荷の偏りを特定できます。「アクティビティ別リソース利用状況」ダッシュボードでは、各ユーザーがプロセス全体の効率にどのように貢献しているか、特定のユーザーの作業がボトルネックに関係しているかを把握できます。
重要な理由
人員のパフォーマンス分析やトレーニングの必要性の特定、公平な作業負荷の配分に役立ちます。
入手先
通常、トランザクションテーブルまたはタスクテーブルにあります。多くの場合、操作時にシステムやハンディ端末にログインしていたユーザーと関連付けられています。
例
JSMITHBJOHNSONUSER123
|
|||
|
倉庫オーダー種別
WarehouseOrderType
|
入荷、出荷、倉庫内移動など、倉庫オーダーの種類を分類します。 | ||
|
説明
倉庫オーダー種別は、オーダーの目的を把握するための重要な情報です。一般的な種別には、顧客向け出荷、発注書に基づく入荷、施設間の在庫移動、返品などがあります。この分類は、プロセス分析を分け、異なるワークフローのパフォーマンスを比較するうえで基本となります。 プロセスマイニングでは、オーダー種別で絞り込むことで、入荷と出荷それぞれのプロセスマップを作成できます。両者ではステップやパフォーマンス目標が大きく異なることがあります。たとえば、出荷の重要業績評価指標(KPI)は処理速度や顧客への納品に重点を置く一方、入荷では在庫の利用可能性や正確性が重視されます。「ピッキングと梱包の処理量」ダッシュボードで、異なる出荷プロセスを比較する際にも重要な属性です。
重要な理由
入荷、出荷、倉庫内業務など、目標やワークフローの異なるプロセスに分けて分析できます。
入手先
Oracle WMS Cloudの文書を確認してください。通常、倉庫オーダーのヘッダーデータにあります。
例
出荷入荷倉庫内移動顧客返品
|
|||
|
優先度
PriorityLevel
|
「高」「通常」「低」など、倉庫オーダーの緊急度を分類します。 | ||
|
説明
優先度は、倉庫オーダーの緊急度を示す業務上の属性です。速達出荷や在庫不足への緊急補充など、優先度の高いオーダーでは、より迅速なプロセス経路で処理し、リソースによる早急な対応が必要になることがあります。 「優先オーダーの履行パフォーマンス」ダッシュボードで重要な属性です。優先度別にプロセスを絞り込んで比較すると、優先度の高いオーダーが実際に優先処理され、より厳しいSLAを満たしているかを評価できます。重要度の高い業務ニーズに応じて、リソースが適切に配分されているかを確認できます。
重要な理由
緊急オーダーが通常のオーダーより速く処理されているかを分析し、重要なSLAの達成状況を確認できます。
入手先
Oracle WMS Cloudの文書を確認してください。通常、オーダーヘッダーデータのフィールドです。
例
高通常低
|
|||
|
実績数量
ActualQuantity
|
入荷やピッキングなどのアクティビティで、実際に数えた、または取り扱った商品の数量です。 | ||
|
説明
実績数量は、倉庫タスクで処理した商品の実数です。入荷、棚入れ、ピッキング、循環棚卸などの際に記録されます。在庫移動の実際の数量を表します。 「在庫数量の差異」ダッシュボードで重要な属性です。実績数量を、発注書や出荷オーダーなどの元文書に記載された予定数量と比較すると、差異をすぐに特定できます。差異を分析することで、仕入先の誤り、入荷時のミス、ピッキングミスなど、在庫の不正確さの原因を特定できます。正確な在庫水準を維持するうえで欠かせません。
重要な理由
予定数量と比較して在庫の差異を特定し、在庫数の正確性を高めるために必要です。
入手先
Oracle WMS Cloudの文書を確認してください。通常、トランザクション詳細またはタスク明細のテーブルにあるフィールドです。
例
10098500
|
|||
|
希望完了日
RequestedCompletionDate
|
倉庫オーダーの完了または出荷予定日です。 | ||
|
説明
希望完了日は、サービスレベル合意(SLA)または顧客が希望するオーダーの期限を示します。実際の完了時刻と比較し、期限どおり、前倒し、または遅延のいずれかを判定する基準となります。 「倉庫オーダーのSLA遵守状況」など、パフォーマンス監視用のダッシュボードや、「納期どおりの出荷率」などの重要業績評価指標(KPI)の算出に欠かせない属性です。実際の出荷時刻を希望完了日と比較することで、サービスレベルの達成状況を測定し、遅延の根本原因を特定できます。また、期限に間に合わないリスクがあるオーダーの優先順位付けにも役立ちます。
重要な理由
納期遵守とSLA遵守状況を測定するための主要な属性であり、顧客満足度にも直接影響します。
入手先
Oracle WMS Cloudの文書を確認してください。通常、オーダーヘッダーデータに含まれ、販売オーダーまたは発注書から取得されることがあります。
例
2023-10-28T17:00:00Z2023-11-05T23:59:59Z2023-11-15T12:00:00Z
|
|||
|
予定数量
PlannedQuantity
|
発注書や販売オーダーなどの元文書に基づく、アクティビティでの予定数量です。 | ||
|
説明
予定数量は、元となる文書で指定されたタスクの処理予定数です。入荷の場合は発注書の数量、出荷の場合は販売オーダーの数量にあたります。 実績数量と比較する際のベースラインとなります。「在庫データ差異率」の重要業績評価指標(KPI)は、予定数量と実績数量の差に基づいて算出されます。こうした差異の分析は、仕入先、社内プロセス、データ入力ミスに関する問題に対処するうえで、サプライチェーンや在庫の管理に欠かせません。
重要な理由
入荷やピッキングの際に在庫数の正確性を測定し、差異を特定するためのベースラインとなります。
入手先
Oracle WMS Cloudの文書を確認してください。通常、倉庫タスクに関連付けられたオーダー明細にあります。
例
100100500
|
|||
|
使用機器
EquipmentUsed
|
倉庫内のアクティビティに使用したフォークリフトやハンディスキャナーなどの機器を識別するIDです。 | ||
|
説明
この属性は、倉庫タスクで使用した機器や物理的な資産を示します。機器の使用状況を追跡すると、作業者のパフォーマンスに加えて、リソース分析の視点を広げられます。機器の稼働率やメンテナンスの必要性を把握し、機材の配分を見直す際にも役立ちます。 「アクティビティ別リソース利用状況」ダッシュボードでは、使用機器別の分析が重要です。特定の機器がボトルネックになっていないか、機器の稼働状況や効率に応じてタスクの割り当てを改善できないかを確認できます。たとえば、特定の型式のフォークリフトで棚入れに時間がかかる傾向が分かれば、原因を調査できます。
重要な理由
機器の利用状況や効率を分析し、機器に起因するボトルネックを特定して、リソース配分を見直すのに役立ちます。
入手先
Oracle WMS Cloudの文書を確認してください。特に作業者が特定の機器にログインする場合、タスク実行レコードに記録されていることがあります。
例
FORKLIFT-05SCANNER-A12CART-27
|
|||
|
倉庫オーダーステータス
WarehouseOrderStatus
|
「完了」や「キャンセル」など、倉庫オーダーの現在または最終のステータスです。 | ||
|
説明
この属性は、倉庫オーダーの結果または最終状態を示します。正常に処理されたオーダーと、キャンセルされたオーダーや処理中のオーダーを区別できます。完了したプロセスだけに絞り込んだり、キャンセルの理由を調べたりする際の重要な切り口です。 最終ステータスに基づくケース分析は、プロセスの違いや結果を理解するうえで重要です。たとえば、「完了」と「キャンセル」のオーダーのプロセスフローを比較すると、キャンセルがどの段階で発生しやすいかが分かり、在庫、顧客からの依頼、システムエラーなどの問題を特定する手掛かりになります。「倉庫の1日あたりの処理量」など、処理量に関する重要業績評価指標(KPI)の算出にも使われます。
重要な理由
ケースの結果を示すため、正常に完了したオーダーに絞った分析や、キャンセルなどの例外の調査が可能になります。
入手先
通常、Oracle WMS Cloudの倉庫オーダーヘッダーレコードにあるステータスフィールドです。
例
完了処理中キャンセル保留中
|
|||
|
出荷ID
ShipmentId
|
まとめて輸送する1つ以上の倉庫オーダーをグループ化する、出荷の一意な識別子です。 | ||
|
説明
出荷IDは、複数の倉庫オーダーを輸送単位としてまとめる上位レベルの識別子です。たとえば、同じ配送先に向かう複数の小口オーダーを、同じトラックの1つの出荷にまとめる場合があります。 この分析では倉庫オーダーをケースIDとして使用しますが、出荷IDを加えることで、出荷物流を別の視点から分析できます。出荷単位でパフォーマンスを評価し、出荷に含まれるすべてのオーダーをまとめるまでの時間などを確認できます。また、個々のオーダーだけでなく、出荷全体に影響する問題の追跡にも使えます。
重要な理由
複数のオーダーを1つの輸送単位にまとめ、集約の効率や出荷単位のパフォーマンスを分析できます。
入手先
Oracle WMS Cloudの文書を確認してください。通常、出荷または積荷の管理モジュールにあります。
例
SHP-98765LOAD-A543BOL-123456
|
|||
|
商品SKU
ProductSKU
|
倉庫オーダーで取り扱う商品を識別する在庫管理単位(SKU)または識別子です。 | ||
|
説明
商品SKUは、特定の商品を一意に識別するコードです。倉庫オーダーには1つ以上の商品が含まれることがあり、この属性を使って処理対象の商品別に分析できます。 商品SKU別にプロセスを分析すると、商品による倉庫業務の効率への影響が分かります。たとえば、大型商品や壊れやすい商品は取り扱いに時間がかかる一方、回転の速い商品はより効率的なプロセス経路をたどる場合があります。この情報は、ピッキングや棚入れの移動時間を短縮できるよう商品の保管場所を決めるロケーション戦略や、商品の特性が全体の処理量に与える影響を把握する際に役立ちます。
重要な理由
商品の特性に基づいて分析でき、取り扱い時間やプロセスの流れへの影響を把握して、保管場所や保管方法の検討に役立てられます。
入手先
Oracle WMS Cloudの文書を確認してください。オーダー明細またはタスク詳細にあります。
例
SKU-100-RED-LGPROD-54321HW-CMP-001A
|
|||
|
場所ID
LocationIdentifier
|
倉庫内でアクティビティが発生した具体的な場所です。保管棚、ドックの扉、出荷待機エリアなどが該当します。 | ||
|
説明
場所IDは、イベントが発生した倉庫内の正確な場所を示します。「商品到着」では入荷ドック、「商品棚入れ」では保管棚、「商品梱包」では梱包ステーション、「出荷待機エリアへの配置」では出荷待機レーンなどが該当します。 この属性を加えることで、プロセス分析に場所の視点を取り入れられます。倉庫内の特定のエリアに関連するボトルネックの特定に役立ちます。たとえば、特定の通路でピッキングに時間がかかる傾向や、特定のドックの扉が入荷の滞留箇所になっていることが分かる場合があります。こうした情報は、倉庫レイアウト、リソース配分、プロセス設計の見直しに役立ちます。
重要な理由
場所の視点を分析に加え、倉庫内の特定のゾーン、通路、保管棚に関連するボトルネックの特定に役立ちます。
入手先
Oracle WMS Cloudの文書を確認してください。通常、タスクレベルの詳細に記録されています。
例
A-01-03-BDOCK-04PACK-STN-02STAGE-LANE-5
|
|||
|
手戻りの有無
IsRework
|
同じケース内で、アクティビティが前のステップの繰り返しかどうかを示す真偽値です。手戻りやプロセスのループを把握できます。 | ||
|
説明
手戻りの有無は、プロセスが直線的な流れから外れ、アクティビティを繰り返した場合に識別する計算フラグです。たとえば、同じ注文で「商品のピッキング」の後に再び「商品のピッキング」が行われた場合、2回目のアクティビティが手戻りとして記録されます。これは、ピッキングミスの修正など、問題が発生した可能性を示します。 この属性は、「プロセス逸脱・手戻り分析」ダッシュボードと「倉庫の手戻り率」KPIに欠かせません。該当するイベントにフラグを付けることで、手戻りの発生頻度と影響を定量化できます。手戻りが起きやすいアクティビティを特定すれば、非効率や運用コストの増加につながるプロセス上の弱点、品質の問題、トレーニング不足を把握できます。
重要な理由
このフラグでプロセスの非効率やループを直接特定し、手戻りのコストと発生頻度を定量化できます。
入手先
プロセスマイニングツールが、同じケースIDでアクティビティの並びが繰り返されていることを検出して算出します。
例
truefalse
|
|||
|
理由コード
ReasonCode
|
在庫調整、返品、逸脱など、特定のイベントが発生した理由を示すコードまたは説明です。 | ||
|
説明
理由コードは、プロセス内で通常とは異なるイベントや例外が発生した背景を示します。たとえば、「在庫調整」アクティビティが発生した場合、理由コードには「商品破損」「循環棚卸による調整」「在庫期限切れ」などが記録されます。プロセス逸脱の根本原因を分析するうえで重要です。 プロセスマイニングでは、例外が発生した理由を理解するために理由コードを使います。理由コードごとの発生頻度や影響を分析すると、組織的な問題の特定に役立ちます。たとえば、「商品破損」による調整が頻発している場合は取り扱い手順の見直しが必要かもしれません。「ピッキングミス」が多い場合は、作業者へのトレーニングやシステムチェックの強化が考えられます。
重要な理由
例外や逸脱の背景を示し、在庫調整や遅延などの問題の根本原因分析に役立ちます。
入手先
Oracle WMS Cloudの文書を確認してください。通常、例外処理のトランザクション時に入力されるコードです。
例
DMG - 輸送中の破損QTY_MISMATCH - 仕入先の数量不足WRONG_ITEM_PICKED
|
|||
|
運送業者
Carrier
|
出荷を担当する運送業者または輸送事業者です。 | ||
|
説明
運送業者属性は、倉庫から最終目的地まで商品を輸送する物流パートナーを識別します。FedExやUPSなどの商業運送業者、貨物輸送会社、または自社の輸送部門が該当します。 「出荷発送のサイクルタイム」ダッシュボードで、運送業者ごとのパフォーマンスを分析、比較するために使います。「出荷待機エリアへの配置」から「出荷発送」までの時間を運送業者別に分けると、効率の高い業者や遅延の原因となる業者を特定できます。このデータは、契約交渉や運送業者の選定にも役立ちます。
重要な理由
運送業者ごとのパフォーマンスを比較し、出荷物流の改善や発送遅延の削減に役立ちます。
入手先
Oracle WMS Cloudの文書を確認してください。通常、倉庫オーダーに関連する出荷情報または積荷情報に保存されています。
例
FedExUPSDHLXPO Logistics
|
|||
倉庫管理のアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
|
倉庫受注を完了
|
倉庫受注そのものが最終的に完了したことを示します。出荷時、またはシステム更新がすべて確定した後に完了する場合があります。プロセスが正常に終了したことを示すイベントです。 | ||
|
重要な理由
倉庫プロセス全体のライフサイクルの終了を示します。倉庫業務全体のサイクルタイムと処理量を算出するために必要です。
入手先
通常、倉庫受注オブジェクトの最終ステータスが「完了」または「クローズ」に変わったことから推定します。最終ステータス更新のタイムスタンプを使用します。
記録
倉庫受注のステータスが最終的な正常終了状態に変わったことから推定します。
イベントタイプ
inferred
|
|||
|
入荷予定を登録
|
このアクティビティは、Oracle WMS Cloudで事前出荷通知(ASN)または入荷予定レコードが作成されたことを示します。入荷プロセスの開始を表し、商品が倉庫に到着する予定であることを正式に通知します。 | ||
|
重要な理由
これは、入荷倉庫プロセスの主な開始イベントです。この時点から実際の荷受けまでの時間を分析すると、仕入先の信頼性と計画の精度を測定できます。
入手先
通常、入荷出荷またはASNオブジェクトの取引履歴から取得します。文書の作成タイムスタンプに該当します。
記録
入荷出荷またはASNレコードの作成イベントから取得します。
イベントタイプ
explicit
|
|||
|
出荷を完了
|
積み込みを終えたトラックが出発し、倉庫から出荷されたことを示す最終工程です。この取引により、WMS上で出荷受注が会計上および物理的に完了します。 | ||
|
重要な理由
出荷プロセスの最終マイルストーンであり、納期どおりの出荷の遵守状況を測る重要業績評価指標(KPI)のデータポイントです。商品が運送会社に引き渡され、倉庫の責任が終了したことを示します。
入手先
Oracle WMS Cloudの重要な明示的取引です。通常、「出荷確定」または「積み込み出荷」と呼ばれます。正確なタイムスタンプとともに、出荷積み込みまたは出荷レコードに記録されます。
記録
「出荷確定」または「積み込み出荷」取引のタイムスタンプから取得します。
イベントタイプ
explicit
|
|||
|
商品をピッキング
|
作業者が保管場所から商品を取り出し、システムでピッキングを確定したことを示します。商品は梱包エリアまたは仕分けエリアへ移動できる状態です。 | ||
|
重要な理由
受注処理における重要なマイルストーンです。ピッキング時間を分析すると、倉庫のレイアウト、ピッキング方法、作業者のパフォーマンスに起因するボトルネックを特定できます。
入手先
タスク履歴または取引ログに記録されたピッキングタスクの完了タイムスタンプから取得します。作業者が確認スキャンを行うと、取引が確定します。
記録
ピッキングタスク取引の完了タイムスタンプに基づきます。
イベントタイプ
explicit
|
|||
|
商品を受領
|
商品が荷下ろしされ、スキャンされ、倉庫の管理対象として正式に受け入れられたことを示します。入荷予定の文書と照合して数量を確認する取引イベントです。 | ||
|
重要な理由
在庫を正式に受領したことを示す重要なマイルストーンです。このアクティビティの完了にかかる時間は、在庫を棚入れや受注処理に利用できるまでの時間に直接影響します。
入手先
Oracle WMS Cloudの荷受け取引ログから取得します。商品の受領をスキャンまたは確認するたびに、タイムスタンプ付きの取引レコードが作成されます。
記録
「ASN受領」または同様の荷受け取引の完了タイムスタンプに基づきます。
イベントタイプ
explicit
|
|||
|
商品を梱包
|
出荷容器または受注全体の梱包が完了したことを示します。作業者がすべての商品を梱包したことを確認し、容器を封印して出荷ラベルを貼ります。 | ||
|
重要な理由
受注に関する倉庫内の付加価値作業が終了したことを示すマイルストーンです。ピッキングから梱包完了までの時間は、倉庫内の受注処理速度を測る重要な指標です。
入手先
通常、「容器を閉じる」や「梱包完了」などの明示的な取引として記録されます。完了タイムスタンプは、梱包または出荷受注の取引履歴に記録されます。
記録
受注に対する最後の梱包取引の完了タイムスタンプから取得します。
イベントタイプ
explicit
|
|||
|
商品を棚入れ
|
棚入れが正常に完了したことを示します。作業者が商品を保管棚へ移動し、システムで作業を確定すると、在庫を利用できる状態になります。 | ||
|
重要な理由
入荷プロセスの終了を示す重要なマイルストーンです。「入荷から保管までの時間」という重要業績評価指標(KPI)の算出や、棚入れの効率分析に欠かせません。
入手先
作業者が棚入れタスクを確定すると、完了タイムスタンプ付きの取引レコードが作成されます。通常、タスク履歴または在庫取引ログから取得します。
記録
棚入れタスク取引の完了タイムスタンプに基づきます。
イベントタイプ
explicit
|
|||
|
ピッキングタスクを作成
|
出荷受注に必要な商品を保管場所から取り出すため、システムが作業者向けのピッキングタスクを作成したときに発生します。倉庫内での受注処理サイクルの開始を示します。 | ||
|
重要な理由
出荷ピッキングプロセスの開始点です。このイベントからピッキング完了までの時間は、受注処理の効率とリソースの対応力を測る重要な指標です。
入手先
倉庫タスク管理テーブルに記録されます。ピッキングタスクレコードの作成タイムスタンプをアクティビティの時刻として使用します。
記録
システムが作成したピッキングタスクの作成タイムスタンプから取得します。
イベントタイプ
explicit
|
|||
|
倉庫受注をキャンセル
|
倉庫受注が完了前にキャンセルされたことを示します。プロセスが正常に完了しなかった場合の終了状態です。 | ||
|
重要な理由
キャンセルを追跡すると、需要の変化、データ入力ミス、受注中止につながるその他の問題を把握できます。プロセス上の無駄の発生源を特定するのに役立ちます。
入手先
倉庫オーダーのステータスが「Cancelled」または同様の終了状態に変わったことから、このイベントを推定します。ステータス更新のタイムスタンプを使用します。
記録
倉庫オーダーのステータスが「Cancelled」に変わったことから推定します。
イベントタイプ
inferred
|
|||
|
出荷エリアへ移動
|
梱包済みの容器が梱包ステーションから指定の出荷仕分けエリアへ移動したことを示します。受注処理は完了し、運送会社の車両への積み込みを待つ状態です。 | ||
|
重要な理由
処理工程から最終出荷工程への移行を示します。商品が仕分けエリアに置かれている時間から、運送会社の到着や荷受け場のスケジュールによる遅延を把握できます。
入手先
通常、梱包済み容器のロケーションを仕分けレーンに更新するロケーション移動取引から取得します。この移動取引のタイムスタンプがイベント時刻になります。
記録
梱包済みLPNを仕分け場所へ移動する在庫移動取引から取得します。
イベントタイプ
explicit
|
|||
|
品質検査を実施
|
受領した商品の品質検査が完了したことを示します。特定の資材や仕入先に対する標準工程の場合もあれば、必要に応じて実施される場合もあります。 | ||
|
重要な理由
品質検査にかかる時間と実施頻度を追跡することは、入荷プロセスの遅延を特定するうえで重要です。商品が品質保証のステータスで保留され、利用可能になるまでの時間を測定できます。
入手先
在庫レコードのステータスが「品質検査保留」から「利用可能」または「棚入れ」に変わったことから推定できます。品質管理モジュールに明示的な取引ログが記録されている場合もあります。
記録
在庫ステータスの変更、または受領した商品に関連付けられた品質保証取引の完了から推定します。
イベントタイプ
inferred
|
|||
|
商品が到着
|
トラックまたは運送会社の車両が倉庫の荷受け場に到着し、正式な受付手続きを行ったことを示します。通常、荷下ろしや個々の商品の詳細な受け入れを始める前に記録されます。 | ||
|
重要な理由
このマイルストーンにより、運送中の時間と倉庫内の処理時間を区別できます。荷受け場の利用状況や、荷受けエリアで発生する可能性のあるボトルネックを分析するうえで重要です。
入手先
通常、入荷出荷またはASNレコードのステータス更新として記録されます。荷受け担当者が納品書類をスキャンするか、システムを手動で更新すると記録されます。
記録
入荷出荷のステータス変更イベントとして記録されます。例:「受付場所に到着」。
イベントタイプ
explicit
|
|||
|
在庫を調整
|
特定のロケーションにある商品の数量を、手動またはシステム処理によって調整したことを示します。循環棚卸、破損、または荷受け時の差異修正などを理由に発生します。 | ||
|
重要な理由
在庫の不正確さにつながるプロセス上の問題を特定するうえで、このアクティビティは重要です。調整の頻度と規模を分析すると、荷受け、ピッキング、保管に関する問題を特定できます。
入手先
Oracle WMS Cloudの在庫調整取引ログから取得します。ログには、商品、ロケーション、数量の変更、理由コード、タイムスタンプが記録されます。
記録
在庫調整取引レコードから直接取得します。
イベントタイプ
explicit
|
|||
|
梱包を開始
|
ピッキングした商品が梱包ステーションに到着し、作業者が梱包を開始したことを示します。通常、商品と梱包容器を関連付けるためにスキャンが行われます。 | ||
|
重要な理由
このアクティビティを追跡すると、梱包サブプロセスをピッキングや仕分けと分けて分析できます。梱包ステーションの効率と処理量を詳しく確認できます。
入手先
明示的な取引として記録される場合と、梱包容器(LPN)の作成および最初の商品のスキャンから推定される場合があります。梱包または出荷の取引ログから取得します。
記録
「梱包開始」取引、または容器に最初の商品を梱包した時刻から取得します。
イベントタイプ
explicit
|
|||
|
棚入れタスクを作成
|
このイベントは、荷受け場から指定の保管場所へ商品を移動するよう、システムが倉庫作業者向けのタスクを作成したことを示します。棚入れサブプロセスの開始点です。 | ||
|
重要な理由
このアクティビティを起点に、棚入れサイクルが始まります。タスクの作成から棚入れの完了までの時間を分析すると、システムの効率と作業者の対応時間を評価できます。
入手先
通常、倉庫タスクまたは取引テーブルに明示的なイベントとして記録されます。棚入れタスクレコードの作成タイムスタンプをイベント時刻として使用します。
記録
システムが作成した棚入れタスクの作成タイムスタンプから取得します。
イベントタイプ
explicit
|
|||
|
積み込みを開始
|
梱包済みの商品を仕分けエリアから運送会社のトラックへ移す、実際の積み込み作業の開始を示します。通常、「積み込み開始」取引によって開始されます。 | ||
|
重要な理由
積み込み作業自体の効率を把握できます。仕分けエリアでの待ち時間と、トラックへの積み込みにかかる作業時間を分けて分析できます。
入手先
通常、Oracle WMS Cloudの出荷積み込みレコードに関連付けられた明示的な取引として記録されます。ユーザーが「積み込み開始」を実行すると、タイムスタンプが記録されます。
記録
特定の出荷積み込みに関連付けられた「積み込み開始」取引から取得します。
イベントタイプ
explicit
|
|||
データ抽出ガイド
利用を始めませんか
このデータテンプレートを使って、倉庫管理のプロセスマイニングを始めましょう。今日から業務の改善に取り組めます。
倉庫管理を最適化し、Oracle WMS Cloudの効率を高める
ボトルネックを特定し、Oracle WMS Cloudの在庫精度99.5%を目指しましょう。
クレジットカードは不要です。今日から業務の改善に取り組めます。