《台灣產業AI化大調查》指出近半企業已投入AI,卻有23%導入後「無感」。AI落地痛點不在技術,而在沒有先定義問題。本文用設計思考的「同理 → 定義 → 解題」框架,拆解企業AI轉型成效低落的根因,並給三組可執行的內部對齊問題。

AI落地痛點正逼著企業重新做一件最古老的事,把問題先定義清楚。陪著台灣企業在數位轉型這條路上跑了 30 年,最常聽到的一句話是:「我們也買了 AI 工具,但好像沒什麼用。」企業AI化的失分不在技術選型,而在更前面一層:問題到底是什麼,有沒有人說得清楚。設計思考裡的同理與定義階段,正好補上這個常被跳過的前置缺口。本文拆解《台灣產業AI化大調查》47.8% Ready/Scaling 卻僅 36.84 應用得分背後的 AI 轉型成效盲點

多數企業以為「導入 AI」就會自動產生效益,這個假設在 23% 的案例已被打破

多數企業以為導入 AI 就會自動產生效益。但《台灣產業AI化大調查》的數據顯示,在已經 Ready AI 或 Scaling AI 的企業中,仍有 23.0% 表示「導入後暫無明顯成效」,另有 23.6% 卡在「找不到適用的應用場景」。這不是技術問題,是組織根本沒先想清楚「AI 要解什麼」。把工具當成答案,原本應該被定義的「問題」就消失了。

調查還揭露了另一組更耐人尋味的數字:47.8% 企業已進入 Ready 或 Scaling AI 階段,但實際應用程度的平均分數只有 36.84,投入意願在前面,落地成效在後面,中間斷成兩截。AIF 自己解讀這個落差時直白指出:「企業在尚未進行內部盤點前,對自身 AI 發展程度抱持樂觀;實際導入後盤點,才意識到資料整備不足、流程未優化。」

這個落差不是台灣獨有。MIT NANDA 計畫 2025 年的《生成式 AI 鴻溝:2025 年商業 AI 狀況》報告更直白:95% 的企業生成式 AI 專案在 6 個月內未能產生可衡量的財務回報。RAND Corporation 訪談 65 位 AI 資料科學家後得到一個更刺眼的結論:超過 80% 的 AI 專案最終會失敗,主因不是技術,而是「核心利益關係人之間的目標不一致」。

換句話說,問題不在 AI 不行,是組織自己沒對齊「要解什麼」。

真正的瓶頸不是技術,是 90% 的失敗源於沒有先定義問題

真正的瓶頸不是技術,是組織進到 AI 採購流程時,沒有人能清楚說出「我們要解的問題是什麼」。Cooper(2024)在《哈佛商業評論》分析多項 AI 失敗案例後直接寫道:「幾乎所有失敗案例都源於對 AI 理解不周全的『愚蠢原因』」。其中第一條是「不了解使用者需求、缺乏明確目標,組織陷入新奇事物症候群」。問題沒被定義,再強的模型也救不回來。

英國建築學者 Cedric Price 在 1966 年留下一句經典提問:「If technology is the answer, what was the question?」(如果科技是答案,那問題是什麼?)這句話放到 2026 年的 AI 浪潮,比當年更刺眼。陳宜秀副教授在《台灣產業AI化大調查》報告序言裡引用這句話,直接點名當下企業導入 AI 的盲點:在「AI 是答案」的氣氛裡,「定義問題」這一步被跳過了

設計思考界有一個經典案例可以對照。國際援助組織在迦納推廣防瘧疾蚊帳,整體死亡率下降了 50–60%,但中產階級家庭的使用率僅有 14%。深入訪談才發現,居民拒用的真實原因不是「不知道蚊帳重要」,而是覺得不美觀、悶熱、進出不方便。團隊重新定義問題後,開發了「錐形拉鍊入口」與「彈出式帳篷」型蚊帳,使用率才真正上來。完美的技術,錯置在錯的問題上,等於沒有解決方案。

把這個邏輯搬回企業內部,常見的錯置長這樣:

錯置一:把「員工生產力低」直接定義成「我們需要 ChatGPT 企業版」

但生產力低的真實原因可能是會議太多、跨部門資料拿不到、報表格式不一致,這些 AI 工具解不了,只有流程重整才解得了。

錯置二:把「客戶服務體驗差」直接定義成「我們需要 AI 客服 Agent」

但體驗差的真實根因可能是商品退換貨政策本身複雜難懂,AI 回答得再流暢,遇到複雜政策還是會失準。

錯置三:把「員工流動率高」直接定義成「導入 AI 招募系統加速找人」

但流動率的真實原因可能是新人 onboarding 體驗差、主管帶人能力斷層,這些是培訓問題,不是篩選效率問題。我們在另一篇〈為什麼你的員工上完 AI 課,回去什麼都沒改變?〉裡也談到類似邏輯:把學習成效低歸因到「員工不認真」,往往就錯過了真正的瓶頸。

