最近幾年涌現(xiàn)了很多SaaS公司，很多資本也進(jìn)入了這個行業(yè)，但是大家不能因為看到幾家美國SaaS公司成功，就認(rèn)為SaaS在中國也會成功。

這種對比過于簡單，忽略了很多客觀因素。就像韓信背水一戰(zhàn)成功后，我們也去類比模仿一樣。

所以，本文會從SaaS優(yōu)缺點兩個方面來談?wù)劊?strong>是不是中國所有行業(yè)都適合使用SaaS？SaaS是「包治百病」的良藥嗎？

01 SaaS出現(xiàn)的背景原因和優(yōu)勢

SaaS把軟件售賣改成了租用模式，倒逼軟件企業(yè)去提升產(chǎn)品質(zhì)量和服務(wù)，否則軟件公司的續(xù)費率很難保障。

這是SaaS模式積極的一面。在美國出現(xiàn)SaaS服務(wù)之前，軟件巨頭的產(chǎn)品非常昂貴，昂貴就限制了軟件的推廣應(yīng)用，導(dǎo)致很多中小企業(yè)很難受益于信息化發(fā)展。

SaaS模式降低了中小企業(yè)的進(jìn)入門檻，做大了中底層用戶，然后再向高端沖擊。Salesforce在美國的成功，就是適應(yīng)了美國社會的時代需求，給用戶帶來了福利。

SaaS模式適應(yīng)了互聯(lián)網(wǎng)時代的需求，相比傳統(tǒng)軟件的單機或者局域網(wǎng)部署，SaaS部署在云上，方便企業(yè)進(jìn)行管理，也讓很多互聯(lián)網(wǎng)C端的需求可以更方便對接。

例如，餐飲SaaS和外賣平臺進(jìn)行對接。因為是統(tǒng)一部署，所以升級相對比較方便，只要升級服務(wù)器端即可。

在SaaS出現(xiàn)之前，很多連鎖管理軟件都采用手動傳輸，實現(xiàn)各個門店和總部的數(shù)據(jù)傳輸，即使有些聲稱自動化傳輸?shù)膽?yīng)用，也普遍存在丟包、數(shù)據(jù)不同步等問題。SaaS因為數(shù)據(jù)都放在云上面，所以客觀上回避了數(shù)據(jù)傳輸?shù)葐栴}。

SaaS模式讓軟件公司收費也變得簡單，不續(xù)費直接斷掉服務(wù)即可，也不用去催賬。

02 SaaS天生存在的局限性

不過，SaaS天然存在嚴(yán)重的網(wǎng)絡(luò)依賴癥。網(wǎng)絡(luò)的穩(wěn)定性就和天氣一樣，影響的因素非常多，不同時間段、不同地區(qū)、不同商場都可能不同。

我在前面文章打了一個比喻，90年代北京路不寬，但并不經(jīng)常堵車?，F(xiàn)在北京路寬了很多，反而常常堵車，那是因為車多了。

就像現(xiàn)在網(wǎng)絡(luò)雖然快了，可使用的人和應(yīng)用更多了，網(wǎng)絡(luò)資源永遠(yuǎn)都是一個寶貴資源，是有價資源，這和道路擁堵的道理是一樣的。

現(xiàn)在的SaaS軟件一般都在云上，云便宜嗎？穩(wěn)定可靠嗎？這個可以看看我在一個服裝軟件群收集到的一線網(wǎng)管人員的感受。

很多SaaS軟件是基于瀏覽器的，瀏覽器兼容性就是一個大問題，比如IE，經(jīng)常因為什么插件就導(dǎo)致莫名其妙的問題。

阿里云現(xiàn)在還是虧損的，現(xiàn)在云帶寬已經(jīng)不便宜了，以后只會更貴。某知名餐飲SaaS平臺前段時間也被爆出穩(wěn)定性問題，大家都可以百度一下。

