很多企業管理的中使用的軟件，基本上都離不開“權限管理”。有的朋友對權限管理理解的很透徹，有些朋友對一些概念模糊不清。這裡總結了一些常見的誤區，可供大家參考。

1. “普通用戶有删除功能嗎”

權限實際上是功能權限和數據權限的組合，像“删除”操作是一個功能操作權限，需要把“删除”賦予給某個用戶，該用戶才能有這個操作權限。如這樣一個場景：企業IT管理員為系統定義角色，給用戶分配角色。

給新員工陳穎賦予“業務經理”角色，“業務經理”具有“新增客戶單位”、“查詢客戶單位”、“修改客戶單位”權限。此時張穎能夠進入系統，則可以進行這些操作。

2. “普通用戶能查看訂單數據嗎”

以上舉例，局限于功能訪問權限，還有一些數據權限的權限管理，如：陳穎是浙江區域的“業務經理”，所以她隻能夠查看本區域的客戶單位，而不能查看到其它地區的客戶單位。甚至考慮到業務經理之間的競争，系統可以控制更細粒度級别的數據權限，即普通業務經理的角色隻能看到自己維護的客戶單位，而不能查看其他人員的客戶單位。軟件系統的權限管理其實是與線下實際管理策略相對應的。

有些企業本身制定和實施了嚴格的規章制度，那麼軟件系統的權限管理就可以幫助企業更好的貫徹制度的實行，提高整體的運行效率和數據的安全。相反有些企業實際線下沒有明确的經營策略，存在着管理風險和員工之間的不正當競争，寄希望于軟件系統的權限規範，但是實施過程中會有很多阻力。

3. “這不就是用戶管理系統嗎”

這是将用戶管理系統當做權限管理系統，其實權限基本都是基于角色的，用戶分配了對應的角色後，則會擁有對應的權限。而用戶管理系統，隻是将用戶管理起來。

從控制力度來看，可以将權限管理分為兩大類：

1. 功能級權限管理；
2. 數據級權限管理。

從控制方向來看，也可以将權限管理分為兩大類：

1. 從系統獲取數據，比如查詢訂單、查詢客戶資料；
2. 向系統提交數據，比如删除訂單、修改客戶資料。

“權限管理”是B端産品的基礎功能，B端産品經理不可避免會遇到權限設計的相關問題，行業裡已經很成熟。雖然它不是核心業務功能，但卻牽一發而動全身，需要産品經理根據具體業務使用場景來設計。

通常情況下我們所說的“權限”，包括“功能權限”和“數據權限”，“功能權限”指用戶登錄系統後能看到哪些模塊，操作哪些按鈕，企業中的由于用戶擁有不同的角色，分工職責不盡相同。

比如常見的CRM系統，銷售人員和财務人員由于處理的業務不同，登錄系統後，看到的功能模塊也不盡相同；而同樣都是财務人員，因為職位等級不同，擁有的操作功能也可能不同。

尤其是針對删除或者撤銷的功能權限的控制。比如“删除”的操作，不會随意提供給一個普通員工。而數據權限指的是用戶在某個模塊裡能看到哪些範圍的數據，比如A業務經理隻能看到自己的客戶數據，但是A的業務總監可以查看到各個區域業務員的客戶數據，

4. 功能權限中按角色訪問控制設計

其基本思想是，對系統操作的各種權限不是直接授予具體的用戶，而是在用戶集合與權限集合之間建立一個角色集合，每一種角色對應一組相應的權限。

一旦用戶被分配了适當的角色後，該用戶就擁有此角色的所有操作權限。

這樣做的好處是，不必在每次創建用戶時都進行分配權限的操作，隻要分配用戶相應的角色即可。而且角色的權限變更比用戶的權限變更要少得多，這樣将簡化用戶的權限管理，減少系統的開銷。一般情況下的角色權限時相對穩定的，而用戶則因為時間的變化而需要獲取相關新的權限。

基礎模型：用戶與角色是多對多的關系。一個用戶可以擁有若幹角色，一個角色也可以賦予若幹用戶。但并不意味着角色之間的關系互斥與否。

在企業的後台管理系統中，通常包含多種管理模塊，有針對供應商的模塊、客戶的模塊、财務人員的模塊、統計管理人員的模塊。為了避免内部信息的交叉傳播，以及操作人員可能存在的誤操作行為，我們就可以通過此種基于角色的訪問控制模型，為後台的操作者設置多種角色，并為每個角色賦予不同的業務權限，精确到對應菜單模塊的控制，甚至是相應的按鈕權限。

這樣就可以讓銷售同事隻能查閱和修改供應商管理模塊，無法查閱公司的财務信息。而财務同事也隻能查閱和修改财務報表相關的管理模塊，無法查看公司的訂單彙總，不同崗位各司其職，互不幹擾。

對于小型的企業，當一個人既負責銷售部，又負責運營部時，就可以為其賦予銷售人員、運營人員兩個角色，這樣他就擁有這兩個角色的所有權限，即可以訪問這兩個模塊的内容。但是公司規模越大，對每個崗位的權責要求也更為細緻，角色之間可能會有相應的組合關系。有必要理清楚崗位，職務，職位，權限，角色。

毫無疑問：權限是這些概念中的最細粒度的一個東西，而角色是一組權限的集合。崗位是職位的同義詞，他們的側重點不同。

職務才是被大家忽略的一個概念：具體定義不是很清晰，但他是某一業務中某一角色應當承擔的責任或者說應該負責的事。

一個職位一般來說有多個職務，比如說我們的經理助理這麼一個“職位”可能要負責的事情可能有很多類，如：協助安排經理的日程，對下面呈上來的某類報告做初步審理等等一條條。這些被我們認為梳理出來的一條條的東西就是職務 – 他在當前職位上需要擔負的義務。

大家初期容易将崗位抽象成一個角色，但是最終發現這個角色可能粒度太粗或者是不宜重用，這個時候就應該梳理一下每個職位的職務，以職務為單位抽象成角色，這樣才能制定出更細粒的角色。

當然職位由于他是我們看的見摸得着的，所以直接将職位映射成角色是非常簡單清晰沒有異議的，而職務就不同了，他需要産品人員深入理解客戶的業務，這樣才能根據客戶的業務情況梳理出一個業務職務體系，這個過程必然會很辛苦。

5. 關于功能權限設計的幾點Tips

1. 如果項目初期不需要權限管理，一定記得提醒開發同學，預留相關接口。
2. 功能權限設計，也包括頁面權限和接口權限，這一點沒有經驗的産品同學可能注意不到，需要保證沒有該模塊功能權限的用戶直接輸入頁面地址或調用接口時，也無法訪問。
3. 一個頁面完成一件事，避免頁面交互方式太複雜，無法劃分功能權限。
4. 功能權限與數據權限有時可以通過模塊進行轉換。

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

題圖來自Unsplash，基于CC0協議

,