簡介

“軟體即服務”(SaaS) 有可能改變資訊科技 (IT) 部門與企業其他部門之間的關係，甚至可以認為 IT 部門的角色是企業其他部門的計算服務提供商。 SaaS 作為一種有效的軟體交付機制，其出現為 IT 部門創造了機會，使他們可以將工作重心從部署和支援應用程式轉移到管理這些應用程式所提供的服務上來。 反過來，一個成功的以服務為中心的 IT 部門通過提供從內部和外部資源中獲得的服務，並將其與企業目標保持一致，就可以直接為企業創造出更大的價值。

（本文章還包含指向英文網頁的連結）

這是關於 SaaS 系列文章中的第三篇文章。 前兩篇文章側重於詳細介紹如何開發 SaaS 應用程式以及如何將其提供給客戶，請

單擊此處檢視。 這次，我們將這個問題換個形式，從企業使用者的角度介紹 SaaS： IT 部門如何從 SaaS 應用程式加入服務資產組合中受益？ 外部託管應用程式加入企業計算環境的意義何在？ 針對 SaaS 需要進行哪些準備工作？ 本文將解答上述所有問題，並一起分析幾個特殊案例，可能對您所在的部門成為 SaaS 提供商和使用者有所幫助。

瞭解 SaaS

簡而言之，SaaS 可以定義為“將軟體部署為託管服務並通過 Internet 進行訪問”。

SaaS 概念通常與二十世紀九十年代的應用程式服務提供商 (ASP) 有關，ASP 通過 Internet 為企業使用者提供“壓縮-包裝”應用程式。 在授權和體系結構等方面，這些早期所嘗試的通過 Internet 交付的軟體與傳統的內部部署的應用程式有許多共同之處，而與現代的 SaaS 應用程式的共同之處相對較少。 因為這些應用程式最初是作為單租戶應用程式構建的，與其他應用程式共享資料和程序的能力比較有限，所以與本地安裝的應用程式相比，它們的經濟效益較低。

現今，預計 SaaS 應用程式可以通過單例項、多租戶體系結構，利用集中化優勢並提供功能豐富的體驗，能夠與類似的內部部署的應用程式相媲美。 典型的 SaaS 應用程式既可以直接由供應商提供，也可以由稱為聚合器的中間方提供。中間方將來自不同供應商的 SaaS 產品繫結在一起，作為統一應用程式平臺的一部分提供。

與常用於內部部署軟體的一次性許可模型相比，通常使用訂閱模型出售 SaaS 應用程式訪問許可權，客戶需要持續付費以使用該應用程式。 費率結構隨應用程式變化；一些提供商收取固定費率，允許無限制地訪問應用程式的一些功能或全部功能；另一些提供商收取可變費率，視使用情況而定。

在技術方面，SaaS 提供商集中託管應用程式和資料，將修補程式和升級程式透明地部署到應用程式，然後使用瀏覽器或智慧客戶端應用程式通過 Internet 將訪問許可權交付給終端使用者。 許多供應商還提供應用程式程式設計介面 (API)，它可以將應用程式資料和功能提供給開發人員，供他們在建立複合應用程式時使用。 您可以使用各種各樣的安全機制，確保傳輸和儲存過程中敏感資料的安全。 應用程式提供商還可以提供一些工具，客戶能夠使用這些工具修改資料架構、工作流以及應用程式執行的其他方面，以滿足其使用要求。

使用 SaaS 的好處

當然，正因為 SaaS 可以加入 IT 基礎結構本身不是 SaaS 加入的原因，所以必然還有其他可行的經營原因。 SaaS 為各種規模的組織提供了實實在在的轉嫁軟體購置風險的機會，並使 IT 部門從一個被動反應的成本中心轉變為主動參與且能夠為企業創造價值的部門。

管理軟體購置風險

一直以來，部署如 ERP 和 CRM 應用程式套件等大型的關鍵業務軟體系統是一項非常重要的任務。 在整個大型企業部署這些系統時，提前支付的授權成本就高達數十萬美元，而且通常需要大批 IT 人員和顧問自定義這些系統，並將其與組織的其他系統和資料整合。 這種級別的部署在時間、人力和預算方面的要求，對任何規模的組織來說都意味著巨大的風險，因而較小的組織往往無法使用這類軟體，否則可從中獲得大量的效益。

