SaaS系列介紹之十: SaaS的商業模式

標籤：

1 引言

　　賺錢之道很多，但是找不到賺錢的種子，便成不了事業家。作為職業軟體人，我們都尋求使用一種有效而經濟的過程來建造一個能夠工作的，有用的產品。

　　                                           ________Grady Booch

　　企業的根本目標是“合法地賺取儘可能多的利潤，使企業整體利益最大化”。企業所有的特定目標和行動(例如研發、營銷等)都是圍繞根本目標開展的，不能和根本目標抵觸。SaaS商業模式更關注軟體作為服務給企業所創造的經濟利潤。

　　2 SaaS商業模式的新轉變

　　商業模式的轉變將涉及到：將軟體的“所有權”從客戶轉移至外部供應商;將技術基礎設施和管理等方面(如硬體與專業服務)的責任從客戶重新分配給供應商;通過專業化和規模經濟降低提供軟體服務的成本;降低軟體銷售的最低成本，針對小型企業的長尾市場做工作。

　　l 將軟體作為服務來考慮

　　為了實現從提供內部部署軟體向軟體即服務的轉變，軟體廠商應在三個相互關聯的領域中轉變思路：一是商業模型;二是應用架構;三是運營結構。

　　

　　圖1 SaaS三個關聯的領域

　　l 轉變商業模式

　　轉變商業模式將涉及以下一種乃至更多種情況：

　　² 將軟體的“所有權”從客戶轉移至外部供應商;

　　² 將技術基礎設施和管理等方面(如硬體與專業服務)的責任從客戶重新分配給供應商;

　　² 通過專業化和規模經濟降低提供軟體服務的成本;

　　² 降低軟體銷售的最低成本，針對小型企業的長尾市場做工作。

　　為了實現SaaS理念的優勢，供應商與客戶都應進行思維轉型，並且供應商還應協助客戶實現這種轉變

　　l 長尾銷售策略

　　作者Chris Anderson在他於《連線》雜誌2004年10月刊3上撰寫的“長尾”一文中，介紹了Amazon.com等網路零售商為什麼處於有利地位，為什麼能針對傳統零售商難以以低成本提供服務的領域填補需求空白，從而使“長尾”這一新概念通俗易懂。

　　

　　圖2 長尾理論

　　書籍、光碟片等各種商品門類的需求往往符合“冪次定律分布”。在這種情況下，每年發布的書籍、CD以及DVD數不勝數，但只有少數能長期成為暢銷品，其他的往往屬於反響平平的長尾類出版物：大量出版物只讓少部分有專門愛好的人感興趣，出版量很小，甚至連幾千份的拷貝都沒有。

　　傳統的實體型零售商致力於銷售最流行的出版物，因為他們不可能把數以百萬計的書籍、CD以及DVD等出版物都拿來當存貨。不過，網路零售商則不用擔心存貨問題，他們能直接從全球各大倉庫直接向客戶發貨，即便銷售的出版物受歡迎程度很低，其廣告和銷售成本也毫不受影響，同樣像暢銷出版物一樣大作宣傳。因而長尾類低銷量出版物也能贏得大量收入。

　　大型的實體書店能在其書架上存放13萬種不同的出版物。而Anderson指出，Amazon.com書籍銷量的大部分都來自13萬種流行出版物之外，換言之，Amazon.com賣出的書中，大部分都是在傳統的實體書店中買不到的。

　　長尾理論的基本原理是：只要儲存和流通的渠道足夠大，需求不旺或銷量不佳的產品所共同佔據的市場份額可以和那些少數熱銷產品所佔據的市場份額相匹敵甚至更大。即眾多小市場匯聚成可與主流大市場相匹敵的市場能量。

　　

　　圖3 長尾理論的經濟模式

