店舗・EC・卸の在庫を別々に管理すると何が起きる？
―「売り越し」と「機会損失」、どちらを防ぐ？
アパレル企業では、一つの商品を複数の販売チャネルで販売することがあります。
例えば、
店舗・EC・卸
です。
店舗ではスマレジなどのPOS、ECではShopifyなどのECサイト、卸では販売管理システム。
販売チャネルによって、使用しているシステムが違うことも珍しくありません。
そこで問題になるのが、
「在庫をどこで管理するのか？」
ということです。
店舗・EC・卸で在庫をきっちり分ける方法もあれば、すべての在庫を共有して販売する方法もあります。
一見すると、全部まとめて管理した方が効率的に思えます。
しかし実際には、どちらにもメリットとデメリットがあります。
今回は、複数の販売チャネルで商品を販売するときの在庫管理について考えてみます。
ECや店舗で売れても、本部の在庫がすぐ減るとは限らない
例えばECで商品が1枚売れたとします。
ECサイトでは販売済みです。
しかし、その売上情報がリアルタイムに販売管理システムへ連携されていなければ、販売管理システム上ではまだ在庫が残っています。
店舗のPOSでも同じことがあります。
つまり、一時的に、
EC・POS：販売済み
販売管理システム：在庫あり
という状態が発生します。
このわずかな時間差が、複数チャネルで同じ商品を販売するときには問題になることがあります。
「在庫あり」だったのに、商品がない
例えば、販売管理システム上では在庫が1枚あるとします。
営業担当者がそれを確認して、卸のお客様から注文を受けました。
ところが実際には、その商品が少し前にECや店舗ですでに売れていた。
ECやPOSの売上情報が、まだ販売管理システムへ届いていなかったのです。
結果として、
「受注したのに商品がない」
という売り越しが発生します。
複数のシステムで同じ商品を販売する場合、単に「在庫を共有すればいい」というだけでは解決できない問題です。
ECでは、あえて正確な在庫数を見せないこともある
こうした売り越しを防ぐため、ECサイトでは実際の在庫数をそのまま表示しないことがあります。
例えば、
○ 在庫あり
△ 残りわずか
× 在庫なし
といった表示です。
「残り3枚」と正確に表示するのではなく、あえて曖昧にすることで、実在庫との差を吸収するための**バッファ（余裕）**を持たせます。
これも、複数の販売チャネルを持つ企業が在庫差異に対応するための一つの方法です。
では、在庫を店舗・EC・卸で分ければいい？
売り越しをできるだけ防ぎたいのであれば、一つの方法があります。
店舗・EC・卸で在庫場所をきっちり分けることです。
例えば100枚の商品を、
店舗：40枚
EC：30枚
卸：30枚
のように割り当てます。
ECではEC用の30枚しか販売しない。
店舗では店舗用の40枚しか販売しない。
こうすれば、同じ1枚をECと卸の両方で販売してしまうリスクを抑えられます。
ところが、別の問題が出てきます。
「在庫はあるのに売れない」という機会損失
例えばECで商品が非常によく売れて、EC用の30枚がすべてなくなったとします。
ECサイトでは、
「在庫なし」
になります。
ところが、店舗を見ると同じ商品が10枚残っている。
会社全体では在庫があるのに、ECでは販売できません。
これは非常にもったいない状態です。
ECでは今まさに売れている。
でもEC用の在庫がない。
一方、店舗では商品が残っている。
そこで、
店舗 → EC
へ在庫を移動すれば、販売を続けられます。
理屈としては簡単です。
しかし、実際にこれを人が行うのは簡単ではありません。
100品番だけでも、カラー・サイズまで見ると膨大になる
例えば商品が100品番あったとします。
しかしアパレルでは、品番だけを見ればいいわけではありません。
前回の記事でも書いたように、
品番 × カラー × サイズ
で在庫を管理します。
この在庫管理の最小単位をSKUと呼びます。
100品番でも、カラーとサイズを組み合わせれば、監視しなければならないSKUは何百、何千という数になります。
それぞれについて、
「ECで急に売れ始めた」
「この店舗では売れていない」
「卸から大量注文が入った」
「店舗Aには余っている」
といった状況を人が毎日確認して、最適な在庫配置を判断する。
これはかなり大変です。
では、全部の在庫を共有すればいい？
もう一つの方法は、
店舗・EC・卸の在庫をひとまとめにして販売する
ことです。
特定のチャネル専用として在庫を固定せず、会社全体の在庫として販売します。
こうすれば、
「EC用の在庫は0枚だけど、店舗には10枚ある」
という理由だけで販売機会を逃すことを減らせます。
一方で、別の作業が発生します。
例えばECで売れた商品が、実際には店舗側の在庫だった場合です。
売上を先に計上して、その後、
店舗 → EC
など、売れた在庫場所へ在庫を移動して帳尻を合わせる運用が必要になることがあります。
つまり、
在庫を分ければ、売り越しは防ぎやすいが機会損失が起きる。
在庫を共有すれば、販売機会を増やせるが在庫移動などの管理が増える。
どちらが正解とは一概に言えません。
会社によって「何を優先するか」が違う
在庫管理の仕組みを考えるとき、
「一元管理すれば解決する」
という単純な話ではありません。
企業によって、何に重きを置くのかが違うからです。
絶対に売り越しを起こしたくない企業もあります。
一方で、
「多少管理の手間が増えても、売れる場所に商品を集めて販売機会を逃したくない」
という企業もあります。
大切なのは、自社がどちらを優先するのかを決め、それに合わせて在庫管理の仕組みを作ることだと思います。
そして、これまでは人が判断してきた
どちらの運用を選んでも、最後に残る問題があります。
人が商品の動きを見て判断しなければならないことです。
担当者が、
「この商品、最近ECでよく売れているな」
「店舗Aでは全然動いていない」
「だったら店舗AからECへ5枚移そう」
と判断します。
経験のある担当者ならできるかもしれません。
しかし、SKUが何百、何千と増えれば、すべての商品を人が監視することには限界があります。
ここは、今後AIが活躍できる領域ではないかと考えています。
AIが売れ行きを監視したらどうなる？
例えばAIが、店舗・EC・卸の販売実績と在庫を監視します。
そして、
「店舗Aで黒・Mサイズの販売が増えています。このままでは3日以内に在庫切れになる可能性があります。」
と知らせる。
さらに、
「卸在庫に黒・Mが20枚あります。直近の受注状況を考慮すると、5枚を店舗Aへ移動しても卸の販売には影響が少ないと考えられます。」
といった在庫配分まで提案する。
担当者はその内容を確認して、
「店舗Aへ5枚移動する」
という判断をします。
しかし、ここで終わりではありません。
システム上の在庫を動かすだけでは、商品は動かない
実際の商品が卸用の倉庫にあるなら、システム上で在庫場所を変更しただけでは店舗には届きません。
現物を動かすためには、
AIが在庫移動を提案
↓
担当者が承認
↓
倉庫へ出荷指示
↓
倉庫で対象商品をピッキング
↓
店舗向けに梱包・出荷
↓
店舗へ商品が到着
↓
店舗在庫として反映
という物流まで動かす必要があります。
つまり必要なのは、単なる**「在庫移動ボタン」**ではありません。
AIの提案を、実際の商品移動までつなげる仕組みです。
「在庫を見るAI」から「仕事を動かすAI」へ
ここが、これからのAI活用で重要になると考えています。
AIが、
「この商品を店舗Aへ5枚移した方がいいです」
と教えてくれるだけでも便利です。
しかし、その後、人が販売管理システムを開いて移動入力し、倉庫へ連絡し、出荷指示を作成しているのであれば、まだ多くの作業が残っています。
理想は、
① AIが売れ行きと在庫を監視する
↓
② 在庫切れや滞留在庫を予測する
↓
③ 最適な在庫配置を提案する
↓
④ 人が内容を確認して承認する
↓
⑤ 販売管理システムが倉庫へ出荷指示を出す
↓
⑥ 倉庫がピッキング・出荷する
↓
⑦ 商品到着後、店舗在庫へ反映する
ところまで、一つの流れとしてつなげることです。
AIが判断を支援するだけでなく、承認された判断を実際の業務処理へつなげる。
そうなって初めて、
「在庫を見るAI」から「仕事を動かすAI」
になっていくのだと思います。
AIだけでは完結しないからこそ、販売管理システムとの連携が重要
商品はデータではありません。
最終的には、人が倉庫から商品を取り出し、梱包して、トラックなどで店舗へ運ばなければなりません。
だからこそ、
AIだけ導入すれば解決するわけではありません。
AIが判断・提案する部分と、
受注・在庫・出荷指示・ピッキング・出荷・入荷
といった販売管理・物流の仕組みをつなげる必要があります。
AIが、
「何をすべきか」を見つける。
人が、
「実行してよいか」を判断する。
販売管理システムが、
「実際の業務を動かす」。
この3つをつなげることが、これからの業務システムでは重要になってくると考えています。
次回は、
「20年前の販売管理システムを使い続けるリスク」
について取り上げたいと思います。