00:00 イントロダクション
02:55 リードタイムのケース
09:25 リアルワールドのリードタイム（1/3）
12:13 リアルワールドのリードタイム（2/3）
13:44 リアルワールドのリードタイム（3/3）
16:12 これまでの話
19:31 ETA: 1時間後
22:16 CPRS（まとめ）（1/2）
23:44 CPRS（まとめ）（2/2）
24:52 クロスバリデーション（1/2）
27:00 クロスバリデーション（2/2）
27:40 リードタイムのスムージング（1/2）
31:29 リードタイムのスムージング（2/2）
40:51 リードタイムの構成（1/2）
44:19 リードタイムの構成（2/2）
47:52 準周期的なリードタイム
54:45 ログロジスティックリードタイムモデル（1/4）
57:03 ログロジスティックリードタイムモデル（2/4）
01:00:08 ログロジスティックリードタイムモデル（3/4）
01:03:22 ログロジスティックリードタイムモデル（4/4）
01:05:12 不完全なリードタイムモデル（1/4）
01:08:04 不完全なリードタイムモデル（2/4）
01:09:30 不完全なリードタイムモデル（3/4）
01:11:38 不完全なリードタイムモデル（4/4）
01:14:33 リードタイムにおける需要（1/3）
01:17:35 リードタイムにおける需要（2/3）
01:24:49 リードタイムにおける需要（3/3）
01:28:27 予測手法のモジュラリティ
01:31:22 結論
01:32:52 今後の講義と視聴者の質問
説明
リードタイムはほとんどのサプライチェーンの状況において基本的な要素です。リードタイムは需要と同様に予測することができ、予測すべきです。確率的予測モデルを使用することができます。サプライチェーンの目的のために確率的なリードタイム予測を作成するための一連の技術が紹介されています。リードタイムと需要を組み合わせることは、サプライチェーンにおける予測モデリングの基礎です。
フルトランスクリプト
このサプライチェーンの講義シリーズへようこそ。私はジョアネス・ヴェルモレルです。今日は「リードタイムの予測」を紹介します。リードタイム、そして一般的にはすべての適用可能な遅延は、サプライとデマンドのバランスを取ろうとする際にサプライチェーンの基本的な側面です。関与する遅延を考慮する必要があります。例えば、おもちゃの需要を考えてみましょう。クリスマス前の需要の季節的なピークを適切に予測しても、商品が1月に届くのでは意味がありません。リードタイムは、需要と同様に計画の詳細を規定します。
リードタイムはさまざまです。これは事実であり、私はすぐにいくつかの証拠を示します。しかし、一見すると、この提案は疑問です。まず、なぜリードタイムが最初からそんなに異なるのかはっきりしません。私たちは、マイクロメートル以下の許容範囲で動作する製造プロセスを持っています。さらに、製造プロセスの一環として、光源の適用などの効果を1マイクロ秒まで制御することができます。マイクロメートルおよびマイクロ秒単位で物質の変換を制御できるのであれば、十分な献身を持って需要の流れを同様の精度で制御できるはずです。でも、そうではないかもしれません。
この考え方は、サプライチェーンの文献ではリードタイムがあまり評価されていない理由を説明するかもしれません。サプライチェーンの書籍や、それに続くサプライチェーンソフトウェアは、在庫モデルの入力パラメータとしてリードタイムを導入すること以外に、リードタイムの存在をほとんど認識していません。この講義では、以下の3つの目標があります。
リードタイムの重要性と性質を理解すること。 不確実性を受け入れることができる確率モデルを用いて、リードタイムを予測する方法を理解すること。 サプライチェーンの目的に関連する方法で、リードタイムの予測と需要の予測を組み合わせること。
主流のサプライチェーンの文献によれば、リードタイムはほとんど注目に値しません。この声明は誇張された誇張のように思えるかもしれませんが、残念ながらそうではありません。Google Scholarによると、2021年の「需要予測」というクエリは10,500件の論文を返します。結果を一瞥すると、確かにそれらのエントリの大部分は、さまざまな状況や市場での需要の予測について議論しています。同じクエリを「リードタイム予測」で行った場合、2021年のGoogle Scholarの結果は71件です。リードタイム予測のクエリの結果は非常に限られているため、1年分の研究を数分で調査することができます。
実際には、リードタイムの予測について真に議論しているエントリは約12件しかありません。実際、ほとんどの一致は、「長期リードタイム予測」や「短期リードタイム予測」といった表現で見つかりますが、それは需要の予測を指し、リードタイムの予測を指しているわけではありません。同様の結果を「需要予測」と「リードタイム予測」などの表現や他の年に対しても行うことができます。これらのバリエーションは似たような結果をもたらします。それは聴衆の課題として残しておきます。
したがって、おおよその見積もりとして、需要の予測に関する論文はリードタイムの予測に関する論文の約1000倍あります。サプライチェーンの書籍やサプライチェーンソフトウェアも同様であり、リードタイムは二流の市民であり、取るに足らない技術的な細部です。しかし、この講義シリーズで紹介されたサプライチェーンの人員は異なる話をしています。これらの人員は架空の企業を代表しているかもしれませんが、彼らはサプライチェーンの典型的なアーキタイプを反映しています。リードタイムに関してどのような状況を考慮すべきかを教えてくれます。リードタイムに関してどのような状況を考慮すべきかを教えてくれます。
パリは架空のファッションブランドで、独自の小売ネットワークを運営しています。パリは海外のサプライヤーから注文を受け、リードタイムは長く、6ヶ月以上になることもあります。これらのリードタイムは不完全にしか知られておらず、それにもかかわらず、新しいコレクションはマーケティング活動によって定義される正しいタイミングで店舗に並ぶ必要があります。サプライヤーのリードタイムは適切な予測を必要とします。
アムステルダムは架空のFMCG会社で、チーズ、クリーム、バターの製造に特化しています。チーズの熟成プロセスは知られており、制御されていますが、数日の偏差があります。しかし、数日はアムステルダムの主要な販売チャネルである小売チェーンによって引き起こされる激しいプロモーションの期間とまったく同じです。これらの製造リードタイムは予測を必要とします。
マイアミは架空の航空宇宙MROです。MROはメンテナンス、修理、オーバーホールを意味します。ジェットライナーは年間を通じて数千の部品を必要とし、1つの欠落した部品は航空機を停止させる可能性があります。修理可能な部品の修理期間、またはTAT（ターンアラウンドタイム）は、回転部品が再び使用可能になる時期を定義します。ただし、TATは修理の範囲によって日から月まで異なり、部品が航空機から取り外された時点ではわかりません。これらのTATは予測を必要とします。
サンノゼは架空のeコマース会社で、さまざまな家具やアクセサリーを配送しています。サンノゼはすべての取引に対して納品日の確約を提供しています。ただし、納品自体は完璧に信頼できる第三者企業に依存しています。したがって、サンノゼはすべての取引に対して納品日を約束するための的確な予測が必要です。この的確な予測は暗黙的にリードタイムの予測です。
最後に、シュトゥットガルトは架空の自動車アフターマーケット会社です。自動車部品の最低購入価格は、長くて多少不規則なリードタイムを提供する卸売業者から得ることができます。より信頼性の高いサプライヤーもありますが、より高価で近いです。各部品に適切なサプライヤーを選ぶには、さまざまなサプライヤーに関連するリードタイムの比較分析が必要です。
これまでに紹介したすべてのサプライチェーンの人員が少なくとも1つ、しばしば複数のリードタイムの予測を必要とすることがわかります。需要の予測にはリードタイムの予測よりも注意と努力が必要であると主張することもできますが、結局のところ、ほとんどすべてのサプライチェーンの状況において、両方が必要です。
したがって、実際の現実世界のリードタイムをいくつか見てみましょう。画面には、3つの機械部品に関連する観測されたリードタイムをまとめてプロットした3つのヒストグラムが表示されています。これらの部品は、西ヨーロッパにある同じサプライヤーから注文されています。注文は西ヨーロッパにある会社から行われます。x軸は日単位で表される観測されたリードタイムの期間を示し、y軸はパーセンテージで表される観測数を示しています。以下では、すべてのヒストグラムが同じ規則に従うことになります。x軸は日単位の期間に関連し、y軸は頻度を反映します。これらの3つの分布から、すでにいくつかの観察ができます。
まず、データはまばらです。数十のデータポイントしかありませんし、これらの観測は数年にわたって収集されています。この状況は典型的です。会社が月に1回しか注文しない場合、リードタイムの観測を100回以上収集するには、ほぼ10年かかります。したがって、統計に関しては、大きな数ではなく小さな数に向けるべきです。実際には、大きな数を扱う贅沢はめったにありません。
次に、リードタイムは不規則です。数日から数四半期までの観測があります。リードタイムの平均値を計算することは常に可能ですが、それらの部品のいずれに対しても平均値に頼ることは賢明ではありません。また、これらの分布のいずれも正規分布とは程遠いことも明らかです。
3つの部品はサイズと価格がほぼ同じであり、それにもかかわらずリードタイムは大きく異なります。これらの観測をまとめてデータをまばらにすることは誘惑されるかもしれませんが、それは明らかに賢明ではありません。なぜなら、非常に異なる分布を混ぜ合わせることになるからです。これらの分布には同じ平均値、中央値、最小値、最大値もありません。
さて、リードタイムのもう1つのバッチを見てみましょう。これらの期間は、3つの異なる航空機部品の修理にかかる時間を反映しています。最初の分布は2つのモードとテールを持っているようです。分布が2つのモードを持つ場合、通常はそれらの2つのモードを説明する隠れた変数が存在することを示唆しています。たとえば、2つの異なる修理作業のタイプがあるかもしれず、それぞれのタイプに固有のリードタイムが関連付けられているかもしれません。2番目の分布は1つのモードとテールを持っているようです。このモードは比較的短い期間（約2週間）に一致します。これは、部品が最初に検査され、時には何の介入もなく使用可能と判断されるため、はるかに短いリードタイムを反映しているかもしれません。3番目の分布は明らかなモードやテールを持たずに完全に広がっているようです。ここでは複数の修理プロセスが同時に行われている可能性があります。3ダースの観測しかないデータのまばらさのため、もっと詳しく言うことは難しいです。この講義の後半でこの3番目の分布に再び取り組む予定です。
最後に、台湾から米国西海岸への出荷遅延を反映した2つのリードタイムを見てみましょう。当然ながら、貨物機は貨物船よりも速いです。2番目の分布は、海上輸送が元の船を逃し、次の船で出荷されることがあることを示唆しています。同じ現象が航空輸送でも起こる可能性がありますが、データが非常に限られているため、それは単なる推測に過ぎません。わずか数回の観測しかないという点について指摘しておきましょう。これはリードタイムに関しては普通のことです。この講義では、数十の観測から始まり、数千の観測のようなリードタイムデータを持つことを望んでいるのではなく、手の届く範囲の観測から始めるためのツールや手法を探しています。両方の分布の短いギャップも、週の中で周期的なパターンが働いていることを示唆していますが、現在のヒストグラムの可視化ではこの仮説を検証するのには適していません。
これらの実世界のリードタイムの短いレビューから、私たちは既に関与しているいくつかの基本的な現象を把握することができます。実際には、リードタイムは非常に構造化されています。遅延は原因なしに発生することはありませんし、それらの原因は特定、分解、定量化することができます。ただし、リードタイムの詳細な分解は、ITシステムに記録されていないことがしばしばあります。特に航空業界などの一部の産業では、観測されたリードタイムの詳細な分解が利用可能な場合でも、リードタイムを完全に予測できるわけではありません。リードタイム内のサブセグメントやフェーズは、独自の不可避的な不確実性を示す可能性があります。
この一連のサプライチェーン講義では、サプライチェーンの研究と実践に関する私の見解と洞察を紹介しています。これらの講義は、一定の独立性を保つようにしていますが、連続して視聴するとより意味があります。この講義の残りの部分は、以前にこのシリーズで紹介された要素に依存していますが、すぐに復習を提供します。
第1章は、サプライチェーンの分野と研究についての一般的な紹介です。この講義シリーズに取り組む視点を明確にします。おそらくすでに推測しているように、この視点はサプライチェーンに関する主流の視点とは大きく異なります。
第2章では、一連の手法を紹介しています。実際には、サプライチェーンは単純な手法に打ち勝ちます。サプライチェーンは、それぞれが独自のアジェンダを持つ人々で構成されています。サプライチェーンには中立的な当事者は存在しません。この章では、私自身がLokadというエンタープライズソフトウェア会社のCEOであり、予測的なサプライチェーン最適化に特化した会社であるという自身の利益相反も含め、これらの複雑さに取り組んでいます。
第3章では、一連のサプライチェーンの「ペルソナ」を調査します。これらの「ペルソナ」は、本日簡単にレビューした架空の企業であり、サプライチェーンの典型的な状況の原型を表すことを意図しています。これらのペルソナの目的は、解決策の提示を延期し、問題にのみ焦点を当てることです。
第4章では、サプライチェーンの補助科学を検討します。これらの科学はサプライチェーンそのものについてではありませんが、現代のサプライチェーンの実践には必須とされるべきです。この章では、コンピューティングハードウェアからサイバーセキュリティの懸念まで、抽象化レイヤーを通じた進行を含みます。
第5章で、予測モデリングに焦点を当てます。予測モデリングは予測需要に関するものだけでなく、対象とするサプライチェーンの将来の要素を推定および数量化するためのモデルの設計についての一般的な視点です。今日はリードタイムについて詳しく説明しますが、サプライチェーン全般では、合理的な確度で把握されていないものはすべて予測が必要です。
第6章では、予測モデルを活用しながら最適化された意思決定を計算する方法を説明します。具体的には、第5章で紹介された確率モデルを使用します。第7章では、量的サプライチェーンイニシアチブの実際の企業実行について、主に非技術的な視点に戻ります。
今日はリードタイムに焦点を当てます。リードタイムが重要な理由を見てきたばかりであり、実世界のリードタイムの短いシリーズを見直しました。したがって、リードタイムモデリングの要素に進みます。確率的な視点を採用するため、確率的な予測の良さを評価するための指標である連続ランク確率スコア（CRPS）を簡単に再導入します。また、交差検証と、確率的な視点に適した交差検証の変種も紹介します。これらのツールを手に入れたら、リードタイムのための最初の非単純な確率モデルを紹介し、評価します。リードタイムデータはまばらであり、私たちの議題の最初の項目はこれらの分布をスムーズにすることです。リードタイムは一連の中間フェーズに分解することができます。したがって、いくつかの分解されたリードタイムデータが利用可能な場合、確率的な視点を保持しながらこれらのリードタイムを再構成するための手段が必要です。
次に、差分可能プログラミングを再導入します。差分可能プログラミングは、需要予測に使用されるだけでなく、リードタイムの予測にも使用できます。アジアからの商品輸入時に観察される典型的なパターンである中国の新年の影響を捉えるための簡単な例から始めます。
次に、リードタイムのためのパラメトリックな確率モデルを考慮して、対数ロジスティック分布を活用します。再び、差分可能プログラミングはモデルのパラメータを学習するために重要な役割を果たします。また、不完全なリードタイムの観測を考慮してこのモデルを拡張します。実際には、まだ完了していない発注でもリードタイムに関する情報を得ることができます。
最後に、確率的なリードタイム予測と確率的な需要予測を単一の在庫補充状況で組み合わせます。これは、予測モデリングにおいて、モデル自体の詳細事項よりもモジュール性が重要な関心事である理由を示す機会となります。
予測の精度を評価するためのツールをいくつか紹介しました。通常の精度指標（平均二乗誤差や平均絶対誤差など）は、点予測にのみ適用されます。しかし、予測が確率的になったからといって、一般的な意味での精度が無関係になるわけではありません。確率的な視点と互換性のある統計的な手法が必要です。
そのような手法の中には、連続ランク確率スコア（CRPS）があります。式は画面に表示されています。CRPSは、絶対誤差であるL1メトリックの一般化ですが、確率分布に対して適用されます。通常のCRPSは、分布（ここではFと呼ばれる）と観測値（ここではXと呼ばれる）を比較します。CRPS関数から得られる値は、観測値と同じ単位です。例えば、Xが日数で表されるリードタイムであれば、CRPSの値も日数で表されます。
CRPSは、2つの分布を比較するために一般化することもできます。画面上で行われているのは、前の式のわずかな変形です。このメトリックの本質は変わりません。Fが真のリードタイム分布であり、F_hatがリードタイム分布の推定値である場合、CRPSは日数で表されます。CRPSは、2つの分布間の差異の量を反映しています。CRPSは、第1の分布の質量を第2の分布の形状と完全に一致させるために必要な最小限のエネルギーとして解釈することもできます。
これで、2つの1次元確率分布を比較するための手法を持っています。これは、リードタイムのための最初の確率モデルを紹介する際に興味を持つことになります。
確率的な予測の良さを測るためのメトリックを持つことは十分ではありません。このメトリックは、持っているデータに基づいて良さを測定しますが、本当に望んでいるのは持っていないデータに対して予測の良さを評価できることです。実際には、将来のリードタイムが私たちにとって興味のあるものであり、過去に観測されたリードタイムではありません。私たちが持っていないデータに対してモデルがうまく機能する能力は、一般化と呼ばれます。クロスバリデーションは、モデルがうまく一般化する能力を評価するために特に意図された一般的なモデル検証技術です。
クロスバリデーションの最も単純な形式では、観測値をいくつかのサブセットに分割します。各イテレーションでは、1つのサブセットが取り除かれ、テストサブセットとして参照されます。その後、他のデータサブセット（トレーニングサブセットとして参照される）に基づいてモデルが生成またはトレーニングされます。トレーニング後、モデルはテストサブセットとの間で検証されます。このプロセスは一定の回数繰り返され、すべてのイテレーションで得られた平均の良さが最終的なクロスバリデーション結果を表します。
クロスバリデーションは、観測間の時間依存性のため、時系列予測の文脈ではほとんど使用されません。実際、クロスバリデーションは、観測が独立しているという前提に基づいています。時系列が関与する場合、代わりにバックテストが使用されます。バックテストは、時間の依存性を考慮に入れたクロスバリデーションの形態と見なすことができます。
クロスバリデーションの手法には、さまざまなバリエーションがありますが、それらのバリエーションをこの講義の目的のために調査することはありません。私は特定のバリエーションを使用します。このバリエーションでは、各分割でトレーニングサブセットとテストサブセットのサイズがほぼ同じです。このバリエーションは、確率モデルの検証に対処するために導入されています。後ほどコードを使用して確認します。
以前に画面で見た実世界のリードタイムのうち、1つを再検討してみましょう。左側のヒストグラムは、第3の航空修理時間分布に関連付けられています。これらは以前に見たものと同じ観測値であり、ヒストグラムは垂直方向に伸びているだけです。これにより、左側と右側の2つのヒストグラムは同じスケールを共有しています。左側のヒストグラムでは、約30の観測値があります。それほど多くはありませんが、頻繁に得ることができるものよりも多いです。
左側のヒストグラムは経験的分布と呼ばれます。これは、観測から得られた生のヒストグラムです。ヒストグラムには、日数の整数倍で表される各期間の観測リードタイムの数がカウントされます。スパースさのため、経験的分布はバーコードのように見えます。
問題があります。正確に50日で2つの観測リードタイムがある場合、49日または51日の観測確率をゼロと言うのは意味がありません。実際には、さまざまな期間が存在しており、このバーコードのような分布よりもはるかに滑らかな真の基礎分布を観測するデータポイントが十分にあると考えられます。
したがって、この分布を滑らかにする方法は無数にあります。一部のスムージング手法は見た目が良く見えるかもしれませんが、統計的には妥当ではありません。良い出発点として、滑らかなモデルがより正確であることを確認したいと考えています。CRPSとクロスバリデーションという2つの手法を既に導入しており、それによって実現できます。
1分後に結果が表示されます。バーコード分布に関連するCRPSエラーは1.6日であり、滑らかな分布に関連するCRPSエラーは1.4日です。これらの2つの数値はクロスバリデーションによって得られました。より低いエラーは、CRPSの意味で、右側の分布が2つのうちで最も正確であることを示しています。1.4と1.6の間の0.2の差はそれほど大きくありませんが、ここでの重要な特性は、ゼロ確率であるというエラティックな中間期間を持たない滑らかな分布があることです。これは、修理に関する理解から、これらの期間が再発生する可能性が高いと考えられるからです。CRPSは、分布を滑らかにすることによってもたらされた改善の真の深さを反映していません。ただし、少なくともCRPSを下げることで、この変換が統計的な観点から合理的であることが確認されます。
これで、これらの2つのモデルを生成し、これらの2つのヒストグラムを表示するために使用されたソースコードを見てみましょう。すべての行を含めると、空白行を除いて12行のコードで実現されています。この講義シリーズではいつものように、コードはLokadの予測最適化に特化したドメイン固有のプログラミング言語であるEnvisionで書かれています。ただし、魔法はありません。このロジックはPythonでも書くことができます。ただし、この講義で考慮しているような問題に対しては、Envisionの方がより簡潔で自己完結しています。
これらの12行のコードを見直しましょう。1行目と2行目では、単一のデータ列を持つExcel スプレッドシートを読み込んでいます。スプレッドシートには30の観測値が含まれています。このデータは、“days"という名前の単一の列を持つテーブル"H"に収集されています。4行目では、経験的な分布を作成しています。変数"R"はデータ型"ranvar"を持ち、代入の右側にある"ranvar"関数は観測値を入力として受け取り、ヒストグラムを表す"ranvar"データ型で返します。結果として、“ranvar"データ型は一次元の整数分布に特化しています。このデータ型は、この章の前の講義で紹介しました。このデータ型は、各操作に対して一定のメモリフットプリントと計算時間を保証します。データ型"ranvar"の欠点は、損失のある圧縮が関与していることですが、この圧縮によるデータの損失は、サプライチェーンの目的には無関係であるように設計されています。
5行目では、組み込み関数"smooth"を使用して分布を平滑化しています。この関数は、元の分布をポアソン分布の混合物で置き換えます。ヒストグラムの各バケットは、バケットの整数位置と等しい平均を持つポアソン分布に変換され、最終的に混合物は各ポアソン分布にバケット自体の重みを割り当てます。この"smooth"関数が行っていることを理解する別の方法は、すべての観測値を観測値自体と等しい平均を持つポアソン分布に置き換えることです。それらのポアソン分布、観測値ごとに1つずつ、が混合されます。混合とは、各ヒストグラムバケットの値を平均化することを意味します。“ranvar"変数"R"と"S"は、14行目と15行目で再び使用されることはありませんが、そこで表示されます。
7行目では、モンテカルロブロックを開始します。このブロックはループの一種であり、Monte Carloキーワードの直後に表示される100の値によって100回実行されます。モンテカルロブロックは、一定のランダム性を含むプロセスに従って生成される独立した観測値を収集することを目的としています。一般的なプログラミング言語では通常ループがあるだけで済むのに、なぜEnvisionには専用の構造があるのか疑問に思うかもしれません。専用の構造を持つことには、重要な利点があります。まず、繰り返しが真に独立していることを保証します。疑似乱数の生成に使用されるシードまで独立しています。さらに、複数のCPUコアまたは複数のマシンにわたるワークロードの自動分散のための明示的なターゲットを提供します。
8行目では、テーブル"H"内のブール値のランダムベクトルを作成しています。この行では、テーブル"H"の各行に対して独立したランダム値（trueまたはfalse）である偏差を作成しています。Envisionでは通常のようにループは配列プログラミングを介して抽象化されます。これらのブール値を使用して、テーブル"H"を2つのグループに分割しています。このランダムな分割は、交差検証プロセスに使用されます。
9行目と10行目では、それぞれ"ranvars"という名前の2つの変数"A"と"B"を作成しています。再び"ranvar"アグリゲータを使用していますが、今回はアグリゲータ呼び出しの直後に"when"キーワードを使用してフィルタを適用しています。“A"は、“a"の値がtrueの行のみを使用して生成されます。“B"はその逆です。“B"は、“a"の値がfalseの行のみを使用して生成されます。
11行目と12行目では、モンテカルロブロックから興味のある数値を収集しています。Envisionでは、キーワード"sample"はモンテカルロブロック内にのみ配置することができます。これは、モンテカルロプロセスを繰り返し実行する間に行われる観測値を収集するために使用されます。11行目では、元のリードタイムセットからのサブサンプル間のCRPS項で表される平均誤差を計算しています。“sample"キーワードは、モンテカルロの反復回数で収集される値を指定します。代入の右側にある"AVG"アグリゲータは、ブロックの最後に単一の推定値を生成するために使用されます。
12行目では、11行目で行われたこととほぼ同じことを行っています。ただし、この場合は"ranvar” “B"に"smooth"関数を適用しています。滑らかな変異体が素朴な経験分布からどれだけ近いかを評価したいのです。CRPSの観点では、滑らかな変異体は元の経験的な対応物よりも近いことがわかります。
14行目と15行目では、ヒストグラムとCRPSの値を表示します。これらの行は、前のスライドで見た図を生成します。このスクリプトは、モデルの経験的な分布の品質の基準を提供します。確かに、このモデルである「バーコード」モデルは素朴なものであると言えますが、それでもモデルであり、確率的なモデルです。したがって、このスクリプトは、元の経験的な分布の滑らかな変異体を通じて、少なくともCRPSの意味でより良いモデルを提供します。
現時点では、プログラミング言語に精通しているかどうかによっては、多くの情報を消化するのは難しいかもしれません。ただし、わずか12行のコードで、4行目と5行目だけが演習の真のモデリング部分を表していることに注目してください。滑らかな変異体に興味がある場合、“ranvar” “S"は1行のコードで書くことができます。したがって、コードの観点では文字通り1行のコードです。まず、ranvarの集約を適用し、次にスムーズ演算子を適用して完了です。残りは単なる計測と表示です。適切なツールを使用すれば、リードタイムやその他のものに関しても、確率モデリングは非常に簡単に行うことができます。大きな数学は関与せず、大きなアルゴリズムや大きなソフトウェアの断片もありません。それは単純であり、非常に単純です。
なぜ出荷が6ヶ月遅れるのでしょうか？答えは明らかです。一日一日です。より真剣に考えると、リードタイムは通常、一連の遅延に分解できます。たとえば、サプライヤのリードタイムは、注文がバックログキューに入れられる待機遅延、商品が生産される製造遅延、そして商品が出荷される輸送遅延に分解できます。したがって、リードタイムが分解できる場合、それを再構成できることも興味深いです。
もし将来が正確に予測できる高度に決定論的な世界に住んでいたら、リードタイムを再構成することは単なる加算の問題になるでしょう。先ほど述べた例に戻ると、注文リードタイムをキュー待ち遅延（日数）、製造遅延（日数）、輸送遅延（日数）の合計として構成することになります。しかし、私たちは将来を正確に予測できる世界に住んでいるわけではありません。この講義の最初に紹介した現実のリードタイム分布は、この主張を支持しています。リードタイムは不規則であり、この数十年で根本的に変わる理由はほとんどありません。
したがって、将来のリードタイムはランダム変数としてアプローチする必要があります。これらのランダム変数は不確実性を受け入れて量子化します。具体的には、リードタイムの各要素も個別にランダム変数としてモデル化する必要があります。先ほどの例に戻ると、注文リードタイムはランダム変数であり、キュー待ち遅延、製造遅延、輸送遅延にそれぞれ関連付けられた3つのランダム変数の合計として得られます。
画面には、2つの独立した1次元整数値のランダム変数の合計の式が表示されます。この式は、合計の期間がZ日であり、最初のランダム変数XにK日がある場合、2番目のランダム変数YにはZからK日が必要です。このタイプの合計は、一般的に数学的には畳み込みとして知られています。
この畳み込みには無限の項があるように思われますが、実際には有限の項にしか関心がありません。まず、すべての負の期間は確率がゼロです。実際、負の遅延は時間を遡ることを意味します。第二に、大きな遅延では、確率は非常に小さくなり、実際のサプライチェーンの目的には確実にゼロとして近似できます。
これらの畳み込みを実践してみましょう。輸送時間を通関での出荷遅延と通関遅延の2つのフェーズに分解することを考えましょう。これらの2つのフェーズを2つの独立したランダム変数でモデル化し、それらの2つのランダム変数を加算して輸送時間を再構成したいと思います。
画面では、左側のヒストグラムは右側のスクリプトによって生成されます。1行目では、出荷遅延をポアソン分布と定数の畳み込みとしてモデル化しています。ポアソン関数は「ranvar」データ型を返します。3を加えることで、分布を右にシフトする効果があります。結果の「ranvar」は変数「C」に割り当てられます。この「ranvar」は3行目で表示されます。左側の最上部のヒストグラムとして表示されます。ここでは、右に数ユニットシフトされたポアソン分布の形状が認識できます。2行目では、通関のクリアランスをゼロのディラックと5のポアソンの混合としてモデル化しています。ゼロのディラックは80％の確率で発生します。これは0.8の定数が意味することです。これは、ほとんどの場合、商品が通関で検査されず、特筆すべき遅延もなく通過する状況を反映しています。代わりに、20％の場合、商品は通関で検査され、遅延は平均5のポアソン分布としてモデル化されます。結果のranvarは変数Dに割り当てられます。このranvarは4行目で表示され、左側の中央のヒストグラムとして表示されます。この非対称な側面は、通関での遅延がほとんどないことを反映しています。
最後に、5行目でCプラスDを計算します。この加算は畳み込みです。CとDは数ではなくranvarsなので、これはこのスクリプトで2番目の畳み込みです。結果のranvarは表示され、左側の3番目で最も低いヒストグラムとして表示されます。この3番目のヒストグラムは最初のヒストグラムと似ていますが、テールが右に広がっています。再び、わずか数行のコードで、通関での通関遅延などの非自明な現実世界の効果にアプローチできることがわかります。
ただし、この例には2つの批判があります。まず、定数の出所が明示されていません。実際には、私たちはこれらの定数を過去のデータから学びたいと考えています。第二に、ポアソン分布は単純さの利点がありますが、特にファットテールの状況を考慮すると、リードタイムモデリングにはあまり現実的な形状ではないかもしれません。したがって、これらの2つのポイントについて順番に取り組むことにします。
データからパラメータを学ぶために、私たちはすでにこの講義シリーズで紹介したプログラミングパラダイムである微分可能プログラミングを再訪します。この章の前の講義をまだ見ていない場合は、この講義の終わり後にそれらをご覧いただくことをお勧めします。微分可能プログラミングは、これらの講義で詳しく紹介されています。
微分可能プログラミングは、2つの技術の組み合わせです：確率的勾配降下法と自動微分です。確率的勾配降下法は、勾配の逆方向にパラメータを1つずつ微調整する最適化技術です。自動微分は、プログラミング言語のコンパイラのようなコンパイル技術であり、一般的なプログラム内に現れるすべてのパラメータの勾配を計算します。
リードタイムの問題を用いて、微分可能プログラミングを説明します。これは、このパラダイムに精通しているかどうかによって、復習または導入として役立ちます。中国の新年の影響をモデル化し、中国からの輸入品に関連するリードタイムに与える影響をモデル化したいと考えています。実際には、中国の新年に2週間または3週間工場が閉鎖されるため、リードタイムが長くなります。中国の新年は周期的で、毎年起こります。ただし、グレゴリオ暦の意味では厳密に季節的ではありません。
1行から6行目では、4つの観測値を持つモックの発注書を紹介しています。実際には、このデータはハードコードされず、会社のシステムからこの過去のデータを読み込むことになります。8行目と9行目では、リードタイムが中国の新年と重なるかどうかを計算しています。変数"T.overlap_CNY"はブールベクトルであり、観測値が中国の新年に影響を受けるかどうかを示します。
12行目では、“autodiff"ブロックを導入しています。表Tは観測表として使用され、1000エポックあります。これは、各観測値、つまり表Tの各行が1000回訪れることを意味します。確率的勾配降下法の1ステップは、“autodiff"ブロック内のロジックの1回の実行に対応します。
13行目と14行目では、2つのスカラーパラメータが宣言されています。“autodiff"ブロックはこれらのパラメータを学習します。パラメータAは中国の新年の影響を受けない基準リードタイムを反映し、パラメータBは中国の新年に関連する追加の遅延を反映します。15行目では、モデルのリードタイム予測であるXを計算します。これは確率モデルではなく、確定的なモデルであり、Xはポイントリードタイム予測です。代入の右側は簡単です：観測値が中国の新年と重なる場合、基準値に新年の要素を加えて返します。そうでなければ、基準値のみを返します。“autodiff"ブロックは1回の実行で1つの観測値のみを取るため、15行目では変数T.overlap_CNYはスカラー値を参照し、ベクトルではありません。この値は、表T内の観測行として選択された1行と一致します。
パラメータAとBは、指数関数"exp"に包まれています。これは微分可能プログラミングの小さなトリックです。確率的勾配降下法を制御するアルゴリズムは、パラメータの増分に対して比較的保守的な傾向があります。したがって、10を超えるような成長する可能性のある正のパラメータを学習したい場合、このパラメータを指数関数のプロセスに包むことで収束を加速させることができます。
16行目では、予測Xと観測された期間（T.daysで表される）との平均二乗誤差を返します。再度、この"autodiff"ブロック内では、T.daysはスカラー値であり、ベクトルではありません。表Tが観測表として使用されるため、返り値は確率的勾配降下を通じて最小化される損失として扱われます。自動微分は、損失からパラメータAとBに勾配を伝播させます。最後に、19行目で学習した2つの値、AとB、つまりリードタイムの基準値と新年の要素を表示します。
これにより、統計的なパターンを学習するための多目的なツールとしての微分可能プログラミングの再導入が終了します。ここから先は、より詳細な状況で"autodiff"ブロックを再訪します。ただし、もう一度指摘しておきますが、少し圧倒されるかもしれませんが、ここでは実際には何も複雑なことは起こっていません。おそらく、このスクリプトの中で最も複雑なコードは、8行目で呼び出される"ChineseYearStart"関数の基礎的な実装であり、これはEnvision標準ライブラリの一部です。数行のコードで、2つのパラメータを持つモデルを導入し、それらのパラメータを学習します。再び、この単純さは注目に値します。
リードタイムは頻繁にファットテールです。つまり、リードタイムが逸脱すると、大幅に逸脱します。したがって、リードタイムをモデル化するためには、そのファットテールの振る舞いを再現できる分布を採用することが興味深いです。数学の文献では、そのような分布の広範なリストが提示されており、いくつかは私たちの目的に適しています。ただし、数学の風景を調査するだけでも数時間かかるでしょう。ここで、ポアソン分布はファットテールを持ちません。したがって、今日はファットテール分布であるログロジスティック分布を選びます。この分布を選ぶ主な理由は、Lokadチームがいくつかのクライアントのリードタイムをログロジスティック分布でモデル化していることです。最小限の複雑さでうまく機能しています。ただし、ログロジスティック分布は万能な解決策ではなく、Lokadがリードタイムを異なる方法でモデル化する場合も多数ありますので、それを念頭に置いておきましょう。
画面には、ログロジスティック分布の確率密度関数が表示されています。これは2つのパラメータ、アルファとベータに依存するパラメトリックな分布です。アルファパラメータは分布の中央値であり、ベータパラメータは分布の形状を制御します。右側には、さまざまなベータ値を用いて得られる形状の短い系列が表示されます。この密度関数の式は、脅威的に見えるかもしれませんが、教科書の材料と同じくらいです。球の体積を計算するための式と同じように、この式を解読して覚えようとすることは必要ありません。単に解析的な式が存在することを知っていれば十分です。式が存在することを知っていれば、オンラインで見つけるのに1分もかかりません。
私たちの意図は、確率的なリードタイムモデルを学習するためにログロジスティック分布を活用することです。これを行うために、対数尤度を最小化します。実際には、この第5章の前の講義で、確率的な視点に適したいくつかのメトリックがあることを見てきました。少し前に、CRPS（Continuous Ranked Probability Score）を再訪しました。ここでは、ベイズ的な視点を採用する対数尤度を再訪します。
要するに、2つのパラメータが与えられた場合、ログロジスティック分布は、経験的なデータセットで見つかる各観測を観測する確率を示しています。この尤度を最大化するパラメータを学習したいのです。対数、つまり対数尤度ではなく単なる尤度を使用するのは、数値的なアンダーフローを回避するためです。数値的なアンダーフローは、非常にゼロに近い非常に小さな数値を処理する場合に発生します。これらの非常に小さな数値は、現代のコンピューティングハードウェアで一般的に見られる浮動小数点表現とはうまく機能しません。
したがって、ログロジスティック分布の対数尤度を計算するために、その確率密度関数に対数を適用します。解析的な式は画面に表示されています。この式は実装できますし、以下の3行のコードで実際に行われていることです。
1行目では、関数「L4」が導入されています。L4は「ログロジスティックの対数尤度」を表しています。はい、これはたくさんのLとたくさんの対数です。この関数は3つの引数、つまりパラメータのalphaとbeta、および観測値xを取ります。この関数は尤度の対数を返します。関数L4はキーワード「autodiff」で修飾されています。このキーワードは、この関数が自動微分を介して微分可能であることを示しています。言い換えると、勾配はこの関数の戻り値から引数であるパラメータalphaとbetaに逆流することができます。技術的には、勾配は観測値xを逆流することもできますが、学習プロセス中に観測値を変更しないため、勾配は観測値には影響を与えません。3行目では、スクリプトの直前に数学的な式の文字通りの転写を取得します。
さて、ログロジスティック分布に基づく確率的リードタイムモデルのパラメータを学習するスクリプトをまとめましょう。1行目と3行目では、モックのトレーニングデータセットを生成します。実際の設定では、モックデータの代わりに過去のデータを使用します。1行目では、元の分布を表す「ranvar」を作成します。この演習では、パラメータalphaとbetaを再学習したいと考えています。ログロジスティック関数はEnvisionの標準ライブラリの一部であり、「ranvar」を返します。2行目では、1,000のエントリを含むテーブル「H」を作成します。3行目では、元の分布「R」からランダムにサンプリングされた1,000の偏差を描画します。このベクトル「H.days」はトレーニングデータセットを表します。
6行目では、「autodiff」ブロックがあります。ここで学習が行われます。7行目と8行目では、2つのパラメータ、alphaとbetaを宣言し、ゼロでの除算などの数値的な問題を回避するために境界が適用されます。Alphaは0.01より大きく、betaは1.0より大きくなければなりません。9行目では、逆数尤度の反対である損失を返します。実際には、「autodiff」ブロックは損失関数を最小化するため、尤度を最大化したいので、マイナス記号が付いています。「log_likelihood.logistic」関数はEnvisionの標準ライブラリの一部ですが、内部では前のスライドで実装した「L4」関数です。したがって、ここでは魔法は何も起こっていません。勾配は損失からパラメータalphaとbetaに逆流するための自動微分によってすべて自動化されています。
11行目と12行目では、元の分布と学習された分布がプロットされています。ヒストグラムは200でキャップされています。このキャップにより、ヒストグラムが少し読みやすくなります。すぐにそれについて説明します。このスクリプトの「autodiff」部分のパフォーマンスについて疑問がある場合、単一のCPUコアで実行するのに80ミリ秒未満かかります。微分可能なプログラミングは多様であるだけでなく、現代のコンピューティングハードウェアが提供する計算リソースを効果的に活用します。
画面には、さきほどレビューしたスクリプトによって生成された2つのヒストグラムが表示されています。上部には、元の分布とその2つの元のパラメータ、alphaとbetaがあります。alphaは80、betaは4です。下部には、微分可能なプログラミングを介して学習された2つのパラメータを持つ学習された分布があります。右側の2つのスパイクは、かなり遠くまで広がるテールに関連しています。ちなみに、まれですが、特定の商品が注文から1年以上経ってから受け取られることがあります。これはすべての業界に当てはまるわけではありませんが、乳製品ではなく、機械部品や電子部品などでは、時折それが起こります。
学習プロセスは正確ではありませんが、元のパラメータ値から1％以内の結果を得ることができます。これは、微分可能なプログラミングによる対数尤度最大化が実際に機能することを少なくとも示しています。対数ロジスティック分布は適切であるかどうかは、直面しているリードタイム分布の形状に依存します。ただし、ほぼ任意の代替パラメトリック分布を選択することができます。確率密度関数の解析的な表現が必要です。そのような分布は非常に多数存在します。テキストブックの式があれば、通常は微分可能なプログラミングを介した簡単な実装で済みます。
リードタイムは、取引が最終的になされるまで観測されるわけではありません。取引が進行中の間には、すでに何かを知っています。不完全なリードタイムの観測値がすでにあります。例えば、100日前に注文をしたとしましょう。商品はまだ受け取られていませんが、リードタイムが少なくとも100日であることはすでにわかっています。この100日の期間は、まだ完全に観測されていないリードタイムの下限を表します。これらの不完全なリードタイムは、非常に重要な場合がよくあります。この講義の冒頭で述べたように、リードタイムのデータセットは頻繁にスパースです。データセットには半ダースの観測値しか含まれないことは珍しくありません。そのような状況では、進行中の観測値を含め、すべての観測値を最大限に活用することが重要です。
次の例を考えてみましょう。合計5つの注文があります。3つの注文はすでに30日に非常に近いリードタイムの値で配達されました。しかし、最後の2つの注文はそれぞれ40日と50日間保留されています。最初の3つの観測値によれば、平均リードタイムは約30日であるはずです。しかし、まだ完全ではない最後の2つの注文はこの仮説を否定します。40日と50日の保留注文は、リードタイムがかなり長いことを示唆しています。したがって、未完了の注文を単に破棄すべきではありません。この情報を活用して、リードタイムをより長く、たとえば60日に更新するべきです。
不完全な観測値を考慮に入れた確率的リードタイムモデルを再考してみましょう。つまり、時には最終的なリードタイムの下限となる観測値を扱いたいと思います。そのためには、対数ロジスティック分布の累積分布関数（CDF）を使用することができます。この式は画面に表示されています。これもテキストブックの内容です。対数ロジスティック分布のCDFは、単純な解析的な表現を持つことができます。以下では、このテクニックを「検閲データの処理」と呼びます。
このCDFの解析的な表現に基づいて、対数ロジスティック分布の対数尤度を再考することができます。画面上のスクリプトは、以前のL4の実装の改訂版を提供しています。1行目では、ほぼ同じ関数宣言が行われています。この関数は、“is_incomplete"という名前の追加の4番目の引数、ブール値を受け取ります。この引数は、観測が不完全かどうかを示すものです。2行目と3行目では、観測が完全である場合は、通常の対数ロジスティック分布の状況に戻ります。したがって、標準ライブラリの対数尤度関数を呼び出します。以前のL4の実装のコードを繰り返すこともできましたが、このバージョンの方が簡潔です。4行目と5行目では、現在の不完全な観測値「X」よりも大きなリードタイムが最終的に観測される対数尤度を表現しています。これはCDFおよびより具体的にはCDFの対数を介して達成されます。
今度は、不完全なリードタイムの存在下で、パラメータを学習するスクリプトを使ってセットアップを繰り返すことができます。画面上のスクリプトはほぼ前のものと同じです。1〜3行目ではデータを生成していますが、これらの行は変更されていません。2行目で暗黙的に作成される自動生成ベクトルであるH.Nについて指摘しましょう。このベクトルは、生成された行に番号を付け、1から始まります。以前のバージョンのスクリプトでは、この自動生成ベクトルは使用されていませんでしたが、現在ではH.Nベクトルが6行目の末尾に表示されます。
5行目と6行目が実際に重要な部分です。ここでは、リードタイムを検閲しています。まるで1日ごとにリードタイムの観測を行い、現在の日付よりも新しすぎる観測を切り捨てているかのようです。これは、たとえば、7日前に開始された20日のリードタイムが7日の不完全なリードタイムとして表示されることを意味します。6行目の終わりまでに、一部の最近の観測（現在の日付を超えて終了するもの）が不完全な状態でリードタイムのリストが生成されます。スクリプトの残りの部分は変更されていませんが、12行目ではH.is_completeベクトルがlog-likelihood関数の4番目の引数として渡されています。したがって、ここで、さきほど紹介した微分可能プログラミング関数を呼び出しています。
最終的に、この改訂版のスクリプトによって2つのヒストグラムが生成されます。パラメータは依然として高い精度で学習されていますが、今では多数の不完全なリードタイムが存在しています。不完全な時間を扱うことが不必要な複雑さではなかったことを検証するために、スクリプトを再実行しましたが、今度はlog-likelihood関数の3つの引数のオーバーロード（最初に使用したもので、すべての観測が完全であると仮定したもの）を使用した変更バリエーションで行いました。alphaとbetaについて、画面下部に表示される値を取得します。予想通り、それらの値は元のalphaとbetaの値とまったく一致しません。
この講義シリーズでは、検閲されたデータを扱うためのテクニックが紹介されるのはこれが初めてではありません。この章の2番目の講義では、ストックアウトを扱うために損失マスキング技術が紹介されました。実際、通常は将来の需要を予測したいので、将来の販売を予測したいわけではありません。ストックアウトは、ストックアウトが発生しなかった場合に発生したすべての販売を観測できないため、下方バイアスを導入します。条件付き確率技術は、ストックアウトと同様に検閲された需要を扱うために使用することができます。条件付き確率技術は損失マスキングよりもやや複雑ですので、損失マスキングで十分な場合は使用しない方が良いでしょう。
リードタイムの場合、データの疎密性が主な動機です。データが非常に少ない場合、不完全な観測を含めてすべての観測を最大限に活用することが重要になる場合があります。実際、条件付き確率技術は、単にそれらを破棄するのではなく、不完全な観測を活用するという意味で、損失マスキングよりも強力です。たとえば、在庫が1つあり、この1つの在庫が売れた場合、ストックアウトを示唆している場合、条件付き確率技術は需要が1以上であるという情報を利用します。
ここでは、確率モデリングの驚くべき利点を得ることができます。これにより、多くのサプライチェーンの状況で発生する検閲という効果に対処する優れた方法が提供されます。条件付き確率を通じて、システマティックなバイアスのクラス全体を排除することができます。
リードタイムの予測は通常、需要予測と組み合わせて使用することを意図しています。実際、画面上に示されているように、単純な在庫補充の状況を考えてみましょう。
私たちは単一の製品を提供し、在庫は単一のサプライヤーからの再注文によって補充することができます。サプライヤーからの再注文の判断をサポートする予測を求めています。今すぐ再注文することができ、そうすると商品は「最初の到着」として示される時点で到着します。後で再注文する機会があります。この後の機会は「次の注文」として示され、この場合、商品は「2番目の到着」として到着します。 「責任の窓」として示されている期間が、再注文の判断に関係する期間です。
実際に再注文するものは、最初のリードタイムより前に発生する需要に対しては既に制御を失っています。そして、後で再注文する機会があるため、2番目の到着後の需要を処理することはもはや私たちの責任ではありません。それは次の再注文の責任です。したがって、2番目の到着を超える需要に対応するための再注文は、次の再注文の機会まで延期する必要があります。
再注文の判断をサポートするために、予測する必要がある2つの要素があります。まず、最初の到着時点での在庫の予想を予測する必要があります。実際、最初の到着時点までにまだ十分な在庫が残っている場合、今すぐ再注文する理由はありません。2つ目に、責任の窓の期間における需要の予測を予測する必要があります。実際のセットアップでは、今注文している商品の保管コストを評価するために、責任の窓を超える需要も予測する必要があります。なぜなら、後の期間に流れ込む可能性がある残り物があるかもしれないからです。ただし、簡潔さとタイミングのために、今日は責任の窓に関連する予想在庫と需要に焦点を当てます。
このスクリプトは、さきほど説明した責任の窓の要素または予測を実装しています。確率的なリードタイム予測と確率的な需要予測を入力として受け取り、到着時の在庫と責任の窓によってスコープされた適格な需要の2つの確率分布を返します。
1行目と2行目では、タイムラインを設定しています。これは1月1日から3月1日までの期間です。予測のセットアップでは、このタイムラインはハードコードされません。4行目では、単純な確率的需要モデルが導入されています。このタイムライン全体で日々繰り返されるポアソン分布です。需要は平均して1ユニット/日です。ここでは明確さのために需要の単純なモデルを使用していますが、実際のセットアップでは、例えばESSM（アンサンブル状態空間モデル）を使用することがあります。状態空間モデルは確率モデルであり、この章の最初の講義で紹介されました。
5行目では、別の単純な確率モデルが導入されています。この2番目のモデルはリードタイムを対象としています。これは右に7日シフトされたポアソン分布です。シフトは畳み込みを介して行われます。6行目では、初期の在庫を定義しています。7行目では、注文サイクルを定義しています。この値は日数で表され、次の再注文が行われるタイミングを特徴付けます。
9行目から16行目では、スクリプトのコアロジックを表すモンテカルロブロックがあります。この講義の前半で、クロスバリデーションロジックをサポートするために別のモンテカルロブロックをすでに紹介しました。ここでは、再注文の判断を反映する2つの確率変数を計算したいのですが、確率変数の代数はこの計算を実行するために十分に表現力がありません。そのため、モンテカルロブロックを使用しています。
この章の第3回の講義では、確率的予測とシミュレーションの間に双対性があることを指摘しました。モンテカルロブロックはこの双対性を示しています。確率的予測からシミュレーションに変換し、最終的にシミュレーションの結果を別の確率的予測に変換します。
細かい点を見てみましょう。10行目では、需要の軌跡を生成しています。11行目では、今日注文すると仮定して、最初の注文の到着日を生成しています。12行目では、注文周期から1つの注文サイクル後に注文すると仮定して、2番目の注文の到着日を生成しています。13行目では、最初の到着日までの在庫残量を計算しています。これは、最初のリードタイムの期間に観測された需要を差し引いた初期在庫からなります。max zeroは、在庫がマイナスにならないことを示しています。つまり、私たちはバックログを取らないと仮定しています。このバックログのない仮定は変更できます。バックログの場合は、未処理の需要の一部がバックログに正常に変換される割合を評価するために、日数が再入荷可能な在庫の利用可能性の前にある日数に応じて、微分可能プログラミングを使用できます。
スクリプトに戻り、14行目では、責任範囲内で発生する需要を計算しています。15行と16行では、「sample」キーワードを使用して興味のある2つの確率変数を収集しています。この講義の最初のEnvisionスクリプトでは、クロスバリデーションに取り組んでいましたが、ここでは、このモンテカルロブロックから確率分布を収集することを目指しています。15行と16行の両方で、代入の右側に表示される確率変数は集約子です。15行では、到着時の在庫の確率変数を取得します。16行では、責任範囲内で発生する需要の別の確率変数を取得します。
18行と19行では、これらの2つの確率変数が表示されます。さて、このスクリプト全体を一時停止して考え直してみましょう。1行から7行までは、モックデータのセットアップに費やされています。18行と19行は結果を表示するだけです。実際のロジックは、9行から16行の8行の間にのみ存在します。実際、すべての実際のロジックは、ある意味では13行と14行にあります。
たった数行のコード、数え方に関係なく10行未満で、確率的リードタイム予測と確率的需要予測を組み合わせて、実際のサプライチェーンの意義に関するハイブリッド確率的予測を作成します。ここで重要なのは、リードタイム予測や需要予測の具体的な内容には依存しないということです。単純なモデルが使用されていますが、洗練されたモデルを使用することもできます。何も変わりませんでした。唯一の要件は、2つの確率モデルを持っていることであり、それによってこれらの軌跡を生成することが可能になります。
最後に、スクリプトによって生成されたヒストグラムが画面に表示されます。上のヒストグラムは到着時の在庫を表しています。おおよそ30%の確率で初期在庫がゼロになる可能性があります。つまり、最初の到着日の直前の最終日までに在庫切れが発生する可能性が30%あります。平均在庫量は5ユニット程度になるかもしれません。しかし、この状況を平均値で判断すると、状況を誤解する可能性があります。適切な初期在庫状況を反映するためには、確率的予測が必要です。
下のヒストグラムは責任範囲に関連する需要を表しています。おおよそ10%の確率で需要がゼロになる可能性があります。この結果も驚くべきものとして捉えられるかもしれません。実際には、平均して1日あたり1ユニットの定常ポアソン需要から始めました。注文間には7日間あります。リードタイムが通常よりも長く、2番目のリードタイムが通常よりも短い場合を除いて、7日間でゼロ需要が発生する確率は0.1%未満であるはずです。しかし、スクリプトはこの発生頻度がはるかに高いことを証明しています。その理由は、最初のリードタイムが通常よりも長く、2番目のリードタイムが通常よりも短い場合に、責任範囲が短くなる可能性があるからです。
責任範囲内でのゼロ需要に直面することは、在庫がある時点で非常に高くなる可能性があることを意味します。状況によっては、これが重要であるかどうかは異なるかもしれませんが、たとえば在庫の容量制限がある場合や在庫が腐敗しやすい場合など、重要な要素となる可能性があります。再度、平均需要はおそらく8程度であり、需要の実際の様子を信頼できる洞察を提供しません。初期の定常需要からこの非対称な分布を得たことを思い出してください。これが変動するリードタイムの効果です。
このシンプルなセットアップは、在庫補充の状況においてリードタイムの重要性を示しています。サプライチェーンの観点からは、リードタイムの予測を需要予測から分離することは、せいぜい実用的な抽象化です。日々の需要は本当に興味があるものではありません。真に興味があるのは、リードタイムと需要の組み合わせです。バックログや返品などの他の確率的要素が存在する場合、それらの要素もモデルの一部となるでしょう。
この講義シリーズの現在の章は、「需要予測」というよりも「予測モデリング」というタイトルになっています。これは、現在の講義を進めるにつれて、その理由が徐々に明らかになるはずです。実際、サプライチェーンの観点からは、サプライチェーンシステムの進化を予測したいのです。需要は確かに重要な要素ですが、それだけではありません。リードタイムなどの他の変動要素も予測する必要があります。さらに重要なことは、これらの要素を最終的に一緒に予測することです。
実際には、意思決定プロセスをサポートするために、これらの予測要素を組み合わせる必要があります。したがって、重要なのは、ある種の最終的な需要予測モデルを求めることではありません。これは、結局のところ、会社の最善の利益に反する方法で精度を向上させることになるため、大いに無駄な努力です。洗練度が高いほど、透明性が高くなり、バグや計算リソースが増えます。一般的な指針として、モデルが洗練されれば洗練されるほど、別のモデルとの成功した運用的な組み合わせが困難になります。重要なのは、自由に組み合わせることができる予測技術のコレクションを組み立てることです。これが予測モデリングの観点からのモジュール性です。この講義では、半ダースの技術が紹介されました。これらの技術は、不完全な観測などの重要な実世界の側面に対応しています。また、非常にシンプルです。今日紹介されたコード例のいずれも、実際のロジックは10行を超えませんでした。最も重要なことは、これらの技術がレゴブロックのようにモジュール化されていることです。それらはうまく連携し、ほぼ無限に再組み合わせすることができます。
サプライチェーンの予測モデリングの最終目標は、そのような技術の特定です。各技術はそれ自体で、既存の予測モデルを見直し、このモデルを簡素化または改善する機会となるべきです。
結論として、学術界ではリードタイムがほとんど無視されているにもかかわらず、リードタイムは予測できるし、予測すべきです。実世界のリードタイム分布の短いシリーズを見直すことで、2つの課題を特定しました。第一に、リードタイムは変動します。第二に、リードタイムはまばらです。したがって、まばらで不規則なリードタイムの観測に対処するのに適したモデリング技術を導入しました。
これらのリードタイムモデルは確率的であり、この章を通じて徐々に導入されてきたモデルの継続です。また、確率の観点からは、供給チェーンにおける不完全な観測の問題に対して優れた解決策を提供することがわかりました。この問題は、在庫切れや保留中の注文がある場合に発生します。最後に、確率的なリードタイム予測と確率的な需要予測を組み合わせて、後続の意思決定プロセスをサポートするために必要な予測モデルを作成する方法を見てきました。
次回の講義は3月8日に行われます。同じ時間帯で、パリ時間の午後3時に行われます。今日の講義は技術的でしたが、次回は非常に技術的ではなく、サプライチェーンサイエンティストの事例について話し合います。実際、主流のサプライチェーンの教科書では、予測モデルや最適化モデルがどのようにして現れ、作動するのかをまったく無視し、それらの「ウェットウェア」コンポーネント、つまり責任者を完全に無視してサプライチェーンにアプローチしています。したがって、サプライチェーンサイエンティストの役割と責任について詳しく見ていきます。サプライチェーンイニシアチブを主導することが期待される人物です。
さて、質問に進みます。
質問: イノベーションのために在庫を保持したり、ジャストインタイムやその他の概念以外の理由で在庫を保持したい場合はどうすればよいですか？
これは非常に重要な質問です。この概念は、この講義シリーズでは「経済ドライバー」と呼んでいるサプライチェーンの経済モデリングを通じて通常取り上げられます。あなたが尋ねているのは、今日顧客にサービスを提供しない方が、後で何らかの理由でより重要な人に同じユニットを提供する機会がある場合には、その顧客にサービスを提供しない方が良いかどうかということです。要するに、あなたが言っているのは、後で別の顧客、たとえばVIPの顧客にサービスを提供することでより多くの価値を得ることができるということです。
これは実際に起こることがあります。たとえば、航空業界では、MRO（メンテナンス、修理、オーバーホール）プロバイダーであるとしましょう。通常のVIPクライアント、つまり長期契約で定期的にサービスを提供している航空会社があります。このような場合、常にこれらのクライアントにサービスを提供できるようにする必要があります。しかし、別の航空会社から電話がかかってきて、1つのユニットを依頼された場合はどうなるでしょうか？この場合、この人にサービスを提供することができますが、彼らとは長期契約を結んでいません。したがって、後で在庫切れに直面する可能性を補うために、価格を非常に高く調整します。この最初の質問については、予測の問題ではなく、経済ドライバーの適切なモデリングの問題だと思います。在庫を保持したい場合、在庫が残っている間に1つのユニットを求める顧客にサービスを提供しないという合理的な反応を示す最適化モデルを生成したいのです。
ちなみに、これにはもう1つの典型的な状況があります。それはキットを販売している場合です。キットは多くの部品の組み立てであり、一緒に販売されるもので、残りの1つの部品は総キットの価値のほんの一部しかありません。問題は、この最後のユニットを販売すると、キットをフル価格で販売することができなくなることです。したがって、後でキットを売るためにユニットを在庫に保持することを好む状況になるかもしれませんが、それも経済ドライバーに帰結し、私がこの状況に取り組む方法です。
質問: 過去数年間、ほとんどのサプライチェーンの遅延は戦争やパンデミックのために起こりましたが、これは以前には存在しなかった非常に予測困難な状況です。あなたはこれについてどう思いますか？
私の考えでは、リードタイムはずっと変動しています。私は2008年からサプライチェーンの世界にいて、私の両親も私より30年前からサプライチェーンで働いていました。私たちが覚えている限り、リードタイムは不規則で変動しています。常に何かが起こっています。抗議活動、戦争、関税の変更などです。はい、過去数年間は非常に不規則でしたが、リードタイムはすでにかなり変動していました。
私は誰もが次の戦争やパンデミックを予測できるわけではないと同意します。これらの出来事を数学的に予測できるならば、人々は戦争に関与したり、サプライチェーンに投資したりせず、単に株式市場で遊んで市場の動きを予測して富を築くことができるでしょう。
肝心なのは、予期せぬ事態に備えることができるということです。将来に自信がない場合、実際には予測のばらつきを増やすことができます。予測をより正確にすることではなく、平均的な期待値を保持し、ただしその確率的な予測に基づいて行う決定が変動に対してよりレジリエントになるように、テールを膨らませるのです。予想される変動を現在見ているものよりも大きくするように設計されています。肝心なのは、簡単か難しいかという考え方は、未来の正確な予測が可能であるかのような一点予測の視点から来ています。これは事実ではありません。未来の正確な予測など存在しません。できることは、将来の無知を示し量子化する広がりのある確率分布と共に作業することだけです。
正確な計画の細かい実行に極めて依存するような意思決定を微調整する代わりに、興味深い程度の変動を考慮し、計画することで、それらの変動に対してより堅牢な意思決定を行うことができます。ただし、これは供給チェーンにあまりにも激しい影響を与えるような変動には適用されません。たとえば、サプライヤーのリードタイムが長くなっても対処できますが、倉庫が爆撃された場合、どんな予測もその状況では救いません。
質問: Microsoft Excelなどでこれらのヒストグラムを作成し、CRPSを計算することはできますか？たとえば、itsastatなどのExcelアドインや多くの分布をホストするものを使用することはできますか？
はい、できます。Lokadの私たちの一人が、在庫補充の状況のための確率モデルを表すExcelスプレッドシートを実際に作成しました。問題の核心は、Excelにはヒストグラムのデータ型が存在しないため、Excelには数値しかありません。Excelには、セルごとに1つの数値しかありません。1つのセルにヒストグラムが詰まった1つの値を持つことができれば、エレガントでシンプルです。ただし、私の知る限り、これはExcelでは不可能です。ただし、ヒストグラムを表現するために約100行程度のコードを書くことができれば、コンパクトで実用的ではありませんが、Excelで分布を実装し、確率モデリングを行うことができます。例のリンクをコメントセクションに投稿します。
Excelはこのタスクに理想的に適しているわけではないため、それは比較的困難な作業です。Excelはプログラミング言語であり、何でもできるため、この作業を達成するためにはアドインは必要ありません。ただし、少し冗長になるので、非常に整然としたものは期待しないでください。
質問: リードタイムは注文時間、生産時間、輸送時間などの要素に分解することができます。リードタイムに対してより詳細な制御をしたい場合、このアプローチはどのように変わりますか？
まず、リードタイムをより制御するとはどういう意味か考える必要があります。平均リードタイムを短縮するのか、リードタイムの変動性を減らすのかです。興味深いことに、多くの企業が平均リードタイムを短縮することに成功していますが、その代わりにリードタイムの変動性が増えています。平均的にはリードタイムは短くなっていますが、時折非常に長くなることもあります。
この講義では、モデリングの演習を行っています。それ自体にはアクションはありません。ただ観察し、分析し、予測するだけです。しかし、リードタイムを分解し、その背後にある分布を分析することができれば、どの要素が最も変動し、どの要素がサプライチェーンに最も大きな悪影響を与えているかを確率モデリングを使用して評価することができます。この情報を使用して「もしも」のシナリオに取り組むことができます。例えば、リードタイムの一部を取り上げて、「もしもこのリードタイムのテールが少し短くなったら、または平均が少し短くなったらどうなるか」と尋ねることができます。それからすべてを再構成し、サプライチェーン全体の予測モデルを再実行し、影響を評価することができます。
このアプローチにより、特定の現象について分割して考えることができます。それはアプローチの変更ではなく、これまで行ってきたことの継続であり、第6章に続く実際の意思決定の最適化に取り組んでいます。
質問: SAPでリードタイムを再計算して、より現実的な時間枠を提供し、システムの引き込みと引き出しを最小限に抑えることは可能ですか？
免責事項: SAPはサプライチェーン最適化の分野でLokadの競合他社です。私の初期の回答は「いいえ、SAPはそれをすることはできません」となります。現実的には、SAPにはサプライチェーン最適化に関わる4つの異なるソリューションがあり、それはどのスタックについて話しているかによります。ただし、それらのスタックはすべて、ポイント予測を中心としたビジョンを共有しています。SAPのすべての要素は、予測が正確であるという前提のもとに設計されています。
はい、SAPにはこの講義の最初に言及した正規分布のような調整可能なパラメータがあります。ただし、私たちが観察したリードタイムの分布は正規分布ではありませんでした。私の知る限り、サプライチェーン最適化のための主流のSAPの設定では、リードタイムに正規分布を採用しています。問題は、ソフトウェアのコアに広く間違った数学的な仮定が組み込まれていることです。パラメータを調整することで正しい意思決定を生成することができるかもしれませんが、理論的には可能ですが、実際には多くの問題が発生するため、本当にそれをやりたいと思う理由はありません。
確率的な視点を採用するには、予測が確率的であり、最適化モデルも確率モデルを活用する必要があります。問題は、リードタイムのわずかな改善のために確率モデリングを調整できたとしても、SAPの他の部分はポイント予測に戻ってしまうことです。何が起ころうとも、それらの分布はポイントに収束してしまいます。平均で近似できるという考えは問題であり、完全に間違っています。したがって、技術的にはリードタイムを調整することができますが、その後に多くの問題に直面する可能性があるため、それに努力を費やす価値があるかどうかは疑問です。
質問: 同じ部品を異なるサプライヤーから注文する場合があります。これはリードタイムの予測を処理するための重要な情報です。アイテムごとにリードタイムの予測を行うのか、アイテムをグループ化することで利点を得る場合があるのか、教えてください。
これは非常に興味深い質問です。同じアイテムに対して2つのサプライヤーがある場合を考えてみましょう。問題は、アイテムとサプライヤーの間にどれだけの類似性があるかです。まず、状況を見てみる必要があります。もし1つのサプライヤーが隣にあり、もう1つのサプライヤーが世界の反対側にある場合、それらのことを別々に考える必要があります。しかし、興味深い状況を想定しましょう。2つのサプライヤーがかなり似ていて、同じアイテムである場合、それらの観測値をまとめるべきかどうかはどうでしょうか？
興味深いことに、微分可能なプログラミングを通じて、サプライヤーに一定の重みを与え、アイテムにも一定の重みを与えるモデルを作成し、学習の魔法に任せることができます。これにより、リードタイムのアイテムコンポーネントに重みを置くべきか、サプライヤーコンポーネントに重みを置くべきかを適合させることができます。同じ種類の製品を提供する2つのサプライヤーのうち、一方のサプライヤーが平均的に少し速いというバイアスがあるかもしれません。しかし、時間がかかるアイテムも確かに存在し、したがって、アイテムを選り分けると、どのサプライヤーがもう一方よりも速いかは非常に明確ではありません。すべてのサプライヤーとアイテムを細分化すると、おそらく非常に少ないデータしかありません。したがって、興味深いこと、そしてここでお勧めすることは、微分可能なプログラミングを通じてエンジニアリングを行うことです。後の講義でこの状況を再評価してみるかもしれません。部品レベルでいくつかのパラメータとサプライヤーレベルでいくつかのパラメータを設定する状況です。したがって、パラメータの総数は部品の数×サプライヤーの数ではなく、部品の数にサプライヤーの数を加えたもの、またはサプライヤーの数×カテゴリの数を加えたものになります。パラメータの数を爆発させることはありません。サプライヤーに親和性を持つ要素であるパラメータを追加するだけで、過去のデータに基づいて動的なミックスを行うことができます。
質問: 注文される数量と一緒に注文される製品も最終的なリードタイムに影響すると思います。この種の問題にすべての変数を含める複雑さについて説明していただけますか？
前の例では、注文サイクルとリードタイムの2種類の期間がありました。注文サイクルは興味深いものです。なぜなら、まだ決定を下していない限り、不確定性があるからです。基本的にはいつでも決定できるものであり、注文サイクルは完全に内部的で自己生成的なものです。これは供給チェーンにおいて同じです。価格も同じです。需要は観測できますが、実際には希望する価格を選ぶことができます。一部の価格は明らかに賢明ではありませんが、同じです-それは自己生成的なものです。
注文サイクルは自己生成的なものです。今、あなたが言っているのは、次の注文リードタイムの正確な時点については不確実性があるということです。確かに、完全に正しいです。この確率モデリングを実装する能力があると、この講義シリーズの第6章で議論されているように、注文サイクルは7日間であると言いたくありません。代わりに、会社の投資利益を最大化する再注文ポリシーを採用したいのです。したがって、現在再注文することで、今日から日々の方針を適用することができます。将来のある時点で再注文を行い、今度は「自分の尾を食べる蛇」のような状況になります。今日の最良の注文決定は、まだ行っていない次の注文決定の決定に依存するからです。この種の問題はポリシー問題として知られており、連続的な意思決定問題です。本質的には、意思決定プロセスを統制する数学的なオブジェクトであるポリシーを作成したいのです。
ポリシー最適化の問題は非常に複雑ですが、私は第6章でこれについて取り上げる予定です。しかし、結論として、質問に戻ると、2つの異なるコンポーネントがあります。何をするにしても独立して変動するコンポーネントであるサプライヤーリードタイムと、プロセスによって内部的に駆動される注文時間です。注文時間は最適化の問題として扱われるべきです。
この考えを締めくくると、最適化と予測モデリングの収束が見られます。結局のところ、あなたが行う決定と将来の出来事には相互作用があるため、ほぼ同じものになります。
今日はこれで終わりです。忘れずに、3月8日、同じ時間、水曜日の午後3時です。ありがとうございました。また次回をお楽しみに。