因為嚴(yán)重依賴網(wǎng)絡(luò)，一般SaaS結(jié)構(gòu)的軟件都會實現(xiàn)分頁查詢，限制用戶一次查詢的數(shù)據(jù)的數(shù)量。比如幾十條，因為數(shù)據(jù)查詢量小，占用帶寬少，這樣對服務(wù)器的壓力也小。網(wǎng)絡(luò)依賴癥的問題會阻礙SaaS向高端用戶發(fā)展。

對于通常的收銀業(yè)務(wù)流程，SaaS還是沒有問題的，但如果進(jìn)行數(shù)據(jù)分析就麻煩了。當(dāng)然SaaS用戶很多都是小的餐飲用戶，對數(shù)據(jù)分析沒有啥要求，但對上規(guī)模的連鎖企業(yè)就不適合了。 

03 SAAS更適合什么行業(yè)？

SaaS不適合操作性強的行業(yè)，例如重餐飲行業(yè)，SKU多的行業(yè)，反之就適合。

重餐飲行業(yè)的特點是每個門店都由多個部門、多個電腦組成，有的還要連接大量不同的打印機等終端設(shè)備。

這類門店本身就是一個獨立性很強的局部機構(gòu)，因為操作量大，對穩(wěn)定性要求也很高，使用SaaS反而會出現(xiàn)穩(wěn)定性隱患。

反之，輕餐飲如奶茶店這些，因為通常只完成收銀，設(shè)備也很少，所以SaaS還可以使用。

在我看來，SKU多的行業(yè)，比如服裝連鎖行業(yè)是不太適合使用SaaS的。

因為中大型服裝連鎖SKU數(shù)量超過5萬是很普遍的。由于每季都要上新款，一款因為顏色和尺碼的原因往往包含10個以上的SKU，導(dǎo)致SKU的膨脹非?？斓?。

SKU多的還有超市門店，超市收銀點多，收銀量大，對系統(tǒng)穩(wěn)定性要求非常高，所以使用SaaS的概率幾乎等于0。

很多生產(chǎn)制造業(yè)的ERP，MES和倉庫管理等系統(tǒng)，對穩(wěn)定性要求也很高，使用頻繁，對操作性要求也非常高，這些行業(yè)也不適合SaaS模式。

上面講的這些行業(yè)應(yīng)用，多是在供應(yīng)鏈管理方面，業(yè)務(wù)之間關(guān)聯(lián)性非常強，一個地方穩(wěn)定性出現(xiàn)問題，往往會影響到很多方面，一個錯誤就可能導(dǎo)致后續(xù)多個錯誤發(fā)生。

所以，SaaS適合的行業(yè)往往是數(shù)據(jù)多、讀取操作比較少的行業(yè)，比如CRM。這類產(chǎn)品多是看客戶的數(shù)據(jù)信息，客戶數(shù)據(jù)之間關(guān)聯(lián)性也很弱。即使需要錄入新的客戶數(shù)據(jù)，強度也不會很大，哪怕網(wǎng)絡(luò)發(fā)生問題，后面錄入也可以。

SaaS適合不適合某個行業(yè)，關(guān)鍵還是要看數(shù)據(jù)量和關(guān)聯(lián)性。數(shù)據(jù)量越多關(guān)聯(lián)性越大，則越不適合。

大家可能有疑問，人家淘寶和微信那么多數(shù)據(jù)，為啥也使用云模式，即數(shù)據(jù)集中在服務(wù)器端的模式，和SaaS本質(zhì)差不多。

記得前些年很多人把雙十一和12306買票做對比，覺得12306和雙11相比簡直弱爆了，一般外行人或者行業(yè)非資深的人都會這么看。

之所以這么看，是因為這種對比只考慮了數(shù)據(jù)量，而沒有考慮到數(shù)據(jù)的關(guān)聯(lián)性，單純數(shù)據(jù)量的比較是不科學(xué)的。

