中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

編輯導(dǎo)語：SaaS平臺是一個比較復(fù)雜的系統(tǒng)，基于垂直領(lǐng)域SaaS平臺特點，所需要的功能特點也不同。文章從藥店SaaS平臺出發(fā)，在基于基礎(chǔ)功能模塊的前提下，闡述垂直SaaS平臺的設(shè)計流程，與大家分享。

阿強已經(jīng)開始創(chuàng)業(yè)了（創(chuàng)業(yè)個毛線哦！就是他老爸給錢去鍛煉了。我tm還在普通副本刷怪升級中……），他決定做一個SaaS平臺，提供給他老爸的萬家藥店使用。作為阿強少爺?shù)闹艺\好友，給他老爸打工的我，“應(yīng)該”為阿強獻(xiàn)上我寶貴的意見……

一、客戶的痛點思考

B端客戶的痛點思考，從來都是以其實體業(yè)務(wù)經(jīng)營的場景為基礎(chǔ)進行思維發(fā)散的。

因為我們需要以“藥店整體解決方案”的理念入場，所以藥店的數(shù)據(jù)一體化顯得非常重要。如果因為我們的入場，客戶的系統(tǒng)數(shù)據(jù)還是四分五裂的，那么我們的存在就顯得那么的無意義了。

1. 因為是藥店客戶，所以，我們首先需要解決藥店基礎(chǔ)系統(tǒng)——藥店進銷存的問題，其次是藥店銷售處方藥的問題，引入互聯(lián)網(wǎng)醫(yī)院提供的電子處方單。
2. 線下服務(wù)，連接性總是弱的，互聯(lián)網(wǎng)的手段必須用起來，微信公眾號、小程序就是首選，那么藥店的在線商城和線上優(yōu)惠券之類的在這里就是必須的了（這里不扯合法合規(guī)性的問題。
3. 服務(wù)要講究粘性，講究千人千面，會員系統(tǒng)也就是必須的了。
4. 作為藥房本身的職能，可以考慮與社區(qū)醫(yī)院合作，作為其指定的藥房使用，也好契合著國家醫(yī)藥分家的號召。
5. 最迫切的，解決藥店藥品供應(yīng)鏈的訴求，降低藥店采購成本，滿足用戶用藥的普及性。當(dāng)然，除了通過供應(yīng)鏈解決藥品多樣性的問題，為藥店引入醫(yī)藥電商平臺也是一種可行的解決方案。

放圖：

當(dāng)然，系統(tǒng)的輸入永遠(yuǎn)都只是工具，真正的運營，還是需要團隊去執(zhí)行的。是藥店的團隊，或者是平臺建立運營團隊服務(wù)，那就是強少爺?shù)氖虑榱?。我不建議了。

臨陣退縮

做為一名專業(yè)的產(chǎn)品經(jīng)理，我敢保證，上面的系統(tǒng)我都能做，我也敢做。但我絕不保證產(chǎn)品的質(zhì)量和產(chǎn)品上線的時間。

B端的項目也好，C端的項目也好，都是需要迎合市場的。快速試錯，快速調(diào)整，才是互聯(lián)網(wǎng)產(chǎn)品迭代的規(guī)律。

很明顯，上面的系統(tǒng)，市場上都有，并且還是經(jīng)過多年的市場錘煉迭代到今天的。專業(yè)性不敢說都是100%完美，但肯定是要比半路出家的要強咯。再說，這里涉及到的隨便一個產(chǎn)品板塊，基本上都是可以養(yǎng)活一家百人級別技術(shù)公司的，讓我們來搞，能不能搞好先不說，前期人力成本就得嘩啦啦的燒一大筆錢。總之這個玩意就是：

1. 工程量大，周期長。
2. 投入大，組建團隊難。
3. 市場未經(jīng)過驗證，做完了，別人買不買單尚是未知數(shù)。

二、專業(yè)的產(chǎn)品解決方案

問題總是比辦法多的。不要害怕，搞就行了。我們始終要明確一個目標(biāo)：保證業(yè)務(wù)開展，試錯要快！

