00:00:00 インタビューの紹介
00:02:15 確率的予測とサプライチェーンの最適化
00:04:31 確率的最適化と意思決定
00:06:45 確率的最適化の要素:変数、制約、損失関数
00:09:00 モデリングと最適化に関する展望
00:11:15 最適化における制約と最悪のシナリオ
00:13:30 不確実性、制約、および不十分な解決策
00:15:45 確定的最適化と異なるシナリオ
00:18:00 MROスペースオペレーションと在庫最適化
00:20:15 リードタイムと修理可能部品の不確実性
00:22:30 部品の不足と古典的なアプローチの制約
00:24:45 サプライチェーンにおける確率的要素と人間による確率性
00:27:00 航空機エンジンの修理と部品の調達
00:29:15 在庫最適化と確率的な材料リスト
00:31:30 サプライチェーン最適化と反応性のポリシー
00:33:45 サプライチェーンにおけるスケーラビリティの問題と凸関数
00:36:00 問題の緩和とサプライチェーン問題における制約
00:38:15 ローカルサーチツールとサプライチェーンにおける実行可能な解決策
00:40:30 メタヒューリスティック遺伝的アルゴリズムとスケーラビリティの課題
00:42:45 スケーラビリティの問題としての数学的最適化
00:45:00 Lokadによる確率的最適化技術の開発
00:47:15 サプライチェーンにおける相互依存関係とお金で問題を解決する
00:49:30 シェルフリミットの制約とヨーグルトの在庫の例
00:51:45 確率的最適化と不確実性のまとめ
00:54:00 ソルバーの役割とサプライチェーン最適化
00:56:15 ‘ソルバー’と最終的な意思決定の計算の明確化
00:58:30 ソルバーの解決策の問題と潜在的な欠点
01:00:45 要点:確率的最適化の重要性
01:03:00 サプライチェーンの不確実性を無視することと優れたソルバーの利点
01:05:15 非自明なサプライチェーンにおける依存関係と相互依存関係
01:07:30 インタビューの終わり

要約

LokadのCEOであるJoannes Vermorelとコミュニケーション担当のConor Dohertyの間の議論では、確率的最適化と供給チェーン管理における確率的予測の重要性が強調されています。Vermorelは、供給チェーンのシナリオでは、損失関数が不確定であることがよくあると説明しています。彼は数学的最適化の3つの要素である変数、制約、損失関数を概説し、確率的最適化では損失関数が確定的ではなくランダム化されることを説明しています。また、供給チェーンの数学的最適化技術のスケーラビリティの問題についても議論し、これが40年間の障害となっていると指摘しています。彼は確率的最適化が供給チェーンの教科書でしばしば見落とされる重要な要素であることを強調して結論付けています。

Lokadのコミュニケーション担当であるConor DohertyとLokadのCEO兼創設者であるJoannes Vermorelの対話では、確率的最適化と供給チェーン管理における確率的予測の複雑さについて掘り下げています。Vermorelは、将来の明確で数量化された予測の重要性を強調し、これが供給チェーンの最適化に不可欠であると述べています。彼は確率的性質の概念を紹介し、損失関数が不確定またはノイズがある状況を指しており、これは供給チェーンのシナリオでよく起こることです。

Vermorelは、損失関数が経済的なドライバーを通じて表現され、ビジネスにかかるドルを反映するように微調整されることを説明しています。彼は、効果的な確率的予測があっても、供給チェーン管理の固有の不確実性と非線形性のために最適化が依然として必要であると主張しています。彼は数学的最適化の3つの要素である変数、制約、損失関数を概説し、確率的最適化では損失関数が確定的ではなくランダム化されることを説明しています。

Vermorelは、数学的最適化における制約の概念についてさらに詳しく説明し、受け入れられない解を表現する方法であると強調しています。彼は、これらの制約が損失関数と同様にビジネス戦略と一致する必要があると強調しています。彼はまた、制約が数学的に真または偽ではなく、存在するだけであることを指摘しています。たとえば、最大容量が100ユニットであるというのは数学的には正しくないが、単に与えられたものであると説明しています。彼は確率的な世界では、制約が数学的により微妙になり、配送時間などの要素の変動により常に強制されない場合があると説明しています。

メンテナンス、修理、オーバーホール(MRO)企業の文脈で、Vermorelは在庫最適化が重要であると説明しています。部品のリストは確率的であり、1つの部品が欠けるとコンポーネントを修理することができません。Lokadは、部品の到着と修理に必要な部品の到着を予測するために確率的予測を使用しています。部品の購入に関する意思決定は、戻ってくる部品と潜在的な廃棄率を考慮に入れる必要があります。目標は部品の購入問題を解決することです。

Vermorelは、部品を単独ではなく一緒に考える確率的最適化アプローチの必要性を強調しています。特定の組み合わせのユニットを取得する経済的価値は、部品を一つずつ分析する場合とは大きく異なる場合があります。彼は、修理の能力の確率的性質をこのモデルに組み込むことができると述べています。

Vermorelは、サプライチェーンの数学的最適化技術のスケーラビリティの問題についても議論しています。これらの技術のスケーラビリティは、すべての制約が適用された後にどれだけの余地が残っているかに依存します。彼は、解空間の除去技術にアプローチするソルバーは、千の変数を超えると性能が低下すると指摘しています。

Vermorelは、Lokadがサプライチェーンに適したスケールでこれらの問題に対処するために、確率的最適化のための新しい技術を開発する必要があったと説明しています。彼は、確率的最適化が従来の数学的最適化と比較して、より柔軟で反応性のある意思決定の最適化方法であるとDohertyの要約に同意しています。彼はまた、これらの問題に対処するためのソフトウェアコンポーネントであるソルバーの必要性についても言及しています。

