WEBVTT

00:00:00.000 --> 00:00:06.660
ある顧客が来月自転車を100台欲しがっていると想像してください フレームの到着は遅れますホイールは別の倉庫にありますさらに組み立てラインは今後2週間

00:00:06.660 --> 00:00:12.520
すでに作業で埋まっていますでは何を購入しますか何を組み立てますか 何を移動させますかそして各部品はいつ必要になりますか

00:00:12.520 --> 00:00:19.580
なるほど m 365 fm のミルコペタスです今回の知識のかけらはダイナミクス365のマスタープランニングについてです

00:00:19.580 --> 00:00:26.960
これは舞台裏でそれらの疑問を解決するサプライチェーン管理の機能です あなたのビジネスをストックルームが併設されたオフィスビルのように考えてみてください

00:00:26.960 --> 00:00:34.840
注文は一つのドアから入ってきます在庫は棚に置かれます サプライヤーが積み込みドックに商品を運び込みます生産部門が部品を完成品へと変えていきます

00:00:34.840 --> 00:00:45.640
マスタープランニングは各チームが個別のリストを抱えるのではなくビル全体を俯瞰します 今日は顧客からの自転車1台の注文が供給アクションに至るまでを追っていきます

00:00:45.640 --> 00:00:55.520
ダイナミクス365は企業がスプレッドシートではなく計画を必要とする理由を示しています 統合された計画ツールが存在する前は企業はバラバラの情報に基づいて動いていました

00:00:55.520 --> 00:01:02.600
営業は顧客の注文を一つの場所にまとめていました 倉庫チームは別のシステムで在庫を確認し購買はサプライヤーの納期をメールやスプレッドシートで管理し

00:01:02.600 --> 00:01:08.100
生産部門は今週工場で何を製造できるか独自のメモを保持していました どのリストも単体で見れば正しいように見えました

00:01:08.100 --> 00:01:13.800
問題は誰かが顧客の質問に答えようとした時に始まりました 約束した期日までに100台の自転車を納品できますか

00:01:13.800 --> 00:01:21.440
アイオラタフツ倉庫に今日完成した自転車が30台あると想像してください 良いスタートのように聞こえますが注文にはあと70台足りません

00:01:21.440 --> 00:01:29.180
そしてその70台の自転車にはフレームホイールチェーンシートボルト 梱包材組み立てる人員そして適切な機械での時間が必要です

00:01:29.180 --> 00:01:37.140
単純な在庫数は今たなにあるものしか教えてくれません それだけでは生産に必要な時までに70台分のフレームが到着するかはわかりません

00:01:37.140 --> 00:01:45.680
ホイールがすでに発注済みの注文でカバーされているかもわかりません そして納期までにすべてを組み立てる十分な時間が工場にあるかどうかもわかりません

00:01:45.680 --> 00:01:54.000
ここからが計画が単なる計算以上のものになるポイントです 顧客が自転車を100台注文するとシステムは100台という需要を見ます

00:01:54.000 --> 00:01:59.480
そこからすでに利用可能な30台を差し引きます そして残りの70台のために何をすべきかを追跡します

00:01:59.480 --> 00:02:03.940
完成した自転車を構成する部品をチェックします すでに配送中の供給品をチェックします

00:02:03.940 --> 00:02:08.820
そしてすべての作業に付随する日付をチェックします 部品が一つ足りないだけで答え全体が変わってしまうことがあります

00:02:08.820 --> 00:02:15.820
ホイールとシートは十分にあるかもしれません しかしフレームの調達にサプライヤーから2週間かかる場合組み立ての前日に購入しても間に合いません

00:02:15.820 --> 00:02:22.340
スプレッドシート上では注文可能に見えてもすべての部品をカレンダーに当てはめるとそうはいきません しかもそのカレンダーは常に変化し続けます

00:02:22.340 --> 00:02:29.240
サプライヤーが納期を早めるかもしれません別の受注によって空きがあると思っていた在庫が確保されるかもしれません 製造業務が予定より遅れるかもしれません

00:02:29.240 --> 00:02:35.800
これらの詳細が別々の場所に存在すると担当者は電話やメール確認作業に終われ それぞれの計画を更新するだけで時間を費やしてしまいます

00:02:35.800 --> 00:02:41.660
ダイナミクス365マスタープランニングは現在の需要と供給を一元的な計画ビューに統合します

