案例研究：找出可調撥的門市

《門市缺貨 → 跨店調撥》是從 Odin 的角度看管理者怎麼建立調撥 Agent，Sindri 那一篇則是業務同仁怎麼在聊天視窗裡核可調撥單。這篇看的是決策之前的那一步：全台門市的庫存到底怎麼分布，哪幾間真的撥得出貨。

信義旗艦店的聯名鈦保溫瓶明天就要斷貨。要調撥就得先知道誰有餘裕，而這個答案分散在十幾間門市的庫存資料裡。零售專案的 POS 門市語意模型就存著這份資料，包含每間門市每個商品的現有庫存、安全庫存與日均銷量。

用一句話問出全門市的庫存分布

營運人員在 Mimir 首頁選定 POS 門市語意模型，輸入：

各門市聯名鈦保溫瓶的現有庫存與安全庫存各是多少？哪些門市庫存高於安全庫存、有多餘可以調撥？請用長條圖呈現各門市的現有庫存

問題裡直接要求長條圖，Mimir 才會畫；否則預設只回文字與資料表。送出後它跑了七個步驟：查可用的語意模型、了解庫存表結構與欄位、驗證查詢、取回各門市現有庫存與安全庫存、整理成表格、命名對話，最後畫圖。

回答把門市分成兩組。可調撥門市共 11 家，板橋店現有 80 件、安全庫存 24 件，盈餘 56 件最多；竹北店 60 件對 24 件，盈餘 36 件次之；屏東店盈餘 15 件，其餘如新莊宏匯店、花蓮店、員林店各約 9 件，台南西門店與台中店只剩 2 件餘裕。缺口門市只有一家：信義旗艦店現有 6 件，安全庫存 40 件，缺口 34 件。

Mimir 並且直接給出建議：優先從板橋（盈餘 56）與竹北（盈餘 36）調撥補充信義旗艦店的 34 件缺口，兩家合計盈餘 92 件，空間充裕。這正是 Odin 那篇案例裡實際開出的三張調撥單的來源。

看圖確認餘裕的分布

點結果卡片的 View chart 展開右側面板，切到 Visualization 分頁就是那張長條圖。

圖用顏色把狀態說完了：藍色是庫存高於安全水位的門市，橘色只有一根，就是缺貨的信義旗艦店。長條由長到短排列，一眼就能看出餘裕集中在板橋與竹北兩間，後面的門市即使有盈餘也只有個位數，把調撥拆給七八間店只會增加物流成本而換不到多少數量。

面板的 SQL Query 分頁可以看到 Mimir 產生的查詢，Data Preview 分頁則是原始的資料列。

存成圖表持續追蹤

缺貨期間庫存每天都在變，這張圖不是問一次就結束。點面板的 Create View，在 Save current view 對話框把 Visualization 選成剛剛那張長條圖，命名後儲存。

存下來的 View 包含它背後的 SQL，可以加進儀表板跟其他缺貨追蹤指標放在一起，之後直接看板就好。做法見 Dashboard 儀表板。

讓答案穩定符合團隊慣例

上面那句問題能一次問對，有個前提：store_inventory 這張表同時有 store_id 與 store_name、sku 與 sku_name，而缺口要用哪兩個欄位相減也不是資料本身決定的。這些約定寫進 Knowledge 之後，Mimir 在回答時會直接沿用，不必每次在問題裡重複交代。這個案例裡它就在回覆開頭說明是依照已儲存的查詢，以 SKU-8801 為目標先驗證 SQL 再執行。

這個案例展示的重點

• 知道信義旗艦店缺 34 件，還不夠決定怎麼補。真正要問的是哪幾間店撥得出貨，而這次的答案是：11 間店有盈餘，但板橋和竹北就佔了 92 件，剩下九間全部加起來也不到 60 件，而且多數只有個位數。所以合理的做法是找這兩間，把調撥拆給七八間店只會多花物流成本。
• 想要圖就在問題裡寫明要長條圖。不寫的話 Mimir 只會回文字跟表格，而且存成 View 時能選的呈現方式只有它真的畫出來的那幾張。
• 這種每天在變的數字不要每天重問。存成 View 放上 Dashboard，之後開看板就看得到最新的。一次性的探索才留在 Thread 裡。
• 缺口 = 安全庫存 − 現有庫存、門市要顯示名稱不顯示代號，這些是團隊的約定，資料本身不會告訴 Mimir。寫進 Knowledge 之後它每次都會照做，不必在每個問題裡重講一遍。