業(yè)務(wù)起步，每個業(yè)務(wù)系統(tǒng)都要自己搞，那是不可能的了。人家有的，我就直接借用吧，反正他們的產(chǎn)品都已經(jīng)那么成熟，不用白不用：

1. 對于進銷存、電商商城、營銷系統(tǒng)（和商城一起的）、在線直播等系統(tǒng)，直接找廠家合作，要求用戶數(shù)據(jù)回傳至我自研的平臺。
2. 對于第三方系統(tǒng)無法提供的，或者提供不合適的系統(tǒng)，安排自研，平臺輸出給藥店使用，如會員系統(tǒng)（多個系統(tǒng)的用戶集合到我平臺，他們的數(shù)據(jù)分別獨立，即時提供會員功能，也是不好使）等。
3. 開放平臺，允許第三方能力輸入，如互聯(lián)網(wǎng)醫(yī)院、藥品供應(yīng)鏈等。

因此，我們相當(dāng)于做了一個數(shù)據(jù)交互的樞紐平臺。后續(xù)數(shù)據(jù)沉淀后，便可做精準(zhǔn)化的用戶服務(wù)。至于第三方系統(tǒng)接觸哪些廠商，可以找市面最火的吧！那是阿強少爺?shù)氖虑榱恕?/p>

業(yè)務(wù)先跑吧！如果后續(xù)客戶用的爽了，第三方系統(tǒng)卻不想和我平臺合作的話，到時候可以讓阿強考慮收購，或者來一次自研！有市場，怕啥投入哇！

回到主題SaaS

尋求第三方合作廠商，為藥店提供應(yīng)用系統(tǒng)，有個前置的條件——對方的系統(tǒng)也必須是SaaS，單機版本的系統(tǒng)自然是不能滿足我平臺建設(shè)的要求。當(dāng)然，我平臺的設(shè)計基礎(chǔ)核心，也必須是SaaS。

三、SaaS的核心

SaaS平臺的核心板塊，就是商戶體系。

以B2C模式的電商商城來舉例，你做產(chǎn)品設(shè)計時，這里的B就是你所在的企業(yè)，所以你在做產(chǎn)品功能設(shè)計時，只會根據(jù)你們企業(yè)內(nèi)部的需求進行定制化。但是SaaS不行，SaaS多了一層平臺的概念，變成了S2B2C，在這個模式里，你所充當(dāng)?shù)慕巧瞧脚_S，而這里的B，就是你之前的公司，所以在這里，你需要設(shè)計的是滿足無數(shù)個B的需求，而不是像以前一樣，只想著一個B是不行的了。

關(guān)于商戶體系的建設(shè)，我們需要從市場的商戶表現(xiàn)形式進行思考。市場主要表現(xiàn)形式為：單店型，連鎖型。而連鎖型里面又包括直營店、加盟店、代管店。單店模式是最簡單的，麻煩在連鎖模式，因為直營店、加盟店、代管店，他們與總部的關(guān)系是不一樣的，特別是在分錢這個環(huán)節(jié)上。

1. 所有合作的企業(yè)，不管是連鎖型，還是單店型，對于平臺來說，只是屬于我平臺的一個商戶，平臺允許其創(chuàng)建門店。也不在乎其創(chuàng)建多少家店，反正應(yīng)用系統(tǒng)，直接與門店關(guān)聯(lián)。
2. 設(shè)置總店與分店，進行數(shù)據(jù)范圍的控制，總部可管理所有分店的數(shù)據(jù)。

因此，平臺開始設(shè)計后，幾乎所有數(shù)據(jù)，都是需要關(guān)聯(lián)到具體門店的。如訂單的數(shù)據(jù)存儲，數(shù)據(jù)表的設(shè)計如下：

四、SaaS的權(quán)限控制

商戶體系建立后，通過系統(tǒng)的賬號、角色、權(quán)限來實現(xiàn)不同人員的操作權(quán)限，是SaaS平臺的又一靈魂之處。