Vermorelは、ソルバーがLokadが顧客に提案する最終的な意思決定を生成することを確認しています。彼は、ヒューリスティックスを含む最適化のアプローチ方法はさまざまであるが、ソルバーは予測を入力として最終的な意思決定を生成するツールであると説明しています。彼は、「数値レシピ」とは、データの準備から結果の生成までの処理の連鎖を指し、「ソルバー」とは予測を入力として最終的な意思決定を計算することを指すと説明しています。

Vermorelは、確率的最適化がサプライチェーンの教科書ではしばしば見落とされる重要な要素であると強調して結論付けています。彼は、サプライチェーンの問題に固有の不確実性を無視した確定的最適化問題のソルバーを販売する既存のプレーヤーを批判しています。彼は、確率的ソルバーの利点を強調し、サプライチェーンとその相互依存関係を包括的に見ることができると述べています。

フルトランスクリプト

Conor Doherty: 確率的最適化は、経済的に妥当な意思決定を定量化し、最適化するためのツールです。ここには、その重要性と、重要な点での動作方法を説明するために、Lokadの創設者であるJoannes Vermorelがいます。では、Joannes、最適化という言葉を私たちが異なる文脈で何度も聞いたことがあると思いますが、それは通常、確率的予測と同じくらいの頻度で使用されます。つまり、これらは私たちが使用する2つの主要なツールです。では、確率的最適化の数学的な詳細に入る前に、これらのツールのエグゼクティブレベルの要約と、なぜそれらが重要なのかについて教えてください。

Joannes Vermorel: 確率的予測は、将来の明確で定量化された予測を持つことに関するものです。ですので、サプライチェーンを最適化するためには、将来に関する情報が必要です。定量化された情報が必要です。確率的予測は、将来を知るだけでなく、自分が何を知らないかを知ること、不確実性を定量化することに関するものです。これは、将来に待ち受けていることを理解するための一部であり、より情報を得て意思決定を行うためのものです。

2番目の部分は、より良い意思決定に至ることです。それはどういう意味ですか?そして、ここでは、数学的な意味での最適化があります。数学的な意味では、与えられた問題に対して、数値基準に従って損失がより小さい解を見つけることを意味します。この議論のために、私たちは損失の観点に焦点を当てることになるでしょう。つまり、損失を最小化したいという視点です。

したがって、この意味での最適化は純粋に数学的な操作です。与えられた問題に対して、自分自身に与えた損失関数を最小化する解を見つけることです。

Conor Doherty: 例えば、この意思決定の結果であまりお金を失いたくないということですね。

Joannes Vermorel: サプライチェーンの場合、基本的な意思決定は、いくつのユニットを注文するかです。そして、私が選んだ任意の数量には、在庫保有コスト在庫切れのペナルティがあります。もちろん、利益を上げるために商品を販売することで実現する利益もありますが、それはネガティブな損失として現れるため、実際には商品を販売することでさらに最小化することができます。

Conor Doherty: では、制約について話しているとき、ほとんどの人は理解できると思います。しかし、確率論はどこにありますか?最適化はできますが、確率論はどこにありますか?

Joannes Vermorel: 確率論は、損失関数が不確実である問題のクラスを指します。損失関数がノイズを含む不確実なものである場合です。非常に古典的な在庫補充問題に移行してみましょう。今日再注文する数量を選びますが、この意思決定から得られるスコアや損失は後でしかわかりません。そして、今のところ、最終的な損失がどうなるかについては不確実性に取り残されています。したがって、損失関数が事前に確実にはわからない状況では、すべてが完全にわかっている古典的な決定論的最適化問題とは異なり、確率論的最適化問題になります。

コンポーネント配置を行いたい場合、さまざまなコンポーネントを物理的な寸法すべてを考慮してボックスに収めたいとします。これは完全にわかっている問題ですので、完全な組み合わせを見つけることは非常に困難かもしれませんが、サプライチェーンの状況とは異なり、不確実性はありません。サプライチェーンの状況は、私が言うには、非常に確率論的な状況であり、不確実性があると言えます。

確率的予測はこの不確実性を組み込んでいますが、何も解決しません。それは単にこれが未来であり、これが不確実性であると伝えるだけです。それは意思決定プロセスや意思決定生成プロセスではありません。その部分が最適化であり、より具体的には確率論的最適化です。

Conor Doherty: では、その確率論性を考慮して、どのように損失関数を微調整するのですか?

Joannes Vermorel: 損失関数は非常にシンプルです。Lokadでは、経済的な要素を通じて表現していますので、単にエラーのドルを最小化することになります。この損失関数を適切に調整するためには、ビジネスに関するノウハウがたくさん必要です。ビジネスのドルを反映するようにするためです。私たちは2つの直交する関心事を持っています。1つは、ビジネス戦略に完全に忠実な損失関数を見つけることです。ただし、これには特定の数値最適化スキルは必要ありません。単に、ビジネスを反映するものがあるかどうかです。基本的な算術演算だけで済みます。特別なことではありません。もう1つは、任意の損失関数に対して確率論的最適化を行うために必要なことです。

Conor Doherty: まあ、非常に良いまたは非常に効果的な確率論的予測を行うと、最適化部分を完全にスキップできるのではないでしょうか?将来の行動や需要がよりよくわかるのであれば、なぜこれらの他の要素をバランスさせる必要があるのでしょうか?特定の量を注文するか、最も確からしいリターンを注文すればいいのではないでしょうか?

Joannes Vermorel: 将来について完全な知識を持っている場合、意思決定部分はそれほど複雑ではありません。ただし、この種の状況でも、MOQsや一律の発注コスト、一律の輸送コストに対処する必要があります。将来を完全に知っていても、解が簡単なものではないいくつかの非線形性に直面することになります。

しかし、実際の状況はそれよりもはるかに悪いです。将来について非常に不完全な知識しか持っていないのです。不確実性を排除する予測を得ることは完全に合理的な評価ではありません。不確実性は減らすことができますが、それは大部分において不可避です。したがって、不確実性に取り残され、明らかな解決策はありません。明らかな解決策は得られません。