00:02:41.660 --> 00:02:49.780
顧客からの注文手持ち在庫入荷予定そして製造情報をまとめて読み取ります その上で供給が需要をどこまで満たしどこに不足があるのかを算出します

00:02:49.780 --> 00:02:55.500
各チームに手作業で関連付けを求めるのではなくシステムが把握可能な情報に基づいて 推奨アクションを作成します

00:02:55.500 --> 00:03:03.140
もちろんシステムがビジネスを自動的に運営するわけではありません プランナーが提案を確認し疑問を投げかけ何を実行すべきかを決定します

00:03:03.140 --> 00:03:09.220
しかしプランナーはバラバラナリストの山ではなく統合された全体像から作業を開始できます スプレッドシートは写真のようなものだと考えてください

00:03:09.220 --> 00:03:16.820
特定の瞬間の在庫を捉えるものであり役に立つこともあります マスタープランニングは数量気付け入荷予定将来の需要を結びつけるため

00:03:16.820 --> 00:03:23.520
寄り先を見越したスケジュールに近いものです 次のステップとして計画プロセスが読み取れる様々な種類の需要を分類します

00:03:23.520 --> 00:03:31.720
3つの計画モードダイナミクス365には重要な特徴があります 計画の方法は一つではありません

00:03:31.720 --> 00:03:41.500
使用する計画モードはビジネスで解決すべき課題によって異なります 今週の顧客注文に対応する企業と来シーズンに向けた資材を準備する企業では必要となる

00:03:41.500 --> 00:03:44.820
ビューが全く異なります 最初のモードはマスタープランニングです

00:03:44.820 --> 00:03:53.740
これは日々の計画であり賞味書容量を算出します つまりシステムが必要なものを把握し手元にある供給や受領予定の供給を差し引くということです

00:03:53.740 --> 00:04:01.980
実際の事業活動顧客からの受注サプライヤーへの発注済注文 製造現場の製造オーダー倉庫の手持ち在庫を読み取ります

00:04:01.980 --> 00:04:08.600
ある製品について100ユニットの顧客注文を想定してください 倉庫に30ユニットの在庫がありそれを注文に当てることができます

00:04:08.600 --> 00:04:13.240
システムはその30ユニットを供給とみなすため 100ユニットすべてを改めて購入または製造するよう提案することはありません

00:04:13.240 --> 00:04:18.160
結果として不足している70ユニットが必要量として算出されます その残りの70が賞味書容量です

00:04:18.160 --> 00:04:26.640
実際の計画には棚にある在庫以上のものを含めることができます 例えば顧客の希望納期までにさらに20ユニットがサプライヤーから到着する予定かもしれません

00:04:26.640 --> 00:04:33.840
その場合システムはそれら20個も考慮に入れ埋めるべき不足分をさらに小さくします しかし答えを左右するのは日付です

00:04:33.840 --> 00:04:41.300
もしその20個が顧客の希望納期を過ぎて到着するならあまり役には立ちません 物理的に受け取れたとしても特定のニーズに対しては手遅れだからです

00:04:41.300 --> 00:04:47.740
マスタープランニングは数量とタイミングの両方を考慮します 単なる合計在庫数だけでは誤った答えを導き出す可能性があります

00:04:47.740 --> 00:04:55.320
多くの企業にとってこれが最も頻繁に実行される計画です マイクロソフトはマスタープランニングを通常1週間から6ヶ月をカバーする短期プロセスと呼んでいます

00:04:55.320 --> 00:05:04.100
正確な期間は供給が届くまでの時間や生産が完了するまでの時間によって異なります 単純な地元の品物を購入する企業なら数週間先を計画するだけで良いでしょう

00:05:04.100 --> 00:05:10.540
しかし部品調達に数ヶ月かかるメーカーは製品の最長リードタイムを見越して さらに先まで計画する必要があります

00:05:10.540 --> 00:05:17.860
そうでなければ計画実行時に不足が判明してもそれを回避するには手遅れになってしまいます 2つ目のモードはフォーキャストプランニング需要予測計画です

00:05:17.860 --> 00:05:28.940
確定した受注から始めるのではなく予想される需要からスタートします 営業チームが夏場の自転車販売像を見込んでいる場合や小売業者が年後半の大型反則で需要喚起を期待する場合などがこれに当たります

00:05:28.940 --> 00:05:40.000
これらは確定注文ではなくチームの予想に基づく予測です 顧客からの注文を待っていては原材料の購入や工場の手配生産能力の準備に時間が足りなくなる可能性があるため非常に役立ちます

