本文基于面向某個垂直行業的SaaS系統的設計經驗，抽象出一套适合中小企業的權限管理體系，目标是最大限度保留系統彈性的同時，把系統複雜度和開發成本盡可能降低。enjoy~

面向企業級的SaaS（軟件及服務）系統，由于企業用戶的規模和内部管理模式千差萬别，設計一套具備足夠彈性、符合絕大部分目标企業用戶需求的權限管理系統，是一個很大的挑戰。

我們可以看到，市面上面向多個行業的綜合性SaaS系統，例如銷售易、紛享銷客等，由于它們的目标客戶跨越了多個行業、多種規模，這些企業具備各種各樣的内部管理風格和模式，在權限系統的管理上，往往做得非常複雜，不僅具備部門、角色、職位、數據等各個維度的權限管理，各個功能模塊還有自己獨立的權限管理，雖然具備最大的彈性，卻給企業的系統管理帶來較大的負擔。

提煉的三個核心原則：

• 企業-管理員-普通賬号三級權限
• 功能和數據權限分離
• 部門和角色分離

圍繞上述三個基本原則，我們力圖在滿足中小企業需求的前提下保持足夠的彈性，并嚴格控制複雜度和開發成本。詳細描述如下。

1. 權限從上到下分為三個層級：企業賬号（老闆賬号）、管理員賬号、普通賬号

對于中小企業來說，公司的實際控制人，往往是公司的創始人或自然人大股東，因此企業賬号的使用者以及對應綁定的手機号碼，都是公司的實際控制人，他應該掌握最核心、權限最大的企業賬号，所以也可以稱為“老闆賬号”。

但是在實際場景中，公司的實際控制人并不會直接管理公司的業務支撐系統，因此，需要在系統首次部署時，創建好企業賬号，并由企業賬号授權給某一個或多個系統管理員，由系統管理員去完成日常的角色創建、員工導入等工作。系統管理員，對應的一般就是HR或行政部門的管理人員。當然，企業賬号的權限高于管理員賬号，如果是小微型企業，也可以由企業賬号直接替代管理員賬号的功能。

除了企業賬号和管理員賬号之外，其他各級員工所持有的賬号，都屬于普通賬号。普通賬号的部門、角色、數據等權限的設置，一律由系統管理員配置。

三個權限層級示意圖如下：

在實際系統中的核心業務步驟如下：

（1）企業購買系統時，創建一個企業賬号，這個企業賬号綁定的手機号碼為公司實際控制人的手機号碼。該手機号碼必要時可以解綁（例如公司實際控制人變更），由于該功能觸發頻率很低，因此不需要在前端功能中實現，隻需要在購買協議中寫明，“購買企業可以通過書面方式提出企業賬号手機号碼綁定變更需求”即可。

（2）在部署和培訓階段，可指導企業賬号持有人創建一個或多個管理員賬号，該賬号一般授權給行政總監或人力資源總監，後續配置即由管理員賬号進行。

（3）管理員賬号持有人需要接受系統培訓，掌握部門創建、角色創建、功能和數據權限分配等基本操作。管理員所有操作都必須記錄在案，供企業賬号持有人監督，且管理員操作觸發異常行為規則（如大量分配高等級權限等）時，系統會通過短信方式通知到企業賬号持有人，确保企業賬号對管理員的全方位掌控。

（4）企業賬号可随時将管理員賬号禁用或設定為離職，但管理員賬号不可對企業賬号進行任何配置或操作。

（5）企業賬号默認擁有所有權限。

2. 功能權限和數據權限分離

功能權限，定義為可見、可以操作的功能範圍。例如某一部分菜單，或者某個頁面裡的各種操作。

數據權限，定義為若幹個數據類型裡的具體可見範圍，例如“客戶”就是一個數據類型，它的權限舉例如“無權限”、“我的客戶”、“我所在部門的客戶”、“我所在部門及下級部門的客戶”。

