サプライチェーン管理データテンプレート
サプライチェーン管理データテンプレート
- 詳細な分析のために収集する推奨属性
- プロセス全体で追跡すべきサプライチェーンの主要アクティビティ
- Microsoft Dynamics 365 SCMからデータを抽出するための手順
サプライチェーン管理の属性
| 名前 | 説明 | ||
|---|---|---|---|
|
物流注文
LogisticsOrder
|
特定のサプライチェーン受注処理依頼を識別する一意の識別子であり、主要なケース識別子として機能します。 | ||
|
説明
Logistics Orderは物流プロセス全体を識別する一意の識別子です。顧客の需要から最終配送までのすべてのアクティビティを結び付けます。この属性は、特定の受注処理依頼に関する調達、生産、出荷などの各サブプロセスをつなぐ中心的な軸となります。 分析では、すべてのイベントがLogistics Orderに関連付けられるため、プロセスフロー全体をエンドツーエンドで再構成できます。これにより、部門やシステムをまたぐ注文の進捗を追跡し、ボトルネックを特定し、開始から完了までのサイクルタイム全体を正確に測定できます。
重要な理由
関連するすべてのプロセスイベントを結び付けるための必須キーです。単一の受注処理依頼について、サプライチェーンプロセスをエンドツーエンドで分析できます。
入手先
概念上の識別子です。SalesTable(販売注文)、WHSLoadTable(積荷ID)、InventTransOrigin(参照ID)などのテーブルのフィールドを組み合わせ、複数のモジュールにまたがる一意のケースIDを作成すると考えられます。
例
LO-2024-00123LO-2024-00124LO-2024-00125
|
|||
|
アクティビティ
ActivityName
|
物流プロセスのある時点で発生した業務イベントまたは作業の名称です。 | ||
|
説明
「Purchase Order Issued」、「Goods Produced」、「Shipment Scheduled」など、発生した具体的な業務イベントまたは作業を記録する属性です。これらのアクティビティがプロセスの基本単位となります。 これらのアクティビティの順序、頻度、所要時間を分析することが、プロセスマイニングの中心となります。プロセスマップの自動検出と可視化、標準手順からの逸脱の検出、改善の余地が大きい頻出または非効率なプロセス手順の特定が可能になります。
重要な理由
プロセスの各ステップを定義し、プロセスフローの可視化、変動の分析、ボトルネックやコンプライアンスに反するアクティビティの特定を可能にします。
入手先
SalesTable、PurchTable、ProdTableなどの各種取引テーブルにおけるステータス変更や、CustInvoiceJourなどのテーブルに記録された文書転記日を基に、業務ロジックから導出されます。
例
購買発注の発行製品の生産完了顧客請求書の転記商品の配送完了
|
|||
|
イベント時刻
EventTime
|
アクティビティが発生した日時を示すタイムスタンプです。 | ||
|
説明
システムにアクティビティが記録された正確な日時を示す属性です。サイクルタイムの計算、プロセスパフォーマンスの把握、ボトルネックの特定など、時間に基づくプロセス分析の基礎となります。 このタイムスタンプに基づいてイベントを時系列に並べることで、プロセスマイニングツールは実際に発生したアクティビティの正確な順序を再構成できます。理想化されたプロセスモデルではなく、実際のプロセスフローとその動きを把握するために欠かせません。
重要な理由
このタイムスタンプは、イベントを正しい順序に並べ、サイクルタイムやリードタイムなど、時間に基づくすべての指標を計算するうえで重要です。
入手先
通常は、D365 SCMのテーブルにある作成日時フィールドまたはステータス変更日時フィールドから取得します。例として、SalesTableのCreatedDateTime、PurchLineのDeliveryDate、InventTransの物理取引日などがあります。
例
2023-04-15T09:00:00Z2023-04-18T14:30:00Z2023-05-01T11:22:00Z
|
|||
|
ソースシステム
SourceSystem
|
イベントデータを抽出した記録元のシステムです。 | ||
|
説明
データの発生元となるシステムまたはモジュールを識別する属性です。複雑なサプライチェーン環境では、Sales、Procurement、Warehouse Managementなど、Dynamics 365 SCM内の複数のモジュールからデータが取得される場合があります。 ソースシステムを指定することは、データガバナンス、データの不整合の調査、記録されたアクティビティの背景の把握に欠かせません。データ品質を確保し、情報の発生元まで追跡できるようにします。統合環境では特に重要です。
重要な理由
データの発生元に関する背景を示します。データ検証、問題の調査、システム境界をまたぐプロセスの変動を理解するうえで欠かせません。
入手先
通常は、データ抽出時にこのシステム固有のレコードであることを示す静的な値として追加されます。
例
Microsoft Dynamics 365 SCMD365-PRODAX2012-FIN
|
|||
|
最終データ更新日時
LastDataUpdate
|
ソースシステムからデータが最後に更新された日時を示すタイムスタンプです。 | ||
|
説明
データが最後に抽出または更新された日時を示す属性です。プロセス分析ダッシュボードにとって重要なメタデータです。 分析対象データの新しさを把握できるため、最新の情報に基づいて結論を導けます。また、データパイプラインの管理や、データの読み込み処理が予定どおり実行されていることの確認にも役立ちます。
重要な理由
データの鮮度を把握できるため、分析に基づいて適時かつ適切な業務判断を行ううえで重要です。
入手先
通常は、データ抽出ツールまたはETLツールが各更新サイクルの終了時にデータセットへ値を付与し、タイムスタンプを記録します。
例
2023-06-10T02:00:00Z2023-06-11T02:00:00Z2023-06-12T02:00:00Z
|
|||
|
ユーザーID
UserId
|
アクティビティを実行したユーザーの識別子です。 | ||
|
説明
特定のアクティビティを実行した従業員またはシステムユーザーのIDを保存する属性です。購買発注を作成した購買担当者や、出荷を確認した倉庫作業員などが該当します。 ユーザー別にアクティビティを分析することで、業務量の分布を把握し、トレーニングの必要性を特定し、プロセスの逸脱を調査できます。また、監査担当者が操作を特定の個人まで追跡できるため、コンプライアンス分析にも欠かせません。パフォーマンス管理とリソースの最適化にも役立ちます。
重要な理由
ユーザーまたはチーム別にプロセスパフォーマンスを分析し、自動化の機会を特定できます。コンプライアンスや監査証跡の分析にも欠かせません。
入手先
D365 SCMの多くの取引テーブルにある「Created by」または「Modified by」フィールドから取得します。SalesTableやPurchTableのCreatedByなどが該当します。
例
j.doea.smithAX_BATCH_USER
|
|||
|
仕入先名
SupplierName
|
原材料または商品を提供する仕入先の名前です。 | ||
|
説明
この属性には、資材の調達元である仕入先の名前が含まれます。調達関連のアクティビティを分析するための重要な切り口です。 Procurement Lead Time BreakdownダッシュボードとSupplier Performance Benchmarkingダッシュボードで幅広く使用されます。仕入先別にプロセス指標を分析すると、信頼性と効率性が高いパートナーだけでなく、遅延や混乱を頻繁に引き起こすパートナーも特定できます。この情報は、戦略的な調達先の選定と仕入先との関係管理に欠かせません。
重要な理由
仕入先別に調達パフォーマンスを分類して比較できます。仕入先との関係を改善し、資材のリードタイムを短縮するうえで重要です。
入手先
発注書テーブル(PurchTable)と仕入先マスターテーブル(VendTable)を、仕入先勘定番号で結合して取得します。
例
Contoso Raw MaterialsFabrikam Inc.Northwind Traders
|
|||
|
希望納品日
RequestedDeliveryDate
|
顧客が希望した納品日です。 | ||
|
説明
この属性には、顧客が注文時に指定した納品日が記録されます。実際の納品パフォーマンスを測定する際の基準日です。 この日付は、On-Time Delivery Performance MonitorダッシュボードとOn-Time Delivery Rate KPIの基礎となります。希望納品日と実際の納品日を比較する方法は、納品パフォーマンスを算出する標準的な手法であり、顧客満足度を測る重要な指標です。
重要な理由
納期どおりの納品パフォーマンスを測定する基準であり、顧客満足度とサプライチェーンの信頼性に関わる重要なKPIです。
入手先
SalesLineテーブルのReceiptDateRequestedフィールド、またはSalesTableのShippingDateRequestedフィールドにあります。
例
2023-05-102023-06-012023-07-20
|
|||
|
納期遵守
IsOnTimeDelivery
|
注文が希望納品日までに納品されたかどうかを示すフラグです。 | ||
|
説明
物流注文が納期どおりに納品されたかどうかを示す、計算による真偽値の属性です。「Goods Delivered」アクティビティのタイムスタンプと「Requested Delivery Date」を比較して算出します。 この属性は、On-Time Delivery Rate KPIの算出基盤であり、On-Time Delivery Performance Monitorダッシュボードの主要なフィルターです。日付の比較結果をtrueまたはfalseの値に変換するため、遅延注文を簡単に抽出して件数を集計できます。
重要な理由
顧客サービスのパフォーマンスを直接測定し、On-Time Delivery KPIの主要な入力値となります。納品の信頼性を簡単に分析できます。
入手先
計算フィールドです。ロジックは次のとおりです:IF(「Goods Delivered」のタイムスタンプ <= 「Requested Delivery Date」)THEN True ELSE False。
例
truefalse
|
|||
|
製造オーダー番号
ProductionOrderNumber
|
生産または製造オーダーを識別する一意の識別子です。 | ||
|
説明
製造施設で特定の製品を指定数量生産するためのオーダーを識別する番号です。原材料の消費量と完成品の生産量を追跡します。 製造を行う企業にとって、このIDは生産プロセスの追跡に欠かせません。Production Schedule Adherence Trackerダッシュボードでは、計画生産日と実際の完了日を結び付け、製造プロセスにおける差異や遅延を明らかにします。
重要な理由
製造ライフサイクルを詳細に分析し、生産スケジュールの遵守状況を測定するとともに、製造現場のボトルネックを特定できます。
入手先
ProdTableテーブルのProdIdフィールドにあります。
例
PRD-000112PRD-000113PRD-000114
|
|||
|
販売注文番号
SalesOrderNumber
|
顧客の販売注文を識別する一意の識別子です。 | ||
|
説明
顧客からの商品またはサービスの依頼を示す主要な参照番号です。販売注文を起点として、調達や生産など、多くのサプライチェーン活動が開始されます。 プロセスマイニングでは、Sales Order Numberがフィルタリングと分析における重要なディメンションとなります。特定の顧客注文について、受注処理全体を追跡できます。また、概念上のLogistics OrderケースIDを構成する主要な要素となることもあります。
重要な理由
サプライチェーンプロセスを顧客需要に直接結び付け、受注から入金までのサイクルと顧客別の受注処理パフォーマンスを分析できます。
入手先
SalesTableテーブルのSalesIdフィールドにあります。
例
SO-001872SO-001873SO-001874
|
|||
|
購買発注番号
PurchaseOrderNumber
|
仕入先へ送付した購買発注を識別する一意の識別子です。 | ||
|
説明
外部の仕入先から原材料や商品を注文する際に使用する正式な文書番号です。品目、数量、価格、納期などの情報が含まれます。 Purchase Order Number別にプロセスを分析することは、Procurement Lead Time BreakdownダッシュボードやSupplier Performance Benchmarkingダッシュボードにとって欠かせません。購買依頼から仕入先への支払いまで、調達から支払いまでのサイクル全体を追跡し、資材調達の遅延を特定できます。
重要な理由
調達部分の分析、仕入先のパフォーマンス監視、資材のリードタイム把握に欠かせないIDです。
入手先
PurchTableテーブルのPurchIdフィールドにあります。
例
PO-000541PO-000542PO-000543
|
|||
|
顧客名
CustomerName
|
販売注文を登録した顧客の名前です。 | ||
|
説明
この属性は、販売注文に関連付けられた顧客を特定します。サプライチェーンプロセスを顧客中心に把握できます。 顧客別に物流プロセスを分析すると、特定の顧客に固有の出荷パターン、要望、課題を明らかにできます。主要顧客の管理やサービスレベルの調整に特に役立ち、顧客満足度と継続率の向上につながります。
重要な理由
顧客中心の分析が可能になり、遅延が最も多い顧客の特定や、主要顧客へのサービスレベルの評価に役立ちます。
入手先
販売注文テーブル(SalesTable)と顧客マスターテーブル(CustTable)を、顧客勘定番号で結合して取得します。
例
Alpine Ski HouseAdventure WorksCity Power & Light
|
|||
|
倉庫ID
WarehouseId
|
商品を保管または取り扱う倉庫の識別子です。 | ||
|
説明
この属性は、ピッキング、梱包、出荷などのアクティビティに関わる特定の倉庫または配送センターを識別します。 Warehouse Operations Throughputダッシュボードに欠かせない属性で、施設間のパフォーマンスを比較できます。倉庫別に分析すると、効率が最も高い拠点、処理能力に課題がある拠点、早急に業務改善が必要な拠点を特定できます。
重要な理由
異なる物理拠点間でパフォーマンスを比較し、ボトルネックを分析できます。倉庫業務の効率改善を支援します。
入手先
InventSumやWHSWorkTableなど、在庫管理および倉庫管理に関連するテーブルのInventLocationIdフィールドにあります。
例
WH-MainWH-EastDC-West
|
|||
|
出荷予定日
ScheduledShipmentDate
|
出荷が予定されていた日付です。 | ||
|
説明
この属性は、倉庫または製造施設から出荷する予定日を表します。フルフィルメントプロセスにおける重要な社内マイルストーンです。 この日付は、Shipment Schedule Adherence Rate KPIの算出に使用されます。予定日と「Goods Loaded For Transport」アクティビティの実績日を比較することで、社内物流の計画と実行の信頼性および予測可能性を測定できます。
重要な理由
社内スケジュールの遵守状況と出荷プロセスの予測可能性を測定できます。下流の輸送計画にも影響します。
入手先
SalesLineのConfirmedShipDateなどのフィールド、または計画済み積荷に関するWHSLoadTableの関連フィールドにあります。
例
2023-05-082023-05-302023-07-18
|
|||
|
手戻り
IsRework
|
アクティビティまたはプロセスループが手戻りに該当するかどうかを示すフラグです。 | ||
|
説明
手戻りや修正ループに該当するアクティビティまたはプロセス経路を特定する、計算による真偽値の属性です。たとえば、「Quality Control Performed」アクティビティが失敗し、前段の「Goods Produced」ステップに戻る場合、手戻りとしてフラグが付けられます。 この属性は、Order Fulfillment Rework Rate KPIの算出に欠かせません。手戻りにフラグを付けることで、品質問題やプロセスエラーの頻度と影響を簡単に定量化し、改善や管理が必要な領域を特定できます。
重要な理由
「標準経路」に含まれないアクティビティを明示的に特定し、プロセスの非効率や品質問題を定量化できます。
入手先
計算フィールドであり、通常はビジネスルールから算出します。たとえば、「Repack Goods」など特定のアクティビティ名を手戻りとしてフラグ付けしたり、プロセスフローの逆戻りループを特定したりします。
例
truefalse
|
|||
|
注文金額
OrderValue
|
販売注文の合計金額です。 | ||
|
説明
この属性は、顧客の販売注文の合計金額を表します。プロセスパフォーマンスが事業に与える影響を把握するための重要な指標です。 注文金額を考慮してサイクルタイムや納品遅延などのプロセス指標を分析すると、改善施策の優先順位を付けられます。たとえば、高額注文に影響する遅延は、少額注文の遅延よりも優先して対応すべき場合があります。プロセス分析に金額の観点を加えられます。
重要な理由
プロセス分析に金額の観点を加え、金銭的な影響に基づいて問題への対応優先度を決められます。
入手先
SalesLineテーブルで、特定の販売注文(SalesId)に属するすべての明細のLineAmountフィールドを合計して算出します。
例
15200.50850.00125000.75
|
|||
|
製品カテゴリー
ProductCategory
|
製品が属するカテゴリーです。 | ||
|
説明
この属性は、個々の製品を「Electronics」、「Raw Materials」、「Finished Goods」などの大きなカテゴリーにまとめます。これにより、サプライチェーンをより上位の視点で分析できます。 数千に及ぶ個別SKUを一つずつ確認する代わりに、製品カテゴリーを使って、製品群全体に影響する傾向やボトルネックを特定できます。異なる種類の資材における仕入先パフォーマンスを把握するうえで、Procurement Lead Time Breakdownダッシュボードに特に役立ちます。
重要な理由
製品グループ全体を集計して分析できます。戦略的な意思決定や、特定の製品タイプに影響する構造的な問題の特定に役立ちます。
入手先
品目マスターテーブル(InventTable)と、EcoResProductCategoryなどの製品カテゴリー関連テーブルを結合して取得します。
例
Audio ComponentsPackaging MaterialsHydraulic Parts
|
|||
|
製品番号
ProductNumber
|
注文または生産する製品を一意に識別する番号です。 | ||
|
説明
この属性は、取引対象となる製品の在庫管理単位(SKU)または品目番号です。顧客に販売する完成品の場合もあれば、仕入先から購入する原材料の場合もあります。 製品別にサプライチェーンプロセスを分析すると、リードタイムが長い品目、品質問題が頻発する品目、複雑な生産経路を持つ品目を特定できます。この情報は、在庫管理、需要予測、製品ポートフォリオの最適化に欠かせません。
重要な理由
製品ごとのプロセスパフォーマンスを分析でき、特定の品目に固有のサプライチェーン上の課題を明らかにできます。
入手先
SalesLine、PurchLine、ProdBOMなどの取引明細テーブルにあるItemIdフィールドにあります。
例
A0001D0010M9201
|
|||
|
輸送手段
ModeOfTransport
|
トラック、航空、海上輸送など、出荷に使用する輸送方法です。 | ||
|
説明
この属性は、出荷元から配送先まで商品を運ぶ輸送方法を指定します。道路、鉄道、航空、海上輸送などがあります。 Transportation Efficiency & Costsダッシュボードの重要な分析軸です。輸送手段別にサイクルタイムとコストを分析すると、速度とコストのバランスを考慮した物流戦略の最適化や、特定の輸送経路における非効率の特定が可能になります。
重要な理由
輸送コストと効率の分析に欠かせません。物流ネットワークの最適化と運賃の削減に役立ちます。
入手先
SalesTableやPurchTableのModeOfDeliveryフィールドにあります。さらに詳細な情報は、TMSRouteなどの輸送管理テーブルにあります。
例
トラック航空輸送海上輸送鉄道輸送
|
|||
|
運送会社名
CarrierName
|
出荷を担当する輸送会社または運送業者の名前です。 | ||
|
説明
この属性は、商品の輸送を担当する第三者物流事業者または社内車両を識別します。商品を実際に輸送する会社を示します。 運送業者は、Transportation Efficiency & Costsダッシュボードにおけるもう一つの重要な分析軸です。運送業者別に輸送時間や納期遵守率などのパフォーマンス指標を分析すると、物流パートナーを比較し、より有利な料金を交渉し、運送業者の選定について適切な判断ができます。
重要な理由
物流パートナーごとのパフォーマンスを分析できます。運送業者の管理と輸送コストの最適化に欠かせません。
入手先
販売注文のCarrierServiceなどのフィールド、またはTMSCarrierなどの専用輸送管理テーブルにあります。
例
FedExUPSMaerskDHL
|
|||
サプライチェーン管理のアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
|
原材料の入荷
|
仕入先から注文した商品または資材が倉庫に物理的に到着したことを示します。Dynamics 365で購買発注に対して製品入荷の転記取引を行うことで記録されます。 | ||
|
重要な理由
このアクティビティは、仕入先リードタイムの終了と、生産または受注処理に資材を利用できる状態になったことを示します。ここでの遅延は、後続のスケジュールや顧客への納期に直接影響します。
入手先
Procurement and sourcingモジュールまたはInventory managementモジュールに記録されます。製品入荷(VendPackingSlipJour)を転記すると、タイムスタンプ付きの取引レコードが作成されます。
取得
購買発注に対して製品入荷が転記された際に記録されるイベントです。
イベントタイプ
explicit
|
|||
|
商品のピッキングと梱包
|
倉庫作業員が在庫から商品を物理的にピッキングし、出荷用に梱包したことを示します。ピッキング作業が完了し、システム上で梱包ステータスが更新された際に記録されます。 | ||
|
重要な理由
倉庫での主要な受注処理作業が完了したことを示します。Warehouse Operations Throughputダッシュボードの主要な指標であり、ピッキングと梱包のプロセスにおけるボトルネックの特定にも役立ちます。
入手先
Warehouse managementモジュールに記録されます。通常は、倉庫作業(WHSWorkTable)のステータスが「Closed」に変わったこと、または梱包明細を転記したことから推定します。
取得
倉庫作業のステータスが「Closed」に変わったこと、または梱包明細の転記日から推定します。
イベントタイプ
inferred
|
|||
|
商品の配送完了
|
商品が顧客の届け先に到着したことを示します。Dynamics 365には標準の「delivered」取引がないため、運送会社の追跡データまたは手動のステータス更新から推定する場合があります。 | ||
|
重要な理由
物理的な配送の完了を示します。納期遵守率のKPIや顧客向け指標の計算に欠かせない「Actual Delivery Date」を提供します。
入手先
通常、標準フィールドとしては存在しません。販売注文または出荷のカスタム日付フィールドに記録し、手動または運送会社システムとの連携によって更新する場合があります。
取得
配送日フィールドの手動更新、または外部運送会社APIとの連携から推定します。
イベントタイプ
inferred
|
|||
|
納品確認書への署名
|
顧客が商品の受領を正式に確認したことを示します。通常は納品書への署名、文書の添付、またはシステム上のステータス更新によって記録されます。 | ||
|
重要な理由
注文処理が正常に完了したことを示す最終確認であり、物流プロセスの明確な終了点です。紛争の解決や注文サイクル全体の所要時間の計算に欠かせません。
入手先
標準的な個別取引ではありません。通常は販売注文のステータスを更新するか、文書管理機能を使ってスキャンした納品確認書を添付します。
取得
ステータスの更新、または販売注文や出荷へのPOD文書の添付から推定します。
イベントタイプ
inferred
|
|||
|
製品の生産完了
|
製造プロセスが完了し、完成品がシステム上で正式に完成品として報告されたことを示します。製造オーダーに対して「Report as Finished」仕訳を転記することで記録され、在庫が更新されます。 | ||
|
重要な理由
生産段階の完了を示し、品質管理と出荷に向けて製品を利用できる状態にします。生産スケジュールの遵守状況を測定する際の重要なマイルストーンです。
入手先
Production controlモジュールに記録されます。「Report as Finished」仕訳を転記すると、タイムスタンプ付きの在庫取引が作成され、製造オーダーのステータスが更新されます。
取得
製造オーダーに対して「Report as Finished」仕訳が転記された際に記録されます。
イベントタイプ
explicit
|
|||
|
購買発注の発行
|
正式な購買発注が作成・確認され、会社が仕入先からの購入を確定したことを示します。POのステータスが「Confirmed」または「In external review」に更新された際に記録されます。 | ||
|
重要な理由
調達における重要なマイルストーンであり、仕入先リードタイムを測定する際の主な開始点です。このイベントから資材の入荷までの時間を分析することで、仕入先のパフォーマンスを評価できます。
入手先
Procurement and sourcingモジュールに記録されます。購買発注の確認は、PurchTableのステータス変更と日付によって追跡されます。
取得
仕訳処理によって購買発注のステータスが「Confirmed」に更新された際に記録されます。
イベントタイプ
explicit
|
|||
|
輸送用車両への商品の積載
|
梱包済みの商品が運送会社の車両に物理的に積載され、システム上で出荷が確認されたことを示します。Dynamics 365の「Ship confirm」アクションに該当します。 | ||
|
重要な理由
商品が倉庫を出発したことを示します。このアクティビティは、「Goods In Transit」の期間を測定し、出荷に関する財務処理を行う際の開始点となります。
入手先
Warehouse managementモジュールまたはTransportation managementモジュールに記録されます。積荷または出荷(WHSLoadTable)に対して「Ship confirm」アクションを実行すると、タイムスタンプ付きのイベントが作成されます。
取得
関連する積荷または出荷に対して「Ship confirm」アクションが実行された際に記録されます。
イベントタイプ
explicit
|
|||
|
顧客注文の作成
|
Dynamics 365 SCMで新しい販売注文が正式に作成されたことを示します。ユーザーが新しい販売注文書を保存した際に、タイムスタンプ付きの明示的なイベントとして記録され、受注処理が開始されます。 | ||
|
重要な理由
このアクティビティは、受注処理サイクルの正式な開始を示します。全体のリードタイム、納期遵守率、注文受付の傾向を測定・分析する際の主要な基準点となります。
入手先
Sales and marketingモジュールに記録される明示的なイベントです。SalesTable(販売注文ヘッダー)に、固有の作成日時とともに記録されます。
取得
SalesTableに販売注文レコードが作成された際に記録されるイベントです。
イベントタイプ
explicit
|
|||
|
倉庫ピッキングリストの生成
|
注文を処理するためにピッキングする品目を作業員に指示するピッキングリストまたは倉庫作業が作成されます。注文が処理のために倉庫へリリースされた際に記録されます。 | ||
|
重要な理由
このアクティビティによって、倉庫での物理的な受注処理作業が開始されます。この時点から梱包完了までの時間を分析することで、倉庫内部の効率と対応力を測定できます。
入手先
Warehouse managementモジュールに記録されます。倉庫作業(WHSWorkTable)の作成、またはピッキングリスト仕訳(WMSPickingRoute)の転記が個別のイベントとなります。
取得
ピッキングリスト仕訳が生成された際、または倉庫作業が作成された際に記録されます。
イベントタイプ
explicit
|
|||
|
出荷のスケジュール設定
|
梱包済み商品の出荷日と運送会社が割り当てられます。通常は、輸送モジュールで積荷を計画した際、または出荷を確認した際に記録されます。 | ||
|
重要な理由
出荷スケジュールの遵守状況を測定する基準となります。予定日と実際の積載日を比較することは、物流計画における重要なパフォーマンス指標です。
入手先
Transportation management(TMS)モジュールに記録されます。積荷(WHSLoadTable)または出荷の確認時に、取得可能な予定出荷日が記録されることがあります。
取得
輸送積荷または出荷レコードが確認された際に記録されます。
イベントタイプ
explicit
|
|||
|
品質管理の実施
|
生産または入荷した製品が基準を満たしていることを確認するため、品質検査を実施します。通常は、システム上で品質オーダーの完了または検証として記録されます。 | ||
|
重要な理由
製品品質とプロセスのコンプライアンスを確保します。品質検査の未実施や検査時間の長期化を特定することで、リスクを抑え、プロセス全体の流れを改善できます。
入手先
Inventory managementモジュールのQuality Ordersを通じて記録されます。品目に関連付けられた品質オーダー(InventQualityOrderTable)の検証または終了が、このイベントとなります。
取得
品目ロットまたはシリアル番号に関連付けられたQuality Orderが検証または終了された際に記録されます。
イベントタイプ
explicit
|
|||
|
注文のキャンセル
|
受注処理が完了する前に、顧客の販売注文がキャンセルされたことを示します。販売注文ヘッダーのステータスが「Canceled」に変更されたことで記録されます。 | ||
|
重要な理由
プロセス上の望ましくない結果を示します。注文がいつ、なぜキャンセルされたかを分析することで、製品の供給状況、リードタイム、顧客サービスに関する解決すべき問題を明らかにできます。
入手先
SalesTableのステータスフィールドが「Canceled」に変更されたことから推定します。変更履歴またはデータベースログが有効になっていれば、この変更日を取得できます。
取得
販売注文のステータスが「Canceled」に変更されたことから推定します。
イベントタイプ
inferred
|
|||
|
製造オーダーの作成
|
顧客の物流注文に必要な完成品を製造するため、製造オーダーが生成されます。Production controlモジュールに記録される個別のイベントです。 | ||
|
重要な理由
受注生産のシナリオで製造プロセスを開始します。このイベントから製品完成までの時間を追跡することは、生産サイクルタイムとスケジュール遵守状況を分析するうえで重要です。
入手先
Production controlモジュールに記録されます。ProdTable(製造オーダーテーブル)に新しいレコードが作成され、作成日時が記録されます。
取得
製造オーダーテーブル(ProdTable)に新しいレコードが作成された際に記録されます。
イベントタイプ
explicit
|
|||
|
購買依頼の作成
|
通常は在庫が不足している場合に、注文に必要な資材を調達するため、購買部門へ正式な依頼を行います。新しい購買依頼書を作成して保存した際に、明示的なイベントとして記録されます。 | ||
|
重要な理由
このアクティビティによって調達サブプロセスが開始されます。購買発注が発行されるまでの社内承認にかかるリードタイムを分析し、遅延を特定するうえで重要です。
入手先
Procurement and sourcingモジュールに記録されます。PurchReqTableにレコードが作成された時点で、タイムスタンプ付きの個別イベントとなります。
取得
購買依頼テーブル(PurchReqTable)にレコードが作成された際に記録されるイベントです。
イベントタイプ
explicit
|
|||
|
顧客請求書の転記
|
販売注文から販売請求書が生成され、財務元帳に転記されます。通常は出荷時に行われますが、プロセスは異なる場合があるため、独立したアクティビティとして扱います。 | ||
|
重要な理由
受注から入金までのサイクルにおける重要な財務上のマイルストーンです。出荷から請求までの時間を分析することで、請求処理の遅延を明らかにし、キャッシュフローへの影響を把握できます。
入手先
Accounts receivableモジュールに記録されます。販売注文の請求書を転記すると、特定の転記日とともにCustInvoiceJourテーブルにレコードが作成されます。
取得
販売注文の請求書が転記され、CustInvoiceJourレコードが作成された際に記録されます。
イベントタイプ
explicit
|
|||
抽出ガイド
準備はできましたか?
このテンプレートを使ってサプライチェーンの可能性を最大限に引き出します。今すぐ業務を最適化し、効率向上とコスト削減につなげましょう。
サプライチェーン管理を極める:今すぐ最適化を開始
エンドツーエンドの可視性を確保し、予測精度を90%まで高めてコストを削減します。
クレジットカードは不要です。数分で設定できます。