編輯導(dǎo)語：近年SaaS化產(chǎn)品也是越來越火爆，那么在未來，SaaS會(huì)如何發(fā)展呢？這篇文章作者從四個(gè)方面一產(chǎn)品角度詳細(xì)闡述了SaaS的發(fā)展趨勢，有興趣的童鞋一起來看看吧。

很多SaaS產(chǎn)品的誕生是從一個(gè)或幾個(gè)項(xiàng)目就開始干的，起步階段相對容易產(chǎn)品化，同時(shí)滿足不同項(xiàng)目的需求。

但隨著項(xiàng)目越來越多，需求的必然千差萬別，很多需求在初期階段是很難拍腦袋想出來的，產(chǎn)品經(jīng)理只能憑自己的業(yè)務(wù)理解和行業(yè)認(rèn)知等盡可能多的去結(jié)構(gòu)化、配置化地設(shè)計(jì)產(chǎn)品，但終歸無法做到滿足所有新的客戶和項(xiàng)目的需求。

在后期的迭代過程中產(chǎn)品面臨很多問題和選擇。

一、這個(gè)客戶的需求，要不要滿足？要不要產(chǎn)品化？

SaaS主要服務(wù)于企業(yè)，不同階段的考慮點(diǎn)不一樣。

1. 初期階段

在初期產(chǎn)品話語權(quán)不強(qiáng)時(shí)，都必然不太會(huì)拒絕客戶的需求，畢竟客戶是衣食父母。同時(shí)這階段的需求來源也不是特別多，我們是很歡迎客戶來提出需求，以滿足產(chǎn)品的豐富、靈活、前瞻性。當(dāng)然特別奇葩的除外。

2. 成熟階段

若SaaS發(fā)展到一定階段，特別是已經(jīng)有很多企業(yè)在用我們的產(chǎn)品時(shí)，這時(shí)有了一定的行業(yè)認(rèn)知和累積，就需要評判了。主要看該功能是否是大部分客戶需要的，該功能是否符合產(chǎn)品的長遠(yuǎn)發(fā)展。

若僅僅個(gè)別企業(yè)需要，那么建議不要納入產(chǎn)品中，否則失去把控，產(chǎn)品會(huì)慢慢變得臃腫、瑣碎，甚至?xí)绊懫渌蛻舻氖褂皿w驗(yàn)。

當(dāng)然，拒絕需求很可能引起客戶不爽，這時(shí)產(chǎn)品需要提供一些可行的解決方案，盡量讓客戶滿意。

比如，客戶需要增加一個(gè)獨(dú)特的字段，可以建議客戶利用某備注欄位；比如客戶有不同的業(yè)務(wù)流程，可以問他能否改變現(xiàn)有流程；比如客戶要增加一個(gè)審批功能，那么你可以解釋加了該功能，需要增加提交人、審批人這些角色的工作、會(huì)有審批拒絕往復(fù)不斷的繁瑣等等，還不如線下審批的靈活性等等。

總之，一方面降低客戶的預(yù)期，一方面也對客戶的需求上心，因?yàn)榭赡芩鎸Φ膯栴}，并不是系統(tǒng)工具就能解決的。但在項(xiàng)目過程中盡量避免出現(xiàn)“客戶沒有一條路可走”的局面。

拒絕不可能是常態(tài)，畢竟產(chǎn)品要不斷的迭代，需求來源也更多是客戶的新需求，這時(shí)產(chǎn)品不得不變得復(fù)雜。

二、SaaS產(chǎn)品在迭代中的復(fù)雜性

1. 業(yè)務(wù)的復(fù)雜性

SaaS產(chǎn)品的復(fù)雜性首先來自基礎(chǔ)業(yè)務(wù)的不斷復(fù)雜。

比如一個(gè)審批功能，從最開始的一級審批，到后面就是多級審批、多方共審、拒后跳轉(zhuǎn)到哪個(gè)階段、什么情況下不可再次提交等規(guī)則，其中還涉及哪些角色能看哪些數(shù)據(jù)（如本人、本部門、上下級、全部等）、哪些字段（如財(cái)務(wù)方面敏感字段）。

同時(shí)，考慮到產(chǎn)品中會(huì)有很多單據(jù)審核的地方，是否可以將這些審核提煉到一個(gè)公用的配置模塊以后就不用重復(fù)造輪子了？可見，最初一個(gè)簡單的審批功能，到最后就是一個(gè)龐然大物。

這時(shí)需要產(chǎn)品經(jīng)理的全局觀，結(jié)合現(xiàn)有情況去判斷功能做到什么程度、價(jià)值、擴(kuò)展性、客戶的使用成本、開發(fā)資源等。

也還有很多業(yè)務(wù)擴(kuò)展，如之前只做線上現(xiàn)在要做線下，之前只管訂單，后面要管供應(yīng)商、物流、品控、財(cái)務(wù)、AI方向、Iot方向等等，就更加豐富了?；径际怯牲c(diǎn)到線到面的發(fā)展，讓你的產(chǎn)品不斷成長。

2. 用戶體系的復(fù)雜性