Conor Doherty: よし、それでは少し戻って、確率的最適化について話しましょう。あなたは要素について話しました。損失関数をリストアップしましたが、確率的最適化に必要な要素は損失関数だけではありません。では、これにはどのような要素が必要ですか?

Joannes Vermorel: 数学的最適化に取り組む際には、3つの要素があります。最初に変数があります。変数は基本的には選択できるものです。これがあなたの解を定義するものです。解は変数の特定の組み合わせです。

パッドロックの適切な組み合わせを見つけるというような離散問題を考える場合、4つの変数があるとしましょう。各変数には10の位置があり、各組み合わせが潜在的な解を定義します。クリックして開く1つの解を見つけたいのです。

最初の要素は変数です。サプライチェーンでは、変数が整数であるため、離散的な問題に頻繁に言及しています。0ユニット、1ユニット、2ユニット、3ユニットなどを再注文することができますが、通常は0.5ユニットを再注文することはできません。離散性の側面があるため、簡単に1つの解から別の解に移行することはできません。非常に非線形なパターンが多く発生します。

たとえば、0から1ユニットに移行することは、微小な分数から移行することとは非常に異なります。また、最小発注数量(MOQ)などの要素もあります。解に到達するためには、100ユニット先にジャンプする必要があります。

Conor Doherty: 制約ですね。

Joannes Vermorel: そして、2つ目は制約です。通常、変数と制約をリストアップします。制約は変数に関する数学的な式のセットであり、これが受け入れ可能な、実行可能な解であるかどうかを示します。

たとえば、補充の場合、何ユニットでも注文することができますが、棚には有限の容量があります。棚には一日に受け取ることができる商品の最大容量があります。店舗や倉庫など、サプライチェーン内の他の場所でも、一日に処理できる商品の最大容量があります。

そのような制約はたくさんあります。たとえば、見栄えの良い棚を作るためには、少なくともこれ、これ、そしてそれが必要です。これは店舗のマーチャンダイジングの制約です。

変数があり、制約があり、3つ目は損失関数です。損失関数は、すべての制約を満たす解に対して、ここにあなたの損失があり、それを最小限にしたいというものです。それは単なる慣例です。

これらの3つの要素が一緒になって、一般的な数学的最適化フレームワークを定義します。過去100年間、数学者たちはこのフレームワークを使用してきた理由は、実際に非常に一般的だからです。

ここでは、問題に非常に珍しい変化を加えている確率性のトリックを見ています。つまり、損失関数が確定的ではないということです。これは、入力を与えると保証された出力が得られるクラシックな数学関数ではありません。入力を与えるとランダムな出力が得られると言っています。

Conor Doherty: 制約のアイデアに戻ると、私が間違っているところを訂正してください。これらの制約を細分化することができます。たとえば、容量、棚の容量、倉庫の容量、1日に処理できる量などをリストアップしました。処理量は少し増やすことができますが、棚の容量は有限です。それは近いうちに変わることはありません。しかし、MOQは変更することができます。再交渉することができます。したがって、これらの制約のいくつかには柔軟性があります。それが、あなたが話している確率性の種類であり、それが意思決定に組み込まれているのですか?

Joannes Vermorel: それほどでもありません。制約は、単にいくつかの解が受け入れられないというアイデアを数学的に表現する方法です。再び、あなたのビジネス戦略に対する損失関数の適切性についての本当に深い問いがありますが、制約についても同じことが言えます。ですから、この制約は本当に制約なのでしょうか?この制約を解除するために実際に投資できるのか、ビジネスについて異なる考え方をすることができるのか、ということです。

また、アイデアは、実際には2つの異なる視点があるということです。1つはモデリングのアプローチであり、変数、損失関数、制約がビジネスに忠実であることを望むというものです。これは基本的には数学的でもアルゴリズム的でもない取り組みです。それは本当にこれらのことがビジネスに適しているかどうかを理解することに関わります。

しかし、数学的な意味では真でも偽でもない制約です。それはただ存在するだけです。これは、最大容量が100ユニットであると言うものです。この文には数学的な妥当性はありません。これは単に与えられたものです。数学者は、「はい、あなたは100を選びました。数学的に言えば、私はあなたに100が良い数かどうかを言うことはできません。ただし、もし100未満であるという制約と100以上であるという制約がある場合、解が存在しないことがわかります。

数学は与えられた入力の種類に対して判断を下しません。それは単に内部の整合性に関するものです。しかし、確率的な世界の確率性の面白いところは、制約が数学的な意味でより微妙になることです。

では、確率的な問題を持つことはどういう意味でしょうか。古い非確率的最適化の視点では、制約によって、この解は機能するか機能しないかが明確に分かれていました。損失は考慮されていません。しかし、損失関数が確率的である世界では、どういう意味になるのでしょうか。たとえば、倉庫があり、補充注文を出すことができ、倉庫の毎日の受入能力があるとします。

毎日、供給業者から処理できる単位数に制限があります。したがって、この倉庫では、供給業者のリードタイムを考慮して補充注文を分散させ、すべての供給業者が同じ日にすべてを配送し、倉庫の受入能力を超えないようにします。

確率的最適化の視点から見ると、数量を選択し、配送の時間に変動があります。これは、非常に不運な場合、補充注文が完全に適切である決定になるかもしれません。すべての補充注文が補充注文の順序に従って分散されているが、最初の注文が遅れていて、後の注文がさらに早い場合があります。偶然の一致で、すべてが同じ日に集中し、この日に倉庫が過負荷になります。名目の受入能力を超えています。

完全に実現可能な解決策がもはや存在しない状況はたくさんあります。つまり、制約条件が適用されない可能性がある状況に直面することがあります。これは私が述べている数学的な主張です。損失関数の性質と、あなたの意思決定が非決定論的である可能性があるという事実により、あなたは数量を決定するが、配送日に完全な制御を持たないというような結果が生じる可能性があります。

最善の意思決定をしても、在庫数量が重なる可能性があります。それが起こらないことを絶対に確実にする唯一の方法は、保留中のすべての注文が同じ日に配送される最悪のシナリオを考慮して、任意の日に受け取ることができるものを超えないようにすることです。これは明らかに極端な状況です。

