輸送管理データテンプレート
輸送管理データテンプレート
これは輸送管理向けの汎用プロセスマイニング用データテンプレートです。より具体的なガイダンスについては、システム別テンプレートをご利用ください。
特定のシステムを選択- あらゆる輸送管理システムに適用できる汎用フレームワークです。
- 詳細なプロセス分析に必要な主要属性とアクティビティを特定します。
- プロセスマイニングを始める際の理想的な出発点です。
輸送管理の属性
| 名前 | 説明 | ||
|---|---|---|---|
| アクティビティ名 ActivityName | 出荷について、ある時点で発生した特定の業務イベントまたはマイルストーンの名称です。 | ||
| 説明 アクティビティ名は、輸送プロセス内の1つのステップまたはタスクを表します。たとえば、「Shipment Planned」、「Carrier Tendered」、「Goods Picked Up」、「Freight Invoice Received」などです。これらのアクティビティは、出荷の流れにおける主要なマイルストーンを示します。 この属性は、出荷が実際にどのようにプロセスを進むかを示すプロセスフローマップの可視化に欠かせません。さまざまなアクティビティの順序と頻度を分析することで、標準的なプロセスを把握し、よくある逸脱ややり直し、非効率な領域を特定できます。あらゆるプロセスマイニング分析の基盤となる属性です。 重要な理由 プロセスマップ上のステップを定義し、出荷のワークフロー、ばらつき、ボトルネックを可視化・分析できます。 入手先 通常、イベントログやステータス更新テーブルから取得するか、TMS内のステータス変更から生成します。 例 出荷を計画運送会社への輸送依頼貨物の納品完了納品証明の受領 | |||
| イベント日時 EventTime | 出荷について、特定のアクティビティまたはイベントが発生した日時を示すタイムスタンプです。 | ||
| 説明 イベント日時は、特定のアクティビティが実行された正確な日付と時刻を記録します。このタイムスタンプは、イベントを時系列に並べ、異なるプロセスステップ間の所要時間を算出するための基礎となります。 プロセスマイニングでは、この属性によって時間に基づくすべての分析が可能になります。サイクルタイム、待機時間、処理時間などの主要業績評価指標の算出に使われます。イベント日時を分析することで、出荷が最も長く滞留するボトルネックを特定し、サービスレベル合意の遵守状況を測定するとともに、プロセスアクティビティの時間的な分布を把握できます。 重要な理由 すべてのアクティビティに時系列の文脈を与え、サイクルタイムの算出、ボトルネックの特定、パフォーマンス測定を可能にします。 入手先 TMS内のイベントログまたは取引レコードから取得します。記録された各操作にタイムスタンプが付与されています。 例 2023-10-26T10:00:00Z2023-11-15T14:35:10Z2024-01-05T08:22:00Z | |||
| 出荷ID ShipmentId | 1件の出荷を一意に識別する識別子で、輸送プロセスのケースIDとして機能します。 | ||
| 説明 出荷IDは、1件の輸送オーダー、または出荷元から納品先までの貨物移動を一意に識別する主キーです。各出荷ケースには、計画、予約、集荷、納品、請求など、関連するすべてのアクティビティ、マイルストーン、データが含まれます。 プロセスマイニングでは、この属性が各出荷のエンドツーエンドの流れを再構成するうえで欠かせません。関連するすべてのイベントを時系列で結び付け、プロセスディスカバリー、適合性チェック、パフォーマンス分析の基盤になります。出荷ID単位でプロセスを分析することで、輸送ライフサイクルにおけるボトルネック、遅延、ばらつきを特定できます。 重要な理由 関連するすべてのイベントを1つのプロセスインスタンスに結び付ける基本識別子であり、出荷ライフサイクルをエンドツーエンドで分析できます。 入手先 通常、Transportation Management System(TMS)の出荷または運賃オーダーに関するヘッダーまたは主要テーブルにあります。 例 SH-2024-001237004568910FO-US-987654 | |||
| ソースシステム SourceSystem | データが抽出されたシステムまたはアプリケーションを識別します。 | ||
| 説明 ソースシステム属性は、イベントデータの取得元を示します。たとえば、Transportation Management System(TMS)、運送会社の可視化プラットフォーム、ERPシステムなどです。現在の物流業務では、1件の出荷データが複数の連携システムから取得される場合があります。 この属性は、データの系譜と品質を把握するうえで役立ちます。データの不整合を調査し、情報源ごとに分析できます。たとえば、可視化プラットフォームと中核TMSからの更新の適時性を比較したり、問題を発生元のシステムまで追跡したりできます。 重要な理由 データを取得元まで追跡できるため、データ検証、トラブルシューティング、各システムが全体のプロセスにどのように関与しているかの把握に役立ちます。 入手先 通常、データ抽出ファイルの標準フィールドとして提供されるか、データソースに基づいてデータ取り込み時に追加できます。 例 SAP TMBlue Yonder TMSOracle OTMproject44 | |||
| 最終データ更新日時 LastDataUpdate | このレコードのデータがソースシステムから最後に更新または抽出された日時を示すタイムスタンプです。 | ||
| 説明 この属性は、特定のレコードまたはイベントがプロセスマイニング用データセットで最後に更新された時点、またはそのデータセット向けに抽出された時点を示します。分析対象データの鮮度を表します。 プロセスフロー分析で直接使われるわけではありませんが、データガバナンスと監視には欠かせません。最新情報に基づいて分析できていることを確認し、遅延または失敗しているデータパイプラインのアラート設定にも利用できます。これにより、生成された分析結果の信頼性と適時性を確認できます。 重要な理由 データの鮮度を示すため、プロセス分析と監視を適時性のある関連情報に基づいて行ううえで欠かせません。 入手先 通常、データの抽出、変換、ロード(ETL)処理中に生成されます。 例 2024-05-20T02:00:00Z2024-05-20T03:00:00Z2024-05-20T04:00:00Z | |||
| 出荷コスト ShipmentCost | 出荷の輸送にかかった運賃総額または請求金額です。 | ||
| 説明 出荷コストは、1件の出荷に関連する輸送費の総額です。基本運賃、燃料サーチャージ、付帯料金、運送会社から請求されるその他の費用が含まれる場合があります。 この属性は、コストに関するすべての分析の基盤です。輸送費総額、1マイル当たりのコスト、単位当たりのコストを追跡するダッシュボードを作成できます。コストデータとプロセスデータを組み合わせることで、コスト超過の根本原因分析、遅延やプロセスの非効率性による財務影響の特定、運賃請求の正確性分析が可能になります。 重要な理由 プロセスのパフォーマンスと財務結果を直接結び付け、輸送費、コスト要因、非効率性による財務影響を分析できます。 入手先 運賃オーダー、運送会社の運賃請求書、または運賃監査・支払いシステムから取得できます。 例 1250.75540.008200.50 | |||
| 実際の納品日 ActualDeliveryDate | 「Goods Delivered」イベントが発生した実際の日時です。 | ||
| 説明 実際の納品日は、出荷が荷受人に実際に納品され、「Goods Delivered」アクティビティが完了した時点の記録日時です。通常、納品証明書類によって確認されます。 この属性は希望納品日に対応する実績値であり、実際のパフォーマンスを算出するうえで欠かせません。「定刻納品率」KPIの算出に直接使われます。また、実際の納品日と集荷日の差から実際の輸送時間を算出し、計画輸送時間と比較して輸送中の遅延を特定できます。 重要な理由 納品パフォーマンスの実績値を提供し、定刻納品率の算出と納品遅延の分析を可能にします。 入手先 TMSの「Goods Delivered」イベントから取得します。通常、運送会社のEDIメッセージ、可視化プラットフォーム、またはドライバーが使用するモバイルアプリによって更新されます。 例 2023-11-01T16:30:00Z2023-11-21T09:00:00Z2024-02-09T18:00:00Z | |||
| 希望納品日 RequestedDeliveryDate | 顧客が希望する、または販売注文で指定された納品日です。 | ||
| 説明 希望納品日は、出荷が納品先に到着することを期待される目標日です。通常、顧客の発注書またはサービスレベル合意(SLA)で定められます。 この属性は、顧客サービスレベルと約束に対するパフォーマンスを測定するうえで欠かせません。「定刻納品率」KPIを算出する基準になります。希望納品日と実際の納品日の差を分析することで、遅延の体系的な原因を特定し、納品の予測可能性を高められます。 重要な理由 定刻納品実績を測定する主要な基準であり、顧客満足度とサプライチェーンの信頼性に関わる重要なKPIです。 入手先 通常、ERPや注文管理システムなどの上流システムから取得され、TMSの運賃オーダー詳細に保存されます。 例 2023-11-01T17:00:00Z2023-11-20T23:59:59Z2024-02-10T12:00:00Z | |||
| 納品先国 DestinationCountry | 出荷が納品される国です。 | ||
| 説明 納品先国は、出荷が納品される予定の国を示します。納品先住所情報の一部です。 出荷元国と同様に、地理的分析と輸送レーンのパフォーマンス把握に欠かせない属性です。国別にデータを切り分け、納品パフォーマンス、コスト、サイクルタイムを比較できます。国際輸送の通関プロセスを分析するうえでも重要です。 重要な理由 納品先別にパフォーマンスとコストを切り分けられるため、輸送レーンの効率や国際輸送の複雑さを分析するうえで欠かせません。 入手先 通常、運賃オーダーの納品先所在地または荷受人住所の詳細の一部として保存されます。 例 カナダメキシコ英国日本 | |||
| 輸送モード ModeOfTransport | 出荷に使用する輸送手段です。トラック、航空、海上、鉄道などがあります。 | ||
| 説明 この属性は、出荷に使用する輸送方法を示します。一般的な輸送モードには、Full Truckload(FTL)、Less-Than-Truckload(LTL)、航空貨物、海上貨物、鉄道があります。 輸送モード別にプロセスを分析することは重要です。輸送モードごとにコスト構造、輸送時間、プロセスの複雑さが異なるためです。この切り分けにより、サイクルタイムやコストのばらつきを説明できます。たとえば、海上貨物のプロセスは、航空貨物よりも自然にサイクルタイムが長くなります。物流業務に合わせたダッシュボードやKPIを構築するうえで、基本となる属性です。 重要な理由 輸送モードごとにプロセス、コスト、期間が本質的に異なるため、分析の主要なフィルターになります。意味のある比較とベンチマーキングに欠かせません。 入手先 TMS内の出荷または運賃オーダーの詳細にあります。 例 トラック貸切輸送(TL)トラック混載輸送(LTL)海上輸送航空輸送鉄道輸送 | |||
| 遅延理由 DelayReason | 出荷の進捗が遅れた原因を説明するコードまたは説明文です。 | ||
| 説明 遅延理由は、出荷が計画どおりに進まなかった理由を示します。天候、通関保留、交通状況、機械的な問題、書類の誤りなどが該当します。遅延イベントが記録されたときに取得されます。 根本原因分析において特に重要な属性の1つです。遅延理由ごとの頻度を分類・定量化することで、納品遅延の主な要因を特定できます。その結果、社内プロセスの改善、運送会社との連携、外部リスクの軽減など、影響の大きい領域に改善活動を集中できます。 重要な理由 出荷遅延の根本原因分析に欠かせません。遅延の主な原因を特定、定量化し、対策を講じられます。 入手先 TMSまたは可視化プラットフォームの例外イベントや遅延イベントのレコードから取得します。運送会社から提供されることが多いデータです。 例 天候による遅延通関保留港湾の混雑機械故障 | |||
| 運送会社名 CarrierName | 出荷の輸送を担当する輸送会社または物流事業者の名称です。 | ||
| 説明 運送会社名は、貨物を実際に輸送する契約先の3PLまたは輸送会社を識別します。トラック運送会社、航空会社、海運会社、鉄道貨物事業者などが該当します。 パフォーマンス分析における重要な分析軸です。定刻納品、定刻集荷、輸送依頼受諾率、コストなどの指標で事業者を比較し、運送会社の評価表を作成できます。運送会社別にプロセスを分析することで、パフォーマンスの高いパートナーや、改善計画が必要なパートナーを特定できます。 重要な理由 異なる輸送事業者のパフォーマンスを比較評価できるため、運送会社の管理や交渉、サービス品質の確保に役立ちます。 入手先 出荷または運賃オーダーの詳細に保存され、通常は運送会社マスターデータテーブルから関連付けられます。 例 FedEx FreightMaersk LineUnion Pacific RailroadDHL Express | |||
| リソース Resource | アクティビティを実行した担当者のユーザーIDまたは氏名です。 | ||
| 説明 Resourceは、特定のプロセスステップの実行を担当する個人ユーザー、チーム、または自動化されたシステムエージェントを識別します。たとえば、出荷計画を作成した輸送計画担当者や、運送会社を手配した物流コーディネーターなどです。 Resourceの観点からプロセスを分析すると、業務量の分布、チームのパフォーマンス、自動化の度合いを把握できます。手戻りが繰り返されるループに関与しているユーザーやチーム、例外処理を最も多く担当しているユーザーやチーム、処理時間が最も長いユーザーやチームを特定できます。この情報は、トレーニング、リソース配分、自動化の機会の特定に役立ちます。 重要な理由 人とシステムのパフォーマンス、業務量の分布、自動化の状況を分析し、トレーニングの必要性やリソースのボトルネックを特定できます。 入手先 通常、この情報はアクティビティ名やタイムスタンプとともに、取引ログまたはイベントログに記録されます。 例 john.smithLogisticsTeam_USTMS_AUTO_PLANNERsarah.jones | |||
| 予定集荷日 ScheduledPickupDate | 運送会社が出荷元で貨物を集荷する予定の日付と時刻です。 | ||
| 説明 予定集荷日は、運送会社が出荷場所に到着して貨物を引き取るために合意した予約日時です。出荷の予約と確認における重要なマイルストーンです。 この属性は、集荷パフォーマンスを測定する基準になります。実際の集荷時刻と比較して「定刻集荷率」KPIを算出します。差異を分析することで、積み込み場のスケジュール、倉庫の準備状況、運送会社の時間厳守に関する問題を特定できます。これらはいずれも、その後の工程の遅延につながる可能性があります。 重要な理由 集荷パフォーマンスを測定する基準です。輸送ライフサイクルの最初の重要なステップであり、その後のスケジュール全体に影響します。 入手先 出荷が運送会社との予約を完了した後、出荷または運賃オーダーの詳細にあります。 例 2023-10-25T14:00:00Z2023-11-15T09:30:00Z2024-02-05T11:00:00Z | |||
| 出荷ステータス ShipmentStatus | 出荷ライフサイクルにおける現在の、または最後に確認された出荷ステータスです。 | ||
| 説明 出荷ステータスは、出荷が全体のプロセスのどの段階にあるかを、「Planned」、「In Transit」、「Delivered」、「Cancelled」などで示す概要情報です。出荷ケースの現在の状態を表します。 プロセスマイニングでは、個々のアクティビティからプロセスフローを導き出しますが、出荷全体のステータスも分析軸として役立ちます。現在「In Transit」の出荷だけを抽出して監視したり、「Cancelled」で終了した出荷の特徴を分析したりできます。出荷の進捗を集約して確認できるシンプルな情報です。 重要な理由 出荷の現在の状態を把握できるため、進行中または完了した出荷の絞り込み、レポート作成、概要監視に役立ちます。 入手先 通常、TMSの主要な出荷または運賃オーダーレコードにある概要ステータスフィールドです。 例 計画済み予約済み輸送中配送済みキャンセル済み | |||
| 出荷元国 OriginCountry | 出荷元の国です。 | ||
| 説明 出荷元国は、出荷の輸送が始まる国を示します。出荷元住所情報の一部です。 地理的分析における基本的な属性です。出荷元の国や地域で出荷データを絞り込み、輸送レーンごとのパフォーマンスを把握できます。国際輸送では、通関要件や輸送時間を決める重要な要素でもあります。 重要な理由 輸送プロセスを地理的に分析し、地域ごとのパフォーマンス差の特定、輸送レーンの複雑さの管理、国際物流の分析に役立ちます。 入手先 通常、運賃オーダーの出荷元所在地または出荷地点の住所詳細の一部として保存されます。 例 USAドイツ中国ブラジル | |||
| 実際の集荷日 ActualPickupDate | 「Goods Picked Up」イベントが発生した実際の日時です。 | ||
| 説明 実際の集荷日は、運送会社が出荷元で貨物を実際に引き取り、「Goods Picked Up」アクティビティが完了した時点の記録日時です。 この日付は、出荷の実際の輸送開始を追跡するうえで欠かせません。「定刻集荷率」KPIの算出に使われ、輸送中のサイクルタイムの開始点になります。このデータを分析することで、集荷プロセスの実際の実行状況と、出荷全体のスケジュールへの影響を把握できます。 重要な理由 集荷パフォーマンスの実績値を示し、出荷の実際の輸送開始点となるため、正確なサイクルタイム分析に欠かせません。 入手先 TMSの「Goods Picked Up」イベントから取得します。通常、運送会社のEDIメッセージまたは可視化プラットフォームを通じて更新されます。 例 2023-10-25T14:10:00Z2023-11-15T09:25:00Z2024-02-05T11:45:00Z | |||
| 運賃請求書の不一致 FreightInvoiceDiscrepancyFlag | 運賃請求書の監査中に不一致が見つかったかどうかを示すフラグです。 | ||
| 説明 このブール型属性は、提示または契約された運賃と、運送会社の最終請求書に記載された金額との間に不一致があったかどうかを示します。「true」は、不一致があり、異議申し立てにつながる可能性があることを意味します。 このフラグは、運賃監査および支払いプロセスの分析に欠かせません。「運賃請求書の正確性」KPIを測定し、請求エラーの割合が高い運送会社や輸送レーンを特定できます。不一致の原因を分析することで、運賃管理の改善、運送会社との契約内容の明確化、支払いプロセスの効率化につながります。 重要な理由 運賃請求書の正確性を測定し、請求エラーが頻発する運送会社を特定するとともに、運賃監査および支払いプロセスの効率を分析できます。 入手先 運賃請求書の監査プロセス中に生成されます。TMS内、または専用の運賃監査・支払いシステム内で発生する場合があります。 例 truefalse | |||
輸送管理のアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
| 出荷キャンセル | 運送会社が集荷する前に出荷が終了したことを示します。顧客による注文のキャンセルや社内計画の変更など、さまざまな理由で発生します。 | ||
| 重要な理由 このアクティビティは、処理が正常に完了しなかったことを示す終端点です。キャンセルを分析することで、プロセス失敗の理由を特定し、受注管理や計画上の問題を明らかにできます。 入手先 通常、出荷レコードのステータスが「Cancelled」または「Voided」に変更されたことで記録されます。 取得 出荷の主要ステータスが「Cancelled」に変更された時点の日時を記録します。 イベントタイプ inferred | |||
| 出荷を計画 | ルート、輸送手段、候補となる運送業者が決定される初期計画段階の完了を示します。システムの計画エンジンが、輸送依頼に対する物流上の解決策を生成します。 | ||
| 重要な理由 このマイルストーンによって計画段階が完了します。依頼から計画完了までの期間は、計画の効率と潜在的なボトルネックを示す重要な指標です。 入手先 通常は、出荷レコードのステータスが「Planned」または同様の状態に変わったこと、あるいは運送注文ドキュメントが作成されたことによって特定します。 取得 有効な計画が作成されたことを出荷ステータスが示した時点のタイムスタンプを記録します。 イベントタイプ inferred | |||
| 支払い処理完了 | 出荷ライフサイクルの最後のアクティビティで、運送会社への輸送サービス料金の支払いが完了したことを確認します。このイベントによって、出荷に関する金銭的な処理が完了します。 | ||
| 重要な理由 出荷に関する調達から支払いまでのサイクルを完了するイベントです。支払い期間、運送会社の財務状況、プロセス全体の完了状況を分析するうえで欠かせません。 入手先 通常、別の財務システムまたはERPシステムで生成され、連携を通じてTMSに更新されます。 取得 支払い取引の日時、または請求書ステータスが「Paid」と表示された日付を使用します。 イベントタイプ explicit | |||
| 納品証明の受領 | 納品が正常に完了したことを確認する正式な書類を受領したことを示します。納品先で取得した署名済み船荷証券、写真、または電子署名などが該当します。 | ||
| 重要な理由 納品証明(POD)の受領は、請求書発行と運賃支払いの前提条件です。PODの受領遅延は、受注から入金までのサイクルタイムに直接影響します。 入手先 特定の書類種別がアップロードされたとき、出荷レコードにリンクされたとき、または納品確認ステータスが更新されたときに記録されることが一般的です。 取得 POD書類が添付された時点、または出荷にPOD受領フラグが設定された時点の日時を記録します。 イベントタイプ explicit | |||
| 貨物の納品完了 | このマイルストーンは、出荷が荷受人の納品先に実際に到着したことを示します。このイベントによって、出荷の輸送中の工程が終了します。 | ||
| 重要な理由 輸送における最も重要なKPIである定刻納品実績を測定する主要イベントです。輸送時間と全体のサイクルタイムを算出する際の終点になります。 入手先 通常、運送会社が電子メッセージ、ドライバーからの更新、またはポータルへの入力を通じて納品を確認し、TMSの出荷ステータスを更新します。 取得 出荷イベントログに記録された最終立ち寄り地点への到着日時、または「Delivered」ステータスの日時を使用します。 イベントタイプ explicit | |||
| 貨物の集荷完了 | このアクティビティは、出荷の実際の輸送開始を示します。倉庫や生産拠点などの出荷元で、運送会社が貨物を引き取ったときに発生します。 | ||
| 重要な理由 運送会社の定刻集荷実績や輸送状況の可視化開始時点を測定する重要なマイルストーンです。この段階での遅延は、最終的な納品時刻に直接影響します。 入手先 通常、運送会社またはドライバーからのステータス更新メッセージに基づいて記録されます。EDI取引やモバイルアプリの更新を通じて通知される場合があります。 取得 出荷イベントログに記録された最初の立ち寄り地点からの出発日時、または「Picked Up」ステータスの日時を使用します。 イベントタイプ explicit | |||
| 輸送依頼を受領 | このアクティビティは、輸送プロセスの正式な開始を示します。通常はERPなどの上流システムからの注文をきっかけに新たな輸送ニーズが作成され、新しい出荷レコードが登録された状態を表します。 | ||
| 重要な理由 主要な開始イベントとして、出荷ライフサイクル全体の所要時間を測定できます。依頼の量と発生時期を分析することで、キャパシティ計画とリソース配分に役立ちます。 入手先 通常は、ソースシステムにおける主要な出荷または輸送要件文書の作成タイムスタンプから取得します。 取得 出荷、注文リリース、またはフォワーディング注文レコードの作成タイムスタンプを使用します。 イベントタイプ explicit | |||
| 運送会社との出荷予約完了 | このマイルストーンは、運送会社が輸送依頼を正式に受諾し、出荷を担当することを確約したことを示します。この段階で、輸送に使用する運送会社、料金、スケジュールが確定します。 | ||
| 重要な理由 この確認は調達フェーズの終了と実行フェーズの開始を示します。輸送依頼から予約完了までのサイクルの効率を測定する重要な時点です。 入手先 運送会社の受諾を受信した時点で記録され、通常は出荷ステータスが「Booked」、「Committed」、または「Confirmed」に更新されます。 取得 輸送依頼のステータスが「Accepted」に変わった時点、または出荷ステータスが「Booked」に更新された時点の日時を記録します。 イベントタイプ explicit | |||
| 到着予定時刻の更新 | リアルタイムデータに基づいて、新しい到着予定時刻(ETA)がシステムで生成または受信されたことを示します。状況の変化に応じて、出荷中に複数回発生する場合があります。 | ||
| 重要な理由 ETAの頻繁な変更や大幅な変更から、出荷の変動性や予測可能性を把握できます。これらの更新を分析することで、遅延に先回りして対応し、顧客への連絡を改善できます。 入手先 リアルタイムの追跡情報や更新後の納品予定を提供する可視化プラットフォームまたは運送会社の更新情報から記録されます。 取得 初回予約後に、最終納品のETAフィールドが更新されたすべての時点を記録します。 イベントタイプ explicit | |||
| 通関完了 | 国際輸送では、国境または港で貨物が通関を正常に通過した時点を示します。必要な書類の提出と検査がすべて完了したことを意味します。 | ||
| 重要な理由 通関は、国際物流における大きなボトルネックになる可能性があります。通関にかかった時間を測定することは、遅延の特定とコンプライアンスプロセスの改善に欠かせません。 入手先 通関業者、運送会社、または政府機関のシステムからの直接更新による通知をきっかけに発生します。 取得 通関許可を示すイベントまたはステータス更新の日時を記録します。 イベントタイプ explicit | |||
| 運賃請求書の受領 | このアクティビティは、提供された輸送サービスに対する運送会社の請求書(運賃請求書)を受領したことを示します。出荷ライフサイクルにおける金銭的な精算フェーズが始まります。 | ||
| 重要な理由 納品から請求書受領までの時間は、財務予測や未払費用の計上に影響します。このイベントを起点として、運賃監査と支払いのサイクルタイムを測定します。 入手先 EDI取引、手動入力、または運送会社ポータルからのアップロードによって、システムに新しい請求書レコードが作成されたときに記録されます。 取得 出荷に関連付けられた運賃請求書または運送会社請求書レコードの作成日を使用します。 イベントタイプ explicit | |||
| 運賃請求書の監査完了 | 運送会社の請求書が、契約料金、付帯料金、納品証明と照合して、システムまたは手作業で監査されたことを示します。支払い承認前に請求内容を確認する工程です。 | ||
| 重要な理由 運賃支出の正確性を確保するための重要な財務管理ポイントです。監査プロセスを分析することで、頻発する差異を明らかにし、コスト削減の機会を見つけられます。 入手先 照合プロセスが完了し、出荷の請求ステータスが「Audited」、「Verified」、または同様の状態に変わったときに記録されます。 取得 監査の完了を示すように請求書ステータスが更新された時点の日時を記録します。 イベントタイプ inferred | |||
| 運送会社による輸送依頼の拒否 | 運送会社が出荷の輸送依頼を拒否したことを示します。通常、このイベントをきっかけに、別の運送会社を選定して再度輸送を依頼するやり直しのループが発生します。 | ||
| 重要な理由 輸送依頼の拒否は、遅延やコスト増加の主な原因です。拒否の頻度と理由を分析することで、運送会社の評価表や調達戦略を改善できます。 入手先 運送会社から受信した電子メッセージ、または拒否を示す運送会社ポータル上の手動ステータス更新から記録されます。 取得 輸送依頼のステータスが「Rejected」または同様の状態に更新された日時を特定します。 イベントタイプ explicit | |||
| 運送会社への輸送依頼 | このアクティビティは、計画済みの出荷が特定の運送会社に正式に提示され、受諾を依頼したときに発生します。通常、この操作によって電子メッセージやポータルの更新を通じて運送会社に通知されます。 | ||
| 重要な理由 輸送依頼を追跡することは、運送会社の応答時間や受諾率を分析するうえで欠かせません。同じ出荷に対する輸送依頼が頻繁に行われている場合、運送会社との契約や輸送能力に問題がある可能性があります。 入手先 通常、TMS内で、運送会社に依頼を提示した時点を記録する明示的な取引またはステータス変更として記録されます。 取得 出荷依頼を運送会社に送信した取引の日時を記録します。 イベントタイプ explicit | |||
| 運送業者を選定 | 出荷を担当する特定の輸送サービス提供者、つまり運送業者が正式に選定された状態です。手動での割り当て、自動計画、または入札プロセスの結果として発生します。 | ||
| 重要な理由 このアクティビティは、運送業者の割り当て方針と、輸送パートナーの確保における遅延を理解するうえで重要です。ルートの計画と、提供者の選定を分けて把握できます。 入手先 このイベントは、出荷レコードの運送会社フィールドに値が入力されたとき、または対応する輸送オーダーに運送会社が割り当てられたときに記録されます。 取得 運送会社IDが出荷レコードに初めて関連付けられた時点のイベント日時を特定します。 イベントタイプ explicit | |||
抽出ガイド
準備はできましたか?
まず、現在利用しているプラットフォームに対応するシステム別抽出ガイドを選択してください。または、この汎用テンプレートを使って輸送管理データの構造化に必要な設計図を作成してください。
輸送パフォーマンスを今すぐ最大化
輸送・物流プロセス全体に潜む非効率を見つけ、効率化します。
クレジットカードは不要です。数分で設定できます。