挑戰
Odoo 這類 ERP 是照模組長的，不是照人的一天長的。打卡、請假、報帳、訂餐、看這個月的業績——五件再平常不過的事，散在五套模組階層裡，每一件都要點好幾層才碰得到。功能一個都不缺，只是每一個都很遠。於是大家默默退回 Excel、群組訊息和貼在牆上的紙，公司付錢養了一套沒人打開的系統。
我們怎麼判斷
這種量體的系統，能不能用是入口決定的，不是功能數量決定的。我們沒有加功能，也沒有拿掉功能。我們把大家每天真的會做的事列出來、按發生頻率排序，讓這個排序——而不是模組樹——決定第一個畫面要放什麼。
做了什麼
落地畫面就放每天要看的兩件事：業績圖表與團隊行事曆。高頻的小事——打卡、休假申請、報帳、訂餐——收成一排，點一下就到。其餘十二個應用收進同一個抽屜，Odoo 後台保留成一個明擺著的連結、不藏起來，沒有人會被關在我們這一層裡出不去。信箱、雲端、白板、GitHub 與培訓站一併收進同一個殼，團隊討論室直接停靠在右側，不必再開一個視窗。視覺跟著結構同一輪改完，不是事後再貼一層皮。
結果與判決
學習成本降在最要緊的地方：你不必先搞懂 ERP 的分類法，才有辦法用它。判決講白：這種系統的可用性瓶頸在資訊架構與入口，不在功能清單——而光改表面救不了底下的壞結構，這也是為什麼 UX 與視覺必須同一輪一起動。誠實的但書：這是我們自家的系統、使用者是自己人，請把它當成一份設計說明，不是對照實驗。
