サプライチェーンマネジメントデータテンプレート
サプライチェーンマネジメントデータテンプレート
- 詳細分析のために収集すべき推奨属性
- プロセス全体で追跡すべき主要なサプライチェーン活動
- Microsoft Dynamics 365 SCM向けの実践的なデータ抽出ガイド
サプライチェーンマネジメント属性
| 名前 | 説明 | ||
|---|---|---|---|
|
ロジスティクスオーダー
LogisticsOrder
|
特定のサプライチェーンフルフィルメント要求に対する一意の識別子であり、主要なケース識別子として機能します。 | ||
|
説明
ロジスティクスオーダーは、顧客の需要発生から最終配送に至るまでのロジスティクスプロセス全体を繋ぐユニークな識別子です。この属性は、特定の出荷要求に対する調達、生産、出荷といった様々なサブプロセスを連携させる中心的な役割を果たします。 分析においては、全てのイベントがロジスティクスオーダーと関連付けられるため、プロセスフローのエンドツーエンドな完全な再構築が可能です。これにより、異なる部門やシステムを横断するオーダーの移動を追跡し、ボトルネックを特定し、開始から完了までの全体的なサイクルタイムを正確に測定できます。
その重要性
サプライチェーンプロセス全体をエンドツーエンドで分析し、単一の出荷要求に対する全ての関連プロセスイベントを繋ぐための不可欠な鍵です。
取得元
これは概念的な識別子であり、
例
LO-2024-00123LO-2024-00124LO-2024-00125
|
|||
|
アクティビティ
ActivityName
|
ロジスティクスプロセスのある時点で発生したビジネスイベント、またはタスクの名称です。 | ||
|
説明
この属性は、「発注書発行済み」、「生産された商品」、「出荷予定」など、発生した特定のビジネスイベントまたはタスクを記録します。これらの活動は、プロセスの基本的な構成要素です。 これらの活動のシーケンス、頻度、および期間を分析することが、プロセスマイニングの核心を成します。これにより、プロセスマップの自動発見と可視化、標準手順からの逸脱の検出、そして改善の余地がある頻繁または非効率なプロセスステップの特定が可能になります。
その重要性
プロセスのステップを定義し、プロセスフローを視覚化し、バリエーションを分析し、ボトルネックや非準拠アクティビティを特定することを可能にします。
取得元
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
|
イベントデータが抽出された元システムです。 | ||
|
説明
この属性は、データが生成されたシステムまたはモジュールを識別します。複雑なサプライチェーン環境では、データは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のほとんどの取引テーブル(SalesTableまたはPurchTableのCreatedByなど)の「作成者」または「変更者」フィールドにあります。
例
j.doea.smithAX_BATCH_USER
|
|||
|
仕入先名
SupplierName
|
原材料または商品を提供するサプライヤーの名称です。 | ||
|
説明
この属性には、原材料の調達元であるベンダー名が含まれます。これは、調達関連活動を分析する上で重要な要素です。 「調達リードタイム内訳」および「サプライヤーパフォーマンスベンチマーク」ダッシュボードで広く活用されます。サプライヤーごとにプロセス指標を分析することで、最も信頼性が高く効率的なパートナー、および頻繁に遅延や問題を引き起こすパートナーを特定するのに役立ちます。この情報は、戦略的ソーシングとサプライヤー関係管理にとって不可欠です。
その重要性
サプライヤー別に調達パフォーマンスをセグメント化・ベンチマークすることを可能にし、サプライヤー関係の改善と資材リードタイムの短縮に不可欠です。
取得元
発注書テーブル(PurchTable)と仕入先マスタテーブル(VendTable)を仕入先勘定番号で結合して導出されます。
例
コンソー原材料Fabrikam Inc.ノースウィンドトレーダーズ
|
|||
|
希望納期
RequestedDeliveryDate
|
顧客が要求した納期。 | ||
|
説明
この属性は、顧客がオーダー時に指定した配送日を記録します。これは、実際の配送パフォーマンスを測定するための主要な基準となります。 この日付は、「納期遵守パフォーマンスモニター」ダッシュボードおよび「納期遵守率KPI」の基盤です。要求された配送日と実際の配送日を比較することは、配送パフォーマンスを算出する標準的な方法であり、顧客満足度の主要な指標となります。
その重要性
これは、納期遵守パフォーマンスを測定するための基準であり、顧客満足度とサプライチェーンの信頼性にとって重要なKPIです。
取得元
SalesLineテーブルの
例
2023-05-102023-06-012023-07-20
|
|||
|
生産オーダー番号
ProductionOrderNumber
|
生産オーダーまたは製造オーダーに対する一意の識別子です。 | ||
|
説明
この番号は、製造施設内で特定の数量の製品を生産するためのオーダーを識別します。原材料の消費と完成品の生産を追跡します。 製造部門を持つ企業にとって、このIDは生産プロセスを追跡するために不可欠です。「生産スケジュール遵守トラッカー」ダッシュボードをサポートし、予定生産日を実際の完了日にリンクすることで、製造プロセスにおける差異や遅延を明確にします。
その重要性
製造ライフサイクルの詳細な分析を可能にし、生産スケジュールの遵守状況を測定し、工場フロアのボトルネックを特定するのに役立ちます。
取得元
ProdTableテーブルのProdIdフィールドに記載されています。
例
PRD-000112PRD-000113PRD-000114
|
|||
|
発注書番号
PurchaseOrderNumber
|
サプライヤーに発行された購買オーダーに対する一意の識別子です。 | ||
|
説明
これは、外部サプライヤーから原材料や商品をオーダーする際に使用される公式文書番号です。品目、数量、価格、配送日に関する詳細が含まれています。 購買オーダー番号ごとにプロセスを分析することは、「調達リードタイム内訳」および「サプライヤーパフォーマンスベンチマーク」ダッシュボードに不可欠です。これにより、要求書作成からサプライヤーへの支払いまでの「購買から支払い」サイクル全体を追跡し、資材調達の遅延を特定するのに役立ちます。
その重要性
このIDは、サプライチェーンの調達部分の分析、サプライヤーパフォーマンスの監視、および資材リードタイムの理解に不可欠です。
取得元
PurchTableテーブルのPurchIdフィールドに記載されています。
例
PO-000541PO-000542PO-000543
|
|||
|
納期内配送
IsOnTimeDelivery
|
注文が依頼された期日までに配送されたかどうかを示すフラグです。 | ||
|
説明
これは、ロジスティクスオーダーが予定通りに配送されたかどうかを示す、計算されたブール型属性です。「配送された商品」活動のタイムスタンプと「要求された配送日」を比較することで導き出されます。 この属性は、「納期遵守率KPI」の算出基盤であり、「納期遵守パフォーマンスモニター」ダッシュボードにおける主要なフィルターでもあります。日付の比較を単純な真偽値に変換することで分析を簡素化し、遅延オーダーのフィルタリングやカウントを容易にします。
その重要性
顧客サービスパフォーマンスを直接測定し、納期遵守KPIの主要な入力であり、配送信頼性の分析を簡素化します。
取得元
これは計算フィールドです。ロジックは、「『商品配送済み』タイムスタンプ <= 『要求された配送日』」の場合True、それ以外はFalseです。
例
truefalse
|
|||
|
調達リードタイム
ProcurementLeadTime
|
購買要求の作成から原材料の受領までの総所要時間です。 | ||
|
説明
これは、調達プロセスの効率を測定する、計算された期間指標です。特定の購買オーダーに対する「購買要求作成済み」活動と「原材料受領済み」活動の間の時間差として算出されます。 この属性は、「調達リードタイム内訳」ダッシュボードおよび「平均調達サイクルタイムKPI」を直接サポートします。この値を事前に計算することで、特にサプライヤーや製品カテゴリで分類した場合の調達パフォーマンス分析が格段に効率的になります。
その重要性
調達サイクル全体の期間を数値化します。これは、在庫レベルと生産スケジュールの管理における重要なKPIです。
取得元
これは計算フィールドです。ロジックは、「Timestamp(『原材料受領済み』) - Timestamp(『購買要求作成済み』)」です。
例
10日25日4時間
|
|||
|
販売オーダー番号
SalesOrderNumber
|
顧客の販売オーダーに対する一意の識別子です。 | ||
|
説明
これは、顧客の商品またはサービス要求の主要な参照番号です。販売オーダーは、調達や生産を含む多くの下流サプライチェーン活動を開始します。 プロセスマイニングにおいて、販売オーダー番号はフィルタリングと分析のための重要な分析軸です。これにより、ビジネスユーザーは特定の顧客オーダーに対する完全なフルフィルメントプロセスを追跡でき、多くの場合、概念的なロジスティクスオーダーケースIDの主要な構成要素となります。
その重要性
顧客の受注から入金までのサイクルや顧客ごとの出荷パフォーマンスを分析するために、サプライチェーンプロセスを顧客の需要と直接結びつけます。
取得元
SalesTableテーブルの
例
SO-001872SO-001873SO-001874
|
|||
|
顧客名
CustomerName
|
受注を発注した顧客の名前です。 | ||
|
説明
この属性は、販売オーダーに関連する顧客を識別します。これにより、サプライチェーンプロセスを顧客中心の視点から捉えることが可能になります。 顧客ごとにロジスティクスプロセスを分析することで、特定の顧客に特有のフルフィルメントパターン、嗜好、または課題が明らかになります。これは、主要顧客管理やサービスレベルの調整に特に有用であり、顧客満足度と顧客維持率の向上に貢献します。
その重要性
顧客中心の分析を可能にし、どの顧客が最も遅延を経験しているかを特定し、主要なアカウントのサービスレベルを評価するのに役立ちます。
取得元
販売注文テーブル(SalesTable)と顧客マスタテーブル(CustTable)を顧客勘定番号で結合して導出されます。
例
アルペンスキーハウスアドベンチャーワークスシティパワー&ライト
|
|||
|
予定出荷日
ScheduledShipmentDate
|
出荷が予定されていた日付です。 | ||
|
説明
この属性は、出荷が倉庫または生産施設を出る予定日または計画日を示します。これは、フルフィルメントプロセスにおける主要な内部マイルストーンです。 この日付は、「出荷スケジュール遵守率KPI」の算出に利用されます。予定日と「輸送のために積載された商品」活動の実際の日付を比較することは、内部ロジスティクス計画および実行の信頼性と予測可能性を測定する上で役立ちます。
その重要性
内部のスケジュール遵守と出荷プロセスの予測可能性を測定するのに役立ち、下流の輸送計画に影響を与えます。
取得元
SalesLineの
例
2023-05-082023-05-302023-07-18
|
|||
|
倉庫ID
WarehouseId
|
商品が保管または処理される倉庫の識別子です。 | ||
|
説明
この属性は、ピッキング、梱包、出荷といった活動に関わる特定の倉庫または流通センターを識別します。 これは「倉庫業務スループット」ダッシュボードに不可欠であり、異なる施設間のパフォーマンス比較を可能にします。倉庫別に分析することで、どの拠点が最も効率的か、どの拠点がキャパシティに課題を抱えているか、そしてどの拠点で業務改善が最も緊急に必要とされているかを特定するのに役立ちます。
その重要性
異なる物理的拠点間でのパフォーマンス比較とボトルネック分析を可能にし、倉庫効率の改善をサポートします。
取得元
InventSumやWHSWorkTableなど、在庫および倉庫管理に関連するテーブルのInventLocationIdフィールドにあります。
例
WH-MainWH-EastDC-West
|
|||
|
手戻り
IsRework
|
アクティビティまたはプロセスループが手戻りであるかどうかを示すフラグです。 | ||
|
説明
これは、手直しや修正ループを示す活動またはプロセスパスを識別する、計算されたブール型属性です。例えば、「品質管理実施済み」活動が失敗し、以前の「生産された商品」ステップに戻る場合、これは手直しとしてフラグが付けられます。 この属性は、「オーダーフルフィルメント手直し率KPI」の算出に不可欠です。手直しにフラグを付けることで、アナリストは品質問題やプロセスエラーの発生頻度と影響を容易に定量化でき、プロセス改善と管理が必要な領域を正確に特定するのに役立ちます。
その重要性
「ハッピーパス」の一部ではないアクティビティを明示的にフラグ付けすることで、プロセスの非効率性や品質問題を定量化するのに役立ちます。
取得元
これは、通常ビジネスルールを用いて算出される計算フィールドです。例えば、「商品を再梱包」のような特定の活動名を再作業としてフラグ付けしたり、プロセスフローにおける逆行ループを特定したりします。
例
truefalse
|
|||
|
注文金額
OrderValue
|
販売受注の総金額です。 | ||
|
説明
この属性は、顧客の販売オーダーの総額を表します。これは、プロセスパフォーマンスがビジネスに与える影響を理解するための主要な指標です。 オーダー金額の観点からサイクルタイムや納期遅延などのプロセス指標を分析することで、改善活動の優先順位付けが可能になります。例えば、高額なオーダーに影響する遅延は、小額のオーダーに影響する遅延よりも対処がより重要となる場合があります。これにより、プロセス分析に財務的な視点が加わります。
その重要性
プロセス分析に財務的な視点を提供し、金銭的な影響度に基づいて問題の優先順位付けを可能にします。
取得元
特定の販売注文(SalesId)に属するすべての明細について、SalesLineテーブルのLineAmountフィールドを合計して計算されます。
例
15200.50850.00125000.75
|
|||
|
製品`カテゴリ`
ProductCategory
|
製品が属するカテゴリを指します。 | ||
|
説明
この属性は、個々の製品を「電子機器」、「原材料」、「完成品」といった広範なカテゴリに分類します。これにより、サプライチェーンのより高レベルな分析が可能になります。 何千もの個別のSKUを見る代わりに、アナリストは製品カテゴリを使用して、製品グループ全体に影響を及ぼすトレンドやボトルネックを特定できます。これは、特に「調達リードタイム内訳」ダッシュボードにおいて、異なる種類の資材におけるサプライヤーパフォーマンスを理解する上で非常に役立ちます。
その重要性
製品グループ全体で集計分析を可能にし、戦略的意思決定や特定の種類の製品に影響を与えるシステム的な問題の特定に役立ちます。
取得元
品目マスタテーブル(InventTable)とEcoResProductCategoryのような製品カテゴリテーブルを結合して導出されます。
例
オーディオコンポーネント梱包資材油圧部品
|
|||
|
製品番号
ProductNumber
|
発注または生産される製品に対する一意の識別子です。 | ||
|
説明
この属性は、取引に関わる製品の在庫管理単位(SKU)または品目番号です。これは、顧客に販売される完成品、またはサプライヤーから購入される原材料である場合があります。 製品ごとにサプライチェーンプロセスを分析することで、リードタイムが長い、品質問題が頻繁に発生する、または生産経路が複雑な品目を特定するのに役立ちます。この情報は、在庫管理、需要予測、製品ポートフォリオの最適化にとって不可欠です。
その重要性
異なる製品のプロセスパフォーマンスを分析することができ、特定の品目に特有のサプライチェーン課題を明らかにできます。
取得元
SalesLine、PurchLine、ProdBOMなどの取引明細テーブルのItemIdフィールドにあります。
例
A0001D0010M9201
|
|||
|
輸送手段
ModeOfTransport
|
トラック、航空、海上など、出荷に用いられる輸送方法です。 | ||
|
説明
この属性は、商品を起点から目的地へ移動させるために用いられる輸送手段を特定します。例えば、陸路、鉄道、空路、海上貨物などが挙げられます。 これは、「輸送効率とコスト」ダッシュボードの主要な分析軸です。輸送手段ごとにサイクルタイムとコストを分析することは、ロジスティクス戦略の最適化、速度とコストの最適なバランスの選択、および特定の輸送チャネル内の非効率性の特定に役立ちます。
その重要性
輸送コストと効率の分析に不可欠であり、物流ネットワークの最適化と運賃費用の削減に役立ちます。
取得元
SalesTableやPurchTableのようなテーブルのModeOfDeliveryフィールド、またはTMSRouteのような輸送管理テーブルでより詳細に記述されています。
例
トラック航空海上Rail
|
|||
|
運送業者名
CarrierName
|
出荷を担当する輸送会社、または運送業者の名称です。 | ||
|
説明
この属性は、商品の輸送を担当する第三者ロジスティクスプロバイダー、または自社フリートを識別します。どの企業が実際に商品を輸送しているかを示します。 運送業者は、「輸送効率とコスト」ダッシュボードにおけるもう一つの重要な分析軸です。運送業者ごとに輸送時間や納期遵守率などのパフォーマンス指標を分析することで、企業はロジスティクスパートナーを評価し、より良い料金交渉を行い、運送業者選択に関して情報に基づいた意思決定を行うことができます。
その重要性
異なる物流パートナーのパフォーマンス分析を可能にし、運送業者管理と輸送コスト最適化にとって重要です。
取得元
販売注文の「CarrierService」のようなフィールド、またはTMSCarrierのような専用の輸送管理テーブルにあります。
例
FedExUPSマースクDHL
|
|||
サプライチェーンマネジメント活動
| アクティビティ | 説明 | ||
|---|---|---|---|
|
原材料受領済み
|
サプライヤーから発注された商品または資材が、物理的に倉庫で受領された状態です。これは、Dynamics 365で購買オーダーに対する製品受領転記トランザクションを通じて記録されます。 | ||
|
その重要性
この活動は、サプライヤーリードタイムの終了と、生産またはフルフィルメントに必要な資材の利用可能性を示します。ここでの遅延は、後続のスケジュールや顧客への配送日に直接影響を及ぼします。
取得元
調達およびソーシング、または在庫管理モジュールで記録されます。製品受領(
取得
発注書に対して製品受領が転記された際にログに記録されるイベントです。
イベントタイプ
explicit
|
|||
|
商品ピッキングと梱包済み
|
倉庫作業員が在庫から商品を物理的にピッキングし、出荷用に梱包しました。これは、ピッキング作業が完了し、システム内で梱包ステータスが更新されたときに記録されます。 | ||
|
その重要性
主要な倉庫フルフィルメントタスクの完了を示します。これは、倉庫業務スループットダッシュボードの主要な指標であり、ピッキングおよび梱包プロセスにおけるボトルネックを特定するために重要です。
取得元
倉庫管理モジュールで記録されます。これは通常、倉庫作業(
取得
倉庫作業のステータスが「クローズ済み」に変更されたこと、または梱包明細書の転記日から推測されます。
イベントタイプ
inferred
|
|||
|
商品配送済み
|
商品が顧客の目的地に到着した状態です。Dynamics 365にはネイティブの「配達済み」トランザクションがないため、このイベントは運送業者の追跡データや手動でのステータス更新から推測される場合があります。 | ||
|
その重要性
物理的な配送の完了を示します。これにより「実際の配達日」が提供され、納期遵守率KPIや顧客対応指標の算出に不可欠なデータとなります。
取得元
これは通常、標準フィールドではありません。販売オーダーまたは出荷のカスタム日付フィールドに記録されるか、手動で、または運送業者のシステムとの連携を通じて更新される場合があります。
取得
配送日フィールドへの手動更新、または外部運送業者API統合を介して推測されます。
イベントタイプ
inferred
|
|||
|
生産完了品
|
製造プロセスが完了し、完成品がシステム上で正式に完成として報告された状態です。これは、生産オーダーの「完成報告」仕訳を転記することで記録され、在庫が更新されます。 | ||
|
その重要性
生産フェーズの完了を示し、商品を品質管理と出荷に利用可能にします。これは生産スケジュールの遵守を測定する上で重要なマイルストーンです。
取得元
生産管理モジュールで記録されます。「完成報告」仕訳を転記すると、タイムスタンプ付きの在庫トランザクションが作成され、生産オーダーのステータスが更新されます。
取得
生産オーダーの「完成報告」仕訳が転記されたときに記録されます。
イベントタイプ
explicit
|
|||
|
発注書発行済み
|
正式な発注書が作成・確認され、サプライヤーからの購入が確定されます。このイベントは、発注書ステータスが「確認済み」または「外部レビュー中」に更新された際にログに記録されます。 | ||
|
その重要性
これは調達における重要なマイルストーンであり、サプライヤーリードタイムを測定する上での主要な出発点です。このイベントから資材受領までの時間を分析することは、サプライヤーのパフォーマンス評価に役立ちます。
取得元
調達およびソーシングモジュールで記録されます。発注書の確認は、
取得
発注書のステータスが仕訳処理によって「確認済み」に更新されたときに記録されます。
イベントタイプ
explicit
|
|||
|
納品証明書署名済み
|
顧客が商品の受領を正式に確認した状態を指し、多くの場合、納品書への署名によって行われます。これは通常、文書の添付やシステム内のステータス更新によって記録されます。 | ||
|
その重要性
これは、オーダーフルフィルメントの成功を最終的に確認するものであり、ロジスティクスプロセスの明確な終了を示します。紛争解決や総オーダーサイクルタイムの算出に不可欠です。
取得元
これは標準的な個別のトランザクションではありません。多くの場合、販売オーダーのステータスを更新するか、文書管理機能を用いてスキャンされた配達証明書を添付することで管理されます。
取得
ステータス更新、または販売注文や出荷へのPOD文書の添付から推測されます。
イベントタイプ
inferred
|
|||
|
輸送のために積載済み
|
梱包された商品が物理的に運送業者の車両に積載され、出荷がシステムで確認された状態です。このイベントはDynamics 365の「出荷確認」アクションに対応します。 | ||
|
その重要性
倉庫からの商品の物理的な出荷を示します。この活動は、「輸送中の商品」期間の測定、および出荷の財務認識の出発点となります。
取得元
倉庫または輸送管理モジュールで記録されます。積載または出荷(
取得
関連する積載または出荷に対して「出荷確認」アクションが実行されたときに記録されます。
イベントタイプ
explicit
|
|||
|
顧客注文作成済み
|
Dynamics 365 SCMにおける新規販売オーダーの正式な作成を示します。これは、ユーザーが新しい販売オーダー文書を保存し、フルフィルメントプロセスを開始した際に、タイムスタンプ付きで記録される明示的なイベントです。 | ||
|
その重要性
この活動は、オーダーフルフィルメントサイクルの正式な開始を示します。これは、全体的なリードタイム、納期遵守パフォーマンス、およびオーダー受付パターンの分析を測定するための主要な基準点です。
取得元
これは販売およびマーケティングモジュールに記録される明示的なイベントです。作成は
取得
SalesTableに販売注文レコードが作成された際にログに記録されるイベントです。
イベントタイプ
explicit
|
|||
|
倉庫ピッキングリスト作成済み
|
注文を履行するためにどの品目をピッキングするかをスタッフに指示するピッキングリストまたは倉庫作業が作成されます。このイベントは、注文が倉庫に処理のためにリリースされた際にログに記録されます。 | ||
|
その重要性
この活動は、物理的な倉庫フルフィルメント業務を開始します。この時点から梱包完了までの時間を分析することは、内部倉庫の効率性や応答性を測定する上で役立ちます。
取得元
倉庫管理モジュールで記録されます。倉庫作業(
取得
ピッキングリスト仕訳の生成時、または倉庫作業の作成時に記録されます。
イベントタイプ
explicit
|
|||
|
出荷予定済み
|
梱包された商品の出荷のために、特定の配送日と運送業者が割り当てられます。これは、多くの場合、輸送モジュールで積載が計画された際、または出荷が確認された際に記録されます。 | ||
|
その重要性
出荷スケジュールの遵守状況を測定するための基準を提供します。この予定日と実際の積載日を比較することは、ロジスティクス計画における主要なパフォーマンス指標です。
取得元
輸送管理(TMS)モジュールで記録されます。積載(
取得
輸送積載または出荷レコードの確認時に記録されます。
イベントタイプ
explicit
|
|||
|
品質管理実施済み
|
製造または受領された製品が基準を満たしていることを確認するために品質検査が実施されます。これは、多くの場合、システム内で品質オーダーの完了または検証として記録されます。 | ||
|
その重要性
製品品質とプロセスコンプライアンスを保証します。スキップされた品質チェックや長い検査時間を特定することは、リスクを軽減し、全体的なプロセスフローを改善するのに役立ちます。
取得元
在庫管理モジュールで品質オーダーを通じて記録されます。品目に関連付けられた品質オーダー(
取得
品目ロットまたはシリアル番号に紐づけられた品質オーダーの検証またはクローズ時に記録されます。
イベントタイプ
explicit
|
|||
|
注文キャンセル済み
|
顧客販売オーダーが、フルフィルメント完了前にキャンセルされた状態です。これは、販売オーダーヘッダーのステータスが「キャンセル済み」に変更されることで記録されます。 | ||
|
その重要性
負のプロセス結果を示します。注文がいつ、なぜキャンセルされたのかを分析することで、製品の可用性、リードタイム、または顧客サービスにおける改善すべき問題が明らかになります。
取得元
SalesTableのステータスフィールドが「Canceled」に変更されたことから推測されます。この変更日は、変更追跡またはデータベースログが有効になっている場合にキャプチャできます。
取得
販売注文ステータスが「キャンセル済み」に変更されたことから推測されます。
イベントタイプ
inferred
|
|||
|
生産オーダー作成済み
|
顧客の物流注文に必要な完成品を製造するための生産オーダーが生成されます。これは、生産管理モジュールにログ記録される個別のイベントです。 | ||
|
その重要性
受注生産シナリオの製造プロセスを開始します。このイベントから製品完成までの時間を追跡することは、生産サイクルタイムとスケジュール遵守を分析する上で不可欠です。
取得元
生産管理モジュールで記録されます。
取得
生産オーダーテーブル(
イベントタイプ
explicit
|
|||
|
購買依頼書作成済み
|
注文に必要な材料を調達するため、通常は在庫が不足している場合に購買部門に正式な依頼が行われます。これは、新しい購買要求書が作成され保存された際にログに記録される明示的なイベントです。 | ||
|
その重要性
この活動は調達サブプロセスを開始します。これを追跡することは、調達リードタイムにおける内部承認部分を分析し、発注書発行前の遅延を特定する上で重要です。
取得元
調達およびソーシングモジュールで記録されます。
取得
購買要求テーブル(PurchReqTable)にレコードが作成された際にログに記録されるイベントです。
イベントタイプ
explicit
|
|||
|
顧客請求書計上済
|
販売請求書が販売注文から生成され、財務元帳に転記されます。これは出荷時に行われることが多いですが、プロセスは異なる場合があり、それが独立したアクティビティとなっています。 | ||
|
その重要性
これは、受注から現金化までのサイクルにおける重要な財務上のマイルストーンです。出荷から請求書発行までの時間を分析することで、請求プロセスにおける遅延が明らかになり、キャッシュフローに影響を及ぼす可能性があります。
取得元
売掛金モジュールで記録されます。販売オーダー請求書の転記により、
取得
販売オーダーの請求書が転記され、
イベントタイプ
explicit
|
|||