每一條看起來都荒謬,但實際導入過程中極為常見。三種錯置攤開比較:

表面痛點跳到 AI 答案真實根因(不解決就會失敗)
員工生產力低採購 ChatGPT 企業版會議過多、跨部門資料拿不到、報表不一致
客戶服務體驗差部署 AI 客服 Agent商品退換貨政策本身複雜難懂
員工流動率高導入 AI 招募系統新人 onboarding 體驗差、主管帶人能力斷層

BCG 的 10-20-70 法則(Patel et al., 2021)就直接量化了這個現象:AI 專案成功的關鍵中,演算法只佔 10%、技術環境佔 20%、剩下 70% 取決於人員與流程。問題定義錯了,70% 的能量就用錯地方。

設計思考怎麼幫企業精準定義 AI 應用問題?

設計思考幫企業精準定義 AI 問題的方法是把「同理(Empathize)」與「定義(Define)」放到「找解(Ideate)」之前。Stanford d.school 的設計思考五段式有一個關鍵設計:在動手找解法之前,先用兩個階段讓組織離開「自我視角」:先理解使用者實際在做什麼、卡在哪、為什麼這樣做,再把零碎的痛點收斂成一個可被 AI 處理的問題敘述。順序對了,後面的解才會對。

具體展開,企業可以做三件事:

動作一:用「同理」階段,先盤點誰會用 AI、卡在哪

不是先問「我們要導入哪個 AI 工具」,而是先問「誰每天在做這件事、他真正的痛點是什麼」。財政部在發展自家稅務 AI 應用時就是這樣做的:他們把策略定位為「業務人員主導,而非資訊人員主導」。承辦營業稅的業務人員最清楚什麼數據異常代表逃漏稅樣態,這些是資訊人員短期訪談撈不到的領域知識。

對照到企業現場:HR 想用 AI 解員工 onboarding 問題,第一動作不是去看 ChatGPT 有什麼功能,而是去訪談 5 位過去半年新進員工,他們前 30 天最卡的三件事是什麼?我們在〈工具愈加愈多,HR 卻愈來愈累〉裡拆過這個現象:工具堆疊不會解決問題,問題定義先做才會。這 5 個訪談會比任何一份廠商簡報都有用。智谷在輔導客戶導入 AI 時也常用這個切點:先盤點工作任務,再決定哪幾個任務適合 AI 介入

動作二:用「定義」階段,把痛點收斂成可被 AI 處理的問題敘述

設計思考裡有一個經典格式:「[誰] 需要 [動詞] [什麼],因為 [洞察]」。把 onboarding 訪談的零碎痛點放進這個格式,會長這樣:「新進業務員需要在前 14 天能快速找到 50 種商品的差異說明,因為現有的 PPT 簡報過於零散,他們不確定哪份是最新版」。

這個句子寫出來之後,AI 工具的選型就清楚了。你要的不是「ChatGPT 企業版」,而是一個能餵商品資料庫的 RAG 應用,給新進業務員當隨身助理。同樣的問題如果定義成「我們要 AI 做員工教育訓練」,方向就模糊了,預算也會花歪。

動作三:用「驗證假設」迴圈,避免用 AI 解錯誤的問題

設計思考五段式的 Test 階段,目標是用最低成本驗證「我們對問題的理解對不對」。回到迦納蚊帳案例:原始假設是「居民不懂蚊帳重要性」,所以解法是「強化教育宣導」;後來實地訪談才驗證真實假設是「居民覺得不美觀通風差」,解法才轉成「重新設計蚊帳形式」。

企業 AI 導入也一樣。在投入 200 萬建置 AI 系統之前,先用 2 週時間做小規模假設驗證:找 3 位真實使用者,給他們現成的 ChatGPT + 你假設的工作流程,看他們實際遇到什麼問題。70% 的 AI 投資失敗,可以在這 2 週裡被擋下來。

定義問題之後,組織要重新對齊三件事

定義問題之後,組織要重新對齊的不是技術選型,是「誰主導、誰驗收、誰負責持續優化」。AI 失敗率高達 80% 的根本原因之一,就是組織把它當成 IT 採購案,找到對的供應商、簽約上線就結案。但 AI 不像 ERP,是一條會持續演化的能力,需要組織內部建立對應的所有權結構。三件事必須同步重新對齊。

第一件:把 AI 專案的「業務 owner」明確指派

不是 IT 部門 owner、不是專案經理 owner,是真正使用這個 AI 的業務單位主管 owner。財政部的成功案例驗證了這一點:當業務人員從「需求提出方」變成「主導開發方」,AI 才會被定義成真正解問題的工具。智谷在執行「企業 AI 診斷」時,第一個釐清的問題就是這個:「這個 AI 應用的業務 owner 是誰?沒指派的話,我們先停下來。」

