WEBVTT

00:00:00.780 --> 00:00:04.440
皆さんこんにちは m365fmのマイクロソフトナレッジナゲットへようこそ

00:00:04.440 --> 00:00:07.460
司会を務めますミルコピーターズです 今日のトピックはサプライチェーン

00:00:07.460 --> 00:00:09.840
に関わる人なら誰もが一度は耳にした ことがあるものの本当の意味で

00:00:09.840 --> 00:00:12.620
理解している人は少ないものです それはダイナミクス365トランスポーテーション

00:00:12.620 --> 00:00:15.720
マネジメント輸送管理です 課題はここにあります顧客が注文

00:00:15.720 --> 00:00:19.520
を出し在庫が倉庫に置かれ運送業者 が収穫時間を求め顧客は配送を

00:00:19.520 --> 00:00:23.020
待ちそして後日誰かのデスクに 運賃請求書が届きます長年これら

00:00:23.020 --> 00:00:25.600
のステップはバラバラのスプレッド シートや電話料金表そしてチーム

00:00:25.600 --> 00:00:28.380
間の引き継ぎの中で行われてきました そうそこにギャップが生まれるの

00:00:28.380 --> 00:00:30.200
です 輸送計画が立つ前に倉庫が商品

00:00:30.200 --> 00:00:32.720
を出荷準備してしまうかもしれません 経理部門は誰がいくら支払うこと

00:00:32.720 --> 00:00:35.060
に合意したのかも知らないまま請求書 を受け取ることになるかもしれません

00:00:35.060 --> 00:00:39.300
では輸送管理とは具体的に何でしょうか 簡単に言えばダイナミクス365サプライ

00:00:39.300 --> 00:00:41.520
チェーンマネジメントに組み込まれた 輸送管理デスクのことです

00:00:41.520 --> 00:00:45.300
倉庫の搬出口ベンダー顧客そして 運送業者をつなぐものです積載計画

00:00:45.300 --> 00:00:48.900
の作成ルートや料金の選択商品 の出荷運賃の称号を行いますこの

00:00:48.900 --> 00:00:51.860
エピソードの終わりにはこれら すべての要素がどのように組み合わ

00:00:51.860 --> 00:00:53.900
さり仕事が楽になるのかがわかる でしょう

00:00:53.900 --> 00:01:00.140
なぜ輸送管理が必要なのかまずは 基本的な事実からお話ししましょう

00:01:00.140 --> 00:01:03.640
画面上に受注電票が存在する だけで物理的な商品が勝手に動く

00:01:03.640 --> 00:01:07.180
わけではありませんトラックトレーラー コンテナあるいは別の移動手段

00:01:07.180 --> 00:01:11.540
が必要なのです誰かが商品の 出発地と到着地専有スペース出発

00:01:11.540 --> 00:01:15.480
日時そして輸送コストを把握する 必要があります箱が一つ顧客の

00:01:15.480 --> 00:01:18.940
元へ届く場面を想像すればそれは 単純に聞こえますしかし実際の

00:01:18.940 --> 00:01:22.780
企業では同じ日に同じ倉庫から 多くの注文を発送し複数のベンダー

00:01:22.780 --> 00:01:25.840
から商品を受け取り同時に自社 拠点間で在庫を移動させることも

00:01:25.840 --> 00:01:29.500
ありますそれぞれの移動には 人日付スペースそしてお金が

00:01:29.500 --> 00:01:32.600
関わっています共通のシステム がなければ各チームは自分の担当

00:01:32.600 --> 00:01:36.240
部分しか見えません営業は顧客 の注文だけを見ます購買はベンダー

00:01:36.240 --> 00:01:40.240
への注文だけを見ます倉庫スタッフ はピッキング梱包入庫保管が必要

00:01:40.240 --> 00:01:43.440
な品目だけを見ています輸送チーム は他のみんなが作業を終えた後に

00:01:43.440 --> 00:01:46.560
移動すべき品目のリストを目にする ことになりますそしてそこに遅延

00:01:46.560 --> 00:01:50.320
や混乱が生じるのです具体的な 例を挙げましょうある倉庫で同じ

00:01:50.320 --> 00:01:53.140
年向けの顧客注文が10件準備 されているとします輸送を予約

00:01:53.140 --> 00:01:55.880
する前に誰もこれらの注文を統合 しなければ企業は中途半端な積載の

00:01:55.880 --> 00:01:58.180
まま何度も便を手配することにな ったり運送業者が到着したのに

00:01:58.180 --> 00:02:00.340
倉庫側はどの商品を積み込むべき か把握できていないといった事態

00:02:00.340 --> 00:02:03.300
が起こります商品は準備できている のに移動が計画されていないの

00:02:03.300 --> 00:02:06.520
ですそこで輸送管理がダイナミクス 365サプライチェーンマネジメント

00:02:06.520 --> 00:02:10.260
の中でその移動の拠り所となる のですこれは追跡番号を入力して

00:02:10.260 --> 00:02:13.460
地図上で荷物の動きを確認する ような独立した消費者向け配送アプリ

00:02:13.460 --> 00:02:15.780
ではありませんそうではなく接続 されたプラットフォーム内に

00:02:15.780 --> 00:02:18.200
既に存在するビジネス記録と 連携して機能します注文が発生

00:02:18.200 --> 00:02:21.440
すると商品の移動が必要になります 倉庫作業によって商品が準備され

00:02:21.440 --> 00:02:24.340
ます油配送管理トランスポーテーション マネジメントはそれらの商品が

00:02:24.340 --> 00:02:26.600
拠点間をどのように移動するか を計画しますオフィスビルの交通

00:02:26.600 --> 00:02:28.860
整理カウンターのようなものだと 考えてください営業チーム