通過功能權限和數據權限的分離，我們可以做到以下場景：需要開拓和維護客戶的角色集合，都可以擁有“客戶”這個菜單的權限，但不同的角色進入“客戶”菜單的列表時，看到的客戶範圍各不相同，極端情況是看不到任何客戶。且不同角色在同一個客戶頁面上，能進行的操作也不同，例如有的角色可以新建客戶，有的卻不行，這就要由功能權限來控制。

可見，通過功能權限和數據權限的分離和配合，我們在具體的權限分配上有了非常大的彈性，且在技術層面的後台系統的設計上，也非常合理、清晰。

而在具體設計上，需要保證以下4點：

1. 正确區分功能和數據，入口性和操作性的都應該歸類為功能
2. 正确對數據進行分類，避免存在分類後的某些數據存在交集
3. 數據分類到多細的顆粒度，需要由行業特性決定
4. 數據權限區分為查看、編輯和删除

示例圖如下，由于涉及具體産品，對某些文字進行了打碼：

3、部門和角色分離

部門的定義，自然就是公司行政組織架構下的部門。

在本設計方案中，角色等同于職位，而在許多大型的SaaS系統中，為了更大的靈活性，往往會把角色和職位分開，但根據我們的判斷，對于中小企業，設定角色一個就夠了，職位當然還存在，但僅僅是一個不涉及權限管理的文本title了。

以一個銷售公司來說，角色可以包括：“渠道專員”、“渠道總監”、“銷售專員”、“銷售經理”、“總經理”等等。

所謂的部門和角色分開，就是不同的部門可以有相同的角色，例如如果有渠道一部、渠道二部，則這兩個渠道部的員工的角色都可以設定為“渠道專員”，這兩個部門的管理者都可以設定為“渠道經理”。再配合功能和數據權限，則進一步配置“渠道專員”具有“渠道”菜單的功能權限，其能夠查看的渠道數據權限範圍則僅為“我的”，而“渠道經理”同樣具有“渠道”菜單的功能權限，但其能夠查看的渠道數據權限的範圍則擴大為“部門”。

具體設計上：

1. 最大部門即為公司
2. 管理員賬号和普通賬号均可禁用或設置為離職
3. 不同部門可以配置相同角色
4. 相同角色的功能權限和數據權限是一樣的

4. 權限系統和其他功能設計的關系

總結完權限系統三個核心的基本原則後，我們還需要指出一點：權限系統的設計方案，在整個系統中絕不是孤立的，它能否實現設計目标，并和整個系統完美配合，還需要做到以下幾點：

首先，菜單和功能的設計，必須是最小顆粒度，否則就和數據權限産生沖突。例如：我們隻需要一個“客戶”菜單即可，不同角色在“客戶”菜單裡能幹什麼事情，由功能權限和數據權限配合進行控制，但切不可出現“我的客戶” “全部客戶”兩個菜單，這明顯和數據權限有根本沖突，且也是一種不優美、不合理、擴展性差的設計。

其次，數據的分類，必須符合業務需求，且劃分合理。有些數據都是公開的可以不歸入數據權限進行管理，所有角色默認都有即可；有些數據需要進一步細分，例如同樣以“客戶”舉例，在某些公司的業務規則中，就需要将客戶的基本信息和聯系信息分開控制，管理層可以看客戶基本信息，但隻有客戶負責人才可以看聯系信息，這種情況就需要将客戶的數據權限分為“客戶基本信息”和“客戶聯系信息”兩個。

最後，權限變更的記錄和所有賬号的行為軌迹記錄一樣重要。權限系統本質是進行權力的限制，沒有監管的權力必定是會失控的。在出現問題的時候，必須同時配合權限變更的記錄、角色變更的記錄和賬号的行為軌迹記錄進行追責和存證，确保維護企業的合法權益。

總結

在合理設計的前提下，權限系統也并非越複雜越好。隻有符合目标客戶需求并具備最大彈性的權限系統，才是最好的。

本文由 @Alex 原創發布于人人都是産品經理。未經許可，禁止轉載。

題圖來源于網絡

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部