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 協議。

該文觀點僅代表作者本人，人人都是産品經理平台僅提供信息存儲空間服務。

,