為了解釋關(guān)聯(lián)性，我舉個行政部門辦事的例子。如果大家辦的事情都是一件事而且是一樣的，提升處理能力的方式很簡單，投入10倍的辦事人員，就能提升10倍的速度，因為這些事務(wù)之間是獨立的，無關(guān)聯(lián)的。

可當(dāng)大家需要辦理多個事情，而且事情之間是有先后順序的，事情辦理的時間也存在不確定性，我們還能夠簡單的加多處理人員來提升效率嗎？

因為關(guān)聯(lián)度高，導(dǎo)致問題變得復(fù)雜，任何一個地方都可能出現(xiàn)瓶頸，簡單加人可能帶來混亂，導(dǎo)致相反的效果。

淘寶微信這些場景，大量數(shù)據(jù)都是非關(guān)聯(lián)的，而且是生成后就很少變化的數(shù)據(jù)，非常適合使用CDN(一種非常成熟的互聯(lián)網(wǎng)緩存技術(shù))。

因為數(shù)據(jù)之間是獨立的，所以可以直接通過添加機器量來擴大處理能力，專業(yè)名稱叫做線性擴展。

再有，當(dāng)大家去羨慕人家強大的數(shù)據(jù)處理能力的時候，其實也要看看這些巨頭投入的機器數(shù)量是多少，帶寬資源是多少，人力成本是多少。

再加上盈利模式不同，也讓巨頭可以通過壟斷，承擔(dān)這些高昂成本，同時實現(xiàn)非常高的利潤。

所以，很多SaaS企業(yè)喜歡拿淘寶和微信來做類別，覺得以后自己規(guī)模擴大了，數(shù)據(jù)處理能力不是問題。這種思路往往忽略了很多SaaS行業(yè)的數(shù)據(jù)都是強關(guān)聯(lián)數(shù)據(jù)，“他人的金剛鉆未必能搞定你的瓷器活兒”。

04 影響數(shù)據(jù)量的多種原因

影響數(shù)據(jù)量的因素是多個方面的，門店數(shù)量、SKU數(shù)量，顯然這兩個數(shù)量越多，總體數(shù)據(jù)量越多。

另外一個因素大家往往會忽略，就是用戶使用的模式習(xí)慣。例如，服裝門店的應(yīng)用，如果收銀員只完成收銀工作和查個別款的庫存，提交和返回的數(shù)據(jù)量很少，所以出現(xiàn)問題的概率會降低。

所以說，單純比較一個系統(tǒng)支撐了多少個門店是沒有意義的，如果是高價值商品收銀，頻次低而且SKU少，確實容易支撐很多門店的并發(fā)。畢竟單店數(shù)據(jù)量不多，對服務(wù)器和帶寬壓力不大。

因此，為了提升并發(fā)的門店數(shù)量，很多系統(tǒng)會限制單店的數(shù)據(jù)訪問量，比如通過分頁技術(shù)減少一次返回的數(shù)據(jù)量，這個在SaaS產(chǎn)品中是非常普遍的，幾乎成了標(biāo)配。

本人曾經(jīng)讓朋友去某國際知名品牌的時裝門店工作過2個月，目的是調(diào)研他們使用的軟件系統(tǒng)。

該系統(tǒng)使用了SaaS一樣的直連服務(wù)器訪問模式，軟件系統(tǒng)只能查到當(dāng)季貨品的情況，這樣可以減少SKU數(shù)量，門店人員一般只查詢簡單報表，返回數(shù)據(jù)量都比較少，庫存查詢一般也是查詢某個款的數(shù)據(jù)，所以返回數(shù)據(jù)量比較少。

其實這些還算可以接受，但會員部分就有些差了，只能在收銀的時候，在對話框中查看到單個會員的簡單信息，如積分?jǐn)?shù)量。