ビジネスは、私の容量を超える可能性が1万分の1あるというような状況に対処しなければなりません。しかし、実際には、制約条件が絶対的であるという考え方は、数学的な考え方に近いものです。実際には、容量を超えるとコストが発生します。

確率的最適化の視点に入ると、制約条件は損失関数の一部になることがわかります。さもなければ、制約条件が低い確率で違反されることを許容するための許容度を持つ方法でアプローチします。サプライチェーンに直面する確率的最適化問題のほとんどの興味深い状況では、制約条件が違反される可能性がわずかに残ります。

Conor Doherty: その許容度について話すとき、それは実現可能性のことですよね?そして、それによって、測定されるのは?

Joannes Vermorel: それは問題に設定した容量によって測定されます。店舗を補充したいと言った場合、店舗の容量に合わせて意思決定を行います。しかし、もし店舗がある日何も売れないという偶然があった場合はどうでしょう?例えば、生鮮食品を扱っている場合、今日は牛乳を補充すると決め、その日の売上を把握せずにこの決定を行います。しかし、いくつかの単位が売れると仮定しています。そして、偶然の一致で、通常は毎日のように在庫の80%を売るこの店舗が、今日は何も売れないという純粋な偶然が起こった場合、制約を超えて補充することになるかもしれません。

重要な洞察は、不確実性が存在する状況では、損失関数だけでなく、制約条件の満足性も変動するということです。興味深い状況のほとんどでは、制約条件が完全に満たされない状況になります。制約条件が満たされることが保証された状況だけを求めるというのは誤りです。なぜなら、数学的には解が得られますが、非常に貧弱な解になるからです。何も注文せず、何もしない、ただそのままにしておくというような解が得られ、制約違反はありませんが、利益は確実に得られません。

Conor Doherty: では、注文を受け取り、注文をずらし、最も経済的な方法で行うという例に戻りたいと思います。それが、確率的アプローチであるということですね。数学的最適化に基づいた以前のモデルは、確率的な次元を欠いていたため、ちょうど説明した問題にどのように取り組みましたか?

Joannes Vermorel: それらは問題を完全に無視していました。古典的な確定論的数学的最適化では、あなたの意思決定の結果が変動することは考慮されておらず、存在しないのです。

この問題を緩和する方法はいくつかあります。1つの簡単な方法は、「まず、最適化を1つではなく、例えば100の異なるシナリオを共同で最適化すると定義することです。そして、私の意思決定はすべての可能な未来に対して共通である必要があり、それらのさまざまなシナリオにおいて、すべての制約が依然として満たされていることを確認しなければなりません」と言うことです。

では、確定論的なケースに戻るにはどうすればよいでしょうか?まあ、単に「私の状況を100回コピーして、100の異なる状況のバリアントを表現し、一度に100のインスタンスを持つマクロ展開された問題を最適化する」と言うことができます。

しかし、それを古典的なソルバーで行うこともできますが、それによって今日のサプライチェーンの実践者が実際に数学的最適化ツールを使用することを妨げている問題をさらに悪化させるだけです。そして、この問題はスケーラビリティです。

Conor Doherty: では、実際に特定の垂直線に適用し始めて、理論が実際の複雑さ、制約、変数とどのように相互作用するかを三次元的に理解できるようにするのは良いポイントになると思います。例えば、MRO会社を取ると、典型的なサイズで通常のサイズのフリートをサービスする、例えば10機の飛行機があり、それぞれが25万個の部品を持っているとします。これらの3つの要素は、あなたによると、確率的最適化と古典的な数学的最適化のどちらにどのように適合しますか?

Joannes Vermorel: MROにはどのような問題があるか見てみましょう。修理を行うために在庫を最適化したいのです。部品が入荷し、使用できない状態で修理を開始し、必要な部品を見つけます。したがって、部品表がありますが、部品表は確率的であり、不確実です。ここで確率性が発生します。修理用の部品が入手できるかどうかの不確実性があります。しかし、一度部品を入手すると、実際に修理に必要な部品がわかります。

問題は、1つの部品が欠けていると、部品を修理することができないということです。つまり、部品の90%を持っていることは問題を解決しません。行き詰まってしまいます。修理にはすべての部品が必要であり、すべての部品がなければ部品を修理することはできません。

Lokadでは、数年前からこのような状況のために確率的な予測を行っています。確率的な予測は、修理するための部品の到着を適切な確率で予測し、必要な部品の確率分布を予測することです。つまり、これが確率的な部品表になります。そして、どの部品を再発注するか、どの部品をどの数量で在庫に持っておくかを決定しなければなりません。そして、それらの部品にはリードタイムの不確実性もあります。そして、それらの部品のうちいくつかは修理可能です。

それらの部品のうち、あなたが部品を取り出すことでターンアラウンド時間を持つだけでなく、この部品自体が修理可能であるという不確実性もあります。したがって、この部品を修理して戻すことができますが、おそらくは別の部品をコンポーネントに入れるでしょう。なぜなら、部品が修理されて戻ってくるのを待つことはしたくないからです。

しかし、それはつまり、もし部品が必要かどうかを決定する場合、既にプロセス中の部品も考慮に入れなければならないということです。持っている部品だけでなく、戻ってくる部品も含まれます。そして、修理を試みますが修理ができない場合には廃棄率などの他の要素もあります。したがって、10個の部品が戻ってくると思っていたが、修理が不可能だったために8個しか手に入らなかった、というようなことが起こるかもしれません。

それは予測の一部であり、すべての不確実性です。最終的に行いたい決定は、部品の調達問題を解決することに関するものです。質問は、「すべての戻ってくる部品やその他のすべてを考慮に入れて、部品のユニットをもっと購入すべきかどうか」ということです。

