2
8

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

新たな安全在庫分析手法がどのように在庫を最適化するのか

Last updated at Posted at 2021-03-11

How a Fresh Approach to Safety Stock Analysis Can Optimize Inventoryの翻訳です。

詳細はノートブックを参照ください

製造業者は、顧客の注文にきちんと対応したとしても、重要な部分が供給業者によって遅延させられてしまうことがあります。これまでに見たことがない理由からビールの需要が急激に増加し、供給能力の欠如から売り上げ機会を損失してしまうということもあります。結果として、需要を満たせない業者に対して、顧客はネガティブなイメージを持つことになります。これらの企業は利益を失い、評判にも傷がつきます。こういった話を聞いたことはありませんか?

理想的な世界においては、商品に対する需要は容易に予測できます。実際のところは、ベストな予測であっても、予期しないイベントに影響を受けてしまいます。原材料の供給、貨物、物流、製造での問題、予期しない需要などによって、断絶は起こりえます。余剰在庫を持つことなしに顧客の需要に応えるために、小売業者、配送業者、製造業者、供給業者全てが、これらの問題に取り組む必要があります。ここで、安全在庫分析(Safety Stock Analysis)が役立ちます。

企業は、予測される需要に応えるためにリソースを配置することを継続的に行っています。しばしば、予測精度の改善が喫緊の課題となります。この課題達成のために、企業はスケーラブルな基盤や、自社内の専門家、洗練された新モデルに投資を行います。

どれだけ精度の良い予測をしたとしても完全に未来を予測することはできませんし、急激な需要のシフトは余剰在庫を引き起こします。このことは、2020年のCOVID-19流行が、広範囲のトイレットペーパーの欠品を引き起こしたことからも分かるかと思います。H-E-Bの社長Craig Boyanによれば「通常2ヶ月で売れる量が2週間で売れた」とのことです。

製造能力を増強するだけが問題の解決策ではありません。トイレットペーパー製造のリーダーであるGeorgia-Pacificは、パンデミックにより在宅が増えた結果、平均的なアメリカの家庭でのトイレットペーパーの消費が40%増加したと推定しました。この結果、14のトイレットペーパー製造施設において20%の製造量の増強を行うことができました。ほとんどの工場では、24時間操業を行っているため、これ以上の増強は、さらなる設備投資が必要となります。

このような製造量の急激な増加は、上流に影響を及ぼします。供給業者は、増加した製造量に対応するためにリソース配置に奮闘することになります。トイレットペーパーはシンプルな商品ですが、その製造には北米、カナダ、スカンジナビア、ロシアの森林地帯からのパルプ供給、ローカルにおける再生紙などに依存します。製造業者の初期在庫が枯渇したとしても、供給業者が伐採、加工、出荷するまでにはリードタイムが発生します。

Bullwhip effectと呼ばれる、サプライチェーンにおける考え方がこれを表現しています。サプライチェーンにおいて発生した混乱した情報は、在庫に多大なる非効率性を引き起こし、貨物・物流コストを引き上げ、キャパシティ計画を不正確なものにします。製造業者や小売業者は在庫を正常な状態にしようとすると、供給業者の製造量も増加させ、それは上流に連鎖していきます。慎重に対応しないと、小売業者、供給業者は在庫の山に囲まれることになり、需要が正常な状態に戻った時には、エンドユーザは自身の蓄積した商品を消費することになるため、場合によっては売り上げが通常よりマイナスになることもあります。Bullwhip effectの影響を軽減するためには、需要の不確実性を考慮した注意深い検討が必要となります。

安全在庫分析による不確実性の管理

COVID-19のパンデミックに関連した需要のシフトを予測することは困難ですが、サプライチェーンを持つ企業が取り組むべき、不確実性のコンセプトの極端な例を示したと言えます。比較的正常な期間における顧客の行動であっても、商品・サービスの需要は変動しますので、十分に検討し、積極的に対応する必要があります。