按需交付模型在一定程度上改變了這種狀況。 SaaS 應用程式不要求在客戶端位置部署大型基礎結構，因此可消除或徹底縮減提前支付的資源承諾。 因為分期付款的首付款數目不大，對於那些部署了 SaaS 應用程式的企業而言，如發現結果不盡如人意，則可以輕鬆地轉而尋求其他方法，從而避免在內部部署基礎結構上進行了大量的投資，最後棄之不用而造成的浪費。

另外，如果不需要自定義整合，還可以最大限度地減少規劃和執行 SaaS 應用程式所需的工作和推廣活動，從而可能成為主要 IT 投資中見效時間最短的專案之一。 許多 SaaS 供應商可以提供一定的無風險（通常只是字面上的無風險）軟體“試用”期，例如 30 天。 在潛在客戶購買軟體之前，為他們提供一個試用軟體的機會，將有助於避免許多圍繞購買軟體所產生的風險。

有關 SaaS 的商業效益的詳細資訊，請參閱 MDSN 庫中的抓住長尾市場的架構戰略。

管理IT部門的工作重心

有了 SaaS，部署應用程式和維持應用程式正常執行的日常工作，其中包括測試和安裝修補程式、管理升級程式、監控效能和確保高可用性等等，都可以由提供商來完成。 通過將這些“開銷”活動的職責轉讓給第三方，IT 部門可以將精力更多的集中在符合和支援企業經營目標的高價值活動上。 從最初的被動反應和側重於操作的日常工作解脫出來，資訊長 (CIO) 和 IT 職員可以更有效率地工作，他們可以擔任公司其他部門職員的技術策略專家，和業務單元員工一起工作，瞭解他們的需求，就如何最好的利用技術實現其目標給出建議。 IT 部門非但不會因為 SaaS 的使用而衰落，反而有機會比以前更直接地為企業的成功做出自己的貢獻。

SaaS 連續區間

在“純”SaaS 中，提供商集中託管應用程式，並通過 Internet 向多個客戶提供訪問許可權以換取使用費。 但在實際應用中，內部部署的應用程式和 SaaS 應用程式之間的定義特徵不是二元的，而是沿著三個不同的維度累進的： 軟體的許可方式、軟體的場所以及軟體的管理方式。 上面的每個特點都可以看作是一個連續區間，一端是傳統的內部部署軟體，另一端是純 SaaS。 中間是結合這兩方面的其他方案。

圖 1. SaaS 應用程式以三個不同的連續區間上的概念性位置為特徵

•	許可：內部部署的應用程式通常是永久獲得許可，可以為每位使用者或每個站點預付一筆費用，也可以完全擁有應用程式（在自定義構建應用程式的情況下）。 SaaS 應用程式一般通過基於使用情況的事務模型獲得許可，只根據服務事務的使用次數向客戶收取費用。 中間是我們所熟悉的基於時間的訂閱模型，即客戶為某一特定的時間段（例如一個月或一個季度）支付固定費用，就可以在該時間段內無限制的使用服務。
•	場所：SaaS 應用程式安裝在 SaaS 託管方的場所中，而內部部署的應用程式則理所當然的安裝在您自己的 IT 環境中。 中間是裝置模型，即由供應商提供一個稱為“黑盒子”的硬體/軟體元件，這個元件安裝在您的場所，而不是供應商的場所。例如包含物流應用程式和進行快取並定期更新的資料庫的裝置。 運輸公司可以為一些大客戶提供這樣的裝置，如果他們需要查詢運輸資訊，可以直接查詢該裝置，而無需每天對運輸公司的伺服器進行數千次單獨的查詢操作。
•	管理：一直以來，IT 部門負責為使用者提供 IT 服務，這意味著他們需要熟悉網路、伺服器和應用程式平臺；負責提供支援和故障排除；負責解決 IT 安全性、可靠性、效能和可用性問題。 這是一項工作量很大的工作，因而一些 IT 部門將其中某些管理職責轉包給專業從事 IT 管理的第三方服務提供商。 在這個區間的另一端，SaaS 應用程式完全由供應商或 SaaS 託管方管理；實際上，這些管理任務和職責的實現對使用者而言並不透明。 服務級別協議 (SLA) 管理著質量和可用性，並支援提供商對訂閱者所做出的承諾。

