AI 工具做出來了，為什麼現場卻不想用？

如果連問題都還沒弄清楚，工具就先做出來了，現場當然很難接受。

最近聽到幾個很類似的 AI 導入案例。

公司找了一位熟識的 AI 工程師，協助各部門推動 AI。

工程師動作很快，根據過去熟悉的工具和技術，很快做出了幾套應用，請各部門同仁開始測試。

結果，現場反彈很大。

主管看不到方向，同仁覺得日常工作又多了一件事。

原本工作就已經很忙了，現在還要額外花時間測試新工具，而且也不知道這個測試之後，到底可以改變什麼。

對現場同仁來說，這其實是很大的負擔。

最後，大家開始質疑工程師：「為什麼不先了解我們的工作流程？」

工程師做的其實是自己最擅長的事。

差別在於如果能先了解現場的流程，知道現在遇到什麼問題，再來討論要用什麼工具解決，結果可能會好很多。

如果連問題都還沒弄清楚，工具就先做出來了，現場當然很難接受。

從 MRP 到 ERP，改變的不只是軟體功能，還包括企業的管理方式。

很多人以為 ERP 導入就是買一套軟體，卻忽略了軟體背後的管理邏輯。

這讓我想到高德拉特在談新技術如何帶來效益時，提出過四個問題：1. 這個工具的主要能力是什麼？

2. 它降低了什麼限制？

3. 過去我們用什麼規則，來因應這個限制？

4. 現在應該改用什麼規則？

這四個問題，其實也很適合拿來思考現在的 AI 導入。

因為工具改變了，不代表原本的管理方式就會跟著改變。

如果系統流程改了，但實際工作時，大家還是按照過去的習慣在作業，那改變能帶來的效果其實很有限。

這也是導入新系統時，很容易被忽略的地方。

回頭看前面的案例，我覺得有幾件事值得思考。

首先，每個部門看到的問題可能都不一樣。

同樣一件客戶需求變更，業務關心交期與訂單金額，生管關心產能與排程，財務關心額外包裝或是急件帶來的成本。

工程師依照自己的經驗設計工具，解決的可能是技術上看得到的問題，卻不一定是現場真正需要解決的問題。

再來，是改變的順序。

限制理論在處理改變時，會思考三個問題：

• 要改變什麼？（What to change?）
• 要改變成什麼？（What to change to?）
• 如何讓改變發生？（How to cause the change?）

從工具出發，很容易變成第一題還沒回答，就開始做第二題。

至於第三題，要怎麼讓改變真的發生，反而沒有處理。

我們可能已經想好新系統要怎麼做，甚至工具都開發完成了，但現場同仁還不知道我們要朝什麼目標前進，也不清楚這個改變可以帶來什麼好處。

在還沒有充分溝通、教育訓練或形成共識之前，就請大家開始使用新工具，想像中的改變不一定有辦法在現場落地。

還有一些現場的實際做法，不一定會寫在 SOP 裡。

這也是為什麼，我會希望負責導入的人，能先去了解使用者每天怎麼工作。

所以，不管工具從 MRP、ERP、BPM 到現在的 AI，我還是會先問：現在真正卡在哪裡？

過去用什麼方法因應這個限制？

有了新工具之後，原本的工作規則是不是也應該跟著改？

AI 可以加快資訊整理、協助判斷，甚至執行部分任務。

但哪些決策可以交給 AI、哪些例外需要人工處理、誰要對結果負責，這些都需要先想清楚。

更重要的是，要讓現場同仁知道我們為什麼要改、希望改成什麼樣子，以及他們的工作會有什麼不同。

如果只有工具改變，人的工作習慣和管理方式卻沒有跟著調整，最後能帶來的效益還是有限。

這也是為什麼，我一直覺得變革管理很重要。

你看過的 AI 導入案例，是先有工具，還是先有問題？

原文 2026-10-24 發表於 LinkedIn；本頁為站內整理版，文字與原文相同，只調整了平台相關的說法。