需要予測から自動発注へ – Amazon Forecast による自動化された機械学習で在庫切れ、過剰在庫、コストを削減

このブログは、More Retail 社の Supratim Banerjee 、Ganit Inc 社のShivaprasad　KT と Gaurav H Kankaria のコラボレーションによるゲスト投稿です。

More Retail 社（MRL）は、インドの食料品トップ4の1つで数十億ドルの売上を誇る小売業者です。インド全土に22の大型スーパーマーケットと624のスーパーマーケットからなる店舗ネットワークを持ち、それを13の流通センター、7つの果物野菜の収集センター、6つの食品加工センターのサプライチェーンで支えています。

大規模な店舗ネットワークにおいては、適切な品質の商品を適切な価格で消費者に提供するにはもちろんのこと、消費者の需要に応えつつ在庫運用コストを最小限に抑えることもまた重要です。MRL 社は AI アナリティクス領域のパートナーである Ganit 社と協業し、より正確な需要予測とそれを自動発注に繋げるシステムを構築しました。これによりオペレーションのボトルネックを解消し、これまで各店長がマニュアルで発注の判断を行っていたことによる発注の不備を克服できるようになったのです。 Amazon Forecast を使用することで予測精度は 24％ から 76％ に向上し、生鮮食品カテゴリでの無駄を最大 30％ 削減、在庫率を 80％ から 90％ に、そして粗利益を 25％ に改善することに成功しました。

自動発注システムの構築とそれによる業績の達成が成功した理由は2つあります：

• 実験する能力 – Forecast は柔軟なモジュール形式のプラットフォームを提供しており、古くからのモデルと ML モデル両方を含むさまざまなタイプの予測器を使用して 200 以上の実験行うことができます。チームはカイゼンのアプローチに従い、失敗したモデルからでも学びを得て、成功した場合にはそのモデルをデプロイしました。成功したモデルがデプロイされてからも実験は並行して継続されました。
• 変更管理 – これまで自身の判断で発注を行っていたカテゴリオーナーに対し ML ベースの注文システムを信頼してもらうよう説得しました。適用計画は体系的に計画されており、ツールによる発注結果を確実に保存し、統制のとれたサイクルでオペレーションが行われました。結果、補充済みの在庫と現在庫がオンタイムに特定、記録されました。

生鮮品を予測することの複雑さ

消費期限の短い、生鮮カテゴリーの商品需要を予測することは難しいことです。過大予測をしてしまった場合、店舗が古くなった商品や熟しすぎた商品を販売したり、在庫を廃棄することに繋がってしまいます（在庫圧縮と呼ばれます）。一方で過小予測をしてしまうと、商品が在庫切れとなる可能性があり、これは顧客体験に影響を及ぼします。買い物リストにある商品のうち「これがないと困る」というキーアイテムがなかった場合、顧客が買い物をやめてしまうこともあります。本当に必要なものがないのにわざわざレジ待ちの列に並びたくないからです。MRL 社の 600 を超えるスーパーマーケットで扱う SKU の数は多く、店舗と SKU の組み合わせは 6,000 を超えています。

2019年末まで MRL 社では従来型の統計手法を使用して店舗と SKU の組み合わせごとに予測モデルを作成していましたが、その予測精度は低く 40% でした。予測に複数のモデルが必要だったため、予測計算のコストも、運用上のコストも高くつくものになってしまっていました。

発注のための需要予測

MRL 社と Ganit 社は協力して、2020年前半、果物と野菜（F&V）と呼ばれる生鮮品カテゴリ商品の予測精度を向上させ、在庫破棄を減らすことに成功しました。

Ganit 社は、問題を 2 つの部分に分割するよう MRL 社にアドバイスしました：

• 店舗- SKU の組み合わせごとの需要予測
• 注文数量の計算（発注書）

以降のセクションで、それぞれの問題にどう対処したのか詳しく説明します。

需要予測

まず店舗- SKU の組み合わせそれぞれに対して需要予測を行うステップについて説明していきます。

需要のドライバーを知る

