📋 RFI 回覆初審報告
回覆完整性
15 / 20
技術能力
16 / 25
成功案例相關性
6 / 20
服務與支援
9 / 15
報價合理性
5 / 10
公司可信度
5 / 10
各項回覆狀況
| 問項 | 狀況 | 說明 |
|---|---|---|
| 供應商基本資訊 | ||
| 公司名稱與登記資訊 | ✅ | 冠富行銷有限公司（24456654） |
| 成立時間 | ✅ | 民國 98 年 08 月（2009 年），約 17 年 |
| 員工人數 | ✅ | 15 人 |
| 主要業務範圍 | ✅ | 系統整合與開發服務 |
| 相關認證或獎項 | ❌ | 完全未提及 |
| 技術架構 | ||
| 系統架構圖 | ✅ | Hybrid Architecture（Device / Edge / Cloud 三層） |
| 技術堆疊說明 | ✅ | C# + Avalonia UI / .NET MAUI（地端）；CI4 + Vue.js；PostgreSQL / TimescaleDB；Redis；AWS / GCP |
| 資訊安全機制 | ✅ | HTTPS + TLS 1.2+、RBAC、JWT、CSRF、Audit Log |
| 備援與災難復原 | ✅ | Multi-AZ、Auto Scaling、RDS Failover（有說明） |
| 擴充性說明 | ✅ | 模組化、API-first、Microservice-ready、Docker |
| 成功案例 / 參考客戶 | ||
| 相關產業案例（至少3個） | ❌ | 僅2個，且均非工業監控（醫療 AI、航班延誤） |
| 客戶推薦信或聯絡方式 | ❌ | 完全未提供 |
| 專案規模與成效說明 | ⚠️ | 文字截斷，內容不完整 |
| 服務與支援 | ||
| 導入服務內容 | ✅ | 8大項服務有詳述（需求盤點→開發→UI/UX→移轉→測試→訓練→維運） |
| 教育訓練計畫 | ✅ | 管理者與操作人員分場次，附驗證機制 |
| 維護支援 SLA | ⚠️ | 分3級，但 RTO/RPO 具體數字未列出 |
| 客服管道與回應時間 | ⚠️ | 僅 Email，09:00–18:00，無 7×24 選項 |
| 時程與報價 | ||
| 預估導入時程 | ✅ | 8大項工作天數均已列出 |
| 各階段里程碑 | ✅ | Phase 1 / 2 / 3 說明清楚 |
| 關鍵路徑分析 | ✅ | 有提及，但未以甘特圖視覺化呈現 |
| 概估總成本 | ⚠️ | 文件總計 200 萬，但核算確認未含 UI/UX 250 萬；含 UI/UX 實際应付總額推算為 450 萬元 |
| 成本結構說明 | ✅ | 分授權費、導入費、維護費三類 |
| 付款條件建議 | ✅ | 里程碑分期付款 |
核心亮點
- 已核實為 MMS 舊系統開發商 — 熟悉現有資料結構與業務邏輯，系統遷移風險為兩家廠商中最低。
- 全客製開發，無平台授權依賴 — C#/Avalonia MAUI + CI4 + Vue.js + PostgreSQL/TimescaleDB，所有功能可完全依桓達需求訂製，不受第三方平台版本或授權策略限制。
- 單一主體，責任歸屬清楚 — 無聯合投標的協調成本與責任分散問題，發生爭議時溝通介面最精簡。
- 付款條件對甲方友善 — 採里程碑分期付款，每階段驗收後付款，降低甲方財務風險。
- 導入流程系統化 — 8 大項服務（需求盤點→UI/UX→資料移轉→測試→教育訓練→維運），每段均有明確驗收機制。
主要疑慮
🔴 高風險 1｜成功案例嚴重不符要求
RFI 明確要求「至少 3 個相關產業成功案例」，但僅提供 2 案且均與工業監控無關（醫療機構生成式 AI 地端部署、航班延誤判斷系統）。亦未提供任何客戶聯絡方式，無法查核。
🔴 高風險 2｜年資宣稱存在矛盾
公司成立於 2009 年，至 2026 年約 17 年，但提案宣稱「累積 20 年以上專案與系統規劃經驗」，邏輯不一致，需查證。
🔴 高風險 3｜報價總計未含 UI/UX，實際總額不明
核算文件內各項鈇計確認：文件所列總計 200 萬元完全排除 UI/UX 項目。2,000,000 = 項目一到八之和（除項目五）。UI/UX 250 萬若包含，實際應付總額應為 450 萬元，為文件總計的 2.25 倍。必須要求廠商明確說明：UI/UX 是分開報價、漏計，還是 `2.500,000` 其實代表 250,000？
🟡 中風險 4｜公司規模與本案需求落差
員工 15 人需承接 Phase 1～3 全面開發（地端 Desktop App、Local Server、雲端 AWS/GCP、PWA 行動化），人力是否足夠需確認。
🟡 中風險 5｜公司名稱與技術業務落差
登記名稱為「行銷有限公司」，但提案定位為全端系統開發商，需確認核心業務與是否以外包進行。
🟡 中風險 6｜雲端平台策略不一致
Phase 2 使用 AWS，Phase 3 切換 GCP，兩平台同時使用缺乏說明邏輯，將增加維運複雜度。
🟡 中風險 7｜SLA 服務時間不足
工業監控場域可能全天運作，但僅提供 Email 客服且服務時間 09:00–18:00，重大事件承諾僅「服務時間內優先回應」。
🟢 輕微 8｜Desktop App 框架尚未確定
Avalonia UI「或」.NET MAUI，兩者 Linux 支援度差異大，建議在 RFP 前確認選型。
🟢 輕微 9｜MMS 既有維護商的挑戰
冠富確認為 MMS 舊系統維護商，熟悉現有架構，但正因系統存在問題且需引入新技術才另尋廠商，能否跳脫舊思維導入新架構是關鍵疑慮。
RFP 建議納入事項
- 1強制要求至少 2 個工業監控相關成功案例，附客戶聯絡人供查核（NDA 案例不得計入）
- 2要求說明年資計算方式（公司年資或核心成員個人年資），並提供佐證
- 3強制要求說明 UI/UX 費用是否含於總報價內：若 2,500,000 確為正確金額，需提供含 UI/UX 的完整重新報價單（實際總額 450 萬）；若為格式誤植（實為 250,000），需更正並重新出具報價
- 4規定報價需以結構化表格呈現，所有項目必須納入總計，不得有項目游離於總計之外；各費用占比超過 30% 時需附估算依據
- 5要求明確指定 Desktop App 框架（不得以「或」帶過），並說明 Linux 支援策略
- 6要求說明雲端平台統一選型邏輯（不得 AWS/GCP 混用無說明）
- 7明定 SLA 最低標準（重大事件 RTO ≤ 4 小時），並說明是否提供非上班時段支援
- 8要求提供專案團隊組成表（姓名、角色、負責模組、可投入人天）
本報告由 GitHub Copilot（Claude Sonnet 4.6，Anthropic）協助初步審核。最終評估結論請由專案負責人核定。