00:02:28.860 --> 00:02:31.800
が顧客からの依頼をカウンターに 持ち込みます購買部門がベンダー

00:02:31.800 --> 00:02:34.200
から商品が送られてくるという 知らせを持ち込みます倉庫部門

00:02:34.200 --> 00:02:37.220
が実際の在庫と搬入口を提供 します交通整理カウンターは

00:02:37.220 --> 00:02:40.840
それらの要求を会社の輸送計画 に結びつけます主な方向性は2つ

00:02:40.840 --> 00:02:43.940
あります入荷輸送インバウンド とは商品が自社内へ運ばれてくる

00:02:43.940 --> 00:02:47.280
ことを指しますベンダーに商品を 発注しその商品が倉庫に届く必要

00:02:47.280 --> 00:02:50.140
がありますベンダーが輸送を管理 する場合もあれば自社で手配

00:02:50.140 --> 00:02:53.540
する場合もありますいずれにせよ 商品を正しい場所に届け到着時

00:02:53.540 --> 00:02:56.460
に受け入れるための明確な計画が 必要です出荷輸送アウトバウンド

00:02:56.460 --> 00:02:59.680
とは商品が自社から外へ運ばれて いくことを指します顧客が製品

00:02:59.680 --> 00:03:03.700
を注文しました倉庫が準備を行い 運送業者や自社の車両が顧客の

00:03:03.700 --> 00:03:07.200
元へ運びますどちらの流れも移動 を扱いますが出発点が異なります

00:03:07.200 --> 00:03:10.700
入荷は発注書購買オーダーとベンダー から始まります出荷は受注電表

00:03:10.700 --> 00:03:14.080
販売オーダーと顧客から始まります 初心者が見落としがちな3つ目の

00:03:14.080 --> 00:03:17.640
タイプとして振替オーダーがあります 振替オーダーは自社の拠点間

00:03:17.640 --> 00:03:20.940
で在庫を移動させるものです ある倉庫に在庫が多すぎて別の

00:03:20.940 --> 00:03:24.440
倉庫でそれが必要な場合などです 顧客の購入は伴いませんが物理

00:03:24.440 --> 00:03:29.140
的な商品の輸送は依然として必要 です365の輸配送管理では振替

00:03:29.140 --> 00:03:32.560
オーダーは出荷シナリオに属し 販売オーダーと一緒に計画できます

00:03:32.560 --> 00:03:36.000
積み込みドッグを想像するとその 理由がよく分かりますパレット

00:03:36.000 --> 00:03:40.240
が支払いをする顧客に届くか会社 の別の倉庫に届くかに関わらず誰か

00:03:40.240 --> 00:03:44.040
が車両を手配しスペースを確保 し同じドアから送り出す必要がある

00:03:44.040 --> 00:03:45.820
のです つまりこの統合されたアプローチ

00:03:45.820 --> 00:03:48.780
によりバラバラのリストや電話 のやり取りという旧来の連鎖が共有

00:03:48.780 --> 00:03:51.460
情報へと置き換わるのです 注文がシステムに何を移動する

00:03:51.460 --> 00:03:54.140
必要があるかを伝えます 倉庫が品物を準備します

00:03:54.140 --> 00:03:56.800
輸配送管理がそのニーズを輸送 計画へと変えます

00:03:56.800 --> 00:04:00.320
商品の移動が必要になるとシステム にはまず実行可能な配送計画が必要

00:04:00.320 --> 00:04:04.360
です 積載計画ロードプランニングです 今日のナレッジのヒントは全ての

00:04:04.360 --> 00:04:07.100
物流チームが必要としている ものの説明が人によって異なる

00:04:07.100 --> 00:04:11.220
ことについてです 積載計画について 輸送計画はオーダーまたは出荷

00:04:11.220 --> 00:04:14.480
のいずれかから開始できます 私はm365のミルコピーターズです

00:04:14.480 --> 00:04:17.440
早速ですがよくある誤解を解いて おきましょう 配送計画はゼロから

00:04:17.440 --> 00:04:19.900
始めるものではありません 既に手元にある記録から始まります

00:04:19.900 --> 00:04:22.280
販売オーダーには顧客が何を 購入したかが記録されているの

00:04:22.280 --> 00:04:24.200
です 発注書にはベンダーが発送すべき品目

00:04:24.200 --> 00:04:26.660
が記載されています 出荷はそれらの品目をより具体的な

00:04:26.660 --> 00:04:29.060
出荷記録としてまとめ他の出荷 と統合できるようにしたものです

00:04:29.060 --> 00:04:32.600
ではどちらを出発点にすべきでしょうか それは記者の業務プロセスによって

00:04:32.600 --> 00:04:35.060
異なります 注文明細を直接見て早期に計画

00:04:35.060 --> 00:04:37.600
を立てるチームもあります 出荷を先に作成してから一緒に

00:04:37.600 --> 00:04:40.220
輸送するものを決めるチームも あります どちらの道も同じ問いに

00:04:40.220 --> 00:04:42.040
行き着きます 何が同じ車両に乗るべきか

00:04:42.040 --> 00:04:44.360
という問いです 最もシンプルな定義を説明

00:04:44.360 --> 00:04:46.620
しましょう 積みにとは計画された物品移動

00:04:46.620 --> 00:04:49.600
のためのデジタル記録です トラック1台トレーラー1台コンテナ

00:04:49.600 --> 00:04:52.500
一つあるいは一緒に輸送される 出荷の集まりと考えると良いでしょう

00:04:52.500 --> 00:04:55.640
これにより物理的な作業が始まる 前にどの物品をまとめるべきかを

00:04:55.640 --> 00:04:58.060
一箇所で把握できます ここで多くの人が勘違いしている

00:04:58.060 --> 00:05:00.060
点があります 積みにとは全ての品目が一つの

