CH4.2 AI導入規劃
AI導入規劃
導入規劃三原則（情境目的導向／資源盤點／彈性調整）→ 資源盤點三面向（人力角色／硬體資源／開發工具）→ 任務分解與時程設計（甘特圖／WBS／Scrum 短衝迭代／跨部門協作／任務追蹤工具）→ 三種導入模式比較（商業服務／內部開發／委外開發）→ POC 驗證流程（小範圍快速迭代）→ 規劃成果五大整合文件。
1. 導入規劃的核心原則
| 原則 | 內容 |
|---|---|
| 情境／目的導向 | 依產業特性與業務需求定義專案目標與範疇（零售聚焦銷售預測、醫療強調診斷輔助） |
| 資源盤點 | 評估現有資料、技術人力與預算，確保專案規模與資源匹配 |
| 彈性調整 | 因應需求改變或技術瓶頸動態調整時程與策略 |
導入規劃「無法採用一體適用的模式」——不同產業（製造業重視感測器即時性、金融業聚焦資料安全與法規遵循）、甚至同企業內不同部門，都需依實際情境調整優先順序與管理方式，而非套用固定流程。
2. 資源盤點與配置
(1) 人力資源角色
| 角色 | 主要職責 |
|---|---|
| 專案負責人（Project Manager） | 協調整體專案進度、制定時程、追蹤里程碑、解決跨部門衝突 |
| 資料工程師 | 資料收集、清理與整合，熟悉 ETL 流程 |
| AI 模型開發者 | 模型設計、訓練與優化 |
| UI/UX 設計師 | 設計使用者操作體驗 |
| 業務顧問 | 連結技術與業務需求，提供產業洞察 |
| 系統架構師 | 設計技術架構與部署方案，確保模型整合至現有系統 |
| 測試工程師 | 驗證模型效能與系統穩定性（如壓力測試） |
(2) 硬體資源
| 類型 | 適用情境 |
|---|---|
| GPU 伺服器 | 加速模型訓練與推論（如影像辨識、NLP） |
| 雲端平台儲存與計算 | 資料量大或需即時處理的應用，彈性擴展 |
| 本地運算設備 | 小型試辦或資料敏感性高的場景（如醫療病患資料） |
(3) 開發工具與框架
Python、TensorFlow、PyTorch（模型開發）；Spark、Hadoop（大數據處理）；Git（版本控制）。
3. 任務分解與時程設計
(1) 甘特圖（甘特圖, Gantt Chart）
以時間為橫軸、任務列表為縱軸的視覺化工具，呈現各項工作的時間安排、重疊區段與關鍵路徑（Critical Path）。常標示階段：問題定義與需求訪談 → 資料準備與標註 → 模型設計與訓練 → 驗證測試與反饋調整 → 部署與落地。
(2) 工作分解結構（WBS, Work Breakdown Structure）
由上而下拆解複雜任務為可控子任務，每一子任務需定義責任角色、預期成果、所需資源與預估時長。例如「資料準備」可拆解為：資料源盤點 → 資料清理 → 欄位標準化 → 欄位對齊與標註流程建立。
甘特圖與 WBS 常被混淆：甘特圖著重「時間軸與進度視覺化」（何時做、做多久、路徑重疊），WBS 著重「任務的階層式拆解」（把大任務拆成小任務並分派角色與資源）——兩者常搭配使用，WBS 拆解出的子任務再放入甘特圖排程。
(3) 短衝（Sprint）與 Scrum 敏捷開發
面對 AI 專案的高度不確定性，多採用敏捷開發（Agile），其中 Scrum 是最常見框架，特別適合 AI 原型開發與快速迭代。
三個角色：
| 角色 | 職責 |
|---|---|
| Product Owner（產品負責人） | 定義需求與優先順序，維護 Product Backlog |
| Scrum Master（敏捷教練） | 協助團隊遵守 Scrum 流程、移除障礙 |
| Development Team（開發團隊） | 跨職能成員，完成 Sprint 內開發任務 |
五個活動：Sprint Planning（短衝規劃）→ Daily Scrum（每日站會，約 15 分鐘）→ Sprint（固定週期開發，通常 1–4 週，常見 2 週）→ Sprint Review（展示成果）→ Sprint Retrospective（回顧檢討）。
三個產出（Artifacts）：Product Backlog（產品待辦清單）、Sprint Backlog（本次短衝任務清單）、Increment（可交付成果）。
Scrum 口訣：三角色、五活動、三產出。每個 Sprint 結束後固定跑「Review（展示）→ Retrospective（檢討）→ Planning（下一輪規劃）」的循環。
(4) 跨部門協作機制
協作流程設計（明確各部門責任範圍）、例行同步節奏（每週例會）、共用工具平台（任務看板 Jira/Trello、文件平台 Notion/Confluence、即時通訊 Slack/Teams）。
(5) 任務追蹤工具比較
| 工具 | 特色 | 適用情境 |
|---|---|---|
| Trello | 看板（Kanban）形式，卡片標註任務狀態 | 小型團隊或初期原型階段，簡單易用但缺乏進階功能 |
| Asana | 支援任務分層、時間軸檢視、跨專案整合 | 需跨部門協作的專案，設定初期較費時 |
| JIRA | 問題追蹤、工作流自訂、支援 Scrum/Kanban | 技術團隊主導（資料科學家/工程師），非技術人員學習曲線較高 |
| ClickUp | 結合看板＋結構化功能，支援檢查清單與里程碑 | 中型專案，功能全面但設定較複雜 |
任務追蹤工具 的選擇邏輯：團隊規模小、需求簡單→ Trello；需要跨部門/時間軸管理→ Asana；技術團隊導向、需要敏捷開發支援→ JIRA；功能需求全面、中型專案→ ClickUp。
4. AI 導入模式比較
| 模式 | 優勢 | 挑戰 | 適用情境 |
|---|---|---|---|
| 選用現有商業服務（Low-code/No-code） | 快速部署、技術門檻低、靈活性高 | 客製化彈性有限、長期訂閱成本高、資料隱私風險 | 技術能力有限或時間緊迫的企業 |
| 內部技術團隊開發 | 掌控力強、客製化程度高、保留技術自主性 | 需投入大量時間資源（人才/GPU/流程），初期成本高 | 具備長期 AI 發展計畫、技術人力與硬體資源充足的企業 |
| 委外開發 | 專業性與執行效率高，能縮短開發時程 | 需謹慎管理合約（交付範圍/時程）與資料安全風險 | 缺乏內部技術能力但有預算支持的企業 |
三種模式沒有絕對優劣，選擇依據是「企業自身的技術能力、資源限制與時間需求」——考題常以情境描述（如「某企業缺乏 AI 人才但預算充足」）要求判斷應選哪種模式（此例應選委外開發）。
5. POC 概念驗證技術與流程可行性
(1) POC 設計與目標設定
須設定明確、可量化的驗證目標（如「測試推薦模型是否能提升銷售 5%」），技術選型不必過於複雜（可用現成工具如 Google AutoML 快速建置原型）。流程涵蓋資料準備到模型測試全流程。
(2) 小範圍測試與多次快速迭代
POC 採小範圍測試與快速迭代（Rapid Iteration），每輪迭代設定具體目標並限制時間（如 1–2 週）。
驗證指標三類：
| 指標類型 | 內容 |
|---|---|
| 技術效能 | 準確率、延遲時間 |
| 商業價值 | 成本節省、效能提升、業務增長 |
| 使用者回饋 | 問卷、訪談了解可用性與操作體驗 |
6. 規劃成果整合（五大文件）
| 文件 | 內容 |
|---|---|
| 導入規劃文件（Implementation Plan Document） | 專案背景、目標、執行策略、範疇、任務、時程、團隊結構、預算需求——貫穿全程的核心文件 |
| 專案成果彙整報告（Planning Summary） | 關鍵決策點、初步原型成果、評估指標結果、團隊分工、風險預警，供高階主管快速掌握 |
| 甘特圖與時程規劃 | 視覺化階段、排程、里程碑、責任歸屬與資源分配 |
| 資源估算與成本預算表 | 人力/硬體/軟體/外部合作需求、資金來源、成本變動情境 |
| 利害關係人審查紀錄（Stakeholder Review） | 技術部門、業務單位、法務/資安、高階管理層的意見回饋與決議 |
規劃成果整合的目的是讓 AI 導入具備「清晰的執行依據與溝通基礎」，銜接下一階段的風險管理與系統部署——這五份文件是 CH4.1（評估）與 CH4.3（風險管理）之間的橋樑產出。
🗒️ 私人備註區
📝 章節考題自測（先作答，再點開解答）
Q1. 有關 AI 導入規劃的核心原則，下列敘述何者錯誤？
(A) 應根據產業特性與業務需求定義專案目標與範疇 (B) 不同企業應採用完全相同、一體適用的導入流程 (C) 應評估現有資料、技術人力與預算，確保專案規模與資源匹配 (D) 應因應需求改變或技術瓶頸動態調整時程與策略
解答與解析
參考 Ans: (B) 導入規劃無法採用一體適用的模式，需依產業特性、企業條件與組織文化彈性調整，(B) 敘述與課文核心原則相反。(A)(C)(D) 分別對應情境導向、資源盤點與彈性調整三大原則，皆正確。
Q2. 甘特圖（Gantt Chart）與工作分解結構（WBS）的主要差異為何？
(A) 甘特圖著重任務階層式拆解，WBS 著重時間軸視覺化 (B) 甘特圖著重時間軸與進度的視覺化呈現，WBS 著重將複雜任務由上而下拆解為可控子任務 (C) 兩者是同一種工具的不同名稱 (D) WBS 只能用於硬體採購規劃
解答與解析
參考 Ans: (B) 甘特圖以時間為橫軸呈現任務排程與關鍵路徑；WBS 則由上而下將複雜任務拆解為可控子任務並定義角色/資源/時長。兩者常搭配使用，(A) 描述恰好對調。
Q3. 在 Scrum 敏捷開發框架中，負責定義產品需求與優先順序、維護 Product Backlog 的角色為何？
(A) Scrum Master (B) Development Team (C) Product Owner (D) 專案負責人（Project Manager）
解答與解析
參考 Ans: (C) Product Owner（產品負責人）負責定義需求與優先順序、維護 Product Backlog；Scrum Master 負責協助團隊遵守流程並移除障礙；Development Team 負責實際完成開發任務。
Q4. 某企業缺乏內部 AI 技術人才，但有充足預算支持，且希望借助外部專業知識加速導入，最適合採取下列何種 AI 導入模式？
(A) 選用現有商業服務（No-code 平台） (B) 內部技術團隊開發 (C) 委外開發 (D) 完全不導入 AI
解答與解析
參考 Ans: (C) 委外開發適合「缺乏內部技術能力但有預算支持」的企業，能借助外部專業團隊的成熟經驗加速導入。(A) 較適合技術門檻要求低且客製化需求不高的情境；(B) 需要充足內部技術人力與長期發展規劃，與題目描述不符。
Q5. POC 測試過程中採用「小範圍測試與快速迭代」的主要目的為何？
(A) 一次性投入全部資源以求最快完成 (B) 不斷調整優化模型，使技術方案逐步對齊業務需求，並及早發現問題 (C) 避免收集任何使用者回饋 (D) 確保專案時程無限延長
解答與解析
參考 Ans: (B) POC 採小範圍測試與快速迭代（如每輪 1–2 週），逐步調整優化模型並對齊業務需求，及早發現問題與風險，而非一次性全力投入或忽略使用者回饋。
Q6. 下列任務追蹤工具與其特色的配對，何者錯誤？
(A) Trello：看板形式，適合小型團隊或初期原型階段 (B) JIRA：專為技術團隊設計，支援 Scrum/Kanban 敏捷開發 (C) Asana：支援任務分層與時間軸檢視，適合跨部門協作 (D) ClickUp：僅能用於財務報表製作，不支援任務管理
解答與解析
參考 Ans: (D) ClickUp 結合看板視圖與結構化功能，提供任務狀態追蹤、目標設定與即時協作，適合中型 AI 專案的任務管理，並非僅能用於財務報表製作，(D) 敘述錯誤。(A)(B)(C) 皆為正確配對。