Ganit 社チームは、店舗需要に影響する因子を理解するところから取り組みを始めました。何度も店舗に出向いてカテゴリーマネージャーと話し合い、スーパーマーケットの CEO との定例会議では、季節変動、欠品、社会経済的因子、マクロ経済因子などについて、 Ganit 社自身の持つ予測に関する専門知識を持って検討しました。

F&V 商品需要への影響を解き明かすために、複数の因子からなる約 80 の仮説が立てられました。チームは、相関、二変量および単変量分析、統計的有意性検定（Studen’s t-test、Z test）などの手法を使用して包括的な仮説検証を行い、フェスティバルの開催日や天気、プロモーション他関連因子と需要との関係を確立しました。

データのセグメント化

次にチームは、店舗-SKU 組み合わせを毎日正確に予測できる詳細なモデルの開発に取り掛かりました。売上貢献と予測の容易さを、ABC-XYZ フレームワークとして整理しました。ABC は売上貢献（A が最高）を示し、XYZ は予測の容易さ（Z が最低）を示します。売上への貢献度が高く、予測が最も困難、と判断された店舗-SKU の組み合わせからモデル構築を始めることにしました。この領域の予測精度を向上できれば、ビジネスに最も大きく影響を与えることができるからです。

データ処理

MRL 社のトランザクションデータは従来の POS データの構成で、携帯電話番号、請求書番号、商品コード、店舗コード、日付、請求額、実価格、割引額などのフィールドが含まれています。チームは、過去 2 年間の日々のトランザクションデータを利用してモデルを構築しました。過去データの分析から、以下 2 つの難しいポイントが明らかになりました：

• 欠損値が大量にある
• 請求額が非常に大きいまたは、小さい日があり、データの中で外れ値として存在している

欠損値への対応

データの欠落している日を詳細に調査したところ、店舗に在庫がない（供給がなかった、シーズン外だった）、あるいは祝日や外部制約（地域または国全体で休業、建設工事など）のために店舗が閉鎖されていたために欠損値が発生していたことが明らかになった。欠落している値は 0 に置き換えられ、適切な予測器またはフラグをモデルに追加することで、モデルが将来の同様のイベントについて学習できるようにしました。

外れ値への対応

チームは、外れ値についても請求レベルで詳細に精査し、これにより、在庫処分、一括購入（B2B）、品質劣化などの要素が確認されました。たとえば、請求書レベルで次のグラフのような、日単位での店舗-SKU 組み合わせの KPI が見られるものがありました。

次に、異常に販売数が多かった日付には外れ値としてフラグを付け、特定された外れ値を詳しく調べます。分析を進めていくと、これらの外れ値が企業による事前予約による購入であることがわかってきました。

このような請求書レベルの外れ値は、一日の最大販売数量に制限をかけることで対処できます。次のグラフでは、この制限によって請求レベルの需要データがどのようになるかを示しています。

予測プロセス

チームは、Forecast を選択する前に、時系列モデル、回帰ベースのモデル、深層学習モデルなどの複数の予測手法をテストしました。 Forecast を選択した主な理由は、XY バケットと Z バケットの予測精度を比較したときのパフォーマンスの違いでした。これは予測が最も困難だったものです。ほとんどの従来の手法は XY バケットでより高い精度を提供しましたが、Forecast の ML アルゴリズムのみが、他のモデルと比較して 10％ 高い精度になったのです。これは Forecast が他の SKU （XY）パターンを学習し、それらの学習を Z バケット内の非常に変動性の高いアイテムに適用できるためです。 AutoML により Forecast DeepAR+ アルゴリズムを予測モデルとして選択することになりました。

Deep AR+ を最良のアルゴリズムとして特定した後、さらに精度向上をはかるために追加機能を使用していくつかの実験を行いました。純粋なターゲット時系列データ（外れ値処理ありとなし）、フェスティバルや閉店などの予測器、店舗-アイテムのメタデータ（店舗-アイテム階層）などのより小さなサンプルセット用いて反復を複数回実行し、精度向上のための最良の組み合わせを探りました。店舗-アイテムのメタデータで外れ値処理をしたターゲット時系列データと予測器の組み合わせが最高の精度になることがわかりました。これを 6,230 の店舗-SKU のオリジナルの組み合わせに適用し、最終的な予測を算出しました。

