M10.02｜AI 專案規劃方法論
從需求分析到 ROI 計算 — 讓 AI 提案說服老闆、通過審核
本講學習重點
可行性三面向：技術可行性、商業可行性、組織可行性
ROI = (效益 - 成本) / 成本 × 100%，需考量直接與間接效益
需求訪談五類：痛點、頻率、資料、成功標準、風險容忍度
專案章程要素：目標、範疇、利害關係人、資源、時程、風險
適合 AI 的問題特徵：有大量歷史資料、規律性任務、人力處理瓶頸
SMART 原則定義成功標準：具體、可量測、可達成、相關、有時限
技術可行性≠商業可行性，技術上能做不代表值得做
🎙️ Podcast（中文）
一句話搞懂
AI 專案規劃方法論就是一套「問對問題、算清帳目、說服人心」的系統框架：在動手開發之前，先確認問題值得解決（需求分析）、解決得了（可行性評估），以及解決後能賺回多少（ROI 計算）。iPAS 考試最愛考這三個環節的判斷題與計算題，掌握它們不只能通過考試，更能在職場上讓你的 AI 提案脫穎而出。
白話解說
為什麼 AI 專案需要方法論？
根據 McKinsey 和 Gartner 的調查，超過 70% 的企業 AI 專案最終未能產生預期商業價值，不是因為技術不夠好，而是因為一開始就問錯了問題、或是沒做好可行性評估就倉促投入資源。
AI 專案失敗的三大根本原因：
- 問題定義不清：不知道要解決什麼，做出來的系統沒人用
- 可行性評估缺漏：技術上做得到，但組織沒有能力維運
- ROI 計算粗糙：效益預估過於樂觀，或成本計算漏項
這就是為什麼 iPAS 課程把「AI 應用規劃」列為核心科目 — 它考驗的是「策略性思維」而非技術能力。
第一步：需求分析框架
需求分析的目標是「把模糊的問題轉化為可解決的 AI 任務」。有效的需求分析包含五個層次的問題：
層次一：痛點確認
- 現有流程的哪個環節最耗時、最容易出錯？
- 這個問題每個月/年造成多少損失（金錢、時間、機會成本）？
- 這個問題是偶發性的，還是系統性的？
層次二：頻率與規模
- 這個問題每天/每月發生幾次？
- 有多少人受到影響？
- 如果用 AI 自動化，能節省多少工時？
層次三：資料盤點
- 是否已有歷史資料？數量多少？
- 資料品質如何（完整性、準確性、及時性）？
- 資料是否涉及個資或敏感資訊？
層次四：成功標準
- 達到什麼指標才算成功？（例如：錯誤率從 5% 降至 1%）
- 誰來判定成功與否？
- 試驗期（Pilot）的通過門檻是什麼？
層次五：風險容忍度
- 如果 AI 判斷錯誤，最壞情況是什麼？
- 組織能接受多高的錯誤率？
- 是否有人工複核機制作為後備？
第二步：可行性評估三面向
可行性評估是專案規劃中最關鍵的決策點，需要同時從三個面向評估：
技術可行性（Technical Feasibility）
- 問題類型是否適合現有 AI 技術？
- 訓練資料的數量與品質是否足夠？
- 技術團隊的能力是否能支撐開發與維運？
- 預估開發時程與技術複雜度？
商業可行性（Business Feasibility）
- 預期效益是否超過總成本？
- 投資回報週期合理嗎？（一般企業期待 12-24 個月回本）
- 競爭對手是否已有類似方案可參考？
- 法規環境是否允許此應用？
組織可行性（Organizational Feasibility）
- 高層主管是否支持？
- 組織文化是否能接受 AI 輔助決策？
- 是否有足夠的人才與預算？
- 使用者（end user）的接受度如何？
三個面向缺一不可。許多失敗案例都是「技術可行但組織不可行」— 系統開發完了，但員工拒絕使用，或管理層不願改變既有流程。
第三步：ROI 計算方法
ROI（投資回報率）是說服高層核准 AI 預算的最重要工具。
基本公式：
ROI = (總效益 - 總成本) / 總成本 × 100%
成本計算要素：
- 開發成本：人力、外包費、硬體採購
- 訓練成本：資料標記、模型訓練運算費
- 導入成本：整合現有系統、員工培訓
- 維運成本：每年雲端費用、模型更新、人力維護
效益計算要素：
- 直接效益（Direct Benefits）：節省人力成本、降低錯誤率減少損失
- 間接效益（Indirect Benefits）：客戶滿意度提升、品牌形象、員工士氣
- 策略效益（Strategic Benefits）：進入新市場、建立競爭壁壘
iPAS 考試常見計算範例： 某工廠導入 AI 品質檢測，開發成本 200 萬、年維運 30 萬，預估每年節省人力成本 120 萬、減少瑕疵品損失 80 萬。請問第 3 年底的累計 ROI 是多少？
解題步驟：
- 總成本（3 年）= 200 + 30×3 = 290 萬
- 總效益（3 年）= (120+80) × 3 = 600 萬
- ROI = (600 - 290) / 290 × 100% ≈ 107%
專案章程（Project Charter）的結構
AI 專案的規劃成果通常會整理成「專案章程」，是後續執行的基礎文件。標準的 AI 專案章程應包含：
- 專案目標：用 SMART 原則描述（Specific、Measurable、Achievable、Relevant、Time-bound）
- 問題陳述：現況是什麼、目標是什麼、差距是什麼
- 範疇界定：包含哪些功能、排除哪些功能（In/Out of Scope）
- 利害關係人：誰是贊助者、誰是使用者、誰是受影響者
- 資源需求：人力、預算、設備
- 里程碑時程：需求分析、資料準備、模型開發、測試、上線
- 風險登記冊：已知風險與對應的緩解策略
- 成功標準：量化的驗收指標
應用場景
| 場景 | 規劃重點 | ROI 計算重點 | 注意事項 |
|---|---|---|---|
| 製造業導入 AI 視覺檢測 | 技術可行性（影像品質）、資料收集成本 | 節省品管人力 + 減少瑕疵品損失 | 初期資料標記成本高，需納入計算 |
| 金融業信貸風險評估 | 法規合規性（PDPA、公平放款） | 降低壞帳率的直接效益 | 模型可解釋性是法規要求 |
| 零售業銷售預測 | 資料整合複雜度（ERP、POS） | 庫存優化節省的倉儲與損耗成本 | 季節性和促銷活動是資料偏差來源 |
| 客服 AI 聊天機器人 | 組織可行性（客服人員接受度） | 節省人力 vs. 維運成本 | 需保留人工轉接機制 |
| 醫療影像 AI 輔助診斷 | 法規（醫療器材軟體認證）、資料隱私 | 提升診斷效率 + 降低漏診率 | 不能完全取代醫師判斷 |
| 人資 AI 履歷篩選 | 公平性偏差風險評估 | 縮短招募週期節省成本 | 需定期稽核模型偏差 |
| 政府機關公文分類 | 組織可行性（流程再造）、資料品質 | 公文處理時效提升 | 跨部門資料整合是主要挑戰 |
常見誤區
誤區 1：「有了資料就可以開始做 AI」
很多人誤以為「有資料 = 可以做 AI」，但資料能不能用、夠不夠用，需要仔細評估。
資料可行性評估的四個關鍵問題：
- 數量夠嗎？ 簡單分類任務每類至少需要數百筆，複雜任務（如醫療影像）可能需要數萬筆
- 品質好嗎？ 缺值比例超過 20%、標籤錯誤率超過 5%，都會嚴重影響模型效果
- 有代表性嗎？ 訓練資料是否覆蓋所有可能的情況，還是有明顯偏斜
- 可以合法使用嗎？ 是否符合個人資料保護法（PDPA）的使用目的限制
忽略資料可行性評估，就像蓋房子沒檢查地基 — 表面看起來可以進行，但最終會倒塌。
誤區 2：「ROI 100% 就代表很划算」
ROI 是相對指標，必須結合回報週期（Payback Period）和資金機會成本一起判斷。
例如：兩個 AI 方案都宣稱 ROI 100%，但方案 A 需要 4 年才能回本，方案 B 只需要 18 個月就能回本。在企業的實際決策中，方案 B 通常更受青睞，因為資金周轉更快，且長期專案的不確定性更高。
此外，ROI 計算常見的陷阱是只算直接效益、漏算間接成本：
- 漏算員工培訓時間（停工損失）
- 漏算整合現有系統的改造成本
- 高估間接效益（「提升員工士氣」這類難以量化的效益不應列為主要支撐）
iPAS 考試偶爾會出現「以下哪個成本計算有誤」的類型題，要特別留意成本項目的完整性。
誤區 3：「需求訪談只要問使用者就好」
需求分析中一個常見的偏差是「只訪談直接使用者，忽略其他利害關係人」。完整的利害關係人分析應包含：
- 贊助者（Sponsor）：提供預算的高層，關心 ROI 和策略契合度
- 使用者（User）：實際操作系統的員工，關心易用性和工作量
- IT 部門：負責整合與維運，關心技術相容性和安全性
- 法律/合規部門：負責法規審查，關心資料使用合法性
- 受影響的相關部門：流程改變後會連帶受影響的其他團隊
每個利害關係人的關切點不同，需求訪談必須涵蓋所有關鍵群體，才能避免「技術做好了但被法律部門踩剎車」或「系統上線但使用者拒絕使用」的情況。
小練習
練習 1：ROI 計算（模擬考題）
某電商公司計劃導入 AI 退貨預測系統，相關數據如下：
- 系統開發費：150 萬元（一次性）
- 每年維運費：20 萬元
- 預估每年可減少的退貨處理成本：90 萬元
- 預估每年因精準預測庫存減少的損耗：30 萬元
請計算：(a) 第 2 年底的累計 ROI；(b) 大約幾個月可以回本（Payback Period）？
練習 2：可行性判斷（模擬情境題）
一家連鎖餐廳（50 間分店）想導入「AI 食材需求預測系統」，希望每週自動產生各分店的食材採購建議。已知條件如下：
- 有 2 年的各分店每日銷售紀錄（SKU 約 200 種）
- IT 系統是 10 年前的舊系統，無標準 API
- 分店主管普遍認為「自己最了解店裡需要什麼」，對 AI 建議持懷疑態度
- 老闆要求 6 個月內上線
請從「技術可行性」、「商業可行性」、「組織可行性」三個面向分析此案的主要風險。