00:05:00.060 --> 00:05:01.740
物理的な箱に収まることを意味 するのではありません

00:05:01.740 --> 00:05:04.140
システムが一つの輸送計画に基づいて 物品をグループ化することを意味

00:05:04.140 --> 00:05:06.020
します 複数の顧客への出荷が1台のトラック

00:05:06.020 --> 00:05:08.360
を共有することもあります 大規模な注文であればそれだけで

00:05:08.360 --> 00:05:09.540
トレーラー1台分になることも あります

00:05:09.540 --> 00:05:12.580
ベンダーから到着するコンテナ も倉庫で入手する前から積みに

00:05:12.580 --> 00:05:15.640
として扱うことができます 重要なのは注文ごとに別々の配送

00:05:15.640 --> 00:05:18.460
として扱うのをやめることです ある配送業者が金曜日に配達

00:05:18.460 --> 00:05:20.420
予定の6つの顧客注文を抱えて いると想像してください

00:05:20.420 --> 00:05:23.460
6つとも同じエリアにあり各注文 はトラックのスペースの一部しか

00:05:23.460 --> 00:05:25.120
使いません 半分しか埋まっていないトラック

00:05:25.120 --> 00:05:27.800
を6台送るのは無駄であり6つの 別々の輸送業務が発生して

00:05:27.800 --> 00:05:29.620
しまいます チームは代わりに互換性のある

00:05:29.620 --> 00:05:31.200
出荷を一つの積みにまとめる ことができます

00:05:31.200 --> 00:05:34.100
互換性があるとは合理的に一緒に 輸送できることを意味します

00:05:34.100 --> 00:05:37.760
同じ倉庫から出発し同時期に配送 が必要で車両の制限内に収まり

00:05:37.760 --> 00:05:39.520
記者の出荷ルールに従っている 必要があります

00:05:39.520 --> 00:05:41.900
システムは誰かがスプレッドシート でパターンを見つけるのを待つ

00:05:41.900 --> 00:05:43.720
のではなくそれらの記録をまとめる 手助けをします

00:05:43.720 --> 00:05:45.920
そのグループには共通の計画が適用 されます

00:05:45.920 --> 00:05:48.200
倉庫部門はその積みに含まれるべき 対象を確認できます

00:05:48.200 --> 00:05:50.680
輸送プランナーは合計スペース と重量を確認できます

00:05:50.680 --> 00:05:53.700
メールやメモ別のファイルで同じ リストを作り直す必要はもうありません

00:05:53.700 --> 00:05:56.840
しかしここが重要な点です 物品をまとめることは単に多くの

00:05:56.840 --> 00:05:58.180
アイテムを一緒に載せること だけではありません

00:05:58.180 --> 00:06:00.860
トラックには重量床面積高さとい った制限があります

00:06:00.860 --> 00:06:02.680
コンテナにはコンテナなりのルール があります

00:06:02.680 --> 00:06:05.740
制限を確認せずにシステムでグループ 化すると画面上では問題なく

00:06:05.740 --> 00:06:07.680
見えても積み込み現場で失敗する ことになります

00:06:07.680 --> 00:06:10.980
ダイナミクス365ではこれを防ぐ ために積みにテンプレートを使用

00:06:10.980 --> 00:06:11.240
します

00:06:11.240 --> 00:06:14.560
積みにテンプレートは車両やコンテナ の種類ごとに再利用可能な制限

00:06:14.560 --> 00:06:15.760
の設定セットだと考えてください

00:06:15.760 --> 00:06:19.380
小型配送トラック用大型トレーラー 用輸送コンテナ用といった具合

00:06:19.380 --> 00:06:20.020
に作成します

00:06:20.020 --> 00:06:23.620
各テンプレートには重量容積高さ その他汽車が必要とするルール

00:06:23.620 --> 00:06:24.500
の制限値が保持されます

00:06:24.500 --> 00:06:27.260
テンプレートを使うと水見作業 を開始する前に積載の形状を

00:06:27.260 --> 00:06:27.680
定義できます

00:06:27.680 --> 00:06:29.960
そのため貨物が重すぎたり場所 を取りすぎたりする場合

00:06:29.960 --> 00:06:31.960
プランナーはそれがその積載 に適していないと判断できます

00:06:31.960 --> 00:06:34.960
その場合の解決策として2台目の 車両を手配したり別のテンプレート

00:06:34.960 --> 00:06:37.200
を使ったり貨物の組み合わせを 変えたりすることが考えられます

00:06:37.200 --> 00:06:39.140
ソフトウェアが実際にパレット を持ち上げるわけではありません

00:06:39.140 --> 00:06:41.840
が作業を開始する前にチームに対して より明確な計画を提供します

00:06:41.840 --> 00:06:45.100
組み込み機能の一つに容積ベース の積載計画があります

00:06:45.100 --> 00:06:48.020
技術用語のように聞こえますが実際 はもっと単純です

00:06:48.020 --> 00:06:51.320
これは積載の構築や提案を行う 際にシステムがテンプレート上の

00:06:51.320 --> 00:06:53.320
最大高さと重量の制限を使用する ことを意味します

00:06:53.320 --> 00:06:56.200
平たく言えば貨物が設定した制限 内に収まるかどうかを確認する

00:06:56.200 --> 00:06:56.560
機能です

00:06:56.560 --> 00:06:58.520
これらの値は固定されているわけ ではありません

00:06:58.520 --> 00:07:00.940
現場の状況が変わればプランナー は値を上書きできます

00:07:00.940 --> 00:07:02.980
運送会社が別のトレーラーをよこす こともあるでしょう

00:07:02.980 --> 00:07:05.140
ルートによっては高さの制限が異なる 場合もあります

00:07:05.140 --> 00:07:08.360
テンプレートが通常のルールを提供し 上書き機能が全てを作り直す

