ARTICLE SUMMARY
多店舗ECの在庫管理は、商品IDを正しく定義することから始まります。
商品IDは、在庫管理だけでなく、販売数集計、受注処理、SKU管理、発注判断、再出品、セット商品、モールごとの対応関係をつなぐキーです。弊社では、どのモールでどのIDが売れても、最後は本IDへ集約します。
INVENTORY ISSUES
多店舗ECで在庫管理が難しくなる理由
商品数が少ないうちは目視でも管理できます。しかし、商品が1,000種類あり、それぞれに10SKUある場合は合計10,000SKUです。この規模では、人の記憶やモール管理画面だけで管理することは難しくなります。
- 各モールの在庫数と販売状態を把握する
- 欠品時の販売停止と入荷後の再開を管理する
- 会社全体の実在庫を一か所で確認する
- 複数モールの販売数を発注判断へつなげる
PRODUCT ID MAPPING
モールごとに商品IDが違うと、販売数と在庫を集計できません
同じ商品でも、販売者が設定した社内ID、モールが自動生成したID、再出品後の新しいIDなど、複数のIDが存在する場合があります。この対応関係が分からないと、販売数、在庫数、発注判断が分かれてしまいます。
| 状況 | ID例 | 必要な管理 |
|---|---|---|
| 社内の基本商品 | a001 | 実在庫、販売数、発注判断の基準にする |
| モールの自動生成ID | XBeefacf685t | a001と同じ商品として対応付ける |
| 再出品後のID | aa001 | 元のa001へ販売数を集約する |
ID STRUCTURE
弊社の解決方法：本ID・仮想ID・親ID・子IDで管理する
| IDの種類 | 役割 | 例 |
|---|---|---|
| 本ID | 実際の商品在庫を持ち、販売数と発注判断の基準になる | a001 |
| 仮想ID | モールID、再出品ID、セット商品IDを本IDへ変換する | XBeefacf685t、aa001 |
| 親ID | 商品本体を表す | a001 |
| 子ID | 色、サイズ、タイプなどのSKU属性を表す | a001-red、a001-blue |
現場でも分かりやすい商品IDの命名
親IDは、できるだけ8文字以内の小文字英字と3〜4桁の数字で定義し、英字部分に商品カテゴリなどの意味を持たせます。子IDは「親ID-SKU属性」の形にし、ピッキング、在庫確認、お問い合わせ対応でも分かりやすくします。
VIRTUAL ID & BUNDLES
セット商品は仮想IDとして、実在庫へ分解します
セット商品は新しい在庫を持つ商品ではありません。セットが売れた場合、構成する本ID・SKUの実在庫を正しく減らす必要があります。
ACTUAL STOCK
モール側の在庫は「販売できるか・できないか」で管理する
弊社では、各モールの在庫数を実在庫として細かく合わせ続けるのではなく、販売できる場合は999などの大きな数、販売を止める場合は0として管理します。実在庫は社内システムで一元管理します。
- 本ID・SKUごとの実在庫数
- 複数モールの販売数
- セット商品の構成数
- 発注が必要な商品と入荷予定
DELIST & RELIST
欠品時の販売停止を記録し、入荷後の再開忘れを防ぐ
欠品しそうな商品を販売停止するだけでは、入荷後に再開を忘れる可能性があります。弊社では、在庫を0にする前に対象モール、商品ID、SKU、変更日時、変更時点の在庫数、停止理由を記録します。
販売数、在庫数、入荷予定を使った発注予測が合えば、欠品による販売停止と再開作業自体も減ります。弊社の在庫変更作業は、月におおよそ3〜4回程度です。
SUITABILITY
この商品ID・在庫管理方法が向いている事業者
重要なのは、最初から大きな仕組みにすることではなく、現在の販売規模とSKU数に合った管理方法を選ぶことです。
CONSULTATION
多店舗ECの商品ID・在庫管理を見直しませんか？
モールごとに異なる商品ID、SKU、セット商品、販売停止・再開、発注判断など、現在の運用に合わせた管理方法をご提案します。
お問い合わせ方法を見る