図解された在庫報酬関数
在庫報酬関数は、確率的予測を最大限に活用し、サプライチェーンパフォーマンスを向上させるための重要な要素です。在庫報酬は、追加の在庫ユニットを購入または製造する際の投資収益率（ROI）を計算するために使われます。
在庫報酬関数は表現力が高く、多岐にわたる状況に対応するための小さなフレームワークのように利用できます。しかしその一方で、この関数が何を計算しているのかを理解するのは必ずしも容易ではありません。以下では、予測に適用されるさまざまな変換を示すグラフを簡単に紹介します。
最初のグラフ 将来の需要 は、ある SKU に対応する確率的需要予測を表しています。曲線は確率分布を示しており、曲線下の面積の総和は 1 です。背景では、この将来需要は暗黙のうちに確率的なリードタイム予測と結び付いており、これもまた確率分布として表現されます。この種の分布は通常、確率的予測エンジンによって生成されます。
限界フィルレート のグラフは、在庫を 1 単位追加したときに取り込める追加需要の割合を表しています。言い換えれば、在庫が増えるにつれてフィルレートがどのように変化するかを示すグラフです。ここで表しているのは限界フィルレートなので、曲線下の総面積は 1 のままです。限界フィルレート分布は fillrate() 関数で計算できます。
バックオーダー込みの需要 のグラフは 将来の需要 のグラフと同一ですが、バックオーダーを表す 8 単位が追加されています。バックオーダーは、すでに顧客によって購入済みであるため、確定した需要を表します。その結果、バックオーダー単位を導入すると、需要の確率分布は右にシフトします。こうした初期分布に対する変換を計算するために、分布代数の一部としてシフト演算子 >> が利用できます。
バックオーダー込みのフィルレート のグラフも、元の 限界フィルレート のグラフと非常によく似ていますが、同様に 8 単位だけ右へシフトしています。ここで描かれているフィルレートは不確実な需要にのみ対応しているため、分布の形状そのものは変わりません。
利益率 のグラフは、バックオーダー込みの需要 を入力として在庫報酬関数が計算した経済的報酬としての利益率を表します。在庫報酬は分布として可視化できますが、これは確率分布ではありません。曲線下の面積は 1 ではなく、在庫が無制限にある場合に獲得できる利益総額に等しくなります。グラフの左側では、各バックオーダー単位が同じ利益を生みますが、これはそれらの単位がすでに購入済みであり、利益の獲得に不確実性がないため自然なことです。
品切れペナルティ は、在庫報酬関数の第 2 の構成要素を表します。分布の形状は少し意外に見えるかもしれませんが、これは在庫報酬関数の構造上、曲線下の総面積が 0 になることを反映しているだけです。直感的には、在庫水準が 0 から始まると、すべての需要を満たせないため、すべての品切れペナルティの合計を抱えることになります。その後、在庫水準が高くなるにつれて、より多くの需要を満たせるようになり、品切れペナルティは徐々に減少していきます。最終的には需要全体が満たされ、ペナルティは残らなくなります。バックオーダーに対応できない場合の品切れペナルティは、その後に続く通常需要を満たせない場合のペナルティよりも大きく表現されています。ここでは、すでにバックオーダーしている顧客の方が、まだ何も購入していない顧客よりも高いサービス期待を持つ傾向がある、という前提を示しています。
保有コスト のグラフは、在庫報酬関数の第 3 にして最後の構成要素を表します。保有コストには上限がなく、在庫を 1 単位増やせば保有コストもさらに増えるため、この分布は発散し、右側では負の無限大へ向かいます。曲線下の総面積も負の無限大になりますが、これはやや理論的な見方です。右側では、バックオーダー単位に対応する保有コストは 0 です。すでに顧客に購入されている単位は、できるだけ早く出荷されるため、追加の保有コストを生まないからです。
最終的な在庫報酬は、上では図示していませんが、在庫報酬関数の 3 つの構成要素を合計することで得られます。得られた分布は、追加で取得する在庫 1 単位ごとの ROI として解釈されます。この分布は通常、最初は正の値から始まり、最初の数単位の在庫は利益を生みますが、保有コストに上限がないため、在庫水準が高くなるにつれて負の無限大へと収束していきます。
数学における support という用語は、古典的には非ゼロ確率に対応する需要水準を指します。上のグラフでは、サポート という語を、Envision が非ゼロ値として処理すべき全範囲を指すやや広い意味で用いています。特に重要なのは、最終的な分布が切り詰められないようにするため、分布サポートを拡張しなければならない計算が複数あることです。
- バックオーダーが存在する場合に起こるシフト演算では、サポートをバックオーダー単位数だけ増やす必要があります。
- 在庫報酬関数の利益率成分と保有コスト成分には、理論上右側の上限がなく、サポートの大幅な拡張が必要になる場合があります。
- 最小発注量のような発注制約により、シフト後の分布が到達する水準よりもさらに高い在庫水準を扱う必要が生じることがあります。MOQ を利益の出る形で満たせるかどうかを見積もるうえで、分布の裾を正しく評価することが重要です。
実際には、Envision ランタイムがサポートを自動的に調整し、計算中に分布が切り詰められないように処理します。