00:05:40.000 --> 00:05:50.720
長納期品は最終的な顧客注文がまだ届いていなくても早い段階で決断を下す必要があります フォーキャストプランニングはグロス要件を計算しますつまり予想される需要量から開始するということです

00:05:50.720 --> 00:05:58.120
7月に500台の自転車需要が予測される場合計画ではまず500台の全必要数を確認し その予想ニーズに基づいて動きます

00:05:58.120 --> 00:06:04.840
ビジネスに押し寄せる将来のワークロードを先読みするものと考えてください その予想ボリュームに合わせて材料や生産能力を計画できます

00:06:04.840 --> 00:06:10.460
サプライヤーとの早期交渉倉庫スペースの確保あるいは生産能力が予想不可に対応できるかの 確認などが必要になるでしょう

00:06:10.460 --> 00:06:15.080
予測はあくまで予測であり状況は変化する可能性がありますし実際の売上と一致しない こともあります

00:06:15.080 --> 00:06:21.900
それでも確定済みの注文のみに基づく計画よりも長期的な視点を提供してくれます そして部門間インターカンパニーマスタープランニングがあります

00:06:21.900 --> 00:06:30.800
これはある法人組織が別の法人組織から供給を受ける必要がある場合に機能します 例えばグループ内の一社が製品を製造し別の会社がそれを他国の顧客に販売するといったケースです

00:06:30.800 --> 00:06:37.320
販売側の会社は顧客の需要を把握します 製造側の会社はその需要によって生じる供給要件を確認する必要があります

00:06:37.320 --> 00:06:44.340
インターカンパニーマスタープランニングはまだ確定注文になっていない計画上の需要と供給を含め 会社間の境界を超えてそれらのニーズを結びつけます

00:06:44.340 --> 00:06:55.660
つまり会社は単独で事業を行っているかのように計画を立てることはありません 販売会社は製造会社からの供給を計画でき製造会社はその需要を支えるために必要な資材と生産能力を把握できます

00:06:55.660 --> 00:07:03.340
このリンクによりある法人から別の法人へと計画シグナルが伝達されます 各モードは需要から始まりますしかし需要は最初のシグナルにすぎません

00:07:03.340 --> 00:07:11.340
一つの完成品が買いレベルにある多くの部品の需要連鎖を生み出す可能性があるからです 一つの注文から供給の連鎖へ自転車を例に見ていきましょう

00:07:11.340 --> 00:07:18.940
マスタープランニングの真の役割がここで始まります 顧客が70台の自転車を注文し特定の期日までの納品を求めていると想像してください

00:07:18.940 --> 00:07:28.600
その日付は単なるメモではなく営業チームにとっての重要な指標となります 自転車を倉庫から出荷するために何が必要かを問い計画を逆算する起点となるのです

00:07:28.600 --> 00:07:34.940
完成した自転車は最初の層にすぎません ダイナミクス365は部品表ボムボムを確認します

00:07:34.940 --> 00:07:43.340
ボムは自転車1台分のレシピだと考えてください そこにはフレームホイールチェーンサドルハンドルブレーキボルトなど組み立てに必要なあらゆる部品が記載されています

00:07:43.340 --> 00:07:50.320
70台の注文があれば計画機能がその注文を展開し70台分に必要な部品を算出します それはあっという間に長いリストになります

00:07:50.320 --> 00:07:55.600
70台のフレーム140本のホイール70本のチェーン70個のサドルそして何百もの小さなボルトが必要になるでしょう

00:07:55.600 --> 00:08:04.800
プランナーが手作業で一つ一つ部品を数える必要はありません ボムによってダイナミクス365に構造が与えられるためシステムは完成者から各コンポーネントに至るまでの需要を追跡できるのです

00:08:04.800 --> 00:08:09.600
しかし部品だけでは自転車は作れません 製造には工程ルートも必要です

00:08:09.600 --> 00:08:16.580
工程とはフレームの組み立てホイールの取り付け ブレーキの点検完成品の梱包といった製品を作るために必要な作業ステップを指します

00:08:16.580 --> 00:08:24.800
各ステップにはリソースが必要になる場合があります リソースとは組み立てライン作業台塗装ブース機械あるいは適切なスキルを持つ人員グループのことです

00:08:24.800 --> 00:08:32.700
計画機能はこの情報を利用して適切なタイミングで作業を割り当てます 製造を即座に行われるものとして扱うのではなくここから日付を逆算し始めます

