對于B端設(shè)計(jì)而言，良好的權(quán)限設(shè)計(jì)架構(gòu)是支持其復(fù)雜業(yè)務(wù)的基礎(chǔ)和關(guān)鍵。本文重點(diǎn)詳細(xì)總結(jié)了管理好功能設(shè)計(jì)的內(nèi)容，希望能夠幫助你在各大業(yè)務(wù)場景中提升效率，一起來看看吧。

權(quán)限設(shè)計(jì)是B端產(chǎn)品永遠(yuǎn)繞不開的一個課題，良好的產(chǎn)品權(quán)限設(shè)計(jì)架構(gòu)是支撐企業(yè)復(fù)雜業(yè)務(wù)的基礎(chǔ)與關(guān)鍵。接下來會分兩篇文章剖析產(chǎn)品權(quán)限管理，一篇分享功能權(quán)限管理，一篇分享數(shù)據(jù)權(quán)限管理。

(資料圖片僅供參考)

一、什么是權(quán)限管理

權(quán)限管理，一般指根據(jù)系統(tǒng)設(shè)置的安全規(guī)則或者安全策略，用戶可以訪問而且只能訪問自己被授權(quán)的資源。

簡而言之，用戶登錄系統(tǒng)后，管理用戶可以使用那些功能、查看哪些數(shù)據(jù)，即為權(quán)限管理。

權(quán)限管理分為兩大類：功能權(quán)限管理、數(shù)據(jù)權(quán)限管理。

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

如：CRM系統(tǒng)可以覆蓋售前（線索、拜訪、工作匯報(bào)等）、售中（合同、訂單等）、售后（服務(wù)工單、維保等）等多個業(yè)務(wù)板塊的內(nèi)容，那么不同角色的人員登錄系統(tǒng)后，可區(qū)分使用不同的功能。負(fù)責(zé)市場的用戶登錄系統(tǒng)后使用線索、拜訪、工作匯報(bào)等功能，負(fù)責(zé)售后的用戶登錄后使用服務(wù)工單、維保計(jì)劃等功能。

2、數(shù)據(jù)權(quán)限管理：定義登錄用戶可以查看哪些數(shù)據(jù)。

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

二、權(quán)限管理模型

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

基于角色的訪問控制，是當(dāng)前大多數(shù)權(quán)限管理設(shè)計(jì)的“底座”。

RBAC模型三個關(guān)鍵元素：用戶、角色、權(quán)限。

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

角色：定義可使用的權(quán)限資源的集合，包括：頁面、功能、數(shù)據(jù)等權(quán)限資源，如銷售業(yè)務(wù)員角色、財(cái)務(wù)角色等。

權(quán)限：系統(tǒng)的所有權(quán)限資源，包括：功能、頁面、操作、流程、數(shù)據(jù)等

RBAC模型，使用角色關(guān)聯(lián)管理用戶及權(quán)限。解耦用戶和權(quán)限的對應(yīng)關(guān)系，通過中間對象 – 角色進(jìn)行關(guān)聯(lián)管理。從而簡化系統(tǒng)權(quán)限的授權(quán)，提升權(quán)限管理的可拓展性和可維護(hù)性。

舉個例子：

企業(yè)的銷售業(yè)務(wù)員在CRM系統(tǒng)中需要使用客戶管理、拜訪管理、訂單管理等模塊的功能。

在傳統(tǒng)模式下，我們需要給銷售員A授權(quán)這部分的權(quán)限，當(dāng)新增加一個銷售員B時，又需要重新授權(quán)一遍這部分的權(quán)限，增加N個銷售員就需要重復(fù)授權(quán)N遍。

在RBAC模式下，將銷售員需要的權(quán)限都同一授權(quán)給“銷售業(yè)務(wù)員”這個角色，增加銷售員時，只需要將“銷售業(yè)務(wù)員”的角色給到銷售員即可。同時，銷售員如果需要新增或減少功能，只需要修改角色授權(quán)的資源即可，無需一個一個銷售員進(jìn)行調(diào)整。

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

