對(duì)于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ù)場(chǎng)景中提升效率，一起來看看吧。
權(quán)限設(shè)計(jì)是B端產(chǎn)品永遠(yuǎn)繞不開的一個(gè)課題，良好的產(chǎn)品權(quán)限設(shè)計(jì)架構(gòu)是支撐企業(yè)復(fù)雜業(yè)務(wù)的基礎(chǔ)與關(guān)鍵。接下來會(huì)分兩篇文章剖析產(chǎn)品權(quán)限管理，一篇分享功能權(quán)限管理，一篇分享數(shù)據(jù)權(quán)限管理。
(資料圖)
一、什么是權(quán)限管理
權(quán)限管理，一般指根據(jù)系統(tǒng)設(shè)置的安全規(guī)則或者安全策略，用戶可以訪問而且只能訪問自己被授權(quán)的資源。
簡(jiǎn)而言之，用戶登錄系統(tǒng)后，管理用戶可以使用那些功能、查看哪些數(shù)據(jù)，即為權(quán)限管理。
權(quán)限管理分為兩大類：功能權(quán)限管理、數(shù)據(jù)權(quán)限管理。
1、功能權(quán)限管理：定義登錄用戶可以看到哪些界面、使用哪些功能。
如：CRM系統(tǒng)可以覆蓋售前（線索、拜訪、工作匯報(bào)等）、售中（合同、訂單等）、售后（服務(wù)工單、維保等）等多個(gè)業(yè)務(wù)板塊的內(nèi)容，那么不同角色的人員登錄系統(tǒng)后，可區(qū)分使用不同的功能。負(fù)責(zé)市場(chǎng)的用戶登錄系統(tǒng)后使用線索、拜訪、工作匯報(bào)等功能，負(fù)責(zé)售后的用戶登錄后使用服務(wù)工單、維保計(jì)劃等功能。
2、數(shù)據(jù)權(quán)限管理：定義登錄用戶可以查看哪些數(shù)據(jù)。
對(duì)于同一功能，不同角色的用戶可以查看的數(shù)據(jù)范圍是不一樣的，如：CRM中的客戶數(shù)據(jù)，對(duì)于企業(yè)CEO而言，所有的客戶CEO都可以查看到；對(duì)于區(qū)域銷售經(jīng)理而言，僅可以查看到歸屬于所管轄區(qū)域內(nèi)的客戶（華東區(qū)域銷售經(jīng)理只查看華東的客戶，華南區(qū)域銷售經(jīng)理只查看華南的客戶）；對(duì)于普通銷售員而言，僅可以查看到自己負(fù)責(zé)的客戶。
二、權(quán)限管理模型 1. RBAC模型（Role-Based Access Control）
基于角色的訪問控制，是當(dāng)前大多數(shù)權(quán)限管理設(shè)計(jì)的“底座”。
RBAC模型三個(gè)關(guān)鍵元素：用戶、角色、權(quán)限。
用戶：登錄系統(tǒng)的使用人員，如：張三、李四等。
角色：定義可使用的權(quán)限資源的集合，包括：頁(yè)面、功能、數(shù)據(jù)等權(quán)限資源，如銷售業(yè)務(wù)員角色、財(cái)務(wù)角色等。
權(quán)限：系統(tǒng)的所有權(quán)限資源，包括：功能、頁(yè)面、操作、流程、數(shù)據(jù)等
RBAC模型，使用角色關(guān)聯(lián)管理用戶及權(quán)限。解耦用戶和權(quán)限的對(duì)應(yīng)關(guān)系，通過中間對(duì)象 – 角色進(jìn)行關(guān)聯(lián)管理。從而簡(jiǎn)化系統(tǒng)權(quán)限的授權(quán)，提升權(quán)限管理的可拓展性和可維護(hù)性。
舉個(gè)例子：
企業(yè)的銷售業(yè)務(wù)員在CRM系統(tǒng)中需要使用客戶管理、拜訪管理、訂單管理等模塊的功能。
在傳統(tǒng)模式下，我們需要給銷售員A授權(quán)這部分的權(quán)限，當(dāng)新增加一個(gè)銷售員B時(shí)，又需要重新授權(quán)一遍這部分的權(quán)限，增加N個(gè)銷售員就需要重復(fù)授權(quán)N遍。
在RBAC模式下，將銷售員需要的權(quán)限都同一授權(quán)給“銷售業(yè)務(wù)員”這個(gè)角色，增加銷售員時(shí)，只需要將“銷售業(yè)務(wù)員”的角色給到銷售員即可。同時(shí)，銷售員如果需要新增或減少功能，只需要修改角色授權(quán)的資源即可，無需一個(gè)一個(gè)銷售員進(jìn)行調(diào)整。
2. 基于RBAC模型的“變形”
基于RBAC模型的變形，將功能權(quán)限和數(shù)據(jù)權(quán)限區(qū)分管理，進(jìn)一步提升權(quán)限管理的靈活性。目前，在paas平臺(tái)、saas+paas的產(chǎn)品中使用較多。
通過職能進(jìn)行功能權(quán)限管理，通過角色進(jìn)行數(shù)據(jù)權(quán)限管理。職能管理是“權(quán)”，角色管理是“限”，一個(gè)用戶的權(quán)限=職能管理+角色管理。
將功能權(quán)限與數(shù)據(jù)權(quán)限分開管理，對(duì)兩種權(quán)限分別做一些復(fù)雜的組合權(quán)限控制時(shí)，可以不用考慮互相影響。如：通過角色權(quán)限+角色組+共享規(guī)則+特例規(guī)則等，組成數(shù)據(jù)權(quán)限滿足復(fù)雜的權(quán)限要求
三、功能權(quán)限管理
功能權(quán)限管理：定義登錄用戶可以查看到哪些界面、使用哪些功能等。
1. 功能權(quán)限資源分類
常見的功能權(quán)限管理可以定義到模塊、頁(yè)面、按鈕、字段、流程、業(yè)務(wù)類型等層級(jí)。
模塊權(quán)限：指業(yè)務(wù)功能板塊的訪問權(quán)限，如：客戶管理、線索管理。一般情況下，分配模塊權(quán)限，功能模塊下的頁(yè)面、按鈕均同步授予權(quán)限，如：分配客戶管理權(quán)限，客戶列表、客戶詳情、新增客戶按鈕、刪除客戶按鈕等同步授予權(quán)限。 頁(yè)面權(quán)限：指特定的功能頁(yè)面的訪問權(quán)限，如：客戶列表、客戶詳情。一般情況下，分配頁(yè)面權(quán)限，頁(yè)面下的按鈕均同步授予權(quán)限，如：分配客戶列表權(quán)限，新增客戶、刪除客戶等按鈕同步授予權(quán)限。 按鈕權(quán)限：指特定功能按鈕的操作權(quán)限，如：新增、刪除、修改、提交等按鈕。 字段權(quán)限：指功能模塊的字段操作權(quán)限，字段權(quán)限控制多出現(xiàn)在paas平臺(tái)，如：客戶的客戶名稱字段的讀寫、導(dǎo)出權(quán)限。 流程權(quán)限：流程權(quán)限控制多出現(xiàn)在paas平臺(tái)，在paas平臺(tái)上支持用戶自定義流程并支持設(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平臺(tái)上。paas平臺(tái)支持用戶定義對(duì)象的不同業(yè)務(wù)類型，且支持不同角色可使用不同的業(yè)務(wù)對(duì)象。如：客戶對(duì)象可定義直銷客戶、渠道客戶兩種業(yè)務(wù)類型，那么負(fù)責(zé)直銷的銷售使用直銷客戶，負(fù)責(zé)渠道的銷售使用渠道客戶，兩種不同的業(yè)務(wù)類型的客戶，字段模型、流程等都可能不同。2. 功能權(quán)限管理基本原則
① 功能權(quán)限分配遵循功能優(yōu)先級(jí)，分配優(yōu)先級(jí)較低的權(quán)限資源時(shí)，必須先分配其歸屬的優(yōu)先級(jí)高的權(quán)限資源。
對(duì)于常用權(quán)限資源，可以分成三個(gè)優(yōu)先級(jí)，且權(quán)限資源是個(gè)層級(jí)結(jié)構(gòu)，有歸屬關(guān)系。權(quán)限資源進(jìn)行分配時(shí)，分配低優(yōu)先級(jí)的權(quán)限資源時(shí)，必須分配其歸屬的高優(yōu)先級(jí)的權(quán)限資源。
如：分配“新增客戶”的按鈕權(quán)限給到用戶，那么需要把“新增客戶”按鈕所在的【客戶列表】頁(yè)面分配給當(dāng)前用戶，同時(shí)為了分配【客戶列表】頁(yè)需要把{客戶管理}模塊分配給到用戶。否則，只分配新增客戶按鈕的權(quán)限，那按鈕所在的頁(yè)面用戶無法查看，這個(gè)按鈕也就無法操作。
所以，大多數(shù)產(chǎn)品的功能權(quán)限管理，在對(duì)角色授予權(quán)限時(shí)，勾選低優(yōu)先級(jí)的權(quán)限資源時(shí)，會(huì)默認(rèn)自動(dòng)將其歸屬的父級(jí)權(quán)限資源默認(rèn)勾選上。如：勾選按鈕時(shí)，會(huì)默認(rèn)將按鈕所在的頁(yè)面，頁(yè)面所在的模塊對(duì)應(yīng)勾選上。
注：圖中將流程歸為第一優(yōu)先級(jí)是因?yàn)椋x業(yè)務(wù)流程時(shí)，可能跨功能模塊、可能涉及多個(gè)頁(yè)面跳轉(zhuǎn)等。如：銷售線索轉(zhuǎn)商機(jī)的流程，當(dāng)銷售線索滿足一定的條件時(shí)，可以點(diǎn)擊按鈕觸發(fā)流程，自動(dòng)生成一條商機(jī)記錄。那么這個(gè)流程就涉及了兩個(gè)功能模塊：線索模塊、商機(jī)模塊。
② 登錄用戶擁有多個(gè)角色時(shí)，可訪問多個(gè)角色關(guān)聯(lián)的權(quán)限資源的總和。
舉例說明：用戶A 擁有 角色1、角色2 兩個(gè)角色，角色1 可訪問頁(yè)面I、按鈕I、流程I，角色2可訪問頁(yè)面I、流程I、頁(yè)面II，那么用戶A即可訪問頁(yè)面I、按鈕I、流程I、頁(yè)面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)限管理支持到“模塊-頁(yè)面-按鈕”層級(jí)，或者是“頁(yè)面-按鈕”層級(jí)。較為常用的系統(tǒng)設(shè)計(jì)中，模塊、頁(yè)面、按鈕這三種類型的權(quán)限資源只需要在系統(tǒng)后臺(tái)完成資源注冊(cè)，即可對(duì)這部分權(quán)限資源進(jìn)行管理。如下方截圖：
以字段的訪問、操作權(quán)限為例，當(dāng)我們希望將權(quán)限管理拓展到字段層級(jí)時(shí)：
首先需要明確對(duì)象字段中的文名稱與數(shù)據(jù)庫(kù)對(duì)象表的列名的對(duì)應(yīng)關(guān)系，用戶定義對(duì)象字段的讀寫、導(dǎo)出等權(quán)限時(shí)，需要根據(jù)字段的中文名稱去做選擇，如果只展示數(shù)據(jù)庫(kù)表名，對(duì)于用戶而言，是無法理解和操作的。 其次在用戶訪問對(duì)象數(shù)據(jù)、編輯對(duì)象數(shù)據(jù)等操作時(shí)需要對(duì)用戶權(quán)限進(jìn)行查驗(yàn)，驗(yàn)證用戶是否有權(quán)限訪問、操作字段。相對(duì)于常用的“模塊-頁(yè)面-按鈕”/“頁(yè)面-按鈕”的權(quán)限控制，只需要控制頁(yè)面、按鈕的顯示/隱藏，整體的維護(hù)和開發(fā)成本是高出一大截的。
四、功能權(quán)限管理的梳理模板
在產(chǎn)品實(shí)施交付的過程中，需要對(duì)用戶的功能使用權(quán)限進(jìn)行梳理，對(duì)于不同職能的用戶授權(quán)不同的功能。
下面分享一份功能權(quán)限管理的梳理模板：
注：文檔模板中并未將字段操作權(quán)限的梳理呈現(xiàn)出來，原因是：各功能對(duì)象的字段較多，實(shí)際情況下，并不會(huì)和業(yè)務(wù)人員逐個(gè)字段核對(duì)是否需要查看、導(dǎo)出等權(quán)限。更多的是，一些特例情況會(huì)在調(diào)研、溝通的過程中會(huì)提出,可在表中通過備注記錄。
最后
相較于功能權(quán)限管理而言，數(shù)據(jù)權(quán)限管理更復(fù)雜、也更難理解。實(shí)際業(yè)務(wù)中，會(huì)有各種業(yè)務(wù)場(chǎng)景需要滿足，因此，靈活的數(shù)據(jù)權(quán)限管理架構(gòu)是至關(guān)重要的。下一篇將結(jié)合實(shí)際場(chǎng)景分享數(shù)據(jù)權(quán)限管理。
本文由 @茶話B端 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載
題圖來自Unsplash，基于CC0協(xié)議
責(zé)任編輯：Rex_09
營(yíng)業(yè)執(zhí)照公示信息