　　從上述中可以看出，與20/80定律不同是，長尾理論中“尾巴”的作用是不能忽視的，經營者不應該只關注頭部的作用。長尾理論已經成為一種新型的經濟模式，被成功應用於網路經濟領域領域。舉例來說，Google就有效地利用了長尾策略。google的Adwords廣告使得無數中小企業都能自如投放網路廣告，而傳統的網路廣告投放只是大企業才能涉足的領域。其Adsense廣告又使得大批中小網站都能自動獲得廣告商投放廣告。Adwords和Adsense因此匯聚成千上萬的中小企業和中小網站，其產生的巨大價值和市場能量足以抗衡傳統網路廣告市場。如果google只是將市場的注意力放在20%的大企業身上(像許多門戶網站的網路廣告策略那樣)，那麼也很難創造現在的輝煌了。同樣，網上零售巨人亞馬遜的商品包羅永珍，而不僅僅是那些可以創造高利潤的少數商品，結果證明，亞馬遜模式是成功的，而那些忽視長尾，僅僅關注少數暢銷商品的網站經營狀況並不理想。

　　複雜的企業軟體解決方案供應商面臨著相似的市場境況。

　　

　　圖4 長尾理論的2/8定律

　　與簡單的套裝軟體不同，企業軟體需要針對不同客戶的需求進行定製，可能包括現場安裝、廠商服務隊伍上門服務等，通常還需要專門的伺服器硬體和技術服務人員加以管理。提供上述專門服務的成本會一定程度上增加供應商銷售軟體的最低成本。因此，這種軟體通常面向大型企業，只有大型企業才有實力來支付專門服務。不過，相對於購買企業解決方案的大型企業數量而言，有著同樣需求的中小型企業的數量要多得多，但他們卻難以承擔高昂的成本。

　　

　　圖5 長尾理論的“長尾”

　　SaaS供應商可消除維護成本，利用規模經濟效益將客戶的硬體和服務需求加以整合，這樣就能提供比傳統廠商價格低得多的解決方案，這不僅減輕了財務成本，而且大幅減少了客戶增加IT基礎設施建設的需要。因此，SaaS供應商能面向全新的客戶群開展市場工作，而這部分客戶是傳統解決方案供應商所無力顧及的，因為他們根本就沒辦法為這部分客戶提供低價格的服務。

　　有效面向小型客戶開展市場工作，這就要求習慣於通過人際交往以及傳統廠家和客戶關係搞營銷的供應商們進行思維轉型;大多數供應商難以用大規模市場上的較低價格向更大的客戶群體提供個人化服務。

　　搞SaaS營銷就像銷售手機彩鈴或音樂下載服務一樣，應該讓客戶能訪問您的Web網站，成為您所提供服務的付費使用者，通過信用卡付費就能開始享受服務，整個過程無須供應商方面的人為介入。這不是說您就不用對需求範圍廣的大規模客戶群做人際聯絡工作。不過，在銷售工作的設計、營銷、供應和定製過程中從頭到尾都是自動化的，因此我們不僅能提供自動化服務，同時又能簡化您支援部門員工的工作，因而不用再協助客戶完成相關任務。

　　3 “點菜”模式

　　什麼是“點菜”模式呢?大家習慣上餐館去吃飯，吃飯前都要點菜。服務員拿出一本菜單給我們點，我們按一個個菜名點菜。這種最熟悉不過的方式應用在軟體開發中將有很大的創新。我們把每一個可獨立啟動並執行最小的使用者功能模組稱之為“一盤菜”。一個系統劃分為若干盤菜，若干盤菜可任意組裝成一個系統。

　　SaaS在提供功能服務時先給客戶一張菜單，客戶在這種菜單上勾勾劃劃，SaaS平台系統就自動按客戶的選擇提供一桌菜。這一桌菜以門戶網站的形式出現在客戶面前。讓使用者似乎看到的是為自己製作的一個系統，事實上軟體廠商根本不需要投入任何其它成本。這一切的完成幾乎不需要多少人工由電腦就可自動完成。大家想想，要是有10盤菜，可組裝成多少個系統?20盤菜呢?100盤菜呢?這100盤菜幾乎要囊括所以的軟體了。

　　3.1 “點菜”模式綜述

　　“菜”的定義

　　“菜”是指可獨立運行(相對平台)的按照軟體功能範疇劃分和組合的滿足使用者的需求並供使用者選擇的最小功能單位。我們可直觀地把它理解為一個小型的應用系統，只是它小到不能再劃分。“菜”的組成主要包括使用者的功能頁面、實現的代碼集合(類、包、組件庫)、資料表、相關文檔及設定檔等(從開發角度來看)。

　　用軟體的術語來講“菜”就是功能組件。一個獨立的功能組件也就是一盤“菜”。

