前回の記事で「多店舗展開をするなら在庫の一元管理ツールは必須」と書きました。今回はその続きとして、実際にどう運用しているかを具体的に書きます。
弊社はGoQSystemを使い、Amazon・楽天市場・メルカリShopsの3モールの在庫を一元管理しています。自社EC（EC-CUBE）を含めれば4店舗です。
ツールを導入すれば自動で解決する、という話ではありません。設定を間違えれば普通に在庫がズレますし、実際に弊社もキャンセル処理を出しました。その話も含めて書きます。
大原則：在庫の「正」を1か所に決める
一元管理で最初に理解すべきなのは、どこが在庫の正しい値を持っているかという一点です。
弊社の場合、在庫の司令塔はGoQです。GoQが持っている総在庫数が各モールへ配信され、Amazon・楽天・メルカリShopsの管理画面に表示されている数字は、すべてGoQ配信値の写しにすぎません。
この構造を理解していないと、モールの管理画面で在庫を直接いじってしまいます。そして次の配信で上書きされ、「変更したはずなのに戻っている」と混乱することになります。
在庫を変更するときは必ずGoQ側で行う。モール側の在庫数は表示でしかない。この原則を運用ルールとして最初に固めておくべきです。
反映はリアルタイムではない
もう一つ、前提として押さえておくべき点があります。
楽天で商品が売れた瞬間に、Amazonの在庫数が減るわけではありません。実際の流れはこうです。
- 楽天で注文が入る
- 数分〜数十分かけて、GoQが注文を取り込む
- 取り込みのタイミングでGoQ側の在庫が減る
- 減った在庫が各モールへ配信される
つまり、数分〜数十分のタイムラグが必ず存在します。
普段は問題になりません。危ないのは在庫が残り1個のときと、セール等でアクセスが集中しているときです。この数分の間に別モールで注文が入れば、出せない商品を売ったことになります。
一元管理ツールは二重販売のリスクを大幅に下げますが、ゼロにはしません。残り1個の商品については、そういうものだと理解したうえで運用する必要があります。
セット品の在庫は「見せ在庫」である
ここからが本題です。多店舗運営で最も事故が起きやすいのが、セット品の在庫管理です。
セット品の在庫は実在しない
単品Aの物理在庫が10個あるとします。この商品を3個セットにして売る場合、セット品の在庫は「3」と表示されます。
この「3」は、GoQが単品在庫から自動計算した数字です。倉庫にセット品が3つ置いてあるわけではありません。あくまで「単品が10個あるから、3個セットなら3セット作れる」という計算結果です。
弊社ではこれを「見せ在庫」と呼んでいます。実在庫ではなく、見せるために計算された数字という意味です。
構成のパターン
セット構成にはいくつかのパターンがあります。
| 構成 | 内容 | 単品Aが10個ある場合 |
|---|---|---|
| A×3 | 同じ商品を3個 | セット在庫は3 |
| A×1＋B×1 | 異なる商品の組み合わせ | Bの在庫数にも依存 |
| A＝A | 単品と単品（後述） | 在庫を共有 |
A×1＋B×1のような組み合わせセットの場合、在庫はAとBのうち少ないほうに引きずられます。Aが10個あってもBが2個しかなければ、セット在庫は2です。
絶対にやってはいけないこと
発注や在庫確認をするとき、単品在庫とセット品在庫を足し算してはいけません。
先ほどの例で言えば、単品Aが10個、A×3セットが3セット。合計13ではありません。物理在庫は10個のままです。
当たり前に思えますが、CSVでデータを落として集計する場面では簡単に間違えます。弊社では発注判定のロジックで、単品SKUの在庫のみを物理在庫として扱い、セット品・多包装SKUは集計から除外しています。
実際にやらかした話：セット構成の設定漏れ
ここからが失敗談です。
GoQでセット品を扱うには、「このセット品は、単品Aを3個使う」という構成設定を登録する必要があります。この設定をして初めて、GoQは在庫を連動させます。
弊社では、この設定を忘れたセット品がありました。
何が起きたか
構成設定がされていないセット品は、GoQ上で単品とは無関係な独立した在庫を持ちます。単品Aが売れて在庫が減っても、セット品の在庫数は変わりません。逆にセット品が売れても、単品Aの在庫は減りません。
結果として、在庫が合わなくなりました。物理在庫がないのに「在庫あり」で売れてしまい、キャンセル処理をすることになりました。
Amazonではキャンセル率が指標として管理されているため、こうした事故は避けたいところです。楽天でも当然、顧客からの信頼を失います。
もう一つの盲点：単品＝単品の構成設定
これはAmazon特有の事情から生まれる、さらに見落としやすいパターンです。
Amazonでは、同じ商品に対して複数のカタログ（ASIN）が存在することがあります。メーカーが登録したものと、別の出品者が登録したものが並存するようなケースです。
弊社では、こうした複数カタログにそれぞれ出品しています。ここで問題になるのが、GoQから見ると「別々の商品」に見えるという点です。
物理在庫は同じ1つの商品なのに、GoQ上では2つの独立したSKUとして扱われます。設定をしなければ、それぞれが別々に在庫を持ってしまいます。
物理在庫1個の商品が、2つのSKUで「在庫あり」と表示される。当然、両方から注文が入れば片方は出せません。
これを防ぐのが「単品＝単品」のセット構成設定です。片方のSKUを、もう片方の単品在庫を参照する形で登録します。構成上は「単品1個＝単品1個」という一見無意味な設定ですが、これによって在庫が共有されます。
弊社では、この設定を忘れたパターンもありました。セット品の構成漏れよりも気づきにくく、厄介です。
導入時に確認すべきチェックリスト
ここまでの内容を、これから一元管理ツールを導入する方向けにまとめます。
- 在庫の「正」がどこにあるかを運用ルールとして明文化する。モール側の管理画面で在庫をいじらない、を全員に徹底する
- 反映のタイムラグを把握する。リアルタイムではありません。残り1個の商品には注意が必要です
- セット品はすべて構成設定を登録する。登録漏れがないか、導入時に全件チェックしてください
- 同一商品に複数カタログがある場合、単品＝単品の構成設定を入れる。これが最も見落としやすい箇所です
- 発注判断では単品SKUの在庫のみを使う。セット品在庫を足すと二重カウントになります
特にセット品の構成設定は、商品数が増えてから遡って確認するのが大変です。導入時と、新商品を登録するたびに確認する運用にしておくことをおすすめします。
それでも一元管理ツールは必要
失敗談を書いたので不安を煽ったかもしれませんが、結論は変わりません。多店舗運営に一元管理ツールは必須です。
設定ミスによる在庫ズレは、設定を直せば解決します。一方、ツールを入れずに手作業で管理する場合、ミスは構造的に発生し続けます。人間が毎日、複数の管理画面を突き合わせて在庫を合わせるのは不可能です。
導入するかどうかではなく、導入したうえでどう正しく設定するか。そこに労力を割くべきだと考えています。