発注数計算

予測モデルの開発に続き、このモデルを使用して発注数量を決定するステップに進みました。発注数量は、予測された需要と現在庫、その他関連する因子により影響を受けます。

発注構成を設計するために、次の式を確立しました。

最小発注数量、サービス単位係数、期末在庫、（棚割りに基づく）最小陳列在庫、補填率調整など、自動発注システムの発注数調整パラメーターを検討し、システムと人間の有するインテリジェンスとの間のギャップを埋めていきました。

過小見積もりと過大見積もりの調整

在庫切れ、売上損失のコストとともに在庫圧縮コストを最適化するため、チームは Forecast の分位数を利用して予測値を調整しました。

モデルの設計では、p40、p50、および p60 の3つの分位数で予測を行い、p50 を基本分位数としました。分位数は、店舗での直近の在庫切れと余剰在庫の状況に基づいて選択するようプログラムされました。たとえば、特定の店舗-SKU の組み合わせにおいて、過去 3 日間に継続的に在庫切れが発生している場合には、より高い分位数が自動的に選択されます。一方、店舗-SKU の余剰在庫が多い場合には、より低い分位数が自動的に選択されます。分位数の増減幅は、その店舗での在庫切れまたは余剰在庫による廃棄の大きさに基づいて決定されます。

Oracle ERP による自動発注

MRL 社は発注に OracleのERP を使っており、これに Forecast を統合しました。次の図に、最終的なアーキテクチャを示します。

自動発注の仕組みを本番環境にデプロイするにあたって、MRL 社の全データが AWS に移行されることになりました。ETL ジョブによりライブテーブルを Amazon Redshift （ビジネスインテリジェンス向けデータウェアハウス）に移行し、以降は Amazon Redshift がすべてのデータ処理のための単一の入力ソースとなりました。

データアーキテクチャ全体は次の2つの部分に分かれています：

• 予測エンジン：
  • 使用される時系列需要データ（1日の需要遅れ）は Redshift に保存
  • 最終購入日、価格、フェスティバルのような説明変数も Redshift で保守
  • Amazon Elastic Compute Cloud (Amazon EC2) インスタンスに、トランザクション、リグレッサー、およびその他のメタデータを加工整形するためのカスタム Python スクリプトをセットアップ
  • データラングリング後のデータは Amazon Simple Storage Service (Amazon S3) バケットに移動され、予測に利用（全ての店舗-SKU の組み合わせに対する2日先の予測）
  • 最終的な予測結果は、S3 バケットの別のフォルダーに保存
• 発注（インデント）エンジン：
  • 予測から注文を導出するために必要なすべてのデータ（現在庫、店舗の受領数、直近 2 日間の発注数、サービスユニット因子、棚割りの最小開始および終了在庫など）は Redshift に保存
  • 発注数量は、EC2 インスタンス上で実行される Python スクリプトで計算
  • 発注情報は Oracle ERP に連携され、ベンダーに発注

発注システムは複数のセグメントを疎結合で繋いで構成されています。プロセスごとに Apache Airflowスケジューラーを利用し、電子メール通知を設定して処理が正常終了または失敗したときにそれぞれ関係者に通知し、すぐに対応できるようにしました。ERP システムを介して行われた発注情報は、翌日の注文数を計算するために Redshift テーブルにフィードバックされます。 AWS システムと ERP システムの統合は容易であり、人の介入の不要な、完全なエンドツーエンドの自動発注システムを実現することができました。

まとめ

MRL  社では機械学習ベースのアプローチにより、データの真の力が解き放たれました。 これまで 1,000 以上の従来型のモデルを利用していたものが、Forecast によって、店舗フォーマット別の 2 つの共通モデルとなりました。

Forecast は、時系列全体での学習も行います。 Forecast 内の ML アルゴリズムにより、 店舗-SKU 組み合わせ間の相互学習が可能になり、予測の精度が向上しました。