00:07:08.360 --> 00:07:09.440
ことなく例外に対応します

00:07:09.440 --> 00:07:11.640
先ほどの6件の顧客注文に戻り ましょう

00:07:11.640 --> 00:07:14.600
それぞれ単独ではトラックの15% 程度しか埋まらないかもしれません

00:07:14.600 --> 00:07:17.600
個別に計画すればほとんど空の 車両を6台も出すことになりかね

00:07:17.600 --> 00:07:17.800
ません

00:07:17.800 --> 00:07:20.560
1つの積載にまとめれば同じ注文 でトラックをほぼ満載にでき

00:07:20.560 --> 00:07:21.600
さらに余裕も生まれます

00:07:21.600 --> 00:07:23.360
これこそがスペースの有効活用 です

00:07:23.360 --> 00:07:25.720
同じ考え方は双方向の物流に適用 できます

00:07:25.720 --> 00:07:28.900
入荷計画ではベンダーからの入荷品 をまとめて積載を作成します

00:07:28.900 --> 00:07:32.680
輸送計画が予定入庫と紐付く ため倉庫は到着予定を把握し受け

00:07:32.680 --> 00:07:33.680
入れ準備を整えられます

00:07:33.680 --> 00:07:37.280
搬入口に来て初めて配送を知る のではなく入荷チームは計画された

00:07:37.280 --> 00:07:38.520
記録に基づいて作業できます

00:07:38.520 --> 00:07:42.940
出荷計画では顧客向けに出荷 する倉庫品を選択し1つの積載に

00:07:42.940 --> 00:07:43.400
まとめます

00:07:43.400 --> 00:07:46.960
倉庫は関連性のないリストでは なく積載の詳細に基づいて商品

00:07:46.960 --> 00:07:47.560
を準備します

00:07:47.560 --> 00:07:51.740
積載が完了しても移動手段輸送 会社予想されるコストの決定

00:07:51.740 --> 00:07:52.380
が必要です

00:07:52.380 --> 00:07:55.040
ルート運送会社そして料金です

00:07:55.040 --> 00:07:58.280
積載により何を一緒に輸送すべき かが明確になりました

00:07:58.280 --> 00:08:01.880
次に誰が輸送を担当しどのサービス を利用しその費用をいくらにする

00:08:01.880 --> 00:08:02.740
かを決める必要があります

00:08:02.740 --> 00:08:05.420
貨物を輸送する会社を運送会社 キャリアと呼びます

00:08:05.420 --> 00:08:08.600
それは貨物の収穫と配送を行う 外部の運送業者かもしれません

00:08:08.600 --> 00:08:11.360
あるいは自社でトラックやドライバー を抱えている場合は自社車両部隊

00:08:11.360 --> 00:08:12.020
を指すこともあります

00:08:12.020 --> 00:08:15.340
いずれの場合も実際に輸送を 担当するのは運送会社です

00:08:15.340 --> 00:08:18.500
たとえ自社所有のトラックであっても 計画は必要であるためこの区別

00:08:18.500 --> 00:08:19.120
は重要です

00:08:19.120 --> 00:08:22.240
外部の運送会社を利用する場合 は事前に価格とサービスを取り

00:08:22.240 --> 00:08:22.720
決めておきます

00:08:22.720 --> 00:08:26.240
自社車両の場合でも特に配送コスト を顧客注文に反映させる必要がある

00:08:26.240 --> 00:08:27.880
なら輸送費を計算しておくべき でしょう

00:08:27.880 --> 00:08:30.980
ダイナミクス365トランスポーテーション マネジメントはその両方の状況を

00:08:30.980 --> 00:08:31.460
サポートします

00:08:31.460 --> 00:08:33.200
次にルートについて説明します

00:08:33.200 --> 00:08:36.180
ルートとは週間から配送先までの 計画された経路と選択されたサービス

00:08:36.180 --> 00:08:36.560
のことです

00:08:36.560 --> 00:08:38.620
これは実務上の疑問に対する答え となります

00:08:38.620 --> 00:08:40.900
どの倉庫から運送会社が商品を 回収するのか

00:08:40.900 --> 00:08:42.940
どの顧客や場所が商品を受け取る のか

00:08:42.940 --> 00:08:45.460
どの運送会社のサービスがその輸送 を担当するのか

00:08:45.460 --> 00:08:48.440
メインの倉庫から国内の顧客へ 配送される様子を想像してください

00:08:48.440 --> 00:08:51.140
あるルートではコストは安いが時間 がかかる標準的な陸上輸送を

00:08:51.140 --> 00:08:51.840
利用するかもしれません

00:08:51.840 --> 00:08:54.740
別のルートではより早くより高価 なサービスを利用するかもしれません

00:08:54.740 --> 00:08:57.380
出発地と目的地は同じでも輸送 の選択肢が変わるのです

00:08:57.380 --> 00:09:00.300
レート料金とはその選択に対する 予想される請求額のことです

00:09:00.300 --> 00:09:02.700
それは土壇場で入力されるような いい加減な数字ではありません

00:09:02.700 --> 00:09:06.020
レートは運送会社との価格契約と 出荷やルートの詳細を組み合わせて

00:09:06.020 --> 00:09:06.580
算出されます

00:09:06.580 --> 00:09:10.440
商品の出発地目的地利用するサービス 輸送料などがそれに当たります

00:09:10.440 --> 00:09:13.560
つまりルートは商品の移動方法 を示しレートは支払うべき予想

00:09:13.560 --> 00:09:14.140
額を示します

00:09:14.140 --> 00:09:15.820
この2つの概念はセットです

00:09:15.820 --> 00:09:18.820
安価なルートでは納品約束を守れない 可能性がありスピードを優先する