00:08:32.700 --> 00:08:38.920
顧客が金曜日に自転車を必要とするなら倉庫での梱包出荷のために木曜日には製造オーダーを完了させる必要があります

00:08:38.920 --> 00:08:48.380
組み立ては火曜日に開始する必要があるかもしれません フレームやホイールは月曜日までに到着している必要がありますサプライヤーのホイール納品に10日かかるなら発注書はさらに早く出さなければなりません

00:08:48.380 --> 00:08:56.160
顧客の希望日が一連の日程の鎖を作り出すのです ダイナミクス365はその鎖を逆方向にたどりリードタイムを考慮して計画を立てます

00:08:56.160 --> 00:09:06.520
リードタイムとは部品の配送倉庫での商品の移動工場での作業完了など何かにかかる時間を指します 部品の遅延は全ての工程に影響を及ぼす可能性があります

00:09:06.520 --> 00:09:14.540
システムが在庫に70個のフレームを見つけたと仮定します また組み立て開始までに納品予定の140個のホイールに対する未完了の購買発注も確認します

00:09:14.540 --> 00:09:23.580
フレーム分はすでに足りているためその供給でホイールの必要数が賄われます 次にチェーンを確認します手元に40個しかチェーンがなく残りの30個を補充する購買発注もないかもしれません

00:09:23.580 --> 00:09:30.580
計画機能は不足分を検知しそれを補うための提案を作成します 完成した自転車その階部品および中間のあらゆる作業に対しても同様のチェックが行われます

00:09:30.580 --> 00:09:37.200
供給源はすでにいくつか存在しています 利用可能な在庫があればニーズを満たすことができます商品が間に合えば未完了の購買発注で対応可能です

00:09:37.200 --> 00:09:44.380
工場での作業が予定通り終われば未完了の製造オーダーで対応可能です これらの供給源で需要を賄えない場合計画機能は計画オーダーを作成します

00:09:44.380 --> 00:09:50.880
計画購買オーダーはサプライヤーからの購入を提案するものです 計画製造オーダーは自社内での製造を提案するものです

00:09:50.880 --> 00:09:57.720
計画転送オーダーはある拠点や倉庫から別の場所へ在庫を移動することを提案します これらはあくまで提案であり確定事項ではありません

00:09:57.720 --> 00:10:07.480
ダイナミクス365が勝手にサプライヤーへ発注を送ったり工場の作業を始めたりすることはありません システムは確認可能なデータに基づいてプランナーに推奨される数量と日付を提示します

00:10:07.480 --> 00:10:12.780
サプライヤーが適切かその日付は可能かそして会社として承認すべきか 最終的には人が判断します

00:10:12.780 --> 00:10:17.620
自転車の注文で小さな問題が発生したと想像してください ホイールが一つ足りない以外はすべて準備が整っています

00:10:17.620 --> 00:10:24.000
フレームチェーンシートそしてほぼすべてのホイールは計画された供給でカバーされています しかしホイールが一つ組み立ての必要日より1日遅れて到着します

00:10:24.000 --> 00:10:31.000
そのホイールがなければ自転車を完成させることができません 倉庫は部品でいっぱいのように見えてもマスタープランニングは不足の根本原因を追跡します

00:10:31.000 --> 00:10:38.100
プランナーはこの不足が顧客の注文自体から生じたものではないことを確認できます 原因はホイールの購買発注におけるサプライヤーの納品日にあることがわかります

00:10:38.100 --> 00:10:43.880
これによりプランナーは具体的な対策を講じることができます 早めの納品を依頼するか他の供給元を探すか製造日程を変更します

00:10:43.880 --> 00:10:47.880
計画機能は供給を提案できます しかし次に問うべきことも同じくらい重要です

00:10:47.880 --> 00:10:54.140
なぜダイナミクス365はこの供給をあの需要に紐付けたのでしょうか 準所要量計算すなわち計画の対話を確認します

00:10:54.140 --> 00:11:01.760
そのためプランナーは準所要量ページを使ってその繋がりを深く掘り下げます このページでは特定の品目に関する計画の全一冊を一箇所でまとめて確認できます

00:11:01.760 --> 00:11:09.200
品目を必要とするすべての需要とそれを満たす供給源をそれぞれの日付とともに一覧で表示します 自転車のホイールを例に挙げてみましょう

