00:00 イントロダクション
02:53 決定 vs アーティファクト
10:07 実験的最適化
13:51 これまでのストーリー
17:01 今日の決定事項
19:36 量的サプライチェーンの宣言
21:01 小売在庫割り当ての問題
24:49 店舗SKUに対する経済的な影響
29:35 未来の具現化
32:41 オプションの具現化 - 1/3
38:25 オプションの具現化 - 2/3
43:02 オプションの具現化 - 3/3
44:44 在庫報酬関数 - 1/2
51:41 在庫報酬関数 - 2/2
56:19 優先順位付けされた在庫割り当て - 1/4
59:59 優先順位付けされた在庫割り当て - 2/4
01:03:39 優先順位付けされた在庫割り当て - 3/4
01:06:34 優先順位付けされた在庫割り当て - 4/4
01:12:58 倉庫のフローのスムージング - 1/2
01:16:48 倉庫のフローのスムージング - 2/2
01:22:12 アクション報酬関数
01:25:02 現実世界は複雑です
01:27:38 結論
01:30:00 今後の講義と視聴者の質問
説明
サプライチェーンの意思決定にはリスク調整された経済評価が必要です。確率的予測を経済評価に変換することは容易ではなく、専用のツールが必要です。しかし、在庫割り当てによって示される経済的優先順位付けは、従来の技術よりも強力であることが証明されています。小売在庫割り当ての課題から始めましょう。配送センター（DC）と複数の店舗を含む2階層ネットワークでは、すべての店舗が同じ在庫を競い合うことを知っている状態で、DCの在庫を店舗にどのように割り当てるかを決定する必要があります。
フルトランスクリプト
サプライチェーンの講義シリーズへようこそ。私はジョアネス・ヴェルモレルです。今日は「確率的予測を用いた小売在庫割り当て」を紹介します。小売在庫割り当ては、いつどれくらいの在庫を配送センターと運営する店舗の間で移動するかを決定するという、シンプルでありながら基本的な課題です。在庫を移動する決定は将来の需要に依存するため、ある種の需要予測が必要です。
しかし、店舗レベルの小売需要は不確定であり、将来の需要の不確実性は削減できません。したがって、将来の需要のこの削減できない不確実性を適切に反映する予測が必要です。そのため、確率的な予測が必要です。しかし、確率的な予測を最大限に活用してサプライチェーンの意思決定を最適化することは容易ではありません。確率的な予測を最初に導入した理由を台無しにすることになります。
この講義の目的は、確率的な予測をそのまま活用してサプライチェーンの意思決定を最適化する方法を学ぶことです。最初の例として、小売在庫割り当ての問題を考えます。この問題の検討を通じて、店舗レベルでの在庫レベルを最適化する方法を見ていきます。さらに、確率的な予測の検討を通じて、配送センターから店舗への在庫の流れをスムーズにし、ネットワークの運営コストを最適化し削減するなど、新しい種類のサプライチェーンの問題にも取り組むことができます。
この講義は、サプライチェーンの文脈での意思決定技術とプロセスについての第6章を開始します。個々のローカル最適化の連続ではなく、統合されたシステムとしてサプライチェーンネットワーク全体を考慮して意思決定を最適化する必要があることを見ていきます。たとえば、SKU（在庫管理単位）の狭い視点を持つことは避ける必要があります。
サプライチェーンの意思決定に取り組むための最初のステップは、実際のサプライチェーンの意思決定を特定することです。サプライチェーンの意思決定は、サプライチェーンに直接的な物理的な影響を与えます。たとえば、配送センターから店舗への在庫の1単位を移動することは現実的です。それを行うと、店舗の棚に1つの追加ユニットがあり、配送センターから1つのユニットがなくなり、他の場所に再割り当てすることはできません。
一方、アーティファクトはサプライチェーンに直接的な物理的な影響を与えません。アーティファクトは、サプライチェーンの意思決定につながる中間計算ステップであることが一般的です。または、サプライチェーンシステムの一部の特性を特徴付ける統計的な推定値であることがあります。残念ながら、意思決定とアーティファクトを区別する際に、サプライチェーンの文献では非常に混乱しているということを指摘せざるを得ません。
注意してください。投資の収益は、意思決定の改善によってのみ得られます。アーティファクトの改善はほとんど意味がありませんし、それが最善です。最悪の場合、企業がアーティファクトの改善に時間を費やしすぎると、実際のサプライチェーンの意思決定の改善を妨げる邪魔になります。画面には、主流のサプライチェーンの世界で頻繁に観察される混乱のリストが表示されています。
たとえば、安全在庫から始めましょう。この在庫は実在しません。安全在庫と作業在庫の2つの在庫はありません。在庫は1つだけであり、取るべき唯一の意思決定は、それ以上必要かどうかです。再発注は実在しますが、安全在庫は実在しません。同様に、サービスレベルも実在しません。サービスレベルは非常にモデル依存です。実際には、小売需要では販売データが乏しいです。したがって、特定のSKUを取ると、通常はSKUを検査するだけでは意味のあるサービスレベルを計算するためのデータが不十分です。サービスレベルにアプローチする方法は、モデリング技術と統計的な推定値ですが、これも現実ではなくアーティファクトです。これは、サプライチェーンに対する数学的な視点です。
同様に、プッシュまたはプルも視点の問題です。サプライチェーンネットワーク全体を考慮に入れた適切な数値レシピは、1つの原点から1つの宛先に1単位の在庫を移動する機会を考慮するだけです。実在するのは在庫の移動です。プッシュまたはプルを定義するのは、原点または宛先に関連する条件に基づいてこの在庫の移動をトリガーするかどうかですが、これは最大でも数値レシピの細かい技術的な問題であり、サプライチェーンの核心的な現実を表していません。
不良在庫は、近い将来在庫の廃棄を受けるリスクの推定です。顧客の視点からは、不良在庫と生きている在庫の区別はありません。どちらも魅力的でない可能性のある製品ですが、不良在庫は在庫についての特定のリスク評価に過ぎません。これは問題ありませんが、在庫の廃棄とは異なり、価値が失われたことを示します。
同様に、下降傾向も、観察される需要をモデル化する方法に存在する数学的な要素です。通常、時間に依存する要素として導入され、時間に対する線形依存性や指数関数的な依存性などがあります。しかし、これが現実ではありません。現実は、ビジネスが顧客を失うことによって減少しているため、離脱がサプライチェーンの現実です。下降傾向は、単にパターンを集約するために使用できるアーティファクトです。
同様に、どのサプライヤーも平均購入価格で何かを販売するわけではありません。現実は、発注書を作成し、数量を選択し、選択した数量に応じてサプライヤーが提供する価格の割引を活用することです。その価格割引と交渉した内容に基づいて購入価格を得ることになります。平均購入価格は実在しないため、これらの数値的なアーティファクトを根本的な真実の要素として誤解しないように注意してください。
最後に、ABC分類は、売れ筋からスロームーバーまでの範囲で、持っているSKUまたは製品の単純なボリュームに基づく分類です。これらのクラスは実在する属性ではありません。通常、製品の半分は1四半期から次の四半期にかけてABCクラスが変わりますが、それによって顧客や市場には何も起こりません。これは製品に適用された数値的なアーティファクトであり、製品が流通業者ブランドの一部であるかどうかなど、重要な属性と混同してはなりません。これはサプライチェーンにとって重要な真の基本的な属性です。この章では、数値的なアーティファクトに時間と焦点を費やすのではなく、サプライチェーンの意思決定に焦点を当てることがなぜ重要かがますます明確になるはずです。
“最適化"という言葉が発音されると、教養のある聴衆にとって思い浮かぶのは、数理最適化の視点です。変数の集合と損失関数が与えられた場合、目標は損失関数を最小化する変数の値を特定することです。残念ながら、これはサプライチェーンではうまく機能しません。なぜなら、関連する変数が通常はわからないからです。それがわかっている場合でも、天候データなどの多くの変数がサプライチェーンに影響を与えることが知られていますが、このデータを取得するには多額のコストがかかります。したがって、サプライチェーンを最適化するためにこのデータを取得する価値があるかどうかは明確ではありません。
さらに問題なのは、損失関数自体がほとんどわからないことです。損失関数はある程度推測できますが、損失関数の適切性についての有効な情報は、サプライチェーンから得られる実世界のフィードバックと損失の対比によってのみ得られます。これは数学的な観点からの正確さの問題ではなく、適切性の問題です。数学的な構造である損失関数が、サプライチェーンの最適化において何を適切に反映しているのかを検証するためには、数多くの観察を通じて得られる実験に基づく証拠が必要です。実験的最適化は、最適化の見方を根本的に変えるものであり、この章ではこの視点を採用します。ここで紹介するツールと技術は、実験的最適化の視点に合わせて設計されています。
いつでも、持っている数値的なレシピは時代遅れと宣言され、サプライチェーンにより適合した代替数値的なレシピに置き換えることができるはずです。したがって、いつでも、持っている数値的なレシピを本番環境に導入し、最適化プロセスをスケールで実行できるはずです。たとえば、損失関数を特定し、その後、3ヶ月間の期間でデータサイエンティストのチームをケースに当ててソフトウェア最適化技術を開発する、とは言えません。代わりに、新しいレシピがある場合は、直接本番環境に導入し、サプライチェーンの意思決定にこの新たに特定された問題の形式をすぐに活用できるようにする必要があります。
この講義はサプライチェーンの一連の講義の一部です。これらの講義をある程度独立しているように保とうとしていますが、これらの講義を順番に視聴する方がより意味がある時点を過ぎています。前の講義を見ていなくても大丈夫ですが、このシリーズは提示された順序で視聴するとより理解しやすいでしょう。
最初の章では、サプライチェーンを研究対象として、また実践としての私の考えを紹介しました。2章では、実験的最適化を含む、サプライチェーンの課題に取り組むために必要な一連の手法を紹介しました。これらの手法は、ほとんどのサプライチェーンの問題が対立的な性質を持つために必要です。3章では、解決策ではなく問題自体に焦点を当てました。4章では、サプライチェーンそのものではないが、サプライチェーンの現代的な実践に不可欠な補助科学を紹介しました。5章では、将来の不確実性に対処するために必要な確率予測などの一連の予測モデリング手法を紹介しました。
今日は、第6章の最初の講義で、意思決定の技術について詳しく取り上げます。過去70年間にわたり、科学文献では多くの意思決定の技術やアルゴリズムが提案されてきました。1950年代の動的計画法から強化学習、そして深層強化学習まで、さまざまな手法が開発されています。しかし、実際のサプライチェーンの結果を得ることは容易ではありません。実際、これらの手法のほとんどは、何らかの理由でサプライチェーンの目的には適さない隠れた欠陥を持っています。今日は、サプライチェーンの意思決定の典型例である小売在庫配分に焦点を当てます。この講義は、より複雑な意思決定や状況に向けた準備をします。
画面には、今日の講義の概要が表示されています。小売在庫配分という最も単純なサプライチェーンの問題を考える場合でも、私たちは多くの内容をカバーする必要があります。これらの要素は、より複雑な状況の基礎となります。まず、量的サプライチェーンの宣言を再訪します。次に、小売在庫配分問題とは何を意味するのかを明確にします。また、この問題に存在する経済的な要素についても見直します。確率予測の概念と、実際にそれらをどのように表現するか、少なくとも1つのオプションを紹介します。予測の精緻化とオプションの精緻化によって、意思決定のモデル化方法を見ていきます。
次に、在庫報酬関数を紹介します。この関数は、確率予測を経済的なスコアに変換するための最小限のフレームワークと見なすことができます。このスコアは、各在庫配分オプションに関連付けられる経済的な要素を考慮に入れます。オプションにスコアが付けられたら、優先リストを作成することができます。優先リストは、数値の安定性とホワイトボックスの特性の両方において、実世界のサプライチェーンで非常に強力で実用的です。
優先リストを使用することで、配送センターから店舗への在庫の流れをほぼ努力なくスムーズにすることができ、配送センターの運営コストを削減することができます。最後に、アクション報酬関数について簡単に調査します。現在、Lokadでは単純さを除いて、アクション報酬関数が在庫報酬関数をほぼすべての側面で置き換えています。
量的サプライチェーンの宣言は、私が2017年に最初に公開した文書です。この視点は、講義1.2で詳しく説明されていますが、明確さのために、今日は簡単に復習します。5つの柱がありますが、今日は最初の3つが関連しています。最初の3つの柱は次のとおりです：
すべての可能な未来を考慮すること。これは確率予測だけでなく、リードタイムのような不確実性の要素を持つ他の要素の予測も含みます。 アーティファクトではなく、意思決定に焦点を当てること。 経済的なドライバーに基づいて優先順位を付けること。これが今日の講義のトピックです。
特に、確率予測を経済的なリターンの推定値に変換する方法を見ていきます。
小売在庫配分問題では、私が定義しているものです。多少任意的な定義ですが、今日はこの定義を使用します。2つのエシュロンを持つネットワークを想定しています。配送センターと複数の店舗があります。配送センターはすべての店舗にサービスを提供し、複数の配送センターがある場合は、1つの店舗は単一の配送センターによってサービスされると仮定しています。目標は、配送センターに存在する在庫を店舗間で適切に配分することであり、すべての店舗が配送センターに存在する同じ在庫を競合します。
すべての店舗は、配送センターからの毎日のスケジュールで毎日補充されることを前提としています。したがって、毎日、各製品ごとに各店舗に移動するユニットの数を決定する必要があります。移動するユニットの総数は、配送センターで利用可能な在庫を超えることはできず、店舗の棚の容量制限があることも合理的に予想されます。配送センターの在庫が無制限であれば、問題は単一エシュロンのサプライチェーンに変わり、在庫を1つの店舗または別の店舗に割り当てるための任意のアービトラージやトレードオフの必要性はありません。ネットワークの2つのエシュロン特性は、店舗が同じ在庫を競合するという事実によってのみ生じます。
当然ながら、店舗の売上と在庫レベルについての可視性を前提とし、配送センターレベルと店舗レベルの両方でトランザクションデータが利用可能であるとします。また、配送センターへの入荷予定（ETA）がわかっているとしますが、ある程度の不確実性が伴う場合もあります。また、製品の仕入れ価格、販売価格、製品カテゴリ（あれば）など、すべての日常的で重要な情報が利用可能であるとします。このような情報は、30年前のERP、WMS、ポイントオブセールシステムなど、どのシステムにも見つかるでしょう。
今日は、配送センター（DC）の補充を問題の一部として含めていません。実際には、配送センターの補充と店舗の割り当ては密接に関連しているため、これらの問題に一緒に取り組むことは合理的です。なぜなら、この講義では明確さと簡潔さを重視するためです。しかし、今日私が提示しているアプローチは、配送センターの補充を含めることも自然な拡張が可能です。
特定の日に、特定の商品の店舗に在庫を1ユニット追加するかどうかは、一連の経済的な要因に依存します。ユニットを移動することが利益になる場合は、移動したいと思います。主な経済的な要因は画面にリストされており、店舗に在庫を追加することでさまざまな利点が生じます。これには、失われた売上を回避することによるより多くの粗利益、ストックアウトの量を減らすことによるより良いサービス品質、および改善された店舗の魅力が含まれます。実際、店舗が魅力的であるためには、豊富に見える必要があります。そうでないと、悲しい印象を与え、人々は購入する意欲が低くなるかもしれません。これは小売業界での一般的な観察ですが、ハードラグジュアリーなどのすべてのセグメントに必ずしも当てはまるわけではありません。ただし、一般的な商品やファッション店には、この考慮が適用されます。
残念ながら、在庫を増やすことには、店舗に在庫を増やすことから期待されるリターンを減少させるデメリットもあります。これらのデメリットには、余分な保管コストが含まれます。在庫が実際に過剰な場合、これは在庫の廃棄につながる可能性があります。また、スタッフが受け取り過多の出荷を処理できない場合、入荷オーバーロードのリスクもあります。スタッフが棚に置くことができる量を超える出荷が行われると、店舗内で混乱や無秩序が生じます。さらに、機会費用もあります。ユニットが1つの店舗に配置されると、別の店舗に配置することはできません。配送センターに戻して再送することもできますが、通常は非常に高価なため、通常は最後の手段となります。小売業者は、在庫を戻さずに効率的な店舗割り当てを目指すべきです。
在庫の流れをスムーズにすることも非常に望ましいです。配送センター（DC）は、ピーク時の経済的効率で運営される名目容量を持っています。このピーク効率は、DCの物理的な設置と、それに付随する常勤スタッフの数によって推進されます。理想的には、DCは日常的に運営され、名目容量に非常に近い状態を維持し、最もコスト効率が高くなるようにする必要があります。ただし、配送センター（DC）でのピーク効率を維持するには、DCから店舗への流れをスムーズにする必要があります。経済的な観点は、主流のサプライチェーンの文献でよく見られる従来のサービスレベル志向の視点とは異なります。私たちはリターンのドルを求めており、パーセンテージポイントではありません。ネットワークレベルで在庫割り当てスキームを調整して運用コストを削減することが合理的かどうか、または店舗でのサービス品質のわずかな低下とのトレードオフを選ぶかどうかを判断する唯一の方法は、ここで提示される経済的視点を採用することです。サービスレベルの視点を採用すると、このような回答を提供することはできません。この時点での私たちの目標は、任意の在庫割り当ての決定に対する経済的結果を推定するための数値レシピを確立することです。
前の章、第5章では、確率的な予測を作成する方法と、“ranvar"という専用のデータ型を紹介しました。“ranvar"は、Envisionで単純な一次元の確率分布を表すために使用される専用のデータ型です。
Envisionは、サプライチェーンの予測最適化のためにLokadによって設計されたドメイン固有のプログラミング言語です。これらの講義では、Envision自体には根本的にユニークなものはありませんが、プレゼンテーションの明瞭さと簡潔さのために使用されています。今日説明する数値レシピは、Python、Julia、Visual Basicなど、任意の言語で実装することができます。
ranvarの重要な側面は、ランダム変数の高性能な代数を提供することです。パフォーマンスは、計算コスト、メモリコスト、および許容できる数値近似の度合いのバランスです。小売ネットワークを扱う際には、計算パフォーマンスが重要です。数百万、または数千万のSKUがあり、それぞれが少なくとも1つの確率的な予測またはranvarを持つ可能性があるためです。その結果、数百万または数千万のヒストグラムが得られる場合があります。
ranvarのキーとなる特性は、CPUコストとメモリコストを上限に保ち、できるだけ低くすることです。また、導入される数値近似がサプライチェーンの観点から無視できるようにすることも重要です。ここでは科学計算ではなく、サプライチェーンの計算を行っていることに注意してください。数値計算は正確である必要がありますが、極度の精度は必要ありません。1十億分の1の近似値がある場合、サプライチェーンの観点からは無視できます。数値計算は正確である必要がありますが、極度の精度は必要ありません。
以下では、確率的な予測はranvarの形で提供されるものとします。ranvarはヒストグラムで置き換えることもでき、パフォーマンスと利便性の面を除いてほぼ同じ結果を得ることができます。
確率的な予測ができたので、次にどのように意思決定に取り組むかを考えましょう。まず、オプションを考慮しましょう。オプションとは、潜在的な意思決定のことです。たとえば、特定の商品を特定の店舗に特定の日に0個割り当てるか、1個、2個、または3個割り当てるかなどです。2個割り当てることを決定した場合、それが私たちの意思決定になります。オプションとは、決定待ちのテーブル上のすべてのものです。
これらのオプションを整理するための簡単な方法は、画面に表示されるようにリストにまとめることです。このリストは複数のSKUをカバーし、各SKUごとにオプションごとに1行追加します。各オプションは割り当てる数量を表します。0個、1個、2個、3個などを割り当てることができます。実際には、無限に行く必要はありません。配送センターの在庫数量で止めることができます。より現実的には、通常、店舗の商品の最大棚容量などの下限があります。
したがって、すべてのSKUを含むリストがあり、各SKUごとに配送センターからの割り当ての候補として考えられるすべての数量があります。スコア列は、この割り当てによって期待される限界結果に関連付けられています。よく設計されたスコアは、スコアの降順で行を選択することで、小売ネットワークの経済的結果を最適化します。
画面に表示される2つのSKUの場合、割り当てが増えるにつれてスコアが減少し、ほとんどのSKUに対して観察される限界収益の支配的な現象を示しています。基本的に、最初のユニットを店舗に配置することは、ほとんどの場合、2番目のユニットよりも多くの収益を生み出します。店舗に最初のユニットを配置すると、在庫切れの状況はすでに解消されます。2番目のユニットを配置すると、最初のクライアントは問題ありませんが、2人のクライアントが現れる場合にのみ、2番目のユニットが役立ちますので、経済的なリターンはより小さいです。ただし、在庫が増えるにつれてリターンは一般的に減少します。経済的なリターンが次の行に厳密に減少しない場合もいくつかありますが、後の講義でこのケースを再検討します。今のところ、在庫が増えるにつれてリターンが厳密に減少する単純な状況に固執します。
私たちが持っている表現方法は、すべてのSKUとオプションを見ることができるグリッドと呼ばれることが一般的です。意図は、このグリッドをROI（投資収益率）の降順でソートすることです。これらのグリッド自体に問題はありませんが、特に計算やメモリの観点からは非常に効率的ではありませんし、大きなテーブル以外のサポートは提供しません。小売ネットワークについて話していることを念頭に置いて、このグリッドは数十億行になる可能性があります。ビッグデータは問題ありませんが、より小さなデータの方が良いです。小さなデータは摩擦が少なく、より柔軟性があります。ビッグデータの問題を小さなデータの問題に変えようとすることが目標です。
したがって、Lokadが大量のオプションを扱うために採用した解決策の1つは、zedfuncsです。このデータ型は、ranvarsの対応物であり、意思決定の観点からの対応物です。ranvarsはすべての可能な未来を表し、zedfuncsはすべての可能な意思決定を表します。ranvarsとは異なり、zedfuncは確率を表すのではなく、オプションの一次元離散系列に関連するすべての経済的結果を表します。
zedfunc、またはzedfunctionは、技術的には整数（正および負）を実数値にマッピングする関数です。これが技術的な定義です。ただし、ranvarsと同様に、有限のメモリでzedfuncsのような任意の複雑な関数を表現することはできません。この場合、精度と解像度の間でトレードオフを行う必要があります。
サプライチェーン管理では、任意の複雑な経済関数は存在しません。かなり複雑なコスト関数を持つことはできますが、任意に複雑ではありません。実際には、zedfuncsを4キロバイト以下に圧縮することが可能です。これにより、コスト関数全体を表すデータ型が得られ、数値の近似度がサプライチェーンの観点から無視できる程度に保たれます。数値の近似度を非常に小さく保つことで、最終的な離散的な意思決定に影響を与えない場合、数値の近似度は完全に無視できると言えます。
4キロバイトを使用する理由は、コンピューティングハードウェアに関連しています。サプライチェーン管理のためのモダンなコンピューティングハードウェアについて以前の講義で見たように、モダンなコンピュータのランダムアクセスメモリ（RAM）は、バイト単位でメモリにアクセスすることはできません。RAMに触れると、4キロバイトのセグメントが取得されます。したがって、サプライチェーンのためにデータ量を4キロバイト以下に保つことが最善です。これにより、ハードウェアが設計され、サプライチェーンのために動作する方法に一致します。
Lokadがzedfuncsに使用する圧縮アルゴリズムは、ranvarsに使用するアルゴリズムとは異なります。ranvarsの場合、主に連続セグメントの確率の質量を保持することに関心があります。zedfuncの場合、焦点は異なります。通常、次の位置からの変動量を保持したいのです。なぜなら、最後の利益のあるオプションかどうか、または停止すべきかを判断するためには、この変動量が必要だからです。したがって、圧縮アルゴリズムも異なります。
画面には、在庫単位数に依存するいくつかの予想在庫保有コストを反映したzedfuncのプロットが表示されています。zedfuncsはベクトル空間であるため、関数に関連する古典的なベクトル空間と同様に、加算および減算が可能です。メモリの局所性を保持することで、操作はナイーブなグリッド実装よりも桁違いに高速に実行できます。ナイーブなグリッド実装では、オプションの局所性を捉える特定のデータ構造がない非常に大きなテーブルがあります。
前のスライドで見たプロットはスクリプトによって生成されました。1行目と2行目で、2つの線形関数fとgを宣言しています。関数「linear」は標準ライブラリの一部であり、「linear of one」は単項式の1次関数、つまり恒等関数です。関数「linear」はzedfuncを返し、zedfuncに定数を追加することも可能です。fとgは1次の多項式です。3行目では、fとgの積によって2次の多項式を構築しています。5行から10行は、zedfuncをプロットするためのユーティリティです。
この時点で、zedfuncと経済的な結果のためのデータコンテナがあります。zedfuncは確率的な予測のためのranvarと同様のデータコンテナです。ただし、これらの経済的な結果を計算するためには、まだ数値レシピが必要です。データコンテナはありますが、まだどのようにしてこれらの経済的な結果を計算し、zedfuncに埋め込むのかは説明していません。
在庫報酬関数は、確率的な予測と経済的要因の短い系列を考慮して、単一SKUの各在庫レベルに対する経済的リターンを計算するための小さなフレームワークです。在庫報酬関数は、Lokadで私たちの実践を統一するために導入されました。2015年には、Lokadはすでに確率的な予測を数年間使用しており、試行錯誤を通じてうまく機能する一連の数値レシピを既に見つけていました。しかし、それらは実際には統一されていませんでした。少し混乱していました。在庫報酬関数は、当時のすべての洞察をクリーンで整然とした最小限のフレームワークにまとめました。2015年以降、より良い方法が開発されていますが、それらはより複雑です。明確さのために、まず在庫報酬関数から始める方が良いです。
在庫報酬関数は、確率的な予測に関連付けられた経済的な結果の計算を提供する数値レシピを見つけることに関して本当に重要です。在庫報酬関数は、画面に表示されている方程式に従い、時刻tにおける在庫kに対して得られる経済的リターンを定義します。変数Rは経済的リターンを表し、ドルやユーロなどの単位で表されます。この関数には2つの変数、時間(t)と在庫(k)があります。すべての可能な在庫レベルに対してこの報酬を計算したいと思います。
考慮するべき経済変数は4つあります：
Mは1つの単位を販売することによって得られる粗利です。1つの単位を正常にサービスすることで得られる利益です。 Sは欠品ペナルティであり、クライアントに対してユニットのサービスに失敗した場合に発生する仮想的なコストです。クライアントにペナルティを支払う必要がなくても、適切なサービスを提供できなかった場合にはコストが発生し、このコストをモデル化する必要があります。このコストをモデル化する最も簡単な方法の1つは、提供できなかったユニットごとにペナルティを割り当てることです。 Cは在庫保有コストであり、単位あたりの時間経過ごとのコストです。3期間にわたって1つの単位を在庫に持っている場合、それは3回のCになります。3期間にわたって2つの単位を在庫に持っている場合、それは6回のCになります。 アルファは将来のリターンを割引するために使用されます。アイデアは、遠い将来に起こることよりも、近い将来に起こることの方が重要であるということです。 在庫報酬関数は、過度に単純化されすぎない限り、できるだけシンプルです。方程式は、需要が在庫を超える場合、リターンには在庫があるすべてのマージンが含まれることを示しています。
最初の行が言っていることは次のとおりです：私たちはkのマージンを持っているので、持っているすべてのユニットを売り、そして提供できなかったユニットすべてに対してY(t) - kのペナルティを支払います。
それ以外の場合、在庫が需要を上回っている場合、私たちはY(t)倍のMを利益として得ることができます。これは、今日売ったもののマージンを表しています。その後、在庫保有コストを支払わなければなりません。今日の在庫保有コストは、1日の終わりに残っているもの、つまりk - Y(t)倍のC、さらに翌日の在庫報酬関数R*に対するアルファ倍が含まれます。
R*には注意点があります。在庫報酬関数Rとほぼ同じですが、在庫切れペナルティをゼロにしています。その理由は明確です。在庫の観点からは、後で在庫を補充する機会があると仮定しています。今日在庫切れが発生した場合、それは遅すぎるため、在庫切れペナルティが発生します。ただし、明日発生するとされる在庫切れペナルティは回避可能と見なされます。
ただし、将来の特定の期間に発生するとされる在庫切れペナルティについては、補充は各期間で行われると仮定しています。したがって、後の期間に発生する在庫切れに対しては、まだ発生していません。まだそれを行う機会があります。そのため、在庫切れペナルティをゼロに設定しています。なぜなら、在庫切れが発生しないようにする別の再注文があることを予期しているからです。
時間割引率のアルファは非常に有用です。なぜなら、具体的な時間枠を指定する必要がなくなるからです。在庫報酬関数は有限の時間枠では機能しません。無限に続きます。アルファのおかげで、非常に遠い将来の経済的な結果は限りなく小さくなり、無視できるようになります。供給チェーンの時間枠を60日、90日、1年、2年などに任意に切り捨てる必要はありません。
Envisionでは、在庫報酬関数はranvarを入力とし、zedfuncを返します。在庫報酬関数は、確率的な予測（ranvar）を経済的なリターンの推定値（zedfunc）に変換する小さなビルディングブロックです。その名前が示すように、在庫報酬関数は各在庫ポジションに関連する経済的なリターンです。在庫がゼロ個、1個、2個、3個などの場合に何が起こるかを反映します。zedfuncは、対応する在庫レベルに関連する経済的な結果をエンコードしたものです。
これらのzedfuncを計算するプロセスは画面に示されています。1行目では、単一の日の需要を示すモック需要を導入しています。2行目から7行目では、経済変数を導入しています。ちなみに、アルファは2つあります。もう1つの注意点は、在庫に関するラチェット効果です。在庫が店舗に押し込まれた後、在庫を戻すのは通常非常に高価です。これは、店舗への割り当てがほぼ最終的であることを反映しています。在庫保有コストに関しては、アルファはあまり小さくない方が良いです。なぜなら、在庫を過剰に持っている場合には本当にその保有コストが発生するからです。この決定を元に戻すことはできません。ただし、マージンに関連するアルファに関しては、将来の在庫切れに対処する機会が他にもあるため、後日に押し込まれる在庫で同じマージンを実行するために、何が起こっているかに比べて割引率をより積極的に適用する必要があります。
9行目から11行目では、在庫報酬関数自体を導入しています。前のスライドで紹介した在庫報酬関数は、マージン、在庫保有コスト、在庫切れペナルティの3つの要素に線形に分解できます。実際に、線形分離があり、Envisionではこれらの3つの要素が別々に計算されます。zedfuncには、総利益であるMを掛けることができます。
13行目から15行目では、最終的な報酬は3つの経済的要素を加えて再構成されます。このスクリプトでは、zedfuncのベクトル空間を利用しています。zedfuncは数値ではなく、関数ですが、それらを加算することができ、加算の結果は別の関数であり、またzedfuncです。変数rewardは、これらの3つの要素を合計した結果です。裏では、在庫報酬関数の計算は固定点解析を通じて行われます。この固定点解析は、各要素に対して一定時間で行うことができます。この一定時間の計算は、些細な技術的な問題のように思えるかもしれませんが、大規模な小売ネットワークを扱う場合には、派手なプロトタイプと実際の製品レベルのソリューションの違いを生み出します。
この時点で、在庫配分の問題に対処するために必要なすべての要素を統合しました。確率的な予測はranvarsとして表現され、これらのranvarsを在庫の手持ち値に対して経済的なリターンを与える関数に変換する技術があり、これらの経済的な結果はzedfuncとして便利に表現することができます。最終的に在庫配分の問題に対処するためには、重要な質問に答える必要があります。在庫を1単位しか移動できない場合、どれを移動し、なぜそれを移動するのか？ネットワーク内のすべての店舗が流通センターの同じ在庫を競っており、1単位の在庫を流通センターから特定の店舗に移動する決定の品質は、ネットワーク全体の状態に依存します。1つの店舗だけを見てこの決定が良いかどうかを評価することはできません。
例えば、すでに2単位の在庫がある店舗があるとしましょう。もし3単位を追加すると、サービスレベルが80%から90%に向上します。これは良いことであり、ネットワーク内の他の人も80から90になるために1単位追加するアイデアに同意するかもしれません。非常に合理的なように思えるので、彼らはこれが良い動きだと言うでしょう。しかし、もしこの単位を移動しようとしている3番目の単位が実際には流通センターで利用可能な最後の単位である場合はどうでしょうか？ネットワーク内の別の店舗はすでに在庫切れになっており、この単位を3番目の単位に移動すると、同じ商品の在庫切れが既に発生している店舗の在庫切れが延長されます。この状況では、在庫切れが既に発生している店舗に単位を移動する方が良い決定であり、より優先度が高いはずです。
そのため、SKUレベルで経済的な在庫レベルを評価することは意味がありません。ローカル最適化の問題は、大規模なシステムで操作する場合には機能しません。サプライチェーンでは、ローカルに対処すると問題が移動するだけで、何も解決しません。SKUの在庫レベルの適切さは、ネットワークの状態に依存します。この単純な例は、安全在庫の計算やリオーダーポイントの計算が、サプライチェーンの教科書にあるおもちゃの例と比べて、実世界の状況ではほとんど意味をなさないことを明確にしています。
ここでは、在庫配分を他のすべての在庫配分と優先順位付けし、最も優れたオプションが私たちの質問の答えになります。これが、1単位しか移動できない場合に移動すべき1単位です。
在庫配分オプションのランキング付けは、適切なツールを使用すれば比較的簡単です。このEnvisionスクリプトを見てみましょう。1行目では、A、B、Cという名前の3つのSKUを作成します。2行目では、1から10までのランダムな購入価格をモックデータとして生成します。3行目では、各SKUの報酬を表すモックzedfuncsを生成します。実際には、zedfuncは在庫報酬関数で計算するべきですが、コードを簡潔に保つためにここではモックデータを使用しています。報酬は、在庫レベル6でゼロになる減少線形関数です。4行目では、在庫を表すグリッドの省略形であるテーブルGを作成します。在庫レベルが10を超える場合は評価に値しないと仮定しています。この仮定は合理的であり、モックデータの観点から、在庫保有レベルが6を超えると報酬関数が負になるためです。6行目では、在庫の任意の単位の限界報酬を抽出し、このグリッドテーブルを作成します。zedfunc、報酬を表す関数を使用して、在庫位置G.Nの値を抽出します。なお、6行目以降では、データが元々どのように生成されたかは重要ではありません。1行目から4行目までは、本番環境では使用されないモックデータですが、6行目以降は本番環境と同じです。
7行目では、スコアを、リターンドルの比率（zedfuncが教えてくれる）と投資ドル（購入価格）の比率として定義しています。1単位あたりのリターンドルを支払うドルの量で割った比率を作成します。基本的に、最も高いスコアは、この店舗に割り当てられたドルあたりのリターン率が最も高い在庫配分で得られます。
最後に、9行から15行で、スコアの降順でソートされたテーブルを表示します。スクリプトには特別なロジックはありません。最初の4行はモックデータの生成であり、最後の6行は優先順位付けされた割り当ての表示です。zedfuncsが存在し、在庫レベルごとの経済的リターンを表す関数がある場合、zedfuncsを優先順位付きリストに変換することは非常に簡単です。
画面上では、前のEnvisionスクリプトを実行して得られたテーブルで、Cという名前のSKUが最初にランク付けされています。すべてのSKUの最初の単位に対する経済的リターンは、$5という同じです。ただし、Cの購入価格が$3.99で最も低いため、$5を$3.99で割ると約1.25のスコアが得られます。これはグリッド上で最も高いスコアです。Cの2番目の単位のスコアは約1で、2番目に高いスコアです。
グリッドの3番目の位置には、Bという別のSKUがあります。Bの購入価格が高いため、最初の単位のスコアは0.96にしかありません。ただし、最初の2つの単位をSKU Cに割り当てることから得られる減少リターンのため、Bの最初の単位のスコアはCの3番目の単位よりも高くなり、したがってCの3番目の単位よりも上位にランク付けされます。基本的に、この優先リストは非常に深くなりますが、しきい値で切り捨てられるように意図されています。たとえば、投資対効果に最低限のリターンがあると決め、その投資対効果を超える単位のみが割り当てられるとします。しきい値が定義されたら、しきい値を超えるすべての行を取り、SKUごとの行数を数えます。これにより、すべてのSKUに割り当てる合計単位数が得られます。この合計単位数は、配送センターに存在するWMSまたはERPが、翌日の店舗への出荷を整理するために期待するものです。
優先リストは、実際に優先順位を決定するための概念的なビューに過ぎません。ただし、カットオフを行い、集計を行い、その後、小売店ネットワーク内のすべてのSKUごとにSKUごとの割り当て数量に戻ります。
優先順位付けされた在庫割り当ての表示は、見た目は単純でありながら強力です。次の行に進むにつれて、割り当てオプション間の競争が展開されていくのがわかります。最良のSKUが最初に割り当てられますが、在庫レベルが高くなると、それらのSKUは在庫が少ない他のSKUと比較して競争力が低下します。優先リストはSKUごとに切り替わり、店舗への割り当てられる資本の期待収益を最大化します。
この画面では、2つ前に紹介したものとは異なるEnvisionスクリプトで得られた以前のテーブルのバリエーションがあります。基本的に、報酬に寄与する経済的要素を分解しています。ここには3つの追加の列があります：マージン、保有コスト、ストックアウトです。マージンは、割り当てられるこの1ユニットの期待平均粗利益です。保有コストは、この1ユニットを店舗の在庫に入れるための期待平均コストです。ストックアウトは、回避される予想されるペナルティですので、ここではストックアウトペナルティは正の値です。最終的な報酬は、これら3つの要素の合計であり、これらの値はドルなどの通貨単位で表されます。マージンドル、保有コストドル、ストックアウトドル、および報酬の列は、この1ユニットを店舗に入れることで期待できるドルの総額です。
これにより、ドルで表されるこの数値レシピの理解とデバッグが非常に容易になります。実際、非自明な数値レシピは設計上非常に不透明になる傾向があります。深層学習は必要ありません。数個の要素がこの回帰に関与している場合、控えめな線形回帰でも十分に不透明になります。この不透明性は、非自明な数値レシピによって実世界のサプライチェーンが危険にさらされる原因となります。サプライチェーンの実践者は、モデリングの技術的な側面によって迷子になり、混乱し、気を散らされる可能性があります。
経済的なドライバを分解する優先順位付けされた割り当てリストは、強力な監査ツールです。これにより、サプライチェーンの実践者は、技術的な側面を乗り越えて基本原則に直接挑戦することができます。以下のような質問を直接することができます：状況を考慮して意味のある保有コストはありますか？それらのコストは、私たちが取るリスクに合致していますか？予測、季節性、季節性のモデリング方法、減少傾向の要素化、その他を忘れることができます。保有コストに対する出力のドルは、最終的な結果に直接的に挑戦することができます。それらは現実的ですか？意味がありますか？非常に頻繁に、非意味のある数字を見つけて直接修正することができます。
明らかに、そのような状況を避けたいと思いますが、サプライチェーンのすべての問題が非常に微妙な予測問題であるという前提で操作しないでください。ほとんどの場合、問題は厳しいものです。データが正しく処理されていないなどの問題が発生する場合があり、その結果、マージンがマイナスになったり、保有コストがマイナスになったりしてサプライチェーンに混乱を引き起こすことがあります。
サプライチェーンの計測装置が需要の予測精度にのみ焦点を当てている場合、実際の問題の90％（またはそれ以上）には気付かないことになります。大規模なサプライチェーンでは、この推定値はおそらく99％程度になるでしょう。サプライチェーンの計測装置は、意思決定に寄与する主要な要素を強調するために絶対に必要であり、それらの要素は経済的な性質でなければなりません。なぜなら、会社を利益に結び付けるためには、自社の行動に優先順位を付ける必要があるからです。それ以外の場合、割合で操作すると、自分自身の行動に優先順位を付けることができず、問題を無差別に対処することになります。私たちは大規模なサプライチェーンについて話しているので、常に数値的な問題が存在します。それらの問題を無差別に対処するということは、大部分が重要でないものに取り組んでいることを意味します。それがなぜ、リターンドルとコストドルが必要なのです。それが、実際に作業と数値レシピの開発努力に優先順位を付ける方法です。時には、バグを修正する価値があるかどうかを決める必要さえありません。年間数ドルの摩擦の価値について話している場合、実際には修正する価値のないバグです。
さて、割り当てリストの適切なカットオフを選ぶ問題に戻りましょう。店舗のSKUにより多くの在庫を割り当てるにつれて、収益の減少が見られることを確認しました。ただし、倉庫または流通センターだけでなく、全体の供給チェーンを見る必要があります。ここでは、倉庫または流通センターという2つの用語を同じ意味で使用しています。倉庫または流通センターは固定費が支配的です。確かに、臨時労働者を雇うことでスタッフを増やすことは可能ですが、それはより高いコストがかかり、臨時労働者は通常、正規のスタッフよりも資格が低いため、他の問題が発生します。
したがって、どの倉庫または流通センターも、経済的効率が最高になる目標容量を持っています。目標容量は増減させることができますが、通常は正規スタッフの規模を調整する必要があるため、比較的時間がかかります。倉庫の目標容量は次の四半期から次の四半期に調整されることが予想されますが、倉庫の名目容量は一日から次の日に調整されることはありません。それほど動的ではありません。
私たちは、倉庫を常に最高の効率で運営し、または可能な限り最高の効率で運営することを望んでいます。経済的なインセンティブがそれに十分な強さがある場合を除いては。優先的な在庫割り当ての視点は、まさにそれを実現するための道を開いています。リストを切り詰めて少し短くしたり長くしたりし、カットオフを倉庫の目標容量に合わせることで、倉庫の最適容量に合わせて最大限に活用することができます。実際には、これには3つの主な利点があります。
まず、倉庫のフローをスムーズにすることです。これにより、倉庫をほとんどの時間最大容量で運営することができ、多くの運営コストを節約することができます。2つ目は、在庫割り当てプロセスが現実の供給チェーンで起こるさまざまな小さな事故に対してより耐性を持つようになることです。トラックが軽微な交通事故に巻き込まれるか、スタッフが病気で出勤しないかもしれません-計画を妨げる小さな理由がたくさんあります。これにより、倉庫が予想していた容量で正確に運営されないかもしれませんが、倉庫が現在使用している容量を最大限に活用することができます。これは最初に計画していた容量とは完全に一致しない場合でもです。
3番目の利点は、在庫割り当ての優先リストのアプローチにより、サプライチェーンチームが倉庫のスタッフレベルを細かく管理する必要がなくなることです。小売ネットワークの販売速度に倉庫の目標容量を合わせるだけで済みます。日々のレベルで容量を細かく管理することはほとんど意味がありません。
Lokadの経験から、フラットな容量カットオフを使用して倉庫のフローをスムーズにする方法が、ほとんどの小売業の状況でうまく機能することが示されています。画面上では、考慮すべきすべてのカットオフを考慮する場合に観察される典型的な経済的リターン曲線が表示されています。X軸には倉庫から出荷されるユニット数があります。概念的には、ユニットが1つずつ出荷されると仮定して、各ユニットの限界的な貢献を観察できるようにしています。実際には、ユニットは一括で出荷されるため、1つずつではありませんが、これは実際に曲線をプロットするためのものです。Y軸には、ストアレベルでの限界的な経済的結果が表示されます。つまり、ネットワーク内の任意のストアに出荷されるn番目のユニットに対して。最初に割り当てられるユニットが大部分のリターンを生み出します。実際には、リストの上部は常に即座の解決を要求する在庫切れの状況で構成されています。それが最初のユニットが在庫切れを解消するためであり、それが経済的リターンが非常に高い理由です。その後、リターンは減少し、曲線のフラットな部分に入ります。
この領域は、経済的感度の低い領域と呼んでいます。基本的には、サービスレベルを100％に近づけつつ、まだほとんどデッドストックを作っていません。このような優先的な割り当てを行う場合、在庫を在庫切れの問題を解決するため以上に押し出すと、在庫が速く動く商品に積み上げられることになります。現時点では必要ではない場所に在庫を作成します。将来的に在庫を補充する機会はありますが、在庫は比較的迅速に売れるため、影響は最小限です。基本的には、倉庫から店舗に在庫を移動する機会費用に関するものです。在庫を増やすにつれて、将来の選択肢が徐々に失われていきます。
この領域は比較的平坦であり、在庫を押し出しすぎて在庫の書き消しを引き起こす可能性のある状況を生成し始めると、かなりネガティブになります。押し続けると、より深刻な在庫超過の状況が生じ、したがって、曲線は非常にネガティブになります。あまりにも多く押し出すと、将来的には大量の在庫の書き消しを生み出します。この低感度セグメントにカットオフがある限り、問題ありませんし、カットオフはどこで切るかに対して非常に敏感ではありません。それが倉庫の容量が日々の販売量を直接模倣する必要がない理由です。
実際、ほとんどの小売ネットワークでは、販売において曜日ごとのサイクルパターンが非常に強く観察されます。例えば、土曜日は最も売れる日です。しかし、倉庫は曜日ごとのサイクルパターンを完全に模倣する必要はありません。非常に平坦な平均を保ち、ターゲット容量は店舗ネットワーク全体の総販売量にほぼ合致するようにする必要があります。ターゲット容量が常にネットワーク全体の総販売量よりも少し低い場合、最初にすべての店舗の在庫が徐々に枯渇し、その後大きな問題に直面します。逆に、実際に売れている量よりも毎日少し多く押し出している場合、すぐに店舗が完全に飽和します。
デイオブザウィークのパターンを細かく管理する必要はない限り、比較的バランスを保つ限り、問題ありません。デイオブザウィークのパターンを細かく管理する必要がない理由は、最初のユニットがリターンの大部分を提供し、経済的な観点からはカットオフがおおよそこの平坦なセグメントに留まっている限り、システムはそれほど感度が高くないからです。
今、私は明確さと簡潔さのために在庫報酬関数を提示しましたが、この講義ではすでに多くをカバーしていました。しかし、在庫報酬関数はサプライチェーン科学の頂点ではありません。確率的な予測の細かい点に関しては、少し単純化されています。
Lokadの私たちの一人が2021年にアクション報酬関数を公開しました。アクション報酬関数は、在庫報酬関数の精神的な子孫であり、確率的な予測自体に対してより詳細な視点を持っています。確かに、すべての確率的な予測は同じではありません。季節性、異なるリードタイム、および配送センターの入庫予定日は、アクション報酬関数では考慮されていますが、在庫報酬関数では考慮されていませんでした。
ちなみに、これらの機能にはより細かい予測が必要ですので、在庫報酬関数を利用するためには優れた予測技術が必要です。この点で、在庫報酬関数は要求が少ないです。概念レベルでは、アクション報酬関数は注文頻度（注文の頻度）と供給リードタイム（決定が行われてから在庫を補充するまでの時間）を明確に分離します。これらの2つの要素は在庫報酬関数では一緒にまとめられていました。アクション報酬では、それらは明確に分離されています。
最後に、アクション報酬関数には意思決定の所有権の視点もあります。これは、ポリシーを導入する必要なく、それに関連するほとんどの経済的利益を得るための単純で非常に賢いトリックです。後の講義で技術的な観点からポリシーが実際に何を意味するのかについて議論しますが、要点は、ポリシーを導入し始めると、より複雑になるということです。それは興味深いですが、間違いなくより複雑です。ここでは、アクション報酬には、ポリシーを導入する必要なく、それに関連するほとんどの経済的利益を得るための賢いトリックがあります。
Lokadでは、在庫報酬関数とその優れた代替であるアクション報酬関数の両方が数年間にわたって製品に使用されてきました。これらの関数は、通常小売ネットワークに悩みを引き起こす問題のクラス全体を効率化します。たとえば、在庫がなくなると、すでに店舗に存在する在庫ユニットに関連する経済的リターンを見るだけで、簡単に評価できます。しかし、今日はまだ取り上げていない多くの視点があります。これらの側面については、後の講義で取り上げます。
これらの視点のいくつかは、私が今日紹介した内容をわずかに変更するだけで対処できます。たとえば、ロットの乗数と在庫の再バランスについては、スクリプトをわずかに変更するだけでこれらの問題に対処できます。在庫の再バランスとは、ネットワーク内の店舗間で在庫をバランスさせることを指します。具体的な輸送コストを前提として、在庫をDCに戻すか、直接店舗間で在庫を移動することができます。
それから、もっと多くの作業が必要ですが、比較的簡単な視点もあります。たとえば、機会費用、一律の輸送コスト、および店舗の受け入れ過多を考慮することです。店舗のスタッフが受け取ったすべてのユニットを処理する能力がない場合に発生する受け入れ過多です。彼らは棚に置くための時間がなく、店舗内で大混乱を引き起こします。これらの視点は可能ですが、今日紹介した内容に加えてかなりの作業が必要です。
商品陳列や店舗の魅力を向上させるなど、優先順位に含めるべき他の視点もあります。これらには優れた技術的アプローチが必要であり、今日紹介した内容のわずかな変更では十分ではありません。いつものように、専門家が最適な方法を持っていると主張するときには、健全な懐疑心を持つことをお勧めします。サプライチェーンでは、最適な方法など存在しません。ツールがあり、その中にはより優れたものもありますが、最適と言えるようなものはありません。
結論として、誤差の割合は無関係であり、誤差のドル数のみが重要です。これらのドル数は、サプライチェーンが物理的なレベルで行うことによって駆動されます。ほとんどのKPIは最高でありません。それらはサプライチェーンのプロセスの一部であり、サプライチェーンの意思決定を駆動する数値レシピを継続的に改善するためのものです。ただし、数値レシピを改善するためのこれらのKPIを考慮しても、サプライチェーンの意思決定を直接改善し、即座により良い結果を生み出す数値レシピを改善することに比べれば、間接的な結果にすぎません。
エクセルシートはサプライチェーンで広く使用されており、これは主流のサプライチェーン理論が意思決定を第一級の市民として推進できなかったためだと私は考えています。その結果、企業は時間とお金を無駄にし、焦点をアーティファクトという二流の市民に向けています。しかし、結局のところ、意思決定を行わなければなりません。在庫を割り当てる必要があり、価格、販売ポイント、攻撃価格を選択する必要があります。適切なサポートがないため、サプライチェーンの実践者は、意思決定を第一級の市民として扱うことができる唯一のツールに頼ることになります。そして、このツールはエクセルです。
ただし、サプライチェーンの意思決定は第一級の市民として扱うことができます。これが今日私たちが行ったことです。ツールはそれほど複雑ではありません。少なくとも、現代のサプライチェーンの典型的なアプリケーションランドスケープの環境の複雑さを考慮すると、それほど複雑ではありません。さらに、適切なツールを使用することで、最小限の努力で配送センターから店舗への在庫の流れをスムーズにするなどの機能が利用できます。これらの機能は、適切なツールを使用することで簡単に実現できますが、エクセルスプレッドシートでは、少なくとも本番環境のセットアップでは期待できないような成果を示しています。
今日はこれで終わりです。次の講義は7月6日（水曜日）に、同じ時間帯の午後3時（パリ時間）に行われます。次は第7章に進み、定量的なサプライイニシアチブの戦術的な実行について話します。ところで、後の講義では、確率的予測について議論する第5章と意思決定技術について議論する第6章に戻ります。特定のテーマに深く入る前に、すべての要素について完全な初心者レベルの視点を持つことが目標です。
では、この時点で質問を見てみましょう。
質問: zedfuncには無限の可能性があるかもしれません。その場合、すべての解決策は短期的なものになるのではないでしょうか？
zedfunctionは、オプションのシーケンスのデータコンテナです。したがって、適用可能な時間の範囲は、スクリプトで使用したアルファ値、時間割引値に埋め込まれています。基本的に、zedfunctionの経済的な結果に埋め込まれているターゲットの時間範囲は、zedfunction自体には実際にはありません。それらはそれらを埋める経済的な計算の中にあります。zedfunctionは単なるデータコンテナであることを忘れないでください。それがそれらを短期的または長期的にするものであり、明らかに、数値レシピを調整して、それらが優先事項を表すようにする必要があります。たとえば、企業がキャッシュフローの問題で非常に多くのストレスを抱えている場合、おそらくお金を受け取ることに関しては短期的な視点を持つでしょう。つまり、在庫をただ流動化するだけです。現金に余裕がある場合は、販売を後の時期に延期し、より良い価格で販売し、より良い粗利益を確保することを選択するかもしれません。したがって、zedfunctionではこれらのすべてのことが可能です。zedfunctionは単なるコンテナであり、zedfunctionに入れたい経済的な結果の数値レシピを必ずしも前提としないのです。
質問: ほとんどの仮定は、目的関数の既存の実際の値に基づいていると思いますが、どう思いますか？
現実とは何でしょうか？それが実験的最適化について講義で議論した問題の本質です。問題は、値や測定値などを持っていると言っても、それが数学的な構築物、数値的な構築物であるということです。数値であるからといって正しいとは限りません。私がサプライチェーンにアプローチする方法は、実験科学としてのものです。現実世界に接続する必要があります。それが本物かどうかを判断する方法です。問題は、仮定は既存の実際の値に基づいているわけではなく、既存の実際の値などというものは存在しないということです。それらの仮定はチェックされなければならず、自分のサプライチェーンで行える実際の世界の観察に対して挑戦されなければなりません。仮定の正確さは、サプライチェーンの現実との接触によってのみ評価できます。
これが実験的最適化の視点が厄介なところです。数学的最適化の視点では、すべての変数が既知であり、すべての変数が実際であり、すべての変数が観測可能であり、損失関数が正しいと仮定しています。しかし、私が言っているのは、サプライチェーンは非常に複雑なシステムであるということです。それは真実ではありません。ほとんどの場合、持っているのはかなり間接的な測定値です。在庫レベルと言っても、実際に店舗に行って在庫レベルを確認するわけではありません。持っているのは非常に間接的な測定値であり、企業ソフトウェアシステムから得た電子的な記録です。それは通常、データサイエンスを行うための理由とはまったく関係のない理由で20年前に導入されたものです。それが言いたいことです。現実の問題は、サプライチェーンが常に地理的に分散しているため、測定するすべてのもの、値として見えるすべてのものは間接的な測定値です。ある意味では、これらの測定値の現実性は常に疑問視されています。直接的な観察として行うことはできますが、それは制御やチェックのためのものであり、サプライチェーンの操作に必要なすべての値のごく一部に過ぎません。
質問: 在庫報酬関数では、マージンなどの明確なパラメータだけでなく、在庫切れのペナルティも扱っています。これらの複雑なパラメータを最適化するためには、どのように学習すればよいですか？
これは非常に良い質問です。確かに、在庫切れのペナルティは実在します。そうでなければ、高いサービスレベルを持つ必要もないでしょう。サービスレベルを持ちたい理由は、経済的に言って、私が知っているすべての小売業者が在庫切れのペナルティが実在すると確信しているからです。顧客は高品質のサービスがないことを好みません。ただし、それらは複雑ではなく、複雑です。それらは本質的に困難であり、その困難の一部は、小売ネットワークの長期戦略そのものがかかっているということです。私のほとんどのクライアントとは、たとえば、在庫切れのペナルティについては、直接会社のCEOと話し合うものです。それは非常に重要な問題です。これは小売ネットワークの超長期戦略がかかっています。
ですから、それは複雑ではありますが、非常に高いリスクを伴う議論です。私たちは何をしたいのでしょうか？顧客をどのように扱いたいのでしょうか？私たちは非常に低価格でユニークなものを持っていると言いたいのでしょうか？それとも新しさを持ちたいのでしょうか？新しさがあるということは、常に新しい製品が入ってくるということであり、常に新しい製品が入ってくるということは、古い製品が段階的になくなっていくということであり、したがって、在庫切れが起こることを許容する必要があるということです。それが新しさを導入する方法です。
在庫切れのペナルティは、会社の長期戦略に直接的な影響を与えるため、評価するのは困難です。実際には、それを評価する最良の方法は実験を行うことです。ある値を選び、在庫切れのペナルティの値、在庫のペナルティ係数の大まかな推定値を作成し、店舗にどのような在庫が入ってくるかを確認します。そして、人々に感じを持って判断してもらい、それが彼らの理想的な店舗を反映しているように見えるかどうかを判断します。それは彼らが顧客に対して本当に望んでいることですか？それは彼らが小売ネットワークで達成したいことですか？
ご覧のように、これは往復の議論があります。通常、サプライチェーンの科学者は一連の値をテストし、経済的な結果を示し、ドライバーに関連するマクロコストも説明します。彼らは「大きな在庫切れのペナルティを設定できますが、注意してください。それを行うと、在庫割り当てロジックが常に店舗に大量の在庫を押し付けることになります。」と言うかもしれません。なぜなら、在庫切れが致命的だというメッセージならば、それは在庫切れを防ぐためにできる限りのことをするべきだからです。基本的には、経営陣が「私の小売ネットワークが実際にできることに経済的に適しているか？」という現実的なチェックを行うために、この議論を反復する必要があります。それが徐々に収束する方法です。ちなみに、それは固定されたものではありません。企業は時間とともに戦略を変更し調整しますので、2010年に在庫切れのペナルティ係数を設定したからといって、2022年に同じ値である必要はありません。
特に、例えば、電子商取引の台頭により。多くの小売ネットワークは、「私の店舗では在庫切れに対してはるかに寛容になりました。特に専門店では。」と言うかもしれません。なぜなら、製品が欠けている場合、特にサイズのバリエーションの場合、人々は電子商取引からオンラインで注文するだけです。店舗はショールームのようになります。したがって、店舗のサービスの品質は、製品を販売する唯一の方法であったときに期待されていたものとは非常に異なります。
質問: 特定の期間内の傾向を正しく理解するために、複利の在庫報酬関数を持つことはできますか？
何の傾向を正確に理解するのですか？需要の傾向であれば、在庫報酬は確率的な予測を消費する関数です。したがって、需要にどのような傾向があっても、それは通常、需要のモデル化方法の要素です。在庫報酬関数に関しては、確率的な予測には既にそれが組み込まれており、傾向があるかどうかは関係ありません。
今、在庫報酬の種類に関する別の質問がある場合、完全に正しいです。在庫報酬関数は完全に静止的な視点を持っています。需要が確率的に毎期完全に同じように繰り返されると仮定しているため、傾向や季節性はありません。これは純粋に静止的な視点です。この状況では、在庫報酬関数は非静止的な需要に対処することができません。ただし、アクション報酬関数はそれを行うことができます。これは非静止的な確率的需要に対処できるようにするための動機の1つでもありました。
質問: 倉庫の容量は固定されていると仮定していますが、ピッキング、パッキング、出荷の努力に依存します。倉庫の操作の最適化によってカットオフリストのポイントを定義すべきではありませんか？
はい、もちろんです。それは私が言ったことです。経済的感度の低いゾーンがある場合、優先順位付けされた在庫割り当てを表す優先リストは、カットする場所に関しては非常に敏感ではありません。平均的には、どれだけ押し込んでどれだけ売るかは非常にバランスが取れているはずです。倉庫の最適化ロジックを実行した後に、ピッキング、パッキング、出荷の努力と変動を考慮に入れて、カットオフをわずかに異なるように調整したい場合は、問題ありません。最後の瞬間の変更ができます。優先順位付けされた在庫割り当てリストの美点は、出荷されるユニットの正確な範囲を文字通り最後の瞬間に確定できることです。必要なのは集計だけで、非常に迅速に行うことができ、より多くのオプションが得られます。これが私が今日紹介したアプローチが新しい供給チェーン最適化のクラスを開くと述べた理由です。これにより、リソースや実行にかかる努力に正確に一致しないあらかじめ定められた出荷エンベロープに固執するのではなく、ピッキング、パッキング、出荷の努力を柔軟に再配置するために、タイミングよく決定することができます。
質問: 倉庫のフローをスムーズにするには、生産フローもスムーズにする必要があります。この意思決定モデルはそれを考慮していますか？
私は、それが自然にスムーズな生産フローを必要としないと言いたいと思います。一般的な商品店などの多くの小売ネットワークでは、非常に大きなバッチを生産している大手FMCG企業から注文を受けています。配送センターから店舗への出荷に関しては、生産フローをスムーズにする必要はありません。生産がスムーズにされていなくても、配送センターからの出荷だけで既にコスト削減の利益があります。
ただし、完全に正しいです。自社の生産施設、配送センター、店舗を内部化している垂直統合ブランドである場合、サプライチェーン全体の最適化とフローのスムーズ化には明確な関心があります。ネットワーク全体の最適化アプローチは、私が今日紹介した内容と非常に一致しています。ただし、真の多段階サプライチェーンネットワークを最適化するには、私が今日紹介したものとは異なる技術が必要です。それを実現するための多くのビルディングブロックがありますが、私が今日紹介したスクリプトを微調整するだけではそれを達成することはできません。これは、後の講義で紹介される多段階設定をカバーする技術です。これはより複雑です。
質問: 在庫報酬アプローチと予測誤差は、金融の期待値の概念を思い出させます。あなたの視点からは、なぜこのアプローチがまだサプライチェーンの世界では主流ではないのですか？
あなたは完全に正しいです。このようなもの、つまり結果の真の経済分析は、金融界では古くから行われてきました。私は、ほとんどの銀行が80年代からこれらの計算を行ってきたと信じていますし、おそらくそれ以前からペンと紙で行っていた人々もいたでしょう。したがって、他の分野では長い間行われてきたことです。
私は、サプライチェーンの問題は、インターネットの登場まで、店舗、流通センターなどが地理的に分散していたため、自然に地理的に分散していたと考えています。1995年以前は、企業間でデータを移動することは可能でしたが、非常に複雑でした。信頼性のある方法で、安価にデータを移動させ、それらのデータを統合するためのエンタープライズシステムを持つことは珍しかったのです。したがって、サプライチェーンは非常に早い段階でデジタル化されましたが、ネットワーク化は比較的遅く、ほとんどの企業では2000年以降になったと言えます。
問題は、配送センターで作業していると想像してみてくださいが、ネットワークの他の部分からはかなり孤立しているため、倉庫マネージャーはこのような洗練された数値計算を行うためのリソースを持っていませんでした。倉庫マネージャーは通常、分析者ではありませんでした。したがって、インターネットの時代より前の実践では、ネットワーク全体で利用可能な情報がすべて利用可能である現在の時代とは異なり、それらの実践は残っています。それが理由であり、ところで、サプライチェーンは通常、非常に大きく、複雑で複雑な存在であるため、動きが遅いのです。
データがネットワーク全体で共有され、非常に素晴らしいデータレイクがあるとしましょう。2010年だったとしますが、それは10年前のことですが、サプライチェーンの規模と複雑さを考えると、10年はそれほど長い時間ではありません。それが、これらのタイプの分析が金融界では40年以上もデフォルトである理由であり、サプライチェーンでは現在でも新興分野であるという理由です。少なくとも私の場合はそうです。
質問: 在庫切れコストについて、主に誤配置コストで計算されますか？
それはできます。再度、在庫切れコストは文字通りあなたが行う決定です。それはあなたの小売ネットワークが顧客に提供するサービスの種類に対する戦略的な視点です。基本的な現実はありません。それはあなたが望むものです。誤配置コストについての質問は、現実は、ほとんどの小売ネットワークが忠実な顧客基盤を持っているために生き残っているということです。人々は店舗に戻ってきます。それが毎週訪れる総合商品店であれ、毎四半期訪れるファッション店であれ、2年ごとに戻ってくる家具店であれ、サービスの品質は長期的な顧客ロイヤリティを維持し、店舗でのポジティブな体験を確保するために重要です。ほとんどの店舗にとって、失われたロイヤリティのコストは誤配置コストをはるかに上回ります。思い浮かぶ例外の一つは、最も安いことを重視したブランド戦略を持つ小売店です。この場合、彼らは品揃えとサービスの品質を犠牲にし、すべてのものの上に低価格を優先します。
質問: 倉庫に在庫を保管する目的は何ですか？低価格で商品を保つことですか、それとも高価格で店舗に商品を供給することですか？
これは素晴らしい質問です。なぜ配送センターに在庫を保管するのですか？すべてを直接クロスドックするのではなく、すべてを店舗に送ることはできませんか？
すべてをクロスドックする小売ネットワークもありますが、このアプローチでも、サプライヤーに注文をする時と実際に在庫を店舗に発送する時の間には遅延があります。特定の数量を特定の割り当て方式で注文することができますが、2日前に考えていた割り当て方式に厳密に固執する必要はありません。在庫が配送センターに届いた時に考えていた割り当て方式を柔軟に変更することができます。
配送センターに在庫を保管せず、クロスドックだけを行うこともできますが、遅延があるため、考えを変えてわずかに異なる発送をすることができます。これは、需要の予想外の急増による在庫切れが発生した場合に役立ちます。在庫切れを持つことは望ましくありませんが、それは予想よりも需要が過剰であることを示しており、完全に否定的なものではありません。
倉庫に在庫を保管する必要がある他の状況では、サプライヤーとの注文制約のためです。たとえば、FMCG企業では、1週間に1回しか注文をすることができず、通常はフルトラックで配送することを希望しています。注文は大量でバッチ処理され、配送センターはその配送のためのバッファとして機能します。また、センターでは在庫の割り当て先を変更するオプションも提供しています。
在庫が配送センターにある限り、考えを変えることができます。ただし、特定の店舗に割り当てられた後、倉庫に戻すための輸送コストは通常非常に高く、避けたいものです。
ありがとうございました。次回お会いできることを願っています。実際の量的なサプライチェーンイニシアチブを実施する方法について、実際の企業で議論します。また次回お会いしましょう！