　　按菜的思想來劃分軟體功能，這裡要關注的是什麼是菜?怎麼細分菜?怎麼實現“點菜”模式?有了“菜”，我們就可以通過“點菜”、“配菜”、“加工菜”來達到使用者的需求。

　　“點菜”是讓使用者來點，軟體廠商如果有現存的“菜”，這些“菜”不需要任何修改直覺組裝就可滿足使用者的需求。這對於軟體廠商是最好不過的方式。

　　但並不是所以使用者的需求都可通過“點菜”來滿足，點不出來的菜再考慮配置，通過“配菜”的方式來實現，使用者想吃“蛋炒飯”這盤快餐，您是重新給使用者炒一盤新的還是把早炒好的蛋加上現有的飯快速地給使用者呢?所謂“配菜”就是指後者。

　　菜配不出來，那隻有要動手術了，這需要在原來的功能上通過代碼的修改和補充來滿足使用者的需求，這就是“加工菜”。

　　既然一切是以“菜”的思想出發，那麼就無所謂系統、子系統了。事實，只要開發好了“菜”，其它系統都是通過“點菜”、“配菜”、“加工菜”來實現的。

　　所以，把“菜”看成一個最小的系統，“菜”的開發包括軟體生命週期的整個過程，從需求分析、設計、實現、測試到維護等整個過程。這裡要強調的是，需求分析只是對一盤“菜”要分析，設計同樣如此。就是說《需求分析說明書》中的內容只可分析一盤菜，《架構設計說明書》、《詳細設計說明書》都是設計這盤菜。菜與菜之間的關係都通過介面實現。菜是獨立的，文檔也是獨立的。從事這盤菜開發、設計的人員組織也是相對獨立的。這樣打破了傳統的按系統劃分軟體的概念。嚴格上講，所謂“人”、“財”、“物”、“事”系統統統都不存在。沒有所謂的ERP，沒有所謂的HR，沒有所謂的OA等等。要構成這些系統，是通過解決方案來實現，解決方案中也是利用“點菜”、“配菜”、“加工菜”來達到最終的目的。

　　“點菜”模式事實是用最少的開發來實現儘可能多的使用者軟體，是通過量變達到規模效應。SaaS模式有效地結合“點菜”模式，將大大降低軟體廠商開發的成本，從而提高軟體利用率，繼而產生規模經濟效益。

　　再比如我們習慣了上超市買東西。超市是大賣場，它提供各種花樣其全的商品，價格相對也比較合理。客戶為什麼喜歡上超市買東西?其中原因之一就是可供選擇的的品種多。客戶可以自己選擇。SaaS模式發展到一定成熟階段，也會轉化為軟體大超市。大量的軟體公司將被併購，在分工合作的統一協調下各自完成軟體大超市的某項工作。理論上各大系統都是按零組件組裝而成。我們的開發分成零組件的生產和組裝這二個重要的環節。

　　零組件在傳統的製造行業體現得很充分。很容易理解。但軟體行業卻完全不同，軟體是不可見的難控的極大靈活度的無形高科技物質。而菜是可見的可控的粒度易把握的。下面我們來看“點菜”模式的組成1：

　　

　　圖6 “點菜”模式的組成

　　“點菜”模式由四部分組成

　　1) 菜的來源及劃分：依據需求來源定義出各種“菜”。

　　2) 菜的實現：由配置開發模式、修改模式和開發模式生產出“菜”。

　　3) 菜入庫：把做好的“菜”放入組件庫。

　　4) 裝配：按使用者需求把“菜”組裝成的產品供使用者使用。

　　3.2 “點菜”模式開發過程

　　

　　圖7 “點菜”模式的開發過程

　　“點菜”模式開發過程劃發為：組件慨信念、組件分析、組件開發、組件入庫、產品發布、產品測試、內部驗收、產品交付、產品維護9個階段，包括以下11個子過程：

　　1) 需求來源：收集共利益者的需要、期望、限制條件和產品元件需求。

　　2) 需求分析：細化客戶需求，開發產品和產品元件需求。

　　3) 配置模式：通過自訂工具快速開發功能組件。

　　4) 修改模式：通過修改原始碼的方式開發功能組件。

　　5) 開發模式：通過軟體程式開發方式開發功能組件。

