兩輪培訓、兩份寫著「聽得懂」的課後問卷,請款系統上線滿兩個月,申請人還是先在 Excel 填好再補登進系統,財務每週仍要核對兩邊的金額(以上為舉例)。檢討會的結論是培訓不夠深入、部門主管沒盯緊,下一季加開第三輪。這場檢討漏掉兩個一天內就能回答的問題:系統裡的供應商與預算科目資料是最新的嗎?送出一張申請單,要切換幾個畫面?前者屬於資料,後者屬於系統,Excel 補登也可能只是習慣。這兩題查完之前,沒人說得準第三輪培訓有沒有用。
數位專案失敗時,該先查什麼?MIT Sloan Management Review 2026 年 10 月刊出〈The Real Reasons Why Digital Projects Fail〉,作者 Curtis A. Merriweather Jr.(Duke 大學 Fuqua 商學院研究員)給的答案是資料品質與系統易用性,兩者要分開查,各需要自己的診斷與投資。文章綜整自他共同發表在 npj Digital Medicine 的論文,下文把它的邏輯轉成企業系統的診斷方法。
Merriweather 的觀察(刊於 MIT Sloan Management Review):數位專案失敗,組織幾乎一律先怪培訓和執行

Merriweather 在文章中寫道,數位投資表現不如預期時,組織幾乎一律把原因歸給執行問題、培訓不足或變革管理失敗。他認為,沒有分開查資料品質與系統設計,事後檢討就查不出真正原因,補救的錢花在錯的問題上,下一套系統接著表現不佳,又是一次誤診。
開場舉例裡加開第三輪培訓,走的就是這條路。跨部門協作也有同樣的誤診:把對齊問題當成溝通問題。
數位專案失敗該查哪兩處?那份醫師研究怎麼分資料與系統

研究團隊對 564 位美國醫師做問卷,涵蓋 32 個專科,分開衡量兩件事。資料可用性看電子病歷裡的資料,品質、完整性與情境相關性夠不夠支撐準確又有效率的臨床決策;系統易用性看醫師做醫療工作時覺得系統好不好用、有沒有用,以及與診療流程貼不貼合。
模型解釋了認知負荷變異的 34.1%,論文自己指出還有其他前因沒被納入,資料是一次性問卷,記錄的是主觀感受,沒有追蹤前後變化。Merriweather 在文章中主張,這些認知機制並非醫療獨有,這是他的判斷;論文只驗證了美國醫師與主流商用電子病歷,沒有測培訓的效果,報表、請款、排班這類企業系統也不在範圍內。本文只借用把問題拆成資料與系統兩種來查的做法,套用到企業系統的部分都是編輯推演。
資料問題與系統問題,讓使用者累在不同的地方

論文用認知負荷(做事時大腦要處理的量)來看這兩件事。資料可用性越高,醫師越能把心力放在有意義的資訊上,這是有益的負荷;系統易用性越高,越能減少花在操作介面上的多餘負荷。資料有問題時,使用者想不通眼前的數字能不能信;系統有問題時,使用者找不到下一步在哪。
| 資料可用性 | 系統易用性 | |
|---|---|---|
| 論文的發現 | 越高,越能促成有益的認知負荷(germane) | 越高,越能降低多餘的認知負荷(extraneous) |
| 報表、請款、排班系統裡的樣子 | 數字對不上、欄位空著、資料太舊 | 步驟多、畫面順序和現場工作不一致 |
資料變好之後,認知負荷其實會上升,這是論文裡反直覺的一點:使用者會花更多心力解讀有價值的資料。論文主張認知負荷要維持平衡,所以診斷時看到使用者很費力,先分辨力氣花在解讀資料,還是花在操作系統。
文章指出,這兩者運作的機制完全不同,失靈的方式也不同。假設排班系統的畫面重做得清爽,各門市回報的出勤資料仍有缺漏,主管照樣要打電話核對;反過來,資料全部校正完畢,排一次班卻要切換五個畫面,操作時間還是花在找功能上。
系統上線沒人用,歸咎員工之前先用五個問題診斷