部品は修理に貢献する場合に経済的な価値を持ちます。しかし、先ほど言及した南京錠のように、すべての部品が揃っている場合には修理が可能であり、それらの部品には価値があります。しかし、部品が不足している場合、それらはただの無駄な重さです。持っている部品は、完全な組み合わせがある場合にのみ役立ちます。組み合わせが1つ少ない場合、クライアントへの遅延が発生します。

いずれにせよ、在庫はすべてが揃っている場合にのみ役立ちます。そして、すべてが揃っていない場合、質問は「何かが不足していることが最後の瞬間にわかり、それに対して非常に遅い注文を出した場合、それが利用可能になるまでにどれくらいの時間がかかるのか」ということになります。

もし私たちがすべてのSKUが厳密に独立している単純な設定にいる場合、異なるクライアント、異なるすべてのものである場合、在庫位置ごとに経済的なスコアを計算し、このユニットを在庫に持つことの期待ドルのリターンを計算することができます。

しかし、MROでは、部品番号間に依存関係があるため、このアプローチはできません。1つのユニットを購入することを決定した場合、それ自体では価値がないかもしれません。しかし、別のユニットを購入することで、修理を完了させることができ、その両方の部品には多くの価値があります。

確率的な材料の構築に必要なすべての部品を持つまで、持っている部品は基本的には役に立ちません。彼らの経済的な価値は、一緒にあるときにのみ存在します。別々に使用する場合、彼らは価値を持ちません。したがって、この確率的最適化問題を解決するために使用するものは、部品を1つずつ購入したり、単独で持っている部品を考慮したりするのではなく、一緒に考えることができる必要があります。特定のユニットの組み合わせは、部品を1つずつ見る単独の分析と比べて、非常に異なる経済的な価値を持つ場合があります。

Conor Doherty: この考えを追いかけてみようと思いますが、すべてのこれらの確率要素を説明するとき、部品のターンアラウンド時間は1日、半日、3日、4日など、さまざまな時間がかかると言っています。また、人々が実際に修理を行う能力という、人間に基づく確率要素もあります。たとえば、部品を受け取った後、人が修理を行うまでにかかる時間は異なる場合があります。そのような人間に基づく確率要素も考慮できますか?

Joannes Vermorel: はい、人間は他の遅延の一種であり、能力も異なる場合があります。たとえば、一部のオペレーターは他の人よりも優れた才能を持っているため、より少ない部品が必要になるかもしれません。ある人は、修理が成功しない場合に物を捨てるだけでなく、より少ないものを消費して修理を行うことができるかもしれません。

航空宇宙 MROでは、コンポーネントは非常にモジュラーであり、コンポーネントはコンポーネントで構成されています。したがって、修理方法がわからない場合は、サブモジュール全体を廃棄し、新しいものに交換するオプションが常にあります。単に故障している部分を特定してそれだけを交換するのではなく、全体を交換するのです。

L6 もし、何を変更する必要があるかを正確に診断する能力があるなら、必要な変更だけを行います。もし能力が低い場合、多くの変更を行うことになるかもしれません。

しかし、話を元に戻しましょう。ここでのトリックは、解決策を定義する際に、方針の観点からそれを見る必要があるということです。つまり、あなたの解決策はただ今すぐに行う決定だけではなく、あなたの決定を導く一般的な原則です。方針は在庫にある部品を管理するかもしれませんが、確率的な部品リストが発見されたときにどのように反応するかも考慮に入れるでしょう。

なぜこれが重要なのでしょうか?たとえば、航空機のエンジンを修理したいとします。エンジンの外側にあるいくつかの部品は、最初に診断されるでしょう。したがって、修理のためにエンジンを受け取ると、エンジンを分解する際に最初に触れる部分が外側の部品であることがわかります。なぜなら、エンジンはコアに向かって多くの層を持つマトリョーシカのようなものだからです。

もしエンジンの外側にある部品を発見した場合、おそらくこの部品を調達するために多くの時間がかかるでしょう。なぜなら、航空機のエンジンをコアまで分解し、その後コアから外側に向かって徐々に組み立て直す必要があり、プロセスの最後にエンジンの外側に適合する部品が必要になるからです。

したがって、この部品は在庫に必要ありません。なぜなら、部品が必要になるまでに部品を再注文することができるからです。たとえば、部品のリードタイムが20日だった場合、部品が実際に必要になる60日前に部品を再注文することができるため、部品はすぐに利用可能です。

部品の在庫最適化を考える際には、確率的な部品リストの発見に対する典型的な反応としての方針を考慮する必要があります。

もし、航空機の分解作業を行う人が部品の在庫の有無についてまったく情報を持っていないという異なる方針を仮定すると、状況はまったく異なるものになります。なぜなら、エンジンを分解し、再び組み立てるまでに60日経っても、この1つの部品が不足していることがわかるからです。

ですから、方針はこのような連続的な意思決定の状況を表現し、状況が展開するにつれて最終的な経済的結果をどのように形作るかを示します。

ここでは2つの方針があります。1つはスマートな方針で、情報があるとすぐに対応し、発注を行います。もう1つは、部品を組み立てる必要があるときになって初めて部品が必要であることがわかり、その後発注を行います。もし方針が後者である場合、航空機のエンジンの遅延を防ぐために、部品を在庫に持つことに経済的価値が非常に高くなることを意味します。

最初の方針であるスマートな方針が採用されている場合、エンジンの外側にある部品を在庫に持つことには経済的価値がありません。方針により、部品が不足することはありません。なぜなら、発注は早めに行われるからです。

Conor Doherty: あなたが説明しているような反応性にはどのような技術的なオーバーヘッドが関連するのでしょうか?つまり、エンジンに進入して部品が必要であることがわかった場合、修理の予定された全体のタイムラインが完全に再構成されます。

Joannes Vermorel: それは非常に興味深い質問です。スケーラビリティは主要な懸念事項でした。スケーラビリティとは、サプライチェーンの数学的最適化技術のスケーラビリティのことを指します。これは実質的に40年間の障害となってきました。