最近の需要予測ツールは、週次、年次の季節性、長期間のトレンド、休日・イベント、気候・プロモーション、経済などの外部要因を考慮して、需要の平均値を予測します。これらは単一の予測値を導出しますが、半分のケースでは需要が予測値を下回り、もう半分のケースでは予測値を上回ることとなり、結果的にミスリーディングとなるケースがあります。

平均の予測値を理解することは重要ですが、その両側にある不確実性を理解することも同様に重要です。この不確実性は、遭遇しうる定量的な確率として、需要の値に幅を持たせるものと考えることができます。需要予測をこのように考えることで、我々はどの範囲に取り組むべきかという議論を始めることが可能となります。

統計学的に言えば、取りうる需要の全ての幅は無限大であるため、100%の幅に取り組むことは不可能です。しかし、仮に需要のあらゆる可能性を追求しようとすると、とてつもないレベルで在庫を抱えなくてはならないという話になってしまうことは容易に理解できます。このことから、この議論は、収益目標と在庫コストのバランスを取った、目標サービスレベルの追求に帰着します。

期待するサービスレベルを定義した結果、不確実性に対するバッファとして、通常の需要に応えるだけの在庫に加えて、一定量の追加在庫を持たなくてはなりません。これが安全在庫(Safety Stock)であり、平均需要サイクルに適応する在庫サイクルに追加することで、多くのケース(全てではありません)の変動に、企業のゴールのバランスを取りながら実際の需要に対応できるようになります。

必要安全在庫レベルを計算する

従来のサブライチェーンに関する文献では、安全在庫は需要の不確実性と配送の不確実性を取り扱う二つの数式のうち一つを用いて計算されます。ここでは、需要の不確実性にフォーカスしているため、リードタイムの不確実性は排除し、シンプルな単一の安全在庫の計算式を用います:

$安全在庫 = Ζ * √PC/T * σD$

簡単に言えば、この数式は需要予測の平均値に含まれる不確実性の平均値($σD$) × 在庫の稼働サイクルの平方根($ √PC/T $ ) × 取り組むべき不確実性のレンジ(Z) として安全在庫を計算します。数式を完全に理解するためには、それぞれの要素に関する説明が必要です。

前の節では、予測によって得られる平均値の周辺に一定幅で潜在的な需要が存在することを説明しました。もし、平均値の周辺に均等な幅で潜在値が存在すると仮定すると、平均値の両側に対して幅の平均値を計算することができます。需要予測の標準偏差として知られる$σD$の値は、平均値の周りの幅を計算する手段を提供します。

我々は、平均値の周辺の帯域はバランスされていると仮定しているため、平均からの標準偏差から幅に関する比率を導出することができます。期待するサービスレベルによって取り組むべき需要の比率を表現するのであれば、安産在庫計画の一部として考慮すべき需要における標準偏差を用いることができます。必要となる標準偏差(計算式でZで表現されるzスコア)の計算式は、幅のパーセンテージを捕捉するために少々複雑なものとなります。しかし、幸運なことにzスコアの表は広く公表されており、オンラインの計算機も利用できます。一般的に用いられるサービスレベルに対応するzスコアの一覧表は以下の通りです:

期待サービスレベル Z(zスコア)
80.00% 0.8416
85.00% 1.0364
90.00% 1.2816
95.00% 1.6449
97.00% 1.8808
98.00% 2.0537
99.00% 2.3263
99.90% 3.0902
99.99% 3.7190

最後に、安全在庫を計算するためのサイクルに関する項( $ √PC/T $ )を説明します。なぜ平方根が必要なのかを一旦脇に置いておけば、数式において非常に理解しやすいものだということがわかります。$PC/T$は安全在庫を計算する期間を表現します。標準偏差を計算するために同じ単位で期間を表現する必要があり、Tによる除算をしています。例えば、7日のサイクルで安全在庫を計画する場合、日次の需要の値を利用して、需要の標準偏差を計算するのであれば、本項には7の平方根を用いることになります。

需要のばらつきを予測するとは困難です

