對于B端設計而言，良好的權限設計架構是支持其復雜業務的基礎和關鍵。本文重點詳細總結了管理好功能設計的內容，希望能夠幫助你在各大業務場景中提升效率，一起來看看吧。

權限設計是B端產品永遠繞不開的一個課題，良好的產品權限設計架構是支撐企業復雜業務的基礎與關鍵。接下來會分兩篇文章剖析產品權限管理，一篇分享功能權限管理，一篇分享數據權限管理。

(資料圖片僅供參考)

一、什么是權限管理

權限管理，一般指根據系統設置的安全規則或者安全策略，用戶可以訪問而且只能訪問自己被授權的資源。

簡而言之，用戶登錄系統后，管理用戶可以使用那些功能、查看哪些數據，即為權限管理。

權限管理分為兩大類：功能權限管理、數據權限管理。

1、功能權限管理：定義登錄用戶可以看到哪些界面、使用哪些功能。

如：CRM系統可以覆蓋售前（線索、拜訪、工作匯報等）、售中（合同、訂單等）、售后（服務工單、維保等）等多個業務板塊的內容，那么不同角色的人員登錄系統后，可區分使用不同的功能。負責市場的用戶登錄系統后使用線索、拜訪、工作匯報等功能，負責售后的用戶登錄后使用服務工單、維保計劃等功能。

2、數據權限管理：定義登錄用戶可以查看哪些數據。

對于同一功能，不同角色的用戶可以查看的數據范圍是不一樣的，如：CRM中的客戶數據，對于企業CEO而言，所有的客戶CEO都可以查看到；對于區域銷售經理而言，僅可以查看到歸屬于所管轄區域內的客戶（華東區域銷售經理只查看華東的客戶，華南區域銷售經理只查看華南的客戶）；對于普通銷售員而言，僅可以查看到自己負責的客戶。

二、權限管理模型

1. RBAC模型（Role-Based Access Control）

基于角色的訪問控制，是當前大多數權限管理設計的“底座”。

RBAC模型三個關鍵元素：用戶、角色、權限。

用戶：登錄系統的使用人員，如：張三、李四等。

角色：定義可使用的權限資源的集合，包括：頁面、功能、數據等權限資源，如銷售業務員角色、財務角色等。

權限：系統的所有權限資源，包括：功能、頁面、操作、流程、數據等

RBAC模型，使用角色關聯管理用戶及權限。解耦用戶和權限的對應關系，通過中間對象 – 角色進行關聯管理。從而簡化系統權限的授權，提升權限管理的可拓展性和可維護性。

舉個例子：

企業的銷售業務員在CRM系統中需要使用客戶管理、拜訪管理、訂單管理等模塊的功能。

在傳統模式下，我們需要給銷售員A授權這部分的權限，當新增加一個銷售員B時，又需要重新授權一遍這部分的權限，增加N個銷售員就需要重復授權N遍。

在RBAC模式下，將銷售員需要的權限都同一授權給“銷售業務員”這個角色，增加銷售員時，只需要將“銷售業務員”的角色給到銷售員即可。同時，銷售員如果需要新增或減少功能，只需要修改角色授權的資源即可，無需一個一個銷售員進行調整。

2. 基于RBAC模型的“變形”

基于RBAC模型的變形，將功能權限和數據權限區分管理，進一步提升權限管理的靈活性。目前，在paas平臺、saas+paas的產品中使用較多。

通過職能進行功能權限管理，通過角色進行數據權限管理。職能管理是“權”，角色管理是“限”，一個用戶的權限=職能管理+角色管理。

將功能權限與數據權限分開管理，對兩種權限分別做一些復雜的組合權限控制時，可以不用考慮互相影響。如：通過角色權限+角色組+共享規則+特例規則等，組成數據權限滿足復雜的權限要求

三、功能權限管理

功能權限管理：定義登錄用戶可以查看到哪些界面、使用哪些功能等。

1. 功能權限資源分類

常見的功能權限管理可以定義到模塊、頁面、按鈕、字段、流程、業務類型等層級。

