一套工具搞定：分階段策略 × 廠商評分 × Function List × 決策投票
📅 時間：2026-04-16 | 📍 地點：會議室 | 🎯 3 項待決議
🎤 預計耗時 90 分鐘 | 先進行前次會議後 Action Item 簡報，再依下方導航卡片進行決策討論
| 名詞 | 中文 / 全名 | 跨部門會議說明 |
|---|---|---|
| OT | Operational Technology / 營運技術 | 指現場感測器、控制器、設備通訊與工業場域運作相關技術，不是一般辦公 IT 系統。 |
| IT | Information Technology / 資訊技術 | 指伺服器、資料庫、帳號權限、網路與雲端系統等企業資訊能力。 |
| SRS | 系統需求規格書 | 把功能、流程、介面、資安與驗收條件寫清楚的正式文件，後續發包以此為準。 |
| RFI | 資訊徵詢書 | 需求尚未完全定稿時，先向候選廠商蒐集能力、案例、支援規格與可行做法。 |
| RFP | 廠商提案需求書 | 發給候選廠商的需求文件，用來請廠商回覆方案、交期與報價。 |
| SLA | 服務等級協議 | 約定系統可用率、故障回應時間、修復時限等服務承諾。 |
| API | 應用程式介面 | 系統與系統交換資料的接口，後續串接 ERP、APP 或第三方平台都會用到。 |
| POC | 概念驗證 | 先做小範圍驗證，確認技術可行，不代表已進入正式上線。 |
| Edge | 邊緣運算 | 資料先在現場設備或閘道器處理後再上傳雲端，可降低延遲與斷線風險。 |
| 階段 | 時間（預估） | 範圍 | 關鍵交付 |
|---|---|---|---|
| Phase 1A | Q2-Q3 2026 （3-4 個月） |
穀倉溫度監測基礎系統 | 多點溫度感測整合、本地監控 UI、警報功能 |
| Phase 1B | Q3-Q4 2026 （2-3 個月） |
穀倉多參數擴展 | 濕度、CO₂ 感測器整合、雲端初版、多廠區支援 |
| Phase 2 | 2027 (另開 Kickoff) |
其它產業擴展（尖樓、飼料槽等） | 以相同 Kickoff 模式另行召開，重新評估廠商、範圍與預算 |
| Phase 3 | 2027 (另開 Kickoff) |
量測管理跨場域擴充 | 以相同 Kickoff 模式另行召開，整合多場域量測管理 |
是否同意：今年（2026）完成 AMMS 穀倉儲，其它產業及量測管理明年（2027）另開 Kickoff？
💡 說明： 下方先說明 A 到 G 各評分維度，再由會議現場直接調整各維度權重，以及每家廠商 A 到 G 的分數（1-5 分）。
系統會即時計算加權總分，供跨部門會議當場比較與記錄。
| 代號 | 維度 | 會議判斷重點 |
|---|
| 廠商 |
|---|
是否接納上述廠商評分表作為主線廠商推薦依據？
| 面向 | 說明 |
|---|---|
| 流程 | 研發 → 廠商尋找 → 需求溝通 → 報價 → 簽約 → 開發 |
| 優勢 | 時程短（立即簽約）、成本透明、責任單一 |
| 風險 | ⚠️ 內部規格不清 → 廠商無從理解 → 返工或交期延誤 |
| 適用 | 需求清晰、廠商經驗豐富 |
| 面向 | 說明 |
|---|---|
| 流程 | 多家 RFI（2-4 家） → 判斷是否需顧問協助收斂 → 定版 SRS / RFP → 廠商提案與報價 → 開發與驗收 |
| 前段工作 | 先用同版 RFI 蒐集候選廠商的整合能力、案例、感測器建議、維運方式與風險假設；若內部仍無法收斂，再引入顧問協助定稿 SRS / RFP |
| 優勢 | ✅ 避免過早被單一廠商帶方向 → 保留顧問導入彈性 → RFP 較中立 → 便於多家廠商公平對標 |
| 成本 | RFI 階段以內部主導為主；若確認需要顧問，再追加顧問費 15-25 萬 NTD，後續另計廠商開發費用 |
| 時程 | 比直接委外多 2-6 週；若再導入顧問，整體時程再增加約 1-2 個月，但可控性較高 ⭐⭐⭐⭐⭐ |
採用 Plan A（直接廠商）還是 Plan B（多家 RFI → 視需要顧問 → 定版 RFP）？
此清單將成為 Phase 1 SRS 設計基礎與 Phase 3 驗收標準
| 功能項 | 優先級 | Go 判定準則 |
|---|---|---|
| 支援私有雲、混合雲部署 | Must Have | 可提供架構設計方案 & 案例 |
| 邊緣運算 (Edge Computing) 支援 | Should Have | 有邊緣 Gateway 產品 & 商業案例 |
| 單一平台管理多廠區 / 多儲倉 | Must Have | 可管理 ≥10 個廠區，有大規模部署案例 |
| 功能項 | 優先級 | Go 判定準則 |
|---|---|---|
| 多點位溫度感測線（EST10000 或同級品） | Must Have | 相容或支援客製化集成 |
| 濕度計整合（Vaisala、Dräger 等） | Should Have | 支援 Modbus RS485 協議集成 |
| 協議支援（Modbus RTU / TCP、MQTT、OPC-UA） | Must Have | 至少支援 Modbus RTU + TCP，有官方文檔 |
| 功能項 | 優先級 | Go 判定準則 |
|---|---|---|
| NoCode ETL（圖形化流程設定） | Should Have | 有完整圖形化 UI 示範、無需寫代碼 |
| 即時警務（Email/SMS/App 推播） | Must Have | 可客製警報規則、多通道消息送達 |
| 數據對齊（多來源時間戳同步） | Should Have | 可處理不同感測器更新頻率，支援時間戳對齊 |
| 歷史存檔與匯出（CSV/Excel） | Must Have | 至少保留 1 年資料，可按條件查詢與匯出 |
| 功能項 | 優先級 | Go 判定準則 |
|---|---|---|
| 異常偵測（溫度/濕度趨勢） | Should Have | 有 ML 模型示範，非僅固定門檻警報 |
| 趨勢分析儀表板 | Nice to Have | 可呈現分層溫度梯度、季節性變化與比較圖 |
| 模型管理（版本與回滾） | Nice to Have | 模型版本可追蹤，支援更新與回滾 |
| 功能項 | 優先級 | Go 判定準則 |
|---|---|---|
| RBAC 權限控管（角色分級） | Must Have | 至少具管理員/操作員/檢視員三層權限 |
| TLS 加密與安全通道 | Must Have | 支援 TLS 1.2+，遠端連線具安全機制 |
| 稽核日誌（操作可追溯） | Must Have | 可查詢誰在何時做了哪些變更 |
| 自動備份與災損復原 | Should Have | 具備備份排程與 RTO/RPO 目標說明 |
| 功能項 | 優先級 | Go 判定準則 |
|---|---|---|
| 導入服務（安裝/訓練/知識轉移） | Must Have | 有明確導入人月與訓練交付計畫 |
| SLA 承諾（可用率與 MTTR） | Must Have | 可用率與修復時程有明確數值承諾 |
| 在地技術支援與維運窗口 | Must Have | 有固定窗口與故障升級處理流程 |
| 版本升級與安全補丁機制 | Should Have | 有定期更新計畫與維護窗口策略 |
| 維護項目 | 基線要求（建議） | 會議確認點 |
|---|---|---|
| 告警分級與通報 | P1 15 分鐘內、P2 30 分鐘內、P3 4 小時內回覆。 | 是否納入合約 SLA 條款 |
| 值班與支援窗口 | 平日 9x5 在地窗口 + 重大事件 24x7 升級聯絡人。 | 是否要求提供值班表 |
| 備份與復原 | 每日增量、每週完整備份，定義 RTO/RPO。 | 是否要求還原測試報告 |
| 災難復原演練 | 每季至少 1 次演練，含缺失改善追蹤。 | 是否納入季度檢核 |
| 月報 KPI | 可用率、MTTR、告警數、誤報率、備份成功率、未結案缺陷數。 | 採購納入合約，資訊單位月審 |
合約面由採購主責，資訊單位負責技術條款與月報稽核，避免責任錯位。
📌 完整清單請見： amms_go_no_go_function_list.html 或 action_item_4_vendor_evaluation_2026-04-15.html
| 項目 | 建議作法 |
|---|---|
| 議項 1-3 決議結果 | 會中確認後，立即抄錄到同仁會議記錄表。 |
| 廠商評分結果 | 會議結束前將評分畫面列印為 PDF，作為附件附在會議記錄表後。 |
| 外部連結來源 | 同步登錄網址、查閱日期與用途說明，與會議記錄一併歸檔。 |