表面上は、安全在庫分析における計算は直感的なものです。サブライチェーンマネジメントのコースでは、学生たちは数式の標準偏差の項を計算するために、しばしば需要の履歴データを用います。期待サービスレベルが与えられれば、すぐにzスコアを導出し、ターゲットレベルに合致する安全在庫を計算します。しかしながら、これらの値は正しくありません。もしくは、少なくとも、間違った重大な仮説の外においては間違っていると言えます。

あらゆる安全在庫の計算においてこだわるべきポイントは需要の標準偏差です。標準的な計算式は、計画すべき未来の期間における需要の変動を知っていることを前提としています。時系列における変動が安定していることは極めて稀です。そうではなく、データにおける季節性パターンやトレンドは頻繁に変動します。イベントや外部の訴求要因も影響を及ぼします。

この問題を解決するために、サプライチェーンのソフトウェアはしばしば、RMSEやMAEなどの予測誤差で、標準偏差を代替しています。しかしながら、これらの値は違うものを表現(関係する概念ではありますが)しています。これは、しばしば以下のチャートにあるように、安全在庫を低く見積もってしまいます。ここでは、95%のサービスレベルを期待しているのにもかかわらず、92.7%のサービレベルとなっています。

そして、多くの予測モデルは予測の平均値を計算するために、予測誤差を最小化しようとします。皮肉なことに、モデルの性能を改善することは、低く見積もるという問題を悪化させてしまいます。このことは、多くの小売業者が期待するサービスレベルを達成するために取り組んでいるにもかかわらず、多くが未達に終わるということを認識し始めている状況です。

次に何をすべきか、いかにDatabricksを利用すべきか

問題に取り組むための、重要な第一歩は安全在庫計算における不足を認識することですが、認識するだけでは不十分です。

何人かの研究者は、安全在庫推定を改善するために、需要のばらつきをより良い精度で予測する手法を定義しようとしています。しかし、どのように達成するかについてはまだ合意が取れていません。また、これらの手法を容易に実装できるソフトウェアがありません。

現時点では、我々はサプライチェーンマネージャに対して、過去のサービスレベルの性能(目標を達成したのか)を注意深く検証することをお勧めします。これを行うためには、過去の予測結果と実績値の両方が必要となります。従来型のデータベース基盤におけるデータ保存にはコストがかかるため、多くの企業では過去の予測結果や予測に用いたデータを保存していません。しかし、Databricksによって提供される、クラウドベースの高性能ストレージ、オンデマンドで利用できる計算資源によってアクセス可能な圧縮データフォーマットにより、多くの企業にとってコスト効果が高く、高性能な検索が可能となります。

多くのBOPIS(Buy Online Pickup In-Store)モデルで必要となる自動化された補充システムを配備し、注文を充足するためのリアルタイムデータを生成することで、企業はこのデータを使って、店舗内在庫とサービスレベルを再評価する必要性を示す在庫切れ問題を検知したいと思い始めます。これらの分析を日次でしか処理できない製造業者は、シフトに応じた調整を行いたいのかもしれません。Databricksのストリーミング機能によって、ニアリルタイムで安全在庫分析を実施できるようになります。

最後になりますが、在庫計画プロセスへのより良いインプットを生成するための新たな手法を探索すべきだということをご説明します。FacebookのProphetとDatabricksのような並列処理基盤を組み合わせることで、タイムリーかつ高精度な予測が実現できます。GARCH(Generalized Autoregressive Conditional Heteroskedastic)のような他の予測モデルを活用することで、安全在庫戦略において非常に有益な需要の変化を検証できるようになります。

安全在庫の課題への取り組みは、この方向に進もうとしている企業にとって非常に有益なものとなります。この旅路の最終的なゴールは現時点では定義されていませんが、柔軟性が成功の鍵となります。我々はDatabricksがこの旅路において、唯一のドライバーになると信じており、ご一緒できることを楽しみにしています。

Databricksは、この重要なトピックに対して示唆を提供してくれたMethodist University Cox School of BusinessのSreekumar Bhaskaran教授に感謝の意を表します。

2
8
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
8

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?