　　6) 組件庫：功能組件的管理與維護。

　　7) “點菜”(產品裝配)：從組件庫中按項目業務需求裝配功能組件。

　　8) 系統測試：從需求的角度對系統的正確性進行驗證。

　　9) 驗收：由客戶對產品進行確認，並向客戶交付產品。

　　10) 維護：產品維護階段的管理過程。

　　11) 軟體問題管理：記錄並管理軟體項目開發/維護過程中所發現的各種軟體問題。

　　3.3 需求來源與分析

　　需求來源的過程包括8：

　　

　　圖8 需求來源

　　l 需求來源渠道

　　1.銷售，2.市場，3.意向客戶，4.合約，5.公司定位，6.行業協定

　　l 需求收集

　　收集各種需求，包括行業標準，行業解決方案，諮詢服務資訊等。

　　l 需求整理

　　篩選並歸納整理，通過評審確定後形成的“菜”的原始材料。

　　需求分析的過程包括9：

　　

　　圖9 需求分析流程

　　功能組件定義：依據需求來源，按“菜”的標準劃分並定義出功能組件。

　　功能組件清單：按模板格式列出功能組件清單，並給各功能組件命名、編號。此清單是功能組件入庫和系統測試、驗收的依據。

　　組件庫尋找：如果此功能組件已經在庫中則可直接供，跳過開發路線這個過程。

　　確定開發路線：分析並評價功能組件的需求，確定開發方式，在配置模式、修改模式、開發模式中選擇一種最快最適合的組件生產流水線。

　　3.5 組件庫

　　

　　圖10 組件庫

　　l 組件庫定義

　　組件庫是用來存放功能組件的倉庫。相當物流公司的存貨庫。此倉庫常由資料庫來實現。功能組件按照分類和規律存放在資料庫中。按照使用者的需求可裝配成不同的產品打包給使用者。

　　l 組件庫設計

　　合理實用的組件庫是“點菜”的關鍵。軟體的不可見度增大了組件庫設計的難度。超市裡的商品擺設都是很有講究的，它是一門藝術學問。

　　組件庫的設計包括組件庫的架構、組成部分、邏輯結構設計、技術實現、物理結構、操作介面、入庫與出庫標準的定義、介面、類別關係等設計。

　　l 組件庫開發

　　實現組件庫的功能，包括建立資料模型，操作介面，入庫出庫的方式，尋找與匹配等功能代碼的編寫與單元測試、組裝測試。

　　3.6 產品裝配

　　產品裝配是按客戶功能清單從組件庫中提取出功能組件，通過裝配工藝組裝成產品提交給使用者。此時的客戶可能就是公司的產品部。

　　裝配清單：產品包、補丁包，平台基礎支援組件等。

　　

　　圖11 產品裝配流程圖

　　3.7 系統測試

　　l 準備

　　1. 系統測試計劃：測試範圍(內容)，測試方法，測試環境與相關工具，測試完成準則，人員及任務安排。

　　2. 設計系統測試案例：測試案例應能夠完整驗證定義的產品需求客功能。

　　3. 同行評審。

　　4. 準備測試載入器。

　　5. 建立測試環境。

　　l 測試

　　1. 擷取整合了所有應交付產品組件，並且通過整合測試的產品，根據《系統測試計劃》和系統測試案例，並對照需求對產品進行測試。

　　2. 將測試中發現的缺陷/問題按照軟體問題管理流程進行管理;

　　3. 比較實際結果和預期結果，識別產品沒有得到滿足的需求，識別測試方法、標準和環境方面的問題;

　　3.8 驗收

　　

　　圖12 驗收流程

　　l 驗收準備

　　1. 開發方、客戶方以及其他項目相關方，共同協商，建立產品驗收組，並指驗收負責人。

　　2. 驗收小組制定出《驗收計劃》，並獲得雙方的負責人批准。

　　l 產品確認

　　1. 為驗收群組成員提供培訓

　　2. 產品審查

　　3. 驗收測試

　　l 召開驗收會

　　1. 會議前確認產品審查和驗收測試活動已結束;

　　2. 驗收測試組提供：產品審查記錄和驗收測試報告等材料;

　　3. 按照驗收會安排，召開驗收會議;