採用 SaaS 時的注意事項

對於任何指定的應用程式或功能，您都可以通過在各個連續區間上標示貴組織的要求和期望來確定 SaaS 的準備情況，請使用圖 2 作為指南。

圖 2. 每個連續區間都可以再分成三段，分別代表傳統方法、SaaS 方法和混合方法

如果您在最右側一列中的所有三個框內都做了標記，那麼說明您已準備就緒，可以考慮遷移到 SaaS。 這意味著，對於此應用程式，您或許應該堅持使用傳統的內部部署的解決方案。 任何其他組合則意味著混合方法比較適合；您應該調查一下市場情況，看看能否確定幾個適合的解決方案。

在每個連續區間上找到合適的位置需要考慮眾多的因素，但每個因素最終都歸結為控制和成本之間的平衡。 其中一些考慮事項包括：

•	政治方面的考慮 有時，來自組織內部的阻力會使決策短命。如果重要人物堅持認為某個功能應該留在內部，並應該由 IT 部門控制，那麼其他因素就都不重要了。 有時候，試用部署（請參閱前面題為“管理軟體購置風險”的小節）可能會有助於說服不願冒險的管理者批准試驗性專案。
•	技術方面的考慮 SaaS 應用程式通常可以為客戶配置提供某些靈活性，但此方法也具有侷限性。 如果某一重要的應用程式需要專業技術知識才能操作和提供支援，或者需要 SaaS 供應商無法提供的自定義功能，那麼該應用程式就不可能採用 SaaS 解決方案。 另一個需要考慮的因素是與該應用程式之間日常傳輸的資料型別和資料量。 與企業 LAN 中常用的千兆位乙太網連結相比，Internet 頻寬就顯得遜色多了。如果在伺服器機房中的伺服器之間傳輸資料，可能只需要幾分鐘；但如果與位於其他國家或地區的 SaaS 應用程式之間傳輸資料，可能就需要幾個小時。 因此，考慮解決方案時應該將網路滯後因素考慮在內。 例如，基於裝置的解決方案就可以進行快取記憶體或批處理。
•	財務方面的考慮 考慮 SaaS 應用程式的總體擁有成本 (TCO)，與相當的內部部署的應用程式的 TCO 相比較。 雖然通過 SaaS 購置若干軟體功能的初始成本通常比內部部署的應用程式低，但長期成本結構的確定性卻不如後者。 影響 SaaS 應用程式 TCO 的因素包括：獲得許可的使用者數量；將 SaaS 應用程式與您的基礎結構整合時必須執行的自定義配置量；您現有的資料中心是否已經具有一定規模的經濟效應，因此降低了 SaaS 的成本節約可能性。 此外，如果您現有的應用程式比較昂貴或者是最近實現的，您也可能決定延遲實現 SaaS 替換，等到原有應用程式產生滿意的投資回報 (ROI) 後再實行。
•	法律方面的考慮 一些行業在世界的不同地方會受到不同的法律法規約束，因此必須滿足各種各樣的報告和記錄維護要求，而這些是您的 SaaS 候選解決方案所無法滿足的。 這就需要考慮貴組織從事經營活動的所有不同的管轄區內的法律法規環境，以及它們如何影響您的應用程式要求。 有時，技術方面和財務方面的考慮也會涉及法律方面的問題，例如候選 SaaS 提供商是否能夠滿足為避免合法披露而建立的一些資料安全性和隱私權方面的內部標準。 還需要考慮為客戶或其他方承擔的任何法律義務，然後看看 SaaS 是否能夠允許您繼續符合這些要求。

以服務為中心的 IT

我們已經使用相當專業的業務和技術術語討論了 SaaS 的好處。 但 SaaS 的最大影響可以歸結為這樣一個事實：SaaS 可以促使 IT 部門採用以服務為中心的模型。

如果我們研究過去數十年來 IT 部門在企業中所扮演的角色的發展變化，我們會發現，資訊科技的職責已經從過去的執行日常的記錄維護和計算任務，逐步發展到了現今的簡化工作流和通訊的行業差異化功能。