商品や中間部品、原材料の在庫を維持する最も一般的な方法は、予測を頼りに、日当たりの平均売上/平均消費を見積もって、固定の日数分の在庫を持ったり、最小と最大の在庫レベルを決めたりするやりかたです。その在庫日数（または在庫週数）は、在庫品のカテゴリ全体に対するポリシーから決められ、供給リードタイムとして大雑把に示されます。
しかし、この一般的な方法だと、実際は決めた在庫レベルから両方向に大きく乖離して、欠品と同時に膨大な余剰在庫が発生します。
その一般的方法の考え方の主な欠陥を挙げると次のとおりです：
- 一般的な方法では、需要の変動を監視し、それを根拠に将来を予測する。しかし、供給リードタイムの不確実性は無視している。目標在庫のレベルは、需要と供給両方の変動を考慮しなければならない。
- 現在の予測方法は、需要平均の予測に基づくもので、不確実性の大きさ（予測誤差）を評価しない。したがって、常に変動している需要を満たすに必要な在庫量に関する情報を欠いている。
- 頻繁な予測し直しでシステム内のノイズが増幅される。
- min-max法はバッチ処理を促して、補充間隔を長くする結果、不確実性の影響が増大する。
それに対してTOCの重要な知見は次のとおりです：
- 手持ち在庫だけでなく、「手配中」のアイテムも勘定に入れる、つまり、未着のものを含むすべての仕入品を勘定に入れて、高いアベイラビリティを保証する仕組みを構築すべきだということ。したがって、目標在庫のレベルは、手持ちと手配中を両方とも含む在庫バッファである。
- 目標在庫のレベルは、もはやそれが適切ではないという、明確な信号を受けとるまで一定に保つ。
- 早く頻繁な補充で目標在庫のレベルを素早く回復する。
- バッファ管理は、ある場所から別の場所への在庫の移動に単一の優先順位を設定するのに使う。
- バッファの動きを追跡して、目標在庫のレベルが高すぎるのか低すぎるのかを判断する。それが動的バッファ管理（DBM：Dynamic Buffer Management）アルゴリズムの目的である。
- 異なる2つの不確実性の発生源の影響の組合せをチェックするのが狙いである：
- 市場の需要 ― その浮き沈み！
- 再補充の時間 ― 補充頻度の影響も含めたそれ自身の変動。
- 小さな変化は気にしても意味がない。
- 手持ち在庫がレッドゾーンに長く留まりすぎていて、同時に深く食込みすぎるのは、バッファを大きくしろという信号である。
- 逆に、グリーンゾーンに長く留まりすぎるのは、バッファを小さくしろという信号である。
- 異なる2つの不確実性の発生源の影響の組合せをチェックするのが狙いである：
DBMの考え方の画期的なところは、バッファサイズを再計算するのではなく、保護メカニズムの有効性をモニターすることです。需要と再補充の時間は、どちらも説明し難い不規則な挙動をします。一番の問題は、環境の頻繁な変化して、需要と供給リードタイムを左右する重要なパラメータが乱されることです。新しい競争相手の出現、論争の的になるマスコミの記事、経済や規制の変化など、どれも市場の需要に劇的な変化を引き起こす可能性があります。
再補充の時間は、供給側の運用管理とキャパシティへの負荷に大きく左右されます。この2つの因子の変化で、再補充の所要時間が大きく変化するかもしれません。
そういう大きな変化が起きたら、バッファサイズの再計算は、過去の実績に頼るしかないので厄介です。ですから、保護メカニズムの状態が実際に変化したのを感知することが、直近の過去に基づいた素早い行動に繋がるのです。この即時応答では、新しいバッファサイズを厳密に推定しようとせず、ただ上方修正か下方修正か推定するだけです。ゴールドラット博士は、DBMがその必要性を通知したら、単純にバッファを現在の33%大きくするか小さくするよう提案しました。
業績へのDBMの影響は極めて大きいので、DBMが間違った信号を出したら非常に高くつくでしょう。特定の事態、特に他と違う対処が必要な状況を見分けられるようアルゴリズムをチューンアップするには、継続的な学習が必要です。
たとえば、レッドゾーンに長い時間深く食込んだ原因が、供給元の在庫不足やキャパシティ不足で（一時的に）補充不能になったということなら、DBMはバッファを大きくすべきではありません。
概念上の問題は、固定の比率でバッファサイズを変更することです。大きくするか小さくするかの問題ではありません。変更した後暫らくして、その変更は実は不要だったと分かることは、常にあり得ます。つまり、大きくした直ぐ後で小さくしろという信号がでるみたいなことです。ところが、常に33%固定で変更すると、大きくする前のバッファの約90%（訳注：1.33×0.67=0.8911）になってしまうのです。問題はその矛盾の釈明が難しいことです。
Dmitry Egorov氏が提案したアイデアは、本当にそれが必要だったことを確認するために、バッファを増やした直後の振る舞いを注意深くチェックするというものでした。バッファを大きくすると、新しいバッファサイズでは、相対的に以前よりも深くレッドゾーンに食い込むことになります。そう考えると、非常に短時間でバッファがイエローゾーンまで回復したとすれば、それはバッファを元のサイズに戻せという信号です。
バッファを小さくするときも同様にすべきです。バッファが小さくなると、一時的に手持ち在庫が新しいグリーンラインを上回ります。ですから、バッファが直ぐにイエローゾーンに下がったら、DBMはバッファを元のサイズに戻すよう促すべきです。
それに関連した問題は、バッファを増やすと減らすでDBMのアルゴリズムが非対称なことです。バッファを増やすときは、DBMのアルゴリズムはレッドゾーンへの食込みの深さも考慮します。ところが、バッファを減らすときは、グリーンゾーンへの食込みの深さは全く考慮しません。実は、バッファを減らすについては、バッファを増やすときよりずっと保守的でないといけないそれなりの理由があります。
TOCのアルゴリズムそのものは再補充の時間を監視しないので、それを意思決定に使うのが適切かどうか疑わしく、私はDBMのアルゴリズムに再補充の時間が含まれるのが気掛かりです。DBMの肝は、需要と再補充時間の変動の複合作用を監視することです。DBMのアルゴリズムで再補充の時間が唯一重要なところは、新しい目標在庫のレベルが有効かどうか確認できるまで、続けてバッファを大きくするのを防ぐことです。しかしそれは、バッファを大きくするために発行した特別な補充指示で手配したものが実際届くのを監視すれば済みます。バッファを大きくするアルゴリズムは、食込みの深さを考慮したレッドゾーンの連続滞在時間を根拠にすれば良いでしょう。それに、バッファを小さくする方は、再補充の時間を基準にしないといけない理由は何もありません。グリーンゾーンに長く滞在しすぎると判定する時間パラメータがあれば事足ります。
DBMは予測と同様に機能し、近い将来を推測するのに過去を振り返ります。しかし、DBMはごく直近の過去しか見ず、手持ち在庫の実際の状態だけを考慮します。
追加の情報として予測を使わないといけないのか？
そもそものアイデアは、バッファが不適切だという明確な兆候がない限り、バッファを変えないことでした。本当に追加で欲しい情報は、DBMにはないパラメータを考慮した予測をベースにして、現在のバッファが明らかに大きすぎるのか小さすぎるのか示してくれる、大雑把な見積もりです。たとえば、季節性を考えると、経済の変動や新製品の登場に関する知識は、バッファを変更すべきかどうかの判断に有効な情報を追加してくれるし、大体どれくらい変えたらよいかも教えてくれます。バッファの20%未満の小さな変化が予想されるなら、バッファサイズは現状のまま据え置くべきでしょう。
私が思うに、もっと全体として効果的な在庫バッファの管理方法を探す上で、上記の問題は中核の問題です。私は常に最終的な決定は人間に委ねるのが好みですが、そうするには最も適正な情報を提供しないといけないと思っています。サプライチェーンのあちこち様々な場所に何百万もの在庫バッファがあって、常時それらの1〜2%が妥当でないらしいとすれば、そんなに多くのバッファの変更を人間が考えるのは事実上無理です。そうだとすれば、予測との組合せかどうかは別にして、DMBにバッファを自動的に更新させる必要があるでしょう。つまり、DBMが効果的かどうかは、組織の財務的と戦略的なパフォーマンスを直接左右するということです。
DBMは、ソフトウェアベンダーが参照すべき効果的なDBMの仕様を考えることは、TOCの専門家を一致団結させるに十分価値のある、非常に重要な課題です。そのソリューションの詳細すべてが広い支持を得ないといけないのです。TOCはいかなる「ブラック・ボックス」アルゴリズムにも明確に反対です。
著者：エリ・シュラーゲンハイム
飽くなき挑戦心こそが私の人生をより興味深いものにしてくれます。私は組織が不確実性を無視しているのを見ると心配でたまりませんし、またそのようなリーダーに盲目的に従っている人々を理解することができません。
この記事の原文： Dynamic Buffer Management (DBM) – the breakthrough idea and several problems to solve
