編輯導語：SaaS平台是一個比較複雜的系統，基於垂直領域SaaS平台特點，所需要的功能特點也不同。文章從藥店SaaS平台出發，在基於基礎功能模塊的前提下，闡述垂直SaaS平台的設計流程，與大家分享。
阿強已經開始創業了（創業個毛線哦！就是他老爸給錢去鍛鍊了。我tm還在普通副本刷怪升級中……），他決定做一個SaaS平台，提供給他老爸的萬家藥店使用。作為阿強少爺的忠誠好友，給他老爸打工的我，“應該”為阿強獻上我寶貴的意見……
一、客户的痛點思考B端客户的痛點思考，從來都是以其實體業務經營的場景為基礎進行思維發散的。
因為我們需要以“藥店整體解決方案”的理念入場，所以藥店的數據一體化顯得非常重要。如果因為我們的入場，客户的系統數據還是四分五裂的，那麼我們的存在就顯得那麼的無意義了。
- 因為是藥店客户，所以，我們首先需要解決藥店基礎系統——藥店進銷存的問題，其次是藥店銷售處方藥的問題，引入互聯網醫院提供的電子處方單。
- 線下服務，連接性總是弱的，互聯網的手段必須用起來，微信公眾號、小程序就是首選，那麼藥店的在線商城和線上優惠券之類的在這裏就是必須的了（這裏不扯合法合規性的問題。
- 服務要講究粘性，講究千人千面，會員系統也就是必須的了。
- 作為藥房本身的職能，可以考慮與社區醫院合作，作為其指定的藥房使用，也好契合着國家醫藥分家的號召。
- 最迫切的，解決藥店藥品供應鏈的訴求，降低藥店採購成本，滿足用户用藥的普及性。當然，除了通過供應鏈解決藥品多樣性的問題，為藥店引入醫藥電商平台也是一種可行的解決方案。
放圖：
當然，系統的輸入永遠都只是工具，真正的運營，還是需要團隊去執行的。是藥店的團隊，或者是平台建立運營團隊服務，那就是強少爺的事情了。我不建議了。
臨陣退縮做為一名專業的產品經理，我敢保證，上面的系統我都能做，我也敢做。但我絕不保證產品的質量和產品上線的時間。
B端的項目也好，C端的項目也好，都是需要迎合市場的。快速試錯，快速調整，才是互聯網產品迭代的規律。
很明顯，上面的系統，市場上都有，並且還是經過多年的市場錘鍊迭代到今天的。專業性不敢説都是100%完美，但肯定是要比半路出家的要強咯。再説，這裏涉及到的隨便一個產品板塊，基本上都是可以養活一家百人級別技術公司的，讓我們來搞，能不能搞好先不説，前期人力成本就得嘩啦啦的燒一大筆錢。總之這個玩意就是：
- 工程量大，週期長。
- 投入大，組建團隊難。
- 市場未經過驗證，做完了，別人買不買單尚是未知數。
問題總是比辦法多的。不要害怕，搞就行了。我們始終要明確一個目標：保證業務開展，試錯要快！
業務起步，每個業務系統都要自己搞，那是不可能的了。人家有的，我就直接借用吧，反正他們的產品都已經那麼成熟，不用白不用：
- 對於進銷存、電商商城、營銷系統（和商城一起的）、在線直播等系統，直接找廠家合作，要求用户數據回傳至我自研的平台。
- 對於第三方系統無法提供的，或者提供不合適的系統，安排自研，平台輸出給藥店使用，如會員系統（多個系統的用户集合到我平台，他們的數據分別獨立，即時提供會員功能，也是不好使）等。
- 開放平台，允許第三方能力輸入，如互聯網醫院、藥品供應鏈等。
因此，我們相當於做了一個數據交互的樞紐平台。後續數據沉澱後，便可做精準化的用户服務。至於第三方系統接觸哪些廠商，可以找市面最火的吧！那是阿強少爺的事情了。
業務先跑吧！如果後續客户用的爽了，第三方系統卻不想和我平台合作的話，到時候可以讓阿強考慮收購，或者來一次自研！有市場，怕啥投入哇！
回到主題SaaS尋求第三方合作廠商，為藥店提供應用系統，有個前置的條件——對方的系統也必須是SaaS，單機版本的系統自然是不能滿足我平台建設的要求。當然，我平台的設計基礎核心，也必須是SaaS。
三、SaaS的核心SaaS平台的核心板塊，就是商户體系。
以B2C模式的電商商城來舉例，你做產品設計時，這裏的B就是你所在的企業，所以你在做產品功能設計時，只會根據你們企業內部的需求進行定製化。但是SaaS不行，SaaS多了一層平台的概念，變成了S2B2C，在這個模式裏，你所充當的角色是平台S，而這裏的B，就是你之前的公司，所以在這裏，你需要設計的是滿足無數個B的需求，而不是像以前一樣，只想着一個B是不行的了。
關於商户體系的建設，我們需要從市場的商户表現形式進行思考。市場主要表現形式為：單店型，連鎖型。而連鎖型裏面又包括直營店、加盟店、代管店。單店模式是最簡單的，麻煩在連鎖模式，因為直營店、加盟店、代管店，他們與總部的關係是不一樣的，特別是在分錢這個環節上。
- 所有合作的企業，不管是連鎖型，還是單店型，對於平台來説，只是屬於我平台的一個商户，平台允許其創建門店。也不在乎其創建多少家店，反正應用系統，直接與門店關聯。
- 設置總店與分店，進行數據範圍的控制，總部可管理所有分店的數據。
因此，平台開始設計後，幾乎所有數據，都是需要關聯到具體門店的。如訂單的數據存儲，數據表的設計如下：
四、SaaS的權限控制商户體系建立後，通過系統的賬號、角色、權限來實現不同人員的操作權限，是SaaS平台的又一靈魂之處。
關於後台系統的賬號、角色、權限，下面會簡介的比較詳細一些，如果沒有什麼興趣的話，可以直接跳過當前章節。
1. 絕對標準化的系統角色權限設計縱觀大大小小的後台系統，關於系統的賬號、角色、權限的產品設計，絕大多數後台創建賬號的操作流程為：
- 開發預設好系統的功能、操作權限；
- 添加角色，角色關聯功能，功能可以再細分到操作權限，如增刪改查等（很多系統喜歡偷懶，權限只控制到功能一層，無操作權限的控制）；
- 添加賬號；
- 選擇賬號角色（也可以在創建賬號的時候就關聯角色）；
我總覺得賬號關聯角色，角色關聯權限的設定，會使得系統在對賬號進行靈活化的權限配置時，顯示蒼白無力。打個比方：設定一個角色為客服，客服關聯了客服相關的操作權限，員工ABC均關聯該客服角色，由於場景特殊化，需要給員工D添加多一個客服角色外的另外一個操作或者功能，就需要在系統中再單獨創建一個客服2的角色，才可以實現此需求：
因為客服1和客服2的角色，關聯的操作權限大部分是一樣的，僅僅只有一個操作權限的差異而已，所以我想，使用賬號直接關聯權限，角色僅僅只是作為一個角色包快速選擇的功能項：
在創建賬號時，還是一樣選擇角色，角色關聯權限包，選擇角色後，加載當前角色所擁有的操作權限，允許進行二次修改（即添加多幾個權限或減少幾個權限）。
這樣的話，針對上面的客服ABCD，我只需要添加一個客服的角色即可，在創建特殊化場景的客户賬號時，給他選擇了客服的角色，然後再進行多一個審批操作的添加或者是其他權限的添加即可。實現賬號權限的絕對靈活化的配置。
但是，產品設計的理念告訴我，比如靈活配置的問題，不是最靈活才是最好的設計的，需要講究最恰當的靈活，才是合理的。
所以，賬號關聯操作權限的理念在系統是行不通的。至於行不通的真實原因，可以自行思考下。對比下兩種方式下創建賬號，在系統生成的數據量，就大概知道原因了。
3. 數據權限的理解上面講到的僅僅只是功能的權限而已。對於系統權限來説，是會區分功能權限和數據權限的。但是很多情況下，在添加賬號的時候，數據權限是沒有辦法顯性的表達出來的，它是需要在某些特定的功能下，才會需要用到的。但是在SaaS平台中，數據的權限，處處都是明擺出來的。
首先，我們來理解沒有做數據權限控制的功能，這個意味着，只要你給該賬號添加該功能權限，所有的用户，進入該功能，看到的界面的數據都是一樣的。自然這個是有違SaaS的規定的。你中不能讓B商户的用户看到A商户的數據吧！那不是扯着嗎？
那麼SaaS關於數據權限的控制第一步，把上面訂單的結構拷貝下來：
所有的業務功能，只要是提供給到商户或者門店去使用的，均需要根據商户或者門店進行第一層過濾。保證門店或者商户，只能看到自己範圍內的數據。大哥，數據隱私性安全性，很重要的，可別亂搞……
第二步，個別功能，數據範圍按角色進行定製化。如客服查看“我跟進的訂單”，那麼數據需要按賬號進行過濾。或訂單數據查看範圍，需要按照區域進行劃分，這就需要對賬號進行定製化的區域範圍關聯了，要比較複雜，除非是賬號本身也有關聯區域，可進行數據匹配進行數據篩選。當前步驟比較特殊，需要根據特性場景定製化。
大多數的系統不願意做數據權限控制，寧願複製多一個一模一樣的功能點，在查詢數據的時候，加多個篩選條件，這樣會比較好辦些。比如説，訂單管理和我的訂單，其實界面來看，操作來看，其實是一模一樣的，但是我的訂單，是隻篩選當前用户關聯的訂單信息。這樣做雖然簡單，但是功能會比較累贅些，且兩個基本一模一樣的功能界面點，後期有一個界面優化迭代，另外一個界面也需要同步進行維護迭代，真心挺麻煩的。
所以，關於數據權限的選擇，真是各花各眼，從系統功能規劃來講，我個人更加喜歡把功能點劃分的簡單些，所以你看到的訂單管理，就是你想看到的訂單管理，不是專門給你多做一個“我的訂單”的板塊，後續維護，老子是真的懶得跟你改這又改那的……
4. 賬號與商户的關係先提個問題：先有賬號才有商户，還是先有商户再有賬號？
SaaS平台的賬號，和單體系統的賬號管理，絕對是不一樣的。
單體系統不用問阿強都是知道的，肯定是現有系統，再有賬號的啦！單體系統的商户就是平台自己，固定的。這也造就了我們對於創建後台管理賬號的習慣性思維邏輯，禁錮了我們發的思想。
我告訴你哦，SaaS平台，賬號和商户沒有必然的先後關係：
模式1就是默化的設計思路，一般這種情況，在創建賬號的時候，會習慣讓填寫一個登錄賬號和登錄密碼的玩意！試問一句，現在登錄的操作，那是有手機號+驗證碼不能做的事情！！！另外就是，假設當前使用的是手機號作為賬號，這樣的設計，可能會漏考慮到同一個人，會關聯多個商户或多個門店的情況。
那麼模式2，在SaaS裏面，就能夠完美解決這個問題。如果有用過釘釘的，可以試想一下，用户賬號是通過手機號先註冊的，進入釘釘後，是允許選擇進入的企業的。這樣的思路同樣適用於後台，我把微店的登錄界面一截圖，就很明顯了：
這個頁面搞得有點花，在設計上來説，去掉這個頁面也是沒有毛病，直接在進入主界面，在頂部欄，做好切換店鋪或企業即可：
那麼，賬號和商户的設計理念，就是這樣的了，賬號登陸後，可以根據賬號關聯的商户或門店，展示出來，以供用户進行選擇，切換管理：
設計這個SaaS平台時，上面對於商户、門店的入口，我們上面基本已經考慮到了。但是如果作為平台本身的管理員，我們應該怎麼去設計其在系統的登錄呢？
很明顯，商户只能看到商户的數據，平台管理員，需要看到全部的數據，但是平台管理員不是萬能的，有些業務性的操作，平台是不能做的。比如説，商户的訂單審核、商户的客户對接，平台是不能亂搞的。這個時候，我們需要考慮下，這個平台的管理員角色，我們一定要讓他登陸到這個後台嗎？
從產品業務合理性的角度出發，建議拆一個運營後台出來，專門給到平台的管理員去使用。這個運營後台，就不需要加SaaS的概念進去了。因為登陸的用户，就是平台自身的員工而已。之後，根據平台管理所需要的業務功能，定製化設計開發即可。
但是，從開發成本和時間成本的角度來説，產品經理就需要對設計做深一步的取捨了。如果人力物力不夠的情況下，平台管理員和商户共用一套系統，是很有必要的。大不了，後期條件允許的情況下，再開始做運營後台咯。
6. SaaS的其他迭代至此，SaaS平台從0到1的基礎框架已經搞完了。至於其他業務板塊的功能迭代，追尋以上的設計原理，在所有的數據前面做好商户和門店的關聯，在功能展示上，定好功能、角色的數據可視可操作範圍就可以了。想象一下，發現，SaaS也就那麼回事……
當然，很多技術人員會和你講到平台的分佈式或微服務的概念，因為SaaS平台，本身在很多業務操作上，是存在很多共性的，所以需要將某些具備固定用途的板塊獨立化，比如支付、比如訂單等等，嗯吶，這個屬於中台的職能了，另外研究吧！
五、SaaS平台的門檻如今技術的發展，要實現一個SaaS平台從0到1的搭建過程，已經不是一件什麼難事了。所以在技術上，基本上是沒有什麼門檻的。但是在花錢上面，門檻比較大。
對於成本的預估，第一是平台從0到1的技術團隊的組建，現在開發人員是那麼的貴哦！想起當年在那個不堪回首的前公司，那個CTO一上來，就是分佈式，關於產品的東西還沒有見到雛形，就已經是100多人的技術團隊了，從項目經理、產品經理、後台、前端、測試、運維、架構師等等，樣樣具備……
那個錢，刷刷刷的燒啊！可怕的是，搞了1年多，還是沒有啥東西出來！第二就是服務器成本，系統大了，要用到的機器也是少不了咯。不曉得要多少，反正要花錢。第三塊是寬帶，現在短視頻和直播那麼火，這些按流量計費的玩意，怎麼收費，可以去阿里雲和騰訊雲LOOK下吧。
最重要的，就是推廣了。花了巨資後，終於把東西搞好了，但是如果沒有人愛用，或者已經被其他同類型的SaaS平台搶了先機，這麼折騰搞這個玩意，到頭來是為了個啥子哦！
六、SaaS平台的市場認可度以前都是單機化的軟件部署模式，誰要，誰買。獨立部署，獨立維護。現在一套SaaS雲端直接解決，一個註冊分配一個賬號，就完事了。商户不用東西折騰，又是搞服務器搞這搞那的。廠家也不用單個系統單個系統的維護，增加人手、增加成本，每個系統都定製化的改來改去，改到最後面都不曉得是自家開發的產品了。且原來獨立化部署的系統，購買成本也是極高，現在SaaS賬號，可以數千元就搞定了。對於這些來説，對於商户和廠家來説，SaaS真是福音啊！
但是，SaaS的市場羣體是有限的，且在一定的程度上，它是不能夠被市場所認可的。因為，SaaS裏面產生的數據，是在SaaS廠商的數據庫裏面的。商户前期雖然在系統的投入上節省了大量的錢財，但是，這些都是通過出賣自己的數據所換回來的！然而，對於長期經營的商户來講，數據，絕對是一大筆財富！
沒有關係，業務先行，可以先跑。不想重投入或者沒錢重投入的人，前期先這樣咯，不然阿強少爺做這個平台還有什麼意義啊！
七、我認為“阿強藥店SaaS服務平台”的未來雖然SaaS平台不應該被市場所認可，但是SaaS平台卻終究是一個行業趨勢，也終究要被很多人所接受。想象一下，當你以為山寨的年代已經過去了，拼多多的崛起還是讓山寨回到你的視野了。為什麼？不就是人太多，想法太多，各種各樣的人都有嗎？
有就好，所以給阿強少爺規劃的這個平台，還是有未來的。
SaaS平台，講究的是產品。產品好，解決了客户的痛點，而剛剛好又做好的客户的客情。生意就這樣開始了。
但是要端正一個態度，當前做的這個SaaS平台，絕對不要給自己囚禁在產品服務的範疇了。對於平台來説，後期的增值性服務尤其重要。如數據分析、大數據輔助決策、用户標籤千人千面、精準推送等等。這些都是讓平台升值的關鍵性因素哇！
另外就是藥店本身屬於一個醫療健康類型的特殊性行業，平台還可以利用這點在行業裏面做一個橫向的擴展，逐步打造成大健康的醫養平台。
八、最後最近在研究微店的SaaS商城，因此想到了這個SaaS的主題。之前在釘釘上購買過一個叫“氚雲”的服務，它也是一個SaaS的系統，同時還加上了PaaS(平台即服務)的理念。作為產品經理的我們，看到這些英文縮寫的時候，並沒有因此會角色它是高大上，因為從產品設計的理念出發，我們只是站在客户的角度去思考客户的痛點而已，然後通過我們專業的能力，剛剛好設計解決了他們的需求。
阿強少爺這個系統還在做，我主動申請親自掛帥了。但是阿強他爸覺得自己來搞太慢了，強迫性要求去找外包團隊實現它。我想，就這樣吧，拜拜，不見。
最後，覺得文章還可以的老鐵，點個贊，一定要點贊哦！
本文由 @產品經理龍汪汪 原創發佈於人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議