起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識SaaS系統框架搭建詳解
SaaS系統能提供一個或者多個行業常見場景的功能支持，只要在有網絡的情況下，便“隨處可用、拿來即用、不用下載”，所以現在也是一個流行的趨勢。本文介紹了SaaS系統的框架搭建，一起來學習一下吧。
根據百度百科的解釋：“SaaS，是Software-as-a-Service的縮寫名稱，意思為軟件即服務，SaaS平臺供應商將應用軟件統一部署在自己的服務器上，客戶可以根據工作實際需求，向廠商訂購所需的應用軟件服務，按定購的服務多少和時間長短向廠商支付費用，并通過互聯網獲得SaaS平臺供應商提供的服務”。
SaaS系統能提供一個或者多個行業常見場景的功能支持，并且只要在有網絡的前提下具有“隨處可用、拿來即用、不用下載”的特點。
對于SaaS服務商來說，邊際成本隨著客戶的增多大幅度降低；對于客戶來說，能在業務開展前期先小成本試用，降低軟件綜合成本，可以更聚焦于業務本身的開展；對于用戶來說，可以拿來即用，并且SaaS系統的常規設計符合相對應領域用戶的心智模型，使用起來非常方便。
所以現在SaaS系統的流行已然是一種趨勢。接下來為大家詳細介紹一下SaaS系統的框架搭建，也就是SaaS異于其他常規B端平臺的地方—權限的配置以及數據的隔離要更為復雜一些。
一、菜單管理
菜單管理主要是為了管理后臺系統菜單的展示、排序、以及跳轉，開發人員每次做好新的的功能時，可以直接從這里配置到后臺，不需要通過在數據庫插數據，或者走開發、發布、上線的流程。
參照原型如下：
- 標識碼：唯一標識，去重
- 菜單名稱：名字直接體現了導航的內容
- 菜單圖標：和菜單名稱相對應，只有目錄類型和菜單類型的才會有
- 權限代碼：代碼里面不會進行漢字邏輯判斷，需要設計對應標識碼，為后續權限設置提供選項
- 父級菜單：菜單的層級關系
- 排序號：控制同一層級的前后順序
- url：菜單類型才會有該字段
- 跳轉類型：內部跳轉（相對路徑）、外部跳轉（絕對路徑）
- 跳轉方式：原頁面打開、新頁面打開
- 類型：目錄（可以包含目錄和菜單）、菜單（設置跳轉url）、按鈕（設置權限的最小單位）
- 狀態：開啟（正常在導航中顯示的菜單）、關閉（停用不在導航中顯示的菜單）
二、站點管理
站點管理主要是為了不同機構的名牌化宣傳，專門為機構配置專屬域名&名字&logo等。多個機構也可以用同一個域名。不管是否使用不同的域名，不同機構的用戶數據都會做數據隔離。
大概涉及到的字段如下：
- 組織名稱：從已有的組織下拉菜單中進行選擇
- 域名：用戶訪問的前端網址，后臺網址一般在前臺網址的后面加上/login
- 門戶網站設置：名稱、logo
- 后臺設置：名稱、logo
- 支付相關配置、頁尾菜單配置、數據統計配置等其他配置
不同機構需要做的個性化配置維度以及配置涉及到的參數都比較多。例如上面提到的“支付相關配置”，不同租戶的收款商戶肯定不同的，所以要對微信開放平臺、微信公眾平臺、微信商戶號、支付寶商戶號等進行配置。不同配置維度的具體配置我們后續專門寫文章進行詳解。
三、組織管理
SaaS系統通過組織來實現多租戶管理，為租戶配置管理員以及系統的功能權限等，除此之外還可以根據實際需求為租戶設置可以管理的其他組織以及組織下內容，對于會提供內容服務的SaaS服務商，需要對應設計跨組織共享內容的功能。接下來要給大家分享的SaaS框架支持跨組織管理數據以及跨組織共享內容。
參照原型如下：
- 組織名稱
- 管理員信息配置：賬號、手機號、密碼
- 系統有效期
- 后臺（or前臺）賬號數量限制：根據業務需求進行必選項的配置
- 組織結構：支持多級組織結構（事業部&部門&小組等）
- 前臺模塊權限
- 后臺功能權限
- 組織權限
- **內容權限（課程包&資訊等）
1. 組織和管理員的關系
①管理員默認有該組織的最高功能權限；
②管理員默認有管理組織的全部數據權限；
③SaaS服務商（原型中的A機構）默認有一個總的管理員賬號，擁有整個系統最高的數據以及功能權限；
④操作者可以對自己管理的其他組織進行所有的信息變更，但是對于自己所在的組織只有【重置密碼】的操作；
⑤組織中的管理員賬號只在組織模塊中出現，不會在賬號管理模塊中出現；
2. 系統有效期
①系統到了有效期之后，如果機構不續約一般數據還會保留1~3年；
②超過有效期之后前端用戶一般無法登錄；
③超過有效期之后后臺用戶設置為只能查看部分數據，無法操作。如果數據被清空之后也無法登錄了；
3. 前臺模塊權限
①門戶網站的功能模塊配置；
②不配置的模塊在前端看不到或者點擊提示無權限；
③選項為操作者所在組織有權限的前臺模塊；
4. 后臺功能權限
①配置該組織擁有的后臺功能權限；
②默認授權給組織管理員功能權限；
③選項為操作者擁有的功能權限，操作者按需選擇；
5. 組織權限
①分配該組織可以管理的組織以及每個組織對應的模塊內容（課程包&資訊&角色&賬號等）；
②默認分配給管理員；
③可查看選項：操作者有權限的組織以及組織下所有的內容模塊；
④可操作選項：操作者有權限的組織以及組織下有權限的內容模塊；
原型如下：
6. **內容權限配置（課程包&資訊等）
①共享給被操作組織具體的內容，同步共享給管理員一份；
②無法共享給自己所在的組織，同組織共享通過賬號進行共享，后續在賬號管理中會講到；
③跨組織共享是一種復制性的共享，同一個ID的內容可以多次共享，每次共享生成一個新的內容（產生新的ID）；
④選項為操作者有權限的內容，如果操作者其中一個內容來源為被操作的組織，那么該內容仍舊可以被分享，因為該內容和原內容目前已經是兩個產品，如果業務實際場景需要做限制也ok；
原型如下：
⑤可以查看的內容是【被操作組織所有被共享的內容】和 【操作者有權限內容】（來源ID）的 交集。同一個內容不管詳情是否發生了更改，重復分享會生成新的ID，并對應一條新的共享記錄。
原型如下：
四、角色管理
角色是權限的集合，作為橋梁的作用把權限賦予給后臺賬號。操作者可以看到的角色分為兩種：一種是操作者所擁有的開通了角色模塊權限的管理組織下的角色，另外一種是操作者所在組織下的權限小于等于操作者權限的角色。操作者可以通過【組織下拉列表】進行不同組織角色的查看。
具體涉及到的字段如下：
- 角色名稱
- 組織名稱
- 狀態：啟用、禁用（禁用后擁有該角色的后臺賬號所對應的權限隨時消失）
- 功能權限配置：選項為角色所屬組織的最高權限和操作者所擁有的權限的交集
五、后臺賬號管理
根據實際場景的需要給后臺賬號配置數據和功能權限，操作者可以看到的賬號分為兩種：
一種是操作者所擁有的開通了賬號模塊權限的管理組織下（不包含自己所在的組織）的后臺賬號；
另外一種是操作者所擁有的自己所在組織下自己所在層級結構下的后臺賬號（同一層級的無法看到，例如部門A的經理無法看到自己以及部門B經理的賬號）。
參考原型如下：
- id
- 用戶名
- 姓名
- 手機號
- 密碼
- 組織：下拉單選，選項為操作者有權限的組織；組織選擇之后一般不可以修改
- 所屬的組織結構：選擇之后可以重新編輯
- 創建時間
- 狀態：（啟用、禁用、禁用狀態的賬號無法登錄系統）
- 功能權限
- 組織權限
- ***內容權限
1. 功能權限
①如果操作者和被操作者是不同的組織，那么選項為被操作者所屬組織下的所有角色；
②如果操作者和被操作者是同一個組織，那么選項為權限小于等于操作者權限的角色；
③支持多選；
2. 組織權限
①展示的選項為被操作者所在組織有權限的組織以及每個組織有權限的模塊內容（課程包&資訊&賬號&角色等）；
②可操作的選項為操作者有權限的組織和【被操作者所在組織有權限的組織】的交集，模塊內容同理。
3. **內容權限（課程包&資訊等）
①一種為跨組織后臺賬號的內容分享：可以查看的內容是【被操作者所屬組織所有被共享的內容】和 【操作者有權限內容】的 交集，其中被操作者已經有權限的內容（分享ID）無法被分享。
原型如下：
注：被分享的內容如果之前已經分享給了被操作者同組織的其他賬號aa，那么被操作者得到的內容應該和aa賬號下的內容是一樣的。
所以比較規范的操作流程是：內容在進行跨組織分享時同步分享給被操作組織的管理員后，后續再用管理員賬號或者其他賬號在組織內部進行分享。
②另外一種是同組織后臺賬號的內容分享，可以查看的內容是 操作者有權限的內容，其中被操作者已經有權限的內容無法被分享。
原型如下：
注：跨組織分享后一個產品相當于被復制成內容一樣的另外一個產品，后續的任何更改都不會被同步。而同組織共享之后仍舊是同一個內容，后續任何更改都會同步。
六、前臺賬號管理
前臺用戶可以在門戶網站上看到自己所在組織的有權限的前臺模塊，如果有場景需求可以精細化同一個組織下的不同前端用戶分別設置權限。前端的數據隔離分為兩種：
①不同的組織發布的內容只能本組織的前臺用戶可以看到。
②對于SaaS服務商為多個租戶提供內容服務的業務，可以對其進行特殊化處理，使其發布的內容讓所有的組織的前端用戶都可以看到，但是不同組織產生的用戶內容只能本組織的用戶看到。
前臺用戶涉及到字段如下：
- 用戶名
- 姓名
- 手機號
- 所在組織
- 注冊時間
- 注冊方式：前臺注冊、后臺導入
- 最近登錄時間
- 狀態：啟用、禁用（禁用狀態的賬號無法登錄系統）
小結
常規SaaS系統的設計用到的概念或者思路大概是類似的，但是是否需要進行跨組織管理，跨組織管理需要精細到什么程度。
不同組織的用戶數據、相同組織的用戶數據如何隔離，處理方式是否相同等都是要根據實際業務場景來設計的。
沒有完全標準通用的SaaS系統，我們需要設計的并不是一個完美的SaaS，而是一個最大限度符合業務需求，又能在通用的同時兼顧后續長遠規劃，盡最大可能降本增效、提升用戶體驗的系統。
此部分分享到此結束，希望本篇文章能幫助到需要的小伙伴們~
本文由 @Grace 原創發布于人人都是產品經理，未經許可，禁止轉載。
題圖來自Unsplash，基于 CC0 協議。
該文觀點僅代表作者本人，人人都是產品經理平臺僅提供信息存儲空間服務。
寫的很好，就是這個可能是我理解能力不行，得多看幾遍
您好，有原型嗎
寫的很好，這類型的文章很少見啊
很干，但是有些描述有點繞，建議直接點