00:09:18.820 --> 00:09:20.660
と注文の採算が取れなくなる可能性 があるからです

00:09:20.660 --> 00:09:24.380
輸送計画とは単にトラックを 見つけることではなく顧客との約束

00:09:24.380 --> 00:09:26.700
と会社のコストルールに適した サービスを選ぶことです

00:09:26.700 --> 00:09:30.340
ダイナミクス365にはレートルート アークベンチが含まれています

00:09:30.340 --> 00:09:32.960
名前は堅苦しいですが目的は シンプルです

00:09:32.960 --> 00:09:36.160
プランナーが出荷のためのルート とレートの選択肢を並べて比較

00:09:36.160 --> 00:09:37.260
できる場所を提供します

00:09:37.260 --> 00:09:40.620
運送会社の表を1つずつ確認し 別のファイルで比較する代わりに

00:09:40.620 --> 00:09:42.960
その出荷ニーズに関連する選択肢 をまとめて確認できます

00:09:42.960 --> 00:09:45.320
あるオプションはより早く顧客 に届くかもしれません

00:09:45.320 --> 00:09:47.420
別のオプションはコストを抑え られるかもしれません

00:09:47.420 --> 00:09:49.480
全ての顧客がコストよりもスピード を重視するとは限らないため

00:09:49.480 --> 00:09:50.780
システムはそれを自動で判断しません

00:09:50.780 --> 00:09:52.880
ビジネスのやり方は企業によって 異なるからです

00:09:52.880 --> 00:09:55.800
顧客が緊急配送の料金を支払 っていればより早いルートを選択

00:09:55.800 --> 00:09:56.580
するのが合理的です

00:09:56.580 --> 00:09:59.680
別の顧客は配送までの時間が長くても より安い料金の方が適している

00:09:59.680 --> 00:10:00.100
かもしれません

00:10:00.100 --> 00:10:02.160
最終的な判断を下すのは人です

00:10:02.160 --> 00:10:04.760
トランスポーテーションマネジメント は合意済みの選択肢と予想コスト

00:10:04.760 --> 00:10:07.560
を提示しどのトレードオフが適切 かをビジネス側で判断します

00:10:07.560 --> 00:10:10.180
組込モジュールが実際に行うことは 以下の通りです

00:10:10.180 --> 00:10:14.140
レート情報は記者がダイナミクス 365に入力維持管理するレートテーブル

00:10:14.140 --> 00:10:14.780
から取得されます

00:10:14.780 --> 00:10:17.920
これらのテーブルは合意された運送 会社の価格とルートルールの記録

00:10:17.920 --> 00:10:18.740
として考えてください

00:10:18.740 --> 00:10:21.940
特定のサービスやレーンで価格交渉 が成立していればその情報はシステム

00:10:21.940 --> 00:10:23.680
内に保存され計画立案を支援します

00:10:23.680 --> 00:10:26.580
これはレートが基地の契約に基 づいている場合に非常に有効です

00:10:26.580 --> 00:10:30.060
例えば特定の運送会社と協力し 決まったルートで配送を行い契約

00:10:30.060 --> 00:10:31.700
変更時に価格を更新するとい った場合です

00:10:31.700 --> 00:10:34.820
輸送プランナーは古いメールを探し 回る代わりに既に記録されている

00:10:34.820 --> 00:10:35.500
レートを使用できます

00:10:35.500 --> 00:10:38.040
しかしここには多くの人が誤解 している点があります

00:10:38.040 --> 00:10:40.720
この組込モジュールは全ての運送 会社とつながったライブショッピング

00:10:40.720 --> 00:10:41.940
サイトのように機能するわけではありません

00:10:41.940 --> 00:10:44.840
ライブフィードから最新の価格を 自動的に取得し広範なネットワーク

00:10:44.840 --> 00:10:46.460
全体でリアルタイムに比較する ものではありません

00:10:46.460 --> 00:10:49.340
企業が複数運送業者の料金比較 リアルタイムの予約リンクより

00:10:49.340 --> 00:10:52.020
詳細な配送状況の更新を必要 とする場合は通常サードパーティー

00:10:52.020 --> 00:10:52.760
のシステムを接続します

00:10:52.760 --> 00:10:55.020
それは輸送管理システムの欠陥 ではありません

00:10:55.020 --> 00:10:57.080
その役割は明確に定義されています

00:10:57.080 --> 00:11:01.340
これらのツールは企業が保持する 運送業者ルート料金情報を利用して

00:11:01.340 --> 00:11:04.240
サプライチェーン管理内の体系 的な輸送計画を処理します

00:11:04.240 --> 00:11:07.320
また消費者向けの荷物追跡ウェブサイト でもありません

00:11:07.320 --> 00:11:11.380
追跡番号を入力して地図上で 車両アイコンの動きを追うような

00:11:11.380 --> 00:11:12.320
使い方はしません

00:11:12.320 --> 00:11:15.520
このモジュールは出荷前及び出荷 に関連するビジネス上の輸送の意思

00:11:15.520 --> 00:11:16.600
決定に重点を置いています

00:11:16.600 --> 00:11:19.180
どの商品をまとめて移動するか どの運送業者が担当するか

00:11:19.180 --> 00:11:21.600
どのルートを適用するかそして 輸送コストをどうするかといった

00:11:21.600 --> 00:11:21.920
点です

00:11:21.920 --> 00:11:25.940
計画が策定されると倉庫部門と輸送 部門がそれを実行に移す必要が

00:11:25.940 --> 00:11:26.220
あります

00:11:26.220 --> 00:11:29.360
倉庫のドアから顧客の元へ届く まで輸送計画はそれが

00:11:29.360 --> 00:11:31.660
出荷として実際に実行されて 初めて価値を持ちます