關(guān)于后臺系統(tǒng)的賬號、角色、權(quán)限，下面會簡介的比較詳細(xì)一些，如果沒有什么興趣的話，可以直接跳過當(dāng)前章節(jié)。

1. 絕對標(biāo)準(zhǔn)化的系統(tǒng)角色權(quán)限設(shè)計

縱觀大大小小的后臺系統(tǒng)，關(guān)于系統(tǒng)的賬號、角色、權(quán)限的產(chǎn)品設(shè)計，絕大多數(shù)后臺創(chuàng)建賬號的操作流程為：

1. 開發(fā)預(yù)設(shè)好系統(tǒng)的功能、操作權(quán)限；
2. 添加角色，角色關(guān)聯(lián)功能，功能可以再細(xì)分到操作權(quán)限，如增刪改查等（很多系統(tǒng)喜歡偷懶，權(quán)限只控制到功能一層，無操作權(quán)限的控制）；
3. 添加賬號；
4. 選擇賬號角色（也可以在創(chuàng)建賬號的時候就關(guān)聯(lián)角色）；

2. 賬號直接關(guān)聯(lián)權(quán)限與角色直接關(guān)聯(lián)權(quán)限的取舍

我總覺得賬號關(guān)聯(lián)角色，角色關(guān)聯(lián)權(quán)限的設(shè)定，會使得系統(tǒng)在對賬號進行靈活化的權(quán)限配置時，顯示蒼白無力。打個比方：設(shè)定一個角色為客服，客服關(guān)聯(lián)了客服相關(guān)的操作權(quán)限，員工ABC均關(guān)聯(lián)該客服角色，由于場景特殊化，需要給員工D添加多一個客服角色外的另外一個操作或者功能，就需要在系統(tǒng)中再單獨創(chuàng)建一個客服2的角色，才可以實現(xiàn)此需求：

因為客服1和客服2的角色，關(guān)聯(lián)的操作權(quán)限大部分是一樣的，僅僅只有一個操作權(quán)限的差異而已，所以我想，使用賬號直接關(guān)聯(lián)權(quán)限，角色僅僅只是作為一個角色包快速選擇的功能項：

在創(chuàng)建賬號時，還是一樣選擇角色，角色關(guān)聯(lián)權(quán)限包，選擇角色后，加載當(dāng)前角色所擁有的操作權(quán)限，允許進行二次修改（即添加多幾個權(quán)限或減少幾個權(quán)限）。

這樣的話，針對上面的客服ABCD，我只需要添加一個客服的角色即可，在創(chuàng)建特殊化場景的客戶賬號時，給他選擇了客服的角色，然后再進行多一個審批操作的添加或者是其他權(quán)限的添加即可。實現(xiàn)賬號權(quán)限的絕對靈活化的配置。

