Retail Fresh-Food Loss & Inventory Decision System

把「六折貼紙」
變成可以提前預防的決策

消費者看到的六折貼紙,對門市而言代表一次已經失準的預測。 鮮守不只呈現已經發生的損失,而是在商品還來得及處理的時候主動指出問題, 並把「該怎麼做」直接寫在畫面上。

Python · Streamlit · SQLite技術棧
58,400營運資料筆數
14功能頁面 · 4 種角色
供應鏈資料流 · WebGL
01 — The Problem

生鮮的損失,發生在看見之前

貼紙只是損失的一半。真正的成本包含賣不掉而報廢的部分, 那些商品從採購、冷鏈到上架的投入,全部歸零。

4,172
全台十店年度總損失
7.59%
平均報廢率
1.9
最差與最佳門市的落差
2,614
年碳排(CO₂e)
關鍵發現:這不是商品問題,是管理問題。 同樣賣一樣的商品,台中逢甲店的報廢率是 10.17%, 台北公館店只有 5.35%。 若全台都做到最佳門市的水準,光是這個落差就代表可觀的改善空間, 這也是系統把「門市互相比較」設計成核心功能的原因。
02 — The Value

這套系統具體幫使用者什麼

三個面向:省錢、省時間、減碳。每個數字都可以追溯到計算方式。

SAVINGS

省錢

兩種估算方式,取較保守者作為承諾值。

標竿學習法(保守)年省 610 萬
業界成效法(降 30%)年省 1,252 萬
換算每店每天1,670–3,429 元
TIME

省時間

把「找問題」的時間還給現場。

店員巡架找即期品30–45 分/天
盤點作業2 小時/次
店長彙整報表3–4 小時/月
ESG

減碳

減少浪費是少數「省錢」與「減碳」一致的行動。

目前報廢碳排2,614 噸
改善 30% 可減少784 噸
相當於種樹37,340 棵/年
為什麼要提兩個數字? 「降 30%」是零售業導入智慧補貨系統的常見成效,但那是別人的成績。 「標竿學習法」只假設每家店做到目前全台最佳門市的水準,完全用自家資料推算, 是更難被質疑的下限。系統內的效益試算頁可以自行調整改善比例重新計算。
03 — System Design

從「事後報表」到「事發當下介入」

多數分析系統只回答「上個月損失多少」。鮮守的設計重心放在營運當下的閉環: 每一個環節都留下紀錄,讓下一個環節有依據。

01

進貨驗收

驗數量、量品溫、記效期,分離供應商與門市責任。

02

庫存管理

依保鮮天數自動推算到期時間,不需人工計算。

03

即期品介入

到期前主動排入待辦,附建議折數。

04

報廢歸因

報廢必須選原因,才能區分可預防與否。

05

盤點驗證

帳面與實盤比對,回答「你怎麼知道庫存是對的」。

06

補貨決策

扣除現有庫存,限制在保鮮期內賣得完的量。

系統會主動說話

登入後的第一個畫面是「今日總覽」,由系統列出需要處理的事項並排序, 而不是等使用者自己去查。這是報表工具與決策系統的分界。

每個建議都附理由

不只顯示「建議訂 165 件」,而是說明扣除了多少庫存、 為什麼上限是這個數字。使用者能判斷該不該採納,而不是盲從。

生鮮專屬的限制

一般商品訂多了壓資金,生鮮訂多了直接報廢。因此補貨建議額外限制 「不超過保鮮期內賣得完的量」,避免一開始就註定要丟。

04 — Screens

實際畫面

以下皆為系統執行時的真實截圖,非設計稿。點選可放大檢視。

即期品處理台:商品依剩餘時效分成四個急迫度區塊,已過期的只能報廢並必須選擇原因
即期品處理台 店員每天的第一個畫面。系統已依剩餘時效排序並算好建議折數, 已過期的商品只提供「報廢」而拿掉販售選項,並強制選擇報廢原因。
今日總覽:系統主動列出待處理事項,依紅橘藍三色標示嚴重程度
今日總覽 登入後的第一頁。系統主動列出今天要處理的事, 依嚴重程度排序,每一則都附建議行動與前往的頁面。
損失瀑布圖:從總營收依序扣除進貨成本、折扣價差、報廢損失,得出實際毛利
損失瀑布分析 回答店長最在意的問題:投入這麼多採購成本, 為什麼最後只剩這些毛利?損失發生在哪一段一目了然。
門市與商品類別的立體交叉分析,可用滑鼠旋轉縮放
門市 × 類別立體交叉 十家門市乘上四個類別共四十個交叉點, 用 2D 圖表會擠成一團。立體呈現能同時看出哪一格突出、突出多少。
資料健檢頁:系統健康分數與九項檢查結果,每項附建議處理方式
資料健檢與稽核 資料問題通常不會報錯,只會安靜地讓報表失真。 這一頁把「不會自己浮現的問題」定期撈出來,每項都附處理方式。
04 — Access Control

四種角色,四種完全不同的系統

