サプライチェーン管理のデータテンプレート
サプライチェーン管理のデータテンプレート
これはサプライチェーン管理向けの汎用プロセスマイニング用データテンプレートです。より詳しい手順については、システム別のテンプレートをご利用ください。
特定のシステムを選択- 一貫した分析に向けた標準データ項目
- プロセス全体の流れを把握するために必要なアクティビティ
- さまざまなサプライチェーン管理システムに対応
サプライチェーン管理の属性
| 名前 | 説明 | ||
|---|---|---|---|
| アクティビティ Activity | 物流プロセスで発生した業務イベントや手順の名称です。たとえば「発注書を発行」や「商品を出荷」などがあります。 | ||
| 説明 アクティビティは、サプライチェーンプロセスで実行される個々の手順やタスクを表します。それぞれが物流受注のライフサイクルにおける特定の時点を示し、プロセスマップを構成する要素となります。 アクティビティを分析すると、実際にどの手順が、どの順序で、どの程度の頻度で実行されているかを把握できます。これにより、ボトルネックや重複した手順、標準業務手順からの逸脱を特定できます。サプライチェーンでよく見られるアクティビティには、受注作成、入荷、ピッキング、梱包、出荷、請求などがあります。 重要な理由 この属性はプロセスマップの基盤となり、サプライチェーンにおける手順の順序を可視化して分析できます。 入手先 イベントログ、ステータス変更記録、文書タイプ、またはソースシステムのトランザクションコードから取得されることがよくあります。 例 発注書発行商品の生産完了ピッキング完了商品出荷 | |||
| 物流受注 CaseId | エンドツーエンドの物流受注を一意に識別するIDです。プロセス分析における主要なケースIDとして使用されます。 | ||
| 説明 ケースIDは、分析対象となるプロセスの個々の実行を識別します。サプライチェーン管理では、通常、物流受注番号がこれにあたり、受注の作成から最終納品まで、関連するすべてのアクティビティを結び付けます。 この属性を使うと、発注書の作成、商品の出荷、顧客への請求など、関連するすべてのイベントを1つのエンドツーエンドのプロセスフローにまとめられます。IDを追跡することで、受注の全体像を可視化し、サイクルタイムの合計を測定するとともに、受注経路ごとの違いを特定できます。一貫したケースIDがなければ、プロセスフローを正確に再構成することはできません。 重要な理由 関連するすべてのアクティビティを1つのケースに結び付けるため、プロセスマイニングの基礎となる属性です。エンドツーエンドのプロセスフローを分析できます。 入手先 通常、販売受注や納品書などの主要な業務文書のヘッダーデータ、または物流受注を管理するテーブルにあります。 例 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 | |||
| サプライヤーID SupplierIdentifier | 原材料や部品を供給するサプライヤーを一意に識別するIDです。 | ||
| 説明 サプライヤー識別子は、サプライチェーンの調達段階に関わるベンダーやサプライヤーを一意に識別するコードまたは番号です。このIDによって、発注書や入荷アクティビティを特定のサプライヤーに結び付けます。 サプライヤーごとのプロセスパフォーマンス分析は、効果的なサプライヤー管理に欠かせません。納期遵守率、リードタイム、品質検査の合格率を測定できます。こうしたインサイトは、サプライヤー評価、契約交渉、リスクを抑えるための調達先分散の判断に役立ちます。サプライヤー別にプロセスを分けて分析すると、パフォーマンスの高い取引先や遅延の原因となる取引先を特定できます。 重要な理由 サプライヤーパフォーマンス分析に利用でき、リードタイム、納期遵守率、品質の測定に役立ちます。調達の最適化に欠かせない属性です。 入手先 ERPまたは調達システムの発注書やサプライヤーマスターデータにあります。 例 SUP-1001V-98765ACME-CORP | |||
| ユーザー名 UserName | アクティビティを実行したユーザー、チーム、または自動化システムの名前やIDです。 | ||
| 説明 ユーザー名属性は、プロセス内の特定のタスクを実行した個人、部門、またはシステムエージェントを示します。たとえば、ピッキングを完了した倉庫作業者や、発注書を自動作成するシステムボットなどです。 ユーザーやチームごとにプロセスのパフォーマンスを分析すると、効率の違いや研修の必要性、優れた取り組みを把握できます。たとえば、処理時間が最も短いチームや、標準プロセスから逸脱する頻度が高いユーザーを特定できます。また、重要な操作を誰が実行したかを追跡できるため、コンプライアンスや監査にも役立ちます。 重要な理由 人やシステムのリソースという観点を分析に加え、パフォーマンスの比較、作業負荷の調整、コンプライアンスの追跡を可能にします。 入手先 トランザクションログや文書の変更履歴から取得できます。多くの場合、ユーザーマスターデータと関連付けられています。 例 j.smith倉庫チームA請求書自動作成ボットlisa.jones | |||
| 実際の納品日 ActualDeliveryDate | 納品証明によって確認された、受注品が顧客に実際に納品された日付です。 | ||
| 説明 実際の納品日は、受注処理のライフサイクルにおける最終時点を示し、顧客が商品を受け取った日時を記録します。納品証明書や運送業者からのステータス更新によって確認されることがよくあります。 この属性は、実際のエンドツーエンドのサイクルタイムの算出やパフォーマンス測定に欠かせません。希望納品日と比較することで、受注が予定より早く届いたか、予定どおりか、遅れたかを判定できます。データを分析すると、調達、生産、物流のどこに遅延の根本原因があるかを特定でき、納品の信頼性を高めるための事実に基づく判断が可能になります。 重要な理由 実際のサイクルタイムを測る基準となる終了時点を示します。希望納品日と組み合わせて、納期遵守パフォーマンスの判定に使います。 入手先 輸送管理システム(TMS)、運送業者からの更新情報、または納品証明の記録から取得できます。 例 2023-05-022023-06-142023-07-22 | |||
| 希望納品日 RequestedDeliveryDate | 顧客が希望した、または社内で計画した受注の納品日です。 | ||
| 説明 希望納品日は、商品が顧客の所在地に到着する予定日です。通常、受注時に顧客が指定するか、社内の計画プロセスで決定します。 この属性は、サプライチェーン管理で重要な指標となる納期遵守パフォーマンスを測定する際のベースラインです。希望納品日と実際の納品日を比較すると、納期遵守率(OTIF)を算出し、遅延の原因を特定するとともに、地域、顧客、製品タイプごとの傾向を分析できます。顧客満足度とサプライチェーンの信頼性を評価するうえで欠かせません。 重要な理由 サプライチェーンのパフォーマンスと顧客満足度を測る重要業績評価指標(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 | 物流受注に関連する製品を一意に識別するIDです。SKUや品目番号などが該当します。 | ||
| 説明 製品識別子は、SKU(在庫管理単位)や品目番号など、調達、生産、納品する品目を一意に識別するものです。1件の物流受注に、1つまたは複数の製品識別子が含まれる場合があります。 製品別にサプライチェーンプロセスを分析すると、品目ごとの流れを把握できます。生産リードタイムが長い製品、品質検査の不合格率が高い製品、出荷遅延が起きやすい製品を特定できます。製品単位の分析は、在庫管理や需要予測に欠かせず、製品群ごとの生産・物流戦略の最適化にも役立ちます。 重要な理由 製品ごとにプロセスを分析でき、サイクルタイムが長い製品や、プロセス上の例外が多い製品を特定できます。 入手先 販売受注、発注書、または製造指図の明細にあります。 例 SKU-12345-BLK-LMAT-RAW-0098PN-750-B | |||
| 顧客ID CustomerIdentifier | 受注した顧客を一意に識別するIDです。 | ||
| 説明 顧客識別子は、顧客ごとに割り当てられる一意のコードまたは番号です。この属性によって、物流受注を商品と請求の受取先となる顧客に結び付けます。 この属性は、受注から入金までのプロセスを分類して分析する際の重要な軸です。顧客グループや主要顧客ごとに、納期遵守や受注サイクルタイムなどの指標を評価できます。分析を通じて、遅延が多い顧客や、特有のプロセス経路を持つ顧客を把握できます。こうしたインサイトは、顧客サービスの向上や、個別のニーズに合わせた物流業務の調整に役立ちます。 重要な理由 顧客ごとにサイクルタイムや納期遵守などの指標を分類でき、顧客を軸とした分析が可能になります。 入手先 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 | |||
| 商品納品 | 出荷した商品が顧客の届け先に到着し、実際に受領されたことを示します。輸送工程の終了時点です。 | ||
| 重要な理由 輸送時間と運送業者の納期遵守パフォーマンスを測定します。顧客の視点で受注から納品までのサイクルタイムを算出する際に欠かせないイベントです。 入手先 EDIメッセージなどの運送業者のデータフィード、または輸送管理システムやERPへの手動入力から取得することがよくあります。 記録 通常、運送業者の追跡情報の更新、または納品証明日の入力から推定します。 イベントタイプ inferred | |||
| 注文キャンセル | 履行が完了する前に物流注文が終了したことを示します。顧客の依頼が履行されなかったことを表す、プロセスの別の終了状態です。 | ||
| 重要な理由 重大な失敗を示すイベントです。注文がキャンセルされた理由と時期を分析すると、販売、商品の在庫状況、顧客とのコミュニケーションに関する問題を特定できます。 入手先 販売注文の最終ステータスがCanceledやVoidなどに変更された記録から取得します。 記録 注文のステータスがCanceledまたはVoidに確定変更された時点のタイムスタンプを記録します。 イベントタイプ explicit | |||
| 注文作成 | 物流の受注プロセスが正式に始まる時点を示します。顧客からの商品やサービスの依頼が基幹業務システムに入力され、新しい注文文書として保存されたときに発生するイベントです。 | ||
| 重要な理由 このプロセスの主な開始イベントです。このアクティビティから後続の工程までの時間を分析すると、受注から入金までのサイクルタイム全体を把握し、初期段階のボトルネックを特定できます。 入手先 通常、受注管理システムまたはERPの販売注文や顧客注文ヘッダーテーブルに記録された作成タイムスタンプから取得します。 記録 主要な販売注文文書の作成タイムスタンプを使用します。 イベントタイプ explicit | |||
| 発注書発行 | このアクティビティは、外部サプライヤーへの発注書の正式な作成と送付を示します。合意した価格で商品や資材を購入する法的な約束にあたります。 | ||
| 重要な理由 サプライヤーのリードタイムが始まる重要な節目です。このイベントから入荷までの時間を分析することは、サプライヤーのパフォーマンス管理に欠かせません。 入手先 通常、発注書の確定、承認、またはサプライヤーへの送付時のステータス更新やタイムスタンプから取得します。 記録 発注書のステータスが確定または承認された時点、あるいはサプライヤーに送付された時点のタイムスタンプを記録します。 イベントタイプ explicit | |||
| 納品証明受領 | 顧客が納品を受領したことを、署名などで正式に確認したことを示します。このアクティビティによって、物流の出荷準備プロセスが正式に終了します。 | ||
| 重要な理由 正常に履行された注文の最終イベントです。収益認識や納品に関する紛争の解決に欠かせません。 入手先 通常、ステータス更新、または注文や出荷に納品証明文書を添付した記録から取得します。 記録 納品証明のステータスが更新された時点、またはPOD文書が注文や出荷に添付された時点のタイムスタンプを記録します。 イベントタイプ explicit | |||
| 顧客請求書作成 | 出荷した商品に基づいて顧客向けの請求文書が作成されたことを示します。このアクティビティから、受注から入金までのサイクルの決済工程が始まります。 | ||
| 重要な理由 売掛金管理プロセスへの引き継ぎを示します。出荷から請求までの間隔を分析すると、請求の遅れとキャッシュフローへの影響を明らかにできます。 入手先 ERPシステムの請求または財務モジュールで請求書文書が作成または転記された際に、明示的に記録されます。 記録 顧客請求書文書の作成または転記のタイムスタンプを使用します。 イベントタイプ explicit | |||
| サプライヤーからの入荷 | 外部サプライヤーから倉庫や生産施設に商品または原材料が物理的に届いたことを示します。このイベントによって在庫数が更新され、資材を使用できるようになります。 | ||
| 重要な理由 このアクティビティでサプライヤーのリードタイムが終了します。入荷日と希望納期を比較すると、サプライヤーの納期遵守パフォーマンスを測定できます。 入手先 在庫管理、倉庫管理、またはERPシステムの入荷トランザクションから取得します。 記録 発注書に対する入荷トランザクションの転記日または入力タイムスタンプを使用します。 イベントタイプ explicit | |||
| ピッキング完了 | 倉庫内の保管場所から商品を集める作業が完了したことを示します。注文を出荷する準備を整えるうえで重要な工程です。 | ||
| 重要な理由 倉庫のピッキング業務の効率を測定します。出荷伝票の作成からピッキング完了までの時間を分析すると、倉庫内のボトルネックを特定できます。 入手先 通常、出荷伝票のステータス更新、または倉庫管理システムのトランザクションログから取得します。スキャンによって記録される場合もあります。 記録 出荷伝票のピッキングステータスがCompleteに更新された時点のタイムスタンプを使用します。 イベントタイプ explicit | |||
| 品質検査完了 | 製造または入荷した商品の品質検査が完了したことを示します。出荷可能にする前に、商品が必要な基準を満たしていることを確認する工程です。 | ||
| 重要な理由 プロセスにおける重要な品質ゲートを示します。この段階で遅延や不合格が発生すると、納期遵守や顧客満足度に大きく影響する可能性があります。 入手先 通常、品質管理モジュールのステータス更新やトランザクションから取得します。使用決定と呼ばれることもあります。 記録 品質検査ロットの最終ステータス変更または使用決定のタイムスタンプから取得します。 イベントタイプ inferred | |||
| 商品の生産完了 | 完成品の製造または組み立てが完了したことを示します。この時点で商品は完成品として報告され、在庫に移されます。 | ||
| 重要な理由 このアクティビティで生産サイクルが終了します。製造オーダーの作成から完了までの時間は、製造効率と生産量を測る重要な指標です。 入手先 通常、生産完了を確定するトランザクション、または製造オーダーに対する入荷を転記するトランザクションから取得します。 記録 最終生産確認のタイムスタンプ、またはReport as Finishedの仕訳転記時刻を使用します。 イベントタイプ explicit | |||
| 梱包完了 | ピッキングした商品をまとめ、出荷用の箱に詰めてラベルを貼る工程が完了したことを示します。倉庫内で付加価値を生み出す最後の工程です。 | ||
| 重要な理由 梱包工程の効率を測定します。ピッキングから梱包完了までの時間を確認すると、梱包ステーションの制約を特定できます。 入手先 梱包ステーションの担当者が箱の封かんを確定したとき、またはWMSで出荷ラベルが作成されたときに記録されることがよくあります。 記録 梱包確定トランザクションまたは出荷ラベル作成イベントのタイムスタンプを使用します。 イベントタイプ explicit | |||
| 注文保留 | 与信審査の不合格や品質上の懸念など、特定の理由で注文が一時的に停止されたときに発生するイベントです。注文を再開するには、保留の原因を解消する必要があります。 | ||
| 重要な理由 プロセスの中断や手戻りの繰り返しを示します。保留の頻度と期間を分析すると、遅延を引き起こす組織的な問題を明らかにできます。 入手先 通常、注文のステータス変更、または後続の処理を止める理由コードの適用から推定します。 記録 販売注文のヘッダーまたは明細にブロックまたは保留のステータスが適用された時点のタイムスタンプを特定します。 イベントタイプ inferred | |||
| 製造オーダー作成 | このアクティビティは、顧客に必要な商品を製造または組み立てるための社内オーダーを正式に作成したことを示します。生産計画と実行のサブプロセスが始まります。 | ||
| 重要な理由 注文に製造が必要であることを示します。これにより、生産リードタイムと受注サイクルタイム全体への影響を分析できます。 入手先 製造システムまたはERPで製造オーダーや作業オーダーを作成した際に、個別のイベントとして記録されます。 記録 顧客需要に関連付けられた製造オーダー文書の作成タイムスタンプを使用します。 イベントタイプ explicit | |||
| 購買依頼作成 | 物流注文の履行に必要な商品や原材料を調達するための社内依頼を示します。通常、手持ち在庫が不足している場合にこの工程が始まります。 | ||
| 重要な理由 調達サブプロセスへの依存を示します。このアクティビティを追跡すると、社内の調達リードタイムと、受注処理全体への影響を測定できます。 入手先 通常、調達システムまたはERPで購買依頼文書を作成した際に、個別のトランザクションとして記録されます。 記録 販売注文に関連付けられた購買依頼文書の作成タイムスタンプを使用します。 イベントタイプ explicit | |||
データ抽出ガイド
データの抽出方法はシステムによって異なります。詳しい手順は、
始める準備はできていますか?
サプライチェーンデータから、改善につながる情報を見つけましょう。システム別ガイドで環境に合わせた手順を確認するか、この汎用テンプレートを土台にして、今日から分析を始められます。
サプライチェーンを最適化し、今すぐ効率を高める
サプライチェーンのプロセスをすぐに把握し、コスト削減につなげましょう。
クレジットカードは不要です。数分で始められます。