模塊權限：指業務功能板塊的訪問權限，如：客戶管理、線索管理。一般情況下，分配模塊權限，功能模塊下的頁面、按鈕均同步授予權限，如：分配客戶管理權限，客戶列表、客戶詳情、新增客戶按鈕、刪除客戶按鈕等同步授予權限。頁面權限：指特定的功能頁面的訪問權限，如：客戶列表、客戶詳情。一般情況下，分配頁面權限，頁面下的按鈕均同步授予權限，如：分配客戶列表權限，新增客戶、刪除客戶等按鈕同步授予權限。按鈕權限：指特定功能按鈕的操作權限，如：新增、刪除、修改、提交等按鈕。字段權限：指功能模塊的字段操作權限，字段權限控制多出現在paas平臺，如：客戶的客戶名稱字段的讀寫、導出權限。流程權限：流程權限控制多出現在paas平臺，在paas平臺上支持用戶自定義流程并支持設定流程使用權限，包括業務流程、審批流程。流程權限較少單獨作為一項權限資源進行管理，通常流程權限和按鈕權限是一致的，大多數流程都是通過按鈕去觸發流程執行，控制按鈕權限也等于控制了流程權限。業務類型權限：較少使用的權限資源控制，多出現在paas平臺上。paas平臺支持用戶定義對象的不同業務類型，且支持不同角色可使用不同的業務對象。如：客戶對象可定義直銷客戶、渠道客戶兩種業務類型，那么負責直銷的銷售使用直銷客戶，負責渠道的銷售使用渠道客戶，兩種不同的業務類型的客戶，字段模型、流程等都可能不同。2. 功能權限管理基本原則

① 功能權限分配遵循功能優先級，分配優先級較低的權限資源時，必須先分配其歸屬的優先級高的權限資源。

對于常用權限資源，可以分成三個優先級，且權限資源是個層級結構，有歸屬關系。權限資源進行分配時，分配低優先級的權限資源時，必須分配其歸屬的高優先級的權限資源。

如：分配“新增客戶”的按鈕權限給到用戶，那么需要把“新增客戶”按鈕所在的【客戶列表】頁面分配給當前用戶，同時為了分配【客戶列表】頁需要把{客戶管理}模塊分配給到用戶。否則，只分配新增客戶按鈕的權限，那按鈕所在的頁面用戶無法查看，這個按鈕也就無法操作。

所以，大多數產品的功能權限管理，在對角色授予權限時，勾選低優先級的權限資源時，會默認自動將其歸屬的父級權限資源默認勾選上。如：勾選按鈕時，會默認將按鈕所在的頁面，頁面所在的模塊對應勾選上。

注：圖中將流程歸為第一優先級是因為，定義業務流程時，可能跨功能模塊、可能涉及多個頁面跳轉等。如：銷售線索轉商機的流程，當銷售線索滿足一定的條件時，可以點擊按鈕觸發流程，自動生成一條商機記錄。那么這個流程就涉及了兩個功能模塊：線索模塊、商機模塊。

② 登錄用戶擁有多個角色時，可訪問多個角色關聯的權限資源的總和。

舉例說明：用戶A 擁有 角色1、角色2 兩個角色，角色1 可訪問頁面I、按鈕I、流程I，角色2可訪問頁面I、流程I、頁面II，那么用戶A即可訪問頁面I、按鈕I、流程I、頁面II。

③ 可支持管理的權限資源類型越多，整體的維護及開發成本越高。

功能權限管理并非支持管理的權限資源類型越多越好，這與系統整體的開發與維護成本息息相關。可管理的權限資源類型越多，成本越高。需要根據實際的管理需要去確定功能權限管理需要支持的權限資源類型。

目前大多數的產品功能權限管理支持到“模塊-頁面-按鈕”層級，或者是“頁面-按鈕”層級。較為常用的系統設計中，模塊、頁面、按鈕這三種類型的權限資源只需要在系統后臺完成資源注冊，即可對這部分權限資源進行管理。如下方截圖：

以字段的訪問、操作權限為例，當我們希望將權限管理拓展到字段層級時：

首先需要明確對象字段中的文名稱與數據庫對象表的列名的對應關系，用戶定義對象字段的讀寫、導出等權限時，需要根據字段的中文名稱去做選擇，如果只展示數據庫表名，對于用戶而言，是無法理解和操作的。其次在用戶訪問對象數據、編輯對象數據等操作時需要對用戶權限進行查驗，驗證用戶是否有權限訪問、操作字段。

相對于常用的“模塊-頁面-按鈕”/“頁面-按鈕”的權限控制，只需要控制頁面、按鈕的顯示/隱藏，整體的維護和開發成本是高出一大截的。

四、功能權限管理的梳理模板

在產品實施交付的過程中，需要對用戶的功能使用權限進行梳理，對于不同職能的用戶授權不同的功能。

下面分享一份功能權限管理的梳理模板：

注：文檔模板中并未將字段操作權限的梳理呈現出來，原因是：各功能對象的字段較多，實際情況下，并不會和業務人員逐個字段核對是否需要查看、導出等權限。更多的是，一些特例情況會在調研、溝通的過程中會提出,可在表中通過備注記錄。

最后

相較于功能權限管理而言，數據權限管理更復雜、也更難理解。實際業務中，會有各種業務場景需要滿足，因此，靈活的數據權限管理架構是至關重要的。下一篇將結合實際場景分享數據權限管理。

本文由 @茶話B端 原創發布于人人都是產品經理，未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議

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