サプライチェーン管理のデータテンプレート
サプライチェーン管理のデータテンプレート
- 詳細な分析に必要な推奨属性
- 追跡する主要なプロセスアクティビティとマイルストーン
- Blue Yonderからデータを抽出する手順
サプライチェーン管理の属性
| 名前 | 説明 | ||
|---|---|---|---|
| アクティビティ名 ActivityName | 物流プロセス内で発生した業務イベントまたはステップの名称です。「発注書の発行」や「商品のピッキングと梱包」などが該当します。 | ||
| 説明 アクティビティ名は、物流受注のライフサイクルで実行された個々のステップやタスクを表します。各ケースの一連の処理を示すため、イベントは時系列で記録されます。 アクティビティの分析は、プロセスマイニングの基礎です。プロセスマップの可視化、特定のステップ間にあるボトルネックの検出、アクティビティの発生頻度の分析、標準的なプロセスフローからの逸脱の特定に役立ちます。 重要な理由 この属性はプロセスマップ上のステップを定義し、物流受注の流れを可視化、分析、最適化できるようにします。 入手先 アクティビティ名は、倉庫管理、輸送、受注管理に関連するBlue Yonderの各種モジュールに記録されたイベントログ、トランザクションコード、またはステータス変更から取得します。 例 顧客からの受注製品の生産完了出荷スケジュールの設定納品受領の署名 | |||
| 物流受注 LogisticsOrder | 個々の物流受注を識別する一意のIDです。サプライチェーン全体のプロセスを追跡するための主要なケースIDとして使われます。 | ||
| 説明 物流受注は、顧客受注の作成から最終納品まで、関連するすべてのアクティビティを結び付ける中心的な識別子です。一意の物流受注番号1つにつき、サプライチェーンプロセスの1件を表します。 プロセスマイニングでは、物流受注ごとにデータを分析することで、受注のライフサイクル全体を把握できます。エンドツーエンドのサイクルタイムの算出、プロセスのバリアントの特定、調達、生産、流通などの各段階を受注がどのように進むかの理解に役立ちます。 重要な理由 これは基本となるケースIDです。プロセスの各ステップを結び付け、受注対応の全体像を再構成して分析できるようにします。 入手先 通常、Blue Yonderの受注管理または物流実行の主要モジュールで確認できます。 例 LO-845123LO-845124LO-845125 | |||
| 開始時刻 EventTime | 特定のアクティビティが開始または発生した時刻を示すタイムスタンプです。 | ||
| 説明 イベント時刻または開始時刻は、アクティビティがソースシステムに記録された正確な日時です。この時系列データは、イベントを正しい順序に並べるため、また時間に基づく分析全般に欠かせません。 このタイムスタンプを使って、アクティビティ間のサイクルタイムやプロセス全体の所要時間を算出し、遅延や待ち時間を特定します。受注から納品までのリードタイムや輸送サイクル時間など、パフォーマンスに関するほぼすべての重要業績評価指標(KPI)の基礎となります。 重要な理由 イベントの順序付け、所要時間の算出、時間の経過に伴うプロセスのパフォーマンスやボトルネックの分析に欠かせないタイムスタンプです。 入手先 通常、Blue Yonderの各業務オブジェクトに関するトランザクションデータテーブルで、作成日時、変更日時、または転記日時のタイムスタンプとして確認できます。 例 2023-10-26T09:00:00Z2023-10-26T14:30:00Z2023-10-27T11:15:00Z | |||
| サプライヤー名 SupplierName | 発注書に基づいて原材料または部品を供給するサプライヤーの名前です。 | ||
| 説明 サプライヤー名は、サプライチェーンプロセスで商品を調達した取引先を示します。入荷物流や調達段階を分析する際の重要な切り口です。 「サプライヤー入荷実績」ダッシュボードでは、この属性を使って、発注書の作成から資材の受領までのサイクルタイムをサプライヤー別に比較できます。安定して迅速に納品するサプライヤーと、遅延が繰り返し発生するサプライヤーを特定し、調達方針やサプライヤーとの関係管理に役立てられます。 重要な理由 サプライヤーごとの実績を分析できます。入荷物流の最適化や生産スケジュールの遵守に欠かせません。 入手先 この情報は発注書ヘッダーデータに保存され、Blue Yonderまたは連携先のERPにあるサプライヤーマスターデータテーブルと関連付けられています。 例 グローバル・コンポーネンツ社アドバンスト・マテリアルズ社プレシジョン・パーツ社 | |||
| ユーザー名 UserName | アクティビティを実行した担当者のユーザーIDまたは名前です。 | ||
| 説明 この属性は、特定のプロセスステップを担当した従業員またはシステムユーザーを示します。リソースの割り当てや作業負荷の分布、個人またはチーム単位のパフォーマンスを把握するうえで欠かせません。 分析では、ユーザー名でプロセスマップを絞り込み、同じタスクに対するユーザーごとの実績を比較したり、トレーニングの必要性や優れた実績を特定したりできます。また、「手作業タスクと自動化の可能性」ダッシュボードで、頻繁に繰り返されるタスクに関わるユーザーを確認する際にも重要です。 重要な理由 ユーザーの操作を個人に関連付けることで、作業負荷の分析、パフォーマンスの比較、自動化の可能性の特定ができます。 入手先 通常、トランザクションデータの「作成者」または「変更者」フィールドに記録され、Blue Yonderのユーザーマスターデータテーブルに関連付けられています。 例 j.doea.smithSYSTEM_RFC | |||
| 実際の納品日 ActualDeliveryDate | 納品証明によって確認された、受注品が顧客に正常に納品された実際の日付です。 | ||
| 説明 実際の納品日は、納品の完了時に記録され、通常は「納品受領の署名」イベントから取得します。このタイムスタンプは、物流受注の受注対応が完了した時点を示します。 この属性は、パフォーマンスの測定に欠かせません。「希望納品日」と比較して、納品が予定どおりか、遅れたか、早まったかを判定します。この計算が納期遵守率の重要業績評価指標(KPI)の基礎となり、「納期遵守パフォーマンス」ダッシュボードに表示されます。 重要な理由 納期遵守率の算出に欠かせない属性で、顧客の期待に対する実際の納品実績を測定します。 入手先 通常、納品証明イベントのタイムスタンプから取得します。Blue YonderのTMSまたは関連する物流モジュールに記録される場合があります。 例 2023-11-142023-11-212023-12-01 | |||
| 希望納品日 RequestedDeliveryDate | 顧客が受注時に希望した納品日です。 | ||
| 説明 希望納品日は、物流受注に関連付けられた重要な顧客マスターデータです。顧客への納期の約束を示し、納品実績を測る主な基準となります。 この日付と「実際の納品日」を比較して、納期遵守率の重要業績評価指標(KPI)を算出します。「納期遵守パフォーマンス」ダッシュボードの基礎となり、運送業者の実績や社内のボトルネックなど、遅延の原因を分析できます。 重要な理由 顧客満足度と納品実績を測るベースラインです。納期遵守率の重要業績評価指標(KPI)の算出に欠かせません。 入手先 通常、Blue Yonderの受注管理システムにある顧客受注ヘッダーデータに保存されています。 例 2023-11-152023-11-202023-12-01 | |||
| 注文ステータス OrderStatus | 「処理中」「完了」「キャンセル」など、物流注文の現在または最終的なステータスです。 | ||
| 説明 注文ステータスは、データ抽出時点で物流注文がライフサイクルのどの段階にあるか、または最終的にどのような結果になったかを示します。ケースの状態を把握するための重要な指標です。 この属性を使うと、完了した注文だけに絞って分析したり、特定の注文がキャンセルされた理由を調べたりできます。プロセスバリアントごとの結果を理解し、プロセス全体の成功率や失敗率を測る際にも役立ちます。 重要な理由 ケースの結果を示します。完了、進行中、キャンセルの注文に絞って分析できるため、パフォーマンス指標を適切な背景とともに評価できます。 入手先 通常、Blue Yonderの主要な物流注文または出荷伝票のヘッダーにあるステータス項目です。 例 完了処理中キャンセル保留中 | |||
| 注文種別 OrderType | 「通常注文」「緊急注文」「一括注文」など、注文の分類です。 | ||
| 説明 注文種別は、特性、緊急度、業務上の背景に基づいて物流注文を分類します。注文種別によって、プロセスの経路やサービスレベル合意(SLA)が異なることがあります。 注文種別ごとの分析は、プロセスの違いを理解するうえで欠かせません。たとえば、緊急注文はサイクルタイムが短く、一部の手順を省略する場合があります。一方、一括注文では生産のリードタイムが長くなることがあります。この属性を使うと、特定のケースが標準から外れる理由を把握でき、「プロセスバリアント分析」ダッシュボードでの分析にも役立ちます。 重要な理由 注文種別ごとに経路、優先度、SLAが異なることが多いため、プロセスの違いやパフォーマンスの差を理解するのに役立ちます。 入手先 通常、この情報はBlue Yonderの注文管理システムにある注文ヘッダーデータに保存されています。 例 通常緊急在庫移動返品 | |||
| エンドツーエンドのサイクルタイム EndToEndCycleTime | 物流注文の最初のアクティビティ(「顧客注文の受領」)から最後のアクティビティ(「納品証明への署名」)までにかかった合計時間です。 | ||
| 説明 この指標は、物流注文のライフサイクル全体にかかる時間を測定します。サプライチェーンプロセス全体の速度と効率を示す重要業績評価指標です。 「エンドツーエンドの注文リードタイム分析」ダッシュボードと「物流注文のエンドツーエンドサイクルタイム」KPIで中心となる指標です。この期間を分析すると、全体に影響する遅延を特定し、プロセスの健全性を大局的に把握できます。注文種別や製品カテゴリなどの属性で内訳を確認すれば、リードタイムが長くなる要因を見つけられます。 重要な理由 サプライチェーン全体の処理速度を測る重要なKPIであり、顧客満足度や運転資本に直接影響します。 入手先 この値はソースシステムに保存されていません。各ケースの最初のイベントと最後のイベントのタイムスタンプの差から算出します。 例 15日4時間22日11時間10日2時間 | |||
| ソースシステム SourceSystem | データの抽出元となるシステムです。この場合はBlue Yonderです。 | ||
| 説明 この属性はプロセスデータの取得元を示します。複数のシステムのデータを組み合わせてプロセス全体を把握する環境では、データの出所を明確にするうえで特に役立ちます。 この分析では値は常に「Blue Yonder」ですが、データガバナンスやコンテキストを把握するための重要なメタデータです。ERPやCRMなど、ほかのシステムを連携する場合にも役立ちます。 重要な理由 データの取得元を示します。データガバナンスや検証、複数の基幹システムにまたがる分析の管理に欠かせません。 入手先 通常、データの取得元を示すため、データの抽出・変換時に追加される固定値です。 例 Blue Yonder TMSBlue Yonder WMSBlue Yonder SCP | |||
| 仕入先の納入予定日 SupplierPromisedDeliveryDate | 特定の発注書について、仕入先が約束した納入日です。 | ||
| 説明 この日付は、原材料や部品を納入する時期についての仕入先の約束を示します。仕入先の信頼性と納期遵守状況を測る基準となります。 この属性は、「仕入先の納期遵守率」KPIの算出に欠かせません。実際の資材受領日(「原材料の受領」イベントのタイムスタンプ)と比較し、仕入先が約束を守ったかどうかを判定します。この分析は、「仕入先の入荷パフォーマンス」ダッシュボードの中心となります。 重要な理由 入荷のパフォーマンスを測る基準となり、仕入先の信頼性と生産スケジュールへの影響を評価できます。 入手先 通常、仕入先から提供された情報や標準リードタイムに基づき、発注書の明細レベルで保存されています。 例 2023-10-102023-10-122023-10-15 | |||
| 最終データ更新 LastDataUpdate | ソースシステムからデータが最後に更新または抽出された時刻を示すタイムスタンプです。 | ||
| 説明 この属性は、データを最後に取得した日時を示します。分析対象のデータがどの時点のものか、次回の更新がいつ頃かを把握するための情報です。 分析するデータが最新かどうかを把握することは重要です。ダッシュボードを正しく読み取り、適時の情報に基づいて判断するのに役立ちます。 重要な理由 データの鮮度に関する重要なコンテキストを示し、プロセス分析がどの時点のデータに基づいているかを把握できるようにします。 入手先 データの抽出、変換、読み込み(ETL)の過程で生成され、追加されるタイムスタンプです。 例 2024-01-15T02:00:00Z2024-01-16T02:00:00Z | |||
| 手戻りフラグ IsRework | 梱包や品質検査の繰り返しなど、注文に手戻りが発生したかどうかを示す計算済みフラグです。 | ||
| 説明 物流注文で「商品のピッキングと梱包」→「品質検査の実施」→「商品のピッキングと梱包」のようなアクティビティの繰り返しが確認された場合、この真偽値フラグはtrueになります。標準的で効率的な流れから外れたケースを特定できます。 この属性は「注文の手戻り率」KPIの算出に使われ、「プロセスバリアントと手戻り分析」ダッシュボードに表示されます。手戻りが発生したケースを特定すると、フルフィルメントプロセスのエラーや非効率の原因を把握し、無駄や業務コストを減らすための改善につなげられます。 重要な理由 手順の繰り返しがあるケースを特定し、プロセスの非効率や品質上の問題を明らかにします。プロセスの安定性向上とコスト削減に向けて、対象を絞った改善に取り組めます。 入手先 Blue Yonderの項目ではありません。プロセスマイニングの分析時に、ケース内で特定のアクティビティが繰り返されるパターンを検出して算出します。 例 truefalse | |||
| 発注書番号 PurchaseOrderNumber | 仕入先から原材料や商品を調達するために作成された発注書の一意の識別番号です。 | ||
| 説明 発注書番号は、物流注文と調達プロセスを関連付けます。「購買依頼の作成」や「発注書の発行」などのアクティビティで作成されます。 この属性を使うと、調達サブプロセスを詳しく分析できます。「仕入先の入荷パフォーマンス」ダッシュボードでは、特定の発注書について、発行から商品の受領までの流れを追跡し、遅延を特定の仕入先や品目と関連付けるために役立ちます。 重要な理由 主要なフルフィルメントプロセスと上流の調達アクティビティを関連付け、仕入先のパフォーマンスや調達サイクルタイムを詳しく分析できます。 入手先 この識別番号は、Blue Yonderの調達または購買モジュール、あるいは連携するERPシステムで生成・保存されます。 例 PO45000123PO45000124PO45000125 | |||
| 納期遵守フラグ IsOnTimeDelivery | 注文が指定された納入日までに納品されたかどうかを示す計算済みフラグです。 | ||
| 説明 「実際の納入日」と「指定納入日」を比較して算出する真偽値属性です。各注文を「納期遵守」(true)または「遅延」(false)に分類するため、パフォーマンスを簡単に分析できます。 この属性は「納期遵守パフォーマンス」ダッシュボードに直接反映され、「納期遵守率」KPIの算出にも使われます。絞り込みや根本原因の分析をすばやく行い、運送会社や製品の種類など、納期遅延に関係する要因を把握できます。 重要な理由 各注文の納期遵守状況を真偽値で明確に示すため、納期遵守率の算出や遅延要因の特定が容易になります。 入手先 この属性はソースシステムにはありません。データ変換時に、次の式を使って算出します:ActualDeliveryDate <= RequestedDeliveryDate。 例 truefalse | |||
| 終了時刻 EndTime | アクティビティが完了した時刻を示すタイムスタンプです。 | ||
| 説明 終了時刻はアクティビティの完了を示します。開始時刻と終了時刻の両方があれば、アクティビティの正確な処理時間を算出し、稼働していない時間や待ち時間と区別できます。 「商品のピッキングと梱包」や「品質検査の実施」など、特定のタスクにかかる時間を分析する際に役立ちます。時間を要しているアクティビティを特定し、対象を絞った改善や自動化の検討につなげられます。 重要な理由 アクティビティの処理時間を正確に算出できるため、非効率なタスクの特定やリソースの生産性測定に役立ちます。 入手先 開始時刻と同様、通常はBlue Yonderの各業務オブジェクトに関するトランザクションデータテーブルにタイムスタンプとして記録され、ステータスの完了を示す場合もあります。 例 2023-10-26T09:05:14Z2023-10-26T14:45:00Z2023-10-27T11:18:30Z | |||
| 製品カテゴリ ProductCategory | 電子機器や衣料品など、物流注文に含まれる製品のカテゴリです。 | ||
| 説明 製品カテゴリは、類似する製品をまとめるための分類です。カテゴリによって、サプライチェーンのプロセス、取り扱い要件、リードタイムが異なる場合があります。 「物流注文の処理量推移」ダッシュボードでは、この属性を使って製品の種類ごとに完了した注文数を絞り込み、比較できます。特定の製品ラインで遅延が多い、または処理量が少ないといった傾向を把握し、改善が必要な領域に取り組みを集中できます。 重要な理由 製品の種類ごとにプロセスを分析し、カテゴリ固有のボトルネック、需要の傾向、取り扱いの複雑さを把握できます。 入手先 Blue Yonderの品目または製品マスターデータに含まれ、物流注文の明細に関連付けられています。 例 家電製品産業機械衣料品食料品 | |||
| 購買依頼の作成者 PurchaseRequisitionCreator | 商品や資材の購入を依頼したユーザーまたは部門です。 | ||
| 説明 この属性は、購買依頼を作成した担当者またはチームを示します。購買依頼は、正式な発注書の作成につながる社内文書です。組織内で誰が調達需要を生み出しているかを把握する手がかりになります。 この属性で分析すると、社内の調達パターンを把握できます。「手作業と自動化の可能性」ダッシュボードでの分析にも利用できます。少数のユーザーが標準的な購買依頼を大量に作成している場合、依頼プロセスを自動化できる可能性があります。 重要な理由 調達依頼の発生元を特定し、社内の需要パターンの分析やプロセス自動化の機会の特定に役立ちます。 入手先 購買依頼の文書データにあり、通常は「作成者」項目として記録されています。 例 m.jonesp.chen計画部門 | |||
| 輸送手段 ModeOfTransport | トラック、航空、海上など、出荷に使用する輸送手段です。 | ||
| 説明 この属性は、商品の輸送に使用する手段を示します。輸送手段によってコスト、速度、輸送能力が異なるため、物流の計画や分析において重要な要素です。 「輸送効率モニター」ダッシュボードでは、この属性を使って輸送手段ごとの所要時間とコストを比較できます。注文の優先度やコストの制約に応じて、速いものの費用が高い航空輸送と、時間はかかるものの費用を抑えられる海上輸送のどちらを選ぶかなど、戦略的な判断に役立ちます。 重要な理由 輸送コストと速度を分析するための重要な切り口となり、効果的な出荷方法の選定に役立ちます。 入手先 通常、この情報はBlue YonderのTMSにある出荷または貨物注文の詳細に保存されています。 例 トラック貸切輸送(FTL)航空貨物輸送海上貨物輸送鉄道輸送 | |||
| 運送会社名 CarrierName | 商品の輸送を担当する運送会社の名称です。 | ||
| 説明 運送会社名は、倉庫から最終目的地まで商品を輸送した物流パートナーを示します。出荷物流のパフォーマンスを評価するうえで重要な属性です。 「輸送効率モニター」ダッシュボードでは、運送会社名ごとにデータを分析し、各社の「輸送中」の期間を比較できます。これにより、最も速く、信頼性が高い、または費用対効果に優れた輸送パートナーを特定し、結果に応じて出荷戦略を見直せます。 重要な理由 運送会社ごとのパフォーマンスを比較し、出荷コスト、ルート、納期の最適化に役立てられます。 入手先 通常、Blue Yonderの輸送管理システム(TMS)にある出荷伝票または貨物注文書に記載されています。 例 エクスプレス貨物輸送ナショナル・ロジスティクススウィフト運送 | |||
| 顧客名 CustomerName | 注文を行った顧客の名称です。 | ||
| 説明 物流注文の最終顧客を示します。顧客の視点から分析を分類するための基本的な属性です。 顧客ごとにプロセスのパフォーマンスを分析すると、リードタイムが長い顧客や問題が多い顧客を特定できます。「納期遵守パフォーマンス」などのダッシュボードで顧客別に内訳を確認し、重要顧客への改善を優先できます。 重要な理由 顧客ごとの分析を可能にし、プロセスの非効率による影響が大きい顧客を特定して、サービス改善の優先順位を決めるのに役立ちます。 入手先 この情報は顧客注文のヘッダーデータに保存され、Blue Yonderまたは連携するCRM/ERPの顧客マスターテーブルから参照されます。 例 リテール社メガストア社ダイレクト・コンシューマー・グッズ | |||
サプライチェーン管理のアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
| 原材料の受領 | 倉庫または生産施設でサプライヤーから商品を物理的に受け取ったことを示すアクティビティです。入荷品のスキャンなどをきっかけに行われる入庫トランザクションを通じて、明示的に記録されます。 | ||
| 重要な理由 このイベントは、サプライヤーからの納品工程の終了を示します。サプライヤーの信頼性や入荷物流の効率を測定するうえで欠かせません。 入手先 倉庫管理システム(WMS)または在庫管理モジュールのトランザクションログから取得します。入庫文書の転記日時に該当します。 記録 入庫転記のトランザクションタイムスタンプに基づきます。 イベントタイプ explicit | |||
| 商品のピッキングと梱包 | 倉庫で保管場所から商品をピッキングし、出荷用に梱包する作業を指します。WMSで倉庫担当者がRFスキャナーを使って記録する明示的なイベントであることが多いです。 | ||
| 重要な理由 出荷物流における重要な節目です。所要時間を分析すると、倉庫業務の非効率な点を特定でき、在庫から出荷までのサイクルタイムの算出にも役立ちます。 入手先 Blue YonderのWMSトランザクションログに明示的に記録されます。倉庫担当者がピッキングと梱包の完了を確認した時点で、タイムスタンプが記録されます。 記録 受注に対する最後のピッキングまたは梱包作業が確認された時点で、イベントのタイムスタンプが記録されます。 イベントタイプ explicit | |||
| 発注書の発行 | 原材料または完成品を外部サプライヤーに正式に発注し、発注書を作成して送付したことを示します。Blue Yonderの購買機能における主要な明示的イベントです。 | ||
| 重要な理由 サプライヤーのリードタイムと実績を追跡するうえで重要な節目です。サプライヤー納期遵守の重要業績評価指標(KPI)の起点となります。 入手先 購買システムのテーブルに明示的なイベントとして記録され、発注書の作成時または正式な発行時のタイムスタンプが含まれます。 記録 発注書文書の作成または発行のタイムスタンプに該当します。 イベントタイプ explicit | |||
| 納品受領の署名 | 顧客が納品を受領したことを確認する最後のアクティビティです。通常、納品書への署名によって確認します。ステータス更新として記録され、担当ドライバーが手入力する場合と、モバイルアプリを通じて記録する場合があります。 | ||
| 重要な理由 物流プロセス全体の終了イベントとして、最も信頼性の高い指標です。サイクルタイム全体と納期遵守率の算出に欠かせません。 入手先 TMSまたはOMSの納品文書または出荷文書にあるステータス更新から推定します。「POD受領済み」または「納品済み」に変わった時刻を使用します。 記録 納品確認を示す出荷文書のステータス変更から算出します。 イベントタイプ inferred | |||
| 製品の生産完了 | 物流受注に関連する製造プロセスの完了を示すイベントです。製造指図のステータスが「完了」または「終了」に変わったことから推定される場合があります。 | ||
| 重要な理由 生産サイクル時間の測定に欠かせない節目です。また、生産から出荷までのリードタイムを測る重要業績評価指標(KPI)の起点となり、商品が次の受注対応段階に進める状態になったことを示します。 入手先 製造指図テーブルのステータス変更(「完了」への更新など)から推定します。最終ステータスの更新に関連するタイムスタンプをイベント時刻として使用します。 記録 生産指図のステータスが最終的な「完了」状態に変わった時刻を特定します。 イベントタイプ inferred | |||
| 輸送車両への商品の積み込み | 梱包済みの商品が輸送車両に積み込まれ、倉庫を出発した時点を示します。重要な明示的イベントであり、WMSまたはTMSの「出庫」トランザクションとして記録されることがよくあります。 | ||
| 重要な理由 輸送サイクル時間と輸送全体の効率を測定する起点となるイベントです。倉庫内の業務から外部の運送業者へ引き渡されたことを示します。 入手先 WMSまたはERPシステムに出庫転記として明示的に記録されます。このトランザクションの転記日時をイベントのタイムスタンプとして使用します。 記録 納品に関連する出庫トランザクションログからイベントを取得します。 イベントタイプ explicit | |||
| 顧客からの受注 | 顧客からの依頼を受け、システムに新しい物流受注が作成されたことを示すアクティビティです。通常、ユーザーまたはEDIメッセージによってBlue Yonderの受注管理モジュールに販売受注文書が作成された時点で、明示的に記録されます。 | ||
| 重要な理由 これは、サプライチェーン全体のプロセスにおける主な開始イベントです。このアクティビティを分析すると、受注件数と受注から納品までの全体的なリードタイムを測定できます。 入手先 販売受注の作成時に、受注管理システムのテーブルに明示的に記録されます。受注ヘッダーレコードの作成日時に該当します。 記録 販売受注の作成時(トランザクションのコミット時など)に記録されます。 イベントタイプ explicit | |||
| 出荷スケジュールの設定 | 運送業者の選定や集荷時間枠の予約など、輸送の計画を示すアクティビティです。Blue Yonderの輸送管理システム(TMS)では、出荷が作成され、確定された時点で明示的なイベントとして記録されます。 | ||
| 重要な理由 輸送計画の段階を把握できます。この段階での遅延は、予定どおりの出発や納品実績全体に影響する可能性があります。 入手先 TMSモジュールのトランザクションログから取得します。出荷文書の確定時または運送業者の割り当て時のタイムスタンプに該当します。 記録 出荷または積載計画の作成または確認のタイムスタンプに基づきます。 イベントタイプ explicit | |||
| 受注のキャンセル | 受注対応が完了する前に物流受注がキャンセルされたことを示します。販売受注の最終ステータスが「キャンセル」または「無効」になったことから推定する、もう1つの終了イベントです。 | ||
| 重要な理由 キャンセルを追跡すると、プロセスからの離脱や顧客の不満を把握できます。受注がキャンセルされた時期と理由を分析することで、営業や業務に潜む問題が明らかになる場合があります。 入手先 販売受注ヘッダーのステータスから推定します。最終状態の「キャンセル」に変わった時刻をイベント時刻として記録します。 記録 受注のステータスが「キャンセル」に変わったタイムスタンプに基づきます。 イベントタイプ inferred | |||
| 品質検査の実施 | 出荷可能になる前に完成品の品質検査が完了したことを示します。在庫ロットまたはバッチのステータスが「制限なし」や「検査合格」に変わったことから推定できます。 | ||
| 重要な理由 品質保証プロセスのボトルネックを特定し、手戻りを分析するのに役立ちます。同じ受注に対して品質検査が繰り返されている場合、品質上の問題が考えられます。 入手先 在庫管理モジュールまたは品質管理モジュールのステータス変更から推定します。「検査中」から「リリース済み」への変更時刻を使用します。 記録 関連する在庫バッチまたはロットの品質ステータスの変更から算出します。 イベントタイプ inferred | |||
| 在庫の引当可能性を確認 | 顧客の受注を満たすために必要な商品が在庫にあるかを、システムまたは担当者が確認するアクティビティです。受注行のステータス変更から推定されることが多く、引当可能在庫(ATP)の確認に合格したことを示します。 | ||
| 重要な理由 受注確認までの時間を測定し、欠品による遅延を特定するのに役立ちます。在庫引当可能率の重要業績評価指標(KPI)の算出や、受注対応力の把握にも欠かせません。 入手先 販売受注行のステータス変更(「新規」から「確認済み」など)、またはBlue Yonderの在庫管理モジュールや受注管理モジュールにあるATP確認ログのタイムスタンプから推定します。 記録 在庫が確認されたことを示す受注行のステータス変更から算出します。 イベントタイプ inferred | |||
| 生産計画の確定 | 必要な商品を製造するための生産指図または製造指図を計画し、スケジュールを設定するアクティビティです。通常、Blue Yonderの製造モジュールまたは供給計画モジュールで明示的なイベントとして生成されます。 | ||
| 重要な理由 製造サイクルの開始を把握できます。スケジュール設定から生産完了までの時間を分析すると、計画と実行のずれを特定できます。 入手先 製造実行システムまたは計画システムのテーブルに記録され、生産指図の作成または確認に関連するタイムスタンプが含まれます。 記録 製造指図の作成またはステータス変更のタイムスタンプから算出します。 イベントタイプ explicit | |||
| 納品先での荷下ろし | 出荷品が顧客の所在地に到着し、荷下ろしされたことを示すアクティビティです。運送業者からのEDIメッセージ、または運送業者からの情報に基づく手入力で明示的に記録されることがよくあります。 | ||
| 重要な理由 輸送中の工程の終了を示します。輸送サイクル時間を正確に算出し、運送業者に起因する遅延を特定するうえで欠かせません。 入手先 通常、EDI連携または運送業者のポータルを通じて外部の運送業者データから取得し、TMSの出荷文書にステータス更新として記録します。 記録 運送業者から「納品済み」のステータス更新があった時刻をイベント時刻として使用します。 イベントタイプ explicit | |||
| 購買依頼の作成 | 受注に必要な在庫が不足している場合に、必要な資材を調達するための依頼が発生します。購買モジュールでは、購買依頼文書の作成が明示的なイベントとして記録されます。 | ||
| 重要な理由 このアクティビティを追跡すると、調達への依存度と、受注対応全体にかかる時間への影響を把握できます。在庫不足によってサプライチェーンに遅延が生じているケースも明らかになります。 入手先 購買依頼文書が作成され、販売受注の需要に関連付けられた時点で、購買または供給計画のテーブルに明示的に記録されます。 記録 購買依頼文書の作成タイムスタンプに基づきます。 イベントタイプ explicit | |||
| 顧客への請求書送付 | 納品した商品について顧客向けの請求書を作成し、発行したことを示します。受注管理モジュールまたは財務モジュールに記録される明示的な財務トランザクションです。 | ||
| 重要な理由 受注から入金までのプロセスにおける重要なステップです。納品との時間差を分析すると、キャッシュフローに影響する請求処理の遅れを特定できます。 入手先 請求または財務のテーブルに明示的に記録されます。請求書文書の作成日または転記日に該当します。 記録 顧客向け請求文書の転記タイムスタンプに基づきます。 イベントタイプ explicit | |||
データ抽出ガイド
このプロセスのデータ抽出方法は現在検証中です。後ほど再度ご確認いただくか、 お問い合わせ ください。
利用を始めませんか?
これらのテンプレートを使って、サプライチェーン管理の改善に取り組みましょう。見えにくい非効率を明らかにし、業務の改善につなげられます。
遅延を防ぐ:Blue Yonderのサプライチェーンを今すぐ最適化
予測精度90%を達成し、コストのかかる欠品をなくしましょう。
クレジットカード不要。数分で設定できます。