数学的最適化は、研究の非常に確立された分野であり、ソルバーとして知られるソフトウェアプレーヤーが存在します。ソルバーは、数学的最適化問題に対処するために設計されたソフトウェアであり、通常、独自のプログラミング言語を備えています。通常、数学的プログラミング言語を使用して、変数、損失関数、制約条件を表現することができます。

興味深いことに、これらのソルバーは40年前に市場に導入されたにもかかわらず、現在ではオープンソースのソルバーも存在しますが、これらのソルバーはサプライチェーンではどこにも見られません。私はスケーラビリティが大きな問題だと考えています。

市場で利用可能な技術の種類を分解すると、まずはうまく振る舞う損失関数、凸関数があります。凸関数とは、関数が緩やかな曲線を持ち、解を選択するときに緩やかに最小値に向かって進むことができることを意味します。線形関数、二次関数などがうまく振る舞う関数です。このような関数はスケーラビリティの問題を抱えていません。数十億の変数を持つことができます。しかし、サプライチェーンで直面する問題は、このようにうまく振る舞っていません。

次に、制約条件が優勢であると仮定するブランチアンドバウンド、ブランチアンドカットなどのソルバーの2番目のクラスがあります。つまり、有効な解が非常に少ないと仮定します。つまり、制約条件が非常に多く、解の空間の超平面全体を排除できるほどです。実質的に、解の集合を半分に分割し、この半分は捨てることができます。なぜなら、これらの解は私が持っている制約条件を満たすことは絶対にありませんからです。そして、文字通り、解の半分を捨てて、解の半分を何度も排除するプロセスを繰り返します。そして最後に、非常に小さな空間にたどり着き、この小さな空間を非常に詳細に調査することができます。

さまざまなテクニックがあります。問題の制約条件を緩和するというもので、制約条件なしで問題を見て、制約条件なしで理想的な解を見つけ、その後に制約条件を再適用します。これらの問題は、非常に厳しい制約条件がない場合、非常にスケーラビリティが悪くなります。つまり、これらのテクニックのスケーラビリティは、すべての制約条件が適用された後にまだ持っている余地に非常に依存しています。そして、それが問題です。サプライチェーンでは、考慮する問題の種類によっては、多くの制約条件がありますが、それらは非常に厳しいものではありません。

パドロックを考えてみてください。パドロックには10,000の組み合わせがあり、クリックするのは1つだけで、他のすべては間違っています。さて、サプライチェーンでは、制約条件がありますが、それらの制約条件は非常に厳しいものではありません。たとえば、棚の容量の制約条件では、まだ非常に多くの解があります。これらの製品をもっと置くことも、これらの製品をもっと置くこともできます。それを見ると、非常に弱い制約条件です。これは、解の空間をわずかな解にまで減らすような制約条件ではありません。まだ絶対に膨大な数の解があります。

これらの解の空間を排除するようなテクニック、ブランチアンドカット、ブランチアンドバウンドなどをアプローチするすべてのソルバーは、1000を超える変数を持つ場合、通常は非常にパフォーマンスが低下します。もし狂気じみたことをすれば、1万の変数でも可能ですが、それは既に極限に近づいています。非常に大きなマシンで、数十ギガバイトのRAM、数十のCPU、そして数時間かかるかもしれません。ですので、非常に遅くなります。そして、1万の変数に対して、それはすでに多いと言えるでしょう。しかし、実際には小さいです。

ただし、ミニマーケットは5000の商品になると考えてください。しかし、それは5000の変数ではありません。なぜなら、本当の問題は「0個のユニットを持ってくるか、1個のユニットを持ってくるか、2個のユニットを持ってくるか、3個のユニットを持ってくるか」ということです。ですので、10で止めると十分ですが、すでに5万の変数になります。そして、場所ごとにミニマーケットがありますので、たくさんのミニマーケットがあります。ですので、ミニマーケットのようなトップの問題でも、すでに5万の変数になります。これは、あなたができることをはるかに超えています。

そして、第3のツールがあります。それはローカルサーチです。ローカルサーチは、実現可能な解を見つけることができると仮定する技術のクラスです。サプライチェーンの場合、これは非常に合理的な仮定です。制約を違反しない解を見つけることは通常非常に簡単です。棚を溢れさせないという制約がある場合、単に注文数を減らせば良いです。それは難しいことではありません。単位を減らして制約を満たすまで減らすだけです。最小注文数量がある場合、制約を満たすためには、単に製品に1を追加すれば良いです。

ですので、制約を満たす解を見つけることは難しくありません。それは、数十の変数を正確に合わせてフィットさせる必要がある暗号パズルのようなものではありません。サプライチェーンでは、通常、問題が簡単であると言うとき、それは通常、1つの変数を調整するだけで解を得ることができるということです。ですので、棚に収まるまで数量を減らすだけで、数量を減らしたり増やしたりして最小数量を得ることができます。それと同じようなことです。ですので、制約を満たす解を得るための半自明な方法があります。ただし、解の品質については何も言っていません。単に解が見つかると言っているだけです。

そして、基本的に、ローカルサーチは、フィットする解がある場合、この解をランダムに変異させ、変異した解が制約のいずれかを違反する場合は、それを取り除きます。そして、それがまだ問題を満たし、損失関数がこの解がより良いと言っている場合、それにジャンプして繰り返します。

ですので、損失関数とは、すでに合法的な解があるという意味です。それをランダムに変更し、運よく損失関数によってより良いと判断され、かつ制約を満たす解が得られた場合、この新しい解にジャンプして繰り返します。

これにはバリエーションがあります。典型的にはメタヒューリスティクス、遺伝的アルゴリズム、タブーサーチなどと呼ばれ、すべてのこれらは、解から始めて、ランダムな変異を持つ解を反復することでスケーラビリティを向上させるという前提で行われます。このようなテクニックを使えば、100万の変数に到達することができるかもしれません。しかし、それでも非常に遅いです。