因為SaaS直連模式對門店數(shù)據(jù)訪問量做了限制，所以門店不能執(zhí)行高質(zhì)量的數(shù)據(jù)分析。例如和歷史銷售數(shù)據(jù)進(jìn)行對比，做深度的會員畫像分析。

因為這些分析需要讀取的數(shù)據(jù)量大，容易觸發(fā)性能問題，所以，數(shù)據(jù)分析一般都是總部來做的。

最能理解數(shù)據(jù)場景和業(yè)務(wù)背景的門店人員不能去分析和解讀數(shù)據(jù)，而總部的人只能在數(shù)據(jù)表面上理解數(shù)據(jù)，可他們未必清楚門店的具體情況，數(shù)據(jù)的理解和解讀可能就會出現(xiàn)問題。

所以，最可靠的辦法是門店和總部都做數(shù)據(jù)分析，讓雙方進(jìn)行交叉驗證，避免決策的失誤。

上面講數(shù)據(jù)分析的事情，就是想說明企業(yè)的經(jīng)營模式也會影響數(shù)據(jù)量，也就是用戶模式習(xí)慣。如果企業(yè)希望門店店長能夠把握市場戰(zhàn)機、隨機應(yīng)變，一定要提升店長的數(shù)據(jù)分析能力。若只希望店長是聽命令的，則不需要提升店長IT能力。

隨著消費市場越來越多樣化和快節(jié)奏，能夠靈活應(yīng)變和分析市場的店長會更加具備優(yōu)勢，也能更好的給總部反饋市場信息，實現(xiàn)門店和總部雙向互動。這才是更具價值的方向。

05 廣域網(wǎng)分布式計算，解決多門店系統(tǒng)穩(wěn)定性的利器

通過上面的分析，我們可以看到SaaS自身的網(wǎng)絡(luò)強依賴性，導(dǎo)致在一些行業(yè)領(lǐng)域是達(dá)不到要求的，而廣域網(wǎng)分布式計算可以完美的解決這個問題，結(jié)構(gòu)如下圖：

廣域網(wǎng)分布式計算，可以保證每個門店都有各種數(shù)據(jù)庫，門店的運行只依賴門店自身的數(shù)據(jù)庫。即使互聯(lián)網(wǎng)網(wǎng)不穩(wěn)定或者斷網(wǎng)，都不會影響到門店自身的運行，保證了門店系統(tǒng)穩(wěn)定。

因為門店自己有數(shù)據(jù)庫，所以可以存放大量的門店自身的歷史數(shù)據(jù)，可以支撐門店自身的各種數(shù)據(jù)分析要求。

數(shù)據(jù)交互則通過數(shù)據(jù)傳輸平臺來完成，總部是數(shù)據(jù)交換中心樞紐，門店變化的增量數(shù)據(jù)會實時傳輸?shù)娇偛?，然后傳輸?shù)狡渌南嚓P(guān)門店，增量傳輸大大降低了網(wǎng)絡(luò)的傳輸量，大大提升了帶寬的使用效率。

因為SaaS是全量重復(fù)傳輸，每次查詢數(shù)據(jù)，全部數(shù)據(jù)都需要重新傳到門店，導(dǎo)致網(wǎng)絡(luò)資源浪費。而分布式計算則充分利用了本地計算資源，大大降低了對總部服務(wù)器的負(fù)載壓力，讓總部服務(wù)器的應(yīng)對能力提升了幾十倍以上。

少資源，高效率，讓分布式計算可以節(jié)約企業(yè)的大量成本。

其實互聯(lián)網(wǎng)大數(shù)據(jù)計算，云計算都是建立在分布式計算上面的，不過局域網(wǎng)分布式計算和這里提到的廣域網(wǎng)模式是有很大區(qū)別的。

