電子商務、官網、ERP、CRM 系統開發
與企業 AI 導入顧問
MAQ 網絡商數科技自 2002 年投入軟體開發，二十餘年來持續為企業建置電子商務、官方網站與內部管理系統。我們兼具系統開發與AI 工作站製造兩項能力，因此在導入 AI 時，撰寫串接程式與規劃運算硬體的，是同一個團隊。
這套能力同時應用於自身營運。MAQ 的進銷存、採購、訂單、電子發票、成本報表與人事排班系統均為自行開發，並在正式環境中每日運作；AI 亦已導入其中，可經由自然語言查詢庫存、採購紀錄、年度營收與熱銷排行。本頁所述之方法，皆源自實際運行中的系統。
最後更新：2026 年 7 月 21 日
四項核心開發服務
電子商務系統
涵蓋商品配置器、購物車、金流串接至訂單管理後台的完整開發。MAQ 官網的線上工作站配置系統即為自行建置，可即時試算數百種零件組合的價格與交期，並承載日常訂單流程。
- 購物車、會員、訂單與出貨管理
- 金流／物流串接（信用卡、分期、超商）
- 商品配置器、即時報價試算
- 後台報表與權限控管
官方網站與形象網站
不只是把版面做出來，而是把網站做成能被搜尋引擎與 AI 找得到、讀得懂的資產：語意化結構、結構化資料（Schema.org）、效能與行動裝置最佳化。
- RWD 響應式設計與效能最佳化
- SEO 與結構化資料（JSON-LD）建置
- 內容管理與多語系
- 網站搬遷、改版與長期維護
ERP 企業資源規劃系統
提供客製化開發，亦可為既有 ERP 建置串接介面與延伸模組。MAQ 的進銷存、採購、訂單、電子發票與成本報表系統均為自行開發並實際運行，因此對系統上線後的維運需求有第一手理解。
- 進銷存、庫存管理與安全存量
- 採購、供應商與進項發票管理
- 訂單、出貨與電子發票開立
- 成本分析、營收報表與估價系統
- 既有 ERP 的 API 串接與資料介接
- 權限分層、稽核軌跡與簡訊二階段登入
CRM 客戶關係管理系統
把散在 LINE、Email、電話與試算表裡的客戶互動，收斂成一條可查詢、可分析、可交接的時間軸。也可與電商、ERP 打通，讓業務看得到訂單與庫存。
- 客戶資料、互動歷程與商機管理
- LINE 官方帳號、Email 與客服整合
- 與電商／ERP 資料互通
- 銷售預測與客戶分析報表
ERP 系統要如何導入 AI？
ERP 導入 AI 無須替換既有系統，真正的前提在於決定運算的位置。目前常見的做法，是透過 API 將 ERP 資料傳送至雲端大型語言模型。此路徑導入最快，但同時意味著報價、成本結構、客戶名單與人事薪資將離開企業內部網路。這項取捨，在多數討論中並未被充分說明。
MAQ 主張先評估資料敏感度，再決定系統架構。一般性查詢與摘要適合採用雲端 API；涉及財務、成本結構、客戶名單與人事薪資者，則應將模型部署於企業自有機房。後者所需的兩項要件——安全取出 ERP 資料的程式，以及足以承載模型的運算主機——正是 MAQ 得以一併提供的部分。
實務上的四個步驟
盤點資料與痛點
辨識既有 ERP 已涵蓋、但仍耗費大量人力的環節，例如訂單重複輸入、庫存仰賴人工判斷、月結報表產出耗時。同時標記不得離開企業內部的資料範圍。
決定運算位置
依資料敏感度分流部署：一般性資料採用雲端 API，機密資料則交由地端模型處理。多數企業最終採行混合架構，日常查詢走雲端，涉及機密者留在內部。
開發串接介面
以唯讀 API 或資料檢視表安全取出 ERP 資料，建立索引供 AI 查詢，並延續原系統的權限分層，確保各職務僅能取得其權責範圍內的資訊。
小範圍上線再擴大
選定單一部門與單一流程先行導入，實際衡量所節省的作業時間後，再評估擴大範圍。全公司同時導入不利於成效驗證與後續維運。
我們先把 AI 接進自己的 ERP
ERP 導入 AI 的討論眾多，實際將自身營運資料納入者則相對少見。MAQ 的內部系統涵蓋進銷存、採購、訂單、電子發票、成本與營收報表及人事排班，皆為自行開發並運行於正式環境。導入 AI 後，系統得以回應下列型態的自然語言查詢。
此一實作帶來兩項具體結論。其一，不應由模型自行產生 SQL 查詢。MAQ 的做法是提供 11 項定義明確的唯讀查詢工具，SQL 語句固定於程式碼中，模型僅能選擇工具名稱與結構化參數，白名單之外的呼叫一律拒絕。此設計犧牲部分彈性，換取的是查詢結果的穩定與可稽核性，不致產生不存在的料號或金額。
其二，權限應於入口層完成控管。MAQ 目前以後台既有的權限等級決定何者得以開啟 AI 介面，具備權限者原即可存取相應資料。更細緻的逐列權限控管，例如同一份報表中不同業務僅能檢視所屬客戶，屬於難度更高的課題，MAQ 亦仍在開發中。組織若有此需求，應於專案初期即納入資料模型設計，後續補強的成本相當可觀。
上述結論皆來自實際建置過程。因此在討論 ERP 導入 AI 時，MAQ 所能提供的是權限劃分方式、查詢工具設計與資料落點判斷等具體議題，而非僅止於架構示意。
如果要把 AI 放在自己機房，需要什麼規格？
此為多數 ERP 與 AI 整合討論未及之處。下表列出實務上的對應關係，供評估可行性參考。
| 使用情境 | 建議模型規模 | 關鍵硬體條件 |
|---|---|---|
| ERP 資料查詢問答、報表摘要（少數人使用） | 7B–14B 量化模型 | 單張 24GB 顯示記憶體等級顯卡 |
| 跨部門知識庫問答、文件檢索（RAG） | 20B–32B 量化模型 | 32GB 顯示記憶體、64GB 以上系統記憶體 |
| 多人並行、需要較強推理品質 | 70B 4-bit 量化 | 48GB 顯示記憶體起、128GB ECC 系統記憶體 |
| 企業級知識中樞、長文脈與高並行 | 120B 級量化模型 | 96GB 顯示記憶體、256GB ECC 系統記憶體 |
上表為 5 至 10 人企業內部使用之實測基準。並行人數每增加一倍，系統記憶體需求約提高五成。詳細對照見 AI 硬體選購指南；企業地端知識主機方案見 MAQ Alishan。
為什麼是 MAQ
- 軟體與硬體同一個團隊
- 軟體廠商完成系統後，運算硬體多需自行張羅；硬體供應商交機之後，串接工作則須另覓人手。MAQ 兼具兩項能力，硬體規格得以依系統的實際負載評估而定，而非依型錄分級推薦。
- 二十餘年、還在自己用
- 自 2002 年投入網站與電子商務開發至今。您正在瀏覽的網站、線上配置器與訂單系統，皆由 MAQ 自行開發並持續維運。
- 先評估必要性，再談導入
- 並非每一項流程都適合導入 AI。MAQ 會先協助試算可節省的時間與成本；評估結果若不具效益，亦會據實說明。
- 資料留存於企業自有機房
- 可依需求採完全地端部署，資料無須經由第三方 API。此為 MAQ 既有之產品線能力，並非因應個案而臨時建構的方案。
常見問題
- ERP 系統要如何導入 AI？需要換掉現有系統嗎？
- 無須替換。實務做法為保留既有 ERP，透過唯讀 API 或資料檢視表安全取出所需資料，建立索引後交由大型語言模型查詢，再將結果呈現於既有介面。真正須優先決定的並非是否更換系統，而是運算的位置：資料是否離開企業內部網路，將決定後續的架構、成本與合規責任。
- 把 ERP 資料送給雲端 AI 有什麼風險？
- ERP 通常涵蓋報價與成本結構、客戶名單、供應商條件與人事薪資，屬營業秘密與個人資料範疇。傳送至第三方 API 前，應確認其資料保存政策、是否用於模型訓練、有無跨境傳輸，以及稽核軌跡的完整性。一般性查詢適用雲端服務；涉及前述資料者，建議改採地端模型，使資料不離開企業內部網路。
- 地端跑 AI 需要什麼等級的硬體？
- 取決於模型規模與並行使用人數。小範圍的 ERP 查詢問答，7B 至 14B 量化模型搭配單張 24GB 顯示記憶體即可勝任；跨部門知識庫建議採用 20B 至 32B 模型並搭配 32GB 顯示記憶體；若需較高的推理品質與多人並行，則建議 70B 4-bit 量化模型，並配置 48GB 以上顯示記憶體與 128GB ECC 系統記憶體。
- MAQ 自己有把 AI 導入 ERP 的實際經驗嗎？
- 有，而且是導入在自己公司的系統上。MAQ 的進銷存、採購、訂單、電子發票、成本與營收報表、人事排班系統皆為自行開發並在正式營運中；我們已把 AI 接上這套 ERP，可用自然語言查詢庫存、最近一次進貨價與價差、特定客戶的歷史採購品項、年度營收與熱賣排行。實作上最關鍵的兩項原則為：其一，不由模型自行產生 SQL。MAQ 提供 11 項唯讀查詢工具，SQL 語句固定於程式碼中，模型僅能選擇工具與結構化參數，白名單之外的呼叫一律拒絕，藉此確保結果穩定且可稽核。其二，權限於入口層完成控管，以後台既有的權限等級決定何者得以開啟 AI 介面。至於更細緻的逐列權限控管，例如不同業務僅能檢視所屬客戶，須於專案初期即納入資料模型設計，後續補強成本可觀。
- MAQ 可以只做系統開發，不買硬體嗎？
- 可以。系統開發、既有 ERP 串接與 AI 導入顧問均為獨立服務，不與硬體採購綁定。若評估結果顯示雲端架構更具效益，我們亦會據實建議。
- 可以承接既有系統的維護或改版嗎？
- 可以，包含由其他團隊開發之網站、電子商務或內部系統的接手維護、效能改善與功能擴充。接手前將先進行程式碼與架構檢視，確認風險與工作範圍後再行報價。
- 一個專案大概要多久？
- 視專案範圍而定。既有 ERP 的資料串接與 AI 查詢概念驗證，通常數週內可見成果；完整的電子商務或 ERP 客製開發則以月為單位。MAQ 傾向先交付小範圍的可用版本，待實際成效確認後再行擴充。