Lokadでは、これを試してみましたが、サプライチェーンのスケーラビリティのテストには合格しませんでした。ですので、古典的な方法ではなく、より良い方法ですが、非常に弱いため、非常に迅速に数百万の変数が発生するような問題には対応できません。

また、問題の確率論的な側面も考慮する必要があります。なぜなら、私がこれまでに説明したようなミニマーケットの問題について言及したとき、100の軌跡でマクロ展開すると、将来の可能性を考慮に入れるために、500万の変数になるからです。ですので、急速に膨張し、やはり十分ではありません。

Conor Doherty: オリジナルの質問を少し追加したいと思います。これまでのところ要約すると、古い数理最適化の問題は決定論的であるという問題がありました。事実が知られており、正しい選択または間違った選択があります。

それから、MROの複雑さについて尋ねましたが、あなたはそれがどれだけ複雑かについて非常に明確な洞察を与えてくれました。ですので、あなたが与えたこの小さな複雑さの確率論的最適化のための技術的なオーバーヘッドは何ですか?明らかに狂気ですが、私が実際に尋ねているのは、これを実装するための完璧な方法ではなく、確率論的最適化を使用するためのより良い方法は何ですか?完璧ではないかもしれませんが、あなたが言ったことをすべて破壊しない実用的な方法は何ですか?

Joannes Vermorel: 数理最適化の問題は本当にスケーラビリティに関するものです。確率論的な問題を確定論的な問題として再表現することで、確定論的な問題に戻ることができます。しかし、私たちは既に深刻なスケーラビリティの問題に苦しんでいる数理最適化の技術から始めました。

今度は、確率論的な問題を確定論的な問題として再表現するために問題を膨らませることになりますが、それによってスケーラビリティの問題はさらに悪化します。確率論的最適化に対処するための簡単な方法があります。変動する損失関数を何百万回も実行し、結果を平均化するだけです。それはうまくいくでしょうが、計算上のオーバーヘッドが膨大です。

つまり、私が言っているのは、これらの数理最適化ツールは数十年前から利用可能でしたが、スケーラビリティがなく、確率論的性質も扱えないということです。確率的予測から生じる確率論的性質を考慮する前に、既にスケーラビリティが不十分でした。確率論的性質を積み重ねると、桁違いになります。それがLokadが供給チェーンに適切なスケールでこれらの問題に対処できるようにするために、実質的に確率論的最適化のための技術のクラスを再開発しなければならなかった理由です。

そして、なぜそれが本当に必要なのかに戻ると、Lokadが2012年に確率的予測を導入したとき、私たちは非常に早く大きな問題があることに気付きました。不確実性の下で最適化することは非常に難しいです。

数年間、私たちはこの状況を何とかしようとして賢明なヒューリスティックスを作り上げました。ですので、賢明なヒューリスティックスでうまくやっていけます。ヒューリスティックスとは、この非常に特定の状況でどうにかうまくいく賢い方法のことです。つまり、ごまかしです。狭い状況でうまく機能するごまかしを見つけます。問題は、それらのヒューリスティックスが壊れやすい傾向にあることです。

そして、クロスプロダクトの制約やクロススキューの制約、またはサプライチェーン内の相互依存する要素がある場合など、ヒューリスティックスは崩壊する傾向があります。それが確率論的最適化が必要な理由です。

そうしないと、ビジネスにとってはどういう意味ですか?それは、通常非常に保守的な人間の判断に頼ることを意味します。それはうまくいくかもしれませんが、制約を満たすために非常に安全な方法を取る傾向があります。問題は、サプライチェーンでは、問題を解決するために単により多くのお金を投入することで解決できるということです。

私の航空MROの例に戻ると、明らかな解決策があります。空は限りないと言うだけです。必要な部品は何でも持っていて、在庫がたくさんあるので、良いサービスレベルを持つことができます。問題を解決するために単にお金を投入すれば、問題は解決するかもしれませんが、これは緩い解決策であり、非常に緩い解決策です。

シェルフリミットについても同じです。店舗を非常に狭い制約で分割することを決めることができます。例えば、これらの2つの製品または3つの製品はこの程度のスペースを持ち、この1つはこれ以上のスペースを持たないとします。これにより、店舗の内部構成の変動の種類が制限されます。

例えば、すべてのヨーグルトを合わせて、200個以上にならないようにするとします。しかし、この制約が間違っている場合はどうでしょうか?地域の需要が急増し、ヨーグルトの総量の制約があまりにも低すぎる場合、毎週土曜日の終わりにはミニマーケットにはヨーグルトが一つも残っていません。

問題を解決するための確率的最適化ソルバーが利用できない場合、企業は通常、解決空間を狭めるために多くの制約を追加する傾向があります。これにより、解決策を選択し、意思決定を行い、より狭い解決空間で操作する人々またはソフトウェアが、さまざまなキュー間の依存関係や関心事を軽減することができます。

しかし、それは実際には詐欺です。そこにはもっと良い解決策が存在するかもしれず、偽の制約を積み重ねることでそれらの解決策を排除してしまったのです。

Conor Doherty: ここでたくさんのことをカバーしました。数学のトレーニングを受けていない人々にとって、確率的最適化は従来の数学的最適化と比較して、より柔軟で反応性のある意思決定の最適化方法ですね?

Joannes Vermorel: はい、それはより表現力のある方法です。確定的な問題として表現できるものは、確率的な問題としても表現できます。しかし、確定的な問題はあなたの関数がまったく変化しないことを意味します。関数が変化する場合、変化しない関数を選ぶことが常にできます。それでも機能します。したがって、フレームワークはまず、アプローチできる問題のクラスを定義します。

問題に不確実性が含まれる場合、確率的最適化が必要です。それがあなたの状況が属する問題のクラスです。そして、理想的には、それに対処するためのソフトウェアコンポーネントが必要です。確率的予測は、不確実性を評価するための基本的な予測を生成するためのツールです。