第二件:建立「定義問題能力」的盤點機制

多數企業沒有意識到,「定義問題」是一個可以被訓練的能力。Korn Ferry 2026 年領導力報告裡,「批判性思考」被列為當前企業最稀缺的第一名能力,它包含的核心動作之一就是「能不能在模糊情境裡,把混亂的訊號收斂成一個可執行的問題」。這個能力不是天生的,是透過工作坊、案例討論、結構化提問練習出來的,也是智谷企業 AI 應用力培訓在診斷階段最常被點名的能力斷層。

智谷將它歸類在「五階段 AI 服務」框架的中段:不知道能幹嘛、知道但不確定、確定但沒見過、想做不知找誰、在跑了想深化。卡在第二、第三階段的企業,最缺的就是「定義問題」的能力,這也是 AI 卡牌工作坊設計時最核心的訓練目標:透過卡牌引導,讓主管把模糊的「我們需要 AI」具體化成「我們要解 X 問題」。

第三件:建立「假設驗證 → 修正定義 → 再投資」的學習迴圈

AI 不是一次性導入,是持續修正的。第一個版本的問題定義一定不準,重點是有沒有設計回饋機制讓問題定義持續被修正。MIT NANDA 報告指出,5% 真正成功的企業有一個共通點:他們不把 PoC 與正式上線當作兩個獨立階段,而是用最小規模真實環境跑出資料,再回頭調整問題定義

這三件事都不是技術問題,是組織治理問題。AI 落地痛點,從來都不是 AI 的問題。對於正在規劃跨部門 AI 對齊的組織,可以參考策略共識營的引導機制,把「定義問題」這一步從會議紀錄變成被持續修正的組織習慣。

FAQ

「定義問題」聽起來很抽象,主管要怎麼跟團隊說明這一步?

最直接的方法是把現有 AI 候選專案攤開,逐個問三個問題:「誰要用?解什麼痛點?沒有 AI 的話現在怎麼解?」第三個問題最關鍵,如果答得出來,AI 介入的價值才能量化;答不出來,這個專案的「問題」其實還沒定義清楚。BCG 在 10-20-70 法則中強調的「人員與流程佔 70%」,前提就是這三個問題都先有答案。

我們公司很小,不需要做設計思考這套大流程,對吧?

恰恰相反。組織越小,越輸不起一次失敗的 AI 投資。設計思考的精華不是「跑完五段式 workshop」,是「在投入錢之前,先用最小成本驗證假設」。對中小企業來說,2 週訪談 5 位真實使用者的成本,遠低於投資 50 萬下去結果沒人用的損失。MIT NANDA 報告裡 95% 失敗的專案,多數規模都不大。

我們已經買了 AI 工具但用不起來,現在補救還來得及嗎?

來得及,前提是你願意回頭重新定義問題。多數「用不起來」的案例,不是工具選錯,是當初買進來時問題沒定義清楚。具體做法:召集實際使用單位 3–5 人,重新訪談他們的工作流程,把工具的功能放回「他們真正的痛點」上重新對應。常見結果是:原本買的功能用不到,但工具本身可以解決另一個更急的問題。

設計思考跟 Lean Startup 的「最小可行產品」有什麼不一樣?

兩者的精神接近,差別在切入點。Lean Startup 假設「我們知道要做什麼產品」,重點是用 MVP 快速驗證市場接受度。設計思考更前一層:先確認「我們是不是在解對的問題」。對企業 AI 導入來說,多數錯誤發生在更前面那一層,還沒驗證問題對不對,就跳到「先做個 PoC 試試」。設計思考的同理與定義階段,正是補上這個前置缺口。

HR 在 AI 導入專案裡,能扮演什麼角色?

HR 可以扮演「定義問題的引導者」。多數企業 AI 失敗的根因是「業務沒主導、只有 IT 在做」,HR 剛好是組織內最熟悉跨部門協作流程的角色。一個具體做法是 HR 主動跨部門訪談 8–10 位使用者,把痛點整理成「個人 AI 技能診斷」報告,讓 IT 與業務有共同的問題敘述當對齊基準。這也是 HR 在 AI 時代從「行政」轉向「組織策略」的具體切入點。

預約一次 30 分鐘的「企業 AI 診斷」對焦會議,把你公司目前卡住的 AI 專案重新定義

推薦精選文章

📚 面對 AI 中階焦慮,Lyft CEO David Risher 給的是另一條路:重新發明這個位置

📚 Duolingo 把「有沒有用 AI」寫進考績,員工集體反彈後撤回,你的公司正準備做一樣的事嗎?

更多企業 AI 培訓服務:https://www.kvalley.biz/tcservice/digital/

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *

This field is required.

This field is required.