診斷拆成資料三問與系統兩問,答案取自實際使用者做一遍任務的觀察。資料三問看內容齊不齊、新不新,欄位與決策有沒有關係,以及有沒有人另外維護對帳用的 Excel;系統兩問看完成一件常做的事要點幾步,流程順序貼不貼合現場。
| 編號 | 問題 | 怎麼查 | 過關的參考基準(編輯擬定) | 沒過關時指向 |
|---|---|---|---|---|
| 資料 1 | 畫面上的資料齊不齊、新不新? | 抽 10 筆最近的紀錄,對照原始單據或現場實況 | 10 筆裡需要人工補欄位或修正的,不超過 1 筆 | 資料:缺漏、延遲、重複 |
| 資料 2 | 每個欄位和實際要做的決策有關嗎? | 請使用者說出每個必填欄位「是為了決定什麼」 | 10 個必填欄位裡,答不出用途的不超過 1 個 | 資料:欄位與情境脫節 |
| 資料 3 | 使用者是否另外維護 Excel 對帳? | 看使用者的桌面與雲端資料夾,有的話問為什麼留著 | 3 位使用者都不需要另外建表,就能完成日常作業 | 資料或系統,追問原因才分得出 |
| 系統 1 | 完成一件常做的事要點幾步? | 請使用者從頭做一遍,數步驟、畫面切換與停下來找功能的次數 | 與上線前的做法比,步驟與畫面切換各多出不超過 2 個,停下來找功能不超過 1 次 | 系統:步驟過多 |
| 系統 2 | 流程順序貼合現場工作嗎? | 把系統的步驟順序和現場實際的順序並排 | 順序顛倒或需要來回跳的地方,不超過 1 處 | 系統:流程與工作脫節 |
基準數字可依自家系統的複雜度調整,診斷前先寫下來,結果出來時比較不會各說各話。
「大家都不用」太模糊,診斷前先追問到哪個動作、哪個環節、哪群人,追問的例子可看搞懂問題才是第一步。
資料 3 要追問原因。使用者留著一份 Excel,可能因為不信系統裡的數字,也可能因為在系統裡做同一件事太花時間,前者指向資料,後者指向系統。資料 2 答不出來,代表欄位和決策之間沒人負責對上,可參考數據蒐集到多少才夠先從業務目標反推的做法。
論文在醫療情境的做法可當修法參考:資料端去除重複紀錄、標示來源可信度、統一完整性規則;系統端合併任務流程,把關鍵資訊放進同一個畫面。
診斷完,培訓還要不要排?

數位專案失敗後,培訓要排,但排在診斷之後,而且只在確認使用者屬於不熟悉時才補課。資料或系統有問題時,先修那一邊,修完的版本才是培訓該教的內容;兩邊都過關、使用者仍做不出來,培訓才直接對症。
這份研究只提供一份先排除的原因清單。
| 診斷結果 | 先處理 | 培訓怎麼排 |
|---|---|---|
| 資料三問有未達基準的項目 | 補齊缺漏、清掉重複、指定資料負責人 | 修好後,教新的欄位定義與填寫規則 |
| 系統兩問有未達基準的項目 | 縮短步驟、調整順序 | 改版後,教新流程 |
| 兩邊都有未達基準的項目 | 分成兩條工作,各有負責人與驗收項目 | 兩條都修完再排 |
| 兩邊都過關,使用者做不出來 | 無需修改 | 補課,教材取自使用者最常做的任務 |
| 兩邊都過關,使用者會做卻不做 | 回頭看人的因素 | 課程之外的問題 |
最後一列已離開資料與系統的範圍,那是人的顧慮,談抗拒變革的那篇文章處理的就是這一層。補課需要外部講師時,可參考數位生產力培訓課程。
要試的話,挑一個使用率偏低的系統,找三位每週都會用它的人,各花半小時,請他們從頭做一遍最常做的任務。你只記錄哪一步停下來、哪個數字被懷疑、桌上有沒有另一份表,三份紀錄放在一起,對照上面的基準,五個問題大致都能回答。
FAQ
老闆說先加開培訓,我該怎麼回?
可以回:培訓照排,先給我一週做診斷,診斷結果決定培訓要教什麼。成本也並排給老闆看:前兩輪的人天(參加人數乘上天數)加講師費,對照診斷的三位使用者各半小時加整理紀錄的時間,數字請用自家帳目填。附上使用者操作的紀錄,預算比較容易花在對的內容上。
使用者只說「就是不好用」,講不出原因怎麼辦?
改成請他做一遍任務,你在旁邊記錄:停在哪一步、回頭修改幾次、切換幾個畫面、有沒有打開另一個檔案或打電話確認數字。這些紀錄直接對應診斷五問,可以取代「你覺得哪裡不好用」這類開放式提問。
只訪問少數幾位使用者,會不會誤判?
五問的目的是找出線索,用不到統計推論。少數幾位使用者的紀錄如果指向同一個卡點,就值得先處理;各說各話時再加人,並確認他們做的是同一類任務。需要對全體下結論時,再用系統後台的操作紀錄或抽樣核對補強。
資料和系統都由外部廠商維護,診斷結果怎麼交給對方?
把第幾個畫面、哪個欄位、哪一筆資料與原始單據對不上、做完一件事點了幾步,整理成一份清單,附上使用者操作時的紀錄。廠商拿到的是能重現的問題,比「員工覺得難用」更容易排進修改清單。
診斷該由 IT 做,還是使用部門做?
建議由使用部門的主管帶頭,IT 配合調出資料與操作紀錄。資料三問需要懂業務的人判斷欄位與決策有沒有關係,系統兩問需要看使用者實際操作。IT 單獨做時,檢查的範圍可能只到系統有沒有出錯,看不到使用者停在哪裡。
關於智谷
智谷網絡(Kvalley Network)自 1996 年創立,專注企業 AI 轉型與中高階主管培訓,累計服務 3,000+ 家企業、75,000+ 小時訓練執行時數、年度訓練 30,000+ 人次。
研究來源
- MIT Sloan Management Review 2026〈The Real Reasons Why Digital Projects Fail〉,Curtis A. Merriweather Jr.,2026-10-06
- npj Digital Medicine 2026〈When better data meets better design: How EHR data usability and system usability shape physicians’ cognitive load〉,Merriweather Jr.、Lyytinen、Aron、Cauley
CTA:想替團隊做一次系統上線後的診斷,和智谷聊聊你手上的專案


