AMMS Kickoff
本次會議目標
- 以「舊系統 + 現有 Dashboard + Agent 初步方向」啟動第一輪需求對齊
- 形成 AMMS v1 暫定範圍（必做/不做）
- 定義會後補件責任與時程
定位：探索型 Kickoff（不是最終規格審查）
快捷鍵：← → / Home End / F 全螢幕
目前已知輸入（可直接開始）
已具備
- 舊系統經驗與痛點
- Dashboard 原型（流程、告警、視覺）
- Agent 方向（先以 L1 問答助理）
尚未具備（會後補）
- 完整 PRD/SRS
- 正式 API/資料模型
- 最終合約與預算
英文名詞快速說明
會議與產品常見名詞
- Kickoff：專案啟動會，用來對齊目標、範圍、角色與時程。
- Dashboard：儀表板介面，集中顯示設備數據、告警、趨勢與報表。
- Agent：AI 助理模組，協助查詢、解讀、建議或執行動作。
- Stage-Gate：分階段推進，每一階段都要通過檢查點才能往下走。
開發常見名詞
- PRD：Product Requirements Document，產品需求文件，說明要做什麼與為什麼做。
- SRS：Software Requirements Specification，系統需求規格，說明系統功能、流程與限制。
- Wireframe：畫面線框稿，先確認欄位、按鈕、操作路徑，不談美術細節。
- API：系統介面規格，定義不同系統之間怎麼交換資料。
給同仁的簡單理解：Kickoff 是先講清楚「要解決什麼問題」；PRD / SRS / Wireframe / API 則是把需求逐步落成可開發、可驗收的文件。
現有 Dashboard 原型（完整頁面）
目前採「雙檔模式」：本投影片 + 完整 Dashboard 檔案，同資料夾即可直接展示。
從 Kickoff 到上線的完整流程框架
為什麼需要 Stage-Gate？
大型專案容易在某個階段才發現需求不清、技術不可行、成本超標，到時改動成本最高。Stage-Gate 就是在每個階段末尾都停下來檢查，確認品質與方向才往下走。
AMMS 的 5 個階段（務實時程）
⚠️ 注意：廠商尚未評選，以下為務實估算，每個 Gate 都可能影響後續時程。
| 階段 | 預估時間 | 主要交付 | Gate 檢查點 |
|---|---|---|---|
| Stage 0 Kickoff | 第 1 個月 （現在進行中） | 痛點確認、v1 範圍草案、PoC 計畫 | 有做/不做清單 + 決策紀錄 |
| Stage 1 需求定義 含廠商評選 | 第 1~3 個月 （約 6~8 週） | PRD/SRS v1、Wireframe、RFQ 詢標、廠商評估與合約 | 需求文件通過審核 + 廠商合約簽訂 |
| Stage 2 技術設計 廠商主導 | 第 3~5 個月 （約 4~6 週） | 架構圖、API 規格、資料模型、環境建置計畫 | 技術可行性確認 + 成本與風險可接受 |
| Stage 3 MVP 開發 Sprint 迭代 | 第 5~9 個月 （約 3~4 個月） | Staging 版本、Sprint 交付、整合測試、缺陷修復 | 核心流程可跑通，無 P1 Bug 待修 |
| Stage 4 驗收上線 | 第 9~12 個月 （視 Stage 3 而定） | UAT 完成、PoC 客戶驗證、正式上線 | 客戶簽核 + SLA 達標 + 維運手冊交接 |
記住這 3 個重點
- 不通過 Gate 就不進下一階段（補件、重新評估或改方向）。
- 每個階段的負責人與時程要清楚（誰審、審什麼、何時審）。
- 越後期的修改成本越高，所以前面的 Gate 要嚴格。
開發模式選擇（會議投票）
建議模式
外部開發 + 內部治理（研發主導、跨部門共創）
三種方式優缺點對照
| 方式 | 優點 | 缺點 / 風險 |
|---|---|---|
| 外部開發 + 內部治理 | 上線速度快、初期人力壓力較小、可借重外部實戰經驗 | 對供應商依賴較高，若交接文件不完整會提高後續維護風險 |
| 混合（部分自研） | 可逐步培養內部能力、關鍵模組可掌握在內部、風險較平衡 | 協作介面多，專案管理複雜度高，責任邊界需事先定義清楚 |
| 完全自研 | 技術與知識完全內部化、客製彈性高、長期自主性最佳 | 前期投入大、時程較長、若需求不穩定容易反覆重工 |
原因
- 縮短首版落地時間
- 避免先養大規模團隊再找需求
- 透過 SLA / 驗收 / 交接條款控制風險
SLA 是什麼？Service Level Agreement（服務水準協議），用來約定故障等級、回應時間、修復時間、可用率與違約處理。
- 驗收條件：功能是否達標（例如告警正確率、報表輸出、權限控管）。
- 交接條款：原始碼、部署文件、帳密權限、維運手冊、教育訓練是否完整移交。
我們要導向的結果（含維修/維運）
| 面向 | 目標範例 | 備註 |
|---|---|---|
| 服務可用率 | 月可用率 ≧ 99.5% | 排除已公告維護時段 |
| P1 故障處理 | 首響 ≤ 15 分鐘、修復 ≤ 4 小時 | 系統中斷或核心流程不可用 |
| P2 故障處理 | 首響 ≤ 1 小時、修復 ≤ 1 個工作天 | 部分功能受影響但可暫行 |
| 交接完整度 | 100% 交付文件與操作手冊 | 含權限、部署、備援、回復流程 |
重點：我們不只要「做出來」，還要確保「壞了能修、交接接得住、後續養得起」。
AMMS Agent 範圍（會議投票）
| 層級 | 定義 | 建議 |
|---|---|---|
| L1 | 查詢問答，不改系統設定 | Phase 1 |
| L2 | 提出建議，人工確認後執行 | Phase 2 |
| L3 | 可自動執行動作（高風險） | Phase 3 |
名詞補充
- L1：只回答問題或查資料，像智慧查詢員。
- L2：會提出建議，但仍需人工確認後才執行。
- L3：可直接執行動作，需完整權限控管與審批機制。
同仁要怎麼協助（本頁重點）
| 角色 | 請提供的內容 | 目的 |
|---|---|---|
| 業務 / 行銷 | 前 10 大常見客戶問題、常見場景與術語 | 建立 L1 問答題庫與回覆語氣 |
| 客服 / FAE | 常見故障排查 SOP、高頻錯誤碼、處理步驟 | 讓 Agent 回覆可直接用於第一線支援 |
| 研發 / SI | 可查詢的資料來源、欄位定義、權限邊界 | 避免回答錯資料或越權讀取 |
| PM | L1 不做清單、風險清單、驗收條件 | 控制範圍，避免需求膨脹 |
| IT / 資安 | 帳號角色、稽核需求、敏感資料規則 | 確保日誌可追溯、符合法規與內控 |
會後 3 個立即行動
- 3 天內收齊「Top 問題清單 + 現行 SOP + 術語表」。
- 1 週內確認 L1 範圍邊界（能回答 / 不能回答 / 需轉人工）。
- 完成 L1 驗收標準（命中率、錯誤率、回覆時間）後，再討論是否進 L2。
第一場（業務/行銷）預期輸出
先釐清：「v1 做 / 不做清單」是功能範圍清單（Scope），不是文件清單。重點是決定 v1 版本「哪些功能要上、哪些先不做」。
本頁要交付的 4 項輸出
| 輸出項目 | 至少要有的內容 | 資料來源 / 提供者 |
|---|---|---|
| Top 3 痛點假設 | 痛點描述、發生情境、影響（時間/成本/風險） | 業務訪談、客服工單、FAE 現場回饋 |
| v1 做 / 不做清單（功能範圍） | 必做 5~8 項、明確不做 5 項、每項理由（價值/風險/時程） | PM 主持，業務/行銷/研發共同決議 |
| 首批訪談名單 | 至少 5 家客戶、產業別、聯絡窗口、預計訪談時間 | 業務名單、既有客戶分級資料 |
| PoC 成功指標 | 時程、數量、KPI 門檻（如：告警縮短%、人工作業下降%） | PM + 業務 + 研發共同定義 |
同仁會後要收集的資料（Checklist）
- 近 3~6 個月客訴 / 工單 Top 問題（含發生頻率與影響程度）。
- 現行流程基準：告警到處理完成平均時間、報表產出時間、人工抄錄時數。
- 客戶端限制：部署限制（On-Prem/SaaS）、資安限制、資料保留需求。
- 關鍵角色名單：決策者、使用者、IT 窗口、驗收簽核者。
- PoC 候選場域：可快速驗證且願意配合的客戶與設備清單。
判斷是否可進下一步：若 4 項輸出都有負責人、時間點、可量化 KPI，就可進 Stage 1；否則先補件再進。
AMMS v1 功能候選（會議先有底）
以下是 建議版草案，目的是讓大家先有共同基準；最終仍以本次會議決議為準。
| 功能項目 | 建議 | 理由（給會議快速判斷） |
|---|---|---|
| Core Dashboard 核心監控 | ||
| 即時監控 Dashboard（核心點位） | v1 做 | 是使用者每天都會看的主畫面，價值高 |
| 設備/點位管理（新增、編輯、停用） | v1 做 | 基礎設定與維護，必須優先 |
| 多點位/多頁面 Dashboard 客製 | v1 做 | 支援不同角色（主管、現場、IT）快速切換 |
| 告警與通知管理 | ||
| 告警規則與通知（Email/Line） | v1 做 | 直接影響異常處理效率與客戶感受 |
| 告警分級與升級機制（L1/L2/L3） | v1 做 | 幫助優先處理，減少重要告警遺漏 |
| 告警 ACK / 關閉與事件追蹤 | v1 做 | 留下稽核紀錄，確認問題解決 |
| 數據查詢與報表 | ||
| 趨勢查詢與基本報表匯出 | v1 做 | 支援追因與內部匯報，屬高頻需求 |
| 日/週/月報自動生成與寄送 | v1 做 | 減少手工統計，提升決策效率 |
| 資料導出（CSV/Excel）與即時圖表 | v1 做 | 支援外部分析工具與簡報製作 |
| 權限、稽核與安全 | ||
| 角色權限（RBAC）與操作日誌 | v1 做 | 維運與稽核必備，避免權限失控 |
| 使用者帳號管理與群組指派 | v1 做 | 支援公司部門結構與職能分工 |
| Agent 模組 | ||
| L1 Agent 問答（查詢/說明） | v1 做 | 快速驗證 Agent 價值，風險可控 |
| L2 Agent 建議與人工確認流程 | 建議 v1.1 | 需先穩定 L1，再擴展建議能力 |
| 不做清單（延後或評估中） | ||
| L3 自動控制設備 | v1 不做 | 風險高，需先完成權限、審批與安全驗證 |
| 全面 ERP/MES 深度整合 | v1 不做 | 整合依賴多、時程不確定，先做必要串接 |
| 多語系完整在地化 | v1 不做 | 開發量大，可先英文/繁中，後續加多語言 |
| 行動 App（iOS/Android） | v1 不做 | 可先用 Responsive Web，驗證市場後再評估 |
| 預測性維護與 AI 異常偵測 | 評估中 | 需先有足量歷史資料與使用案例驗證 |
| Open API 與第三方整合 | v1 不做 | 需先確定內部流程穩定，再開放介面 |
本頁要確認的 3 件事
- 每個「v1 做」項目是否有對應負責人與交付時間。
- 每個「v1 不做」項目是否已說明延後條件（何時重啟評估）。
- 是否有任何高風險項目需要改成 PoC 先驗證。
各階段詳細時程與交付物
⚠️ 時程為務實估算，廠商評選與合約通常需要 6~10 週，不宜以天數（D+）規劃。
| 階段 | 務實時程 | 主要輸出 | Gate |
|---|---|---|---|
| Stage 0 Kickoff | 第 1 個月 | 範圍草案、功能候選清單 | 有做/不做清單 + 決策紀錄 |
| Stage 1 需求定義 含廠商評選 / RFQ | 第 1~3 個月 | PRD/SRS v1、Wireframe、廠商合約 | 每項功能有驗收條件 + 合約簽訂 |
| Stage 2 技術設計 廠商主導 | 第 3~5 個月 | 架構圖、API 規格、資料模型 | 技術可行 + 成本與風險可接受 |
| Stage 3 MVP 開發 Sprint 迭代 | 第 5~9 個月 | Staging 版本、Sprint 週報、整合測試 | 核心流程可跑通，無 P1 Bug |
| Stage 4 驗收上線 | 第 9~12 個月 | UAT 報告、PoC 驗證結果、正式上線 | 客戶簽核 + SLA 達標 |
名詞補充
- MVP：Minimum Viable Product，最小可行產品，先做能驗證市場與流程的最小版本。
- Staging：正式上線前的測試環境，用來做整合驗證與模擬操作。
- Sprint：敏捷開發的短週期工作單位，常見為 1~2 週一輪。
各階段要準備的文件
| 文件 | 用途 | 主要提供 / 協作 |
|---|---|---|
| Kickoff Package | 整理背景、目標、範圍、會議結論與待辦 | PM / 業務 / 研發 |
| PRD | 定義產品要解決的問題、使用情境、功能範圍與優先序 | PM / 業務 / 行銷 |
| SRS | 把需求寫成系統可實作規格與驗收依據 | PM / 研發 / 外部廠商 |
| Wireframe | 確認畫面流程、欄位與操作路徑 | PM / UIUX / 使用單位 |
| API / 資料模型 | 定義設備、系統、報表與告警資料如何交換 | 研發 / SI / 外部廠商 |
| UAT 計畫 | 定義驗收情境、角色、測試案例與通過標準 | PM / 使用單位 / QA |
會議上至少要先講清楚：誰提供資料、誰確認內容、哪一份文件是進下一階段的門檻。
Kickoff 後 D+5 ~ D+10 第一次提交
- AMMS Kickoff Package v1：會議摘要、範圍、角色分工、待補件清單
- PRD/SRS v1（含 Acceptance Criteria：每項功能怎樣才算驗收通過）
- Wireframe v1（主流程）
- Backlog v1（功能待辦清單，可開 Sprint 1）
- UAT 計畫 v1（驗收情境、測試案例、KPI）
即時決策（互動）
本次會議型態
第一場參與對象
決策摘要（可截圖作會議紀錄）
結語
先對齊，再開發；先驗證，再擴張。
- 第一場先收斂市場假設，不求一次定案
- 第二場再做技術可行性與時程校正
- 未通過 Gate，不進下一階段
1 / 15
AMMS Kickoff Deck · Single HTML