小売のデータ基盤を作る順序｜POS・会員・在庫を分析できる形にする
分析が進まない原因の多くは、データがないことではなく繋がっていないことです。POS・会員・在庫を結ぶキーの設計、商品マスタの整理、着手すべき順序を、投資対効果の観点から解説します。
この記事の要点
- 分析の障害は「データがない」ことより「商品マスタが揃っていない」こと
- 最初に整えるのは商品マスタ。ここが崩れると全ての集計が信用できなくなる
- 全データの統合を目指さず、答えたい問いから逆算して必要な範囲だけ繋ぐ
- リアルタイム連携は用途が限られる。日次バッチで足りるかを先に検証する
小売業のデータ活用が進まない原因を調べると、「データがない」ではなく「データが繋がっていない」ことがほとんどです。POSにも在庫にも数字はあるものの、同じ商品が別のコードで登録されているため、突き合わせができないという状態です。
本記事では、分析できる形にするまでの順序を、投資対効果の観点から解説します。
最初に整えるのは商品マスタ
| 問題 | 分析への影響 |
|---|---|
| 同一商品が複数コードで登録 | 売上・在庫が分散し、実態が見えない |
| 店舗ごとに独自の商品名 | 店舗間比較ができない |
| 廃番商品が残っている | 品目数が実態より多く見える |
| カテゴリ分類が統一されていない | カテゴリ別分析が成立しない |
| 入数・単位が不統一 | 数量の集計が合わない |
ここが崩れていると、後続の分析は全て信用できません。BIツールを導入しても、集計結果が実感と合わないという状態になります。
整理の手順
- 各システム（POS、在庫、発注、EC）で商品をどう識別しているかを確認する
- システム間の対応表を作る（同じ商品が異なるコードを持つ場合の紐づけ）
- 統一する商品コードの体系を決める（既存のいずれかを正とするか、新設するか）
- カテゴリ分類を統一する
- 廃番・休止商品のフラグ運用を決める
3番目で新しい体系を作ると移行負荷が大きくなるため、既存のいずれかを正として他を寄せる判断が現実的です。
繋ぐべきデータと、そのキー
| データ | 主なキー | 繋がると分かること |
|---|---|---|
| POS（購買履歴） | 商品コード、店舗、日時、会員ID | 何が、いつ、どこで売れたか |
| 在庫 | 商品コード、店舗 | 欠品の有無、滞留在庫 |
| 発注・入荷 | 商品コード、店舗、日付 | リードタイム、発注精度 |
| 会員 | 会員ID | 顧客別の購買傾向 |
| 販促 | 商品コード、期間、店舗 | 施策の効果 |
商品コードと店舗コードが2つの軸になります。この2つが全システムで一致していれば、大半の分析は成立します。
答えたい問いから逆算する
全データの統合を目指すと年単位の作業になります。まず問いを2〜3個決め、それに必要な範囲だけを繋ぎます。
| 問い | 必要なデータ | 難易度 |
|---|---|---|
| 欠品による機会損失はどれくらいか | POS＋在庫 | 低 |
| 販促の効果はあったか | POS＋販促 | 低 |
| 発注リードタイムは実際どれくらいか | 発注＋入荷 | 低 |
| 会員の離反兆候は捉えられるか | POS＋会員 | 中 |
| 需要予測を発注に組み込めるか | POS＋在庫＋発注＋販促 | 高 |
上3つは2つのデータを繋ぐだけで答えられる問いです。ここから着手すると、3〜4か月で成果が出て、次の投資の説得材料になります。
リアルタイム化の判断
| 用途 | 必要な鮮度 |
|---|---|
| 在庫の引当（EC連携） | リアルタイム |
| 欠品対応 | 数時間以内 |
| 売上分析 | 日次 |
| 需要予測 | 日次 |
| 会員分析 | 日次〜週次 |
| 経営レポート | 日次〜月次 |
リアルタイムが必要な用途は限られます。全体をリアルタイム化すると、開発費と運用負荷が大きく増えます。日次バッチで足りる範囲を明確にし、即時性が必要な部分だけを切り出す設計にしてください。
データの品質を維持する仕組み
作った基盤は、放置すると劣化します。
| 仕組み | 内容 |
|---|---|
| マスタ登録のルール | 新商品登録時の必須項目と承認者 |
| 定期的な重複チェック | 月次で類似商品名を検出 |
| 欠損の監視 | 日次でデータ件数と欠損率を確認 |
| 廃番処理の運用 | 取扱終了時のフラグ更新 |
| 変更履歴の保持 | 価格・カテゴリ変更の履歴を残す |
最終行は分析の観点で重要です。現在の値だけを持つと、過去の分析が再現できません。価格やカテゴリが変わると、過去の売上を当時の条件で振り返れなくなります。
進め方の順序
| 時期 | 取り組み | 到達点 |
|---|---|---|
| 1〜2か月目 | 商品マスタの現状把握、対応表の作成 | 名寄せの完了 |
| 2〜3か月目 | POSと在庫の接続 | 欠品分析ができる |
| 3〜4か月目 | 発注・入荷データの接続 | リードタイムの実測 |
| 5〜6か月目 | 販促データの接続、効果測定 | 施策評価の運用 |
| 7か月目以降 | 会員データ、需要予測への展開 | 高度な分析へ |
まとめ
小売のデータ基盤づくりは、商品マスタの整理から始まり、答えたい問いに必要な範囲だけを繋ぐ進め方が最も効率的です。全システムの統合を先に目指すと、成果が出る前に時間と予算を使い切ります。
欠品分析や販促効果の測定など、2つのデータを繋ぐだけで答えられる問いから着手すれば、数か月で成果が出て、次の投資判断の材料が得られます。
関連記事
- 需要予測の精度を上げても在庫が減らない理由｜発注ルールと安全在庫の見直し方
- 店舗とECの在庫を一元化する｜OMO実装の設計と落とし穴
- 小売・物流のAI活用とは？需要予測から在庫最適化・配送計画までの流れを解説
参考
- 独立行政法人情報処理推進機構（IPA）「DXの推進」https://www.ipa.go.jp/digital/dx/index.html
- 総務省統計局 https://www.stat.go.jp/
よくある質問
- Q. データ基盤の構築にはどのくらいかかりますか？
- 対象を絞れば3〜6か月で最初の分析ができる形になります。期間の大半は商品マスタの整理に費やされます。全システムの統合を目指すと年単位になるため、まず答えたい問いを2〜3個に決め、それに必要なデータだけを繋ぐ範囲から始めてください。
- Q. 何から着手すべきですか？
- 商品マスタの整理です。同じ商品が複数のコードで登録されている、店舗ごとに独自の名称がある、といった状態では、どんな分析も信用できません。POS・在庫・発注の各システムで商品をどう識別しているかを確認し、対応表を作るところから始めます。
- Q. リアルタイムでデータを見る必要はありますか？
- 用途によります。在庫の引当や欠品対応には即時性が必要ですが、売上分析や需要予測は日次で十分です。リアルタイム化は開発費と運用負荷を大きく押し上げるため、本当に即時性が必要な用途を特定してから範囲を限定して適用してください。
- Q. 会員データと購買データを紐づける際の注意点は？
- 個人情報の取り扱いを社内規程と利用目的の範囲で整理することが前提です。技術面では、会員IDが付与されない購買（非会員の現金購入など）が一定割合あるため、会員分析の結果を全体の傾向として扱わないよう注意が必要です。
ABOUT THE AUTHOR
Pactom 開発チーム
株式会社Pactomは、製造業・建設業・小売/物流を中心に、AI導入の課題整理からユースケース設計、実装、運用定着までを一貫して支援しています。
導入について相談する