00:11:31.660 --> 00:11:35.540
出荷注文の場合業務の流れは通常 顧客による購入から始まります

00:11:35.540 --> 00:11:39.680
販売注文には顧客の要望配送先 到着予定日が記載されています

00:11:39.680 --> 00:11:43.060
その注文は出荷データとなり同じ 輸送工程にある他の商品と共に

00:11:43.060 --> 00:11:44.300
計画された積みにまとめられます

00:11:44.300 --> 00:11:46.120
次に倉庫部門が引き継ぎます

00:11:46.120 --> 00:11:49.400
作業員が保管場所から商品を 取り出し梱包し適切な積み込み

00:11:49.400 --> 00:11:50.000
エリアに運びます

00:11:50.000 --> 00:11:52.760
出荷データは積みに紐付いている ためチームはどの商品をまとめて

00:11:52.760 --> 00:11:55.180
出荷すべきかどの運送業者が 回収に来るかを把握できます

00:11:55.180 --> 00:11:58.920
車両が到着すると商品は倉庫 から運送業者へと引き渡され顧客

00:11:58.920 --> 00:11:59.880
の元へと輸送されます

00:11:59.880 --> 00:12:02.240
全てのステップが同一の移動記録 に紐付いています

00:12:02.240 --> 00:12:04.760
当たり前のことのように聞こえます が以前の方法を想像してみてください

00:12:04.760 --> 00:12:07.080
ピッキング作業員は印刷された 注文書に基づいて作業していました

00:12:07.080 --> 00:12:09.160
輸送計画担当者は別のリストを持っていました

00:12:09.160 --> 00:12:11.820
積み込み担当者はどの運送業者 がどのパレットを運ぶべきかを確認

00:12:11.820 --> 00:12:13.520
するためにメールを検索しなければ なりませんでした

00:12:13.520 --> 00:12:16.440
詳細が一つでも変更されると全員 が更新された情報を受け取る必要

00:12:16.440 --> 00:12:16.820
がありました

00:12:16.820 --> 00:12:19.740
輸送管理システムがあれば積み にデータがチーム間の共通記録

00:12:19.740 --> 00:12:20.140
となります

00:12:20.140 --> 00:12:24.140
倉庫部門は積みにに関連する品目 を確認でき計画担当者は出荷

00:12:24.140 --> 00:12:28.040
詳細を収穫手配担当者は計画された 運送業者とサービスを確認できます

00:12:28.040 --> 00:12:31.660
複数の紙のリストを回覧する 代わりに各担当者は同じ注文

00:12:31.660 --> 00:12:34.080
や出荷データに紐付いた情報に 基づいて作業します

00:12:34.080 --> 00:12:35.500
簡単な例を挙げます

00:12:35.500 --> 00:12:39.320
ある倉庫に同じ配送エリア内の 複数の顧客から注文が入ったとします

00:12:39.320 --> 00:12:43.440
ある顧客は清掃用品のカートン を別の顧客は紙製品を3番目の

00:12:43.440 --> 00:12:45.020
顧客は少量の機器を注文しました

00:12:45.020 --> 00:12:47.780
ここの注文にはピッキングと梱包 が必要ですが輸送チームがそれら

00:12:47.780 --> 00:12:49.500
を完全に別の配送として扱う必要 はありません

00:12:49.500 --> 00:12:52.100
彼らはそれらの出荷を一つの 計画された積み荷に割り当てます

00:12:52.100 --> 00:12:55.540
倉庫スタッフは各注文をピッキング して適切に梱包し積み込みエリア

00:12:55.540 --> 00:12:56.080
へ準備します

00:12:56.080 --> 00:12:59.580
積載記録はそれらすべての出荷 が一緒に輸送されることを示しています

00:12:59.580 --> 00:13:02.620
配送業者が到着した際チームは 直前になってバラのパレットを

00:13:02.620 --> 00:13:05.200
ドライバーに合わせようとする のではなく計画された一つの輸送

00:13:05.200 --> 00:13:06.260
として貨物を引き渡します

00:13:06.260 --> 00:13:08.560
顧客は引き続き個別の注文を 受け取ります

00:13:08.560 --> 00:13:12.000
しかし舞台裏では企業はその 配送をより大きな輸送計画の一部

00:13:12.000 --> 00:13:12.840
として計画しています

00:13:12.840 --> 00:13:16.300
この連携により倉庫は先回り して作業したり遅れて届く指示

00:13:16.300 --> 00:13:19.080
を待ったりするのではなく輸送 チームと協力できるようになります

00:13:19.080 --> 00:13:22.820
入荷の輸送も方向が逆になる だけでこれと同じ繋がった考え方

00:13:22.820 --> 00:13:23.360
に従います

00:13:23.360 --> 00:13:26.580
購買発注書は自社がベンダーから 商品を受け取る予定であること

00:13:26.580 --> 00:13:27.080
を伝えます

00:13:27.080 --> 00:13:30.940
自社で輸送を手配する場合計画 された入荷積載によって商品

00:13:30.940 --> 00:13:33.560
が倉庫に届く前に品目と配送 が結び付けられます

00:13:33.560 --> 00:13:37.540
ベンダーが出荷し運送業者が自社 へ運び倉庫がそれを受け取ります

00:13:37.540 --> 00:13:40.360
入荷スタッフは何が届くべきか を知っているため準備をすること

00:13:40.360 --> 00:13:40.860
ができます

00:13:40.860 --> 00:13:43.780
彼らは計画された積み荷とドック に届いた商品を称号できます

00:13:43.780 --> 00:13:46.920
これは予告なしにトラックが現れ 誰かがパレットがどの購買発注

00:13:46.920 --> 00:13:49.160
所に属するかを確認しようとする よりもはるかに明確です

00:13:49.160 --> 00:13:51.520
転送注文もこのプロセスに適合 します