但是，產(chǎn)品設(shè)計的理念告訴我，比如靈活配置的問題，不是最靈活才是最好的設(shè)計的，需要講究最恰當(dāng)?shù)撵`活，才是合理的。

所以，賬號關(guān)聯(lián)操作權(quán)限的理念在系統(tǒng)是行不通的。至于行不通的真實原因，可以自行思考下。對比下兩種方式下創(chuàng)建賬號，在系統(tǒng)生成的數(shù)據(jù)量，就大概知道原因了。

3. 數(shù)據(jù)權(quán)限的理解

上面講到的僅僅只是功能的權(quán)限而已。對于系統(tǒng)權(quán)限來說，是會區(qū)分功能權(quán)限和數(shù)據(jù)權(quán)限的。但是很多情況下，在添加賬號的時候，數(shù)據(jù)權(quán)限是沒有辦法顯性的表達(dá)出來的，它是需要在某些特定的功能下，才會需要用到的。但是在SaaS平臺中，數(shù)據(jù)的權(quán)限，處處都是明擺出來的。

首先，我們來理解沒有做數(shù)據(jù)權(quán)限控制的功能，這個意味著，只要你給該賬號添加該功能權(quán)限，所有的用戶，進入該功能，看到的界面的數(shù)據(jù)都是一樣的。自然這個是有違SaaS的規(guī)定的。你中不能讓B商戶的用戶看到A商戶的數(shù)據(jù)吧！那不是扯著嗎？

那么SaaS關(guān)于數(shù)據(jù)權(quán)限的控制第一步，把上面訂單的結(jié)構(gòu)拷貝下來：

所有的業(yè)務(wù)功能，只要是提供給到商戶或者門店去使用的，均需要根據(jù)商戶或者門店進行第一層過濾。保證門店或者商戶，只能看到自己范圍內(nèi)的數(shù)據(jù)。大哥，數(shù)據(jù)隱私性安全性，很重要的，可別亂搞……

第二步，個別功能，數(shù)據(jù)范圍按角色進行定制化。如客服查看“我跟進的訂單”，那么數(shù)據(jù)需要按賬號進行過濾。或訂單數(shù)據(jù)查看范圍，需要按照區(qū)域進行劃分，這就需要對賬號進行定制化的區(qū)域范圍關(guān)聯(lián)了，要比較復(fù)雜，除非是賬號本身也有關(guān)聯(lián)區(qū)域，可進行數(shù)據(jù)匹配進行數(shù)據(jù)篩選。當(dāng)前步驟比較特殊，需要根據(jù)特性場景定制化。

大多數(shù)的系統(tǒng)不愿意做數(shù)據(jù)權(quán)限控制，寧愿復(fù)制多一個一模一樣的功能點，在查詢數(shù)據(jù)的時候，加多個篩選條件，這樣會比較好辦些。比如說，訂單管理和我的訂單，其實界面來看，操作來看，其實是一模一樣的，但是我的訂單，是只篩選當(dāng)前用戶關(guān)聯(lián)的訂單信息。這樣做雖然簡單，但是功能會比較累贅些，且兩個基本一模一樣的功能界面點，后期有一個界面優(yōu)化迭代，另外一個界面也需要同步進行維護迭代，真心挺麻煩的。

所以，關(guān)于數(shù)據(jù)權(quán)限的選擇，真是各花各眼，從系統(tǒng)功能規(guī)劃來講，我個人更加喜歡把功能點劃分的簡單些，所以你看到的訂單管理，就是你想看到的訂單管理，不是專門給你多做一個“我的訂單”的板塊，后續(xù)維護，老子是真的懶得跟你改這又改那的……

4. 賬號與商戶的關(guān)系

先提個問題：先有賬號才有商戶，還是先有商戶再有賬號？

SaaS平臺的賬號，和單體系統(tǒng)的賬號管理，絕對是不一樣的。

單體系統(tǒng)不用問阿強都是知道的，肯定是現(xiàn)有系統(tǒng)，再有賬號的啦！單體系統(tǒng)的商戶就是平臺自己，固定的。這也造就了我們對于創(chuàng)建后臺管理賬號的習(xí)慣性思維邏輯，禁錮了我們發(fā)的思想。

我告訴你哦，SaaS平臺，賬號和商戶沒有必然的先后關(guān)系：

模式1就是默化的設(shè)計思路，一般這種情況，在創(chuàng)建賬號的時候，會習(xí)慣讓填寫一個登錄賬號和登錄密碼的玩意！試問一句，現(xiàn)在登錄的操作，那是有手機號+驗證碼不能做的事情?。?！另外就是，假設(shè)當(dāng)前使用的是手機號作為賬號，這樣的設(shè)計，可能會漏考慮到同一個人，會關(guān)聯(lián)多個商戶或多個門店的情況。

那么模式2，在SaaS里面，就能夠完美解決這個問題。如果有用過釘釘?shù)?，可以試想一下，用戶賬號是通過手機號先注冊的，進入釘釘后，是允許選擇進入的企業(yè)的。這樣的思路同樣適用于后臺，我把微店的登錄界面一截圖，就很明顯了：

這個頁面搞得有點花，在設(shè)計上來說，去掉這個頁面也是沒有毛病，直接在進入主界面，在頂部欄，做好切換店鋪或企業(yè)即可：

那么，賬號和商戶的設(shè)計理念，就是這樣的了，賬號登陸后，可以根據(jù)賬號關(guān)聯(lián)的商戶或門店，展示出來，以供用戶進行選擇，切換管理：

5. SaaS系統(tǒng)中，平臺管理員與商戶管理員的區(qū)分

設(shè)計這個SaaS平臺時，上面對于商戶、門店的入口，我們上面基本已經(jīng)考慮到了。但是如果作為平臺本身的管理員，我們應(yīng)該怎么去設(shè)計其在系統(tǒng)的登錄呢？

很明顯，商戶只能看到商戶的數(shù)據(jù)，平臺管理員，需要看到全部的數(shù)據(jù)，但是平臺管理員不是萬能的，有些業(yè)務(wù)性的操作，平臺是不能做的。比如說，商戶的訂單審核、商戶的客戶對接，平臺是不能亂搞的。這個時候，我們需要考慮下，這個平臺的管理員角色，我們一定要讓他登陸到這個后臺嗎？

從產(chǎn)品業(yè)務(wù)合理性的角度出發(fā)，建議拆一個運營后臺出來，專門給到平臺的管理員去使用。這個運營后臺，就不需要加SaaS的概念進去了。因為登陸的用戶，就是平臺自身的員工而已。之后，根據(jù)平臺管理所需要的業(yè)務(wù)功能，定制化設(shè)計開發(fā)即可。

但是，從開發(fā)成本和時間成本的角度來說，產(chǎn)品經(jīng)理就需要對設(shè)計做深一步的取舍了。如果人力物力不夠的情況下，平臺管理員和商戶共用一套系統(tǒng)，是很有必要的。大不了，后期條件允許的情況下，再開始做運營后臺咯。

6. SaaS的其他迭代

至此，SaaS平臺從0到1的基礎(chǔ)框架已經(jīng)搞完了。至于其他業(yè)務(wù)板塊的功能迭代，追尋以上的設(shè)計原理，在所有的數(shù)據(jù)前面做好商戶和門店的關(guān)聯(lián)，在功能展示上，定好功能、角色的數(shù)據(jù)可視可操作范圍就可以了。想象一下，發(fā)現(xiàn)，SaaS也就那么回事……

當(dāng)然，很多技術(shù)人員會和你講到平臺的分布式或微服務(wù)的概念，因為SaaS平臺，本身在很多業(yè)務(wù)操作上，是存在很多共性的，所以需要將某些具備固定用途的板塊獨立化，比如支付、比如訂單等等，嗯吶，這個屬于中臺的職能了，另外研究吧！

五、SaaS平臺的門檻

如今技術(shù)的發(fā)展，要實現(xiàn)一個SaaS平臺從0到1的搭建過程，已經(jīng)不是一件什么難事了。所以在技術(shù)上，基本上是沒有什么門檻的。但是在花錢上面，門檻比較大。

對于成本的預(yù)估，第一是平臺從0到1的技術(shù)團隊的組建，現(xiàn)在開發(fā)人員是那么的貴哦！想起當(dāng)年在那個不堪回首的前公司，那個CTO一上來，就是分布式，關(guān)于產(chǎn)品的東西還沒有見到雛形，就已經(jīng)是100多人的技術(shù)團隊了，從項目經(jīng)理、產(chǎn)品經(jīng)理、后臺、前端、測試、運維、架構(gòu)師等等，樣樣具備……

那個錢，刷刷刷的燒??！可怕的是，搞了1年多，還是沒有啥東西出來！第二就是服務(wù)器成本，系統(tǒng)大了，要用到的機器也是少不了咯。不曉得要多少，反正要花錢。第三塊是寬帶，現(xiàn)在短視頻和直播那么火，這些按流量計費的玩意，怎么收費，可以去阿里云和騰訊云LOOK下吧。

最重要的，就是推廣了?；司拶Y后，終于把東西搞好了，但是如果沒有人愛用，或者已經(jīng)被其他同類型的SaaS平臺搶了先機，這么折騰搞這個玩意，到頭來是為了個啥子哦！

六、SaaS平臺的市場認(rèn)可度

以前都是單機化的軟件部署模式，誰要，誰買。獨立部署，獨立維護?，F(xiàn)在一套SaaS云端直接解決，一個注冊分配一個賬號，就完事了。商戶不用東西折騰，又是搞服務(wù)器搞這搞那的。廠家也不用單個系統(tǒng)單個系統(tǒng)的維護，增加人手、增加成本，每個系統(tǒng)都定制化的改來改去，改到最后面都不曉得是自家開發(fā)的產(chǎn)品了。且原來獨立化部署的系統(tǒng)，購買成本也是極高，現(xiàn)在SaaS賬號，可以數(shù)千元就搞定了。對于這些來說，對于商戶和廠家來說，SaaS真是福音??！

但是，SaaS的市場群體是有限的，且在一定的程度上，它是不能夠被市場所認(rèn)可的。因為，SaaS里面產(chǎn)生的數(shù)據(jù)，是在SaaS廠商的數(shù)據(jù)庫里面的。商戶前期雖然在系統(tǒng)的投入上節(jié)省了大量的錢財，但是，這些都是通過出賣自己的數(shù)據(jù)所換回來的！然而，對于長期經(jīng)營的商戶來講，數(shù)據(jù)，絕對是一大筆財富！

沒有關(guān)系，業(yè)務(wù)先行，可以先跑。不想重投入或者沒錢重投入的人，前期先這樣咯，不然阿強少爺做這個平臺還有什么意義??！

七、我認(rèn)為“阿強藥店SaaS服務(wù)平臺”的未來

雖然SaaS平臺不應(yīng)該被市場所認(rèn)可，但是SaaS平臺卻終究是一個行業(yè)趨勢，也終究要被很多人所接受。想象一下，當(dāng)你以為山寨的年代已經(jīng)過去了，拼多多的崛起還是讓山寨回到你的視野了。為什么？不就是人太多，想法太多，各種各樣的人都有嗎？

有就好，所以給阿強少爺規(guī)劃的這個平臺，還是有未來的。

SaaS平臺，講究的是產(chǎn)品。產(chǎn)品好，解決了客戶的痛點，而剛剛好又做好的客戶的客情。生意就這樣開始了。

但是要端正一個態(tài)度，當(dāng)前做的這個SaaS平臺，絕對不要給自己囚禁在產(chǎn)品服務(wù)的范疇了。對于平臺來說，后期的增值性服務(wù)尤其重要。如數(shù)據(jù)分析、大數(shù)據(jù)輔助決策、用戶標(biāo)簽千人千面、精準(zhǔn)推送等等。這些都是讓平臺升值的關(guān)鍵性因素哇！

另外就是藥店本身屬于一個醫(yī)療健康類型的特殊性行業(yè)，平臺還可以利用這點在行業(yè)里面做一個橫向的擴展，逐步打造成大健康的醫(yī)養(yǎng)平臺。

八、最后

最近在研究微店的SaaS商城，因此想到了這個SaaS的主題。之前在釘釘上購買過一個叫“氚云”的服務(wù)，它也是一個SaaS的系統(tǒng)，同時還加上了PaaS(平臺即服務(wù))的理念。作為產(chǎn)品經(jīng)理的我們，看到這些英文縮寫的時候，并沒有因此會角色它是高大上，因為從產(chǎn)品設(shè)計的理念出發(fā)，我們只是站在客戶的角度去思考客戶的痛點而已，然后通過我們專業(yè)的能力，剛剛好設(shè)計解決了他們的需求。

阿強少爺這個系統(tǒng)還在做，我主動申請親自掛帥了。但是阿強他爸覺得自己來搞太慢了，強迫性要求去找外包團隊實現(xiàn)它。我想，就這樣吧，拜拜，不見。

最后，覺得文章還可以的老鐵，點個贊，一定要點贊哦！

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

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