サプライチェーンマネジメント データテンプレート
サプライチェーンマネジメント データテンプレート
こちらはサプライチェーンマネジメント向けの汎用プロセスマイニングデータテンプレートです。より具体的なガイダンスが必要な場合は、システム固有のテンプレートをご利用ください。
特定のシステムを選択- 一貫した分析のための標準化されたデータフィールド
- 完全なプロセスフローを把握するために不可欠な活動
- さまざまなサプライチェーン管理システムに適用可能
サプライチェーン管理属性
| 名前 | 説明 | ||
|---|---|---|---|
| アクティビティ Activity | 物流プロセス内で発生した特定のビジネスイベントまたはステップの名前(例:「購買注文発行済み」または「商品出荷済み」)。 | ||
| 説明 アクティビティは、サプライチェーンプロセス内で実行される個別のステップまたはタスクを表します。各アクティビティは、物流注文のライフサイクルにおける特定の時点を示し、プロセスマップの構成要素を提供します。 アクティビティを分析することで、組織は実際にどのようなステップが、どのような順序で、どのくらいの頻度で実行されているかを理解できます。この視点は、ボトルネック、冗長なステップ、および標準作業手順書からの逸脱を特定するのに役立ちます。サプライチェーンにおける一般的なアクティビティには、注文作成、商品受領、ピッキング、梱包、出荷、請求書発行が含まれます。 その重要性 この属性はプロセスマップの根幹を形成し、サプライチェーンにおけるステップの順序の可視化と分析を可能にします。 取得元 ソースシステム内のイベントログ、ステータス変更記録、ドキュメントタイプ、またはトランザクションコードから導出されることがよくあります。 例 購買注文発行済み製品生産完了ピッキング完了商品発送済み | |||
| 物流注文 CaseId | 単一の、エンドツーエンドのロジスティクス注文に対する一意の識別子で、プロセス分析の主要な案件IDとして機能します。 | ||
| 説明 ケースIDは、分析対象となるプロセスのユニークなインスタンスを表します。サプライチェーン管理においては、これは通常、物流注文番号であり、初期作成から最終配送までのすべての関連活動をリンクさせます。 この属性は、購買注文の作成、商品の出荷、顧客への請求書発行などのすべての関連イベントを単一のエンドツーエンドプロセスフローにグループ化するために不可欠です。この識別子を追跡することで、アナリストは注文の完全なジャーニーを可視化し、総サイクルタイムを測定し、異なる注文経路間のバリエーションを特定できます。一貫したケースIDがなければ、プロセスフローを正確に再構築することは不可能です。 その重要性 すべての関連活動を単一のケースに接続し、エンドツーエンドのプロセスフロー分析を可能にするため、プロセスマイニングの基本的な属性です。 取得元 通常、販売注文書、納品書、または包括的なロジスティクス注文テーブルなどの主要なビジネス文書のヘッダーデータに含まれています。 例 LO-2024-00123ORD-987654321SHIP-55443322 | |||
| 開始時刻 StartTime | 特定のアクティビティが開始または発生した日時を示すタイムスタンプ。 | ||
| 説明 開始時間は、アクティビティの開始を示す日付と時刻を含む正確なタイムスタンプです。これは、イベントを時系列で並べ替えたり、パフォーマンス分析を行ったりするための重要な要素です。 この属性は、サイクルタイムの計算、ステップ間の遅延の特定、およびプロセス全体の期間の理解に不可欠です。タイムスタンプを分析することで、企業はスループットを測定し、案件が長期間待機するボトルネックを特定し、サービスレベル契約に対するパフォーマンスを評価できます。正確なタイムスタンプは、時間ベースのプロセスマイニング分析の基盤となります。 その重要性 活動の時間的順序付けを可能にし、サイクルタイムやボトルネック分析など、すべての時間ベースの計算に不可欠です。 取得元 通常、ソースシステムのトランザクションテーブル内のイベントログ、トランザクション記録、または文書作成タイムスタンプに見られます。 例 2023-04-15T09:00:00Z2023-04-16T14:30:15Z2023-04-18T11:20:00Z | |||
| ソースシステム SourceSystem | イベントデータが抽出された情報システムの名称。 | ||
| 説明 ソースシステム属性は、イベントデータがどこから発生したかを示すアプリケーションまたはデータベースを識別します。複雑なサプライチェーン環境では、データはERP、倉庫管理システム(WMS)、輸送管理システム(TMS)など、複数のシステムから得られることがよくあります。 ソースシステムを追跡することは、データガバナンス、検証、およびアクティビティのコンテキストを理解する上で重要です。データ品質問題のトラブルシューティングに役立ち、異なるシステムにまたがるプロセスを比較したり、特定のアプリケーションのみで処理されるアクティビティを特定したりするための分析に利用できます。この情報は、ビジネスプロセスの技術的なコンテキストを提供します。 その重要性 データソースに関する重要なコンテキストを提供し、これはデータ検証や複数のエンタープライズシステムにわたるプロセス分析にとって不可欠です。 取得元 この情報は、データ抽出層の一部であるか、データソース接続に基づいて割り当てられる静的な値である場合が多いです。 例 `SAP S/4HANA`Oracle SCM CloudBlue Yonder WMSKinaxis RapidResponse | |||
| 最終データ更新 LastDataUpdate | ソースシステムからの最終更新または抽出日時を示す timestamp。 | ||
| 説明 この属性は、特定のイベントレコードに対する最新のデータ抽出または更新の日付と時刻を記録します。これは、データの鮮度と信頼性を確保するために使用される技術的な属性です。 通常、直接的なプロセス分析には使用されませんが、最終データ更新はダッシュボードの監視とデータガバナンスにとって重要です。表示されている情報がどれだけ最新であるかをユーザーが理解するのに役立ち、データパイプラインの障害に対するアラートを設定するためにも使用できます。これにより、ビジネス上の意思決定がタイムリーで関連性の高いデータに基づいて行われることが保証されます。 その重要性 データガバナンスとモニタリングに不可欠であり、ユーザーが分析の鮮度を確認し、提供される洞察を信頼できるようにします。 取得元 このタイムスタンプは通常、データ取り込みプロセス中にETL(抽出、変換、ロード)ツールまたはデータ統合プラットフォームによって生成および記録されます。 例 2023-05-20T01:00:00Z2023-05-20T02:00:00Z2023-05-20T03:00:00Z | |||
| `実績納期` ActualDeliveryDate | 注文が顧客に正常に配送され、配達証明によって確認された実際の日付。 | ||
| 説明 実際配送日は、注文フルフィルメントライフサイクルにおける最終タイムスタンプであり、顧客が商品を受け取った瞬間を捉えます。これは多くの場合、配達証明書または運送業者からのステータス更新を通じて確認されます。 この属性は、実際のエンドツーエンドサイクルタイムの計算とパフォーマンス測定に不可欠です。要求配送日と比較することで、注文が早期、定時、または遅延であったかを直接判断できます。このデータを分析することで、遅延のシステム的な原因(調達、生産、物流のいずれに起因するか)を特定し、配送信頼性を向上させるための事実に基づいた根拠を提供します。 その重要性 実際のサイクルタイムを測定するための事実上の終点を提供し、要求された日付と組み合わせて定時配送パフォーマンスを決定するために使用されます。 取得元 輸送管理システム(TMS)、運送業者からの更新、または配達証明記録から取得されます。 例 2023-05-022023-06-142023-07-22 | |||
| ユーザー名 UserName | アクティビティを実行したユーザー、チーム、または自動化システムの名称またはID。 | ||
| 説明 ユーザー名属性は、プロセス内で特定のタスクを実行する責任を負う個人、部門、またはシステムエージェントを識別します。これには、ピッキングを完了する倉庫作業員や、購買発注を自動的に作成するシステムボットなどが含まれます。 ユーザーまたはチーム別にプロセスパフォーマンスを分析することは、効率のばらつきを発見し、トレーニングの必要性を特定し、ベストプラクティスを強調するのに役立ちます。例えば、どのチームが最も処理時間が短いか、どのユーザーが最も頻繁に標準プロセスから逸脱しているかを明らかにできます。また、重要なアクションを実行した担当者を追跡するためのコンプライアンスおよび監査目的にも価値があります。 その重要性 この属性は、分析に人的またはシステムのリソースディメンションを追加し、パフォーマンス比較、ワークロードバランシング、およびコンプライアンス追跡を可能にします。 取得元 トランザクションログまたは文書変更履歴で利用可能で、多くの場合、ユーザーマスターデータにリンクされています。 例 j.smith倉庫チームAAUTO_INVOICE_BOTlisa.jones | |||
| 仕入先ID SupplierIdentifier | 原材料または部品を提供するサプライヤーの一意の識別子。 | ||
| 説明 サプライヤー識別子は、サプライチェーンの調達段階に関与するベンダーまたはサプライヤーを一意に識別するコードまたは番号です。このIDは、購買発注と物品受領活動を特定のサプライヤーに紐付けます。 サプライヤー別にプロセスパフォーマンスを分析することは、効果的なベンダー管理にとって極めて重要です。これにより、企業はサプライヤーの納期遵守率、リードタイム、品質検査合格率を測定できます。これらの洞察は、サプライヤー評価、契約交渉、およびリスクを軽減するためのサプライチェーンの多様化に関する決定に役立ちます。サプライヤーごとにプロセスをセグメント化することで、企業は優れたパフォーマンスを発揮するパートナーと、遅延の原因となっているパートナーを特定できます。 その重要性 サプライヤーのパフォーマンス分析を可能にし、調達最適化に不可欠なリードタイム、定時配送率、品質の測定に役立ちます。 取得元 ERPまたは調達システム内の購買注文ドキュメントまたはサプライヤーマスターデータで見つかります。 例 SUP-1001V-98765ACME-CORP | |||
| 希望納期 RequestedDeliveryDate | 顧客によって要求された、または社内で計画された注文の配送日。 | ||
| 説明 要求納期は、商品が顧客の場所に到着する予定の目標日です。この日付は通常、注文時に顧客によって設定されるか、内部の計画プロセスによって決定されます。 この属性は、サプライチェーンマネジメントにおける重要なKPIである納期遵守率を測定するための主要な基準となります。要求納期と実際の納期を比較することで、企業はOTIF(On-Time In-Full)率を算出し、遅延の原因を特定し、異なる地域、顧客、または製品タイプ間のパフォーマンス傾向を分析できます。顧客満足度とサプライチェーンの信頼性を評価するための基本となります。 その重要性 サプライチェーンのパフォーマンスと顧客満足度を測定するための最も重要なKPIの1つである定時配送率を計算するための基準です。 取得元 ERPまたは注文管理システム内の販売注文ヘッダーデータまたは計画ドキュメントで見つかります。 例 2023-05-012023-06-152023-07-20 | |||
| 終了日時 EndTime | 特定のアクティビティが完了した時点を示すタイムスタンプ。 | ||
| 説明 終了時刻は、活動の完了を示す正確なタイムスタンプです。イベントに対して開始時刻と終了時刻の両方が利用可能な場合、その処理時間を直接測定することが可能になります。 この属性により、パフォーマンスのより詳細な分析が可能になります。活動間の待機時間のみを測定するのではなく、アナリストはアクティブな処理時間とアイドル時間を区別できます。これは、長い梱包時間や延長された品質検査時間など、かなりのリソースを消費する非効率な活動を特定するのに特に役立ちます。この詳細レベルは、的を絞った運用改善をサポートします。 その重要性 活動処理時間の計算を可能にし、付加価値時間と待機時間を区別することで、より正確なボトルネック分析に役立ちます。 取得元 タスクの開始タイムスタンプと完了タイムスタンプの両方が記録されているイベントログまたはトランザクションテーブルで見つかります。 例 2023-04-15T09:15:20Z2023-04-16T15:00:00Z2023-04-18T11:55:30Z | |||
| 製品ID ProductIdentifier | ロジスティクス注文に関連付けられた製品の一意の識別子(SKUや品目コードなど)。 | ||
| 説明 製品識別子(SKUや品目コードなど)は、調達、生産、配送される品目を一意に識別します。一つのロジスティクス注文に、一つまたは複数の製品識別子が含まれる場合があります。 製品別にサプライチェーンプロセスを分析することで、異なる品目がシステム内でどのように流れるかを明らかにします。生産リードタイムが長い製品、品質検査の不合格率が高い製品、または出荷遅延が発生しやすい製品などを特定できます。この製品レベルの視点は、在庫管理、需要予測、および異なる製品ファミリーに対する生産・物流戦略の最適化に不可欠です。 その重要性 これにより、プロセスの製品レベル分析が可能になり、どの製品のサイクルタイムが長いか、またはより多くのプロセス例外に関連しているかを特定するのに役立ちます。 取得元 販売注文、購買注文、または生産注文の明細データで見つかります。 例 SKU-12345-BLK-LMAT-RAW-0098PN-750-B | |||
| 顧客ID CustomerIdentifier | 注文を行った顧客の一意の識別子。 | ||
| 説明 顧客識別子は、各顧客に割り当てられる一意のコードまたは番号です。この属性は、物流注文を商品と支払いを受け取る特定のエンティティにリンクさせます。 この属性は、オーダーからキャッシュまでのプロセスをセグメント化して分析するための重要な側面です。これにより、企業は異なる顧客グループや主要アカウントに対して、定時配送や注文サイクルタイムなどのパフォーマンス指標を評価できます。この分析は、どの顧客が最も遅延を経験しているか、またはどの顧客が独自のプロセスバリエーションを持っているかを明らかにすることができます。これらの洞察は、顧客サービスを改善し、特定のニーズに合わせて物流業務を調整するために価値があります。 その重要性 顧客中心の分析を可能にし、サイクルタイムや定時配送といったパフォーマンス指標を顧客別にセグメント化できます。 取得元 ERPまたはCRMシステム内の販売注文ヘッダーデータまたは顧客マスターデータで見つかります。 例 CUST-00542GLOBEX-US77889900 | |||
| 出荷元 OriginLocation | 出荷元となる倉庫、工場、または施設。 | ||
| 説明 出発地は、配送センター、製造工場、サプライヤー倉庫などの物理的な場所を特定し、そこから商品が移動を開始します。これはサプライチェーンにおける重要な物流経路の出発点を示します。 出発地別にプロセスを分析することで、異なる施設間のパフォーマンスのばらつきを特定できます。どの工場で生産リードタイムが長いか、どの配送センターでピッキングと梱包がより効率的かなどを明らかにすることができます。この地理的または拠点固有の分析は、ネットワーク最適化、リソース配分、組織全体のベストプラクティス標準化にとって不可欠です。 その重要性 異なる工場や倉庫間でのパフォーマンス比較を可能にし、特定のサイトにおける業務上のボトルネックとベストプラクティスを特定するのに役立ちます。 取得元 在庫管理、倉庫管理、または輸送システムで見つかり、多くの場合、出荷または生産注文データに関連付けられています。 例 WH-CENTRAL-01PLANT-FRANKFURTDC-US-WEST | |||
| 受注`ステータス` OrderStatus | 物流注文の現在または最終ステータス(例:「完了」または「キャンセル済み」)。 | ||
| 説明 注文ステータスは、プロセスの終了時またはデータ抽出時に、ロジスティクス注文がライフサイクルのどの段階にあるかを示すものです。通常、案件の最終的な結果を反映します。 この属性は主に成果分析に利用されます。例えば、「キャンセル済み」のステータスを持つ案件で絞り込むことで、アナリストは注文キャンセルの根本原因を調査できます。同様に、「一部履行済み」の注文を分析することで、在庫の正確性やサプライヤーの信頼性に関する課題を明らかにできます。最終ステータスの分布を理解することは、プロセス全体の成功を測る上で重要です。 その重要性 結果分析にとって重要であり、完了、キャンセル、遅延などの最終状態に基づいてケースをフィルタリングし調査できます。 取得元 主要な注文ドキュメント(例:販売注文、物流注文)のヘッダーデータで利用可能です。 例 完了済み進行中キャンセル済み保留中 | |||
| 注文タイプ OrderType | 注文の分類(例:「通常注文」、「緊急注文」、「大量注文」など)。 | ||
| 説明 注文タイプは、ロジスティクス注文の性質、優先度、または履行戦略に基づいて分類します。一般的なタイプには、通常注文、緊急注文、補充注文、または特別プロジェクト注文などがあります。 この属性は、比較分析において強力なフィルターとなります。緊急注文と通常注文のプロセスフローを比較することで、企業は迅速なプロセスが本当に速いのか、あるいは非効率性やコスト増を招いているのかを評価できます。また、異なる注文タイプがそれぞれ異なるプロセスパスをたどるのかを理解し、各パスを個別に最適化するのに役立ちます。 その重要性 異なる種類の注文間のプロセス比較を可能にし、特定のカテゴリが遅延や手戻りの傾向があるかどうかを理解するのに役立ちます。 取得元 通常、販売注文またはロジスティクス注文のヘッダーデータに保存されます。 例 通常注文緊急注文大量注文補充 | |||
| 発注書番号 PurchaseOrderNumber | サプライヤーに送信された購買発注の一意の識別子。 | ||
| 説明 購買発注番号は、外部サプライヤーから物品やサービスを調達するために使用される文書の一意な識別子です。これは、全体のロジスティクス注文と特定の調達活動を結びつける重要なリンクとなります。 この属性により、アナリストは調達サブプロセスを深く掘り下げて分析できます。購買要求から物品受領までの購買のライフサイクルを追跡し、サプライヤーのリードタイムを正確に測定し、購買承認プロセスや履行プロセスにおけるボトルネックを特定するのに役立ちます。また、調達上の問題と、生産や顧客配送における下流の遅延との相関関係を特定するためにも利用できます。 その重要性 エンドツーエンドのプロセスを特定の調達活動にリンクさせ、調達から支払いまでのサブプロセスとサプライヤーのパフォーマンスの詳細な分析を可能にします。 取得元 購買文書ヘッダーに保存され、入庫やサプライヤー請求書などの関連文書で参照されます。 例 PO45000123457300005678PO-2023-987 | |||
| 販売オーダー番号 SalesOrderNumber | 顧客の販売注文の一意の識別子。 | ||
| 説明 販売注文番号は、顧客の要求に基づいて履行プロセスを開始する文書の一意な識別子です。これは受注から入金までのサイクル全体を通じて主要な参照情報となります。 メインの案件IDが統合されたロジスティクス注文であるシナリオでは、販売注文番号は特定の顧客要求への重要なリンクを提供します。これにより、販売の視点からプロセスを分析することが可能になり、注文処理時間、履行率、注文作成から最終配送までの時間を測定するのに役立ちます。サプライチェーンの運用を顧客取引に直接結びつけるために不可欠です。 その重要性 物流活動を初期の顧客需要に接続し、オーダーからキャッシュまでのプロセスと顧客フルフィルメントのパフォーマンスを明確に可視化します。 取得元 販売文書ヘッダーに保存され、配送や請求書などの後続文書で参照されます。 例 SO-102030408000009876ORD-CUST-5544 | |||
| 輸送手段 ModeOfTransport | 出荷に使用される輸送方法(トラック、航空便、海上便など)。 | ||
| 説明 輸送手段は、商品を発地から目的地へ移動させるために使用される物流方法を指定します。これには、道路、鉄道、航空、海上輸送などの選択肢が含まれます。 輸送手段別にプロセスを分析することは、物流コストとパフォーマンスを最適化するのに役立ちます。例えば、航空貨物と海上貨物の実際の輸送時間を明らかにすることができ、データに基づいた費用対効果分析が可能になります。また、特定の輸送手段が遅延や損傷に対してより脆弱であるかどうかを特定するのにも役立ち、より良い運送業者とルート計画をサポートします。 その重要性 輸送コストと配送時間を分析するための重要な側面を提供し、物流戦略の最適化に役立ちます。 取得元 出荷ドキュメント、配送指示書、または輸送管理システム(TMS)記録で見つかります。 例 トラック航空便海上便Rail | |||
サプライチェーン管理活動
| アクティビティ | 説明 | ||
|---|---|---|---|
| 出荷伝票登録済み | 倉庫がピッキング、梱包、出荷活動を開始することを承認する配送文書の作成を示します。この活動は、プロセスを注文管理から物流実行へと正式に移行させます。 | ||
| その重要性 これは営業チームとロジスティクスチーム間の重要な引き渡しポイントです。これは履行サイクルタイムの開始を示し、全体の注文リードタイムの重要な構成要素となります。 取得元 物流実行システムで配送伝票、出荷指示書、または同等の文書が作成された際の明示的なイベントとして記録されます。 取得 出荷伝票または出荷文書の作成タイムスタンプを使用します。 イベントタイプ explicit | |||
| 商品発送済み | 梱包された商品が物理的に倉庫または流通センターを出る時点を示します。このイベントは通常、所有権のリスクを移転し、在庫や売上原価などの財務記録を更新します。 | ||
| その重要性 これは、輸送期間の開始を示す重要なマイルストーンです。顧客の要求日に対する納期遵守率を測定するための重要な日付となります。 取得元 WMSまたはERPシステムでの「出庫」伝票、出荷確認トランザクション、または類似のイベントを介して取得されます。 取得 在庫を減少させる出庫トランザクションの転記日またはタイムスタンプを使用します。 イベントタイプ explicit | |||
| 商品配送済み | このアクティビティは、出荷品が顧客の目的地に到着し、物理的に受領されたことを示します。これは輸送経路の終了を意味します。 | ||
| その重要性 輸送時間と運送業者の定時配送パフォーマンスを測定します。これは、顧客視点からの注文から配送までの全体のサイクルタイムを計算するための重要なイベントです。 取得元 EDIメッセージなどの運送業者データフィードから、または輸送管理システムやERPでの手動更新を通じて取得されることがよくあります。 取得 通常、運送業者の追跡更新、または配送証明日の入力から推測されます。 イベントタイプ inferred | |||
| 注文キャンセル済み | フルフィルメント完了前に物流注文が終了したことを表します。これはプロセスの代替終了状態であり、顧客の要求が満たされなかったことを示します。 | ||
| その重要性 これは重要な失敗イベントです。注文がキャンセルされる理由と時期を分析することは、販売、製品の可用性、または顧客コミュニケーションにおける課題を特定するのに役立ちます。 取得元 販売注文の最終ステータス変更、例えば「キャンセル済み」や「無効」から取得されます。 取得 注文ステータスが確定的に「キャンセル済み」または「無効」に変更されたときのタイムスタンプをキャプチャします。 イベントタイプ explicit | |||
| 注文作成 | 物流注文ライフサイクルの正式な開始を示します。このイベントは、顧客の商品またはサービスのリクエストが主要なビジネスシステムに新しい注文ドキュメントとして入力され、保存されたときに発生します。 | ||
| その重要性 これはプロセスの主要な開始イベントです。このアクティビティから他のアクティビティまでの時間を分析することで、受注から入金までの総サイクルタイムが明らかになり、初期段階のボトルネックを特定できます。 取得元 通常、受注管理システムまたはERPシステムにおける販売注文または顧客注文ヘッダーテーブルの作成タイムスタンプから捕捉されます。 取得 主要な販売注文文書の作成タイムスタンプを使用します。 イベントタイプ explicit | |||
| 購買注文発行済み | このアクティビティは、外部サプライヤーへの購買発注の正式な作成と発送を示します。これは、合意された価格で物品または材料を購入するという法的拘束力のあるコミットメントを表します。 | ||
| その重要性 これはサプライヤーリードタイムが開始される重要なマイルストーンです。このイベントと物品受領の間の時間を分析することは、サプライヤーのパフォーマンス管理にとって不可欠です。 取得元 通常、購買発注が確認、承認、またはベンダーに送信された際のステータス更新またはタイムスタンプから捕捉されます。 取得 購買注文ステータスが確認、承認、またはベンダーに送信されたときのタイムスタンプをキャプチャします。 イベントタイプ explicit | |||
| 配送証明受領済み | 顧客が配送を受け入れたことの正式な確認(しばしば署名付き)を表します。この活動により、物流フルフィルメントプロセスが正式に完了します。 | ||
| その重要性 これは、正常に履行された注文の明確な終了イベントです。収益認識および配送に関する紛争の解決にとって極めて重要です。 取得元 通常、ステータス更新、または注文や配送への配送証明書添付によって捕捉されます。 取得 配達証明(POD)のステータスが更新されたとき、またはPODドキュメントが注文または配送に添付されたときのタイムスタンプをキャプチャします。 イベントタイプ explicit | |||
| 顧客請求書作成済み | 出荷された商品に基づき、顧客向けの請求書ドキュメントの作成を表します。この活動は、注文から現金化までのサイクルにおける財務決済部分を開始します。 | ||
| その重要性 売掛金プロセスへの引き渡しを強調します。出荷と請求の間のギャップを分析することで、請求遅延とそれがキャッシュフローに与える影響を明らかにできます。 取得元 ERPシステムの請求または財務モジュールで請求書ドキュメントが作成または記帳された際に明示的に記録されます。 取得 顧客請求書文書の作成または転記タイムスタンプを使用します。 イベントタイプ explicit | |||
| サプライヤーから商品受領済み | 外部サプライヤーからの商品または原材料が倉庫または生産施設で物理的に受領されたことを示します。このイベントは、在庫レベルを更新し、資材を使用可能にします。 | ||
| その重要性 このアクティビティはサプライヤーリードタイムを終了します。受領日と要求納期を比較することで、サプライヤーの納期遵守率を測定するのに役立ちます。 取得元 在庫管理、倉庫管理、またはERPシステムにおける入庫トランザクションから取得されます。 取得 購買発注に対する物品受領トランザクションの転記日または入力タイムスタンプを使用します。 イベントタイプ explicit | |||
| ピッキング完了 | このアクティビティは、倉庫内の保管場所から品目を集める物理的なプロセスの完了を示します。これは出荷のために注文を準備する上で重要なステップです。 | ||
| その重要性 倉庫ピッキング作業の効率を測定します。配送作成からピッキング完了までの時間を分析することで、倉庫内のボトルネックを特定するのに役立ちます。 取得元 通常、配送文書のステータス更新、または倉庫管理システムからのトランザクションログ(多くの場合、スキャンを介して)から捕捉されます。 取得 配送文書のピッキングステータスが「完了」に更新された際のタイムスタンプを使用します。 イベントタイプ explicit | |||
| 品質検査完了 | 生産または受領された商品に対する品質管理チェックの完了を表します。このステップは、出荷可能になる前に品目が要求される基準を満たしていることを保証します。 | ||
| その重要性 プロセスにおける重要な品質ゲートを強調します。この段階での遅延や失敗は、定時配送と顧客満足度に大きな影響を与える可能性があります。 取得元 通常、品質管理モジュールにおけるステータス更新またはトランザクション(しばしば「使用決定」と呼ばれる)から捕捉されます。 取得 品質検査ロットの最終ステータス変更または使用決定のタイムスタンプから導出されます。 イベントタイプ inferred | |||
| 梱包完了 | ピックされた品目が統合され、出荷用カートンに梱包され、ラベル付けされるプロセスの完了を表します。これは、倉庫内での最後の付加価値ステップです。 | ||
| その重要性 梱包プロセスの効率を測定します。ピッキングから梱包完了までの時間は、梱包ステーションでの制約を特定するのに役立ちます。 取得元 梱包ステーションの作業員がカートンが封印されたことを確認したとき、またはWMSで出荷ラベルが生成されたときに記録されることがよくあります。 取得 梱包確認トランザクションまたは出荷ラベル作成イベントからのタイムスタンプを使用します。 イベントタイプ explicit | |||
| 注文保留適用済み | このイベントは、信用照会の失敗や品質に関する懸念など、特定の理由で注文が一時的に停止された場合に発生します。注文を続行する前に、この保留を解除する必要があります。 | ||
| その重要性 プロセスの中断と手戻りループを強調します。保留の頻度と期間を分析することで、遅延を引き起こすシステム的な問題を明らかにできます。 取得元 通常、注文のステータス変更、またはそれ以上の処理をブロックする理由コードの適用から推測されます。 取得 販売注文ヘッダーまたは明細項目に「ブロック」または「保留」ステータスが適用されたときのタイムスタンプを特定します。 イベントタイプ inferred | |||
| 生産オーダー作成済み | このアクティビティは、顧客が必要とする商品を製造または組み立てるための内部注文の正式な作成を表します。これにより、生産計画および実行サブプロセスが開始されます。 | ||
| その重要性 注文が製造を必要とすることを示します。これにより、生産リードタイムとそれが全体の注文サイクルタイムに与える影響を分析できます。 取得元 製造システムまたはERPシステムで生産注文または作業指示書が作成された際の明確なイベントとしてログに記録されます。 取得 顧客需要にリンクされた製造指図文書の作成タイムスタンプを使用します。 イベントタイプ explicit | |||
| 製品生産完了 | 完成品の製造または組立プロセスの完了を示します。この時点で、商品は完成として報告され、在庫に移動されます。 | ||
| その重要性 このアクティビティは生産サイクルを終了します。生産開始から完了までの時間は、製造効率とスループットの主要な指標です。 取得元 通常、生産完了を確認するトランザクション、または製造指図からの物品受領を転記するトランザクションによって捕捉されます。 取得 最終生産確認または「完成報告」仕訳の転記タイムスタンプを使用します。 イベントタイプ explicit | |||
| 購買依頼書作成済み | 物流注文を履行するために必要な商品または原材料を調達するための内部要求を表します。このステップは通常、手持ちの在庫が不足している場合にトリガーされます。 | ||
| その重要性 調達サブプロセスへの依存性を示します。この活動を追跡することで、内部調達リードタイムとそれが全体の注文フルフィルメントに与える影響を測定できます。 取得元 通常、調達システムまたはERPシステムで購買依頼文書が作成された際に、個別のトランザクションとして記録されます。 取得 販売注文にリンクされた購買依頼文書の作成タイムスタンプを使用します。 イベントタイプ explicit | |||