SaaS 何時已經足夠，前線部署工作又有何不同

企業討論 AI 現代化時，往往把它視為工具選擇。

更困難的決定，是機構實際需要哪一種改變。

標準工作流程可能需要一套設計完善的 SaaS 產品。現有系統可能需要託管服務供應商可靠地營運。已定義的體驗或整合可能需要代理公司。尚未釐清的組織問題可能需要顧問。跨系統營運問題則可能需要一個平台，以及一支貼近業務工作的團隊。

這些路徑可以重疊，卻不能互相取代。每一種模式對標準化、擁有權、實施方式，以及工作完成後留下甚麼，都有不同承諾。

從問題開始，而不是從供應商類別開始

同一項要求可以隱藏幾種截然不同的需要。

「需要更清楚看見供應商狀況」可能代表：

• 在現有採購產品中統一供應商紀錄；
• 清理和核對財務及物流系統中的供應商身份；
• 重新設計資格審查的責任和審批；
• 為一個採購團隊建立比較介面；
• 連接多個系統內的證據、決定和下一步；
• 為形成的工作流程提供持續營運支援。

每一種需要都指向不同交付模式。

如果機構能回答以下問題，選擇便會清楚得多：

• 工作流程在不同公司是否標準，還是這間企業獨有？
• 是否已有一類現成產品負責這個流程？
• 主要問題是軟件存取、營運可靠性、專門執行、組織診斷，還是相互連接的營運模型？
• 資料有多零散和不一致？
• 哪些團隊和決定需要跨越系統邊界？
• 實施之後由誰擁有工作流程？
• 期望成果是建議、交付物、營運服務，還是持久軟件？

所選路徑應由這些答案決定。

標準化能創造價值時，SaaS 最有優勢

美國國家標準與技術研究院把軟件即服務（SaaS）定義為存取供應商在雲端基礎設施上運行的應用程式，底層基礎設施由供應商管理，客戶對其控制有限（NIST^{1NIST SP 800-145, The NIST Definition of Cloud Computing}）。

這種安排有清楚價值。客戶不需要自行建立底層軟件，便可獲得持續維護的產品、可重複的營運模式、更新、文件和產品路線圖。

以下情況通常適合選擇 SaaS：

• 工作流程常見而且已有充分理解；
• 產品資料模型與業務足夠配合；
• 標準化比保留本地差異更有價值；
• 整合介面已經存在而且穩定；
• 機構願意採用產品的營運假設；
• 實施速度和可維護性比完全貼合工作流程更重要。

薪酬、會計、電郵、工單、文件管理、CRM、項目追蹤和許多其他職能工作流程，都受惠於這種模式。

取捨並不在於 SaaS 是否通用或欠缺彈性。成熟產品可以高度配置。真正取捨是產品仍然需要一套可以服務眾多客戶的穩定模型。如果業務成果取決於產品沒有表達的關係，使用者便要改變工作、建立權宜方法，或增加另一層系統。

託管服務解決營運擁有權問題

託管服務供應商持續負責一項已議定的服務，可能包括基礎設施、保安營運、支援、監察、管理、備份、合規支援，或特定應用程式的運作。

當機構需要可靠覆蓋、專門能力或已定義服務水平，多於需要新的營運模型，這種模式便有用。

以下情況通常適合託管服務：

• 系統和責任已經清楚；
• 主要需要是持續營運和支援；
• 機構希望在清楚服務邊界下取得外部能力；
• 表現可以用事故、可用性、回應、控制或服務水平描述。

如果問題出在工作流程本身，限制便會浮現。令幾個系統保持運作，不一定能核對當中的資料、重新設計決定，或令跨系統情境更容易被使用者理解。

代理公司擅長交付已定義成果

代理公司按工作說明組織專門技能，成果可以是網站、介面、原型、自動化、整合、內容系統、推廣活動或數碼服務。

當機構能夠定義成果，並需要專門執行能力交付時，這是一種有力模式。

以下情況通常適合代理公司：

• 所需成品或體驗清楚；
• 項目可以界定範圍；
• 客戶能提供決定和回饋；
• 長期擁有權和維護安排已經議定；
• 成功可以按工作說明評估。

取捨在於延續性。成功的交付物仍可能依賴客戶的資料模型、權限、營運擁有權和整合架構。如果這些基礎不在工作範圍內，成品即使執行出色，也未必改變底層營運問題。

問題尚未清楚時，顧問可以提供幫助

當管理層需要診斷、策略、流程設計、管治、採購支援、項目管理或組織協調時，顧問工作便有價值。

機構可能仍未知道哪個工作流程重要、計劃為何失敗、決策權應如何改變，或應該建立甚麼。建議、引導、分析和變革領導可以是正確的第一步。

以下情況通常適合顧問工作：

• 實施前需要先界定問題；
• 多個持份者需要協調；
• 營運或管治選擇仍未落實；
• 機構需要獨立專業意見；
• 期望成果是一份路線圖或一項決定。

取捨在於如何由建議進入營運。只有當機構能把建議轉化成有人負責的流程、資料變更、介面、控制、培訓和實際系統，建議才會創造價值。

平台提供可重用基礎

平台是建立系統的底層能力，而不是單一固定工作流程。

它可以提供以下可重用功能：

• 身份和存取控制；
• 連接器和獲准來源索引；
• 資料模型和本體模型；
• 資料沿革和審計；
• 檢索和搜尋；
• 工作流程狀態和佇列；
• 介面元件；
• 自動化和受控回寫路徑；
• 審閱、審批和升級處理。

平台的價值在於組合能力。新的工作流程不需要從頭重建身份驗證、權限、資料沿革、部署和控制。

