洞察 01
數碼轉型與 AI 轉型，不是同一件工作
把 AI 項目當成系統上線來規劃，你會漏掉那個真正要緊的風險——直到東西已經做好，而且安靜地出錯。
現在人人都在講「AI 轉型」。有一半的情況，那其實只是換了個標誌的數碼轉型。
這不是小小的用詞混淆。如果你按照系統上線的方式去規劃一個 AI 項目，你會漏掉那個真正要緊的風險——而且在東西做好、並且安靜地出錯之前，你不會發現。
以下是兩者重疊的地方，以及不重疊的地方。
相同的部分
大部分流程是一樣的。把「AI」這個標籤拿掉，底下的骨架就是一個再普通不過的轉型項目：
| 共同點 | 為什麼兩者都適用 |
|---|---|
| 從業務問題出發，而不是從工具出發 | 兩者都不該從「我們來用 X 吧」開始，而是從什麼卡住了、什麼太慢開始 |
| 需要高層支持 | 沒有一位能解開預算與內部政治的負責人，兩者都會停擺 |
| 變革管理無法迴避 | 不論工具是新的 ERP 還是新的 AI 助理，人都會抗拒新的工作方式 |
| 成功看成果，不看上線 | 「我們裝好了」在兩者都不算成功，被採用、有影響才算 |
| 分階段推進勝過一次到位 | 小規模試點、驗證價值、再擴大，兩者的標準做法 |
| 數據質素是地基 | 壞數據會毀掉一次 CRM 遷移，也會同樣毀掉一個 AI 模型 |
| 上線之後仍需支援 | 兩者都不是「做完就走」，都需要上線後的支援機制 |
如果你的 AI 項目跳過了上面任何一項，那不是什麼特殊的 AI 問題——那是基本的轉型問題，它一樣會拖垮一次 CRM 遷移。
真正分歧的地方
這一段最常被略過，而它正是讓人付出代價的那一段。
| 數碼轉型 | AI 轉型 | |
|---|---|---|
| 核心技能 | 系統整合、流程再造 | 提示設計、模型評估、數據就緒度 |
| 「專家」是什麼意思 | 懂那套軟件（SAP、Salesforce、雲端遷移） | 懂一個模型能穩定做到什麼、做不到什麼 |
| 規劃能力 | 路線圖、變革管理、持份者對齊 | 同樣需要，再加上判斷 AI 在哪裡真有價值、哪裡只是熱鬧 |
| 建置能力 | 配置與整合既有系統 | 圍繞一個機率性工具來設計——測試、護欄、人在迴路 |
| 風險能力 | 項目風險與供應商風險 | 模型風險——幻覺、偏誤、數據外洩、過度依賴 |
| 驗證能力 | 用戶驗收測試，對照規格簽署 | 持續評估——輸出質素會漂移，每次執行也可能不同 |
| 組織能力 | 訓練員工使用新工具 | 訓練員工與一個不確定、會變動的工具共事 |
| 時間尺度 | 項目有結束日期 | 永遠沒有真正做完——模型與最佳實務一直在動 |
| 失敗的樣子 | 超支、沒人採用 | 自信地給出錯誤答案，質素無聲衰退 |
最要緊的是最後一行。一次失敗的系統遷移是吵鬧的——它會壞掉、有人會發現、然後被修好。一次失敗的 AI 上線可以是安靜的。它繼續運作，繼續給出答案。其中有些就是錯的，而除非你一開始就把「盯着看」這件事養成習慣，否則沒有人在盯。
大家會跳過的那一段
每個人都想談怎麼做。幾乎沒有人想談在動手之前先證明這東西行得通——因為那一步的結論可能是「別做」，而這在進度報告上看起來不像進展。
但那正是 AI 轉型真正不同的地方。你不是在整合一套已知的系統。你是在決定要不要信任一個可能「很有信心地出錯」的工具，而唯一的判斷方式，是在它變成關鍵環節之前，拿真實的工作、真實的人去測試它。
跳過那一步，你做的就不是 AI 轉型。你做的是加裝了 AI 功能的數碼轉型——同一套紀律，錯誤的風險模型——而這個落差，要到代價很高的時候才會顯現。