SKU爆発とシーズン消化率、値下げロスを「色・サイズ」の粒度で押さえる
品番×色×サイズでSKUが2万を超えると、消化率の一覧は数千行になる。誰も見きれない。結果として品番単位の粗い判断に戻る。店間移動と値下げの判断を、色サイズの粒度で回す。
業界に共通する課題
色・サイズ粒度で追えない
品番単位では消化率が良く見えても、実際は特定の色・サイズだけが売れ残っている。SKU数が多すぎて手集計では追跡できない。
店間移動の判断が遅い
「A店で欠品、B店で滞留」が起きても発見が週次の棚卸後。移動指示を出す頃にはシーズンが終わっている。
値下げロスが見えない
プロパー消化率と値下げ後の粗利が分離管理で、「いつ・いくら下げるのが最適だったか」を振り返れない。
モデル企業の前提
会社・売上・拠点数は、すべて架空の数字です。
データはどこで切れているか
システムは揃っていますが、データが分断されている状況です。
- 販売管理（卸・直営）
- 店舗POS（60店）
- 自社EC＋モール
- MDのシーズン計画Excel
- 委託3PLのWMS
- 店舗在庫（POS内）
- 返品・戻り品の処理
症状：店舗在庫はPOSのJANコード、EC受注はカートの商品管理番号、倉庫在庫はWMSのSKUコードで管理され、色とサイズの持ち方も系統ごとに異なる。品番までは突き合わせられるが、色サイズまで揃えた在庫と販売の対応表がない。このため消化率は品番単位でしか出せず、色サイズ別の偏りは棚卸のたびに現場が個別に気づく状態になっている。
W3 Data Platform 適用シナリオ（想定）
つなぐ → 揃える → 使う の3ステップ。既存システムは入れ替えません。
つなぐ
販売管理・店舗POS・EC・委託3PLのWMSを接続し、品番×色×サイズの粒度のまま収集。SKU数が多くても列指向ストレージで高速に扱えます。
揃える
品番・カラーコード・サイズコードを統一し、投入数・販売数・在庫・値下げ履歴を1本の時系列に。プロパー消化と値下げ後粗利を分けて保持します。
使う
色サイズ別消化率のヒートマップ、店間移動提案、値下げタイミングの最適化提案。移動指示は承認後にWMS・店舗へ書き戻されます。
粒度を細かくすると、見る量が増えます。ここが従来の限界でした。人が見きれない粒度をAIが常時監視し、見るべき例外だけを上げてくるため、粒度を上げても担当者の負荷は増えません。SKU数が多いほど効果が出る領域です。
AIとのやりとり
MCP接続により、AIが統合データを直接参照します。SQLの記述もBIツールの操作も不要で、会話で引き出せます。
JAN、商品管理番号、品番を名寄せし、色とサイズの粒度まで揃えて消化率を算出しました。投入後6週の低消化順です。
| 品番 | 色/サイズ | 投入数 | 消化率 | 滞留店舗 |
|---|---|---|---|---|
| 24SS-BL03 | ベージュ/S | 480 | 22% | 銀座・梅田ほか6店 |
| 24SS-BL03 | ネイビー/M | 520 | 78% | —（3店で欠品） |
| 24SS-PT11 | ブラック/L | 360 | 41% | 名古屋ほか2店 |
24SS-BL03 は色サイズで両極化しています。ベージュ/Sは6店で滞留（消化22%）、一方ネイビー/Mは3店で欠品。① まずネイビー/Mの店間移動（想定 機会損失▲86万円の回避）、② ベージュ/Sは4週後の一斉値下げより「今、EC単独で15%オフ」の方が想定粗利が+34万円高い、と算出しました。承認すれば移動指示をWMSへ、価格変更をEC・POSへ連携します。
※ 画面・数値はイメージです。実際の項目・粒度は接続するシステムとデータ内容により異なります。
揃えたあとのデータの並び
各データの列名・粒度・書式を同じ定義に揃えます。拠点ごとのExcelも、同じ表の中に入ります。
mart.sku_sellthrough- 品番
style_cd - カラーコード
color_cd - サイズコード
size_cd - 販売チャネル
channel - 投入数
intake - 販売数
sold - 消化率
sellthrough - 値下げ率
markdown_rate - 対象週
week
JAN・商品管理番号・品番を名寄せし、色サイズ粒度の消化率を週次で保持。プロパー消化と値下げ後粗利を分けて持つため、値下げ判断の振り返りができます。
誰が、いつ、何に使うか
定型の集計とアラートは自動で届くため、担当者がダッシュボードを開く必要がありません。
- 朝 9:00MD
「今週見るべき低消化SKUと欠品SKU」だけがAIから届く（数千行を見る必要がない）。
- 昼 13:00エリアマネージャ
担当店舗の色サイズ別在庫バランスを照会。店間移動の依頼をその場で起案。
- 夕 17:00物流部
店間移動・EC向け出荷の優先度変更を承認。WMSへ書き戻され翌日出荷される。
- シーズン末経営
プロパー消化率と値下げロスを分離して振り返り、次シーズンの投入計画に反映できる。
想定効果（仮定に基づく試算イメージ）
記載の数値は代表値・想定値です。実環境（データ量・システム構成・ネットワーク）により変動する可能性があります。費用は対象システムの仕様確認が必要なため、個別にお見積りいたします。
3つの使い方のうち、どれを使うか
3つは排他ではありません。Cだけで始めて、あとからBへ広げることもできます。
W3 WMS × AI照会併用
弊社WMS（W3 sirius / W3 mimosa）のデータをデータレイクに取り込み、MCP経由でAIが直接参照します。SQLの記述もBIツールの操作教育も要りません。聞けば返ってきます。
データレイク蓄積（データ基盤 格納型）このモデルケースの主軸
他社システムのデータ連携サーバー、基幹DB、ECカートなどをCDC（変更差分取得）で接続し、毎日流れてくるデータをraw／mart 2層に溜め込みます。既存システムは無改修です。溜まったデータを、自然言語の指示で分析・加工できる状態にします。
ETL単体（システム直接連携）
データレイクを作らないまま、「抽出→変換→格納」だけのシステム間インターフェースとして使えます。個別IF開発をノーコードのGUI設定に置き換えることで、IF開発費が従来比 1/3〜1/2 になります。ここから始めて、あとからBへ広げることもできます。
本ページは架空のモデルケースです。記載の企業は実在せず、数値・効果は仮定に基づく試算イメージであり、実際の導入実績ではありません。効果は対象業務・データ規模・システム構成により変動します。
記載の数値は代表値・想定値です。実環境（データ量・システム構成・ネットワーク）により変動する可能性があります。費用は対象システムの仕様確認が必要なため、個別にお見積りいたします。