最近聽到一個狀況，蠻常見的，也蠻值得聊聊：

某單位被要求每年提出「三項系統優化建議」，還被列進KPI評核。聽起來好像是鼓勵大家參與改善？但其實這樣的做法，很容易讓整件事變成一場荒謬劇。

---

❌ 提三項改善建議 = 改變成真?

說真的，多數使用者根本不知道該怎麼提改善。

不是他們懶，也不是他們不用心，而是：

🌟 他們知道哪裡不順，但不知道為什麼，也不知道怎麼改。

然後就變成這樣的場景：

• 「你那個表單能不能美一點？」

• 「欄位是不是太多了？」

• 「登入畫面可不可以不要那麼醜？」

這些不是建議，是情緒。

💡 為什麼不該讓使用者背系統改善KPI？

1. 使用者不是系統設計者⇒A:你懂製程嗎? B:我胡瓜啦!

就像車主懂開車，不代表會設計引擎；系統使用者懂流程，不代表能拆解邏輯與資料結構。強迫他們提改善建議，不只難度高，還容易流於表面應付。

---

2. 壓力下提出的建議品質低落

當「提出3項建議」變成年度KPI，使用者往往為了完成指標而亂提、硬提，甚至陷入「為了找碴而找碴」的行為，這不但消耗信任，也浪費資源。

---

3. 系統改善需要全貌視角

只有IT部門能從技術、資料流、安全性、跨模組關聯等角度整體考量，而這些往往不是使用者能觸及的領域。讓非專業者單獨負責改善規劃，等於把責任丟給沒地圖的人找出路。

---

🧑‍🍳 用餐廳比喻一下好了

想像你是一個廚師，廚房熱得要命、設備難用、切菜區離爐子兩公里。老闆來說：

「你這季度要提三個改善廚房的點子，不然KPI扣分喔。」

你傻眼。你會煮菜沒錯，但你又不是廚房設計師啊。

更別說瓦斯怎麼接、水管怎麼走、動線怎麼規劃，哪懂。

最後你可能隨便寫：「加強冷氣、桌子換新、弄個咖啡機」——交差了事，什麼都沒解決。

---

🎯 正確的合作方式是怎樣？

改善本來就應該是 IT＋使用單位一起做 的事。

但要做對，有一個很重要的分工原則：

🧠 使用者負責「提問題」，IT負責「找根源＋想解法」

也就是說：

• 使用者說：「我覺得這流程很卡」「這裡常填錯」「我不知道要選哪個選項」

• IT回：「喔～你遇到這問題，是因為後端邏輯太複雜／選單沒依條件篩選，我來處理」

這樣就對了。

不要反過來叫使用者：「請幫忙想解法，我們來評估能不能做」——這樣大家都會很痛苦。

---

📌 那KPI怎麼設才不會鬧劇收場？

重點是聚焦在成果，而不是交辦數量。例如：

這些目標才真的對業務有幫助，而且雙方都可以參與、負責，甚至一起成就感加倍。

---

💬 最後想說的是...

改善這件事，不該只是某一邊的責任。

KPI不是甩鍋工具，而是雙方有共識的行動承諾。

所以：

🚫 別再問：「你怎麼都沒提改善建議？」

✅ 要問：「你哪裡卡？我們一起想辦法！」

這樣大家才會真的「一起走在改善的路上」，而不是走上KPI地獄。