　　4. 根據評價結果和已定義的驗收準則，得出驗收結論，並形成《驗收報告》。

　　5. 如果產品需要複評，開發方應給出矯正措施，雙方對再次驗收的時間進行

　　6. 協商。

　　l 產品交付

　　發布已通過驗收的產品。

　　3.9 交付產品

　　按照《驗收計劃》中定義的交付方式和交付進度，將產品交付給客戶。

　　

　　圖13 產品交付流程

　　l 封裝設計

　　產品光碟片，光碟片套封面，安裝說明等設計。

　　l 產品打包

　　產品打包，包括資料庫結構、資料庫建立檔案、編譯過的程式檔案、設定檔、輔助

　　檔案、分頁檔、使用者安裝手冊、使用者使用幫忙說明書、補丁、平台支撐檔案、其他工具檔案等打包成安裝檔案。

　　打包好的檔案刻成光碟片或者放在網上供下載安裝。

　　l 產品實施

　　打包好的檔案供實施人員去客戶現場安裝實施。

　　3.10 維護

　　

　　圖14 維護流程

　　l 準備

　　在產品通過驗收，正式發布後，產品相關方(如開發部門、銷售部、產品部、支援人員部、客戶方等)應協商建立產品維護小組，並指定維護負責人。產品維護群組成員的組成可以是產品開發項目組的成員，也可以不是項目組的成員。

　　l 制定維護實施計劃

　　由維護負責人負責維護計劃的編製。

　　l 實施產品維護

　　1. 維護需求的識別

　　2. 維護需求的評估

　　3. 實施維護

　　4. 後續工作

　　如果需要向客戶交付維護後的產品，更新受影響的客戶軟體，期過程應嚴格遵循《組態管理程式檔案》，通過CCB批准後，變更運行基準。

　　3.11 軟體問題管理

　　

　　圖15 軟體問題管理流程

　　l 問題的發現與登記

　　軟體項目開發或維護過程中，開發、整合或測試人員一旦發現了軟體問題，應立即填寫《軟體問題報告單》，並將《軟體問題報告單》提交項目指定的問題管理人員;

　　l 分析分類

　　根據引入問題的開發階段，確認問題的類型;

　　評估是否修改，對某些問題是否投入資源和工期進行修改有爭議時，專案經理是最終決策者;

　　指定問題修改的責任組或責任人和解決問題的優先順序。

　　l 問題發布

　　根據分析的結果，問題管理人員對問題進行分發和跟蹤;

　　將《軟體問題報告單》的副本分發到指定的負責部門或人員;

　　跟蹤問題的解決情況，維護《軟體問題狀態登記表》記錄相關資訊，

　　l 問題和解決與驗證

　　問題負責部門或人員對問題報告進行進一步的分析，解決問題，填寫《軟體問題報告單》，修改《軟體問題狀態登記表》的狀態。

　　如果問題無法解決，可以選擇在這個版本中不給予解決，擱置問題。但必須由專案經理進行批准。

　　如果問題的修訂將會引起設定基準的變更，變更的過程應按照《組態管理程式檔案》中的“配置變更管理”子過程進行。

　　問題解決後必須經過測實驗證才能確認問題關閉。

　　4 通過“點菜”模式提升SaaS的商業價值

　　4.1“點菜”模式不同於構件開發方式

　　事實上，軟體業中組件化開發、構件化開發的思想早存在，有不少公司在從事這方面的工作並取得不錯的成績。但是失敗的確定不少。其失敗的原因是多方面的。其中主要的是組件/構件的粒度把握得不準。這種可大可小的抽象性的東西用不同的觀點不同的人去劃分就會有種種不同意結果。

　　但“點菜”模式卻不同，菜是可看得見的。劃分與開發的難度要小得多。菜是供使用者最終吃的，而不是構件是供軟體從業從員自己用。菜是功能性的，站在使用者的立場來看待問題。菜的粒度比構件要粗。事實上構件更形象地可看作是構成菜的原料。定義與開發原料是件極大的挑戰。

　　4.2 正確運用“點菜”模式

　　“點菜”模式在傳統軟體業上也適應，只是軟體公司在這方面研究得並不夠，實際操作上存在許多困難，發揮作用也不明顯。如何解決好這些問題，這裡我們提如下幾條建議：

