店舗発注と食材原価をつなぎ、店舗別FLコストを日次で回す
POS売上は日次で見える。食材原価と人件費を突合した店舗別FLコストだけが、月次締めまで出てこない。手を打つのが1ヶ月遅れる。店長のExcel発注と紙の廃棄記録を基盤に載せる。
業界に共通する課題
FLコストが月次締め後
POS売上は日次で見えるが、食材原価（F）と人件費（L）を突合した店舗別FLコストは月次締め後。手を打つのが1ヶ月遅れる。
発注精度が店長依存
発注は店長の経験と勘。過発注による廃棄と、欠品による機会損失が同じチェーン内で同時に起きている。
廃棄ロスが記録されない
廃棄は店舗の紙／Excel記録で本部に集約されず、「何がどれだけ捨てられたか」が分からない。改善対象が特定できない。
モデル企業の前提
会社・売上・拠点数は、すべて架空の数字です。
データはどこで切れているか
システムは揃っていますが、データが分断されている状況です。
- POS（120店）
- 勤怠システム（シフト・実働）
- 基幹（会計・原価）
- 販促・クーポン実績
- 店舗発注システム
- 委託3PLのWMS（3温度帯）
- 廃棄記録（店舗の紙／Excel）
- 棚卸データ（月次）
症状：売上はPOSにメニュー単位で、食材の発注は店舗発注システムに食材コード単位で、人件費は勤怠システムにある。廃棄は店舗の紙とExcelで、本部に集約されていない。メニューと食材を結ぶレシピ情報がデータとして持たれていないため、売上から理論原価を引き当てられず、実際原価との差が廃棄なのか歩留りなのか判別できない。
W3 Data Platform 適用シナリオ（想定）
つなぐ → 揃える → 使う の3ステップ。既存システムは入れ替えません。
つなぐ
POS・店舗発注システム・勤怠・委託3PLのWMSを接続。店舗の廃棄記録Excel／スプレッドシートもそのまま取り込み、統一スキーマに載せます。
揃える
店舗×日×メニュー／食材の粒度で、売上・食材投入・廃棄・人時を1本に統合。3温度帯の物流費も店舗別に配賦します。
使う
店舗別FLコストの日次可視化、需要予測に基づく発注推奨（天候・曜日・販促を考慮）、廃棄ロスの原因分析、シフト最適化提案。
店長の発注Excelや紙の廃棄記録は、やめさせる対象ではなく取り込む対象です。現場の記録方法を変えないまま基盤に載るため、店舗の負担を増やさずに改善が回り始めます。現場が抵抗する理由がなくなります。
AIとのやりとり
MCP接続により、AIが統合データを直接参照します。SQLの記述もBIツールの操作も不要で、会話で引き出せます。
POS、店舗発注、勤怠、廃棄記録を店舗と日付で結合し、FLコスト率を日次で算出しました。直近7日平均の悪化順です。
| 店舗 | 売上（7日） | F率 | L率 | FL合計 |
|---|---|---|---|---|
| R駅前店 | ¥3,240,000 | 36.8% | 31.2% | 68.0% |
| S郊外店 | ¥2,180,000 | 32.1% | 29.4% | 61.5% |
| T商業施設店 | ¥4,120,000 | 30.4% | 26.8% | 57.2% |
R駅前店のFL合計68.0%（目標60%）が悪化しています。F率悪化の主因は「生鮮3品目の廃棄が売上比2.8%（チェーン平均0.9%）」、L率は「アイドルタイムの人員配置」。① 該当3品目の発注ロット見直し（想定 月▲34万円）、② 14〜16時のシフト2名削減案（同▲28万円）を提示します。明日の発注推奨（天候・曜日・販促考慮）も生成済みです。
※ 画面・数値はイメージです。実際の項目・粒度は接続するシステムとデータ内容により異なります。
揃えたあとのデータの並び
各データの列名・粒度・書式を同じ定義に揃えます。拠点ごとのExcelも、同じ表の中に入ります。
mart.store_fl_daily- 店舗コード
store_id - 対象日
dt - 売上金額
sales - 食材原価
food_cost - 廃棄ロス金額
waste_cost - 労働時間
labor_hours - 人件費
labor_cost - FL比率
fl_rate - 天候
weather
店舗の紙／Excel廃棄記録も統一スキーマへ。売上・食材・廃棄・人時が同じ日付軸に並び、FLコストが締めを待たずに日次で確定します。
誰が、いつ、何に使うか
定型の集計とアラートは自動で届くため、担当者がダッシュボードを開く必要がありません。
- 朝 9:00エリアマネージャ
担当店舗の前日FLコストと異常値（廃棄急増・人時過多）がAIから届く。
- 昼 15:00店長
明日の発注推奨（天候・曜日・販促を考慮）を確認して承認。発注システムへ連携される。
- 夕 18:00本部 商品部
「廃棄が多い食材とメニュー」を横断分析。レシピ・提供サイズの見直し材料になる。
- 週次経営
全店のFLコストが同じ定義で並ぶ。締めを待たずに不採算店の手当てができる。
想定効果（仮定に基づく試算イメージ）
記載の数値は代表値・想定値です。実環境（データ量・システム構成・ネットワーク）により変動する可能性があります。費用は対象システムの仕様確認が必要なため、個別にお見積りいたします。
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へ広げることもできます。
本ページは架空のモデルケースです。記載の企業は実在せず、数値・効果は仮定に基づく試算イメージであり、実際の導入実績ではありません。効果は対象業務・データ規模・システム構成により変動します。
記載の数値は代表値・想定値です。実環境（データ量・システム構成・ネットワーク）により変動する可能性があります。費用は対象システムの仕様確認が必要なため、個別にお見積りいたします。