基于RBAC模型的變形，將功能權(quán)限和數(shù)據(jù)權(quán)限區(qū)分管理，進(jìn)一步提升權(quán)限管理的靈活性。目前，在paas平臺、saas+paas的產(chǎn)品中使用較多。

通過職能進(jìn)行功能權(quán)限管理，通過角色進(jìn)行數(shù)據(jù)權(quán)限管理。職能管理是“權(quán)”，角色管理是“限”，一個用戶的權(quán)限=職能管理+角色管理。

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

三、功能權(quán)限管理

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

1. 功能權(quán)限資源分類

常見的功能權(quán)限管理可以定義到模塊、頁面、按鈕、字段、流程、業(yè)務(wù)類型等層級。

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

① 功能權(quán)限分配遵循功能優(yōu)先級，分配優(yōu)先級較低的權(quán)限資源時，必須先分配其歸屬的優(yōu)先級高的權(quán)限資源。

對于常用權(quán)限資源，可以分成三個優(yōu)先級，且權(quán)限資源是個層級結(jié)構(gòu)，有歸屬關(guān)系。權(quán)限資源進(jìn)行分配時，分配低優(yōu)先級的權(quán)限資源時，必須分配其歸屬的高優(yōu)先級的權(quán)限資源。

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

所以，大多數(shù)產(chǎn)品的功能權(quán)限管理，在對角色授予權(quán)限時，勾選低優(yōu)先級的權(quán)限資源時，會默認(rèn)自動將其歸屬的父級權(quán)限資源默認(rèn)勾選上。如：勾選按鈕時，會默認(rèn)將按鈕所在的頁面，頁面所在的模塊對應(yīng)勾選上。

注：圖中將流程歸為第一優(yōu)先級是因?yàn)?，定義業(yè)務(wù)流程時，可能跨功能模塊、可能涉及多個頁面跳轉(zhuǎn)等。如：銷售線索轉(zhuǎn)商機(jī)的流程，當(dāng)銷售線索滿足一定的條件時，可以點(diǎn)擊按鈕觸發(fā)流程，自動生成一條商機(jī)記錄。那么這個流程就涉及了兩個功能模塊：線索模塊、商機(jī)模塊。

② 登錄用戶擁有多個角色時，可訪問多個角色關(guān)聯(lián)的權(quán)限資源的總和。

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

③ 可支持管理的權(quán)限資源類型越多，整體的維護(hù)及開發(fā)成本越高。

功能權(quán)限管理并非支持管理的權(quán)限資源類型越多越好，這與系統(tǒng)整體的開發(fā)與維護(hù)成本息息相關(guān)?？晒芾淼臋?quán)限資源類型越多，成本越高。需要根據(jù)實(shí)際的管理需要去確定功能權(quán)限管理需要支持的權(quán)限資源類型。

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

以字段的訪問、操作權(quán)限為例，當(dāng)我們希望將權(quán)限管理拓展到字段層級時：

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

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

四、功能權(quán)限管理的梳理模板

在產(chǎn)品實(shí)施交付的過程中，需要對用戶的功能使用權(quán)限進(jìn)行梳理，對于不同職能的用戶授權(quán)不同的功能。

下面分享一份功能權(quán)限管理的梳理模板：

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

最后

相較于功能權(quán)限管理而言，數(shù)據(jù)權(quán)限管理更復(fù)雜、也更難理解。實(shí)際業(yè)務(wù)中，會有各種業(yè)務(wù)場景需要滿足，因此，靈活的數(shù)據(jù)權(quán)限管理架構(gòu)是至關(guān)重要的。下一篇將結(jié)合實(shí)際場景分享數(shù)據(jù)權(quán)限管理。

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

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

該文觀點(diǎn)僅代表作者本人，人人都是產(chǎn)品經(jīng)理平臺僅提供信息存儲空間服務(wù)。