意思決定自体に関しては、別のコンポーネントが必要です。数学的最適化の典型的な視点は、ソルバー、汎用のソフトウェアの一部を持つことです。このソフトウェアは、任意の問題文、確定的な損失関数、変数、制約を受け取り、損失関数を最小化する変数の組み合わせを提供します。同じことができますが、ソルバーは確率的なソルバーになります。したがって、求める変数の組み合わせを出力します。

なぜソルバーが必要なのでしょうか?利益と損失を表す損失関数は変更される可能性があります。おそらく関数を微調整して戦略的なビジョンを適応させたいのです。数値的なレシピの完全なソフトウェア解決を再実装する必要はありません。

単にこう言いたいだけです。新しい損失関数をここに示し、この更新された損失関数に対して解決を再適用してください。それがソルバーがあなたに提供できることです。それは、損失関数の定義、制約の定義、変数の定義を受け取り、解を提供するパッケージ化されたソフトウェアコンポーネントのようなものです。

Conor Doherty: では、お話ししているソルバーソフトウェアツール、最適化または解決策を自動的に再生成するソルバーソフトウェアツールは、従来のサプライチェーンの実践者が行わなければならなかった作業量を減らすことになるのですね?

Joannes Vermorel: 実際には、これにより意思決定プロセスを完全に自動化することができます。はい、ソルバーはLokadが顧客に提案する最終的な意思決定を生成するものです。最適化にはさまざまなアプローチがあります。いくつかのヒューリスティックスを使用することもできますが、それらのいくつかは非常に優れています。特定の状況ではうまく機能しますので、ソルバーは必ずしも必要ではありません。ソルバーの代わりに役割を果たすヒューリスティックスを持つこともできます。しかし、要点は、ソルバーが予測を入力として与えられた場合に、解を生成するものであるということです。

Conor Doherty: ‘ソルバー’という言葉を使うとき、例えば在庫の補充において推奨される意思決定を生成する’数値レシピ’と同義に使用していますか?

Joannes Vermorel: ‘数値レシピ’という用語を使用する場合、通常は処理の全体の連鎖を指しています。データの準備から結果の生成まで、すべてを含みます。この数値レシピは通常、データの準備、予測の生成、最適化、そして結果の提示という一連のステージに分解されます。今日は、予測を入力として最終的な意思決定の計算についてのみ議論しています。

Conor Doherty: ソルバーが生成したサプライチェーンの意思決定について、サプライチェーンの実践者が異議を唱えた場合、どのような対応策がありますか?人間の能力をはるかに超える規模で数百万の変数を考慮に入れている場合、サプライチェーンの実践者として、その正当性や誤りをどのように評価できるのでしょうか?

Joannes Vermorel: ソルバーは非常に簡単に挑戦できます。単に「ここに私のより良い解があります。この解を損失関数に対して挑戦しましょう」と言うだけです。ソルバーが良くないことを証明するには、ソルバーが見つけた解よりも優れた解を示すだけです。

したがって、ソルバーは組み合わせを提供します。通常、解を提供した後、損失関数にアクセスすることができます。制約もあります。したがって、ここに試験的な解があります。まず、制約が満たされているかどうかをチェックしましょう。はい、満たされています。そして、損失関数を適用して、損失をドルで計算しましょう。はい、これが損失です。そして、これがソルバーによって提示された解です。

もし手動で変数を選んで調整し、損失関数よりも優れたものになった場合、私はソルバーよりも優れた解を生成できると証明したことになります。この場合、ソルバーはあまり良くありません。それは非常によく起こります。

市場で見つけることができる既製のソルバーの問題は、解を見つけられないことではなく、解を見つけることができるが非常に劣った解を見つけることです。サプライチェーンの実践者が数量を手動で調整し、すべての制約を満たし、損失関数によればより良い解になるようにする必要があります。したがって、ソルバーを挑戦することは、確率的な予測モデルを挑戦するよりもはるかに簡単です。損失関数に基づいてより良い解を示すだけです。

問題に特別な洞察がある場合、ソルバーよりも優れたものを手動で作成することができるかもしれません。サプライチェーンの設定で利用可能なほとんどのソフトウェアについては、手動でソルバーよりも優れた結果を出すのは非常に簡単です。確率的な問題に関しては、彼らのスケーラビリティはひどいです。したがって、ソルバーを30分間実行して終了する必要があります。30分後の解が完全に駄目な場合、人間がより良い結果を出すことは頻繁には難しくありません。

Conor Doherty: では、この話を聞いた人々にとってのキーポイントは何だと思いますか?

Joannes Vermorel: キーポイントは、確率的最適化がサプライチェーンの教科書からほとんど欠落している非常に重要な視点であるということです。ほとんどの著者は、まず問題が存在することさえ認識していません。非常に大きく、非常に確立されたプレーヤーは、確定的最適化問題のためのソルバーを販売しています。それらは良いソルバーですが、この不確実性によるサプライチェーンの問題クラスを解決していません。彼らは不確実性を無視しています。

そのようなソルバーを持つ利点は、存在するすべての相互依存関係を真に考慮してサプライチェーンを改善できることです。孤立した事柄を見るのではなく、サプライチェーン全体をシステムとして見る必要があり、それらの依存関係を考慮する必要があります。

これらの依存関係はさまざまな形を取ることがあります。航空業界では、修理に必要な部品のリストです。ファッション業界では、店舗が魅力的になるためにはすべての色の衣類を揃える必要があります。これは製品レベルでは表現できません。ハイパーマーケットでは、人々が実際に欲しい買い物リストを考える必要があります。彼らは1つのものを買いに来るのではなく、リスト全体のものが欲しいのです。おそらく彼らはレシピを作りたいので、すべてのものを揃える必要があります。ほとんどの非自明なサプライチェーンでは、相互依存関係があり、確率的ソルバーや確率的な解決技術がない限り、問題に満足のいく方法でアプローチすることはできません。

Conor Doherty: それでは、Joannes、お時間いただきありがとうございました。これ以上の質問はありません。そして、ご視聴いただきありがとうございました。次回お会いしましょう。