皆さんこんにちは m365fmのマイクロソフトナレッジナゲットへようこそ司会を務めますミルコピーターズです 今日のトピックはサプライチェーンに関わる人なら誰もが一度は耳にした ことがあるものの本当の意味で理解している人は少ないものです それはダイナミクス365トランスポーテーションマネジメント輸送管理です 課題はここにあります顧客が注文を出し在庫が倉庫に置かれ運送業者 が収穫時間を求め顧客は配送を待ちそして後日誰かのデスクに 運賃請求書が届きます長年これらのステップはバラバラのスプレッド シートや電話料金表そしてチーム間の引き継ぎの中で行われてきました そうそこにギャップが生まれるのです 輸送計画が立つ前に倉庫が商品を出荷準備してしまうかもしれません 経理部門は誰がいくら支払うことに合意したのかも知らないまま請求書 を受け取ることになるかもしれませんでは輸送管理とは具体的に何でしょうか 簡単に言えばダイナミクス365サプライチェーンマネジメントに組み込まれた 輸送管理デスクのことです倉庫の搬出口ベンダー顧客そして 運送業者をつなぐものです積載計画の作成ルートや料金の選択商品 の出荷運賃の称号を行いますこのエピソードの終わりにはこれら すべての要素がどのように組み合わさり仕事が楽になるのかがわかる でしょうなぜ輸送管理が必要なのかまずは 基本的な事実からお話ししましょう画面上に受注電票が存在する だけで物理的な商品が勝手に動くわけではありませんトラックトレーラー コンテナあるいは別の移動手段が必要なのです誰かが商品の 出発地と到着地専有スペース出発日時そして輸送コストを把握する 必要があります箱が一つ顧客の元へ届く場面を想像すればそれは 単純に聞こえますしかし実際の企業では同じ日に同じ倉庫から 多くの注文を発送し複数のベンダーから商品を受け取り同時に自社 拠点間で在庫を移動させることもありますそれぞれの移動には 人日付スペースそしてお金が関わっています共通のシステム がなければ各チームは自分の担当部分しか見えません営業は顧客 の注文だけを見ます購買はベンダーへの注文だけを見ます倉庫スタッフ はピッキング梱包入庫保管が必要な品目だけを見ています輸送チーム は他のみんなが作業を終えた後に移動すべき品目のリストを目にする ことになりますそしてそこに遅延や混乱が生じるのです具体的な 例を挙げましょうある倉庫で同じ年向けの顧客注文が10件準備 されているとします輸送を予約する前に誰もこれらの注文を統合 しなければ企業は中途半端な積載のまま何度も便を手配することにな ったり運送業者が到着したのに倉庫側はどの商品を積み込むべき か把握できていないといった事態が起こります商品は準備できている のに移動が計画されていないのですそこで輸送管理がダイナミクス 365サプライチェーンマネジメントの中でその移動の拠り所となる のですこれは追跡番号を入力して地図上で荷物の動きを確認する ような独立した消費者向け配送アプリではありませんそうではなく接続 されたプラットフォーム内に既に存在するビジネス記録と 連携して機能します注文が発生すると商品の移動が必要になります 倉庫作業によって商品が準備されます油配送管理トランスポーテーション マネジメントはそれらの商品が拠点間をどのように移動するか を計画しますオフィスビルの交通整理カウンターのようなものだと 考えてください営業チームが顧客からの依頼をカウンターに 持ち込みます購買部門がベンダーから商品が送られてくるという 知らせを持ち込みます倉庫部門が実際の在庫と搬入口を提供 します交通整理カウンターはそれらの要求を会社の輸送計画 に結びつけます主な方向性は2つあります入荷輸送インバウンド とは商品が自社内へ運ばれてくることを指しますベンダーに商品を 発注しその商品が倉庫に届く必要がありますベンダーが輸送を管理 する場合もあれば自社で手配する場合もありますいずれにせよ 商品を正しい場所に届け到着時に受け入れるための明確な計画が 必要です出荷輸送アウトバウンドとは商品が自社から外へ運ばれて いくことを指します顧客が製品を注文しました倉庫が準備を行い 運送業者や自社の車両が顧客の元へ運びますどちらの流れも移動 を扱いますが出発点が異なります入荷は発注書購買オーダーとベンダー から始まります出荷は受注電表販売オーダーと顧客から始まります 初心者が見落としがちな3つ目のタイプとして振替オーダーがあります 振替オーダーは自社の拠点間で在庫を移動させるものです ある倉庫に在庫が多すぎて別の倉庫でそれが必要な場合などです 顧客の購入は伴いませんが物理的な商品の輸送は依然として必要 です365の輸配送管理では振替オーダーは出荷シナリオに属し 販売オーダーと一緒に計画できます積み込みドッグを想像するとその 理由がよく分かりますパレットが支払いをする顧客に届くか会社 の別の倉庫に届くかに関わらず誰かが車両を手配しスペースを確保 し同じドアから送り出す必要があるのです つまりこの統合されたアプローチによりバラバラのリストや電話 のやり取りという旧来の連鎖が共有情報へと置き換わるのです 注文がシステムに何を移動する必要があるかを伝えます 倉庫が品物を準備します輸配送管理がそのニーズを輸送 計画へと変えます商品の移動が必要になるとシステム にはまず実行可能な配送計画が必要です 積載計画ロードプランニングです 今日のナレッジのヒントは全ての物流チームが必要としている ものの説明が人によって異なることについてです 積載計画について 輸送計画はオーダーまたは出荷のいずれかから開始できます 私はm365のミルコピーターズです早速ですがよくある誤解を解いて おきましょう 配送計画はゼロから始めるものではありません 既に手元にある記録から始まります販売オーダーには顧客が何を 購入したかが記録されているのです 発注書にはベンダーが発送すべき品目が記載されています 出荷はそれらの品目をより具体的な出荷記録としてまとめ他の出荷 と統合できるようにしたものですではどちらを出発点にすべきでしょうか それは記者の業務プロセスによって異なります 注文明細を直接見て早期に計画を立てるチームもあります 出荷を先に作成してから一緒に輸送するものを決めるチームも あります どちらの道も同じ問いに行き着きます 何が同じ車両に乗るべきかという問いです 最もシンプルな定義を説明しましょう 積みにとは計画された物品移動のためのデジタル記録です トラック1台トレーラー1台コンテナ一つあるいは一緒に輸送される 出荷の集まりと考えると良いでしょうこれにより物理的な作業が始まる 前にどの物品をまとめるべきかを一箇所で把握できます ここで多くの人が勘違いしている点があります 積みにとは全ての品目が一つの物理的な箱に収まることを意味 するのではありませんシステムが一つの輸送計画に基づいて 物品をグループ化することを意味します 複数の顧客への出荷が1台のトラックを共有することもあります 大規模な注文であればそれだけでトレーラー1台分になることも ありますベンダーから到着するコンテナ も倉庫で入手する前から積みにとして扱うことができます 重要なのは注文ごとに別々の配送として扱うのをやめることです ある配送業者が金曜日に配達予定の6つの顧客注文を抱えて いると想像してください6つとも同じエリアにあり各注文 はトラックのスペースの一部しか使いません 半分しか埋まっていないトラックを6台送るのは無駄であり6つの 別々の輸送業務が発生してしまいます チームは代わりに互換性のある出荷を一つの積みにまとめる ことができます互換性があるとは合理的に一緒に 輸送できることを意味します同じ倉庫から出発し同時期に配送 が必要で車両の制限内に収まり記者の出荷ルールに従っている 必要がありますシステムは誰かがスプレッドシート でパターンを見つけるのを待つのではなくそれらの記録をまとめる 手助けをしますそのグループには共通の計画が適用 されます倉庫部門はその積みに含まれるべき 対象を確認できます輸送プランナーは合計スペース と重量を確認できますメールやメモ別のファイルで同じ リストを作り直す必要はもうありませんしかしここが重要な点です 物品をまとめることは単に多くのアイテムを一緒に載せること だけではありませんトラックには重量床面積高さとい った制限がありますコンテナにはコンテナなりのルール があります制限を確認せずにシステムでグループ 化すると画面上では問題なく見えても積み込み現場で失敗する ことになりますダイナミクス365ではこれを防ぐ ために積みにテンプレートを使用します積みにテンプレートは車両やコンテナ の種類ごとに再利用可能な制限の設定セットだと考えてください小型配送トラック用大型トレーラー 用輸送コンテナ用といった具合に作成します各テンプレートには重量容積高さ その他汽車が必要とするルールの制限値が保持されますテンプレートを使うと水見作業 を開始する前に積載の形状を定義できますそのため貨物が重すぎたり場所 を取りすぎたりする場合プランナーはそれがその積載 に適していないと判断できますその場合の解決策として2台目の 車両を手配したり別のテンプレートを使ったり貨物の組み合わせを 変えたりすることが考えられますソフトウェアが実際にパレット を持ち上げるわけではありませんが作業を開始する前にチームに対して より明確な計画を提供します組み込み機能の一つに容積ベース の積載計画があります技術用語のように聞こえますが実際 はもっと単純ですこれは積載の構築や提案を行う 際にシステムがテンプレート上の最大高さと重量の制限を使用する ことを意味します平たく言えば貨物が設定した制限 内に収まるかどうかを確認する機能ですこれらの値は固定されているわけ ではありません現場の状況が変わればプランナー は値を上書きできます運送会社が別のトレーラーをよこす こともあるでしょうルートによっては高さの制限が異なる 場合もありますテンプレートが通常のルールを提供し 上書き機能が全てを作り直すことなく例外に対応します先ほどの6件の顧客注文に戻り ましょうそれぞれ単独ではトラックの15% 程度しか埋まらないかもしれません個別に計画すればほとんど空の 車両を6台も出すことになりかねません1つの積載にまとめれば同じ注文 でトラックをほぼ満載にできさらに余裕も生まれますこれこそがスペースの有効活用 です同じ考え方は双方向の物流に適用 できます入荷計画ではベンダーからの入荷品 をまとめて積載を作成します輸送計画が予定入庫と紐付く ため倉庫は到着予定を把握し受け入れ準備を整えられます搬入口に来て初めて配送を知る のではなく入荷チームは計画された記録に基づいて作業できます出荷計画では顧客向けに出荷 する倉庫品を選択し1つの積載にまとめます倉庫は関連性のないリストでは なく積載の詳細に基づいて商品を準備します積載が完了しても移動手段輸送 会社予想されるコストの決定が必要ですルート運送会社そして料金です積載により何を一緒に輸送すべき かが明確になりました次に誰が輸送を担当しどのサービス を利用しその費用をいくらにするかを決める必要があります貨物を輸送する会社を運送会社 キャリアと呼びますそれは貨物の収穫と配送を行う 外部の運送業者かもしれませんあるいは自社でトラックやドライバー を抱えている場合は自社車両部隊を指すこともありますいずれの場合も実際に輸送を 担当するのは運送会社ですたとえ自社所有のトラックであっても 計画は必要であるためこの区別は重要です外部の運送会社を利用する場合 は事前に価格とサービスを取り決めておきます自社車両の場合でも特に配送コスト を顧客注文に反映させる必要があるなら輸送費を計算しておくべき でしょうダイナミクス365トランスポーテーション マネジメントはその両方の状況をサポートします次にルートについて説明しますルートとは週間から配送先までの 計画された経路と選択されたサービスのことですこれは実務上の疑問に対する答え となりますどの倉庫から運送会社が商品を 回収するのかどの顧客や場所が商品を受け取る のかどの運送会社のサービスがその輸送 を担当するのかメインの倉庫から国内の顧客へ 配送される様子を想像してくださいあるルートではコストは安いが時間 がかかる標準的な陸上輸送を利用するかもしれません別のルートではより早くより高価 なサービスを利用するかもしれません出発地と目的地は同じでも輸送 の選択肢が変わるのですレート料金とはその選択に対する 予想される請求額のことですそれは土壇場で入力されるような いい加減な数字ではありませんレートは運送会社との価格契約と 出荷やルートの詳細を組み合わせて算出されます商品の出発地目的地利用するサービス 輸送料などがそれに当たりますつまりルートは商品の移動方法 を示しレートは支払うべき予想額を示しますこの2つの概念はセットです安価なルートでは納品約束を守れない 可能性がありスピードを優先すると注文の採算が取れなくなる可能性 があるからです輸送計画とは単にトラックを 見つけることではなく顧客との約束と会社のコストルールに適した サービスを選ぶことですダイナミクス365にはレートルート アークベンチが含まれています名前は堅苦しいですが目的は シンプルですプランナーが出荷のためのルート とレートの選択肢を並べて比較できる場所を提供します運送会社の表を1つずつ確認し 別のファイルで比較する代わりにその出荷ニーズに関連する選択肢 をまとめて確認できますあるオプションはより早く顧客 に届くかもしれません別のオプションはコストを抑え られるかもしれません全ての顧客がコストよりもスピード を重視するとは限らないためシステムはそれを自動で判断しませんビジネスのやり方は企業によって 異なるからです顧客が緊急配送の料金を支払 っていればより早いルートを選択するのが合理的です別の顧客は配送までの時間が長くても より安い料金の方が適しているかもしれません最終的な判断を下すのは人ですトランスポーテーションマネジメント は合意済みの選択肢と予想コストを提示しどのトレードオフが適切 かをビジネス側で判断します組込モジュールが実際に行うことは 以下の通りですレート情報は記者がダイナミクス 365に入力維持管理するレートテーブルから取得されますこれらのテーブルは合意された運送 会社の価格とルートルールの記録として考えてください特定のサービスやレーンで価格交渉 が成立していればその情報はシステム内に保存され計画立案を支援しますこれはレートが基地の契約に基 づいている場合に非常に有効です例えば特定の運送会社と協力し 決まったルートで配送を行い契約変更時に価格を更新するとい った場合です輸送プランナーは古いメールを探し 回る代わりに既に記録されているレートを使用できますしかしここには多くの人が誤解 している点がありますこの組込モジュールは全ての運送 会社とつながったライブショッピングサイトのように機能するわけではありませんライブフィードから最新の価格を 自動的に取得し広範なネットワーク全体でリアルタイムに比較する ものではありません企業が複数運送業者の料金比較 リアルタイムの予約リンクより詳細な配送状況の更新を必要 とする場合は通常サードパーティーのシステムを接続しますそれは輸送管理システムの欠陥 ではありませんその役割は明確に定義されていますこれらのツールは企業が保持する 運送業者ルート料金情報を利用してサプライチェーン管理内の体系 的な輸送計画を処理しますまた消費者向けの荷物追跡ウェブサイト でもありません追跡番号を入力して地図上で 車両アイコンの動きを追うような使い方はしませんこのモジュールは出荷前及び出荷 に関連するビジネス上の輸送の意思決定に重点を置いていますどの商品をまとめて移動するか どの運送業者が担当するかどのルートを適用するかそして 輸送コストをどうするかといった点です計画が策定されると倉庫部門と輸送 部門がそれを実行に移す必要があります倉庫のドアから顧客の元へ届く まで輸送計画はそれが出荷として実際に実行されて 初めて価値を持ちます出荷注文の場合業務の流れは通常 顧客による購入から始まります販売注文には顧客の要望配送先 到着予定日が記載されていますその注文は出荷データとなり同じ 輸送工程にある他の商品と共に計画された積みにまとめられます次に倉庫部門が引き継ぎます作業員が保管場所から商品を 取り出し梱包し適切な積み込みエリアに運びます出荷データは積みに紐付いている ためチームはどの商品をまとめて出荷すべきかどの運送業者が 回収に来るかを把握できます車両が到着すると商品は倉庫 から運送業者へと引き渡され顧客の元へと輸送されます全てのステップが同一の移動記録 に紐付いています当たり前のことのように聞こえます が以前の方法を想像してみてくださいピッキング作業員は印刷された 注文書に基づいて作業していました輸送計画担当者は別のリストを持っていました積み込み担当者はどの運送業者 がどのパレットを運ぶべきかを確認するためにメールを検索しなければ なりませんでした詳細が一つでも変更されると全員 が更新された情報を受け取る必要がありました輸送管理システムがあれば積み にデータがチーム間の共通記録となります倉庫部門は積みにに関連する品目 を確認でき計画担当者は出荷詳細を収穫手配担当者は計画された 運送業者とサービスを確認できます複数の紙のリストを回覧する 代わりに各担当者は同じ注文や出荷データに紐付いた情報に 基づいて作業します簡単な例を挙げますある倉庫に同じ配送エリア内の 複数の顧客から注文が入ったとしますある顧客は清掃用品のカートン を別の顧客は紙製品を3番目の顧客は少量の機器を注文しましたここの注文にはピッキングと梱包 が必要ですが輸送チームがそれらを完全に別の配送として扱う必要 はありません彼らはそれらの出荷を一つの 計画された積み荷に割り当てます倉庫スタッフは各注文をピッキング して適切に梱包し積み込みエリアへ準備します積載記録はそれらすべての出荷 が一緒に輸送されることを示しています配送業者が到着した際チームは 直前になってバラのパレットをドライバーに合わせようとする のではなく計画された一つの輸送として貨物を引き渡します顧客は引き続き個別の注文を 受け取りますしかし舞台裏では企業はその 配送をより大きな輸送計画の一部として計画していますこの連携により倉庫は先回り して作業したり遅れて届く指示を待ったりするのではなく輸送 チームと協力できるようになります入荷の輸送も方向が逆になる だけでこれと同じ繋がった考え方に従います購買発注書は自社がベンダーから 商品を受け取る予定であることを伝えます自社で輸送を手配する場合計画 された入荷積載によって商品が倉庫に届く前に品目と配送 が結び付けられますベンダーが出荷し運送業者が自社 へ運び倉庫がそれを受け取ります入荷スタッフは何が届くべきか を知っているため準備をすることができます彼らは計画された積み荷とドック に届いた商品を称号できますこれは予告なしにトラックが現れ 誰かがパレットがどの購買発注所に属するかを確認しようとする よりもはるかに明確です転送注文もこのプロセスに適合 しますある拠点から在庫が発送され 別の拠点へ受け入れられます最初の倉庫が品目を準備して出荷 し2番目の倉庫が同じ品目を受け入れ在庫として形状しますその配送先に外部の顧客はいません が企業には依然として両拠点間の明確な引渡しが必要です積載は送信側と受信側の作業 を一つの計画された輸送を中心に結び付けます顧客の配送選択も出荷の決定と 結び付いています顧客が商品を急いで必要とする ために計画担当者がより高速な運送サービスを選択した場合その 選択が出荷と結び付きます配送日に余裕があるため企業が 低コストのサービスを利用する場合その選択も同様に結び付きます担当者は配送コストをその発生 要因となったルートや運送業者の選択にまで遡って追跡できます車両がドックを離れ商品が安全 に到着したとしても作業はまだ完了していません運送業者は後で運賃請求書を送付 するため誰かがそれを確認する必要があります運賃コストと称号商品は倉庫を離れ配送が完了 している場合さえありますその後運送業者からの請求書が 届きますその請求書は確認が必要です記載された金額は輸送業者ルート サービス荷物の詳細予定運賃など企業が以前に計画した輸送の選択 内容と一致している必要があるからです計画段階においてダイナミクス 365は企業の料金情報に基づいて予想される 輸送コストを算出できますこの予想金額があれば運送会社 からの請求を待つ前に企業は判断の基準を持つことができますその後運送会社から輸送の請求書 が届きます運賃の称号とはその請求書をシステム に既に記録されている料金及び出荷の詳細情報と付き合わせる 作業です簡単に言えば会社が期待していた 金額と実際に商品を運んだサービスに対する運送会社の請求額が一致 しているかを確認する作業です計画上の料金が500ドルだった としましょう運送会社からの請求書も500ドル で出荷の詳細も一致しています計画上の記録と請求書が一致 しているためその請求書は確認プロセスをスムーズに通過できますしかし請求書が常に計画と一致 するとは限りません料金表が間違っていたり運送会社 が別のサービスを請求していたりあるいは計画後に荷物が変更されて 説明が必要な料金が発生したりする場合があるからです関連する記録がなければ財務部門 は請求書番号と金額しか見ることができず倉庫や輸送チーム に何が起きたのかを問い合わせる無駄な時間を過ごすことになります輸送管理システムtmsは輸送に関する 決定と称号プロセスを紐付けたままにしますルールに基づいて運送会社の請求書 と予想金額及び計画された出荷情報を比較できます詳細が企業の許容ルール内に収ま っていれば請求書は承認プロセスを進められます詳細が一致しない場合システム は差異があることを担当者に通知し確認を求めますつまり全ての運賃を盲目的に 承認することはないのです輸送プランナーが運送会社による サービス変更を確認する必要があるかもしれませんし財務担当者 が追加料金の理由を調査する必要があるかもしれません重要なのは不一致の全てを間違い だと決めつけることではありません重要なのは支払い前に不一致 に気づくことなのですこれにより運用部門と財務部門 が同一の出荷情報を共有できます輸送チームが運送会社とサービス を選択しますその選択により予想コストが作成 されます倉庫が商品を出荷し財務部門 が計画された記録と照らし合わせて後から届く請求書をチェックします各チームが見ている部分は異なり ますが彼らは連携された情報を見ているのですただし標準機能には明確な適用 範囲があります大規模で高度に自動化された運賃 監査を必要とする企業は多くの場合サードパーティの輸送管理 システムを追加しますそのようなツールを使えばより深い 運送会社との接続やより自動化されたチェックルールを導入できます標準モジュールはサプライチェーン 管理内での予定コストと称号業務を処理しビジネスがさらに高度な 機能を必要とする場合には別のシステムでそれを拡張できますこれらの構成要素を全て組み合わせる ことで全体像が見えてきますどこに適合し何ができないのかが 明らかになるのですでは輸送管理は実際にどこにある のでしょうかそれはフィナンス&オペレーションズ アプリ上で動作するダイナミクス365サプライチェーンマネジメント の中にありますそれがその本拠地です対象となるのは次のような企業 です独自の配送業者記録料金表積載 ルールを使用して入荷顧客への出荷拠点間の在庫転送を体系的 に計画する必要がある企業ですここでよくある混乱を解消して おきましょうビジネスセントラルは異なりますビジネスセントラルにはこの組み込み の輸送管理モジュールは含まれていませんビジネスセントラルを利用していて 輸送計画が必要な場合はサードパーティの輸送管理システムを検討 することになりますそれが境界線です反対側の境界線も明確にして おきましょうこの組み込みモジュールは全ての 配送業者ポータルリアルタイムの交通サービス高度な追跡ツール にとって変わるものではありません多くの配送業者からのリアルタイム 料金より幅広い配送業者の選択しまたは出荷後の詳細な追跡が 必要な場合はサードパーティのtmsを接続しますそれらのツールが社外の活動を 処理しますオフィスビルを想像してみてください輸送管理はそのビル内にある 輸送デスクのようなものですそれは注文倉庫作業財務とつなが っています会社独自の輸送計画を一つにまとめ ます外部の配送業者ツールはそのデスク の外での活動を処理するかもしれません二つの異なる層が連携して動作 するのですまとめです次のナレッジナゲットへ進みましょう最もシンプルな考え方はこうです輸送管理はビジネスの注文を 商品の計画的な移動へと変換しますそしてその移動を会社が後で確認 する運賃コストと結びつけますそれが一連のループですお気に入りのポッドキャスト プラットフォームで登録してくださいダイナミクス365サプライチェーン マネジメントを学習中の方にこのナレッジナゲットを共有しましょう次は倉庫と在庫に関するエピソード をご覧くださいどのような積みに出会っても最終 的には倉庫の扉の向こうにある在庫に依存しているのです