在市場經濟環境下，所有商業組織（主要是企業）的使命都是在于為市場提供價值，以換得相應的利潤回報。每個企業都是一個價值轉化系統，通過原材料、資本、人力資源、企業家精神、管理等要素輸入并經過企業內部的業務流程從而輸出市場所需的產品或服務。因而每個企業至少包括三個環節：入口、內部流程、出口。每一個企業的出口對應著下游企業的入口，這種上下游協同關系就構成了產業鏈。
在《九軒資本劉億舟：互聯網+的本質是新通路》一文中，把這三個環節分別定義為：上通路、中通路、下通路。可以說，今天所有的互聯網或技術性企業都在圍繞這個三個環節提供相應的服務。
近年來受資本熱捧的B2B企業其實是在幫助企業解決上通路（采購供應鏈）的問題，而SaaS和云計算等企業服務則是為企業解決中通路（內部流程管理）的問題，而一眾B2C、O2O等互聯網企業則是幫助企業解決下通路（銷售）的問題。對于服務于上通路的互聯網企業來說，提升供應鏈效率是其核心。對于服務于中通路的互聯網企業來說，本質是要幫助其所服務的提升組織內部的運營效率，對于服務于下通路的互聯網企業來說，降低獲客成本和交付成本是其核心。所有的商業變革和技術創新，都在致力于從整個社會商業流通大格局的角度提高這三段通路的效率和降低其成本。
產業演進的終極狀態通常是，整個社會的資源和要素在同一個“片層”內整合（形成幾家大型企業，不同產業能夠實現的整合程度不同，有些甚至很難整合）以實現最大程度的規模經濟效應，為產業下游提供最富效率的“公有云”服務，而整個產業就如同一串被串起來的薯片，其中只有少部分規模巨大的企業可以實現縱向一體化，而他們一般通過并購來實現，這也是留給創業者的機會，找一個“薯片”機會，迅速做大，然后被巨頭并購（感興趣的可以參閱《劉億舟：用“薯片理論”理解產業演進》一文）。
引導這種產業演進的本質規律其實是市場背后那只無形的手——交易成本最小化。顯然，當市場存在“公有云”服務的選擇并且成本更低時，把企業內部的服務職能甩給市場的專業機構來做可能更有效率，反之則反。
傳統的企業之間以及企業和消費者之間的交易都是基于傳統的“人肉”信息傳遞模式，可以形象地稱之為“賣灌裝煤氣”，而產業互聯網則致力于打通產業鏈上下游之間的信息通路，將“賣灌裝煤氣”模式變為“賣管道煤氣”。
如果說消費互聯網建立了“球”（商業組織，企業）和“點”（消費者個人）之間的連接，那么產業互聯網則試圖要建立球和球之間的數字化連接，而要建立“球”和“球”之間的數字化連接，必須要打通“球”內部的數字化連接（內部流程的信息化）。其最終愿景是要建立“生產-流通-消費”整個通路的信息化和數字化。
當單個企業在市場上的采購和銷售行為被數字化后，企業和企業之間、企業和消費者之間就從原來的“軟連接”和“冷連接”變成了“硬連接”和“熱連接”，企業自身也就實現了數字化生存。當這一愿景實現后，現有的金融風控體系、企業征信體系、采購決策體系、供銷模式都會發生巨大的變化。因為，企業作為一個市場的主體的大部分行為也納入大數據的范疇，就像今天我們每個個體已經初步實現數字化生存（各種消費行為數據被數字化），在互聯網上被一系列ID所表征那樣。
當然這是一個宏大的愿景，需要一個漫長的演變過程。沒有哪一家公司有能力從頂層設計的角度規劃所有市場參與主體之間的信息化連接，而從單個企業和單個行業出發的SaaS解決方案又往往從最終來看無法滿足社會頂層設計的需要（事實上沒有誰會從這個邏輯角度設計產品），這就注定了社會總體層面的系統集成就像單個企業內部的系統集成那樣，過分超前的設計往往都是失敗的，而滿足局部和眼前需求的設計又往往容易被推動重來。所以，從某個角度來說，浪費是不可避免的，這是市場發育和教育的成本，也是市場動態博弈的成本。
從某種意義上來說，消費互聯網時代的每一個網站都是SaaS，只不過面向消費者那一端只是一個“瘦客戶端”，而面向商家那一端最初是一個相對的“胖客戶端”，在平臺模式下，可能還無法把背后商家的業務流程給“托”起來，當然，其進一步發展目標是希望能夠全盤“托”起來，從而給商家實現信息化賦能。
在產業互聯網時代，SaaS的使命就是要站在全產業鏈的角度幫助“上通路”、“中通路”、“下通路”實現信息化和數字化。今天，任何缺乏產業互聯網思維而從孤立、短淺的角度開發的SaaS產品可能都無法迎合“大連接”時代的數據貫通要求，當然過分的超前也是不可行的，前面說了，就信息化建設而言，浪費是必須的。
今天，SaaS在企業的上通路、中通路、下通路三個環節都出現了很多創業項目，其各自有其價值邏輯和發展邏輯。在《九軒資本劉億舟：SaaS路上，你不得不直面的那些坑》（萬字文）一文中，劉億舟將所有的SaaS分成“大SaaS（管理工具型SaaS）”、“小SaaS（業務管控型SaaS）”和“供應鏈SaaS（交易平臺型SaaS）”，并分別分析各種類型SaaS的價值模式以及可能碰到的坑。
雖然，從終極格局的角度來看，SaaS是貫通整個產業鏈數據鏈條的基礎設施，但無論哪種SaaS，要能夠切入企業的具體業務并為企業所接受，必須在具體而微觀的場景中為企業提供實實在在的價值。產業互聯網和消費互聯網完全不同，如果說消費互聯網屬于“輕連接”，前期可以靠燒錢補貼可以把用戶累積起來，待用戶基礎大了以后再逐步迭代產品和服務從而“脫虛入實”的話，產業互聯網則屬于“重連接”，企業用戶的決策心智完全不同于個人消費者，企業用戶的決策更加理性而惰性、更加看重產品價值而非成本、更加具有前瞻性而看重轉換成本。因此不能用2C的互聯網思維來做SaaS產品。
理論上講，存在即數據，行為即數據。企業每天在每個業務過程都有大量的數據產生，當這些業務過程沒能通過一套軟件系統去信息化，那么這些數據就只是表現為一堆紙質文檔或者表單的數據孤島，或者雖然已經被信息化或者數據化，但是無法互聯化，那么這些數據就沒辦法被識別、被統計、被解讀、被匯總、被分析，因而也就無法產生業務價值增值。
信息化的過程本質就是：線下的工作線上化、隱性的數據顯性化、數據共享容易化、數據分析智能化。
所以，SaaS對于產業互聯網來說，其價值釋放路徑應該是按照信息化、數字化、互聯化、智能化進行演進。當然，這幾個環節并不是必然串行的，在SaaS應用的場景下，信息化、數字化、互聯化可以同步實現，而只有累計的數據足夠多且采集的數據足夠“富”（貧數據沒有太大價值）以滿足增值業務場景時才具備了智能化的價值。
以人力資源領域來說，最初我們招人要到人才市場去擺攤收簡歷，互聯網招聘網站發揮了讓我們告別了這種招人模式，產生了信息紅利1.0，但是時至今日，我們在招人環節依然有很大的痛點，簡歷不真實、匹配不精準、海選太費時、通知面試爽約而沒有數據反哺機制、員工日常表現的數據不能在職業生涯中傳遞、背景環節反饋的數據容易失真等。
如果所有的企業都基于一套SaaS系統進行人力資源的全流程管理，并累積這些數據，并且這些數據能夠在公有云上進行某種程度的互聯共享，如果這些數據能夠反哺至互聯網招聘網站，建立每個求職者的職場信用分數，那么這些互聯網招聘網站就可以發揮信息紅利2.0了，就能夠實現真正的智能招聘了。當然，如果某個HR SaaS從這個角度切入，很有可能是失敗的，后面會分析這一點。但產業互聯網的愿景，從長期來看，就是應該實現數據的互聯互通。在具體的實現形式上，既有公有云模式也有私有云模式，在涉及要素流通（如人才流動）的領域，顯然，公有云模式下的數據積累更加容易產生網絡效應和價值倍增效應。
圍繞企業服務的SaaS領域還包括原料供應鏈（分行業）、財稅、電子發票、費控、HR、社保、智能合約、知識產權、公證、法律訴訟、商業數據、投融資等領域。可以想象，當這些領域的SaaS像原始叢林一樣，其根系牢牢地抓住企業業務過程這片土壤，汲取各種業務數據，那么這些從垂直領域出發的數據未來有望基于區塊鏈技術進行整合和優化，從而實現智能化的產業互聯網。但這個過程必然會遇到很多的阻力，因為企業家們都希望別人呈現一個陽光的企業，而自己則是一個“黑盒子”。
這幾年人工智能火了以后，很多SaaS的項目一夜之間插上了AI的翅膀。然后如何區分到底是一個SaaS項目還是一個AI+的項目呢？我有一個簡單的鑒別方式。
在財務學中，通常將會計分為財務會計和管理會計。財務會計的核心職能是記錄和反映真實的財務狀況，而管理會計的核心職能是分析和優化。如果某個SaaS軟件主要是將“線下的工作線上化”，實現了業務過程的信息化，那么相當于只發揮了財務會計的職能，為業務過程管理實現了信息化賦能，這個時候沒有產生“化學反應”，只是發生了“物理反應”；而在此基礎之上，如果能夠有更多的數據挖掘和商業智能（BI）分析功能，能夠為業務優化提供可視化的報表和持續改進的建議，那么相當于進一步發揮了管理會計的職能，除了有過程管控的價值，還提供了數據賦能的價值。從整個行業來說，如果SaaS只是實現了信息化、數字化，那么只能提供過程管控的價值，如果能夠進一步實現互聯化（哪怕是內部的互聯化）、智能化，那就可以產生數據賦能的價值，也才可以稱得上SaaS+AI了。
愿景是美好的，道路是曲折的。現實中接觸很多做SaaS的兄弟，在具體的業務場景中遭遇很多的困局和挑戰。下面就幾個典型的問題展開分析，有關SaaS發展過程中可能會碰到的坑，可以進一步參閱《九軒資本劉億舟：SaaS路上，你不得不直面的那些坑》。
對于通用型SaaS（甚至某些垂直SaaS）來說，通常存在一個這樣的現象：
小微企業可用可不用，用戶黏性不高，付費意愿很低；
中等規模的企業有信息化的需求也愿意付費，但企業總有很多個性化需求（與其他系統的集成、更加便捷的功能及UI、更加靈活的表單引擎、流程引擎、規則引擎等），當這種個性化需求強烈到一定程度，而SaaS平臺又無法提供充分的接口和后續開發服務時，企業總有一種沖動想要自建系統；
大企業通常內部都有一個龐大的信息化部門在進行各種系統的建設以及系統之間的集成，他們很難選擇外部基于通用邏輯設計的SaaS產品。
這就好比一根甘蔗，樹梢部分太嫩（小微企業），不能吃，根部太老，吃不動，只有中間一段是甜的，可以吃。暫且把這個現象稱之為“甘蔗理論”吧。
如果中間的部分有足夠的“汁”可以榨取，SaaS產品也可以支撐資本市場的投資邏輯。但如果產品過于通用，給用戶提供的價值厚度不夠，無法保證足夠的續費率，其用戶周期價值（LTV）低于其獲客成本（CAC），則SaaS產品的投資價值就會受到資本市場的質疑。
個人一直堅持認為，通用型的SaaS平臺如果不能成為PaaS級的生態平臺，無法成為一個靠“強產品強服務”甚至“強產品弱服務”而挺住的“木本植物”，又糾結于不想成為一個“項目式公司”的“草本植物”，則很容陷入尷尬的境地。尤其對于今天已經估值高達幾十億的通用型SaaS平臺來說，如果不能在垂直領域為用戶提供深度的價值，其高企的估值可能將自己悶死（只能靠傳統軟件巨頭接盤了）。
因此，SaaS產品應當圍繞垂直細分的領域進行深耕（可以參閱《九軒資本劉億舟：管理型SaaS應聚焦垂直領域做深做透》和《億舟微評：SaaS產品應該從垂直角度切入，價值深度要重要于價值寬度》），在具體的業務場景里面，才能將過程管控和數據賦能的價值落到實處，指望給客戶一個Excel表格，而指望客戶具有高超的VBA（Visual Basic for Applications）技能不太現實。
傳統的信息化項目一般都要經歷一個業務流程梳理和管理需求提煉的過程，后續的代碼開發只是以一種技術邏輯去實現咨詢階段所梳理的業務邏輯和管理邏輯。而SaaS產品通常都是基于行業的“最大公約數”而設定了一些表單模板。
而事實上，不同的企業其管理需求是完全不同的。對于一個要攜帶數據的過程控制表單來說，該設置哪些字段，這些字段應該設置成什么類型，如果是選擇題，應該設置哪些選項，顆粒度應該如何把控，設定好之后，如何將判據規則落實到具體的操作層，如何保證操作過程中的執行力，哪些字段應該被設定為必填字段等等，這些問題都是決定了SaaS軟件跑下來的最終效果，而這些最終效果又決定了用戶持續使用該軟件的意愿和動力。
在現實中，很多軟件沒有跑起來，領導問起來，原因大部分都是“軟件太爛了，不夠智能，不好用！”，而缺乏信息化經驗的領導又無法武斷地強奸團隊的想法，怎么辦呢？最后不了了之。
事實上，對于很多信息化場景來說，半自動化半手工化的解決方案其實比所謂的全自動化的系統更好（事實上很多操作是需要人機交互，因而是無法全自動化的），但是很多人無法深入理解這一點。帶著技術性思維的產品經理也會不由自主地迎合這種想法，而試圖去做一個完全智能化、自動化的產品（這種努力是非常值得贊賞的），但往往要么無法做出來，要么就必須犧牲一些非自動化可以采集信息的字段，從而使系統跑一遍出來，獲取的數據點確實相當有限的。
要設計一個合理的數據表單驅動一個完整的業務過程，并且滿足管理者在后期的數據分析的需求，其表單設計必須遵循以下原則：
能做選擇題就不要做填空題，能做填空題就盡量不要做論述題，實在萬不得已要做論述題，也應當給出一個模板。
而事實上，我們在設計字段時往往面臨兩難選擇，迎合用戶的易用性要求，就必須要犧牲填空題和論述題字段（需要敲字的），而這樣一來，站在管理者角度就不得不犧牲一些信息訴求。而在做選擇題時，應該設置為單選題還是多選題同樣需要根據具體的場景和管理需求進行精細化的考慮。另外就是，哪些字段應該設置為必填項（帶星號的），哪些可以設置為可填項，在不同的團隊其接受力也是不同的。
對于選擇題來說，如何設置具體的選項也是很有講究的，通常來說，有以下幾個原則可供參考：
1、標準化原則（盡可能做選擇題）；
2、從管理需求出發原則（每一個字段都可以回溯到某一個管理需求）；
3、顆粒度適中原則；
4、完備性原則（覆蓋所有的可能）；
5、互斥性原則（不能同時有兩個可選項，多選除外）；
6、可執行原則（每一個選項應該有明確的歸類標準）。
舉個例子來說明以上這兩段。比如在某個工單管理場景下，我想知道上個月一個叫小張的小伙子在給30歲以下的穿紅色衣服的女孩子做的工單中，有多少是超時完成多少是按時完成的。假設要實現這個管理需求，那么在工單管理的表單設計中，必須包含執行人、被服務對象的性別、衣服的顏色、年齡、漂亮與否、計劃完成時間、實際完成時間等字段，否則“此情可待成追憶，只是當時已枉然”，也就是說如果表單設計沒有預埋這些字段，事后來看，原本一秒鐘可以搞定的數據統計工作，給你2個小時你也未必能搞定。
以上這些細節的問題，恰恰是SaaS軟件在實現基本的過程管控價值之外，能否實現徹底的數據賦能的關鍵所在。而大部分的SaaS（尤其是通用型SaaS）完全無法掌控這些情況。
此外，流程引擎和規則引擎無法支持針對定制化的字段進行靈活的處理，也是企業在后期應用中碰到的頭疼的問題。
所以，SaaS產品要幫助客戶成功，必須要針對垂直場景深度挖掘客戶的需求，并且為客戶實施咨詢賦能，才有可能產生持續的價值。
相反，大部分的SaaS產品雖然基于行業最大公約數進行設計，也能夠為用戶產生一定的價值，但是如果用戶自身不是一個合格的“超級用戶”（大部分的用戶都不是，也缺乏足夠的重視，也可能沒有配備專門的信息化專員），則很難讓越過用戶的替代性拐點，很難持續付費也就不奇怪了。
按照應用場景，企業中使用的軟件通常可以分為三類：技術工具類軟件、業務軟件、管理軟件。一般來說，技術工具類軟件和業務軟件不存在執行力的問題，前者如果作為效率工具通常工程師都愿意接受使用，如監控軟件等；后者跑的是企業的核心業務流程，員工繞不過去。而管理軟件在企業里面的執行力最容易遭受考驗。
管理軟件有幾個基本特點：
1、不是強剛需，用也可以，不用似乎也沒什么大問題；
2、需要員工充分配合，越用越有用，越不用越沒用；
3、一旦某個或者某些環節不用，會導致整個體系的垮塌；
4、短期和局部來看是犧牲效率的；
5、有時候，領導容易帶頭破壞流程。
對于很多SaaS產品來說，如果切的不是企業的核心業務流程，很容易遭受執行力不強的問題。所以，就其最終效果而言，40%取決于產品本身（無論自認為做得多完美），40%取決于企業的老板，只有20%取決于操作層的員工。
為什么這么說呢？前面已經分析到，一套軟件要在企業中真正落地，除了前期需要一個完善的產品選型、初始化設計（業務流程梳理、數據字典設計、角色設計等）、員工宣貫培訓外，更離不開后期的監督和持續改進，如果企業的老板不能認識到這一點，很容易半路上“投降”而屈服于員工的阻力，很容易導致應用推廣過程流產。因此，有信息化經驗的領導深諳這一點，在確保執行力上都是強迫癥！
所以，一個軟件產品在企業要真正落地成功，其最大的挑戰來自于流程文化的缺失。什么是流程？
流程就是不惜犧牲個人效率，保證團隊的效率；
不惜犧牲當前的效率，保證長遠的效率；不惜犧牲局部的靈活性，保證整體的統一性；
不惜犧牲效率保證風險控制的要求。
但是很多人沒有這個意識（包括領導者本人），所有人都不停的加塞、闖紅燈，結果所有人都很堵。在中國，這種企業的流程和規則意識是很薄弱的，甚至好多流程是老板帶頭打破的。但領導們從來不認為是他的管理有問題，他們認為是你的軟件的問題。這件事的評判權在你，但繼續付費與否的決策權在領導。
所以，SaaS軟件尤其是管理軟件類的SaaS產品，不能簡單帶著賣產品的思路去推。你想省事，你想輕，你想采用鴕鳥策略，讓客戶自行掙扎，其最終的結果是你輕不了，還是得跳下去幫助客戶成功，因為你要追求續費率。
對于很多企業來說，管理軟件其實是個軟剛需，即便你站在一個咨詢專家的角度認為對企業很重要，企業可能還是后知后覺地堅持自己的觀點。因為管理軟件的價值很多時候取決于使用的過程本身，因而價值并不顯性。因此，選擇切入角度很重要的。
通常來說，如果能選擇產品（如原料供應鏈）或者服務（如代繳社保或代發工資）切入，并且這種產品和服務是企業歡迎的，那么應優先建立產品或服務的供應鏈往來，先“賣灌裝煤氣”，先為客戶提供供應鏈本身的價值，然后再逐步把SaaS“管道”延伸過去。其實，如果是先以服務或者產品切入，其邏輯已經不是SaaS的邏輯了，而是產品或服務供應鏈的邏輯。
很多SaaS項目有個誤區，以為先把SaaS產品延伸過去就可以進一步轉到供應鏈服務。其實不然，應該反過來，先賣罐裝煤氣，再賣管道煤氣。也就是說，總體上來講，通過服務或者產品的價值切進去，會比軟件賦能（過程管控）更容易切入，另外，通過數據賦能去切入又相對會比單純的過程管控更容易切入。
當然，對于沒有其他產品或者服務切入的單純SaaS產品來說，就只能踏踏實實地為客戶提供過程管控的價值，如果用戶普遍為這種軟件價值買單并續費，本身就說明SaaS產品對于客戶是有持續的價值的。
有些SaaS產品在互聯網思維的影響下，采用免費策略將SaaS產品給商家使用，然后試圖通過B端的使用帶動C端的用戶流量，最終希望能夠成為該垂直領域的O2O服務平臺，個人認為這種思路要謹慎。
SaaS其實相當于是個“胖客戶端”，通過SaaS軟件對線下商家或者服務商的業務流程的滲入，實現了線下資源的線上化，成為一個整合的資源網絡，相當于打造了線下服務的接口平臺，站在互聯網的角度來看，相當于建立了一個SSP（供給方平臺），而傳統的互聯網流量巨頭則相當充當了DSP（需求方平臺）。SaaS要逆襲成為DSP而作為互聯網入口挺難的，這個結論很殘酷但也很現實。
但在有些重服務的領域，如果SaaS服務商不僅僅給線下商家輸出軟件賦能，同時還輸出品牌紅利和管理紅利，并且在初期通過整合其他互聯網巨頭的流量給線下商家或者服務商進行流量賦能，同時，在有些重資金的領域為線下商家提供供應鏈金融賦能（如房產中介領域的SaaS服務商好房通），理論上，SaaS服務商有可能通過品牌強化成為垂直服務平臺。待品牌效應形成之后，可以觸發平臺的流量機制，進而為線下商家提供流量賦能。
而對于很多標準化程度很高的輕服務領域，SaaS的植入要成為獨立的自流量平臺，有相當的難度。但這并不意味著這種場景下的SaaS沒有價值。在這種情況下，建議SaaS產品更加聚焦于為客戶提供業務價值，做深做透，牢牢抓住用戶，就一定具有價值（起碼可以被巨頭并購），否則，有可能兩頭空。
對于很多價值黏性不夠的SaaS產品來說，BD能力越強越容易掩蓋產品本身的價值不足的事實。如果產品團隊不能盡早地發現這一點，很有可能導致過分燒錢跑馬圈地換來的用戶數據無法支撐后續的融資和估值，畢竟2B的領域跟2C的領域邏輯完全不同。在強大的BD攻勢面前，很多用戶會嘗試著使用SaaS產品，但如果客觀上需求暫時不成立或者需求雖然成立但是產品無法為用戶提供足夠的價值，最終活躍用戶數據也會很難看。用2C的思維去做2B的SaaS產品會是一場災難。