00:11:09.200 --> 00:11:19.220
画面上部でそのホイールに関連する拠点や倉庫を選択します すると下段にダイナミクス365が販売購買在庫生産といった関連するすべての取引を一つのリストに表示します

00:11:19.220 --> 00:11:27.860
需要は利用可能な在庫に対する負の数値として表示されます その需要は様々な発生源から生まれます顧客からの自転車の注文により販売オーダーでホイールが必要になります

00:11:27.860 --> 00:11:32.720
予測によって将来の需要が見込まれます 製造計画のために生産オーダーでホイールが必要になります

00:11:32.720 --> 00:11:37.820
また別の倉庫から在庫の要求があると移動オーダーによって需要が発生します 各業はシンプルな問いに対する答えを示しています

00:11:37.820 --> 00:11:44.080
誰がこの品目を必要としているのかいくつ必要なのか そしていつ必要なのか単純に聞こえますがこれはよくある間違いを防ぐのに役立ちます

00:11:44.080 --> 00:11:51.420
合計数量を見て特定の顧客やジョブ一つだけのものと思い込みがちですが 実際には同じ品目が異なる日付の複数のオーダーを支えている場合があります

00:11:51.420 --> 00:11:59.720
供給側には手持ち在庫やすでに入庫済みの在庫があります さらにベンダーからの購買オーダー生産計画に基づく生産オーダー

00:11:59.720 --> 00:12:09.520
倉庫間の移動そしてシステムが推奨する未作成の計画オーダーなどがあります ページ上のすべては日付順に並べ替えられますリストをスクロールすると利用可能な在庫数量の変化を確認できます

00:12:09.520 --> 00:12:16.000
月の始めには在庫が十分でも生産オーダーで部品が消費されれば減少し その後サプライヤーからの納品があれば再び増加します

00:12:16.000 --> 00:12:22.800
タイミングが結果を左右します 例えば月曜日に倉庫にホイールが100個あっても火曜日に生産オーダーで80個必要になり

00:12:22.800 --> 00:12:30.180
水曜日に別の顧客から30個の注文が入るとします 金曜日に50個のホイールが届く予定の購買オーダーがあっても合計需要は在庫を上回ります

00:12:30.180 --> 00:12:36.080
金曜の納品では水曜日の不足分を補うことはできません この日ごとのビューを見ればシステムがなぜそのような提案をするのかがわかります

00:12:36.080 --> 00:12:43.240
ダイナミクス365は単に適当にホイールを追加するよう求めているわけではありません 利用可能な供給がカバーすべき需要を下回るタイミングを正確に把握しているのです

00:12:43.240 --> 00:12:49.480
ここでより具体的な疑問が浮かぶかもしれません どの供給ラインがどの需要ラインをカバーしているのかその接続をペギングと呼びます

00:12:49.480 --> 00:12:57.440
ペギングとはダイナミクス365における需要と供給を結びつける独自の計画リンクです これは自転車の生産オーダーのようなニーズとホイールの購買オーダーや計画購買オーダーといった

00:12:57.440 --> 00:13:02.420
それを補うための供給源を結びつけます システムは計画計算の過程でこのリンクを構築します

00:13:02.420 --> 00:13:10.040
需要が変化すれば計画計算によってその繋がりを再計算できます 例えば顧客が配送日を変更したり入庫予定の購買オーダーが遅延したりする場合です

00:13:10.040 --> 00:13:17.100
その場合ペギングは別の供給源を指定するか不足が生じる場所に新しい計画オーダーを作成します 全体の繋がりを追跡するのに役立ちます

00:13:17.100 --> 00:13:24.520
販売注文から開始しそれに関連する製造オーダーを確認し必要な部品までたどってそれらを調達する 購買注文を見つけます時にはより詳細な制御が必要になることもあります

00:13:24.520 --> 00:13:30.040
そこで登場するのがマーキングです マーキングとは供給トランザクションと需要トランザクションを手動で関連付ける機能です

00:13:30.040 --> 00:13:38.480
計画で自由に割り当てさせるのではなく特定の供給が特定の需要を確実に満たすよう システムに指示します関連する2つのレコードにラベルを貼るようなものだと考えてください

00:13:38.480 --> 00:13:45.280
特定の製造オーダーのために仕入れた車輪の購買注文がある場合 その車輪を該当する製造オーダーに対してマークすることができます

