「売るデータ」と「届けるデータ」をつなぎ、SKU×チャネル採算を日次化
ECカート、モール、POS、OMS。どれも数字は出る。ただし別々に出る。売上は販売管理、物流費は請求書。「どの商品がどこで儲かるか」に答えられる状態をつくる。
業界に共通する課題
チャネルごとにデータが分断
ECカート・モール・POS・OMSがサイロ化し、在庫と受注の全体像が見えない。モール在庫数の更新は担当者の手作業。
SKU別・チャネル別採算が不明
売上は販売管理、物流費は請求書。粒度が揃わず「どの商品が・どのチャネルで本当に儲かっているか」がどんぶり勘定のまま。
欠品と過剰在庫が同時発生
チャネル間で在庫が偏り、機会損失と値下げ・廃棄ロスが同時に起きる。片方の倉庫で欠品、片方の店舗で滞留。
モデル企業の前提
会社・売上・拠点数は、すべて架空の数字です。
データはどこで切れているか
システムは揃っていますが、データが分断されている状況です。
- 自社ECカート
- モールA／モールB
- POS（直営120店）
- OMS（受注管理）
- 自社DCのWMS
- 委託3PLのWMS
- 配送実績（送り状データ）
症状：売上はチャネル別に取れるが、送料と梱包費は送り状データとWMSの作業実績にあり、返品処理費はさらに別系統にある。商品コードもモール、POS、WMSで体系が異なる。このため売上とコストをSKU単位で同じ行に並べられず、粗利は全社平均の物流費率を掛けて算出している。
W3 Data Platform 適用シナリオ（想定）
つなぐ → 揃える → 使う の3ステップ。既存システムは入れ替えません。
つなぐ
ECカート・POS・OMS・WMSを接続。店舗・EC・倉庫のデータをリアルタイムに収集します。モールごとに違うCSVフォーマットの差はETLで吸収します。
揃える
販売×在庫×物流費をSKU×チャネル粒度で突合できる形に標準化・統合。手数料・配送費込みの「真の粗利」をmart層に保持します。
使う
SKU×チャネル別採算の日次ダッシュボード、欠品予兆アラート、チャネル間の在庫再配分提案。承認すれば移庫指示とモール在庫数の更新まで実行されます。
BIツールもAIも、あとから変えられます。カートやPOSの入替にもデタッチャブルに追従するため、システム構成が固まっていない段階でも着手できます。構成が決まるまで待つ、という判断がいちばん時間を失います。
AIとのやりとり
MCP接続により、AIが統合データを直接参照します。SQLの記述もBIツールの操作も不要で、会話で引き出せます。
モール、POS、WMSの商品コードを名寄せし、手数料と配送費を含めた限界利益をSKU×チャネル単位で算出しました。
| SKU | チャネル | 売上 | 原価＋物流費 | 限界利益率 |
|---|---|---|---|---|
| SKU-0831 | モールA | ¥ 482,000 | ¥ 493,600 | ▲2.4% |
| SKU-1204 | モールA | ¥1,180,000 | ¥1,108,000 | +6.1% |
| SKU-1204 | 自社EC | ¥ 940,000 | ¥ 769,000 | +18.2% |
| SKU-0774 | 直営店 | ¥2,310,000 | ¥1,842,000 | +20.3% |
モールA経由のSKU-0831は配送費負けです。単品購入比率が84%と高く、1件あたり送料が利益を上回っています。① 同梱率改善（セット販売の導線追加）、② モールAでの価格見直し（+180円で黒字転換）を推奨します。あわせて自社EC在庫が3日後に欠品見込みのSKU 12件を検出しました。
※ 画面・数値はイメージです。実際の項目・粒度は接続するシステムとデータ内容により異なります。
揃えたあとのデータの並び
各データの列名・粒度・書式を同じ定義に揃えます。拠点ごとのExcelも、同じ表の中に入ります。
mart.sku_channel_pl- 商品コード
sku - 販売チャネル
channel - 売上金額
sales - 売上原価
cogs - 物流費
logistics_cost - 販売手数料
fee - 粗利率
margin_rate - 対象日
dt
モール・POS・WMSで別々だった商品コードを名寄せし、手数料・配送費込みの「真の粗利」をSKU×チャネル粒度で保持。会議のたびの突合作業がなくなります。
誰が、いつ、何に使うか
定型の集計とアラートは自動で届くため、担当者がダッシュボードを開く必要がありません。
- 朝 8:30EC担当
「昨日の欠品による機会損失と、今日中に振替すべき在庫」をAIが能動通知。モール在庫数の更新案まで添付される。
- 昼 12:00MD（商品部）
「今週値下げ候補のSKUを、物流費込みの限界利益が低い順に」と依頼。会議前に判断材料が揃う。
- 夕 18: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へ広げることもできます。
本ページは架空のモデルケースです。記載の企業は実在せず、数値・効果は仮定に基づく試算イメージであり、実際の導入実績ではありません。効果は対象業務・データ規模・システム構成により変動します。
記載の数値は代表値・想定値です。実環境（データ量・システム構成・ネットワーク）により変動する可能性があります。費用は対象システムの仕様確認が必要なため、個別にお見積りいたします。