此處的用戶體系主要指賬戶、角色、權(quán)限等基礎(chǔ)管理。雖然是一個(gè)產(chǎn)品很基礎(chǔ)的東西，但是很多業(yè)務(wù)的擴(kuò)展就夾雜著用戶體系的不斷復(fù)雜化，如果沒有統(tǒng)籌計(jì)劃，那么用戶角色權(quán)限這部分就會(huì)像補(bǔ)丁一樣的讓產(chǎn)品復(fù)雜。

你肯定有這樣的體驗(yàn)：一個(gè)功能中一個(gè)簡單的列表，如果涉及到很多部門（銷售、采購、倉儲(chǔ)）、很多相關(guān)人(舉例創(chuàng)建人、采購員、采購主管、質(zhì)檢員)以及其他很多字段，客戶對權(quán)限有著各式各樣的需求，有人要看這，有人要看那，有人不要看這，有人不能看那，有些人都可看。

不同企業(yè)的管理方式、不同關(guān)鍵用戶的認(rèn)知都不一樣，所以都是合理的。

一個(gè)系統(tǒng)角色要控制的點(diǎn)太多了，功能權(quán)限(頁面&按鈕)、數(shù)據(jù)權(quán)限（靈活的規(guī)則）、字段權(quán)限（列表頁、詳情頁具體字段），已經(jīng)不是一個(gè)簡單的RBAC能解決的了。

因此基礎(chǔ)建設(shè)的問題在產(chǎn)品發(fā)展后期會(huì)越來越突出，也更棘手。同時(shí)，這部分產(chǎn)品設(shè)計(jì)及開發(fā)工作，竟然是又繁瑣又無趣又沒有高光的部分。

3. 版本管理與版本發(fā)布的復(fù)雜性

如果你的產(chǎn)品支持多個(gè)版本，那么意味著開發(fā)、測試、客服、運(yùn)營都得兼容歷史版本，也會(huì)讓SaaS產(chǎn)品復(fù)雜。建議盡量統(tǒng)一版本。

版本發(fā)布時(shí)，可能會(huì)讓引發(fā)一些奇奇怪怪的問題，特別是用戶體現(xiàn)搭建的不夠好時(shí)，發(fā)版后，可能客戶的頁面突然多冒出幾個(gè)字段，多出來一些按鈕，頁面發(fā)生變化、功能發(fā)生變化等等，盡量做到讓客戶感受不到變化吧。

總之，在產(chǎn)品的發(fā)展之路上，切記“有所為有所不為”。

三、SaaS的歸宿是什么？

一系列的操作會(huì)讓你的SaaS產(chǎn)品越來越復(fù)雜或豐富。最初可能只是較為單純的業(yè)務(wù)，到后面遍地開花。

類比ERP軟件，如SAP、OracleEBS、用友NCC等，它們就是很復(fù)雜也很豐富的成熟軟件，盡可能的支持不同企業(yè)的業(yè)務(wù)需求。它們不僅有強(qiáng)大的基礎(chǔ)建設(shè)，還有分支眾多超級多變的業(yè)務(wù)覆蓋度，在ERP面前一般的SaaS只是個(gè)弟弟。但強(qiáng)大的它們依然不能滿足所以企業(yè)的需求，“配配就能用”是所有實(shí)施人員的夢想。

因此一個(gè)不夠強(qiáng)大的SaaS平臺(tái)，產(chǎn)品的發(fā)展之路，ERP這樣的成熟軟件他們早都淌過一遍了。無非是傳統(tǒng)ERP的和SaaS部署方式、數(shù)據(jù)存儲(chǔ)等有差別，但很多ERP也在出云版本、移動(dòng)端等多產(chǎn)品形態(tài)了。

SaaS的歸宿一樣會(huì)是復(fù)雜的平臺(tái)化、配置化，但這條路依然得往前走。

四、SaaS的局限是什么？

SaaS的局限在于不適合太大的企業(yè)，僅適合中小企業(yè)。

因?yàn)閺漠a(chǎn)品本身來說，SaaS并沒有點(diǎn)顛覆或替代什么，只是另一種展現(xiàn)方式，畢竟這么多年，線下實(shí)實(shí)在在的業(yè)務(wù)都依然是那些。

大企業(yè)對數(shù)據(jù)安全敏感、對license管理更加嚴(yán)格、對新需求更加渴望、對交付更苛刻、同時(shí)也有很多系統(tǒng)要一并管理，因此會(huì)有專門的IT部門去負(fù)責(zé)。而中小企業(yè)需要的是好用、簡單、省心、省錢。

不是說SaaS產(chǎn)品Cover不了大企業(yè)的需求，而是大企業(yè)不會(huì)選擇這類產(chǎn)品，除非獨(dú)立部署+各種定制開發(fā)+基礎(chǔ)設(shè)施對齊，至少國內(nèi)現(xiàn)在是這樣的情況。

總結(jié)，從市場來說，SaaS產(chǎn)品肯定是有需求的，但可以早點(diǎn)認(rèn)識(shí)到他的局限性，產(chǎn)品經(jīng)理在做未來規(guī)劃、市場在未來推廣時(shí)，可以更好的控制范圍，把握重點(diǎn)，有所為有所不為，畢竟不可能把所有蛋糕都吃到嘴里。

本文由 @Felix 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉(zhuǎn)載。

題圖來自Unsplash，基于 CC0 協(xié)議