00:13:45.280 --> 00:13:52.000
計画は通常のペギングリンクよりもこの関係を強固に尊重します とはいえマークされた供給が最も強力なつながりというわけではありません

00:13:52.000 --> 00:13:58.020
予約の方がより強力です 在庫や入庫予定の供給を特定の需要のために予約すると強力なリンクが作成されます

00:13:58.020 --> 00:14:06.640
その数量は選択された販売注文製造オーダーまたはその他の需要のために確保されます またマスタープランニングは通常のペギングやマーキングよりも予約を優先して扱います

00:14:06.640 --> 00:14:17.280
在庫に10個の車輪があってもそれらが緊急の修理オーダーのために予約されていると想像してください 後から入った顧客オーダーも車輪を必要とするかもしれませんが計画は予約済みの10個を自由に使用できる在庫として扱うことはできません

00:14:17.280 --> 00:14:24.880
予約によって他の用途に割り当てられているため別の供給を見つけるか追加の供給を提案する必要があります このようにペギングマーキング予約は3つのレベルの接続を提供します

00:14:24.880 --> 00:14:31.200
ペギングはシステムの自動マッチングです マーキングはより固定された手動のリンクです予約は供給を特定のニーズにロックします

00:14:31.200 --> 00:14:37.400
これら3つの中で最も強力なものです これらのリンクが読めるようになれば計画オーダーは理由不明な指示には見えなくなります

00:14:37.400 --> 00:14:45.880
次の疑問はこの計画ビューがどの程度の頻度で変化しダイナミクス365がどれほど迅速に計算できるかということです 静的プラン動的プランそしてプランニング最適化についてです

00:14:45.880 --> 00:14:53.400
所要領ページには計画結果が表示されますが全てのプランが同じ方法で更新されるわけではありません 静的プランは誰かがマスタープランニングのジョブを実行した時にのみ変更されます

00:14:53.400 --> 00:14:58.860
これによりプランナーは新しいトランザクションが発生するたびに数値が変わることなく1日中安定した計画ビューを確認できます

00:14:58.860 --> 00:15:06.980
午前11時に大きな販売注文が入ったと想像してください 静的プランが夜間に実行されていた場合その新しい注文は次のプランニング実行まで提案に現れません

00:15:06.980 --> 00:15:14.620
このプランは最後に計算された結果を表示し続けるためチームがその日の共通認識として一つのビューを必要とする場合に便利です しかしその安定性には代償が伴います

00:15:14.620 --> 00:15:19.840
特に夜間や週に人としかプランニングを実行しないビジネスの場合新しい需要がしばらく静的プランの外側に置かれることになります

00:15:19.840 --> 00:15:24.900
プランナーは顧客オーダーの存在を知っていても静的プラン側ではまだ供給への対応が再計算されていない可能性があるのです

00:15:24.900 --> 00:15:34.060
そこで役立つのが動的計画です動的計画は発生したその瞬間の現在の需要を示します 計画担当者は次回のフルマスタープランニングの実行を待たずに新規受注やその他の需要の影響を確認できます

00:15:34.060 --> 00:15:43.320
これはより短期的な視点です動的計画は予測をスキップし今現在起きていることに焦点を当てます 例えば今日の午後に顧客から自転車200台の予期せぬ注文が入ったとします

00:15:43.320 --> 00:15:55.360
納期を約束する前に計画担当者は動的計画を開いてその影響を確認できます その新規注文は不足を生じさせますか既存のニーズを後の日付に押し出しますか新しい購買や生産の推奨アクションを誘発しますか

00:15:55.360 --> 00:16:02.300
これによりチームは実用的なワットイフ分析が可能になります 一つの新規注文を調査するために性的計画を変更する必要はありません

00:16:02.300 --> 00:16:11.740
まずは影響を確認しその注文に今すぐ対応すべきか次回の計画実行まで待てるかを判断します 性的計画と動的計画は関連してはいるものの異なる問いに答えるものです

00:16:11.740 --> 00:16:19.880
性的計画は前回の公式な計画計算では何をすべきとされたかを問いかけます 動的計画は現在の需要が今どのような状況かを問いかけます

00:16:19.880 --> 00:16:28.880
どちらの計画の背後にもダイナミクス365クラウド環境向けの計画エンジンが存在します プランニング最適化はマイクロソフトがマスタープランニングを実行するために使用する最新の

00:16:28.880 --> 00:16:37.680
エンジンです メインの業務アプリケーションの外で要件を計算するため日々の業務で使用するシステムへの負荷が軽減されます 従来の計画実行は長い時間を要することがありました