權限採雙層設計:選單只顯示該角色可用的頁面,每個頁面內另有獨立驗證。 即使直接輸入網址也無法繞過。

功能頁面店員店長總部採購後台管理員
今日總覽
即期品處理台
收貨驗收 · 盤點 · 補貨
本店儀表板
全台營運彙總
需求預測與進貨建議
供應商管理
帳號與權限 · 門市設定 · 稽核
現場作業

門市店員

「今天哪些要處理?」清單式待辦、建議折數、批次標記。

單店管理

門市店長

「本店哪裡在漏錢?」損失排行、員工執行、庫存風險。

跨店決策

總部採購

「哪家店要介入?」跨店比較、標竿分析、供應商績效。

系統維護

後台管理員

「系統健康嗎?」帳號權限、門市主檔、資料健檢與稽核。

安全措施: 密碼以 bcrypt 雜湊儲存;所有查詢使用參數化 SQL;連續登入失敗暫時鎖定; 閒置逾時自動登出;新帳號強制首次登入變更密碼;停用的帳號無法登入但保留完整歷史紀錄; 稽核紀錄只增不刪,系統中沒有任何介面能刪改它。
05 — Data & Model

資料方法論與模型驗證

真實門市的生鮮銷售資料屬於商業機密,無法取得。因此採用機器學習領域 驗證模型能力的標準做法:植入已知規律,再檢驗模型能否獨立學回。

方法論:先植入,再驗證

資料生成時植入天氣、節慶、週末、門市規模與管理效率等規律。 模型訓練時完全不被告知這些規律。若能學回,代表模型確實在學習資料中的關係, 而不是碰巧猜對。

誠實揭露: 所有人為設定的參數都在系統內完整列出,不假裝資料是真實的。 方法論的可信度來自透明。

模型結果與對照組

模型說明
隨機森林(100 樹)0.88能捕捉非線性關係
線性迴歸(對照組)0.60無法處理交互作用

對照組很重要:只秀出 R²=0.88,無從判斷這算好還是不好。 有了線性迴歸的 0.60,才能證明選擇隨機森林是有理由的。

58,400
營運資料筆數
16
商品品項
10
門市
16
資料表(星狀綱要)
模型能力邊界(刻意保留的限制說明): MAPE 約 13%,但生鮮食品沒有專屬的業界基準可直接對照; R² 不等於「猜對的比例」,這是常見誤解; 模型適合做方向性判斷(明天大概會多賣或少賣),不適合完全自動決定精確訂貨量。 真實門市的資料雜訊更高,實際誤差預期會上升。
06 — Metrics

採用零售業通用指標,而非自訂數字

每個指標都使用業界通行的定義,讓使用者能把自己的數字拿去跟同業比較。 系統內每個指標都附計算式與基準來源。

指標計算方式意義
報廢率 / 損耗率
Shrinkage Rate
報廢金額 ÷ 總進貨成本可與同業直接比較的核心指標
總損失率
Total Loss Rate
(報廢 + 折扣價差) ÷ 總進貨成本反映真實損失,含折扣讓利
售罄率
Sell-Through Rate
售出量 ÷ 進貨量進貨量是否符合實際需求
折扣率
Markdown Rate
折扣銷售額 ÷ 總銷售額預測失準的直接證據
庫存周轉天數
DIO
平均庫存 ÷ 日均銷貨成本生鮮應遠低於一般商品
毛利投資報酬率
GMROI
毛利 ÷ 平均庫存成本每一元庫存創造多少毛利

分母採「正常售出 + 折扣售出 + 報廢」的成本合計,代表該期間實際投入的採購成本。 若只用已售出成本作分母,會系統性低估損失率。

07 — Architecture

技術架構

設計原則:任何一台電腦解壓縮後就能執行,不需安裝資料庫伺服器、不需設定連線字串。

FRONTEND

前端 / 應用層

Streamlit(Python)。自訂設計系統:CSS 變數、Material Symbols 單色圖示、 卡片動畫與無障礙降級。Three.js 用於門市×類別的立體交叉分析。

DATA

資料層

SQLite 單檔資料庫,星狀綱要(Dim_ / Fact_)。由 SQL Server 遷移而來, 移除 pyodbc 相依,達成零安裝。

ANALYTICS

分析層

scikit-learn 隨機森林、pandas 資料處理、Plotly 互動圖表(33 張)、 Open-Meteo 無金鑰天氣 API。

模組職責
app.py入口:資料庫健檢 → 登入 → 依角色組出選單
db.py唯一的資料庫存取點,路徑相對於專案根目錄
auth_helper.py登入驗證、權限檢查、鎖定與逾時
metrics.py營運指標計算(報廢率、排行、即期品、瀑布分析)
kpi.py業界標準 KPI 定義、基準值與評級
operations.py營運作業(驗收、盤點、報廢歸因、補貨、告警)
admin.py後台管理(帳號、門市、參數、資料健檢、稽核)
three_viz.pyThree.js 3D 視覺化元件(離線可用)
ui.py設計系統:色票、元件、動畫、品牌識別
封面 1 / 8