AI 專案別急著登月：6,200 萬美元的 Watson 教訓，中小企業該先摘哪顆果實？
陳泳睿（Yung Chen） AI 筆記｜2026-10-20
「同業都在講 AI，廠商也來簡報好幾次，我們是不是該做一個大的？」
這句話，相信不少老闆心裡都問過。這個「大的」，通常是一套從排程、品質到報價全包的 AI 平台，預算一開就是一大筆。問題是，做大的就一定比較快嗎？還是只是比較好向董事會交代？
Thomas H. Davenport 在《The AI Advantage》（MIT Press，2018）裡講得很直白：很多公司是被高層、董事會，甚至某家廠商推著去做 AI 專案，有些企業已經在技術和顧問的選擇上吃過虧。他在書裡放了兩個正反對照的案例，加上一份 152 個 AI 專案的分析，我覺得很適合拿來回答上面那個問題。
一場被寄予厚望的「登月計畫」
2011 年 2 月，IBM Watson 在美國益智節目《Jeopardy!》把人類冠軍打得毫無招架之力。題目又刁鑽、又愛玩文字遊戲，AI 照樣贏。Davenport 推測，或許就是這場勝利，讓很多組織開始相信 AI 什麼都能解，連癌症也可以。
2012 年 3 月，IBM 先和紐約的 Memorial Sloan Kettering 癌症中心合作。2013 年 10 月，它的老對手、休士頓的 M.D. Anderson 癌症中心也宣布，早在前一年就和 IBM 簽約，以 Watson 為核心開發「腫瘤專家顧問」（Oncology Expert Advisor，OEA）。這個專案被列進醫院的「登月計畫」（Moon Shot Program），執行長全力支持，還拿到一位亞洲富豪 5,000 萬美元的捐款，另外請了顧問協助導入。
宣布後才一個月，醫院部落格就訪問了一位白血病研究人員，說得好像白血病的問題幾乎已經解決了。但進度並不如預期，媒體形容這是「送 Watson 去讀醫學院」，《華爾街日報》甚至引述 IBM Watson 部門主管的話，說這個專案在 2013 年就已經「卡在溝裡」。
依 Davenport 書中的整理，2016 年 11 月，德州大學系統的稽核室發布報告：OEA 已經花了 6,200 萬美元，卻尚未投入臨床照護使用；它沒有和醫院的電子病歷系統整合，專案管理與會計作法也有問題。專案無限期擱置，專案負責人 2015 年就已經離開，報告出來幾個月後，執行長也請辭。
Davenport 以「從醫學院休學」比喻這段挫折。這裡談的是臨床落地未完成，不能理解為專案完全未做過研究或測試。
同一家醫院，另一個角落
有意思的是，在 OEA 燒錢的同時，醫院資訊長 Chris Belmont 帶著 IT 部門做了幾個「小」專案。一個是幫病人家屬推薦飯店和餐廳的「照護禮賓」（care concierge），一個是找出哪些病人最需要繳費協助，還有一個處理員工電腦問題的自動化服務台。
這些專案便宜、低調，稽核報告還特別指出，IT 部門幾乎沒有參與 OEA。但就是這幾個小專案，讓病人滿意度和醫院財務表現都往上走，照護管理師每天繁瑣的資料輸入也少了。醫院後來沒有放棄 AI，反而著手建立專責的能力中心（center of competency）繼續往下做。
同一家醫院、同一個年代的技術，一邊未實現預期的臨床落地，一邊默默賺到效益。差別在哪？我認為在野心的大小，以及專案有沒有長在既有的流程上。
新加坡星展銀行：踩過坑之後，改摘低垂的果實
如果您覺得醫院離製造業太遠，再看一個商業案例。
新加坡的星展銀行（DBS）是東南亞最大的銀行，2016 年被《Euromoney》評為全球最佳數位銀行。它也是最早和 IBM 簽約開發 AI 應用的企業之一，2014 年 1 月宣布要用 Watson 做一套智慧理財顧問（robo-advisor），把研究報告、公司新聞、市場情緒和客戶持股全部吃進去，再給理專和客戶建議。
結果呢？資訊長 David Gledhill 事後坦白，當時技術還不成熟，軟體看不懂大量的圖表，各種格式的研究報告也得靠人工大量介入。做出來的試行版，效果連一般理專的一半都不到，他們很早就喊停。
所幸，星展沒有因此放棄 AI，而是把力氣放在「沒那麼野心勃勃、但很重要」的營運問題上。書裡列了幾個成果：
用機器學習預測 ATM 什麼時候要補鈔，原本平均每三個月會缺鈔一次，現在平均五十五年才會缺一次，補鈔趟次也減少超過 10%。
人資部門預測業務人員的離職，三個月內會不會走，準確度達 85%。
整家銀行用 AI 處理客戶互動之後，打進客服中心的電話量少了 15%。
Gledhill 對這段轉折的說法，我很認同：這些專案單獨看都不大，加總起來卻是轉型，帶來的是更低的營運費用、更高的員工生產力、更少的錯誤和更快的上市速度。他也強調，主要目標從來就沒有放在裁員，而是讓客戶體驗更好。
您可能會說，那是因為他們不夠強。Davenport 拿出 Amazon 當對照：無人機送貨、無人商店 Amazon Go，這些都是看得見的登月計畫，而且以 Amazon 的人才和資源，最有機會做成。
但 Jeff Bezos 在 2017 年給股東的信裡卻說，Amazon 用機器學習做的事情，大多發生在水面下：需求預測、搜尋排序、商品推薦、詐欺偵測、翻譯……這些看不太到，卻在默默改善核心營運。
書裡還引了兩句話，我覺得放在一起看特別有感。一句是 Amara 定律：我們總是高估一項技術的短期影響，卻低估它的長期影響。另一句是 Kevin Kelly 2014 年的說法：AI 會像電力一樣，平常看不見、也很無聊，卻在背後改變一切。
152 個專案告訴我們：最多的，是最「無聊」的那一類
Davenport 和 Deloitte 的團隊分析了 152 個 AI 顧問專案。這些專案發生在 2016 到 2017 年，大多在北美，分析時間是 2017 年年中。他把企業的 AI 應用分成三類。
最多的是流程自動化（Process Automation），71 個，佔 47%。像是把 email 和客服系統裡的資料搬進核心系統、自動補發遺失的信用卡、從合約裡抓出條款。這類專案多半用 RPA，是最便宜、最好導入的自動化技術，投資報酬又快。美國太空總署（NASA）就做了四個 RPA 試點，人資那一個有 86% 的交易完全不需要人介入。另外，這 71 個專案裡，以裁員為主要目標或結果的很少。
其次是認知洞察（Cognitive Insight），57 個，佔 37%，也就是用機器學習在大量資料裡找規律、做預測。書裡的例子包括分析保固資料找出汽車和製造業產品的品質問題，以及收集感測器資料預測機台什麼時候會故障。
最少的是聊天機器人、智慧客服這類認知互動（Cognitive Engagement），24 個，佔 16%。原因很實際：技術還不夠成熟。書裡提到，Facebook 在 2017 年發現，它的 Messenger 聊天機器人有 70% 的客戶需求沒辦法在沒有真人介入下回答。
圖 1｜152 個企業 AI 專案：三大類別與書中例子、產業與職能分布
換句話說，聽起來最有未來感的那一類，在實務上反而最少；佔最多的，是後台那些沒人想上台報告的苦工。Deloitte 同一年的調查也一樣，企業導入 AI 的目標裡，「用自動化減少人力」是最少人選的一項。
對製造業最有用的兩段話
這 152 個專案的分析裡，有兩段話跟我們工廠特別有關。
第一段在講 RPA。顧問 David Brain 認為，幾乎每一個 RPA 專案都得先做流程設計，因為很多公司內部對流程的理解程度很低，就算有一疊 SOP，也常常寫得不清楚、早就過時。這跟我在書裡寫傳承接班時描述的狀況一模一樣：SOP 在檔案櫃裡，真正的作法在老師傅腦袋裡。
第二段在講預測。想用感測器資料預測機台什麼時候故障，前提是手上要有足夠多「真的壞過」的紀錄讓模型學，這叫做監督式學習（Supervised Learning）。也就是說，想做異常預警，得先把異常好好記錄下來、分類清楚，買一套軟體並不會自動解決這件事。
兩段話放在一起，對製造業來說順序就很清楚了：先把流程和知識理順，再談預測。
我在《職場進化！生成式 AI 工作流》裡提過「點-線-面-體」四層模型：點是個人效率，線是流程與管理，面是平台與知識，體是整個產業生態。
M.D. Anderson 的 OEA 和星展的智慧理財顧問，都是想從零直接跳到「面」。資訊長那幾個小專案、星展的 ATM 補鈔預測，則是一條「線」一條「線」地把 AI 嵌進既有流程。
Davenport 給大多數企業的建議也是這樣：在同一個業務領域，做一系列野心沒那麼大的應用，每個專案風險都低，累積起來卻能對事業產生實質影響。他舉車險理賠為例。登月版本是客戶用手機拍照上傳，AI 立刻估價並把錢匯進帳戶，難度可想而知。務實版本則拆成幾個小專案：用深度學習判斷修車廠照片裡車架有沒有受損、做一個應用詢問車主並推薦修車廠、再用機器學習評估詐保風險。
換到線束廠：品質這條線，可以這樣疊
換到製造業，就是在同一條「線」上疊台階。我用書裡寫過的品質工具，把線束廠的品質線排成三階。
第一階，先把「人為疏忽」問到底。書裡用過「接線端子脫落」的例子：用 5 個為什麼（5 Whys）的教練式 Prompt，一層一層往下問，從「操作員沒有確實施力」問到「SOP 沒有明確的檢核點」，再問到「開發時沒把端子定位列為關鍵品質控制點（KCP）」、「工程變更缺乏跨部門風險評估」，最後收斂到「品質管理系統在變更控制上的規章不夠嚴謹」。根因從人，收斂到制度。問題比較複雜時，再搭配 8D 報告和 6M 特性要因圖，把團隊的「猜」變成「查」，再變成「證」。
第二階，把老師傅的經驗變成文件。書裡設計了一份「資深知識工程教練」Prompt，讓 AI 用「複述、釐清、追問」的方式訪談老師傅，最後一次產出六份知識套件：結構化資料（knowledge_pack.yaml）、SOP、關鍵工藝檢核表、故障排除樹、流程圖原始碼和培訓課綱。如果平台支援語音，讓老師傅直接用講的，效果更好。這一步剛好補上 David Brain 講的那個洞：SOP 不清楚、早就過時。
第三階，才是異常預警。前兩階累積下來的 5 Whys 紀錄、8D 報告和更新過的檢核表，就是模型要學的「標註過的異常」。沒有前兩階，第三階的模型連教材都沒有。 實際建模仍需將紀錄連結到批次、時間、設備與正常樣本，檢查標註品質，再以獨立資料驗證；文件累積本身不等於已具備可用的訓練集。
圖 2｜線束廠品質線三階路線圖：輸入、AI 做法、輸出、追蹤指標與建議節奏（示意）
每一階都能單獨看到效果，也替下一階準備好資料和人。也就是星展資訊長 Gledhill 說的，單獨看都不大，加總起來卻是轉型。
什麼時候才適合登月？
Davenport 並沒有全盤否定登月。他認為少數情況下可以一次到位，但這幾個條件要同時成立：技術成熟且經過驗證、組織已經累積很多 AI 經驗、曾經成功推動大型 IT 轉型、高階主管完全站在同一邊、組織擅長推動流程與行為的改變，而且承受得了高風險。
圖 3｜該不該登月：六個條件自我檢核表
老實說，台灣大多數中小企業對照完這六條，應該會默默把登月計畫收回抽屜。這不丟臉。連資源數一數二的 Amazon 都說，機器學習的影響大多在水面下；星展銀行也是踩過坑之後，才在低垂的果實上看到成果。
我的建議很簡單：先別問「我們要不要做一個大的 AI 專案」，改問「哪一條流程，明天就可以讓 AI 幫上忙」。從製造財走向管理財，靠的是一條一條把流程理順，不是一次押寶。
您公司的第一顆低垂果實，會是哪一條線？
參考資料與閱讀定位
Thomas H. Davenport，《The AI Advantage: How to Put the Artificial Intelligence Revolution to Work》，MIT Press，2018。Ch.1，p.1–7（Watson、DBS、Amazon）；Ch.3，p.39–46（152 個專案、流程自動化、預測與互動）；Ch.4，p.63、92–94（策略與登月條件）。數據及歷史敘述依原稿所附書籍定位整理。
陳泳睿，《職場進化！生成式 AI 工作流》：序言、1.1、3.1、4.1–4.3。涵蓋點線面體、管理財、知識傳承、5 Whys、8D 與 6M。圖表為原稿提供之自製整理；圖中節奏為示意，並非實績承諾。
留言