サプライチェーン管理用データテンプレート
サプライチェーン管理用データテンプレート
これはサプライチェーン管理向けの汎用プロセスマイニング用データテンプレートです。より具体的なガイダンスについては、システム別テンプレートをご利用ください。
特定のシステムを選択- 一貫した分析のために標準化されたデータ項目
- プロセス全体の流れを把握するために必要なアクティビティ
- さまざまなサプライチェーン管理システムに適用可能
サプライチェーン管理の属性
| 名前 | 説明 | ||
|---|---|---|---|
| アクティビティ 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/4HANAOracle SCM CloudBlue Yonder WMSKinaxis RapidResponse | |||
| 最終データ更新日時 LastDataUpdate | ソースシステムからデータが最後に更新または抽出された時点を示すタイムスタンプです。 | ||
| 説明 この属性は、特定のイベントレコードについて、直近のデータ抽出または更新が行われた日付と時刻を記録します。データの鮮度と信頼性を確保するために使用される技術属性です。 最終データ更新日時は通常、直接的なプロセス分析には使われませんが、ダッシュボードの監視とデータガバナンスに欠かせません。表示されている情報がどの時点のものかを把握できるほか、データパイプラインの障害を検知するアラート設定にも利用できます。これにより、適時性と関連性のあるデータに基づいて業務上の意思決定を行えます。 重要な理由 データガバナンスと監視に欠かせない属性です。分析データの鮮度を確認し、提供される分析結果を信頼できるようにします。 入手先 通常は、データ取り込み処理中にETL(抽出、変換、ロード)ツールまたはデータ統合プラットフォームが生成・記録します。 例 2023-05-20T01:00:00Z2023-05-20T02:00:00Z2023-05-20T03:00:00Z | |||
| ユーザー名 UserName | アクティビティを実行したユーザー、チーム、または自動システムの名称またはIDです。 | ||
| 説明 ユーザー名属性は、プロセス内の特定のタスクを実行した個人、部門、またはシステムエージェントを識別します。ピッキングを完了する倉庫作業員や、発注書を自動作成するシステムボットなどが該当します。 ユーザーまたはチーム別にプロセスパフォーマンスを分析すると、効率の違い、トレーニングの必要性、優れた実践方法を把握できます。たとえば、処理時間が最も短いチームや、標準プロセスから頻繁に逸脱するユーザーを特定できます。また、重要な操作を誰が実行したかを追跡できるため、コンプライアンスと監査にも役立ちます。 重要な理由 この属性により、人またはシステムというリソースの観点を分析に加え、パフォーマンス比較、業務量の平準化、コンプライアンスの追跡が可能になります。 入手先 トランザクションログまたは文書変更履歴に含まれており、ユーザーマスターデータと関連付けられていることが一般的です。 例 j.smithWarehouseTeamAAUTO_INVOICE_BOTlisa.jones | |||
| 仕入先ID SupplierIdentifier | 原材料または部品を提供する仕入先を一意に識別する識別子です。 | ||
| 説明 仕入先識別子は、サプライチェーンの調達段階に関わる販売業者または仕入先を一意に識別するコードまたは番号です。このIDにより、発注書と入荷アクティビティを特定の仕入先に関連付けられます。 仕入先別にプロセスパフォーマンスを分析することは、効果的な仕入先管理に欠かせません。仕入先の納期遵守率、リードタイム、品質検査の合格率を測定できます。これらの分析結果は、仕入先評価表、契約交渉、リスク低減に向けたサプライチェーンの分散化に関する判断に役立ちます。仕入先別にプロセスを分けて分析することで、優れたパートナーや遅延の原因となる仕入先を特定できます。 重要な理由 仕入先のパフォーマンス分析を可能にし、リードタイム、納期遵守率、品質を測定できます。調達の最適化に欠かせない属性です。 入手先 ERPまたは調達システムの発注書や仕入先マスターデータに含まれています。 例 SUP-1001V-98765ACME-CORP | |||
| 実納品日 ActualDeliveryDate | 受注品が顧客に正常に納品された実際の日付です。納品証明によって確認されます。 | ||
| 説明 実納品日は、商品が顧客に受け取られた時点を記録する、受注履行ライフサイクルの最終タイムスタンプです。通常は納品証明書または運送業者からのステータス更新によって確認されます。 この属性は、実際のエンドツーエンドのサイクルタイム計算とパフォーマンス測定に欠かせません。希望納品日と比較することで、受注が早着、納期どおり、遅延のいずれであったかを直接判定できます。このデータを分析すると、調達、生産、物流のどこで遅延が発生したかを含め、遅延の構造的な原因を特定できます。また、納品の信頼性を改善するための事実に基づく根拠を得られます。 重要な理由 実際のサイクルタイムを測定するための事実上の終点となり、希望納品日と組み合わせて納期遵守パフォーマンスを判定します。 入手先 輸送管理システム(TMS)、運送業者からの更新情報、または納品証明記録から取得されます。 例 2023-05-022023-06-142023-07-22 | |||
| 希望納品日 RequestedDeliveryDate | 顧客が希望した、または社内で計画した受注の納品日です。 | ||
| 説明 希望納品日は、商品が顧客の所在地に到着する目標日です。通常は受注時に顧客が指定するか、社内の計画プロセスで決定します。 この属性は、サプライチェーン管理における重要なKPIである納期遵守パフォーマンスを測定するための基準となります。希望納品日と実納品日を比較することで、納期遵守率(OTIF)を計算し、遅延の原因を特定するとともに、地域、顧客、製品タイプごとの傾向を分析できます。顧客満足度とサプライチェーンの信頼性を評価するうえで欠かせません。 重要な理由 納期遵守率を計算する基準となります。サプライチェーンのパフォーマンスと顧客満足度を測定する重要なKPIの一つです。 入手先 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(在庫保管単位)または品目番号であることが多く、調達、生産、納品の対象となる品目を一意に識別します。単一の物流受注に、1つまたは複数の製品識別子が含まれる場合があります。 製品別にサプライチェーンプロセスを分析すると、異なる品目がシステム内をどのように流れるかを把握できます。生産リードタイムが長い製品、品質検査の不合格率が高い製品、出荷遅延が発生しやすい製品を特定できます。この製品レベルの分析は、在庫管理、需要予測、製品群ごとの生産・物流戦略の最適化に欠かせません。 重要な理由 プロセスを製品レベルで分析でき、サイクルタイムが長い製品や、プロセス上の例外が多い製品を特定できます。 入手先 販売受注、発注書、製造指図の明細データに含まれています。 例 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)の記録に含まれています。 例 トラック航空海上鉄道 | |||
サプライチェーン管理のアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
| 出荷伝票作成 | 倉庫がピッキング、梱包、出荷作業を開始するための出荷伝票が作成されたことを示します。このアクティビティにより、プロセスは正式に受注管理から物流実行へ移行します。 | ||
| 重要な理由 営業チームと物流チームの間で引き継ぎが行われる重要な地点です。全体の注文リードタイムを構成する重要な要素である、受注処理サイクルタイムの開始を示します。 入手先 物流実行システムで納品書、出荷指示書、または同等の文書が作成された際に、明示的なイベントとして記録されます。 取得 出荷伝票または出荷書類の作成タイムスタンプを使用します。 イベントタイプ explicit | |||
| 出荷完了 | 梱包済みの商品が倉庫または配送センターを物理的に出発した時点を示します。このイベントにより、通常は所有権上のリスクが移転し、在庫や売上原価などの財務記録が更新されます。 | ||
| 重要な理由 輸送中の時間が始まる重要な節目です。顧客の希望納品日を基準に、出荷の納期遵守パフォーマンスを測定する重要な日付です。 入手先 WMSまたはERPシステムの「出庫」転記、「出荷確認」トランザクション、または同様のイベントから取得します。 取得 在庫を減少させる出庫トランザクションの転記日またはタイムスタンプを使用します。 イベントタイプ explicit | |||
| 注文キャンセル | 履行が完了する前に物流注文が終了したことを示します。顧客の依頼が履行されなかったことを示す、プロセスの別の終了状態です。 | ||
| 重要な理由 重大な失敗イベントです。注文がキャンセルされた理由と時点を分析することで、販売、商品の在庫状況、顧客とのコミュニケーションに関する問題を特定できます。 入手先 販売注文の最終ステータスが「キャンセル」や「無効」などに変更された記録から取得します。 取得 注文ステータスが最終的に「キャンセル」または「無効」に変更された時点のタイムスタンプを取得します。 イベントタイプ explicit | |||
| 注文作成 | 物流注文のライフサイクルが正式に始まることを示します。顧客からの商品またはサービスの依頼が入力され、基幹業務システムに新しい注文書として保存された時点で発生するイベントです。 | ||
| 重要な理由 このプロセスの主要な開始イベントです。このアクティビティから他のアクティビティまでの時間を分析することで、受注から入金までのサイクルタイム全体を把握し、初期段階のボトルネックを特定できます。 入手先 通常は、受注管理システムまたはERPシステムの販売注文や顧客注文ヘッダーテーブルにある作成タイムスタンプから取得します。 取得 主要な販売注文書の作成タイムスタンプを使用します。 イベントタイプ explicit | |||
| 発注書発行 | このアクティビティは、外部サプライヤーへの発注書の正式な作成と送付を示します。合意した価格で商品や資材を購入する法的な約束を表します。 | ||
| 重要な理由 サプライヤーのリードタイムが始まる重要な節目です。このイベントから入荷までの時間を分析することは、サプライヤーのパフォーマンス管理に欠かせません。 入手先 通常は、発注書が確認、承認、またはサプライヤーに送付された時点のステータス更新やタイムスタンプから取得します。 取得 発注書のステータスが確認、承認、またはサプライヤーに送付された時点のタイムスタンプを取得します。 イベントタイプ explicit | |||
| 納品完了 | 出荷品が顧客の納品先に到着し、物理的に受領されたことを示します。輸送工程の終了を示すアクティビティです。 | ||
| 重要な理由 輸送時間と運送会社の納期遵守パフォーマンスを測定します。顧客の視点で、受注から納品までのサイクルタイム全体を計算するための重要なイベントです。 入手先 通常は、EDIメッセージなどの運送会社のデータフィード、または輸送管理システムやERPでの手動更新から取得します。 取得 通常は、運送会社の追跡情報の更新、または納品証明の日付の入力から推定します。 イベントタイプ inferred | |||
| 納品証明受領 | 顧客が納品を受け入れたことを、署名などにより正式に確認したことを示します。このアクティビティにより、物流の受注処理が正式に完了します。 | ||
| 重要な理由 正常に履行された注文の最終イベントです。収益認識や納品に関する紛争の解決に欠かせません。 入手先 通常は、ステータス更新、または注文や出荷伝票への納品証明書の添付から取得します。 取得 納品証明のステータスが更新された時点、またはPOD文書が注文や出荷伝票に添付された時点のタイムスタンプを取得します。 イベントタイプ explicit | |||
| 顧客請求書作成 | 出荷した商品に基づき、顧客向けの請求書が作成されたことを示します。このアクティビティにより、受注から入金までのサイクルにおける決済プロセスが始まります。 | ||
| 重要な理由 売掛金プロセスへの引き継ぎを示します。出荷から請求までの間隔を分析することで、請求の遅延とキャッシュフローへの影響を明らかにできます。 入手先 ERPシステムの請求または財務モジュールで請求書が作成または転記された際に、明示的に記録されます。 取得 顧客請求書の作成または転記タイムスタンプを使用します。 イベントタイプ explicit | |||
| サプライヤーからの入荷 | 外部サプライヤーからの商品や原材料が、倉庫または生産施設に物理的に到着したことを示します。このイベントにより在庫水準が更新され、資材が使用可能になります。 | ||
| 重要な理由 このアクティビティでサプライヤーのリードタイムが終了します。入荷日と希望納品日を比較することで、サプライヤーの納期遵守パフォーマンスを測定できます。 入手先 在庫管理システム、倉庫管理システム、またはERPシステムの入荷トランザクションから取得します。 取得 発注書に対する入荷トランザクションの転記日または登録タイムスタンプを使用します。 イベントタイプ explicit | |||
| ピッキング完了 | 倉庫内の保管場所から商品を集める物理的な作業が完了したことを示します。出荷に向けて注文を準備する重要なステップです。 | ||
| 重要な理由 倉庫のピッキング業務の効率を測定します。出荷伝票の作成からピッキング完了までの時間を分析することで、倉庫内のボトルネックを特定できます。 入手先 通常は、出荷伝票のステータス更新、または倉庫管理システムのトランザクションログから取得します。スキャンによって記録されることもあります。 取得 出荷伝票のピッキングステータスが「完了」に更新された時点のタイムスタンプを使用します。 イベントタイプ explicit | |||
| 品質検査完了 | 製造または入荷した商品の品質管理チェックが完了したことを示します。出荷可能になる前に、商品が必要な基準を満たしていることを確認するステップです。 | ||
| 重要な理由 プロセス上の重要な品質ゲートを示します。この段階での遅延や不合格は、納期遵守と顧客満足度に大きな影響を与える可能性があります。 入手先 通常は、品質管理モジュールのステータス更新またはトランザクションから取得します。「使用決定」と呼ばれることもあります。 取得 品質検査ロットの最終ステータス変更または使用決定のタイムスタンプから取得します。 イベントタイプ inferred | |||
| 梱包完了 | ピッキングした商品をまとめ、出荷用の箱に梱包し、ラベルを貼る作業が完了したことを示します。倉庫内で行われる最後の付加価値ステップです。 | ||
| 重要な理由 梱包プロセスの効率を測定します。ピッキングから梱包完了までの時間を確認することで、梱包ステーションの制約を特定できます。 入手先 通常は、梱包ステーションの担当者が箱の封かんを確認した時点、またはWMSで出荷ラベルが生成された時点に記録されます。 取得 梱包確認トランザクションまたは出荷ラベル作成イベントのタイムスタンプを使用します。 イベントタイプ explicit | |||
| 注文保留適用 | 与信審査の不合格や品質上の懸念など、特定の理由で注文が一時的に停止された際に発生します。注文を再開するには、保留を解消する必要があります。 | ||
| 重要な理由 プロセスの中断と手戻りのループを明らかにします。保留の頻度と期間を分析することで、遅延を引き起こす構造的な問題を見つけ出せます。 入手先 通常は、注文のステータス変更、または後続処理をブロックする理由コードの適用から推定します。 取得 販売注文のヘッダーまたは明細に「ブロック」または「保留」ステータスが適用された時点のタイムスタンプを特定します。 イベントタイプ inferred | |||
| 生産完了 | 完成品の製造または組み立てプロセスが完了したことを示します。この時点で商品は完成品として報告され、在庫に移されます。 | ||
| 重要な理由 このアクティビティで生産サイクルが終了します。生産開始から完了までの時間は、製造効率と生産スループットを測る重要な指標です。 入手先 通常は、生産完了を確認するトランザクション、または製造指図からの入荷を転記するトランザクションによって取得します。 取得 最終生産確認のタイムスタンプ、または「Report as Finished」仕訳の転記タイムスタンプを使用します。 イベントタイプ explicit | |||
| 製造指図作成 | 顧客に必要な商品を製造または組み立てるための社内注文が正式に作成されたことを示します。生産計画と実行のサブプロセスを開始します。 | ||
| 重要な理由 注文に製造が必要であることを示します。これにより、生産リードタイムと注文サイクルタイム全体への影響を分析できます。 入手先 製造システムまたはERPシステムで製造指図や作業指図が作成された際に、個別のイベントとして記録されます。 取得 顧客需要に関連付けられた製造指図書の作成タイムスタンプを使用します。 イベントタイプ explicit | |||
| 購買依頼作成 | 物流注文を履行するために必要な商品や原材料を調達する、社内からの依頼を表します。通常、手元の在庫が不足している場合にこのステップが開始されます。 | ||
| 重要な理由 調達サブプロセスへの依存関係を示します。このアクティビティを追跡することで、社内調達のリードタイムと、受注処理全体への影響を測定できます。 入手先 通常は、調達システムまたはERPシステムで購買依頼書が作成された際に、個別のトランザクションとして記録されます。 取得 販売注文に関連付けられた購買依頼書の作成タイムスタンプを使用します。 イベントタイプ explicit | |||
抽出ガイド
準備はできましたか?
サプライチェーンのデータを最大限に役立てます。用途に合った手順を確認する場合はシステム別ガイドを選択し、まず始める場合はこの汎用テンプレートを基盤として、サプライチェーンに関する理解を深めてください。
今すぐサプライチェーンを最適化し、効率を高める
サプライチェーンプロセスをすぐに把握し、コストを削減できます。
クレジットカードは不要です。数分で始められます。