00:13:51.520 --> 00:13:54.940
ある拠点から在庫が発送され 別の拠点へ受け入れられます

00:13:54.940 --> 00:13:59.240
最初の倉庫が品目を準備して出荷 し2番目の倉庫が同じ品目を受け

00:13:59.240 --> 00:14:00.900
入れ在庫として形状します

00:14:00.900 --> 00:14:04.740
その配送先に外部の顧客はいません が企業には依然として両拠点間の

00:14:04.740 --> 00:14:06.200
明確な引渡しが必要です

00:14:06.200 --> 00:14:09.800
積載は送信側と受信側の作業 を一つの計画された輸送を中心

00:14:09.800 --> 00:14:10.800
に結び付けます

00:14:10.800 --> 00:14:13.760
顧客の配送選択も出荷の決定と 結び付いています

00:14:13.760 --> 00:14:16.600
顧客が商品を急いで必要とする ために計画担当者がより高速な

00:14:16.600 --> 00:14:19.480
運送サービスを選択した場合その 選択が出荷と結び付きます

00:14:19.480 --> 00:14:22.500
配送日に余裕があるため企業が 低コストのサービスを利用する場合

00:14:22.500 --> 00:14:24.040
その選択も同様に結び付きます

00:14:24.040 --> 00:14:26.940
担当者は配送コストをその発生 要因となったルートや運送業者の

00:14:26.940 --> 00:14:28.340
選択にまで遡って追跡できます

00:14:28.340 --> 00:14:32.060
車両がドックを離れ商品が安全 に到着したとしても作業はまだ完了

00:14:32.060 --> 00:14:32.560
していません

00:14:32.560 --> 00:14:36.100
運送業者は後で運賃請求書を送付 するため誰かがそれを確認する

00:14:36.100 --> 00:14:37.100
必要があります

00:14:37.100 --> 00:14:38.300
運賃コストと称号

00:14:38.300 --> 00:14:41.720
商品は倉庫を離れ配送が完了 している場合さえあります

00:14:41.720 --> 00:14:44.120
その後運送業者からの請求書が 届きます

00:14:44.120 --> 00:14:46.180
その請求書は確認が必要です

00:14:46.180 --> 00:14:51.100
記載された金額は輸送業者ルート サービス荷物の詳細予定運賃など

00:14:51.100 --> 00:14:54.260
企業が以前に計画した輸送の選択 内容と一致している必要がある

00:14:54.260 --> 00:14:54.580
からです

00:14:54.580 --> 00:14:57.340
計画段階においてダイナミクス 365は企業の

00:14:57.340 --> 00:15:00.040
料金情報に基づいて予想される 輸送コストを算出できます

00:15:00.040 --> 00:15:03.460
この予想金額があれば運送会社 からの請求を待つ前に企業は判断

00:15:03.460 --> 00:15:04.400
の基準を持つことができます

00:15:04.400 --> 00:15:07.080
その後運送会社から輸送の請求書 が届きます

00:15:07.080 --> 00:15:10.620
運賃の称号とはその請求書をシステム に既に記録されている料金及び

00:15:10.620 --> 00:15:12.220
出荷の詳細情報と付き合わせる 作業です

00:15:12.220 --> 00:15:15.280
簡単に言えば会社が期待していた 金額と実際に商品を運んだサービス

00:15:15.280 --> 00:15:17.540
に対する運送会社の請求額が一致 しているかを確認する作業です

00:15:17.540 --> 00:15:19.980
計画上の料金が500ドルだった としましょう

00:15:19.980 --> 00:15:23.840
運送会社からの請求書も500ドル で出荷の詳細も一致しています

00:15:23.840 --> 00:15:27.120
計画上の記録と請求書が一致 しているためその請求書は確認

00:15:27.120 --> 00:15:28.360
プロセスをスムーズに通過できます

00:15:28.360 --> 00:15:31.160
しかし請求書が常に計画と一致 するとは限りません

00:15:31.160 --> 00:15:34.280
料金表が間違っていたり運送会社 が別のサービスを請求していたり

00:15:34.280 --> 00:15:37.240
あるいは計画後に荷物が変更されて 説明が必要な料金が発生したり

00:15:37.240 --> 00:15:38.020
する場合があるからです

00:15:38.020 --> 00:15:40.900
関連する記録がなければ財務部門 は請求書番号と金額しか見る

00:15:40.900 --> 00:15:43.320
ことができず倉庫や輸送チーム に何が起きたのかを問い合わせる

00:15:43.320 --> 00:15:44.400
無駄な時間を過ごすことになります

00:15:44.400 --> 00:15:48.140
輸送管理システムtmsは輸送に関する 決定と称号プロセスを紐付けたまま

00:15:48.140 --> 00:15:48.400
にします

00:15:48.400 --> 00:15:51.920
ルールに基づいて運送会社の請求書 と予想金額及び計画された出荷

00:15:51.920 --> 00:15:52.660
情報を比較できます

00:15:52.660 --> 00:15:56.140
詳細が企業の許容ルール内に収ま っていれば請求書は承認プロセス

00:15:56.140 --> 00:15:56.760
を進められます

00:15:56.760 --> 00:15:59.940
詳細が一致しない場合システム は差異があることを担当者に通知し

00:15:59.940 --> 00:16:00.800
確認を求めます

00:16:00.800 --> 00:16:04.100
つまり全ての運賃を盲目的に 承認することはないのです

00:16:04.100 --> 00:16:07.140
輸送プランナーが運送会社による サービス変更を確認する必要が

00:16:07.140 --> 00:16:10.340
あるかもしれませんし財務担当者 が追加料金の理由を調査する必要

00:16:10.340 --> 00:16:11.080
があるかもしれません