當多個工作流程共用基礎，卻無法歸入同一標準應用類別時，平台便變得合適。平台不能取代對業務的理解，它提供可重用結構，讓這種理解可以變成軟件。

前線部署工作貼近營運開始

前線部署工作把平台或技術基礎，與一支從營運環境學習、並和使用者共同塑造實施方案的團隊結合。

重要分別不是職銜，而是回饋循環。

團隊由一項業務成果開始，觀察工作如何發生、審核獲准資料、對應權限和例外、建立相互連接的模型、與真實使用者測試介面或工作流程，再按修正持續改進。

以下情況適合這種模式：

• 工作流程包含機構自己的營運語言和判斷；
• 相關資料分散於不同系統或互不一致；
• 決定橫跨多個團隊和來源；
• 邊緣情況會實質影響成果；
• 使用者需要按角色設計的介面；
• 採用新系統需要改變習慣、審閱和擁有權；
• 實施應變成持久軟件，而不是一連串人手介入。

工作流程複雜，並不足以證明需要前線部署模式。有些複雜度應該移除，有些本地差異應該標準化，有些問題更適合透過配置現有產品解決。

只有當理解和表達具體營運方式本身就是產品價值的一部分，前線部署模式才有充分理由。

AI 更需要營運配合

傳統自動化最適合狀態和下一步已經清楚的工作。IBM 把工作流程自動化描述為以軟件執行部分或全部流程（IBM^{2IBM, What is workflow automation?}）。

AI 可以協助處理結構較少的工作，但仍然需要營運情境：

• 涉及哪個客戶、訂單、供應商、項目、資產或案件；
• 哪個來源具權威性；
• 哪些證據反映當前狀態；
• 尚有甚麼不確定或衝突；
• 決定由誰負責；
• 系統可以讀取、準備、更新或發送甚麼；
• 何時需要人手審閱。

Anthropic 的指引區分預先定義的工作流程，與可自行選擇更多處理步驟的 AI 代理，並建議在增加自主程度前先採用最簡單而有效的模式（Anthropic^{3Anthropic, Building effective agents}）。

這項原則會改變實施方法。加入 AI 代理之前，機構可能要先審核和核對資料、定義業務本體模型、設計範圍有限的工具、建立審閱路徑，以及培訓使用者。通用介面無法憑空補上決策權，也不能自行解決互相衝突的產品身份。

AI 周邊的營運模式因此是系統的一部分，不是包裝在完成模型外面的服務。

工作完成後應留下持久能力

如果前線部署工作變成沒有穩定基礎的定制工作，便會失敗。

警號包括：

• 每項客戶要求都成為獨立程式路徑；
• 重要邏輯只存在於一位顧問的記憶；
• 資料對應沒有負責人或資料沿革；
• 客戶無法理解工作流程如何運作；
• 使用者修正不能改善系統；
• 實施長期依賴人手介入；
• 供應商和客戶對營運與變更責任不清。

健康的合作會把可重用基礎和特定營運設計分開。

可重用基礎可以包括存取控制、連接器、索引、資料沿革、工作流程元件、審計、介面元件和部署基礎設施。

特定設計可以包括客戶的業務成果、本體模型、來源對應、狀態定義、權限、例外規則、營運節奏、使用者介面和培訓。

客戶特定工作應令平台能力更強，同時承認不同機構有不同用語和流程。

比較各種模式最後留下甚麼

按持久成果比較，這些類別會更容易理解：

實際合作可以結合多種模式。一間公司可以使用 SaaS 紀錄系統、由託管服務供應商管理基礎設施、由顧問支援管治、由代理公司建立客戶體驗，再由前線部署平台處理跨系統營運工作流程。

有用的問題，是哪種模式負責每項成果和交接。

成本結構取決於工作種類

這些路徑有不同商業結構，因為客戶購買的是不同東西。

SaaS 通常按存取或用量收費。託管服務通常按持續覆蓋和服務水平收費。代理公司和顧問工作則多數按交付物、時間或項目責任界定範圍。

前線部署合作可能包括：

• 付費探索或設定；
• 已界定範圍的實施或嵌入式工程支援；
• 持續託管支援和改善；
• 適用時另行計算第三方 AI、雲端、牌照或交易成本。

實際價格需要在界定範圍後確定，因為整合、資料狀況、保安、使用者驗收測試、工作流程複雜度和支援需要，都會實質改變工作量。

這不代表商業模式無法預計，而是工作範圍應把成本連到已定義的業務成果、實施邊界、責任和成功準則，而不是用一個掩蓋實際工作的通用公開數字。

如何選擇

如果工作流程標準，而且採用產品模型比保留本地差異更能創造價值，選擇 SaaS。

如果主要問題是可靠營運和覆蓋，選擇託管服務。

如果成果已經定義，而限制在於專門執行能力，選擇代理公司。

如果實施前需要先做診斷、協調、管治或變革設計，選擇顧問。

如果多個系統或工作流程需要可重用的技術和管治基礎，選擇平台。

如果業務成果取決於特定資料、跨系統關係、行業語言、邊緣情況、按角色設計的介面和持續採用，可以考慮前線部署工作。

無論選擇哪一條路徑，管治仍然是營運責任。NIST 的 AI 風險管理框架把風險視為情境問題，並要求在整個生命週期持續管理；ISO/IEC 42001 則描述一套持續管理負責任 AI 使用的制度（NIST AI RMF）。

採購決定並不是由簡單走向複雜的階級，而是配合程度的問題。最有力的選擇，是能夠達成成果，同時令機構有能力營運下一步的最簡單模式。

資料來源

1. NIST SP 800-145, The NIST Definition of Cloud Computing
2. IBM, What is workflow automation?
3. Anthropic, Building effective agents
4. NIST AI Risk Management Framework
5. ISO/IEC 42001 AI management systems