00:16:37.680 --> 00:16:43.080
顧客やパートナーからの報告によるとかつては数時間かかっていた計画作業が プランニング最適化によって数分で完了するようになりました

00:16:43.080 --> 00:16:51.160
実行が早くなれば1日の終わりまで需要の変化を待つ必要はなくより頻繁に計画を更新できます しかし早い答えが必ずしも正しい答えとは限りません

00:16:51.160 --> 00:16:57.760
プランニング最適化は膨大な量の関連データを高速で計算できます しかしあくまでビジネス側が提供する記録に基づいて機能します

00:16:57.760 --> 00:17:06.560
サプライヤーのリードタイムが間違っていれば推奨される注文日も間違ったものになります システムが在庫に500個のホイールがあると思い込んでいても実際にはない場合本当に必要な購入提案がスキップされる可能性があります

00:17:06.560 --> 00:17:15.780
また部品表ボムに部品が漏れていれば計画はその欠落した部品の需要を作り出すことができません 計算は数分で終わるかもしれませんがその部品がなければ工場は止まってしまいます

00:17:15.780 --> 00:17:28.160
計画の実行方法にも変化があります プランニング最適化では計画はリジェネラティブ再生成形ですこれは前回の実行以降に変更があった品目のみを更新する従来のネットチェンジ手法とは異なり各実行ですべての要件を再評価することを意味します

00:17:28.160 --> 00:17:38.880
毎回計画全体を再計算するものと考えてください これにより以前の変更が計算から漏れていないかという不確実性が解消されエンジンが高速化したことで多くの企業にとって完全な再計算がより実用的なものとなりました

00:17:38.880 --> 00:17:47.420
スピードも大切ですが計画が信頼に足るものかどうかはデータの正確さで決まります 計画が提案を提示したら次はどの提案に優先して取り組むかを判断する必要があります

00:17:47.420 --> 00:17:52.780
ではマスタープランニングでできることそしてできないことは何でしょうか 最もシンプルな定義をご紹介します

00:17:52.780 --> 00:18:00.000
マスタープランニングはダイナミクス365内のあらゆるデータを取り込み何をいつまでにどれだけ購入 製造または移動すべきかを提案します

00:18:00.000 --> 00:18:08.580
プランナーは行動を起こす前にそれらの計画オーダーを確認します 仕入れ先納期数量そして工場で対応可能かどうかを確認します確認後提案を確定

00:18:08.580 --> 00:18:12.580
ファーミングすることで実際の購買オーダー製造オーダーまたは転送オーダーに変換され ます

00:18:12.580 --> 00:18:18.620
しかしマスタープランニングには未来を予見することはできません 予測はあくまで見積もりに過ぎず実際の顧客注文は一晩で変わることもあります

00:18:18.620 --> 00:18:23.300
そして決して人間のプランナーにとって変わるものではありません サプライヤーのリスクは依然として人が管理するものです

00:18:23.300 --> 00:18:31.220
顧客への約束や例外対応も同様ですシステムには判断ができないのです 在庫があるだけでは十分ではありません在庫が到着予定に間に合わなかったり間違った倉庫にあったり

00:18:31.220 --> 00:18:38.200
あるいは別の注文ですでに予約されている場合があるからです 良い結果を得るにはクリーンなデータ整理された品目記録正確なリードタイム正しい部品表

00:18:38.200 --> 00:18:44.760
最新の在庫状況そして現実的な需要から始めることが不可欠です 自転車の注文の場合既存在庫が需要の一部をカバーします

00:18:44.760 --> 00:18:52.920
プランニングは残りの供給を提案しプランナーがその実行を確認します そこであらゆるチームが答えを必要とする問いに戻ります次に何を行うべきか

00:18:52.920 --> 00:19:01.740
結論として一つのつながった計画が必要です マスタープランニングは需要在庫レベル仕入れ先の納期生産スケジュール能力を取り込み

00:19:01.740 --> 00:19:08.080
すべてをチームが検討可能なアクションへと変えます 計画オーダーは人間が意思決定を始めるためのものです決定を完了させるものではありません

00:19:08.080 --> 00:19:15.500
だからこそプランナーの存在が不可欠なのです お気に入りのポッドキャストプラットフォームで登録しダイナミクス365サプライチェーン管理を学んでいる誰かにこの知見をシェアしてください