局域網(wǎng)分布式計算通過大量廉價的服務(wù)器，實現(xiàn)了比之前昂貴的巨型機強大太多的計算能力，為互聯(lián)網(wǎng)企業(yè)大大節(jié)約了成本，是互聯(lián)網(wǎng)行業(yè)爆發(fā)的基礎(chǔ)條件。否則，利潤都被IBM和Oracle這些傳統(tǒng)巨頭拿去了。

同理，廣域網(wǎng)網(wǎng)分布式計算，可以為企業(yè)節(jié)約在計算力和網(wǎng)絡(luò)方面的大量成本，還保證了更高的穩(wěn)定性，提供了更強大的門店數(shù)據(jù)分析能力。

下面是一個真實的費用花銷對比，我們的一個服裝連鎖客戶，有200家門店，使用廣域網(wǎng)分布式計算。

一臺幾年前的PC服務(wù)器帶動了全部門店，而且還要支撐幾十個總部人員的使用。2個分析師在工廠以遠(yuǎn)程SaaS方式訪問總部服務(wù)器，常常拉取1G以上的數(shù)據(jù)量。總部服務(wù)器連接到200M的商業(yè)光纖帶寬上面，每年網(wǎng)絡(luò)費用是3000元。

因為我們不是知名品牌，所以客戶老板在個別人忽悠下，嘗試換知名品牌的系統(tǒng)，老板不懂系統(tǒng)，簡單認(rèn)為品牌越大，系統(tǒng)也就越好。

一個阿里投資的行業(yè)頭牌企業(yè)提供了云SaaS解決方案，每年的SaaS固定費用是6萬(不是系統(tǒng)購買費用)，帶寬不到5M。下面是阿里云的帶寬費用表，可以看到6M以上的帶寬，成本會大幅增加。

下圖是分析師拉去全部庫存信息，導(dǎo)入到EXCEL表格進(jìn)行分析的案例。

廣域網(wǎng)分布式計算的應(yīng)用場景

前面提到的重型餐飲，SKU多的超市和服裝連鎖行業(yè)都是這種技術(shù)的應(yīng)用場景。傳輸平臺解決了互聯(lián)問題，可以對接各種電商平臺，電商的訂單和信息實時的傳輸?shù)较鄳?yīng)的門店系統(tǒng)中。

例如，電商下訂單，指定門店進(jìn)行發(fā)貨，用戶在平臺進(jìn)行訂餐和選臺，用戶線上購買超市貨品，不用擔(dān)心庫存不足問題，因為線下超市庫存情況會實時傳輸?shù)骄€上平臺。這種計算模式還支持系統(tǒng)的遠(yuǎn)程自動升級，讓后期的系統(tǒng)維護(hù)變得自動化和簡單。

總結(jié)

所以，SaaS模式相較于傳統(tǒng)軟件產(chǎn)品，雖然是先進(jìn)的，可并不是包治百病，可以解決所有企業(yè)信息化的良方。

企業(yè)進(jìn)行數(shù)字化轉(zhuǎn)型、軟件部署，一定要對癥下藥，要使用最適合自己的產(chǎn)品，而不是最新穎、最前衛(wèi)的概念。

SaaS好與不好，是否適合某個行業(yè)、某家企業(yè)，需要根據(jù)實際業(yè)務(wù)需求和使用場景，具體問題具體分析。

從最基本的判斷點來看，企業(yè)一定要清楚自己的數(shù)據(jù)量和數(shù)據(jù)關(guān)聯(lián)性，以及用戶對穩(wěn)定性的接受程度。

【鈦媒體作者介紹：黃允聰，20多年的信息化老兵，對中國2025信息化具有很深的思考，一直在研究如何通過提升軟件開發(fā)效率，降低成本，提升中國的信息化水平。公眾號【可持續(xù)開發(fā)】，文章主要探討如何普及和提升企業(yè)信息化水平，以及過程中面臨的困難和解決方法。如何通過提升信息化管理水平來實現(xiàn)新零售，提升企業(yè)的盈利能力等?！?/p>