多數人以為 SaaS 跟一般軟體的差別只在用租的還是用買的，其實真正分界線是維運責任落在誰身上。同樣是每個月扣一筆訂閱費，有些工具背後的伺服器、資安更新、版本升級全部由供應商處理，你打開瀏覽器就能用；有些卻只是換了收費方式，系統架設、備份、修補其實還是要自己來，一旦分不清楚，選型跟後續預算都會抓不準。
SaaS 是 Software as a Service（軟體即服務）的縮寫，中文也稱為軟體服務或雲端應用服務。比起記住這個全名，更重要的是先弄清楚它背後代表哪一種責任分工，這會直接牽動導入成本與往後承擔的風險。
釐清這條界線之後，更該弄清楚的是 SaaS 實際怎麼運作，供應商實際扛下了哪些維運工作。
SaaS是什麼？
SaaS 的核心不在於用哪種方式付費，而在於應用程式實際跑在誰的環境裡、由誰負責維運。美國國家標準與技術研究院（NIST）在 2011 年 9 月發布的雲端運算標準文件《The NIST Definition of Cloud Computing》（編號 SP 800-145，作者 Peter Mell 與 Timothy Grance）裡，把 SaaS 定義為供應商的應用程式運行在雲端基礎設施上，使用者透過網頁瀏覽器這類輕量客戶端介面，或直接透過程式介面連上去操作。使用者不需要管理、也不需要控制底層的網路、伺服器、作業系統或儲存設備，連應用程式本身的功能通常也碰不到，頂多只能調整有限的、屬於個人層級的應用程式設定，例如介面語言或通知偏好。
這份文件把雲端運算歸納成 3 種服務模型，SaaS 是其中之一，同時也定義了雲端運算的 5 項基本特性，包括隨需自助服務、廣泛的網路存取、資源池化、快速彈性，以及可計量的服務。對一般企業來說，不必記住這 5 項特性的名稱，記住 SaaS 買到的是使用權而不是所有權就夠了。你付的錢換來的是連上去操作應用程式的權利，伺服器擺在哪裡、機器汰換到第幾年、軟體什麼時候更新版本，這些全部是供應商要處理的事，不是你要煩惱的事。
SaaS、PaaS、IaaS 三種雲端服務模型的責任分工
SaaS、PaaS、IaaS 這 3 個名詞常被混用，差別其實很單純，就是使用者自己要管到哪一層。IaaS（Infrastructure as a Service，基礎設施即服務）只提供最底層的運算、儲存與網路資源，供應商讓你在上面部署跟執行任何軟體，作業系統、儲存內容、實際跑起來的應用程式都要自己管理，有時候連主機防火牆這類網路元件也要自己設定。PaaS（Platform as a Service，平台即服務）再往上一層，程式語言、函式庫、開發工具與資料庫服務供應商都先備好了，只需要管理自己開發或取得的應用程式，以及應用程式執行環境的部分設定，不必碰底層的網路、伺服器、作業系統或儲存。
SaaS 則是把整層都包了，連應用程式本身的功能維護、更新排程都不需要插手，只需要管好帳號、權限與輸入的資料。這個責任分工同樣出自 NIST 的正式定義，不是各家廠商各自解讀出來的說法。分清楚三者的差別，實際用處是採購決策時不會搞混。選一套標榜雲端服務的系統前，先問清楚它屬於哪一層，這會直接影響日後要自己扛下多少維運工作，以及該編列多少對應的人力。
CRM、會計系統與協作平台等常見的 SaaS 產品類型
把定義放進生活裡看，其實每天都在用 SaaS，只是不見得注意到這個名稱。團隊溝通與協作類別裡，像 Slack 這種即時訊息平台，或是 Google Workspace、Microsoft 365 這種整合信箱、文件與雲端硬碟的辦公套件，都是這個類型的代表。客戶關係管理（CRM）這個類別裡，Salesforce 幾乎已經等於這個品類的代名詞，企業用它記錄客戶資料、追蹤業務進度、管理銷售漏斗，整套系統由 Salesforce 代管在雲端，企業不必自己架設伺服器。
會計與人力資源這個類別也一樣普及，QuickBooks 這類雲端記帳工具讓中小企業不必自己架設伺服器就能做帳、對帳；Workday 這類人力資源管理平台則把招募、薪資、績效考核整合在同一套系統裡。設計與內容協作類別裡，Figma 這種可以多人同時在同一個檔案裡編輯設計稿的工具，也是典型的 SaaS。這裡列出來的每一個名字，都只是幫助理解「這是哪一種類型的服務」，不是排行榜也不是推薦清單，同一個類型底下還有很多選擇，實際要用哪一套，得看團隊規模與需求。
訂閱使用權與買斷所有權，各自的維運責任不一樣
SaaS 跟聽起來很像的買斷制軟體、地端軟體，差別不是只有付費方式，而是部署位置與維運責任這 2 個維度都不一樣。
SaaS 的應用程式與資料存放在供應商的雲端基礎設施裡，你的電腦只負責顯示畫面、送出操作；買斷制或地端軟體則是安裝並運行在企業自己的電腦或機房伺服器上，軟體本身、產生的資料，實際上都放在自己管得到的機器裡。
維運責任的分野更明顯。SaaS 的版本更新、安全性修補、基礎設施的容量規劃，全部由供應商在背後完成，幾乎所有用戶會在同一時間用到同一個版本；買斷制或地端軟體的這些工作，升級、修補、備份、容量規劃，都要企業自己或委託 IT 人員處理，如果企業選擇暫時不升級，版本落差跟隨之而來的資安風險，就會一直留在自己身上，不會有人主動幫忙擋下來。
買斷制付的是永久授權，一次付清之後，軟體本身就是企業的資產；SaaS 付的則是持續使用的權利，合約到期或停止繳費，存取權就會跟著中止，手上留不下一套可以繼續運作的系統。這層責任轉移放進預算裡一起看，才會發現兩種模式真正的成本落在什麼地方。
座位數與導入整合費堆疊出 SaaS 真正的總持有成本
SaaS 常給人「就是每個月一筆固定月費，很便宜」的印象，但這個印象只看到報價單最上面那一行。要看懂 SaaS 真正的支出，得用總持有成本（Total Cost of Ownership，TCO）這個概念去檢視。國際科技研究機構 Gartner 對 TCO 的定義，是針對資訊科技或其他成本，跨越企業內部各個部門界線、拉長時間週期做的完整評估；就 IT 而言，TCO 涵蓋硬體與軟體的取得成本、管理與支援、通訊費用、終端使用者相關支出，以及停機、教育訓練與其他生產力損失帶來的機會成本。美國環境保護署（EPA）的說明則指出，IT 投資的 TCO 模型是在 1987 年由 Gartner 帶動普及，Gartner 最早的模型估算的就是個人電腦一年要花掉企業多少錢，如今這套方法已被廣泛採用，重點是把資產從採購、維運到汰換整個生命週期的直接與間接成本一起算進去。
套進 SaaS 身上，基本方案費之外，至少還有 5 個項目會持續疊加。第一，依使用人數計費的席次費，團隊每多一個帳號，月費就跟著往上加；第二，進階功能模組通常要另外加購，基本方案往往只是入門版本；第三，資料遷移與初期建置、客製化設定，這是一次性費用，但金額常常超乎預期；第四，跟既有系統整合串接，像是會計系統、官網、其他工具互相串接，需要額外的開發或另一筆訂閱費；第五，教育訓練與交接花掉的人力時間，雖然不會出現在請款單上，卻是實際發生的成本。
這些項目單獨看都不算大錢，但會隨著團隊成長、使用年限拉長持續累加。這正是很多企業低估 SaaS 長期支出的主因，因為多數人只拿月費乘以人數，沒把席次成長、模組加購跟整合開發一起算進去。
買斷制授權費之外還要自行吸收的維運帳單
買斷制或地端軟體常給人「一次付清，以後不用再付錢」的印象，但實際攤開來看，授權費之外還有好幾筆帳要企業自己吸收，這樣兩邊的總持有成本才比得公平。
版本升級通常要另外購買升級授權或直接買新版本，軟體商不會義務幫忙免費更新到最新版本；資安漏洞的修補速度與意願，取決於軟體商自己的規模與態度，如果軟體商規模小，或乾脆停止支援某個版本，企業就只剩兩條路，一是冒著資安風險繼續用舊版，二是砍掉重練換一套新系統，等於把導入的投入再花一次。
硬體本身也有生命週期，伺服器與終端設備汰換，要企業自己編列預算，不會有供應商幫忙分攤。如果企業沒有專職 IT 人員，維運跟故障排除花掉的人力時間，同樣是隱性成本的一部分，只是它不會出現在任何一張請款單上，很容易被忽略。把這些項目攤開來看，買斷制的總持有成本，並不是授權費那個數字就能代表的。
兩種模式的總持有成本，取決於規模成長曲線和時間長短
前面兩節攤開的費用結構，收束起來會得出一個可操作的判斷框架，而不是哪個比較划算這種空泛結論。SaaS 的成本曲線接近隨規模線性增長，座位數、模組、用量越多，付出去的錢就越多，前期投入低，但邊際成本會持續累加；買斷制或地端軟體的成本曲線接近前置固定、後續邊際成本較低，一次性投入比較大，但只要規模沒有大幅擴張，長期不會再多付一筆授權費，需要負擔的主要是維運。
這代表規模還在成長、還在測試階段的團隊，SaaS 的低前期成本與彈性退場比較有利，不必一開始就投入一大筆錢在一套可能用不到幾年就要換掉的系統上。規模已經穩定，而且預期長期都會用同一套系統的團隊，買斷制的長期總支出才有機會反而更低，但這個反而更低，前提是把維運人力跟資安責任都算進去之後的比較，不是只看授權費表面上的數字。哪一種模式划算，取決於規模成長的不確定性有多高，還有預計使用的年限有多長，不是單看短期報價就能下定論。
資料所有權、退場風險，合約沒寫清楚就等著被綁住
SaaS 最容易被忽略、也最難事後補救的風險，出在資料所有權這一層。用 SaaS 買到的是使用權，不是資料的實體所有權，輸入進系統裡的所有資料，實際上存放在供應商的基礎設施裡。如果哪天想換一套系統，或乾脆停用某個服務，能不能順利、多快時間、用什麼格式把自己的資料完整搬出來，完全取決於當初簽約時合約條款有沒有寫清楚。多數企業簽約當下不會去問這些問題，直到真的要退場，才發現自己被綁住，這種情況業界稱為供應商鎖定（vendor lock-in）。
供應商鎖定的成因，通常來自資料匯出格式不通用、應用程式介面（API）開放程度不夠，或是團隊已經太習慣既有的操作流程，換系統等於把整套工作方式重新學一遍。歐盟近年已經立法，要求雲端服務供應商在客戶要求轉換服務時提供協助，包括資料的取回與轉移。這不是在說台灣企業會受這部歐盟法規管轄，而是可以拿它當一個參照標準，理解一個成熟市場認為雲端服務轉換該有的最低保障長什麼樣子，轉頭套用在自己簽約前該問供應商的問題清單上。
簽 SaaS 合約前，至少該把幾個問題問清楚。資料能不能完整匯出，匯出的格式是不是通用格式，而不是只有這套系統自己讀得懂的格式；停用服務或合約到期後，資料會保留多久才被刪除，這段緩衝期夠不夠讓你把資料搬到下一套系統；要不要付額外費用才能拿回自己的資料。這幾個問題現在多問一句，遠比合約到期那天才發現搬不動資料划算得多。
中小企業採用 SaaS 前，四個現實的評估依據
把前面幾節的定義、成本結構跟退場風險放在一起看，中小企業要不要採用 SaaS，實際上可以收斂成 4 個現實的評估依據，而不是單純比較月費高低。
第一個依據是資料敏感度與法遵要求。如果處理的是客戶個資、財務資料，或受監管產業的資料，資料實際存放的位置，以及第三方能不能存取、存取的透明度夠不夠，就變得格外重要，這會直接影響企業能不能接受資料不在自己手上這件事；敏感度越高，選擇 SaaS 前要問供應商的問題就要越具體。
第二個依據是 IT 維運人力與技術能力。企業有沒有專職或委外的 IT 人員，能不能處理機房、硬體汰換、資安修補這些工作；如果沒有，買斷制或地端軟體的隱性維運成本，會比想像中更真實，也更容易被低估。
第三個依據是營運規模成長的不確定性。草創階段或正在快速擴張的企業，規模變化幅度大，SaaS 前期低成本、退場也相對彈性的優勢會比較明顯；規模已經穩定，而且預期長期不會大幅擴張的企業，買斷制的長期總持有成本才有機會反而更低。
第四個依據是預算結構與現金流的偏好。一次性的大額資本支出，跟分攤在每個月或每年的營運費用，哪一種比較符合企業目前的現金流狀況與預算審批流程，這是實際會左右決策的現實因素，不只是數字上划不划算的問題。
這 4 個依據沒有標準答案，同一家企業在不同成長階段，答案也可能完全相反。真正該記住的是，SaaS 省下的是前期建置的力氣，不是省下所有維運責任。供應商扛走的是機房與版本更新，扛不走的是資料放在誰手上、合約寫得夠不夠清楚這幾件事。把這幾層想清楚，再談要不要簽下一套系統，才不會等到退場那天才發現早就被綁住了。