L21202 AI 導入規劃
2導入規劃定位與核心原則
前言定位 + 產業差異 + 三大核心原則
2.1導入規劃的角色定位
| 面向 | 教材原文重點 |
|---|---|
| 角色定位 | 承上啟下的核心角色：在完成初步評估階段後，把「可行性與價值潛力」轉化為「具體可執行的規劃行動」 |
| 影響後果 | 規劃的質與量直接影響：① 後續技術部署的順利進行 ② 專案是否如期達成 ③ AI 導入是否能產生預期效益 |
| 策略性質 | 高度依賴組織條件與資源狀態，無法一體適用；需依產業、規模、治理文化、預算彈性調整 |
2.2產業 / 部門差異對照
| 維度 | 案例 A | 案例 B |
|---|---|---|
| 產業差異 | 製造業：更重視感測器資料的整合與即時性 | 金融業：聚焦於資料安全與法規遵循 |
| 部門差異 | 行銷部門：優先開發顧客行為分析模型 | 生產部門：專注於設備預測維護 |
2.3導入規劃三大核心原則
| 原則 | 內容 | 案例 |
|---|---|---|
| A. 情境 / 目的導向 | 根據企業產業特性與業務需求，定義專案目標與範疇 | 零售業聚焦銷售預測；醫療業強調診斷輔助 |
| B. 資源盤點 | 評估現有資料、技術人力與預算，確保專案規模與資源匹配 | 若資料品質不足，先投入資料整備，而非急於模型開發 |
| C. 彈性調整 | 因應專案推進中的變動（需求改變或技術瓶頸），動態調整時程與策略 | 原計畫三個月導入產能預測 → 發現感測器資料不完整 → 先花一個月優化資料收集 → 成功上線並提升產能效率 15% |
2.4本節定位與後續主幹
| 面向 | 內容 |
|---|---|
| 本節目的 | 介紹具代表性的導入規劃步驟與常見的專案管理工具與方法，作為企業制定自身策略的參考 |
| 決策原則 | 以組織條件為基礎，結合成本效益思維，做出最具可行性與契合度的決策，而非單純套用固定流程 |
| 三大主幹 | 3．-4．專案設計與管理（資源 + 任務）→ 5．三大導入模式選擇 → 6．POC 驗證與成果彙整 |
3資源盤點與配置（人力 / 硬體 / 工具）
七大人力角色 + 三類硬體 + 開發工具與框架
3.1人力資源 — 七大角色與職責
| 角色 | 核心職責 | 能力 / 技術需求 |
|---|---|---|
| ① 專案負責人 Project Manager | 整體專案協調與進度管理；制定時程計畫、追蹤里程碑、解決跨部門衝突、與利害關係人溝通 | PMP 認證等專案管理知識 + 跨團隊溝通能力 |
| ② 資料工程師 | 資料收集、清理與整合，從多來源萃取資料並轉換為可用格式 | 資料庫管理 + ETL 流程 |
| ③ AI 模型開發者 | 專注於模型設計、訓練與優化 | 機器學習與深度學習 + Python + TensorFlow / PyTorch |
| ④ UI/UX 設計師 | 若專案涉及使用者介面（如 AI 客服），需設計直觀的操作體驗，確保業務人員易於上手 | UI/UX 設計 |
| ⑤ 業務顧問 | 連結技術與業務需求，協助定義專案目標、提供產業洞察（如確認銷售預測模型的關鍵指標） | 產業 domain knowledge |
| ⑥ 系統架構師 | 設計技術架構與部署方案；規劃伺服器架構、資料流設計與 API 介接，確保模型整合至現有系統 | 雲端服務（如 AWS Lambda）+ 系統整合技術 |
| ⑦ 測試工程師 | 驗證模型效能與系統穩定性；執行壓力測試、檢查輸出是否符合預期 | 測試方法 + 即時反饋調整 |
3.2硬體資源 — 三類選擇
| 類型 | 代表 | 適用情境 |
|---|---|---|
| A. GPU 伺服器 | NVIDIA A100 GPU | 加速模型訓練與推論；適合影像辨識、自然語言處理等大運算需求 |
| B. 雲端平台 | AWS / Google Cloud / Azure | 彈性擴展的儲存空間與運算能力；適合資料量大或需即時處理的應用 |
| C. 本地運算設備 | 高效能工作站 | 適用於小型試辦或資料敏感性高場景（如醫療專案需在本地處理病患資料） |
3.3開發工具與框架
| 類別 | 常見工具 | 用途 |
|---|---|---|
| 程式語言 | Python | AI 開發主流語言 |
| 深度學習框架 | TensorFlow、PyTorch | 模型訓練與部署 |
| 大數據處理 | Spark、Hadoop | 資料處理與分析 |
| 版本控制 | Git 等源代碼管理工具 | 確保開發的高效與規範 |
4任務分解、時程設計與跨部門協作
甘特圖 / WBS / Scrum 三角五活三產出 / 跨部門 / 任務追蹤四工具
4.1甘特圖（Gantt Chart）
| 面向 | 內容 |
|---|---|
| 定義 | 以時間為橫軸、任務列表為縱軸的視覺化工具；呈現時間安排、重疊區段與關鍵路徑（Critical Path） |
| 五大標示階段 | ① 問題定義與需求訪談（1-2 週） ② 資料準備與標註（數週至數月） ③ 模型設計與訓練（依複雜度） ④ 驗證測試與反饋調整（多次迭代） ⑤ 部署與落地 |
| 實務案例 | 某零售業 AI 專案用甘特圖規劃三個月時程，發現資料準備與模型訓練階段重疊 → 提前調整資源 → 縮短整體時程 10% |
4.2工作分解結構 WBS
| 面向 | 內容 |
|---|---|
| 核心方法 | 由上而下的拆解方式，將複雜任務分割為可控的子任務，明確每一單元的執行細節 |
| 「資料準備」拆解範例 | ① 資料源盤點（確認可用資料來源與格式） ② 資料清理（移除缺失值與異常值） ③ 欄位標準化（統一資料格式與單位） ④ 欄位對齊與標註流程建立 |
| 每一子任務需定義 | ① 責任角色（如資料工程師） ② 預期成果（如清理後資料集） ③ 所需資源（如運算設備） ④ 預估時長（如兩週） |
4.3短衝（Sprint）與 Scrum 核心
| 類別 | 內容（教材鎖死數量） |
|---|---|
| 方法論定位 | 敏捷開發（Agile Development）的代表，特別適合 AI 原型開發與快速迭代階段，取代瀑布式開發 |
| Sprint 週期 | 固定週期，通常 1-4 週、常見 2 週 |
| 三大角色 | 職責 |
|---|---|
| Product Owner 產品負責人 | 定義產品需求與優先順序，維護 Product Backlog，確保開發內容符合業務價值 |
| Scrum Master 敏捷教練 | 協助團隊遵守 Scrum 流程與原則，移除障礙，促進團隊合作與持續改善 |
| Development Team 開發團隊 | 跨職能成員組成，負責實際完成 Sprint 內任務（資料處理、建模、測試、系統整合） |
| 五大活動 | 做什麼 |
|---|---|
| ① Sprint Planning 短衝規劃會議 | 決定本次 Sprint 要完成哪些任務 |
| ② Daily Scrum 每日站會 | 快速同步團隊進度與阻礙（通常 15 分鐘） |
| ③ Sprint 短衝 | 固定週期的開發節奏（1-4 週） |
| ④ Sprint Review 展示成果會議 | 展示 Sprint 成果、接受回饋（模型結果、Demo 畫面、系統整合介面） |
| ⑤ Sprint Retrospective 回顧檢討會議 | 內部自我反思，回顧過程問題與瓶頸，提出改善措施 |
| 三大產出 Artifacts | 內容 |
|---|---|
| Product Backlog | 產品開發待辦清單（全專案） |
| Sprint Backlog | 本次 Sprint 要完成的任務清單 |
| Increment 可交付成果 | 每次 Sprint 結束時的完整、可運作的產品版本 |
4.4跨部門協作三機制
| 機制 | 做什麼 | 典型工具 |
|---|---|---|
| A. 協作流程設計 | 明確各部門責任與任務範圍（資料提供、模型驗收、系統整合），避免重疊與漏洞 | — |
| B. 例行同步節奏 | 定期專案會議與進度報告（常見每週例會），即時處理阻礙 | — |
| C. 共用工具平台 | 任務看板 + 共用文件 + 即時通訊三類 | 任務看板：Jira / Trello；共用文件：Notion / Confluence；即時通訊：Slack / Microsoft Teams |
4.5任務追蹤四大工具對比
| 工具 | 核心特徵 | 適用情境 | 限制 |
|---|---|---|---|
| Trello | 看板（Kanban）形式 — 卡片標註狀態（待辦/進行中/完成）、負責人、截止日 | 小型團隊或初期原型階段；簡單易用、視覺化 | 大型專案缺乏進階功能（自動化、依賴管理） |
| Asana | 結構化 — 任務分層、時間軸檢視、跨專案整合、多負責人 | 需要跨部門協作的 AI 專案（如業務訪談、資料整合、模型部署分層管理） | 設定初期需花時間建立結構 |
| JIRA | 專為技術團隊；問題追蹤（Issue Tracking）、工作流自訂、支援敏捷（Scrum + Kanban）、優先級、預估工時、依賴關係 | 資料科學家與工程師主導的 AI 專案（追蹤模型訓練子任務） | 非技術人員學習曲線高 |
| ClickUp | 結合 Trello 看板 + Asana 結構化；Checklist + Milestone、即時協作、外部工具整合（Google Drive） | 中型 AI 專案（如預測維護系統，里程碑 = 模型準確率 80%） | 功能多 → 設定複雜度高 |
5AI 導入模式選擇（A / B / C 三模式）
商業服務 Low-code/No-code / 內部開發 / 委外開發
5.1三模式總覽對比
| 模式 | 誰來做 | 適合的企業 |
|---|---|---|
| A. 商業服務 Low-code / No-code | 使用現成 AI 平台（Google AutoML、ChatGPT 等） | 技術能力有限或時間緊迫的企業 |
| B. 內部技術團隊開發 | 企業內部團隊自行設計、開發、部署 | 具備技術人力與硬體資源，需高度客製化，有長期 AI 發展計畫 |
| C. 委外開發 | 外包給專業技術公司或顧問團隊 | 缺乏內部技術能力但有預算支持，希望加速導入 |
5.2A. 商業服務（Low-code/No-code）
| 面向 | 內容 |
|---|---|
| 優勢 ① 快速部署 | 無需深入開發即可使用現有平台訓練與部署，降低時間成本 |
| 優勢 ② 技術門檻低 | 不需深厚程式設計或數據科學基礎，企業輕鬆上手 |
| 優勢 ③ 靈活性 | 支援不同類型的業務情境，可根據需求選擇和調整 |
| 挑戰 ① 彈性有限 | 功能自定義選項有限 — Google AutoML 難以調整深層模型結構，ChatGPT 需額外資料整合才能服務特定業務情境 |
| 挑戰 ② 長期成本 | 通常基於訂閱計費，長期使用可能產生較高運營成本 |
| 挑戰 ③ 資料隱私風險 | 資料需經雲端服務處理，引發隱私與安全問題（特別是敏感資料） |
5.3B. 內部技術團隊開發
| 面向 | 內容 |
|---|---|
| 適用前提 | 具備技術人力與硬體資源，需高度客製化 |
| 優勢 | 掌控力強與適應性高；可根據業務需求調整模型結構與部署方式，保留技術自主性 |
| 劣勢 | 需投入大量時間與資源（招聘資料科學家、採購 GPU、建立流程），初期成本較高 |
| 正面案例 — 金融 | 某金融機構內部開發詐欺偵測模型，整合多源交易資料與客戶行為紀錄 → 準確率 95%，完全符合內部法規與安全要求 |
| 正面案例 — 製造影像 | 某科技公司內部開發影像辨識系統，針對產品缺陷深度優化 → 辨識率提升至 98%，大幅降低人工檢查成本 |
| 反面案例 | 某零售企業因缺乏 AI 人才，內部開發耗時六個月且成效不佳 → 顯示此模式需充足技術基礎為前提 |
5.4C. 委外開發
| 面向 | 內容 |
|---|---|
| 適用前提 | 缺乏內部技術能力但有預算支持，希望加速導入 |
| 優勢 | 專業性與執行效率；外部團隊具備成熟經驗與技術資源 → 縮短開發時程 |
| 風險 | ① 合約管理（交付範圍、時程約定） ② 資料安全（敏感資料外流） |
| 正面案例 — 製造 | 某製造企業委外開發設備預測維護系統，與技術公司合作六個月內完成部署 → 節省維護成本 15% |
| 正面案例 — 醫療 | 某醫療機構與顧問團隊合作開發病患診斷輔助系統，三個月內整合影像與病歷資料 → 準確率達 90% |
| 反面案例 | 某電商企業因未明確合約條款，委外開發的推薦系統延誤兩個月 → 調整合約細節才順利上線 |
6導入成果驗證與彙整（POC + 五份成果）
POC 設計 + 快速迭代 + 三類驗證指標 + 規劃成果 ABCDE
6.1POC 概念驗證定位
| 面向 | 內容 |
|---|---|
| POC 定義 | Proof of Concept — 企業在實際導入 AI 技術前，進行小範圍測試的重要步驟 |
| 核心目的 | 驗證特定技術或流程是否能有效運作，並檢視技術解決方案是否符合企業需求 |
| 聚焦範圍 | 通常專注於單一功能或情境，通過快速實施、測試並收集回饋 |
| 最終價值 | 辨識技術瓶頸、進行風險控制，為全面部署奠定基礎 |
6.2POC 設計與目標設定
| 面向 | 內容 |
|---|---|
| 目標設定 | 設定明確的驗證目標與範圍，幫助專注於可量化的成果 |
| 零售案例 | POC 目標：「測試推薦模型是否能提升銷售 5%」（教材鎖死數字） |
| 技術選型 | 不必過於複雜 — 可使用現成工具（如 Google AutoML）快速建置原型，節省開發時間 |
| 製造案例 | 進行 POC 驗證設備故障預測模型 → 資料收集 → 數據處理 → 訓練初步模型；通常數週時間確認可行性 |
6.3小範圍測試與快速迭代
| 面向 | 內容 |
|---|---|
| 核心方法 | 小範圍測試 + 快速迭代（Rapid Iteration），不斷調整與優化模型 |
| 迭代節奏 | 每次設定具體目標，限制每次迭代時間（1-2 週），快速調整並確認模型可行性 |
| 循環模式 | 每次迭代後評估與調整 → 快速發現問題並改進 |
6.4POC 三類驗證指標
| 指標類型 | 具體項目 | 用途 |
|---|---|---|
| ① 技術效能 | 準確率、延遲時間等 | 衡量模型本身的表現 |
| ② 商業價值 | 成本節省、效能提升、業務增長 | 量化 AI 技術帶來的實際效益 |
| ③ 使用者回饋 | 問卷、訪談等 | 了解模型的可用性和操作體驗 |
6.5規劃成果整合（ABCDE 五份輸出）
| 成果 | 內容 |
|---|---|
| A. 導入規劃文件 Implementation Plan Document | 彙整整體導入策略與規劃邏輯：背景、目標、執行策略、範疇、主要任務、時程、團隊結構、預算、資源需求；貫穿導入全程的核心文件 |
| B. 專案成果彙整報告 Planning Summary | 各子模組成果摘要：關鍵決策點、初步原型成果、評估指標結果、團隊分工、潛在風險預警；供高階主管快速掌握 |
| C. 甘特圖與時程規劃 Gantt Chart and Timeline | 視覺化呈現專案階段、任務排程、里程碑（Milestone）、責任歸屬、資源分配；掌握進度節點與潛在瓶頸 |
| D. 資源估算與成本預算表 — | 詳列人力、硬體、軟體與外部合作需求；預期支出項目、資金來源（自有 / 補助 / 外包）、時程分配、可能成本變動情境 |
| E. 利害關係人審查紀錄 Stakeholder Review | 關鍵部門或管理層審查（技術部門、業務單位、法務/資安、高階管理層）；記錄意見回饋與決議事項，作為進入實作階段的條件 |
AIONDAILY × 咖啡 AI 學 · iPAS AI 應用規劃師中級 · L21202 考前複習筆記 · v1.0（2026-05 表格化精簡版）