2023/11/20 公開
Eコマースの管理システムとして、これまで販売を行うカート・モールに加えて、OMS(一元管理システム)やWMS(倉庫管理システム)が利用されてきました。
これらのシステムは、管理する在庫の種類や目的が異なっています。
販売可能在庫をリアルタイムに管理するカート・モールやOMSに対して、WMSは倉庫内のリアルの在庫数(実在庫数)を管理するものです。
一方、新たにデータドリブンで商品戦略・販売戦略を立案するというより高度なニーズが大手小売りを中心に発生しています。
それに対応したシステムがEOS(分析・発注システム)です。
その場合、高度な在庫分析機能が求められ、在庫日数というこれまでなかった概念での在庫管理手法が生まれています。
システム | 管理在庫 | 在庫更新頻度 | 管理目的 | 説明 |
---|---|---|---|---|
カート・モール | 販売可能在庫数 | リアルタイム減数 | 買い物かご制御(売越し防止) | 現在、販売可能な在庫数 |
OMS | 販売可能在庫数 | リアルタイム減数 | 買い物かご制御(売越し防止) | 現在、販売可能な在庫数 |
WMS | リアル在庫数 | 数回/日 | 実在庫の管理(在庫精度維持) | 倉庫の現物在庫数 |
EOS | 在庫日数 | 1回/日 | 欠品、過剰在庫の防止 | 在庫が何日分あるか |
ほとんどのECショップがOMSを利用し始めています。OMSの主要機能の1つに販売在庫共有があります。
この機能は、2つの用途があります。
(1)ひとつのショップで販売された場合のストア販売可能在庫への自動共有(在庫ー)
(2)倉庫への入荷、返品、在庫調整のストア販売可能在庫への自動共有(在庫±)
ストアの販売可能在庫のデータ書き換えの際にリアルタイムに書き換えは不可能で、5分~10程度タイムラグが発生します。
販売可能在庫が「1」の場合、本来は「0」に書き換えらるのですが、タイムラグ期間中に販売がなされた場合、売り越しとなって、出荷ができない問題が発生します。
追加に在庫の補充ができない商品の場合、大きなクレームに発生する場合がありますので、そのような場合、安全在庫数の加算をすることで問題は解決します。
もう一つの問題として、倉庫側で在庫が見つからず、マイナスに在庫調整した場合があります。
この場合、速やかにWMSからOMSへ在庫調整値を反映させないと売り越しを発生する原因となります。
いずれにしても本件は、イレギュラー的な細かい問題であると言えます。
この問題は、まさに経営上の問題と定義できます。
よって、ECの在庫管理とは、欠品と過剰在庫をいかに防ぐかというのが、その目的と言えるでしょう。
本来の在庫管理は、欠品と過剰在庫を防ぐための管理手法ですが、ほとんどのECショップ運営者は、そのノウハウを持っていません。
一部のOMSに発注点の設定ができるものがありますが、あまり役に立つものではありません。
なぜなら、発注点の理解が不十分だからです。
OMSの発注点は、以下のように単純なものです。
在庫数が発注点を下回ったら、アラートを出します。
実は、この手法では、チラシや資材など補充型の単純な商品にしか利用できないのです。
SKU | 在庫数 | 発注点設定 | |
---|---|---|---|
A001 | 100 | 10 | |
A002 | 9 | 10 | !アラート |
EOSの発注点は、OMSとはまったく違う概念です。
グラフの縦軸は、在庫数でなく在庫日数となります。
例えば、AとBという2種類の商品があり、両方とも本日の在庫が100個あるとします。
Aは、1日10個売れますが、Bは、1日100個売れます。
Aは、10日分の在庫があり、Bは、1日分の在庫となります。Bは翌日には欠品となってしまいますね。
したがって、在庫数という値で、在庫を見てもほとんど意味がないということです。
在庫日数での管理が必要ということが分ります。 したがって、本来の在庫管理とは、在庫日数で在庫を管理するということだと思います。
簡単にいうと何日分の在庫を現在所有しているかという計算となります。
在庫日数が「1日」とは、1日分の在庫、在庫日数が「365日」とは、1年分の在庫数ということです。
売れ行きのいい商品(Aランク)は、1日の需要予測数が大きく、売れ行きの悪い商品(Dランク)は、1日の需要予測数が0に近い値となります。
したがって、在庫数の値が大きい、小さいは、在庫管理上ほとんど意味がないことが分ります。
それでは、1日の需要予測数は、どのように計算したらいいのでしょうか?
こちらは、第3回講座「EC在庫の需要予測の基礎」で解説していきます。