　　1. 成立一個專家小組，該小組從整體、全域上走規劃、定義“菜”，並進行相關的培訓、指導和規範。

　　2. 定義並制定出配置模式、修改模式、開發模式。

　　3. 打破傳統的以項目型為主的開發模式，建立以“菜”為中心的小組。但也可以以小組組成大的組，這個大組只是重在管理和協調上。小組以3至5人最適宜，3至5人的小組更易溝通、管理，開發效率極高。

　　4. 規範並明確點“菜”的開發模式，包括從需求到設計的快速響應，各盤“菜”支援參數化定製、資料模型定製與工作流程定製。

　　5. 組態管理逐步實現點“菜”模式。可自動快速地通過“菜”組裝成不同應用系統。

　　6. 整理上布局SaaS模式，點“菜”模式有效地與SaaS結合，實現平民化軟體，走軟體超市之路，建立軟體服務運營平台。

　　7. 對原有的系統分情況分階段按“菜”標準重新定義和重構，重視介面設計。

　　8. 提供客戶線上快速訂購組件，自動設定組裝客戶門戶系統，平台提供統一的定製門戶入口，並且按實際的使用量靈活計費。

　　9. SaaS下組件是細碎零散的，為了避免組件過於細碎零散，能夠按主題如某行業應用Mashup起來。

　　10. SaaS下組件數量眾多，大規模的多租客架構，要求可擴充的部署平台與監控機制。

　　11. 組件在資料、服務、介面等層次共用與組合，提供資料匯流排、服務匯流排與Mashup Server等基礎設施，提供可擴充的行業資料模型;SaaS組件必須是可定製擴充的。

　　12. 應該大大簡化客戶的訂購、使用產品，提供統一的頁面風格與使用者體驗。

　　13. 研究而創新“菜”的擴充性、源碼的開發性，可提供二次開發。

　　14. 支援線上測試、部署應用，組件的設施與企業內部IT系統的良好互聯，可定製企業門戶。

　　15. 面向組件庫的開發與面向客戶的開發完全分離開來。

　　4.3 SaaS模式促進軟體大超市的早日到來

　　商品化的超市購物方式已經深入人心，人人都享有進超市購物的權利。商家不一定是商品的生產者，經營超市的商家承擔了商品的採購與銷售的職責，這不僅僅極大方便地給顧客提供了物美價廉的商品，也讓自己賺得缽滿滿。事實，我們在90年代初還是上小雜貨店或者百貨大樓指著貨物叫銷貨員拿給我們，這樣既沒有更多選擇的範圍也沒法保證商品的品質，價格也難降下來，商品大超市的出現提高了人們生活的品質，人人享受購物的樂趣。軟體一樣是商品，軟體又怎麼不會走向大超市呢?如果只是把軟體當作光碟片賣，那叫不上超市，不管您的軟體種類怎麼多，也不管您光碟片數量有多少。因為那樣買的是一整套軟體。

　　我們完全可以把整理的軟體細分為模組，模組與模組可以組合，使用者只是根據自己的所需購買一個由多個模組組成的系統，而不是買了財務軟體還要買OA系統。一大堆軟體事實用到的功能還不到20%。因此我們完全可以通過點菜模式來滿足使用者的真正需求，我們最終提供給使用者的一個系統，這個系統可覆蓋使用者的所有功能需求。

　　這樣，我們在網上開個軟體大超市，讓使用者按模組來選擇功能，再通過組合控制方法形成一個獨立的系統，真正做到了這點會很快讓軟體走向平民化、福士化，人人都可享受軟體就是人人都可享受美食一樣。SaaS模式會快速地推動軟體大超市的早日到來。

　　5 小結

　　SaaS商業模式與傳統產業的商業模式都是為了推廣自己的產品，佔有更多的市場份額，最終達到擷取更多的經濟利潤。

　　本章介紹了“以服務為導向”的SaaS模式如何以商業的思維來理解軟體，通過“點菜”模式來提升SaaS的商業價值。通過配置模式滿足使用者的定製要求，從於抓住更多的使用者。通過建立品牌並推廣，明確誰是自己的客戶，推銷什麼產品給客戶等戰略的高度來營銷SaaS軟體，創造更好的經濟效益。

SaaS系列介紹之十: SaaS的商業模式