最近幾年湧現了很多SaaS公司，很多資本也進入了這個行業，但是大家不能因為看到幾家美國SaaS公司成功，就認為SaaS在中國也會成功。
這種對比過於簡單，忽略了很多客觀因素。就像韓信背水一戰成功後，我們也去類比模仿一樣。
所以，本文會從SaaS優缺點兩個方面來談談，
是不是中國所有行業都適合使用SaaS？SaaS是「包治百病」的良藥嗎？
01
SaaS出現的
背景原因和優勢
SaaS把軟體售賣改成了租用模式，倒逼軟體企業去提升產品質量和服務，否則軟體公司的續費率很難保障。
這是SaaS模式積極的一面。在美國出現SaaS服務之前，軟體巨頭的產品非常昂貴，昂貴就限制了軟體的推廣應用，導致很多中小企業很難受益於資訊化發展。
SaaS模式降低了中小企業的進入門檻，做大了中底層使用者，然後再向高階衝擊。
Salesforce在美國的成功，就是適應了美國社會的時代需求，給使用者帶來了福利。
SaaS模式適應了網際網路時代的需求，相比傳統軟體的單機或者區域網部署，SaaS部署在雲上，方便企業進行管理，也讓很多網際網路C端的需求可以更方便對接。
例如，餐飲SaaS和外賣平臺進行對接。因為是統一部署，所以升級相對比較方便，只要升級伺服器端即可。
在SaaS出現之前，很多連鎖管理軟體都採用手動傳輸，實現各個門店和總部的資料傳輸，即使有些聲稱自動化傳輸的應用，也普遍存在丟包、資料不同步等問題。SaaS因為資料都放在雲上面，所以客觀上回避了資料傳輸等問題。
SaaS模式讓軟體公司收費也變得簡單，不續費直接斷掉服務即可，也不用去催賬。
02
SaaS天生存在的侷限性
不過，SaaS天然存在嚴重的網路依賴症。網路的穩定性就和天氣一樣，影響的因素非常多，不同時間段、不同地區、不同商場都可能不同。
我在前面文章打了一個比喻，90年代北京路不寬，但並不經常堵車。現在北京路寬了很多，反而常常堵車，那是因為車多了。
就像現在網路雖然快了，可使用的人和應用更多了，網路資源永遠都是一個寶貴資源，是有價資源，這和道路擁堵的道理是一樣的。
現在的SaaS軟體一般都在雲上，雲便宜嗎？穩定可靠嗎？這個可以看看我在一個服裝軟體群收集到的一線網管人員的感受。
很多SaaS軟體是基於瀏覽器的，瀏覽器相容性就是一個大問題，比如IE，經常因為什麼外掛就導致莫名其妙的問題。
阿里雲現在還是虧損的，現在雲頻寬已經不便宜了，以後只會更貴。某知名餐飲SaaS平臺前段時間也被爆出穩定性問題，大家都可以百度一下。
因為嚴重依賴網路，一般SaaS結構的軟體都會實現分頁查詢，限制使用者一次查詢的資料的數量。比如幾十條，因為資料查詢量小，佔用頻寬少，這樣對伺服器的壓力也小。網路依賴症的問題會阻礙SaaS向高階使用者發展。
對於通常的收銀業務流程，SaaS還是沒有問題的，但如果進行資料分析就麻煩了。當然SaaS使用者很多都是小的餐飲使用者，對資料分析沒有啥要求，但對上規模的連鎖企業就不適合了。
03
SAAS更適合什麼行業？
SaaS不適合操作性強的行業，例如重餐飲行業，SKU多的行業，反之就適合。
重餐飲行業的特點是每個門店都由多個部門、多個電腦組成，有的還要連線大量不同的印表機等終端裝置。
這類門店本身就是一個獨立性很強的區域性機構，因為操作量大，對穩定性要求也很高，使用SaaS反而會出現穩定性隱患。
反之，輕餐飲如奶茶店這些，因為通常只完成收銀，裝置也很少，所以SaaS還可以使用。
在我看來，
SKU多的行業，比如服裝連鎖行業是不太適合使用SaaS的。
因為中大型服裝連鎖SKU數量超過5萬是很普遍的。由於每季都要上新款，一款因為顏色和尺碼的原因往往包含10個以上的SKU，導致SKU的膨脹非常快的。
SKU多的還有超市門店，超市收銀點多，收銀量大，對系統穩定性要求非常高，所以使用SaaS的機率幾乎等於0。
很多生產製造業的ERP，MES和倉庫管理等系統，對穩定性要求也很高，使用頻繁，對操作性要求也非常高，這些行業也不適合SaaS模式。
上面講的這些行業應用，多是在供應鏈管理方面，業務之間關聯性非常強，一個地方穩定性出現問題，往往會影響到很多方面，一個錯誤就可能導致後續多個錯誤發生。
所以，
SaaS適合的行業往往是資料多、讀取操作比較少的行業，比如CRM。
這類產品多是看客戶的資料資訊，客戶資料之間關聯性也很弱。即使需要錄入新的客戶資料，強度也不會很大，哪怕網路發生問題，後面錄入也可以。
SaaS適合不適合某個行業，關鍵還是要看資料量和關聯性。資料量越多關聯性越大，則越不適合。
大家可能有疑問，人家淘寶和微信那麼多資料，為啥也使用雲模式，即資料集中在伺服器端的模式，和SaaS本質差不多。
記得前些年很多人把雙十一和12306買票做對比，覺得12306和雙11相比簡直弱爆了，一般外行人或者行業非資深的人都會這麼看。
之所以這麼看，是因為這種對比只考慮了資料量，而沒有考慮到資料的關聯性，單純資料量的比較是不科學的。
為了解釋關聯性，我舉個行政部門辦事的例子。如果大家辦的事情都是一件事而且是一樣的，提升處理能力的方式很簡單，投入10倍的辦事人員，就能提升10倍的速度，因為這些事務之間是獨立的，無關聯的。
可當大家需要辦理多個事情，而且事情之間是有先後順序的，事情辦理的時間也存在不確定性，我們還能夠簡單的加多處理人員來提升效率嗎？
因為關聯度高，導致問題變得複雜，任何一個地方都可能出現瓶頸，簡單加人可能帶來混亂，導致相反的效果。
淘寶微信這些場景，大量資料都是非關聯的，而且是生成後就很少變化的資料，非常適合使用CDN（一種非常成熟的網際網路快取技術）。
因為資料之間是獨立的，所以可以直接透過新增機器量來擴大處理能力，專業名稱叫做線性擴充套件。
再有，當大家去羨慕人家強大的資料處理能力的時候，其實也要看看這些巨頭投入的機器數量是多少，頻寬資源是多少，人力成本是多少。
再加上盈利模式不同，也讓巨頭可以透過壟斷，承擔這些高昂成本，同時實現非常高的利潤。
所以，很多SaaS企業喜歡拿淘寶和微信來做類別，覺得以後自己規模擴大了，資料處理能力不是問題。這種思路往往忽略了很多SaaS行業的資料都是強關聯資料，
“他人的金剛鑽未必能搞定你的瓷器活兒”。
04
影響資料量的多種原因
影響資料量的因素是多個方面的，門店數量、SKU數量，顯然這兩個數量越多，總體資料量越多。
另外一個因素大家往往會忽略，就是使用者使用的模式習慣。例如，服裝門店的應用，如果收銀員只完成收銀工作和查個別款的庫存，提交和返回的資料量很少，所以出現問題的機率會降低。
所以說，單純比較一個系統支撐了多少個門店是沒有意義的，如果是高價值商品收銀，頻次低而且SKU少，確實容易支撐很多門店的併發。畢竟單店資料量不多，對伺服器和頻寬壓力不大。
因此，為了提升併發的門店數量，很多系統會限制單店的資料訪問量，比如透過分頁技術減少一次返回的資料量，這個在SaaS產品中是非常普遍的，幾乎成了標配。
本人曾經讓朋友去某國際知名品牌的時裝門店工作過2個月，目的是調研他們使用的軟體系統。
該系統使用了SaaS一樣的直連伺服器訪問模式，軟體系統只能查到當季貨品的情況，這樣可以減少SKU數量，門店人員一般只查詢簡單報表，返回資料量都比較少，庫存查詢一般也是查詢某個款的資料，所以返回資料量比較少。
其實這些還算可以接受，但會員部分就有些差了，只能在收銀的時候，在對話方塊中檢視到單個會員的簡單資訊，如積分數量。
因為SaaS直連模式對門店資料訪問量做了限制，所以門店不能執行高質量的資料分析。例如和歷史銷售資料進行對比，做深度的會員畫像分析。
因為這些分析需要讀取的資料量大，容易觸發效能問題，所以，資料分析一般都是總部來做的。
最能理解資料場景和業務背景的門店人員不能去分析和解讀資料，而總部的人只能在資料表面上理解資料，可他們未必清楚門店的具體情況，資料的理解和解讀可能就會出現問題。
所以，最可靠的辦法是門店和總部都做資料分析，讓雙方進行交叉驗證，避免決策的失誤。
上面講資料分析的事情，就是想說明企業的經營模式也會影響資料量，也就是使用者模式習慣。如果企業希望門店店長能夠把握市場戰機、隨機應變，一定要提升店長的資料分析能力。若只希望店長是聽命令的，則不需要提升店長IT能力。
隨著消費市場越來越多樣化和快節奏，能夠靈活應變和分析市場的店長會更加具備優勢，也能更好的給總部反饋市場資訊，實現門店和總部雙向互動。這才是更具價值的方向。
05
廣域網分散式計算，
解決多門店系統穩定性的利器
透過上面的分析，我們可以看到SaaS自身的網路強依賴性，導致在一些行業領域是達不到要求的，而廣域網分散式計算可以完美的解決這個問題，結構如下圖：
廣域網分散式計算，可以保證每個門店都有各種資料庫，門店的執行只依賴門店自身的資料庫。即使網際網路網不穩定或者斷網，都不會影響到門店自身的執行，保證了門店系統穩定。
因為門店自己有資料庫，所以可以存放大量的門店自身的歷史資料，可以支撐門店自身的各種資料分析要求。
資料互動則透過資料傳輸平臺來完成，總部是資料交換中心樞紐，門店變化的增量資料會實時傳輸到總部，然後傳輸到其它的相關門店，增量傳輸大大降低了網路的傳輸量，大大提升了頻寬的使用效率。
因為SaaS是全量重複傳輸，每次查詢資料，全部資料都需要重新傳到門店，導致網路資源浪費。而分散式計算則充分利用了本地計算資源，大大降低了對總部伺服器的負載壓力，讓總部伺服器的應對能力提升了幾十倍以上。
少資源，高效率，讓分散式計算可以節約企業的大量成本。
其實網際網路大資料計算，雲計算都是建立在分散式計算上面的，不過區域網分散式計算和這裡提到的廣域網模式是有很大區別的。
區域網分散式計算透過大量廉價的伺服器，實現了比之前昂貴的巨型機強大太多的計算能力，為網際網路企業大大節約了成本，是網際網路行業爆發的基礎條件。否則，利潤都被IBM和Oracle這些傳統巨頭拿去了。
同理，廣域網網分散式計算，可以為企業節約在計算力和網路方面的大量成本，還保證了更高的穩定性，提供了更強大的門店資料分析能力。
下面是一個真實的費用花銷對比，我們的一個服裝連鎖客戶，有200家門店，使用廣域網分散式計算。
一臺幾年前的PC伺服器帶動了全部門店，而且還要支撐幾十個總部人員的使用。2個分析師在工廠以遠端SaaS方式訪問總部伺服器，常常拉取1G以上的資料量。總部伺服器連線到200M的商業光纖頻寬上面，每年網路費用是3000元。
因為我們不是知名品牌，所以客戶老闆在個別人忽悠下，嘗試換知名品牌的系統，老闆不懂系統，簡單認為品牌越大，系統也就越好。
一個阿里投資的行業頭牌企業提供了雲SaaS解決方案，每年的SaaS固定費用是6萬（不是系統購買費用），頻寬不到5M。下面是阿里雲的頻寬費用表，可以看到6M以上的頻寬，成本會大幅增加。
下圖是分析師拉去全部庫存資訊，匯入到EXCEL表格進行分析的案例。
廣域網分散式計算的應用場景
前面提到的重型餐飲，SKU多的超市和服裝連鎖行業都是這種技術的應用場景。傳輸平臺解決了互聯問題，可以對接各種電商平臺，電商的訂單和資訊實時的傳輸到相應的門店系統中。
例如，電商下訂單，指定門店進行發貨，使用者在平臺進行訂餐和選臺，使用者線上購買超市貨品，不用擔心庫存不足問題，因為線下超市庫存情況會實時傳輸到線上平臺。這種計算模式還支援系統的遠端自動升級，讓後期的系統維護變得自動化和簡單。
///
總結
所以，SaaS模式相較於傳統軟體產品，雖然是先進的，可並不是包治百病，可以解決所有企業資訊化的良方。
企業進行數字化轉型、軟體部署，一定要對症下藥，要使用最適合自己的產品，而不是最新穎、最前衛的概念。
SaaS好與不好，是否適合某個行業、某家企業，需要根據實際業務需求和使用場景，具體問題具體分析。
從最基本的判斷點來看，企業一定要清楚自己的資料量和資料關聯性，以及使用者對穩定性的接受程度。