00:16:11.080 --> 00:16:14.180
重要なのは不一致の全てを間違い だと決めつけることではありません

00:16:14.180 --> 00:16:16.720
重要なのは支払い前に不一致 に気づくことなのです

00:16:16.720 --> 00:16:19.500
これにより運用部門と財務部門 が同一の出荷情報を共有できます

00:16:19.500 --> 00:16:21.800
輸送チームが運送会社とサービス を選択します

00:16:21.800 --> 00:16:24.220
その選択により予想コストが作成 されます

00:16:24.220 --> 00:16:27.420
倉庫が商品を出荷し財務部門 が計画された記録と照らし合わせて

00:16:27.420 --> 00:16:29.120
後から届く請求書をチェックします

00:16:29.120 --> 00:16:32.120
各チームが見ている部分は異なり ますが彼らは連携された情報を

00:16:32.120 --> 00:16:32.680
見ているのです

00:16:32.680 --> 00:16:35.340
ただし標準機能には明確な適用 範囲があります

00:16:35.340 --> 00:16:38.900
大規模で高度に自動化された運賃 監査を必要とする企業は多くの

00:16:38.900 --> 00:16:41.200
場合サードパーティの輸送管理 システムを追加します

00:16:41.200 --> 00:16:44.580
そのようなツールを使えばより深い 運送会社との接続やより自動化

00:16:44.580 --> 00:16:45.720
されたチェックルールを導入できます

00:16:45.720 --> 00:16:48.860
標準モジュールはサプライチェーン 管理内での予定コストと称号業務

00:16:48.860 --> 00:16:52.400
を処理しビジネスがさらに高度な 機能を必要とする場合には別の

00:16:52.400 --> 00:16:53.560
システムでそれを拡張できます

00:16:53.560 --> 00:16:57.160
これらの構成要素を全て組み合わせる ことで全体像が見えてきます

00:16:57.160 --> 00:17:00.220
どこに適合し何ができないのかが 明らかになるのです

00:17:00.220 --> 00:17:02.840
では輸送管理は実際にどこにある のでしょうか

00:17:02.840 --> 00:17:05.500
それはフィナンス&オペレーションズ アプリ上で動作するダイナミクス

00:17:05.500 --> 00:17:07.200
365サプライチェーンマネジメント の中にあります

00:17:07.200 --> 00:17:08.580
それがその本拠地です

00:17:08.580 --> 00:17:10.540
対象となるのは次のような企業 です

00:17:10.540 --> 00:17:15.520
独自の配送業者記録料金表積載 ルールを使用して入荷顧客への

00:17:15.520 --> 00:17:19.300
出荷拠点間の在庫転送を体系的 に計画する必要がある企業です

00:17:19.300 --> 00:17:21.920
ここでよくある混乱を解消して おきましょう

00:17:21.920 --> 00:17:23.560
ビジネスセントラルは異なります

00:17:23.560 --> 00:17:26.900
ビジネスセントラルにはこの組み込み の輸送管理モジュールは含まれていません

00:17:26.900 --> 00:17:29.720
ビジネスセントラルを利用していて 輸送計画が必要な場合はサード

00:17:29.720 --> 00:17:31.560
パーティの輸送管理システムを検討 することになります

00:17:31.560 --> 00:17:32.900
それが境界線です

00:17:32.900 --> 00:17:35.220
反対側の境界線も明確にして おきましょう

00:17:35.220 --> 00:17:37.820
この組み込みモジュールは全ての 配送業者ポータルリアルタイム

00:17:37.820 --> 00:17:40.180
の交通サービス高度な追跡ツール にとって変わるものではありません

00:17:40.180 --> 00:17:43.400
多くの配送業者からのリアルタイム 料金より幅広い配送業者の選択

00:17:43.400 --> 00:17:46.660
しまたは出荷後の詳細な追跡が 必要な場合はサードパーティのtms

00:17:46.660 --> 00:17:47.260
を接続します

00:17:47.260 --> 00:17:49.440
それらのツールが社外の活動を 処理します

00:17:49.440 --> 00:17:51.160
オフィスビルを想像してみてください

00:17:51.160 --> 00:17:54.120
輸送管理はそのビル内にある 輸送デスクのようなものです

00:17:54.120 --> 00:17:56.900
それは注文倉庫作業財務とつなが っています

00:17:56.900 --> 00:17:59.340
会社独自の輸送計画を一つにまとめ ます

00:17:59.340 --> 00:18:02.880
外部の配送業者ツールはそのデスク の外での活動を処理するかもしれません

00:18:02.880 --> 00:18:05.420
二つの異なる層が連携して動作 するのです

00:18:05.420 --> 00:18:06.260
まとめです

00:18:06.260 --> 00:18:08.280
次のナレッジナゲットへ進みましょう

00:18:08.280 --> 00:18:10.400
最もシンプルな考え方はこうです

00:18:10.400 --> 00:18:13.840
輸送管理はビジネスの注文を 商品の計画的な移動へと変換します

00:18:13.840 --> 00:18:17.400
そしてその移動を会社が後で確認 する運賃コストと結びつけます

00:18:17.400 --> 00:18:18.960
それが一連のループです

00:18:18.960 --> 00:18:21.540
お気に入りのポッドキャスト プラットフォームで登録してください

00:18:21.540 --> 00:18:24.680
ダイナミクス365サプライチェーン マネジメントを学習中の方にこの

00:18:24.680 --> 00:18:26.160
ナレッジナゲットを共有しましょう

00:18:26.160 --> 00:18:29.000
次は倉庫と在庫に関するエピソード をご覧ください

00:18:29.000 --> 00:18:31.340
どのような積みに出会っても最終 的には倉庫の扉の向こうにある

00:18:31.340 --> 00:18:32.140
在庫に依存しているのです